Re: [Linux-fbdev-users] matroxfb, 2.6 and 2.4

[Jonas M. <jo...@fr...>]

On 03/08/2004 Petr Vandrovec wrote:
> ksymoops do not work on 2.6.x kernel. When you build 2.6.x kernel, you
> have option (Kernel hacking -> Compile the kernel with debug info) to
> store all symbols into kernel image, and then 2.6.x kernel will translate
> oops from numbers to symbols for you, without any need for help from
> ksymoops (and in this case your klogd should be started with option
> '-x' or '-2').

ok, i've done so, but now i'm running with mga compiled as module, and
automaticly mounted. first boot with this new kernel did work well ...

> Do you run 32bit or 64bit kernel? Strange thing is that while you
> are in the X matroxfb is completely off. Did you tried booting
> with 'video=matroxfb:disabled' to find whether it does not crash
> without matroxfb too? Or try 'video=matroxfb:init' so matroxfb
> initializes your video hardware from scratch, without relying on
> BIOS doing its job correctly. Or try vesafb instead (if x86-64 supports
> it).

i'm running debian i386 port with 32bit kernel. i'll try with
video=matroxfb:disabled and :init, and report.

> Does it power off your box immediately, or after you hold it down for
> 4 seconds? 

no, it shutdowns the system, like a 'shutdown -h now' or 'halt' would
do. that's the function of the ACPI button module.

> Can you recheck that you have 'Option "UseFBDev" "true"' and 
> 'Option "HWcursor" "off"' in the XFree config?

both weren't in the config, but also aren't documented in XF86Config-4(5x)
anyway i've added them to "Device" section, and xfree86 still runs ok.

we'll see if it helps.

> First three are fixed in my matroxfb patches (which you can use with
> other drivers too - I use it with radeon on my notebook and with
> vesafb on Parhelia on my other system). But as yesterday even full
> removal of VT from kernel was proposed on LKML, chance to get these
> changes in is pretty low.

VT is virtual terminal? so how else will it be handled in future? is
there a superior system?

> And for DRI I do not understand X code well enough to find where
> tests which should prevent X from hitting hardware should be added.

mh, no idea how to say more.

bye
 jonas