From: Tejun Heo <htejun@gmail.com>
To: "Gaston, Jason D" <jason.d.gaston@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-ide@vger.kernel.org
Subject: Re: ATAPI devices in AHCI mode not working
Date: Wed, 31 Oct 2007 17:07:16 +0900 [thread overview]
Message-ID: <472837B4.3000109@gmail.com> (raw)
In-Reply-To: <39B20DF628532344BC7A2692CB6AEE0701EA70F4@orsmsx420.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
Gaston, Jason D wrote:
>> -----Original Message-----
>> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
>> Sent: Monday, October 29, 2007 3:14 PM
>> To: Gaston, Jason D
>> Cc: linux-ide@vger.kernel.org
>> Subject: Re: ATAPI devices in AHCI mode not working
>>
>>> ata1: SATA max UDMA/133 abar m1024@0xd9101000 port 0xd9101100 irq 216
>>> ata2: SATA max UDMA/133 abar m1024@0xd9101000 port 0xd9101180 irq 216
>>> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> ata1.00: ATAPI: ATAPI DVD D DH16D2S, EP52, max UDMA/100
>>> ata1.00: configured for UDMA/100
>> Much better - no misdetected link type, no device claiming to be PATA
>> when its SATA.
>>
>>
>> Right that eliminates all the obvious goings on being caused by broken
>> devices which is a start. Doesn't shed any light on the rest of it.
> What
>> happens if you boot with irqpoll enabled ? (wondering if the timeouts
> are
>> ACPI or IRQ routing stuff)
>
> I rebuilt the kernel; the DVD and USB devices are functional now. I'm
> not sure what the problem was before. On a side note: In 2.6.24.rc1 the
> DVD starts working right away, but on a SLES10_SP1 kernel, it takes some
> time for it to step down to a PIO mode before the DVD can be mounted.
> Oh well.
Yeah, there has been quite some update in libata between SLES10_SP1 and
2.6.24-rc1. The controller being ahci, I wonder whether this is caused
by the different in check_atapi_dma().
1. Does other optical drives have the same problem? If not, please post
the result of "hdparm -I /dev/sr0" with the problematic one attached.
2. If you apply the attached patch to 2.6.24-rc1, does it behave the
same as the SLES10SP1 kernel?
--
tejun
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 529 bytes --]
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8ee56e5..5d9b193 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4491,11 +4491,13 @@ int ata_check_atapi_dma(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
+#if 0
/* Don't allow DMA if it isn't multiple of 16 bytes. Quite a
* few ATAPI devices choke on such DMA requests.
*/
if (unlikely(qc->nbytes & 15))
return 1;
+#endif
if (ap->ops->check_atapi_dma)
return ap->ops->check_atapi_dma(qc);
next prev parent reply other threads:[~2007-10-31 8:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 18:14 ATAPI devices in AHCI mode not working Gaston, Jason D
2007-10-29 20:30 ` Alan Cox
2007-10-29 21:08 ` Gaston, Jason D
2007-10-29 22:13 ` Alan Cox
2007-10-29 23:40 ` Gaston, Jason D
2007-10-31 8:07 ` Tejun Heo [this message]
2007-10-31 17:40 ` Gaston, Jason D
2007-10-31 23:42 ` Gaston, Jason D
2007-11-01 0:48 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=472837B4.3000109@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jason.d.gaston@intel.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).