linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Tejun Heo <tj@kernel.org>
Cc: Linda Walsh <lkml@tlinx.org>,
	linux-ide@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux acpi <linux-acpi@vger.kernel.org>
Subject: Re: Promise 300-TX 4-channel SATA disk going dead under load 2.6.24-7
Date: Fri, 29 Aug 2008 13:39:58 +0200	[thread overview]
Message-ID: <200808291339.59785.trenn@suse.de> (raw)
In-Reply-To: <48B7CD5E.1050701@kernel.org>

On Friday 29 August 2008 12:20:14 Tejun Heo wrote:
> Thomas Renninger wrote:
> > Also the system is really old. Why don't you stick to pci=noacpi or
> > even acpi=off?
> > What advantage do you want to get with ACPI (SATA works?)?
>
> I think this is the second time I see ACPI IRQ routing doesn't work on
> old ACPI.
Hey, that's great. I expected you have seen much more (you inflicted me
on more than two? :) ).
There is a cut (date) when it makes sense to use ACPI and when to not
use it. Ideally one would like to choose for what the machine got
tested and certified, but you can only guess.
Thus a lot old machines need acpi=force or acpi=off.
> Is it possible to detect this and turn off automatically?  Or 
> does that risk breaking even more machines?
I do not know the very IRQ and PCI details, but I expect the
problem is you cannot detect whether an interrupt is wrongly set up.

While apic vs pic is a real HW switch and once done there is no way back,
acpi vs legacy IRQ setup, should just be about different ways of parsing and 
getting info how to set up the irq.
If you set up the IRQ using ACPI information and you detect that something
went wrong, it should be no problem (hmm, maybe a solvable design problem in 
the pci layer) to use PCI config or whatever legacy info to re-set up the
IRQ.
But as said, I expect it's not easy/possible to detect when the IRQ is
wrongly set up. Maybe you can add in the devices:
test_irq_activity(..)
If this fails you can try to set it up again..., no I do not think you want
to do that.

Also beside old machines which might need the noacpi or acpi=off, pci=noacpi 
and related boot params we do rather good IMO.
I remember:
    - legacy IDE problems, one boiled down to a BIOS Bug
    - No PCI domain support, that broke one HP machine which seemed to be the
      only one using it. Maybe it's already supported, rather old.
    - yeah and some older machines I do not really remember
where pci=noacpi helped. IMO not worth an automated detection.
Especially for those old machines..., people know which param to use, you will
produce more grief than any good.

There were several acpipnp problems recently, but this is another topic and 
that needs fixing anyway, Bjorn is doing a real good job here.

    Thomas

  reply	other threads:[~2008-08-29 11:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-13 22:27 Promise 300-TX 4-channel SATA disk going dead under load 2.6.24-7 Linda Walsh
2008-08-14 10:50 ` Alan Cox
2008-08-20  7:39   ` Tejun Heo
2008-08-28  1:46     ` Linda Walsh
2008-08-28  7:03       ` Tejun Heo
2008-08-28 12:36         ` Thomas Renninger
2008-08-29 10:20           ` Tejun Heo
2008-08-29 11:39             ` Thomas Renninger [this message]
2008-08-29 12:02               ` Tejun Heo
2008-08-29 13:11                 ` Thomas Renninger
2008-08-29 13:18                   ` Tejun Heo
2008-08-29 13:31                     ` Thomas Renninger

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=200808291339.59785.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=lkml@tlinx.org \
    --cc=tj@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).