On 08/22/2015 07:37 AM, Anatol Pomozov wrote:
> Hi
>
> I recently got 2 Seagate 8Tb drives. 'dd' over whole disc ran fine.
> Then I inserted into my RAID and started rebalancing. I've got
> following error almost immediately:
>
>
>
> ata5.00: failed command: WRITE FPDMA QUEUED
> ata5.00: cmd 61/00:e0:80:e7:75/1d:00:9f:00:00/40 tag 28 ncq 3801088 out
> res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata5.00: status: { DRDY }
> ata5.00: failed command: WRITE FPDMA QUEUED
> ata5.00: cmd 61/80:e8:80:04:76/1d:00:9f:00:00/40 tag 29 ncq 3866624 out
> res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata5.00: status: { DRDY }
> ata5: hard resetting link
> ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
> ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
> ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY)
> filtered out
> ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
> ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
> ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY)
> filtered out
> ata5.00: configured for UDMA/133
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
> ata5.00: device reported invalid CHS sector 0
>
>
>
> Discs are from different batches and I was a bit surprised to see
> identical failures at the same time. I was ready send the drives to
> RMA but then I discovered this thread
> https://bbs.archlinux.org/viewtopic.php?id=199351 A lot of people
> report the same problem as mine. It was found that the problem appears
> only starting from 3.19, with kernel 3.18 or Windows these drives work
> fine. It is recommended to revert this change
> 9162c6579bf90b3f5ddb7e3a6c6fa946c1b4cbeb "libata: Implement
> ATA_DEV_ZAC" that seems fixes the issue.
>
Please clarify: Have you _checked_ that it fixes this issue?
The above patch just adds a new ATA device type, and the necessary
changes to have it detected correctly.
I find it extremely unlikely it being the culprit here.
> There is also the same issue reported at kernel.org
> https://bugzilla.kernel.org/show_bug.cgi?id=93581
>
>
> This issue is extremely annoying and makes negative SMR drives user
> experience. Had anybody look at this bug?
>
Did you attempt a bisect to find out the offending patch?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
