linux-kernel - Re: Wierdness - linux-next KVM patch breaks Dell Latitude D820, KVM not in kernel

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: <22130.1252438888@turing-police.cc.vt.edu>
Date:	Tue, 08 Sep 2009 15:41:28 -0400
From:	Valdis.Kletnieks@...edu
To:	Beth Kon <eak@...ibm.com>
Cc:	rostedt@...dmis.org, avi@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Wierdness - linux-next KVM patch breaks Dell Latitude D820, KVM not in kernel

On Tue, 08 Sep 2009 09:32:46 EDT, Beth Kon said:

> > 3) no KVM in this kernel:
> > % grep KVM .config
> > CONFIG_HAVE_KVM=y
> > ## CONFIG_KVM is not set
> >   
> Hi Vladis. I'm at a loss regarding my patch being the problem if it is 
> really the case that CONFIG_KVM is not set.  Are you sure that is the 
> config being used?

Yeah, I was quite confused by the bisect results as well, I may end up
re-doing it just to make sure I didn't screw something up along the way (since
I started it with -rc7/HEAD as the good/bad, but most of the resulting
kernels reported a pre-rc7 release (a 2.6.28 at one point, IIRC, and it
finished at 31-rc2.

%  pwd
/usr/src/valdis/linux-next
% grep KVM .config
CONFIG_HAVE_KVM=y
# CONFIG_KVM is not set

>                    My only other thought (assuming somehow CONFIG_KVM 
> *is* set) is to be sure your repository also has 
> b4eba884776b5ab77fef1febbd3203e54a66d0bd.

Yes, that commit is also in the repository, though I'm not sure what
difference it makes since it hits arch/x86/kvm/x86.c which isn't even built
in my .config.  I'm also confused why the trace.o module *did* get rebuilt
when it doesn't look like it would have needed it, and why that seems to have
been the critical issue.

Oh well.. off to go re-do the bisect, I guess.  Wish me luck. ;)

Content of type "application/pgp-signature" skipped