- use vmspace rather than proc or lwp where appropriate.
the latter is more natural to specify an address space.
(and less likely to be abused for random purposes.)
- fix a swdmover race.
a u_int64_t variable). Fixes 1 to 2 TB disks in qemu. Tested with
1200GB and to a lesser extent 2047GB sparse files. For reference
an empty FFS1 filesystem on a 1200GB sparse file uses 19GB of disk.
- rather than embedding bufq_state in driver softc,
have a pointer to the former.
- move bufq related functions from kern/subr_disk.c to kern/subr_bufq.c.
- rename method to strategy for consistency.
- move some definitions which don't need to be exposed to the rest of kernel
from sys/bufq.h to sys/bufq_impl.h.
(is it better to move it to kern/ or somewhere?)
- fix some obvious breakage in dev/qbus/ts.c. (not tested)
and in a better way than what is done in wddump() (which also does it
for DMA transfers, limiting the dump speed significantly). So remove
code splitting transfers in wd->sc_multi chunks from wddump(), and call
wd->atabus->ata_bio() with the whole transfers.
Problem reported by Frank Kardel, and patch tested by him.
standard scheme:
if (<configured> != <wildcard> && <configured> != <real>)
then fail
else
ask device match function
This is handled by config_stdsubmatch() now.
explicitely by a plain integer array
the length in now known to all relevant parties, so this avoids
duplication of information, and we can allocate that thing in
drivers without hacks
Change a boundary check to ensure that we won't accidentally read and use
uninitialized memory if ATA_RAID_TYPE_MAX is updated without updating the
array.
Update comment near ATA_RAID_TYPE_MAX to note that the array in ata_raid.c
should be updated if a new ATA_RAID_TYPE_* is added.
returns EINVAL, indicating that DMA cannot be done for this transfer.
Fall back to PIO in this case.
- Add a geodeide_dma_init() routine that checks to make sure that transfers
start on a 16 byte boundary, returning EINVAL if not. Works around a chip
bug that causes a hard system hang.
Problem reported and patch tested by Erik Fair.
system hangs whenever a read or write request to sector 0xfffffff occurs.
The hang appears to happen when:
status = bus_space_read_1(wdr->cmd_iot, wdr->cmd_iohs[wd_status], 0);
is executed in __wdcwait(), and it is not possible to enter the debugger or
make the system respond at all after this point.
Whilst not necessarily the most prudent solution to handling the large number
of drives that exhibit this problem, it is currently the popular workaround.
[An alternative approach is to just always drop to LBA48 if the request
happens to pass by sector 0xfffffff and the drive reported as larger than
0xfffffff sectors. My understanding is that the 32 bit addressing below
0x10000000 is purely there as a performance booster, not to resolve a
compatibility issue.]
controller is idle.
Change the powerhook function to call ata_queue_idle() on standby/suspend,
and ata_reset_channel() on resume (to wake up the disks and start from a
clean state).
Fix PR kern/30194 by Lubomir Sedlacik.
WDCC_FLUSHCACHE command. So for drive < ATA4, test WDC_CMD2_FC in atap_cmd_set2
before returning ENODEV.
Problem reported and fix tested by Michael Gerhards on port-sparc64.
context. For this introduce 3 new xfer tags:
- C_WAIT, equivalent of AT_WAIT
- C_WAITACT, when there is a thread waiting on this xfer to become the active
one (that is, to be at the head of the queue)
- C_FREE, set by ata_free_xfer() when it can't free the xfer because it's
still in use. The holder should then free the xfer ASAP.
If ata_exec_xfer() is called with (C_POLL | C_WAIT), and there is already
xfers to be processed, assert C_WAITACT and sleep.
atastart() checks for C_WAITACT, and wakeup the thread waiting for this xfer
to become active if set. atastart() won't process this xfer, it's the
responsability of the thread waked up to handle it.
Fix (the right way) kern/27421 by Martin Husemann.
necessary information to create the pseudo-device instance. Pseudo-device
device's will reference this cfdata, just as normal devices reference
their corresponding cfdata.
Welcome to 2.99.10.
