- make elf_load_file() and elf_load_psection() static
- make loops consistent
- 'nload' is not used - see rev1.24
- 'ap' is not used in elf_load_file()
ok agc@ christos@
helper functions in arch/x86/x86/fpu.c
They (hopefully) ensure that we write to the entire buffer and don't load
values that might cause faults in kernel.
Also zero out the 'pad' field of the i386 mcontext fp area that I think
once contained the registers of any Weitek fpu.
Dunno why it wasn't pasrt of the union.
Some of these copies could be removed if the code directly copied the save
area to/from userspace addresses.
The cost of zeroing the save area on exec is minimal.
This stops the FP registers of a random process being used the first
time an lwp uses the fpu.
sendsig_siginfo() and get_mcontext() now unconditionally copy the FP
registers.
I'll remove the double-copy for signal handlers soon.
get_mcontext() might have been leaking kernel memory to userspace - and
may still do so if i386_use_fxsave is false (short copies).
This changes the trap10 and trap13 code to call directly into fpu.c,
removing all the code for T_ARITHTRAP, T_XMM and T_FPUNDA from i386/trap.c
Not all of the code thate appeared to handle fpu traps was ever called!
Most of the changes just replace the include of machine/npx.h with x86/fpu.h
(or remove it entirely).
instead of pulling the kernel definition of the fpu (etc) into
userspace programs.
I've included machine/fenv.h into x86/cpu.c to ensure the duplicated
definitions stay in step.
The default control words are now the hardware defaults.
XXX: Anyone care to explain the differences between the i386 and amd64
versions of this file?
Add arch/generic and move non-x86 files from rumpkern/ there. Also,
move files from arch/i386 to arch/x86, and make both i386 and x86_64
use those.
This clarifies the situation with what is MD vs. MI code.
renames:
rumpcpu_generic,kobj_stubs,pmap_stubs => arch/generic/rump_generic_$x
arch/i386/* => arch/x86/rump_x86_$x
(for those who forget, x86 requires MD code because rump kernels
use the same ABI as kernel modules)
Move the checks for fpu traps in kernel into x86/fpu.c.
Remove the code from amd64/trap.c related to fpu traps (they've not gone
there for ages - expect to panic in kernel mode).
In fpudna():
- Don't actually enable hardware interrupts unless we need to
allow in IPIs.
- There is no point in enabling them when they are blocked in software
(by splhigh()).
- Keep the splhigh() to avoid a load of the KASSERTS() firing.
X680x0 SCSI IOCS stalls if SCSI device doesn't return inquiry data
of specified allocation length size on the INQUIRY command,
and it causes hangup on the XM6 based emulators that return only
upto 36 byte inquiry data on SCSI disk emulation.
Many real SCSI-2 hard drives seem to support >100 byte inquiry data,
but at least there is a harddisk that returns only supported inquiry
data size and quits transfer.
The bootloader checks only the device type and there is no reason
to read 100 bytes that includes vender specific data.
Analyzed and reported by GIMONS, a developer of XM6 TypeG emulator,
which also can run NetBSD/x68k.
floating point error when raising a signal.
Multiple errors bits can easily be set if different sub-fields of an
xmm simd operation generate different errors.
Replace the hand generated 28 lines that initialised fpetable[]
with some pre-processor expressions.
The latter was verified to give the same table entries.
There is no need to save the fpu state here, and definitely no need
to initialise the fpu.
The code is running with interrupts disabled having trapped on either
an x87 instruction (the one after the one that generated the error)
or on an SSE (etc) instruction that caused the error.
So all it needs to do it obtain the 'error' bits from the relevant
status register, clear the bits, and then raise any signal.
The signal code will save the fp state if the signal itself isn't masked.
It also passes the FP state to the signal handler - which can modify it.
(I suspect that wasn't thecase when this code was written.)
Seems to work for both 64bit and 32bit 'divide by zero' errors.
For the xmm trap, the xmm registers are updated for the result of the
instruction, but the trap returns to re-execute the instruction!
This makes it difficult for the signal handler to do anything sensible.
I've also changed the code to only use unmasked error bits when deciding
the signal code.
into the hashlist and discards the now unneeded node it will raise a
panic "dead but not clean".
Reorder the initialization and use ungetnewvnode() to discard the node.
sysctl_copyin fails, 'tmp' is not initialized. This bug is
harmless since only the return value will be different;
it does not expose kernel memory unless diagnostic is enabled.
ok agc@ martin@
inside the ucontext structure passed to signal handlers to modify the
xmm registers.
This should make the code compile - I'm not at all sure it works as expected,
the interactions between FP and signal handlers aren't at all clear.
AFAICT the FP state is saved on the user stack when the handler is called,
however the FP trap code can already done odd things to the FPU....
definitions match those of i386.
Mostly just structure and field renames, in addition:
1) process_xmm_to_s87() and process_s87_to_xmm() moved into
x86/convert_xmm_s87.c so they can be used by amd64's netbsd32 code.
2) The linux signal code simplified to use a structure copy for ths fxsave
data - it matches the hardware definition and won't change.
The relevant bit is always masked out higher up.
The only place I can find a reference to a 'datachain' error is for the
weitek 1167 fpu. Even the 8087 has the corresponding bit of the x87
status reserved.
Quite why it has appeared here is anybodies guess.
This underscores the need to replace this error-prone cpp API by
unconditionally defined {pre,post}atomic_membar_*.
This change should only remove unnecessary membar_producers on x86.
-mno-mmx -mno-sse -mno-avx -mno-80387 -mno-fp-ret-in-387
Since no-sse implies no-sse2 that should ensure that the compiler really
doesn't emit any instructions that might trap trying to use the FPU.
On amd64 at least some of those are needed to stop the compiler
saving the registers to stack on every varargs function.
It might be that -mno-sse did that before.
hardware ones, and those in the mcontext, ptrace and core files we
can really safely cast and copy between the types.
Remove a couple of temporary buffers and add CTASSERT()s that the sizes
do actually match.
to save the control word and tag word on fp faults.
Nothing I could find looked at them before I removed the code that wrote them.
It might appear that these fields got exported to userspace (via mcontext),
but that code carefully avoided those fields.
I've also deleted some very historic fields from the union inside __fpregset_t
this doesn't affect its size.
The __fpregset_t fields are now the same size as the ones in the pcb.
Which is good because they get cast to each other in a few places.
Rename the associated ci_fpsaving field to 'unused'.
I'm not sure they could ever happen, you could get unwanted calls into
the fpu trap code while saving state when using INT13 - but these are
different.
The return value from the i386 fpudna() was always 1 - possibly a historic
relic of the kernel fp emulation. Remove and don't check in trap.S.
The amd64 and i386 fpudna() code is now almost identical.
npxintr() is only generated when a process executes an FP instruction
and the TS set interrupt takes precedence - so we know the current lwp
owns the fp registers.
It is also then impossible to get a splurious error while saving
the registers.
Ths lets the npxintr() code be simplified somewhat.
XXX: I'm not at all sure it really DTRT if the process actually wished
to fixup anything in the signal handler (or even if the signal is masked).
be mapped by XKPHYS/KSEGn, then the load will succeed. If it would
require a bounce buffer or being mapped into the kernel's address space,
the load will fail.
returns other than 0, the TX ring might not full. Check whether
the TX ring has one or more packets. If the ring is empty,
dont' set IFF_OACTIVE because an TX complete interrupt never
occur and IFF_OACTIVE flags is left. The interface's timer
isn't reset, so a device timeout desn't occur.
Fixes a bug that IFF_OACTIVE flag is left on heavy load.
Part of PR#48568.
Set default CR) so that the FPU is enabled (unset CR0_EM) and initialise
i386_fpu_present to 1.
No need to call the npx trap indirectly, rename to fpunda() to match amd64.
Remove the i386_fpu_exception variable and sysctl (It used to indicate
which irq was used for fpu exceptions, but we only support 'internal'
now). Hopefully no one cares.
fpuinit() now only needs to clear TS before the fninit(). Apart from the
checks for 486SX and the 'fdiv bug' this matches the amd64 version.
Exclude fpuinit() from XEN kernels, they don't call it - which rather begs
the question as to whether it is needed at all!
- register softc of child devices as an argument of the sio interrupt
handler to avoid device_lookup_private() calls on every interrupt
- change type of sc_reg from (void *) to (struct sioreg *)
to avoid weird address offset calculations with redundant casts
- rename struct sio_softc members for consistency
- use a channel number passed via sio_attach_args in lunaws_attach()
No functional chnages. Tested on LUNA.
the file action list) by limiting the maximum number of file actions to
twice the current file descriptor limit.
Fix a few bugs in the support functions and document the new limit.
From Maxime Villard.
Stop a stream of
npxintr: came from nowherenpxintr: l = 0xc17ba560, curproc = 0xc177d880, fpu_present = 0
when running some ATF tests:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/i386/201401300920Z_anita.txt
XXX this is probably still broken for native i386, at last for older CPUs.
It looks like on newer CPUs (such as the one emulated by qemu) this code path
is not used.
Even if mode is not used, the call to pci_mode_detect() is mandatory to
initialize the PCI subsystem.
Fix "panic booting -current DOM0" reported by Patrick Welche on port-xen.
