LinHES Forums
http://forum.linhes.org/

UDEV sucks!!!!!
http://forum.linhes.org/viewtopic.php?f=2&t=13882
Page 1 of 4

Author:  alexvd [ Sat Jan 27, 2007 6:04 pm ]
Post subject:  UDEV sucks!!!!!

Hi upgraded from RD51 to RE50 recently. My pvr-250 cards are not working and I am getting errors in the logs:

2007-01-27 18:47:31.609 adding: mythtvmasterbackend as a client (events: 1)
2007-01-27 18:47:31.625 MainServer::HandleAnnounce Playback
2007-01-27 18:47:31.644 adding: mythtvmasterbackend as a client (events: 0)
2007-01-27 18:47:31.695 TVRec(5): Changing from None to WatchingLiveTV
2007-01-27 18:47:31.699 TVRec(5): HW Tuner: 5->5
2007-01-27 18:47:32.881 ret_pid(3100) child(3100) status(0x0)
2007-01-27 18:47:32.884 External Tuning program exited with no error
2007-01-27 18:47:34.230 MPEGRec(/dev/video4) Warning: MPEG Layer1 does not work
properly with ivtv driver.
Using MPEG layer 2 audio instead.
2007-01-27 18:47:34.235 MPEGRec(/dev/video4) Error: Could not set MPEG controls
2 through 0.
eno: Numerical result out of range (34)
2007-01-27 18:48:20.714 TVRec(5): Changing from WatchingLiveTV to None
2007-01-27 18:48:20.728 Finished recording CBS Evening News: channel 2002
2007-01-27 18:48:20.804 scheduler: Finished recording: CBS Evening News: channel
2002
2007-01-27 18:50:44.773 Expiring CBS Evening News from Sat Jan 27 18:30:00 2007,
0 MBytes, forced expire (LiveTV recording)
2007-01-27 18:50:44.781 autoexpire: Expiring Program: Expiring CBS Evening News
from Sat Jan 27 18:30:00 2007, 0 MBytes, forced expire (LiveTV recording)
2007-01-27 18:58:52.682 MainServer::HandleAnnounce Monitor


It looks like i am sharing interrupts. I did do enable the bios setting for plug and play os, but I have no option to reset the defaults. I have 5 capture cards in the box plus the agp graphics so I might have challenges.

root@mythtvmasterbackend:~# cat /proc/interrupts
CPU0
0: 7436637 XT-PIC timer
1: 18 XT-PIC i8042
2: 0 XT-PIC cascade
7: 3 XT-PIC ivtv0
8: 1 XT-PIC rtc
10: 0 XT-PIC cx88[1], cx88[1]
11: 555047 XT-PIC cx88[0], cx88[0], nvidia
12: 13114 XT-PIC cx88[2], cx88[2], ivtv1, eth0
14: 14893 XT-PIC ide0
15: 135 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 1
MIS: 0


Here is the output for ivtv

Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv: ==================== START INIT IVTV ====================
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv: version 0.8.2 (tagged release) loading
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv: Linux version: 2.6.18-chw-13 SMP preempt mod_unload 586 gcc-4.1
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv: In case of problems please include the debug info between
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv: the START INIT IVTV and END INIT IVTV lines, along with
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv: any module options, when mailing the ivtv-users mailinglist.
Jan 27 15:00:13 mythtvmasterbackend kernel: cx88[2]/0: found at 0000:02:0a.0, rev: 5, irq: 12, latency: 64, mmio: 0xe5000000
Jan 27 15:00:13 mythtvmasterbackend kernel: cx88[2]/0: registered device video2 [v4l2]
Jan 27 15:00:13 mythtvmasterbackend kernel: cx88[2]/0: registered device vbi2
Jan 27 15:00:13 mythtvmasterbackend kernel: cx88[2]/0: registered device radio2
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Enabling device 0000:02:0a.2 (0014 -> 0016)
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Found IRQ 12 for device 0000:02:0a.2
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Sharing IRQ 12 with 0000:02:02.0
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Sharing IRQ 12 with 0000:02:0a.0
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Sharing IRQ 12 with 0000:02:0e.0
Jan 27 15:00:13 mythtvmasterbackend kernel: cx88[2]/2: found at 0000:02:0a.2, rev: 5, irq: 12, latency: 64, mmio: 0xe4000000
Jan 27 15:00:13 mythtvmasterbackend kernel: cx88[2]/2: cx2388x based dvb card
Jan 27 15:00:13 mythtvmasterbackend kernel: DVB: registering new adapter (cx88[2]).
Jan 27 15:00:13 mythtvmasterbackend kernel: DVB: registering frontend 2 (Oren OR51132 VSB/QAM Frontend)...
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Autodetected Hauppauge card (cx23416 based)
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Enabling device 0000:02:0b.0 (0014 -> 0016)
Jan 27 15:00:13 mythtvmasterbackend kernel: PCI: Found IRQ 7 for device 0000:02:0b.0
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
Jan 27 15:00:13 mythtvmasterbackend kernel: tuner 4-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Jan 27 15:00:13 mythtvmasterbackend kernel: msp3400 4-0040: MSP4448G-A2 found @ 0x80 (ivtv i2c driver #0)
Jan 27 15:00:13 mythtvmasterbackend kernel: msp3400 4-0040: MSP4448G-A2 supports radio, mode is autodetect and autoselect
Jan 27 15:00:13 mythtvmasterbackend kernel: saa7115 4-0021: saa7115 found @ 0x42 (ivtv i2c driver #0)
Jan 27 15:00:13 mythtvmasterbackend kernel: tveeprom 4-0050: Hauppauge model 32032, rev B310, serial# 6985383
Jan 27 15:00:13 mythtvmasterbackend kernel: tveeprom 4-0050: tuner model is Philips FI1236 MK2 (idx 10, type 2)
Jan 27 15:00:13 mythtvmasterbackend kernel: tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
Jan 27 15:00:13 mythtvmasterbackend kernel: tveeprom 4-0050: audio processor is MSP4448 (idx 27)
Jan 27 15:00:13 mythtvmasterbackend kernel: tveeprom 4-0050: decoder processor is SAA7115 (idx 19)
Jan 27 15:00:13 mythtvmasterbackend kernel: tveeprom 4-0050: has no radio, has IR remote
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Autodetected Hauppauge WinTV PVR-250
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Encoder revision: 0x02050032
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Registered device video3 for encoder MPEG
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Registered device video32 for encoder YUV
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Registered device vbi3 for encoder VBI
Jan 27 15:00:13 mythtvmasterbackend kernel: ivtv0: Registered device video24 for encoder PCM audio
Jan 27 15:00:13 mythtvmasterbackend kernel: tuner 4-0061: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles))
:
I also checked the ivtv section

alias char-major-81 videodev
alias char-major-61 lirc_i2c
#options ivtv debug=1
#options tuner type=2
options msp3400 once=1
install ivtv /sbin/modprobe tuner; /sbin/modprobe msp3400; /sbin/modprobe saa7115; /sbin/modprobe --ignore-install ivtv
remove ivtv /sbin/modprobe -r --ignore-remove ivtv && /sbin/modprobe -r saa7115 && /sbin/modprobe -r msp3400 && /sbin/modprobe -r tuner

Author:  tjc [ Sat Jan 27, 2007 6:26 pm ]
Post subject: 

You're already running the latest version for the 2.6.18 kernel. It almost looks like to used the wrong card type. See the mythtv-setup configuration walk through on the BlackScreenWatchingTV wiki page.

When you get to Capture Cards, delete all of them and recreate them following the directions on the wiki, and note that there is a difference between MPEG and MPEG2 cards. When you do that, don't forget it means you need to redo the Input Connections too.

Author:  alexvd [ Sat Jan 27, 2007 6:49 pm ]
Post subject: 

Interesting I selected the pvr-x50 its odd. I am aware of the difference between the framegrabber cards.

I also redid the card inputs.

it detects as happaugge card below.

I had to delete them all already in fact I did it several times. I have 3 PCHDTV cards that are 0, 1, and 2. I wonder if the analog (frame grabber) function is somehow screwing things up. The PVR 250 were normally dev/video 3 and 4 respectively.

Strange I have never had this issue before.

Author:  tjc [ Sat Jan 27, 2007 7:06 pm ]
Post subject: 

Is your card order getting scrambled by udev? I know that's sending a lot of folks to the house of pain...

Author:  alexvd [ Sat Jan 27, 2007 7:35 pm ]
Post subject: 

Funny you should mention that. I wanted change the order of my capture cards because I have low power frontends who crash because the first source they grab is PCHDTV HD channels. They are too low power so they basically dump back to the desktop. As I understand it the order in which you add the capture cards determines which capture card has priority.

So I deleted them all and re-added them. Things got wierd from here. All of a sudden I had the PCHDTV cards inserting themselves out of order in wierd spots even though I was adding sequentially. Kinda like this

pchdtv 0
pvr-250 video 3
pchdtv 1
pchdtv 2
pvr-250 video 4

I had to add in reverse order is the best way I could describe. What was really odd was the numbering convention got screwed up. So they were be reported as

6
23
24
25
26

I had to delete them all again and reboot the box. A restart of the backend wouldnt work. After this they reported properly in sequence. Its important to note the PCHDTV card capture or Pass the HD streams with no issues. In fact RE50 is noticeably faster than any other release when it come to starting LiveTV. However the PVR-250 don't work.

Author:  tjc [ Sat Jan 27, 2007 7:39 pm ]
Post subject: 

There is a fix available. See this posting for how to nail down the card definitions to avoid this kind of screwy behavior... http://mysettopbox.tv/phpBB2/viewtopic.php?t=13520

