I am having trouble getting a laptop running (null)+up2date to use devices on a docking port w/o rebooting. I can not get the laptop to recognize that it now has more PCI devices that it had when the machione was booted. If I plug in the laptop into the docking station (after it was booted w/o it), "lspci -H 1" would show all the docking station devices, but the simple "lspci" would not. And I have an opposite problem if I reboot the laptop in the docking station and then unplug it. It might have been working at some previous point, but I am not sure.
I started to use HP Omnibook 500 with RH 7.2 and this feature never worked. Currently I'm running 7.3 with 2.4.18-5 kernel. Here is lspci -H1 output of docked laptop: [root@localhost root]# lspci -H1 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) 00:0b.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus (rev 10) 00:0b.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 10) 00:0d.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator 00:11.0 IDE interface: CMD Technology Inc PCI0648 (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) If laptop was booted undocked and than connected to docked station, CMD648 with attached dvd drive is unavailable and lspci without H1 key doesn't show it.
Correct. You would need to write a hotplug driver for the docking bridge. I've got a rather hackish one for the Thinkpad bridge but it needs some work and parts of it really need the 2.5 tree to do the resource assignment at the moment. Alan
Here is what I have: % lspci 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02) 00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] 02:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 02:01.0 CardBus bridge: Texas Instruments PCI1420 02:01.1 CardBus bridge: Texas Instruments PCI1420 02:03.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) % lspci -H1 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] 02:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 02:01.0 CardBus bridge: Texas Instruments PCI1420 02:01.1 CardBus bridge: Texas Instruments PCI1420 02:03.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) 02:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) My biggest issue is not being able to use the netwoprk card on the docking station. Even if I unload the 3c59x and load it back, it still does notice the second card.
> Correct. You would need to write a hotplug driver for the docking bridge. Well, until the driver is there, is there some way to "manually" [de]activate the devices on the docking station w/o a reboot? At least some of them? The way this currently works, I do not have any way to use a USB mouse when using docking station (again, short of rebooting every time) - the USB hubs on the docking station are not activated and the USB hub in the laptop is physically inaccessible when laptop is in the docking station. This is very inconvenient, to say the least. In would be really nice to be able to activate the docking station USB hubs somehow. Another annoying aspect is that I boot with the docking station and then unplug, the machine freezes for short periods of time whenever something tries to access the docking station eth card. Again, could be really nice to be able to tell the kernel that the card is no longer there... The third proiority (for me) would be being able to use the station eth adapter after booting without it, but it's not as bad as with USB - the onboard eth socket is on the side (and not on the back) of the laptop and I can still use it even when plugged into the docking station.
P.S. Is http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=101312609603679&w=2 somthing I should try?
Thats the kind of code that needs writing for each given laptop. There may also be specific code to control latches, bus isolation and the like. Code something like that seems to be what is needed for the IBM docking bridge (which I don't yet have completely working). Alan
Alan, I have to admit - I do not quite understand what you just said. For *manual* hotplugging, is something really needed beyond re-scanning the PCI bus? I've tried the rescanning "module" by Vladimir Kondratiev (http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=101312609603679&w=2) and it does pick up the eth card at 02:08.0 (see my comment from 2002-10-02 20:28:38 above), but unfortunatelly does not pick up the additional USB hubs at 00:1d.1 and 00:1d.2 (haven't really looked at the code yet, but I am guessing it doesn not see the difference between the already known hub at 00:1d.0 and does not realize that new hubs were added). Going back to your previous comment - are you saying this additional work is neede to be able to properly *activate* the new devices or just to *detect* when the new devices appear? If it's only a detection problem, I'd imagine that simply rescanning the PCI bus (or whatever) at every resume might be a pretty acceptable solution for most users (at least until something bettere is worked out).
Created attachment 85984 [details] A "module" to rescan the PCI bus.
I was successful in updating the "pci rescan" module (attached) to notice my USB devices, so my USB mouse now works! It even seems to work reasonable well with hotplug - the modules for the newly detected devices are loaded properly by hotplug. Now I just need to make sure it work as well for undocking and find a reasonable place to put it in APM scripts (should probably go into /etc/sysconfig/apm-scripts/apmcontinue-pre on resume).
Opening bug to public eye.
Created attachment 86004 [details] Code that works for undocking as well.
Instructions: - compile as a module - use apmcontinue (or better: change ampscript to call ampcontinue-pre with $@ for arguments (see bug 44603) and use apmcontinue-pre) to modprobe (or insmod) the module on power change and on resume - Note: the modprobe/insmod will fail and print error messages - ignore them it's normal (the thing is not relally a proper module). I use /sbin/modprobe -q pcibus > /dev/null 2>&1 || /bin/true in my scripts. Work really great for me (of course, your milage may vary). P.S. I am quite surprized that this pcibus module is not anywhere as well-known as you might expect based on how useful it is and how easy it is to use (well, at least once you code the missing functionality ;-) ).
My code descussed here, for PCI bus rescan, was written for hot plug PCI slot, there is such slot that looks like extender, with large switch so you can turn it on/off. Aleksey, thanks for adding code for multi-function devices. Card I used to plug was single function, so I just forgot to iterate over functions. I will add your code. What I was unable to do, is to assign IRQ to this slot, if it has no device at the moment of POST. Seems like BIOS assign IRQ route, and even kernel, while booting, can't add new routing. I tested it like this: switched on the host, while slot is off, when in boot loader menu - switched on the slot. No way to assing IRQ since that. If anybody know how to deal with IRQ, not routed at POST time, please let me know.
All my devices (except for IDE controller) on all PCI, USB and PCMCIA buses seem to always share a single IRQ (11) no matter what, and so far everything works for me (even things not present at boot time - e.g. if I boot undocked and then dock) without any IRQ issues. P.S. Please use the second pcibus.c attachment, the first one had a few bugs.
ACPI may handle the IRQ lookup, also the $PIR data from the BIOS. If the system doesn't have IRQ routing data for the docking station you may have to map it out by hand (shove a card in each docking station slot, boot that way, read off the assigned IRQ's and use it as a table). Typically they are wired 'barber pole' (slot 1 inta is slot 2 int b is slot 3 int c is slot 4 int d is slot 5 int a) pci_enable_device will do IRQ assignment providing the tables are known to the kernel
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/