aic7xxx broken in 2.6.18-rc3-mm2

DISCUSSION Dave Hansen 7 participants 20 messages Aug 11, 2006 – Aug 14, 2006 SCSI

Share & tools

Dave Hansen

author

2006-08-11 22:12 UTC #0 lore raw

My scsi card stopped being detected in 2.6.18-rc3-mm2, but works in plain 2.6.18-rc3. I bisected all the way down to the git-sas.patch. I then noticed that if I enable the AIC94XX driver, my card works again.

I'm digging through it right now, but I figured I'd post in case anyone else had seen this. This error mode seems vaguely familiar as well. Any ideas?

-- Dave

James Bottomley

2006-08-11 22:27 UTC #1 lore raw

Quoted 9 lines · Dave Hansen

My scsi card stopped being detected in 2.6.18-rc3-mm2, but works in plain 2.6.18-rc3. I bisected all the way down to the git-sas.patch. I
then noticed that if I enable the AIC94XX driver, my card works again.
I'm digging through it right now, but I figured I'd post in case anyone
else had seen this. This error mode seems vaguely familiar as well. Any ideas?

There's nothing in the driver diff that interferes with the aic7xxx ... my best guess would be some cockup over duplicate pci id claims ... what's the lspci -n output for the card?

James

Dave Hansen

author

2006-08-11 22:32 UTC #2 lore raw

Quoted 6 lines · James Bottomley

Quoted 5 lines · Dave Hansen
My scsi card stopped being detected in 2.6.18-rc3-mm2, but works in plain 2.6.18-rc3. I bisected all the way down to the git-sas.patch. I
then noticed that if I enable the AIC94XX driver, my card works again.

Quoted 8 lines

Quoted 4 lines
I'm digging through it right now, but I figured I'd post in case anyone
else had seen this. This error mode seems vaguely familiar as well. Any ideas?
There's nothing in the driver diff that interferes with the aic7xxx ... my best guess would be some cockup over duplicate pci id claims ... what's the lspci -n output for the card?

0000:02:01.0 0100: 9005:00cf (rev 01)
0000:02:01.1 0100: 9005:00cf (rev 01)

-- Dave

James Bottomley

2006-08-11 22:50 UTC #3 lore raw

Quoted 2 lines

0000:02:01.0 0100: 9005:00cf (rev 01)
0000:02:01.1 0100: 9005:00cf (rev 01)

OK strike that. The aic94xx cards all have IDs like 9005:04XX

There does seem to be a cockup in the initialisation tables, but I can't see how it could affect what you're seeing. (PCI_DEVICE() uses the .name = value initialisation method and the fields following are unnamed). Do you build both of these into the kernel, and if so does it work when they're both modular?

James

Doug Maxey

2006-08-11 23:05 UTC #4 lore raw

Quoted 5 lines · James Bottomley

Quoted 2 lines
0000:02:01.0 0100: 9005:00cf (rev 01)
0000:02:01.1 0100: 9005:00cf (rev 01)
OK strike that. The aic94xx cards all have IDs like 9005:04XX

Quoted 7 lines

There does seem to be a cockup in the initialisation tables, but I can't see how it could affect what you're seeing. (PCI_DEVICE() uses the .name = value initialisation method and the fields following are unnamed). Do you build both of these into the kernel, and if so does it work when they're both modular?
James

Brian King had a similar issue come up between the ipr card and the DAC960. In that case, the subsys id's were wild carded, which prevented the correct driver being loaded for ipr.

++doug

Dave Hansen

author

2006-08-11 23:06 UTC #5 lore raw

In reply to James Bottomley

Quoted 10 lines · James Bottomley

Quoted 2 lines
0000:02:01.0 0100: 9005:00cf (rev 01)
0000:02:01.1 0100: 9005:00cf (rev 01)
OK strike that. The aic94xx cards all have IDs like 9005:04XX
There does seem to be a cockup in the initialisation tables, but I can't see how it could affect what you're seeing. (PCI_DEVICE() uses the .name = value initialisation method and the fields following are unnamed). Do you build both of these into the kernel, and if so does it work when they're both modular?

