linux-kernel - Re: 2.6.32 seemed to have broken nVidia MCP7A sata controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 Dec 2009 12:35:31 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Mike Cui <cuicui@...il.com>, linux-ide@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.32 seemed to have broken nVidia MCP7A sata controller

On 12/19/2009 01:29 AM, Jeff Garzik wrote:
> On 12/19/2009 01:13 AM, Mike Cui wrote:
>> I have an nVidia MCP7A AHCI controller. I upgraded to 2.6.32.2 and my
>> system deterministically freezes trying to mount file systems. Once in
>> a while it will come back and finish booting after freezing for 1
>> minute or 2. dmesg indicates that there were NCQ errors, but 2.6.31
>> anb before has always worked flawlessly for me. What changed in
>> 2.6.32? I will be more than happy to help track down this issue.
>
>> ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
>> ata1.00: cmd 61/08:00:4f:ad:03/00:00:00:00:00/40 tag 0 ncq 4096 out
>> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>> ata1: hard resetting link
>> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> ata1.00: configured for UDMA/133
>> ata1.00: device reported invalid CHS sector 0
>
> Looks like things are timing out, and then go downhill from there. This
> explanation of timeout gives some hints on possible causes:
> http://ata.wiki.kernel.org/index.php/Libata_error_messages#Error_classes
>
> The ideal would be if you could bisect between 2.6.31 and 2.6.32, to see
> if it's a software change that is the cause.
>
> Looking at drivers/ata/ahci.c history, the only thing that -might- cause
> problems is 388539f3ff0cf1de926b03f94e1eec112358f74d ('git show $commit'
> for full commit info and diff).

I suspect that as well (it's the commit that adds FPDMA auto-activate on 
DMA setup FIS support). Your drive indicates it's supported but it's 
possible it's broken on that drive or the controller. If the drive 
doesn't set the activate bit in the DMA setup FIS properly or the 
controller doesn't respect it, then FPDMA requests will stall.

Mike, can you try and revert that patch, or else just change this line 
in drivers/ata/ahci.c:

		pi.flags |= ATA_FLAG_NCQ | ATA_FLAG_FPDMA_AA;

to

		pi.flags |= ATA_FLAG_NCQ;

and rebuild and see if it works better?

I tend to suspect the controller is the problem (I've got WD drives that 
work fine with AA on Intel AHCI, though it could be model-specific). I 
guess the only way to verify for sure which one it is would be if 
someone else had that particular drive model on a different AHCI 
controller and could verify if it worked with 2.6.32+ or not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/