LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>,
Oliver Neukum <oliver@neukum.org>,
Sergey Dolgov <solkaa@gmail.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: usb-storage, error reading the last 8 sectors, regression in 2.6.25-rc7
Date: Tue, 01 Apr 2008 18:26:40 +0300 [thread overview]
Message-ID: <47F25430.7070303@panasas.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0804011040260.4253-100000@iolanthe.rowland.org>
Alan Stern wrote:
> On Tue, 1 Apr 2008, Matthew Dharm wrote:
>
>> On Tue, Apr 01, 2008 at 10:28:52AM -0400, Alan Stern wrote:
>>> On Tue, 1 Apr 2008, Oliver Neukum wrote:
>>>
>>>> Am Dienstag, 1. April 2008 03:58:31 schrieb Alan Stern:
>>>>> Nevertheless, it's clear that the problem has nothing to do with the
>>>>> USB stack. The real source of the problem lies in the device itself,
>>>>> for reporting a bogus error when in fact nothing went wrong. That may
>>>>> also explain why you don't always see the problem -- sometimes the
>>>>> device works the way it ought to.
>>>> Reminds me of the devices that can read the last sector but only if it is read
>>>> by itself. Do you reckon this device may have the "opposite" quirk?
>>> Could be something like that.
>> Didn't I see some SCSI patches go by to implement exactly this change?
>> That is, only read the last sector by itself?
>
> You are getting the two problems mixed up. The older problem, which
> the SCSI patche addressed, was that the device would fail when
> accessing the last sector unless the transfer was 1 sector long.
>
> This problem is different. When performing an 8-sector read that
> includes the last sector, the device succeeds. When performing a
> 7-sector read starting from the same place (so not including the last
> sector), the device fails.
>
> Alan Stern
>
It is a different problem but it explains why it used to work in previous
kernels. 8-sector been one page.
So it is related. Looks like another black list here. Is there a sysfs
way to disable the last-sector-thing for a usb device?
Boaz
next prev parent reply other threads:[~2008-04-01 15:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-30 7:49 Sergey Dolgov
2008-03-30 18:59 ` Alan Stern
2008-03-30 22:32 ` Sergey Dolgov
2008-04-01 1:18 ` Sergey Dolgov
2008-04-01 1:58 ` Alan Stern
2008-04-01 7:38 ` Oliver Neukum
2008-04-01 14:28 ` Alan Stern
2008-04-01 14:34 ` Matthew Dharm
2008-04-01 14:42 ` Alan Stern
2008-04-01 15:26 ` Boaz Harrosh [this message]
2008-04-01 15:53 ` Matthew Dharm
2008-04-01 16:31 ` Boaz Harrosh
2008-04-01 20:24 ` Hans de Goede
2008-04-01 21:01 ` Alan Stern
2008-04-02 7:01 ` Hans de Goede
2008-04-02 14:15 ` Alan Stern
2008-04-01 16:48 ` Sergey Dolgov
2008-04-03 22:49 2.6.25-rc8-git2: Reported regressions from 2.6.24 Rafael J. Wysocki
2008-04-03 23:22 ` usb-storage, error reading the last 8 sectors, regression in 2.6.25-rc7 Rafael J. Wysocki
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=47F25430.7070303@panasas.com \
--to=bharrosh@panasas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mdharm-kernel@one-eyed-alien.net \
--cc=oliver@neukum.org \
--cc=solkaa@gmail.com \
--cc=stern@rowland.harvard.edu \
--subject='Re: usb-storage, error reading the last 8 sectors, regression in 2.6.25-rc7' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).