Was sent thefollowing and it works.

(1) su
(2) setpci  -s 0:a.0 SUBORDINATE_BUS=0A
(3) insert a cardbus card
(4) lspci

This needs to be moved to the pci list.

The PCI bridge at 0:a.0 is not correctly setup to forward bus cycles for cards
downstream of the cardbus socket to its secondary bus.  We are seeing this
rather a lot on nVidia based systems.  Here is another case:

00:00.0 Host bridge: nVidia Corporation: Unknown device 00d1 (rev a4)
      Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
      Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
      Latency: 0
      Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
      Capabilities: <available only to root>

Host bridge - fine.

00:0a.0 PCI bridge: nVidia Corporation: Unknown device 00dd (rev a2) (prog-if 00
[Normal decode])
      Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
      Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
      Latency: 0
      Bus: primary=00, secondary=02, subordinate=02, sec-latency=128
      I/O behind bridge: 00003000-00007fff
      Memory behind bridge: e8100000-e97fffff
      BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-

PCI bridge to bus 2 forwards bus IDs 2 up to and including 2.  But, behind
this we have:

02:04.0 CardBus bridge: Texas Instruments: Unknown device ac54 (rev 01)
      Subsystem: Hewlett-Packard Company: Unknown device 006d
      Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
      Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
      Latency: 168, cache line size 10
      Interrupt: pin A routed to IRQ 11
      Region 0: Memory at e8102000 (32-bit, non-prefetchable) [size=4K]
      Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
      Memory window 0: e8200000-e83ff000 (prefetchable)
      Memory window 1: e8400000-e85ff000
      I/O window 0: 00004000-000040ff
      I/O window 1: 00004400-000044ff
      BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
      16-bit legacy interface ports at 0001

the cardbus bridges which use secondary bus numbers 3 to 6 and 7 to 10
(second function of bridge not shown here.)

The point here is - why should PCMCIA/Cardbus mess with the bridge at 0:a.0
to forward these other buses if the BIOS and/or PCI subsystem didn't do it
already?  Is it not against the modularity of drivers to mess with devices
for which we are not the driver for?

So, there are two possible solutions to this problem:
1. The BIOS is at fault for not setting up the bus numbers correctly.
   This is obviously a ludricous idea - how does the BIOS know that the Linux
   PCI subsystem itself is going to assign 4 bus numbers to each cardbus
   bridge, and do we shout at BIOS vendors when we decide we want more?

2. The Linux PCI subsystem is at fault for assigning bus numbers to the Cardbus
   bridges but not correctly adjusting upstream bridges.

(2) obviously makes a lot more sense.

Therefore, this is a PCI problem.

Created attachment 3324 [details]
pci-subordinate-busnr-fix

Clark,

Could you please show me the output of lspci -vv before and after this patch. 
It should solve your problem.  Unfortunantly, I don't have the right hardware
to properly test this.

Thanks,
Adam

Created attachment 3328 [details]
lspci -vv before patch

lspci taken before patch

Created attachment 3329 [details]
lspci after patch

Patch worked.  After inserting a Belkin usb 2.0 cardbus card, lspci showed the
card and a usb mouse plugged into the card worked.

Created attachment 3333 [details]
lspci -vv for related nVidia board PCI problem

Attached at Russell King's request.  I'm having problems with a Ricoh
PCI-to-PCMCIA converter that may be related to this bug.

Jeff's problem is slightly more interesting:

0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
(prog-if 00 [Normal decode])
        Bus: primary=00, secondary=01, subordinate=02, sec-latency=32

Forwards busses 1 to 2.

0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) (prog-if 00
[Normal decode])
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=32

Forwards bus 3.

0000:01:0a.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
        Bus: primary=01, secondary=02, subordinate=05, sec-latency=176

But the cardbus bridge, which is on bus 1 wants busses 2 through 5.  This
means that Adam's fix to just tweak the subordinate bus number of upstream
bridges will not work for this case, since that tweak would mean changing
the bridge at 8.0 to forward bus numbers 1 through 5.  But bus number 3 is
already allocated to AGP!

