Hans, John, Steve, et al:I compared 0.4.0 to 0.2.0 and found that a lock had been commented out of ivtv-irq.c line 611 and 615 in 0.4.0.
itv->DMA_lock would lock:
dma_from_device() in ivtv_sched_DMA()
And block:
dma_to_device() in dec_work_thread()
SO I brought this lock back (see attached patch) and I haven't been
able to crash my system since (via the crashes this thread is about).
Can anyone else try this out on their dual processor / hyperthread
enabled machine and try to crash it (note that the patch is for 0.4.0
release)?
ivtvDMA.diff
Description: Binary data
- Rick
***
PS - Could this also be the corruption responsible for thread:
"Encoder Firmware 0x02050032 gives artifacts on PVR500"
As you said:
so the shift happens either in the DMA handling (most likely) or in the internal buffer handling of the driver.
***PPS - There's also a set of this lock in the VBI code, but I haven't figured out if those should be brought back.
----- On Nov 21, 2005, at 5:19 AM, Duncan Webb wrote:
Hans Verkuil wrote:On Saturday 19 November 2005 18:09, Steve & Laurie Sanders wrote:This is a big clue! I think. I believe it supports my suspicion thatthe DMA linked list programming might get occasionally clobbered with SMP kernels. In your case you have two physically separate processorsso you can remove one. When the kernel boots it will only see one so there is never going to be another processor banging away with an opportunity to collide with whatever goes wrong in DMA transactions. In my case, I have a hyper threading enabled P4 processor which is actually two processor cores on one socket so I can not do this experiment. My only option is to load a plain vanilla non SMP kernelinstead. That means I also have to recompile and install many moduleswhich I built for SMP kernel. I am thinking of just building another whole image on a differend HDD. It might be easier!Isn't is possible to turn hyperthreading off in the bios? Also, I remember seeing a 'noht' kernel option that turns off Hyperthreading support in the kernel.I think what you are seeing when you press "save position" is the pointers being shifted to a new index in the video stream buffer and programming a new DMA transfer starting at the new index thus fixing the corrupt DMA link list. I do not have clue how to go aboutdebugging this myself. I would be happy to load gdb and look at it ifsomeone who knows what they are doing can give some direction. Sounds to me like we just have way more processing power available than the driver can handle! of course it only seems to be a problem when X is running along with mythtv. Like you I would really like to be able to exploit my extra processor but I may just have to downgrade my media center to a single processor till we can get this figured out.No, it looks like classic smp problems, hard to fix if you don't have a dual cpu. And I haven't. None of the main developers have such a computer, so I am not surprised that there are smp bugs.I don't know if this helps.I was able to create a SMP PREEMPT crash consistently with a uniprocessor and SMP enabled. All I needed to do was start freevo and then it would crash every time when mplayer started.Regards, DuncanHansSteve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ricardo Lugo Sent: Saturday, November 19, 2005 8:24 AM To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] ivtv framebuffer is broken with PVR350 I have the same problem as Steve with my dual-processor & PVR350 TV-out setup. I usually get freezes within the first 10 minutes of playback. When I remove one of my processors (same vanilla 2.6.14 kernel w/ SMP & PREEMPT) this doesn't happen. Curiously, when it freezes during playback in myth, if I press "save position," it saves the position, displays some stuff on the OSD, and then unfreezes & continues playback 10 minutes downstream (hopefully this means something to someone). John, I tried your tests (an hour each) and here are the results: 1) Decoder-only: no crashes 2) Decoder & Encoder: no crashes 3) Decoder & FB updates: no crashes 4) Decoder & Encoder & FB: no crashes So, inconclusive... If there's any other tests you would like for me to run, I offer up my time to help diagnose. -Rick On Nov 12, 2005, at 2:34 PM, Steve & Laurie Sanders wrote: I have been posting about freezing playback and ivtv-osd warnings, and ivtv DEC warnings in the ivtv-users list sinsce I am using 0.4.0 stable. I tried to provide enough detail to solicit some help but nobody has responded. I think I have done enough debugging to narrow the problem down to the ivtv driver and based on that have filed abug report (#53) in the Trac system. Ticket URL: http://ivtvdriver.org/trac/ticket/53 You can find my previous posts to ivtv-users here:http://www.ivtvdriver.org/pipermail/ivtv-users/2005-November/ 000184.html &http://www.ivtvdriver.org/pipermail/ivtv-users/2005-November/ 000239.html If I need to post somewhere else, let me know where. If you need more infomation "". Yesterday I went so far as to disable tvout, and not load ivtv-fb and just playback directly to my monitor without using framebuffer or xdriver. When I did this I was able to playback a two hour movie without any freezes. This to me indicates the problem is somewhere in either the framebuffer or xdriver interface. I would like to do whatever I can to support the development of this project, I am willing and able to capture any kind of debug information that might be requested. Are there any develpers out there that have any interest in this failure? It may be specific to smp cores, I don't know how many are developing systems with smp processors._______________________________________________ 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
