I'm seeing this on an HP Pavilion 4400 series, but list comments suggest it happens on all AMD / ATI / ALi mobile Athlon laptops When the machine boots up kernel-2.4.22-1.2040.nptl.athlon, it hangs during Starting PCMCIA services during boot up. It does this whether or not a cardbus / pcmcia card is inserted Booting the machine with acpi=off is not an option on these On older kernels, these machines have other problems (see Bug #102563), but they at least booted.... Chipset on this is: 00:00.0 Host bridge: ATI Technologies Inc: Unknown device cab0 (rev 13) 00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 320M] (rev 01) 00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02) 00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] 00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem] 00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) 00:11.0 Bridge: ALi Corporation M7101 PMU 00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1
Try with acpi=on pci=noacpi
Tried both kernel-2.4.22-1.2040.nptl.athlon and kernel-2.4.22-1.2049.nptl.athlon Both hang without options Both hang with acpi=on pci=noacpi 2.4.22-20.1.2024.2.36.nptl.athlon is what I'm using for now -- it mostly works, cardbus-wise
Now we're getting somewhere! ;-) With 2.4.22-1.2051, acpi=off hangs acpi=on hangs acpi=on pci=noacpi boots Not only that, but acpi=on pci=noacpi even boots up w/ cards inserted, and brings them up (no need for the cardctl eject, cardctl insert route)
Interesting. Can you get the boot messages from all 3 cases too ? There are a few more ACPI patches queued, but I'm somewhat sceptical they'll solve this problem.
Okay, I did a lot more poking on 2051, and it turns out at least some of the above is incorrect -- I eventually discovered that boot hangs were sometimes caused by the internal NIC being attached (and therefore enabled at boot), and some of the above was tested w/ NIC in use, and some without. What follows is definitive and replaces above comments about 2051.... If I plug an ethernet cable into the internal (natsemi) NIC and boot up (/etc/sysconfig/network-scripts/ifcfg-eth0 does DHCP and enables automatically at boot): acpi=on hangs when PCMCIA is initialized (w/ or w/o card present) acpi=on pci=noacpi hangs when PCMCIA is initialized (w/ or w/o card present) acpi=off hangs when PCMCIA is initialized (w/ or w/o card present) If I leave the internal NIC detached from the network: acpi=off actually works. It lacks all power management, but at least the boot no longer hangs. Cardbus cards work, but require the cardctl eject ; cardctl insert cycle. Machine boots w/ or w/o cardbus cards inserted. acpi=on boots okay, and does nothing when I insert a cardbus card. When I do the cardct eject ; cardctl insert, it hangs hard. Machine does boot w/ or w/o cardbus cards inserted though, since it doesn't initialize them until forced acpi=on pci=noacpi boots okay, and usually does nothing when I insert a cardbus card. Most of the time, it requires a cardctl eject;cardctl insert cycle, though sometimes it Just Works when I insert the card. It does boot w/ or w/o cardbus cards inserted. Now, here's where things get extra-fun. I'm running with acpi=on pci=noacpi, as that gives me cardbus and power management. In that configuration, the machine hangs if the NIC is plugged into a network at boot time (as is true of all other configurations tested). However: if I boot into run level 3, log in, plug the internal NIC into the network, and ifup eth0, all is fine. Cardbus works, X works, internal NIC works, etc. if I boot into run level 3, log in, start X, then plug the NIC into the network and ifup eth0, the machine locks hard if I boot into run level 5, log in, then plug the NIC into the network and ifup eth0, the machine locks hard presumably IRQ routing madness still?
Created attachment 94626 [details] boot messages with acpi=off (works, no power management)
Created attachment 94627 [details] boot messages w/ acpi=on (hangs when using cardbus)
Created attachment 94628 [details] boot messages with acpi=off pci=noacpi (works, but eth0 weirdness)
Just attached 3 boot messages: 1. acpi=off 2. acpi=on 3. acpi=on pci=noacpi All were done w/o eth0 plugged in, since that causes hangs at boot in all three configurations
I think I've managed to reproduce this. Try booting with nomce For some reason the port reservation we were doing for this chipset isn't getting done anymore, and when we poke it, it goes bang and MCEs. I'll chase this some more.
Thanks. nomce doesn't help -- with the MCE disabled, it still hangs at the Starting PCMCIA point if eth0 is already configured.... This is with kernel-2.4.22-1.2061.nptl
I am seeing this issue on i686 with 2.4.22-1-2087,2.4.22-1-2086, and 2.4.22.1.2061. 2.4.21.20.1.2024.2.1 does not have any issues at all for me :-) Have /proc stuff from bug-106327 I will attach.
Created attachment 94941 [details] /proc info Hope this is helpful.
Try with the latest pcmcia-cs update. It fixed a problem with port exlusion related to this chipset.
Which versions? I still hang with eth0 plugged in with kernel-2.4.22-1.2087.nptl kernel-pcmcia-cs-3.1.31-13
Where can one obtain the latest pcmcia-cs update. I am already running kernel-pcmcia-cs-3.1.31-13.
*** This bug has been marked as a duplicate of 100528 ***
I see this bug, too. It is rather distracting. About 1/4 of the boots stops when the booting sequence reach the pcmcia. I have to switch off the power and force a filesystem check. Then it boots correctly. I om a Itel i686 based labtop with lasted Red Hat kernel up-dates. When will Red Hat provide a bug fix?
Try latest Fedora, works like a charm for me :-) Even subcribed to rawhide. I must warn you, the terminal are a little funky though. Nothing a reset or clear can't deal with though.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.