From: "Uwe Bugla" <uwe.bugla@gmx.de>
To: castet.matthieu@free.fr, shaohua.li@intel.com
Cc: bjorn.helgaas@hp.com, linux-acpi@vger.kernel.org,
len.brown@intel.com, akpm@osdl.org, ambx1@neo.rr.com
Subject: Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
Date: Tue, 27 Jun 2006 16:19:06 +0200 [thread overview]
Message-ID: <20060627141906.6140@gmx.net> (raw)
In-Reply-To: <1151409746.44a11e52e7002@imp8-g19.free.fr>
-------- Original-Nachricht --------
Datum: Tue, 27 Jun 2006 14:02:26 +0200
Von: castet.matthieu@free.fr
An: Shaohua Li <shaohua.li@intel.com>
Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
> Selon Shaohua Li <shaohua.li@intel.com>:
>
> >
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4bb6f5ad968540d7f9619565bacd18d7419b85f
> > Thanks and sorry I didn't find the issue before. We'd better blacklist
> > root bridge. I saw at lest one BIOS (IA64 box) didn't assign correct
> > producer/consumer flag to root bridge resources. Blacklist it is much
> > safer.
>
> Is only PNP0A03 is producer type in __all__ ACPI possible devices ?
> If not we will have the same problem with others devices...
>
> I don't think blacklist is the solution : pnpacpi should be able to handle
> all
> ressources types : we should complete the implementation instead of
> blacklist
> devices our implementation doesn't support.
>
> If there are broken ACPI bios, there should be firmware update, a patched
> dsdt
> or a quirk, but no "quirk and no generic solution".
>
> To be honest I am bored about this acpi stuff : there are no reply when
> you ask
> questions or propose things, it takes months to have a patch, there are
> lot's
> of broken ACPI bios, ...
>
> For example http://bugzilla.kernel.org/show_bug.cgi?id=3358 I submited 1,5
> years
> ago is still present in the kernel...
>
>
> Matthieu CASTET
>
> --------
>
> "The fact that ACPI was designed by a group of monkeys high on LSD, and is
> some
> of the worst designs in the industry obviously makes running it at _any_
> point
> pretty damn ugly. " (July 31, 2005) Linus Torvalds
Salut Matthieu, hi everybody else wanting to listen,
A thousand Thanks for:
a. your excellent work in doing this patch. I did not test mm3 right now, but I swear I will do that as soosn as possible.
b. this very good citation from Linus hitting it to the point very exactly (Is the Microsoft team meant by those acid trip monkeys??? I simply do not know who the fuck invented this rubbish!).
"To be honest I am bored about this acpi stuff : there are no reply when
you ask questions or propose things, it takes months to have a patch, there are lot's of broken ACPI bios, ..."
But you do not mean me personally, do you? I spent couples of days on this sucking shit NOT to "fight down" anything or anybody (like Bjorn stated), but to help finding a solution in this very sucking issue.
As a cross-platform solution is appreciated I understand your exhaust and frustration very well. Blacklisting is NO good solution at all, is it?
Furthermore I really dislike those abbreviations like "NAK", "IMHO" etc.
And I´d like to repeat my proposal:
This stuff should NOT be in the mm-branch, but in a RC-candidate of the main vanilla: There would be much more traffic on this issue and a significant higher motivation for resolving that so that everyone is satisfied. But Andrew will never agree on this, will he ever?
Cheers everybody, just smile now
Uwe
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-06-27 14:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-27 6:30 [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources Brown, Len
2006-06-27 7:03 ` Andrew Morton
2006-06-27 7:37 ` Adam Belay
2006-06-27 7:29 ` Shaohua Li
2006-06-27 12:02 ` castet.matthieu
2006-06-27 14:19 ` Uwe Bugla [this message]
2006-06-27 16:03 ` Bjorn Helgaas
2006-06-28 1:02 ` Shaohua Li
2006-06-28 8:57 ` Uwe Bugla
2006-06-28 16:55 ` Bjorn Helgaas
2006-06-29 1:13 ` Shaohua Li
2006-06-29 12:24 ` Uwe Bugla
2006-06-29 18:38 ` Bjorn Helgaas
2006-06-30 1:30 ` Shaohua Li
-- strict thread matches above, loose matches on Subject: below --
2006-06-29 12:41 Li, Shaohua
2006-06-30 9:04 ` Uwe Bugla
2006-06-30 16:03 ` Bjorn Helgaas
2006-07-03 8:19 ` Uwe Bugla
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=20060627141906.6140@gmx.net \
--to=uwe.bugla@gmx.de \
--cc=akpm@osdl.org \
--cc=ambx1@neo.rr.com \
--cc=bjorn.helgaas@hp.com \
--cc=castet.matthieu@free.fr \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=shaohua.li@intel.com \
/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