All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Ben Collins <ben.collins@ubuntu.com>
Cc: torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.15-rc6] block: Make CDROMEJECT more robust
Date: Mon, 19 Dec 2005 21:05:34 +0100	[thread overview]
Message-ID: <20051219200533.GP3734@suse.de> (raw)
In-Reply-To: <1135022319.2029.11.camel@localhost.localdomain>

On Mon, Dec 19 2005, Ben Collins wrote:
> On Mon, 2005-12-19 at 20:35 +0100, Jens Axboe wrote:
> > On Mon, Dec 19 2005, Ben Collins wrote:
> > > This patch fixes the WRITE vs READ issue, and also sends the extra two
> > > commands. Anyone with an iPod connected via USB (not sure about firewire)
> > > should be able to reproduce this issue, and verify the patch.
> > 
> > The bug was in the SCSI layer, and James already has the fix integrated
> > for that. It really should make 2.6.15, James are you sending it upwards
> > for that?
> 
> You mean this patch?
> 
> James Bottomley:
>       [SCSI] Consolidate REQ_BLOCK_PC handling path (fix ipod panic)
> 
> This fixes an oops with data direction because sbp2 was not checking
> enough itself.
> 
> I seriously doubt this will fix the issue being reported. Changing the
> blk request to a READ did not fix the problem. The problem was only
> fixed by sending the extra two commands. The direction was just a side
> issue.

Your report surely made it seem like an issue, hence I pointed you at
the fix(es). What part of the block layer didn't like these commands?

> Is there a problem with sending the commands? If they don't bother
> unaffected devices, but it does fix a large number of other devices,
> what's the problem?

It's not necessarily a problem, especially if other paths end up doing
it in some way or another. Hard to say whether it bothers other device,
but I agree it should not. Please resend after 2.6.15 is released (and
do make those macros functions, thanks).

-- 
Jens Axboe


      reply	other threads:[~2005-12-19 20:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-19 15:32 [PATCH 2.6.15-rc6] block: Make CDROMEJECT more robust Ben Collins
2005-12-19 19:35 ` Jens Axboe
2005-12-19 19:35   ` Jens Axboe
2005-12-19 19:44   ` Ben Collins
2005-12-19 19:56     ` Jens Axboe
2005-12-19 20:27       ` Ben Collins
2005-12-19 20:46         ` Jens Axboe
2005-12-19 21:24           ` Ben Collins
2005-12-19 20:02     ` Linus Torvalds
2005-12-19 20:07       ` Jens Axboe
2005-12-19 20:37       ` Ben Collins
2005-12-19 19:58   ` Ben Collins
2005-12-19 20:05     ` Jens Axboe [this message]

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=20051219200533.GP3734@suse.de \
    --to=axboe@suse.de \
    --cc=akpm@osdl.org \
    --cc=ben.collins@ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.