On Friday 09 October 2009, Danny Feng wrote: > On 10/04/2009 06:56 AM, Rafael J. Wysocki wrote: > > On Thursday 01 October 2009, Alex Chiang wrote: > >> Hi Danny, > >> > >> * Danny Feng<dfeng@xxxxxxxxxx>: > >>> Call Trace: > >>> [<ffffffff81254193>] acpi_get_pci_dev+0x106/0x167 > >>> [<ffffffff8125545a>] acpi_pci_bind+0x1c/0x86 > >>> [<ffffffff8116230a>] ? sysfs_create_file+0x2a/0x2c > >>> [<ffffffff8125141f>] acpi_add_single_object+0x964/0xa0c > >>> [<ffffffff812515a7>] acpi_bus_check_add+0xe0/0x138 > >>> [<ffffffff81251667>] acpi_bus_scan+0x68/0xa0 > >>> [<ffffffff812516f4>] acpi_bus_add+0x2a/0x2e > >>> [<ffffffff81252c59>] hotplug_dock_devices+0x114/0x13e > >>> [<ffffffff8125301a>] acpi_dock_deferred_cb+0xbf/0x192 > >>> [<ffffffff8124d6ca>] acpi_os_execute_deferred+0x29/0x36 > >>> [<ffffffff8106a244>] worker_thread+0x251/0x347 > >>> [<ffffffff8106a1ef>] ? worker_thread+0x1fc/0x347 > >>> [<ffffffff8124d6a1>] ? acpi_os_execute_deferred+0x0/0x36 > >>> [<ffffffff8106e426>] ? autoremove_wake_function+0x0/0x39 > >>> [<ffffffff81069ff3>] ? worker_thread+0x0/0x347 > >>> [<ffffffff8106e0e0>] kthread+0x7f/0x87 > >>> [<ffffffff81012cea>] child_rip+0xa/0x20 > >>> [<ffffffff81012650>] ? restore_args+0x0/0x30 > >>> [<ffffffff8106e061>] ? kthread+0x0/0x87 > >>> [<ffffffff81012ce0>] ? child_rip+0x0/0x20 > >>> Code: ff 49 89 fc 41 89 f5 a9 00 ff ff 07 74 11 be 87 00 00 00 48 c7 c7 > >>> 45 6d 5a 81 e8 f6 2b e3 ff 48 c7 c7 30 ab 68 81 e8 29 77 20 00<49> 8b > >>> 5c 24 28 49 83 c4 28 eb 09 44 39 6b 38 74 10 48 89 c3 48 > >>> RIP [<ffffffff812217e7>] pci_get_slot+0x4c/0x8c > >>> RSP<ffff88022ee69aa0> > >>> CR2: 0000000000000028 > >>> ---[ end trace b5a7793bd9db2a4d ]--- > >> > >> Can you please reproduce with this debug patch? I'm guessing that > >> we're dying because we have a NULL parent device, but I'm curious > >> as to what causes this situation to occur. > > > > If we had a NULL parent, acpi_get_parent() would return an error. Also, if we > > one of the devices is NULL at the PCI level, pci_get_slot() will return NULL. > > The only possibility left is that one of the buses we find in the ACPI tables > > doesn't have a secondary PCI bus. > > > > I think what happens is that on resume we get a dock notification > > (via dock_acpi_notifier registered in dock_init()) for a dock station device > > that is present in the ACPI tables, but not physically accessible at the moment > > (I guess that falls into the "BIOS bug" category, but we can fix this easily in > > the kernel). > > > > So, IMO, the appended patch is the right fix. > > > > Danny, please test it and report back (in particular, please tell us if you see > > the "Secondary bus not present" message in dmesg). > Yes, this patch works. I got "ata_piix 0000:00:1f.2: Secondary bus not > present". Now that's a puzzle! Can you please attach the output of acpidump from this machine? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