From my understanding of PCI (and not ACPI) I'd say that the solution is a
full PCI bus renumbering, but someone has mentioned that there is a
dependence with ACPI here.

Created attachment 3398 [details]
lspci from 2.6.8-rc2

Tried the 2.6.8-rc2 kernel.  Not able to use cardbus cards with rc2.  It looks
like some of your patch code is in the new kernel, but it did not detect the
cardbus card.

Can you try the latest -mm kernel?  Some pci allocation logic has been changed
in there that would hopefully fix this up.

Tried the mm3 patch and no joy.  Still did not see the cardbus card. 

Created attachment 3801 [details]
dmesg from mm3 test

The new pci code sees the card, but has errors and does not setup the card.

As of 2.6.10, this is still broken.  I noticed here:

http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00878.html

that Alan suggested incorporating this into the kernel (for Fedora Core
anyway), and in fact I found it last December in the 2.6.9-ac kernel.  
Any reason why this can't be included here?

*** Bug 4501 has been marked as a duplicate of this bug. ***

This patch is now in mainline.  If you could test 2.6.13-rc4 and verify that it fixes the problem, I would
appreciate it.

If not, please reopen this bug.

gregkh: please close this bug

closed.

Unfortunately, the function which has been added by the patch needed to be
deactivated because it does not check against creating overlapping bus numbers
and that caused problems with some laptops:

Ivan Kokshaysky (Continuing PCI and Yenta troubles in 2.6.13.1 and 2.6.14-rc1):
http://lkml.org/lkml/2005/9/20/114

It seems that we can only renumber all busses or fixup the parent's subordinate
numbers after we completed scanning so what we can do checks to prevent
overlapping bus numbers when fixing up the parent subordinate numbers.

I created a kernel module which does the latter and it would not hurt if it
gets some more testing. I want to turn it into a patch which gets called
after scanning the PCI root bridge(s) is completed to fix the currently known
issues with BIOSes which were too lazy to reserve bus numbers for Cardbus
bridges.

As a lot of machines are affected, seems better than an approach to do a full
bus renumbering on all affected machines, as this would require getting DMI
values for all of them and side effects to Graphic cards already happened:
https://bugzilla.novell.com/show_bug.cgi?id=146438

This is the list of currently known affected sytems:
* ASUS Z71V and L3s
* Samsung X20 (fixed in latest BIOS, but older BIOSes are affected)
* Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller,
  also Compaq R4000 series 
* HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it)
* HP zv5200z
* IBM ThinkPad 240
* An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek
  gives the correspondig message which detects the breakage.
* MSI S260 / Medion SIM 2100 MD 95600

I'll attach the patch now.

Created attachment 7775 [details]
atch for a test module to check if my fixup parent code fixes the other machines too

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 for the kernel which you
run and the packages patch and gcc. The you do the following as root:

cd /usr/src/linux
zcat /proc/config.gz >.config
make oldconfig include/asm include/linux/version.h scripts
make SUBDIRS=drivers/pci modules
insmod drivers/pci/fixup-parent-busses.ko

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.

It appears to work on my system.  Attached are the list from lspci and messages.

Created attachment 7781 [details]
before lspci

Created attachment 7782 [details]
lspci after

Created attachment 7783 [details]
listing from messages

Created attachment 7793 [details]
streamlined and cleaned-up version of the test module

Clark,

many thanks for the kernel messages and the lspci outputs, they helped a lot.

The attached streamlined and cleaned-up version of the test module should
work as the initial version. To compile it, make sure that the patch for
building the initial version is not applied (use patch -R -p0 <patchfile to
revert the initial patch) and apply it like the initial patch.

The test routine is called on module insertion time, no echo to /sys.

If it works, you load it in your system's initrd/initramfs, or otherwise
before the PCMCIA driver is loaded and a PCI scan for cardbus scans is started.


