Distribution: Debian Unstable Hardware Environment: Thinkpad T40p and ThinkPad Dock II Software Environment: ACPI dock driver from vanilla 2.6.18 Problem Description: If I dock my notebook to the dockingstation, I get the attached 'Scheduling while atomic BUG' in my dmesg. I can still work with this machine afterwards. Steps to reproduce: Dock the Thinkpad. I tested this with undocking first until now. If you like, I can boot the notebook outside the dock, dock it and see if it gives the same result.
Created attachment 9204 [details] dmesg after docking
I just want to make clear how to duplicate the problem. 1. Boot laptop docked. 2. Undock 3. Dock Or is it: 1. Boot laptop undocked 2. Dock ?
Sorry for being somewhat unclear on my first report. It's the first variant: 1. Boot laptop docked. 2. Undock 3. Dock If you like, i can test even the second variant. But earliest in three days, as the dock is in my office and I'm at home the next two days.
I can even reproduce the bug with the second scenario. 1. Boot laptop undocked. 2. Dock laptop. I'll attach a scecond dmesg.
Created attachment 9247 [details] dmesg after docking a undocked laptop
I add some ugly debug printk's to dock.c, to get a better overview where this bug triggers. The bug occurs inside hotplug_dock_devices(), between debug STEP 13 and 14. printk(KERN_INFO PREFIX "STEP 13\n"); /* * Now make sure that an acpi_device is created for each * dependent device, or removed if this is an eject request. * This will cause acpi_drivers to be stopped/started if they * exist */ list_for_each_entry(dd, &ds->dependent_devices, list) { printk(KERN_INFO PREFIX "STEP 14\n"); I have now idea about list_for_each_entry(). Hopefully this helps you to debug it. I attach a dmesg and the modified dock.c for reference. BTW, were you able to reproduce the bug?
Created attachment 9283 [details] dmesg with debug.
Created attachment 9284 [details] dock.c with debug.
Hi Stefan, Thanks for the additional debug output. I have not had a chance to duplicate the bug yet - I anticipate being able to spend time on this in a couple days. Thanks for your patience. Kristen
Hi Stefan, I was not able to reproduce - can you attach your .config please, there is probably something I don't have quite the same. Thanks, kristen
Created attachment 9311 [details] .config
JFYI, I was able to reproduce this even with 2.6.19-rc2 regards Stefan Schmidt
I was finally able to duplicate the problem - it seems to only happen while in preempt mode. I will try to find out if this is a generic problem with acpi, or specific to something that I'm doing wrong.
Good to know. I began to think this is a local problem. ;) Let me know if you have patches I should test.
Created attachment 9365 [details] patch to switch from spinlock to mutex when hotplugging devices
Can you try out the patch I attached and see if it solves your problem? thanks, Kristen
I will test your patch at the beginning of the next week, as I have the docking station in my office. regards Stefan Schmidt
I tested it now. The origin prblem seems fixed. No bug message in dmesg anymore. But I got another message in dmesg now. Not sure yet if this comes rom the patch: ACPI: docking IPv6 addrconf: prefix with wrong length 56 IPv6 addrconf: prefix with wrong length 56 ACPI Exception (pci_bind-0302): AE_NOT_FOUND, Unable to get data from device DOCK [20060707] ACPI: undocking
The message : ACPI Exception (pci_bind-0302): AE_NOT_FOUND, Unable to get data from device Is ok and is expected when you are hot plugging (i.e. docking) a device that previously had not existed. so, this seems to be working as far as I can tell. I'll submit this fix.
Ah, ok. The message was a bit confusing, as it talks about exeception. I just saw your patch submit on lkml. Thanks for your work. I'm fine with it, so you can close the bug. regards Stefan Schmidt
patch from comment #15 applied to acpi-test
shipped in 2.6.20-rc2 closed.