From owner-freebsd-current@FreeBSD.ORG Wed Jan 19 06:54:26 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3FDDE106564A; Wed, 19 Jan 2011 06:54:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: bf1783@gmail.com, Marc UBM Bocklet Date: Wed, 19 Jan 2011 01:54:12 -0500 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_ZqoNNogI35BllUL" Message-Id: <201101190154.18380.jkim@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: lockup with vidcontrol VESA_800x600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 06:54:26 -0000 --Boundary-00=_ZqoNNogI35BllUL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 18 January 2011 10:08 pm, b. f. wrote: > Marc UBM Bocklet wrote: > > Yesterday I upgraded to > > > > FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan 8 > > 17:05:30 CET 2011 > > > > and vidcontrol VESA_800x600 stopped working (again). I exchanged > > emails with jkim about a similar problem in February 2010 > > (vidcontrol VESA_800x600 would mangle the screen output), there > > was no definitive resolution, but it started working again > > sometime around July 2010. > > > > Now however, when I try to set VESA_800x600, my machine seems to > > lockup. It no longer responds to any input, I cannot ping it and > > I cannot drop to the debugger. > > > > I've tried setting other modes, but trying to set them results > > in: > > > > obtaining new video mode parameters: operation not supported by > > device. > > > > graphics card is a: > > > > vgapci0 at pci0:1:0:0: class=0x030000 card=0x013a1002 > > chip=0x514c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies > > Inc. / Advanced Micro Devices, Inc.' device = 'Radeon 8500 / > > 8500LE (R200)' class = display > > subclass = VGA > > I'm joining the chorus of those having problems with video > mode-switching on recent 9-CURRENT. From r216756 through r217561, > I'm able to reliably panic my UP i386 machine by using MODE_268, > which 'vidcontrol -i mode' describes as: > > mode# flags type size font window > linear buffer > ------------------------------------------------------------------- >----------- 268 (0x10c) 0x0000000d T 132x60 8x8 0xb8000 > 32k 32k 0xfc000000 15k > > Prior to 28 Dec. 2010, on versions of 9-CURRENT less than three > months old, MODE_268 was my default video mode. A number of other > modes that used to work now also trigger panics. I've been forced > to fall back to MODE_48: > > mode# flags type size font window > linear buffer > ------------------------------------------------------------------- >----------- 48 (0x030) 0x00000001 T 90x60 8x8 0xb8000 > 32k 32k 0x00000000 32k > > which works fine. A representative panic with a problematic mode > is: > > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xcd29a05b > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc0746391 > stack pointer = 0x28:0xcd299714 > frame pointer = 0x28:0xcd299714 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 94550 (vidcontrol) > > and a backtrace shows: > > db:1:lockedvnods> show pcpu > cpuid = 0 > dynamic pcpu = 0x40d080 > curthread = 0xc2b7c5a0: pid 94550 "vidcontrol" > curpcb = 0xcd299d80 > fpcurthread = 0xc2b7c5a0: pid 94550 "vidcontrol" > idlethread = 0xc2851870: tid 100003 "idle" > APIC ID = 0 > currentldt = 0x50 > db:1:pcpu> bt > Tracing pid 94550 tid 100057 td 0xc2b7c5a0 > fpusave(0,9e000,cd299778,c073106c,cd299ff0,...) at 0xc0746391 = > fpusave+0x11 npxsave(cd299ff0) at 0xc07463b1 = npxsave+0x11 > vm86_bioscall(10,cd2997a0,c08540a0,0,0,...) at 0xc073106c = > vm86_bioscall+0x3c x86bios_intr(cd299818,10,cd299848,0,0,...) at > 0xc074d6f2 = x86bios_intr+0xd2 > vesa_set_mode(c084dfc0,10c,cd299920,c2bb8354,5a,...) at 0xc094ee49 > = vesa_set_mode+0xf9 > set_mode(c082ea80,0,3c,0,c2834000,...) at 0xc050cc9f = > set_mode+0x7f sc_set_text_mode(c082ea80,c2834000,10c,84,3c,...) at > 0xc050b0e0 = sc_set_text_mode+0x220 > vesa_ioctl(c2834000,2000560c,cd299cf4,c2b7c5a0,c2b7c5a0,...) at > 0xc095065c = vesa_ioctl+0xac > sctty_ioctl(c2834000,2000560c,cd299cf4,c2b7c5a0,7,...) at > 0xc050f015 = sctty_ioctl+0x35 > tty_ioctl(c2834000,2000560c,cd299cf4,3,c2b7c5a0,...) at 0xc05cb314 > = tty_ioctl+0x44 > ttydev_ioctl(c28c5800,2000560c,cd299cf4,3,c2b7c5a0,...) at > 0xc05cca1d = ttydev_ioctl+0x1ad > devfs_ioctl_f(c2a75508,2000560c,cd299cf4,c2a53780,c2b7c5a0,...) at > 0xc0516b3a = devfs_ioctl_f+0x10a > kern_ioctl(c2b7c5a0,0,2000560c,cd299cf4,299cec,...) at 0xc05bbae8 = > kern_ioctl+0x288 > ioctl(c2b7c5a0,cd299cec,cd299d28,cd299d80,28161bb0,...) at > 0xc05bbc4f = ioctl+0x12f > syscallenter(c2b7c5a0,cd299ce4,cd299ce4,0,c2b7c5a0,...) at > 0xc05b7428 = syscallenter+0x348 > syscall(cd299d28) at 0xc0743ab4 = syscall+0x34 > Xint0x80_syscall() at 0xc0730ab1 = Xint0x80_syscall+0x21 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2817b82b, esp = > 0xbfbfe86c, ebp = 0xbfbfe8a8 --- > > Any suggestions about how to fix this? I can furnish more > information about my kernel config, etc., if necessary. Please try the attached patch. Jung-uk Kim --Boundary-00=_ZqoNNogI35BllUL Content-Type: text/plain; charset="iso-8859-1"; name="vm86bios.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm86bios.diff" Index: sys/i386/i386/vm86bios.s =================================================================== --- sys/i386/i386/vm86bios.s (revision 217516) +++ sys/i386/i386/vm86bios.s (working copy) @@ -73,8 +73,7 @@ ENTRY(vm86_bioscall) je 1f /* no curproc/npxproc */ pushl %edx movl TD_PCB(%ecx),%ecx - addl $PCB_SAVEFPU,%ecx - pushl %ecx + pushl PCB_SAVEFPU(%ecx) call npxsave popl %ecx popl %edx /* recover our pcb */ --Boundary-00=_ZqoNNogI35BllUL--