Re: generating firewire traffic

Carl Karsten wrote:
> I can cause a kernel panic:

It's only of peripheral interest to kino-dev then. :-)
([email protected] and [email protected] cover kernel
driver topics.)

> http://bugzilla.kernel.org/show_bug.cgi?id=13075
> by plugging in a dv cam and running the following for a few minutes:
> 
> dvgrab - | nc 192.168.1.216 2007 | nc 192.168.1.216 2008 > /dev/null
> 
> on 192.168.1.216 I am running my home made echo server:
> while /bin/true;do  nc -l -p 2007 -c cat; done &
> while /bin/true;do  nc -l -p 2008 -c cat; done &
> 
> To make it easier to debug, I would like to remove the need for the
> cam and the dvgrab command and just use something that stimulates the
> firewire hardware without anything plugged into the port.

You need the camera and a capture program; only then the controller
generates interrupts and utilizes its DMA units.  You cannot achieve
this locally.  Instead of the camera, there could be a second PC or the
same PC with a second card and a streamer program.

Well, you actually /can/ achieve something similar without camera or
second PC or second card --- by /transmitting/ video (which works even
if nothing is connected).  But different DMA units of the controller and
different DMA programming of the kernel drivers would be involved then,
so you may get same or different results --- more likely different results.

> Or if I need something plugged in, then not having to worry about what
> is plugged in (cam, drive, 2nd firewire port...)
> 
> and in case it is somehow dependent on the timing created by a dv cam,
> something like cat /dev/raw1394 so that "install dvgrab" isn't needed.

# cat /dev/dv1394/$n
But that would utilize different driver code paths, i.e. ohci1394 +
dv1394 instead of ohci1394 + ieee1394 + raw1394.

/dev/raw1394 isn't cat-friendly.  But you could try testdv on it or
something along the lines.

> Or convince me that the panic isn't dependent on firewire at all,
> which I have been told, but have not been able to reproduce.
> 
> Or buy me a pony and I'll stop worrying about this :)

Since the panic happens in the networking code, it is either a pure
networking bug, or it is an ieee1394 bug which corrupts the kernel in a
way that can only be seen by the networking driver (perhaps only the
forcedeth driver in particular) while network traffic is going on.

Can you capture to local disk without panic?

One other experiment which could possibly give some further information
is to repeat everything after replacing ohci1394 + ieee1394 + raw1394 by
firewire-ohci + firewire-core.  Requires libraw1394 v2.  (Latest is best.)
-- 
Stefan Richter
-=====-==--= -==- -=-=-
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects