- handle devices which has no OBP node.
- move PCI latency-timer initialization from pci_intr_map to
pci_enumerate_bus.
- make PCI bus free space extents for cardbus devices.
- fix PCI config space map size.
- some code integrations.
by Andrey Petrov and Jason Thorpje (AFAIK).
This is a hack that covers some symptoms while we have no idea where
the real problem is. Anyway, since this avoids random data corruption
we better be safe and have this in-tree until the problem is solved the
right way.
This is derived from alpha/microtime.c and i386/tsc_microtime.c,
and will share with both ports.
This should fix PR port-sparc64/18452.
(approved by martin)
walking the page tables whenever this information is needed.
Add an option PMAP_COUNT_DEBUG to assert the new counts and the
page table walk agree.
The old solution had very bad performance impact, for example
by the high CPU load when running top(1).
Thanks to Simon Burge for pointing at the cause of the problem and
to Valeriy E. Ushakov for optimizing my simple minded assembler code.
port: T_IDIV0 is the hardware trap generated on integer division by
zero, T_DIV0 is the software trap used to signal the same event.
This makes 32 bit kernels able to run sparc code with the v7 multiply/
divide library, as well as with the v8 one.
port: T_IDIV0 is the hardware trap generated on integer division by
zero, T_DIV0 is the software trap used to signal the same event.
This makes 32 bit kernels able to run sparc code with the v7 multiply/
divide library.
Spotted by Valeriy E. Ushakov.
- in tlb_flush_all(), don't skip TLB entries with the high bit on,
I was confused about which MMU register it was using. it's also fine
to use the last hardware context.
- in pmap_create(), don't allocate a hardware context for the new pmap.
it's unnecessary, and when this would cause us to recycle all the contexts,
it would result in the current process's context being set to 0
(ie. the kernel's context). the current process could then return to
userspace without going through the context-switch code (and thus without
having a hardware context reallocated). this would lead to user mappings
being entered in the kernel's context later, causing all sorts of trouble.
add some assertions to catch this kind of thing.