Yep, I build both of them in. Making them both modular will require a wee bit more time, as the aic7xxx has my root disk on it, and I don't have any initrds.

In any case, I'm starting to get some funky results. I can't get the problem to reappear in the tree where I was doing the bisect, but my development tree where I first saw it is still broken.

I'll do some more digging and get out a more reliable bug report.

-- Dave

Andrew Morton

2006-08-11 23:21 UTC #6 lore raw

Quoted 16 lines · On Fri, 11 Aug 2006 16:06:43 -0700 Dave Hansen <[email protected]> wrote:

Quoted 10 lines · James Bottomley
Quoted 2 lines
0000:02:01.0 0100: 9005:00cf (rev 01)
0000:02:01.1 0100: 9005:00cf (rev 01)
OK strike that. The aic94xx cards all have IDs like 9005:04XX
There does seem to be a cockup in the initialisation tables, but I can't see how it could affect what you're seeing. (PCI_DEVICE() uses the .name = value initialisation method and the fields following are unnamed). Do you build both of these into the kernel, and if so does it work when they're both modular?
Yep, I build both of them in. Making them both modular will require a wee bit more time, as the aic7xxx has my root disk on it, and I don't have any initrds.

Quoted 6 lines

In any case, I'm starting to get some funky results. I can't get the problem to reappear in the tree where I was doing the bisect, but my development tree where I first saw it is still broken.
I'll do some more digging and get out a more reliable bug report.

CONFIG_PCI_MULTITHREAD_PROBE might be implicated, if it's enabled.

Dave Hansen

author

2006-08-12 00:17 UTC #7 lore raw

Well, I have a new culprit of the hour:

gregkh-pci-pci-use-pci_bios-as-last-fallback

There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch

There was an off-list thread called

	"PCI device issue in 2.6.16-rc3-mm1 through 2.6.16-rc6-mm1"

Anyway, here's the information from the syslog at boot in a working system (without the patch applied):

PCI: PCI BIOS revision 2.10 entry at 0xfd32c, last bus=8 Setting up standard PCI resources
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Discovered peer bus 02
PCI: Firmware left 0000:02:05.0 e100 interrupts enabled, disabling
PCI: Discovered peer bus 05
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 16 PCI->APIC IRQ transform: 0000:00:0f.2[A] -> IRQ 19 PCI->APIC IRQ transform: 0000:02:01.0[A] -> IRQ 17 PCI->APIC IRQ transform: 0000:02:01.1[B] -> IRQ 18 PCI->APIC IRQ transform: 0000:02:05.0[A] -> IRQ 24 PCI->APIC IRQ transform: 0000:05:02.0[A] -> IRQ 21 PCI->APIC IRQ transform: 0000:05:02.1[B] -> IRQ 26 PCI->APIC IRQ transform: 0000:06:04.0[A] -> IRQ 22 PCI->APIC IRQ transform: 0000:06:05.0[A] -> IRQ 27 PCI->APIC IRQ transform: 0000:06:06.0[A] -> IRQ 28 PCI->APIC IRQ transform: 0000:06:07.0[A] -> IRQ 29
PCI: Bridge: 0000:05:03.0
IO window: 7000-7fff
MEM window: eb000000-ec1fffff
PREFETCH window: ea300000-ea3fffff

And the same thing in a system where it can't find my SCSI card (with the patch applied):

PCI: Using configuration type 1
Setting up standard PCI resources
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 16 PCI->APIC IRQ transform: 0000:00:0f.2[A] -> IRQ 19

-- Dave

Andrew Morton

2006-08-12 00:36 UTC #8 lore raw

Quoted 3 lines · On Fri, 11 Aug 2006 17:17:15 -0700 Dave Hansen <[email protected]> wrote:

Well, I have a new culprit of the hour:
gregkh-pci-pci-use-pci_bios-as-last-fallback

Thanks, I'll drop it.

Quoted 38 lines

