Bug 457649
Summary: | Kernel double faults when nxclient tries to connect | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Underhill <redhat-bugzilla> |
Component: | kvm | Assignee: | Glauber Costa <gcosta> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 9 | CC: | berrange, clalance, gcosta, kernel-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-11-06 04:10:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Chris Underhill
2008-08-02 11:03:22 UTC
Ooops - cut-and-paste error. The kernel in the Fedora 8 VM is kernel-2.6.25.11-60.fc8 Are there any messages in the host's log when that happens? (In reply to comment #2) > Are there any messages in the host's log when that happens? The only messages are in my .xsession-errors file, where I see: Qt: Locales not supported on X server Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4ac specified for 0x5600006 ( NX - fc8v). but I get this as the NX logon window appears, i.e., before connection, regardless of which VM (or remote machine) I connect to, so doubt it's relevant. There's nothing reported in dmesg, /var/log/messages or /var/log/Xorg.0.log Is the nxserver program 32-bit or 64-bit? Also, is this still happening with 2.6.26.3 kernels? NX software on the Fedora 8 virtual machine consists of: nxnode-3.0.0-93.i386 nxserver-3.0.0-79.i386 nxclient-3.0.0-89.i386 I've updated the vm to use kernel-2.6.26.3-14.fc8.x86_64 and the double fault is still present: Sep 28 23:10:51 fc8v1 kernel: double fault: 0000 [1] SMP Sep 28 23:10:51 fc8v1 kernel: CPU 0 Sep 28 23:10:51 fc8v1 kernel: Modules linked in: rfcomm l2cap bluetooth autofs4 fuse sunrpc nf_conntrack_ipv4 ipt_REJECT ipt able_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp ip6t_ipv6header ip6t_REJECT ip6table_filter ip6_tabl es x_tables sha256_generic aes_x86_64 aes_generic cbc dm_crypt crypto_blkcipher dm_mirror dm_log dm_multipath dm_mod ipv6 floppy 8139cp pcspkr 8139too mii i2c_piix4 i2c_core sr_mod cdrom sg pata_acpi ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: freq_table] Sep 28 23:10:51 fc8v1 kernel: Pid: 2479, comm: nxserver Not tainted 2.6.26.3-14.fc8 #1 Sep 28 23:10:51 fc8v1 kernel: RIP: 0010:[<0000000081026580>] [<0000000081026580>] Sep 28 23:10:51 fc8v1 kernel: RSP: 0018:0000000000000000 EFLAGS: 00010012 Sep 28 23:10:51 fc8v1 kernel: RAX: 000000000000002d RBX: 0000000000000000 RCX: 0000000000caaff4 Sep 28 23:10:51 fc8v1 kernel: RDX: 0000000000000000 RSI: 0000000000cacacc RDI: 0000000000021000 Sep 28 23:10:51 fc8v1 kernel: RBP: 00000000fff10b48 R08: 0000000000000000 R09: 0000000000000000 Sep 28 23:10:51 fc8v1 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 Sep 28 23:10:51 fc8v1 kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Sep 28 23:10:51 fc8v1 kernel: FS: 0000000000000000(0000) GS:ffffffff8141a000(0063) knlGS:00000000f7ef16c0 Sep 28 23:10:51 fc8v1 kernel: CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b Sep 28 23:10:51 fc8v1 kernel: CR2: 0000000081026580 CR3: 0000000004625000 CR4: 00000000000006e0 Sep 28 23:10:51 fc8v1 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 28 23:10:51 fc8v1 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Sep 28 23:10:51 fc8v1 kernel: Process nxserver (pid: 2479, threadinfo ffff8100060e4000, task ffff81000b538000) Sep 28 23:10:51 fc8v1 kernel: Stack: ffffffff8158fe48 0000000081026555 ffffffff8158ff58 000000000000002b Sep 28 23:10:51 fc8v1 kernel: 0000000000000040 0000000081026580 ffffffff8158feb8 ffffffff8100daca Sep 28 23:10:51 fc8v1 kernel: 0000000000000000 0000000000000000 ffffffff812aa564 ffffffff8158ff58 Sep 28 23:10:51 fc8v1 kernel: Call Trace: Sep 28 23:10:51 fc8v1 kernel: <#DF> [<ffffffff8100daca>] ? show_registers+0xbc/0x211 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff81299548>] ? __die+0x94/0xfa Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8100dd3f>] ? die+0x42/0x66 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8100de51>] ? do_double_fault+0x63/0x65 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8100d339>] ? double_fault+0x89/0xa0 Sep 28 23:10:51 fc8v1 kernel: <<EOE>> Sep 28 23:10:51 fc8v1 kernel: Sep 28 23:10:51 fc8v1 kernel: Code: Bad RIP value. Sep 28 23:10:51 fc8v1 kernel: RIP [<0000000081026580>] Sep 28 23:10:51 fc8v1 kernel: RSP <0000000000000000> Sep 28 23:10:51 fc8v1 kernel: ---[ end trace e74e5e35529f801d ]--- Sep 28 23:10:51 fc8v1 kernel: BUG: sleeping function called from invalid context at kernel/rwsem.c:21 Sep 28 23:10:51 fc8v1 kernel: in_atomic():0, irqs_disabled():1 Sep 28 23:10:51 fc8v1 kernel: Pid: 2479, comm: nxserver Tainted: G D 2.6.26.3-14.fc8 #1 Sep 28 23:10:51 fc8v1 kernel: Sep 28 23:10:51 fc8v1 kernel: Call Trace: Sep 28 23:10:51 fc8v1 kernel: <#DF> [<ffffffff8102bfbb>] __might_sleep+0xd5/0xd9 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff81297c2b>] down_read+0x1d/0x2e Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8105f30c>] acct_collect+0x4c/0x1a0 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8103946a>] do_exit+0x213/0x83d Sep 28 23:10:51 fc8v1 kernel: [<ffffffff81299237>] oops_begin+0x0/0xa6 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8100dd5a>] die+0x5d/0x66 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8100de51>] do_double_fault+0x63/0x65 Sep 28 23:10:51 fc8v1 kernel: [<ffffffff8100d339>] double_fault+0x89/0xa0 Sep 28 23:10:51 fc8v1 kernel: <<EOE>> from System.map: ffffffff81026580 T ia32_sysenter_target The reported oops address in 2.6.26.3-14 is <0000000081026580> The report on 2.6.25.11-60 is consistent with this one. Somehow the top half of the address got zeroed?? This is apparently a bug in kvm, fixed in kvm-74. Alexanders patch is at: http://thread.gmane.org/gmane.comp.emulators.kvm.devel/20012/focus=20235 Or to be more specific: diff --git a/qemu/target-i386/cpu.h b/qemu/target-i386/cpu.h index 7e95900..61c39d4 100644 --- a/qemu/target-i386/cpu.h +++ b/qemu/target-i386/cpu.h @@ -542,8 +542,8 @@ typedef struct CPUX86State { /* sysenter registers */ uint32_t sysenter_cs; - uint32_t sysenter_esp; - uint32_t sysenter_eip; + uint64_t sysenter_esp; + uint64_t sysenter_eip; uint64_t efer; uint64_t star; kvm-65-10.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/kvm-65-10.fc9 kvm-65-10.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kvm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8846 Updated to kvm-65-10.fc9 and I can successfully connect to my vm using nxclient with no kernel faults. As far as I'm concerned, the updated rpm fixes this bug - Thanks! kvm-65-10.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. |