Hi, Just to add to Bryan's data here's the short story on the machine. It's an EMachines P4HT machine with SMP disabled. It runs Gentoo:
dragonfly ~ # emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo- r11 i686) ================================================================= System uname: 2.6.11-gentoo-r11 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.12 I can supply all the emerge info output if required. As a user type I don't understand who'd responsible in this case for /proc. I thought /proc was something that the system sets up, not ivtv. (At least for PCI devices.) Could this be a really low level problem with Linux and this chipset? (Intel I865 based.) dragonfly ~ # lspci 0000:00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 0000:00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) 0000:00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 0000:00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 0000:00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) 0000:00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 0000:00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 0000:00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 0000:00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 0000:00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 0000:01:01.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) 0000:01:02.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) 0000:01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) dragonfly ~ # Thanks, Mark On 6/29/05, Bryan Mayland <[EMAIL PROTECTED]> wrote: > I've been working with Mark Knecht tracking down his problem with his > cards not initializing properly every boot. We're using the PCI > subsystem information to say "card 0 is a 250", but when we map the io > and start chatting on the I2C, we've obviously got a 150. We detect > card 1 as a 150, but it is clearly a 250 once we talk to it. Mark's > been really great about providing me information. Finally I've hit a > brick wall with this bit of information: > > --- WORKING BOOUP --- > cat /proc/bus/pci/01/01.0 | od -Ax -t x1 > 000000 44 44 16 00 06 00 10 02 01 00 00 04 08 40 00 00 > 000010 08 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 > 000020 00 00 00 00 00 00 00 00 00 00 00 00 70 00 03 80 > 000030 00 00 00 00 44 00 00 00 00 00 00 00 05 01 80 08 > cat /proc/bus/pci/01/02.0 | od -Ax -t x1 > 000000 44 44 16 00 06 00 10 02 01 00 00 04 08 40 00 00 > 000010 08 00 00 f4 00 00 00 00 00 00 00 00 00 00 00 00 > 000020 00 00 00 00 00 00 00 00 00 00 00 00 70 00 09 40 > 000030 00 00 00 00 44 00 00 00 00 00 00 00 03 01 80 08 > > --- BUSTED BOOTUP --- > cat /proc/bus/pci/01/01.0 | od -Ax -t x1 > 000000 44 44 16 00 06 00 10 02 01 00 00 04 08 40 00 00 > 000010 08 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 > 000020 00 00 00 00 00 00 00 00 00 00 00 00 70 00 03 00 > 000030 00 00 00 00 44 00 00 00 00 00 00 00 05 01 80 08 > cat /proc/bus/pci/01/02.0 | od -Ax -t x1 > 000000 44 44 16 00 06 00 10 02 01 00 00 04 08 40 00 00 > 000010 08 00 00 f4 00 00 00 00 00 00 00 00 00 00 00 00 > 000020 00 00 00 00 00 00 00 00 00 00 00 00 70 00 09 00 > 000030 00 00 00 00 44 00 00 00 00 00 00 00 03 01 80 08 > > Note that the difference between the two is that the PCI subsystem > device field statring at 0x2e is cleared in the non-working system. > This throws off our autodetection and causes us to set up wrong, as that > byte is significant: > device 00 03 -> PVR250 > device 80 03 -> PVR150 > device 00 09 -> PVR150 > device 40 09 -> PVR250 > > Has anyone ever seen this behavior? How in the heck can this be > happening? It is rather consistent, and only that one byte gets messed up! > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > ivtv-devel mailing list > ivtv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ivtv-devel > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
