On Sun, 18 Mar 2001, David Malone wrote:

> Presumably what is happening is i586_bzero begins and finds that
> PCPU(NPXPROC) is not zero, so it decides to preserve the fpu
> registers. Then something interrupts it, but doesn't restore
> PCPU(NPXPROC). When i586_bzero returns it uses the first 8 bytes
> of the fpu registers for its intstruction pointer and stack pointer
> and goes boom.

i586_bzero is missing the hack of disabling interrupts to prevent
problems with npxproc getting switched, and it uses its own funky
locking which hasn't been regraded for SMPng, so it is quite likely
to be buggy.

K6-2's aren't really i586's and i586_bzero should never be used for
them (generic bzero is faster), but there is apparently another
bug that may cause them to be used.  From des's dmesg output:

> i586_bzero() bandwidth = -1980152482 bytes/sec
> bzero() bandwidth = 129299198 bytes/sec

i586_bzero gets used because negative bandwidths are significantly
smaller than positive ones, so plain bzero is faster according to this
message, but whatever the overflow apparently causes other bad things.
npx.c already has one "fix" for the overflow problem.  The problem
is may be that clocks don't work early any more.

Similarly for the i586-optimized bcopy and copyin/out (the bandwidth
test for bzero controls them all).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to