Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 104320
Summary: | kernel-2.4.22-1.2061.nptl.athlon hangs during boot when initializing PCMCIA if internal NIC used | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Chris Ricker <chris.ricker> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | pfrields, tedkaz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-21 18:58:34 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 100643 | ||
Attachments: |
Description
Chris Ricker
2003-09-12 14:48:48 UTC
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. |