Reply interspersed
Dale
Andy Walls wrote:
> On Sun, 2010-01-10 at 21:41 -0500, Dale Pontius wrote:
>
>> Every now and then my hvr-1600 goes red-screen on me. (Apparently this
>> indicates no signal, so presumably something has gone south in the
>> front-end selection logic.) From the lookup I've done, it's a symptom of
>> no signal.
>>
>
> I wouldn't say that "red screen" means "no signal". I would say that
> "red screen", with buffers still being DMA'ed properly from the CX23418,
> means the analog front end/digitizer in the CX23418 stopped operating
> normally.
>
>
Interesting, I have to think about that one. If I grep for "cx18" in my
logs nothing pops up other than a normal initialization. Are there any
flags I should use when loading the module that would deliver helpful info?
>
>> For a while I blamed it on my cheapo splitter/amp, because
>> when it happened I'd take things down, move the input to another
>> channel, and things would work, again. Recently I installed a much
>> better distribution amp.
>>
>> Today it happened again. I guess I need to sort out symptoms better,
>> but from what I can tell, once it goes red-screen, a simple reboot
>> doesn't clear things up, though I need to verify this. I'm going to
>> presume that rmmod/modprobe wouldn't clear things either, if a reboot
>> didn't. These facts are a bit murky, from the old splitter/amp, but I
>> do remember that once an input went, it stayed gone until I fiddled with
>> the hardware.
>>
>> Tonight when that happened, I realized that fiddling with the hardware
>> also meant really disconnecting the power, and that means the V5SB (5V
>> standby - on when the front-panel power is off) too. So I shutdown,
>> then turned off the switch on the pack of the power supply to really
>> power off, and waited about 20 minutes. (I wanted to record "Serenity"
>> and I thought it was at 6:00, but it was really at 6:30, so I could have
>> given it 50 minutes.) Anyway, all is well now.
>>
>
>
> So it sounds like either:
>
> a. a resistor somewhere - power supply, motherboard, or HVR-1600 - has
> open-circuited. Once you build up enough charge on some capacitors
> somewhere, the circuit stops working (oscillators for clock signals stop
> oscillating)
>
> b. You're power supply voltages are sagging and you're getting CMOS
> latch up. See section 4.3 of the publicly available CX25840/1/2/3
> datasheet for a terse description of CMOS latch up.
>
Is there any way shy of probing like a maniac to find (a) above?
Incidentally, this situation has happened at some point or other on both
HVR-1600, though I'm not sure it has ever happened to both at the same
time. As for (b), I have lm_sensors running, but never really trusted
the values it gives much more than a buglight. In other words, the 5V
supply is within a few tenths of 5V, and I certainly don't believe the
hundredths of a volt digit. From my perspective, it's an instrument
that has never been calibrated. Am I being unfair? Are the
measurements form lm_sensors better than I'm giving them credit for
being? That said, I do believe that I could likely take repeated
measurements and look for drift, etc.
As for latch-up, sounds like they don't have the best process/ESD
design. I've got 27 years in silicon design, and 4 years of test before
that. Forward-biasing a pin is certainly a bad thing to do, but decent
layout rules and a really good ESD device shouldn't let latch-up happen.
>
> Some rhetorical questions:
>
> Was 20 minutes needed to get back to normal operation, or is some
> smaller period of time also OK?
>
I don't really know. Since I'd been assuming that it was the fault of
my old distribution amp, I hadn't considered the problem to be inside
the computer case until now. My assumption was "something needs to
discharge," and the more time I could give it, the better. My wife got
off of the computer a little after 5:30, and I thought "Serenity" was on
SciFi (can't SyFy) at 6:00, so 20 minutes was what I thought I had. I
hadn't gotten into a debug frame of mind, yet. Had I realized that
"Serenity" was really on at 6:30, I would have given it 50 minutes.
> How many minutes of continuous operation does it take to get the red
> screen? Is there a lot of variance in that number?
>
Again, I don't really know. This is very infrequent, and since I was
blaming a box I planned on replacing, I didn't bother to look for
patterns. Now I am.
As for the best I can tell about this incident, it may well have been on
the fritz from boot, that morning. When I found that the show I wanted
to watch had the red screen, I checked something recorded earlier that
day, and it was bad, too. Obviously liveTV was bad.
Incidentally, a day or two after Chrismas the northbridge fan failed.
It had failed before, but I was able to clean and oil it, and get it
running again. I also ordered a passive heatsink, but had not gotten
around to installing it. So with system and new heatsink I went to a
friend's house Tuesday after Christmas, and we installed it on his
static-safe bench. The system has been powered up since, until the
other day when I flipped the switch off for 20 min.
As mentioned next, next time this happens I'll have my debug hat on, and
get some much better data. I'm still thinking that the 5VSB supply is
holding some badness in there.
>
>
>> Next time it goes red-screen, I'll first shut down mythbackend, then try
>> the rmmod/modprobe, and if that doesn't work I'll simply reboot. Then
>> I'll try the full powerdown, including the backside switch. (and report
>> findings here) By the way, this is on the NTSC side, while in this
>> state the ATSC/QAM side works OK.
>>
>
> OK. It sounds like the integrated ananlog front-end/digitizer is what
> is ceasing proper operation. ATSC/QAM doesn't require that piece to be
> operational.
>
> It could also be a DDR ram problem on the HVR-1600 board. The
> digitized video gets dumped into a certain memory and the encoder works
> on it from there. If that memory is faulty, one could also expect
> incorrect video (but a solid colored field is not what I would really
> expect).
>
>
>
>> In the meantime, have other seen this, or have any observations?
>>
>
> A few more rhetorical questions:
>
> How old is your power supply? Is it a name brand or off brand?
>
I can't recall the brand - it's the second in this case. The original
PS was a 350W Antec that came with the case. Some time after installing
a second hard drive, the system started occasionally powering down. I
set up remote logging so that I could capture the last events before the
crash that didn't make it onto disk, and found nothing unusual
happening. So I decided it must be the power supply.
I read reviews, found a brand working its way into the power supply
market that was well reviewed, and got a 430W model. I've been happy
with it, though of course that doesn't mean that it's perfect, but it
hasn't knowingly caused any problems.
A sensors readout follows, if it indicates anything. (Keeping in mind
my comments above.) There are lots of alarms, but none of them look real.
-------------------------------------
user@localhost ~ $ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:
+24 C
it8712-isa-0290
Adapter: ISA adapter
VCore 1: +1.10 V (min = +0.00 V, max = +4.08 V) ALARM
VCore 2: +0.00 V (min = +0.00 V, max = +4.08 V) ALARM
+3.3V: +3.31 V (min = +0.00 V, max = +4.08 V) ALARM
+5V: +4.95 V (min = +0.00 V, max = +6.85 V) ALARM
+12V: +11.84 V (min = +0.00 V, max = +16.32 V) ALARM
-12V: -4.78 V (min = -27.36 V, max = +3.93 V) ALARM
-5V: -13.64 V (min = -13.64 V, max = +4.03 V) ALARM
Stdby: +4.89 V (min = +0.00 V, max = +6.85 V) ALARM
VBat: +3.02 V
fan1: 3308 RPM (min = 0 RPM, div = 8)
fan2: 0 RPM (min = 0 RPM, div = 8)
fan3: 0 RPM (min = 0 RPM, div = 8)
M/B Temp: +26 C (low = -1 C, high = +127 C) sensor =
invalid ALARM
CPU Temp: +30 C (low = -1 C, high = +127 C) sensor =
invalid ALARM
Temp3: +24 C (low = -1 C, high = +127 C) sensor =
invalid ALARM
> Regards,
> Andy
>
>
>
>> Dale Pontius
>>
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users