Redhat 8.0 on 1655MC

Michael James michael.james at
Mon Mar 24 17:41:00 CST 2003

On Tue, 25 Mar 2003 02:26 am, you wrote:
> Well, I rebooted using the single processor kernel and uptime says...
>   9:19am  up 3 days, 22:16,  1 user,  load average: 4.28, 6.35, 6.96
> We only have 10 blades and the others are allocated unfortunately.  Are your
> Suse 8.1 blades all single processor? :)

A lot of people reported running single processor as a workaround.

But mine are all twin PIII 1.4 Gig.
I'm running an SMP kernel supplied by Suse.
I've not found the need to turn off acpi
 despite a lot of people suggesting it on lists.

The drivers for the disk controllers were the critical thing for me.

Suse chose mptbase and mptscsih
 and they are the only ones that can see the disks.
Redhat 7.3 used them too.

I don't know the version numbers involved but before the upgrade
 to a kernel dated 27 November 2002, It wouldn't boot.
It just couldn't read the root disk and we had a kernel panic.

For me, once it booted it ran fine.
I'm running tg3 ethernet drivers but getting some whierdness.

There has been a lot of discussion on this list about ethernet drivers,
 both the tg3 and broadcom drivers have problems, that expose kernel bugs.

Search back along this list for Jeff Garzick,
  there has been a lot of activity
 so upgrading to the newest versions
 would probably be worthwhile.

Good luck, if there's any other info that would help...

Michael James				michael.james at
System Administrator			voice:	02 6246 5040
CSIRO Bioinformatics Facility	fax:		02 6246 5166

Jeff Garzik's post from 27 Feb 2003  follows:

Just wanted to expand on the hints in my previous email.  Am a bit
snowed in here ATM, without direct access to the lab, but through
the help of remote users, I have been able to nail down the freezing
problems with tg3.

The first was a deadlock with the NAPI component of the net stack.
This was the cause of the "freeze" after appearing to work for
multiple hours.

The second was a BroadCom-requested change that works around a hardware
bug -- but their workaround is what causes machines to freeze instantly
when the interface is up'd.  Thanks, BroadCom :)

Anyway, expect to see another test kernel soon, and then the changes
rolled into the next Red Hat Linux release, and also the next kernel
errata release.

Until then, my current [unofficial, not-red-hat-or-dell-approved] workaround
suggestions are:
* run a uniprocessor kernel
* or, run "noapic" on kernel command line
* or, use an e1000 board

More information about the Linux-PowerEdge mailing list