Description of problem: ThinkPad X31 (2672-CXG) in dock (91P9024) will become unresponsive when the eject button on the dock is pressed Version-Release number of selected component (if applicable): 2.6.25-0.234.rc9.git1.fc9 How reproducible: always Steps to Reproduce: 1. press the undock button on the docking station Actual results: after a few seconds the system just locks up. Expected results: either complete undocking procedure or do nothing at all, undocking being preferred of course Additional info: # lshal -m Start monitoring devicelist: ------------------------------------------------- 14:20:43.296: pci_8086_24ca_scsi_host_0_scsi_device_lun0_scsi_generic removed 14:20:43.514: storage_model_RW/DVD_GCC_4240N removed 14:20:43.551: pci_8086_24ca_scsi_host_0_scsi_device_lun0 removed 14:20:43.554: pci_8086_24ca_scsi_host_0 removed [so it removed the DVD drive in th edock, as expected and then it locks up] In syslog I get kernel: ata2.00: disabled kernel: ata2.00: detaching (SCSI 1:0:0:0) kernel: D.MSTR: Bay event SysRq-T (and then S U B) does not end up on disk, I'll try next week with a serial console (do not have the cable here). The system's smolt ID is pub_0f2c73c6-fe24-4644-9a21-456ef1e6c1bc in case you want to look it up
setting needinfo on myself until I provide the Sysrq-t output.
Created attachment 303238 [details] console output from boot to hang changed /etc/rsyslogd.conf so that kern.* goes to ttyS0 booted with "console=ttyS0,115200" but I do not get the wished output :-( (I just see "SysRq : Show State", so it got the Sysrq-T and subsequent Sysrq-S, Sysrq-U, Sysrq-B work just fine.) what am I doing wrong here? What I do see (and hence the log being attached) is "kernel: ACPI: \_SB_.PCI0.IDE0.SCND.MSTR: Bay event" spamming when I press the key. Not sure if this is enough for you to work with. Feel free to tell me WTH I am doing wrong in getting that SysRq-T output.
oh, creating an attachment does not flip out of NEEDINFO
(In reply to comment #2) > Created an attachment (id=303238) [edit] > console output from boot to hang > > changed /etc/rsyslogd.conf so that kern.* goes to ttyS0 > booted with "console=ttyS0,115200" > but I do not get the wished output :-( > (I just see "SysRq : Show State", so it got the Sysrq-T and subsequent Sysrq-S, > Sysrq-U, Sysrq-B work just fine.) Maybe the console log level is set wrong? Try booting with kernel options "ignore_loglevel sysrq_always_enabled".
Just to confirm that I have the same problem on Fedora 8: with kernels 2.6.23 (i686): no problem at all (dock/undock) with kernels 2.6.24 (i686): freezes everytime I press the "undock" button or I brutally undock (undock without pressing the button). I didn't see any error nor information in any log files about the freezes.
Created attachment 303664 [details] serial console log of hang doh! setting log level to 9 before attempting SysRq-T reaaly helps. attached is the serial console log of the boot and the SysRq-T output when the machine is hung. I only set log level to 9 once the machine was hung. Note that the "ACPI: \_SB_.PCI0.IDE0.SCND.MSTR: Bay event" entries seem to continue ad absurdum, I stopped logging after a while.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I confirm this bug is still in Fedora 9, kernel 2.6.25-14.fc9.i686.
one should change the SEVERITY to HIGH because it causes data losses as it freezes the laptop entirely without warning. Nothing is reacting, only BIOS functions still remain usable, like screen brightness. no more console, nor ssh, nor anything alive.
OK I tried to unload the "bay" new experimental acpi module and there was no more freeze. someone on IRC #fedora_kernel advised me that this has to do with lib_ata: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=ae6c23c4 so for now a quick work around is to blacklist the bay module. Obviously it needs testing but I can't do that because I'm not skilled enough in compiling kernel. So if anyone is skilled enough and willing to test that code, feel free to help. :)
*** This bug has been marked as a duplicate of 439197 ***