There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch
There was an off-list thread called
	"PCI device issue in 2.6.16-rc3-mm1 through 2.6.16-rc6-mm1"
Anyway, here's the information from the syslog at boot in a working system (without the patch applied):
PCI: PCI BIOS revision 2.10 entry at 0xfd32c, last bus=8 Setting up standard PCI resources
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Discovered peer bus 02
PCI: Firmware left 0000:02:05.0 e100 interrupts enabled, disabling
PCI: Discovered peer bus 05
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 16 PCI->APIC IRQ transform: 0000:00:0f.2[A] -> IRQ 19 PCI->APIC IRQ transform: 0000:02:01.0[A] -> IRQ 17 PCI->APIC IRQ transform: 0000:02:01.1[B] -> IRQ 18 PCI->APIC IRQ transform: 0000:02:05.0[A] -> IRQ 24 PCI->APIC IRQ transform: 0000:05:02.0[A] -> IRQ 21 PCI->APIC IRQ transform: 0000:05:02.1[B] -> IRQ 26 PCI->APIC IRQ transform: 0000:06:04.0[A] -> IRQ 22 PCI->APIC IRQ transform: 0000:06:05.0[A] -> IRQ 27 PCI->APIC IRQ transform: 0000:06:06.0[A] -> IRQ 28 PCI->APIC IRQ transform: 0000:06:07.0[A] -> IRQ 29
PCI: Bridge: 0000:05:03.0
IO window: 7000-7fff
MEM window: eb000000-ec1fffff
PREFETCH window: ea300000-ea3fffff
And the same thing in a system where it can't find my SCSI card (with the patch applied):

Quoted 7 lines

PCI: Using configuration type 1
Setting up standard PCI resources
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 16 PCI->APIC IRQ transform: 0000:00:0f.2[A] -> IRQ 19

Cc culprits ;)

Greg KH

2006-08-12 01:03 UTC #9 lore raw

Quoted 13 lines · Andrew Morton

Quoted 3 lines · On Fri, 11 Aug 2006 17:17:15 -0700 Dave Hansen <[email protected]> wrote:
Well, I have a new culprit of the hour:
gregkh-pci-pci-use-pci_bios-as-last-fallback
Thanks, I'll drop it.
Quoted 4 lines
There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch

Ugh, this is a mess. Daniel, why does your machine need this patch, yet as per Dave's comments, it's wrong?

I think it might come down to the fact that the ordering before used to not always happen in the same order (it depended on config options and linker luck.) Now it's "fixed" to be the same way all the time. Daniel, can't you solve this with the proper pci boot option?

thanks,

greg k-h

Daniel Ritz

2006-08-12 18:05 UTC #10 lore raw

Quoted 10 lines · Greg KH

Quoted 9 lines · Andrew Morton
Quoted 3 lines · On Fri, 11 Aug 2006 17:17:15 -0700 Dave Hansen <[email protected]> wrote:
Well, I have a new culprit of the hour:
gregkh-pci-pci-use-pci_bios-as-last-fallback
Thanks, I'll drop it.

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch
Ugh, this is a mess. Daniel, why does your machine need this patch, yet as per Dave's comments, it's wrong?

it's not my machines. they work fine :) but there where bug reports on linux-pcmcia for this problem...only shows up with kernel >= 2.6.17. see also bug 6801.

2.6.16 shows this:

	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
	  PCI: Using configuration type 1
while 2.6.17+ shows only
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0

so accessing the cardbus cards is not possible with PCI BIOS but works just fine with direct access...

Quoted 5 lines

I think it might come down to the fact that the ordering before used to not always happen in the same order (it depended on config options and linker luck.) Now it's "fixed" to be the same way all the time. Daniel, can't you solve this with the proper pci boot option?

sure, but the point is: it used to work on those boxes, but broke with 2.6.17

ok, i had a look. the problem is not the patch itself. look at arch/i386/pci/legacy.c it's where those messages come from:
PCI: Probing PCI hardware
PCI: Discovered peer bus 02
PCI: Discovered peer bus 05

