April 2004 - openSUSE AMD64 - openSUSE Mailing Lists

Kernel panic installing Suse 9.0 (amd64) on presario r3000
by Magnus Christensson 08 Apr '04

08 Apr '04

I'm trying to install suse linux professional 9.0, amd64 edition, on a compaq presario r3000 laptop. When booting from the DVD I get this panic: Real Time Clock Driver v1.10e Unable to handle kernel paging request at virtual address 000000008010ddbf print rip: 000000008010ddbf PML4 0 Oops: 0010 CPU 0 Pid: 0, comm: swapper Not tainted RIP: 0010:[<000000008010ddbf>] RSP: 0000:ffffffff8048dfd8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffff8010dda0 RCX: 0000000000000001 ... CS: 0010: DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 000000008010ddbf CR3: 00000000000101000 CR4: 00000000000006e0 Process swapper (pid: 0, stackpage=ffffffff8048d000) Stack: ffffffff8048dfd8 0000000000000000 0000000000000000 ffffffff8010de2a 0000000000000108 ffffffff8048f775 ffffffff803e4ca0 0000000000000000 Call Trace: [<ffffffff8010de2a>]{cpu_idle+42} Code: Bad RIP value. <0>Kernel panic: Attempted to kill the idle task! Same with the no-ACPI and safe switches in the menu. I actually got it to start the install process once, but now I always get the panic. Has anyone managed to install 9.0 on such a machine? Any other ideas? M.

4 7

RE: [suse-amd64] Opteron Board preference ....
by Alan Gray 08 Apr '04

08 Apr '04

Very informative !!! Thanks Alan > -----Original Message----- > From: ascotti(a)email.unc.edu [mailto:ascotti@email.unc.edu] > Sent: Thursday, 8 April 2004 12:16 PM > To: William A. Mahaffey III; suse-amd64(a)suse.com > Subject: Re: [suse-amd64] Opteron Board preference .... > > > > > --On Wednesday, April 07, 2004 7:00 PM -0500 "William A. > Mahaffey III" > <wam(a)HiWAAY.net> wrote: > > > Darrell Shively wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hi William: > >> > >> On Wednesday 07 April 2004 05:54, William A. Mahaffey III wrote: > >> > >> > >>> [...] > >>> > >>> Hmmmm .... I thought the CPUs talked to eachother (at > least the 200 & > >>> 800 series) through high speed busses & could shuttle data between > >>> eachother as fast as direct memory access (except for > some small latency > >>> to start the proceedings), no ? > >>> > >>> > >> > >> Turns out no. The Hyptertransport connection between the > processors > >> *is* very fast but not as fast as each processors' 128+ > bit wide memory > >> bus. This is why the processor affinity feature of NUMA > kernels is > >> important; it tries to keep a process on the processor whose RAM > >> contains its data. > >> > >> > >> > >>> I had been leaning toward some of the > >>> balanced MP boards (TYAN S2882, Arima HDAMA) on that count. > >>> > >>> > >> > >> It depends on your needs. A second processor can be > useful even if it's > >> memory access is via a hypertransport link. It depends on > what sort of > >> jobs you are running - if stuff fits mostly in the 2nd processors' > >> cache then there is happiness. > >> > >> Regards, > >> - Darrell > >> - -- > >> sused(a)mucus.com "Perfect! ....what am I doing?" > >> -- Washu > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.0.7 (GNU/Linux) > >> > >> iD8DBQFAdB5Veo6c0kw6mZ0RAkurAKCiJKUfv8aSxeUjfS5hF9D4WfNf3wCgt6B1 > >> KiTOydpVERJIfX8PLiCywCU= > >> =nCUl > >> -----END PGP SIGNATURE----- > >> > >> > >> > > Actually most of the stuff I run would be large jobs requiring a > > significant fraction of available RAM, too big to fit into cache. I > > thought the actual data speed of the hyper-transport bus > (6.4 GB/s) was > > similar to the memory bus (6.4 GB/s using PC3200 RAM, 5.3 GB/s using > > PC2700 RAM), although by different means (64 bit > dual-channel DDR bus at > > either 166 MHz or 200 MHz for the RAM, 16 bit DDR at 1600 > MHz for the > > hyper-transport bus). I would also be interested in knowing > how SMP is > > working .... just to help keep the already busy thread going :-). > > I can relate my experience with a quad opteron. Using the > STREAM benchmark, > which calculates bandwidth by measuring the time required to > perform simple > operations on large arrays (where the bottleneck is the > streaming speed), I > get about 2 GB/s on a single CPU, (PC2700 ->333MHz*16 5.3 > GB/s, 1.4 GHz CPU > speed). Under a NUMA kernel (e.g. 2.4.21-207, SLES SP3), the > collective > bandwidth gets as high as 7.5 GB/s, running on 4 CPUS, > whereas running a > non NUMA kernel (2.4.24) it rarely exceeds 3 GB/s. I have > observed similar > trends with different codes, all constrained by the memory > bandwidth. The > bottom line is > 1) The theoretical Bandwidth is an ephemeral goal. Compilers > just are not > that tuned. I can get closer if I start writing my own > assembler code, but > that takes time.. > 2) NUMA makes a big difference. > 3) Using standard MPICH benchmarks, CPU X to CPU Y bandwidth > is of the > order of 750 MB/s, for large packets. Why so low, I do not > know. It could > be related to the compiler used to compile the MPICH library > (pgcc with > -fastsse -Mvect=prefetch, v 5.1, 64 bit). I have read > elsewhere that pgcc > does not produce good code (I think was for the ATLAS > libraries), but that > might have to do with the way ATLAS routines are written. > Actually, it > would be interesting to hear from other people on the best > combination of > compiler/switches. On a related note, I have not noticed much > difference > between compiling in 32 or 64 bit. > > Having said that, my BIOS (quartet motherboard, manifactured > by Celestica) > allows to distribute memory addresses in a roundrobin > fashion among CPUs. > When this option is enabled, a large array is spread > uniformly among CPUs. > While this is bad running NUMA, it could improve the performance with > traditional SMP kernels, but I have not tried that. > > Overall, I am quite happy with the machine. Based on runs of > a CFD code > (parallel), each Opteron CPU is equivalent to 2.5 Athlon cpus > at the same > frequency. It took almost a month to put all the pieces of > software and > firmware to work together, but it was worth the hassle. > > Alberto Scotti > > > -- > Check the List-Unsubscribe header to unsubscribe > For additional commands, email: suse-amd64-help(a)suse.com > >

