[PATCH] link scsi_debug later

[PATCH] link scsi_debug later

[Randy.Dunlap]

From: Randy Dunlap <rdunlap@xenotime.net>

Link scsi-debug driver after SATA so that scsi-debug does not
interfere with real SCSI device ordering.
Yes, I was bitten by this.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/scsi/Makefile |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2616-rc6.orig/drivers/scsi/Makefile
+++ linux-2616-rc6/drivers/scsi/Makefile
@@ -117,7 +117,6 @@ obj-$(CONFIG_SCSI_PPA)		+= ppa.o
 obj-$(CONFIG_SCSI_IMM)		+= imm.o
 obj-$(CONFIG_JAZZ_ESP)		+= NCR53C9x.o	jazz_esp.o
 obj-$(CONFIG_SUN3X_ESP)		+= NCR53C9x.o	sun3x_esp.o
-obj-$(CONFIG_SCSI_DEBUG)	+= scsi_debug.o
 obj-$(CONFIG_SCSI_FCAL)		+= fcal.o
 obj-$(CONFIG_SCSI_LASI700)	+= 53c700.o lasi700.o
 obj-$(CONFIG_SCSI_NSP32)	+= nsp32.o
@@ -140,6 +139,7 @@ obj-$(CONFIG_SCSI_SATA_MV)	+= libata.o s
 obj-$(CONFIG_SCSI_PDC_ADMA)	+= libata.o pdc_adma.o
 
 obj-$(CONFIG_ARM)		+= arm/
+obj-$(CONFIG_SCSI_DEBUG)	+= scsi_debug.o
 
 obj-$(CONFIG_CHR_DEV_ST)	+= st.o
 obj-$(CONFIG_CHR_DEV_OSST)	+= osst.o


---

Re: [PATCH] link scsi_debug later

[Andrew Morton]

"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Link scsi-debug driver after SATA so that scsi-debug does not
> interfere with real SCSI device ordering.
> Yes, I was bitten by this.
> 

What does "bitten" mean?

Is this a regression?

If so, relative to which release?

Potentially this sort of thing can have serious effects.  Like, non-booting
machines.  Is that the case here?

Is this 2.6.16 material?

Stuff like that, thanks.

Re: [PATCH] link scsi_debug later

[Randy.Dunlap]

On Fri, 17 Mar 2006 21:29:24 -0800 Andrew Morton wrote:

> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> >
> > From: Randy Dunlap <rdunlap@xenotime.net>
> > 
> > Link scsi-debug driver after SATA so that scsi-debug does not
> > interfere with real SCSI device ordering.
> > Yes, I was bitten by this.
> > 
> 
> What does "bitten" mean?

It means that I got the usual "VFS: could not find root filesystem on
device (8,8)"  (or however it is spelled).
Oh, and that I had to add netconsole to see what was causing it,
but that is easy enough to do.

> Is this a regression?

It's probably been like this ever since SATA was added (libata)
and only happens if SCSI_DEBUG=y (so I changed it to =m).
I can't say that it's a regression since this occurred on a new
machine.

> If so, relative to which release?
> 
> Potentially this sort of thing can have serious effects.  Like, non-booting
> machines.  Is that the case here?

Yes, it was.

> Is this 2.6.16 material?

Well... I would say yes, I don't think it's too risky for that.

> Stuff like that, thanks.

OK, I'll try to be more verbose in the future (on patches).

---
~Randy

Re: [PATCH] link scsi_debug later

[Douglas Gilbert]

Randy.Dunlap wrote:
> On Fri, 17 Mar 2006 21:29:24 -0800 Andrew Morton wrote:
> 
> 
>>"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>>
>>>From: Randy Dunlap <rdunlap@xenotime.net>
>>>
>>>Link scsi-debug driver after SATA so that scsi-debug does not
>>>interfere with real SCSI device ordering.
>>>Yes, I was bitten by this.
>>>
>>
>>What does "bitten" mean?
> 
> 
> It means that I got the usual "VFS: could not find root filesystem on
> device (8,8)"  (or however it is spelled).
> Oh, and that I had to add netconsole to see what was causing it,
> but that is easy enough to do.
> 
> 
>>Is this a regression?
> 
> 
> It's probably been like this ever since SATA was added (libata)
> and only happens if SCSI_DEBUG=y (so I changed it to =m).
> I can't say that it's a regression since this occurred on a new
> machine.

