Since 2.6.23 I don't get my tvcard working anymore. I didn't change any bttv relating kernel-config. And I have still gentoo-sources-2.6.21-r4 installed where the tvcard works perfectly. If I boot 2.6.23-r5 (or any other of the 2.6.23 series) I get /dev/video0 invalid argument when I try to start a tv application like tvtime. Reproducible: Always Steps to Reproduce: 1. boot 2.6.23-r* 2. start tvtime Actual Results: error message in tvtime: /dev/video0 invalid argument And I don't get any signal from the tvcard, neither pic nor sound. In mplayer I get: ioctl get capabilites failed: Inappropriate ioctl for device Expected Results: tv picture Tested Applications: tvtime, mplayer, Skype, aMSN,
Created attachment 139721 [details] Error message in mplayer
Created attachment 139722 [details] Issue of dmesg
Ah I forgot: /dev/video0 is a symlink and points to /dev/v4l/video0 /dev/v4l: total 0 drwxr-xr-x 2 root root 100 Dec 18 17:53 . drwxr-xr-x 12 root root 14840 Dec 18 17:55 .. crw-rw---- 1 root video 81, 64 Dec 18 17:53 radio0 crw-rw---- 1 root video 81, 224 Dec 18 17:53 vbi0 crw-rw---- 1 root video 171, 16 Dec 18 17:53 video0 lspci: 01:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 01:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) And my user is member of the group video.
Created attachment 139724 [details] Kernel-Config
In the non-working kernel and working kernel can you post the outputs of: lsmod also attach both .config files.
Created attachment 139837 [details] Kernel-Config-2.6.21-r4 The first .config is of 2.6.23-r5 lsmod doesn't seem to be very helpful, because I used to compile the bttv module into the kernel. lsmod: Module Size Used by libafs 476080 3 lirc_i2c 7748 2 lirc_dev 12296 1 lirc_i2c nvidia 6208880 34 ne2k_pci 9412 0 8390 8448 1 ne2k_pci
Can you test with vanilla-sources.2.6.24_rc8 and post the result here?
I tried it now with 2.6.24. Same behaviour. Still invalid argument.
I got it working again. I used to compile the bttv driver directly into the kernel. Appearantly that doesn't seem to work since 2.6.23. You have to compile the bttv driver now as a module. Is there a known reason why? Close the bug or leave it open?
Would you be able to test 2.6.25_rc4. I'd like to see if the problem using the driver when built into the kernel has been addressed.
Please reopen if you want to investigate building it in the kernel in later versions.
Sorry, I have to wait until the Reiser4-Patch. My root partition is on Reiser4.
Sorry for reopen a temporarely solved problem. In 2.6.23 and 2.6.24 I had to compile bttv as module. In 2.6.25 it worked also with the compiled-in driver. But now I upgraded to 2.6.26 and again I get the same error like in 2.6.23 and 2.6.24. It works as module but not compiled in. However it works as a module so there's no importance to put a lot of work onto it.
Sven, can you please test with gentoo-sources-2.6.27
> can you please test with gentoo-sources-2.6.27 bttv compiled as module works perfect. Fix built in into kernel gives me also in 2.6.27 the error of the invalid argument.
OK, lets dig into this. First of all, please attach dmesg output from after loading the bttv modules (in the situation where the card works fine). I want to compare the initialization messages to the failing case in comment #2. Next, please apply the patch I am attaching to this ticket below to 2.6.27, and compile with bttv as built-in so that it fails as described in this bug. Boot into the new kernel, run mplayer to check the failure. Then capture dmesg output to a file and attach it here (there may be some messages added). Lastly, capture the strace output of a failing mplayer: strace mplayer -tv driver=v4l2:height=240:width=320 tv://se12 > strace.log and attach strace.log here thanks!
Created attachment 170217 [details, diff] patch
Created attachment 170327 [details] dmesg, bttv as module, module autoloaded while booting
Created attachment 170328 [details] dmesg, bttv built in, just booted
Created attachment 170329 [details] output of mplayer, bttv built in
Created attachment 170331 [details] mplayer with strace The first file (01_dmesg.txt) is without patch. For the other logs I patched the kernel.
Created attachment 170332 [details] the real strace-output Sorry for the German output of mplayer in 04_mplayer.txt. For some reason I don't know, export LC_ALL=C mplayer ... didn't work to get the output it in English.
(In reply to comment #19) > Created an attachment (id=170328) [edit] > dmesg, bttv built in, just booted > Was this captured immediately after boot, or immediately after running mplayer? My request is for you to capture dmesg after running mplayer (and seeing it fail).
I did it before and after starting mplayer. The output of dmesg was identical. With other words, running mplayer didn't add any message into dmesg.
Can you post the output of "stat -L /dev/video0" from both a working modular kernel and a broken builtin kernel? Thanks.
Created attachment 170994 [details] working modular kernel
Created attachment 170996 [details] broken compiled-in kernel
Would you mind double checking those results? I'm wondering if you got them the wrong way around. Your "broken compiled-in kernel" attachment says: Device type: 51,0 but this is what I would expect to be the working configuration. and your "working modular kernel" attachment says: Device type: ab,10 and this is just downright strange. Number "ab" is reserved for firewire. I'm really surprised that actions made on /dev/video0 get through to bttv in this case. Can you please double check? I would expect that the broken configuration gives ab, and the working configuration gives 51, but the labelling of your attachments contradicts this.
(In reply to comment #28) > I would expect that the broken configuration gives > ab, and the working configuration gives 51, but the labelling of your > attachments contradicts this. > You were right. The working config is 51 and the broken one ab
Thanks! That makes more sense, we are closer to the problem. Next up, firstly for the working kernel: Please post output of: udevinfo -q path -n /dev/video0 note: if using a brand new udev, then replace udevinfo with "udevadm info" e.g.: udevadm info -q path -n /dev/video0 (and same for all further instructions) The output refers to a directory under /sys, which in turn will include a file named 'dev'. Please post it's contents. You can read it with this command: cat /sys/$(udevinfo -q path -n /dev/video0)/dev Then repeat the above for the broken kernel. Thanks!
Working modular kernel version: dev: 81 card: 10 index: 0 name: BT878 video (Hauppauge (bt878)) uevent: MAJOR=81, MINOR=0 Not working compiled-in kernel version: udevadm: /devices/virtual/ieee1394_protocol/video1394-0 dev: 171:16 uevent: MAJOR=171, MINOR=16 It seems, the video-device was assigned to the firewire port. The firewire-connection is provided by my pci Soundblaster sound card and also compiled in into the kernel.
OK.. we've been looking at /dev/video0 I assume you also have a /dev/video1 ? I think the issue is that /dev/video0 and /dev/video1 are swapping around in these two different configurations.
Broken version: la /dev/vid* lrwxrwxrwx 1 root root 10 9. Nov 17:41 /dev/video -> v4l/video0 lrwxrwxrwx 1 root root 10 9. Nov 17:41 /dev/video0 -> v4l/video0 lrwxrwxrwx 1 root root 10 9. Nov 17:41 /dev/video1394-0 -> v4l/video0 udevadm info -q path -n /dev/video1394-0 /devices/virtual/ieee1394_protocol/video1394-0 There are 3 videosymlinks all showing to the firewire-device.
Which version of udev is installed?
actual: 130-r1 But I had this problem since kernel-2.6.23. And since this kernel there have been some udev-updates.
Please upgrade to udev-133 (130 was buggy) and post output of: udevadm test /devices/virtual/ieee1394_protocol/video1394-0
Created attachment 174093 [details] udevadm test with bttv driver compiled in - kernel-2.6.27-r1
Created attachment 174094 [details] udevadm test bttv compiled as module - kernel-2.6.27-r1
Created attachment 174096 [details] udevadm test bttv compiled in - kernel-2.6.27-r4
Created attachment 174098 [details] udevadm test bttv compiled as module - kernel-2.6.27-r4
Strange. Indepedent of udev in kernel-2.6.27-r1 bttv didn't work as compiled in. But in 2.6.27-r4 it does. It seems the problem has been (temporarely) solved at least with kernel-2.6.27-r4.
I suspect that's just a coincidence and it will not hold. Or did you include a udev-135 upgrade? I see changes in the rules files which were causing this bug. Maybe udev-135 has fixed it?
Last udev version installed is 133. Upgrade to 135 I haven't included yet. I just booted the two kernel versions with the two different configurations. That was the only difference. The kernel configs of 27-r1 and 27-r4 are also the same. When upgrading I did just make oldconfig.
OK, probably just a coincidence as I don't think there have been relevant changes in the kernel between those 2 versions. I found out that udev rules are what was creating a v4l-style node for the video1394 device, but fortunately those rules are gone in udev-135. So, if this does reappear, please ensure you are running udev-135 or newer before reopening this bug.
