[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [2.6.30] Kernel bug with dock driver
    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
    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:
    shopt -s nullglob

    if [ -d $ULTRABAY_SYSDIR ]; then
    echo 1 > $ULTRABAY_SYSDIR/delete
    logger "removed $ULTRABAY_SYSDIR"
    # 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"
    echo eject > /proc/acpi/ibm/bay
    # 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?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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