Bug 13313 - (vm86old) vm86old oops
(vm86old)
vm86old oops
Status: CLOSED CODE_FIX
Product: Platform Specific/Hardware
Classification: Unclassified
Component: i386
All Linux
: P1 normal
Assigned To: platform_i386
:
Depends on:
Blocks: 13070
  Show dependency treegraph
 
Reported: 2009-05-14 21:53 UTC by Sergey Senozhatsky
Modified: 2009-06-11 13:14 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.30-rc5-git5
Tree: Mainline
Regression: Yes


Attachments
.config (81.99 KB, text/plain)
2009-05-14 21:53 UTC, Sergey Senozhatsky
Details
vbetool (-g3 -ggdb) (133.89 KB, application/octet-stream)
2009-06-06 11:03 UTC, Sergey Senozhatsky
Details
kernel 2.6.30-rc8-git2 (debug info) (50 bytes, text/plain)
2009-06-06 11:21 UTC, Sergey Senozhatsky
Details
Possible fix? (3.90 KB, patch)
2009-06-07 18:28 UTC, H. Peter Anvin
Details | Diff

Description Sergey Senozhatsky 2009-05-14 21:53:09 UTC
Created attachment 21359 [details]
.config

Hello,
hardware: ASUS f3jc
kernel: 2.6.30-rc5-git5

Kernel built with
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_LOCKDEP=y

