Re: ACPI panic on amd64
On Fri, Nov 26, 2021 at 05:16:08PM +0100, Parodper wrote: > Here is a gzipped collage of a video I took of the dmesg. Please don't send such large attachments to the list.
Re: ACPI panic on amd64
O 27/11/21 ás 02:26, Theo de Raadt escribiu: > Parodper wrote: > >> Here is a gzipped collage of a video I took of the dmesg. > If you won't put any effort into summarizing the details of a > report, we won't put any effort into fixing it. There are many things happening on the dmesg, and I did not want to miss some crucial detail, so I tried to put everything in. However, if you like I can try to transcribe parts of the dmesg. What I can also do is upload the installer's dmesg, but since the installer did not panic I don't know if it would be useful. > Because we don't owe you that effort. Seriously go run Windows > or RedHat -- that way you can encourage an ecosystem where people > don't care, or you pay them to care, because they won't watch > your videos. It is not a video, but a bunch of images pasted together. I did that to not have to upload a video. The image is gzipped because I did not know if there were file size limits on this list.
Re: ACPI panic on amd64
Parodper wrote: > Here is a gzipped collage of a video I took of the dmesg. Yawn. TLDW. If you won't put any effort into summarizing the details of a report, we won't put any effort into fixing it. Because we don't owe you that effort. Seriously go run Windows or RedHat -- that way you can encourage an ecosystem where people don't care, or you pay them to care, because they won't watch your videos. You have made some pretty big assumptions and they are incorrect.
Re: acpi panic
Committed the fix.
Thanks all.
On Wed, 17 Mar 2021 08:35:52 -0700
Rafael Ávila de Espíndola wrote:
> Your patch works too.
>
> Thanks!
> Rafael
>
>
> YASUOKA Masahiko writes:
>
>> On Tue, 16 Mar 2021 16:03:27 -0700
>> Rafael Ávila de Espíndola wrote:
>>> Patrick Wildt writes:
>>>
Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola:
>
> Patrick Wildt writes:
>
> > Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de
> > Espíndola:
> >> Patrick Wildt writes:
> >>
> >> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de
> >> > Espíndola:
> >> >> Got the same error this morning after updating to MP#408.
> >> >>
> >> >> Cheers,
> >> >> Rafael
> >> >
> >> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you
> >> > already following snapshots and switching from one snapshot to the
> >> > other broke it?
> >>
> >> I was following snapshots, but not very frequently. The last one that I
> >> was using without any problems was from Feb 15 (or at least that is
> >> when
> >> I got the "upgrade log" email).
> >>
> >> Cheers,
> >> Rafael
> >
> > Can this be the cause? There have been only few changes in ACPI, and
> > this definitely does some AML store thing:
> >
> > https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6
>
> Yes, that is the one. A patch with
> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6,
> abe2aacc6845fd5ce80896a50e770d4116e9f80c and
> 71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one
> with just the last two reverted fails in the same way as the snapshot.
>
> Thanks,
> Rafael
>
Wait, so which one is it?
>>>
>>> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 is the one that causes the
>>> problem.
>>
>> How about the following diff instead of reverting c1053d6a5a6ff0?
>>
>> Previous breaks if LocalX itself is an object reference.
>>
>> Index: sys/dev/acpi/dsdt.c
>> ===
>> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
>> retrieving revision 1.260
>> diff -u -p -r1.260 dsdt.c
>> --- sys/dev/acpi/dsdt.c 10 Mar 2021 22:20:44 - 1.260
>> +++ sys/dev/acpi/dsdt.c 17 Mar 2021 02:42:36 -
>> @@ -2961,10 +2961,13 @@ aml_store(struct aml_scope *scope, struc
>> aml_rwfield(rhs, 0, rhs->v_field.bitlen, , ACPI_IOREAD);
>> rhs =
>> }
>> +/* Store to LocalX: free value */
>> +if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
>> +aml_freevalue(lhs);
>>
>> lhs = aml_gettgt(lhs, AMLOP_STORE);
>>
>> -/* Store to LocalX: free value */
>> +/* Store to LocalX: free value again */
>> if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
>> aml_freevalue(lhs);
>> switch (lhs->type) {
>
Re: acpi panic
> Date: Wed, 17 Mar 2021 11:47:25 +0900 (JST)
> From: YASUOKA Masahiko
>
> On Tue, 16 Mar 2021 16:03:27 -0700
> Rafael Ávila de Espíndola wrote:
> > Patrick Wildt writes:
> >
> >> Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola:
> >>>
> >>> Patrick Wildt writes:
> >>>
> >>> > Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de
> >>> > Espíndola:
> >>> >> Patrick Wildt writes:
> >>> >>
> >>> >> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de
> >>> >> > Espíndola:
> >>> >> >> Got the same error this morning after updating to MP#408.
> >>> >> >>
> >>> >> >> Cheers,
> >>> >> >> Rafael
> >>> >> >
> >>> >> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you
> >>> >> > already following snapshots and switching from one snapshot to the
> >>> >> > other broke it?
> >>> >>
> >>> >> I was following snapshots, but not very frequently. The last one that I
> >>> >> was using without any problems was from Feb 15 (or at least that is
> >>> >> when
> >>> >> I got the "upgrade log" email).
> >>> >>
> >>> >> Cheers,
> >>> >> Rafael
> >>> >
> >>> > Can this be the cause? There have been only few changes in ACPI, and
> >>> > this definitely does some AML store thing:
> >>> >
> >>> > https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6
> >>>
> >>> Yes, that is the one. A patch with
> >>> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6,
> >>> abe2aacc6845fd5ce80896a50e770d4116e9f80c and
> >>> 71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one
> >>> with just the last two reverted fails in the same way as the snapshot.
> >>>
> >>> Thanks,
> >>> Rafael
> >>>
> >>
> >> Wait, so which one is it?
> >
> > c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 is the one that causes the
> > problem.
>
> How about the following diff instead of reverting c1053d6a5a6ff0?
>
> Previous breaks if LocalX itself is an object reference.
ok kettenis@
> Index: sys/dev/acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.260
> diff -u -p -r1.260 dsdt.c
> --- sys/dev/acpi/dsdt.c 10 Mar 2021 22:20:44 - 1.260
> +++ sys/dev/acpi/dsdt.c 17 Mar 2021 02:42:36 -
> @@ -2961,10 +2961,13 @@ aml_store(struct aml_scope *scope, struc
> aml_rwfield(rhs, 0, rhs->v_field.bitlen, , ACPI_IOREAD);
> rhs =
> }
> + /* Store to LocalX: free value */
> + if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
> + aml_freevalue(lhs);
>
> lhs = aml_gettgt(lhs, AMLOP_STORE);
>
> - /* Store to LocalX: free value */
> + /* Store to LocalX: free value again */
> if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
> aml_freevalue(lhs);
> switch (lhs->type) {
>
>
Re: acpi panic
Your patch works too.
Thanks!
Rafael
YASUOKA Masahiko writes:
> On Tue, 16 Mar 2021 16:03:27 -0700
> Rafael Ávila de Espíndola wrote:
>> Patrick Wildt writes:
>>
>>> Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola:
Patrick Wildt writes:
> Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de
> Espíndola:
>> Patrick Wildt writes:
>>
>> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de
>> > Espíndola:
>> >> Got the same error this morning after updating to MP#408.
>> >>
>> >> Cheers,
>> >> Rafael
>> >
>> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you
>> > already following snapshots and switching from one snapshot to the
>> > other broke it?
>>
>> I was following snapshots, but not very frequently. The last one that I
>> was using without any problems was from Feb 15 (or at least that is when
>> I got the "upgrade log" email).
>>
>> Cheers,
>> Rafael
>
> Can this be the cause? There have been only few changes in ACPI, and
> this definitely does some AML store thing:
>
> https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6
Yes, that is the one. A patch with
c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6,
abe2aacc6845fd5ce80896a50e770d4116e9f80c and
71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one
with just the last two reverted fails in the same way as the snapshot.
Thanks,
Rafael
>>>
>>> Wait, so which one is it?
>>
>> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 is the one that causes the
>> problem.
>
> How about the following diff instead of reverting c1053d6a5a6ff0?
>
> Previous breaks if LocalX itself is an object reference.
>
> Index: sys/dev/acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.260
> diff -u -p -r1.260 dsdt.c
> --- sys/dev/acpi/dsdt.c 10 Mar 2021 22:20:44 - 1.260
> +++ sys/dev/acpi/dsdt.c 17 Mar 2021 02:42:36 -
> @@ -2961,10 +2961,13 @@ aml_store(struct aml_scope *scope, struc
> aml_rwfield(rhs, 0, rhs->v_field.bitlen, , ACPI_IOREAD);
> rhs =
> }
> + /* Store to LocalX: free value */
> + if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
> + aml_freevalue(lhs);
>
> lhs = aml_gettgt(lhs, AMLOP_STORE);
>
> - /* Store to LocalX: free value */
> + /* Store to LocalX: free value again */
> if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
> aml_freevalue(lhs);
> switch (lhs->type) {
Re: acpi panic
On Tue, 16 Mar 2021 16:03:27 -0700
Rafael Ávila de Espíndola wrote:
> Patrick Wildt writes:
>
>> Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola:
>>>
>>> Patrick Wildt writes:
>>>
>>> > Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de
>>> > Espíndola:
>>> >> Patrick Wildt writes:
>>> >>
>>> >> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de
>>> >> > Espíndola:
>>> >> >> Got the same error this morning after updating to MP#408.
>>> >> >>
>>> >> >> Cheers,
>>> >> >> Rafael
>>> >> >
>>> >> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you
>>> >> > already following snapshots and switching from one snapshot to the
>>> >> > other broke it?
>>> >>
>>> >> I was following snapshots, but not very frequently. The last one that I
>>> >> was using without any problems was from Feb 15 (or at least that is when
>>> >> I got the "upgrade log" email).
>>> >>
>>> >> Cheers,
>>> >> Rafael
>>> >
>>> > Can this be the cause? There have been only few changes in ACPI, and
>>> > this definitely does some AML store thing:
>>> >
>>> > https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6
>>>
>>> Yes, that is the one. A patch with
>>> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6,
>>> abe2aacc6845fd5ce80896a50e770d4116e9f80c and
>>> 71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one
>>> with just the last two reverted fails in the same way as the snapshot.
>>>
>>> Thanks,
>>> Rafael
>>>
>>
>> Wait, so which one is it?
>
> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 is the one that causes the
> problem.
How about the following diff instead of reverting c1053d6a5a6ff0?
Previous breaks if LocalX itself is an object reference.
Index: sys/dev/acpi/dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.260
diff -u -p -r1.260 dsdt.c
--- sys/dev/acpi/dsdt.c 10 Mar 2021 22:20:44 - 1.260
+++ sys/dev/acpi/dsdt.c 17 Mar 2021 02:42:36 -
@@ -2961,10 +2961,13 @@ aml_store(struct aml_scope *scope, struc
aml_rwfield(rhs, 0, rhs->v_field.bitlen, , ACPI_IOREAD);
rhs =
}
+ /* Store to LocalX: free value */
+ if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
+ aml_freevalue(lhs);
lhs = aml_gettgt(lhs, AMLOP_STORE);
- /* Store to LocalX: free value */
+ /* Store to LocalX: free value again */
if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
aml_freevalue(lhs);
switch (lhs->type) {
Re: acpi panic
Patrick Wildt writes: > Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola: >> >> Patrick Wildt writes: >> >> > Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de Espíndola: >> >> Patrick Wildt writes: >> >> >> >> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de >> >> > Espíndola: >> >> >> Got the same error this morning after updating to MP#408. >> >> >> >> >> >> Cheers, >> >> >> Rafael >> >> > >> >> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you >> >> > already following snapshots and switching from one snapshot to the >> >> > other broke it? >> >> >> >> I was following snapshots, but not very frequently. The last one that I >> >> was using without any problems was from Feb 15 (or at least that is when >> >> I got the "upgrade log" email). >> >> >> >> Cheers, >> >> Rafael >> > >> > Can this be the cause? There have been only few changes in ACPI, and >> > this definitely does some AML store thing: >> > >> > https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 >> >> Yes, that is the one. A patch with >> c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6, >> abe2aacc6845fd5ce80896a50e770d4116e9f80c and >> 71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one >> with just the last two reverted fails in the same way as the snapshot. >> >> Thanks, >> Rafael >> > > Wait, so which one is it? c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 is the one that causes the problem. Cheers, Rafael
Re: acpi panic
Am Tue, Mar 16, 2021 at 03:25:46PM -0700 schrieb Rafael Ávila de Espíndola: > > Patrick Wildt writes: > > > Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de Espíndola: > >> Patrick Wildt writes: > >> > >> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de > >> > Espíndola: > >> >> Got the same error this morning after updating to MP#408. > >> >> > >> >> Cheers, > >> >> Rafael > >> > > >> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you > >> > already following snapshots and switching from one snapshot to the > >> > other broke it? > >> > >> I was following snapshots, but not very frequently. The last one that I > >> was using without any problems was from Feb 15 (or at least that is when > >> I got the "upgrade log" email). > >> > >> Cheers, > >> Rafael > > > > Can this be the cause? There have been only few changes in ACPI, and > > this definitely does some AML store thing: > > > > https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 > > Yes, that is the one. A patch with > c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6, > abe2aacc6845fd5ce80896a50e770d4116e9f80c and > 71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one > with just the last two reverted fails in the same way as the snapshot. > > Thanks, > Rafael > Wait, so which one is it?
Re: acpi panic
Patrick Wildt writes: > Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de Espíndola: >> Patrick Wildt writes: >> >> > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de Espíndola: >> >> Got the same error this morning after updating to MP#408. >> >> >> >> Cheers, >> >> Rafael >> > >> > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you >> > already following snapshots and switching from one snapshot to the >> > other broke it? >> >> I was following snapshots, but not very frequently. The last one that I >> was using without any problems was from Feb 15 (or at least that is when >> I got the "upgrade log" email). >> >> Cheers, >> Rafael > > Can this be the cause? There have been only few changes in ACPI, and > this definitely does some AML store thing: > > https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 Yes, that is the one. A patch with c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6, abe2aacc6845fd5ce80896a50e770d4116e9f80c and 71a585ed804adbdd9d4eee13175b0812699dc34b reverted boots fine, but one with just the last two reverted fails in the same way as the snapshot. Thanks, Rafael
Re: acpi panic
Am Tue, Mar 16, 2021 at 09:24:46AM -0700 schrieb Rafael Ávila de Espíndola: > Patrick Wildt writes: > > > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de Espíndola: > >> Got the same error this morning after updating to MP#408. > >> > >> Cheers, > >> Rafael > > > > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you > > already following snapshots and switching from one snapshot to the > > other broke it? > > I was following snapshots, but not very frequently. The last one that I > was using without any problems was from Feb 15 (or at least that is when > I got the "upgrade log" email). > > Cheers, > Rafael Can this be the cause? There have been only few changes in ACPI, and this definitely does some AML store thing: https://github.com/openbsd/src/commit/c1053d6a5a6ff0c23fa9cda5b6bd2d6feb9d82b6 The other "bigger" change is https://github.com/openbsd/src/commit/abe2aacc6845fd5ce80896a50e770d4116e9f80c but I don't think it's related to that. Can you build a kernel without that aml_store() change and see if it fixes something for you? Patrick
Re: acpi panic
Patrick Wildt writes: > Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de Espíndola: >> Got the same error this morning after updating to MP#408. >> >> Cheers, >> Rafael > > Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you > already following snapshots and switching from one snapshot to the > other broke it? I was following snapshots, but not very frequently. The last one that I was using without any problems was from Feb 15 (or at least that is when I got the "upgrade log" email). Cheers, Rafael
Re: acpi panic
Am Tue, Mar 16, 2021 at 08:17:09AM -0700 schrieb Rafael Ávila de Espíndola: > Got the same error this morning after updating to MP#408. > > Cheers, > Rafael Is this a regression? Did 6.8 work and 6.9-beta broke it? Were you already following snapshots and switching from one snapshot to the other broke it?
Re: acpi panic
Got the same error this morning after updating to MP#408. Cheers, Rafael
Re: acpi panic on asus ux31a
On Sat, 03 Nov 2012 at 13:46:53 +0100, Jonathan Armani wrote:
I don't know if ACPI allow method to be overrided, but here is a diff
that pass the first panic and allow only by an integer.
I did not found anything related to that in the spec, does someone have
an idea ?
Any update on this going in? It fixes one of the ACPI problems with
this machine for me, but I don't know if it's correct.
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.197
diff -u -p -u -p -r1.197 dsdt.c
--- dsdt.c16 Jul 2012 15:27:11 - 1.197
+++ dsdt.c3 Nov 2012 12:37:45 -
@@ -2593,6 +2593,14 @@ aml_store(struct aml_scope *scope, struc
aml_freevalue(lhs);
aml_copyvalue(lhs, rhs);
break;
+ case AML_OBJTYPE_METHOD:
+ /* Method override */
+ if (rhs-type != AML_OBJTYPE_INTEGER) {
+ aml_die(Overriding a method with non-int?);
+ }
+ aml_freevalue(lhs);
+ aml_copyvalue(lhs, rhs);
+ break;
default:
aml_die(Store to default type! %x\n, lhs-type);
break;
Re: acpi panic on asus ux31a
On Thu, Sep 13, 2012 at 01:21:54PM +0300, Paul Irofti wrote:
On Wed, Sep 12, 2012 at 09:12:20PM -0500, joshua stein wrote:
asus ux31a running amd64 sept 11 snapshot, newest bios (happened
with older one too), panics during acpi configuration.
Does this help?
Hi,
There is a store(Int, Method) :
101 Method (_PDC, 1, NotSerialized)
102 {
103 Store (CPPC, \_PR.CPU0._PPC)
104 Store (CPDC (Arg0), Local0)
defined :
32 Scope (\_PR.CPU0)
33 {
34 Method (_PPC, 0, NotSerialized)
35 {
36 Return (\LIMT)
37 }
I don't know if ACPI allow method to be overrided, but here is a diff
that pass the first panic and allow only by an integer.
I did not found anything related to that in the spec, does someone have
an idea ?
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.197
diff -u -p -u -p -r1.197 dsdt.c
--- dsdt.c 16 Jul 2012 15:27:11 - 1.197
+++ dsdt.c 3 Nov 2012 12:37:45 -
@@ -2593,6 +2593,14 @@ aml_store(struct aml_scope *scope, struc
aml_freevalue(lhs);
aml_copyvalue(lhs, rhs);
break;
+ case AML_OBJTYPE_METHOD:
+ /* Method override */
+ if (rhs-type != AML_OBJTYPE_INTEGER) {
+ aml_die(Overriding a method with non-int?);
+ }
+ aml_freevalue(lhs);
+ aml_copyvalue(lhs, rhs);
+ break;
default:
aml_die(Store to default type! %x\n, lhs-type);
break;
Re: acpi panic on asus ux31a
On Wed, Sep 12, 2012 at 09:12:20PM -0500, joshua stein wrote:
asus ux31a running amd64 sept 11 snapshot, newest bios (happened
with older one too), panics during acpi configuration.
Does this help?
Index: dev/acpi/acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.57
diff -u -p -r1.57 acpicpu.c
--- dev/acpi/acpicpu.c 21 Jul 2010 19:35:15 - 1.57
+++ dev/acpi/acpicpu.c 13 Sep 2012 10:18:44 -
@@ -201,19 +201,23 @@ acpicpu_set_pdc(struct acpicpu_softc *sc
static uint8_t cpu_oscuuid[16] = { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29,
0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70,
0x58, 0x71, 0x39, 0x53 };
- /* Evaluate _PDC */
- memset(cmd, 0, sizeof(cmd));
- cmd.type = AML_OBJTYPE_BUFFER;
- cmd.v_buffer = (uint8_t *)buf;
- cmd.length = sizeof(buf);
-
- buf[0] = ACPI_PDC_REVID;
buf[1] = 1;
buf[2] = ACPI_PDC_C_C1_HALT | ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH
| ACPI_PDC_C_C2C3_FFH | ACPI_PDC_SMP_P_SWCOORD | ACPI_PDC_SMP_C2C3
| ACPI_PDC_SMP_C1PT;
- aml_evalname(sc-sc_acpi, sc-sc_devnode, _PDC, 1, cmd, res);
+ /* Look-up the method first, since it's deprecated since ACPI 3.0. */
+ if (aml_searchname(sc-sc_devnode, _PDC)) {
+ /* Evaluate _PDC */
+ memset(cmd, 0, sizeof(cmd));
+ cmd.type = AML_OBJTYPE_BUFFER;
+ cmd.v_buffer = (uint8_t *)buf;
+ cmd.length = sizeof(buf);
+
+ buf[0] = ACPI_PDC_REVID;
+ aml_evalname(sc-sc_acpi, sc-sc_devnode,
+ _PDC, 1, cmd, res);
+ }
/* Evaluate _OSC */
memset(osc_cmd, 0, sizeof(cmd) * 4);
Re: acpi panic on asus ux31a
On Thu, 13 Sep 2012 at 13:21:54 +0300, Paul Irofti wrote:
On Wed, Sep 12, 2012 at 09:12:20PM -0500, joshua stein wrote:
asus ux31a running amd64 sept 11 snapshot, newest bios (happened
with older one too), panics during acpi configuration.
Does this help?
no, same aml_die output and same panic (just with a different offset
in acpicpu_set_pdc())
Index: dev/acpi/acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.57
diff -u -p -r1.57 acpicpu.c
--- dev/acpi/acpicpu.c21 Jul 2010 19:35:15 - 1.57
+++ dev/acpi/acpicpu.c13 Sep 2012 10:18:44 -
@@ -201,19 +201,23 @@ acpicpu_set_pdc(struct acpicpu_softc *sc
static uint8_t cpu_oscuuid[16] = { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29,
0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70,
0x58, 0x71, 0x39, 0x53 };
- /* Evaluate _PDC */
- memset(cmd, 0, sizeof(cmd));
- cmd.type = AML_OBJTYPE_BUFFER;
- cmd.v_buffer = (uint8_t *)buf;
- cmd.length = sizeof(buf);
-
- buf[0] = ACPI_PDC_REVID;
buf[1] = 1;
buf[2] = ACPI_PDC_C_C1_HALT | ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH
| ACPI_PDC_C_C2C3_FFH | ACPI_PDC_SMP_P_SWCOORD | ACPI_PDC_SMP_C2C3
| ACPI_PDC_SMP_C1PT;
- aml_evalname(sc-sc_acpi, sc-sc_devnode, _PDC, 1, cmd, res);
+ /* Look-up the method first, since it's deprecated since ACPI 3.0. */
+ if (aml_searchname(sc-sc_devnode, _PDC)) {
+ /* Evaluate _PDC */
+ memset(cmd, 0, sizeof(cmd));
+ cmd.type = AML_OBJTYPE_BUFFER;
+ cmd.v_buffer = (uint8_t *)buf;
+ cmd.length = sizeof(buf);
+
+ buf[0] = ACPI_PDC_REVID;
+ aml_evalname(sc-sc_acpi, sc-sc_devnode,
+ _PDC, 1, cmd, res);
+ }
/* Evaluate _OSC */
memset(osc_cmd, 0, sizeof(cmd) * 4);
Re: acpi panic in aml_parse from acpivout
What happens when you run with this diff? Index: acpivout.c === RCS file: /cvs/src/sys/dev/acpi/acpivout.c,v retrieving revision 1.9 diff -u -p -r1.9 acpivout.c --- acpivout.c 23 May 2011 11:58:03 - 1.9 +++ acpivout.c 21 Oct 2011 09:44:17 - @@ -115,6 +115,7 @@ acpivout_attach(struct device *parent, s ws_get_param = acpivout_get_param; ws_set_param = acpivout_set_param; + acpivout_set_brightness(sc, 0x0f); acpivout_get_bcl(sc); }
