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,
Now we're getting somewhere! ;-)
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
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
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:
3. acpi=on pci=noacpi
All were done w/o eth0 plugged in, since that causes hangs at boot in all three
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
I am seeing this issue on i686 with 2.4.22-1-2087,2.4.22-1-2086, and
184.108.40.206.2061. 220.127.116.11.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]
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
Where can one obtain the latest pcmcia-cs update. I am already running
*** 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.