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.
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
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
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
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"
"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
"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
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...
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
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 :(
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.
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
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
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...
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.
(Linux ACPI maintainer)