[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0912180734220.3712@localhost.localdomain>
Date: Fri, 18 Dec 2009 07:45:45 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mark Hounschell <markh@...pro.net>
cc: Mark Hounschell <dmarkh@....rr.com>, Alain Knaff <alain@...ff.lu>,
linux-kernel@...r.kernel.org, fdutils@...tils.linux.lu
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists