we can see if it's a small distance beyond the end, or way out. This may
give some clues as to whether it is being caused by something coalescing
the transfers in spite of the bounce buffers, or simply because of buffer
corruption. (The BT driver seems to occasionally get hit by from this too,
except that it does not trap the transfer, and the system panics later
with vm_bounce_page_free.) This "event" usually happens to me during a
savecore (on the rare occasion that a kernel coredump is actually taken
after a crash - the lack of kernel core dumps is another problem...).
bzero.
Deprecated blkclr (removed it).
Removed some old cruft from cpufunc.h.
The optimized bzero was submitted by Torbjorn Granlund <tege@matematik.su.se>
The kernel adaption and other changes by me.
bzero.
Deprecated blkclr (removed it).
Removed some old cruft from cpufunc.h.
The optimized bzero was submitted by Torbjorn Granlund <tege@matematik.su.se>
The kernel adaption and other changes by me.
bcopy:
Be smarter about handling overlapped copies and only go backwards if it
is really necessary. Going backwards on a P6 is much slower than forwards
and it's a little slower on a P5. Also moved the count mask and 'std'
down a few lines - it's a couple percent faster this way on a P5.
libkern.a are now specified by listing their source files in
files.${MACHINE}. The list is machine-dependent to save space.
All the necessary object for each machine must be linked into the
kernel in case an lkm wants one.
feature of the ICU. auto-EOI on the slave is not safe, however, so it
remains an option. Killed religious FASTER_NOP when writing the ICU.
Reviewed by: bde
or deleted.
Motivated by: `int doclusteread = 1;' in ext2_vnops.c redefined
doclusterread if DEBUG is defined, so it could not have worked.
This was fixed by staticizing things before it caused problems.
I didn't find any more cases like this.
wasteful, but better than clobbering the variables below the stack.
About 300 bytes of variables were clobbered when I examined double
faults using ddb. Perhaps a page that is known not to be accessed by
the double fault handler could be used. Such pages are not easy to
find, since the double fault handler calls panic() which calls sync()
and possibly dumpsys().
part of the DMA channel 0 address and wasn't random in the intended
way.
Submitted by: KATO Takenori <kato@eclogite.eps.nagoya-u.ac.jp>
Disable interrupts while reading the clock. This probably isn't
important (allowing interrupts probably increased randomness in
the usual case).
Removed __i386__ ifdef. This file is in an i386 directory and has
other i386 dependencies.
unintentionally committed):
- the fifo was completely disabled for low speeds. Apart from being
unnecessarily inefficient, this invalidated com->tx_fifo_size.
- `ftl' became a bogus name.
- the 16650 probe breaks the COM_NOFIFO() case and has other bugs
(disabled, not fixed).
Fixed bogus change of the fifo settings for the non-speed of 0. This
bug made the above fifo bug occur even at non-low speeds.
Fixed the modes of the cua devices. It isn't possible to set the uid
and gid correctly since the kernel can't know who uucp.dialer is.
Register the devswitch at device attach time. SYSINIT() is not
the right way to initialize devswitches (if anything :->).
Eventually, the devswitch should be deregistered at device detach
and/or unload time and reregistered at device attach time ... Then
some com->gone tests could be removed.
Cleaned up some other recent changes.
redistribute a few last routines to beter places and shoot the file
I haven't act actually 'deleted' the file yet togive people time
to
have done a config.. I.e. they are likely to have done one in a week or so
so I'll remove it then..
it's now empty.
makes the question of a USL copyright rather moot.
about decoding trap/syscall/interrupt frames and generally works better
than the previous stuff.
Removed some special (incorrect) frobbing of the frame pointer that
was messing some things up with the new traceback code.
overflows.
It sure would be nice if there was an unmapped page between the PCB and
the stack (and that the size of the stack was configurable!). With the
way things are now, the PCB will get clobbered before the double fault
handler gets control, making somewhat of a mess of things. Despite this,
it is still fairly easy to poke around in the overflowed stack to figure
out the cause.
Unstaticize a function in scsi/scsi_base that was used, with an undocumented
option.
My last count on the LINT kernel shows:
Total symbols: 3647
unref symbols: 463
undef symbols: 4
1 ref symbols: 1751
2 ref symbols: 485
Approaching the pain threshold now.
