required (rounded up a little) instead of twice the previous amount (or
a fixed amount for the first allocation).
The bug caused memory corruption when a new unit number for a devclass
was more than about twice the previous maximum one (or more than 3 for
the first one), so it corrupted memory (which happened to be the atkbdc
port resource list) in the reporter's configuration with sio unit
numbers { 0, 25, 1, 2, ... }.
Reviewed by: dfr
Reported by: Leonid Lukiyanets <stalwar78@hotmail.com>
2. Newbusify the driver.
3. Build as a module.
4. Use correct minor numbers when creating device files.
5. Correctly lock control characters.
6. Return ENXIO when device not configured.
Submitted by: Tor Egge <Tor.Egge@fast.no>
7. Fix the baud_table.
Submitted by: Elliot Dierksen <ebd@oau.org>
Note:
- the old driver still lives in src/sys/i386/isa, so that you can
revert to it if something goes wrong.
- The module does not detach very well. Attaching works fine.
config(8). This commit allows control of the creation of the
#include "foo.h" files. We now only create them explicitly when needed.
BTW; these are mostly bad because they usually imply static limits on
numbers of units for devices. eg: struct mysoftc sc[NFOO];
These static limits have Got To Go.
map physical addresses below 0x2000 (accoding to AMI). If we
allocate our s/g tables and get an address below this point, leak the
memory and try again.
This should fix booting from these controllers.
Get ray_detach working correctly. This is a very simple routine as it
just wakes up sleeping processes. Note that anything woken has NO softc
structure available! runq_add is suitably modified to detect a detach and
return straight away.
Due to ray_detach and its implications use a macro for adding things
to the runq in user land.
handling for this case (which was slightly broken anyway)
Fix up some whitespace problems while I'm here too.
Submitted by: alfred (in a slightly different form)
tested on Intel BX chipsets only. The other agp minidrivers are totally
untested.
The programming api is a subset of the Linux api and is only intended to
be enough for the X server to use. There is also an in-kernel api for the
use of other kernel modules such as the 3D DRI.