1 0

Re: [suse-amd64] Opteron Board preference ....
by Mark Horton 07 Apr '04

07 Apr '04

Oh yes, I've tried all the BIOS updates. I'll contact rioworks directly to see if they can add support for the megaraid 4x raid card. I previously dealt with Accelertech because that's what all the boxed documentation said to do. BTW I noticed the HDAMC is not listed on the www.rioworks.com website. Does anyone happen to know why? Mark John McCorquodale wrote: > > You are, I assume, aware that there have been several BIOS updates over the > last year for the HDAMA and like any mobo these days you shouldn't expect > them to work (at all, really) out of the box without flashing in the newest > BIOS? >

1 0

RE: [suse-amd64] Kernel panic installing Suse 9.0 (amd64) on pres ario r3000
by mark.langsdorf＠amd.com 07 Apr '04

07 Apr '04

> > I'm trying to install suse linux professional 9.0, amd64 > > edition, on a compaq presario r3000 laptop. When booting > > from the DVD I get this panic: > > > > Real Time Clock Driver v1.10e > > Unable to handle kernel paging request at virtual address > 000000008010ddbf > > print rip: > > 000000008010ddbf > > PML4 0 > > Oops: 0010 > > CPU 0 > > Pid: 0, comm: swapper Not tainted > > RIP: 0010:[<000000008010ddbf>] > ^^^^^^^^ > > Your BIOS doesn't have a workaround for K8 erratum #93 and > dropped the upper 32bits of the RIP. Best option is to get > an fixed BIOS. AMD is working with Compaq, HP, and eMachines to fix these problems and to make sure that similiar problems do not persist in the future. However, all companies respond best to customer complaints so if you have one of the machines with a BIOS bug, please alert the manufacturer. -Mark Langsdorf Team Lead, Linux Device Drivers AMD, Inc.

1 0

RE: [suse-amd64] Opteron Board preference ....
by Pettini, Don 07 Apr '04

07 Apr '04

