Message-ID: <3850.1252332427@turing-police.cc.vt.edu>
Date:	Mon, 07 Sep 2009 10:07:07 -0400
From:	Valdis.Kletnieks@...edu
To:	Beth Kon <eak@...ibm.com>, rostedt@...dmis.org, avi@...hat.com
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Wierdness - linux-next KVM patch breaks Dell Latitude D820, KVM not in kernel

Symptoms: Dell Latitude D820 either hangs at very early boot (before
any output, not even penguins), or (apparently) triple-faults into an
immediate reboot.  linux-2.6.31-rc7-mmotm0827 works fine, so whatever the
real issue is, it hit linux-next between then and when Andrew pulled for
-0902.  Since I was feeling lazy, I told 'git bisect' that 2.6.31-rc7 was
good and HEAD was bad.

'git bisect' against a linux-next pulled Friday evening finds this:

% git bisect good
92e1f62fb1f5d614ca9ad2d5f99f7b41da53d13b is first bad commit
commit 92e1f62fb1f5d614ca9ad2d5f99f7b41da53d13b
Author: Beth Kon <eak@...ibm.com>
Date:   Tue Jul 7 11:50:38 2009 -0400

    KVM: PIT support for HPET legacy mode
    
    When kvm is in hpet_legacy_mode, the hpet is providing the timer
    interrupt and the pit should not be. So in legacy mode, the pit timer
    is destroyed, but the *state* of the pit is maintained. So if kvm or
    the guest tries to modify the state of the pit, this modification is
    accepted, *except* that the timer isn't actually started. When we exit
    hpet_legacy_mode, the current state of the pit (which is up to date
    since we've been accepting modifications) is used to restart the pit
    timer.
    
    The saved_mode code in kvm_pit_load_count temporarily changes mode to
    0xff in order to destroy the timer, but then restores the actual
    value, again maintaining "current" state of the pit for possible later
    reenablement.
    
    [avi: add some reserved storage in the ioctl; make SET_PIT2 IOW]
    
    Signed-off-by: Beth Kon <eak@...ibm.com>
    Signed-off-by: Avi Kivity <avi@...hat.com>

:040000 040000 9771592c8df5806f5da4e3fc5def70e6b046b0b7 1e71e65dad0e013cb434391f1aea3213ddc89617 M      arch
:040000 040000 58b808be039743c69f34eba373b078b84beada13 b681e2afecd12a2c75cd32d9d56fc3297d11f0e2 M      include

% git bisect log
git bisect start
## good: [422bef879e84104fee6dc68ded0e371dbeb5f88e] Linux 2.6.31-rc7
git bisect good 422bef879e84104fee6dc68ded0e371dbeb5f88e
## bad: [b174f87b707ffa866de88a3d96e702a48f834930] Add linux-next specific files for 20090904
git bisect bad b174f87b707ffa866de88a3d96e702a48f834930
## bad: [7b0f9406ef7770bf37aacf98ba59dcccd12deae7] Merge commit 'dlm/next'
git bisect bad 7b0f9406ef7770bf37aacf98ba59dcccd12deae7
## bad: [2d55d81d9d2ead8e1ba97a3e000efa3796193805] KVM: MMU: shadow support for 1gb pages
git bisect bad 2d55d81d9d2ead8e1ba97a3e000efa3796193805
## good: [c3071eae069e407d067a98c22ab2d1973b68785b] KVM: MMU: unify slots_lock usage
git bisect good c3071eae069e407d067a98c22ab2d1973b68785b
## good: [93bde9fd0d39f18d1bdb0f0b7dbea763277fc83a] KVM: s390: Fix memory leak of vcpu->run
git bisect good 93bde9fd0d39f18d1bdb0f0b7dbea763277fc83a
## good: [ed13abffa3568d222fda9fc4b1ddebccbafadd2e] KVM: Replace kvmclock open-coded get_cpu_var() with the real thing
git bisect good ed13abffa3568d222fda9fc4b1ddebccbafadd2e
## good: [e85dd2c90b6f523f6c014959313b4a8b7bf09ba4] KVM: Use pointer to vcpu instead of vcpu_id in timer code.
git bisect good e85dd2c90b6f523f6c014959313b4a8b7bf09ba4
## good: [a2e3bb114b6afc79b2e8771ede074e9aabbe11ee] KVM: document locking for kvm_io_device_ops
git bisect good a2e3bb114b6afc79b2e8771ede074e9aabbe11ee
## good: [be5ef0d26ae68aa6825630cdfc2d0f93a36e3ac1] KVM: No need to kick cpu if not in a guest mode.
git bisect good be5ef0d26ae68aa6825630cdfc2d0f93a36e3ac1
## bad: [398eea630db0dd3f1e97294b74538521800a6ba8] KVM: x86: use get_desc_base() and get_desc_limit()
git bisect bad 398eea630db0dd3f1e97294b74538521800a6ba8
## bad: [988bdebfe40ab15a38a788ef9fda0b68a698121b] KVM: Move kvm_cpu_get_interrupt() declaration to x86 code
git bisect bad 988bdebfe40ab15a38a788ef9fda0b68a698121b
## bad: [f7bc646cae299e60c982cb4646915f9763fcea09] KVM: make io_bus interface more robust
git bisect bad f7bc646cae299e60c982cb4646915f9763fcea09
## bad: [92e1f62fb1f5d614ca9ad2d5f99f7b41da53d13b] KVM: PIT support for HPET legacy mode
git bisect bad 92e1f62fb1f5d614ca9ad2d5f99f7b41da53d13b
## good: [ce0c990165e183d07cde7c8ed726c37c4f94ae5c] KVM: Always report x2apic as supported feature
git bisect good ce0c990165e183d07cde7c8ed726c37c4f94ae5c

Why this is weird (the first two are just my lack of git-foo):

1) During the bisect, the kernel version was jumping all over the place - as
far back as 2.6.28-rc<mumble> even though I gave 31-rc7 as the start - right
now, at the end of the bisect, it's sitting at 31-rc2.  Where does git get
these versions from?

2) Probably related - git reports this patch as being done 2009-07-07, but
it apparently got to linux-next between 08/27 and 09/03.  Is there any way
to get git to tell when a revision went tree-to-tree?

The truly weird:

3) no KVM in this kernel:
% grep KVM .config
CONFIG_HAVE_KVM=y
## CONFIG_KVM is not set

4) During the kernel build for the last few bisects, the *only* thing rebuilt
besides things like version.o was kernel/trace/trace.o - there *is* tracing
in this kernel.

My best guess is that the flagged commit does something to a .h file that
gives trace.c indigestion at system boot, but looking at the patch, damned
if I know what it was...

.config at the end of bisecting attached.

View attachment ".config" of type "text/plain " (66994 bytes)

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists