On Sun, 2009-08-23 at 22:24 +0200, Jeroen Roos wrote: > > 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. > > That is what I thought, but the 2.6.22-gentoo-r8 release that seems to > work for me (I couldn't reproduce the issue anymore) appears to have > ivtv in-kernel. Unfortunately it has been removed from the 'portage' > tree, so I cannot check out on what vanilla version/patchlevel it was > based. Besides that, as mentionned in my previous mail, I cannot compile > these kernels anymore, since they can't be built with GCC 4.3
Jeroen, IN your previous email you mentioned ivtv diffs. The change that induces the problem is likely not there (or all there). Your symptoms indiicate PCI chipset configuration, interrupt configuration, IO memory management, or DMA configuration problems. Basically anything that might do something to make the motherboard's PCI chipset unhappy enough to decide to reboot the machine. It's not the CPU or the kernel rebooting the machine, it's the PCI chipset. > > The core problem is that 1) you're the first reporter of this problem, > > That makes me think that there's more to this problem... I simply can't > imagine that I am the only person in the world running this motherboard > (that was designed specifically for video-purposes) with this card (one > of the most popular analog tv cards for PVR's, I think) and Linux... > > > 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. > > Well, it is worth *MY* time, as I simply don't want to throw out a > system that should be working perfectly except for a software error. > > I'd be happy to try and test and figure out things, but I need some > guidance on what to try and interpreting kernel messages and stuff... There will be no kernel messages to interpret - the PCI chipset is rebooting the machine. No state will be saved, no messages will be emitted, the thing will just reboot. Even if the kernel notices something and starts to log it, it will never flush the message to screen, serial port, or disk before the reboot happens. If you really want to figure it out, you'll need to collect documents and do some reading: 1. The PCI local bus and PCI bridge specifications. You'll need to have a medium to advanced understanding of the PCI bus. 2. The data sheets for your motherboard's PCI chipset: northbridge and southbridge. You'll be looking for documented conditions which will cause the chipset to assert reset or maybe generate non-maskable interrupts. 3. The datasheet for the Hint Corp HB6 PCI-PCI bridge. I believe they were bought by PLX Tech: http://www.plxtech.com/ . Look for the PCI 6254 (HB6) bridge documents, if they have them publicly available. This bridge chip supports a few different modes, IIRC. 4. You'll need to dump the registers and inspect the configuration of the bridge chips against their datasheets so you understand how they should be behaving. Once you've done that homework, then you can start working on serious hypotheses about what may be causing the reboot and testing them. You should inform your hypotheses with the diff between working and non-working kernel. That's the only way I would know to isolate the root cause without without a very expensive PCI bus analyzer. There is no magic solution here. It is simply a lot of work. It's also not work that can be easily divided among a number of people nor resolved without the hardware in hand. I agree with Hans, it is hardly worth the time to fix the problem: Assume you spend 60 hours or more on document research, software modifications, and testing to resolve the problem. If 2 PVR-150's cost US$200 total, then over 60 hours of work, US$3.33/hour is the break-even point on the wage equivalent of one's time. If one were to also sell the PVR-500 on eBay for, say, US$125, then the break-even point sinks to US$1.25/hour. The only things worth the time are probably the intangible results of persuing the solution: learning about the PCI bus, satisfaction from solving a hard problem, learning about the linux kernel internals, etc. Regards, Andy > Jeroen _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
