Bug 443222

Summary: X31 freezes (not oops) on dock eject
Product: [Fedora] Fedora Reporter: Patrick C. F. Ernzer <pcfe>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-27 14:07:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
console output from boot to hang
serial console log of hang none

Description Patrick C. F. Ernzer 2008-04-19 08:40:43 EDT
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):

How reproducible:

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
Comment 1 Patrick C. F. Ernzer 2008-04-19 08:42:42 EDT
setting needinfo on myself until I provide the Sysrq-t output.
Comment 2 Patrick C. F. Ernzer 2008-04-21 21:44:40 EDT
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.
Comment 3 Patrick C. F. Ernzer 2008-04-21 21:45:38 EDT
oh, creating an attachment does not flip out of NEEDINFO
Comment 4 Chuck Ebbert 2008-04-24 11:50:30 EDT
(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".
Comment 5 Dag 2008-04-24 12:49:39 EDT
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.
Comment 6 Patrick C. F. Ernzer 2008-04-24 13:19:51 EDT
Created attachment 303664 [details]
serial console log of hang

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.
Comment 7 Bug Zapper 2008-05-14 05:43:23 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 8 Dag 2008-05-15 08:57:17 EDT
I confirm this bug is still in Fedora 9, kernel 2.6.25-14.fc9.i686.
Comment 9 Dag 2008-05-15 09:02:59 EDT
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
no more console, nor ssh, nor anything alive.
Comment 10 Dag 2008-05-23 07:05:25 EDT
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:

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. :)
Comment 11 Chuck Ebbert 2008-05-27 14:07:46 EDT

*** This bug has been marked as a duplicate of 439197 ***