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.
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.
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, before someone just had to rewrite the
1394 stuff again?
--
Cheers, Gene
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).
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.
> 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?
> before someone just had to rewrite the 1394 stuff again?
The 1394 kernel drivers are not being rewritten. 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.)
--
Stefan Richter
-=====-=-==- =-=- -=-==
http://arcgraph.de/sr/
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@diablo ~]# 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@diablo ~]# 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
Gene Heskett wrote:
> Stefan Richter wrote:
>> 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
...
> No 64 bit kernels ever, this has always been a 32 bit install.
Hmm.
...
> 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]
There should be a message like "ieee1394: Host added: ID:BUS[0-00:1023]
GUID..." shortly later. It's logged at kern.debug level though.
> Then, manually loaded via 'modprobe raw1394':
>
> Oct 16 11:50:11 diablo kernel: ieee1394: raw1394: /dev/raw1394 device
> initialized
OK.
> 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
I don't get what this is about. Who denies what?
> SELinux is in permissive mode, and /dev/raw1394 has perms of:
> [root@diablo ~]# 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.
There should be something like "ieee1394: Node added: ID:BUS[0-00:1023]
GUID..." and that the host changed from 0-00 to 1-00 at kern.debug level.
> 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.
...
>> 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.
...
>>> 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.
I don't remember what was changed at that time. Maybe that was the
addition of the new isochronous interface that I mentioned. The old one
was (is?) still there but maybe there were interactions... However this
is not related to the inability to issue AV/C commands, which are issued
asynchronously. I think though that your kino 0.8.x package is
configured to work isochronously via video1394(?) but asynchronously via
raw1394, and the kino 0.9.x package to do both via raw1394. But don't
take my word on it, I keep mistaking one interface for another. I never
used video cameras on FireWire myself.
> 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@diablo ~]# dvcont dev 0 play
> Could not find any AV/C devices on the 1394 bus.
>
> The camera is still plugged in and powered up.
Anything under /sys/bus/ieee1394/devices?
It might be not too difficult to compile 1394commander since it doesn't
have many library dependencies; just libraw1394 (probably as -devel
package) and optionally readline. Gscanbus would show a bit more about
attached devices without resorting to magic commands but it is a bit
harder to compile, as a GUI program.
--
Stefan Richter
-=====-=-==- =-=- =----
http://arcgraph.de/sr/
Stefan Richter wrote:
> Gene Heskett wrote:
>> Stefan Richter wrote:
>>> 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
> ...
>> No 64 bit kernels ever, this has always been a 32 bit install.
>
> Hmm.
>
> ...
>> 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]
>
> There should be a message like "ieee1394: Host added: ID:BUS[0-00:1023]
> GUID..." shortly later. It's logged at kern.debug level though.
I had udev set for debug earlier, lemme check the older log.
In logs reaching back 8 days while I messed with this, the string
"ieee1394: Host added: ID:BUS" never appears.
>> Then, manually loaded via 'modprobe raw1394':
>>
>> Oct 16 11:50:11 diablo kernel: ieee1394: raw1394: /dev/raw1394 device
>> initialized
But there are lots of the above, and hundreds of:
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 775 forked, pid
[2645], 'add' 'ieee1394', 0 seconds old
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 777 forked, pid
[2646], 'add' 'ieee1394', 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2645]: wait_for_sysfs: file
'/sys/devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0/08004601044684e4/bus
' appeared after 0 loops
Oct 15 19:47:32 diablo udevd-event[2645]: pass_env_to_socket: passed -1
bytes to socket '/org/kernel/udev/monitor',
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_hotplugd'
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_hotplugd' returned with status 0
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_devd'
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_devd' returned with status 0
Oct 15 19:47:32 diablo udevd-event[2645]: pass_env_to_socket: passed 242
bytes to socket '/org/freedesktop/hal/udev_event',
Oct 15 19:47:32 diablo udevd-event[2645]: udev_event_run: seq 775 finished
Oct 15 19:47:32 diablo udevd[417]: udev_done: seq 775, pid [2645] exit
with 0, 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2646]: wait_for_sysfs: file
'/sys/devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0/623f0200cbe5407d/bus
' appeared after 0 loops
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 776 forked, pid
[2649], 'add' 'ieee1394_node', 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2646]: pass_env_to_socket: passed -1
bytes to socket '/org/kernel/udev/monitor',
Oct 15 19:47:32 diablo udevd-event[2646]: run_program:
'/lib/udev/udev_run_hotplugd'
Oct 15 19:47:32 diablo udevd-event[2649]: pass_env_to_socket: passed -1
bytes to socket '/org/kernel/udev/monitor',
Oct 15 19:47:32 diablo udevd-event[2646]: run_program:
'/lib/udev/udev_run_hotplugd' returned with status 0
Oct 15 19:47:32 diablo udevd-event[2649]: run_program:
'/lib/udev/udev_run_hotplugd'
Oct 15 19:47:32 diablo udevd-event[2646]: run_program:
'/lib/udev/udev_run_devd'
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 779 forked, pid
[2651], 'add' 'ieee1394', 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2651]: wait_for_sysfs: file
'/sys/devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0/08004601044684e4/080
04601044684e4-0/bus' appeared after 0 loops
> OK.
>
>> 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
>
> I don't get what this is about. Who denies what?
>
It just says denied, but selinux is set permissive, so thats just a
report of what would be denied if it was fully enabled.
>> SELinux is in permissive mode, and /dev/raw1394 has perms of:
>> [root@diablo ~]# 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.
>
> There should be something like "ieee1394: Node added: ID:BUS[0-00:1023]
> GUID..." and that the host changed from 0-00 to 1-00 at kern.debug level.
Never happens.
>
>> 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.
> ...
>>> 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.
> ...
>>>> 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.
>
> I don't remember what was changed at that time. Maybe that was the
> addition of the new isochronous interface that I mentioned. The old one
> was (is?) still there but maybe there were interactions... However this
> is not related to the inability to issue AV/C commands, which are issued
> asynchronously. I think though that your kino 0.8.x package is
> configured to work isochronously via video1394(?)
Its showing raw1394, the other choice is dvgrab, which doesn't...
but asynchronously via
> raw1394, and the kino 0.9.x package to do both via raw1394. But don't
> take my word on it, I keep mistaking one interface for another. I never
> used video cameras on FireWire myself.
>
>> 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@diablo ~]# dvcont dev 0 play
>> Could not find any AV/C devices on the 1394 bus.
>>
>> The camera is still plugged in and powered up.
>
> Anything under /sys/bus/ieee1394/devices?
[root@diablo ~]# ls -R /sys/bus/ieee1394/devices
/sys/bus/ieee1394/devices:
08004601044684e4 08004601044684e4-0 623f0200cbe5407d
623f0200cbe5407d-0 fw-host0
and:
[root@diablo ~]# ls -l /sys/bus/ieee1394/devices/fw-host0
lrwxrwxrwx 1 root root 0 Oct 16 11:16 /sys/bus/ieee1394/devices/fw-host0
-> ../../../devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0
[root@diablo ~]#
>
> It might be not too difficult to compile 1394commander since it doesn't
> have many library dependencies; just libraw1394 (probably as -devel
> package) and optionally readline. Gscanbus would show a bit more about
> attached devices without resorting to magic commands but it is a bit
> harder to compile, as a GUI program.
I'll put in the devel stuff and give it a shot. And let the lists know.
Thanks, Stefan
--
Cheers, Gene
Stefan Richter wrote:
> Gene Heskett wrote:
[...]
>> There should be a message like "ieee1394: Host added: ID:BUS[0-00:1023]
>> GUID..." shortly later. It's logged at kern.debug level though.
>I had udev set for debug earlier, lemme check the older log.
>In logs reaching back 8 days while I messed with this, the string
>"ieee1394: Host added: ID:BUS" never appears.
>> Then, manually loaded via 'modprobe raw1394':
>>
>> Oct 16 11:50:11 diablo kernel: ieee1394: raw1394: /dev/raw1394 device
>> initialized
But there are lots of the above, and hundreds of:
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 775 forked, pid
[2645], 'add' 'ieee1394', 0 seconds old
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 777 forked, pid
[2646], 'add' 'ieee1394', 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2645]: wait_for_sysfs: file
'/sys/devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0/08004601044684e4/bus
' appeared after 0 loops
Oct 15 19:47:32 diablo udevd-event[2645]: pass_env_to_socket: passed -1
bytes to socket '/org/kernel/udev/monitor',
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_hotplugd'
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_hotplugd' returned with status 0
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_devd'
Oct 15 19:47:32 diablo udevd-event[2645]: run_program:
'/lib/udev/udev_run_devd' returned with status 0
Oct 15 19:47:32 diablo udevd-event[2645]: pass_env_to_socket: passed 242
bytes to socket '/org/freedesktop/hal/udev_event',
Oct 15 19:47:32 diablo udevd-event[2645]: udev_event_run: seq 775 finished
Oct 15 19:47:32 diablo udevd[417]: udev_done: seq 775, pid [2645] exit
with 0, 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2646]: wait_for_sysfs: file
'/sys/devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0/623f0200cbe5407d/bus
' appeared after 0 loops
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 776 forked, pid
[2649], 'add' 'ieee1394_node', 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2646]: pass_env_to_socket: passed -1
bytes to socket '/org/kernel/udev/monitor',
Oct 15 19:47:32 diablo udevd-event[2646]: run_program:
'/lib/udev/udev_run_hotplugd'
Oct 15 19:47:32 diablo udevd-event[2649]: pass_env_to_socket: passed -1
bytes to socket '/org/kernel/udev/monitor',
Oct 15 19:47:32 diablo udevd-event[2646]: run_program:
'/lib/udev/udev_run_hotplugd' returned with status 0
Oct 15 19:47:32 diablo udevd-event[2649]: run_program:
'/lib/udev/udev_run_hotplugd'
Oct 15 19:47:32 diablo udevd-event[2646]: run_program:
'/lib/udev/udev_run_devd'
Oct 15 19:47:32 diablo udevd[417]: udev_event_run: seq 779 forked, pid
[2651], 'add' 'ieee1394', 0 seconds old
Oct 15 19:47:32 diablo udevd-event[2651]: wait_for_sysfs: file
'/sys/devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0/08004601044684e4/080
04601044684e4-0/bus' appeared after 0 loops
> OK.
>
>> 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
>
> I don't get what this is about. Who denies what?
>
It just says denied, but selinux is set permissive, so thats just a
report of what would be denied if it was fully enabled.
>> SELinux is in permissive mode, and /dev/raw1394 has perms of:
>> [root@diablo ~]# 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.
>
> There should be something like "ieee1394: Node added: ID:BUS[0-00:1023]
> GUID..." and that the host changed from 0-00 to 1-00 at kern.debug level.
Never happens.
>
>> 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.
> ...
>>> 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.
> ...
>>>> 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.
>
> I don't remember what was changed at that time. Maybe that was the
> addition of the new isochronous interface that I mentioned. The old one
> was (is?) still there but maybe there were interactions... However this
> is not related to the inability to issue AV/C commands, which are issued
> asynchronously. I think though that your kino 0.8.x package is
> configured to work isochronously via video1394(?)
Its showing raw1394, the other choice is dvgrab, which doesn't...
but asynchronously via
> raw1394, and the kino 0.9.x package to do both via raw1394. But don't
> take my word on it, I keep mistaking one interface for another. I never
> used video cameras on FireWire myself.
>
>> 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@diablo ~]# dvcont dev 0 play
>> Could not find any AV/C devices on the 1394 bus.
>>
>> The camera is still plugged in and powered up.
>
> Anything under /sys/bus/ieee1394/devices?
[root@diablo ~]# ls -R /sys/bus/ieee1394/devices
/sys/bus/ieee1394/devices:
08004601044684e4 08004601044684e4-0 623f0200cbe5407d
623f0200cbe5407d-0 fw-host0
and:
[root@diablo ~]# ls -l /sys/bus/ieee1394/devices/fw-host0
lrwxrwxrwx 1 root root 0 Oct 16 11:16 /sys/bus/ieee1394/devices/fw-host0
-> ../../../devices/pci0000:00/0000:00:14.4/0000:03:04.2/fw-host0
[root@diablo ~]#
>
> It might be not too difficult to compile 1394commander since it doesn't
> have many library dependencies; just libraw1394 (probably as -devel
> package) and optionally readline. Gscanbus would show a bit more about
> attached devices without resorting to magic commands but it is a bit
> harder to compile, as a GUI program.
I'll put in the devel stuff and give it a shot. And let the lists know.
I did find, with googles help, some rpms of 1394commander and gscanbus,
but they don't work here.
gscanbus bus displays two icons, one for the device (ohci1394) running
at 400megabaud, and the camera running at 100 megabaud. Clicking on
either icon locks it, but it does respond to a ctl+c in the shell the
launched it.
And 1394commander has problems with my readline library I think:
[root@diablo src]# 1394commander
1394commander: symbol lookup error: /usr/lib/libreadline.so.5:
I believe its way too long in the tooth for modern 1394 snooping as its
3 years old or more.
I tried to build the src rpm of gscanbus, but it autoedits gscanbus.c,
wrapping long lines which then fail to compile due to missing final " in
a 2+ line text argument. Its there, but the compiler apparently expects
to see the ending " on the same line as opposed to 2-3 lines below.
Thanks, Stefan
--
Cheers, Gene
--
fedora-list mailing list
[email protected]
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
On Monday 16 October 2006 2:38 pm, Stefan Richter wrote:
> Gene Heskett wrote:
> > 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.
> ...
> > 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.
>
> I don't remember what was changed at that time. Maybe that was the
> addition of the new isochronous interface that I mentioned. The old one
> was (is?) still there but maybe there were interactions...
Allow me to help clarify. There are 4 interfaces for capturing DV--I kid you
not! One is video1394, which Kino has never supported for capture. Kino 0.8.0
supports legacy raw1394 and dv1394 switchable via Preferences. Gene is using
the legacy raw1394 in that version, based upon a screenshot he sent. Kino
0.9.2 supports dv1394 and libiec61883 (atop raw1394 rawiso) switchable ONLY
at build time requiring an explicit configure option for dv1394. This is to
coerce builders to the newest and best capture interface.
> However this is not related to the inability to issue AV/C commands, which
> are issued asynchronously.
Correct; it is very curious that his device is not recognized via configROM
probes and does not respond to AV/C control commands. This now impacts Kino
0.9.2 with libiec61883 (Gene's configuration) because I simplified the UI for
the typical case--the one where 1394 asynch works. In that case, the first
recognized camera during a bus traversal (or selectable via a simple pulldown
menu) lets Kino determine on which 1394 port this device sits in order to
make capture "just work." (permissions issues to /dev/raw1394 aside :-) It is
very rare that someone can capture but not have AV/C and device recognition.
The majority of problem reports are just the opposite with the majority
resolved by unloading eth1394!
--
+-DRD-+
[...]
This is going to sound rather silly, because I did try a couple of
earlier kernels before I started posting about this problem.
Tonight, I saw that kernel-2.6.18-1.2200.fc5.i686 was available, along
with the matching kmod-ndiswrapper pieces and kmod-ntfs in versions
2.6.18-1.2200.fc5 were available, so I installed them and rebooted.
Now kino-0.8 works sortof, wants to crash.
And kino-0.9.2 apparently works flawlessly, as does dvcont.
Looking into the logs, I see this during the boot:
Oct 16 20:20:29 diablo kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI):
IRQ=[10] MMIO=[c0209000-c02097ff] Max Packet=[2048] IR/IT contexts=[
4/8]
Oct 16 20:20:29 diablo kernel: audit(1161044396.750:4): avc: denied {
getattr } for pid=1310 comm="pam_console_app" name="raw1394" dev=tmpfs
ino=4494 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 20:20:29 diablo kernel: audit(1161044396.750:5): avc: denied {
setattr } for pid=1310 comm="pam_console_app" name="raw1394" dev=tmpfs
ino=4494 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
And I believe the camera was plugged in and powered up during the boot
as there are no further messages in the log & I've been playing with a
very wide grin on my face for about half an hour with it.
So it was a kernel problem all along!
Just one question here. Am I the only idiot that actually wants to do
work on linux? On second thought, I might not like the answer :-)
Anyway, end of thread, till the next time :)
--
Cheers, Gene
Dan Dennedy wrote:
> On Monday 16 October 2006 2:38 pm, Stefan Richter wrote:
>> Gene Heskett wrote:
>>> 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.
>> ...
>>> 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.
>> I don't remember what was changed at that time. Maybe that was the
>> addition of the new isochronous interface that I mentioned. The old one
>> was (is?) still there but maybe there were interactions...
>
> Allow me to help clarify. There are 4 interfaces for capturing DV--I kid you
> not! One is video1394, which Kino has never supported for capture. Kino 0.8.0
> supports legacy raw1394 and dv1394 switchable via Preferences. Gene is using
> the legacy raw1394 in that version, based upon a screenshot he sent. Kino
> 0.9.2 supports dv1394 and libiec61883 (atop raw1394 rawiso) switchable ONLY
> at build time requiring an explicit configure option for dv1394. This is to
> coerce builders to the newest and best capture interface.
>
>> However this is not related to the inability to issue AV/C commands, which
>> are issued asynchronously.
>
> Correct; it is very curious that his device is not recognized via configROM
> probes and does not respond to AV/C control commands. This now impacts Kino
> 0.9.2 with libiec61883 (Gene's configuration) because I simplified the UI for
> the typical case--the one where 1394 asynch works. In that case, the first
> recognized camera during a bus traversal (or selectable via a simple pulldown
> menu) lets Kino determine on which 1394 port this device sits in order to
> make capture "just work." (permissions issues to /dev/raw1394 aside :-) It is
> very rare that someone can capture but not have AV/C and device recognition.
> The majority of problem reports are just the opposite with the majority
> resolved by unloading eth1394!
>
After a fresh install of kernel-2.6.18-1.2200.fc5 and friends tonight,
it all, for kino-0.9.2, Just Works(TM) with one minor exception. The
sound I hear while not capturing is intermittently all tore up, very
choppy. This effect seems to come and go at random intervals, but I
didn't notice it when playing back the capture later.
All previous kernels were 2.6.17-1 with whatever the redhat folks
patched in for their usage.
FWIW, even dvcont works now. So ATM, and until I get that wedding tape
into my hands (its at home, while I'm sitting in a motel waiting on a
freight shipment that SHOULD have been here Sept 28th, am a happy camper
but twiddling my arthritic thumbs to the point of needing pain meds.
In other words, YIPPEE!
--
Cheers everybody, Gene
Dan Dennedy wrote:
> On Monday 16 October 2006 2:38 pm, Stefan Richter wrote:
>> Gene Heskett wrote:
>>> 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.
>> ...
>>> 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.
>> I don't remember what was changed at that time. Maybe that was the
>> addition of the new isochronous interface that I mentioned. The old one
>> was (is?) still there but maybe there were interactions...
>
> Allow me to help clarify. There are 4 interfaces for capturing DV--I kid you
> not! One is video1394, which Kino has never supported for capture. Kino 0.8.0
> supports legacy raw1394 and dv1394 switchable via Preferences. Gene is using
> the legacy raw1394 in that version, based upon a screenshot he sent. Kino
> 0.9.2 supports dv1394 and libiec61883 (atop raw1394 rawiso) switchable ONLY
> at build time requiring an explicit configure option for dv1394. This is to
> coerce builders to the newest and best capture interface.
>
>> However this is not related to the inability to issue AV/C commands, which
>> are issued asynchronously.
>
> Correct; it is very curious that his device is not recognized via configROM
> probes and does not respond to AV/C control commands. This now impacts Kino
> 0.9.2 with libiec61883 (Gene's configuration) because I simplified the UI for
> the typical case--the one where 1394 asynch works. In that case, the first
> recognized camera during a bus traversal (or selectable via a simple pulldown
> menu) lets Kino determine on which 1394 port this device sits in order to
> make capture "just work." (permissions issues to /dev/raw1394 aside :-) It is
> very rare that someone can capture but not have AV/C and device recognition.
> The majority of problem reports are just the opposite with the majority
> resolved by unloading eth1394!
>
Let me append that with this kernel, gscanbus also works as expected,
including controlling the camera. Wahoo!
--
Cheers, Gene
Gene Heskett wrote:
..
> Tonight, I saw that kernel-2.6.18-1.2200.fc5.i686 was available, along
> with the matching kmod-ndiswrapper pieces and kmod-ntfs in versions
> 2.6.18-1.2200.fc5 were available, so I installed them and rebooted.
>
> Now kino-0.8 works sortof, wants to crash.
> And kino-0.9.2 apparently works flawlessly, as does dvcont.
...
> So it was a kernel problem all along!
...
I have no idea what we did between 2.6.17 and .18 that made it work. Or
was it just the reboot after kernel update which brought it into shape?
--
Stefan Richter
-=====-=-==- =-=- =---=
http://arcgraph.de/sr/
Stefan Richter wrote:
> Gene Heskett wrote:
> ..
>> Tonight, I saw that kernel-2.6.18-1.2200.fc5.i686 was available, along
>> with the matching kmod-ndiswrapper pieces and kmod-ntfs in versions
>> 2.6.18-1.2200.fc5 were available, so I installed them and rebooted.
>>
>> Now kino-0.8 works sortof, wants to crash.
>> And kino-0.9.2 apparently works flawlessly, as does dvcont.
> ...
>> So it was a kernel problem all along!
> ...
>
> I have no idea what we did between 2.6.17 and .18 that made it work. Or
> was it just the reboot after kernel update which brought it into shape?
It was rebooted many times on the previous kernel. This kernel also
'feels' considerably faster.
--
Cheers, Gene