On Mon, Sep 19, 2005 at 10:19:32AM -0500, James Bottomley wrote:
> On Sun, 2005-09-18 at 15:01 -0700, Greg KH wrote:
> > Should I apply any additional patches too? Or just this one will
> > suffice?
>
> Just to make assurances doubly sure, could you remove all the scsi
> patches and just pull the
On Sun, 2005-09-18 at 15:01 -0700, Greg KH wrote:
> Should I apply any additional patches too? Or just this one will
> suffice?
Just to make assurances doubly sure, could you remove all the scsi
patches and just pull the scsi git tree at
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-f
On Sun, Sep 18, 2005 at 03:01:26PM -0700, Greg KH wrote:
> On Sun, Sep 18, 2005 at 03:05:20PM -0500, James Bottomley wrote:
> > On Sat, 2005-09-17 at 19:35 -0500, James Bottomley wrote:
> > > The attached should be that patch with the race window closed.
> >
> > There's a big oops in this one (and
On Sun, Sep 18, 2005 at 03:05:20PM -0500, James Bottomley wrote:
> On Sat, 2005-09-17 at 19:35 -0500, James Bottomley wrote:
> > The attached should be that patch with the race window closed.
>
> There's a big oops in this one (and there was when greg tested it). The
> state checker is reversed (
On Sun, 18 Sep 2005, James Bottomley wrote:
> void scsi_remove_host(struct Scsi_Host *shost)
> {
> + unsigned long flags;
> down(&shost->scan_mutex);
> - scsi_host_set_state(shost, SHOST_CANCEL);
> + spin_lock_irqsave(shost->host_lock, flags);
> + if (scsi_host_set_state(sh
On Sat, 2005-09-17 at 19:35 -0500, James Bottomley wrote:
> The attached should be that patch with the race window closed.
There's a big oops in this one (and there was when greg tested it). The
state checker is reversed (it's checking !scsi_host_set_state() for
indicating a problem ... of course
On Sat, 2005-09-17 at 22:33 -0400, Alan Stern wrote:
> > OK, I looked at making this work while reaping the target correctly, but
> > I couldn't (basic problem is that the target list keeps the target until
> > it has no more devices, a condition that could be made untrue by
> > something as simple
On Sat, 17 Sep 2005, James Bottomley wrote:
> On Thu, 2005-09-15 at 21:52 -0400, Alan Stern wrote:
> > In short, those iterations must be carried out as in my patch.
>
> OK, I looked at making this work while reaping the target correctly, but
> I couldn't (basic problem is that the target list ke
On Thu, 2005-09-15 at 21:52 -0400, Alan Stern wrote:
> In short, those iterations must be carried out as in my patch.
OK, I looked at making this work while reaping the target correctly, but
I couldn't (basic problem is that the target list keeps the target until
it has no more devices, a conditio
On Thu, 2005-09-15 at 18:38 -0400, James Bottomley wrote:
> On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> > In looking at the state model introduced by your patch I believe there may
> > still be a state model race issue if the recovery completes just after
> > the "if (!scsi_host_set_s
On Thu, 2005-09-15 at 21:52 -0400, Alan Stern wrote:
> You're forgetting something: Devices can be removed at any time, no matter
> what state the host is in. It's even possible for thread A to be removing
> a device while thread B is removing the host. The A thread will interfere
> with the B th
On Thu, 15 Sep 2005, Greg KH wrote:
> On Thu, Sep 15, 2005 at 05:08:03PM -0400, James Bottomley wrote:
> > On Thu, 2005-09-15 at 15:57 -0400, James Bottomley wrote:
> > > I haven't had time to review the eh changes, but I was going to reply to
> > > the other one (basically there's a better way to
On Thu, 15 Sep 2005, James Bottomley wrote:
> Well, I think the symptoms are racing scsi_remove_host() calls and the
> solution is to enforce the state model on removal (as in if the host is
> already in the remove state, don't try to remove it again).
You're forgetting something: Devices can be
On Thu, 2005-09-15 at 16:55 -0700, Mike Anderson wrote:
> James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> > > A side effect of not applying Alan's previous patch that added
> > > SHOST_RECOVERY to the SHOST_CANCEL: state is that we will not m
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> > A side effect of not applying Alan's previous patch that added
> > SHOST_RECOVERY to the SHOST_CANCEL: state is that we will not move to the
> > SHOST_CANCEL and subsequently not to SHOST_DEL st
On Thu, Sep 15, 2005 at 05:08:03PM -0400, James Bottomley wrote:
> On Thu, 2005-09-15 at 15:57 -0400, James Bottomley wrote:
> > I haven't had time to review the eh changes, but I was going to reply to
> > the other one (basically there's a better way to try to close the device
> > add/host remove
On Thu, 2005-09-15 at 15:19 -0700, Mike Anderson wrote:
> A side effect of not applying Alan's previous patch that added
> SHOST_RECOVERY to the SHOST_CANCEL: state is that we will not move to the
> SHOST_CANCEL and subsequently not to SHOST_DEL state if the eh is active
> during the start of scsi_
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-09-15 at 15:57 -0400, James Bottomley wrote:
> > I haven't had time to review the eh changes, but I was going to reply to
> > the other one (basically there's a better way to try to close the device
> > add/host remove race using the host st
On Thu, 2005-09-15 at 15:57 -0400, James Bottomley wrote:
> I haven't had time to review the eh changes, but I was going to reply to
> the other one (basically there's a better way to try to close the device
> add/host remove race using the host state model).
>
> Let me complete the SCSI process a
On Thu, 2005-09-15 at 12:29 -0700, Greg KH wrote:
> Ah, thanks for the pointer. SCSI developers, any objections to these
> patches being merged?
I haven't had time to review the eh changes, but I was going to reply to
the other one (basically there's a better way to try to close the device
add/ho
On Thu, Sep 15, 2005 at 03:23:11PM -0400, Alan Stern wrote:
> On Thu, 15 Sep 2005, Greg KH wrote:
>
> > Here's a nice oops I get when removing a usb-storage device with
> > 2.6.14-rc1. I've also created a bug for this for those who like to
> > track bugzilla:
> > http://bugzilla.kernel.org/sh
On Thu, 15 Sep 2005, Greg KH wrote:
> Here's a nice oops I get when removing a usb-storage device with
> 2.6.14-rc1. I've also created a bug for this for those who like to
> track bugzilla:
> http://bugzilla.kernel.org/show_bug.cgi?id=5265
>
> Any ideas?
Patches for this bug plus two othe
22 matches
Mail list logo
