RE: Buggy DSDTs policy ?

RE: Buggy DSDTs policy ?

[Yu, Luming]

>> 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.

Re: Buggy DSDTs policy ?

[Pekka Pietikainen]

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 ;) )

Re: Buggy DSDTs policy ?

[Xavier Bestel]

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

RE: Buggy DSDTs policy ?

[Yu, Luming]

>
>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

Buggy DSDTs policy ?

[Olivier Galibert]

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.

Re: Buggy DSDTs policy ?

[Onur Kucuk]

On Fri, 22 Oct 2004 14:23:27 +0200
Olivier Galibert <galibert@pobox.com> 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  

Re: Buggy DSDTs policy ?

[Xavier Bestel]

Le ven 22/10/2004 à 16:41, Onur Kucuk a écrit :
> On Fri, 22 Oct 2004 14:23:27 +0200
> Olivier Galibert <galibert@pobox.com> 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

Re: Buggy DSDTs policy ?

[Pekka Pietikainen]

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.

Re: Buggy DSDTs policy ?

[Xavier Bestel]

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

Re: Buggy DSDTs policy ?

[Pekka Pietikainen]

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.

Re: Buggy DSDTs policy ?

[Onur Kucuk]

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