public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: Hans de Goede <j.w.r.degoede@hhs.nl>
Subject: Re: [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6
Date: Mon, 17 Sep 2007 14:56:01 +0200	[thread overview]
Message-ID: <46EE7961.3050309@hhs.nl> (raw)

Hi all,

Please keep me CC-ed I'm not on the list. I just found out about this thread 
while ivnestegating some autosuspend problems, which I will describe in another 
list.

stern at rowland  wrote:
 > Linus Torvalds wrote:
 > > - US_FL_FIX_CAPACITY:
 > > This is a generic SCSI issue, not a USB one, and maybe there are
 > > better solutions to it. Are we perhaps doing something wrong? Is
 > > there some patterns we haven't seen? Why do we need this, when
 > > presumably Windows does not?
 >
 > Why doesn't Windows need this? For all we know, it does. Has anybody
 > ever tried forcing Windows to read the sector beyond the end of one of
 > these buggy devices?

I haven't but I'm pretty sure it will crash my hp usb printer (with builtin 
cardreader)

 > For one reason or another, Linux supports filesystems/partitioning
 > schemes which do need to access the last sector (EFI GUID, md, maybe
 > others). Some devices are so buggy that trying to read the nonexistent
 > "last" sector causes them to lock up, requiring a power cycle.
 > Obviously we can't probe for this sort of behavior. (There was one
 > report of a device which _could_ read its last sector correctly, but
 > only if the transfer was exactly 1 sector long! Attempts to read two
 > sectors starting from the second-to-last sector would cause it to
 > crash.)

Yes and the reporter of that one device (a HP PSC1350) would be me, I even 
wrote a patch introducing a new quirk for this (shoot me, I don't like quirks 
either, but if we can choose between making some device work and not 
introducing a quirk, I say make the device work!)

Talking about this patch (posted to the usb-storage list) I haven't received 
any feedback, any chance this patch could get integrated soon? I have found 
another Linux user with the same printer and the same problem who has 
independently verified my patch fixes it. Currently a third Linux using owner 
of such a device has contacted me, I'm waiting for his feedback if the patch 
helps him too, but I assume it will. That makes 3 users who have jumped through 
many hoops to get it to work, so there are probably many other users who have 
just given up, or even returned to that other OS!

I'm pretty sure the only reason why that other OS doesn't crash the printer is 
because it normally doesn't try to read the last sector, I haven't tried as I 
no longer have that other OS on any computer in my home.

Also I think it might be an idea to have an option to easily disable the 
partition reading code which tries to read the end of the disk, this seems to 
cause problems in various places.

Regards,

Hans


             reply	other threads:[~2007-09-18  8:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-17 12:56 Hans de Goede [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-09-18 10:39 [GIT PATCH] USB autosuspend fixes for 2.6.23-rc6 Joerg Schilling
2007-09-13 13:33 Greg KH
2007-09-13 14:52 ` Adrian Bunk
2007-09-13 15:20   ` Alan Stern
2007-09-13 15:40     ` Adrian Bunk
2007-09-13 16:07       ` Alan Stern
2007-09-13 16:34         ` Greg KH
2007-09-13 16:43         ` Linus Torvalds
2007-09-13 19:13           ` Alan Stern
2007-09-14  0:24             ` Matthew Dharm
2007-09-14 14:34               ` Alan Stern
2007-09-14  8:55             ` Jiri Kosina
2007-09-14  9:59               ` Greg KH
2007-09-13 19:26           ` Pete Zaitcev
2007-09-13 20:19         ` Adrian Bunk
2007-09-13 20:31           ` Alan Stern
2007-09-13 20:44           ` Linus Torvalds
2007-09-13 21:28             ` Adrian Bunk
2007-09-13 22:05               ` Adrian Bunk
2007-09-14  0:11                 ` Linus Torvalds
2007-09-14 13:21                   ` Mark Lord
2007-09-14 14:15                     ` Adrian Bunk
2007-09-14 14:29                 ` Alan Stern
2007-09-14 14:26               ` Alan Stern

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=46EE7961.3050309@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --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