From: Xavier Bestel <xavier.bestel@free.fr> http://marc.theaimsgroup.com/?t=111929555100004&r=1&w=2 When using dvgrab (32bits userspace) on an amd64, the 1st write() syscall on /dev/raw1394 fails with -EINVAL on a 64bits kernel, whereas it works on a 32bits kernel.
I assume this problem remains on 2.6.13-rc4?
bugme-daemon@kernel-bugs.osdl.org wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=4779 > > Summary: amd64: raw1394 returns EINVAL Xavier, could you please retest 2.6.13-rc5 (or -rc6 if it's out) and update this bug report? You can do that by doing a reply-to-all to this email if you like. Thanks.
Ping. Please test 2.6.14-rc1.
Xavier, is this problem still present in kernel 2.6.15-rc7?
I'm assuming this issue is already fixed. Please reopen this bug if it's still present in recent 2.6 kernels.
OK, finally got around to reproducing this on a friend's machine. It's still a problem. I'll work on a fix when I get time. open("/dev/raw1394", O_RDWR) = 3 write(3, "\1\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 52) = -1 EINVAL (Invalid argument)
2.6.16-rc3 64-bit Intel Xeon Same bug, but only when sending ISO packets (using raw1394 from userspace). Original bug report indicates all writes fail, but for me, I only notice ISO writes to fail, other writes appear to work as expected. Very reproducable.
Half of the problem should be fixed by a patch by Andi Kleen in Linux 2.6.16-git11: "x86_64: Implement compat code for raw1394 read/write" http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4bc32c4d5cde5c57edcc9c2fe5057da8a4dd0153
Robert, does iso transmission work with libraw1394 1.2.1 as Dan mentioned? http://article.gmane.org/gmane.linux.kernel.firewire.user/1994 http://article.gmane.org/gmane.linux.kernel.firewire.user/1996 http://article.gmane.org/gmane.linux.kernel.firewire.user/1999
My comment here (#7) should not be considered valid in favor or against this bug. As Stefan alluded to, I tracked my problem down to what could be considered a version incompatibility between (2.6.12/libraw1.2.0) and (2.6.13/libraw1.2.1); not even related to 64bit architecture. In effect, though my problem is solved, this bug may very well not be.
Re comment #10: AFAIU everything should work since Andi's patch (comment #8) except ioctls by 32bit userland on 64bit kernel. http://kerneltrap.org/node/6528 http://lwn.net/Articles/119652/ (raw1394 has two interfaces for isochronous operation, an obsolete one and the recommended one, called rawiso. The latter uses ioctls. Anything else doesn't.)
Fixes posted by Petr Vandrovec: http://marc.info/?t=117858638000102
Xavier, Can you test the new kernel and confirm the problem is gone? Thanks.
Alas Andi's patch was insufficient. Petr's patches are required too but these aren't merged yet. They are in linux1394-2.6.git and hence in -mm. They will be sent to Linus after 2.6.22 is out/ before 2.6.23-rc1. But this still doesn't complete the 32bit user on 64bit kernel fixes. AFAIK: - struct compat_raw1394_req shouldn't be packed on PPC. - struct arm_request needs a compat_ counterpart.
> - struct compat_raw1394_req shouldn't be packed on PPC. [PATCH] ieee1394: raw1394: fix a 32/64-bits compat fix http://lkml.org/lkml/2007/7/4/253
Several fixes were merged in 2.6.23-rc1, at last. Only the struct arm_request seems to remain in need of a fix.
Closing this bug, because the arm_ functionality is not related to what the reporters use.