Re: matroxfb, 2.6 and 2.4
Jonas Meurer <[email protected]>
| Newsgroups | gmane.linux.fbdev.user |
|---|---|
| Message-ID | <[email protected]> |
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 ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com