On Wed, Feb 09, 2011 at 08:25:32PM -0500, Andy Walls wrote: > 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. > The slowest part of the process for me was deciding to start. After that, the 'install, test, and reboot back into a good kernel' cycle takes about 10 minutes, then I start the next build and walk away. By squeezing in one cycle in the morning before leaving for work, and one or two in the evening, I have gotten this far: Bisecting: 37 revisions left to test after this (roughly 5 steps) -- 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
