Bug#222374: d-i melts screen on sis 630 laptop
Martin Michlmayr wrote:
* Thomas Winischhofer <thomas@winischhofer.net> [2003-12-29 23:16]:
Just looked at vesafb source again - it doesn't even have a
module_init() function. So it DOES NOT (and CANNOT) work as a module.
It's a Debian specific change, you'll have to look at the Debian
kernel sources.
Ah I see. Didn't think of this. (I don't use Debian kernels.)
[short break, downloading Debian kernel-source-2.4.23...]
Ok, let's see. Here's the diff between Debian's vesafb and the vanilla one:
--- /usr/src/linux/drivers/video/vesafb.c 2003-11-28
19:26:21.000000000 +0100
+++ kernel-source-2.4.23/drivers/video/vesafb.c 2003-11-29
10:53:45.000000000 +0100
@@ -696,6 +696,13 @@
return 0;
}
+static void __exit vesafb_exit(void)
+{
+ unregister_framebuffer(&fb_info);
+ iounmap(video_vbase);
+ release_mem_region(video_base, video_size);
+}
+
/*
* Overrides for Emacs so that we follow Linus's tabbing style.
*
---------------------------------------------------------------------------
@@ -705,3 +712,7 @@
*/
MODULE_LICENSE("GPL");
+#ifdef MODULE
+module_init(vesafb_init);
+#endif
+module_exit(vesafb_exit);
[end of diff output]
Apart from this and a small patch to Config.in there is (naturally, I
might dare add) nothing - not even a change in arch/i386/boot/video.S -
which could manage to overcome the problem that the kernel can't call
int10 functions as soon as the CPU is in protected mode.
vesafb_init(), which is being declared as the module entry point by that
Debian patch, starts with the following statement:
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -ENXIO;
The code for setting this flag this is in arch/i386/boot/video.S; to be
exact, it's the second instruction (movb $023,fs:PARAM_HAVE_VGA) in the
mopar_gr routine - which itself is only being called if "graphic_mode"
is non-zero, which will only be the case if an actual graphics (as
opposed by text) mode number is provided and the mode-switch succeeded
(see end of the check_vesa routine).
Hence, unless a video=x (x >= 0x200) parameter is given in the kernel
command line, the above quoted conditional will always run into "return
-ENXIO". And ENXIO is short for "no such device or address". Not
surprising.
So my statement still stands. Vesafb cannot (meaningfully) work as a
module (unless one gives a video=X [X>=0x200] argument in the kernel
command line and can live with a totally blank screen until vesafb is
modprobed).
What actually seems to happen is that the installer, after failure to
modprobe vesafb, modprobes vga16fb which does not depend on int10 calls
(but pokes into the crtc registers itself). This does and will cause
severe problems on many, not only SiS based laptops.
I hope that helps to finally solve this riddle.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
Reply to: