This patch fixes or helps to avoid several ATA subsystem problems, namely:
system crash after RAID hard disk failures or after disk removal
for hot-swappable disks;
deadlock during RAID label access or update;
systems failing to come up after reboot every 8-10 reboots;
system crashes doing atacontrol attach or detach commands;
In addition, this patch includes a write support for LSIv3 RAID.
This is the hardware that is used by a current Intel Server Board (SE7520JR2).
And it introduces a scheme for defining array-specific write label functions
that divides functionality into two pieces, one to fill data in memory,
and the other to write label. If adopted, these scheme may enable
to use the same labelling routines with GEOM modules.
Fix: Some problems can be traced to missing synchronisation. Locking was added.
In other cases ATA request weren't tracked correctly, and the system tried to
access device structures after they were freed. We added reference counters
to requests, to be used in suspicious circumstances.
The larger problem is architectural: RAID label read and write are synchronous,
and stop any I/O completion on a channel until label requests are completed.
As a result, software interrupt servicing channel completion may have
several completion tasks waiting to be executed. Now, if one of the requests
on a channel I/O queue before the label is a RAID composite request
that depends on a read operation on a different channel to complete
before it can continue, we are in a deadlock.
The patch makes label updates asynchronous, and that takes care of the most situations. The price is a changed semantics for label write, - it now reports
success after starting an operation. I think it's acceptable,
because a failure of the forthcoming wirte will cause an array reconfiguration
and a visible message to user.
However, the problem is in a read label case. Not willing to introduce
massive architectural changes, I left it synchronous. So the deadlock
described above may still happen if somebody uses atacontrol
at an unhappy moment.
Also, see above a comment regarding LSIv3 label support and a proposed
label code structuring.
How-To-Repeat: reboot the system with RAID array multiple times.
or simulate disk failure (e.g., remove disk or detach disk) during normal disk operation or array rebuild.
or run rebuild cycle several times.
Assign to sos@, aka Mr. ATA =)
sos@ is not actively working on ATA-related PRs.
To submitter: is this still an issue?
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped