linux-kernel - Re: isochronous receives?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Dec 2006 07:30:12 -0700
From:	"Robert Crocombe" <rcrocomb@...il.com>
To:	"Keith Curtis" <Keith.Curtis@...eo.com>
Cc:	linux1394-devel <linux1394-devel@...ts.sourceforge.net>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: isochronous receives?

On 11/29/06, Keith Curtis <Keith.Curtis@...eo.com> wrote:
> I never resolved the problem. I turned on the excessive debugging output, but it
> didn't print out info about receiving packets or interrupts. My test
> app claimed there were no packets received although the bus analyzer
> showed lots of packets going by.

Well, I figured it out, finally.  Thankfully (in a way...), it was my
code: I was setting the tag to -1 in a certain spot (which indicates
that you want to see all packets, regardless of their tag), but
unhelpfully changing it to 0 before calling raw1394_iso_recv_start...

...dangit, though.  Looking at the data stream, the tag *is* zero.

Stefan, isn't the line:

        /* match on specified tags */
        contextMatch = tag_mask << 28;

in ohci_iso_recv_start() wrong?  The register looks to work like this.
 The tag field is two bits.

if you want to match on 11b, then set bit tag3 (bit 31)
if you want to match on 10b, then set bit tag2 (bit 30)
if you want to match on 01b, then set bit tag1 (bit 29)
if you want to match on 00b, then set bit tag0 (bit 28)

Which makes the shift obviously wrong.  Passing in '3' to match on tag
11b will have you instead set bits 29 and 28, and you will match on
01b and 00b.  Passing in '0' will completely bone you: no bits will be
turned on.  Passing in '-1' to match all bits does work, though.
You'd have to know to pass in 0x8 to match for tag 11b, which is a
skosh counterintuitive and probably not what was intended.

Here's my crap patch.  It appears to Work For Me(tm).

--- ohci1394.c  2006-12-04 16:52:10.916044780 -0700
+++ modified_ohci1394.c 2006-12-13 07:22:07.613917511 -0700
@@ -1491,7 +1491,18 @@
        reg_write(recv->ohci, recv->ContextControlSet, command);

        /* match on specified tags */
-       contextMatch = tag_mask << 28;
+        switch (tag_mask)
+        {
+       case -1: contextMatch = tag_mask << 28; break;
+       case 0: contextMatch = (1 << 28); break;
+       case 1: contextMatch = (1 << 29); break;
+       case 2: contextMatch = (1 << 30); break;
+       case 3: contextMatch = (1 << 31); break;
+       default:
+               DBGMSG("Invalid tag_mask %0x, matching all tags",tag_mask);
+               contextMatch = tag_mask << 28;
+               break;
+       }

        if (iso->channel == -1) {
                /* enable multichannel reception */

So nevermind.  I'm totally vindicated and my code is, as always,
flawless.  Cough.

-- 
Robert Crocombe
rcrocomb@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/