|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>|
|Version:||8.0||CC:||acpi-bugzilla, alan, jgarzik, warren.stark|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-03-25 05:06:04 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Rick Richardson 2002-11-30 02:47:23 UTC
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; UNIX) Opera 6.1 [en] Description of problem: I have a brand new Toshiba Satellite 1115-S103 notebook. I tested Linux compatibility by using the Knoppix 3.1 Live CD. Knoppix boots and runs on this notebook. Sweet!!!! I then tried to install RH 8.0 on the notebook. It hangs at the first installation screen, where it says "Initializing PC Card Devices". I tried running the RH 8.0 install process with the option "nopcmcia", but got no joy that way, either. In that case, all I get is a completely blue screen. The Toshiba Satellite 1115-S103 is going for $650-$700 around here, so should be a very popular notebook. I urge RH to look into the problem. Obviously, Linux *can* run on this notebook, just note Redhat's version.
Comment 1 Rick Richardson 2002-12-01 22:04:04 UTC
Created attachment 87006 [details] Workaround for installing RH 8.0 on Toshiba 1115-S103 laptop
Comment 2 Michael Fulbright 2002-12-02 16:02:52 UTC
Appears to be kernel related.
Comment 3 Arjan van de Ven 2002-12-02 16:06:30 UTC
now the REAL question is which IO range needs blocking for this laptop
Comment 4 Rick Richardson 2002-12-02 17:10:58 UTC
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.
Comment 5 Arjan van de Ven 2002-12-02 22:35:50 UTC
strange. wireless works on my laptop and on the laptops of most people I know (with the exception of some bin only atmel stuf)
Comment 6 Rick Richardson 2002-12-04 11:32:16 UTC
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.
Comment 7 Arjan van de Ven 2002-12-04 11:43:30 UTC
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.
Comment 8 Rick Richardson 2002-12-04 12:09:53 UTC
What do you need from me in order tomake sure that Redhat 8.1 has a fix?
Comment 9 Arjan van de Ven 2002-12-04 12:18:21 UTC
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.
Comment 10 Rick Richardson 2002-12-04 15:34:25 UTC
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?
Comment 11 Arjan van de Ven 2002-12-04 15:37:25 UTC
if yenta_socket hangs the box.... then it's not an IO port thing Can you attach lspci -vxxx output ?
Comment 12 Warren Stark 2002-12-17 05:06:03 UTC
Created attachment 88773 [details] output of lspci -vxxx output of lspci -vxxx
Comment 13 Warren Stark 2002-12-17 05:07:29 UTC
Created attachment 88774 [details] lspci -vvv output from my machine without pcmcia loaded
Comment 14 Warren Stark 2002-12-17 05:08:25 UTC
Created attachment 88775 [details] dmesg with debug in kernel pci-i386.h
Comment 15 Warren Stark 2002-12-17 05:11:07 UTC
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
Comment 16 Rick Richardson 2002-12-17 12:16:03 UTC
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.
Comment 17 Rick Richardson 2002-12-17 14:49:25 UTC
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.
Comment 18 Warren Stark 2002-12-17 22:42:11 UTC
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?
Comment 19 Alan Cox 2002-12-17 22:58:53 UTC
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
Comment 20 Warren Stark 2002-12-18 03:04:03 UTC
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 :(
Comment 21 Rick Richardson 2002-12-18 03:41:40 UTC
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.
Comment 22 Warren Stark 2002-12-18 03:51:46 UTC
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
Comment 23 Michael K. Johnson 2002-12-18 14:35:40 UTC
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. :-)
Comment 24 Michael K. Johnson 2003-01-22 16:49:32 UTC
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.
Comment 25 Rick Richardson 2003-01-22 17:30:03 UTC
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 :-)
Comment 26 Rick Richardson 2003-06-08 20:02:39 UTC
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
Comment 27 Len Brown 2004-03-25 05:06:04 UTC
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)