Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28 (Was:Re: Cannot format floppies under kernel 2.6.*?)

From: Mark Hounschell
Date: Fri Dec 18 2009 - 15:05:40 EST

On 12/18/2009 10:45 AM, Linus Torvalds wrote:
> 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

It looks like I may have to back up and first find the points that, let me,
and stop me, booting with the HPET enabled. Before I change direction, can
the git-bisect start sequence use the SHA1 id for the starting 'goods' and
'bads'? I don't see reference to that in the doc.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at