If you try it, the dmesg output created by inserting this module would be
useful to have too, it will be also much shorter.

Ultimatively, it should be part of mainline, integrated into the kernel,
not as a module (the module is for easy testing)

For Kernel developers: This version of the test module is simplified to
be straightforward in function it's more easy to understand therefore.
It's also completely documented to satisfy everyone reviewing the code
to ease inclusion into mainline and vendor kernels until it is in mainline.

Created attachment 7807 [details]
The same patch as the last one one Comment #23, but this time integrated into the yenta_socket driver

Patch header:

Fixup subordinate numbers of the yenta Cardbus Bridge when
it is initialised.

This is an early version of the patch which should be further
refined (debug printks should be removed) before it goes into
mainline.

Signed-Off-By: Bernhard Kaindl <bk@suse.de>
---

This now patches the yenta cardbus bridge driver because the systems of
which I saw debug output were obviously all using this dirver, so a least
invasive approach would be to run the code only when this driver probes a
new bridge. It may be also restricted to also run only on i386 and x86_64
machines since that are the only architectures where this problem is known.

It appears to work the same way as the previous patch for me on my laptop
but it would be good if users of a Compaq/HP notebook can test it since that
has one bus more and it would be interesting to see the syslog output generated

by it. The patch is to be applied using patch -p1.

Created attachment 7813 [details]
File: yenta-fixup-parent-v2.diff - based on attachment #7807 [details] (from comment #24), but now minimum invasive, the smallest possible code which is careful to check against overlaps

This smallest possible patch only checks the parent bridge of the yenta bridge
and fixes it, checking against overlaps. It's all what is needed to fix the
systems on which the previous code has been tested on.