now if pcibios probing never runs pcibios_last_bus is -1 and pcibios_fixup_peer_bridges() exits immediatley, the other busses are never found...but why legacy probing anyway?

rgds
-daniel

Daniel Ritz

2006-08-12 22:04 UTC #11 lore raw

Quoted 39 lines · Daniel Ritz

Quoted 10 lines · Greg KH
Quoted 9 lines · Andrew Morton
Quoted 3 lines · On Fri, 11 Aug 2006 17:17:15 -0700 Dave Hansen <[email protected]> wrote:
Well, I have a new culprit of the hour:
gregkh-pci-pci-use-pci_bios-as-last-fallback
Thanks, I'll drop it.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch
Ugh, this is a mess. Daniel, why does your machine need this patch, yet as per Dave's comments, it's wrong?
it's not my machines. they work fine :) but there where bug reports on linux-pcmcia for this problem...only shows up with kernel >= 2.6.17. see also bug 6801.
2.6.16 shows this:
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
	  PCI: Using configuration type 1
while 2.6.17+ shows only
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
so accessing the cardbus cards is not possible with PCI BIOS but works just fine with direct access...
Quoted 5 lines
I think it might come down to the fact that the ordering before used to not always happen in the same order (it depended on config options and linker luck.) Now it's "fixed" to be the same way all the time. Daniel, can't you solve this with the proper pci boot option?
sure, but the point is: it used to work on those boxes, but broke with 2.6.17

Quoted 9 lines

ok, i had a look. the problem is not the patch itself. look at arch/i386/pci/legacy.c it's where those messages come from:
PCI: Probing PCI hardware
PCI: Discovered peer bus 02
PCI: Discovered peer bus 05
now if pcibios probing never runs pcibios_last_bus is -1 and pcibios_fixup_peer_bridges() exits immediatley, the other busses are never found...but why legacy probing anyway?

anyway, this alternative patch should help. it should be more like the <= 2.6.16 behavior.

[ CC'ing Marcus Better as the tester of the original patch. ]

Marcus, could you test this patch instead of the original one and see how your cardbus cards behave?

Dave, your SCSI card should work with this as well :)

with this patch my old toshiba laptop shows this in dmesg:

	PCI: PCI BIOS revision 2.10 entry at 0xf1987, last bus=21
	PCI: Using configuration type 1

ie. like kernel 2.6.16 and earlier...2.6.17+ would only show the pci bios line, while with the earlier patch it only shows the type 1 line

rgds
-daniel

arch/i386/pci/init.c +6 -2

index c7650a7..51087a9 100644
@@ -14,8 +14,12 @@ #endif
 #ifdef CONFIG_PCI_BIOS
 	pci_pcbios_init();
 #endif
-	if (raw_pci_ops)
-		return 0;
+	/*
+	 * don't check for raw_pci_ops here because we want pcbios as last
+	 * fallback, yet it's needed to run first to set pcibios_last_bus
+	 * in case legacy PCI probing is used. otherwise detecting peer busses
+	 * fails.
+	 */
 #ifdef CONFIG_PCI_DIRECT
 	pci_direct_init();
 #endif

Marcus Better

2006-08-14 12:17 UTC #12 lore raw

Quoted 2 lines · Daniel Ritz

Marcus, could you test this patch instead of the original one and see how your cardbus cards behave?

It seems to work, from a cursory check.

Marcus

Dave Hansen

author

2006-08-14 16:06 UTC #13 lore raw

In reply to Daniel Ritz

Quoted 52 lines · Daniel Ritz

Quoted 39 lines · Daniel Ritz
Quoted 10 lines · Greg KH
Quoted 9 lines · Andrew Morton
Quoted 3 lines · On Fri, 11 Aug 2006 17:17:15 -0700 Dave Hansen <[email protected]> wrote:
Well, I have a new culprit of the hour:
gregkh-pci-pci-use-pci_bios-as-last-fallback
Thanks, I'll drop it.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch
Ugh, this is a mess. Daniel, why does your machine need this patch, yet as per Dave's comments, it's wrong?
it's not my machines. they work fine :) but there where bug reports on linux-pcmcia for this problem...only shows up with kernel >= 2.6.17. see also bug 6801.
2.6.16 shows this:
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
	  PCI: Using configuration type 1
