From owner-freebsd-emulation Mon Jan 19 17:20:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12689 for freebsd-emulation-outgoing; Mon, 19 Jan 1998 17:20:40 -0800 (PST) (envelope-from owner-freebsd-emulation@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA12684 for ; Mon, 19 Jan 1998 17:20:37 -0800 (PST) (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 19 Jan 1998 20:19:17 -0500 (EST) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA00619; Mon, 19 Jan 98 20:19:15 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id UAA00057; Mon, 19 Jan 1998 20:17:59 -0500 Message-Id: <19980119201759.61620@ct.picker.com> Date: Mon, 19 Jan 1998 20:17:59 -0500 From: Randall Hopper To: Jonathan Lemon Cc: emulation@FreeBSD.ORG Subject: Re: DOSCMD: Problems w/ Quicken References: <19980119022348.44312@hydrogen.nike.efn.org> <199801191136.WAA00350@word.smith.net.au> <19980119103920.28769@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19980119103920.28769@right.PCS>; from Jonathan Lemon on Mon, Jan 19, 1998 at 10:39:20AM -0600 Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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