linux-kernel - Re: sata_nv times out for BD-ROM iHOS104-08

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]

Message-ID: <4B5A70E5.6050106@kernel.org>
Date:	Sat, 23 Jan 2010 12:45:41 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Cengiz Günay <cgunay@...ry.edu>
CC:	Robert Hancock <hancockrwd@...il.com>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: sata_nv times out for BD-ROM iHOS104-08

Hello,

On 01/22/2010 11:11 PM, Cengiz Günay wrote:
> On Tue, Jan 19, 2010 at 9:59 PM, Robert Hancock <hancockrwd@...il.com> wrote:
>>>> 2009/12/24 Tejun Heo <tj@...nel.org>:
>>> Hmm.... it worked?  Does kernel parameter sata_nv.adma_enabled=0 make
>>> any difference?  Can you please attach boot log with the kernel
>>> parameter specified?
>>
>> Think you meant maybe sata_nv.swncq=0 instead - this is an MCP51
>> controller so it doesn't support ADMA. I don't imagine SWNCQ would
>> make any difference with an ATAPI device, but wouldn't hurt to try.
> 
> Thanks for following this up. I tried both of your suggested kernel
> parameters (attached). Neither solved my problem, but also it looks
> like I couldn't turn off the SWNCQ mode. Even though I set it to zero,
> sata_nv still shows that it uses it. Although the order of my devices
> changed, so I assume it did something.

The parameter isn't being passed to the module loaded by initrd.  You
probably need to edit modules.conf and then regenerate initrd.  :-(

> I hope this helps shed some light! I will also try the kernel patch --
> not sure if that is suited for the problem I'm having?

Yeah, I was about to suggest trying the patch.  It could be that the
timeout used by the new TUR code is too aggressive.

Thanks.

-- 
tejun
--
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/