On Sunday 23 August 2009 18:55:41 Andy Walls wrote:
> 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_resu
> > >lts&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=VI
> >A%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.
Hmm, the problem with that is that 2.6.22 is the moment that ivtv was
finally merged into the kernel. So you probably end up with the merger of
ivtv as being the moment it broke :-) Not useful that.
The core problem is that 1) you're the first reporter of this problem, 2) it
doesn't happen on non-VIA PCs (at least, to my knowledge), 3) I strongly
suspect that it might be related to the PCI bridge on the PVR-500 together
with some interaction in other parts of the kernel. I actually have one
server that refuses to boot if I install an PVR-500. These things are very
hard to debug and, to be very honest, it is simply not worth the time to
attempt to resolve this.
It doesn't help you at all, I realize that, but it's the truth. It would be
different if I see such bug reports all the time, but that is not the case.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
