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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B2BE05B.9050006@compro.net>
Date:	Fri, 18 Dec 2009 15:04:43 -0500
From:	Mark Hounschell <markh@...pro.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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 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.

Thanks
Mark
--
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/