Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jan 1998 20:17:59 -0500
From:      Randall Hopper <rhh@ct.picker.com>
To:        Jonathan Lemon <jlemon@americantv.com>
Cc:        emulation@FreeBSD.ORG
Subject:   Re: DOSCMD: Problems w/ Quicken
Message-ID:  <19980119201759.61620@ct.picker.com>
In-Reply-To: <19980119103920.28769@right.PCS>; from Jonathan Lemon on Mon, Jan 19, 1998 at 10:39:20AM -0600
References:  <19980119022348.44312@hydrogen.nike.efn.org> <199801191136.WAA00350@word.smith.net.au> <19980119103920.28769@right.PCS>

next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon:
 |>From one of the original postings, the setup message for doscmd says
 |`Init: 0', which indicates that the hardware does not support VME.

Hmm.  Well, in the boot-up probes, it says my CPU does support VME:

CPU: Pentium (233.22-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping=3
  Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>

However, looking at the sysarch() kernel path briefly, it appears that the
0 after Init: is just the return code of sysarch() and vm86_sysarch(),
which for the latter, just implies that the copyin()'s and
i386_extend_pcb() didn't fail.

 |When an int13 (gpf) is generated, under VME, it simply looks at the
 |interrupt vector, and jumps directly to the associated interrupt handler,
 |without leaving vm86 mode.  Without VME, it falls back to doscmd, with
 |a SIGBUS.
 |
 |doscmd looks at the instruction to try to figure out why the interrupt 
 |was generated (sti, cli, popf, etc) and if it doesn't find it, assumes 
 |that this is an illegal instruction.  It doesn't attempt to jump to the
 |int 13 vector.  It does this since SIGBUS is overloaded with all sorts 
 |of things and typically a GPF is fatal anyway.
 |
 |The following (untested) patch to doscmd might fix the problem.
 |--
 |+ #if 0
 |            dump_regs(REGS);
 |            fatal("unsupported instruction\n");
 |+ #endif
 |+           fake_int(REGS, 13);

I just tried this, but when the exception happened, I got an unending
stream of:

IRQ5 with no handler!
IRQ5 with no handler!

in the parent terminal.  I don't know if this is a result or just the next
snag after the current one.

Randall




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980119201759.61620>