On Sun, 2009-01-25 at 10:44 -0500, Jeff Campbell wrote: > Andy, > > My apologies, it would be more useful to put the full dmesg output, > and in fact you can see as soon as eth1 comes up that the errors > start, so its definitely a conflict with eth1,
Not necessarily. As long as the eth1 driver stays in it's memory mapped IO window and cx18 stays in it's MMIO windows, it's not a conflict. It's likely a lot of PCI bus activity coupled with a buggy bridge chip or marginal bus signals causing problems in successfully writing the cx18 firmware image. > but I'm unsure of my options to resolve it. Two suggested mitigations which you may try in any order: 1. Remove all PCI cards, blow dust out of all the slots, reseat all the cards. The PCI bus uses reflected wave signaling: it relies on voltage waves propagating down the bus and being refelected back from the unterminated end of the bus to bring the signaling voltages up to the proper level by the time the bits are to be clocked-in. Poor connections anywhere on the PCI bus can affect that needed, reflected part of the voltage signals. 2. Blacklist cx18 in /etc/modporbe.conf or /etc/modporbe.d/blacklist to prevent it from being loaded at boot. The modprobe cx18 it sometime later when the PCI bus isn't so busy. I still think the somewhat interleave cx18 firmware loads will create a lot of activity on the bus though. > I've tried disabling anyting on the PCI bus that I don't need in the > BIOS but I can't seem to get the system to reallocate the IRQs. The disabling devices may help only in that Linux won't make so many accesses to device on the PCI bus when some devices are disabled. That just treats a symptom, but not the cause. Moving PCI IRQs can only be done in one of two ways AFAIK: moving the card to a different slot, or telling the card to use something other than the PCI INTA line (not an option for most devices including the CX23418). I don't think serving IRQs at this early stage is the problem though. > Linux video capture interface: v2.00 > cx18: Start initialization, version 1.0.4 > cx18-0: Initializing card #0 > cx18-0: Autodetected Hauppauge card > cx18 0000:00:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > cx18-0: Unreasonably low latency timer, setting to 64 (was 32) > cx18-0: cx23418 revision 01010000 (B) > input: PC Speaker as /class/input/input5 > tveeprom 0-0050: Hauppauge model 74541, rev C6B6, serial# 5117034 > tveeprom 0-0050: MAC address is 00-0D-FE-4E-14-6A > tveeprom 0-0050: tuner model is Philips FM1236 MK5 (idx 116, type 43) > tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08) > tveeprom 0-0050: audio processor is CX23418 (idx 38) > tveeprom 0-0050: decoder processor is CX23418 (idx 31) > tveeprom 0-0050: has radio > cx18-0: Autodetected Hauppauge HVR-1600 > cx18-0: Raw VBI supported; Sliced VBI is not yet supported > tuner 1-0043: chip found @ 0x86 (cx18 i2c driver #0-1) > tda9887 1-0043: creating new instance > tda9887 1-0043: tda988[5/6/7] found > tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) > cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > tuner-simple 1-0061: creating new instance > tuner-simple 1-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or > FM1236/F)) > cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB) > DVB: registering new adapter (cx18) > MXL5005S: Attached at address 0x63 > DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB > Frontend)... > cx18-0: DVB Frontend registered > cx18-0: Registered DVB adapter0 for TS (32 x 32 kB) > cx18-0: Registered device video32 for encoder YUV (16 x 128 kB) > cx18-0: Registered device vbi0 for encoder VBI (60 x 17328 bytes) > cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB) > cx18-0: Registered device radio0 for encoder radio > cx18-0: Initialized card #0: Hauppauge HVR-1600 > cx18-1: Initializing card #1 > cx18-1: Autodetected Hauppauge card > cx18 0000:00:0d.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 > cx18-1: Unreasonably low latency timer, setting to 64 (was 32) > cx18-1: cx23418 revision 01010000 (B) > tveeprom 2-0050: Hauppauge model 74541, rev C6B6, serial# 5117196 > tveeprom 2-0050: MAC address is 00-0D-FE-4E-15-0C > tveeprom 2-0050: tuner model is Philips FM1236 MK5 (idx 116, type 43) > tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08) > tveeprom 2-0050: audio processor is CX23418 (idx 38) > tveeprom 2-0050: decoder processor is CX23418 (idx 31) > tveeprom 2-0050: has radio > cx18-1: Autodetected Hauppauge HVR-1600 > cx18-1: Raw VBI supported; Sliced VBI is not yet supported > tuner 3-0043: chip found @ 0x86 (cx18 i2c driver #1-1) > tda9887 3-0043: creating new instance > tda9887 3-0043: tda988[5/6/7] found > tuner 3-0061: chip found @ 0xc2 (cx18 i2c driver #1-1) > cs5345 2-004c: chip found @ 0x98 (cx18 i2c driver #1-0) > tuner-simple 3-0061: creating new instance > tuner-simple 3-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or > FM1236/F)) > cx18-1: Registered device video1 for encoder MPEG (64 x 32 kB) > DVB: registering new adapter (cx18) > MXL5005S: Attached at address 0x63 > DVB: registering adapter 1 frontend 0 (Samsung S5H1409 QAM/8VSB > Frontend)... > cx18-1: DVB Frontend registered > cx18-1: Registered DVB adapter1 for TS (32 x 32 kB) > cx18-1: Registered device video33 for encoder YUV (16 x 128 kB) > cx18-1: Registered device vbi1 for encoder VBI (60 x 17328 bytes) > cx18-1: Registered device video25 for encoder PCM audio (256 x 4 kB) > cx18-1: Registered device radio1 for encoder radio > cx18-1: Initialized card #1: Hauppauge HVR-1600 > cx18: End initialization So far so good. > warning: `ntpd' uses 32-bit capabilities (legacy support in use) > firmware: requesting v4l-cx23418-cpu.fw > cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) > firmware: requesting v4l-cx23418-apu.fw > firmware: requesting v4l-cx23418-cpu.fw > cx18-1: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) > firmware: requesting v4l-cx23418-apu.fw > cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) > cx18-1: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) > cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) > firmware: requesting v4l-cx23418-cpu.fw > firmware: requesting v4l-cx23418-apu.fw > cx18-1: Retry loading firmware > firmware: requesting v4l-cx23418-cpu.fw > cx18-1: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) > firmware: requesting v4l-cx23418-apu.fw > cx18-1: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes) > firmware: requesting v4l-cx23418-dig.fw > cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 bytes) > cx18-1: Failed to initialize on minor 5 > cx18-1: FW version: 0.0.74.0 (Release 2007/03/12) So when looking at the above remeber 3 things: a) cx18 loads the CPU and APU firmware for each CX23418 device twice b) each of the load attempts in a) is allowed 1 Retry c) We only print out the EPU_DEBUG message with the "Release 2007" string when the CPU is up and running after the first load, we supress it for the second CPU firmware load. Since it is processed in a work handler, it will likely show up in the logs at later time. Notice that cx18-0 made two CPU/APU firmware loads with no retries and the expected one "Release 2007" string. That unit should be OK. Notice that cx18-1 made the first CPU/APU firmware load with no retries and we got a "Release 2007" string, but that the second CPU/APU firmware load was retried, and did fail after the second retry: "Failed to initialize on minor 5". > r8169: eth1: link up > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > cx18-1: Failed to initialize on minor 5 > usb 2-1.4: USB disconnect, address 4 Well, this is the cx18 driver being kind of pig-headed. It refuses to try the firmware load process again on subsequent open() attempts, if it has failed once. I'm torn on whether to change that. On the one hand, it will allow possibly marginal setup to load firmware and "work" (for some defintion of "work"), but on the other hand, that will possibly mask marginal setups and likely generate a host of apparently unrelated symptom reports. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