Just a few more words on the last patch (attachment #7813 [details]) from comment #25,
(I was really short on time and my laptop battery was nearly empty):

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:

This patch only targets machines with a yenta_socket-compatible cardbus
controller who's parent bridge's subordinate number was not high enough.
This was the case for all machines which I saw (and where the code is
also tested using the test module)

Insteaf of using SUBDIRS=drivers/pci, as this is now part of the PCMCIA
directory, you would use

make SUBDIRS=drivers/pcmcia modules

instead of the corresponding make command in the series of commands in
comment #18 for a quick compile which is limited to the PCMCIA drivers.

For testing, you 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 one or two messages like these 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

Shall I add it to the pcmcia git tree for testing in -mm? If so, please update
it so that it doesn't add trailing whitespace and that it can be applied in the
top directory using "patch -p1", not "patch -p0" as the current version is. Thanks!

Created attachment 7844 [details]
fix the subordinate number of parent bridge in yenta_socket_probe within limits

The same patch as the last one (attachment #7813 [details] from comment #25) - obsoletes
it therefore, with trailing white space whitespace removed and changed for
applying with patch -p1 in the top directory as requested by Dominik Brodowski
for adding it to the pcmcia git tree for testing in -mm.

Dominik, thanks - yes that would be good!

Comment on attachment 7844 [details]
fix the subordinate number of parent bridge in yenta_socket_probe within limits

>Fixup the subordinate number parent bridge of yenta Cardbus Bridges
>before the PCI bus scan starts to make the cardbus cards which are
>otherwise hidden for PCI scans work. Previous versions of this code
>in the form of a test module (before putting it into yenta_socket_probe)
>have been tested on a Compaq R3120 AMD 64 laptop and (I assume) a R3140
>and another R3000 series laptop.
>
>The number of affected systems is longer (from an internet search):
>* ASUS Z71V and L3s
>* Samsung X20 (fixed in latest BIOS, but older BIOSes are affected)
>* Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller
>  (AMD64-based Laptops), also Compaq R4000 series
>* HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it)
>* HP zv5200z
>* IBM ThinkPad 240
>* An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek
>  gives the correspondig message which detects the breakage.
>* MSI S260 / Medion SIM 2100 MD 95600
>
>Signed-off-by: Bernhard Kaindl <bk@suse.de>
>
>--- linux-2.6.16/drivers/pcmcia/yenta_socket.c
>+++ linux-2.6.16/drivers/pcmcia/yenta_socket.c	2006/04/08 11:51:20
>@@ -998,6 +998,77 @@
> 	config_writew(socket, CB_BRIDGE_CONTROL, bridge);
> }
>
>+/**
>+ * pci_fixup_parent_subordinate - Fix the subordinate number parent bridge
>+ * @cardbus_bridge: Bus the CardBus bridge bridge to
>+ *
>+ * Checks if devices on the bus the CardBus bridge bridges to would be
>+ * invisible during PCI scans because of a misconfigured subordinate number
>+ * of the parent brige - some BIOSes seem to be too lazy to set it right.
>+ * Does to fixup carefully by checking how far it can go without overlap.
>+ */
>+static void yenta_fixup_parent_bridge(struct pci_bus *cardbus_bridge)
>+{
>+	struct list_head *tmp;
>+	/* Our starting point is the max PCI bus number */
>+	unsigned char upper_limit = 0xff;
>+ 	/*
>+	 * We only check and fix the parent bridge: All systems which need
>+	 * this fixup that have been reviewed are laptops and the only bridge
>+	 * which needed fixing was the parent bridge of the CardBus bridge:
>+	 */
>+	struct pci_bus *bridge_to_fix = cardbus_bridge->parent;
>+
>+	/* Check bus numbers are already set up correctly: */
>+	if (bridge_to_fix->subordinate >= cardbus_bridge->subordinate)
>+		return; /* Thanks, nothing to do */
>+
>+	if (!bridge_to_fix->parent)
>+		return; /* The root bridges are ok */
>+
>+	/* stay within the limits of the bus range of the parent: */
>+	upper_limit = bridge_to_fix->parent->subordinate;
>+
>+	/* check the bus ranges of all silbling bridges to prevent overlap */
>+	list_for_each(tmp, &bridge_to_fix->parent->children) {
>+		struct pci_bus * silbling = pci_bus_b(tmp);
>+		/*
>+		 * If the silbling has a higher secondary bus number
>+		 * and it's secondary is equal or smaller than our
>+		 * current upper limit, set the new upper limit to
>+		 * the bus number below the silbling's range:
>+		 */
>+		if (silbling->secondary > bridge_to_fix->subordinate
>+		    && silbling->secondary <= upper_limit)
>+			upper_limit = silbling->secondary - 1;
>+	}
>+
>+	/* Show that the wanted subordinate number is not possible: */
>+	if (cardbus_bridge->subordinate > upper_limit)
>+		printk(KERN_WARNING "Yenta: Upper limit for fixing this "
>+			"bridge's parent bridge: #%02x\n", upper_limit);
>+
>+	/* If we have room to increase the bridge's subordinate number, */
>+	if (bridge_to_fix->subordinate < upper_limit) {
>+
>+		/* use the highest number of the hidden bus, within limits */
>+		unsigned char subordinate_to_assign =
>+			min(cardbus_bridge->subordinate, upper_limit);
>+
>+		printk(KERN_INFO "Yenta: Raising subordinate bus# of parent "
>+			"bus (#%02x) from #%02x to #%02x\n",
>+			bridge_to_fix->number,
>+			bridge_to_fix->subordinate, subordinate_to_assign);
>+
>+		/* Save the new subordinate in the bus struct of the bridge */
>+		bridge_to_fix->subordinate = subordinate_to_assign;
>+
>+		/* and update the PCI config space with the new subordinate */
>+		pci_write_config_byte(bridge_to_fix->self,
>+			PCI_SUBORDINATE_BUS, bridge_to_fix->subordinate);
>+	}
>+}
>+
> /*
>  * Initialize a cardbus controller. Make sure we have a usable
>  * interrupt, and that we can map the cardbus area. Fill in the
>@@ -1113,6 +1184,8 @@
> 	yenta_get_socket_capabilities(socket, isa_interrupts);
> 	printk(KERN_INFO "Socket status: %08x\n", cb_readl(socket, CB_SOCKET_STATE));
>
>+	yenta_fixup_parent_bridge(dev->subordinate);
>+
> 	/* Register it with the pcmcia layer.. */
> 	ret = pcmcia_register_socket(&socket->socket);
> 	if (ret == 0) {

Created attachment 7850 [details]
fix the subordinate number of parent bridge in yenta_socket_probe within limits

Editing the attachment didn't work as well as I hoped, so I'm attaching the new
version as a separate attachment.

I changed only a few comments, no code.

OK, I've put it into git-pcmcia-2.6 now, it should show up in the next -mm
release. Let's see how it works out :)

Bug #5557 is also about the same problem some related info can be found there.

Looking thru the mail archives of February, March and April (until today) of
linux-pcmcia on http://lists.infradead.org/pipermail/linux-pcmcia/ , I have
found five additional laptops which should be fixed with this patch:

Alex Kavanagh
- HP DV1448:
Bus: primary=00, secondary=06, subordinate=06, sec-latency=216
Bus: primary=06, secondary=07, subordinate=0a, sec-latency=176
http://lists.infradead.org/pipermail/linux-pcmcia/2006-April/003492.html

Nicolas Bellido
- Toshiba Satellite Pro A60 with TI PCI1440 Cardbus controller:
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
http://lists.infradead.org/pipermail/linux-pcmcia/2006-March/003350.html

Chris Lu
- Unknown machine based on nVidia Corporation nForce3 Host Bridge (rev a4):
Bus: primary=00, secondary=02, subordinate=02, sec-latency=128
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
http://lists.infradead.org/pipermail/linux-pcmcia/2006-March/003356.html

Jeremy Johnson
- Kyocera KPC650:
Bus: primary=00, secondary=05, subordinate=05, sec-latency=64
Bus: primary=05, secondary=06, subordinate=09, sec-latency=176
http://lists.infradead.org/pipermail/linux-pcmcia/2006-April/003459.html

Diego Mart

Created attachment 8058 [details]
final patch, the functional equivalent of the last patch, with comment updates and a superflous early initialisation removed

This is the final patch which is (in the same functional form)
in the pcmcia-2.6 git tree of Dominik since soon (this version
has only cosmetical changes) since 4 weeks and since 3 weeks in
the -mm kernels

Since every tester reported success and there were no failure reports
so far, I'd regard it as stable and I think it should be merged to mainline
at the next opportunity.

Dominik, can you update the patch in your pcmcia git tree to this version
just to ensure that Linus does not grab the unpolished version from your tree?
(e.g. it names itself also pci_fixup_parent_subordinate() in the function
header, while it should read yenta_fixup_parent_subordinate(), just an example)

Thanks,
Bernhard

Reply-To: aaron@assonance.org

I have a laptop with:
02:00.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus
Controller (rev 02)

That also seems fixed by this patch (pci=assign-buses also worked
around the problem).

It's in a Clevo D900T laptop which is rebadged and sold all over the place.

Aaron Cohen

On 5/8/06, bugme-daemon@bugzilla.kernel.org
<bugme-daemon@bugzilla.kernel.org> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=2944
>
> bk@suse.de changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Attachment #7807 [details] is|0                           |1
>            obsolete|                            |
> Attachment #7850 [details] is|0                           |1
>            obsolete|                            |
>
>
>
> ------- Additional Comments From bk@suse.de  2006-05-08 09:49 -------
> Created an attachment (id=8058)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=8058&action=view)
> final patch, the functional equivalent of the last patch, with comment updates
> and a superflous early initialisation removed
>
> This is the final patch which is (in the same functional form)
> in the pcmcia-2.6 git tree of Dominik since soon (this version
> has only cosmetical changes) since 4 weeks and since 3 weeks in
> the -mm kernels
>
> Since every tester reported success and there were no failure reports
> so far, I'd regard it as stable and I think it should be merged to mainline
> at the next opportunity.
>
> Dominik, can you update the patch in your pcmcia git tree to this version
> just to ensure that Linus does not grab the unpolished version from your tree?
> (e.g. it names itself also pci_fixup_parent_subordinate() in the function
> header, while it should read yenta_fixup_parent_subordinate(), just an example)
>
> Thanks,
> Bernhard
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
> _______________________________________________
> Linux PCMCIA reimplementation list
> http://lists.infradead.org/mailman/listinfo/linux-pcmcia
>

