changes to ieee1394/sbp2 outside of linux1394.org

changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Hi linux-scsi people and linux1394 people,

there are a few changes to sbp2 in linux-2.6.13 (-rc2) that were not
merged back into the linux1394.org repository (and were not tested by
linux1394 maintainers as far as I have heard). Most of these changes
deal with TYPE_RBC devices.

Previous discussion:
 - "TYPE_RBC cache fixes (sbp2.c affected)"
   http://marc.theaimsgroup.com/?t=111620896500001

 - "Problems with Firewire and -mm kernels"
   http://marc.theaimsgroup.com/?t=111994463000003
   http://marc.theaimsgroup.com/?t=112027470800001
   http://marc.theaimsgroup.com/?t=112029841400001

I have one question for now: Is the following part of the diff related
to the TYPE_RBC issue, or is it unrelated? As you can see, locking is
removed from sbp2scsi_complete_command() but added to sbp2scsi_reset():


--- ieee1394_linux1394.org/sbp2.c	2005-07-03 12:29:55.000000000 +0200
+++ linux-2.6.13-rc2/drivers/ieee1394/sbp2.c	2005-07-06 05:46:33.000000000 +0200
@@ -2580,8 +2454,6 @@ static void sbp2scsi_complete_command(st
 				      u32 scsi_status, struct scsi_cmnd *SCpnt,
 				      void (*done)(struct scsi_cmnd *))
 {
-	unsigned long flags;
-
 	SBP2_DEBUG("sbp2scsi_complete_command");
 
 	/*
@@ -2680,11 +2552,7 @@ static void sbp2scsi_complete_command(st
 	/*
 	 * Tell scsi stack that we're done with this command
 	 */
-	spin_lock_irqsave(scsi_id->scsi_host->host_lock,flags);
 	done (SCpnt);
-	spin_unlock_irqrestore(scsi_id->scsi_host->host_lock,flags);
-
-	return;
 }
 
 
