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
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 ]---
I'm unable to reproduce this. What distribution are you running?
> --- 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
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 #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
Created attachment 21777 [details] vbetool (-g3 -ggdb)
Created attachment 21778 [details] kernel 2.6.30-rc8-git2 (debug info)
> --- 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.
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 #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
Handled-By : H. Peter Anvin <hpa@zytor.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=21795
> --- 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>
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()