On Wed, 25 Jul 2007, Julien Cristau wrote:
On Fri, May 4, 2007 at 19:27:03 +0100, Robert de Bath wrote:
Well, looks like I was wrong, the current unstable (1:7.2-3) locks up
with 100% cpu. The process can be kill -9'd and the attached log is what
remains. In addition after resetting the console I can see the messages:
" f000:5054: 01 ILLEGAL EXTENDED X86 OPCODE!
" XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
" after 0 requests (0 known processed) with 0 events remaining.
This is either a bug in the x86 emulator included in the X server, or a
bug in your vbios. In either case, it'd probably work if you didn't use
the vesa driver. Is there any particular reason you use it instead of
an appropriate driver for your video card?
To some extent you're right, the kernel frame buffer works, the svgalib
driver (chipset VESA) works and debian stable xserver-xorg-video-vesa
driver works. The current card specific driver also works (and it uses
vesa) but bugs 402673 and 407620 make it a pain to use, especially as
402673 understates the problem somewhat. All those except the older
xserver work in linear mode.
One thing I've noticed in the log is this:
...
*Mode: 118 (1024x768)
ModeAttributes: 0x9b
WinAAttributes: 0x7
WinBAttributes: 0x0
WinGranularity: 64
...
DirectColorModeInfo: 0
PhysBasePtr: 0x0
Mode: 117 (1024x768)
...
What does the X server do when that PhysBasePtr is zero ? Why is it zero
and not 0xf0000000 ? Google seems to say that you need to ask for the
linear mode to get the specs for it but the int(10,4f01) table looks like
it doesn't need to change. The kernel seems to do it that way, it looks
like X asks for the specs to paged mode, but it's very confused, does it?
This is what vesafb says ...
vesafb: framebuffer at 0xf0000000, mapped to 0xe0880000, using 6144k, total
32768k
vesafb: mode is 1024x768x32, linelength=4096, pages=9
vesafb: protected mode interface info at c000:85ba
vesafb: pmi: set display start = c00c85e9, set palette = c00c8652
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0
fb0: VESA VGA frame buffer device
I am reminded about how these BIOSs have probably been tested, and with
which (single) driver, that driver just tries the mode and if the user
doesn't respond in a few seconds switches back to one that was working.
So shouldn't the vesa driver use the same sequence of calls it does, with
the mode sniffing of course but also an "I don't care what you smell,
just jump" option too.
So how easy would a 'paranoid but under orders mode' be :-)
Anyway in the short term that machine is back on stable using the slow
X vesa driver and "mplayer -vo svga" for fullscreen video.
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.debath.co.uk/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
