On Sun, 2009-08-23 at 17:53 +0200, Jeroen Roos wrote: > Andy Walls wrote: > > Well, looking through the lessons of the past: > > > > http://www.google.com/search?q=ivtv+PVR-500+VIA+reboot > > http://www.gossamer-threads.com/lists/engine?list=ivtv&do=search_results&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&search_type=AND > > Thanks for your reply, I checked those out and ran a few extra tests: > > - Adding "noapic nolapic pci=noacpi acpi=off" to my kernel, as found on > http://ivtvdriver.org/index.php/Via_motherboard_problems > > - setpci -s 00:0c.0 COMMAND=0107 (the exact opposite from > http://www.gossamer-threads.com/lists/ivtv/users/38179?search_string=VIA%20ivtv%20reboot%20PVR-500;#38179, > since mine was already reporting 0007 to start with) > > Neither solved the problem, unfortunately.
Not surprising. > > you are not the first to have a problem with a VIA PCI chipset and the > > Hint Corp PCI bridge on the PVR-500. > > > > > > The reboot is caused by hardware interactions, causing the VIA PCI > > chipset to decide to reboot the system. > > > > Those detremental hardware interactions are set in motion by the ivtv > > driver, CX23416 firmware, and kernel software. > > > > What are the software actions causing the reboot? Who knows... > > The strange thing is, that with a kernel before 2.6.22, I did not have > these issues, so that would point to something software, not hardware > related (or at least a hardware problem that can be avoided). A hardware problem that can be avoided sounds correct. Without detailed insight into the PCI chipsets, your best course of action is to do some differential analysis: 1. Find that latest kernel that still works and the earliest kernel that does not. A binary search will terminate in a few trials, e.g. .30, .26, .24, .23. (I suspect this could be painful on a Gentoo system, if you have to rebuild each kernel.) 2. Diff the source tree of the two kernels. 3. Analyze the diff for the change that may have caused the problem. That will narrow the cause down from "anything" to "one of these changes". That changeset still could be rather large. > > I can say that with the new kernel you are using, the implications of > > these messages looks worth investigating: > > > > IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs > > IRQ 18/ivtv1: IRQF_DISABLED is not guaranteed on shared IRQs > > > > Other than digging into that, you can try what others have tried in the > > past in the links above. > > So, how can I investigate that? I am sorry, I am quite an experienced > Linux user, but the kernel is mostly a black box for me... Hmm. Upon reflection, it may not be important. What the kernel is trying to say is that ivtv's interrupt handler may get interrupted under certain circumstances. The guranatee that ivtv's interrupt handler for a certain IRQ line will be serialized (ivtv's irq handler can't be called while ivtv's irq handler is interrupted) should still be in place. Let's defer looking into this. You'll make the most ground with differential analysis. Regards, Andy > Thanks again, > Jeroen _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
