-----Original Message-----
From: Richard Smith
Sent: 29 December 2005 19:52
> And there was much rejoicing.
> Still un-answered is _what_ was trashing parts of the 0x0c0000 area.
> We have fixed the symptom but not the cause.
Just to add more meat to the knowledge about the Via vga bios, and about what 'might' be going on here:
We do know that the Via vga bios is not entirely 'self sufficient', and makes proprietory calls into the main BIOS through software interrupt 21
During Linuxbios boot and vga initialisation we cater for this by providing an interrupt 21 handler in the Linuxbios code
However I do believe that this bios also makes these int 21 calls during a mode set call, as I believe is done by the various fb drivers, and ceratinly by the Vesa X server. But of course once the kernel is booted the int 21 handler of Linuxbios will have vapourised, although the page 0 vectors to these functions still exist. Consequently any such call will end up wandering around random code, and it is highly probable that this is the cause of the corruption noted.
I have managed to trace the Vesa X server sufficiently to know that it crashes / locks up with its instruction pointer in the 0xf000 segment, where in theory there is no code under Linuxbios, but presumably there is with a stock bios.
Thus the epia M/MII/ML port is not currently VESA compatible - i.e. you can't do a bios call to set the current display mode.
That leaves us with native CLE266 chipset drivers. On my test bed I quite happily run X using the Via X driver for CLE266. I don't have a need for fbdev, and so can't vouch for that.
On my test bed I run either an old homebrew linux built using the Linux