asus_acpi still broken on Samsung P30/P35

asus_acpi still broken on Samsung P30/P35

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Hi,

Since several kernel-versions now the asus_acpi module is broken on several 
Samsung notebooks, it causes an oops when loading and a kernelpanic when 
compiled into the kernel.

This is known for ages. There was a patch by Karol Kozimor shortly after the 
bug became public that was ignored.
The code was changed so the patch failed. Christian Aichinger again made a 
patch. It was ignored as well.

Now, finally the patch is in the mm-source, I asked Andrew Morton to push it 
to Linus so 2.6.15 will be fixed, Andrew said this is up to Len Brown. No 
Reply from him.

Now it seems that 2.6.15 is going to be released soon, the patch still has not 
made it into linus tree.

This is not "some minor issue", this completely breaks the usage of current 
vanilla-kernels on certain Hardware. Can please, please, please anyone in the 
position to do this take care that this patch get's accepted before 2.6.15?

The patch is available inside mm-sources or here:
http://www.int21.de/samsung/p30-2.6.14.diff

If I should send it to anyone else or if there's anything I can do to help 
fixing this, I'm glad to help.

cu,

-- 
Hanno Böck		Blog:   http://www.hboeck.de/
GPG: 3DBD3B20		Jabber: jabber@hboeck.de

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: asus_acpi still broken on Samsung P30/P35

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2519 bytes --]



On Wed, 21 Dec 2005, Hanno Böck wrote:
> 
> This is not "some minor issue", this completely breaks the usage of current 
> vanilla-kernels on certain Hardware. Can please, please, please anyone in the 
> position to do this take care that this patch get's accepted before 2.6.15?
> 
> The patch is available inside mm-sources or here:
> http://www.int21.de/samsung/p30-2.6.14.diff
> 
> If I should send it to anyone else or if there's anything I can do to help 
> fixing this, I'm glad to help.

Last I saw this patch, I wrote this reply (the patch above is still 
broken). Nobody ever came back to me on it.

			Linus

---
Date: Tue, 13 Dec 2005 21:15:56 -0800 (PST)
From: Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org>
To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005-hi6Y0CQ0nG0@public.gmane.org>
cc: Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>, 
    Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, 
    stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, acpi-devel <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops

On Wed, 14 Dec 2005, Carl-Daniel Hailfinger wrote:
> 
> The patch has been tested and verified, is shipped in the
> SUSE 10.0 kernel and does not cause any regressions.

I'd be _much_ happier if

 - the patch wasn't totally whitespace-damaged (your mailer seems 
   to not only remove spaces at the end of lines, it _also_ adds them to 
   the beginning when there was another space there, as far as I can tell)

   Being right "on average" thanks to having two different bugs does not a 
   good mailer make.

 - you were to separate out the oops-fixing code from the code that adds 
   handling for that (strange?) model type logic.

   It seems that the _oops_ is because the later paths just assume that 
   it's a ACPI_TYPE_STRING and will dereference "model->string.pointer" 
   regardless of whether that is true or not. And you add a test for 
   ACPI_TYPE_INTEGER, however, you do _not_ fix the oops for any other 
   type, so the exact _same_ bug is still waiting to happen if there is 
   some other strange ACPI table entry some day.

So I think the proper fix is to _first_ just do something like

	if (model->type != ACPI_TYPE_STRING)
		goto unknown;

which should fix the oops (no?), and then handling ACPI_TYPE_INTEGER above 
that as one case would be a separate patch.

		Linus

Re: [ACPI] Re: asus_acpi still broken on Samsung P30/P35

[Carl-Daniel Hailfinger]

Linus Torvalds schrieb:
> 
> On Wed, 21 Dec 2005, Hanno Böck wrote:
> 
>>This is not "some minor issue", this completely breaks the usage of current 
>>vanilla-kernels on certain Hardware. Can please, please, please anyone in the 
>>position to do this take care that this patch get's accepted before 2.6.15?
>>
>>The patch is available inside mm-sources or here:
>>http://www.int21.de/samsung/p30-2.6.14.diff
>>
>>If I should send it to anyone else or if there's anything I can do to help 
>>fixing this, I'm glad to help.
> 
> 
> Last I saw this patch, I wrote this reply (the patch above is still 
> broken). Nobody ever came back to me on it.
> [...]

