Messages in this thread | | | Date | Fri, 18 Dec 2009 07:45:45 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?) |
| |
On Fri, 18 Dec 2009, Mark Hounschell wrote: > > Yep, thanks. I'm past that now. But haven't done a bisect [good|bad] on the > results of that one yet. Did you see Alain's email response to my bisect > progress report to him? > > I'm still at a loss as to how to proceed?
Ahh, the HPET issue.
That one is actually very interesting information, because we've had problems with HPET before. But what I would suggest is to try to continue to bisect with HPET enabled (to see the problem), and the commit that you couldn't even boot with HPET enabled you should not count as good or bad because you just don't know.
You can do "git bisect skip" to make git know that some particular commit is not a commit you can test, and you can also move away from a whole problematic region to another area by doing
git bisect visualize
to bring up a graphical gitk view of what all you have left to bisect, pick a good point (still _reasonably_ close to the middle) there, and do
git reset --hard <the-point-you-want-to-test>
and try that kernel instead of the one git bisect suggested.
But this floppy DMA inconsistency being somehow HPET-related is interestign in itself. One thing that HPET does si to obviously change how we read the time - and what that can cause (totally indirectly) is that now we don't touch the southbridge with IO accesses nearly as much, because instead of going to the old 8253 PIT will touch the same legacy chip support that implements the floppy controller itself.
So it's entirely possible that the reason a non-HPET setup doesn't show this is that the accesses to the i8253 PIT part will "synchronize" the old floppy controller too, and hide some issue.
But still, I assume you had HPET enabled in 2.6.27, so it would be interesting to see exactly when the problem starts.
Linus
| |