What is the policy w.r.t broken DSDTs and the ACPI subsystem?
Specifically, which of these two options is right:
1- Provide a non-buggy DSDT to the kernel
2- Make the ACPI subsystem tolerant of the bugs
The option 3, have all biosen over the world fixed is a nice fantasy,
but nothing else.
If 1, we need to put a mechanism for that in the official kernel.
If 2, I'll start working on patches to make the laptop I play with
work as-is.
So, which it is?
OG.
On Fri, 22 Oct 2004 14:23:27 +0200
Olivier Galibert <[email protected]> wrote:
> What is the policy w.r.t broken DSDTs and the ACPI subsystem?
> Specifically, which of these two options is right:
>
> 1- Provide a non-buggy DSDT to the kernel
> 2- Make the ACPI subsystem tolerant of the bugs
>
> The option 3, have all biosen over the world fixed is a nice fantasy,
> but nothing else.
>
> If 1, we need to put a mechanism for that in the official kernel.
CONFIG_ACPI_CUSTOM_DSDT is included in 2.6.9
> If 2, I'll start working on patches to make the laptop I play with
> work as-is.
>
> So, which it is?
--
Onur Kucuk Knowledge speaks,
<onur.--.-.delipenguen.net> but wisdom listens
Le ven 22/10/2004 à 16:41, Onur Kucuk a écrit :
> On Fri, 22 Oct 2004 14:23:27 +0200
> Olivier Galibert <[email protected]> wrote:
>
> > What is the policy w.r.t broken DSDTs and the ACPI subsystem?
> > Specifically, which of these two options is right:
> >
> > 1- Provide a non-buggy DSDT to the kernel
> > 2- Make the ACPI subsystem tolerant of the bugs
> >
> > The option 3, have all biosen over the world fixed is a nice fantasy,
> > but nothing else.
> >
> > If 1, we need to put a mechanism for that in the official kernel.
>
> CONFIG_ACPI_CUSTOM_DSDT is included in 2.6.9
But fixed DSDTs are a pain to find, and fixing a buggy DSDT is
impossible for a non-hacker.
Xav
Le ven 22/10/2004 à 17:19, Pekka Pietikainen a écrit :
> On Fri, Oct 22, 2004 at 04:55:35PM +0200, Xavier Bestel wrote:
> > > CONFIG_ACPI_CUSTOM_DSDT is included in 2.6.9
> >
> > But fixed DSDTs are a pain to find, and fixing a buggy DSDT is
> > impossible for a non-hacker.
> >
> http://acpi.sourceforge.net/dsdt/index.php has quite a few.
.. which aren't all proper fixes (I tried the DSDT for Armada 1700, it's
a partial fix only).
> The problem is getting the fixed dsdt in use without recompiling your
> kernel, since quite a few people, especially non-technical ones, use vendor
> kernels. There's an approach that uses initrd, but this isn't merged
> yet. I'd say it should be, assuming no better solution can be found.
Yes, sure. But real non-technical people won't replace their DSDT
either.
Xav
On Mon, Oct 25, 2004 at 02:21:09PM +0800, Yu, Luming wrote:
> >> Yes, sure. But real non-technical people won't replace their DSDT
> >> either.
> >Their distro could do it for them :-) A simple approach would be to
> >store md5sums of known-bad dsdt's and xdeltas to fixed ones, and the
> >fixed one gets placed in /etc where mkinitrd automagically picks it up
> >whenever a new kernel is installed.
>
> I don't think distro can do that, because they are not the owner of
> DSDT.
That's what I said xdelta, so the only "new" code is patches against
the broken vendor code in /proc/acpi/dsdt. But it's messy even
that way, I know.
But that's all userspace, the kernel should still make it possible (via
initrd or something else ;) )
Le lun 25/10/2004 à 11:01, Pekka Pietikainen a écrit :
> On Mon, Oct 25, 2004 at 02:21:09PM +0800, Yu, Luming wrote:
> > >> Yes, sure. But real non-technical people won't replace their DSDT
> > >> either.
> > >Their distro could do it for them :-) A simple approach would be to
> > >store md5sums of known-bad dsdt's and xdeltas to fixed ones, and the
> > >fixed one gets placed in /etc where mkinitrd automagically picks it up
> > >whenever a new kernel is installed.
> >
> > I don't think distro can do that, because they are not the owner of
> > DSDT.
> That's what I said xdelta, so the only "new" code is patches against
> the broken vendor code in /proc/acpi/dsdt. But it's messy even
> that way, I know.
Hackish at best. Having an AML interpreter able to follow MS's quirks
seems a preferred solution (2.6.9's ACPI is said to be better at that, I
haven't tested it yet).
Xav
On Fri, Oct 22, 2004 at 04:55:35PM +0200, Xavier Bestel wrote:
> > CONFIG_ACPI_CUSTOM_DSDT is included in 2.6.9
>
> But fixed DSDTs are a pain to find, and fixing a buggy DSDT is
> impossible for a non-hacker.
>
http://acpi.sourceforge.net/dsdt/index.php has quite a few.
The problem is getting the fixed dsdt in use without recompiling your
kernel, since quite a few people, especially non-technical ones, use vendor
kernels. There's an approach that uses initrd, but this isn't merged
yet. I'd say it should be, assuming no better solution can be found.
On Fri, Oct 22, 2004 at 05:35:16PM +0200, Xavier Bestel wrote:
> > The problem is getting the fixed dsdt in use without recompiling your
> > kernel, since quite a few people, especially non-technical ones, use vendor
> > kernels. There's an approach that uses initrd, but this isn't merged
> > yet. I'd say it should be, assuming no better solution can be found.
>
> Yes, sure. But real non-technical people won't replace their DSDT
> either.
Their distro could do it for them :-) A simple approach would be to
store md5sums of known-bad dsdt's and xdeltas to fixed ones, and the
fixed one gets placed in /etc where mkinitrd automagically picks it up
whenever a new kernel is installed.
But that's userspace (with possible problems in distributing dsdt's, which
is why xdelta might be an acceptable solution), the kernel should just make
something like like that possible, if someone wants to do it.
Xavier Bestel wrote:
> Le ven 22/10/2004 ? 17:19, Pekka Pietikainen a ?crit :
> > On Fri, Oct 22, 2004 at 04:55:35PM +0200, Xavier Bestel wrote:
> > > > CONFIG_ACPI_CUSTOM_DSDT is included in 2.6.9
> > >
> > > But fixed DSDTs are a pain to find, and fixing a buggy DSDT is
> > > impossible for a non-hacker.
> > >
> > http://acpi.sourceforge.net/dsdt/index.php has quite a few.
>
> .. which aren't all proper fixes (I tried the DSDT for Armada 1700,
> it's a partial fix only).
This can be an issue to work on. I am sure acpi people won't reject
proper fixes.
> > The problem is getting the fixed dsdt in use without recompiling
> > your kernel, since quite a few people, especially non-technical
> > ones, use vendor kernels. There's an approach that uses initrd, but
> > this isn't merged yet. I'd say it should be, assuming no better
> > solution can be found.
The initrd approach seems nicer and more customisable.
> Yes, sure. But real non-technical people won't replace their DSDT
> either.
Real non-technical people follow their distros. They don't need to
recompile a kernel of their own. It is a distro's job for them.
--
Onur Kucuk Knowledge speaks,
<onur.--.-.delipenguen.net> but wisdom listens
>
>But fixed DSDTs are a pain to find, and fixing a buggy DSDT is
>impossible for a non-hacker.
>
> Xav
>
There is some fixed DSDT filed on acpi.sf.net
>> Yes, sure. But real non-technical people won't replace their DSDT
>> either.
>Their distro could do it for them :-) A simple approach would be to
>store md5sums of known-bad dsdt's and xdeltas to fixed ones, and the
>fixed one gets placed in /etc where mkinitrd automagically picks it up
>whenever a new kernel is installed.
I don't think distro can do that, because they are not the owner of
DSDT.