* Problems with 2.6.15-mm1 and mm2.
@ 2006-01-09 17:59 Martin Bligh
2006-01-09 23:41 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Martin Bligh @ 2006-01-09 17:59 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, Andy Whitcroft
OK, so on -mm1 we get:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c01fccd2
*pde = 0042d001
*pte = 00000000
Oops: 0000 [#1]
SMP
last sysfs file:
Modules linked in:
CPU: 0
EIP: 0060:[<c01fccd2>] Not tainted VLI
EFLAGS: 00010286 (2.6.15-mm1-autokern1)
EIP is at pci_call_probe+0x1a/0xa1
eax: 00000000 ebx: ffffffed ecx: e748a030 edx: c03a4680
esi: e7767800 edi: c03a4680 ebp: ffffffff esp: e749fef0
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=e749e000 task=e748a030)
Stack: <0>ffffffed e7767800 c03a4680 c03a46ac c01fcd8c c03a4680 e7767800
c03a441c
<0>c03a4680 e7767800 c03a46ac c01fcdbf c03a4680 e7767800
e7767800 00000000
<0>e7767848 c021c265 e7767848 e7767848 00000000 c021c311
c021c34a c03a46ac
Call Trace:
[<c01fcd8c>] __pci_device_probe+0x33/0x47
[<c01fcdbf>] pci_device_probe+0x1f/0x34
[<c021c265>] driver_probe_device+0x3a/0x84
[<c021c311>] __driver_attach+0x0/0x60
[<c021c34a>] __driver_attach+0x39/0x60
[<c021ba18>] bus_for_each_dev+0x47/0x6d
[<c01f4d5a>] kobject_add+0x76/0x95
[<c021c385>] driver_attach+0x14/0x18
[<c021c311>] __driver_attach+0x0/0x60
[<c021be30>] bus_add_driver+0x54/0x87
[<c021c72c>] driver_register+0x3b/0x3e
[<c01fcfa6>] __pci_register_driver+0x7e/0x8c
[<c03f646d>] qla1280_init+0xc/0xf
[<c03e4789>] do_initcalls+0x4b/0x99
[<c0100393>] init+0x98/0x195
[<c01002fb>] init+0x0/0x195
[<c0100ea9>] kernel_thread_helper+0x5/0xb
from the NUMA-Q. http://test.kernel.org/19793/debug/console.log
------------------------------------------------------------------
on -mm2 I get the x86_64 seems to lock up (NFI why ... looking at it),
the NUMA-Q and x440 panic (very similar to the above).
I think Andy figured out what was causing those panics. Can we drop
those patches until they're fixed?
Thanks,
M.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with 2.6.15-mm1 and mm2.
2006-01-09 17:59 Problems with 2.6.15-mm1 and mm2 Martin Bligh
@ 2006-01-09 23:41 ` Andrew Morton
2006-01-10 0:05 ` Martin Bligh
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2006-01-09 23:41 UTC (permalink / raw)
To: Martin Bligh; +Cc: linux-kernel, apw, Greg KH
Martin Bligh <mbligh@google.com> wrote:
>
> OK, so on -mm1 we get:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> printing eip:
> c01fccd2
> *pde = 0042d001
> *pte = 00000000
> Oops: 0000 [#1]
> SMP
> last sysfs file:
> Modules linked in:
> CPU: 0
> EIP: 0060:[<c01fccd2>] Not tainted VLI
> EFLAGS: 00010286 (2.6.15-mm1-autokern1)
> EIP is at pci_call_probe+0x1a/0xa1
> eax: 00000000 ebx: ffffffed ecx: e748a030 edx: c03a4680
> esi: e7767800 edi: c03a4680 ebp: ffffffff esp: e749fef0
> ds: 007b es: 007b ss: 0068
> Process swapper (pid: 1, threadinfo=e749e000 task=e748a030)
> Stack: <0>ffffffed e7767800 c03a4680 c03a46ac c01fcd8c c03a4680 e7767800
> c03a441c
> <0>c03a4680 e7767800 c03a46ac c01fcdbf c03a4680 e7767800
> e7767800 00000000
> <0>e7767848 c021c265 e7767848 e7767848 00000000 c021c311
> c021c34a c03a46ac
> Call Trace:
> [<c01fcd8c>] __pci_device_probe+0x33/0x47
> [<c01fcdbf>] pci_device_probe+0x1f/0x34
> [<c021c265>] driver_probe_device+0x3a/0x84
> [<c021c311>] __driver_attach+0x0/0x60
> [<c021c34a>] __driver_attach+0x39/0x60
> [<c021ba18>] bus_for_each_dev+0x47/0x6d
> [<c01f4d5a>] kobject_add+0x76/0x95
> [<c021c385>] driver_attach+0x14/0x18
> [<c021c311>] __driver_attach+0x0/0x60
> [<c021be30>] bus_add_driver+0x54/0x87
> [<c021c72c>] driver_register+0x3b/0x3e
> [<c01fcfa6>] __pci_register_driver+0x7e/0x8c
> [<c03f646d>] qla1280_init+0xc/0xf
> [<c03e4789>] do_initcalls+0x4b/0x99
> [<c0100393>] init+0x98/0x195
> [<c01002fb>] init+0x0/0x195
> [<c0100ea9>] kernel_thread_helper+0x5/0xb
>
> from the NUMA-Q. http://test.kernel.org/19793/debug/console.log
>
Yes, I asked Greg about that - we don't know what's causing it yet. I have
a bad feeling that this bug will go into Linus's tree if we don't fix it
quick.
I had problems with gregkh-pci-x86-pci-domain-support-the-meat.patch. It
might be worth reverting that.
>
> on -mm2 I get the x86_64 seems to lock up (NFI why ... looking at it),
> the NUMA-Q and x440 panic (very similar to the above).
>
> I think Andy figured out what was causing those panics. Can we drop
> those patches until they're fixed?
>
I'm not aware of any buggy x86_64 patches in -mm2 :(
I guess you don't have the time to sit down and do a bisection search.
It'd take a solid few hours...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with 2.6.15-mm1 and mm2.
2006-01-09 23:41 ` Andrew Morton
@ 2006-01-10 0:05 ` Martin Bligh
2006-01-10 0:46 ` Andrew Morton
0 siblings, 1 reply; 6+ messages in thread
From: Martin Bligh @ 2006-01-10 0:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, apw, Greg KH
>>from the NUMA-Q. http://test.kernel.org/19793/debug/console.log
>>
>
>
> Yes, I asked Greg about that - we don't know what's causing it yet. I have
> a bad feeling that this bug will go into Linus's tree if we don't fix it
> quick.
>
> I had problems with gregkh-pci-x86-pci-domain-support-the-meat.patch. It
> might be worth reverting that.
Andy figured out what caused it.
>>on -mm2 I get the x86_64 seems to lock up (NFI why ... looking at it),
>>the NUMA-Q and x440 panic (very similar to the above).
>>
>>I think Andy figured out what was causing those panics. Can we drop
>>those patches until they're fixed?
>>
>
>
> I'm not aware of any buggy x86_64 patches in -mm2 :(
>
> I guess you don't have the time to sit down and do a bisection search.
> It'd take a solid few hours...
It's more that I don't have direct access to the machines in question
any more. The x86_64 one might just be a machine issue ... trying to
confirm that still ... but the PCI one was real.
M.
Below is cut & pasted, so not applyable, and maybe it shouldn't be
applied. But ... it worked before whatever is in -mm ... so my personal
feeling is that if we don't have a fix for whatever is currently in -mm,
it should get dropped until we do ? Going backwards = bad.
Perhaps I'm in a time loop, and just confused. but I don't think so ?
----------------------------------------------
From apw:
pci device ensure sysdata initialised
[Ok, here is a patch to ensure sysdata is valid for all busses.]
We have been seeing panic's on NUMA systems in pci_call_probe() in
2.6.15-rc5-mm2 and -mm3. It seems that some changes have occured
to the meaning of the 'sysdata' for a device such that it is no
longer just an integer containing the node, it is now a structure
containing the node and other data. However, it seems that we do not
always initialise this sysdata before we probe the device.
Below are three examples from a boot with this checked for.
The attached patch ensures that we supply a valid sysdata for system
busses. Currently we take no account of the node for this bus for
no ACPI configured systems. This is unchanged from the -mm1 code.
Intel(R) PRO/1000 Network Driver - version 6.1.16-k2
Copyright (c) 1999-2005 Intel Corporation.
pci_call_probe: starting drv<c03d4be0> dev<dfd16800> id<c03d4734>
pci_call_probe: dev->bus<dfce6800>
pci_call_probe: dev->bus->sysdata<00000000>
pci_call_probe: node<-1>
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
pci_call_probe: starting drv<c03ef220> dev<dfd17400> id<c03eed00>
pci_call_probe: dev->bus<dfce6800>
pci_call_probe: dev->bus->sysdata<00000000>
pci_call_probe: node<-1>
Linux Tulip driver version 1.1.13 (December 15, 2004)
input: AT Translated Set 2 keyboard as /class/input/input0
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 10baseT (#0) described by a
21140 non-MII (0) block.
tulip0: Index #1 - Media 100baseTx (#3) described by a
21140 non-MII (0) block.
tulip0: Index #2 - Media 10baseT-FDX (#4) described by a
21140 non-MII (0) block.
tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a
21140 non-MII (0) block.
eth1: Digital DS21140 Tulip rev 33 at 0001fc00,
00:00:BC:0F:08:96, IRQ 28.
pci_call_probe: starting drv<c040a360> dev<dfd14400> id<c040a0fc>
pci_call_probe: dev->bus<dfce6600>
pci_call_probe: dev->bus->sysdata<dfffafa0>
pci_call_probe: node<0>
qla1280: QLA1040 found on PCI bus 0, dev 11
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
arch/i386/pci/common.c | 2 ++
arch/i386/pci/fixup.c | 8 +++++---
arch/i386/pci/legacy.c | 3 ++-
arch/i386/pci/numa.c | 8 +++++---
arch/i386/pci/visws.c | 4 ++--
include/asm-i386/pci.h | 1 +
6 files changed, 17 insertions(+), 9 deletions(-)
diff -upN reference/arch/i386/pci/common.c current/arch/i386/pci/common.c
--- reference/arch/i386/pci/common.c
+++ current/arch/i386/pci/common.c
@@ -29,6 +29,8 @@ unsigned long pirq_table_addr;
struct pci_bus *pci_root_bus;
struct pci_raw_ops *raw_pci_ops;
+struct pci_sysdata pci_default_sysdata = { .node = -1 };
+
static int pci_read(struct pci_bus *bus, unsigned int devfn, int
where, int size, u32 *value)
{
return raw_pci_ops->read(pci_domain_nr(bus), bus->number,
diff -upN reference/arch/i386/pci/fixup.c current/arch/i386/pci/fixup.c
--- reference/arch/i386/pci/fixup.c
+++ current/arch/i386/pci/fixup.c
@@ -25,9 +25,11 @@ static void __devinit pci_fixup_i450nx(s
pci_read_config_byte(d, reg++, &subb);
DBG("i450NX PXB %d: %02x/%02x/%02x\n", pxb, busno, suba, subb);
if (busno)
- pci_scan_bus(busno, &pci_root_ops, NULL); /* Bus A */
+ pci_scan_bus(busno, &pci_root_ops,
+ &pci_default_sysdata); /* Bus A */
if (suba < subb)
- pci_scan_bus(suba+1, &pci_root_ops, NULL); /* Bus B */
+ pci_scan_bus(suba+1, &pci_root_ops,
+ &pci_default_sysdata); /* Bus B */
}
pcibios_last_bus = -1;
}
@@ -42,7 +44,7 @@ static void __devinit pci_fixup_i450gx(s
u8 busno;
pci_read_config_byte(d, 0x4a, &busno);
printk(KERN_INFO "PCI: i440KX/GX host bridge %s: secondary bus
%02x\n", pci_name(d), busno);
- pci_scan_bus(busno, &pci_root_ops, NULL);
+ pci_scan_bus(busno, &pci_root_ops, &pci_default_sysdata);
pcibios_last_bus = -1;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx);
diff -upN reference/arch/i386/pci/legacy.c current/arch/i386/pci/legacy.c
--- reference/arch/i386/pci/legacy.c
+++ current/arch/i386/pci/legacy.c
@@ -26,7 +26,8 @@ static void __devinit pcibios_fixup_peer
l != 0x0000 && l != 0xffff) {
DBG("Found device at %02x:%02x [%04x]\n", n, devfn, l);
printk(KERN_INFO "PCI: Discovered peer bus %02x\n", n);
- pci_scan_bus(n, &pci_root_ops, NULL);
+ pci_scan_bus(n, &pci_root_ops,
+ &pci_default_sysdata);
break;
}
}
diff -upN reference/arch/i386/pci/numa.c current/arch/i386/pci/numa.c
--- reference/arch/i386/pci/numa.c
+++ current/arch/i386/pci/numa.c
@@ -97,9 +97,11 @@ static void __devinit pci_fixup_i450nx(s
pci_read_config_byte(d, reg++, &subb);
DBG("i450NX PXB %d: %02x/%02x/%02x\n", pxb, busno, suba, subb);
if (busno)
- pci_scan_bus(QUADLOCAL2BUS(quad,busno), &pci_root_ops, NULL); /* Bus
A */
+ pci_scan_bus(QUADLOCAL2BUS(quad,busno), &pci_root_ops,
+ &pci_default_sysdata); /* Bus A */
if (suba < subb)
- pci_scan_bus(QUADLOCAL2BUS(quad,suba+1), &pci_root_ops, NULL); /*
Bus B */
+ pci_scan_bus(QUADLOCAL2BUS(quad,suba+1), &pci_root_ops,
+ &pci_default_sysdata); /* Bus B */
}
pcibios_last_bus = -1;
}
@@ -124,7 +126,7 @@ static int __init pci_numa_init(void)
printk("Scanning PCI bus %d for quad %d\n",
QUADLOCAL2BUS(quad,0), quad);
pci_scan_bus(QUADLOCAL2BUS(quad,0),
- &pci_root_ops, NULL);
+ &pci_root_ops, &pci_default_sysdata);
}
return 0;
}
diff -upN reference/arch/i386/pci/visws.c current/arch/i386/pci/visws.c
--- reference/arch/i386/pci/visws.c
+++ current/arch/i386/pci/visws.c
@@ -102,8 +102,8 @@ static int __init pcibios_init(void)
"bridge B (PIIX4) bus: %u\n", pci_bus1, pci_bus0);
raw_pci_ops = &pci_direct_conf1;
- pci_scan_bus(pci_bus0, &pci_root_ops, NULL);
- pci_scan_bus(pci_bus1, &pci_root_ops, NULL);
+ pci_scan_bus(pci_bus0, &pci_root_ops, &pci_default_sysdata);
+ pci_scan_bus(pci_bus1, &pci_root_ops, &pci_default_sysdata);
pci_fixup_irqs(visws_swizzle, visws_map_irq);
pcibios_resource_survey();
return 0;
diff -upN reference/include/asm-i386/pci.h current/include/asm-i386/pci.h
--- reference/include/asm-i386/pci.h
+++ current/include/asm-i386/pci.h
@@ -9,6 +9,7 @@ struct pci_sysdata {
int domain; /* PCI domain */
int node; /* NUMA node */
};
+extern struct pci_sysdata pci_default_sysdata;
#ifdef CONFIG_PCI_DOMAINS
static inline int pci_domain_nr(struct pci_bus *bus)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with 2.6.15-mm1 and mm2.
2006-01-10 0:05 ` Martin Bligh
@ 2006-01-10 0:46 ` Andrew Morton
2006-01-10 0:50 ` Martin Bligh
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2006-01-10 0:46 UTC (permalink / raw)
To: Martin Bligh; +Cc: linux-kernel, apw, greg
Martin Bligh <mbligh@google.com> wrote:
>
> >>from the NUMA-Q. http://test.kernel.org/19793/debug/console.log
> >>
> >
> >
> > Yes, I asked Greg about that - we don't know what's causing it yet. I have
> > a bad feeling that this bug will go into Linus's tree if we don't fix it
> > quick.
> >
> > I had problems with gregkh-pci-x86-pci-domain-support-the-meat.patch. It
> > might be worth reverting that.
>
> Andy figured out what caused it.
>
> >>on -mm2 I get the x86_64 seems to lock up (NFI why ... looking at it),
> >>the NUMA-Q and x440 panic (very similar to the above).
> >>
> >>I think Andy figured out what was causing those panics. Can we drop
> >>those patches until they're fixed?
> >>
> >
> >
> > I'm not aware of any buggy x86_64 patches in -mm2 :(
> >
> > I guess you don't have the time to sit down and do a bisection search.
> > It'd take a solid few hours...
>
> It's more that I don't have direct access to the machines in question
> any more. The x86_64 one might just be a machine issue ... trying to
> confirm that still ... but the PCI one was real.
>
> M.
>
> Below is cut & pasted, so not applyable, and maybe it shouldn't be
> applied. But ... it worked before whatever is in -mm ... so my personal
> feeling is that if we don't have a fix for whatever is currently in -mm,
> it should get dropped until we do ? Going backwards = bad.
>
> Perhaps I'm in a time loop, and just confused. but I don't think so ?
This isn't at all clear, sorry.
Does the patch you sent fix things in 2.6.15-mm2? On NUMAQ and on x86_64?
Does it fix a bug which was introduced in a patch which in in 2.6.15-mm2?
If so, which one?
etc ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with 2.6.15-mm1 and mm2.
2006-01-10 0:46 ` Andrew Morton
@ 2006-01-10 0:50 ` Martin Bligh
2006-01-10 14:52 ` Andy Whitcroft
0 siblings, 1 reply; 6+ messages in thread
From: Martin Bligh @ 2006-01-10 0:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, apw, greg
>> Below is cut & pasted, so not applyable, and maybe it shouldn't be
>> applied. But ... it worked before whatever is in -mm ... so my personal
>> feeling is that if we don't have a fix for whatever is currently in -mm,
>> it should get dropped until we do ? Going backwards = bad.
>>
>> Perhaps I'm in a time loop, and just confused. but I don't think so ?
>
>
> This isn't at all clear, sorry.
>
> Does the patch you sent fix things in 2.6.15-mm2? On NUMAQ and on x86_64?
> Does it fix a bug which was introduced in a patch which in in 2.6.15-mm2?
> If so, which one?
It fixes the symptom, yes. Greg complained it's papering over the
problem and not a real fix, which is fair enough, but ...
yes, it did seem to be a newly introduced problem in -mm1 or -mm2. To my
mind, if we don't have a proper fix, we ought to drop the patch that
caused the problem in the first place? Andy .. can you finger which
patch that was, I forget ...
M.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with 2.6.15-mm1 and mm2.
2006-01-10 0:50 ` Martin Bligh
@ 2006-01-10 14:52 ` Andy Whitcroft
0 siblings, 0 replies; 6+ messages in thread
From: Andy Whitcroft @ 2006-01-10 14:52 UTC (permalink / raw)
To: Martin Bligh, Andrew Morton; +Cc: linux-kernel, greg
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
> It fixes the symptom, yes. Greg complained it's papering over the
> problem and not a real fix, which is fair enough, but ...
>
> yes, it did seem to be a newly introduced problem in -mm1 or -mm2. To my
> mind, if we don't have a proper fix, we ought to drop the patch that
> caused the problem in the first place? Andy .. can you finger which
> patch that was, I forget ...
The fix I proposed (also attached to this email) fixes a bug introduced
in the pci domain patches in greg's tree, specifically this patch:
gregkh-pci-x86-pci-domain-support-struct-pci_sysdata.patch
I believe that my fix is complete in the context of those changes, in
that it returns the original semantics. As greg points out this exposes
a couple of places where we do have proper domain and node information
where it is not supplied. I have a patch or two waiting to be tested
which tries to fill in some of the gaps exposed, but the boxes I was
testing on have dropped off the network and am waiting for that to be
fixed before sending them in. That said I think that if the pci domain
patches are accepted then this minimal fix should be applied with them.
-apw
[-- Attachment #2: pci-device-ensure-sysdata-initialised --]
[-- Type: text/plain, Size: 6446 bytes --]
pci device ensure sysdata initialised
[Ok, here is a patch to ensure sysdata is valid for all busses.]
We have been seeing panic's on NUMA systems in pci_call_probe() in
2.6.15-rc5-mm2 and -mm3. It seems that some changes have occured
to the meaning of the 'sysdata' for a device such that it is no
longer just an integer containing the node, it is now a structure
containing the node and other data. However, it seems that we do not
always initialise this sysdata before we probe the device.
Below are three examples from a boot with this checked for.
The attached patch ensures that we supply a valid sysdata for system
busses. Currently we take no account of the node for this bus for
no ACPI configured systems. This is unchanged from the -mm1 code.
Intel(R) PRO/1000 Network Driver - version 6.1.16-k2
Copyright (c) 1999-2005 Intel Corporation.
pci_call_probe: starting drv<c03d4be0> dev<dfd16800> id<c03d4734>
pci_call_probe: dev->bus<dfce6800>
pci_call_probe: dev->bus->sysdata<00000000>
pci_call_probe: node<-1>
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
pci_call_probe: starting drv<c03ef220> dev<dfd17400> id<c03eed00>
pci_call_probe: dev->bus<dfce6800>
pci_call_probe: dev->bus->sysdata<00000000>
pci_call_probe: node<-1>
Linux Tulip driver version 1.1.13 (December 15, 2004)
input: AT Translated Set 2 keyboard as /class/input/input0
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 10baseT (#0) described by a
21140 non-MII (0) block.
tulip0: Index #1 - Media 100baseTx (#3) described by a
21140 non-MII (0) block.
tulip0: Index #2 - Media 10baseT-FDX (#4) described by a
21140 non-MII (0) block.
tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a
21140 non-MII (0) block.
eth1: Digital DS21140 Tulip rev 33 at 0001fc00,
00:00:BC:0F:08:96, IRQ 28.
pci_call_probe: starting drv<c040a360> dev<dfd14400> id<c040a0fc>
pci_call_probe: dev->bus<dfce6600>
pci_call_probe: dev->bus->sysdata<dfffafa0>
pci_call_probe: node<0>
qla1280: QLA1040 found on PCI bus 0, dev 11
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
arch/i386/pci/common.c | 2 ++
arch/i386/pci/fixup.c | 8 +++++---
arch/i386/pci/legacy.c | 3 ++-
arch/i386/pci/numa.c | 8 +++++---
arch/i386/pci/visws.c | 4 ++--
include/asm-i386/pci.h | 1 +
6 files changed, 17 insertions(+), 9 deletions(-)
diff -upN reference/arch/i386/pci/common.c current/arch/i386/pci/common.c
--- reference/arch/i386/pci/common.c
+++ current/arch/i386/pci/common.c
@@ -29,6 +29,8 @@ unsigned long pirq_table_addr;
struct pci_bus *pci_root_bus;
struct pci_raw_ops *raw_pci_ops;
+struct pci_sysdata pci_default_sysdata = { .node = -1 };
+
static int pci_read(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *value)
{
return raw_pci_ops->read(pci_domain_nr(bus), bus->number,
diff -upN reference/arch/i386/pci/fixup.c current/arch/i386/pci/fixup.c
--- reference/arch/i386/pci/fixup.c
+++ current/arch/i386/pci/fixup.c
@@ -25,9 +25,11 @@ static void __devinit pci_fixup_i450nx(s
pci_read_config_byte(d, reg++, &subb);
DBG("i450NX PXB %d: %02x/%02x/%02x\n", pxb, busno, suba, subb);
if (busno)
- pci_scan_bus(busno, &pci_root_ops, NULL); /* Bus A */
+ pci_scan_bus(busno, &pci_root_ops,
+ &pci_default_sysdata); /* Bus A */
if (suba < subb)
- pci_scan_bus(suba+1, &pci_root_ops, NULL); /* Bus B */
+ pci_scan_bus(suba+1, &pci_root_ops,
+ &pci_default_sysdata); /* Bus B */
}
pcibios_last_bus = -1;
}
@@ -42,7 +44,7 @@ static void __devinit pci_fixup_i450gx(s
u8 busno;
pci_read_config_byte(d, 0x4a, &busno);
printk(KERN_INFO "PCI: i440KX/GX host bridge %s: secondary bus %02x\n", pci_name(d), busno);
- pci_scan_bus(busno, &pci_root_ops, NULL);
+ pci_scan_bus(busno, &pci_root_ops, &pci_default_sysdata);
pcibios_last_bus = -1;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454GX, pci_fixup_i450gx);
diff -upN reference/arch/i386/pci/legacy.c current/arch/i386/pci/legacy.c
--- reference/arch/i386/pci/legacy.c
+++ current/arch/i386/pci/legacy.c
@@ -26,7 +26,8 @@ static void __devinit pcibios_fixup_peer
l != 0x0000 && l != 0xffff) {
DBG("Found device at %02x:%02x [%04x]\n", n, devfn, l);
printk(KERN_INFO "PCI: Discovered peer bus %02x\n", n);
- pci_scan_bus(n, &pci_root_ops, NULL);
+ pci_scan_bus(n, &pci_root_ops,
+ &pci_default_sysdata);
break;
}
}
diff -upN reference/arch/i386/pci/numa.c current/arch/i386/pci/numa.c
--- reference/arch/i386/pci/numa.c
+++ current/arch/i386/pci/numa.c
@@ -97,9 +97,11 @@ static void __devinit pci_fixup_i450nx(s
pci_read_config_byte(d, reg++, &subb);
DBG("i450NX PXB %d: %02x/%02x/%02x\n", pxb, busno, suba, subb);
if (busno)
- pci_scan_bus(QUADLOCAL2BUS(quad,busno), &pci_root_ops, NULL); /* Bus A */
+ pci_scan_bus(QUADLOCAL2BUS(quad,busno), &pci_root_ops,
+ &pci_default_sysdata); /* Bus A */
if (suba < subb)
- pci_scan_bus(QUADLOCAL2BUS(quad,suba+1), &pci_root_ops, NULL); /* Bus B */
+ pci_scan_bus(QUADLOCAL2BUS(quad,suba+1), &pci_root_ops,
+ &pci_default_sysdata); /* Bus B */
}
pcibios_last_bus = -1;
}
@@ -124,7 +126,7 @@ static int __init pci_numa_init(void)
printk("Scanning PCI bus %d for quad %d\n",
QUADLOCAL2BUS(quad,0), quad);
pci_scan_bus(QUADLOCAL2BUS(quad,0),
- &pci_root_ops, NULL);
+ &pci_root_ops, &pci_default_sysdata);
}
return 0;
}
diff -upN reference/arch/i386/pci/visws.c current/arch/i386/pci/visws.c
--- reference/arch/i386/pci/visws.c
+++ current/arch/i386/pci/visws.c
@@ -102,8 +102,8 @@ static int __init pcibios_init(void)
"bridge B (PIIX4) bus: %u\n", pci_bus1, pci_bus0);
raw_pci_ops = &pci_direct_conf1;
- pci_scan_bus(pci_bus0, &pci_root_ops, NULL);
- pci_scan_bus(pci_bus1, &pci_root_ops, NULL);
+ pci_scan_bus(pci_bus0, &pci_root_ops, &pci_default_sysdata);
+ pci_scan_bus(pci_bus1, &pci_root_ops, &pci_default_sysdata);
pci_fixup_irqs(visws_swizzle, visws_map_irq);
pcibios_resource_survey();
return 0;
diff -upN reference/include/asm-i386/pci.h current/include/asm-i386/pci.h
--- reference/include/asm-i386/pci.h
+++ current/include/asm-i386/pci.h
@@ -9,6 +9,7 @@ struct pci_sysdata {
int domain; /* PCI domain */
int node; /* NUMA node */
};
+extern struct pci_sysdata pci_default_sysdata;
#ifdef CONFIG_PCI_DOMAINS
static inline int pci_domain_nr(struct pci_bus *bus)
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-01-10 14:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-09 17:59 Problems with 2.6.15-mm1 and mm2 Martin Bligh
2006-01-09 23:41 ` Andrew Morton
2006-01-10 0:05 ` Martin Bligh
2006-01-10 0:46 ` Andrew Morton
2006-01-10 0:50 ` Martin Bligh
2006-01-10 14:52 ` Andy Whitcroft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).