Customer is getting a panic from x440 w/ sysfs. May well not be
sysfs's fault ... but it's difficult to tell without knowing
what's meant to happen here ;-) debug is turned on.
Looks like kobject_register is just getting an error from kobject_add,
but as we don't see this:
pr_debug("kobject %s: registering. parent: %s, set: %s\n",
kobj->name, parent ? parent->name : "<NULL>",
kobj->kset ? kobj->kset->kobj.name : "<NULL>" );
presumably we're hitting:
if (!(kobj = kobject_get(kobj)))
return -ENOENT;
But withh no real context on all the kobject stuff it's hard to tell what
that really means ;-)
M.
Type: Processor ANSI SCSI revision: 02
DEV: registering device: ID = '1:0:9:0', name = ZIBM GNHv1 S2 0
kobject 1:0:9:0: registering. parent: 01:03.1, set: devices
bus scsi: add device 1:0:9:0
sysfs_create_link: depth = 3, size = 38
sysfs_create_link: path = '../../../devices/pci1/01:03.1/1:0:9:0'
(scsi1:A:12): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Vendor: IBM-ESXS Model: ST336607LC F Rev: B258
Type: Direct-Access ANSI SCSI revision: 03
DEV: registering device: ID = '1:0:12:0', name = SIBM-ESXSST336607LC F
3JA0JR
4X000073235STN
kobject 1:0:12:0: registering. parent: 01:03.1, set: devices
bus scsi: add device 1:0:12:0
sysfs_create_link: depth = 3, size = 39
sysfs_create_link: path = '../../../devices/pci1/01:03.1/1:0:12:0'
scsi1:A:12:0: Tagged Queuing enabled. Depth 32
(scsi1:A:13): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Vendor: IBM-ESXS Model: ST336607LC F Rev: B258
Type: Direct-Access ANSI SCSI revision: 03
DEV: registering device: ID = '1:0:13:0', name = SIBM-ESXSST336607LC F
3JA0J7
EV000073235W9F
kobject 1:0:13:0: registering. parent: 01:03.1, set: devices
bus scsi: add device 1:0:13:0
(scsi1:A:13): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Vendor: IBM-ESXS Model: ST336607LC F Rev: B258
Type: Direct-Access ANSI SCSI revision: 03
DEV: registering device: ID = '1:0:13:0', name = SIBM-ESXSST336607LC F
3JA0J7
EV000073235W9F
kobject 1:0:13:0: registering. parent: 01:03.1, set: devices
bus scsi: add device 1:0:13:0
sysfs_create_link: depth = 3, size = 39
sysfs_create_link: path = '../../../devices/pci1/01:03.1/1:0:13:0'
scsi1:A:13:0: Tagged Queuing enabled. Depth 32
bus pci: add driver ips
kobject ips: registering. parent: <NULL>, set: drivers
bus pci: add driver ips
kobject ips: registering. parent: <NULL>, set: drivers
Badness in kobject_register at lib/kobject.c:152
Call Trace:
[<c019a47b>] kobject_register+0x3b/0x50
[<c01bf3f5>] bus_add_driver+0x65/0xe0
[<c019cec6>] pci_register_driver+0x46/0x60
[<c0209b8a>] ips_detect+0x8a/0xc0
[<c01e82c6>] __scsi_add_host+0x56/0x70
[<c01e8679>] scsi_register_host+0x39/0x80
[<c01050ae>] init+0x4e/0x1c0
[<c0105060>] init+0x0/0x1c0
Thanks for the debug output and backtrace - that's really helpful. :)
> bus pci: add driver ips
>
> kobject ips: registering. parent: <NULL>, set: drivers
>
> bus pci: add driver ips
>
> kobject ips: registering. parent: <NULL>, set: drivers
>
> Badness in kobject_register at lib/kobject.c:152
>
> Call Trace:
[...]
This is typically caused by the same object being added twice at the same
level in the hierarchy, which appears to be happening. Is the ips driver
calling pci_register_driver() twice?
-pat
Patrick Mochel [[email protected]] wrote:
>
> This is typically caused by the same object being added twice at the same
> level in the hierarchy, which appears to be happening. Is the ips driver
> calling pci_register_driver() twice?
>
> -pat
It was possible in the past that pci_module_init could be called more
than once with non-unique pci_driver names. It is fixed in the current
trees, but I do not have the date when it was pushed. Here is some
context mail links.
http://marc.theaimsgroup.com/?l=linux-scsi&m=104275858704733&w=2
http://marc.theaimsgroup.com/?l=linux-scsi&m=104455557710731&w=2
-andmike
--
Michael Anderson
[email protected]
>> This is typically caused by the same object being added twice at the
>> same level in the hierarchy, which appears to be happening. Is the ips
>> driver calling pci_register_driver() twice?
>>
>> -pat
>
> It was possible in the past that pci_module_init could be called more
> than once with non-unique pci_driver names. It is fixed in the current
> trees, but I do not have the date when it was pushed. Here is some
> context mail links.
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=104275858704733&w=2
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=104455557710731&w=2
OK, so two similar, but not identical cards using the same driver?
First patch mentioned looks very simple, but won't apply to 2.5.62
There's now just:
static char ips_hot_plug_name[] = "ips";
static int __devinit ips_insert_device(struct pci_dev *pci_dev, const
struct pci_device_id *ent);
static void __devexit ips_remove_device(struct pci_dev *pci_dev);
struct pci_driver ips_pci_driver = {
.name = ips_hot_plug_name,
.id_table = ips_pci_table,
.probe = ips_insert_device,
.remove = __devexit_p(ips_remove_device),
};
Second patch looks a little intimidating ... more like a full blown update
of the driver ... I'd rather not go there unless I really have to.
M.
Martin J. Bligh [[email protected]] wrote:
> OK, so two similar, but not identical cards using the same driver?
> First patch mentioned looks very simple, but won't apply to 2.5.62
Are you seeing this problem on 2.5.62? The registration problem I
described should be gone in 2.5.62.
-andmike
--
Michael Anderson
[email protected]
>> OK, so two similar, but not identical cards using the same driver?
>> First patch mentioned looks very simple, but won't apply to 2.5.62
>
> Are you seeing this problem on 2.5.62? The registration problem I
> described should be gone in 2.5.62.
Yup. But I can't see it now we avoided a VM bug ... maybe it was indirect
fallout from that ... sorry. If it's still happening, and I just missed it,
will let you know. Thanks for the help,
M.