Ah, if scsi_debug is a module, nothing is going to
load it automatically (at least the PCI subsystem
won't load it). However if it is built in then
it will "steal" /dev/sda (if some other SCSI LLD
hasn't already got it). That would then cause
a SATA driver to get /dev/sdb ... That is enough
to cause a kernel parameter like "root=/dev/sda8"
to flounder and give the "could not find root filesystem"
error.

A regression??
Hmm.

Doug Gilbert

Re: [PATCH] link scsi_debug later

[James Bottomley]

On Sat, 2006-03-18 at 01:24 -0500, Douglas Gilbert wrote:
> Ah, if scsi_debug is a module, nothing is going to
> load it automatically (at least the PCI subsystem
> won't load it). However if it is built in then
> it will "steal" /dev/sda (if some other SCSI LLD
> hasn't already got it). That would then cause
> a SATA driver to get /dev/sdb ... That is enough
> to cause a kernel parameter like "root=/dev/sda8"
> to flounder and give the "could not find root filesystem"
> error.

Is there actually any purpose for not compiling scsi_debug as a module?
i.e. isn't the problem really that we simply shouldn't allow it to be
built directly into the kernel and it should only be compilable as a
module?

James

Re: [PATCH] link scsi_debug later

[Randy.Dunlap]

On Sat, 18 Mar 2006 07:22:44 -0600 James Bottomley wrote:

> On Sat, 2006-03-18 at 01:24 -0500, Douglas Gilbert wrote:
> > Ah, if scsi_debug is a module, nothing is going to
> > load it automatically (at least the PCI subsystem
> > won't load it). However if it is built in then
> > it will "steal" /dev/sda (if some other SCSI LLD
> > hasn't already got it). That would then cause
> > a SATA driver to get /dev/sdb ... That is enough
> > to cause a kernel parameter like "root=/dev/sda8"
> > to flounder and give the "could not find root filesystem"
> > error.
> 
> Is there actually any purpose for not compiling scsi_debug as a module?
> i.e. isn't the problem really that we simply shouldn't allow it to be
> built directly into the kernel and it should only be compilable as a
> module?

I don't see a need to be that restrictive about it.
As long as SCSI_DEBUG is last, it won't affect the device order
(boot or other devices), which is the problem IMO.

Yes, the scsi-debug device(s) could become different devices
depending on what other SCSI devices were found, so maybe someone's
scripts would have to change (scripts should be flexible :).
But that would also happen if SCSI_DEBUG=m.

Anyway, I'll let Doug/James decide.

---
~Randy

Re: [PATCH] link scsi_debug later

[Andrew Morton]

"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> On Fri, 17 Mar 2006 21:29:24 -0800 Andrew Morton wrote:
> 
>  > "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>  > >
>  > > From: Randy Dunlap <rdunlap@xenotime.net>
>  > > 
>  > > Link scsi-debug driver after SATA so that scsi-debug does not
>  > > interfere with real SCSI device ordering.
>  > > Yes, I was bitten by this.
>  > > 
>  > 
>  > What does "bitten" mean?
> 
>  It means that I got the usual "VFS: could not find root filesystem on
>  device (8,8)"  (or however it is spelled).
>  Oh, and that I had to add netconsole to see what was causing it,
>  but that is easy enough to do.
> 
>  > Is this a regression?
> 
>  It's probably been like this ever since SATA was added (libata)
>  and only happens if SCSI_DEBUG=y (so I changed it to =m).
>  I can't say that it's a regression since this occurred on a new
>  machine.

OK, thanks.  For the recond, I altered the changelog to read

  Changing CONFIG_SCSI_DEBUG from =n or =m to =y can cause the
  enumeration of the SATA devices to change.

  Fix that by linking the scsi-debug driver after the SATA drivers.

>  > Is this 2.6.16 material?
> 
>  Well... I would say yes, I don't think it's too risky for that.

Pretty much any change is risky in this kernel :(

James, your call please.

Re: [PATCH] link scsi_debug later

[Matthew Wilcox]

On Fri, Mar 17, 2006 at 10:27:38PM -0800, Andrew Morton wrote:
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> >  > Is this 2.6.16 material?
> > 
> >  Well... I would say yes, I don't think it's too risky for that.
> 
> Pretty much any change is risky in this kernel :(
> 
> James, your call please.

I'm not James, but I think it's a safe change for 2.6.16.