Humm, well ill look into adjusting the latency on the pci bus though i have played with that before with no luck but i have little to know how on doing that, but to rule out both kernel/driver/firmware conflict and to check and make sure that the drives stop failing(dont want to lose data no matter what the cause is), i disable ivtv in the master myth system so if a drive fails again it has nothing to do with ivtv, and update the system in the slave to the same kernel and ivtv version on the master and enable the tuner (i have had it disabled while trying to work this out on the master first) i found that with the same driver version and kernel version i get the same audio issue (only hardware that is simmiler is the tuner) so i tryed the register setting # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=1 register 0x810 set to 0x1 # v4l2-dbg -r type=i2cdrv,chip=cx25840,reg=0x810,val=0 register 0x810 set to 0x0 and it does fix the audio like set audio trick, i cant find any older version for the audio chipset and the older version of the encoder chipset that i can find does not work. so that does not work, and for the other suggestions im not sure where to start on those.
on the note on the drives its a driver issue, i couldn't even initially build the array from the live cd till i built an install with the 2.6.25 kernel, i have lots of cooling, and a 1000w power supply(planned for large power demand) as for bus and latency i have no idea where to start there but if i can identify that as an issue and i cant resolve it ill need to move to a hardware raid pcie controller Kevin Andy Walls wrote: > On Sat, 2008-06-28 at 19:18 -0300, Kevin Blair wrote: >> ok ill give that a try, though i think i may have another direction that >> could be the issue, i had a suspicion but since i had a very similar >> issue with out ivtv affecting things i didnt think so, but due to the >> failure i just had and recovered from, i am suspecting it may be! >> >> i noticed a point on one of the ivtv posts about ivtv and sata drives, >> now over all i have had little issue and nothing directly relating to >> that post so i didnt think it was related, but i have a raid5 array with >> 4 drives setup, and i have bin having an intermittent issue of one of >> the drives fails out (SDC) and goes non responcive, and i had an issue >> building the array (same issue) when building the array with an older >> kernel driver, but with the newer 2.6.25 kernel i dont have the building >> issue but every so often the drive fails and my raid array goes >> degraded, not a big deal and not that often, reboot remove and add drive >> and it rebuilds and it works fine, but now i have the "temp >> set-audio-input fix" i had enabled, dissabled for testing and i didnt >> enable it again, and there was a recording starting the same time the >> drives failed, and not just one went out but 3 out of the 4 went out, >> but since they simply went offline and not bad, i was able to recover >> with no data lost, any chance that it could be an incompatibly with the >> sata_mv libata driver for the chipset: >> 00:0e.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) >> 00:0e.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) >> 00:0e.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) >> and ivtv causeing both my drives to fail out and ivtvs bad audio? > > PCI bus load for disk I/O and an ivtv capture simultaneously could cause > an error on the PCI bus that adversely affects disk operations. > > Using lspci, you should review your PCI bus latency settings against > each card's MIN_GRANT (minimum desired latency timer setting) and > MAX_LAT (maximum interval the device should be held off the bus), and > thus the overall throughput of the shared PCI bus that each device wants > when most active. You should also look for Parity Errors, System > Errors, and Master and Slave aborts on the PCI bus as these can indicate > problems. > > > ivtv bad audio would be independent of disk problems though. Here's a > simple block diagram of how broadcast TV audio moves through a PVR-150: > > > Antenna --> Tuner ---> CX25843 -----> CX23416 ----> PCI Bus ---> Memory > RF SIF I2S(?) MPEG MPEG > > > The the tinny audio is likely happening inside the CX25843, when the > microcontroller firmware program inside modifies how it demodulates > analog Sound Intermediate Frequency (SIF), probably because the firmware > audio standard autodetection routines may have a bug. There is also a > chance that the CX23416 is doing something wrong with the digital I2S > serial audio stream, but this also would be a firmware bug. > > Audio digitization, demodulation, filtering, and encoding is well > removed from the PCI bus. If you've commanded an MPEG capture and the > audio starts out OK, no PCI bus error is going to change that audio to > sound differently (tinny) unless you're actively trying to command the > ivtv board to change it's audio related processing. > > > > >> attached is the syslog file of the errors outputed pertaining to the >> drive failures if its of any use to see if this is the issue, also all >> the drives have bin checked to see that they are good drives, and sdc >> has bin replaced with a good offline spare i had last time i had a >> failure to rule out bad drives. > > I cannot really comment on your drives or mobo chipset without a lot > more research. Suffice to say, make sure power and cooling are up to > the job. > > Since the PCI bus is a shared resource (although PCIe legs aren't), an > analysis of PCI bus timing and typical demand by your devices will let > you know your potential for PCI bus bottlenecks. Doing raid in software > to individual SATA controllers (as opposed to a hardware RAID > controller) is going to chew up a bit of PCI bus bandwidth during disk > access, I'd imagine. Throwing video capture on the shared PCI bus on > top of software RAID will stress things further during disk access. > > Just my $0.02. > > Regards, > Andy > >> Thank you so much for any help if this is the cause of both of my issues. >> >> Kevin >> >> >> Andy Walls wrote: >>> On Thu, 2008-06-26 at 10:41 -0300, [EMAIL PROTECTED] >>> wrote: >>>> ok, here is the debug reports, i did the fallowing, i got the system to be >>>> producining the bad audio >>>> and generated the log status file, and a debug file, then i used the >>>> set-audio-input switch which >>>> brought the audio to being normal, and generated another set of logs and >>>> debug logs >>>> since this is little difference in the log status i am only posting the >>>> diff of the 2, as for the debugs >>>> im not sure what you need so im posting the full log of both and a diff. >>> I've looked at the diff's. Some comments are in line below. Basically >>> the significant differences are in the audio decoder register block of >>> the cx28543. Unfortunately most of the differences are in >>> undocumented/reserved register regions. >>> >>> The ones in the AC'97 audio codec register region very likely don't >>> matter as ivtv and PVR-150's don't use this interface. >>> >>> The undocumented registers in the range 0x880-0x89f being different tell >>> me the audio micrcontroller is doing something differently in the two >>> cases, but that may or may not be the cause of the tinny audio. >>> >>> >>>> please let me know if you need any more information thanks for the help. >>> The next time you get tinny audio, could you use v4l2-dbg to set >>> register 0x810 to 1 and then back to 0. This toggles the SOFT_RESET of >>> the audio microcontroller, and should get it to try and redetect the >>> audio standard. (IIRC the driver does this as one of the steps when >>> switching inputs.) If that fixes things, you will have then verified >>> that the audio microcontroller firmware in the cx25843 is getting >>> confused. >>> >>> >>> If that is the case you have some courses of action which are limited >>> because the firmware source is not available: >>> >>> 1. Experiment with different versions of the Mako (cx2854x) firmware to >>> see if there is one that doesn't produce the tinny audio problem. >>> >>> 2. Try to reliably detect tinny audio from within a program polling the >>> ivtv driver, and when you detect the tinny audio condition, run a >>> utility to reset the audio microcontroller or take some other corrective >>> action. >>> >>> 3. Since you know the TV standards you normally capture, limit the >>> auto-detection of audio standard to the one you capture. I don't think >>> v4l2-ctl supports this right now, and the driver may not currently >>> easily support anything other than autodetection of audio standard. >>> (I'd need to do more research on this.) >>> >>> >>> [snip] >>>> Diff of the 2 >>>> -----------------------Start----------------------------- >>>> --- ivtv.good.dbg 2008-06-25 21:52:06.659558323 -0300 >>>> +++ ivtv.bad.dbg 2008-06-25 21:51:19.185396931 -0300 >>>> @@ -6,7 +6,7 @@ >>>> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F >>>> 00000100: 33 84 00 d0 00 dc 04 07 0f 04 0a 18 fe e2 2b 00 >>>> 00000110: e5 d6 98 00 00 8c 07 00 02 00 00 00 00 00 00 00 >>>> -00000120: 00 00 01 10 87 b6 30 50 f8 93 11 a0 ff 5f 20 11 >>>> +00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11 >>> ^^ >>> This may not matter: GPIO0 was 0 for good, 1 for bad >>> >>>> 00000130: 00 00 00 00 02 18 0a 00 00 00 00 00 00 00 36 00 >>>> 00000140: 04 f0 00 00 10 32 54 76 00 00 00 00 00 00 00 00 >>>> 00000150: 00 00 00 00 00 00 00 00 00 e1 86 10 00 e1 86 06 >>>> @@ -18,7 +18,7 @@ >>>> 00000230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> >>>> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F >>>> -00000400: 01 e2 04 00 2e 25 10 00 00 80 00 00 00 91 7d 00 >>>> +00000400: 01 e2 04 00 2e 25 10 00 00 80 00 00 00 81 7d 00 >>> ^^ >>> This doesn't matter: Video field was odd (good) vs. even (bad) >>> >>>> 00000410: bf 07 ff 7f 00 7e 00 00 00 00 08 00 00 00 08 00 >>>> 00000420: 7e 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> 00000430: 00 00 00 00 00 00 00 00 00 00 00 00 06 00 f0 ff >>>> @@ -26,7 +26,7 @@ >>>> 00000450: 01 00 00 03 0d c4 08 26 77 88 00 54 00 00 00 00 >>>> 00000460: 02 14 0a 34 6e ca 36 06 e7 00 00 08 20 f6 84 02 >>>> 00000470: 7a 00 2d 5b 1a 70 1e 1a 1f 02 50 66 1f 7c 08 00 >>>> -00000480: db 02 00 00 00 00 60 42 1a 32 06 f8 dc 40 10 00 >>>> +00000480: b0 03 00 00 00 00 60 42 1a 2f 06 f8 dc 40 10 00 >>> ^^^^^ ^^^^^ >>> Vid Field count doesn't matter Vid AGC value probably doesn't matter >>> >>>> 00000490: 8a 02 3f cd 00 03 1f 16 22 00 00 00 14 00 50 14 >>>> 000004a0: 0f 02 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> 000004b0: 00 00 00 00 03 00 00 00 01 00 00 00 00 00 00 00 >>>> @@ -40,8 +40,8 @@ >>>> 00000850: 55 5f a1 00 30 00 00 00 00 00 00 00 3e 70 00 80 >>>> 00000860: b8 01 ca 00 00 00 00 01 00 00 00 00 00 00 00 00 >>>> 00000870: 00 00 00 00 00 00 00 00 7e 05 7e 05 88 45 a2 06 >>>> -00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 bd 01 65 00 >>>> +00000880: da 07 3c 0b e1 ca 03 40 30 70 30 70 da 01 64 00 >>> ^^ ^^ >>> Internal/reserved audio microcontroller registers differ >>> >>>> -00000890: 24 f4 03 40 30 70 30 70 85 0c 21 02 4f 01 ba 04 >>>> +00000890: 24 f4 03 40 30 70 30 70 d3 0c 00 01 5b 01 16 05 >>> ^^ ^^^^^^^^ ^^^^^ >>> Internal/reserved audio microcontroller registers differ >>> >>>> 000008a0: 78 06 d6 12 87 51 00 00 de 53 03 00 b1 01 00 00 >>>> 000008b0: d0 f3 00 00 00 00 00 00 c8 00 ff 0f 1f 00 0f 00 >>>> 000008c0: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 0f >>>> @@ -53,9 +53,9 @@ >>>> 00000920: 00 48 3d f5 05 05 00 00 00 00 00 00 00 00 00 00 >>>> 00000930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> 00000940: 00 00 00 00 00 00 00 00 00 2e 3f 4a 00 33 64 ff >>>> -00000950: 10 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00 >>>> +00000950: 00 00 00 ff 03 10 40 07 00 08 02 ff 00 00 00 00 >>> ^^ >>> This probably doesn't matter: internal AC'97 codec register differs >>> >>>> 00000960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> 00000970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> 00000980: 00 00 00 00 00 00 00 00 00 3f 00 3f 00 3f 00 3f >>>> 00000990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> -000009a0: 00 00 00 00 00 00 00 00 01 00 00 00 12 00 00 80 >>>> +000009a0: 00 00 00 00 00 00 00 00 01 00 00 00 0e 00 00 80 >>> ^^ >>> This probably doesn't matter: internal AC'97 codec register differs >>>> -------------------------END------------------------------ >>> >>> Regards, >>> Andy >>> > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
