- Free resources in all the possible attachment failure cases.
One critical bugfix:
- Fix a race where it was possible to get out of synch with the log
messages from the controller, if the controller hung up for any
period of time (eg. while resetting a SCSI bus). This would result
in an endless string of console errors, bringing the machine to a
halt.
Exceptions:
Vinum untouched. This means that it cannot be compiled.
Greg Lehey is on the case.
CCD not converted yet, casts to struct buf (still safe)
atapi-cd casts to struct buf to examine B_PHYS
- implement user-initiated background drive rebuild
- implement user-initiated background consistency check
- log controller-initiated background rebuild/check operations
Try to fix the elusive "invalid log operation" bug, and panic if we do
hit this one in the hopes of getting better information.
Tidy up diagnostic messages.
Try to use disk_create/disk_destroy correctly. This isn't working
properly yet, but it's not clear whose fault that is.
(Much of this done by script)
Move B_ORDERED flag to b_ioflags and call it BIO_ORDERED.
Move b_pblkno and b_iodone_chain to struct bio while we transition, they
will be obsoleted once bio structs chain/stack.
Add bio_queue field for struct bio aware disksort.
Address a lot of stylistic issues brought up by bde.
field in struct buf: b_iocmd. The b_iocmd is enforced to have
exactly one bit set.
B_WRITE was bogusly defined as zero giving rise to obvious coding
mistakes.
Also eliminate the redundant struct buf flag B_CALL, it can just
as efficiently be done by comparing b_iodone to NULL.
Should you get a panic or drop into the debugger, complaining about
"b_iocmd", don't continue. It is likely to write on your disk
where it should have been reading.
This change is a step in the direction towards a stackable BIO capability.
A lot of this patch were machine generated (Thanks to style(9) compliance!)
Vinum users: Greg has not had time to test this yet, be careful.
this version include:
- Support for version 2.x firmware (2.42 or later recommended). This
means we are the only open-source driver supporting these adapters.
This code has only been tested on a Digital KZPCA adapter in an Alpha
system, but is believed to be correct. NOTE: EISA adapters are not
yet supported.
- Support the BIOS/Firmware initialisation handshake protocol. This
allows the driver to bring the card up to operational state even if
the BIOS can't be run (eg. if it's an x86 BIOS in an Alpha system).
- A working command pasthrough interface. This allows a user-space
configuration tool (under development) to issue arbitrary commands
to the controller or to devices in the system.
- Don't keep private copies of some of the data fields from the
ENQUIRY and ENQUIRY2 commands. Instead, standardise on the ENQUIRY2
command for initial adapter information, and keep a copy of the entire
structure. Refer to it where appropriate.
- Move all of the controller description functionality into a new
function. Print lots more controller data if bootverbose is set.
Add knowledge of the DAC960 PR, PT, PTL0 and PRL controllers, rename
the 960PTL -> PTL0 and 1100P -> 1100PVX.
- Correctly terminate an error message.
The controller interface procedures have been reviewed against the
Mylex-supplied documentation; no changes appear necessary at this
time.
and fixing some major bugs.
- Add support for the v5 firmware interface, used by the DAC1164P
(tested) and AcceleRAID 352 (untested but should work). We now cover
all of the Mylex family's protocols except for v2 (used by EISA and
Alpha-compatible cards).
- Fix an accounting bug which resulted in endless 'poll still busy'
messages. In situations of high controller load the count of poll
commands could be incremented without actually successfully launching
a command. This totally removes the accounting for status poll
commnads; it was its own worst enemy.
- Add some simple reentry prevention locks to processing of the waiting
and completed command queues to prevent races which could result in
I/O being done or completed twice (both are fatal). This highlights
a need for simple locking primitives in both the UP and SMP kernels.
- Streamline the handling of command completion to reduce the amount of
redundant work being done. Remove the code which tests for commands
that have gone missing in action; nobody has ever seen one of these
and it wouldn't have worked properly anyhow.
- Handle disconnection of drives from the controller in the detach,
not shutdown method. This avoids problems flushing the cache in
a panic when a drive is mounted.
- Don't call bus_generic_detach when disconnecting drives; it doesn't
actually do anything useful.
- Increment the log message index regardless of whether we actually
retrieved one or not. If we run into a message that we can't fetch,
we don't want to spin endlessly complaining about the fact.
- Don't assume that interrupts will work when we're flushing the
controller. We may think they are enabled, but in eg. a panic
situation the controller may not be able to deliver an interrupt.
The same goes for CD drivers and tape drivers. In systems with mixed IDE
and SCSI, devices in the same priority class will be sorted in attach
order.
Also, the 'CCD' priority is now the 'ARRAY' priority, and a number of
drivers have been modified to use that priority.
This includes the necessary changes to all drivers, except the ATA drivers.
Soren will modify those separately.
This does not include and does not require any change in the devstat
version number, since no known userland applications use the priority
enumerations.
Reviewed by: msmith, sos, phk, jlemon, mjacob, bde
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
Shift to using the same queueing strategy that the amr driver uses.
Some simple tests indicate that we use about 2% of the CPU at around
500tps with the controller completely saturated with I/O.
32 bytes is safe.
Handle successful completion of message log retrieval commands.
With these changes, the driver correctly handles the consequences of drive
death and replacement in a reliable array. Note that the massive backlog
of I/O during handling of such an event can kill the system if softupdates
is enabled.
PJ cards. This will probably also support the AcceleRAID and
eXtremeRAID cards, but nobody has volunteered one for testing, so I
haven't enabled their PCI device IDs.
Slightly clean up communication between the disk devices and the
controller device as per new practice, and move some more register-
related items int mlxreg.h from mlxvar.h.
Remove some unnecessary read-modify-write operations to the card
control registers; they don't behave like that.
Increase the status polling interval to 10 seconds. It's still possible
to load the card up to the point where a status poll will find the
previous poll still running, but this will reduce the incidence of
complaints.
