Bug 78791
Summary: | (PCMCIA, ACPI) RH 8.0 hangs at "Initializing PC Card Devices" on Toshiba 1115-S103 notebook | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Rick Richardson <rickrich> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED UPSTREAM | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | acpi-bugzilla, alan, jgarzik, warren.stark |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-03-25 05:06:04 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: | |||
Attachments: |
Description
Rick Richardson
2002-11-30 02:47:23 UTC
Created attachment 87006 [details]
Workaround for installing RH 8.0 on Toshiba 1115-S103 laptop
Appears to be kernel related. now the REAL question is which IO range needs blocking for this laptop I think the issue is bigger than just just which IO range to block so you can get thru the installation procedure. It has to do with whether or not PCMCIA support is built into the kernel. You don't want to just get thru the installation, you want to get thru the installation and have working PCMCIA support. According to all of my friends who have laptops, the root problem is that the PCMCIA kernel support is flat out broken, and has been for many versions of Redhat releases. They report that the only way to get wireless PCMCIA cards such as the Orinico to work within Redhat 7.x or 8.0 is to rebuild the kernel without PCMCIA support, and then install the pcmcia_cs package from sourceforge. In my case, that certainly solved the problem I was having (see tosh.instructions). It seems to me that if Redhat is going to make a serious push onto the desktop, these issues need to be resolved. strange. wireless works on my laptop and on the laptops of most people I know (with the exception of some bin only atmel stuf) That is really a non-helpful comment. Is this Redhat's official position on laptop support - works for us? You should try querying your own bugzilla database, google, and take a browse thru the http://www.linux-on-laptops.com/ database. You will find a large amount of people who cannot use Redhat's kernel pcmcia support, and have to go off to sourceforge for the pcmcia_cs stuff for every new Redhat release, meanwhile hoping that "the next Redhat release" would be one where they wouldn't have to do this anymore. The core pcmcia support has to work first. I stand by my position that Redhat needs to figure out how to get the union of the functionality that is in their kernel version of pcmcia and the pcmcia_cs stuff if they are serious about making a push onto the desktop. the official position is that we use the official kernel's pcmcia. From an historic note: this kernel pcmcia came from the sourceforge pcmcia (got submitted to Linus, and Linus accepted it and integrated it more). The code is still pretty similar, that is why I suspect there is some IO range acting up. A blanket "I only accept it if you go wholesale to the sourceforge pcmcia" doesn't get us anywhere. Unless there is an idea WHY it doesn't work, it's a non-starter. IO range is the most likely suspect in that. What do you need from me in order tomake sure that Redhat 8.1 has a fix? first step is to try the rawhide kernel-pcmcia-cs package since that has a port range excluded that broke IBM thinkpads for one... maybe your laptop is affected by that range too. I installed kernel-pcmcia-cs-3.1. Note that I also had to install hwdata-0.61-1.noarch due to a dependecy. Further note that those two RPMs have a conflict with /etc/pcmcia/config. I did a --force to load kernel-pcmcia-cs-3.1, so its version of /etc/pcmcia/config was installed. I then booted the original RH 8.0 kernel. Did an "insmod pcmcia_core". No problem. Did an "insmod i82365". This failed, device not detected. Note that this is the device that the sourceforge pcmcia_cs package selects as appropriate for the OZ6933 Cardbus Controller, and which it is able to successfully initialize. Just for laughs, I then tried an "insmod yenta_socket". Whammo, system lockup. Note that "yenta_socket" is what the RH 8.0 installer selected for my controller when I did the original RH 8.0 installation. Bottom line, its still broken. What to try next? if yenta_socket hangs the box.... then it's not an IO port thing Can you attach lspci -vxxx output ? Created attachment 88773 [details]
output of lspci -vxxx
output of lspci -vxxx
Created attachment 88774 [details]
lspci -vvv output from my machine without pcmcia loaded
Created attachment 88775 [details]
dmesg with debug in kernel pci-i386.h
Adding myself in as a CC to this bug , also experiencing the same problem with the same laptop. Have installed RH 8.0 using workaround above. Tried update of pcmcia package and the computer starts but doesn't allocated any IRQ's for what I guess is the pcmcia card.. When using stock standard RH kernel after a reboot get the following errors: "Starting pcmcia: PCI: No IRQ known for interrupt pin A of device 02:04.0. Please try using pci=biosirq" and "Starting pcmcia: PCI: No IRQ known for interrupt pin B of device 02:04.1. Please try using pci=biosirq" followed by a lock up. I've tried the pci=biosirc without any result. Turning debug on in /usr/src/linux/arch/i386/kernel/pci-i386.h shows the following extra messages: "IRQ for 02:04.0:0 -> not found in routing table" "IRQ for 02:04.1:1 -> not found in routing table" along with some other stuff I have attached as "dmesg.txt" I cannot do an lspci with the pcmcia version from source forge while pcmcia is started - it reports "pcilib: Cannot open /proc/bus/pci/03/00.0" "lspci: Unable to read 64 bytes of configuration space" With standard RH installed kernel lspci -vxxx as requested has been attached, as has lspci -vvvv I have tried the latest kernel (2.4.21-pre1 if I remember right) to see if it made any difference, no luck there :( Willing to try anything to get this to work :) If it is anything to do with the IRQ , windows XP pro on the same box is allocation IRQ 10 to the cardbus controllers. Warren In order for interrupts to be properly routed, you will need a recent-level ACPI enabled kernel. ACPI is a work in progress. You will need to abandon RedHat's kernels, which are ancient with respect to ACPI. Here's a place where you can go to see what I've been up to lately... http://home.mn.rr.com/richardsons/toshiba-1115-s103/ I hope Redhat 8.1 comes with an ACPI-enabled kernel. I have a theory, as yet untested, that if the Redhat kernel had been ACPI-enabled, then the kernel PCMCIA drivers would have "just worked", and the installation process wouldn't have hung. I also hope someone at RedHat runs down to Best Buy and picks up one of these laptops for $500 (Yes, they are on sale this week for $500), and puts it into the testing lab. These laptops are dirt cheap for what you get, and there will be a lot of them floating around. Created attachment 88780 [details]
lspci -vvv using linux-2.4.20 + acpi-20021205
Note that with the 2.4.20+ACPI kernel, the interrupts are routed.
trying fixes mentioned by Rick.. will update later today if I can get them to work for me, maybe Redhat can try these out as well if they have the hardware? We are aware of them. Also of the ACPI issues. Putting ACPI into a distro is hard because of code quality concerns (and lousy buggy acpi tables in bioses). Should be more info on that side of things soon with acpi loaded , along with other fixes from Rick I'm all up and running now. All PCMCIA deviced on my system are now working properly (netgear MA401 wireless card and NETCOMM 10/100 network card), though I had to get updated drivers for the netcomm card (rtl8139 based). If only RH could get the acpi stuff added... this would resolve this problem but comments from Alan Cox would indicate this may make the situation worse :( Warren: Did you go with ACPI+kernel PCMCIA drivers, or ACPI+sourceforge PCMCIA drivers? I was wondering if my "theory" about ACPI being the key ingredient in order to get the kernel PCMCIA drivers to fly had just been tested by you. :-) Alan and Redhat: Two weeks ago I had never heard of ACPI. Now I know more than I want to, and am a Heretic on the ACPI mailing list :-). Let me throw out a couple of ideas for RH 8.1. First, at some point RH has to test the ACPI waters. Maybe it won't be ripe yet to be the default for the 8.1 install. But what you could do is compile it in but make it so that it isn't turned on unless you give a boot line parameter "with-acpi". That will let some of us give it a shot, while not risking problems with the default installation. Second, it seems to me that the critical bits of ACPI are the boot time hardware configuration, such as interrupt routing. I wonder if a case couldn't be made for an ACPI-lite that just takes care of the critical stuff and doesn't result in so much kernel bloat? Maybe its not possible to strip it down, I don't know. I used the pcmcia from sourceforge as it supported my wireless card with the linux-wlan project (loading a real prism2 driver rather than the orinioco one). I can give the kernel pcmcia a try but I'll need a bit of time on that one... Christmas just about on us and all :) I'll be keeping my eye on this bug anyway and if I give kernel pcmcia a try I'll post the results. Warren A few things: We've actually been using static ACPI tables for interrupt routing already; Red Hat was the driving force behind the "acpitable" support in the kernel so that we could make some use of ACPI before the entire stack was ready for general use. We were a bit ahead of the curve there. There's already the ability to turn off ACPI when it has been built in using "acpi=off". Unfortunately, acpi=off does not get rid of bugs introduced by merging ACPI into the kernel. The default state (on or off) doesn't affect merge bugs, either, so changing it to be off by default wouldn't solve that class of problems. Using the AML interpreter to set up the ioapic is very new functionality that has only recently been introduced in the 2.5.x ACPI codebase and is still buggy, at least in the implementation as backported to the 2.4 kernels. In fact, I'm not sure if we've found a system on which it works yet. ACPI-lite has been a raging debate for several years now, I won't fan those flames here. :-) Unfortunately, ACPI caused too many problems in our first pheobe beta release and had to be removed. We're working directly with Intel on it, though, so it's not forgotten or ignored. Thank you for the update. I've pretty much come to the conclusion that ACPI support, especially on laptops, may be an intractable problem for Redhat. On the one hand, you have the ACPI standards bearers controlling the kernel ACPI implementation. On the other hand you have the reality of the what the major PC vendors have actually shipped, and continue to ship. Neither side seems particularly interested in budging, leaving the unsophisticated end-user high and dry. With the exception of suspend/resume, I have all hardware working on this laptop using a combination of hacked-ACPI, the omnibook module, the sourceforge pcmcia_cs package, the linux-wlan driver from absolute value systems, and the slmdm driver from smart link. I am so far off the stock-Redhat-kernel map at this point that ACPI is just a tiny teardrop in the hours-of-customization bucket. I ought to go into business making a new distro: RedLap :-) BTW, Greg Gulik my partner in crime in getting RH8 working on this laptop did take the plunge a couple months ago and installed RH9 on this same laptop. The good news is the normal RH install did not hang like with RH8. The bad news is that not much else is improved. Here's where you can read about it... http://home.gagme.com/greg/linux/toshiba1115-rh9.php Red Hat updated ACPI in Fedora Core 1, and built it into the kernel by default. It can be enabled on the command line with "acpi=on". Fedora Core 2-test1 has even newer ACPI enabled by default without any boot parameters. If you have problems with them on his hardware, feel free to re-open this bug (it will be the oldest ACPI bug in red hat bugzilla;-) or open a new one. thanks, -Len (Linux ACPI maintainer) |