Re: Call for testers: acpica-unix-20020815
Mark Santcroos wrote: On Mon, Aug 26, 2002 at 03:01:48AM +0900, Mitsuru IWASAKI wrote: >How about this one? >http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz > >This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. This didn't work unfortunately. The problem is actually a bit weird. When I suspend (close the lid or with the key combo) the display is not turned off actually. It does go in some form of suspend however. When I resume, the machine comes back to life again, but the screen goes off at that moment. Any news on this issue? I still see the issue Mark described on a similar Dell with today's -current, and it's the only major remaining issue that prevents me from switching to -current exclusively. Not being able to standby is a major pain. This is probably incredibly naive, but since this worked under -stable, shouldn't there be some code already that does the right thing? (I'm guessing the answer must be "no, everything is different with ACPI.") Other than that, great job on the ACPI code - everything else works flawlessly! Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Call for testers: acpica-unix-20020815
On Sun, Aug 25, 2002 at 06:59:45PM +0200, Mark Santcroos wrote: > I have a Dell Latitude C640 and my screen won't come back after a suspend. > The machine works fine besides that. FYI: I just did a minimal Linux installation on this machine and tried latest kernel with latest ACPI. Exactly the same behaviour. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815
On Wed, 28 Aug 2002, Mitsuru IWASAKI wrote: > > 1) Fix the ASL so that it compiles without errors or warnings > > 2) Override the BIOS version of the table with your new one. (I don't know > > how this is done on FreeBSD, someone else will have to help you. > > Attached patches will fix the ASL. It seems that no ... :( In fact, enabling the printer port in the bios, as you requested in another post, have the nice side effect to silence the "can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA" warning. I have now anyway: full suspend / resume with acpi, and routed interrupts so I can now use my embedded wi card, those are two big steps forward. Thanks to all for this ! - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815
Your patches seem to fix three things:
1) Implicit returns
2) Invalid escape sequences (missing double backslashes)
3) Uninitialized Locals
Which one was causing the original problem as reported?
Thanks,
Bob
-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 28, 2002 3:36 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815
> 1) Fix the ASL so that it compiles without errors or warnings
> 2) Override the BIOS version of the table with your new one. (I don't
know
> how this is done on FreeBSD, someone else will have to help you.
Attached patches will fix the ASL.
For compiling and overriding, please refer to acpi(4).
# iasl Tecra8200.asl
# cp acpi_dsdt.aml /boot/
# echo 'acpi_dsdt_load="YES"' >> /boot/loader.conf
Thanks
--- Tecra8200.asl- Wed Aug 28 19:30:30 2002
+++ Tecra8200.asl Wed Aug 28 19:26:57 2002
@@ -79,11 +79,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x1)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQA)
+Return(STAL(\_SB_.PCI0.FNC0.IRQA))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQA)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQA))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQA, Local0)
@@ -108,11 +108,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x2)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQB)
+Return(STAL(\_SB_.PCI0.FNC0.IRQB))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQB)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQB))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQB, Local0)
@@ -137,11 +137,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x3)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQC)
+Return(STAL(\_SB_.PCI0.FNC0.IRQC))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQC)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQC))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQC, Local0)
@@ -166,11 +166,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x4)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQD)
+Return(STAL(\_SB_.PCI0.FNC0.IRQD))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQD)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQD))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQD, Local0)
@@ -195,11 +195,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x5)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQE)
+Return(STAL(\_SB_.PCI0.FNC0.IRQE))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQE)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQE))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQE, Local0)
@@ -224,11 +224,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x8)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQH)
+Return(STAL(\_SB_.PCI0.FNC0.IRQH))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQH)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQH))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQH, Local0)
@@ -253,7 +253,7 @@
Name(_HID, 0x010cd041)
Name(_STA, 0xf)
Method(_CRS) {
-CRS_(0x1)
+Return(CRS_(0x1))
}
OperationRegion(SRAM, SystemMemory, 0x000ee800, 0x1800)
Field(SRAM, AnyAcc, NoLock, Preserve) {
@@ -944,13 +944,13 @@
Name(_HID, 0x000ed041)
Name(_UID, 0x2)
Method(_STA) {
-STA_(0x25)
+Return(STA_(0x25))
}
Method(_CRS) {
-CRS_(0x25)
+Return(CRS_(0x25))
}
Method(_PRS) {
-PRS_(0x25)
+Return(PRS_(0x25))
}
Method(_SRS, 1) {
SRS_(0x25, Arg0)
@@ -965,7 +965,7 @@
PS3_(0x25)
}
Method(_PSC) {
-PSC_(0x25)
+Return(PSC_(0x25))
}
Name(_PRW, Package(0x2) {
0xb,
@@
Re: [acpi-jp 1745] Re: Call for testers: acpica-unix-20020815
>Thanks a lot. I must apologize though, I had the same error with >previous versions of acpi (I should have checked, sorry, I confounded >2 laptops) This is very important fact for me! OK, I'll import 20020815 version today. BTW, Could you check your BIOS setting and see if printer port is disabled? And if so, how about enabling printer port? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1753] RE: Call for testers: acpica-unix-20020815
> 1) Fix the ASL so that it compiles without errors or warnings
> 2) Override the BIOS version of the table with your new one. (I don't know
> how this is done on FreeBSD, someone else will have to help you.
Attached patches will fix the ASL.
For compiling and overriding, please refer to acpi(4).
# iasl Tecra8200.asl
# cp acpi_dsdt.aml /boot/
# echo 'acpi_dsdt_load="YES"' >> /boot/loader.conf
Thanks
--- Tecra8200.asl- Wed Aug 28 19:30:30 2002
+++ Tecra8200.asl Wed Aug 28 19:26:57 2002
@@ -79,11 +79,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x1)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQA)
+Return(STAL(\_SB_.PCI0.FNC0.IRQA))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQA)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQA))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQA, Local0)
@@ -108,11 +108,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x2)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQB)
+Return(STAL(\_SB_.PCI0.FNC0.IRQB))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQB)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQB))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQB, Local0)
@@ -137,11 +137,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x3)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQC)
+Return(STAL(\_SB_.PCI0.FNC0.IRQC))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQC)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQC))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQC, Local0)
@@ -166,11 +166,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x4)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQD)
+Return(STAL(\_SB_.PCI0.FNC0.IRQD))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQD)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQD))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQD, Local0)
@@ -195,11 +195,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x5)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQE)
+Return(STAL(\_SB_.PCI0.FNC0.IRQE))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQE)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQE))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQE, Local0)
@@ -224,11 +224,11 @@
Name(_HID, 0x0f0cd041)
Name(_UID, 0x8)
Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQH)
+Return(STAL(\_SB_.PCI0.FNC0.IRQH))
}
Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQH)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQH))
}
Method(_DIS) {
Store(\_SB_.PCI0.FNC0.IRQH, Local0)
@@ -253,7 +253,7 @@
Name(_HID, 0x010cd041)
Name(_STA, 0xf)
Method(_CRS) {
-CRS_(0x1)
+Return(CRS_(0x1))
}
OperationRegion(SRAM, SystemMemory, 0x000ee800, 0x1800)
Field(SRAM, AnyAcc, NoLock, Preserve) {
@@ -944,13 +944,13 @@
Name(_HID, 0x000ed041)
Name(_UID, 0x2)
Method(_STA) {
-STA_(0x25)
+Return(STA_(0x25))
}
Method(_CRS) {
-CRS_(0x25)
+Return(CRS_(0x25))
}
Method(_PRS) {
-PRS_(0x25)
+Return(PRS_(0x25))
}
Method(_SRS, 1) {
SRS_(0x25, Arg0)
@@ -965,7 +965,7 @@
PS3_(0x25)
}
Method(_PSC) {
-PSC_(0x25)
+Return(PSC_(0x25))
}
Name(_PRW, Package(0x2) {
0xb,
@@ -982,7 +982,7 @@
Device(VDSC) {
Name(_HID, 0x1001a865)
Method(_STA) {
-STA_(0x26)
+Return(STA_(0x26))
}
}
PowerResource(PDOC, 1, 0) {
@@ -1006,7 +1006,7 @@
Event(DKSQ)
Device(DLAN) {
Name(_ADR, 0x000a)
-Name(_EJD, "\_SB_.PCI0.PCIB.DOCK")
+Name(_EJD, "_SB_.PCI0.PCI
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Thus spake Terry Lambert <[EMAIL PROTECTED]>: > > Sometimes. But see http://www.tuxedo.org/~esr/jargon/html/entry/DWIM.html > > I understand, but having a different failure is no worse than > having a failure, I think. In either case, it doesn't work, > even if it doesn't work in an entirely different way. 'delete *' is a *whole lot* worse than `delete: File not found'. (You get the latter either way, actually. :-) There's always a danger in having too much magic. It's okay when the magic does something right part of the time and fizzles out the rest of the time. But when it does something terribly wrong, you have to question the tradeoff. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
David Schultz wrote: > > So the worst possible outcome in the failure case is that it > > fails -- which it already does, without the assumption -- and > > the best possible outcome is that it succeeds when it wouldn't > > have. > > > > "Anything that works is better than anything that doesn't" > > Sometimes. But see http://www.tuxedo.org/~esr/jargon/html/entry/DWIM.html I understand, but having a different failure is no worse than having a failure, I think. In either case, it doesn't work, even if it doesn't work in an entirely different way. | Everyone knows that dragons don't exist. But while this simplistic | formulation may satisfy the layman, it does not suffice for the | scientific mind. The School of Higher Neantical Nillity is in fact | wholly unconcerned with what does exist. Indeed, the banality of | existence has been so amply demonstrated, there is no need for us to | discuss it any further here. The brilliant Cerebron, attacking the | problem analytically, discovered three distinct kinds of dragon: the | mythical, the chimerical, and the purely hypothetical. They were all, | one might say, nonexistent, but each nonexisted in an entirely | different way ... | -- Stanislaw Lem, "Cyberiad" 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Thus spake Terry Lambert <[EMAIL PROTECTED]>: > FWIW, there's historical precedent for this: the DEC VAX/VMS > C compiler would imply semicolons for the programmer that > forgot them, and a couple of other similar "fixups", issue a > warning, but the resulting code would run "as the programmer > most likely intended", rather than not generating a running > program at all. > > The issue here is one of syntactical vs. grammatical ambiguity; > if the only choices are between two possible outcomes, and one > of them is a failure to operate at all, while the other is to > operate, but potentially incorrectly. The upshot is that ir > can't hurt, and it might help: > > assumption? > no yes > - > grammar error | FAILS | FAILS | > | > syntax error | FAILS | WORKS | > - > > So the worst possible outcome in the failure case is that it > fails -- which it already does, without the assumption -- and > the best possible outcome is that it succeeds when it wouldn't > have. > > "Anything that works is better than anything that doesn't" Sometimes. But see http://www.tuxedo.org/~esr/jargon/html/entry/DWIM.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1744] RE: Call for testers: acpica-unix-20020815
Hi,
> This looks like the (in)famous "implicit return" problem that is in some
> Toshiba ASL files.
>
> Method(_CRS) {
> CRS_(0x10)
> }
No, this is not "implicit return" problem. We have a workaround in
ACPI CA code in FreeBSD locally, and it is functioning properly even
now (checked on my Toshiba PORTEGE 3110CT).
Real problem is;
>rsirq-0234 [15] RsIrqResource : Invalid interrupt polarity/trigger in
>resource list
> can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA
I guess that
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
this buffer value causes AE_BAD_DATA error in RsIrqResource() ?
Or
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
wrong value came from from _SB_.MEM_.PAR3 or _SB_.MEM_.PRES ?
I'll track this down...
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
> From: Moore, Robert [mailto:[EMAIL PROTECTED]]
> 1) Fix the ASL so that it compiles without errors or warnings
> 2) Override the BIOS version of the table with your new one.
> (I don't know
> how this is done on FreeBSD, someone else will have to help you.
ISTR someone (Iwasaki-san?) had a patch that applied against our code to
workaround this problem. While we won't accept that patch into our release,
why can't you keep using it? Then, we get to keep the moral high ground and
you get fewer problems.
Regards -- Andy
>
> Bob
>
>
> -Original Message-
> From: Yann Berthier [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 27, 2002 3:19 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
>
> On Tue, 27 Aug 2002, Moore, Robert wrote:
>
> >
> > This looks like the (in)famous "implicit return" problem
> that is in some
> > Toshiba ASL files.
> >
> > Method(_CRS) {
> > CRS_(0x10)
> > }
> >
> > This does NOT actually return a value and the ASL code is
> incorrect. It
> has
> > to be:
> >
> > Method(_CRS) {
> > Return (CRS_(0x10))
> > }
> >
> > The iASL compiler generates warnings for all instances of
> this erroneous
> > code.
>
>Thanks a lot for your input. What is the best way for me to verify
>this ?
>
>- yann
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
1) Fix the ASL so that it compiles without errors or warnings
2) Override the BIOS version of the table with your new one. (I don't know
how this is done on FreeBSD, someone else will have to help you.
Bob
-Original Message-
From: Yann Berthier [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:19 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815
On Tue, 27 Aug 2002, Moore, Robert wrote:
>
> This looks like the (in)famous "implicit return" problem that is in some
> Toshiba ASL files.
>
> Method(_CRS) {
> CRS_(0x10)
> }
>
> This does NOT actually return a value and the ASL code is incorrect. It
has
> to be:
>
> Method(_CRS) {
> Return (CRS_(0x10))
> }
>
> The iASL compiler generates warnings for all instances of this erroneous
> code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
We have to look at each of these on a case-by-case basis. It turns out that it is purely an accident that the code works on windows; by some fluke of their AML interpreter, the value gets returned. Because of architectural differences, the CA interpreter deletes everything that isn't needed before the method returns -- and therefore any "implied" return object is long gone by the time the method exits. Toshiba knows about this problem and has agreed to fix it in it's various BIOSs Bob -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 3:40 PM To: Moore, Robert Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Grover, Andrew Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815 "Moore, Robert" wrote: > I think you are missing something: > > 1) BIOS vendor writes ASL > 2) BIOS vendor compiles ASL to AML byte-code > 3) BIOS vendor puts AML into BIOS > 4) OS gets AML from the BIOS > 5) OS interprets AML > > The error you are experiencing is in (5). There is no return statement in > the original ASL, so there is no return opcode in the AML. The AML > interpreter has nothing to "return" and things fall apart. > > However, the error was written in (1) and should have been caught by the ASL > compiler in (2). However, there are other ASL compilers out there that do > not perform such error-checking. This is how these kinds of problems creep > into the BIOS AML code. As a consumer of 1-3, I have zero opportunity to fix the problem before item #4. Since use of a trademark or other legal baseball bat (8-)) won't get the code in the BIOS fixed, the only way to make things work in the short term is to either intervene in step #4 or in step #5. In the long term, it'd probably be a good idea to release the source code for the ASL-to-AML compiler under a strict license, and displace all the ASL compilers that fail to do error checking, so problems like this can't arise in the first place. I guess I would like to know if the AML can be recognized as defective by the interpreter, and modify it at step #4 before interning it for interpretation; Windows has to have *some* way of dealing with this, short of supplying replacement AML for every PC ever manufacturered, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
"Moore, Robert" wrote: > I think you are missing something: > > 1) BIOS vendor writes ASL > 2) BIOS vendor compiles ASL to AML byte-code > 3) BIOS vendor puts AML into BIOS > 4) OS gets AML from the BIOS > 5) OS interprets AML > > The error you are experiencing is in (5). There is no return statement in > the original ASL, so there is no return opcode in the AML. The AML > interpreter has nothing to "return" and things fall apart. > > However, the error was written in (1) and should have been caught by the ASL > compiler in (2). However, there are other ASL compilers out there that do > not perform such error-checking. This is how these kinds of problems creep > into the BIOS AML code. As a consumer of 1-3, I have zero opportunity to fix the problem before item #4. Since use of a trademark or other legal baseball bat (8-)) won't get the code in the BIOS fixed, the only way to make things work in the short term is to either intervene in step #4 or in step #5. In the long term, it'd probably be a good idea to release the source code for the ASL-to-AML compiler under a strict license, and displace all the ASL compilers that fail to do error checking, so problems like this can't arise in the first place. I guess I would like to know if the AML can be recognized as defective by the interpreter, and modify it at step #4 before interning it for interpretation; Windows has to have *some* way of dealing with this, short of supplying replacement AML for every PC ever manufacturered, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
On Tue, 27 Aug 2002, Moore, Robert wrote:
>
> This looks like the (in)famous "implicit return" problem that is in some
> Toshiba ASL files.
>
> Method(_CRS) {
> CRS_(0x10)
> }
>
> This does NOT actually return a value and the ASL code is incorrect. It has
> to be:
>
> Method(_CRS) {
> Return (CRS_(0x10))
> }
>
> The iASL compiler generates warnings for all instances of this erroneous
> code.
Thanks a lot for your input. What is the best way for me to verify
this ?
- yann
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
I think you are missing something: 1) BIOS vendor writes ASL 2) BIOS vendor compiles ASL to AML byte-code 3) BIOS vendor puts AML into BIOS 4) OS gets AML from the BIOS 5) OS interprets AML The error you are experiencing is in (5). There is no return statement in the original ASL, so there is no return opcode in the AML. The AML interpreter has nothing to "return" and things fall apart. However, the error was written in (1) and should have been caught by the ASL compiler in (2). However, there are other ASL compilers out there that do not perform such error-checking. This is how these kinds of problems creep into the BIOS AML code. Bob -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 2:54 PM To: Moore, Robert Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Grover, Andrew Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815 "Moore, Robert" wrote: > Well, the *real* problem is that there is no Return AML opcode in the > control method and the interpreter therefore does not return a value. > > However, to answer your question with a question: > > Would you ask a C compiler, or any other compiler for that matter, to > actually *GUESS* at what you had intended to be the return value of a > function? Is this a trick question? If I had to write my source code to read-only media, with no way to tell whose compiler was going to be used on it, and had no way to fix it afterwards, I think the answer would have to be "yes". 8-) 8-). FWIW, there's historical precedent for this: the DEC VAX/VMS C compiler would imply semicolons for the programmer that forgot them, and a couple of other similar "fixups", issue a warning, but the resulting code would run "as the programmer most likely intended", rather than not generating a running program at all. The issue here is one of syntactical vs. grammatical ambiguity; if the only choices are between two possible outcomes, and one of them is a failure to operate at all, while the other is to operate, but potentially incorrectly. The upshot is that ir can't hurt, and it might help: assumption? no yes - grammar error | FAILS | FAILS | | syntax error| FAILS | WORKS | - So the worst possible outcome in the failure case is that it fails -- which it already does, without the assumption -- and the best possible outcome is that it succeeds when it wouldn't have. "Anything that works is better than anything that doesn't" -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
"Moore, Robert" wrote: > Well, the *real* problem is that there is no Return AML opcode in the > control method and the interpreter therefore does not return a value. > > However, to answer your question with a question: > > Would you ask a C compiler, or any other compiler for that matter, to > actually *GUESS* at what you had intended to be the return value of a > function? Is this a trick question? If I had to write my source code to read-only media, with no way to tell whose compiler was going to be used on it, and had no way to fix it afterwards, I think the answer would have to be "yes". 8-) 8-). FWIW, there's historical precedent for this: the DEC VAX/VMS C compiler would imply semicolons for the programmer that forgot them, and a couple of other similar "fixups", issue a warning, but the resulting code would run "as the programmer most likely intended", rather than not generating a running program at all. The issue here is one of syntactical vs. grammatical ambiguity; if the only choices are between two possible outcomes, and one of them is a failure to operate at all, while the other is to operate, but potentially incorrectly. The upshot is that ir can't hurt, and it might help: assumption? no yes - grammar error | FAILS | FAILS | | syntax error| FAILS | WORKS | - So the worst possible outcome in the failure case is that it fails -- which it already does, without the assumption -- and the best possible outcome is that it succeeds when it wouldn't have. "Anything that works is better than anything that doesn't" -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Well, the *real* problem is that there is no Return AML opcode in the
control method and the interpreter therefore does not return a value.
However, to answer your question with a question:
Would you ask a C compiler, or any other compiler for that matter, to
actually *GUESS* at what you had intended to be the return value of a
function?
Bob
-Original Message-
From: Terry Lambert [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 2:05 PM
To: Moore, Robert
Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
"Moore, Robert" wrote:
> This looks like the (in)famous "implicit return" problem that is in some
> Toshiba ASL files.
>
> Method(_CRS) {
> CRS_(0x10)
> }
>
> This does NOT actually return a value and the ASL code is incorrect. It
has
> to be:
>
> Method(_CRS) {
> Return (CRS_(0x10))
> }
>
> The iASL compiler generates warnings for all instances of this erroneous
> code.
Is there any way to add a "-s" for "strict" option to the iASL compiler,
in which it generates warnings for this code... but in the absence
of the option, simply pretends it saw the "Return", since it knows
that that's the problem anyway, and is just being bitchy by warning
about it instead of warning, but also taking the appropriate corrective
action for this case?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
"Moore, Robert" wrote:
> This looks like the (in)famous "implicit return" problem that is in some
> Toshiba ASL files.
>
> Method(_CRS) {
> CRS_(0x10)
> }
>
> This does NOT actually return a value and the ASL code is incorrect. It has
> to be:
>
> Method(_CRS) {
> Return (CRS_(0x10))
> }
>
> The iASL compiler generates warnings for all instances of this erroneous
> code.
Is there any way to add a "-s" for "strict" option to the iASL compiler,
in which it generates warnings for this code... but in the absence
of the option, simply pretends it saw the "Return", since it knows
that that's the problem anyway, and is just being bitchy by warning
about it instead of warning, but also taking the appropriate corrective
action for this case?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
On Tue, 27 Aug 2002, Mitsuru IWASAKI wrote: > Hi, > > Could you put the following lines into /boot/loader.conf and send > dmesg output again? > > debug.acpi.layer="ACPI_ALL_COMPONENTS" > debug.acpi.level="ACPI_LV_ERROR" > Of course, here we go :) > >[sent privately to not spam the lists with my dump files] > > > > On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote: > > > > > >FYI, I have now a "can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - > > > >AE_BAD_DATA" with acpica-unix-20020815 during boot. > > > > > > I'd like to make sure if AE_BAD_DATA error occurred w/ previous > > > versions (acpica-unix-20020725, 20020611, 20020404...) ? > > > Or first time w/ acpica-unix-20020815 ? > > > >This error did not happened with previous versions of acpi > > Hmmm... OK, I put your full ASL at: > >http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=freebsd-jp Thanks a lot. I must apologize though, I had the same error with previous versions of acpi (I should have checked, sorry, I confounded 2 laptops) Thanks, - yann Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #29: Tue Aug 27 21:35:25 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TAZ Preloaded elf kernel "/boot/kernel/kernel" at 0xc06a7000. Preloaded elf module "/boot/kernel/usb.ko" at 0xc06a70a8. Preloaded elf module "/boot/kernel/ums.ko" at 0xc06a7150. Preloaded elf module "/boot/kernel/vga_pci.ko" at 0xc06a71f8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06a72a4. ACPI_DEBUG: set 'ACPI_ALL_COMPONENTS' ACPI_DEBUG: set 'ACPI_LV_ERROR' ACPI debug layer 0xfff debug level 0x8 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 847427840 Hz CPU: Pentium III/Pentium III Xeon/Celeron (847.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 267780096 (261504K bytes) avail memory = 252694528 (246772K bytes) Pentium Pro MTRR support enabled netsmb_dev: loaded Using $PIR table, 9 entries at 0xc00f0300 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_tz0: on acpi0 pcib1: port 0xcf8-0xcff on acpi0 pci0: on pcib1 pcib2: at device 1.0 on pci0 pci1: on pcib2 vga_pci0: mem 0xf7ff8000-0xf7ff,0xf800-0xf9ff,0xfbc0-0xfbff,0xfc00-0xfdff irq 11 at device 0.0 on pci1 pcib3: at device 30.0 on pci0 pci2: on pcib3 pcm0: port 0xdf3c-0xdf3f,0xdf40-0xdf7f mem 0xf7df8000-0xf7df irq 11 at device 7.0 on pci2 fxp0: port 0xdec0-0xdeff mem 0xf7df7000-0xf7df7fff irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:00:39:ee:60:38 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: device is routed to IRQ 11 pcic0: irq 11 at device 12.0 on pci2 pcic0: PCI Memory allocated: 0xf7d0 pcic0: TI12XX PCI Config Reg: [pwr save][pci only] pccard0: on pcic0 pcic1: irq 11 at device 13.0 on pci2 pcic1: PCI Memory allocated: 0xf7d01000 pccard1: on pcic1 pcic2: irq 11 at device 13.1 on pci2 pcic2: PCI Memory allocated: 0xf7d02000 pccard2: on pcic2 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xcff0-0xcfff at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xcf80-0xcf9f irq 11 at device 31.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: port 0xcf60-0xcf7f irq 11 at device 31.4 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 31.6 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A rsirq-0234 [15] RsIrqResource : Invalid interrupt polarity/trigger in resource list can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - AE_BAD_DATA ppc0: parallel port not found. acpi_lid0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_acad0: on acpi0 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xee08-0xee0b on acpi0 ppc0: parallel port not found. ppc0: parallel port not found. orm0: at iomem 0xe-0xe,0xc-0xcbfff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0:
RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
This looks like the (in)famous "implicit return" problem that is in some
Toshiba ASL files.
Method(_CRS) {
CRS_(0x10)
}
This does NOT actually return a value and the ASL code is incorrect. It has
to be:
Method(_CRS) {
Return (CRS_(0x10))
}
The iASL compiler generates warnings for all instances of this erroneous
code.
Bob
-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 27, 2002 3:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Hi,
Could you put the following lines into /boot/loader.conf and send
dmesg output again?
debug.acpi.layer="ACPI_ALL_COMPONENTS"
debug.acpi.level="ACPI_LV_ERROR"
>[sent privately to not spam the lists with my dump files]
>
> On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote:
>
> > >FYI, I have now a "can't fetch resources for \\_SB_.PCI0.FNC0.PRT_
-
> > >AE_BAD_DATA" with acpica-unix-20020815 during boot.
> >
> > I'd like to make sure if AE_BAD_DATA error occurred w/ previous
> > versions (acpica-unix-20020725, 20020611, 20020404...) ?
> > Or first time w/ acpica-unix-20020815 ?
>
>This error did not happened with previous versions of acpi
Hmmm... OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1&con
tent-type=text/x-cvsweb-markup&cvsroot=freebsd-jp
It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}
Intel folks, any ideas?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
Hi,
Could you put the following lines into /boot/loader.conf and send
dmesg output again?
debug.acpi.layer="ACPI_ALL_COMPONENTS"
debug.acpi.level="ACPI_LV_ERROR"
>[sent privately to not spam the lists with my dump files]
>
> On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote:
>
> > >FYI, I have now a "can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ -
> > >AE_BAD_DATA" with acpica-unix-20020815 during boot.
> >
> > I'd like to make sure if AE_BAD_DATA error occurred w/ previous
> > versions (acpica-unix-20020725, 20020611, 20020404...) ?
> > Or first time w/ acpica-unix-20020815 ?
>
>This error did not happened with previous versions of acpi
Hmmm... OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=freebsd-jp
It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}
Intel folks, any ideas?
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
Hi, > On Mon, Aug 26, 2002 at 10:32:58PM +0900, Mitsuru IWASAKI wrote: > > Any volunteers to solve this problem? > > Well yes, me. > > Like I said, I don't have experience with ACPI yet, but basicly I need to > get this working so that makes me a good candidate ;) Thanks, very cool! > Am I correct in stating that I should extend your vga_pci driver to do the > correct actions on suspend/resume or are there also other places that need > changes? For starting, I think just extending vga_pci would be OK. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
On Mon, Aug 26, 2002 at 10:32:58PM +0900, Mitsuru IWASAKI wrote: > Any volunteers to solve this problem? Well yes, me. Like I said, I don't have experience with ACPI yet, but basicly I need to get this working so that makes me a good candidate ;) I just registered myself as a developer on ati.com hoping to get some specs out of them. Especially regarding pm. Also did I start reading the ACPI specs. You mentioned earlier that the problem was probably that the graphics chip needs to be re-initialized at wakeup. That doesn't seem a correct description of the solution however as the screen doesn't even go out at the moment of suspending, so something is already wrong at that point. Am I correct in stating that I should extend your vga_pci driver to do the correct actions on suspend/resume or are there also other places that need changes? All help appreciated, thanks! Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
> One other note: > > At boot time the VGA is reported as: > Aug 25 21:15:20 laptop kernel: vga0: at port 0x3c0-0x3df iomem >0xa-0xb on isa0 > > And when I load your module: > Aug 25 21:12:44 laptop kernel: vga_pci0: port 0xc000-0xc0ff mem >0xfcff-0xfcff,0xe000-0xe7ff irq 11 at device 0.0 on pci1 > > In other words, is it a problem that it is already configured as an ISA > device or is that normal? It's normal. My vga_pci driver only provide suspend/resume methods so that kernel manipulate PCI power state for VGA device. Usually do nothing. > > If this don't solve your problem, I think graphic chip need to be > > re-initialized on wakeup. Maybe needs time... > > Ah, that makes sense. I was searching through the acpi documentation and > couldn't find anything about displays actually. So this is fully > controlled by the graphics controller? > > > Some VAIO machines (w/ ATI graphic chip), also have the same problem. > > I also have an ATI chip. ATI Radeon to be precise, is that a possible > explanation? Yes, I think so too. Any volunteers to solve this problem? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815
>FYI, I have now a "can't fetch resources for \\_SB_.PCI0.FNC0.PRT_ - >AE_BAD_DATA" with acpica-unix-20020815 during boot. I'd like to make sure if AE_BAD_DATA error occurred w/ previous versions (acpica-unix-20020725, 20020611, 20020404...) ? Or first time w/ acpica-unix-20020815 ? Anyway, I didn't receive serious problem reports of degrade so far, will do importing tomorrow. >I have not yet correct battery info either. > >Laptop : Toshiba Tecra 8200, dmeg attached. I can provide more info >if needed :) Please send me acpidump output (DSDT and ASL file): # acpidump -o Tecra8200.dsdt > Tecra8200.asl I'll put them to our CVS repo. in Japan as test data. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
Mark Santcroos wrote: > The problem is actually a bit weird. When I suspend (close the lid or with > the key combo) the display is not turned off actually. It does go in some > form of suspend however. When I resume, the machine comes back to life > again, but the screen goes off at that moment. ... > I also have an ATI chip. ATI Radeon to be precise, is that a possible > explanation? I see the same issue you describe here on a Dell Latitude C600 with an ATI Rage Mobility M3, too. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Call for testers: acpica-unix-20020815
Hello, I applied the patch, and nothing changed, so it works :) What tools do you use to check battery state? Any links on userland tools for monitoring / controling the ACPI (other than acpiconf) ? On my laptop, power switch, lid switch and stuff like that show up under boot-up, but they do not work. Is there a default behaviour, or do I need a userland tool to configure what should happen? (VIA PN133 chipset) I also see CPU throttling show up on boot-up (a total of 16 steps, wow). When I unplug the power, "system profile" changes from power to economy. Is it possible to do any more fine-grained control of this? Anyone know what the status is on the disk spindown patch (ATA)? I saw some references to a old patch for this somewhere, and that Søren had some things he could commit, when he got the time :) My desktop computer automaticly shuts down whenever I hit the power button, so I guess it works there, but not on my laptop :( Is there a updated homepage for the ACPI project somewhere? I think the ACPI implementation for FreeBSD rocks, but it has a long way to go before it's perfect. So I would love to help out. Mvh, Frode On Thu, 2002-08-22 at 16:51, Mitsuru IWASAKI wrote: > I'm going to import Intel acpica-unix-20020815 sometime early next > week. Please test new version of acpica and give feedback before my > importing. > Major fix in this version is Ref/Deref operators bug fix. > Personally I'm very happy with the new version because > now my laptop (FIVA 206VL) reports correct battery info. :-) > > The full change log: > http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt > > The patches against CURRENT sys tree are available at: > http://people.freebsd.org/~iwasaki/acpi/acpica-20020725-20020815-test20020822.diff > > Please note that any feedback should be sent to [EMAIL PROTECTED] > > Enjoy! > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
On Mon, Aug 26, 2002 at 03:01:48AM +0900, Mitsuru IWASAKI wrote: > How about this one? > http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz > > This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. This didn't work unfortunately. The problem is actually a bit weird. When I suspend (close the lid or with the key combo) the display is not turned off actually. It does go in some form of suspend however. When I resume, the machine comes back to life again, but the screen goes off at that moment. One other note: At boot time the VGA is reported as: Aug 25 21:15:20 laptop kernel: vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 And when I load your module: Aug 25 21:12:44 laptop kernel: vga_pci0: port 0xc000-0xc0ff mem 0xfcff-0xfcff,0xe000-0xe7ff irq 11 at device 0.0 on pci1 In other words, is it a problem that it is already configured as an ISA device or is that normal? > If this don't solve your problem, I think graphic chip need to be > re-initialized on wakeup. Maybe needs time... Ah, that makes sense. I was searching through the acpi documentation and couldn't find anything about displays actually. So this is fully controlled by the graphics controller? > Some VAIO machines (w/ ATI graphic chip), also have the same problem. I also have an ATI chip. ATI Radeon to be precise, is that a possible explanation? Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote: > > > > I have a Dell Latitude C640 and my screen won't come back after a suspend. > > > > The machine works fine besides that. > > > > > > OK, I think this is not related with ACPI CA code update. > > > > If that was not clear, it also didn't work before. > > understood. I meant that ACPI CA code changes won't > solve the individual device problems in many cases. > > > > If you have this problem w/ X running, and don't have w/o X, > > > please try attached patches. > > > > It's unrelated to X. > > > > Other ideas? > > How about this one? > http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz > > This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. It seems to solve the acpi resume on my laptop (Toshiba Tecra 8200) Thanks, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
> iwasaki> Index: isa/syscons_isa.c > iwasaki> === > iwasaki> RCS file: /home/ncvs/src/sys/isa/syscons_isa.c,v > iwasaki> retrieving revision 1.17 > iwasaki> diff -u -r1.17 syscons_isa.c > iwasaki> --- isa/syscons_isa.c30 Jun 2001 10:15:06 - 1.17 > iwasaki> +++ isa/syscons_isa.c16 Feb 2002 13:11:50 - > > I need this patch to do suspend/resume my laptop (Victor InterLink > XP). This patch is also required for FIVA. OK, commited. > It may better to have kernel option or sysctl to enable/disable this > function. I think this has no side effect but if I get any reports, I'll consider the option. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
Hi,
>>> Mon, 26 Aug 2002 02:37:36 +0900 (JST),
>>> Mitsuru IWASAKI <[EMAIL PROTECTED]> said:
iwasaki> If you have this problem w/ X running, and don't have w/o X,
iwasaki> please try attached patches.
iwasaki> Index: isa/syscons_isa.c
iwasaki> ===
iwasaki> RCS file: /home/ncvs/src/sys/isa/syscons_isa.c,v
iwasaki> retrieving revision 1.17
iwasaki> diff -u -r1.17 syscons_isa.c
iwasaki> --- isa/syscons_isa.c 30 Jun 2001 10:15:06 - 1.17
iwasaki> +++ isa/syscons_isa.c 16 Feb 2002 13:11:50 -
I need this patch to do suspend/resume my laptop (Victor InterLink
XP). This patch is also required for FIVA.
It may better to have kernel option or sysctl to enable/disable this
function.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
> > > I have a Dell Latitude C640 and my screen won't come back after a suspend. > > > The machine works fine besides that. > > > > OK, I think this is not related with ACPI CA code update. > > If that was not clear, it also didn't work before. understood. I meant that ACPI CA code changes won't solve the individual device problems in many cases. > > If you have this problem w/ X running, and don't have w/o X, > > please try attached patches. > > It's unrelated to X. > > Other ideas? How about this one? http://people.freebsd.org/~iwasaki/acpi/vga_pci-20020228.tar.gz This simply set PCI_POWERSTATE_D0 for VGA device on wakeup. If this don't solve your problem, I think graphic chip need to be re-initialized on wakeup. Maybe needs time... Some VAIO machines (w/ ATI graphic chip), also have the same problem. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
On Mon, Aug 26, 2002 at 02:37:36AM +0900, Mitsuru IWASAKI wrote: > > I applied the patches, and I still have the same results on my laptop. > > > > I have a Dell Latitude C640 and my screen won't come back after a suspend. > > The machine works fine besides that. > > OK, I think this is not related with ACPI CA code update. If that was not clear, it also didn't work before. > Our device driver (maybe syscons?) or X server issue. > > > Do you have any idea/advice how this can be debugged? > > If you have this problem w/ X running, and don't have w/o X, > please try attached patches. It's unrelated to X. Other ideas? Thanks for your help. I'm new to ACPI. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
> I applied the patches, and I still have the same results on my laptop.
>
> I have a Dell Latitude C640 and my screen won't come back after a suspend.
> The machine works fine besides that.
OK, I think this is not related with ACPI CA code update.
Our device driver (maybe syscons?) or X server issue.
> Do you have any idea/advice how this can be debugged?
If you have this problem w/ X running, and don't have w/o X,
please try attached patches.
Thanks
Index: isa/syscons_isa.c
===
RCS file: /home/ncvs/src/sys/isa/syscons_isa.c,v
retrieving revision 1.17
diff -u -r1.17 syscons_isa.c
--- isa/syscons_isa.c 30 Jun 2001 10:15:06 - 1.17
+++ isa/syscons_isa.c 16 Feb 2002 13:11:50 -
@@ -88,6 +88,39 @@
return sc_attach_unit(device_get_unit(dev), device_get_flags(dev));
}
+static int sc_cur_scr;
+
+static int
+scsuspend(device_t dev)
+{
+ int retry = 10;
+ static int dummy;
+ sc_softc_t *sc;
+
+ sc = &main_softc;
+ sc_cur_scr = sc->cur_scp->index;
+ do {
+ sc_switch_scr(sc, 0);
+ if (!sc->switch_in_progress) {
+ break;
+ }
+ tsleep(&dummy, 0, "scsuspend", 100);
+ } while (retry--);
+
+ return (0);
+}
+
+static int
+scresume(device_t dev)
+{
+ sc_softc_t *sc;
+
+ sc = &main_softc;
+ sc_switch_scr(sc, sc_cur_scr);
+
+ return (0);
+}
+
int
sc_max_unit(void)
{
@@ -230,6 +263,8 @@
DEVMETHOD(device_identify, scidentify),
DEVMETHOD(device_probe, scprobe),
DEVMETHOD(device_attach,scattach),
+ DEVMETHOD(device_suspend, scsuspend),
+ DEVMETHOD(device_resume,scresume),
{ 0, 0 }
};
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Call for testers: acpica-unix-20020815
Hi Mitsuru, I applied the patches, and I still have the same results on my laptop. I have a Dell Latitude C640 and my screen won't come back after a suspend. The machine works fine besides that. Do you have any idea/advice how this can be debugged? Thanks Mark On Thu, Aug 22, 2002 at 11:51:42PM +0900, Mitsuru IWASAKI wrote: > I'm going to import Intel acpica-unix-20020815 sometime early next > week. Please test new version of acpica and give feedback before my > importing. > Major fix in this version is Ref/Deref operators bug fix. > Personally I'm very happy with the new version because > now my laptop (FIVA 206VL) reports correct battery info. :-) > > The full change log: > http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt > > The patches against CURRENT sys tree are available at: > http://people.freebsd.org/~iwasaki/acpi/acpica-20020725-20020815-test20020822.diff > > Please note that any feedback should be sent to [EMAIL PROTECTED] > > Enjoy! > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Call for testers: acpica-unix-20020815
I'm going to import Intel acpica-unix-20020815 sometime early next week. Please test new version of acpica and give feedback before my importing. Major fix in this version is Ref/Deref operators bug fix. Personally I'm very happy with the new version because now my laptop (FIVA 206VL) reports correct battery info. :-) The full change log: http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt The patches against CURRENT sys tree are available at: http://people.freebsd.org/~iwasaki/acpi/acpica-20020725-20020815-test20020822.diff Please note that any feedback should be sent to [EMAIL PROTECTED] Enjoy! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
