From: Brian Jackson <brian@brianandsara.net>
To: linux-kernel@vger.kernel.org
Cc: kai.engert@gmx.de
Subject: Re: only ieee1394 from 2.4.20 works for me
Date: Thu, 26 Feb 2004 00:12:25 -0600 [thread overview]
Message-ID: <200402260012.25098.brian@brianandsara.net> (raw)
In-Reply-To: <Pine.LNX.4.58L.0402251153550.21511@logos.cnet>
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
next prev parent reply other threads:[~2004-02-26 6:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-22 14:33 only ieee1394 from 2.4.20 works for me Kai Engert
2004-02-22 15:53 ` Ben Collins
2004-02-23 20:32 ` Ben Collins
2004-02-25 14:57 ` Marcelo Tosatti
2004-02-26 6:12 ` Brian Jackson [this message]
2004-02-26 13:14 ` Ben Collins
2004-02-26 19:13 ` Brian Jackson
2004-02-27 1:30 ` Kai Engert
-- strict thread matches above, loose matches on Subject: below --
2004-02-25 22:54 Holger Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200402260012.25098.brian@brianandsara.net \
--to=brian@brianandsara.net \
--cc=kai.engert@gmx.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox