Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: I know several local guys with exactly the same bug (some time ago I've convinced some them to swith to -current and test/report any problems) and it is very sad to see my efforts vanished, especially considering that the source of the problem is located and as you said it is a trivial one. FWIW, trivial usually refers to the complexity of the problem, not the amount of work required to fix it (if it's trivial, then that means the work to fix it is grunt work, i.e. it is not intellectually challenging, and therefore not attractive to work on or spend your effort on). The other use of trivial is concerned with trivia; it means that while the problem is known, so is the workaround, and so it is not a critical problem, just an annoying one. The most commonly cited workaround for this case is to delete or rename acpi.ko to prevent it being loaded. The first definition is the one used by mathematicians; the second one is used by the other sciences to describe things like the value of the constant of integration, when all they are concerned with is a line fit for the curve (i.e. set it to whatever displaces the curve sufficiently for it to fit the data). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1371] Re: ACPI: problem with fdc resource allocation
# Congratulations, Maxim! On Thu, Oct 25, 2001 at 05:13:56PM +0300, Maxim Sobolev wrote: 6. And finally I've put back corrected ACPI table back into BIOS image using CBROM.EXE, flashed resulting BIOS image and voila - the ACPI problem gone. :) Way cool. :) Yeah, Maxim is maniac :) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote:
Hi, Maxim. Thanks for reporting and reminding us.
I think this is very difficult to fix, because;
1. Basically, this is a bug in BIOS, should be reported to vendor.
2. ACPI CA is developed by Intel. We'd like to have less local
workaround changes as possible.
3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).
Thank you very much for pointing me into the right
direction! Finally I've properly fixed the bug, though I
took slightly different approach, which I will describe
below in the case when somebody else has the same or similar
problem:
1. First of all, I dumped the ASL DSDT code using
acpidump(8) utility available from ports/devel/acpicatools.
For some reason output of the similar utility in the base
system (fresh 5-CURRENT) appears to be incompatible with
iasl compiler, so if anybody else will follow these steps
please make sure that you are using a right acpidump(8).
2. After that I have compiled ASL code back into AML using
iasl and saved resulting AML under different name DSDT_old.
3. Then I've patched ASL file to fix the problem - as Mike
suggested changed 0x19 to 0x11 and 0x1c to 0x14 and compiled
fixed ASL into DSDT_new file. With this message I am
attaching appropriate patch, perhaps it is a good idea to
put it somehow into the repository.
4. Next I've compared output of `hexdump -C' of both files
(DSDT_old and DSDT_new), noted the differencies - as I
expected only three bytes were different - checksum in the
header and two bytes in the code itself.
5. Then I've extracted ACPI table from BIOS image using
AWARD's CBROM.EXE utility, fired my favourite hex editor,
found those two bytes in the extracted file and changed them
accordingly (0x19--0x11, 0x1c--0x14). Also I've increased
checksum in the DSDT header by the difference of the
checksums in the DSDT_old and DSDT_new (0x10 in this
particular case).
6. And finally I've put back corrected ACPI table back into
BIOS image using CBROM.EXE, flashed resulting BIOS image and
voila - the ACPI problem gone. :)
If anybody else needs it, I could provide fixed BIOS image
for Tyan-S1590 (Trinity 100AT) mobo, just drop me a note.
Thanks to all who helped!
-Maxim
I'll describe again the problem. This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.
Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.
Maxim, could you apply the following patches and try DSDT overriding?
Thanks
--- Tyan-S1590.asl.org Wed Oct 24 22:00:44 2001
+++ Tyan-S1590.asl Wed Oct 24 22:02:09 2001
@@ -884,12 +884,14 @@
}
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0,
0x79, 0x0 })
+/*
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
+*/
Return(BUF0)
}
Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0,
0x38, 0x79, 0x0 })
--- Tyan-S1590.asl 2001/10/25 11:00:43 1.1
+++ Tyan-S1590.asl 2001/10/25 11:07:17 1.2
@@ -868,8 +868,8 @@
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
Re: [acpi-jp 1371] Re: ACPI: problem with fdc resource allocation
On Thu, Oct 25, 2001 at 05:13:56PM +0300, Maxim Sobolev wrote: 6. And finally I've put back corrected ACPI table back into BIOS image using CBROM.EXE, flashed resulting BIOS image and voila - the ACPI problem gone. :) Way cool. :) Joe msg32007/pgp0.pgp Description: PGP signature
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: Maxim Sobolev wrote: Mike Smith wrote: This just isn't going to work. The _CRS data stream stops at byte 0x17, and these extra items are simply mis-aimed. The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie. this is a BIOS bug, and should be reported to the vendor. (It should also have failed the Microsoft ACPI validation suite...) The correct action should probably be to silently discard the write operations outside of a defined buffer, and return Zeroes or Ones for a read outside a buffer. Do you have a patch to test this approach? While I understand that the best way to resolve the problem is to convince vendors to fix their ACPI implementations, but obviously this isn't going to happen any time soon, so appropriate workarround is really a must. The problem is still here as of today's kernel. Please do something about it. Should I reapeat how sad it is that this longstanding problem is being completely ignored by the acpi maintainer(s)? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
The problem is still here as of today's kernel. Please do something about it. Should I reapeat how sad it is that this longstanding problem is being completely ignored by the acpi maintainer(s)? No, I'd prefer that you found something constructive to do with your time. I'm not interested in being bitched out over something as trivial as this when I have so much on my plate already; if you can't contribute, do me the least favour and save me the angst. Thanks. Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
The problem is still here as of today's kernel. Please do something about it. Should I reapeat how sad it is that this longstanding problem is being completely ignored by the acpi maintainer(s)? No, I'd prefer that you found something constructive to do with your time. I'm not interested in being bitched out over something as trivial as this when I have so much on my plate already; if you can't contribute, do me the least favour and save me the angst. What you expect me to do constructive about this? I've submitted detailed report, tested some patches proposed by the Japanese ACPI developers and so on. I do not see what else I could do to get this problem resolved apart from bugging you from time to time. Perhaps you have any better ideas, then please let me know. Also if the problem is as trivial as you are describing, then it is highly unclear why it is not fixed yet (some 6 weeks are passed since initial report). I know several local guys with exactly the same bug (some time ago I've convinced some them to swith to -current and test/report any problems) and it is very sad to see my efforts vanished, especially considering that the source of the problem is located and as you said it is a trivial one. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Hi, Maxim. Thanks for reporting and reminding us.
I think this is very difficult to fix, because;
1. Basically, this is a bug in BIOS, should be reported to vendor.
2. ACPI CA is developed by Intel. We'd like to have less local
workaround changes as possible.
3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).
I'll describe again the problem. This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.
Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.
Maxim, could you apply the following patches and try DSDT overriding?
Thanks
--- Tyan-S1590.asl.org Wed Oct 24 22:00:44 2001
+++ Tyan-S1590.asl Wed Oct 24 22:02:09 2001
@@ -884,12 +884,14 @@
}
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79,
0x0 })
+/*
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
+*/
Return(BUF0)
}
Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0,
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x38,
0x79, 0x0 })
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote:
Hi, Maxim. Thanks for reporting and reminding us.
I think this is very difficult to fix, because;
1. Basically, this is a bug in BIOS, should be reported to vendor.
I understood that, but it is a discontinued model, so it is
unlikely that they will bother to provide updated BIOS just
to satisfy those strange that want to run FreeBSD on it. :((
2. ACPI CA is developed by Intel. We'd like to have less local
workaround changes as possible.
Ok, I see.
3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
in [acpi-jp 1315] is correct fix, maybe not. Probably another approach
can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
interpreter execution).
I'll describe again the problem. This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
And strangely, this method just return the buffer w/o any changes
after CreateByteField operations. I guess that BIOS writer forgotten to
delete CreateByteField statements, or change the buffer size.
Now that we have DSDT override patches;
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
or
http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
and AML disassembler (acpidump), and ASL compiler (iasl) in
ports/devel/acpicatools/.
Maxim, could you apply the following patches and try DSDT overriding?
Looks like a way to go. I'll test them tomorrow and let you
know then.
Big thanks!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: Mike Smith wrote: This just isn't going to work. The _CRS data stream stops at byte 0x17, and these extra items are simply mis-aimed. The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie. this is a BIOS bug, and should be reported to the vendor. (It should also have failed the Microsoft ACPI validation suite...) The correct action should probably be to silently discard the write operations outside of a defined buffer, and return Zeroes or Ones for a read outside a buffer. Do you have a patch to test this approach? While I understand that the best way to resolve the problem is to convince vendors to fix their ACPI implementations, but obviously this isn't going to happen any time soon, so appropriate workarround is really a must. The problem is still here as of today's kernel. Please do something about it. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Mike Smith wrote:
This just isn't going to work. The _CRS data stream stops at byte 0x17,
and these extra items are simply mis-aimed.
The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
this is a BIOS bug, and should be reported to the vendor. (It should
also have failed the Microsoft ACPI validation suite...)
The correct action should probably be to silently discard the write
operations outside of a defined buffer, and return Zeroes or Ones for a
read outside a buffer.
Do you have a patch to test this approach? While I understand that the best way to
resolve the problem is to convince vendors to fix their ACPI implementations, but
obviously this isn't going to happen any time soon, so appropriate workarround is
really a must.
-Maxim
Hi, I've just made a workaround for this. Intel folks, could you review
it as always?
The problem is here, right?
can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
which you reported. Trace attached in this mail.
[snip]
dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer si
ze 192 (bits)
PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIM
IT
This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0
})
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
for this.
Anyway, I made a patch to reallocate a large enough buffer for the
requested operation.
Thanks
Index: dsopcode.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 dsopcode.c
--- dsopcode.c7 Sep 2001 01:22:24 - 1.1.1.10
+++ dsopcode.c1 Oct 2001 18:58:41 -
@@ -615,11 +615,24 @@
if ((BitOffset + BitCount)
(8 * (UINT32) SrcDesc-Buffer.Length))
{
+UINT32 Length;
+UINT8 *Pointer;
+
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
Field size %d exceeds Buffer size %d (bits)\n,
BitOffset + BitCount, 8 * (UINT32) SrcDesc-Buffer.Length))
;
-Status = AE_AML_BUFFER_LIMIT;
-goto Cleanup;
+Length = ((BitOffset + BitCount) / 8) +
+ (((BitOffset + BitCount) % 8) ? 1 : 0);
+Pointer = ACPI_MEM_CALLOCATE (Length);
+if (!Pointer)
+{
+Status = AE_NO_MEMORY;
+goto Cleanup;
+}
+MEMCPY (Pointer, SrcDesc-Buffer.Pointer, SrcDesc-Buffer.Length
);
+ACPI_MEM_FREE (SrcDesc-Buffer.Pointer);
+SrcDesc-Buffer.Pointer = Pointer;
+SrcDesc-Buffer.Length = Length;
}
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, I've just made a workaround for this. Intel folks, could you review
it as always?
The problem is here, right?
can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
which you reported. Trace attached in this mail.
[snip]
dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192
(bits)
PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT
This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
for this.
Anyway, I made a patch to reallocate a large enough buffer for the
requested operation.
Yes, that patch fixed the problem, thank you!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
This just isn't going to work. The _CRS data stream stops at byte 0x17,
and these extra items are simply mis-aimed.
The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
this is a BIOS bug, and should be reported to the vendor. (It should
also have failed the Microsoft ACPI validation suite...)
The correct action should probably be to silently discard the write
operations outside of a defined buffer, and return Zeroes or Ones for a
read outside a buffer.
Hi, I've just made a workaround for this. Intel folks, could you review
it as always?
The problem is here, right?
can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT
I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some
problems (not sure in BIOS or ACPICA yet). I could reproduce the problem
which you reported. Trace attached in this mail.
[snip]
dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer si
ze 192 (bits)
PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8)
Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIM
IT
This method is like this;
Method(_CRS) {
Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0
})
CreateByteField(BUF0, 0x2, IOLO)
CreateByteField(BUF0, 0x3, IOHI)
CreateByteField(BUF0, 0x4, IORL)
CreateByteField(BUF0, 0x5, IORH)
CreateByteField(BUF0, 0x19, IRQL)
CreateByteField(BUF0, 0x1c, DMAV)
Return(BUF0)
}
The problem is that this AML is trying to create a field at exceeded
position (0x19) of the Buffer (size is 0x18).
I couldn't find how AML interprepter treat this in ACPI Spec. so I'm
not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround
for this.
Anyway, I made a patch to reallocate a large enough buffer for the
requested operation.
Thanks
Index: dsopcode.c
===
RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 dsopcode.c
--- dsopcode.c7 Sep 2001 01:22:24 - 1.1.1.10
+++ dsopcode.c1 Oct 2001 18:58:41 -
@@ -615,11 +615,24 @@
if ((BitOffset + BitCount)
(8 * (UINT32) SrcDesc-Buffer.Length))
{
+UINT32 Length;
+UINT8 *Pointer;
+
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
Field size %d exceeds Buffer size %d (bits)\n,
BitOffset + BitCount, 8 * (UINT32) SrcDesc-Buffer.Length))
;
-Status = AE_AML_BUFFER_LIMIT;
-goto Cleanup;
+Length = ((BitOffset + BitCount) / 8) +
+ (((BitOffset + BitCount) % 8) ? 1 : 0);
+Pointer = ACPI_MEM_CALLOCATE (Length);
+if (!Pointer)
+{
+Status = AE_NO_MEMORY;
+goto Cleanup;
+}
+MEMCPY (Pointer, SrcDesc-Buffer.Pointer, SrcDesc-Buffer.Length
);
+ACPI_MEM_FREE (SrcDesc-Buffer.Pointer);
+SrcDesc-Buffer.Pointer = Pointer;
+SrcDesc-Buffer.Length = Length;
}
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Maxim Sobolev wrote: Maxim Sobolev wrote: Andrey A. Chernov wrote: On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. Knock, knock... Is anybody home? Hmm, it is very sad to see that acpi code is totally unsupported, especially in the spite of recent how to attract people to test -current thread. The problem is still here, as of today's kernel. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Mitsuru IWASAKI wrote: Hi, Maxim Sobolev wrote: Maxim Sobolev wrote: Andrey A. Chernov wrote: On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. Knock, knock... Is anybody home? Hmm, it is very sad to see that acpi code is totally unsupported, especially in the spite of recent how to attract people to test -current thread. The problem is still here, as of today's kernel. I'm not sure exactly what's the problem you are having, but it's too little information to track it down... Could you send [EMAIL PROTECTED] ; - acpidump output; like # acpidump -o your_machine_name.dsdt your_machine_name.dsdt.asl I'll add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp - dmesg output of kernel boot -v Just sent it to you privately. After hiting sed button I've realised that machine_name that you have requested != host_name. Since it isn't a brandname model you can identify it after the mainboard name - Tyan-S1590. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, I'm not sure exactly what's the problem you are having, but it's too little information to track it down... Could you send [EMAIL PROTECTED] ; - acpidump output; like # acpidump -o your_machine_name.dsdt your_machine_name.dsdt.asl I'll add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp - dmesg output of kernel boot -v Just sent it to you privately. After hiting sed button I've realised that machine_name that you have requested != host_name. Since it isn't a brandname model you can identify it after the mainboard name - Tyan-S1590. Thanks, I've just add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tyan-S1590.asl?cvsroot=freebsd-jp The problem is here, right? can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some problems (not sure in BIOS or ACPICA yet). I could reproduce the problem which you reported. Trace attached in this mail. I'll try to make a workaround tomorrow or next, sorry. # Here in Japan, it's midnight... Thanks % acpicadb Tyan-S1590.dsdt Parsing Methods:... 55 Control Methods found and parsed (259 nodes total) ACPI Namespace successfully loaded at root 0x8087414 - f FDC0 \_SB_.PCI0.ISA_.FDC0 (0x8098da8) - Device - debug _SB_.PCI0.ISA_.FDC0._CRS Executing \_SB_.PCI0.ISA_.FDC0._CRS 0 #0008 [00] Name BUF0 (Path \) [00] ( 5 #0011 [01] Buffer [01] ( 7 #000A [02] (UINT8) 0x18, 9 #0033 [02] ByteList (Length 0x0018) [02] } [01] } % ArgObj:0x80acfa8 Obj Integer 0018 00021 #008C [00] CreateByteField [00] ( 00022 #002D [01] BUF0, (Path 00026 #000A [01] (UINT8) 0x02, 00028 #002D [01] IOLO (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af1a8 Obj Integer 0002 ArgObj:0x80af0a8 NodeName IOLO Type-BuffField 0002C #008C [00] CreateByteField [00] ( 0002D #002D [01] BUF0, (Path 00031 #000A [01] (UINT8) 0x03, 00033 #002D [01] IOHI (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af328 Obj Integer 0003 ArgObj:0x80af228 NodeName IOHI Type-BuffField 00037 #008C [00] CreateByteField [00] ( 00038 #002D [01] BUF0, (Path 0003C #000A [01] (UINT8) 0x04, 0003E #002D [01] IORL (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af4a8 Obj Integer 0004 ArgObj:0x80af3a8 NodeName IORL Type-BuffField 00042 #008C [00] CreateByteField [00] ( 00043 #002D [01] BUF0, (Path 00047 #000A [01] (UINT8) 0x05, 00049 #002D [01] IORH (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af628 Obj Integer 0005 ArgObj:0x80af528 NodeName IORH Type-BuffField 0004D #008C [00] CreateByteField [00] ( 0004E #002D [01] BUF0, (Path 00052 #000A [01] (UINT8) 0x19, 00054 #002D [01] IRQL (Path [01] } % ArgObj:0x80acf28 NodeName BUF0 Type-Buffer ArgObj:0x80af7a8 Obj Integer 0019 ArgObj:0x80af6a8 NodeName IRQL Type-BuffField dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer size 192 (bits) PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8) Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIMIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Hi, Maxim Sobolev wrote: Maxim Sobolev wrote: Andrey A. Chernov wrote: On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. Knock, knock... Is anybody home? Hmm, it is very sad to see that acpi code is totally unsupported, especially in the spite of recent how to attract people to test -current thread. The problem is still here, as of today's kernel. I'm not sure exactly what's the problem you are having, but it's too little information to track it down... Could you send [EMAIL PROTECTED] ; - acpidump output; like # acpidump -o your_machine_name.dsdt your_machine_name.dsdt.asl I'll add them to http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/?cvsroot=freebsd-jp - dmesg output of kernel boot -v Mike, anything add to this? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: problem with fdc resource allocation
Andrey A. Chernov wrote: On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. Doesn't work, exactly the same problem - see attached device.hints. -Maxim #hint.fdc.0.at=isa #hint.fdc.0.port=0x3F0 #hint.fdc.0.irq=6 #hint.fdc.0.drq=2 hint.fd.0.at=fdc0 hint.fd.0.drive=0 hint.atkbdc.0.at=isa hint.atkbdc.0.port=0x060 hint.atkbd.0.at=atkbdc hint.atkbd.0.irq=1 hint.vga.0.at=isa hint.sc.0.at=isa hint.sc.0.flags=0x6 hint.npx.0.at=nexus hint.npx.0.port=0x0F0 hint.npx.0.irq=13 hint.sio.0.at=isa hint.sio.0.port=0x3F8 hint.sio.0.flags=0x10 hint.sio.0.irq=4 hint.sio.1.at=isa hint.sio.1.port=0x2F8 hint.sio.1.irq=3 hint.ppc.0.at=isa hint.ppc.0.flags=0x8 hint.ppc.0.irq=7 hint.plip.0.at=ppbus hint.psm.0.at=atkbdc hint.psm.0.irq=12
ACPI: problem with fdc resource allocation
Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. Thanks! -Maxim Copyright (c) 1992-2001 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 #23: Mon Sep 17 16:03:59 EEST 2001 root@big_brother:/usr/src/sys/i386/compile/MBSD Timecounter i8254 frequency 1193025 Hz CPU: AMD-K6(tm) 3D processor (501.07-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 167706624 (163776K bytes) avail memory = 159588352 (155848K bytes) Preloaded elf kernel /boot/kernel/kernel at 0xc0346000. Preloaded elf module /boot/kernel/acpi.ko at 0xc03460a8. K6-family MTRR support enabled (2 registers) Using $PIR table, 6 entries at 0xc00fddf0 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface acpi0: AWARD AWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0x5080-0x50ff,0x5000-0x507f,0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C586 ATA33 controller port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xe800-0xe81f irq 9 at device 9.0 on pci0 ed0: address 00:40:05:5b:69:33, type NE2000 (16 bit) fdc0: cannot reserve I/O port range (1 ports) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: Hewlett-Packard HP LaserJet 1100.1.1 PRINTER MLC,PCL,PJL lpt0: Printer on ppbus0 lpt0: Interrupt-driven port atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 fdc0: cannot reserve I/O port range (1 ports) psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc0: cannot reserve I/O port range (6 ports) ppc1: cannot reserve I/O port range ata2: Generic ESDI/IDE/ATA controller at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0 ad0: 4110MB QUANTUM FIREBALL ST4.3A [14848/9/63] at ata0-master UDMA33 ad1: 2014MB QUANTUM FIREBALL ST2.1A [4092/16/63] at ata1-master UDMA33 acd0: CDROM Philips R O D 1270 at ata1-slave PIO3 Mounting root from ufs:/dev/ad1s1a
Re: ACPI: problem with fdc resource allocation
On Mon, Sep 17, 2001 at 16:26:20 +0300, Maxim Sobolev wrote: Hi, Finally decided to upgrade my current box to the post-ACPI/KSE and found that I'm having problem with resource allocation for floppy disk controller. I'm sure somebody already reported this some time ago, but the problems seems still here, so I would like to see it resolved. fdc0: cannot reserve I/O port range (1 ports) It seems that here is conflict with your device.hints, try to remove fdc from the hints. As I already write, it is very bad thing that ACPI is in conflicts with default hints file correctly describing devices used. ACPI must ignore duplicate devices from the hints. The problem with floppy is harder, because floppy controller present in ACPI but the floppy itself not present (on my motherboard at least), so in current situation fdc0 must not be in hints, but fd0 must be, it makes whole thing even more cryptic. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