@@ -2747,7 +2616,7 @@ static int sbp2scsi_abort(struct scsi_cm
 /*
  * Called by scsi stack when something has really gone wrong.
  */
-static int sbp2scsi_reset(struct scsi_cmnd *SCpnt)
+static int __sbp2scsi_reset(struct scsi_cmnd *SCpnt)
 {
 	struct scsi_id_instance_data *scsi_id =
 		(struct scsi_id_instance_data *)SCpnt->device->host->hostdata[0];
@@ -2762,6 +2631,18 @@ static int sbp2scsi_reset(struct scsi_cm
 	return(SUCCESS);
 }
 
+static int sbp2scsi_reset(struct scsi_cmnd *SCpnt)
+{
+	unsigned long flags;
+	int rc;
+
+	spin_lock_irqsave(SCpnt->device->host->host_lock, flags);
+	rc = __sbp2scsi_reset(SCpnt);
+	spin_unlock_irqrestore(SCpnt->device->host->host_lock, flags);
+
+	return rc;
+}
+
 static const char *sbp2scsi_info (struct Scsi_Host *host)
 {
         return "SCSI emulation for IEEE-1394 SBP-2 Devices";



Thanks in advance for clarification.
-- 
Stefan Richter
-=====-=-=-= -=== -=--=
http://arcgraph.de/sr/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sat, 2005-07-09 at 14:37 +0200, Stefan Richter wrote:
> there are a few changes to sbp2 in linux-2.6.13 (-rc2) that were not
> merged back into the linux1394.org repository (and were not tested by
> linux1394 maintainers as far as I have heard). Most of these changes
> deal with TYPE_RBC devices.

That's probably because no-one knows about you: the sbp2 driver is
listed as Orphaned in the MAINTAINERS file.  You're welcome to take over
maintenance, but you need to get that file updated.

> I have one question for now: Is the following part of the diff related
> to the TYPE_RBC issue, or is it unrelated? As you can see, locking is
> removed from sbp2scsi_complete_command() but added to sbp2scsi_reset():

It's from the SCSI reset API changes, as a quick excursion into the
kernel web history viewer would have shown you:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;h=a92b7b80579fe68fe229892815c750f6652eb6a9;f=drivers/ieee1394/sbp2.c

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

If it was orphaned it was done so mistakenly. I maintain that code, and
linux1394.

Aside from that, the the change was pushed into the mainstream kernel
without going through our repository, which means it would have been
caught before going to all of our users (most of users of ieee1394 on
linux use it for sbp2).

THese changes break sbp2, and we'll need to revert them in the main stream
kernel until the patch is tested and fixed in our tree.


On Sat, Jul 09, 2005 at 10:18:26AM -0500, James Bottomley wrote:
> On Sat, 2005-07-09 at 14:37 +0200, Stefan Richter wrote:
> > there are a few changes to sbp2 in linux-2.6.13 (-rc2) that were not
> > merged back into the linux1394.org repository (and were not tested by
> > linux1394 maintainers as far as I have heard). Most of these changes
> > deal with TYPE_RBC devices.
> 
> That's probably because no-one knows about you: the sbp2 driver is
> listed as Orphaned in the MAINTAINERS file.  You're welcome to take over
> maintenance, but you need to get that file updated.
> 
> > I have one question for now: Is the following part of the diff related
> > to the TYPE_RBC issue, or is it unrelated? As you can see, locking is
> > removed from sbp2scsi_complete_command() but added to sbp2scsi_reset():
> 
> It's from the SCSI reset API changes, as a quick excursion into the
> kernel web history viewer would have shown you:
> 
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;h=a92b7b80579fe68fe229892815c750f6652eb6a9;f=drivers/ieee1394/sbp2.c
> 
> James
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> mailing list linux1394-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux1394-devel

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sat, 2005-07-09 at 12:27 -0400, Ben Collins wrote:
> THese changes break sbp2, and we'll need to revert them in the main stream
> kernel until the patch is tested and fixed in our tree.

They cannot be simply reverted.  The API has changed from the EH
routines being called with the host lock held to being called lockless.
If you need the lock, you have to take it yourself, which is what the
changes do from my reading of the code.

What's the breakage?

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

On  9 Jul, James Bottomley wrote:
> On Sat, 2005-07-09 at 12:27 -0400, Ben Collins wrote:
>> THese changes break sbp2, and we'll need to revert them in the main stream
>> kernel until the patch is tested and fixed in our tree.
> 
> They cannot be simply reverted.  The API has changed from the EH
> routines being called with the host lock held to being called lockless.
> If you need the lock, you have to take it yourself, which is what the
> changes do from my reading of the code.

The locking change is probably not an issue. I will test it ASAP and
prepare a patch for the linux1394.org repo.

(James, thanks for your explanation and pointers to the history in your
other post.)

> What's the breakage?

There was one report from a -mm tester (Rogério Brito) who needed to
revert the TYPE_RBC changes to sbp2.[ch]. Else the initial inquiry would
fail. See the link to the archive in my initial post. Summary of that
report:

-- bad inquiry with TYPE_RBC patch --
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST316002  Model: 1A                Rev: 3.06
  Type:   Unknown                            ANSI SCSI revision: 04

-- good inquiry with old sbp2 sources --
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST316002  Model: 1A                Rev: 3.06
  Type:   Direct-Access                      ANSI SCSI revision: 06
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
 sda: [mac] sda1 sda2 sda3 sda4
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

To make the matter a bit more complicated, Rogério's FireWire disk has
got another problem with the ieee1394 base driver. Rogério and I will
try to work these two (perhaps orthogonal) problems out.
-- 
Stefan Richter
-=====-=-=-= -=== -=--=
http://arcgraph.de/sr/

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sat, 2005-07-09 at 18:56 +0200, Stefan Richter wrote:
> -- bad inquiry with TYPE_RBC patch --
> ieee1394: sbp2: Logged into SBP-2 device
> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
>   Vendor: ST316002  Model: 1A                Rev: 3.06
>   Type:   Unknown                            ANSI SCSI revision: 04

Could you get a copy of the device's sysfs type file when this happens?

should be under /sys/class/scsi_device/<dev>/device/type

Thanks,

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

First of all, thank you very much for still taking this issue into
consideration.

Unfortunately, I was submitted to a surgery and only now I am recovered
enough to have access to computers (and I experienced the worst pains that
I have ever felt in my entire life this past week).

Anyway, I will still keep the data that I have on
<http://www.ime.usp.br/~rbrito/bug/> if it helps chasing the bug.

On Jul 09 2005, Stefan Richter wrote:
> On  9 Jul, James Bottomley wrote:
> > What's the breakage?
> 
> There was one report from a -mm tester (Rogério Brito) who needed to
> revert the TYPE_RBC changes to sbp2.[ch]. Else the initial inquiry would
> fail. See the link to the archive in my initial post. Summary of that
> report:
(...)
> To make the matter a bit more complicated, Rogério's FireWire disk has
> got another problem with the ieee1394 base driver. Rogério and I will
> try to work these two (perhaps orthogonal) problems out.

If you want me to experiment with anything, please let me know.

Already reporting to James the contents of
/sys/class/scsi_device/<dev>/device/type when the device isn't configured
(I'm using a -rc2-mm1 kernel here; vanilla -mm, that is), I get:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rbrito@dumont:~$ cat /sys/class/scsi_device/0\:0\:0\:0/device/type 
14
rbrito@dumont:~$ 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If anything else is important, please, don't hesitate to ask.


Thank you very much, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

Can you give the latest git tree, plus the latest linux1394 repo a try?

On Thu, Jul 14, 2005 at 09:53:09PM -0300, Rog?rio Brito wrote:
> First of all, thank you very much for still taking this issue into
> consideration.
> 
> Unfortunately, I was submitted to a surgery and only now I am recovered
> enough to have access to computers (and I experienced the worst pains that
> I have ever felt in my entire life this past week).
> 
> Anyway, I will still keep the data that I have on
> <http://www.ime.usp.br/~rbrito/bug/> if it helps chasing the bug.
> 
> On Jul 09 2005, Stefan Richter wrote:
> > On  9 Jul, James Bottomley wrote:
> > > What's the breakage?
> > 
> > There was one report from a -mm tester (Rog?rio Brito) who needed to
> > revert the TYPE_RBC changes to sbp2.[ch]. Else the initial inquiry would
> > fail. See the link to the archive in my initial post. Summary of that
> > report:
> (...)
> > To make the matter a bit more complicated, Rog?rio's FireWire disk has
> > got another problem with the ieee1394 base driver. Rog?rio and I will
> > try to work these two (perhaps orthogonal) problems out.
> 
> If you want me to experiment with anything, please let me know.
> 
> Already reporting to James the contents of
> /sys/class/scsi_device/<dev>/device/type when the device isn't configured
> (I'm using a -rc2-mm1 kernel here; vanilla -mm, that is), I get:
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> rbrito@dumont:~$ cat /sys/class/scsi_device/0\:0\:0\:0/device/type 
> 14
> rbrito@dumont:~$ 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> If anything else is important, please, don't hesitate to ask.
> 
> 
> Thank you very much, Rog?rio.
> 
> -- 
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Ben Collins wrote:
> Can you give the latest git tree, plus the latest linux1394 repo a try?
> 
> On Thu, Jul 14, 2005 at 09:53:09PM -0300, Rogério Brito wrote:
>>Already reporting to James the contents of
>>/sys/class/scsi_device/<dev>/device/type when the device isn't configured
>>(I'm using a -rc2-mm1 kernel here; vanilla -mm, that is), I get:
>>
>>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>rbrito@dumont:~$ cat /sys/class/scsi_device/0\:0\:0\:0/device/type 
>>14

This type should also appear with the latest linux1394 drivers.
sd_mod should be bound to this type now, but it must be loaded manually
or the hotplug script needs to be adapted:
http://marc.theaimsgroup.com/?m=112129844017488

Rogério, the disable_irm issue has not been addressed yet, so please
try the new code with and without this parameter. (I still intent to
find out how to make it work without that parameter.) Thanks for testing.

I hope you get well again soon.
-- 
Stefan Richter
-=====-=-=-= -=== -====
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

On Jul 15 2005, Stefan Richter wrote:
> This type should also appear with the latest linux1394 drivers.
> sd_mod should be bound to this type now, but it must be loaded manually
> or the hotplug script needs to be adapted:
> http://marc.theaimsgroup.com/?m=112129844017488

Ok, I already patched the hotplug scripts. I will post the results I get in
the next reboot.

> Rogério, the disable_irm issue has not been addressed yet, so please
> try the new code with and without this parameter. (I still intent to
> find out how to make it work without that parameter.) Thanks for testing.

I will test that and report ASAP.

> I hope you get well again soon.


Thank you very much for everything, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, Ben.

On Jul 14 2005, Ben Collins wrote:
> Can you give the latest git tree, plus the latest linux1394 repo a try?

Yes, of course I can. I already have vanilla -rc3-git2 here being compiled.
I have already checked out the linux1394 trunk (in a separate tree).

Should I replace the git ieee1394 tree with the contents of ilnux1394 tree
or should I just focus on sbp2.[ch] like I did in the previous tries?


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, all.

On Jul 14 2005, Ben Collins wrote:
> Can you give the latest git tree, plus the latest linux1394 repo a try?

Well, I just booted with a vanilla -rc3-git2 kernel with the patch to the
hotplug scripts that Stefan mentioned in an earlier e-mail and the
enclosure worked this time.

I didn't try the linux1394 trunk yet.

I just uploaded the dmesg output to <http://www.ime.usp.br/~rbrito/bug/>.


Thank you very much for the help, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

Please try with the latest trunk of our repo (just replace the direcory).

On Fri, Jul 15, 2005 at 12:53:33PM -0300, Rog?rio Brito wrote:
> Hi, all.
> 
> On Jul 14 2005, Ben Collins wrote:
> > Can you give the latest git tree, plus the latest linux1394 repo a try?
> 
> Well, I just booted with a vanilla -rc3-git2 kernel with the patch to the
> hotplug scripts that Stefan mentioned in an earlier e-mail and the
> enclosure worked this time.
> 
> I didn't try the linux1394 trunk yet.
> 
> I just uploaded the dmesg output to <http://www.ime.usp.br/~rbrito/bug/>.
> 
> 
> Thank you very much for the help, Rog?rio.
> 
> -- 
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, Ben and others.

On Jul 15 2005, Ben Collins wrote:
> Please try with the latest trunk of our repo (just replace the direcory).

I already tried this and things stopped working. :-( I put the dmesg log on
<http://www.ime.usp.br/~rbrito/bug/> anyway.

Any other things that I should try? Any printk's that I can add to help
debug this thing?


Thanks, Rogério Brito.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Fri, Jul 15, 2005 at 03:50:34PM -0300, Rog?rio Brito wrote:
> Hi, Ben and others.
> 
> On Jul 15 2005, Ben Collins wrote:
> > Please try with the latest trunk of our repo (just replace the direcory).
> 
> I already tried this and things stopped working. :-( I put the dmesg log on
> <http://www.ime.usp.br/~rbrito/bug/> anyway.

No, there are changes in the current rev of the repo. Are sure you tried
the latest rev?

> Any other things that I should try? Any printk's that I can add to help
> debug this thing?
> 
> 
> Thanks, Rog?rio Brito.
> 
> -- 
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Ben Collins wrote:
> On Fri, Jul 15, 2005 at 03:50:34PM -0300, Rogério Brito wrote:
>>I already tried this and things stopped working. :-( I put the dmesg log on
>><http://www.ime.usp.br/~rbrito/bug/> anyway.
> 
> No, there are changes in the current rev of the repo. Are sure you tried
> the latest rev?

(The latest rev from linux1394.org includes the changed TYPE_RBC handling,
i.e. has it moved out of sbp2 into the scsi drivers, plus some further
cleanups. I.e. it is close to the code which caused Rogério's first failure
report at linux-kernel about the -mm tree.)

>>Any other things that I should try? Any printk's that I can add to help
>>debug this thing?

Rogério, try "modprobe ieee1394 disable_irm=1" again, of course before
ohci1394 is loaded. Make sure that sd_mod was loaded.

If this does not help, enable scsi_print_command(...) and scsi_print_sense(...)
in sbp2scsi_complete_command(), i.e. #define CONFIG_IEEE1394_SBP2_DEBUG 1
or 2 near the beginning of sbp2.c. I assume there won't be too much resulting
SCSI traffic logged, so you could post it directly here to the lists.

Thanks,
-- 
Stefan Richter
-=====-=-=-= -=== -====
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, Stefan.

On Jul 15 2005, Stefan Richter wrote:
> Rogério, try "modprobe ieee1394 disable_irm=1" again, of course before
> ohci1394 is loaded. Make sure that sd_mod was loaded.

Ok, I tried this. Here is the relevant part of the dmesg (the whole log is
uploaded to http://www.ime.usp.br/~rbrito/bug/):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SCSI subsystem initialized
ieee1394: Initialized config rom entry `ip1394'
ieee1394: IRM functionality disabled
sbp2: $Rev: 1311 $ Ben Collins <bcollins@debian.org>
ohci1394: $Rev: 1313 $ Ben Collins <bcollins@debian.org>
PCI: Found IRQ 5 for device 0000:00:0a.0
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5]  MMIO=[db800000-db8007ff]  Max Packet=[2048]
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0011066645555ead]
ieee1394: Node added: ID:BUS[0-01:1023]  GUID[0050c501e00010e8]
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-01:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST316002  Model: 1A                Rev: 3.06
  Type:   Unknown                            ANSI SCSI revision: 06
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
 sda: [mac] sda1 sda2 sda3 sda4
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This time, I removed everything like udev and hotplug, doing things by
hand. I loaded the ohci1394 module after I loaded the sbp2 module.

The drive works this way, but the mouse (ps2) doesn't work. I don't know if
this is related to the fact that I am not using the hotplug scripts (OTOH,
I do see that the kernel has identified the mouse in the dmesg log).

> If this does not help, enable scsi_print_command(...) and 
> scsi_print_sense(...)
> in sbp2scsi_complete_command(), i.e. #define CONFIG_IEEE1394_SBP2_DEBUG 1
> or 2 near the beginning of sbp2.c. I assume there won't be too much 
> resulting SCSI traffic logged, so you could post it directly here to the
> lists.

I will try this right now with the hotplug/udev scripts back (with the
patch you mentioned) and without disable_irm.


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

On Jul 15 2005, Ben Collins wrote:
> No, there are changes in the current rev of the repo. Are sure you tried
> the latest rev?

Well, I think it is, since this is what svn tells me:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rbrito@dumont:/usr/local/media/progs$ svn co svn://svn.linux1394.org/ieee1394/trunk/ ieee1394
Checked out revision 1315.
rbrito@dumont:/usr/local/media/progs$ 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I then copied this over the ieee1394 tree of the git2 kernel and things
stopped working (but with vanilla git2, it worked).

I will now try what Stefan told me and I will report back.


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

>From your last dmesg, it appears that things are in fact working.

Are you sure that you just don't need to do modprobe sd_mod?

On Fri, Jul 15, 2005 at 10:42:25PM -0300, Rog?rio Brito wrote:
> On Jul 15 2005, Ben Collins wrote:
> > No, there are changes in the current rev of the repo. Are sure you tried
> > the latest rev?
> 
> Well, I think it is, since this is what svn tells me:
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> rbrito@dumont:/usr/local/media/progs$ svn co svn://svn.linux1394.org/ieee1394/trunk/ ieee1394
> Checked out revision 1315.
> rbrito@dumont:/usr/local/media/progs$ 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> I then copied this over the ieee1394 tree of the git2 kernel and things
> stopped working (but with vanilla git2, it worked).
> 
> I will now try what Stefan told me and I will report back.
> 
> 
> Thanks, Rog?rio.
> 
> -- 
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, Ben, Stefan and co.

On Jul 16 2005, Ben Collins wrote:
> From your last dmesg, it appears that things are in fact working.
> 
> Are you sure that you just don't need to do modprobe sd_mod?

You are right. I just modprobe'd sd_mod by hand and the device was
recognized:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ieee1394: Initialized config rom entry `ip1394'
ohci1394: $Rev: 1313 $ Ben Collins <bcollins@debian.org>
PCI: Found IRQ 5 for device 0000:00:0a.0
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5]  MMIO=[db800000-db8007ff]  Max Packet=[2048]
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0011066645555ead]
eth1394: $Rev: 1312 $ Ben Collins <bcollins@debian.org>
eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth1: link up, 10Mbps, half-duplex, lpa 0x0000
ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0050c501e00010e8]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
SCSI subsystem initialized
sbp2: $Rev: 1311 $ Ben Collins <bcollins@debian.org>
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: ST316002  Model: 1A                Rev: 3.06
  Type:   Unknown                            ANSI SCSI revision: 06
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
 sda: [mac] sda1 sda2 sda3 sda4
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I had to load sd_mod by hand, though. The hotplug scripts didn't load it
this time.


Hope this helps, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Rogério Brito wrote:
> I just modprobe'd sd_mod by hand and the device was recognized:
[...]
> ieee1394: sbp2: Logged into SBP-2 device
> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
>   Vendor: ST316002  Model: 1A                Rev: 3.06
>   Type:   Unknown                            ANSI SCSI revision: 06
> SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
[...]
> I had to load sd_mod by hand, though. The hotplug scripts didn't load it
> this time.

The .../device/type is 14, right?

In the scsi.agent patch I posted earlier I added that device number and its
association with sd_mod. However I must admit I did not test this patch in
the form that I posted since my distro uses a little different scsi.agent.

I could check your scsi.agent if you upload or post it although the necessary
addition is trivial.

But make sure hotplug is really active and not accidently disabled.
(E.g. sbp2 should be autoloaded too when ieee1394 detected an SBP-2 device.)
-- 
Stefan Richter
-=====-=-=-= -=== =----
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, Stefan.

On Jul 16 2005, Stefan Richter wrote:
> Rogério Brito wrote:
> >I just modprobe'd sd_mod by hand and the device was recognized:
> [...]
> >ieee1394: sbp2: Logged into SBP-2 device
> >ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
> >  Vendor: ST316002  Model: 1A                Rev: 3.06
> >  Type:   Unknown                            ANSI SCSI revision: 06
> >SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> [...]
> >I had to load sd_mod by hand, though. The hotplug scripts didn't load it
> >this time.
> 
> The .../device/type is 14, right?

Yes, it still is.

(...)
> I could check your scsi.agent if you upload or post it although the 
> necessary addition is trivial.

The changes you suggested are trivial indeed and hwere is what my
scsi.agent file has:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
dumont:~# grep sd_mod /etc/hotplug/scsi.agent
    0)		TYPE=disk ;	MODULES=sd_mod ;;
    7)		TYPE=mod ;	MODULES=sd_mod ;;
    14)		TYPE=rbc-disk ;  MODULE=sd_mod ;;
dumont:~# 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> But make sure hotplug is really active and not accidently disabled.

I think that it is working.

> (E.g. sbp2 should be autoloaded too when ieee1394 detected an SBP-2
> device.)

Yes, sbp2 is automatically loaded when the device is connected. But, for
some reason, the sd_mod module doesn't. :-(

I have uploaded dmesg's and lsmod's and other information to
<http://www.ime.usp.br/~rbrito/bug/>.

I think that I did it detailed enough (just after booting the system, after
plugging the device and after manually loading the sd_mod module) so that
you can see whatever is interesting.

Of course, I can provide you with any information that you think might be
useful.


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

That's exactly what we were expecting. The hotplug scripts don't recognize
TYEP_RBC just yet, but that will be resolved soon.

James, I'm wondering is there anyway to make the scsi device model setup
correct mappings internally? The Linux1394 device modules all have
mappings so they get autoloaded. We never have to change the hotplug
scripts, just add new mappings in the modules (and the modutils-scripts
pull the info out).

On Sat, Jul 16, 2005 at 01:42:02PM -0300, Rog?rio Brito wrote:
> Hi, Ben, Stefan and co.
> 
> On Jul 16 2005, Ben Collins wrote:
> > From your last dmesg, it appears that things are in fact working.
> > 
> > Are you sure that you just don't need to do modprobe sd_mod?
> 
> You are right. I just modprobe'd sd_mod by hand and the device was
> recognized:
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> ieee1394: Initialized config rom entry `ip1394'
> ohci1394: $Rev: 1313 $ Ben Collins <bcollins@debian.org>
> PCI: Found IRQ 5 for device 0000:00:0a.0
> ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5]  MMIO=[db800000-db8007ff]  Max Packet=[2048]
> ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0011066645555ead]
> eth1394: $Rev: 1312 $ Ben Collins <bcollins@debian.org>
> eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> eth1: link up, 10Mbps, half-duplex, lpa 0x0000
> ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0050c501e00010e8]
> ieee1394: Node changed: 0-00:1023 -> 0-01:1023
> SCSI subsystem initialized
> sbp2: $Rev: 1311 $ Ben Collins <bcollins@debian.org>
> scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
> ieee1394: sbp2: Logged into SBP-2 device
> ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
>   Vendor: ST316002  Model: 1A                Rev: 3.06
>   Type:   Unknown                            ANSI SCSI revision: 06
> SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> SCSI device sda: drive cache: write back
>  sda: [mac] sda1 sda2 sda3 sda4
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> I had to load sd_mod by hand, though. The hotplug scripts didn't load it
> this time.
> 
> 
> Hope this helps, Rog?rio.
> 
> -- 
> Rog?rio Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
> Homepage of the algorithms package : http://algorithms.berlios.de
> Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

On Jul 17 2005, Ben Collins wrote:
> That's exactly what we were expecting. The hotplug scripts don't
> recognize TYEP_RBC just yet, but that will be resolved soon.

Oh, right. I can test any further changes that you might have, then.


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Rogério Brito wrote:
> On Jul 17 2005, Ben Collins wrote:
> 
>>That's exactly what we were expecting. The hotplug scripts don't
>>recognize TYEP_RBC just yet, but that will be resolved soon.
> 
> Oh, right. I can test any further changes that you might have, then.

But didn't you add type 14 (RBC disk) and its association with sd_mod
to your distro's scsi.agent script already...?
-- 
Stefan Richter
-=====-=-=-= -=== =---=
http://arcgraph.de/sr/


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Stefan Richter wrote:
> Rogério Brito wrote:
> 
>> On Jul 17 2005, Ben Collins wrote:
>>
>>> That's exactly what we were expecting. The hotplug scripts don't
>>> recognize TYEP_RBC just yet, but that will be resolved soon.
>>
>>
>> Oh, right. I can test any further changes that you might have, then.
> 
> 
> But didn't you add type 14 (RBC disk) and its association with sd_mod
> to your distro's scsi.agent script already...?

Yes, I did. I'm using a patched scsi.agent as per your recommendation. I 
just thought that, perhaps, Ben had another change in mind.

But if that is all that has to be changed, then, there must be something 
incomplete somewhere, because, even though, sd_mod is associated with 
type 14 in scsi.agent, I had to load it manually to make it work with 
the linux1394 trunk. :-(

Of course, as you may expect, loading sd_mod manually is not the only 
way to get the firewire disk working. I have a small USB pen-drive (that 
I use for saving critical data) and plugging it automatically loads sd_mod.

If I, then, plug the firewire enclosure, then everything works as 
expected (as sd_mod is already loaded).

I am now slightly puzzled. BTW, I'm using Debian testing as my 
distribution, just as some extra information.


Thank you very much, Rogério.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Rogério Brito wrote:
> Stefan Richter wrote:
[sd_mod not auto-loaded]
>> But didn't you add type 14 (RBC disk) and its association with sd_mod
>> to your distro's scsi.agent script already...?
>
> Yes, I did. I'm using a patched scsi.agent as per your recommendation.
[...]
> I am now slightly puzzled.

Me too.

> BTW, I'm using Debian testing as my distribution, just as some extra
> information.

I'm on Mandrake 10.1. Maybe they have some more routines in their
hotplug scripts whose relevance for scsi hotplugging escaped me.
-- 
Stefan Richter
-=====-=-=-= --== -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Philipp Slusallek]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Hi all,

Stefan Richter wrote:
> Rogério Brito wrote:
>>Stefan Richter wrote:
>>>But didn't you add type 14 (RBC disk) and its association with sd_mod
>>>to your distro's scsi.agent script already...?
>>
>>Yes, I did. I'm using a patched scsi.agent as per your recommendation.
> 
> [...]
> 
>>I am now slightly puzzled.
> Me too.

I though everyone would notice it: There is an "S" missing in the 
rbc-disk line from Rogerio's scsi.agent file.

> The changes you suggested are trivial indeed and hwere is what my
> scsi.agent file has:
>  
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>  dumont:~# grep sd_mod /etc/hotplug/scsi.agent
>      0)		TYPE=disk ;	MODULES=sd_mod ;;
>      7)		TYPE=mod ;	MODULES=sd_mod ;;
>      14)		TYPE=rbc-disk ;  MODULE=sd_mod ;;


	Philipp

[-- Attachment #2: slusallek.vcf --]
[-- Type: text/x-vcard, Size: 418 bytes --]

begin:vcard
fn:Philipp Slusallek
n:Slusallek;Philipp
org:Saarland University;Computer Graphics Group
adr;quoted-printable:;;Im Stadtwald, Geb. 36.1;Saarbr=C3=BCcken;;66123;Germany
email;internet:slusallek@cs.uni-sb.de
title:Prof. Dr.-Ing.
tel;work:+49 681 302 3831
tel;fax:+49 681 302 3843
tel;home:+49 6897 568904
tel;cell:+49 173 659 2518
x-mozilla-html:FALSE
url:http://graphics.cs.uni-sb.de
version:2.1
end:vcard

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Philipp Slusallek wrote:
> There is an "S" missing in the rbc-disk line from Rogerio's scsi.agent file.
>>  dumont:~# grep sd_mod /etc/hotplug/scsi.agent
>>      0)        TYPE=disk ;    MODULES=sd_mod ;;
>>      7)        TYPE=mod ;    MODULES=sd_mod ;;
>>      14)        TYPE=rbc-disk ;  MODULE=sd_mod ;;

The original scsi.agent from linux-hotplug.sf.net's CVS contains a
'modprobe $MODULE'. Maybe it was called MODULES in an earlier version
of theirs or Debian saw fit to rename it for some reason.
-- 
Stefan Richter
-=====-=-=-= -=== =--=-
http://arcgraph.de/sr/


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

On Jul 18 2005, Philipp Slusallek wrote:
> Hi all,

Hi, Philipp.

> I though everyone would notice it: There is an "S" missing in the 
> rbc-disk line from Rogerio's scsi.agent file.

Good catch! I am now going to bed, but I will change that and test it as
soon as I wake up. I will report back the results that I get.


Thanks, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Rogério Brito]

Hi, all.

On Jul 18 2005, Rogério Brito wrote:
> On Jul 18 2005, Philipp Slusallek wrote:
> > I though everyone would notice it: There is an "S" missing in the 
> > rbc-disk line from Rogerio's scsi.agent file.
> 
> Good catch! I am now going to bed, but I will change that and test it as
> soon as I wake up. I will report back the results that I get.

Just reporting what I promised, indeed, the missing "S" in the scsi.agent
script was enough to make everything work with the linux1394 trunk.

Now, with the patched scsi.agent, the sd_mod actually gets loaded when I
plug the device.


Thank you very much, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Sat, Jul 09, 2005 at 11:35:01AM -0500, James Bottomley wrote:
> On Sat, 2005-07-09 at 12:27 -0400, Ben Collins wrote:
> > THese changes break sbp2, and we'll need to revert them in the main stream
> > kernel until the patch is tested and fixed in our tree.
> 
> They cannot be simply reverted.  The API has changed from the EH
> routines being called with the host lock held to being called lockless.
> If you need the lock, you have to take it yourself, which is what the
> changes do from my reading of the code.

It's not the lock change that is breaking things, it's the RBC changes.
SBP2 simply doesn't work (incorrect information read from the driver,
which I assume is bad translation of the scsi commands caused by the
changes).

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sat, 2005-07-09 at 13:49 -0400, Ben Collins wrote:
> It's not the lock change that is breaking things, it's the RBC changes.
> SBP2 simply doesn't work (incorrect information read from the driver,
> which I assume is bad translation of the scsi commands caused by the
> changes).

The RBC changes were tested out by Al Viro and seemed to work well.

The intent of the changes looks good (bringing TYPE_RBC into SCSI where
it belongs and updating sd.c to handle RBC differences), so probably
what needs to happen is that we fix whatever's broken in the current
TYPE_RBC framework.

James




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Sat, Jul 09, 2005 at 01:41:20PM -0500, James Bottomley wrote:
> On Sat, 2005-07-09 at 13:49 -0400, Ben Collins wrote:
> > It's not the lock change that is breaking things, it's the RBC changes.
> > SBP2 simply doesn't work (incorrect information read from the driver,
> > which I assume is bad translation of the scsi commands caused by the
> > changes).
> 
> The RBC changes were tested out by Al Viro and seemed to work well.
> 
> The intent of the changes looks good (bringing TYPE_RBC into SCSI where
> it belongs and updating sd.c to handle RBC differences), so probably
> what needs to happen is that we fix whatever's broken in the current
> TYPE_RBC framework.

It just may be that SBP2 doesn't work well with the changes. There's a
little bit of workarounds and massaging to get things to work on most SBP2
drives. This may be one more thing that needs some massaging.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Arjan van de Ven]

On Sat, 2005-07-09 at 12:27 -0400, Ben Collins wrote:
> If it was orphaned it was done so mistakenly. I maintain that code, and
> linux1394.
> 
> Aside from that, the the change was pushed into the mainstream kernel
> without going through our repository, which means it would have been
> caught before going to all of our users (most of users of ieee1394 on
> linux use it for sbp2).
> 
> THese changes break sbp2, and we'll need to revert them in the main stream
> kernel until the patch is tested and fixed in our tree.
> 

you can't revert the changes done to the locking really.... the API
changed. Also I can't imagine these breaking at all.

Does ieee1394 tree have a git tree that james could pull? (like akpm
pulls many trees I guess at least sbp2 should be pulled into the scsi
tree)

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Sat, Jul 09, 2005 at 06:37:10PM +0200, Arjan van de Ven wrote:
> On Sat, 2005-07-09 at 12:27 -0400, Ben Collins wrote:
> > If it was orphaned it was done so mistakenly. I maintain that code, and
> > linux1394.
> > 
> > Aside from that, the the change was pushed into the mainstream kernel
> > without going through our repository, which means it would have been
> > caught before going to all of our users (most of users of ieee1394 on
> > linux use it for sbp2).
> > 
> > THese changes break sbp2, and we'll need to revert them in the main stream
> > kernel until the patch is tested and fixed in our tree.
> > 
> 
> you can't revert the changes done to the locking really.... the API
> changed. Also I can't imagine these breaking at all.
> 
> Does ieee1394 tree have a git tree that james could pull? (like akpm
> pulls many trees I guess at least sbp2 should be pulled into the scsi
> tree)

No git tree, we've been strictly subversion lately. I may end up creating
a script to sync a git tree soon.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

On  9 Jul, Ben Collins wrote:
> If it was orphaned it was done so mistakenly. I maintain that code, and
> linux1394.

sbp2 and eth1394 have been listed as orphan since linux-2.6.12.
-- 
Stefan Richter
-=====-=-=-= -=== -=--=
http://arcgraph.de/sr/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Sat, Jul 09, 2005 at 07:00:52PM +0200, Stefan Richter wrote:
> On  9 Jul, Ben Collins wrote:
> > If it was orphaned it was done so mistakenly. I maintain that code, and
> > linux1394.
> 
> sbp2 and eth1394 have been listed as orphan since linux-2.6.12.

Can't see how the most used driver in our repo can be considered orphaned.
I'm a little irritated that the change occured. I've sent a patch to Linus
to put SBP2 back under my name.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Arjan van de Ven]

On Sat, 2005-07-09 at 13:51 -0400, Ben Collins wrote:
> On Sat, Jul 09, 2005 at 07:00:52PM +0200, Stefan Richter wrote:
> > On  9 Jul, Ben Collins wrote:
> > > If it was orphaned it was done so mistakenly. I maintain that code, and
> > > linux1394.
> > 
> > sbp2 and eth1394 have been listed as orphan since linux-2.6.12.
> 
> Can't see how the most used driver in our repo can be considered orphaned.
> I'm a little irritated that the change occured. I've sent a patch to Linus
> to put SBP2 back under my name.

did you also send him the changes you have pending in these drivers (if
any) to him ? Or maybe sbp2 should go via james since it is a scsi
driver....

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Sat, Jul 09, 2005 at 07:57:29PM +0200, Arjan van de Ven wrote:
> On Sat, 2005-07-09 at 13:51 -0400, Ben Collins wrote:
> > On Sat, Jul 09, 2005 at 07:00:52PM +0200, Stefan Richter wrote:
> > > On  9 Jul, Ben Collins wrote:
> > > > If it was orphaned it was done so mistakenly. I maintain that code, and
> > > > linux1394.
> > > 
> > > sbp2 and eth1394 have been listed as orphan since linux-2.6.12.
> > 
> > Can't see how the most used driver in our repo can be considered orphaned.
> > I'm a little irritated that the change occured. I've sent a patch to Linus
> > to put SBP2 back under my name.
> 
> did you also send him the changes you have pending in these drivers (if
> any) to him ? Or maybe sbp2 should go via james since it is a scsi
> driver....

Not yet. I will once everything is back in sync in our tree.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sat, 2005-07-09 at 12:27 -0400, Ben Collins wrote:
> If it was orphaned it was done so mistakenly. I maintain that code, and
> linux1394.

Well, it's becoming hard to interrogate BK about ancient changes now
that Larry has stopped all the tools from working.  However, with a bit
of patience and the web interface I find that Jody McIntyre did it about
six months ago.  The Commit log just says "Update ieee1934 Maintainers".

http://linux.bkbits.net:8080/linux-2.6/cset@41fea0f48hdaU1fFdS1Cb88bjsXqLA

I'm not about to get into an argument over the whys and wherefores; you
need to take this up with Linus.

James




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

Alright, I need some explanation on these changes to sbp2. Lots of things
ripped out.

I can understand that TYPE_RDC is what we had as TYPE_SDAD. Now, in our
tree for TYPE_RDC, we converted it to TYPE_DISK. We also did a lot of mode
conversions for DISK/RDC/ROM types.

My question is, why were the conversions all removed? The conversions, as
far as I know, are related to SBP protocol, and not SCSI, so why would the
SCSI maintainers feel the need to rip out an important part of the SBP2
driver? Note, this isn't really a SCSI device, or a scsi host controller.
It's a protocol translation layer.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Jeff Garzik]

On Sat, Jul 09, 2005 at 07:06:56PM -0400, Ben Collins wrote:
> I can understand that TYPE_RDC is what we had as TYPE_SDAD. Now, in our
> tree for TYPE_RDC, we converted it to TYPE_DISK. We also did a lot of mode
> conversions for DISK/RDC/ROM types.

This isn't correct.

RBC is a separate, valid disk type defined by the SCSI T10 committee.
It has its own spec.  Of course, SBP2 isn't wholly RBC compliant, even
though it reports itself as an RBC device.


> My question is, why were the conversions all removed? The conversions, as
> far as I know, are related to SBP protocol, and not SCSI, so why would the
> SCSI maintainers feel the need to rip out an important part of the SBP2
> driver?

It's a standard conversion that we've been ripping out of all drivers,
because it is unnecessary.

I understand you're a bit hacked off by all these changes occurring, but
how about debugging the failure you're seeing, before ripping out stuff?
"doesn't work at all" is untrue.  So who are the failure cases, and what
makes them different from the working case(s)?

	Jeff

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

> > My question is, why were the conversions all removed? The conversions, as
> > far as I know, are related to SBP protocol, and not SCSI, so why would the
> > SCSI maintainers feel the need to rip out an important part of the SBP2
> > driver?
> 
> It's a standard conversion that we've been ripping out of all drivers,
> because it is unnecessary.
> 
> I understand you're a bit hacked off by all these changes occurring, but
> how about debugging the failure you're seeing, before ripping out stuff?
> "doesn't work at all" is untrue.  So who are the failure cases, and what
> makes them different from the working case(s)?

I'm not a SCSI expert, so at first glance, the changes seemed to be a
little far streching. I can see that isn't the case though.

However, since SBP2 may not be fully compliant, it would seem we may not
be able to use this standard conversion policy.

I would have to say that it isn't working for a lot of people. Why does
our code work for everything, but the scsi code only work for some ppl?
Atleast I can say that where things are broken, our code fixes it, and
where things are working, our code also works. It would seem our code has
a workaround for the cases where the scsi code doesn't.

One thing that stands out is that we have a bit of code that changed the
device type from TYPE_RBC to TYPE_DISK in the command structure. Since I
didn't write this code, I can't really say why that is.  Any ideas what
that was trying to accomplish? I've attached the changes here, so you can
see what our code did and maybe make some sense of it.

I honestly thing that our code was removed in an attempt to replace it
with some common code, perhaps without fully understanding what it may
have done special. I have to say, after looking at the scsi code that
replaces the sbp2 code, I can't see a hole lot of similarity.


diff -urN -x .svn drivers/ieee1394-git/sbp2.c drivers/ieee1394/sbp2.c
--- drivers/ieee1394-git/sbp2.c	2005-07-05 23:46:33.000000000 -0400
+++ drivers/ieee1394/sbp2.c	2005-07-09 19:22:45.870920869 -0400
@@ -2112,6 +2112,102 @@
  */
 static void sbp2_check_sbp2_command(struct scsi_id_instance_data *scsi_id, unchar *cmd)
 {
+	unchar new_cmd[16];
+	u8 device_type = SBP2_DEVICE_TYPE (scsi_id->sbp2_device_type_and_lun);
+
+	SBP2_DEBUG("sbp2_check_sbp2_command");
+
+	switch (*cmd) {
+
+		case READ_6:
+
+			if (sbp2_command_conversion_device_type(device_type)) {
+
+				SBP2_DEBUG("Convert READ_6 to READ_10");
+
+				/*
+				 * Need to turn read_6 into read_10
+				 */
+				new_cmd[0] = 0x28;
+				new_cmd[1] = (cmd[1] & 0xe0);
+				new_cmd[2] = 0x0;
+				new_cmd[3] = (cmd[1] & 0x1f);
+				new_cmd[4] = cmd[2];
+				new_cmd[5] = cmd[3];
+				new_cmd[6] = 0x0;
+				new_cmd[7] = 0x0;
+				new_cmd[8] = cmd[4];
+				new_cmd[9] = cmd[5];
+
+				memcpy(cmd, new_cmd, 10);
+
+			}
+
+			break;
+
+		case WRITE_6:
+
+			if (sbp2_command_conversion_device_type(device_type)) {
+
+				SBP2_DEBUG("Convert WRITE_6 to WRITE_10");
+
+				/*
+				 * Need to turn write_6 into write_10
+				 */
+				new_cmd[0] = 0x2a;
+				new_cmd[1] = (cmd[1] & 0xe0);
+				new_cmd[2] = 0x0;
+				new_cmd[3] = (cmd[1] & 0x1f);
+				new_cmd[4] = cmd[2];
+				new_cmd[5] = cmd[3];
+				new_cmd[6] = 0x0;
+				new_cmd[7] = 0x0;
+				new_cmd[8] = cmd[4];
+				new_cmd[9] = cmd[5];
+
+				memcpy(cmd, new_cmd, 10);
+
+			}
+
+			break;
+
+		case MODE_SENSE:
+
+			if (sbp2_command_conversion_device_type(device_type)) {
+
+				SBP2_DEBUG("Convert MODE_SENSE_6 to MODE_SENSE_10");
+
+				/*
+				 * Need to turn mode_sense_6 into mode_sense_10
+				 */
+				new_cmd[0] = 0x5a;
+				new_cmd[1] = cmd[1];
+				new_cmd[2] = cmd[2];
+				new_cmd[3] = 0x0;
+				new_cmd[4] = 0x0;
+				new_cmd[5] = 0x0;
+				new_cmd[6] = 0x0;
+				new_cmd[7] = 0x0;
+				new_cmd[8] = cmd[4];
+				new_cmd[9] = cmd[5];
+
+				memcpy(cmd, new_cmd, 10);
+
+			}
+
+			break;
+
+		case MODE_SELECT:
+
+			/*
+			 * TODO. Probably need to change mode select to 10 byte version
+			 */
+
+		default:
+			break;
+	}
+
+	return;
 }
 
 /*
@@ -2152,6 +2248,7 @@
 				     struct scsi_cmnd *SCpnt)
 {
 	u8 *scsi_buf = SCpnt->request_buffer;
+	u8 device_type = SBP2_DEVICE_TYPE (scsi_id->sbp2_device_type_and_lun);
 
 	SBP2_DEBUG("sbp2_check_sbp2_response");
 
@@ -2176,6 +2273,14 @@
 			}
 
 			/*
+			 * Check for Simple Direct Access Device and change it to TYPE_DISK
+			 */
+			if ((scsi_buf[0] & 0x1f) == TYPE_RBC) {
+				SBP2_DEBUG("Changing TYPE_RBC to TYPE_DISK");
+				scsi_buf[0] &= 0xe0;
+			}
+
+			/*
 			 * Fix ansi revision and response data format
 			 */
 			scsi_buf[2] |= 2;
@@ -2183,6 +2288,27 @@
 
 			break;
 
+		case MODE_SENSE:
+
+			if (sbp2_command_conversion_device_type(device_type)) {
+
+				SBP2_DEBUG("Modify mode sense response (10 byte version)");
+
+				scsi_buf[0] = scsi_buf[1];	/* Mode data length */
+				scsi_buf[1] = scsi_buf[2];	/* Medium type */
+				scsi_buf[2] = scsi_buf[3];	/* Device specific parameter */
+				scsi_buf[3] = scsi_buf[7];	/* Block descriptor length */
+				memcpy(scsi_buf + 4, scsi_buf + 8, scsi_buf[0]);
+			}
+
+			break;
+
+		case MODE_SELECT:
+
+			/*
+			 * TODO. Probably need to change mode select to 10 byte version
+			 */
+
 		default:
 			break;
 	}
@@ -2559,8 +2685,7 @@
 static int sbp2scsi_slave_configure (struct scsi_device *sdev)
 {
 	blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
-	sdev->use_10_for_rw = 1;
-	sdev->use_10_for_ms = 1;
+
 	return 0;
 }
 

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sun, 2005-07-10 at 00:36 -0400, Ben Collins wrote:
> I would have to say that it isn't working for a lot of people. Why does
> our code work for everything, but the scsi code only work for some ppl?
> Atleast I can say that where things are broken, our code fixes it, and
> where things are working, our code also works. It would seem our code has
> a workaround for the cases where the scsi code doesn't.

Could we have a few bug reports to try to diagnose, please?

> One thing that stands out is that we have a bit of code that changed the
> device type from TYPE_RBC to TYPE_DISK in the command structure. Since I
> didn't write this code, I can't really say why that is.  Any ideas what
> that was trying to accomplish? I've attached the changes here, so you can
> see what our code did and maybe make some sense of it.
> 
> I honestly thing that our code was removed in an attempt to replace it
> with some common code, perhaps without fully understanding what it may
> have done special. I have to say, after looking at the scsi code that
> replaces the sbp2 code, I can't see a hole lot of similarity.

What the code you attached does is

1) Convert READ_6 and WRITE_6 into READ_10 and WRITE_10 (RBC devices
only use 10 byte commands).  The equivalent functionality is achieved by
setting sdev->use_10_for_rw in slave configure.

2) Convert MODE_SENSE into MODE_SENSE_10.  The equivalent functionality
is achieved by setting sdev->use_10_for_ms in slave configure.

3) Massage the value of MODE_SENSE_10 returns slightly.  RBC devices
have a few small differences in the way they present mode sense
information.  The changes in sd.c account for this.

So, for RBC devices, the changes look equivalent.

The only possibility for a problem might be that the code you quote
massages the MODE_SENSE data for every device, whereas the SCSI changes
only do it for RBC devices ... are the devices reporting difficulties
non-RBC?

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

> The only possibility for a problem might be that the code you quote
> massages the MODE_SENSE data for every device, whereas the SCSI changes
> only do it for RBC devices ... are the devices reporting difficulties
> non-RBC?

Ah, this function wasn't in the patch:

static __inline__ int sbp2_command_conversion_device_type(u8 device_type)
{
        return (((device_type == TYPE_DISK) ||
                 (device_type == TYPE_SDAD) ||
                 (device_type == TYPE_ROM)) ? 1:0);
}

I didn't see that the scsi code made a distinction here. I thought it did
the conversion for all devices if use_10_for_{rw,ms} was set, and did the
fallback when it got ILLEGAL_REQUEST. Is there something in there that
will disable use_10_for_{rw,ms} if it's not TYPE_RBC?


Ok, I see something different in the MODE_SENSE:

drivers/scsi/scsi_lib.c(__scsi_mode_sense):1579

        memset(data, 0, sizeof(*data));
        memset(&cmd[0], 0, 12);
        cmd[1] = dbd & 0x18;    /* allows DBD and LLBA bits */
        cmd[2] = modepage;

For TYPE_RBC, scsi sets modepage to 6 (drivers/scsi/sd.c:1384), which is
normally 8 for all other devices.  However, the sbp2 translation did not
change the modepage:

	SBP2_DEBUG("Convert MODE_SENSE_6 to MODE_SENSE_10");

	new_cmd[0] = 0x5a;
	new_cmd[1] = cmd[1];
	new_cmd[2] = cmd[2];
	...

Looking the pre TYPE_RBC code, I can see that the modepage change wasn't
there, so sure enough we were using 8. Could this cause an
ILLEGAL_REQUEST, and thus disable use_10_for_{rw,ms}?

I'm starting to understand some of the code paths here. So before all of
this, TYPE_RBC was not recognized by the scsi layer as a "disk" type
device (which is why sbp2 forced TYPE_DISK for TYPE_RDC devices when
commands passed into the scsi layer).


-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sun, 2005-07-10 at 11:58 -0400, Ben Collins wrote:
> I didn't see that the scsi code made a distinction here. I thought it did
> the conversion for all devices if use_10_for_{rw,ms} was set, and did the
> fallback when it got ILLEGAL_REQUEST. Is there something in there that
> will disable use_10_for_{rw,ms} if it's not TYPE_RBC?

It doesn't.  As you say, the flags are universal for the device,
whatever the ULD is.  However, as you also say, if MS_10 fails with
ILLEGAL_REQUEST we do fall back to MS_6.

> Ok, I see something different in the MODE_SENSE:
[...]
> Looking the pre TYPE_RBC code, I can see that the modepage change wasn't
> there, so sure enough we were using 8. Could this cause an
> ILLEGAL_REQUEST, and thus disable use_10_for_{rw,ms}?

Yes, that was the core of the bug Al was fixing.  sd has been requesting
caching data for a while now.  However, for RBC devices it was probing
the wrong mode page and failing.  After the changes we actually get the
correct caching data.

> I'm starting to understand some of the code paths here. So before all of
> this, TYPE_RBC was not recognized by the scsi layer as a "disk" type
> device (which is why sbp2 forced TYPE_DISK for TYPE_RDC devices when
> commands passed into the scsi layer).

Exactly, but trying to pretend they were true TYPE_DISK was also causing
issues (most notably the cache problem).

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

> > Looking the pre TYPE_RBC code, I can see that the modepage change wasn't
> > there, so sure enough we were using 8. Could this cause an
> > ILLEGAL_REQUEST, and thus disable use_10_for_{rw,ms}?
> 
> Yes, that was the core of the bug Al was fixing.  sd has been requesting
> caching data for a while now.  However, for RBC devices it was probing
> the wrong mode page and failing.  After the changes we actually get the
> correct caching data.

Well, what I was asking was that since we were working with modepage=8,
could the switch to modepage=6 with the new code be causing our problems?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

James Bottomley wrote:
> Could we have a few bug reports to try to diagnose, please?

I tested sbp2 with the logic as presently in 2.6.13-rc2 and added
printks everywhere where linux1394.org's old code would do a conversion.
The result:

DViCO Momobay FX-3A 3.5" HDD, based on TSB42AA9A bridge
-------------------------------------------------------
Jul 10 18:30:15 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 18:30:15 shuttle kernel: ieee1394: sbp2: Node 1-00:1023: Using 36byte inquiry workaround
Jul 10 18:30:16 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 18:30:17 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case INQUIRY, TYPE_RBC
Jul 10 18:30:17 shuttle kernel:   Vendor:  DViCO    Model: MOMOBAY FX-3A     Rev: REV1
Jul 10 18:30:17 shuttle kernel:   Type:   Unknown                            ANSI SCSI revision: 02

Then silence.

$ cat /sys/bus/scsi/devices/*/type
14

Side note: The FX-3A does not really need the inquiry workaround. It is just
matched like a Momobay CX-1 in sbp2's workarounds section. But the inquiry
hack is harmless when applied on the FX-3A.

DViCO Momobay CX-1 2.5" HDD, based on TSB42AA9 bridge
-----------------------------------------------------
Jul 10 19:15:16 shuttle kernel: scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 19:15:16 shuttle kernel: ieee1394: sbp2: Node 1-00:1023: Using 36byte inquiry workaround
Jul 10 19:15:18 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 19:15:18 shuttle kernel:   Vendor: "DViCO"   Model: MOMOBAY CX-1      Rev: REV2
Jul 10 19:15:18 shuttle kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jul 10 19:15:19 shuttle scsi.agent: disk at /devices/pci0000:00/0000:00:0c.0/fw-host1/0001041010004beb/0001041010004beb-0/host1/target1:0:0/1:0:0:0
Jul 10 19:15:19 shuttle kernel: SCSI device sda: 19640880 512-byte hdwr sectors (10056 MB)
Jul 10 19:15:19 shuttle kernel: sda: asking for cache data failed
Jul 10 19:15:19 shuttle kernel: sda: assuming drive cache: write through
Jul 10 19:15:19 shuttle kernel: SCSI device sda: 19640880 512-byte hdwr sectors (10056 MB)
Jul 10 19:15:19 shuttle kernel: sda: asking for cache data failed
Jul 10 19:15:19 shuttle kernel: sda: assuming drive cache: write through
Jul 10 19:15:19 shuttle kernel:  sda: sda1 sda2
Jul 10 19:15:19 shuttle kernel: Attached scsi disk sda at scsi1, channel 0, id 0, l

$ cat /sys/bus/scsi/devices/*/type
0

fdisk -l and hdparm -tT work flawlessly.

MacPower IceCube 800 3.5" HDD, based on OXUF922
-----------------------------------------------
Jul 10 19:25:32 shuttle kernel: scsi2 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case INQUIRY, TYPE_RBC
Jul 10 19:25:33 shuttle kernel:   Vendor: ST340083  Model: 2A                Rev: 3.01
Jul 10 19:25:33 shuttle kernel:   Type:   Unknown                            ANSI SCSI revision: 06
Jul 10 19:25:33 shuttle kernel: SCSI device sda: 781422768 512-byte hdwr sectors (400088 MB)
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_command: case MODE_SENSE, conversion device type
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case MODE_SENSE, TYPE_DISK or TYPE_RBC or TYPE_ROM
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_command: case MODE_SENSE, conversion device type
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case MODE_SENSE, TYPE_DISK or TYPE_RBC or TYPE_ROM
Jul 10 19:25:33 shuttle kernel: SCSI device sda: drive cache: write back
Jul 10 19:25:33 shuttle kernel: SCSI device sda: 781422768 512-byte hdwr sectors (400088 MB)
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_command: case MODE_SENSE, conversion device type
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case MODE_SENSE, TYPE_DISK or TYPE_RBC or TYPE_ROM
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_command: case MODE_SENSE, conversion device type
Jul 10 19:25:33 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case MODE_SENSE, TYPE_DISK or TYPE_RBC or TYPE_ROM
Jul 10 19:25:33 shuttle kernel: SCSI device sda: drive cache: write back
Jul 10 19:25:33 shuttle kernel:  sda: sda1
Jul 10 19:25:33 shuttle kernel: Attached scsi disk sda at scsi2, channel 0, id 0, lun 0

$ cat /sys/bus/scsi/devices/*/type
14

fdisk -l and hdparm -tT work flawlessly. sbp2_check_sbp2_command and
sbp2_check_sbp2_response are not logged while fdisk and hdparm access
the disk.


More data from other devices including CD-RWs (and from FX-3A without inquiry
hack) will follow later. Must reboot for some reason now.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sun, 2005-07-10 at 19:34 +0200, Stefan Richter wrote:
> Jul 10 18:30:17 shuttle kernel:   Type:   Unknown                            ANSI SCSI revision: 02

Sorry, that's expected: I had a patch that would identify it as RBC, but
there was another different one from someone else, and neither got
applied.  Can you try this:

http://sourceforge.net/mailarchive/message.php?msg_id=11828307

> Then silence.

Hmm, it sounds like the driver's not binding.  If you do a

ls -l /sys/class/scsi_device/<device>/device/driver

On this, do you see anything (it should be a link to the bound driver).

If there's nothing there, it sounds like sd.c is missing the RBC
attachment code, which was this hunk of the patch:

  @@ -1533,7 +1551,7 @@
  	int error;
  
  	error = -ENODEV;
 -	if ((sdp->type != TYPE_DISK) && (sdp->type != TYPE_MOD))
 +	if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != TYPE_RBC)
  		goto out;
  
  	SCSI_LOG_HLQUEUE(3, printk("sd_attach: scsi device: <%d,%d,%d,%d>\n", 

Could you check that that's in sd.c

Thanks,

James




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

James Bottomley wrote:
> On Sun, 2005-07-10 at 19:34 +0200, Stefan Richter wrote:
>>Jul 10 18:30:17 shuttle kernel:   Type:   Unknown                            ANSI SCSI revision: 02
> 
> Sorry, that's expected: I had a patch that would identify it as RBC, but
> there was another different one from someone else, and neither got
> applied.  Can you try this:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=11828307

Yes, the type is logged as Direct-Access-RBC with that addition.

>>Then silence.
> 
> Hmm, it sounds like the driver's not binding.  If you do a
> 
> ls -l /sys/class/scsi_device/<device>/device/driver
> 
> On this, do you see anything (it should be a link to the bound driver).

"driver" does not exist. But the solution is too simple to be obvious:
# modprobe sd_mod
is followed by
Jul 10 21:45:14 shuttle kernel: SCSI device sda: 585940320 512-byte hdwr sectors (300001 MB)
Jul 10 21:45:14 shuttle kernel: SCSI device sda: drive cache: write back
Jul 10 21:45:14 shuttle kernel: SCSI device sda: 585940320 512-byte hdwr sectors (300001 MB)
Jul 10 21:45:14 shuttle kernel: SCSI device sda: drive cache: write back
Jul 10 21:45:14 shuttle kernel:  sda: sda1
Jul 10 21:45:14 shuttle kernel: Attached scsi disk sda at scsi1, channel 0, id 0, lun 0

So I added a mapping from type # 14 to TYPE_RBC and sd_mod to
/etc/hotplug/scsi.agent and it's back to normal. fdisk -l and hdparm -tT
play well.

And while they access the disk, no log notices come from sbp2 from the
points where conversions occured in the former code. (Only the initial
inquiry before sd_mod's attachment is logged as a former case for
conversion.)

> If there's nothing there, it sounds like sd.c is missing the RBC
> attachment code, which was this hunk of the patch:
> 
>   @@ -1533,7 +1551,7 @@
>   	int error;
>   
>   	error = -ENODEV;
>  -	if ((sdp->type != TYPE_DISK) && (sdp->type != TYPE_MOD))
>  +	if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != TYPE_RBC)
>   		goto out;
>   
>   	SCSI_LOG_HLQUEUE(3, printk("sd_attach: scsi device: <%d,%d,%d,%d>\n", 
> 
> Could you check that that's in sd.c

sd.c contains the line with TYPE_RBC.

Alas, at least two problems remain:

  - Suddenly, the other problem reappeared. When I disconnect the disk,
    scsi_eh_0 stays there even though I am running the scsi_device_put
    modification in sbp2 (which helped before). This is accompanied by
    ieee1394's knodemgrd falling into D state.

  - As written in the other post, one of my 2.5" disks lets the system
    reboot shortly after the disk was attached. I have to find a way to
    identify the point of failure.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

So you're saying that generally, everything is working ok now, atleast
where RBC is concerned?

I wonder if the hotplug issue has been our problem all along. What you are
describing sounds an aweful lot like what everyone was describing. The
error cases showing the "Unknown" in the dmesg output compared to the
original "Disk", which at first glance looked like things weren't being
read right from the disk (wrong type, so sd wasn't probing it).

So the sd driver doesn't implement something for the driver model to
autoload it when it picks up a known type, without /etc/hotplug/scsi.agent
entries?

Thanks for tracking this Stefan.

On Sun, Jul 10, 2005 at 10:13:37PM +0200, Stefan Richter wrote:
> James Bottomley wrote:
> >On Sun, 2005-07-10 at 19:34 +0200, Stefan Richter wrote:
> >>Jul 10 18:30:17 shuttle kernel:   Type:   Unknown                         
> >>ANSI SCSI revision: 02
> >
> >Sorry, that's expected: I had a patch that would identify it as RBC, but
> >there was another different one from someone else, and neither got
> >applied.  Can you try this:
> >
> >http://sourceforge.net/mailarchive/message.php?msg_id=11828307
> 
> Yes, the type is logged as Direct-Access-RBC with that addition.
> 
> >>Then silence.
> >
> >Hmm, it sounds like the driver's not binding.  If you do a
> >
> >ls -l /sys/class/scsi_device/<device>/device/driver
> >
> >On this, do you see anything (it should be a link to the bound driver).
> 
> "driver" does not exist. But the solution is too simple to be obvious:
> # modprobe sd_mod
> is followed by
> Jul 10 21:45:14 shuttle kernel: SCSI device sda: 585940320 512-byte hdwr 
> sectors (300001 MB)
> Jul 10 21:45:14 shuttle kernel: SCSI device sda: drive cache: write back
> Jul 10 21:45:14 shuttle kernel: SCSI device sda: 585940320 512-byte hdwr 
> sectors (300001 MB)
> Jul 10 21:45:14 shuttle kernel: SCSI device sda: drive cache: write back
> Jul 10 21:45:14 shuttle kernel:  sda: sda1
> Jul 10 21:45:14 shuttle kernel: Attached scsi disk sda at scsi1, channel 0, 
> id 0, lun 0
> 
> So I added a mapping from type # 14 to TYPE_RBC and sd_mod to
> /etc/hotplug/scsi.agent and it's back to normal. fdisk -l and hdparm -tT
> play well.
> 
> And while they access the disk, no log notices come from sbp2 from the
> points where conversions occured in the former code. (Only the initial
> inquiry before sd_mod's attachment is logged as a former case for
> conversion.)
> 
> >If there's nothing there, it sounds like sd.c is missing the RBC
> >attachment code, which was this hunk of the patch:
> >
> >  @@ -1533,7 +1551,7 @@
> >  	int error;
> >  
> >  	error = -ENODEV;
> > -	if ((sdp->type != TYPE_DISK) && (sdp->type != TYPE_MOD))
> > +	if (sdp->type != TYPE_DISK && sdp->type != TYPE_MOD && sdp->type != 
> > TYPE_RBC)
> >  		goto out;
> >  
> >  	SCSI_LOG_HLQUEUE(3, printk("sd_attach: scsi device: 
> >  	<%d,%d,%d,%d>\n", 
> >Could you check that that's in sd.c
> 
> sd.c contains the line with TYPE_RBC.
> 
> Alas, at least two problems remain:
> 
>  - Suddenly, the other problem reappeared. When I disconnect the disk,
>    scsi_eh_0 stays there even though I am running the scsi_device_put
>    modification in sbp2 (which helped before). This is accompanied by
>    ieee1394's knodemgrd falling into D state.
> 
>  - As written in the other post, one of my 2.5" disks lets the system
>    reboot shortly after the disk was attached. I have to find a way to
>    identify the point of failure.
> -- 
> Stefan Richter
> -=====-=-=-= -=== -=-=-
> http://arcgraph.de/sr/
> 

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

Ben Collins wrote:
> So you're saying that generally, everything is working ok now, atleast
> where RBC is concerned?

Yes and no. The command and response conversions as they are now done
by scsi seem to work.

After the FX-3A I tried also the IceCube 800 which works too. Could
not try the IceCube 400 yet.

> So the sd driver doesn't implement something for the driver model to
> autoload it when it picks up a known type, without /etc/hotplug/scsi.agent
> entries?

Seems to be the case. And the last official hotplug scripts release
maps type 14 to "enclosure" and to no module.

> On Sun, Jul 10, 2005 at 10:13:37PM +0200, Stefan Richter wrote:
...
>> - Suddenly, the other problem reappeared. When I disconnect the disk,
>>   scsi_eh_0 stays there even though I am running the scsi_device_put
>>   modification in sbp2 (which helped before). This is accompanied by
>>   ieee1394's knodemgrd falling into D state.

Knodemgrd hanging in D state has _sometimes_ happened with older kernels
too. At the moment it looks suspiciously like it always happens (with
the new sbp2 code) if I disconnect a TYPE_RBC device, but it might be
mere coincidence. Anyway, there is obviously still some deadlock in device
management somewhere. I will try to find out whether that can happen with
1394 hardware other than SBP-2 too but it will take some time.

>> - As written in the other post, one of my 2.5" disks lets the system
>>   reboot shortly after the disk was attached. I have to find a way to
>>   identify the point of failure.

I let syslogd log synchronously and added
	printk(KERN_NOTICE "--- sleep 1s ---\n");
	msleep_interruptible(1000);
right at the end of print_inquiry() in scsi_scan.c. Yields:

Jul 10 22:32:26 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 22:32:26 shuttle kernel: ieee1394: sbp2: Node 1-00:1023: Using 36byte inquiry workaround
Jul 10 22:32:27 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 22:32:27 shuttle kernel:   Vendor: Initio    Model: IC25N080ATMR04-0  Rev: 2.18
Jul 10 22:32:27 shuttle kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jul 10 22:33:28 shuttle syslogd 1.4.1: restart.

Maybe the MODE_SENSE response needs to be mangled for this device as if
it was an RBC device. (But remember, my older 2.5" disk says it's
Direct-Access and it worked without MODE_SENSE response conversion.)

Can unexpected MODE_SENSE responses lead to a reboot?

Furthermore, I never noticed before that this disk also triggers the 36byte
inquiry workaround. I will try it without the workaround.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

I wrote:
> Ben Collins wrote:
>> So you're saying that generally, everything is working ok now, atleast
>> where RBC is concerned?
> 
> Yes and no. The command and response conversions as they are now done
> by scsi seem to work.
> 
> After the FX-3A I tried also the IceCube 800 which works too. Could
> not try the IceCube 400 yet.

IceCube 400 is OK too, so all the three disks of mine that claim to be
TYPE_RBC work (...WRT the new command and response conversion code
path).

>>> - As written in the other post, one of my 2.5" disks lets the system
>>>   reboot shortly after the disk was attached. I have to find a way to
>>>   identify the point of failure.
...
> Jul 10 22:32:26 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
> Jul 10 22:32:26 shuttle kernel: ieee1394: sbp2: Node 1-00:1023: Using 36byte inquiry workaround
> Jul 10 22:32:27 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
> Jul 10 22:32:27 shuttle kernel:   Vendor: Initio    Model: IC25N080ATMR04-0  Rev: 2.18
> Jul 10 22:32:27 shuttle kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
> Jul 10 22:33:28 shuttle syslogd 1.4.1: restart.
> 
> Maybe the MODE_SENSE response needs to be mangled for this device as if
> it was an RBC device. (But remember, my older 2.5" disk says it's
> Direct-Access and it worked without MODE_SENSE response conversion.)

No difference with sbp2's former MODE_SENSE conversion put back into
sbp2_check_sbp2_response().

> Can unexpected MODE_SENSE responses lead to a reboot?
> 
> Furthermore, I never noticed before that this disk also triggers the 36byte
> inquiry workaround. I will try it without the workaround.

As to be expected, no difference without that workaround.

I will try to get nearer the point of failure during the week.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

(summary) Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

To wrap it up for today...:
>> Ben Collins wrote:
>>> So you're saying that generally, everything is working ok now,
>>> atleast where RBC is concerned?
...
> all the three disks of mine that claim to be  TYPE_RBC work
> (...WRT the new command and response conversion code path).

And as mentioned, all of my three TYPE_ROM and one out of two
TYPE_DISK devices do work. The hotplug scripts should be made
aware of the new TYPE_RBC though.

The one TYPE_DISK that does not work fails catastrophically:
The system reboots shortly after the initial inquiry.
-- 
Stefan Richter
-=====-=-=-= -=== -=-==
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

I wrote:
>>>> - As written in the other post, one of my 2.5" disks lets the system
>>>>   reboot shortly after the disk was attached.
>>
>> Maybe the MODE_SENSE response needs to be mangled for this device as if
>> it was an RBC device. (But remember, my older 2.5" disk says it's
>> Direct-Access and it worked without MODE_SENSE response conversion.)
> 
> No difference with sbp2's former MODE_SENSE conversion put back into
> sbp2_check_sbp2_response().

I tested again with all conversions reactivated in sbp2 and with
sdev->use_10_for_rw = 1, sdev->use_10_for_ms = 1 removed from
sbp2scsi_slave_configure again --- i.e. the old pseudo TYPE_DISK
mangling completely reinstated. This prevents the reboot and lets
me access the disk again.

That is, scsi's mid or high level definitely needs protection from
bogus TYPE_DISKs like this one --- in one way or another.
-- 
Stefan Richter
-=====-=-=-= -=== -=-==
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Mon, 2005-07-11 at 00:32 +0200, Stefan Richter wrote:
> I tested again with all conversions reactivated in sbp2 and with
> sdev->use_10_for_rw = 1, sdev->use_10_for_ms = 1 removed from
> sbp2scsi_slave_configure again --- i.e. the old pseudo TYPE_DISK
> mangling completely reinstated. This prevents the reboot and lets
> me access the disk again.
> 
> That is, scsi's mid or high level definitely needs protection from
> bogus TYPE_DISKs like this one --- in one way or another.

Could you get a trace of what's going on from the command response point
of view?  Doing a scsi_print_command() in the queuecommand() routine and
printing the return code and sense (with scsi_print_sense()) in the -
>done() should be sufficient.

Thanks,

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

James Bottomley wrote:
> Could you get a trace of what's going on from the command response point
> of view?  Doing a scsi_print_command() in the queuecommand() routine and
> printing the return code and sense (with scsi_print_sense()) in the
> ->done() should be sufficient.

If I only new where the done() is taken from. Seems to come
from scsi.c.

Here is the log with all the old conversions active in sbp2.
I put scsi_print_command() into sbp2scsi_queuecommand() and
scsi_print_sense() into scsi_done().

Jul 13 21:53:20 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 13 21:53:21 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 13 21:53:21 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:21 shuttle kernel:         command: Inquiry: 12 00 00 00 24 00
Jul 13 21:53:21 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:21 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:21 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:21 shuttle kernel:   Vendor: Initio    Model: IC25N080ATMR04-0  Rev: 2.18
Jul 13 21:53:21 shuttle kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jul 13 21:53:21 shuttle scsi.agent: disk at /devices/pci0000:00/0000:00:0c.0/fw-host1/00101003b80001e0/00101003b80001e0-0/host0/target0:0:0/0:0:0:0
Jul 13 21:53:21 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:21 shuttle kernel:         command: Test Unit Ready: 00 00 00 00 00 00
Jul 13 21:53:21 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:21 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:21 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:21 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:22 shuttle kernel:         command: Read Capacity (10): 25 00 00 00 00 00 00 00 00 00
Jul 13 21:53:22 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:22 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:22 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:22 shuttle kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Jul 13 21:53:22 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:23 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda4
Jul 13 21:53:23 shuttle kernel:         command: Mode Sense (6): 1a 00 08 00 04 00
Jul 13 21:53:23 shuttle kernel: ieee1394: sbp2: Convert MODE_SENSE_6 to MODE_SENSE_10
Jul 13 21:53:23 shuttle kernel: ieee1394: sbp2: Modify mode sense response (10 byte version)
Jul 13 21:53:23 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:23 shuttle kernel:         command: Mode Sense (6): 1a 00 08 00 10 00
Jul 13 21:53:23 shuttle kernel: ieee1394: sbp2: Convert MODE_SENSE_6 to MODE_SENSE_10
Jul 13 21:53:23 shuttle kernel: ieee1394: sbp2: Modify mode sense response (10 byte version)
Jul 13 21:53:23 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel: sda: got wrong page
Jul 13 21:53:23 shuttle kernel: sda: assuming drive cache: write through
Jul 13 21:53:23 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:23 shuttle kernel:         command: Test Unit Ready: 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:23 shuttle kernel:         command: Read Capacity (10): 25 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Jul 13 21:53:23 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:23 shuttle kernel:         command: Mode Sense (6): 1a 00 08 00 04 00
Jul 13 21:53:23 shuttle kernel: ieee1394: sbp2: Convert MODE_SENSE_6 to MODE_SENSE_10
Jul 13 21:53:23 shuttle kernel: ieee1394: sbp2: Modify mode sense response (10 byte version)
Jul 13 21:53:23 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:24 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:24 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:24 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 21:53:24 shuttle kernel:         command: Mode Sense (6): 1a 00 08 00 10 00
Jul 13 21:53:24 shuttle kernel: ieee1394: sbp2: Convert MODE_SENSE_6 to MODE_SENSE_10
Jul 13 21:53:24 shuttle kernel: ieee1394: sbp2: Modify mode sense response (10 byte version)
Jul 13 21:53:24 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:24 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:24 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda3
Jul 13 21:53:24 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:23 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda1
Jul 13 21:53:24 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda6
Jul 13 21:53:25 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda9
Jul 13 21:53:25 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda8
Jul 13 21:53:25 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda10
Jul 13 21:53:25 shuttle kernel: sda: got wrong page
Jul 13 21:53:25 shuttle kernel: sda: assuming drive cache: write through
Jul 13 21:53:25 shuttle kernel:  sda:scsi0 : destination target 0, lun 0
Jul 13 21:53:25 shuttle kernel:         command: Read (10): 28 00 00 00 00 00 00 00 08 00
Jul 13 21:53:25 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:25 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:25 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:25 shuttle kernel:  [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7scsi0 : destination target 0, lun 0
Jul 13 21:53:25 shuttle kernel:         command: Read (10): 28 00 00 00 00 08 00 00 08 00
Jul 13 21:53:25 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 21:53:25 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:25 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 21:53:25 shuttle kernel:  sda8 sda9 sda10
Jul 13 21:53:25 shuttle kernel: Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Jul 13 21:53:25 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda7
Jul 13 21:53:26 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda5
Jul 13 21:53:26 shuttle perl: drakupdate_fstab called with --auto --add /dev/sda2

Next I will try the new sbp2 without conversion (the one that lets the
system reboot).
-- 
Stefan Richter
-=====-=-=-= -=== -==-=
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Wed, 2005-07-13 at 21:56 +0200, Stefan Richter wrote:
> If I only new where the done() is taken from. Seems to come
> from scsi.c.

I think it happens in sbp2scsi_complete_command.

> Here is the log with all the old conversions active in sbp2.
> I put scsi_print_command() into sbp2scsi_queuecommand() and
> scsi_print_sense() into scsi_done().

Actually, I'm afraid I need the command trace for the failing case to
see if I can fix it (i.e. without the sbp2 translations put back in).

Thanks,

James




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

James Bottomley wrote:
> On Wed, 2005-07-13 at 21:56 +0200, Stefan Richter wrote:
>>If I only new where the done() is taken from. Seems to come
>>from scsi.c.
> 
> I think it happens in sbp2scsi_complete_command.

OK, I will move scsi_print_sense just in front of the call to
->done().

>>Here is the log with all the old conversions active in sbp2.
>>I put scsi_print_command() into sbp2scsi_queuecommand() and
>>scsi_print_sense() into scsi_done().
> 
> Actually, I'm afraid I need the command trace for the failing case to
> see if I can fix it (i.e. without the sbp2 translations put back in).

Here is sbp2 without its conversions. That's what the syslog file
caught and what was written on disk before the machine rebooted:

Jul 13 22:31:41 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 13 22:31:42 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 13 22:31:42 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 22:31:42 shuttle kernel:         command: Inquiry: 12 00 00 00 24 00
Jul 13 22:31:42 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 22:31:42 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:32:40 shuttle syslogd 1.4.1: restart.

But there was more than the inquiry going on. We already know that the
inquiry actually succeeds and the disk is recognized as TYPE_DISK.

Just before that attempt I tried to insert msleep()s after the debug
printk to get more out to disk. Of course I managed to put these
right into interrupt context. But at least there was a bit more left
in the syslog file after reboot:

Jul 13 22:24:06 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 13 22:24:07 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 13 22:24:07 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 22:24:07 shuttle kernel:         command: Inquiry: 12 00 00 00 24 00
Jul 13 22:24:07 shuttle kernel: ...sleep 2s...<3>scheduling while atomic: modprobe/0x00000001/6408
Jul 13 22:24:07 shuttle kernel:  [schedule+1425/1632] schedule+0x591/0x660
[...bla bla...]
Jul 13 22:24:08 shuttle kernel:  [<c0102edb>] sysenter_past_esp+0x54/0x75
Jul 13 22:24:09 shuttle scsi.agent: disk at /devices/pci0000:00/0000:00:0c.0/fw-host1/00101003b80001e0/00101003b80001e0-0/host0/target0:0:0/0:0:0:0
Jul 13 22:24:09 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 22:24:09 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:24:09 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:24:09 shuttle kernel:   Vendor: Initio    Model: IC25N080ATMR04-0  Rev: 2.18
Jul 13 22:24:09 shuttle kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jul 13 22:24:09 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 22:24:09 shuttle kernel:         command: Test Unit Ready: 00 00 00 00 00 00
Jul 13 22:24:09 shuttle kernel: ...sleep 2s...<3>scheduling while atomic: modprobe/0x00000001/6496
Jul 13 22:24:09 shuttle kernel:  [schedule+1425/1632] schedule+0x591/0x660
[...got it now...]
Jul 13 22:24:10 shuttle kernel:  [<c0102edb>] sysenter_past_esp+0x54/0x75
Jul 13 22:24:11 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 22:24:11 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:24:11 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:24:11 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 22:24:11 shuttle kernel:         command: Read Capacity (10): 25 00 00 00 00 00 00 00 00 00
Jul 13 22:24:11 shuttle kernel: ...sleep 2s...<3>scheduling while atomic: modprobe/0x00000001/6496
Jul 13 22:24:11 shuttle kernel:  [schedule+1425/1632] schedule+0x591/0x660
[...]
Jul 13 22:24:12 shuttle kernel:  [<c0102edb>] sysenter_past_esp+0x54/0x75
Jul 13 22:24:13 shuttle kernel: Unrecognized sense data (in hex):
Jul 13 22:24:13 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:24:13 shuttle kernel:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jul 13 22:24:13 shuttle kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Jul 13 22:24:13 shuttle kernel: scsi0 : destination target 0, lun 0
Jul 13 22:24:13 shuttle kernel:         command: Mode Sense (10): 5a 00 08 00 00 00 00 00 08 00
Jul 13 22:24:13 shuttle kernel: ...sleep 2s...<3>scheduling while atomic: modprobe/0x00000001/6496
Jul 13 22:24:13 shuttle kernel:  [schedule+1425/1632] schedule+0x591/0x660
[...]
Jul 13 22:24:14 shuttle kernel:  [<c0102edb>] sysenter_past_esp+0x54/0x75
Jul 13 22:25:12 shuttle syslogd 1.4.1: restart.

I'll try to get some more info.
-- 
Stefan Richter
-=====-=-=-= -=== -==-=
http://arcgraph.de/sr/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

I wrote:
> I'll try to get some more info.

There is no way to get more than I already posted. (Except maybe
with a serial console.) All other atempts ended at the first inquiry
command or even at sbp2's "Logged into SBP-2 device" message, leaving
the following SCSI commands to our imagination. Why does the kernel
reboot anyway? If it at least only halted, then I could watch klogd
at the virtual console.

However. The bug is probably in the handling of MODE_SENSE_10 responses
because this is how the new sbp2 code differs from the old code WRT
TYPE_DISK devices as far as I can see. The AVLAB enclosure's firmware
perhaps returns something like a TYPE_RBC device despite it claims to be
of TYPE_DISK.
-- 
Stefan Richter
-=====-=-=-= -=== -===-
http://arcgraph.de/sr/

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Stefan Richter]

I wrote:
> I tested sbp2 with the logic as presently in 2.6.13-rc2 and added
> printks everywhere where linux1394.org's old code would do a conversion.
> The result:

DViCO Momobay FX-3A 3.5" HDD, based on TSB42AA9A bridge
now without sbp2's 36byt inquiry workaround
-------------------------------------------------------
Jul 10 20:04:13 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 20:04:14 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 20:04:14 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case INQUIRY, TYPE_RBC
Jul 10 20:04:14 shuttle kernel:   Vendor:  DViCO    Model: MOMOBAY FX-3A     Rev: REV1
Jul 10 20:04:14 shuttle kernel:   Type:   Unknown                            ANSI SCSI revision: 02

Then silence.
# cat /sys/bus/scsi/devices/*/type
14

MacPower IceCube 3.5" HDD (old FireWire 400 model), OXFW911 based
-----------------------------------------------------------------
Jul 10 20:05:12 shuttle kernel: scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 20:05:14 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 20:05:14 shuttle kernel: ieee1394: sbp2: sbp2_check_sbp2_response: case INQUIRY, TYPE_RBC
Jul 10 20:05:14 shuttle kernel:   Vendor: SAMSUNG   Model: SV1204H           Rev:
Jul 10 20:05:14 shuttle kernel:   Type:   Unknown                            ANSI SCSI revision: 06

Silence.
# cat /sys/bus/scsi/devices/*/type
14

AVLAB 1394b-to-IDE 2.5” Drive Kit, INIC-2430F based
---------------------------------------------------
A few log lines appear, then the PC *reboots* right away. Happens consistently.
Did not happen with the kernel I used before, 2.6.11.x + up-to-date linux1394.


MacPower Prefect II 5.25" DVD-RW, PL-3507 based
-----------------------------------------------
Jul 10 20:18:51 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 20:18:52 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 20:18:52 shuttle kernel:   Vendor: PLEXTOR   Model: DVDR   PX-716A    Rev: 1.08
Jul 10 20:18:52 shuttle kernel:   Type:   CD-ROM                             ANSI SCSI revision: 02
Jul 10 20:18:52 shuttle scsi.agent: cdrom at /devices/pci0000:00/0000:00:0c.0/fw-host1/0030e005003b00c8/0030e005003b00c8-0/host0/target0:0:0/0:0:0:0
Jul 10 20:18:52 shuttle kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray

# cat /sys/bus/scsi/devices/*/type
5

"cdrdao read-cd ..." and "cdrdao write --simulate ..." work.
No sbp2_check_command or _response is logged during cdrdao's runs.
scsi_host_dev_release is not called when the DVD-RW is disconnected, but
that is another story.

Formac CDRW 16/10/40, an old 5.25" enclosure with LSI bridge
------------------------------------------------------------
Jul 10 20:46:00 shuttle kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 20:46:02 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 20:46:02 shuttle kernel:   Vendor: TEAC      Model: CD-W516EB         Rev: 1.0A
Jul 10 20:46:02 shuttle kernel:   Type:   CD-ROM                             ANSI SCSI revision: 02
Jul 10 20:46:02 shuttle scsi.agent: cdrom at /devices/pci0000:00/0000:00:0c.0/fw-host1/00a0b80300002142/00a0b80300002142-0/host0/target0:0:0/0:0:0:0
Jul 10 20:46:04 shuttle kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray

Same as above with type and cdrdao.

SmartDisk VST Portable CD-RW, unknown bridge
--------------------------------------------
Jul 10 20:58:05 shuttle kernel: scsi1 : SCSI emulation for IEEE-1394 SBP-2 Devices
Jul 10 20:58:14 shuttle kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 10 20:58:14 shuttle kernel:   Vendor: TEAC      Model: CD-W28E           Rev: 1.1A
Jul 10 20:58:14 shuttle kernel:   Type:   CD-ROM                             ANSI SCSI revision: 02
Jul 10 20:58:14 shuttle kernel: sr1: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Jul 10 20:58:14 shuttle kernel: Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0,  type 5
Jul 10 20:58:15 shuttle scsi.agent: cdrom at /devices/pci0000:00/0000:00:0a.0/fw-host0/00d0010500006823/00d0010500006823-0/host1/target1:0:0/1:0:0:0

Same again.

I will have a closer look at the silent 3.5" disks right away.
-- 
Stefan Richter
-=====-=-=-= -=== -=-=-
http://arcgraph.de/sr/


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: changes to ieee1394/sbp2 outside of linux1394.org

[James Bottomley]

On Sat, 2005-07-09 at 19:06 -0400, Ben Collins wrote:
> Alright, I need some explanation on these changes to sbp2. Lots of things
> ripped out.

The patch seems reasonably explanatory:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=631e8a1398ce4cfef8b30678d51daf0c64313a09


> I can understand that TYPE_RDC is what we had as TYPE_SDAD. Now, in our
> tree for TYPE_RDC, we converted it to TYPE_DISK. We also did a lot of mode
> conversions for DISK/RDC/ROM types.
> 
> My question is, why were the conversions all removed? The conversions, as
> far as I know, are related to SBP protocol, and not SCSI, so why would the
> SCSI maintainers feel the need to rip out an important part of the SBP2
> driver? Note, this isn't really a SCSI device, or a scsi host controller.
> It's a protocol translation layer.

TYPE_RBC is essentially a TYPE_DISK but with a few weird quirks, mainly
in the mode page setups.  The object of the changes is to make sd.c
treat TYPE_RBC correctly without any need of translations.

I'm not sure where you get the idea that SBP isn't a SCSI protocol from:
it was defined and ratified by the T10 SCSI committee
(http://www.t10.org/ftp/t10/drafts/sbp2/sbp2r04.pdf).  The RBC command
set was designed for the SBP protocol, but not for exclusive use by it.
The idea of the changes is to treat SBP for what it is (a transport
protocol) and have the ULDs understand the actual command protocol (RBC)
so there's no need for a protocol translation layer at all (this is the
bit that got removed).  This has the added benefit that the sd ULD is
ready for the day USB or other device vendors adopt RBC.

James

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

Ok, I see that the rw and ms 10byte conversions are in the scsi lib now.

Thing is, these don't seem to be working for SBP2. I assume these
conversions came from libata (since that's the only other user of them).
Is that correct? Was the logic compared to the SBP2 conversions before
being moved over to using them?

Reverting this portion wont break anything, correct? Just means we have
duplication of code (well, except that one works for us and the other
doesn't).

I'm going to revert this in my merge with Linus, but I will retain it in
our tree until we can figure out what the problem is.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Jeff Garzik]

On Sat, Jul 09, 2005 at 07:31:38PM -0400, Ben Collins wrote:
> Thing is, these don't seem to be working for SBP2. I assume these
> conversions came from libata

Incorrect.


> (since that's the only other user of them).

Incorrect.


> Was the logic compared to the SBP2 conversions before
> being moved over to using them?

Ask Al Viro, the author of the changes in question.


> Reverting this portion wont break anything, correct?

Probably correct.

	Jeff

Re: changes to ieee1394/sbp2 outside of linux1394.org

[Ben Collins]

On Sat, Jul 09, 2005 at 11:29:14PM -0400, Jeff Garzik wrote:
> On Sat, Jul 09, 2005 at 07:31:38PM -0400, Ben Collins wrote:
> > Thing is, these don't seem to be working for SBP2. I assume these
> > conversions came from libata
> 
> Incorrect.
> 
> 
> > (since that's the only other user of them).
> 
> Incorrect.

Well, I didn't see anything else in the kernel that set the use_10_*
settings, other than libata.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk  - http://www.swissdisk.com/