lkml.org 
[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [2.6.30] Kernel bug with dock driver
Date
Am Monday, 15. June 2009 schrieb Henrique de Moraes Holschuh:
> Do it in single user mode with udev helpers *killed*, but just release

Today I tried to reproduce the bug in runlevel 2 (Debian based system) without
success, even after a suspend to disk. In the past this was one method to
trigger bugs with the bay.

> the lever, _don't_ pull the drive off the bay, unless you do verify that
> the bay LED went off.
>
> ***NEVER*** remove an Ultrabay device with the Ultrabay LED still lit,
> especially if it is a PATA device.

I did this accidentally some times before and the bay is still working. But
I'll try to not to do it again :)

> If the bug cannot be reproduced in that condition, it is happening
> because userspace is trapping the lever release event (as it should),
> and doing something the kernel doesn't like with it (which is a bug
> in the kernel in any case). That might help you track down a better
> way to reproduce the issue.

Userspace scripts are written by me (based on some information from
thinkwiki).
The udev rule looks like this:
ATTR{type}=="ata_bay", ATTR{docked}=="1", KERNEL=="dock.*", ACTION=="change",
SUBSYSTEM=="platform", RUN+="/usr/local/sbin/ultrabay_open"

and ultrabay_open contains the following lines of shell code:
#!/bin/bash
ULTRABAY_SYSDIR='/sys/class/scsi_device/1:0:0:0/device'
shopt -s nullglob

if [ -d $ULTRABAY_SYSDIR ]; then
sync
echo 1 > $ULTRABAY_SYSDIR/delete
logger "removed $ULTRABAY_SYSDIR"
fi
sync
# Turn off power to the UltraBay:
if [ -f /sys/devices/platform/dock.2/undock ]; then
echo 1 > /sys/devices/platform/dock.2/undock
logger "/sys/devices/platform/dock.2/undock"
else
echo eject > /proc/acpi/ibm/bay
fi
# Tell the user we're OK
logger "/proc/acpi/ibm/beep"
echo 12 > /proc/acpi/ibm/beep

What I discovered today after modifying ultrabay_open was that in some cases
the script is called again directly after inserting a drive to the bay. But
only, if the execution of this script takes some more time (I added a sleep 2
after the second sync to be able to see which command might trigger the bug).

So maybe yesterday this script was called twice and the kernel does not like
to undock a device while it is in the process of being undocked? How should I
modify the udev rule to prevent another execution each time a drive is
inserted into the bay?

regards,
Jörg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-06-15 09:39    [W:0.097 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site