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
On Fri, 2006-08-11 at 15:11 -0700, Dave Hansen wrote:
> 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
On Fri, 2006-08-11 at 17:27 -0500, James Bottomley wrote:
> On Fri, 2006-08-11 at 15:11 -0700, Dave Hansen wrote:
> > 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?
0000:02:01.0 0100: 9005:00cf (rev 01)
0000:02:01.1 0100: 9005:00cf (rev 01)
-- Dave
> 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
On Fri, 11 Aug 2006 17:50:53 CDT, James Bottomley wrote:
> > 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
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
On Fri, 2006-08-11 at 17:50 -0500, James Bottomley wrote:
> > 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
On Fri, 11 Aug 2006 16:06:43 -0700
Dave Hansen <[email protected]> wrote:
> On Fri, 2006-08-11 at 17:50 -0500, James Bottomley wrote:
> > > 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.
>
CONFIG_PCI_MULTITHREAD_PROBE might be implicated, if it's enabled.
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
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.
> 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
>
Cc: culprits ;)
On Fri, Aug 11, 2006 at 05:36:24PM -0700, Andrew Morton wrote:
> 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.
>
> > 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
On Saturday 12 August 2006 03.03, Greg KH wrote:
> On Fri, Aug 11, 2006 at 05:36:24PM -0700, Andrew Morton wrote:
> > 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.
> >
> > > 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...
>
> 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
On Saturday 12 August 2006 20.05, Daniel Ritz wrote:
> On Saturday 12 August 2006 03.03, Greg KH wrote:
> > On Fri, Aug 11, 2006 at 05:36:24PM -0700, Andrew Morton wrote:
> > > 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.
> > >
> > > > 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...
>
> >
> > 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?
>
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
diff --git a/arch/i386/pci/init.c b/arch/i386/pci/init.c
index c7650a7..51087a9 100644
--- a/arch/i386/pci/init.c
+++ b/arch/i386/pci/init.c
@@ -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
Daniel Ritz wrote:
> 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
On Sun, 2006-08-13 at 00:02 +0200, Daniel Ritz wrote:
> On Saturday 12 August 2006 20.05, Daniel Ritz wrote:
> > On Saturday 12 August 2006 03.03, Greg KH wrote:
> > > On Fri, Aug 11, 2006 at 05:36:24PM -0700, Andrew Morton wrote:
> > > > 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.
> > > >
> > > > > 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...
> >
> > >
> > > 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?
> >
> 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 :)
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
On Monday 14 August 2006 18.05, Dave Hansen wrote:
> On Sun, 2006-08-13 at 00:02 +0200, Daniel Ritz wrote:
> > On Saturday 12 August 2006 20.05, Daniel Ritz wrote:
> > > On Saturday 12 August 2006 03.03, Greg KH wrote:
> > > > On Fri, Aug 11, 2006 at 05:36:24PM -0700, Andrew Morton wrote:
> > > > > 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.
> > > > >
> > > > > > 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...
> > >
> > > >
> > > > 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?
> > >
> > 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 :)
>
> 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
> 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
On Mon, 2006-08-14 at 18:58 +0200, Daniel Ritz wrote:
> On Monday 14 August 2006 18.05, Dave Hansen wrote:
> > On Sun, 2006-08-13 at 00:02 +0200, Daniel Ritz wrote:
> > > 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.
> 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
On Mon, 2006-08-14 at 18:58 +0200, Daniel Ritz wrote:
> 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.
> 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
> 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
> 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
On Monday 14 August 2006 19.16, Dave Hansen wrote:
> On Mon, 2006-08-14 at 18:58 +0200, Daniel Ritz wrote:
> > 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.
>
> > 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
>
> > 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
>
> > 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
diff --git a/arch/i386/pci/init.c b/arch/i386/pci/init.c
index c7650a7..51087a9 100644
--- a/arch/i386/pci/init.c
+++ b/arch/i386/pci/init.c
@@ -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
On Mon, 2006-08-14 at 20:21 +0200, Daniel Ritz wrote:
> 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
>
> diff --git a/arch/i386/pci/init.c b/arch/i386/pci/init.c
> index c7650a7..51087a9 100644
> --- a/arch/i386/pci/init.c
> +++ b/arch/i386/pci/init.c
> @@ -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
That one works on my box without any issues. Thanks!
-- Dave
On Monday 14 August 2006 21.56, Dave Hansen wrote:
> On Mon, 2006-08-14 at 20:21 +0200, Daniel Ritz wrote:
> > 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
> >
> > diff --git a/arch/i386/pci/init.c b/arch/i386/pci/init.c
> > index c7650a7..51087a9 100644
> > --- a/arch/i386/pci/init.c
> > +++ b/arch/i386/pci/init.c
> > @@ -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
>
> 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]>
diff --git a/arch/i386/pci/init.c b/arch/i386/pci/init.c
index c7650a7..51087a9 100644
--- a/arch/i386/pci/init.c
+++ b/arch/i386/pci/init.c
@@ -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