Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 May 1996 01:15:01 -0700 (PDT)
From:      asami@cs.berkeley.edu (Satoshi Asami)
To:        bde@zeta.org.au
Cc:        bde@zeta.org.au, current@FreeBSD.ORG, nisha@cs.berkeley.edu
Subject:   Re: some more on fast bcopy
Message-ID:  <199605110815.BAA19373@silvia.HIP.Berkeley.EDU>
In-Reply-To: <199605110425.OAA11493@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 11 May 1996 14:25:50 %2B1000)

next in thread | previous in thread | raw e-mail | index | archive | help
 * Oops.  npxdna() is only relevant for user mode.  You must be getting a
 * trap of type T_DNA (device not available) in system mode.  This can't
 * happen :-).  `clts' make the coprocessor device available and nothing
 * should change the TS bit.

But it's happening. :>

Is the following possible?  Say, process A is in the kernel for the
copyin, and then process B (or rather a device associated to it)
interrupts it, and it also invokes copyin.  Someone else interrupts B,
and then when that someone else is done, we go back to A.  Now A's
copyin is done, and %cr0 is set back to the original value, whose TS
bit says the coprocessor is not available.  So we get a panic when B
returns.

(I'm quite possibly way off, I know zilch about kernel scheduling.)
If this scenario is possible, then it explains the file corruption too
(note A will be using B's register contents when it returns).

By the way, according to the trace:

===
(kgdb) bt
#0  0xf01b3bf3 in boot ()
#1  0xf01183a6 in panic ()
#2  0xf01bbd66 in trap_fatal ()
#3  0xf01bb5ea in trap ()
#4  0xf01b1491 in calltrap ()
#5  0xf019b7e8 in ffs_write ()
#6  0xf0134c1f in vn_write ()
#7  0xf0119bc6 in write ()
#8  0xf01bc005 in syscall ()
#9  0xf01b14e5 in Xsyscall ()
#10 0x2289 in ?? ()
#11 0x1de7 in ?? ()
#12 0x1095 in ?? ()
===

I don't see any copyin()/copyout() or fastmove() there, is this
natural?  Or does this mean we screwed up the %cr0 for someone else?
(Although what ffs_write() has to do with the floating-point unit
unless it's calling our FP copy, I have no idea.)

Satoshi



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