Hi Mark, I had the Tyan 2885 with the LSI MegaRAID SCSI 320-4x working. I found that you need to manually install it as the scan doesn't find it for some reason, so we had to install the module manually(megaraid.o, if you try megaraid2.o the system locks up). Don > -----Original Message----- > From: Mark Horton [mailto:mark@nostromo.net] > Sent: Tuesday, April 06, 2004 1:26 PM > To: SuSE AMD 64 Mailing List > Subject: Re: [suse-amd64] Opteron Board preference .... > > I'll chime in my 2 cents worth... > > I have an Arima HDAMA and a Tyan 2885 and both work great. > However, the HDAMA didn't support our raid card. The card is > a MegaRAID SCSI 320-4X. > I called Accelertech a couple of times, and they were nice, > but they didn't seem to have the resources to track down the > problem. As far as I could tell I was the only person in the > world who was having this particular compatibility issue. > They did say if I sent them the card they would try to fix > the issue, which I thought was a good sign. I ended up > getting the tyan because I knew they already had support for the card. > > From what I understand some (or all) of the IWill opteron > boards are the same as the Arima boards. The Arima HDAMC is > the same exact board as the IWIll DK8X. > > A couple of nits about the HDAMA. 2 of the dimm slots on the > second cpu are very close to each other. The other dimm > slots have a slight space between them. These 2 dimms, when > populated, are almost touching, while the other have a decent > space between them. This probably isn't a huge deal but it > worried me a little. The tyan board has a space between all > 8 dimm slots. > > One final nit-pick in the HDAMA. Accelertech's website > (www.accelertech.com) has been down for over a week now and > is still down. They seemed to provide support, bios upgrades > and docs, for the Arima boards. > > Mark > > > > Miller, Daniel J. wrote: > > MSI-9131 and Arima HDAMA have both been good for us. One > of our MSI's > > has 6gig of RAM, most of the rest of our systems have 4gig > (or less). > > > >>From past personal experience with the Tyan 24XX (and > other) boards, > >>I'd > > stay away from Tyan. Supposedly Tyan boards are now OK (they won't > > just die after a few months to maybe 3 years) but I'd let > someone else > > prove or disprove that supposition. The only other board line I've > > ever seen with a failure rate like Tyan's is PCChips. > > > > I hate to be so negative about a line that has so many terrific > > looking board designs, but so it goes. > > > > Maybe our distributor happened to store their Tyan boards > next to an > > industrial microwave oven with broke shielding, leaving the boxes > > pristine but mortally wounded components inside, and no one > but us has > > had reliability problems with Tyan boards - but I doubt it. > > > > Tyan has been offering attractive designs for a long time. > I remember > > an early dual Pentium (wouldn't support MMX, just Pentium) > Tyan system > > that had a screwed up cache controller design limiting its > effective > > memory support to 64 meg. At least that board didn't flat out fail > > after a year. > > > > They make some very appealing systems, because they're > often the first > > (or the only) company to offer some configurations, but I know that > > I've learned to find something else, however appealing the > Tyan may look. > > > > I'll probably get seduced into trying them again in about 2 > years, but > > my most recent experiences (with some Athlon MP boards) > will keep me > > away from Tyan for a while. > > > > Get an Asus, MSI, or Arima board. > > > > -----Original Message----- > > From: wam(a)mail.hiwaay.net [mailto:wam@mail.hiwaay.net] On Behalf Of > > William A. Mahaffey III > > Sent: Saturday, March 27, 2004 8:28 AM > > To: SuSE AMD 64 Mailing List > > Subject: [suse-amd64] Opteron Board preference .... > > > > > > .... I am getting close to trying to build an Opteron based > machine as > > a compute node on my LAN, set up to run w/o monitor, keybd, > mouse, & > > not a file server, just a (fast) CPU & lots of RAM. I have narrowed > > down to either ASUS SK8V or TYAN Tomcat K8S (both available @ > > newegg.com). Does anyone have any strong (preferably firsthand :-)) > > opinions, yea or nay, about either of these boards ? Thanks > in advance. > > > > > > > -- > Check the List-Unsubscribe header to unsubscribe For > additional commands, email: suse-amd64-help(a)suse.com > > >

3 2

RE: [suse-amd64] Opteron Board preference ....
by Miller, Daniel J. 07 Apr '04

07 Apr '04

MSI-9131 and Arima HDAMA have both been good for us. One of our MSI's has 6gig of RAM, most of the rest of our systems have 4gig (or less). >From past personal experience with the Tyan 24XX (and other) boards, I'd stay away from Tyan. Supposedly Tyan boards are now OK (they won't just die after a few months to maybe 3 years) but I'd let someone else prove or disprove that supposition. The only other board line I've ever seen with a failure rate like Tyan's is PCChips. I hate to be so negative about a line that has so many terrific looking board designs, but so it goes. Maybe our distributor happened to store their Tyan boards next to an industrial microwave oven with broke shielding, leaving the boxes pristine but mortally wounded components inside, and no one but us has had reliability problems with Tyan boards - but I doubt it. Tyan has been offering attractive designs for a long time. I remember an early dual Pentium (wouldn't support MMX, just Pentium) Tyan system that had a screwed up cache controller design limiting its effective memory support to 64 meg. At least that board didn't flat out fail after a year. They make some very appealing systems, because they're often the first (or the only) company to offer some configurations, but I know that I've learned to find something else, however appealing the Tyan may look. I'll probably get seduced into trying them again in about 2 years, but my most recent experiences (with some Athlon MP boards) will keep me away from Tyan for a while. Get an Asus, MSI, or Arima board. -----Original Message----- From: wam(a)mail.hiwaay.net [mailto:wam@mail.hiwaay.net] On Behalf Of William A. Mahaffey III Sent: Saturday, March 27, 2004 8:28 AM To: SuSE AMD 64 Mailing List Subject: [suse-amd64] Opteron Board preference .... .... I am getting close to trying to build an Opteron based machine as a compute node on my LAN, set up to run w/o monitor, keybd, mouse, & not a file server, just a (fast) CPU & lots of RAM. I have narrowed down to either ASUS SK8V or TYAN Tomcat K8S (both available @ newegg.com). Does anyone have any strong (preferably firsthand :-)) opinions, yea or nay, about either of these boards ? Thanks in advance. -- Check the List-Unsubscribe header to unsubscribe For additional commands, email: suse-amd64-help(a)suse.com

3 3

Opteron Board preference ....
by William A. Mahaffey III 07 Apr '04

07 Apr '04

.... I am getting close to trying to build an Opteron based machine as a compute node on my LAN, set up to run w/o monitor, keybd, mouse, & not a file server, just a (fast) CPU & lots of RAM. I have narrowed down to either ASUS SK8V or TYAN Tomcat K8S (both available @ newegg.com). Does anyone have any strong (preferably firsthand :-)) opinions, yea or nay, about either of these boards ? Thanks in advance.

5 12

OT: Unsubscribe
by Andreas Huennebeck 07 Apr '04

07 Apr '04

Sorry for the inconvenience, but after numerous unsuccessful tries to unsubscribe from this list using the officially announced mail addresses: Could please someone responsible for this list unsubscribe ah(a)bruker.de from SuSE AMD64 Mailing list? Thank you. Andreas

2 1

Re: [suse-amd64] SCSI problem on Tyan Thunder 2882
by Alan Gray 07 Apr '04

07 Apr '04

Any SCSI above 160 needs the correct sort of teminators. What happens when you go into the SCSI bios (Control-A) and detect the drives. The cabling for SCSI 160/320 can be critical. >From: Andreas Jaeger <aj(a)suse.de> >To: arno(a)lucienet.de >CC: suse-amd64(a)suse.com >Subject: Re: [suse-amd64] SCSI problem on Tyan Thunder 2882 >Date: Wed, 31 Mar 2004 07:46:10 +0200 > >Arno Seitzinger <arno(a)lucienet.de> writes: > > > Hi NG, > > > > I have a problem with a 4 disk raid0 on a dual opteron tyan board. > > > > When copying large files, the kernel reports 'scsi0 transmission error > > detected' > > > > Where do I start sorting out the problems? Software or hardware problem? > >This sounds like a hardware issue. > > > The board is a Tyan Thunder K8S Pro S2882, the drives are Fujitsu >MAS3367NP. > > OS is Suse Linux 9.0 64bit > > The scsi controller is an on board aic7902w dual channel u320 scsi > > controller. In the bios, I enabled the termination. > > > All 4 drives are connected to the scsi-a connector, there is a >termination > > board at the last drive and the jumper on the drive is set to provide > > terminal power > > > > I placed the complete error messages at www.lucienet.de/scsiprob.txt > > > > Any help will be appreciated > > >Andreas >-- > Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj > SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 ><< attach3 >> _________________________________________________________________ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail

2 1

kernel panics during bootup on quad-opteron
by ALBERTO D SCOTTI 06 Apr '04

06 Apr '04

Hi, I have been trying to run 2.4.24 on a quad opteron (Quartet motherboard, from Celestica). If I enable NUMA, the kernel panics during bootup most of the times. Occasionally it will boot ok (without me doing anything special). I have tried the various noapic, idle=poll without success. I can get it to consistently boot if I specify pci=off, but then the machine it is not of great use, since the RAID card is mounted on a PCI slot... When it crashes, I get (I am copying from the screen by hand...) CPU 3 PID:1, comm, swapper not tainted RIP: 0010:[<ffffffff801421e7>] RSP:0000:0000010003c33e78 EFLAGFS 00010016 The CPU number varies (but never 0), the content of RIP is always the same. I can copy more, if necessary. The BIOS is the most recent (upgraded to fix sluggish memory). Note that kernel 2.4.19-NUMA boots fine as so does 2.6.4, with NUMA enabled. THe reason I am trying to use 2.4.24 is that when it works is gives good performance and has openAFS supported. I tried to get openAFS to work on 2.4.19-NUMA, without luck. OpeanAFS has not been ported yet to 2.6... Any help will ber greatly appreciated. Thank you Alberto Scotti -- Alberto Scotti Asst. Prof. Dept. of Marine Sciences CB 3300 University of North Carolina Chapel Hill, NC 27599-3300 919-962-9454 (w) 919-962-1254 (f)

1 0