- 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.