Re: lockup with vidcontrol VESA_800x600

On Tuesday 18 January 2011 10:08 pm, b. f. wrote:
> Marc UBM Bocklet <ubm.freebsd at googlemail.com> 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