|
Bugzilla – Full Text Bug Listing |
Greg, any idea what may be going wrong here? This has reverted to the pre 9.2, 9.3, 10.0 method of looking at the buses. Using setpci -s 0:a.0 SUBORDINATE_BUS=0A is the only way to get cardbus working. This problem had logged to the SuSE site over 18 months ago and a patch was developed and incorporated into later kernels. Kernel bug 2944. Yes, and according to that kernel.org bugzilla number, this has already been fixed in the mainline kernel, which is what we are using here. I'm really curious as to why if you use the "assign-busses" option, the nvidia driver doesn't work anymore. If you use the opensource version of the driver, does it all work properly? Currently using the xorg nv driver. When I used the assign busses, sax2 was not able to see the video card and would not run. Trying startx reports that no screens are seen. I did a compare of probe.c in the current 10.0 and the 10.1 beta3. There were changes made in that code (and possable else where in the pci subsystem) that are causing this problem. Those changes have caused the pci checking of the busses to revert to the same actions as when the 2944 bug was reported. The only command that works for me is the setpci command then insert the cardbus card that I need to use. With out the setpci command, the system knows only that a card was inserted. What other information would you like from this system? Additional information: bus assignments change with pci=assign-busses:
-[0000:00]-+-00.0 nVidia Corporation nForce3 Host Bridge
+-01.0 nVidia Corporation nForce3 LPC Bridge
+-01.1 nVidia Corporation nForce3 SMBus
+-02.0 nVidia Corporation nForce3 USB 1.1
+-02.1 nVidia Corporation nForce3 USB 1.1
+-02.2 nVidia Corporation nForce3 USB 2.0
+-06.0 nVidia Corporation nForce3 Audio
+-06.1 nVidia Corporation nForce3 Audio
+-08.0 nVidia Corporation nForce3 IDE
+-0a.0-[0000:01-09]--+-[0000:02]-+-00.0 NEC Corporation USB
| | \-00.1 NEC Corporation USB
| \-[0000:01]-+-01.0 Realtek Semiconductor Co., L td. RTL-8139/8139C/8139C+
| +-02.0 Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller
| +-04.0 Texas Instruments PCI1620 PC Card Controller
| +-04.1 Texas Instruments PCI1620 PC Card Controller
| \-04.2 Texas Instruments PCI1620 Fi rmware Loading Function
+-0b.0-[0000:0a]----00.0 nVidia Corporation NV17 [GeForce4 420 Go 32 M]
+-18.0 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTrans port Technology Configuration
+-18.1 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Ma p
+-18.2 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Contr oller
\-18.3 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellane ous Control
The address for the vidio changes and both startx and sax are looking for the Nvidia card on 0.10.0 .
Can you attach the output of the 'hwinfo' program? Also, the output of 'lspci -v' when booting both with and without the "assign-busses" option? Emailed hwinfo -- too big to add as comments. lspci -v (normal boot): 00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at f0000000 (32-bit, prefetchable) [size=128M] Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [c0] AGP version 2.0 00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev a6) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: 66MHz, fast devsel, IRQ 10 I/O ports at 2040 [size=64] I/O ports at 2000 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209 Memory at e8000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 193 Memory at e8001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2) (prog-if 20 [EHCI]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201 Memory at e8004000 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201 I/O ports at 1400 [size=256] I/O ports at 1c00 [size=128] Memory at e8002000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.1 Modem: nVidia Corporation nForce3 Audio (rev a2) (prog-if 00 [Generic]) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: 66MHz, fast devsel, IRQ 193 I/O ports at 1800 [size=256] I/O ports at 1c80 [size=128] Memory at e8003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5) (prog-if 8a [Master SecP PriP]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at 2080 [size=16] Capabilities: [44] Power Management version 2 00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=128 I/O behind bridge: 00003000-00007fff Memory behind bridge: e8100000-e97fffff Prefetchable memory behind bridge: 50000000-53ffffff 00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 16 Bus: primary=00, secondary=01, subordinate=01, sec-latency=10 Memory behind bridge: ea000000-eaffffff Prefetchable memory behind bridge: f8000000-fc0fffff 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at ea000000 (32-bit, non-prefetchable) [size=16M] Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at fc000000 (32-bit, prefetchable) [size=512K] [virtual] Expansion ROM at fc080000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Hewlett-Packard Company Unknown device 006b Flags: bus master, medium devsel, latency 64, IRQ 185 I/O ports at 7000 [size=256] Memory at e8104000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) Subsystem: Hewlett-Packard Company Unknown device 12f4 Flags: bus master, fast devsel, latency 64, IRQ 217 Memory at e8100000 (32-bit, non-prefetchable) [size=8K] 02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, medium devsel, latency 168, IRQ 177 Memory at e8102000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: 50000000-51fff000 (prefetchable) Memory window 1: e8400000-e87ff000 I/O window 0: 00003000-000030ff I/O window 1: 00003400-000034ff 16-bit legacy interface ports at 0001 02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, medium devsel, latency 168, IRQ 185 Memory at e8103000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176 Memory window 0: 52000000-53fff000 (prefetchable) Memory window 1: e8c00000-e8fff000 I/O window 0: 00003800-000038ff I/O window 1: 00003c00-00003cff 16-bit legacy interface ports at 0001 02:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, medium devsel, latency 64 I/O ports at 7400 [size=64] Capabilities: [44] Power Management version 2 lspci -v (assign-busses) - 00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at f0000000 (32-bit, prefetchable) [size=128M] Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [c0] AGP version 2.0 00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev a6) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: 66MHz, fast devsel, IRQ 10 I/O ports at 2040 [size=64] I/O ports at 2000 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209 Memory at e8000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 193 Memory at e8001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2) (prog-if 20 [EHCI]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201 Memory at e8004000 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201 I/O ports at 1400 [size=256] I/O ports at 1c00 [size=128] Memory at e8002000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.1 Modem: nVidia Corporation nForce3 Audio (rev a2) (prog-if 00 [Generic]) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: 66MHz, fast devsel, IRQ 193 I/O ports at 1800 [size=256] I/O ports at 1c80 [size=128] Memory at e8003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5) (prog-if 8a [Master SecP PriP]) Subsystem: nVidia Corporation Unknown device 0c80 Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at 2080 [size=16] Capabilities: [44] Power Management version 2 00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=09, sec-latency=128 I/O behind bridge: 00003000-00007fff Memory behind bridge: e8100000-e97fffff Prefetchable memory behind bridge: 50000000-53ffffff 00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 16 Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=10 Memory behind bridge: ea000000-eaffffff Prefetchable memory behind bridge: f8000000-fc0fffff 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Hewlett-Packard Company Unknown device 006b Flags: bus master, medium devsel, latency 64, IRQ 185 I/O ports at 7000 [size=256] Memory at e8104000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) Subsystem: Hewlett-Packard Company Unknown device 12f4 Flags: bus master, fast devsel, latency 64, IRQ 217 Memory at e8100000 (32-bit, non-prefetchable) [size=8K] 01:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, medium devsel, latency 168, IRQ 177 Memory at e8102000 (32-bit, non-prefetchable) [size=4K] Bus: primary=01, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 50000000-51fff000 (prefetchable) Memory window 1: e8400000-e87ff000 I/O window 0: 00003000-000030ff I/O window 1: 00003400-000034ff 16-bit legacy interface ports at 0001 01:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, medium devsel, latency 168, IRQ 185 Memory at e8103000 (32-bit, non-prefetchable) [size=4K] Bus: primary=01, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 52000000-53fff000 (prefetchable) Memory window 1: e8c00000-e8fff000 I/O window 0: 00003800-000038ff I/O window 1: 00003c00-00003cff 16-bit legacy interface ports at 0001 01:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, medium devsel, latency 64 I/O ports at 7400 [size=64] Capabilities: [44] Power Management version 2 02:00.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: Qualcomm Inc Unknown device 444b Flags: bus master, medium devsel, latency 64, IRQ 177 Memory at e8400000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 02:00.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: Qualcomm Inc Unknown device 444b Flags: bus master, medium devsel, latency 64, IRQ 177 Memory at e8401000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 0a:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company Unknown device 006d Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at ea000000 (32-bit, non-prefetchable) [size=16M] Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at fc000000 (32-bit, prefetchable) [size=512K] [virtual] Expansion ROM at fc080000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 ugh, please attach the lspci stuff, don't paste it in, that makes it almost impossible to analize... Don't worry, I've done it already... Created attachment 67478 [details]
lspci normal
Created attachment 67479 [details]
lspci assign-busses
Created attachment 67480 [details]
difference between the two lspci instances.
Created attachment 67481 [details]
lspci -tv normal
Created attachment 67482 [details]
lspci -tv assign-busses
Created attachment 67483 [details]
lspci -tv diff
Still need the hwinfo please. Created attachment 67588 [details]
hwinfo file
Performed a test by reinstalling with the pci=assign-busses as an option on the install boot. The cardbus cards were seen and the video was properyly setup. I did attempt before the reinstall by booting the installed system with the pci setting. Tried resetting the system using mkinitrd and by reintalling the default kernel with a force option. This did not work, cardbus worked but video did not. Tested the pci command on a Gateway 9500 laptop (p3 900) and it did not affect the system. It appears that pci=assign-busses should be the default action, but I do not have access to enough different laptops at work that I can reload and test. I also can't say that making pci=assign-busses will work with all machines, and the it's too late to test that now during the beta phase. Adam Belay <abelay@novell.com> (Linux Plug and Play Support) told me this: > I think forcing a full renumbering may introduce some problems. ACPI > makes references to specific bus numbers, and it may make sense to ask > the acpi mailing list about how safe it is to change these numbers. > Also, bus renumbering can result in a new set of detection challenges. > If a renumbered value conflicts with a bus that is yet to be detected, > it's possible to run into problems. Regarding that pci_fixup_parent_subordinate_busnr() in only active with pci=assign-busses in 2.6.13 and newer, referring to the comment /* Attempts to fix that up are really dangerous unless we're going to re-assign all bus numbers. */ in this function, he pointed out: > It's not the actual tweaking of subordinate numbers that breaks the > systems. Rather, it's that we blindly reserve 4 bus numbers (many > BIOSes don't expect us to reserve any) for each cardbus bridge without > first checking if there's actually enough room. The conflict exists in > either case, it's just not expressed when the subordinate number is too > small. So, it appears that contrary to the comment pci_fixup_parent_subordinate_busnr, we can indeed tweak the subordinate number, but with carefully checking that we do not conflict with other bus numbers. As far as I can tell, it is also simply an issue of the PCIBIOS providing PCI tables which cannot work. E.g. Samsung fixed it's PCIBIOS tables for their X20 notebook somewhere between version 04Z and 11Z. I think, asking the notebook vendors to provide fixed PCI BIOSses for their machines would be the right thing to do, but of course we should provide something for machines which do not have a fixed BIOS installed for another reason. It seems to me, that fixing the subordinate number with setpci is the most commonly used approach for this, it's described in the wiki of the Compaq R3000 series and HP zv5000 users: http://prinsig.se/weekee/index.php/PCMCIA_%28hw%29 Also, FreeBSD people do the same: http://www.cokane.org/amd64.html http://lists.freebsd.org/pipermail/freebsd-amd64/2005-January/003365.html It seems to me that this is the most well-tested BIOS-workaround available. If we would fix the subordinate number carefully, before we load the Cardbus bridge drivers in the initramfs, we would have that, and it would also work when people choose to boot the machine with a mainline kernel, for any reason, e.g for verifying if a certain problem also appears in a specific version of mainline. I don't have such routine ready, but mkinitrd already requires pciutils, so we can rely on lspci and setpci being available when mkinitrd runs. Since lspci and setpci only link against glibc (and need only minimal libc functionality) it would also not be a problem to use them in the initramfs or to provide a special minimal pci_fixup_subordinate_numbers binary with pciutils which could be included in the initramfs. Doing that in the initramfs would also work for a boot where we resume from disk, but I see possible problems with standy and suspend to RAM: Is the PCI configuration spacs retained in it's last state when suspending to RAM? If not, and a PCI bus rescan which includes Cardbus busses takes place before the changed subordinate numbers are restored, or if there are attempts to reach cardbus devices before that, these accesses would fail and could cause trouble, especially if data on Cardbus-Connected devices is needed before userland would restore the subordinate numbers. I hope nobody would swap over Cardbus, but maybe other scenarios exist. So if the PCI configuration is not retained over suspend to ram by the machine or the kernel, the setpci approach would not work for these, and the kernel would have to fix the subordinate numbers. I think the least invaisve approach for that should be a final scan over the PCI tree which checks if PCI devices behind all PCI bridges are reachable and tries to carefully reassign subordinate numbers, if possible. Such check is already in 2.6.16, but it's not run in a final PCI scanning pass, but inside the second pass, during which PCI bus renumbering still takes place. Such check would need to be done recursively after the normal PCI bus scanning and renumbering is done. What do you think of these other options? Setting hardware to all, since this problem shows on many IA32 laptops as well. I did a patch which would selectively enable pci=assign-busses on some specific affected machines which are known to work with pci=assign-busses: http://lkml.org/lkml/2006/2/16/240 This patch, would need to be extended to allow for disabling the pci assign-busses default if it does not work on a machine where it was enabled without having been able to test all HW types or HW/BIOS combinations. The mail also contains a list of machines which I have found affected by seraching thru web pages. But, I think it's hard to test all incarnations of a specific machine, for example the Samsung X20 has been built also in at least one other configuration (I think two), one was with a ATI GPU and and other I think with a NVdidia GPU instead of the Intel 915 GPU. These older variations are not available from Samsung anymore but nonetheles many of them are out there and used under Linux. It would require quite some effort to test all different models in all usage cases, e.g. with my X20, standby and suspend2ram do not work, while it works with one of these older, different models and apparently also with a newer model, but I can't test standby or suspend2ram on my machine, and I don't know if it would also work with these other machines. It would also be a huge effort to test if forcing pci=assign-busses to on for these all X20 machines would not break e.g. machines of the same hardware but with different BIOS versions. That's also why I believe that it would be best if the vendors of the machines which are affeced provide fixes like Samsung has done for the X20. What we can do, is, I think, only provide a workaround. Bernhard, do you want me to add your patch to our kernel? I think it missed the 2.6.16 deadline (yeah, just went in after). Ok, I checked this patch in, so this should be fixed in beta 9. If not, please reopen this patch. *** Bug 161462 has been marked as a duplicate of this bug. *** It isn't fixed for me. I still have to set "setpci -s 0:a.0 SUBORDINATE_BUS=0A" to get the card working. Created attachment 76677 [details]
patch for compiling a test module to check if my fixup parent code fixes these machine too.
Andreas and Clark (and anybod who has the same problem), please try the following:
Please try the attached patch which creates a kernel module for testing if my code also fixes your machines.
What you need to compile it is the kernel-source rpm for the kernel which you run and the packages patch and gcc. The you do the following as root:
cd /usr/src/linux
make cloneconfig include/asm include/linux/version.h scripts
make SUBDIRS=drivers/pci modules
insmod drivers/pci/fixup-parent-busses.ko
Be sure that you safed all unsafed data now and that
you have backups of anything important on the machine,
just in case the machine would crash now.
Then continue with:
lspci -v | grep -e ^0 -e subordinate| grep -B1 subordinate >prior.lspci
tail -f /var/log/messages
sync
echo > /sys/module/fixup_parent_busses/parameters/fixup_parent_subord
lspci -v | grep -e ^0 -e subordinate| grep -B1 subordinate >after.lspci
Add a bugzilla comment with output of the
tail -f /var/log/messages which should snow up if
everything worked and with the lspci output wich
was captured in prior.lspci and after.lspci.
I can also attach a kernel module built to x86_64 Beta9 if building the module yourself is too much hassle, but with the steps which I provided, it should be straight forward, if not, send me a note.
I will have to reinstall beta 9 as I installed it using the pci=assign-busses option. Clark,
it may be possible to avoid the reinstall by reconfiguring X from scratch using
sax2 -r
From man sax2:
-r Remove detection database and re-init the hardware database
The author of sax2 recommeneded me to use this option whenever there is
something which sax2 might not expect. It ignores all prior knowledge of
sax2 about the system, your card and your configured modes and starts fresh.
That would be done of course after you booted into runlevel 3 (no X) and
without pci=assign-busses.
You can do such boot for example also by pressing the ESC key at the graphical boot screen, entering the text-based boot grub boot screen thereby.
Then, you can press 'e' within grub to edit the kernel command line to temprorarily remove the pci=assign-busses and replace that with a "3" (without the quotes) to tell init to not boot into the default runlevel (which is 5, with X login) but into runlevel 3 (no X, just console).
That is temporary only unless you edit /boot/grub/menu.lst and make or change an entry to have that grub configuration file.
The reason why startx might not work may be that the BusID of the Device
might change with pci=assign-busses, it's used in this part of /etc/X11/Xorg.conf:
Section "Device"
BoardName "915 GM"
BusID "PCI:0@0:2:0"
Driver "i810"
Identifier "Device[0]"
VendorName "Intel"
EndSection
For your Nvidia Card, the BoardName and Driver will be different, but the
section will look very similar. It coul even be possible that simply adding a '#' in front of the BusID line might make X working with and without pci=assign-busses.
If the test module works as expected, it would do nearly the same as
setpci -s 0:a.0 SUBORDINATE_BUS=0A, with the only difference that the
kernel knows abot the changed subordinate number internally. Once that
test is done (which can be done also without X), we know that the code
is fine for your Presario R3000 too, and that's all so you could reboot
and keep using X with pci=assign-busses.
But, because of the problems with having to configure X differently, I'd
like to use the subordinate fix approach (by using the code in the module
or setpci -s 0:a.0 SUBORDINATE_BUS=0A) to avoid possible mass problems of
people not having a working X configuration after updating the system to
a kernel which does pci=assign-busses and later away from it.
Until the subordinate fixup is done automatically, the setpci command could
be manually added to /etc/init.d/boot.local. Alternatively, the test module
could be copied to /lib/modules/`uname -r`/kernel/drivers/pcmcia and be added
to INITRD_MODULES in /etc/sysconfig/kernel. This would cause that the fixup
is done very early and certainly before loading the PCMCIA controller driver,
so that should work as smooth as pci=assign-busses, but without the need for
a different X configuration.
Created attachment 76844 [details]
syslog output
It works just fine with this module as you can see.
prior.lspci:
00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode])
Bus: primary=00, secondary=02, subordinate=02, sec-latency=128
00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) (prog-if 00 [Normal decode])
Bus: primary=00, secondary=01, subordinate=01, sec-latency=10
--
02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
after.lspci:
00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode])
Bus: primary=00, secondary=02, subordinate=0a, sec-latency=128
00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) (prog-if 00 [Normal decode])
Bus: primary=00, secondary=01, subordinate=01, sec-latency=10
--
02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
Andreas, Many thanks, I found that the code did a number of rounds thru the chained PCI lists and I simplified that part to do just what is needed and tested that on my machine. I attached it to the corresponding kernel.org bug with this comment: http://bugzilla.kernel.org/show_bug.cgi?id=2944#c23 It would be nice if you could try that simplified version, it also produces less syslog output. I'd change that version to be built into the kernel and called automatically after the kernel scanned the PCI bus during early bootup and submit it for large-scale review and inclusion into mainline if this test works as well. Created attachment 77254 [details]
syslog output
Works just fine, here is the syslog output.
Thanks.
-- andreas
Thanks, good to see that it worked. Now I have any actual patch which you could call a 'fix' and which I could propose on linux-kernel for inclusion into the main kernel line. It is a lot smaller and a lot easyer to understand and read as the test modules since the code is now well tested enough to be placed at a specific critical place where it can do it's job in time and from the best starting point without having to look for hidden cardbusses, which is the initialisation of the cardbus bridge itself. It covers what I have seen in terms of debug output so far and I think that this should cover all machines, maybe only 90%, but it should fix your machines and it can be checked if other machines need a different fix, but this would be similar to this fix, just the place would be more common (in the PCMCIA Cardbus controller register function then). So this patch only targets machines with a yenta_socket-compatible cardbus controller who's parent bridge's subordinate number was not high enough, which was the case for all machines which I saw and where the code is tested using the module as well. You can see the use of yenta_socket when you run "lsmod | grep yenta" and when you look at the syslog messages from system boot in /var/log/boot.msg, they may look somewhat similar to this: <6>Yenta: CardBus bridge found at 0000:06:09.0 [144d:c01a] <6>Yenta: ISA IRQ mask 0x0098, PCI irq 11 <6>Socket status: 30000006 <6>pcmcia: parent PCI bridge I/O window: 0x4000 - 0x4fff <6>cs: IO port probe 0x4000-0x4fff: clean. <6>pcmcia: parent PCI bridge Memory window: 0xb8000000 - 0xb80fffff <6>pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x32ffffff If you apply the patch in http://bugzilla.kernel.org/attachment.cgi?id=7813&action=view from Comment 25 of the corresponding kernel.org bug report http://bugzilla.kernel.org/show_bug.cgi?id=2944 then insead of compiling the test module in drivers/pci, compile the PCMCIA drivers using make SUBDIRS=drivers/pcmcia modules and unload the Cardbus Controller driver with rmmod yenta_socket and load the patched yenta driver using insmod drivers/pcmcia/yenta_socket.ko, you should see these two messages included(intermixed) in the syslog output of the controller initialisation during insmod: Yenta: Increasing subordinate of bus #02 from #02 to #06 Yenta: Increasing subordinate of bus #02 from #06 to #0a That would be the confirmation that the fix is indeed finished. Created attachment 78078 [details]
yenta_socket insmod syslog
It works just fine for me. Thanks :)
Thanks, looks very good! Looks all well for me. Dominik Brodowski has offered to include it in his pcmcia git tree to test it in the -mm kernel series, which is also a good sign. I guess it might be possible to include that also in our kernel soon, but I'd like to ask Greg if he has an opinion on that. No objection from me, care to send me the patch that Dominik is going to include in his tree through email (or attach it here) so that I can add it to our kernel tree? Created attachment 78105 [details] fix the subordinate number of the parent bridge in yenta_socket_probe within limits This is the patch which Dominik Brodowski offered to add to the pcmcia git tree for testing in -mm: http://bugzilla.kernel.org/show_bug.cgi?id=2944#c27 I only removed trailing whitespace and changed it to apply with -p1 (that was what he asked for) and updated a few comments, no code. I forgot: I did a checkout of our kernel CVS now and would like to add that the patch (in attachment 78105 [details] from comment #34 above) obsoletes my previous patch to turn on pci=assign-busses for the Samsung X20 series: patches.drivers/pci-0031-Cardbus-cards-hidden-needs-pci-assign-busses-to-fix.patch This patch for activating pci=assign-busses should be removed if this patch is applied because it is superflous with the yenta-fixup-parent-bridge patch in place and could (in theory) cause some problems on other X20 models which I do not have. It also changes the warning message in pci/probe.c, but that hunk should be removed also, so you can remove the entire patch. It is also part of 2.6.17-rc1 - I think it should be removed from mainline too and instead, the yenta-subordinate fix. I'll send a mail to linux-kernel tomorrow about that then. Status update: I sent the cardbus-cards-hidden-fixup-parent-subordinate-carefully.patch to the lkml ( http://lkml.org/lkml/2006/4/14/45 ) and akpm added it to his tree, temporarily but apparently he overlooked that I mentioned at the top of my mail that it's already in the 2.6 pcmcia git tree which goes into -mm. He was so nice to create a patch which reverts my initial attempt with enabling pci=assign-busses (which was only activated for the Samsung X20) and apply it to his tree - the following was part of a mail sent over mm-commits@vger.kernel.org: -------------------------------------------------------------------------- The patch titled revert pci-pci-cardbus-cards-hidden-needs-pci=assign-busses-to-fix has been added to the -mm tree. Its filename is revert-pci-pci-cardbus-cards-hidden-needs-pci=assign-busses-to-fix.patch See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find out what to do about this From: Andrew Morton <akpm@osdl.org> As described in the next patch, revert commit 8c4b2cf9af9b4ecc29d4f0ec4ecc8e94dc4432d7 Author: Bernhard Kaindl <bk@suse.de> Date: Sat Feb 18 01:36:55 2006 -0800 Cc: Andreas Schneider <mail@cynapses.org> Cc: Bernhard Kaindl <bk@suse.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> --- arch/i386/pci/common.c | 32 -------------------------------- drivers/pci/probe.c | 4 +--- 2 files changed, 1 insertion(+), 35 deletions(-) --------------------------------------------------------------------------- ... So he seems to like that reverted too. Created attachment 79337 [details]
Carefully fixup subordinate bus number of the partent of the CardBus bridges
Latest diff with:
* lastest list of systems affeced by this problem
* added on which system it'S verified
* listed the people who tested it on their machines
* removed a superflous initialisation of upper_limit at it's declaration: As can be seen in the patch, it is initialized unconditionally later before it's first use.
Bernhard, when could I expect it part of our kernel? We are close to release. Reassigning it to Bernhard. It's not safe to add to the 10.1 kernel at this late in the cycle. for SLES10/SLED10, I could see adding it, it just needs more real-life testing, there is a lot of wierd hardware out there... Created attachment 82866 [details] detailed description of the patch for understanding and veriflying it Update: The patch is now: * since 4 weeks in the pcmcia-2.6 git tree * since soon 4 weeks posted on linux kernel (URL: http://www.spinics.net/lists/kernel/msg463423.html) and added to the -mm kernels. There have been * no critical comments, * no failure reports and it fixed every laptop which which it was expected to fix, which is a handful of machines now. I'm attaching a full-detail description of the patch to aid understanding and verifying it. Because of the soon 4-week-long inclusion into the -mm kernels and the good reports on it in http://bugzilla.kernel.org/show_bug.cgi?id=2944 I'm getting more more eager to check it in and I think I may do it tomorrow (maybe too late for SLES RC1, but you never know) unless Greg is able to give me a tangible reason to stay away from it. I disabled the patch in our CVS for now on Greg's request. The discussion about it is on our internal list. He wants to see the patch in mainline first before it's added to out tree at this point. The patch was submitted by the resplonsible maintainer to mainline http://lists.infradead.org/pipermail/linux-pcmcia/2006-June/003703.html and is in mainline since 2.6.18, so it did become part of 10.2 and this bug is fixed in all distributions which use a kernel based on 2.6.18 or newer. I wrote a detailed description of the patch which isn't found anywhere else so far, so I paste it here and close it: Short description: ------------------ This patch fixes detection of the CardBus cards in many notebooks due to a too low subordinate number of the parent PCI-PCI bridge It fixes the subordinate number of the parent PCI-PCI bridge of CardBus bridges when one is probed, before registering the CardBus bridge with the kernel and scanning its slot for devices. Longer description: ------------------- On a number of Laptops, the PCI scans do not find any CardBus cards because the parent bridge of the CardBus bridge is not configured so that Type 1 PCI configuration cycles can reach the CardBus cards. On one of the affected Laptops, a Samsung X20, Windows XP does a full pci bus renumbering, so the problem is not seen with Windows. Booting with pci=assign-busses does the same but since ACPI may contain references to PCI busses and we do not translate them yet, it may break things. The generic solution used in 2.6.13 was to only increase the subordinate number, but since this was done during PCI bus discovery, it was not safe to it at this point and taken out with the next release. This patch does the same but takes care that it can never cause create a PCI bus configuration with overlapping bus numbers which was the reason why the solution of 2.6.13 was moved to pci=assign-busses. Description of the fix: ======================= Principles: ----------- Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html --------------------------------------------------------------------------- It is up to each individual operating system to allocate bus numbers during PCI configuration but whatever the numbering scheme used the following statement must be true for all of the PCI-PCI bridges in the system: ``All PCI busses located behind a PCI-PCI bridge must reside between the seondary bus number and the subordinate bus number (inclusive).'' If this rule is broken then the PCI-PCI Bridges will not pass and translate Type 1 PCI configuration cycles correctly and the system will fail to find and initialise the PCI devices in the system. --------------------------------------------------------------------------- What the patch may not do: -------------------------- The patch may not raise the subordinate number of any PCI-PCI bridge so that it overlaps with the bus ranges of other PCI-PCI bridges. It has the checks neccesary to ensure that this does not happen. What the patch does: -------------------- Called from Cardbus controller probe function, before the controller is registered, so before the devices on it can be scanned, a new function call is inserted. This function works the following way: > If the parent of the cardbus parent is a root bridge, do nothing. (The root bridge does not hide Cardbus devices, it was always ok) > The parent of the cardbus bridge has been identified as the PCI-PCI bridge who's subordinate bus number may be raised to pass and translate Type 1 PCI configuration cycles so that they can reach the devices behind the CardBus brodge, it's called bridge_to_fix. > The subordinate number the parent of the bridge_to_fix is used as the initial upper limit to which we could theoretically raise the subordinate number of the bridge_to_fix. (there is no point in exceeding the range of the parent, childs will got get Type 1 PCI configuration cycles for those anyway) > For each child bridge of the parent bridge (equal to: for each silbling and the bridge_to_fix itself), do: -> If the silbling's secondary bus number is higher than the subordinate of the bridge_to_fix (thus, it is a bridge which we have to care for when raising the subordinate of the bridge_to_fix to prevent overlapping) *and* if this silbling's secondary bus number is smaller than the upper limit, then update the upper limit to the secondary bus number of the silbling minus 1. This is repeated for all silbling bridges of the bridge_to_fix (and for the bridge_to_fix itself too, but for this to have any effect, it's secondary must be higher than it's subordinate which should never be the case but even if it is [then, the PCI config of it is totally broken and won't work anyway] is that the subordinate of it will only be raised to it's secondary minus one, so it won't have any effect) -> The upper_limit is then left at the last free bus number to which the subordinate of the cardbus parent bridge could be raised without reaching a bus number which is allocated for a different silbling bridge on the same bus and without leaving the bus range of the parent. I tested these checks to work by modifying the relevant data structures and verifying the results, so I certify that with all these tests, the upper limit was always right. If this upper limit is lower than the subordinate number of the cardbus bridge, a warning message which says which shows this constraint for raising the subordinate of the bridge_to_fix is logged. If the upper limit is higher than the subordinate of the bridge_to_fix (this means it could be raised to this limit, it is never reduced, so nothing can break), the following is done: The subordnate bus number to assign is set to the upper_limit or to the subordinate bus number of the cardbus bridge (this is the number which we want to have), whatever value is smaller. A message which logs that we raise the subordinate number of bridge_to fix to its new value is logged. The subordinate field of the PCI struct of the bridge_to_fix is set to the new subordnate bus number and the PCI config byte PCI_SUBORDINATE_BUS is set to the new number. That's it all. There are related follow-up bugs which are concerned with the kernel boot message which warns of hidden PCI busses, which is made obsolete by this patch for the cases which this patch fixes: * bug 237229 has the best initial comments * bug 225672 also tracks it (may be come a duplicate of 237229) * bug 191194 mentions it, but is about a different issue |
Clean install of Opensuse 10.1 Beta 2 on a Compaq R3120 AMD 64 laptop. Inserting pcmcia cards results in an entry in the log file that a card has been inserted in card slot 0, but the card is not activated or seen. Using pci=assign-busses causes the pcmcia cards to be seen and activated BUT then the nvidia video card is not useable by startx or sax2. Xorg reports that there are no screens. output from lspci -vt -[0000:00]-+-00.0 nVidia Corporation nForce3 Host Bridge +-01.0 nVidia Corporation nForce3 LPC Bridge +-01.1 nVidia Corporation nForce3 SMBus +-02.0 nVidia Corporation nForce3 USB 1.1 +-02.1 nVidia Corporation nForce3 USB 1.1 +-02.2 nVidia Corporation nForce3 USB 2.0 +-06.0 nVidia Corporation nForce3 Audio +-06.1 nVidia Corporation nForce3 Audio +-08.0 nVidia Corporation nForce3 IDE +-0a.0-[0000:02]--+-01.0 Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ | +-02.0 Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller | +-04.0 Texas Instruments PCI1620 PC Card Controller | +-04.1 Texas Instruments PCI1620 PC Card Controller | \-04.2 Texas Instruments PCI1620 Firmware Loading Function +-0b.0-[0000:01]----00.0 nVidia Corporation NV17 [GeForce4 420 Go 32M] +-18.0 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration +-18.1 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map +-18.2 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller \-18.3 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control