I am running 2.6.17r8 on a Blade 100 with X 7.1.1 and whenever I try to shut it down, it hangs just after tring to go back to OPB and freezes there. I say "trying" because on the same freeze screen I can see gentoo shutdown messages, (get this, in a pink color font!!) like "unmounting filesystems..." AND the OBP OK> prompt.
From there I get no response from keyboard or anything so I always have to power it off by holding down the power button for a few secons.
The strange thing is that this does not happen when rebooting, and it's driving me nuts.

Here are the commands I use:
poweroff system freezes
reboot system reboots with success
shutdown -i 0 now system freezes
shutdown -h now system freezes
shutdown -r now system reboots with success.

There are numerous buggy BIOSes and motherboards out there that can cause this. As a result there are quite a few options in the kernel to workaround this. The most prominent one I know about is "Processor Type and Features --> Enable X86 board specific fixups for reboot".

There are numerous buggy BIOSes and motherboards out there that can cause this. As a result there are quite a few options in the kernel to workaround this. The most prominent one I know about is "Processor Type and Features --> Enable X86 board specific fixups for reboot".

BIOS and x86 are PC terms. Blade 100 is a SPARC platform, therefore in stead of BIOS it has OpenBoot Prom and instead of a x86 CPU it's a UltraSPARC IIe CPU.
Thanks for the info though. I'll be sure not to miss it if I use a PC._________________Blade 100 2.6.17r8
a wise man said once:
"Give your sun a sparc with Gentoo"

For Hummingbird PCI controllers, we should create the root
PCI memory space resource as the full 4GB area, and then
allocate the IOMMU DMA translation window out of there.

The old code just assumed that the IOMMU DMA translation base
to the top of the 4GB area was unusable. This is not true on
many systems such as SB100 and SB150, where the IOMMU DMA
translation window sits at 0xc0000000->0xdfffffff.

So what would happen is that any device mapped by the firmware
at the top section 0xe0000000->0xffffffff would get remapped
by Linux somewhere else leading to all kinds of problems and
boot failures.

While we're here, report more cases of OBP resource assignment
conflicts. The only truly valid ones are ROM resource conflicts.

[PATCH] sparc64 pt_regs fixes

[PATCH] pci: don't try to remove sysfs files before they are setup.

The PCI sysfs attributes are created after the initial PCI bus scan. With
the addition of more return value checking and assertions in the device and
sysfs layers we now can get dumps like this on sparc64:

For Hummingbird PCI controllers, we should create the root
PCI memory space resource as the full 4GB area, and then
allocate the IOMMU DMA translation window out of there.

The old code just assumed that the IOMMU DMA translation base
to the top of the 4GB area was unusable. This is not true on
many systems such as SB100 and SB150, where the IOMMU DMA
translation window sits at 0xc0000000->0xdfffffff.

So what would happen is that any device mapped by the firmware
at the top section 0xe0000000->0xffffffff would get remapped
by Linux somewhere else leading to all kinds of problems and
boot failures.

While we're here, report more cases of OBP resource assignment
conflicts. The only truly valid ones are ROM resource conflicts.

[PATCH] sparc64 pt_regs fixes

[PATCH] pci: don't try to remove sysfs files before they are setup.

The PCI sysfs attributes are created after the initial PCI bus scan. With
the addition of more return value checking and assertions in the device and
sysfs layers we now can get dumps like this on sparc64:

It's triggering because removal of the "config" PCI sysfs file for the
device fails.

On sparc64, after probing the device, we'll delete the PCI device via
pci_remove_bus_device() if we cannot find the firmware device tree node
corresponding to it.

This is fine, but at this point the sysfs files for the PCI device won't be
setup yet.

So we should not try to do anything in pci_remove_sysfs_dev_files() if
pci_sysfs_init() has not run yet.

I might give it a try when I get time.
Although I can't help it wonder why would 2.6.17r8 be released as stable if this issue were kernel-related..._________________Blade 100 2.6.17r8
a wise man said once:
"Give your sun a sparc with Gentoo"

Blade 100 is a SPARC platform, therefore in stead of BIOS it has OpenBoot Prom and instead of a x86 CPU it's a UltraSPARC IIe CPU.

Ahh, here I did not know...at my work we run Blades as well, but all of ours are x86 or EM64T (Intel anyways) based. Since I am not a hardware guy/server admin (Programmer by trade, DBA by job description), I am not certain what models of Blades we run, nor did I "know" that your Blade 100 was a Sparc machine. Based on my experience with Blade Servers, I naturally assumed that yours was Intel based as well....my bad. BTW, I appreciate the wake-up call, it shows me how used to working in a 98% Intel/Windows shop I have become...which is why I refuse to become a Server Admin at this shop....but I digress...

You think the whole "Gentoo on Sparc" title of this thread would have clued me in....

Ahh, here I did not know...at my work we run Blades as well, but all of ours are x86 or EM64T (Intel anyways) based. Since I am not a hardware guy/server admin (Programmer by trade, DBA by job description), I am not certain what models of Blades we run, nor did I "know" that your Blade 100 was a Sparc machine. Based on my experience with Blade Servers, I naturally assumed that yours was Intel based as well....my bad. BTW, I appreciate the wake-up call, it shows me how used to working in a 98% Intel/Windows shop I have become...which is why I refuse to become a Server Admin at this shop....but I digress...

You think the whole "Gentoo on Sparc" title of this thread would have clued me in....

I think I led you to confusion by saying Blade. My mistake. I should have said Sun Blade 100 Workstation, which has nothing to do with those pluggable server modules, called "blades", sold today by many vendors, IBM, HP, Hitachi, to name a few... AFAIK, those seem to be generally Intel based._________________Blade 100 2.6.17r8
a wise man said once:
"Give your sun a sparc with Gentoo"

Right. Sun too does sell those...
Hey Weeve, anything I can do about the above-mentioned shutdown-system-hang issue?_________________Blade 100 2.6.17r8
a wise man said once:
"Give your sun a sparc with Gentoo"

OBP 4.5.9
I think the latest is 4.6.x
Should I try an upgrade? Although, I heard somewhere that 4.6 has issues with linux..._________________Blade 100 2.6.17r8
a wise man said once:
"Give your sun a sparc with Gentoo"