in a different fashion. Individually, they have the same functionality,
but their layout is different. An example of such a chipset is
the Promise 203xx.
To be able to deal with this, transform the cmd and dma bus_space handles
into an array of handles, each seperately created with bus_space_subregion.
The code generated by using the extra indirection shouldn't change much,
since the extra indirection is negated by having the offset calculation
already done in bus_space_subregion. E.g.
bus_space_write_4(tag, handle, offset, value)
becomes
bus_space_write_4(tag, handles[offset], 0, value)
Reviewed by Manuel Bouyer. Tested on wdc_isa, wdc_pcmcia, viaide, piixide (i386)
and on cmdide (sparc64).
interrupt while SRST is asserted. Work around by blocking interrupts while
SRST is asserted, and clearing any pending interrupt before unblocking.
Fix kern/23529 from Michael Hertrick.
Otherwise we would bump queue_freeze several times, but the kernel thread would
decrease it only one time.
Fix PR kern/23377 by Mattias Karlsson, and should also fix similar problem
reported by Mihai CHELARU and Bruce J.A. Nourish on current-users.
in case the previous loop scheduled some more work to do (e.g. reset)
- use queue_freese to block the queue when a reset is pending too
- Avoid using WDCF_TH_RUN in some place that can be called from callout.
If the kernel thread is tsleep()ing somewhere, we may come here with
WDCF_TH_RUN set while being in the callout context. Fix a panic() in
tsleep() reported by Chuck Silvers.
- Use AT_WAIT instead of WDCF_TH_RUN wdcwait(), as we may not be in the
channel's thread context but still be able to tsleep(). Fix queue_freese
panics for WDC_CAPABILITY_NOIRQ controllers (port-mac68k/23208 by
Frederick Bruck).
device; some ATAPI devices as master will report 0x7f in all registers
for slave before reset
- For the same reason, remove the er1 check.
Makes slave device with a "strange" ATAPI master probe again.
Problem reported and fix tested by Gary Duzan on current-users.
http://mail-index.netbsd.org/tech-kern/2003/09/25/0006.html
This adds a device (atabus) between IDE controllers and wd or atapibus, to
have each ATA channel show up in the device tree. Later there will be atabus
devices in /dev, so that we can do IOCTL on them.
Each atabus has its own kernel thread, to handle operations that needs polling,
e.g. reset and others.
Device probing on each bus it defered to the atabus thread creation.
This allows to do the reset and basic device probes in parallel, which reduce
boot time on systems with several pciide controllers.
When probing a nonexistent slave, we may timeout waiting for an interrupt.
In __wdccommand_start(), for polled data in commands, abort quickly if
status still read 0 after 400ns (for a nonexistant slave, the
command will either be aborted, or the status register will report 0; for
a real device we should have BSY, DRQ or ERR).
Thanks to Alexander Yurchenko for reporting the problem and testing the
fix.
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.
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.
Such RAID controllers are actually just IDE controllers with a BIOS that
can create RAID volumes and write the configuration info to config blocks
on the disks. The BIOS can do I/O to these volumes, and the OS must
understand the config blocks and implement RAID in software in order to be
able to use these volumes.
Only SPAN (simple concatenation) and RAID0 are supported at this time,
and writing back config blocks is also not supported at this time. Currently,
only the Promise configuration scheme is supported, although supporting
the Highpoint scheme should not be too difficult.
In any case, this is sufficient to use the Promise RAID0 volume (thus
preserving the win2k AS installation) on this new Intel server I have.
Thanks to Soren Schmidt for doing the work in FreeBSD; it made this
task much easier. The config block parsing code is adapted from his
work.
the data transfer. This is mandatory for data out commands (although none are
used for now), and not forbiddend for data in commands. Also record if we
did transfers any data.
May solve kern/16159 by making the probe more robust in face of fake identify.
possible pending interrupt. This should avoid the interrupt loop described
in PR kern/15841.
It is safe to read status here, because if we're not waiting for an interrupt
we have no command pending, so the device should be idle.
thorpej