leads to:
[   14.816002] general protection fault: 0000 [#1] PREEMPT SMP 
[   14.816073] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
[   14.816110] Modules linked in: fuse sbp2 snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm serio_raw snd_seq_midi psmouse snd_rawmidi snd_seq_midi_event i2c_i801 snd_seq pcspkr snd_timer snd_seq_device rng_core snd evdev asus_laptop soundcore led_class snd_page_alloc usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi ata_piix ohci1394 libata ehci_hcd uhci_hcd r8169 mii ieee1394 scsi_mod ide_pci_generic usbcore
[   14.816636] 
[   14.816659] Pid: 2379, comm: vbetool Not tainted (2.6.30-rc5-git5-fb #3) F3JC                
[   14.816701] EIP: 0060:[<c018c967>] EFLAGS: 00013286 CPU: 0
[   14.816738] EIP is at lockdep_sys_exit+0x7/0xa0
[   14.816769] EAX: f60d6000 EBX: f60d7ed4 ECX: 00000000 EDX: 00000000
[   14.816805] ESI: c06f53c0 EDI: f6ac42b0 EBP: f60d7ec0 ESP: f60d7eac
[   14.816839]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   14.816873] Process vbetool (pid: 2379, ti=f60d6000 task=f6ac42b0 task.ti=f60d6000)
[   14.816910] Stack:
[   14.816933]  f60d7ec8 c01454cd 00000000 b0c29a68 f60d7ed4 f60d6000 c0128fc8 00000000
[   14.817024]  00000000 f60d6000 00000000 0000000f 00000000 00000000 00000000 00000000
[   14.817136]  00004f04 00000000 00000000 00000000 00000000 00000000 0000100a 0000c000
[   14.817260] Call Trace:
[   14.817283]  [<c01454cd>] ? copy_vm86_regs_from_user+0x3d/0x60
[   14.817329]  [<c0128fc8>] ? resume_userspace+0x8/0x28
[   14.817375]  [<c012918c>] ? syscall_call+0x7/0xb
[   14.817415] Code: 89 44 24 08 89 5c 24 04 c7 04 24 0d ff 5c c0 e8 20 51 36 00 eb c0 e8 e9 2e fd ff 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 83 ec 10 <65> a1 14 00 00 00 89 45 f8 31 c0 64 8b 1d 20 30 6f c0 8b 93 b0 
[   14.818042] EIP: [<c018c967>] lockdep_sys_exit+0x7/0xa0 SS:ESP 0068:f60d7eac
[   14.818136] ---[ end trace 15302304171b6ed3 ]---


reproduces with command (for example) 
vbetool vbemode get

strace (vbetool vbemode get):
execve("/usr/sbin/vbetool", ["vbetool", "vbemode", "get"], [/* 38 vars */]) = 0
brk(0)                                  = 0x99d5000
access("/etc/ld.so.nohwcap", F_OK)      = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8078000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=72327, ...}) = 0
mmap2(NULL, 72327, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb8066000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = 0
open("/usr/lib/libz.so.1", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=82160, ...}) = 0
mmap2(NULL, 84892, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb8051000
mmap2(0xb8065000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xb8065000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = 0
open("/lib/libx86.so.1", O_RDONLY)      = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\5\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=7712, ...}) = 0
mmap2(NULL, 11884, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb804e000
mmap2(0xb8050000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb8050000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = 0
open("/usr/lib/libpci.so.3", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \30\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=39052, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb804d000
mmap2(NULL, 37824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb8043000
mmap2(0xb804c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9) = 0xb804c000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320h\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1310924, ...}) = 0
mmap2(NULL, 1316432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f01000
mmap2(0xb803d000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13c) = 0xb803d000
mmap2(0xb8040000, 9808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb8040000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = 0
open("/lib/libresolv.so.2", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@&\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=71376, ...}) = 0
mmap2(NULL, 84036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7eec000
mmap2(0xb7efd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10) = 0xb7efd000
mmap2(0xb7eff000, 6212, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eff000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7eeb000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7eeb6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, us
eable:1}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "Y9e\332", 4)                   = 4
close(3)                                = 0
mprotect(0xb7efd000, 4096, PROT_READ)   = 0
mprotect(0xb803d000, 8192, PROT_READ)   = 0
mprotect(0xb8096000, 4096, PROT_READ)   = 0
munmap(0xb8066000, 72327)               = 0
open("/dev/zero", O_RDWR)               = 3
mmap2(0x1000, 655360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3, 0) = 0x1000
close(3)                                = 0
open("/dev/mem", O_RDWR)                = 3
mmap2(NULL, 1282, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3, 0) = 0
mmap2(0xa0000, 393216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3, 0xa0) = 0xa0000
close(3)                                = 0
iopl(0x3)                               = 0
brk(0)                                  = 0x99d5000
brk(0x99f6000)                          = 0x99f6000
access("/sys/bus/pci", R_OK)            = 0
vm86old(0xb8050dcc <unfinished ...>
+++ killed by SIGSEGV +++

Sergey
Comment 1 Rafael J. Wysocki 2009-06-01 20:23:54 UTC
On Sunday 31 May 2009, Sergey Senozhatsky wrote:
> On (05/30/09 21:37), Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13313
> > Subject		: vm86old oops
> > Submitter	: Sergey Senozhatsky <sergey.senozhatsky@mail.by>
> > Date		: 2009-05-14 21:53 (17 days old)
> > 
> 
> Hello Rafael.
> Linux 2.6.30-rc7-git4
> Bug is still here.
> 
> dmesg:
> 
> [   17.754509] Modules linked in: fuse sbp2 snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq
> snd_timer snd_seq_device serio_raw psmouse i2c_i801 pcspkr snd rng_core soundcore snd_page_alloc asus_laptop led_class evdev usbhid hid sg sr_mod cdrom sd_mod ata_generic
> pata_acpi ata_piix ohci1394 libata ieee1394 ehci_hcd uhci_hcd scsi_mod ide_pci_generic r8169 mii usbcore
> [   17.755064] 
> [   17.755087] Pid: 2416, comm: vbetool Not tainted (2.6.30-rc7-fb-git4 #9) F3JC                
> [   17.755134] EIP: 0060:[<c016cdf7>] EFLAGS: 00013286 CPU: 0
> [   17.755174] EIP is at lockdep_sys_exit+0x7/0xa0
> [   17.755207] EAX: f609a000 EBX: f609bed4 ECX: 00000000 EDX: 00000000
> [   17.755246] ESI: f61887a0 EDI: c1ce1100 EBP: f609bec0 ESP: f609beac
> [   17.755284]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [   17.755322] Process vbetool (pid: 2416, ti=f609a000 task=f61887a0 task.ti=f609a000)
> [   17.755365] Stack:
> [   17.755387]  c01203a9 c012026d 00000000 d8079a0f f609bed4 f609a000 c01032c8 00000000
> [   17.755484]  00000000 f609a000 00000000 0000000f 00000000 00000000 00000000 00000000
> [   17.755602]  00004f04 00000000 00000000 00000000 00000000 00000000 0000100a 0000c000
> [   17.755732] Call Trace:
> [   17.755759]  [<c01203a9>] ? do_sys_vm86+0x119/0x270
> [   17.755809]  [<c012026d>] ? copy_vm86_regs_from_user+0x3d/0x60
> [   17.755857]  [<c01032c8>] ? resume_userspace+0x8/0x28
> [   17.755904]  [<c0103474>] ? syscall_call+0x7/0xb
> [   17.755947] Code: 89 44 24 08 89 5c 24 04 c7 04 24 a8 06 5b c0 e8 a7 a1 36 00 eb c0 e8 89 13 fd ff 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 83 ec 10 <65> a1 14 00 00 00 89 45 f8
> 31 c0 64 8b 1d 00 80 6c c0 8b 8b dc 
> [   17.756585] EIP: [<c016cdf7>] lockdep_sys_exit+0x7/0xa0 SS:ESP 0068:f609beac
> [   17.756694] ---[ end trace dcebd4adaaf1918c ]---
Comment 2 H. Peter Anvin 2009-06-04 23:40:09 UTC
I'm unable to reproduce this.  What distribution are you running?
Comment 3 Sergey Senozhatsky 2009-06-05 09:50:01 UTC
> --- Comment #2 from H. Peter Anvin <hpa@zytor.com>  2009-06-04 23:40:09 ---
> I'm unable to reproduce this.  What distribution are you running?
> 

Hello Peter.
I'm using debian squeeze/sid  (kernel 2.6.30-rc8-git1).

vbetool vbemode get

dmesg:
[  285.419048] general protection fault: 0000 [#1] PREEMPT SMP 
[  285.419067] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/energy_full
[  285.419076] Modules linked in: ipv6 fuse sbp2 snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi serio_raw psmouse
snd_seq_midi_event snd_seq pcspkr i2c_i801 snd_timer snd_seq_device rng_core snd evdev soundcore snd_page_alloc asus_laptop led_class usbhid hid sg sr_mod cdrom sd_mod ata_generic
pata_acpi ata_piix libata ohci1394 ieee1394 uhci_hcd ehci_hcd scsi_mod ide_pci_generic usbcore r8169 mii
[  285.419211] 
[  285.419221] Pid: 3534, comm: vbetool Not tainted (2.6.30-rc8-nv-git1 #1) F3JC                
[  285.419229] EIP: 0060:[<c016cdd7>] EFLAGS: 00213286 CPU: 1
[  285.419243] EIP is at lockdep_sys_exit+0x7/0xa0
[  285.419252] EAX: d160e000 EBX: d160fed4 ECX: 00000000 EDX: 00000000
[  285.419259] ESI: f2908020 EDI: c1e2c100 EBP: d160fec0 ESP: d160feac
[  285.419267]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  285.419276] Process vbetool (pid: 3534, ti=d160e000 task=f2908020 task.ti=d160e000)
[  285.419283] Stack:
[  285.419288]  c01203a9 c012026d 00000000 2ed11dce d160fed4 d160e000 c01032c8 00000000
[  285.419313]  00000000 d160e000 00000000 00000000 00000000 00000000 00000000 00000000
[  285.419340]  00004f03 00000000 00000000 00000000 00000000 00000000 0000100a 0000c000
[  285.419369] Call Trace:
[  285.419375]  [<c01203a9>] ? do_sys_vm86+0x119/0x270
[  285.419390]  [<c012026d>] ? copy_vm86_regs_from_user+0x3d/0x60
[  285.419403]  [<c01032c8>] ? resume_userspace+0x8/0x28
[  285.419420]  [<c0103474>] ? syscall_call+0x7/0xb
[  285.419432] Code: 89 44 24 08 89 5c 24 04 c7 04 24 a4 16 5b c0 e8 49 a3 36 00 eb c0 e8 a9 13 fd ff 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 83 ec 10 <65> a1 14 00 00 00 89 45 f8
31 c0 64 8b 1d 00 80 6c c0 8b 8b dc 
[  285.419593] EIP: [<c016cdd7>] lockdep_sys_exit+0x7/0xa0 SS:ESP 0068:d160feac
[  285.419615] ---[ end trace e96e758c02ca6438 ]---



	Sergey
Comment 4 H. Peter Anvin 2009-06-05 23:43:14 UTC
Could you please attach your vbetools binary?  It might help, or it might clarify if this is something that requires your particular system to reproduce.  Also, it would be helpful if you could compile your kernel with CONFIG_DEBUG_INFO and attach your vmlinux file (to try to examine the error in more detail.)

It's tripping over a gs: reference, which looks to me like the stack protector.  However, gs: has the correct value to point to the stack canary, which implies that there is something fishy with the GDT:

00000000  89442408          mov [esp+0x8],eax
00000004  895C2404          mov [esp+0x4],ebx
00000008  C70424A4165BC0    mov dword [esp],0xc05b16a4
0000000F  E849A33600        call dword 0x36a35d
00000014  EBC0              jmp short 0xffffffd6
00000016  E8A913FDFF        call dword 0xfffd13c4
0000001B  89F6              mov esi,esi
0000001D  8DBC2700000000    lea edi,[edi+0x0]
00000024  55                push ebp
00000025  89E5              mov ebp,esp
00000027  53                push ebx
00000028  83EC10            sub esp,byte +0x10
0000002B  65A114000000      mov eax,[gs:0x14]            <--- #GP trap here
00000031  8945F8            mov [ebp-0x8],eax
00000034  31C0              xor eax,eax
00000036  648B1D00806CC0    mov ebx,[dword fs:0xc06c8000]

I'm not sure why it doesn't happen when I try it.  It could be compiler-dependent, or having something to do with the system.
Comment 5 Sergey Senozhatsky 2009-06-06 11:02:47 UTC
> --- Comment #4 from H. Peter Anvin <hpa@zytor.com>  2009-06-05 23:43:14 ---
> Could you please attach your vbetools binary?  It might help, or it might
> clarify if this is something that requires your particular system to reproduce.
>  Also, it would be helpful if you could compile your kernel with
> CONFIG_DEBUG_INFO and attach your vmlinux file (to try to examine the error in
> more detail.)
> 
> It's tripping over a gs: reference, which looks to me like the stack protector.
>  However, gs: has the correct value to point to the stack canary, which implies
> that there is something fishy with the GDT:
> 
> 00000000  89442408          mov [esp+0x8],eax
> 00000004  895C2404          mov [esp+0x4],ebx
> 00000008  C70424A4165BC0    mov dword [esp],0xc05b16a4
> 0000000F  E849A33600        call dword 0x36a35d
> 00000014  EBC0              jmp short 0xffffffd6
> 00000016  E8A913FDFF        call dword 0xfffd13c4
> 0000001B  89F6              mov esi,esi
> 0000001D  8DBC2700000000    lea edi,[edi+0x0]
> 00000024  55                push ebp
> 00000025  89E5              mov ebp,esp
> 00000027  53                push ebx
> 00000028  83EC10            sub esp,byte +0x10
> 0000002B  65A114000000      mov eax,[gs:0x14]            <--- #GP trap here
> 00000031  8945F8            mov [ebp-0x8],eax
> 00000034  31C0              xor eax,eax
> 00000036  648B1D00806CC0    mov ebx,[dword fs:0xc06c8000]
> 
> I'm not sure why it doesn't happen when I try it.  It could be
> compiler-dependent, or having something to do with the system.
> 

Hello Peter.
I compiled vbetools with -g3 -ggdb.

vbetools vbemode get
[ 4346.704647] general protection fault: 0000 [#11] PREEMPT SMP 
[ 4346.704666] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/energy_full
[ 4346.704675] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse sbp2 snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device serio_raw psmouse snd i2c_i801 pcspkr rng_core soundcore snd_page_alloc evdev
asus_laptop led_class usbhid hid sg sr_mod cdrom sd_mod ata_generic pata_acpi ata_piix ohci1394 libata scsi_mod ieee1394 ide_pci_generic ehci_hcd uhci_hcd r8169 mii usbcore
[ 4346.704825] 
[ 4346.704835] Pid: 4327, comm: vbetool Tainted: G      D    (2.6.30-rc8-nv-dbg-git2 #1) F3JC                
[ 4346.704845] EIP: 0060:[<c016cde7>] EFLAGS: 00213286 CPU: 1
[ 4346.704859] EIP is at lockdep_sys_exit+0x7/0xa0
[ 4346.704868] EAX: c1f8a000 EBX: c1f8bed4 ECX: 00000000 EDX: 00000000
[ 4346.704876] ESI: c1fa6520 EDI: c3f37100 EBP: c1f8bec0 ESP: c1f8beac
[ 4346.704884]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 4346.704893] Process vbetool (pid: 4327, ti=c1f8a000 task=c1fa6520 task.ti=c1f8a000)
[ 4346.704900] Stack:
[ 4346.704905]  c01203a9 c012026d 00000000 7d0dbc0e c1f8bed4 c1f8a000 c01032c8 00000000
[ 4346.704930]  00000000 c1f8a000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4346.704956]  00004f03 00000000 00000000 00000000 00000000 00000000 0000100a 0000c000
[ 4346.704985] Call Trace:
[ 4346.704992]  [<c01203a9>] ? do_sys_vm86+0x119/0x270
[ 4346.705006]  [<c012026d>] ? copy_vm86_regs_from_user+0x3d/0x60
[ 4346.705020]  [<c01032c8>] ? resume_userspace+0x8/0x28
[ 4346.705038]  [<c0103474>] ? syscall_call+0x7/0xb
[ 4346.705050] Code: 89 44 24 08 89 5c 24 04 c7 04 24 e4 16 5b c0 e8 49 a3 36 00 eb c0 e8 89 13 fd ff 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 83 ec 10 <65> a1 14 00 00 00 89 45 f8
31 c0 64 8b 1d 00 80 6c c0 8b 8b dc 
[ 4346.705209] EIP: [<c016cde7>] lockdep_sys_exit+0x7/0xa0 SS:ESP 0068:c1f8beac
[ 4346.705230] ---[ end trace b427bd0ea6b59e4a ]---


(gdb) break LRMI_int
Function "LRMI_int" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (LRMI_int) pending.
(gdb) run vbemode get
Starting program: /media/dev/vbetool/vbetool-1.1/vbetool vbemode get

Breakpoint 1, 0xb80892e6 in LRMI_int () from /lib/libx86.so.1
(gdb) bt
#0  0xb80892e6 in LRMI_int () from /lib/libx86.so.1
#1  0x08049828 in do_vbe_service (AX=20227, BX=0, regs=0xbfe894b8) at vbetool.c:169
#2  0x0804a0c9 in do_get_mode () at vbetool.c:465
#3  0x0804950f in main (argc=3, argv=0xbfe895d4) at vbetool.c:97
(gdb) stepi
0xb80892e9 in LRMI_int () from /lib/libx86.so.1
(gdb) stepi
0xb8088677 in ?? () from /lib/libx86.so.1
(gdb) x/a 0xb8088677
0xb8088677 <__cxa_finalize@plt+199>:	0xc3241c8b
(gdb) stepi
0xb808867a in ?? () from /lib/libx86.so.1
(gdb) x/a 0xb808867a
0xb808867a <__cxa_finalize@plt+202>:	0x909090c3
(gdb) stepi
0xb80892ee in LRMI_int () from /lib/libx86.so.1
(gdb) stepi
0xb80892f4 in LRMI_int () from /lib/libx86.so.1
(gdb) bt
#0  0xb80892f4 in LRMI_int () from /lib/libx86.so.1
#1  0x08049828 in do_vbe_service (AX=20227, BX=0, regs=0xbfe894b8) at vbetool.c:169
#2  0x0804a0c9 in do_get_mode () at vbetool.c:465
#3  0x0804950f in main (argc=3, argv=0xbfe895d4) at vbetool.c:97
(gdb) stepi
0xb80892f7 in LRMI_int () from /lib/libx86.so.1
0xb80892fb in LRMI_int () from /lib/libx86.so.1
(gdb) stepi 5
0xb8089315 in LRMI_int () from /lib/libx86.so.1
(gdb) stepi 5
...
(gdb) stepi 5
0xb8089440 in LRMI_int () from /lib/libx86.so.1
(gdb) stepi 5
0xb8088da0 in ?? () from /lib/libx86.so.1
(gdb) bt
#0  0xb8088da0 in ?? () from /lib/libx86.so.1
#1  0xb808945a in LRMI_int () from /lib/libx86.so.1
#2  0x08049828 in do_vbe_service (AX=20227, BX=0, regs=0xbfe894b8) at vbetool.c:169
#3  0x0804a0c9 in do_get_mode () at vbetool.c:465
#4  0x0804950f in main (argc=3, argv=0xbfe895d4) at vbetool.c:97
(gdb) disassemble 0xb808945a
Dump of assembler code for function LRMI_int:
0xb80892e0 <LRMI_int+0>:	push   %ebp
0xb80892e1 <LRMI_int+1>:	mov    %esp,%ebp
0xb80892e3 <LRMI_int+3>:	sub    $0x18,%esp
0xb80892e6 <LRMI_int+6>:	mov    %ebx,-0xc(%ebp)
0xb80892e9 <LRMI_int+9>:	call   0xb8088677 <__cxa_finalize@plt+199>
0xb80892ee <LRMI_int+14>:	add    $0x1646,%ebx
0xb80892f4 <LRMI_int+20>:	mov    %esi,-0x8(%ebp)
0xb80892f7 <LRMI_int+23>:	mov    %edi,-0x4(%ebp)
0xb80892fa <LRMI_int+26>:	cld    
0xb80892fb <LRMI_int+27>:	mov    0x8(%ebp),%eax
0xb80892fe <LRMI_int+30>:	mov    0xc(%ebp),%esi
0xb8089301 <LRMI_int+33>:	movzwl 0x2(,%eax,4),%edx
0xb8089309 <LRMI_int+41>:	movzwl 0x0(,%eax,4),%eax
0xb8089311 <LRMI_int+49>:	mov    %dx,-0xe(%ebp)
0xb8089315 <LRMI_int+53>:	movzwl %dx,%edx
0xb8089318 <LRMI_int+56>:	cmp    $0x9fff,%edx
0xb808931e <LRMI_int+62>:	jbe    0xb8089333 <LRMI_int+83>
0xb8089320 <LRMI_int+64>:	movzwl %ax,%eax
0xb8089323 <LRMI_int+67>:	shl    $0x4,%edx
0xb8089326 <LRMI_int+70>:	mov    %eax,-0x14(%ebp)
0xb8089329 <LRMI_int+73>:	lea    (%edx,%eax,1),%eax
0xb808932c <LRMI_int+76>:	cmp    $0xfffff,%eax
0xb8089331 <LRMI_int+81>:	jbe    0xb8089348 <LRMI_int+104>
0xb8089333 <LRMI_int+83>:	xor    %edx,%edx
0xb8089335 <LRMI_int+85>:	mov    -0xc(%ebp),%ebx
0xb8089338 <LRMI_int+88>:	mov    %edx,%eax
0xb808933a <LRMI_int+90>:	mov    -0x8(%ebp),%esi
0xb808933d <LRMI_int+93>:	mov    -0x4(%ebp),%edi
0xb8089340 <LRMI_int+96>:	mov    %ebp,%esp
0xb8089342 <LRMI_int+98>:	pop    %ebp
0xb8089343 <LRMI_int+99>:	ret    
0xb8089344 <LRMI_int+100>:	lea    0x0(%esi,%eiz,1),%esi
0xb8089348 <LRMI_int+104>:	xor    %eax,%eax
0xb808934a <LRMI_int+106>:	mov    $0x15,%ecx
0xb808934f <LRMI_int+111>:	lea    0x498(%ebx),%edi
0xb8089355 <LRMI_int+117>:	rep stos %eax,%es:(%edi)
0xb8089357 <LRMI_int+119>:	movzwl -0xe(%ebp),%ecx
0xb808935b <LRMI_int+123>:	movl   $0x3200,0x4d0(%ebx)
0xb8089365 <LRMI_int+133>:	mov    (%esi),%eax
0xb8089367 <LRMI_int+135>:	mov    %eax,0x4a8(%ebx)
0xb808936d <LRMI_int+141>:	mov    0x4(%esi),%eax
0xb8089370 <LRMI_int+144>:	mov    %eax,0x4a4(%ebx)
0xb8089376 <LRMI_int+150>:	mov    0x8(%esi),%eax
0xb8089379 <LRMI_int+153>:	mov    %eax,0x4ac(%ebx)
0xb808937f <LRMI_int+159>:	mov    0x10(%esi),%eax
0xb8089382 <LRMI_int+162>:	mov    %eax,0x498(%ebx)
0xb8089388 <LRMI_int+168>:	mov    0x14(%esi),%eax
0xb808938b <LRMI_int+171>:	mov    %eax,0x4a0(%ebx)
0xb8089391 <LRMI_int+177>:	mov    0x18(%esi),%eax
0xb8089394 <LRMI_int+180>:	mov    %eax,0x49c(%ebx)
0xb808939a <LRMI_int+186>:	mov    0x1c(%esi),%eax
0xb808939d <LRMI_int+189>:	mov    %eax,0x4b0(%ebx)
0xb80893a3 <LRMI_int+195>:	movzwl 0x22(%esi),%eax
0xb80893a7 <LRMI_int+199>:	mov    %ax,0x4dc(%ebx)
0xb80893ae <LRMI_int+206>:	movzwl 0x24(%esi),%eax
0xb80893b2 <LRMI_int+210>:	mov    %ax,0x4e0(%ebx)
0xb80893b9 <LRMI_int+217>:	movzwl 0x26(%esi),%eax
0xb80893bd <LRMI_int+221>:	mov    %ax,0x4e4(%ebx)
0xb80893c4 <LRMI_int+228>:	movzwl 0x28(%esi),%eax
0xb80893c8 <LRMI_int+232>:	mov    %cx,0x4cc(%ebx)
0xb80893cf <LRMI_int+239>:	mov    %ax,0x4e8(%ebx)
0xb80893d6 <LRMI_int+246>:	movzwl 0x30(%esi),%edx
0xb80893da <LRMI_int+250>:	mov    -0x14(%ebp),%eax
0xb80893dd <LRMI_int+253>:	test   %dx,%dx
0xb80893e0 <LRMI_int+256>:	mov    %eax,0x4c8(%ebx)
0xb80893e6 <LRMI_int+262>:	jne    0xb80894d8 <LRMI_int+504>
0xb80893ec <LRMI_int+268>:	movzwl 0x2e(%esi),%eax
0xb80893f0 <LRMI_int+272>:	test   %ax,%ax
0xb80893f3 <LRMI_int+275>:	je     0xb80894e8 <LRMI_int+520>
0xb80893f9 <LRMI_int+281>:	movzwl %ax,%eax
0xb80893fc <LRMI_int+284>:	mov    %dx,0x4d8(%ebx)
0xb8089403 <LRMI_int+291>:	mov    %eax,0x4d4(%ebx)
0xb8089409 <LRMI_int+297>:	movzwl 0x4d8(%ebx),%eax
0xb8089410 <LRMI_int+304>:	mov    0x4d4(%ebx),%ecx
0xb8089416 <LRMI_int+310>:	shl    $0x4,%eax
0xb8089419 <LRMI_int+313>:	movw   $0x3200,-0x2(%ecx,%eax,1)
0xb8089420 <LRMI_int+320>:	movzwl 0x4d8(%ebx),%eax
0xb8089427 <LRMI_int+327>:	movzwl 0x490(%ebx),%edx
0xb808942e <LRMI_int+334>:	shl    $0x4,%eax
0xb8089431 <LRMI_int+337>:	mov    %dx,-0x4(%ecx,%eax,1)
0xb8089436 <LRMI_int+342>:	lea    -0x6(%ecx),%eax
0xb8089439 <LRMI_int+345>:	movzwl 0x492(%ebx),%edx
0xb8089440 <LRMI_int+352>:	mov    %eax,0x4d4(%ebx)
0xb8089446 <LRMI_int+358>:	movzwl 0x4d8(%ebx),%eax
0xb808944d <LRMI_int+365>:	shl    $0x4,%eax
0xb8089450 <LRMI_int+368>:	mov    %dx,-0x6(%ecx,%eax,1)
0xb8089455 <LRMI_int+373>:	call   0xb8088da0		; ...
0xb808945a <LRMI_int+378>:	mov    %eax,%edx		; frame #1
0xb808945c <LRMI_int+380>:	mov    0x4a8(%ebx),%eax
0xb8089462 <LRMI_int+386>:	mov    %eax,(%esi)
0xb8089464 <LRMI_int+388>:	mov    0x4a4(%ebx),%eax
0xb808946a <LRMI_int+394>:	mov    %eax,0x4(%esi)
0xb808946d <LRMI_int+397>:	mov    0x4ac(%ebx),%eax
0xb8089473 <LRMI_int+403>:	mov    %eax,0x8(%esi)
0xb8089476 <LRMI_int+406>:	mov    0x498(%ebx),%eax
0xb808947c <LRMI_int+412>:	mov    %eax,0x10(%esi)
0xb808947f <LRMI_int+415>:	mov    0x4a0(%ebx),%eax
0xb8089485 <LRMI_int+421>:	mov    %eax,0x14(%esi)
0xb8089488 <LRMI_int+424>:	mov    0x49c(%ebx),%eax
0xb808948e <LRMI_int+430>:	mov    %eax,0x18(%esi)
0xb8089491 <LRMI_int+433>:	mov    0x4b0(%ebx),%eax
0xb8089497 <LRMI_int+439>:	mov    %eax,0x1c(%esi)
0xb808949a <LRMI_int+442>:	mov    0x4d0(%ebx),%eax
0xb80894a0 <LRMI_int+448>:	mov    %ax,0x20(%esi)
0xb80894a4 <LRMI_int+452>:	movzwl 0x4dc(%ebx),%eax
0xb80894ab <LRMI_int+459>:	mov    %ax,0x22(%esi)
0xb80894af <LRMI_int+463>:	movzwl 0x4e0(%ebx),%eax
0xb80894b6 <LRMI_int+470>:	mov    %ax,0x24(%esi)
0xb80894ba <LRMI_int+474>:	movzwl 0x4e4(%ebx),%eax
0xb80894c1 <LRMI_int+481>:	mov    %ax,0x26(%esi)
0xb80894c5 <LRMI_int+485>:	movzwl 0x4e8(%ebx),%eax
0xb80894cc <LRMI_int+492>:	mov    %ax,0x28(%esi)
0xb80894d0 <LRMI_int+496>:	jmp    0xb8089335 <LRMI_int+85>
0xb80894d5 <LRMI_int+501>:	lea    0x0(%esi),%esi
0xb80894d8 <LRMI_int+504>:	movzwl 0x2e(%esi),%eax
0xb80894dc <LRMI_int+508>:	jmp    0xb80893f9 <LRMI_int+281>
0xb80894e1 <LRMI_int+513>:	lea    0x0(%esi,%eiz,1),%esi
0xb80894e8 <LRMI_int+520>:	movzwl 0x494(%ebx),%eax
0xb80894ef <LRMI_int+527>:	mov    %ax,0x4d8(%ebx)
0xb80894f6 <LRMI_int+534>:	movzwl 0x496(%ebx),%eax
0xb80894fd <LRMI_int+541>:	mov    %eax,0x4d4(%ebx)
0xb8089503 <LRMI_int+547>:	jmp    0xb8089409 <LRMI_int+297>
End of assembler dump.
(gdb) stepi
0xb8088da1 in ?? () from /lib/libx86.so.1
...
0xb8088dc6 in ?? () from /lib/libx86.so.1
(gdb) stepi
0xb8088dc8 in ?? () from /lib/libx86.so.1
(gdb) stepi

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.


As for 'compiler-dependent', I use gcc 'svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch'
gcc -v
Target: i686-linux-gnu
Configured with: ./configure -v --enable-languages=c,c++ --prefix=/usr --enable-shared
 --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
 --enable-nls --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4
 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=i686-linux-gnu
 --enable-cld --with-tune=i686 --disable-multilib --enable-checking=release --build=i686-linux-gnu
 --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.4 20090605 (prerelease) (Debian 4.4)


attached:
vbetool (dbg);
vmlinux (debug info).


	Sergey
Comment 6 Sergey Senozhatsky 2009-06-06 11:03:55 UTC
Created attachment 21777 [details]
vbetool (-g3 -ggdb)
Comment 7 Sergey Senozhatsky 2009-06-06 11:21:12 UTC
Created attachment 21778 [details]
kernel 2.6.30-rc8-git2 (debug info)
Comment 8 Sergey Senozhatsky 2009-06-07 13:52:52 UTC
> --- Comment #4 from H. Peter Anvin <hpa@zytor.com>  2009-06-05 23:43:14 ---
> Could you please attach your vbetools binary?  It might help, or it might
> clarify if this is something that requires your particular system to reproduce.
>  Also, it would be helpful if you could compile your kernel with
> CONFIG_DEBUG_INFO and attach your vmlinux file (to try to examine the error in
> more detail.)
> 
> It's tripping over a gs: reference, which looks to me like the stack protector.
>  However, gs: has the correct value to point to the stack canary, which implies
> that there is something fishy with the GDT:
> 
> 00000000  89442408          mov [esp+0x8],eax
> 00000004  895C2404          mov [esp+0x4],ebx
> 00000008  C70424A4165BC0    mov dword [esp],0xc05b16a4
> 0000000F  E849A33600        call dword 0x36a35d
> 00000014  EBC0              jmp short 0xffffffd6
> 00000016  E8A913FDFF        call dword 0xfffd13c4
> 0000001B  89F6              mov esi,esi
> 0000001D  8DBC2700000000    lea edi,[edi+0x0]
> 00000024  55                push ebp
> 00000025  89E5              mov ebp,esp
> 00000027  53                push ebx
> 00000028  83EC10            sub esp,byte +0x10
> 0000002B  65A114000000      mov eax,[gs:0x14]            <--- #GP trap here
> 00000031  8945F8            mov [ebp-0x8],eax
> 00000034  31C0              xor eax,eax
> 00000036  648B1D00806CC0    mov ebx,[dword fs:0xc06c8000]
> 
> I'm not sure why it doesn't happen when I try it.  It could be
> compiler-dependent, or having something to do with the system.
> 

Hello Peter.
Same error for get-edid.

# get-edid
get-edid: get-edid version 2.0.0

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Segmentation fault


dmesg:
[  241.446838] general protection fault: 0000 [#3] PREEMPT SMP 
[  241.446857] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/energy_full
[  241.446866] Modules linked in: ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc ipv6 fuse sbp2 snd_hda_codec_si3054 snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm serio_raw psmouse pcspkr snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq i2c_i801 snd_timer snd_seq_device rng_core snd soundcore snd_page_alloc
asus_laptop led_class evdev usbhid hid sg sd_mod sr_mod cdrom ata_generic pata_acpi ohci1394 ata_piix ieee1394 ehci_hcd uhci_hcd libata scsi_mod ide_pci_generic r8169 mii usbcore
[  241.447020] 
[  241.447030] Pid: 3199, comm: get-edid Tainted: G      D    (2.6.30-rc8-nv-git4 #4) F3JC                
[  241.447039] EIP: 0060:[<c016cde7>] EFLAGS: 00213286 CPU: 1
[  241.447053] EIP is at lockdep_sys_exit+0x7/0xa0
[  241.447060] EAX: f63c2000 EBX: f63c3ed4 ECX: 00000000 EDX: 00000000
[  241.447069] ESI: f50108e0 EDI: c1e2e100 EBP: f63c3ec0 ESP: f63c3eac
[  241.447077]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  241.447086] Process get-edid (pid: 3199, ti=f63c2000 task=f50108e0 task.ti=f63c2000)
[  241.447092] Stack:
[  241.447097]  c01203a9 c012026d 00000000 2eae39c3 f63c3ed4 f63c2000 c01032c8 00000000
[  241.447123]  00000000 f63c2000 00000000 00000000 00000000 00000000 00000000 00000000
[  241.447149]  00004f00 00000000 00000000 00000000 00000000 00000000 0000100a 0000c000
[  241.447178] Call Trace:
[  241.447184]  [<c01203a9>] ? do_sys_vm86+0x119/0x270
[  241.447199]  [<c012026d>] ? copy_vm86_regs_from_user+0x3d/0x60
[  241.447213]  [<c01032c8>] ? resume_userspace+0x8/0x28
[  241.447230]  [<c0103474>] ? syscall_call+0x7/0xb
[  241.447243] Code: 89 44 24 08 89 5c 24 04 c7 04 24 88 17 5b c0 e8 89 b1 36 00 eb c0 e8 89 13 fd ff 89 f6 8d bc 27 00 00 00 00 55 89 e5 53 83 ec 10 <65> a1 14 00 00 00 89 45 f8
31 c0 64 8b 1d 00 a0 6c c0 8b 8b dc 
[  241.447403] EIP: [<c016cde7>] lockdep_sys_exit+0x7/0xa0 SS:ESP 0068:f63c3eac
[  241.447424] ---[ end trace 361bce12cbd27581 ]---


	Sergey.
Comment 9 H. Peter Anvin 2009-06-07 18:28:03 UTC
Created attachment 21795 [details]
Possible fix?

This patch which was recently committed looks like it might be related.  It would be really great if you could test if this patch addresses your problem.
Comment 10 Sergey Senozhatsky 2009-06-07 19:30:26 UTC
> --- Comment #9 from H. Peter Anvin <hpa@zytor.com>  2009-06-07 18:28:03 ---
> Created an attachment (id=21795)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=21795)
> Possible fix?
> 

Looks like it is.


vbetool vbemode get
3

	Sergey
Comment 11 Rafael J. Wysocki 2009-06-07 20:45:54 UTC
Handled-By : H. Peter Anvin <hpa@zytor.com>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=21795
Comment 12 Sergey Senozhatsky 2009-06-08 09:17:37 UTC
> --- Comment #9 from H. Peter Anvin <hpa@zytor.com>  2009-06-07 18:28:03 ---
> Created an attachment (id=21795)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=21795)
> Possible fix?
> 

Hello Peter.
patch is ok.

Tested-by: Sergey Senozhatsky <sergey.senozhatsky@mail.by>
Comment 13 Rafael J. Wysocki 2009-06-11 13:13:19 UTC
On Thursday 11 June 2009, Sergey Senozhatsky wrote:
> On (06/07/09 11:52), Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13313
> > Subject		: vm86old oops
> > Submitter	: Sergey Senozhatsky <sergey.senozhatsky@mail.by>
> > Date		: 2009-05-14 21:53 (25 days old)
> > 
> 
> Hello Rafael.
> 
> commit 3aa6b186f86c5d06d6d92d14311ffed51f091f40
> Author: Lubomir Rintel <lkundrak@v3.sk>
> Date:   Sun Jun 7 16:23:48 2009 +0200
> 
> x86: Fix non-lazy GS handling in sys_vm86()

Note You need to log in before you can comment on or make changes to this bug.