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
