Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> Resetting the pchdtv 3000
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
Resetting the pchdtv 3000
PostPosted: Thu Mar 09, 2006 10:43 pm Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




Is there any way to reset the card besides rebooting the machine?
View user's profile Send private message Visit poster's website
Re: Resetting the pchdtv 3000
PostPosted: Fri Mar 10, 2006 3:00 am Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




tupari wrote:
Is there any way to reset the card besides rebooting the machine?

You could rmmod all the modules and modprobe them again. What's happening though that you need to reset the card?
View user's profile Send private message
Re: Resetting the pchdtv 3000
PostPosted: Fri Mar 10, 2006 8:20 am Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




kmj0577 wrote:
tupari wrote:
Is there any way to reset the card besides rebooting the machine?

You could rmmod all the modules and modprobe them again. What's happening though that you need to reset the card?


I was getting no signal on all stations. It happened before and it was fine after I rebooted. Removing all the modules and reloading them worked too.
View user's profile Send private message Visit poster's website
Why the HD 3000 would need resetting.
PostPosted: Mon Mar 13, 2006 5:57 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




I've been studying this problem for quite some time. I think I can now say what is happening when the i2c gets lost and the driver locks-out.



i2c fail cause #1:
dvb_frontend.c has a zig-zag tuning default that keeps setting the same frequency and modulation over and over again needlessly.



i2c fail cause #2:
It doesn't help that it also checks the status continuously, adding more useless i2c traffic.

These appear to be defaults for dvb-s that are fine for satellite users but not used and actually bothersome for cable or terrestrial broadcast. These two cause eventual i2c failure, but it may not manifest itself as fast as #3 will.



i2c fail cause #3:
There is no method to properly handle a signal (SIGINT, SIGTERM, et al) during the i2c transfer. If it gets a signal, it will abort the transfer part-way through and not send the stop bit.

Control-C of any application while it is reading signal strength seems to be the fastest way to desynchronize the i2c.



i2c fail cause #4:
read_signal_strength and read_snr in or51132.c (and or51211.c?) do not check the status before attempting to read the SNR after equalizer data. This forces the DVR to present junk data if there is no signal lock. It's always a bad idea to force junk data and in this case will cause i2c to desync eventually.



i2c problem #5:
There is no way to reset it other than reload cx88-dvb. This means whatever program that has the driver open has to close the device so it can reload. Not particularly convenient if you have 3 cards, since cx88-dvb handles all 3 cards.



Fixes for all of these have now been done.



ioctl(fe_file, FE_SET_FRONTEND_TUNE_MODE, FE_TUNE_MODE_ONESHOT);

ioctl FE_SET_FRONTEND_TUNE_MODE was recently added (January or so) to the v4l-dvb mercurial CVS. This turns off the continual re-tuning and status check, fixing problem cause #1 and #2.

pchdtvr will use this ioctl if it finds it defined.



Fixing problem cause #3, #4 and #5 requires a patch that is not yet in the v4l-dvb mercurial CVS.

i2c is currently software driven, so it's up to i2c-algo-bit to send the i2c stop bit on a signal. It apparently does not do this, or does it incorrectly.

I took the bttv-i2c.c hardware i2c code and put it into cx88-i2c.c. Since all the bits are identical, only the names changed.

I added a stop bit send to the error end of the hardware send and receive routines to handle wait_event_interruptible_timeout signal.

I also experimented with wait_event_timeout in place of wait_event_interruptible_timeout that would ignore the signals entirely.

Either method seems to work as well at fixing #3.



To fix #4: I added a status check before SNR read, in both read_signal_strength and read_snr. If there is no lock, it now returns 0% strength.



Fixing problem #5:

The hardware i2c makes the microcode load very quickly without the annoying CPU stealing stalls that are so bad with software i2c that they corrupt captures on other cards.

This makes it possible to add some reset code that will be non-intrusive to user applications.

I added cx88_ext_reset to to cx88-core.c to reset the or51132 to a known state. The tuner does not seem to be affected by the reset, staying at whatever you last set it to. Once the or51132 is reset, the microcode can be reloaded automatically based on the settings prior to the reset.

That's all well and good you might say, but how does it know WHEN to reset to handle #5?


Turns out the first byte of receiver status return should match the modulation. If it doesn't, i2c is probably lost. I let the first couple of errors slide, because it does frequently give spurious incorrect values as one-off occurrences.

Once there are 3 bad receiver status reads in a row, it will reset the device automatically and restore the previous settings.

