1) Don't wait for DRQ on an IDENTIFY command -- if it's not set when we see
BSY clear, abort the command and ignore the drive. (Do this by testing
for DRQ in the read/write cases in __wdccommand_intr().)
2) Don't wait for DRQ to deassert when we finish an IDENTIFY (or any other
non-block command that reads data) -- we don't do this for block I/O, and
empirically it doesn't clear on my CF cards at all, causing a pointless 1s
delay.
3) Add comments to some of the delay()s, and add missing ones in wdcreset()
and the WDCC_RECAL in the so-called "pre-ATA" probe.
4) Slightly simplify the reset sequence -- we were doing an extra I/O.
5) Modify the register writability test to make sure that registers are not
overlapped -- this can happen in some weird cases with a missing device 1.
6) Check the error register value after the reset -- if it's not 01h or 81h,
as appropriate (see ATA spec), punt.
Tested with a number of ATA-only, ATAPI-only, mixed ATA-ATAPI, CF, and IDE
disk configurations.
Also remove the SINGLE_DRIVE nonsense again.
- Make AENs use the generic code table stuff.
- Add a few more AEN codes (from FreeBSD).
- Correct the context of a few AEN codes (some were listed as
"unit context" when they're really "port context").
- Add a queue of AENs that management tools in userspace can poll
(from FreeBSD).
* introduce fsetown(), fgetown(), fownsignal() - this sets/retrieves/signals
the owner of descriptor, according to appropriate sematics
of TIOCSPGRP/FIOSETOWN/SIOCSPGRP/TIOCGPGRP/FIOGETOWN/SIOCGPGRP ioctl; use
these routines instead of custom code where appropriate
* make every place handling TIOCSPGRP/TIOCGPGRP handle also FIOSETOWN/FIOGETOWN
properly, and remove the translation of FIO[SG]OWN to TIOC[SG]PGRP
in sys_ioctl() & sys_fcntl()
* also remove the socket-specific hack in sys_ioctl()/sys_fcntl() and
pass the ioctls down to soo_ioctl() as any other ioctl
change discussed on tech-kern@
of struct wsdisplay_softc. Unused entries are NULL, and there were
a lot of places where we did not checked that the caller did not
requested an operation on a NULL entry.
While we are there, one bit of KNFification, and make return code more
consistent by always returning the same code (EINVAL) when a screen
number higer than the maximum is requested.
of both devices are written, and device 0 will respond for device 1 if
device 1 isn't present. Pointed out by Quentin Garnier.
So the only way to know if device 1 is there or not is to send a command, which
is done later.
Detecting the second device here isn't important and won't speed up the probe.
We just need to know if there is at last one device on the bus.
Fix PR kern/22869 from Julio M. Merino Vidal.
call ata_raid_check_component() immediately, and panics since DMA setup
isn't done yet. So, defer the call until attach stage is almost done.
Tested with Promise TX2000.
most polling.
2) Clean up some goofiness in pciide -- get rid of the whole "candisable" path
(it's gratuitous) and simplify the code by calling pciide_map_compat_intr(),
*_set_modes() and wdc_print_modes() from central locations.
3) Add a register writability and register ghost test to eliminate phantom
drives more quickly.
another function, always doing a page 0 MODE SENSE to get the block
descriptor if we use READ CAPACITY, and use SMS_DBD on the page 4/5 MODE
SENSE. This does one extra command in some cases, but it separates and
simplifies the code a little.
Why do we prefer READ CAPACITY over READ FORMAT CAPACITIES? Two reasons:
1) It's much older and is much less likely to have had its command code
abused, and is thus "safer" to try first. 2) ALL of my USB flash readers
and pen drives screw up their capacity descriptors -- mostly off-by-one
errors in the size (they return the maximum LBA number instead, a la READ
CAPACITY, which has *never* been how READ FORMAT CAPACITIES was documented
in the MMC spec), and one returns the "no media" code on slots that have
media inserted (despite returning almost-correct data otherwise)!
F*** me with a chainsaw.
This wasn't an error, on this chipset we have the SATA controller on function
0 of the IDE controller, not the pcib bridge.
Fix provided by Stephen Degler.
