Bug 7812

Summary: Dell Prescision M20 100% cpu usage after undocking
Product: ACPI Reporter: Dawid Wr (dawid)
Component: Config-HotplugAssignee: Shaohua (shaohua.li)
Severity: normal CC: acpi-bugzilla, kristen.c.accardi, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: Subsystem:
Regression: --- Bisected commit-id:
Attachments: dmesg's output after pressing the 'undock button' twice and then rmmodding the dock module and modprobing it.
Tracebacks, dmesg, etc.
acpidump taken soon after booting up
debug patch

Description Dawid Wr 2007-01-11 12:25:29 UTC
Most recent kernel where this bug did *NOT* occur: never used dock module before
Distribution: archlinux
Hardware Environment: Dell Precision M20 (pretty much Latitude D610), Dell D/
Port Replicator
Software Environment:
Problem Description: having dock module loaded, after pressing the 'undock' 
button on the port replicator cpu usage raises to 100%. Note that I am not 
removing the laptop from the replicator, if I do the problem (AFIR) disappears. 
On the other hand the problem sometimes happens when docking the laptop, too. 

Steps to reproduce: Put the laptop on the replicator and press the undock 
button on the replicators panel (might need to power it off, power on and then 
try). Notice the cpu usage. Try to rmmod dock module  - it causes a segfault 
and traceback. Try to modprobe it and it causes segfault and another 
(different) traceback again. Both tbacks are attached.
Comment 1 Dawid Wr 2007-04-26 02:39:27 UTC
I tried to reproduce the bug again with 2.6.20. It's still here. Again, what I 
had to to was just pressing the "undock" button on port replicator and keep the 
latop plugged into it (i.e. not remove it). After some time (or a couple more 
button pressings) kacpid process raises its cpu usage to ~90%. Again, both 
rmmoding and modprobing the dock module causes errors.
Comment 2 Dawid Wr 2007-04-26 02:41:43 UTC
Created attachment 11276 [details]
dmesg's output after pressing the 'undock button' twice and then rmmodding the dock module and modprobing it.
Comment 3 Natalie Protasevich 2007-06-14 16:42:20 UTC
Maybe you can collect alt-sysrq-t traces while the system goes into 100% cpu busy state, could be revealing if there is any locking issue, and some race condition afterwards that causes oops/panics. 2 consequential traces will be great because one can see better which processes are stuck.
Comment 4 ykzhao 2007-12-19 20:59:55 UTC
Hi, Dawid
Will you please try the latest kernel and see whether the problem still exists ? 
After the system is booted, please attach the output of acpidump and dmesg.
It will be great if the debug function of acpi is enabled in kernel configuration.
Comment 5 Dawid Wr 2007-12-21 15:30:45 UTC
Created attachment 14141 [details]
Tracebacks, dmesg, etc.

I tested with, the problem is still here, with one difference. I can now rmmod the dock module and modprobe it back without problems. Moreover, after doing that system goes back to normal state, i.e. the cpu usage drops and everything seems working fine and usable again. 
However, I attach the tracebacks and outputs as you asked. 

syslog_after_2_consecutive_sysrq_t_tracebacks.out - file contains combined dmesg, syslog and tracebacks output. The undock button is pressed at 00:02:49, first alt-sysrq-t traceback taken at 00:04:16, second one at 00:04:50. 
As I mentioned above, rmmmoding dock module and modprobing it back causes no errors - simple "Dec 22 00:08:34 kromka ACPI: ACPI Dock Station Driver" shows up in dmesg.
Comment 6 Dawid Wr 2007-12-21 15:31:55 UTC
Created attachment 14142 [details]
acpidump taken soon after booting up
Comment 7 Shaohua 2008-05-05 22:16:31 UTC
Created attachment 16033 [details]
debug patch

can you please try latest base kernel? If it doesn't work, try attached debug patch.
Comment 8 Shaohua 2008-07-14 22:12:13 UTC
No response, reject it.
Comment 9 Dawid Wr 2008-07-15 03:53:17 UTC
Hi. Sorry, I didn't notice the patch. I am currently however unable to test it as I don't have dock station here until the begining of October. I would be glad if someone else could test it though.