Re: lk 4.20.0 sd: 'Unaligned partial completion (resid=3584, sector_sz=4096)' forever

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019-01-16 11:55 a.m., Douglas Gilbert wrote:
On 2019-01-16 11:44 a.m., Martin K. Petersen wrote:

Doug,

If these types of disks (ones that can fast format between 512 and
4096 bytes) are not out in the field yet, they soon will be. This
problem requires a hard reboot (i.e. hold you finger on the power
button for 5-10 seconds). Sad ....

Do we get a notification from the drive that inquiry data has changed
once the format is complete?

I need to reconfigure my box to use FreeBSD with those disks. Then I
should be able to answer that question.


BTW I'm told by the manufacturer of said disk, that the last firmware
update was to production firmware.

No sign of a Unit Attention on FreeBSD (12.0 Release) from either a
512->4096 or 4096->512 fast format. And fdisk (which is different on
FreeBSD) worked when the block size was 512 byte but said it could
find the block size when disk's LB size was 4096.

sbc4r16 chapter 4.10:
"Any time the READ CAPACITY (10) parameter data (see 5.19.2) or the
READ CAPACITY (16) parameter data (see 5.20.2) changes (e.g., when a
FORMAT UNIT command or a MODE SELECT command causes a change to the
logical block length or protection information, or when a vendor specific mechanism causes a change), then the device server shall establish a
unit attention condition for the SCSI initiator port (see SAM-5)
associated with each I_T nexus, except the I_T nexus on which the command causing the change was received with the additional sense code set to
CAPACITY DATA HAS CHANGED."

So seeing I'm using the I_T nexus that sent the FORMAT UNIT, then no Unit
Attention is expected, as per above.

So onto INQUIRY VPD pages: what has changed that will cause a UA?

And surely the sd driver or mid-level should "smell a rat" after the first:
   Unaligned partial completion
error message. The disk was unmounted so it should not be a big deal to
run initialisation again on it. If it was mounted then that would be an
interesting situation, since the user visible data (say just changed to
4096 byte LBs) would be the concatenation of 8 of the previous 512 byte
LBs. However there is nothing in SBC-4 that says that will be the case,
and I was told by the firmware people, just assume that was an "accident".
PI might even survive across LB size changes.

Doug Gilbert






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux