From: Jeff Garzik <jeff@garzik.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: RESEND: [PATCH] libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
Date: Thu, 29 May 2008 13:46:13 -0400 [thread overview]
Message-ID: <483EEBE5.5030708@garzik.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0805290950230.2958@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Thu, 29 May 2008, Alan Cox wrote:
>> (Jeff would you please take a look at this: Its #4 or #5 top OOPS on Arjan's
>> oops tracker, and it generally causes the boot to fail. First sent 20th May)
>
> Quite frankly, if I was Jeff, I'd have refused to apply this patch as "too
> damn ugly to live".
>
> Why the *hell* doesn't it just fix "ata_sff_altstatus()" instead? Why does
> it introduce a ludicrously named stupid "maybe" version of it that doesn't
> oops?
>
> In other words: in *any* case where the old "ata_sff_altstatus()" function
> worked correctly, the new "ata_sff_maybe_altstatus()" function does THE
> EXACT SAME THING. And in any case where the old "ata_sff_altstatus()"
> function oopsed, the new "maybe" version at least is _better_.
>
> In other words: there is absolutely no excuse for keeping the old (and
> known-to-be-broken) "ata_sff_altstatus()" function at all. It should be
> removed, not left around with an alternate function that works.
That's my general feeling on the issue. It was ugly and seemed to
needlessly avoid the existing one, which we would probably have to
bugfix later on...
> I also think your "ata_sff_sync()" thing is buggy. It has a "ndelay(400)"
> that is almost certainly buggy (it's the one that is already in
> ata_sff_pause()).
>
> It may be that you meant to make it an "else if" case, ie if there was no
> IO-read, then you do a ndelay(400) as a last desperate case, but that's
> not how your ata_sdd_sync() is actually written.
The double-ndelay is definitely wrong, but we do need one. Technically
it should -only- be a 400ns delay, but we also have a register read in
there to make sure any posted writes are flushed.
Jeff
next prev parent reply other threads:[~2008-05-29 17:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-29 16:25 RESEND: [PATCH] libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl Alan Cox
2008-05-29 17:04 ` Linus Torvalds
2008-05-29 17:46 ` Jeff Garzik [this message]
2008-05-29 18:04 ` Linus Torvalds
2008-05-29 18:13 ` Jeff Garzik
2008-05-29 18:29 ` Alan Cox
2008-05-29 18:19 ` Alan Cox
2008-05-29 21:13 ` Linus Torvalds
2008-05-29 21:19 ` Alan Cox
2008-05-29 18:02 ` Alan Cox
2008-05-29 18:25 ` Jeff Garzik
2008-05-29 18:38 ` Alan Cox
2008-05-29 19:46 ` Linus Torvalds
2008-05-29 20:18 ` Alan Cox
2008-05-29 18:42 ` Alan Cox
2008-05-29 19:31 ` Jeff Garzik
2008-05-29 21:10 ` [RFC PATCH] " Alan Cox
2008-05-29 21:37 ` Alan Cox
2008-05-29 21:57 ` Jeff Garzik
2008-05-29 21:57 ` Alan Cox
2008-05-30 22:14 ` Jeff Garzik
2008-06-04 10:45 ` Jeff Garzik
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=483EEBE5.5030708@garzik.org \
--to=jeff@garzik.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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).