I've been busy trying to gather all the different DSDTs to compare
them and find out if the logic can be simplified. Will try to come
up with a patch addressing all your and Andrew's concerns until friday.

Regards,
Carl-Daniel

RE: asus_acpi still broken on Samsung P30/P35

[Brown, Len]

Karol,
Do you have an update of your asus driver in the pipeline
that addresses this?

thanks,
-Len
 

>-----Original Message-----
>From: Linus Torvalds [mailto:torvalds@osdl.org] 
>Sent: Wednesday, December 21, 2005 1:37 PM
>To: Hanno Böck
>Cc: Andrew Morton; Brown, Len; 
>acpi-devel@lists.sourceforge.net; 
>linux-kernel@vger.kernel.org; Karol Kozimor; Christian Aichinger
>Subject: Re: asus_acpi still broken on Samsung P30/P35
>
>
>
>On Wed, 21 Dec 2005, Hanno Böck wrote:
>> 
>> This is not "some minor issue", this completely breaks the 
>usage of current 
>> vanilla-kernels on certain Hardware. Can please, please, 
>please anyone in the 
>> position to do this take care that this patch get's accepted 
>before 2.6.15?
>> 
>> The patch is available inside mm-sources or here:
>> http://www.int21.de/samsung/p30-2.6.14.diff
>> 
>> If I should send it to anyone else or if there's anything I 
>can do to help 
>> fixing this, I'm glad to help.
>
>Last I saw this patch, I wrote this reply (the patch above is still 
>broken). Nobody ever came back to me on it.
>
>			Linus
>
>---
>Date: Tue, 13 Dec 2005 21:15:56 -0800 (PST)
>From: Linus Torvalds <torvalds@osdl.org>
>To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>
>cc: Greg KH <greg@kroah.com>, 
>    Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, 
>    stable@kernel.org, acpi-devel <acpi-devel@lists.sourceforge.net>
>Subject: Re: [PATCH] Fix oops in asus_acpi.c on Samsung P30/P35 Laptops
>
>On Wed, 14 Dec 2005, Carl-Daniel Hailfinger wrote:
>> 
>> The patch has been tested and verified, is shipped in the
>> SUSE 10.0 kernel and does not cause any regressions.
>
>I'd be _much_ happier if
>
> - the patch wasn't totally whitespace-damaged (your mailer seems 
>   to not only remove spaces at the end of lines, it _also_ 
>adds them to 
>   the beginning when there was another space there, as far as 
>I can tell)
>
>   Being right "on average" thanks to having two different 
>bugs does not a 
>   good mailer make.
>
> - you were to separate out the oops-fixing code from the code 
>that adds 
>   handling for that (strange?) model type logic.
>
>   It seems that the _oops_ is because the later paths just 
>assume that 
>   it's a ACPI_TYPE_STRING and will dereference 
>"model->string.pointer" 
>   regardless of whether that is true or not. And you add a test for 
>   ACPI_TYPE_INTEGER, however, you do _not_ fix the oops for any other 
>   type, so the exact _same_ bug is still waiting to happen if 
>there is 
>   some other strange ACPI table entry some day.
>
>So I think the proper fix is to _first_ just do something like
>
>	if (model->type != ACPI_TYPE_STRING)
>		goto unknown;
>
>which should fix the oops (no?), and then handling 
>ACPI_TYPE_INTEGER above 
>that as one case would be a separate patch.
>
>		Linus
>

Re: asus_acpi still broken on Samsung P30/P35

[Karol Kozimor]

Thus wrote Brown, Len:
> Karol,
> Do you have an update of your asus driver in the pipeline
> that addresses this?

I still believe the only _right_ *workaround* is
http://bugme.osdl.org/attachment.cgi?id=6006&action=view

I'll take a shot at rediffing it against recent kernels in a couple of
hours (unless someone beats me to it).

acpi=strict will work until a suitable patch is merged.

Note: it's still a workaround, to properly fix this we need to make ACPI
interpreter behave predictably, as written in
http://bugme.osdl.org/show_bug.cgi?id=5067#c6 -- I believe I still haven't
heard from Robert Moore on the feasibility of such a solution.

Please also see http://bugme.osdl.org/show_bug.cgi?id=5067 and
http://bugzilla.kernel.org/show_bug.cgi?id=5092 for more info.

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click