only ieee1394 from 2.4.20 works for me

only ieee1394 from 2.4.20 works for me

[Kai Engert]

In the last year I have been playing with a variety of combinations of 
ieee1394 controllers, machines, external mass storage devices and linux 
kernel versions. So have some friends of mine.

The only version that works for us is the ieee1394 code that was 
included with kernel version 2.4.20.

(I removed drivers/ieee1394 completely, and replaced it with 
drivers/ieee1394 from 2.4.20)

Using that snapshot, we are able to transfer data to disks and video 
from a camcorder just fine, in all combinations we have tested.

Every other kernel version, both older or newer than 2.4.20, is broken. 
We either see random errors, or writing data to disks stalls 
immediately, or daisy chained devices don't work.

I'm currently using the official Fedora core 1 series kernels, patched 
that way, and it works like a charm.

Please consider to use the 2.4.20 ieee1394 snapshot in future 2.4.x 
releases.

Best Regards,
Kai


PS: Please CC me on replies.

Re: only ieee1394 from 2.4.20 works for me

[Ben Collins]

On Sun, Feb 22, 2004 at 03:33:39PM +0100, Kai Engert wrote:
> In the last year I have been playing with a variety of combinations of 
> ieee1394 controllers, machines, external mass storage devices and linux 
> kernel versions. So have some friends of mine.
> 
> The only version that works for us is the ieee1394 code that was 
> included with kernel version 2.4.20.
> 
> (I removed drivers/ieee1394 completely, and replaced it with 
> drivers/ieee1394 from 2.4.20)
> 
> Using that snapshot, we are able to transfer data to disks and video 
> from a camcorder just fine, in all combinations we have tested.
> 
> Every other kernel version, both older or newer than 2.4.20, is broken. 
> We either see random errors, or writing data to disks stalls 
> immediately, or daisy chained devices don't work.
> 
> I'm currently using the official Fedora core 1 series kernels, patched 
> that way, and it works like a charm.
> 
> Please consider to use the 2.4.20 ieee1394 snapshot in future 2.4.x 
> releases.

It's pretty strange that I haven't heard of such problems. Maybe you
would consider trying to debug the problem rather than reverting to
source that is several years old (and that I know is broken).

Latest 2.4.x code (that which is in our SVN repo) works fine for me.

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

Re: only ieee1394 from 2.4.20 works for me

[Ben Collins]

This lack of response is probably why you haven't gotten any help. I
can't magically fix the issues you are seeing.

I did however take the time today to load up 2.4.25 on my AMD/nForce
box, and was able to load sbp2 and read/write from a drive without any
problems (even did an fsck afterwards to make sure) and also captured
some video frames with video1394 using coriander.

I didn't see any problems, but then again with such a vague complaint
it's sort of hard to attempt to reproduce anything.

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

Re: only ieee1394 from 2.4.20 works for me

[Marcelo Tosatti]

On Sun, 22 Feb 2004, Kai Engert wrote:

> In the last year I have been playing with a variety of combinations of
> ieee1394 controllers, machines, external mass storage devices and linux
> kernel versions. So have some friends of mine.
>
> The only version that works for us is the ieee1394 code that was
> included with kernel version 2.4.20.
>
> (I removed drivers/ieee1394 completely, and replaced it with
> drivers/ieee1394 from 2.4.20)
>
> Using that snapshot, we are able to transfer data to disks and video
> from a camcorder just fine, in all combinations we have tested.
>
> Every other kernel version, both older or newer than 2.4.20, is broken.
> We either see random errors, or writing data to disks stalls
> immediately, or daisy chained devices don't work.
>
> I'm currently using the official Fedora core 1 series kernels, patched
> that way, and it works like a charm.
>
> Please consider to use the 2.4.20 ieee1394 snapshot in future 2.4.x
> releases.

Hi Kai,

As Ben already said, he needs a detailed report of your the problems.

I'm sure he will work to fix them as soon as he has the reports.

Get backtraces with Alt+SysRQ+T and Alt+SysRQ+P when the kernel hangs.

Re: only ieee1394 from 2.4.20 works for me

[Holger Gruber]

Hi Ben,

