David Xu wrote: > > testl $PSL_VM,TF_EFLAGS(%esp) /* are we in vm86 mode? */ > > jz doreti_notvm86 > > cmpl $1,in_vm86call /* are we in a vm86 call? */ > > sorry for a bit OT, does anyone see this in_vm86call crazy global variable? > it prevents two CPUs to trap into VM86 model :( > if you have interest in fixing this problem, please have a look at PR :
This is on purpose. Most BIOS implementations are non-reentrant, and if you allocate resources in the bus space to BIOS based I/O, you end up contending for it without locks. This is "crossing the beams" bad... 8-). > http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223 > > I have also fixed the problem that VM86 call is preempted by interrupt > threads and causes system crash. newest patch can always be gotten from : > http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz I saw the fix. I like it, though it doesn't fix the handling using an interrupt gate to take interrupts in VM86() mode (the FreeBSD code doesn't do this at present, but it's a problem if you run under VMWare, I think). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message