Author:  alexvd [ Sat Jan 27, 2007 8:26 pm ]
Post subject: 

Man this is PIA. Can't I just disable plug and play OS in bios. I did for a very long time in fact I thought we were supposed to with knoppmyth. I just recently enabled plug and play.

So i need to go and create local rules file udev for both of my pvr250 cards. It appears he has only 1. He set it up for just /dev/video. My cards are currently
/dev/video3
/dev/video 4

I followed his steps and the info about the cards looks similar. See below.

root@mythtvmasterbackend:~# udevinfo -e |less
root@mythtvmasterbackend:~# udevinfo -a -p /class/video4linux/video3

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/class/video4linux/video3':
KERNEL=="video3"
SUBSYSTEM=="video4linux"
DRIVER==""
ATTR{name}=="ivtv0 encoder MPEG"
ATTR{dev}=="81:3"

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:02:0b.0':
KERNELS=="0000:02:0b.0"
SUBSYSTEMS=="pci"
DRIVERS=="ivtv"
ATTRS{broken_parity_status}=="0"
ATTRS{enable}=="1"
ATTRS{modalias}=="pci:v00004444d00000016sv00000070sd00004009bc04sc00i00"
ATTRS{local_cpus}=="ffffffff"
ATTRS{irq}=="7"
ATTRS{class}=="0x040000"
ATTRS{subsystem_device}=="0x4009"
ATTRS{subsystem_vendor}=="0x0070"
ATTRS{device}=="0x0016"
ATTRS{vendor}=="0x4444"

looking at parent device '/devices/pci0000:00/0000:00:1e.0':
KERNELS=="0000:00:1e.0"
SUBSYSTEMS=="pci"
DRIVERS==""
ATTRS{broken_parity_status}=="0"
ATTRS{enable}=="1"
ATTRS{modalias}=="pci:v00008086d00002418sv00000000sd00000000bc06sc04i00"
ATTRS{local_cpus}=="ffffffff"
ATTRS{irq}=="0"
ATTRS{class}=="0x060400"
ATTRS{subsystem_device}=="0x0000"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{device}=="0x2418"
ATTRS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

Author:  bruce_s01 [ Sun Jan 28, 2007 8:57 pm ]
Post subject: 

As I understand it, what you basically do is try to use the comparison parts of the assignments (the ones "==" in them) to identify the devices. Some of these are going to be the same for the two cards, but there should be a difference between the ATTR{dev} and the KERNELS id ("0000:02:0b.0" in the sample you gave).
If you rerun udevinfo -a -p for video3 and 4, you should see the differences between the two cards.

I don't know what will it do if you assign them to video3 and video4 to "fix" their location. I've currently got a system that's working well, so I don't want to break it. :) But I've got a sneaking suspicion that I need to place the file higher in the udev order (ie lower the prefix in the symlink from "z99" to say "a01").

Bruce S.

Author:  tjc [ Mon Jan 29, 2007 12:10 am ]
Post subject: 

Bruce, that's the PCI bus ID so it's generally a safe difference to use. It should only change if you physically move the cards to different slots on the motherboard. You can find the Bus ID using the lspci command. The numbers in the left column are the Bus ID.

Author:  alexvd [ Mon Jan 29, 2007 12:51 pm ]
Post subject: 

so this is the only way to go? what happens when i have to upgrade to a newer version of knoppmyth? will it break again?

Does this not happen on clean builds of R5e50?

Author:  tjc [ Mon Jan 29, 2007 7:12 pm ]
Post subject: 

alexvd wrote:
Does this not happen on clean builds of R5e50?

Yeah. It's just part of the wonderful new udev world. I made the fstab entries for my removable and SATA drives use the disk label rather than the device names because of this.

As for breaking in the future, that why the backups grab all of your /etc tree. You can extract the files and integrate your fix with the new ones. I'd probably script it myself. If you kept a copy of the original file, do a "diff -c oldfilename newfilename" between the two versions and save that as a patch...

Author:  brendan [ Mon Jan 29, 2007 7:57 pm ]
Post subject: 

Is it likely that udev will randomly shuffle device->card assignments forever?

I can't see how that would be a feature...

Or will that stop after some defaults are set in upcoming kernel releases?

-brendan

Author:  alexvd [ Mon Jan 29, 2007 8:53 pm ]
Post subject: 

So udev is like a plug and play right? Could I just not disable plug and play os in the bios. Or will that not affect udev.

Author:  bruce_s01 [ Tue Jan 30, 2007 9:32 am ]
Post subject: 

My suspicion is that this was unexpected result.
In most circumstances, there are going to be no problems if you are running with a single type of card with a single source.

Bruce S.

Author:  alexvd [ Wed Jan 31, 2007 4:50 pm ]
Post subject: 

so are you saying that if you run multiple tuners with a couple of lineups that you will have issues.

I think cecil would disagree. One of the major benefits of myth is its scalability vs other solutions.

Page 1 of 4 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/