Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Jan 2011 03:08:58 +0000
From:      "b. f." <bf1783@googlemail.com>
To:        freebsd-current@FreeBSD.org
Cc:        jkim@FreeBSD.org
Subject:   Re: lockup with vidcontrol VESA_800x600
Message-ID:  <AANLkTikXNDeByH9k5NzqDjsV_Mg_Zg6HBWnhrJF%2BK8CC@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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.

Regards,
               b.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikXNDeByH9k5NzqDjsV_Mg_Zg6HBWnhrJF%2BK8CC>