while 2.6.17+ shows only
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
so accessing the cardbus cards is not possible with PCI BIOS but works just fine with direct access...
Quoted 5 lines
I think it might come down to the fact that the ordering before used to not always happen in the same order (it depended on config options and linker luck.) Now it's "fixed" to be the same way all the time. Daniel, can't you solve this with the proper pci boot option?
sure, but the point is: it used to work on those boxes, but broke with 2.6.17
Quoted 9 lines
ok, i had a look. the problem is not the patch itself. look at arch/i386/pci/legacy.c it's where those messages come from:
PCI: Probing PCI hardware
PCI: Discovered peer bus 02
PCI: Discovered peer bus 05
now if pcibios probing never runs pcibios_last_bus is -1 and pcibios_fixup_peer_bridges() exits immediatley, the other busses are never found...but why legacy probing anyway?
anyway, this alternative patch should help. it should be more like the <= 2.6.16 behavior.

Quoted 6 lines

[ CC'ing Marcus Better as the tester of the original patch. ]
Marcus, could you test this patch instead of the original one and see how your cardbus cards behave?
Dave, your SCSI card should work with this as well :)

Sorry, it has the same behavior as without the patch. If it matters, here is the relevant portion of my .config:

CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set

-- Dave

Daniel Ritz

2006-08-14 16:59 UTC #14 lore raw

Quoted 55 lines · Dave Hansen

Quoted 54 lines · Daniel Ritz
Quoted 39 lines · Daniel Ritz
Quoted 10 lines · Greg KH
Quoted 9 lines · Andrew Morton
Quoted 3 lines · On Fri, 11 Aug 2006 17:17:15 -0700 Dave Hansen <[email protected]> wrote:
Well, I have a new culprit of the hour:
gregkh-pci-pci-use-pci_bios-as-last-fallback
Thanks, I'll drop it.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
There was a previous patch that messed up a few of my machines and this same driver a few months ago, which accounts for my sense of deja vu:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm1/broken-out/gregkh-pci-pci-give-pci-config-access-initialization-a-defined-ordering.patch
Ugh, this is a mess. Daniel, why does your machine need this patch, yet as per Dave's comments, it's wrong?
it's not my machines. they work fine :) but there where bug reports on linux-pcmcia for this problem...only shows up with kernel >= 2.6.17. see also bug 6801.
2.6.16 shows this:
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
	  PCI: Using configuration type 1
while 2.6.17+ shows only
	  PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
so accessing the cardbus cards is not possible with PCI BIOS but works just fine with direct access...
Quoted 5 lines
I think it might come down to the fact that the ordering before used to not always happen in the same order (it depended on config options and linker luck.) Now it's "fixed" to be the same way all the time. Daniel, can't you solve this with the proper pci boot option?
sure, but the point is: it used to work on those boxes, but broke with 2.6.17
Quoted 9 lines
ok, i had a look. the problem is not the patch itself. look at arch/i386/pci/legacy.c it's where those messages come from:
PCI: Probing PCI hardware
PCI: Discovered peer bus 02
PCI: Discovered peer bus 05
now if pcibios probing never runs pcibios_last_bus is -1 and pcibios_fixup_peer_bridges() exits immediatley, the other busses are never found...but why legacy probing anyway?
anyway, this alternative patch should help. it should be more like the <= 2.6.16 behavior.
[ CC'ing Marcus Better as the tester of the original patch. ]

Quoted 7 lines

Quoted 4 lines
Marcus, could you test this patch instead of the original one and see how your cardbus cards behave?
Dave, your SCSI card should work with this as well :)
Sorry, it has the same behavior as without the patch. If it matters, here is the relevant portion of my .config:

