> Doscmd is really only useable with X, and running doscmd -bx with a local X
> server generates tons of "trap 25 with interrupts disabled". I don't recall
> this being the case many moons ago...
Yeah, me too. I was told this is a bug in doscmd and the owner needs
to fix it. I don't understand the inner parts of DOS VM86 as it
relates to the x86 architecture or I'd take a crack at it.
Instead, I hacked as follows to silence this specific error. This is
not a good thing to do in general, but it lets me use doscmd to program
EPROMs. I just use cvs instead of cvsup to update my working source
tree so I don't lose this (and other) local mods.
Don't know about the panic though - I haven't seen anything like it.
I've never used vn to access the floppy under DOS. Instead I just
point it to a 1.44Mb floppy image on the filesystem and a 10Mb
hard-drive image on the filesystem, and it works fine for me.
-- Parag Patel
===================================================================
# my ~/.doscmdrc
assign A: /u/parag/dos/1.44M 1440
assign B: /dev/rfd0 1440
assign C: /u/parag/dos/10M 306 4 17
assign D: /cgt/src/bin/of/ppc
assign E: /u/parag/tmp
#assign lpt1: direct /dev/lpt0
# map in the parallel port for the EMP-10
portmap 0x378 8
boot c:
===================================================================
Index: trap.c
===================================================================
RCS file: /src/freebsd/src/sys/i386/i386/trap.c,v
retrieving revision 1.133
diff -c -r1.133 trap.c
*** trap.c 1999/01/06 23:05:36 1.133
--- trap.c 1999/01/16 18:32:46
***************
*** 234,240 ****
printf(
"pid %ld (%s): trap %d with interrupts
disabled\n",
(long)curproc->p_pid, curproc->p_comm,
type);
! else if (type != T_BPTFLT && type != T_TRCTRAP)
/*
* XXX not quite right, since this may be for a
* multiple fault in user mode.
--- 234,240 ----
printf(
"pid %ld (%s): trap %d with interrupts
disabled\n",
(long)curproc->p_pid, curproc->p_comm,
type);
! else if (type != T_BPTFLT && type != T_TRCTRAP && type
!= T_TSSFLT)
/*
* XXX not quite right, since this may be for a
* multiple fault in user mode.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
