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).
Jeff
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.
Thanks, changing that one line fixed it. I can try to find an intel
motherboard sometime next week to see if it's the drive or the
controller.
On Sat, Dec 19, 2009 at 10:35 AM, Robert Hancock <[email protected]> wrote:
> 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.
>
On 12/19/2009 05:37 PM, Mike Cui wrote:
> Thanks, changing that one line fixed it. I can try to find an intel
> motherboard sometime next week to see if it's the drive or the
> controller.
>
> On Sat, Dec 19, 2009 at 10:35 AM, Robert Hancock<[email protected]> wrote:
>> 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?
Thanks for that confirmation. And yeah, it would definitely help if we
can narrow that down to either the drive or the controller.
Jeff
On Sat, Dec 19, 2009 at 4:37 PM, Mike Cui <[email protected]> wrote:
> Thanks, changing that one line fixed it. I can try to find an intel
> motherboard sometime next week to see if it's the drive or the
> controller.
Hi Mike, did you ever get a chance to try this test?
>
> On Sat, Dec 19, 2009 at 10:35 AM, Robert Hancock <[email protected]> wrote:
>> 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.
>>
>
I finally got a chance to try this on an x58 motherboard. It works
fine. It looks like the nvidia controller is the problem. Or maybe
it's just my motherboard.
Thanks.
On Sun, Dec 27, 2009 at 1:52 PM, Robert Hancock <[email protected]> wrote:
> On Sat, Dec 19, 2009 at 4:37 PM, Mike Cui <[email protected]> wrote:
>> Thanks, changing that one line fixed it. I can try to find an intel
>> motherboard sometime next week to see if it's the drive or the
>> controller.
>
> Hi Mike, did you ever get a chance to try this test?
>
>>
>> On Sat, Dec 19, 2009 at 10:35 AM, Robert Hancock <[email protected]> wrote:
>>> 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.
>>>
>>
>
On Thu, Jan 21, 2010 at 5:48 PM, Mike Cui <[email protected]> wrote:
> I finally got a chance to try this on an x58 motherboard. It works
> fine. It looks like the nvidia controller is the problem. Or maybe
> it's just my motherboard.
I'll try and cook up a patch to disable AA on this chipset. Can you
post the output of "lspci -nn" ?
>
> Thanks.
>
> On Sun, Dec 27, 2009 at 1:52 PM, Robert Hancock <[email protected]> wrote:
>> On Sat, Dec 19, 2009 at 4:37 PM, Mike Cui <[email protected]> wrote:
>>> Thanks, changing that one line fixed it. I can try to find an intel
>>> motherboard sometime next week to see if it's the drive or the
>>> controller.
>>
>> Hi Mike, did you ever get a chance to try this test?
>>
>>>
>>> On Sat, Dec 19, 2009 at 10:35 AM, Robert Hancock <[email protected]> wrote:
>>>> 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.
>>>>
>>>
>>
>
00:00.0 Host bridge [0600]: nVidia Corporation MCP79 Host Bridge
[10de:0a80] (rev b1)
00:00.1 RAM memory [0500]: nVidia Corporation MCP79 Memory Controller
[10de:0a88] (rev b1)
00:03.0 ISA bridge [0601]: nVidia Corporation MCP79 LPC Bridge
[10de:0aac] (rev b2)
00:03.1 RAM memory [0500]: nVidia Corporation MCP79 Memory Controller
[10de:0aa4] (rev b1)
00:03.2 SMBus [0c05]: nVidia Corporation MCP79 SMBus [10de:0aa2] (rev b1)
00:03.3 RAM memory [0500]: nVidia Corporation MCP79 Memory Controller
[10de:0a89] (rev b1)
00:03.4 RAM memory [0500]: nVidia Corporation Device [10de:0a98] (rev b1)
00:03.5 Co-processor [0b40]: nVidia Corporation MCP79 Co-processor
[10de:0aa3] (rev b1)
00:04.0 USB Controller [0c03]: nVidia Corporation MCP79 OHCI USB 1.1
Controller [10de:0aa5] (rev b1)
00:04.1 USB Controller [0c03]: nVidia Corporation MCP79 EHCI USB 2.0
Controller [10de:0aa6] (rev b1)
00:06.0 USB Controller [0c03]: nVidia Corporation MCP79 OHCI USB 1.1
Controller [10de:0aa7] (rev b1)
00:06.1 USB Controller [0c03]: nVidia Corporation MCP79 EHCI USB 2.0
Controller [10de:0aa9] (rev b1)
00:08.0 Audio device [0403]: nVidia Corporation MCP79 High Definition
Audio [10de:0ac0] (rev b1)
00:09.0 PCI bridge [0604]: nVidia Corporation MCP79 PCI Bridge
[10de:0aab] (rev b1)
00:0a.0 Ethernet controller [0200]: nVidia Corporation MCP79 Ethernet
[10de:0ab0] (rev b1)
00:0b.0 SATA controller [0106]: nVidia Corporation MCP79 AHCI
Controller [10de:0ab8] (rev b1)
00:0c.0 PCI bridge [0604]: nVidia Corporation MCP79 PCI Express Bridge
[10de:0ac4] (rev b1)
00:10.0 PCI bridge [0604]: nVidia Corporation MCP79 PCI Express Bridge
[10de:0aa0] (rev b1)
00:15.0 PCI bridge [0604]: nVidia Corporation MCP79 PCI Express Bridge
[10de:0ac6] (rev b1)
03:00.0 VGA compatible controller [0300]: nVidia Corporation C79
[GeForce 9300 / nForce 730i] [10de:086c] (rev b1)
Thanks!
On Thu, Jan 21, 2010 at 4:36 PM, Robert Hancock <[email protected]> wrote:
> On Thu, Jan 21, 2010 at 5:48 PM, Mike Cui <[email protected]> wrote:
>> I finally got a chance to try this on an x58 motherboard. It works
>> fine. It looks like the nvidia controller is the problem. Or maybe
>> it's just my motherboard.
>
> I'll try and cook up a patch to disable AA on this chipset. Can you
> post the output of "lspci -nn" ?
>
>>
>> Thanks.
>>
>> On Sun, Dec 27, 2009 at 1:52 PM, Robert Hancock <[email protected]> wrote:
>>> On Sat, Dec 19, 2009 at 4:37 PM, Mike Cui <[email protected]> wrote:
>>>> Thanks, changing that one line fixed it. I can try to find an intel
>>>> motherboard sometime next week to see if it's the drive or the
>>>> controller.
>>>
>>> Hi Mike, did you ever get a chance to try this test?
>>>
>>>>
>>>> On Sat, Dec 19, 2009 at 10:35 AM, Robert Hancock <[email protected]> wrote:
>>>>> 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.
>>>>>
>>>>
>>>
>>
>