Bug 74510

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/