I have exactly the same problem with my ieee1394 mass storage device.
To solve it, I did the same as Kai and replaced the drivers/ieee1394
directory for kernel versions later than 2.4.20 with those found in
2.4.20.
The problem seems to be the same with 2.6.x kernel series. I didn't
investigate this further, but I think I will be able to send to you
the reports needed the next days.

Holger
PS: Please CC me on replies.

Re: only ieee1394 from 2.4.20 works for me

[Brian Jackson]

On Wednesday 25 February 2004 08:57, Marcelo Tosatti wrote:
> On Sun, 22 Feb 2004, Kai Engert wrote:
> > In the last year I have been playing with a variety of combinations of
> > ieee1394 controllers, machines, external mass storage devices and linux
> > kernel versions. So have some friends of mine.
> >
> > The only version that works for us is the ieee1394 code that was
> > included with kernel version 2.4.20.

Oddly enough I've been having trouble with ieee1394 too for quite some time (I 
was beginning to think my drive boxes were dead for some reason), and much to 
my pleasure your little trick works.

> >
> > (I removed drivers/ieee1394 completely, and replaced it with
> > drivers/ieee1394 from 2.4.20)
> >
> > Using that snapshot, we are able to transfer data to disks and video
> > from a camcorder just fine, in all combinations we have tested.
> >
> > Every other kernel version, both older or newer than 2.4.20, is broken.
> > We either see random errors, or writing data to disks stalls
> > immediately, or daisy chained devices don't work.

I however don't have the same problems you describe. Newer versions just 
simply fail to see anything attached to the ieee1394 bus. I'm using a via 
epia M10000. I saw a report similar to mine on the 1394 list, but it went 
unanswered.

> >
> > I'm currently using the official Fedora core 1 series kernels, patched
> > that way, and it works like a charm.
> >
> > Please consider to use the 2.4.20 ieee1394 snapshot in future 2.4.x
> > releases.

I'll be the first one to agree with ben that this is a bad idea.

>
> Hi Kai,
>
> As Ben already said, he needs a detailed report of your the problems.
>
> I'm sure he will work to fix them as soon as he has the reports.
>
> Get backtraces with Alt+SysRQ+T and Alt+SysRQ+P when the kernel hangs.

Unfortunately, I don't have any crashes, errors, or anything else helpful. 
I've tried different settings for debugging, none showed anything more 
revealing.

If there is anything that I can do (extra debugging patches, etc.) these boxes 
were bought for testing, and that's what they shall do.

--Brian Jackson

-- 
http://www.brianandsara.net

Re: only ieee1394 from 2.4.20 works for me

[Ben Collins]

> I however don't have the same problems you describe. Newer versions just 
> simply fail to see anything attached to the ieee1394 bus. I'm using a via 
> epia M10000. I saw a report similar to mine on the 1394 list, but it went 
> unanswered.

Did you cat /proc/bus/ieee1394/devices?
Did you try using the rescan-scsi-bus.sh script?


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

Re: only ieee1394 from 2.4.20 works for me

[Brian Jackson]

On Thursday 26 February 2004 07:14, Ben Collins wrote:
> > I however don't have the same problems you describe. Newer versions just
> > simply fail to see anything attached to the ieee1394 bus. I'm using a via
> > epia M10000. I saw a report similar to mine on the 1394 list, but it went
> > unanswered.
>
> Did you cat /proc/bus/ieee1394/devices?

I tried a bunch of stuff, don't remember exactly about this, let me check real 
quick...
Empty.

> Did you try using the rescan-scsi-bus.sh script?

Yeah, ran and reran this, the sbp2 driver never registers itself with the scsi 
subsystem.

--Brian Jackson

-- 
http://www.brianandsara.net

Re: only ieee1394 from 2.4.20 works for me

[Kai Engert]

Thanks a lot for your offer to analyze the problem.
I spent the last 6 hours trying to gather some helpful data.

I'm traveling between places a lot these days,
today I had access to one ieee1394 disk only.

I could play with a second disk Saturday.

--------

Let's ignore the small problem that 2.4.20 immediately recognizes
a disk when plugged in, but other versions require me to run
the rescan-scsi-bus script before the device is listed in /proc/scsi.

