Irritating USB Flash Memory LED behaviour (usb_storage related?)
- From: Claus Fischer <claus.fischer@xxxxxxxxxxxxxxxx>
- Date: Wed, 25 Mar 2009 17:34:41 +0100
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@xxxxxxxxxxxxxxxx>
http://www.clausfischer.com/
Attachment:
signature.asc
Description: Digital signature
- Prev by Date: Re: [tip:tracing/kmemtrace] rcutree: fix rcu_tree_trace.c data structure dependencies
- Next by Date: Re: [tip:tracing/kmemtrace] fs.h: uninline simple_transaction_set()
- Previous by thread: [PATCH -tip] x86: cpu_debug.c remove some not required header files
- Next by thread: [PATCH 2.2] CAP_FS_MASK: add CAP_LINUX_IMMUTABLE
- Index(es):
Relevant Pages
|
