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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <4533DDA2.2050008@verizon.net>
Date:	Mon, 16 Oct 2006 15:29:38 -0400
From:	Gene Heskett <gene.heskett@...izon.net>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	linux-kernel@...r.kernel.org,
	For users of Fedora Core releases 
	<fedora-list@...hat.com>, linux1394-user@...ts.sourceforge.net
Subject: Re: raw1394 problems galore

Stefan Richter wrote:
> On 10/16/2006, Gene Heskett wrote to lkml and fedora-list:
>> Greetings all;
>>
>> After about 4 days of snooping around trying to get kino, either 08.xx 
>> or 0.9.2, to run here, I'm getting noplace at a very high rate of speed.
>>
>> System is an HP dv5120us lappy, with ddual boot of xp and FC5, with FC5 
>> about as uptodate as can be managed when the kmod stuff is always 1 or 2 
>> versions behind the kernel, so I'm still running 2.6.17-1.2174_FC5 for a 
>> kernel.
>>
>> Specifically, kino-0.8.0-2.lvn5.i386.rpm can receive and record a/v from 
>> my camera, a Sony TRV-460, but cannot control it via the av/c controls 
>> as it cannot 'see' a device to do the controls in the prefs->ieee1394 
>> screen.
> 
> Could be version problems between kernel--library--app. Maybe somebody
> else knows more about it. But it's more probably the same problem as the
> following:
> 
>> Then kino-0.9.2-1.lvn5.i386.rpm cannot even see the raw1394 interface, 
>> reporting on its screen that the raw1394 kernel module isn't loaded, or 
>> that it cannot read/write /dev/raw1394.
> 
> HP dv5120us is based on Turion 64. Do you run a 64bit kernel on it? Then
> the following bug may prevent access:
> http://bugzilla.kernel.org/show_bug.cgi?id=4779
> The bug has been fixed for read and write operations on /dev/raw1394 in
> Linux 2.6.17 (actually 2.6.16-git11).

No 64 bit kernels ever, this has always been a 32 bit install.

> The bug has _not_ been fixed yet for "ioctl" operations. The so-called
> rawiso interface for isochronous transmission and reception uses ioctls.
> I suppose the older Kino version could have slightly more success for
> you simply because it uses a different interface for iso transmission
> and reception.
> 
> My last comment in the bugzilla entry points to explanations on
> 64bit<-->32bit compatibility code for ioctls, in case anybody feels up
> to hack the kernel and contribute the rest of the fix.
> 
> Gene, if you run a 64bit kernel, check if you could switch to a 32bit
> kernel --- if only to confirm or deny that this is indeed the bug that
> is biting your setup. Another thing to try is to test whether gscanbus
> or 1394commander can work with raw1394. But as the _very first step_,
> check the kernel log for messages from the 1394 drivers.
After last reboot, having reset udev.conf for err only, as debug is so 
verbose it prevents booting if wlan0 is enabled.

Oct 16 11:16:31 diablo kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): 
IRQ=[10]  MMIO=[c0209000-c02097ff]  Max Packet=[2048]  IR/IT contexts=[
4/8]

Then, manually loaded via 'modprobe raw1394':

Oct 16 11:50:11 diablo kernel: ieee1394: raw1394: /dev/raw1394 device 
initialized
Oct 16 11:50:11 diablo kernel: audit(1161013811.874:4): avc:  denied  { 
getattr } for  pid=2753 comm="pam_console_app" name="raw1394" dev=tmpfs
  ino=10625 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Oct 16 11:50:11 diablo kernel: audit(1161013811.874:5): avc:  denied  { 
setattr } for  pid=2753 comm="pam_console_app" name="raw1394" dev=tmpfs
  ino=10625 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 
tcontext=system_u:object_r:device_t:s0 tclass=chr_file

SELinux is in permissive mode, and /dev/raw1394 has perms of:
[root@...blo ~]# ls -l /dev/raw1394
crw-rw-rw- 1 root root 171, 0 Oct 16 11:50 /dev/raw1394

As I had given up, the camera is packed away, but I'll get it out and 
connect it again for grins:

And no further messages were logged when I plugged it in and turned it on.

kino-0.8 receives video from it in real time and is doing so right now, 
and can capture it to file, and then play/edit that file, or could 
saturday when I last tried it.  I ASSume that kino-0.9.2 could also 
play/edit that file, but have not verified that by reinstalling 0.9.2.

>> The module is loaded when the cable is plugged in, and the 
>> /etc/security/console.perms.d/50-defaults has been edited so that 
>> /dev/raw1394 as created by the hotplug event now has these perms:
>> crw-rw-rw- 1 root root 171, 0 Oct 15 20:20 /dev/raw1394
>>
>> This has had no effect on the performance of either version of kino.
>>
>> So when do we actually get a functioning firewire interface, which we 
>> DID have 18 months ago in FC2,
> 
> Did you run FC2 as 32bit environment on 32bit kernel?

Yes, and kino-0.7.5 died with kernel changes in the ieee1394 code 
someplace at about 2.6.9 IIRC.  That FC2 box is my kernel test box, is 
950 miles SE of me in West Virginia and powered down ATM, but its 
running 2.6.19-rc1 just fine except for the ieee1394 problems.  That was 
why I thought I'd see if I could make it work here on my lappy with FC5 
and release kernels. I upgraded from kernel-2.6.17-1.2174_FC5 to 
kernel-2.6.17-1.2187_FC5 this morning with no detectable difference.

>> before someone just had to rewrite the 1394 stuff again?
> 
> The 1394 kernel drivers are not being rewritten.

I was told it was a total rewrite of bad code when I complained about a 
year ago.  My reply at the time was that it worked, and I don't often 
fix things that are working.  I'm getting lazy in my dotage I guess.

  We just discover old
> bugs, try to fix them on a rather slow rate, and sometimes introduce
> regressions along with bug fixes. (We try not to do so, but there is
> weird hardware out there.) I think similar things can be said about the
> status quo of libraw1394's development; minus the regressions I hope. I
> don't know about the other libraries and about the status of the
> application software. The last big "rewrite" concerning the whole stack
> from kernel to apps was the addition of the rawiso programming
> interface, which was quite a long time ago, but migration of application
> programs to it seems to be a still ongoing process, including
> deployment. (Even Linux 2.4 has the rawiso interface.)
> 
> (I added linux1394-user to the Cc list. You don't need to subscribe
> there; just keep all Ccs during the discussion.)

As for 1394commander or gscanbus, I have not managed to find rpms of 
those in any of the repos yumex or SPM shows me.  They apparently are 
not part of the FC5 tree.  I'd love to see what those 2 might have to 
say about the system.  The only thing I do have is dvcont, which reports 
this:

[root@...blo ~]# dvcont dev 0 play
Could not find any AV/C devices on the 1394 bus.

The camera is still plugged in and powered up.

Thanks Stefan.  Silly Q though, are you any kin to Thomas, a math prof 
at math-tu?  I've known him since back in my amiga days.

-- 
Cheers, Gene

-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