hmm..should be 2.6.16 behavior with this...
what kind of box is this? could you give me dmesg output of plain 2.6.18-rc4 and a 2.6.18-rc4 with the patch (not -mm if possible)?
oh...and a lspci -vvv please

Quoted 9 lines

CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set

thanks,
-daniel

Dave Hansen

author

2006-08-14 17:04 UTC #15 lore raw

Quoted 9 lines · Daniel Ritz

Quoted 5 lines · Dave Hansen
Quoted 1 line · Daniel Ritz
Dave, your SCSI card should work with this as well :)
Sorry, it has the same behavior as without the patch. If it matters, here is the relevant portion of my .config:
hmm..should be 2.6.16 behavior with this...
what kind of box is this?

IBM 4-way PIII Xeon. 5 years old or so.

Quoted 2 lines

could you give me dmesg output of plain 2.6.18-rc4 and a 2.6.18-rc4 with the patch (not -mm if possible)?

The patch you just sent, or the original one that went into -mm? (You could just attach whatever you want me to test to your reply, and that way I _can't_ screw it up ;)

-- Dave

Dave Hansen

author

2006-08-14 17:17 UTC #16 lore raw

In reply to Daniel Ritz

Quoted 2 lines · Daniel Ritz

hmm..should be 2.6.16 behavior with this...
what kind of box is this?

I know my earlier description was vague. Please let me know if there are any specifics you need.

Quoted 1 line

could you give me dmesg output of plain 2.6.18-rc4

http://sr71.net/~dave/linux/daniel.ritz/dmesg-elm3b82-2.6.18-rc4.txt

Quoted 1 line

and a 2.6.18-rc4 with the patch (not -mm if possible)?

http://sr71.net/~dave/linux/daniel.ritz/dmesg-elm3b82-2.6.18-rc4-with-gregkh-pci-pci-use-pci_bios-as-last-fallback.txt

Quoted 1 line

oh...and a lspci -vvv please

http://sr71.net/~dave/linux/daniel.ritz/lspci-vvv-elm3b82.txt

(A reversed copy of) the patch I applied to 2.6.18-rc4 is in that directory, too:

http://sr71.net/~dave/linux/daniel.ritz/gregkh-pci-pci-use-pci_bios-as-last-fallback.patch

-- Dave

Daniel Ritz

2006-08-14 18:21 UTC #17 lore raw

Quoted 6 lines · Dave Hansen

Quoted 2 lines · Daniel Ritz
hmm..should be 2.6.16 behavior with this...
what kind of box is this?
I know my earlier description was vague. Please let me know if there are any specifics you need.

thanks, for the info.

Quoted 9 lines

Quoted 2 lines
could you give me dmesg output of plain 2.6.18-rc4
http://sr71.net/~dave/linux/daniel.ritz/dmesg-elm3b82-2.6.18-rc4.txt
Quoted 1 line
and a 2.6.18-rc4 with the patch (not -mm if possible)?
http://sr71.net/~dave/linux/daniel.ritz/dmesg-elm3b82-2.6.18-rc4-with-gregkh-pci-pci-use-pci_bios-as-last-fallback.txt

Quoted 8 lines

Quoted 1 line
oh...and a lspci -vvv please
http://sr71.net/~dave/linux/daniel.ritz/lspci-vvv-elm3b82.txt
(A reversed copy of) the patch I applied to 2.6.18-rc4 is in that directory, too:
http://sr71.net/~dave/linux/daniel.ritz/gregkh-pci-pci-use-pci_bios-as-last-fallback.patch

errm...sorry, i didn't mean that patch but the alternative i sent later. attached. it should use direct access while not breaking legacy PCI probing. in theory..

thanks,
-daniel

arch/i386/pci/init.c +6 -2

index c7650a7..51087a9 100644
@@ -14,8 +14,12 @@ #endif
 #ifdef CONFIG_PCI_BIOS
 	pci_pcbios_init();
 #endif
-	if (raw_pci_ops)
-		return 0;
+	/*
+	 * don't check for raw_pci_ops here because we want pcbios as last
+	 * fallback, yet it's needed to run first to set pcibios_last_bus
+	 * in case legacy PCI probing is used. otherwise detecting peer busses
+	 * fails.
+	 */
 #ifdef CONFIG_PCI_DIRECT
 	pci_direct_init();
 #endif

Dave Hansen

author

2006-08-14 19:57 UTC #18 lore raw

Quoted 15 lines · Daniel Ritz

errm...sorry, i didn't mean that patch but the alternative i sent later. attached. it should use direct access while not breaking legacy PCI probing. in theory..
thanks,
(quoted diff) +0 -1
-daniel
arch/i386/pci/init.c +0 -1
index c7650a7..51087a9 100644
@@ -14,8 +14,12 @@ #endif
 #ifdef CONFIG_PCI_BIOS
 	pci_pcbios_init();
 #endif
-	if (raw_pci_ops)

arch/i386/pci/init.c #endif · line 25

Quoted 10 lines

arch/i386/pci/init.c +6 -1

-		return 0;
+	/*
+	 * don't check for raw_pci_ops here because we want pcbios as last
+	 * fallback, yet it's needed to run first to set pcibios_last_bus
+	 * in case legacy PCI probing is used. otherwise detecting peer busses
+	 * fails.
+	 */
 #ifdef CONFIG_PCI_DIRECT
 	pci_direct_init();
 #endif

That one works on my box without any issues. Thanks!

-- Dave

Daniel Ritz

2006-08-14 20:19 UTC #19 lore raw

Quoted 20 lines · Dave Hansen

Quoted 19 lines · Daniel Ritz
errm...sorry, i didn't mean that patch but the alternative i sent later. attached. it should use direct access while not breaking legacy PCI probing. in theory..
thanks,
(quoted diff) +0 -1
-daniel
arch/i386/pci/init.c +3 -2
index c7650a7..51087a9 100644
@@ -14,8 +14,12 @@ #endif
 #ifdef CONFIG_PCI_BIOS
 	pci_pcbios_init();
 #endif
-	if (raw_pci_ops)
-		return 0;
+	/*
+	 * don't check for raw_pci_ops here because we want pcbios as last
+	 * fallback, yet it's needed to run first to set pcibios_last_bus

Quoted 8 lines

arch/i386/pci/init.c #endif · line 25
Quoted 6 lines
arch/i386/pci/init.c +3 -0
+	 * in case legacy PCI probing is used. otherwise detecting peer busses
+	 * fails.
+	 */
 #ifdef CONFIG_PCI_DIRECT
 	pci_direct_init();
 #endif
That one works on my box without any issues. Thanks!

nice! thanks for testing.

Andrew/Greg could you add the patch to your trees? attached again with a better description.

rgds
-daniel

-----

[PATCH] PCI: use PCBIOS as last fallback

there was a change in 2.6.17 which affected the order in which the PCI access methods are probed. this gives regressions on some machines with broken BIOS. the problem is that PCBIOS sometimes reports last bus wrong, leaving cardbus non-funcational. previously those system worked fine with direct access.

the patch changes the PCI init code to have PCBIOS as last fallback, yet the PCBIOS code still has to run first to set pcibios_last_bus to the value reported by the BIOS. this is needed in case legacy PCI probing (arch/i386/pci/legacy.c) is used to detect peer busses. using direct access if available fixes the cardbus problems.

Signed-off-by Daniel Ritz <[email protected]>

arch/i386/pci/init.c +6 -2

index c7650a7..51087a9 100644
@@ -14,8 +14,12 @@ #endif
 #ifdef CONFIG_PCI_BIOS
 	pci_pcbios_init();
 #endif
-	if (raw_pci_ops)
-		return 0;
+	/*
+	 * don't check for raw_pci_ops here because we want pcbios as last
+	 * fallback, yet it's needed to run first to set pcibios_last_bus
+	 * in case legacy PCI probing is used. otherwise detecting peer busses
+	 * fails.
+	 */
 #ifdef CONFIG_PCI_DIRECT
 	pci_direct_init();
 #endif