From: Tejun Heo <htejun@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: jeff@garzik.org, linux-ide@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
Date: Wed, 21 May 2008 13:23:26 +0900 [thread overview]
Message-ID: <4833A3BE.2070107@gmail.com> (raw)
In-Reply-To: <20080520145031.13437.90254.stgit@core>
Alan Cox wrote:
> This fixes most common oops #5 on Arjan's kerneloops.org site
>
> Not all controllers have ctl/altstatus. In particular many ISAPnP controllers
> omit them. While libata should handle this it generally only got the ctl port
> (the write side) correct.
>
> Functions
> - ata_sff_maybe_altstatus - this uses the status if altstatus is not available.
> In the longer term I believe each use of it is in fact removable but don't
> want to perturb anything during the -rc releases
> - ata_sff_pause - don't use altstatus I/O for fencing if we don't have one
> - ata_sff_sync - add a fencing call so we can distinguish fencing from real
> altstatus usage. All non ctl/altstatus controllers are PIO
> so do not need a fence
>
> Code wise we then use maybe_altstatus in the IRQ path (where we should only
> check status and the current code is actually I think buggy), and for DMA
> completion (no non ctl/altstatus controller does DMA but need to finish
> verifying the calling cases).
>
> This has been tested with ctl/altstatus faked to be unavailable on controllers
> I have and works. You get some spew about failed identify but that is another
> issue that can be fixed later and it does all work. Also the spew only occurs
> on controllers that currently just go wrong.
>
> Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Tejun Heo <htejun@gmail.com>
--
tejun
prev parent reply other threads:[~2008-05-21 4:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 14:57 [PATCH] libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl Alan Cox
2008-05-21 4:23 ` Tejun Heo [this message]
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=4833A3BE.2070107@gmail.com \
--to=htejun@gmail.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeff@garzik.org \
--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 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.