All the user sees is a 3 second delay on signal scan, on the now rare occasions where it resets.

Jack may be getting the patch added to v4l-dvb mercurial CVS. If it isn't there yet, email me if you know how to use patch.

You want to make sure you have the latest v4l-dvb mercurial CVS before contacting me for the patch to make it apply painlessly.

Why? I'll probably need to co-ordinate my patch with the latest v4l-dvb mercurial CVS, since my patch is against 2006-Feb-20 mercurial that I have not updated since.



My own solution for the past year has been to reload the driver. That was fine while I was still testing pchdtvr, but I need it to be more reliable now that pchdtvr is done.

It is as reliable as I wanted now, being up for the past two weeks without driver lock-out and few resets.



Hope that helps explain what is going on.


Cheers!

-ink


kmj0577 wrote:
tupari wrote:
Is there any way to reset the card besides rebooting the machine?

You could rmmod all the modules and modprobe them again. What's happening though that you need to reset the card?
View user's profile Send private message
Bullet-Proof HD-3000 DVB driver
PostPosted: Wed Mar 15, 2006 7:12 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Hey tupari,

I have a dvb-v4l driver patch available now that will reset the HD-3000 when enough i2c errors occur. You could say it's fault-tolerant and has fault-recovery. I like the *Bullet-Proof buzzword myself.

*Bullet-Proof should not be implied as Failure-Proof. Software does not usually fix a dead card, unless it's dead microcode or configuration data on the dead card that can be easily remedied.

You will need to do this to use it:

Install mercurial and get the latest linuxtv.org v4l-dvb mercurial hg/CVS.

Don't forget to update /usr/include/[...] with the new dvb header .h files so user applications, like pchdtvr, can see all the new features from the updated header files without a lot of Makefile hassle to fix it.


Then get this file:
http://www.nop.org/inkling/dtv/test/dvb-ink.diff.gz

and gzip -d the file.

Now you have a patch that MIGHT apply to the current v4l-dvb CVS. No promises because I have not updated my v4l-dvb codebase since Feb 20.

cd [mercurial....]/v4l-dvb

patch -p1 <[.../]dvb-ink.diff

( only you know what goes in the [...] )


On the odd chance it applies without any rejects, you still have to do two more things to change it from my test system to your system.


Either do a make and control-c it after it makes the symlinks to easily edit v4l/or51132.c,

or do "find . | grep or51132.c" and edit the long pathname.

Edit or51132.c and change:
#define STRESS
to:
#undef STRESS

and change in the same file:
#define FW_EMBEDDED
to:
#undef FW_EMBEDDED

since you probably aren't interested in 100 signal scans per second and you probably want to use hotplug and not the separate microcode include file that you do not have (but could easily make).


After editing or51132.c to fix it from my test system:

make && make install the new drivers, then rmmod anything your kernel put in for v4l-dvb drivers.

Before you load the new modules, you will need something in modules.conf to tell it to use the new hardware i2c, if you want the fast and smooth-as glass microcode reload on reset, which you should:


Edit /etc/modules.conf (or whatever your linux distro prefers for the global module options file):

options cx8802 i2chw=1

(and then do anything your global module option update requires: i.e., gentoo is modules-update.)


Then load the newly compiled v4l-dvb modules. "modprobe cx88-dvb" should be enough for the new modules.



With luck, the HD-3000 driver will now be Bullet-Proof and reset itself every time i2c tries to shoot itself in the foot.

If it works, you should see something like this in your /var/log/syslog or dmesg:

Mar 1 20:25:53 malcomix kernel: CORE cx88[2]: subsystem: 7063:3000, board: pcHDTV HD3000 HDTV [card=22,autodetected]
Mar 1 20:25:53 malcomix kernel: TV tuner 52 at 0x1fe, Radio tuner -1 at 0x1fe
Mar 1 20:25:53 malcomix kernel: cx88[2]: cx88_sram_select ATSC FIFO SRAM
Mar 1 20:25:53 malcomix kernel: tda9887 3-0043: chip found @ 0x86 (cx88[2])
Mar 1 20:25:53 malcomix kernel: cx88[2]: tda9887 i2c attach [addr=0x43,client=tda9887]
Mar 1 20:25:54 malcomix kernel: cx88[2]: i2c sw register ok
Mar 1 20:25:54 malcomix kernel: cx88[2]/2: found at 0000:00:0c.2, rev: 5, irq: 11, latency: 32, mmio: 0xda000000
Mar 1 20:25:54 malcomix kernel: cx88[2]: i2c detach [client=tda9887]
Mar 1 20:25:54 malcomix kernel: cx88[2]/2: i2c sw unregister ok
Mar 1 20:25:54 malcomix kernel: cx88[2]/2: i2c hw register ok
Mar 1 20:25:54 malcomix kernel: cx88[2]/2: cx2388x based dvb card
Mar 1 20:25:54 malcomix kernel: DVB: registering new adapter (cx88[2]).
Mar 1 20:25:54 malcomix kernel: DVB: registering frontend 2 (Oren OR51132 VSB/QAM Frontend)...