--------

Let's talk about the major problem, which is stalled data transfers,
when accessing hard disk drives.

I reconfirmed the problem still exists with 2.4.25.
I used 2.4.25 for the following tests.

Depending on the tools I use to access the external ieee1394 disk,
I sometimes get the stall effect very quickly, sometimes it takes a 
minute, sometimes it's difficult to reproduce at all.

When data transfer stalls, there is a period of about 30 seconds
where nothing happens, then I get:

   ieee1394: sbp2: aborting sbp2 command
   Read (10) 00 01 fa 9b 67 00 00 ff 00

After the message is shown, things again work for a random amount
of time, until it eventually stalls again.
(The numbers on the Read line appear to be different each time).

In my tests, I didn't do anything else on the system besides accessing 
the disk.

--------

An excerpt showing 1000 lines from /var/log/messages around the abort
is available at
   http://kuix.de/misc/kernel1394/excerpt

Output from /proc/bus/ieee1394/devices is available at
   http://kuix.de/misc/kernel1394/devices

cat /proc/scsi/scsi
   http://kuix.de/misc/kernel1394/scsi

--------

Because the dmesg output uses a small buffer, which quickly gets
overwritten once the stall period  is over, I didn't
include it here.

But now that I write these lines, I realize, maybe it would
help to catch output from dmesg, while things are stalled.
During that perioud, dmesg probably contains the last messages just 
before the problem. I can try it again Saturday, if you need that output.

--------

The data above was produced using the official 2.4.25 kernel.

I played with three combinations of debug settings.

a) No 1394 debug output enabled, which only gives the abort message.

b) Having set CONFIG_IEEE1394_VERBOSEDEBUG=y
    which gave the output I provided on the server.

c) In addition to b), having set CONFIG_IEEE1394_SBP2_DEBUG to 2.
    With that seeting, it was difficult to watch what's going on,
    because there was so much output on the screen.
    I'm quite sure things did not stall with this debug
    setting activated.

--------

What did I do to reproduce the problem?
Hopefully I found a testcase that you could try yourself.

   mount /fire
   cp linux-2.4.25.tar.bz2 /fire
   cd /fire
   tar xjf linux-2.4.25.tar.bz2

This stalls at least twice for me,
until all data is eventually processed.

--------

While I said in my initial mail, code from 2.4.20 works reliably,
I have to take that back partially.

While 2.4.20 works very good for me when copying a small
amount of larger files, the above scenario, where a lot of small
files are used, does not work reliably.

With the above test case, using ieee1394 from 2.4.20 gives me:
   ieee1394: sbp2: sbp2util_allocate_request_packet - no packets available!
   ieee1394: sbp2: sbp2util_allocate_write_request_packet failed
   ieee1394: sbp2: aborting sbp2 command
   Write (10) 00 01 bb db 77 00 00 06 00

--------

Thanks again for looking into the problem.
I hope the information provided helps.

If you want me to do more, I'd be glad to help,
but would appreciate detailed instructions what to do.

If you want me to try other snapshots of the ieee1394 code,
please feel free to send me a .tar.bz2 of the drivers/ieee1394 directory.

Best Regards,
Kai


Kai Engert wrote:
> In the last year I have been playing with a variety of combinations of 
> ieee1394 controllers, machines, external mass storage devices and linux 
> kernel versions. So have some friends of mine.
> 
> The only version that works for us is the ieee1394 code that was 
> included with kernel version 2.4.20.
> 
> (I removed drivers/ieee1394 completely, and replaced it with 
> drivers/ieee1394 from 2.4.20)
> 
> Using that snapshot, we are able to transfer data to disks and video 
> from a camcorder just fine, in all combinations we have tested.
> 
> Every other kernel version, both older or newer than 2.4.20, is broken. 
> We either see random errors, or writing data to disks stalls 
> immediately, or daisy chained devices don't work.
> 
> I'm currently using the official Fedora core 1 series kernels, patched 
> that way, and it works like a charm.
> 
> Please consider to use the 2.4.20 ieee1394 snapshot in future 2.4.x 
> releases.
> 
> Best Regards,
> Kai
> 
> 
> PS: Please CC me on replies.
>