From: Antonino Daplas <redacted>
Date: Sun, Apr 13, 2003 at 04:14:08AM -0400

I believe I've seen that "oops" tracing before.  It is due to console 
blanking routines calling a lot of functions (fb_blank, fb_setcolreg, 
etc), all of which are done when "sleeping" is not allowed.  
However, /dev/vm86 will always sleep, and this causes the oops.

Calling fb_blank via an ioctl is pretty safe though (ie, when xfree86 
uses fb_blank ioctls for XFree86 DPMS).

I worked around this by doing deferred execution of fb_blank (also 
using a workqueue), and differentiating if fb_blank() was called from 
fbcon_blank() or from fb_ioctl().  I think I've also included these 
fixes in vm86d-0.1.tar.gz (md5sum 10fa0ad4647ea6a8a002998196ce6cd9)

I don't think it's in that patch.

Anyway, as a quick workaround, you can make vbe_blank() in vbe.c 
return 0 always.  This will not blank the screen, but it will at 
least prevent the oops.

Anyway, here is your patch, split in a vm86-patch and an edid-patch, and
all other changes removed. In this form, there patches apply against
2.5.67, against 2.5.67-ac1 and against 2.5.67-bk5.

They also work (tested with 2.5.67).

Kind regards,
Jurriaan

-- 
However, the things that surprise Emacs users are very different from
the things that surprise users of lesser operating systems.
	Per Abrahamsen in news.software.readers
Debian (Unstable) GNU/Linux 2.5.67 3940 bogomips 5 users load av: 0.15 0.14 0.07