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

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

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

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

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

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 ;;

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

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 puz

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

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 puzzl

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

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

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

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) an

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

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 : [EMAIL PROTECTED] : http

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

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.

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

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

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

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: 1ARev: 3.06 Type: Unknown

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

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: - - - - - - - - - - - -

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

>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 yo

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

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/b

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

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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [EMAIL PROTECTED]:/usr/local/media/prog

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

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 anyway. No, there are changes in the current rev of the repo. Are sure you tried the latest rev?

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

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 >

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

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 anyway. Any other things that I should try? Any prin

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

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 va

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

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

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

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

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

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

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

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//device/type when the device isn't configured (I'm using a -rc2-mm1 kernel

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

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

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

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 s

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

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. Wh

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

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

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

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_queuecom

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

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 don

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

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 preve

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

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 witho

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

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 m

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

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 th

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

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

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

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 com

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

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 som

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

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 ---

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

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

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

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

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

> > 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 wh

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

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_1

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

> 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_comm

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

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 worki

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

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). >

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

> > 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 rippin

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

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=631e8a1398ce4cfef8b30678d51daf0c6

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

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 di

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

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 m

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

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 ove

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

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

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

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 tr

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

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

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

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

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

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 cod

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

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 orph

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

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 > > wit

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

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

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

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. T

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

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: 1ARev: 3.06 > Type: Unknown

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

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/ - To unsubscribe from this list: send the line "un

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

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 >

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

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 bef

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

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 hel

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

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

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

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

changes to ieee1394/sbp2 outside of linux1394.org

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 discussio