public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Claus Fischer <claus.fischer@clausfischer.com>
To: linux-kernel@vger.kernel.org
Subject: Irritating USB Flash Memory LED behaviour (usb_storage related?)
Date: Wed, 25 Mar 2009 17:34:41 +0100	[thread overview]
Message-ID: <20090325163441.GA17166@clausfischer.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]


Summary: Some new USB memory sticks will not stop blinking the LED.
         Behaviour varies across distributions and OS's.
         Any helpful hints appreciated.


On a system that we use for mass erasure of USB sticks (64 sticks),
based on Debian with automatical udev-handling of USB sticks disabled,
we have a problem with a batch of new USB sticks: They will continue
blinking for as long as they are plugged in, independent of data
access.

The sticks however stop blinking (as they should) on a SuSE based
desktop system with the usual KDE software. They also stop blinking
when attached to a Windows system.


Good behaviour:
***************

Previously, (good) USB sticks would behave like this:
 -  blink while the usb_storage module identifies them
    and maps them to an SCSI device
 -  then stop blinking
 -  blink again while being formatted via our script
 -  stop blinking after being unmounted
Together with a visual program display, the blinking LED has always
been a good indicator for operating personnel of the stick's status.

Bad behaviour:
**************
The new sticks will start blinking when the usb_storage module kicks
in use, and continue blinking throughout idle phases, mounts, writes,
umounts etc.; an eject command will change the blinking to
a permanently lighted LED, but it will never go off.




I'm at a loss looking for the reason of the continued blinking,
and how to get rid of it (it's a large batch of sticks, and
returning them is out of the question).

Possible causes:
 - Kernel
   But: the "good" SuSE kernel 2.6.25 is between "bad" Debian 2.6.16
   and "bad" Debian 2.6.26.
   Also, old USB sticks work fine with each machine.
 - Bad USB controller
   The new batch of sticks uses a different internal USB
   controller from old batches.
   But: Windows and SuSE work fine.
 - Interaction of KDE components with the USB stick
   that is missing on our batch formatting system.
   But: Why do old sticks work fine without such interaction?


Questions:
 - I always thought that USB stick LEDs cannot be controlled by the
   operating system. They just indicates "write accesses".
   Is that correct?
 - If USB stick leds are not OS-accessible, why do the new
   sticks behave differently on different systems?
 - If USB stick leds are OS-accessible, has there been any change
   in policy of kernel/modules that leave them blinking?
 - Can anyone point me to information how SuSE/KDE control the
   blinking light, and how I can (write code to) let the LED
   react similarly on our Debian-based batch system?
   [ For various reasons beyond the scope of this mail,
     automatically mounting the sticks is out of the question. ]


Any helpful hints, pointers to knowledge/information etc. are
greatly appreciated.

Best regards,

Claus


-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

                 reply	other threads:[~2009-03-25 16:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090325163441.GA17166@clausfischer.com \
    --to=claus.fischer@clausfischer.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox