linux1394-devel

length of iso packets

[Manfred W. <e95...@st...>]

I have the following problem concerning the reception of iso packets:

I have to ways to find out the length of an iso packet in the iso handler:
the length argument and the iso header which is positioned in the first
quadlet of the buffer.
Normally length == (data[0] >> 16) + 4. This is because the length of the
buffer contains the quadlet which represents the iso header. Usually this
condition is fulfilled.
But sometimes I received packets where the length argument sayed that the
packet length was 332 wherea the iso header (ie. data[0] >> 16) sayed 584.
Since I know the size of my iso packets, I can tell you that (of course)
the iso header is right and the length argument reports an incorrect
length.

So two questions emerge:
1) Why does the handler report an incorrect packet length?
2) Is the buffer (*data) filled correctly or are only the first 332
bytes valid and the rest (256 Bytes) lost?

Manfred Weihs

PS: I use a Unibrain Fireboard with the pcilynx driver, and reception of
iso packets works quite find, but as mentioned above: sometimes data is
lost.

PPS: Just when I wanted to send this mail I observed another version of
that problem: Iso header said 776 whhereas the length argument said 732.
So now 48 Bytes are missing. Again the length reported by the header is
correct, since valid packet sizes in my application are (without iso
header) 192*k+8 (k is an integer and 8 is the length of the CIP header).
But the most frequent version of that problem is 332 vs. 584.

Re: length of iso packets

[Andreas B. <and...@mu...>]

On Tue, Apr 11, 2000 at 03:35:11PM +0200, Manfred Weihs wrote:
> But sometimes I received packets where the length argument sayed that the
> packet length was 332 wherea the iso header (ie. data[0] >> 16) sayed 584.
> Since I know the size of my iso packets, I can tell you that (of course)
> the iso header is right and the length argument reports an incorrect
> length.

The initial length comes from the hardware driver and is passed
through to raw1394 (which uses it to allocate a buffer) and then on to
user space and to the handler by libraw1394.  It is not looked up from
the actual header anywhere.

> So two questions emerge:
> 1) Why does the handler report an incorrect packet length?

Good question.

Apparantly because the PCILynx reports lower packet lengths in the DMA
stat register.  But why it does that I don't know.  I just looked over
my driver to see whether there are any bugs in that code, but
basically the transfer count is just taken from the reg and passed on.

> 2) Is the buffer (*data) filled correctly or are only the first 332
> bytes valid and the rest (256 Bytes) lost?

raw1394 only uses the length from hardware driver to decide how much
to save, so the rest is lost.


Could you please apply the following patch to pcilynx.c directly
(i.e. cd into drivers/ieee1394 directory and "patch pcilynx.c <patch")
It will probably say that it moved the hunk because I have changed my
pcilynx.c a bit but that's no problem.  The patched file should log
length mismatches with the register content, please send them to me.

--- pcilynx.c~  Thu Apr 13 03:37:57 2000
+++ pcilynx.c   Fri Apr 14 03:14:33 2000
@@ -1175,6 +1175,12 @@
                 data = lynx->iso_rcv.page[idx / ISORCV_PER_PAGE]
                         + (idx % ISORCV_PER_PAGE) * MAX_ISORCV_SIZE;
 
+                if ((*data >> 16) + 4 != (lynx->iso_rcv.stat[idx] & 0x1fff)) {
+                        PRINT(KERN_ERR, lynx->id,
+                              "iso length mismatch 0x%08x/0x%08x", *data,
+                              lynx->iso_rcv.stat[idx]);
+                }
+
                 if (lynx->iso_rcv.stat[idx] 
                     & (DMA_CHAN_STAT_PCIERR | DMA_CHAN_STAT_PKTERR)) {
                         PRINT(KERN_INFO, lynx->id,


-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

Re: length of iso packets

[Manfred W. <e95...@st...>]

On Fri, 14 Apr 2000, Andreas Bombe wrote:

> Could you please apply the following patch to pcilynx.c directly
> (i.e. cd into drivers/ieee1394 directory and "patch pcilynx.c <patch")
> It will probably say that it moved the hunk because I have changed my
> pcilynx.c a bit but that's no problem.  The patched file should log
> length mismatches with the register content, please send them to me.

OK. I here is that part of my /var/log/messages, which is of interrest:

Apr 14 13:21:10 localhost kernel: pcilynx0: sent reject 
Apr 14 13:21:10 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a014c 
Apr 14 13:21:12 localhost kernel: pcilynx0: sent reject 
Apr 14 13:21:12 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02dc 
Apr 14 13:21:12 localhost kernel: pcilynx0: sent reject 
Apr 14 13:21:12 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02fc 
Apr 14 13:23:03 localhost kernel: pcilynx0: sent reject 
Apr 14 13:23:03 localhost kernel: pcilynx0: sent reject 
Apr 14 13:23:03 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 
Apr 14 13:23:03 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 
Apr 14 13:25:09 localhost kernel: pcilynx0: sent reject 
Apr 14 13:25:09 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a014c 
Apr 14 13:25:27 localhost kernel: pcilynx0: sent reject 
Apr 14 13:25:27 localhost kernel: pcilynx0: sent reject 
Apr 14 13:25:27 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 
Apr 14 13:25:28 localhost kernel: pcilynx0: sent reject 
Apr 14 13:25:28 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 
Apr 14 13:25:28 localhost kernel: pcilynx0: sent reject 
Apr 14 13:25:28 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 
Apr 14 13:25:33 localhost kernel: pcilynx0: sent reject 
Apr 14 13:25:33 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02bc 
Apr 14 13:26:34 localhost kernel: pcilynx0: sent reject 
Apr 14 13:26:34 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 
Apr 14 13:29:34 localhost kernel: pcilynx0: sent reject 
Apr 14 13:29:34 localhost kernel: pcilynx0: sent reject 
Apr 14 13:29:34 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c 

I should mention that this especially happens, if there is higher load on
my system, eg. if I start netscape and load a page.

Manfred Weihs

Re: length of iso packets

[Andreas B. <and...@mu...>]

On Fri, Apr 14, 2000 at 01:36:46PM +0200, Manfred Weihs wrote:
> 
> 
> On Fri, 14 Apr 2000, Andreas Bombe wrote:
> 
> > Could you please apply the following patch to pcilynx.c directly
> > (i.e. cd into drivers/ieee1394 directory and "patch pcilynx.c <patch")
> > It will probably say that it moved the hunk because I have changed my
> > pcilynx.c a bit but that's no problem.  The patched file should log
> > length mismatches with the register content, please send them to me.
> 
> OK. I here is that part of my /var/log/messages, which is of interrest:
> 
> Apr 14 13:21:10 localhost kernel: pcilynx0: sent reject 
> Apr 14 13:21:10 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a014c 
> Apr 14 13:21:12 localhost kernel: pcilynx0: sent reject 
> Apr 14 13:21:12 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02dc 

Now that I've been running with this, I got the same errors...  It's
apparantly caused by receive buffer overflows.  Some data gets lost,
so the DMA does and reports smaller packets than the iso header.

> I should mention that this especially happens, if there is higher load on
> my system, eg. if I start netscape and load a page.

... which might cause heavy activity on the PCI bus so that the FIFO
on the Lynx can't be emptied in time and overflows.

I didn't know how to size the FIFOs so I gave all of them (general
receive, async transmit, iso transmit) the same size.  Try the current
version of pcilynx.c from CVS which has the iso length check already
included and configures the receive FIFO larger.

This might cause transmits to fail due to underruns on the transmit
FIFO.  Try it and see if there are problems.  It would be possible to
do dynamic resizing based on overflow / underrun statistics...

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

Re: length of iso packets

[Manfred W. <e95...@st...>]

On Sat, 15 Apr 2000, Andreas Bombe wrote:
> I didn't know how to size the FIFOs so I gave all of them (general
> receive, async transmit, iso transmit) the same size.  Try the current
> version of pcilynx.c from CVS which has the iso length check already
> included and configures the receive FIFO larger.

I am not sure, if that was a real solution to the problem. I still get
those errors, and I think, they come as frequently as before.

Manfred Weihs

Re: length of iso packets

[Andreas B. <and...@mu...>]

On Tue, Apr 18, 2000 at 12:54:57PM +0200, Manfred Weihs wrote:
> 
> 
> On Sat, 15 Apr 2000, Andreas Bombe wrote:
> > I didn't know how to size the FIFOs so I gave all of them (general
> > receive, async transmit, iso transmit) the same size.  Try the current
> > version of pcilynx.c from CVS which has the iso length check already
> > included and configures the receive FIFO larger.
> 
> I am not sure, if that was a real solution to the problem. I still get
> those errors, and I think, they come as frequently as before.

It made it better for me.  I guess it does help, but just not enough
for you.  It seems to be a symptom of interrupts not being served fast
enough.  Do you probably have some drivers running that take a lot of
irq time (e.g. vesa fb)?  Otherwise the data copying might really
overload your system.

Another possibility is that it runs out of iso buffers while it is
receiving (because the bottom half isn't executed often enough to get
clean buffers), but I don't really think that happens since in that
case it just stops receiving iso.  You can try to raise the
NUM_ISORCV_PCL number in pcilynx.h anyway and see if that helps in any
way.

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

Re: length of iso packets

[Manfred W. <e95...@st...>]

Andreas Bombe wrote:
> It made it better for me.  I guess it does help, but just not enough
> for you.  It seems to be a symptom of interrupts not being served fast
> enough.  Do you probably have some drivers running that take a lot of
> irq time (e.g. vesa fb)?  Otherwise the data copying might really
> overload your system.

I do not use vesa fb. But maybe the reason could be the high data rate
on that iso channel. I am receiving a complete MPEG 2 transport stream,
which is iirc about 50 MBit/s. And the complete data is copied again in
user space to the buffers of my software (which is not very efficient; I
will improve that sometime in future), and a part of the data (which is
intended to be decoded) is copied once again. Maybe there are too many
copies (and the discussion about "DMA to userspace" tells me that
copying the data could obviously cause performance problems).
And since I also do some decoding, there is really high load on my
system.
This might be the reason.

Manfred Weihs