On 01/16/2013 05:10 AM, Sedat Dilek wrote:
On Sat, Jan 5, 2013 at 3:20 AM, Huang, Shane wrote:
OK, I see the patch I mentioned to fix the problem was later reverted [1].
The real fix is "libata: replace sata_settings with devslp_timing" [2].
Yes, please use [2] which can also be found in
On Sat, Jan 5, 2013 at 3:20 AM, Huang, Shane wrote:
>> OK, I see the patch I mentioned to fix the problem was later reverted [1].
>> The real fix is "libata: replace sata_settings with devslp_timing" [2].
>
> Yes, please use [2] which can also be found in kernel bugzilla #51881
> and is pending
On Sat, Jan 5, 2013 at 3:20 AM, Huang, Shane shane.hu...@amd.com wrote:
OK, I see the patch I mentioned to fix the problem was later reverted [1].
The real fix is libata: replace sata_settings with devslp_timing [2].
Yes, please use [2] which can also be found in kernel bugzilla #51881
and is
On 01/16/2013 05:10 AM, Sedat Dilek wrote:
On Sat, Jan 5, 2013 at 3:20 AM, Huang, Shane shane.hu...@amd.com wrote:
OK, I see the patch I mentioned to fix the problem was later reverted [1].
The real fix is libata: replace sata_settings with devslp_timing [2].
Yes, please use [2] which can
On Sat, Jan 5, 2013 at 3:20 AM, Huang, Shane wrote:
>> OK, I see the patch I mentioned to fix the problem was later reverted [1].
>> The real fix is "libata: replace sata_settings with devslp_timing" [2].
>
> Yes, please use [2] which can also be found in kernel bugzilla #51881
> and is pending
On Sat, Jan 5, 2013 at 3:20 AM, Huang, Shane shane.hu...@amd.com wrote:
OK, I see the patch I mentioned to fix the problem was later reverted [1].
The real fix is libata: replace sata_settings with devslp_timing [2].
Yes, please use [2] which can also be found in kernel bugzilla #51881
and is
> OK, I see the patch I mentioned to fix the problem was later reverted [1].
> The real fix is "libata: replace sata_settings with devslp_timing" [2].
Yes, please use [2] which can also be found in kernel bugzilla #51881
and is pending on Jeff's acceptance. Sorry for the trouble to you guys.
On Fri, Jan 4, 2013 at 4:59 PM, Sedat Dilek wrote:
> On Fri, Jan 4, 2013 at 4:40 PM, Sedat Dilek wrote:
>> Hi,
>>
>> I noticed messages like the following in my syslogs with Linux
>> v3.8-rc1 and v3.8-rc2:
>>
>> ata1.00: failed to get Identify Device Data, Emask 0x1
>>
>> In this Samsung
On Fri, Jan 4, 2013 at 4:40 PM, Sedat Dilek wrote:
> Hi,
>
> I noticed messages like the following in my syslogs with Linux
> v3.8-rc1 and v3.8-rc2:
>
> ata1.00: failed to get Identify Device Data, Emask 0x1
>
> In this Samsung ultrabook there exists a small SSD and a 500GiB HDD.
> I had no look
On Fri, Jan 4, 2013 at 4:40 PM, Sedat Dilek sedat.di...@gmail.com wrote:
Hi,
I noticed messages like the following in my syslogs with Linux
v3.8-rc1 and v3.8-rc2:
ata1.00: failed to get Identify Device Data, Emask 0x1
In this Samsung ultrabook there exists a small SSD and a 500GiB HDD.
I
On Fri, Jan 4, 2013 at 4:59 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Fri, Jan 4, 2013 at 4:40 PM, Sedat Dilek sedat.di...@gmail.com wrote:
Hi,
I noticed messages like the following in my syslogs with Linux
v3.8-rc1 and v3.8-rc2:
ata1.00: failed to get Identify Device Data, Emask 0x1
OK, I see the patch I mentioned to fix the problem was later reverted [1].
The real fix is libata: replace sata_settings with devslp_timing [2].
Yes, please use [2] which can also be found in kernel bugzilla #51881
and is pending on Jeff's acceptance. Sorry for the trouble to you guys.
Thanks,
12 matches
Mail list logo
