On Sunday 23 August 2009 21:29:18 Hans Verkuil wrote:
> 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_re
> > > >su
> > > > lts&search_forum=forum_2&search_string=VIA+ivtv+reboot+PVR-500&sear
> > > >ch_ 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.
Sorry, ignore this. I thought that it was broken in 2.6.22, but it broke in
2.6.23. In that case the binary search method might well result in
something useful.
Regards,
Hans
>
> 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
