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

[Linus Torvalds <torvalds@linux-foundation.org>]

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