| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20061009184648.GA21207@us.ibm.com>
Date: Mon, 9 Oct 2006 11:46:48 -0700
From: Sukadev Bhattiprolu <sukadev@...ibm.com>
To: Jeff Garzik <jgarzik@...ox.com>
Cc: Martin Bligh <mbligh@...igh.org>,
Badari Pulavarty <pbadari@...ibm.com>,
Andrew Morton <akpm@...l.org>,
Andy Whitcroft <apw@...dowen.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: Panic in pci_call_probe from 2.6.18-mm2 and 2.6.18-mm3
Jeff Garzik [jgarzik@...ox.com] wrote:
| Martin Bligh wrote:
| >Badari Pulavarty wrote:
| >>On Sun, 2006-10-08 at 00:02 -0700, Martin J. Bligh wrote:
| >>
| >>>Not sure if you've seen this already ... catching up on test results.
| >>>
| >>>This was on NUMA-Q, on both -mm2 and -mm3. -mm1 didn't suffer from this
| >>>problem.
| >>>
| >>>Full logs:
| >>>
| >>>mm2 - http://test.kernel.org/abat/50727/debug/console.log
| >>>mm3 - http://test.kernel.org/abat/51442/debug/console.log
| >>>
| >>>config - http://test.kernel.org/abat/51442/build/dotconfig
| >>>
| >>>I'm guessing from the 00000004 that the pcibus_to_node(dev->bus)
| >>>is failing because bus->sysdata is NULL. The disassembly and
| >>>structure offsets seem to line up for that.
| >>>
| >>>#define pcibus_to_node(bus) (
| >>> (struct pci_sysdata *)((bus)->sysdata))->node
| >>>
| >>>struct pci_sysdata {
| >>> int domain; /* PCI domain */
| >>> int node; /* NUMA node */
| >>>};
| >>>
| >>
| >>
| >>Martin,
| >>
| >>Jeff moved "node" to a proper field in sysdata, instead
| >>of overloading sysdata itself. I think this is causing the
| >>problem. I guess we could end up with sysdata = NULL in some
| >>cases ? Since you are the NUMA-Q expert, where does sysdata gets set
| >>for NUMA-Q ? :)
| >>
| >>-mm2 changed:
| >>
| >>#define pcibus_to_node(bus) ((long) (bus)->sysdata)
| >>
| >>to
| >>#define pcibus_to_node(bus) ((struct pci_sysdata *)((bus)->sysdata))-
| >>
| >>>node
| >
| >Buggered if I know, that's some strange pci thing ;-)
| >
| >But can we revert whatever patch that was until it gets fixed, please?
|
| It needs to get fixed, otherwise whose buses of PCI devices disappear on
| some machines.
|
| Can you turn on PCI debugging?
|
| Jeff
I turned on CONFIG_PCI_DEBUG. already had CONFIG_KERNEL_DEBUG and
CONFIG_DEBUG_INFO. Booted with "debug" parameter.
Here are the last few messages. Complete dmesg attached.
Let me know if there are other config tokens or boot options that may
provide more info.
Suka
---
PCI: Calling quirk c024da00 for 0000:00:0a.0
PCI: Calling quirk c031ce30 for 0000:00:0a.0
PCI: Calling quirk c024da00 for 0000:00:0b.0
PCI: Calling quirk c031ce30 for 0000:00:0b.0
PCI: Calling quirk c024da00 for 0000:00:0e.0
PCI: Calling quirk c031ce30 for 0000:00:0e.0
PCI: Calling quirk c024da00 for 0000:00:0e.1
PCI: Calling quirk c031ce30 for 0000:00:0e.1
PCI: Calling quirk c024da00 for 0000:00:0e.2
PCI: Calling quirk c031ce30 for 0000:00:0e.2
PCI: Calling quirk c024da00 for 0000:00:0e.3
PCI: Calling quirk c031ce30 for 0000:00:0e.3
PCI: Calling quirk c024da00 for 0000:00:10.0
PCI: Calling quirk c031ce30 for 0000:00:10.0
PCI: Calling quirk c024da00 for 0000:00:12.0
PCI: Calling quirk c05093b0 for 0000:00:12.0
PCI: Calling quirk c031ce30 for 0000:00:12.0
PCI: Calling quirk c024da00 for 0000:00:14.0
PCI: Calling quirk c05093b0 for 0000:00:14.0
PCI: Calling quirk c031ce30 for 0000:00:14.0
PCI: Calling quirk c024da00 for 0000:01:0c.0
PCI: Calling quirk c031ce30 for 0000:01:0c.0
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.2.9-k2
Copyright (c) 1999-2006 Intel Corporation.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
printing eip:
c024e92c
*pde = 00529001
*pte = 00000000
Oops: 0000 [#1]
SMP
last sysfs file:
Modules linked in:
CPU: 0
EIP: 0060:[<c024e92c>] Not tainted VLI
EFLAGS: 00010286 (2.6.18-mm3 #3)
EIP is at pci_call_probe+0x1c/0xe0
eax: 00000000 ebx: dfe63c00 ecx: c10fca90 edx: c048ad60
esi: dfe63c00 edi: 0000000f ebp: dfc3fd00 esp: c10ffe70
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, ti=c10fe000 task=c10fca90 task.ti=c10fe000)
Stack: dfe63c00 ffffffed ffffffed dfe63c00 c048b1c0 c024ea55 c048b1c0 dfe63c00
c048ad60 c048b1c0 dfe63c00 c048b1f4 c024ea9f c048b1c0 dfe63c00 dfe63c48
dfc3fd00 c02761f9 dfe63c48 00000286 dfff9060 000000d0 c048b1f4 dfc3fd00
Call Trace:
[<c024ea55>] __pci_device_probe+0x65/0x80
[<c024ea9f>] pci_device_probe+0x2f/0x50
[<c02761f9>] really_probe+0xf9/0x100
[<c02762e8>] driver_probe_device+0xc8/0xe0
[<c03ae92d>] klist_next+0x5d/0xa0
[<c02763a0>] __driver_attach+0x0/0xa0
[<c0276430>] __driver_attach+0x90/0xa0
[<c0275409>] bus_for_each_dev+0x69/0x80
[<c0276465>] driver_attach+0x25/0x30
[<c02763a0>] __driver_attach+0x0/0xa0
[<c0275ad3>] bus_add_driver+0x73/0x140
[<c024edc4>] __pci_register_driver+0x74/0x90
[<c050c6f9>] tulip_init+0x29/0x30
[<c04f2a62>] do_initcalls+0x42/0x140
[<c01433eb>] register_irq_proc+0xab/0xd0
[<c01003f0>] init+0x0/0x1a0
[<c0143479>] init_irq_proc+0x39/0x50
[<c01003f0>] init+0x0/0x1a0
[<c0100451>] init+0x61/0x1a0
[<c0103c0b>] kernel_thread_helper+0x7/0x1c
=======================
Code: 74 92 eb 8e 8d 74 26 00 8d bc 27 00 00 00 00 57 56 53 83 ec 08 8b 5c 24 1c 89 e0 25 00 e0 ff ff 8b 08 8b 43 10 8b 79 5c 8b 40 44 <8b> 50 04 85 d2 78 11 0f a3 15 c0 9f 4e c0 19 c0 85 c0 0f 85 8c
View attachment "dmesg-3.txt" of type "text/plain" (13800 bytes)
Powered by blists - more mailing lists