From Bugzilla Helper:
User-Agent: Mozilla/4.73 [de] (Windows NT 5.0; U)
Fujitsu-Siemens Laptop: Lifebook X-7595 in Full-Docking-Station with extended PCI bus.
1.) installation from CD-ROM in docking station hangs on PCMCIA card lookup
--> start installation outside docking station
2.) startup-scripts of installed system in docking station hang in
modprobe usb-uhci --> boot: linux nousb
kudzu --> noS??kudzu
pcmcia --> noS??pcmcia
3.) modprobe eth1 works, as eth1 is an alias for e100, the same as for eth0
ifconfig eth1 up fails (eth1 on PCI bus in docking station)
SIOCSIFFLAGS: Resource temporarily unavailable
Hints: - 3rd IDE device in docking station works fine (hde, hdf).
- strace modprobe usb_uhci
usb.c: null device being purged!!!
<repeated x times>
usb.c: null device being purged!!!
- strace /usr/sbin/kudzu -s
wait(1114, <incomplete line>
Steps to Reproduce:
1. modprobe usb-uhci
3. /etc/rc.d/init.d/pcmcia start
Actual Results: system hangs
Expected Results: checking for new hardware
Laptop datasheet: http://www.fujitsu-siemens.com/rl/products/notebooks/professional/lifebook/lifebookx/lifebookx.html#
Port replicator: http://www.fujitsu-siemens.com/rl/products/notebooks/accessories.html#
I will attach two files: pci-off /proc/pci when off the docking station
pci-in /proc/pci when in the docking station
As you may see from the attached files, the laptop has PCI bus 0,1,2 internaly; PCI bus 5 externaly in the docking station
I asume, but have not tested it, that all cards on the external PCI bus are not working (as eth1).
Created attachment 13784 [details]
contents of /proc/pci of laptop when in/off the docking station
May I have the /proc/version string from that one?
Created attachment 13825 [details]
contents of /proc/version
Does anyone know if this happens with the 7.1 release?
The bug was filed with Wolverine originally.
Created attachment 17248 [details]
Output of 'dmesg'
the problems do still exist (more or less) in the 7.1 release.
1.) same problem as before
2.) startup-scripts now __crash__ or hang
crash: modprobe usb-uhci
hang: /etc/rc.d/init.d/pcmcia start
3.) same problem as before
Linux version 2.4.2-2 (firstname.lastname@example.org) (gcc version 2.96 20000731
(Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001
I will attach the output of 'dmesg'
That dmesg was very helpful! Now I see that UHCI (both of them)
conflict with the second IDE, apparently found in the docking
station (CD-ROM perhaps?).
After that, uhci does not fail gracefuly, and causes different
problems - locking up, crashing, etc. It is a bad thing too,
I'll look into it.
Created attachment 17288 [details]
Proper recovery if request_irq fails in usb-uhci.
With the patch to uhci the system will not crash or
lock up for that reason (I hope there are no other
reasons, the eepro100 being the next suspect).
However, fixing the IDE not to hog interrupts seems difficult.
Alan says that we have controllers in the field that sit
on PCI, but use edge triggered interrupts [presumably,
This may end in a situation when nothing works when
the lappy is docked, except the CD-ROM.
7.1 errata is out, please try that. At least USB
won't crash when it finds request_irq() bounced.
If you don't retest, I mark the bug resolved in a week.
Shared IDE interrupts were not resolved, I keep arguing
with Andre Hendriks about it. Very little can be done
at this point about it. If you are inclined so, run a
custom kernel with SA_SHIRQ set at all times, as per patch.
That's the only recourse that I see.
RESOLVED the named bug (see Summary)
USB now does not crash or hang the system
/usr/sbin/kudzu now works
service pcmcia start still hangs the system
Thanks, Toni (right back from vacation)
Resolving "in Rawhide" because I pushed the resolution
into Linus tree, so it's sure there. Dunno about
the errata, if the split off HEAD CVS was in time
to pick the fix.
I have applied all errata for 7.1 on 2001-07-10
and I'm now running kernel 2.4.3-12
I looked into usb-uhci.c and found something that
looks like the modifications of 2001-05-03
(attach_id=17288) at usb-uhci.c line 2971.
I now had the time to try the SA_SHIRQ hack (see: comment from 2001-06-25).
But that causes the machine to hang when bringing up eth1 (the one in the
I'm not shure, whether this is the right place for the hack.
Created attachment 32478 [details]
prposed hack for SA_SHIRQ (does not work)