I just installed SuSE 9.0 on a dual Opteron file server. It has a 4 TB
SATA raid attached by Fibre through a Qlogic 2312 HBA. I had issues with
the hardware RAID set up (not related to SuSE), originally intending to
have a single 3.5TB device (RAID5), but ended up with 2 logical raid
devices, which appear to SuSE as /dev/sda (2TB) and /dev/sdb (1.5TB). It
takes 20 hours for the RAID to build so I don't want to change that now.
So, in order to combine the space (and allow for future expansion) I set
up LVM. I created a volume group that includes both physical volumes,
then attempt to create logical volumes. Actually, when creating the
volume group there is already a warning that the logical volume size is
limited to 2 TB. I have read conflicting information about this. In
some places, it says that this is due to the maximum block device size
in 2.4 kernels is 2TB, in some places, I read that there is a 2TB limit
imposed by 32 bit hardware (but hey, this is 64 bit hardware!). Isn't
LVM supposed to get around block device limits? Also, I am using JFS
for the file system, so that should not be limiting. When creating the
volume group I used 256 MB physical extents (the default is 32) , so
that should allow larger logical volumes.
So, I create 2 logical volumes, lvol1 (2TB) and lvol2 (1.5TB), and
create a JFS file system on each. In both cases, mkfs.jfs reports the
file system created sucessfully. Now, I can mount lvol1, but when I try
to mount lvol2, it says "wrong fs type, bad option, bad superblock, or
too many mounted filesystems" Well, the mount parameters are the same
for both logical volumes (different mount points), and they are both
freshly created filesystems, so the only possibility seems is that there
are too many mounted filesystems. But, the only other file system that
is mounted is the IDE boot disk, which contains the OS, /home, etc. all
in a single partition, plus /dev/shm.
Is there a kernel parameter I can tweak to allow me to mount more drive
space? 2TB is nothing any more (haha).
Any help will be apreciated.
Thanks for all input on compatible hardware for a SuSE 9.0 AMD64
out-of-the-box workstation instalation.
I now purchased a Tyan Tiger K8W (s2875) with 2 x Opteron 244, 2 x 1GB
Kingston reg. memory and an ASUS Geforce FX 5900 graphics card, which
should work fine. (with the Nvidia binary for 3D)
The only thing left is my SCSI controller to connect 2 x Maxtor 10K-IV U320.
I cannot find much information about compatibility besides that the
adaptec controlers "should probably work". So I'm planning the Adaptec
19160 or the 29160N.
Does anybody have experience that either or both of these controlers work
or not with this SuSE version? (Or maybe advise another controler)
Emile van Mierlo
>So, it always hangs when cpufreq is started? Then you have either a
>broken BIOS or hardware :-(.
>Please remove cpufreq, e.g.:
>Use the rescue option and remove /etc/init.d/cpufreqd (hope that's the
>right path) and try again.
Yes, to follow up my previous post: I have reinstalled Suse 9 pro
(AMD64) and was able to remove "cpufreqd" from the /etc/init.d/
directory. This definitely solved the problem. Suse boots up
normally. I also noticed that this process was skipped during the
initial installation startup procedures. So yes "cpufreqd" was causing
the problem. Everything seems nice here, and I actually have the
opportunity to relax and admire your beautiful gnome desktop. Very well
done. Hmm the "cpufreqd" problem you say, is associated with a messed
up motherboard / bios? What exactly does this service do? I do know
that I have a 350 watt power supply inside my case, which should be
enough to power the Athlon 64 (it's not an FX). Anyways I am glad this
is cleared up. Any feedback about why this possibly went wrong would be
appreciated. I don't know it could just be a problem with cpufreqd.
But I am really a non technical user. Thanks to all and Andreas.
Dear SUSE-AMD64 users.
I just bought the SUSE LINUX PROFESSIONAL 9.0 64 BIT VERSION FOR AMD64 and booted the installation DVD on my computer which has the following specs:
Mainboard: EPoX EP-8HDA3+ for Socket 754 (VIA K8T800/8237 chipset)
Processor: AMD Athlon 64 XP3200+ 2,0 GHz HT bus Socket 754 prosessor, 1 MB, BOXED
Memory: TwinMOS PC3200 DDR-DIMM 512MB m/Winbond 32M*8/16chip, 184-P (for DDR-PC400MHz)
Harddisk: Maxtor 80 GB IDE 7200 rpm
Graphics: Abit Siluro Geforce FX5200 DT 128MB AGP, DDR, TV-Out, DVI-I, Retail
>From the SUSE 9.0 boot menu I selected INSTALLATION and then the usual text from detection of IDE-drives etc. came on the screen, but unfortunately the process ended up hanging with the following text:
> misc. 1.3: read floppy
To check for any hardware errors i booted Knoppix (a cd-based linux distro), and Knoppix run perfectly on my hardware. My next step was to try to install RedHat 9.0 to have the machine workable in unntil I have figured out the SUSE problem. RedHat 9.0 aslo installed fine, but of course no 64bit utilisation.
Do you have a tip that could help me get SUSE running?
Best regards from Trond Rafoss
Hello all. I recently purchased an AMD Athlon 64 w/ a VIA K8T800 chipset.
I had a successful install from the SUSE 9 pro dvd. Yast detected
everything from the Sound Card all the way to the built in ethernet.
Everything worked and was detected flawlessly. The system seemed useable
until I rebooted the machine. The machine hung at bootup around the
"cpufreq" process. I tried safemode and the same problem occurred. During
a second re-install I have upgraded the kernel over through Yast to the
latest "bugfix" version provided by SUSE and that didn't seem to help
either. Are there any other reported issues with this VIA chipset? I
currently have Mandrake AMD64 9.2 RC1 working with no problems. I would
like to get the SUSE Pro 9 working, but this situation leaves me no choice.
Thanks for any feedback. I appreciate it.
I'm trying to compile rdiff on a SuSE 9.0 AMD-64 system. Rdiff
has librsync-0.9.6 as a dependency, which complains thusly:
/usr/lib/libpopt.so: could not read symbols: Invalid operation
Both x86 and amd64 versions of libpopt.so are installed. Has anyone
seen a problem like this? It compiles okay on an x86 version of 9.0.
Thanks in advance,
People who had problems with the SLES8-SP3 or 9.0 kernel and 3ware controllers please
test if the kernels in
fix the problem. [they should work on both 9.0 and SLES8]. The test makes only
sense when you have more than 3GB memory in your machine.
John McCorquodale wrote:
>>This is with an 8500-12 SATA raid controller. I should also mention
>>that using the 32-bit SUSE 9.0 Professional on the same machine does not
>>exhibit the corruption.
>Yes, I have this problem as well. I have reported it to 3ware (which you
>should do too; duplicate bug reports add legitimacy to problems) with no
>luck. There was some theorization on the x86-64 kernel list a few months
>ago that it was an IOMMU problem, but I never had luck with tweeking IOMMU
Yes, we reported this to 3ware as well.
>The problem I saw was that reads/writes with blocksize under 4k-N (where N was
>40 bytes or something like that) seemed to work fine, but would return all
>zeros (or bogus data) in the buffers above 4k-N or in some cases (M*4k)-N.
>Also, the first 16k (if I remember correctly) of the partition always reads
As another data point, I was able to install onto the RAID array and do
some testing with RedHat Enterprise for AMD64 with no corruption.
>The K8W appears to have serious BIOS problems setting up memory mappings
>(particularly in regard to AGP setup) when 8GB is installed, so drop your RAM
>to 1GB and see if you have better luck.
What sort of AGP problems are you seeing? We are seeing poor
performance with > 4GB.
>After I'm done here at Supercomputing, I'll try to come up with a kernel patch
>to reorganize memory mappings to sanify Tyan's BIOS's mess for 8GB, but I
>don't know that this approach will work. I'm hoping it will solve the 3ware
>problem and my AGP problem simultaneously, but I am used to engaging in
>wishful thinking. :)
Well, I'll keep my fingers crossed. :-)
I've been suspicious of Tyan - particularly their bios - due to their
response (many years ago) when I experienced problems with one of their
dual Pentium boards, that was limited to 100mhz parts (wouldn't take the
133mhz) wouldn't take MMX parts (only "classic" Pentiums) and would only
cache 64meg (not Gig, this was a long time ago) meg of RAM. In a dual
processor system, even at the time, that was a low limit.
Their tech support spin some delaying story, depending on who you spoke
to. I finally got someone new there who just told me the board design
was fundamentally bad and would never be reliable with more than 64meg.
More recently, their early 2460 dual Athlon boards were great, but later
shipments of the boards were often flakey or DOA. They did seem to fix
things with the 2466 - but I now avoid Tyan unless they have some
feature I need that's otherwise unavailable.
Given these recent reports, it seems they still can't build a bios.
Are any other manufacturer's boards having similar issues? I have an
MSI server with 6gig of RAM running SuSE EL and it seems to be just fine
(and other MSI Opteron systems with 4gig or less, also fine). There is
one setting on the MSI board (IOMMU?) that must be set properly for
>4gig operation. Our Arima boards haven't had any trouble, either, but
none have more than 4gig of RAM installed, so that's no test.
From: John McCorquodale [mailto:email@example.com]
Sent: Thursday, November 20, 2003 3:06 PM
To: Michael Madore
Cc: John McCorquodale; Mark Horton; suse-amd64(a)suse.com
Subject: Re: [suse-amd64] SUSE 64-bit + 3ware controller = Corrupt
> What sort of AGP problems are you seeing? We are seeing poor
> performance with > 4GB.
Yes, it's pathetic with 8GB installed. Bandwidth across the AGP
connector is about 17MB/s, due mostly to a bogus uncachable MTRR entry
that BIOS sets up, the removal of which blows the system away (reason
unknown; I don't know why it's there in the first place). With 1GB
installed, the frame buffer can be mapped write-combining and AGP b/w
jumps to about 250MB/s. This is the fastest I've been able to observe
actual data transport (about 1x AGP) depite the fact that the AGP
connector is signalling as fast as 8x AGP v3 (on an ATI X1).
The 8151 is on its own HT link, and that link is running at 16 bit, 600
MHz, so there's no architectural reason it should be this slow.
There is clearly something incredibly and obviously wrong going on with
way things are getting set up on the board, and being as it's been weeks
since I initially started talking to Tyan and have heard nothing back,
I'm not hopeful that they're even bothered to reproduce the problem let
alone do anything about it. I am afraid they're of the mindset that
"picture on screen == works" -- I sure wish they'd correct this
misconception if it is one.
Anyway, I'm still of the belief that there's just a crazy memory mapping
and requests to AGP are getting stalled/deferred because of some
entries somewhere. I haven't found them yet 'tho. :)
See my posts to the suse-amd64 archives for Oct/Nov timeframe for more
details and pointers to a benchmark you can play with if you're that
I really want to start making my own boards...
> Well, I'll keep my fingers crossed. :-)
Check the List-Unsubscribe header to unsubscribe
For additional commands, email: suse-amd64-help(a)suse.com
> This is with an 8500-12 SATA raid controller. I should also mention
> that using the 32-bit SUSE 9.0 Professional on the same machine does not
> exhibit the corruption.
Yes, I have this problem as well. I have reported it to 3ware (which you
should do too; duplicate bug reports add legitimacy to problems) with no
luck. There was some theorization on the x86-64 kernel list a few months
ago that it was an IOMMU problem, but I never had luck with tweeking IOMMU
The problem I saw was that reads/writes with blocksize under 4k-N (where N was
40 bytes or something like that) seemed to work fine, but would return all
zeros (or bogus data) in the buffers above 4k-N or in some cases (M*4k)-N.
Also, the first 16k (if I remember correctly) of the partition always reads
The K8W appears to have serious BIOS problems setting up memory mappings
(particularly in regard to AGP setup) when 8GB is installed, so drop your RAM
to 1GB and see if you have better luck.
After I'm done here at Supercomputing, I'll try to come up with a kernel patch
to reorganize memory mappings to sanify Tyan's BIOS's mess for 8GB, but I
don't know that this approach will work. I'm hoping it will solve the 3ware
problem and my AGP problem simultaneously, but I am used to engaging in
wishful thinking. :)
I have been in contact with Tyan about this problem, and have had no useful
response so far.
It is worth noting that there are two other AGP/PCIX Opteron boards on display
in the AMD booth at Supercomputing (and the Tyan board is absent). You
might check out the Gigabyte 7A8WD (1 32 bit, 2 PCIX, AGP, 4 DDR on 1 proc),
Iwill DK8X (2 32bit, 3 PCIX, AGP, 8 DDR).