Reply-To: aaron@assonance.org

Tried this on a Thinkpad G40 that I'd also had troubles getting
Cardbus cards to be recognized and it also fixed the problem there. 
It's the exact same TI chipset (PCI1410).

Thanks a ton for the patch!

Created attachment 8097 [details]
updated, more complete patch header

Thanks.

If anyone else used this patch to fix Cardbus card detection, please
reply to this mail, specifiying the notebook type.

Please remove all quoted mail text when replying to bugmail
because your reply is added as a comment to this bug entry
automatically and since we have full context in the bug entry,
quoting from this mail would insert redundant text in it.

Just for information, I got this:
-----------
I've just bought a HP Pavilion ze2000 series (the model name is ze2508au).
I confirm your patch available in bug #2944 fix the Cardbus card detection.

Great patch! This is the first time I've used a PCMCIA bus and I thought
I've did something wrong.
It took me awhile 'till I was confident it wasn't my fault.
-----------
Status: The patch is still waiting for hitting mainline (it's in the pcmcia git
tree, waiting to be forwarded/picked up with an upcoming merge of patches),
further confirmations should also help, so thanks for sending me reports (and
please continue to do so, it also increases our knowledge which models need this)!

I have a Compaq Presario R3455EA (athlon64, nforce3), and i'm trying to get the 
card reader work. any time I insert a sd/mmc in the slot (which is connected to 
the pci1620), i get errors on probing memory range 0xe0100000 - 0xe17fffff and 
the machine hangs.
i have a 2.6.17 kernel with gentoo patches. before applying the patch attached 
here, i got this lockups, that I solved with setpci. on inserting a card, the 
kernel said "inserted pcmcia card into slot 1". after applying the patch, lspci 
shows the correct "subordinate" entry, but every time i plug in a memory card, 
it hangs probing that range.

