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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