For me, the following messages show up every time the device is opened now, to let me know it has been reset on open.

Hotplug will say "Waiting for FW upload", then "xxx FW uploaded", where using the include file only shows "xxx firmware embedded".

Hotplug only adds about a half-second to the overall reset and does not seem to suffer any lag under heavy loading. I use the FW_EMBEDDED include file because I will not suffer any delay that I need not suffer any longer.

This is what I see every time pchdtvr loads now, unless I reload it before the frontend kernel thread terminates:

Mar 1 20:25:59 malcomix kernel: or51132[2]: or51132_reset
Mar 1 20:25:59 malcomix kernel: or51132[2]: VSB firmware embedded
Mar 1 22:21:13 malcomix kernel: or51132[0]: FW Version 10001134-19430000 (113-4-194-3)

It's been two weeks since fixing it and no problems except the occasional reset that rights itself after 3 seconds. It loads the CPU so lightly for reset now that xine playback of another file captured from the same machine is not interrupted.

I've never seen it die during capture, so no way to know much about that except it woud probably lose 3s of capture due to the reset delay, should it ever occur.

Fault-tolerance and recovery during capture may require more from the microcode than it can provide. It does not seem to do very well when it is being bothered via i2c WHILE it is streaming. It may simply be a limitation of how many tasks the microcode can handle at once.

Hey, I can see it dodging the bullets in the syslog, but none of them kill it anymore! A Kevlar/Teflon driver!!


Without luck, you'll have to twiddle the mercurial v4l-dvb/v4l/Make.config to reduce the number of drivers it tries to compile so it will actually finish the driver compile.


I made a patch to disable all that extra unnecessary junk, but so far as I can tell, with the 2006-Feb-20 hg/CVS, the extra junk is not bothering anything except me with the wasted module space.

Hope this helps,

Cheers!

-ink



tupari wrote:
Is there any way to reset the card besides rebooting the machine?
View user's profile Send private message
PostPosted: Wed Mar 15, 2006 9:20 am Reply with quote
tupari
 
Joined: 29 Dec 2004
Posts: 38




Sorry, this machine is acting as my mail server, and I don't feel very adverterous when it comes to hacking kernel modules. Hopefully your changes will make it into the kernel cvs.
View user's profile Send private message Visit poster's website
fail-safe
PostPosted: Wed Mar 15, 2006 9:44 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




It's only replacing the modules you have existing without actually modifiying the existing kernel. You can always rebuild the kernel modules to put it back, but I understand your caution.

I also hope that some day reliability will arrive built-in to the Linux kernel.

Sure been waiting for it long enough.

Cheers!


-ink



tupari wrote:
Sorry, this machine is acting as my mail server, and I don't feel very adverterous when it comes to hacking kernel modules. Hopefully your changes will make it into the kernel cvs.
View user's profile Send private message
Re: fail-safe
PostPosted: Wed Mar 15, 2006 11:19 am Reply with quote
dieter
 
Joined: 20 Jan 2005
Posts: 43
Location: US




inkling wrote:

I also hope that some day reliability will arrive built-in to the Linux kernel.

Sure been waiting for it long enough.




What we need is a HD-3000 driver for a BSD kernel. BSD has been reliable for ages.
View user's profile Send private message
Re: fail-safe
PostPosted: Wed Mar 15, 2006 11:07 pm Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Lotta sawdust in the new kernels. Gets everywhere. Oddly enough, now that is running the captures all by itself on a dedicated machine, it doesn't crash anymore.

An HD-2000 and 3 HD-3000s all getting along well on the 4 tentacled antenna monster. So nice to see at last.

xine is being a box-locking machine killer for me lately.


For a BSD driver, all you need for ATSC is cx88-core.c, cx88-i2c.c, cx88-mpeg.c, or51132.c and maybe a couple of others from the v4l-dvb code.