----lspci -v----
00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4)
        Flags: bus master, 66MHz, fast devsel, latency 0
        Memory at e8000000 (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 e0000000 (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 217
        Memory at e0001000 (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 e0004000 (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 e0002000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2

00:06.1 Modem: nVidia Corporation Unknown device 00d9 (rev a2) (prog-if 00 
[Generic])
        Subsystem: Hewlett-Packard Company Unknown device 006d
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
        I/O ports at 1800 [size=256]
        I/O ports at 1c80 [size=128]
        Memory at e0003000 (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=0a, sec-latency=128
        I/O behind bridge: 00003000-00007fff
        Memory behind bridge: e0100000-e17fffff
        Prefetchable memory behind bridge: 30000000-33ffffff

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: e2000000-e2ffffff
        Prefetchable memory behind bridge: f0000000-f80fffff

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 248, IRQ 225
        Memory at e2000000 (32-bit, non-prefetchable) [size=16M]
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at f8000000 (32-bit, prefetchable) [size=512K]
        [virtual] Expansion ROM at f8080000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [44] AGP version 2.0

02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 
Controller (PHY/Link) (prog-if 10 [OHCI])
        Subsystem: Hewlett-Packard Company Unknown device 006d
        Flags: bus master, medium devsel, latency 64, IRQ 177
        Memory at e0108000 (32-bit, non-prefetchable) [size=2K]
        Memory at e0100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [44] Power Management version 2

02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Flags: bus master, medium devsel, latency 64, IRQ 185
        I/O ports at 7000 [size=256]
        Memory at e0108800 (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 Presario R3000 802.11b/g
        Flags: bus master, fast devsel, latency 64, IRQ 193
        Memory at e0104000 (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 e0106000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
        Memory window 0: 30000000-31fff000 (prefetchable)
        Memory window 1: e0400000-e07ff000
        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 e0107000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
        Memory window 0: 32000000-33fff000 (prefetchable)
        Memory window 1: e0c00000-e0fff000
        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
--------------

---- cat /proc/iomem ----
00000000-0009f7ff : System RAM
  00000000-00000000 : Crash kernel
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cfbff : Video ROM
000d4000-000d4fff : Adapter ROM
000f0000-000fffff : System ROM
00100000-1ff6ffff : System RAM
  00200000-004dc7ed : Kernel code
  004dc7ee-006007a7 : Kernel data
1ff70000-1ff7efff : ACPI Tables
1ff7f000-1ff7ffff : ACPI Non-volatile Storage
1ff80000-1fffffff : reserved
30000000-33ffffff : PCI Bus #02
  30000000-31ffffff : PCI CardBus #03
  32000000-33ffffff : PCI CardBus #07
e0000000-e0000fff : 0000:00:02.0
  e0000000-e0000fff : ohci_hcd
e0001000-e0001fff : 0000:00:02.1
  e0001000-e0001fff : ohci_hcd
e0002000-e0002fff : 0000:00:06.0
  e0002000-e0002fff : NVidia nForce3
e0003000-e0003fff : 0000:00:06.1
e0004000-e00040ff : 0000:00:02.2
  e0004000-e00040ff : ehci_hcd
e0100000-e17fffff : PCI Bus #02
  e0100000-e0103fff : 0000:02:00.0
  e0104000-e0105fff : 0000:02:02.0
    e0104000-e0105fff : bcm43xx
  e0106000-e0106fff : 0000:02:04.0
    e0106000-e0106fff : yenta_socket
  e0107000-e0107fff : 0000:02:04.1
    e0107000-e0107fff : yenta_socket
  e0108000-e01087ff : 0000:02:00.0
    e0108000-e01087ff : ohci1394
  e0108800-e01088ff : 0000:02:01.0
    e0108800-e01088ff : 8139too
  e0400000-e07fffff : PCI CardBus #03
  e0c00000-e0ffffff : PCI CardBus #07
e2000000-e2ffffff : PCI Bus #01
  e2000000-e2ffffff : 0000:01:00.0
    e2000000-e2ffffff : nvidia
e8000000-efffffff : 0000:00:00.0
  e8000000-efffffff : aperture
f0000000-f80fffff : PCI Bus #01
  f0000000-f7ffffff : 0000:01:00.0
  f8000000-f807ffff : 0000:01:00.0
  f8080000-f809ffff : 0000:01:00.0
fff80000-ffffffff : reserved
------------

Sorry for the long post, but it seems that the bug is still here, even with 
that patch...

My patch was merged into mainline under the name "fix hidden PCI bus numbers"
with 2.6.18-rc1: http://lwn.net/Articles/190305/ and I verified it to work
there. Hence, I close this bug woth CODE_FIX.

To Guiseppe, who wrote the last comment:

The issue of hanging card reader drivers should not related to this bug, they
were at a pretty inferior state in 2.6.17.

Please retest the newer card reader drivers with 2.6.21 and report back.

General remarks:
* Hangs of drivers have never been the topic of this bug, you should have opened
a new one and added a note here.
* I do not understand how you fixed the hang with lspci, you didn'd describe
that, not even with a link. Please state exactly what you did when describing a
new issue (by opening a new bug!)
* Full output from lspci -vv is too long to be pasted into a comment and still
have the bug in readable form, please select "Create attachment" and attach to
the lspci file if want to attach long dumps of data.

Yes I known that bugzilla is not easy, and this one is poor in introducing new
reporters and commenting in how to contribute best.