suffering a bad case neglect for the last few years.
- Add full prototypes, including to function pointers.
- Make the wire protocols 64-bit type safe, eg: 32 bit quantities are
int32_t, not long. The orginal rpc code was implemented when an int
could be 16 bits.
Obtained from: a diff of FreeBSD vs. OpenBSD/NetBSD rpc code.
also implies VM_PROT_EXEC. We support it that way for now,
since the break system call by default gives VM_PROT_ALL. Now
we have a better chance of coalesing map entries when mixing
mmap/break type operations. This was contributing to excessive
numbers of map entries on the modula-3 runtime system. The
problem is still not "solved", but the situation makes more
sense.
Eventually, when we work on architectures where VM_PROT_READ
is orthogonal to VM_PROT_EXEC, we will have to visit this
issue carefully (esp. regarding security issues.)
maps. Additionally, eliminate the map->hint distortion
associated with useracc. That may/may-not be the "right"
thing to do -- but time will tell.
Submitted by: Partially by Alan Cox <alc@cs.rice.edu>
Firstly, now our read-ahead clustering is on a file descriptor basis and not
on a per-vnode basis. This will allow multiple processes reading the
same file to take advantage of read-ahead clustering. Secondly, there
previously was a problem with large reads still using the ramp-up
algorithm. Of course, that was bogus, and now we read the entire
"chunk" off of the disk in one operation. The read-ahead clustering
algorithm should use less CPU than the previous also (I hope :-)).
NOTE: THAT LKMS MUST BE REBUILT!!!
Firstly, now our read-ahead clustering is on a file descriptor basis and not
on a per-vnode basis. This will allow multiple processes reading the
same file to take advantage of read-ahead clustering. Secondly, there
previously was a problem with large reads still using the ramp-up
algorithm. Of course, that was bogus, and now we read the entire
"chunk" off of the disk in one operation. The read-ahead clustering
algorithm should use less CPU than the previous also (I hope :-)).
vm_map_simplify and vm_map_simplify_entry. Make vm_map_simplify_entry
handle wired maps so that we can get rid of vm_map_simplify. Modify
the callers of vm_map_simplify to properly use vm_map_simplify_entry.
Submitted by: Alan Cox <alc@cs.rice.edu>
has the negative effect of disabling some map optimizations. This
patch defers the creation of the object until it needs to be at fault time.
Submitted by: Alan Cox <alc@cs.rice.edu>
is still broken - it doesn't restore the floating point state.
2.2-BETA users should disable it using npx0 flags 0x04 the same as
2.2-ALPHA users should have.
successful write. Only do it for the IO_SYNC case (like ufs). On
one of my systems, this speeds up `iozone 24 512' from 32K/sec
(1/128 as fast as ufs) to 2.8MB/sec (7/10 as fast as ufs).
Obtained from: partly from NetBSD
the START UNIT command before testing whether the device is ready.
Maybe it should be done even earlier, i'm not 100 % sure.
Again, CD changers will most likely benefit from it.
While i was at it, also made the debugging case a little more verbose
about why the cdopen() yielded an ENXIO. (Only in effect when
SCSIDEBUG is specified.)
Should eventually also go into 2.2.
error code with ASC/ASCQ 4/1 (``Logical unit is in the process of
becoming ready'') non-fatal. Retry the operation until it will
eventually either yield a real error condition, or finally succeed.
Devices like CD changers or tape drives with a freshly inserted
cartridge should benefit from this.
Should go into 2.2 after some testing in -current. I'd like to see
this in the release if possible.
Closes PR # kern/1065.
While i was at it, also reject IO requests that are not an integer
multiple of the device blocksize.
Submitted by: vak@crox.net.kiae.su (Serge V.Vakulenko)
Confirmed by: Georg-W. Koltermann (gwk@cray.com)
workings of #error in particular. He also broke the 2.2 build with this
change, leading me to wonder whether or not the changes were ever even
tested. Folks, I'm happy to see people work directly on 2.2 like
this and will continue to encourage Nate to make direct commits, but
please TEST before committing! I think that's a more than reasonable
prerequisite, and this code could never have worked at all, leading me to
believe that Nate skipped this most basic of steps.
Don't allow people to use the 'dedicated' drivers at the same time as
the generic support code, as it can cause all sorts of problems
including kernel crashes.
[ definite 2.2 material ]
after the first found, if multiple LUNs are tried.
Change probe message to just the SCSI chip id,
similar to what the NCR driver prints.
Change the driver name to "amd" in all places.
Thanks to Nick Sayer <nsayer@quack.kfu.com> for
doing some debugging, for sending a boot message
log that shows the driver is functional, and for
pointing out there still were places that needed
the driver name to be corrected.
