From: Jeff Garzik <jgarzik@pobox.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: Intel SATA combined mode quirk broken for SCSI_SATA=m
Date: Sun, 16 Oct 2005 22:33:11 -0400 [thread overview]
Message-ID: <43530D67.6020209@pobox.com> (raw)
In-Reply-To: <200510161913.59622.jbarnes@virtuousgeek.org>
Jesse Barnes wrote:
> Back in July, Adrian Bunk sent in a patch to make SCSI_SATA tristate. This
> prevents the intel_ide_combined quirk in drivers/pci/quirks.c from working if
> SCSI_SATA=m, which is the case for Fedora kernels (my motivation for tracking
> this down).
>
> In my configuration, not running the quirk causes the ata_piix driver (the
> libata driver for my IDE controller) to fail to attach to the device, since
> the legacy IDE driver has already claimed the ports. Unfortunately, the AHCI
> driver also tries to mess with the device, and ends up disabling its
> interrupts before aborting its load, causing the IDE layer to complain loudly
> that hda is losing interrupts.
Thanks a ton for figuring this out!
> So what should be done? Ideally, libata would fully support ATAPI and then I
> wouldn't need the legacy IDE drivers at all on this box, making the quirk
> moot, but that won't happen for 2.6.14, so we'll need something else.
> Unconditionally enabling the quirk will cause at least one of the ports to be
> reserved for the SATA driver, which may never load. And obviously not
> running the quirk leads to the situation described above.
>
> A hack that might be suitable for 2.6.14 is to make the quirk depend on either
> CONFIG_SCSI_SATA or CONFIG_SCSI_SATA_MODULE. Then the quirk could be removed
> entirely when ATAPI support for libata is merged.
Overall the quirk is a hack until ATAPI is supported -- but even after
ATAPI is supported, we need to figure out some way to keep IDE driver
from stealing the legacy IDE ports before libata can touch them :(
However, when ATAPI is supported, that at least means that both PATA and
SATA can run at full speed.
Your patch is correct, and should go into 2.6.14-rc post-haste.
I continue to grumble at the Kconfig annoyance: CONFIG_SCSI_SATA is
fundamentally a yes/no question. CONFIG_SCSI_SATA=m makes no sense at
all -- and causes problems, as we see -- but is required in order to do
Kconfig dependencies correctly AFAIK.
Maybe 'if SCSI_SATA' is needed instead? A lame way to implement
dependencies, but if there is no other way...
Jeff
next prev parent reply other threads:[~2005-10-17 2:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-17 2:13 Intel SATA combined mode quirk broken for SCSI_SATA=m Jesse Barnes
2005-10-17 2:33 ` Jeff Garzik [this message]
2005-10-17 2:48 ` Jesse Barnes
2005-10-17 2:45 ` [PATCH] " Jeff Garzik
2005-10-17 2:55 ` Jesse Barnes
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=43530D67.6020209@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@osdl.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.