Bug 443222 - X31 freezes (not oops) on dock eject
X31 freezes (not oops) on dock eject
Status: CLOSED DUPLICATE of bug 439197
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-19 08:40 EDT by Patrick C. F. Ernzer
Modified: 2008-05-27 14:07 EDT (History)
0 users

See Also:
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:


Attachments (Terms of Use)
console output from boot to hang (85.24 KB, text/plain)
2008-04-21 21:44 EDT, Patrick C. F. Ernzer
no flags Details
serial console log of hang (424.33 KB, text/plain)
2008-04-24 13:19 EDT, Patrick C. F. Ernzer
no flags Details

  None (edit)
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):
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
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

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.
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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
brightness.
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:
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. :)
Comment 11 Chuck Ebbert 2008-05-27 14:07:46 EDT

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

Note You need to log in before you can comment on or make changes to this bug.