You'll have to design your own BSD'ized ioctls for it.

It doesn't have to use the DVB API.

Have fun!

-ink
View user's profile Send private message
Re: Why the HD 3000 would need resetting.
PostPosted: Sat Mar 25, 2006 7:16 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




inkling wrote:
I've been studying this problem for quite some time. I think I can now say what is happening when the i2c gets lost and the driver locks-out.


Nice work. It's nice that hardware I2C can finally be used. I wrote a patch to use hardware interrupt driven I2C for the bt8x8 driver around *nine* years ago. At the time I was told hardware I2C couldn't be used because some obscure chip on someone else's card wasn't compatible with it, and the new kernel i2c layer didn't support both hardware i2c and software i2c.

Did you figure this out just by looking at the driver, or do you have access to the or51132 data sheet?
View user's profile Send private message
How I finally got HD3000 rock-solid
PostPosted: Sun Mar 26, 2006 4:23 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




I used the code from bttv-i2c.c, even if the bttv driver apparently doesn't. Seemed a shame to let a good idea like that go to waste, untested.

Nine years ago a lot of hardware was probably software i2c only, because CPUs were slower and the delay was acceptable and not much money was spent on making it better.

It's still pretty bad and I still contend a piece of string and two tin cans will give you a more reliable communication interface. :>

The Philips i2c spec and the cx23883 datasheet told me all I needed to know, once I started digging around the bttv driver to see what it had that was the same as, and different from, the cx88 driver.

It sure does seem like a lot of code in bttv driver is unused. Cut and paste and change names to match cx88. I'll use it, if it works.

Since the code in or51132.c uses the standard i2c interface, it didn't need any change to make hardware i2c work: on the first try.

The easiest problem to figure out was to not read the signal strength data if it is not likely to be valid. Figured that out for these DTV cards two years ago.

The hardest problem to find was the software i2c was not getting the start/stop bits correct after SIG* interrupt. Took a lot of logging to a tmpfs volume to find that.

The helpful discovery was realizing the x06 set for VSB8 modulation mode is same x06 you get back from receiver status, which gave me a way to know when the i2c died.

As for resetting the or51132, I added cx88_ext_reset to cx88-core.c to reset all the external devices, crossed my fingers and hoped it worked.

Seemed to, as everything is still rock solid, 4 weeks after finally figuring out how to reset it. That's better than the 60 weeks before!

I've been testing reading signal strength during capture again.

It still causes the same i2c failure problems as software mode, except hardware mode will actually read the signal strength during capture without glitching the capture.

The seemingly random (still collecting data for charting, theorizing, etc) i2c failures still occur, so the hardware i2c apparently can not cure that particular issue, even if it can reset itself after the i2c issue occurs in sufficient quantity to trigger the reset.

The QoS solution in pchdtvr to actually validate each packet seems to be [and has proven to be] the least problematic and most generic method of determining when the signal goes bad during capture.

All the QAM tests in or51132.c are best guess from common sense. No way to know if those work at all, but if they follow the VSB settings they should work well enough.

Just for grins, I re-read W. Edwards Deming's book "Out of the Crisis". It actually helped me to realize the failing process was much farther out of statistical control than I originally understood it to be. [I knew it was bad, but I didn't know how bad until I quantified it.]

It also gave me ideas on which data points I needed to collect to make a theory on how to get it back into statistical control.

I think it's still available from the M.I.T. Press, in case you find engineering and product design statistical analysis even remotely interesting.

Cheers!

-ink
View user's profile Send private message
wasn't xine at all
PostPosted: Wed Apr 05, 2006 2:10 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




inkling wrote:
xine is being a box-locking machine killer for me lately.


Strike that. Turns out my new memory chips wanted 2.6v instead of the BIOS default of 2.5v. Simple BIOS adjustment. Go figure. Dang Samsung.

xine is fine now.

-ink
View user's profile Send private message
PostPosted: Fri Apr 07, 2006 10:16 pm Reply with quote
GrepTar
 
Joined: 10 Jan 2005
Posts: 51




I used your patch to patch kernel 2.6.16.2, and only had to manualy patch 2 files.

When I do the dmesg, though, I don't see:
Mar 1 20:25:54 malcomix kernel: cx88[2]: i2c detach [client=tda9887]
Mar 1 20:25:54 malcomix kernel: cx88[2]/2: i2c sw unregister ok
Mar 1 20:25:54 malcomix kernel: cx88[2]/2: i2c hw register ok

