On Tue, 2011-02-08 at 22:41 -0700, Dave Johansen wrote: > On Tue, Feb 8, 2011 at 9:51 AM, Dave Johansen <davejohansen@xxxxxxxxx> wrote: > > On Tue, Feb 8, 2011 at 8:25 AM, Mark Zimmerman <markzimm@xxxxxxxx> wrote: > >> On Mon, Feb 07, 2011 at 06:54:30PM -0500, Andy Walls wrote: > >>> > >>> You perhaps could > >>> > >>> A. provide the smallest window of known good vs known bad kernel > >>> versions. Maybe someone with time and hardware can 'git bisect' the > >>> issue down to the problem commit. (I'm guessing this problem might be > >>> specific to a particular 64 bit platform IOMMU type, given the bad > >>> dma_ops pointer.) > >>> > >> > >> FYI: I am on the process of doing a git bisect (10 kernels to go) to > >> track down this problem: > >> > >> http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg25342.html > >> > >> Which may or may not be related to the problem in this thread. > >> > > > > I'm using Mythbuntu 10.10 x64, which I believe uses 2.6.35 but I will > > check tonight, so if the issue you're tracking down really is related > > to 2.6.36, then I imagine that my problem wouldn't be caused by what > > you're looking into. Plus, every time I've looked at dmesg the > > firmware has loaded properly, so I'm guessing I'm on 2.6.35 and being > > affected by a different issue. > > > > Thanks for the heads up, > > Dave > > > > So I don't know how useful this is, but I tried Mythbuntu 10.10 x86 > and it works like a charm. So the issue appears to be isolated to the > x64 build. You validated my guess. :) > If there's anything I can do to help figure out what the > cause of this issue is in the x64 build, then please let me know and > I'll do my best to help out. So this increases the likelyhood that this is a kernel problem introduced outside of the drivers/media directory. To find it, someone needs to clone out the kernel with git; start a git bisect using the lastest known good and earliest known bad kernel versions; and build, install, and test kernels until the problem is found, as outlined here: http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ http://manpages.ubuntu.com/manpages/maverick/man1/git-bisect.1.html The "build, install and test kernels" step is the pain. Let's say it takes a 2 core AMD64 machine about 17 minutes to build a minimal kernel. The number of kernels that need to be tested will be roughly log2(Number of commits between known good and bad kernels). So 30,000 commits will require roughly 15 kernel builds to narrow the problem. If it takes 20 minutes per iteration, that's 5 hours to find the problem. That someone also needs 64 bit hardware and a board supported by the cx23885 driver that also exhibits the problem. I have an HVR-1850 and a 64-bit machine, but I haven't tested it yet. I do not have 5 hours free. Sorry. Regards, Andy > Thanks for all the help, > Dave -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
