public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Clemens Koller <clemens.koller@anagramm.de>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@vger.kernel.org
Subject: Re: single bit errors on files stored on USB-HDDs via USB2/usb_storage
Date: Sun, 10 Dec 2006 16:37:43 +0100	[thread overview]
Message-ID: <457C29C7.1020009@anagramm.de> (raw)
In-Reply-To: <20061210084453.13702.qmail@science.horizon.com>

Hi There!

> Now, I can imagine a USB slave controller so cheap and/or buggy that it
> doesn't check the CRC, but I'd think that most would.  Checking a CRC
> is hardly a novel challenge.

Do we have any counters in the USB Stack and the drivers which count the
USB transaction errors?
According to some datasheets (i.e. NXP ISP1563) there are bits called
USB Error and USB Error Interrupt" etc.
Are those should be implemented / counted in the driver stack somewhere?
Okay, simple question...

A quick look into ehci.h tells me that the bit inside of the kernel
is propably called STS_ERR and is used i.e. in ehci_dbg.c 's 
and printed through dbg_status_buf() and dbg_intr.buf().
Maybe it's sufficient to turn on debugging and turn the
error flag into an error counter just to get an idea if it cumulates?

Just my five cents,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19

  reply	other threads:[~2006-12-10 15:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-10  8:44 single bit errors on files stored on USB-HDDs via USB2/usb_storage linux
2006-12-10 15:37 ` Clemens Koller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-12-07 18:08 [usb-storage] " Alan Stern
2006-12-07 19:41 ` Matthias Schniedermeyer
2006-12-07 23:45   ` Pete Zaitcev
2006-12-08  9:16     ` Matthias Schniedermeyer
2006-12-08 12:21       ` Stefan Richter
2006-12-08 16:18         ` John Stoffel
     [not found] <fa./xvi+/Ji/HqNkvnGjUt4pIS9goM@ifi.uio.no>
2006-12-07  0:02 ` Robert Hancock
2006-12-07  9:03   ` Matthias Schniedermeyer
     [not found] ` <fa.nPT9ZJ5poT8fZx3aWy0MqRK/gto@ifi.uio.no>
     [not found]   ` <fa.aML3aAeWqfac08XNpQa7Zu0AC8w@ifi.uio.no>
2006-12-08  3:18     ` Robert Hancock
2006-12-08  9:07       ` Matthias Schniedermeyer
2006-12-08 10:25         ` Stefan Richter
2006-12-08 10:39           ` Matthias Schniedermeyer
2006-12-08 11:01             ` Oliver Neukum
2006-12-08 12:27               ` Stefan Richter
2006-12-09  6:11               ` Ben Nizette
2006-12-09  8:18                 ` Oliver Neukum
2006-12-09 10:16                   ` Ben Nizette
2006-12-06 22:01 Matthias Schniedermeyer
2006-12-07 22:10 ` DervishD
2006-12-07 22:57   ` Matthias Schniedermeyer
2006-12-07 23:05     ` Jan Engelhardt
2006-12-08  9:32     ` DervishD

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=457C29C7.1020009@anagramm.de \
    --to=clemens.koller@anagramm.de \
    --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