:-) I know the feeling: been bitten by the "let's just quickly do this upgrade"-bug too...
Don't have any experience with Gentoo or emerge, so can't really help you there. Compiling 2.6.15 from kernel.org and ivtv-0.4.1 (and later 0.4.3) from ivtvdriver.org worked without a problem, except for not compiling msp3400 due to disabled bt848 support. Does the 'emerge' method by any chance add aliases to modules.conf? Stanley. > I guess the problems are more annoying because many of the changes > (eg. changing the name of the tuner device) cause problems for people > who had working systems before. I come from a FreeBSD background, not > Linux, so my expectations are a little different I suppose. FreeBSD > tends to lag behind the cutting edge support for new devices > (particularly non-server ones) but regression problems seem far fewer > (and this isn't specific to the ivtv driver in my experience of the > Linux world so far). > > This one bit me because I had a working system and a quick "emerge > ivtv" broke it. My fault I guess, and I'll do what I can to help work > it out and see if the ivtv can be improved. This isn't to belittle > the great work behind the ivtv driver. I am sure it isn't easy > without comprehensive documentation of the hardware. > > Anyhow, can anyone clarify the relationship between eeprom, tuner, > ivtv and msp3400 and which versions of each are meant to work with > different kernel versions, which ones should come from the ivtv > source and which should be installed from the kernel? > > Looks like for me I need to go back to 0.3.x and some (don't yet > know) old kernel release. But before I do, is it worth me running > ivtv in some sort of debug mode to gather more information about the > exact nature of the problem? > > I probably only have a day or two before some members of the > household rebel against not having TV... :-< > > > Cheers > Ari Maniatis > > > > On 26/02/2006, at 5:26 AM, [EMAIL PROTECTED] wrote: > >> >> Hi, >> >> Well, actually, the eeprom, tuner and msp3400 (and perhaps more, but I >> cannot think of them) modules were already part of the kernel >> before ivtv, >> but were split off early in the development cycle of ivtv to speed up >> development. >> >> The difficult part is now to merge these changes back into the >> original >> V4L modules, so they can eventually become part of the kernel >> again. In my >> opinion Hans is doing a great job working towards this goal... >> >> I believe that the biggest changes with regard to this merge >> occured in >> 0.4.1, but I'm not sure; could be 0.4.0 too... >> >> Regards, >> Stanley. >> >> >>> >>> On 25/02/2006, at 3:08 AM, Tyler Trafford wrote: >>> >>>> Yeah, but one of those is a PVR150, which does not have an >>>> msp3400 in >>>> it. >>> >>> Ah. That's helpful. I just tried moving back to 0.4.0 and kernel >>> 2.6.14 and got a slightly different startup error: >>> >>> : drive cache: write back >>> sdb:<6>ivtv0: i2c attach to card #0 ok [client=saa7115, addr=21] >>> msp34xx: ivtv version >>> msp34xx: init: chip=MSP3415D-B3, has NICAM support, simple (D) mode >>> msp34xx: $Id$ compiled on: Feb 25 2006 00:32:38 >>> msp3410: daemon started >>> ivtv0: i2c attach to card #0 ok [client=MSP3415D-B3, addr=40] >>> sdb1 >>> Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 >>> ivtv0: loading /lib/modules/ivtv-fw-enc.bin >>> ivtv0: loading /lib/modules/ivtv-fw-dec.bin >>> ivtv0: Encoder revision: 0x02050032 >>> ivtv0: Decoder revision: 0x02020023 >>> ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB >>> total) >>> ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers (2048KB >>> total) >>> ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB >>> total) >>> ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers >>> (2048KB total) >>> ivtv0: Create encoder radio stream >>> tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) by >>> ivtv i2c driver #0 >>> msp34xx: I/O error #1 (read 0x10/0x200) >>> msp34xx: I/O error #2 (read 0x10/0x200) >>> msp34xx: I/O error #3 (read 0x10/0x200) >>> msp34xx: I/O error #1 (read 0x10/0x200) >>> msp34xx: giving up, reseting chip. Sound will go off, sorry folks :-| >>> >>> >>> Because the dmesg buffer is being filled by those lines line >>> repeating many times, that is actually the very top of the buffer so >>> I can't see what came before. Strange that the CVS "$Id" tag is in >>> there. >>> >>> I might have to try and go back to 0.3.x where everything worked >>> fine. At what kernel/ivtv versions did msp3400 move into the kernel? >>> >>> Cheers >>> Ari Maniatis >>> >>> >>> >>> >>> --------------------------> >>> ish >>> http://www.ish.com.au >>> Level 1, 30 Wilson Street Newtown 2042 Australia >>> phone +61 2 9550 5001 fax +61 2 9550 4001 >>> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 >>> >>> >>> >>> _______________________________________________ >>> ivtv-devel mailing list >>> [email protected] >>> http://ivtvdriver.org/mailman/listinfo/ivtv-devel >>> >>> >>> >> >> >> >> _______________________________________________ >> ivtv-devel mailing list >> [email protected] >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel > > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 > > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > > > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