I take it that means your patch isn't actually being used?

In fact, my dmesg never has tda9887 in it.

Was thinking that this patch would work on a kernel download just not right?

I know the changes to or51132.c are being used, because I can change the static int debug to get more info on the firmware upload:

or51132[0]: or51132_init
or51132[0]: or51132_reset #1
or51132[0]: set_parameters
or51132[0]: set_parameters VSB MODE
or51132[0]: FW Upload: dvb-fe-or51132-vsb.fw
or51132[0]: Firmware is 17532 bytes
or51132[0]: FirmwareA is 1771 bytes
or51132[0]: FirmwareB is 15753 bytes
or51132[0]: Firmware loading to i2c slave addr 0x15

I'd appreciate any thoughts you have.
View user's profile Send private message
PostPosted: Fri Apr 07, 2006 10:29 pm Reply with quote
GrepTar
 
Joined: 10 Jan 2005
Posts: 51




Nevermind, I found the switch to turn it on. Now I get:

CORE cx88[1]: subsystem: 7063:3000, board: pcHDTV HD3000 HDTV [card=22,autodetected]
TV tuner 52 at 0x1fe, Radio tuner -1 at 0x1fe
cx88[1]: cx88_reset
cx88[1]: cx88_sram_select ATSC FIFO SRAM
cx88[1]: sram setup video y / packed: bpl=8 lines=2
cx88[1]: sram setup video u: bpl=8 lines=2
cx88[1]: sram setup video v: bpl=8 lines=2
cx88[1]: sram setup vbi: bpl=8 lines=2
cx88[1]: sram setup audio from: bpl=8 lines=2
cx88[1]: sram setup audio to: bpl=8 lines=2
cx88[1]: sram setup mpeg: bpl=14664 lines=2
cx88[1]: cx88_ext_reset SRSTO# 0 for 10ms
cx88[1]: i2c sw register ok
ACPI: PCI Interrupt 0000:04:02.2[A] -> GSI 18 (level, low) -> IRQ 21
cx88[1]/2: found at 0000:04:02.2, rev: 5, irq: 21, latency: 64, mmio: 0xde000000
cx88[1]/2: i2c sw unregister ok
cx88[1]/2: i2c hw register ok
cx88[1]/2: cx2388x based dvb card
DVB: registering new adapter (cx88[1]).
DVB: registering frontend 1 (Oren OR51132 VSB/QAM Frontend)...
or51132[0]: or51132_init
or51132[0]: or51132_reset #1
cx88[0]: cx88_ext_reset SRSTO# 0 for 10ms
or51132[0]: set_parameters
or51132[0]: set_parameters VSB MODE
or51132[0]: FW Upload: dvb-fe-or51132-vsb.fw
or51132[0]: Firmware is 17532 bytes
or51132[0]: FirmwareA is 1771 bytes
or51132[0]: FirmwareB is 15753 bytes
or51132[0]: Firmware loading to i2c slave addr 0x15
or51132[0]: FW Version 113-4-194-3
or51132[0]: Firmware upload complete.
or51132[0]: setmode 7
or51132[0]: set #1 to 50
or51132[0]: set #6 to 03 06
or51132[0]: dvb pll configure
or51132[0]: set parameters tuner x0E908E3A
or51132[0]: set_parameters
or51132[0]: dvb pll configure
or51132[0]: set parameters tuner x24108E3C
or51132[0]: read_status 06 23
or51132[0]: read_status 06 27
or51132[0]: read_status 06 67
or51132[0]: read_status 06 27

So, I think I am set to try it out. Thanks a bunch.
View user's profile Send private message
Re: wasn't xine at all
PostPosted: Sat Apr 08, 2006 11:19 am Reply with quote
Scott Larson
 
Joined: 15 Oct 2003
Posts: 713
Location: Portland, OR




inkling wrote:
Strike that. Turns out my new memory chips wanted 2.6v instead of the BIOS default of 2.5v. Simple BIOS adjustment. Go figure. Dang Samsung.

Same thing with my system! I couldn't get the memory to run at 400 Mhz reliably until I gave the chips a little more juice.

One interesting symptom was what appeared to be poor HDTV reception (occasional CRC and MPEG errors). Obviously that was just the data getting corrupted in memory, not from the reception because it would "correct itself" when I played it again.
View user's profile Send private message
Resetting the pchdtv 3000
  pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 1 of 1  

  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin