I have two patches:
the first patch is to keep vm86lock as a sleep lock, and allow the
thread calling vm86 bios could be preempted, but still only one
thread can call vm86 bios. so if we want a sleep mutex in trap() code
execute path, it hasn't problem.
the second patch try to keep source code modification minimal,
change vm86lock to spin lock, don't allow to be preempted when calling
vm86 bios, but if someday someone wants a sleep mutex in trap() code
execute path, it would have trouble.
you can select one of them to apply. I am not maintainer of VM86 code,
so I have trouble to commit this patch unless someone allow me to do.
On Sunday 22 September 2002 06:09, Gavin Atkinson wrote:
> On Fri, 26 Jul 2002, David Xu wrote:
> > Yes, this is a known problem. I have a patch for this, you may
> > download it from here:
> > http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz
> Is there any chance of geting these committed? With them, my laptop is
> happy to give a 100x37 screen on VESA_800x600.
> > ----- Original Message -----
> > From: "Rob" <[EMAIL PROTECTED]>
> > To: "Current" <[EMAIL PROTECTED]>
> > Sent: Saturday, July 27, 2002 6:46 AM
> > > Having a laptop here, I wanted to get the same 800x600 console that I
> > > have in -stable. I built my kernel with OPTIONS VESA and OPTIONS
> > > SC_PIXEL_MODE. I have tried two methods. The first was to put 0x0080
> > > in the device.hints file for SC. That gave me a blank screen upon
> > > startup. I also tried putting into /usr/local/etc/rc.d the vidcontrol
> > > command "vidcontrol -g 100x37 VESA_800x600. That gave me a blank
> > > screen at the end of the bootup. Is this functionality broken in
> > > -current, or am I doing something wrong?
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message