Bug 104320 - kernel-2.4.22-1.2061.nptl.athlon hangs during boot when initializing PCMCIA if internal NIC used
kernel-2.4.22-1.2061.nptl.athlon hangs during boot when initializing PCMCIA i...
Status: CLOSED DUPLICATE of bug 100528
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
1.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks: CambridgeBlocker
  Show dependency treegraph
 
Reported: 2003-09-12 10:48 EDT by Chris Ricker
Modified: 2015-01-04 17:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:58:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
boot messages with acpi=off (works, no power management) (16.21 KB, text/plain)
2003-09-22 10:54 EDT, Chris Ricker
no flags Details
boot messages w/ acpi=on (hangs when using cardbus) (17.42 KB, text/plain)
2003-09-22 10:54 EDT, Chris Ricker
no flags Details
boot messages with acpi=off pci=noacpi (works, but eth0 weirdness) (17.89 KB, text/plain)
2003-09-22 10:55 EDT, Chris Ricker
no flags Details
/proc info (14.53 KB, text/plain)
2003-10-05 18:01 EDT, Ted Kaczmarek
no flags Details

  None (edit)
Description Chris Ricker 2003-09-12 10:48:48 EDT
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
Comment 1 Dave Jones 2003-09-15 18:46:27 EDT
Try with acpi=on pci=noacpi
Comment 2 Chris Ricker 2003-09-17 09:55:25 EDT
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
Comment 3 Chris Ricker 2003-09-20 09:42:28 EDT
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)

Comment 4 Dave Jones 2003-09-20 09:52:48 EDT
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.
Comment 5 Chris Ricker 2003-09-22 10:53:03 EDT
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?
Comment 6 Chris Ricker 2003-09-22 10:54:02 EDT
Created attachment 94626 [details]
boot messages with acpi=off (works, no power management)
Comment 7 Chris Ricker 2003-09-22 10:54:54 EDT
Created attachment 94627 [details]
boot messages w/ acpi=on (hangs when using cardbus)
Comment 8 Chris Ricker 2003-09-22 10:55:46 EDT
Created attachment 94628 [details]
boot messages with acpi=off pci=noacpi (works, but eth0 weirdness)
Comment 9 Chris Ricker 2003-09-22 10:57:09 EDT
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
Comment 10 Dave Jones 2003-09-28 20:24:40 EDT
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.
Comment 11 Chris Ricker 2003-09-29 01:04:55 EDT
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
Comment 12 Ted Kaczmarek 2003-10-05 18:00:41 EDT
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.

Comment 13 Ted Kaczmarek 2003-10-05 18:01:32 EDT
Created attachment 94941 [details]
/proc info

Hope this is helpful.
Comment 14 Dave Jones 2003-10-08 21:55:47 EDT
Try with the latest pcmcia-cs update. It fixed a problem with port exlusion
related to this chipset.
Comment 15 Chris Ricker 2003-10-10 13:33:14 EDT
Which versions? I still hang with eth0 plugged in with

kernel-2.4.22-1.2087.nptl
kernel-pcmcia-cs-3.1.31-13
Comment 16 Ted Kaczmarek 2003-10-10 17:05:32 EDT
Where can one obtain the latest pcmcia-cs update. I am already running
kernel-pcmcia-cs-3.1.31-13.

 
Comment 17 Bill Nottingham 2003-10-21 16:23:29 EDT

*** This bug has been marked as a duplicate of 100528 ***
Comment 18 Flemming G. Jensen 2003-10-21 16:59:03 EDT
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?
Comment 19 Ted Kaczmarek 2003-10-21 21:13:46 EDT
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.
Comment 20 Red Hat Bugzilla 2006-02-21 13:58:34 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.