Re: [SeaBIOS] [Seabois] BSOD during start of Win2003 installation
On 07/24/12 19:51, Alexey Korolev wrote: > Hi, > > Win2003 falls to BSOD during early init stage of installer. > It is ACPI related issue and it appears in any configuration. RAM size is 6GB > Error code is : > 0x00A5 (0x02, 0xfADF6A446880, 0x1, 0xFADFAA34690) > > The things get broken after commit 2062f2bab81915c5c1f7af12a49ad8d4b3fd23fb > (update dsdt resources at runtime) > > I've tried to debug this issue but haven't succeed yet. > > One strange thing here is that the code doesn't reach the _CRS method. We > have added a debug output but nothing related to CRS was printed. > May be you have any ideas why it may fail. I would much appreciate any help > on this. DBUG() didn't work for me with winxp (same code base as win2k3 iirc), so no debug output is *not* an indicator for not reaching _CRS. Is this win2k3 with latest service pack? I've used winxp with sp3 for testing ... cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
On Sun, Aug 05, 2012 at 11:36:15PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 30, 2012 at 07:42:48PM +, Moore, Robert wrote:
> > Yes, you are correct, the listing no longer includes the comments.
> >
> > Sorry for causing you a problem.
> >
> > What is happening is that the preprocessor parser is stripping the comments
> > during the creation of the .i file. Then, the compiler is invoked on the .i
> > file -- thus, the comments are gone.
> >
> > This is going to take a bit of work to correct, but we will do it.
> >
> > In the meantime, try using the -Pn flag to disable the preprocessor. When
> > this flag is set, the preprocessor is completely bypassed and the compiler
> > should function as it did previously.
>
>
> So we are doing it this way meanwhile. If you change this preprocessor
> behaviour like you indicated you would, please let us know so e can
> test.
>
> Thanks!
By the way, is there interest in adding some of the functionality
that we get by parsing the listing to iasl directly?
Here's what our tool currently supports:
# Process mixed ASL/AML listing (.lst file) produced by iasl -l
# Locate and execute ACPI_EXTRACT directives, output offset info
#
# Documentation of ACPI_EXTRACT_* directive tags:
#
# These directive tags output offset information from AML for BIOS runtime
# table generation.
# Each directive is of the form:
# ACPI_EXTRACT_ (...)
# and causes the extractor to create an array
# named with offset, in the generated AML,
# of an object of a given type in the following .
#
# A directive must fit on a single code line.
#
# Object type in AML is verified, a mismatch causes a build failure.
#
# Directives and operators currently supported are:
# ACPI_EXTRACT_NAME_DWORD_CONST - extract a Dword Const object from Name()
# ACPI_EXTRACT_NAME_WORD_CONST - extract a Word Const object from Name()
# ACPI_EXTRACT_NAME_BYTE_CONST - extract a Byte Const object from Name()
# ACPI_EXTRACT_METHOD_STRING - extract a NameString from Method()
# ACPI_EXTRACT_NAME_STRING - extract a NameString from Name()
# ACPI_EXTRACT_PROCESSOR_START - start of Processor() block
# ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from Processor()
# ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processor() + 1
# ACPI_EXTRACT_PKG_START - start of Package block
#
# ACPI_EXTRACT_ALL_CODE - create an array storing the generated AML bytecode
#
# ACPI_EXTRACT is not allowed anywhere else in code, except in comments.
Example:
ACPI_EXTRACT_NAME_DWORD_CONST aml_adr_dword
Name (_ADR, 0x0001)
adds the offset of 0x0001 constant to array aml_adr_dword
Example:
ACPI_EXTRACT_METHOD_STRING aml_ej0_name
Method (_EJ0, 1) { Return(PCEJ(0x0001)) }
adds the offset of _EJ0 string to array aml_ej0_name
ACPI_EXTRACT_ALL_CODE ssdp_pcihp_aml
names the array to include the generated AML code
--
MST
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
On Mon, Jul 30, 2012 at 07:42:48PM +, Moore, Robert wrote: > Yes, you are correct, the listing no longer includes the comments. > > Sorry for causing you a problem. > > What is happening is that the preprocessor parser is stripping the comments > during the creation of the .i file. Then, the compiler is invoked on the .i > file -- thus, the comments are gone. > > This is going to take a bit of work to correct, but we will do it. > > In the meantime, try using the -Pn flag to disable the preprocessor. When > this flag is set, the preprocessor is completely bypassed and the compiler > should function as it did previously. So we are doing it this way meanwhile. If you change this preprocessor behaviour like you indicated you would, please let us know so e can test. Thanks! -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] UHCI on US15W: Crazy stuff happening
On Sun, Aug 05, 2012 at 12:21:13PM +0100, Matthew Millman wrote: > Hi > > I'm seeing a rather interesting problem with UHCI on Intel US15W and > wondered if anyone else had seen anything like this before. I noticed it > when I plugged in a USB keyboard, which caused a crash due to something > corrupting the stack? it turns out that the stack has been trashed by the > UHCI controller via DMA?! > > When trying to transmit the 8 byte address setup packet, the hardware > doesn't quite seem to be doing as it's told. SeaBIOS sets up the UHCI TDs > exactly as per the spec - no problems there, > > Once the QH element is set, instead of transmitting the 8 bytes as > described in the TD, it transmits a full 1023 bytes? (according to the > returned TD) UHCI then goes ahead and overwrites another 35 bytes beyond > the end of the buffer pointed to by the TD. > > Here's the 8 bytes of the setup packet (I've set everything after it to > 0xFF): > > 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff > 1fbc1fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 1fbc1fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 1fbc1fd0: ff ff ff ff ff > > Here it is after the UHCI controller has been at it. The only code to > execute between these two dumps is this: > > pipe->qh.element = (u32)&tds[0]; (in uhci_control()) > > 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff > 1fbc1fa0: bf 00 05 01 00 00 00 00 00 ff ff ff fd 03 00 00 > 1fbc1fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 1fbc1fd0: ff ff ff ff ff > > TD Chain before: > 1fbc4870: 84 48 bc 1f 00 00 80 1c 2d 00 e0 00 95 1f bc 1f > 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00 > > TD Chain after: > 1fbc4870: 84 48 bc 1f ff 07 80 1c 2d 00 e0 00 95 1f bc 1f > 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00 My read of the spec says an actlen=0x07ff means a null transfer (not 1023 bytes). However, given that the status is still active I don't think it really matters what's in the td. > I'm wondering if I'm not the first person to have seen this. The problem > (without detailed debugging) manifests its self exactly as described in > this message: I haven't seen this type of report before. A couple of things you could try: dump the USB controller registers as well (the controller may have shutdown for a different reason), check to see if any other transfer attempted to use 0x1fbc1fa0 in the past (perhaps the controller has something stale cached), look for an errata for the chipset, look through the linux code for the chipset to see if it is working about something, try aligning the setup packet buffer to 16 bytes. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] UHCI on US15W: Crazy stuff happening
Hi I'm seeing a rather interesting problem with UHCI on Intel US15W and wondered if anyone else had seen anything like this before. I noticed it when I plugged in a USB keyboard, which caused a crash due to something corrupting the stack? it turns out that the stack has been trashed by the UHCI controller via DMA?! When trying to transmit the 8 byte address setup packet, the hardware doesn't quite seem to be doing as it's told. SeaBIOS sets up the UHCI TDs exactly as per the spec - no problems there, Once the QH element is set, instead of transmitting the 8 bytes as described in the TD, it transmits a full 1023 bytes? (according to the returned TD) UHCI then goes ahead and overwrites another 35 bytes beyond the end of the buffer pointed to by the TD. Here's the 8 bytes of the setup packet (I've set everything after it to 0xFF): 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff 1fbc1fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1fbc1fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1fbc1fd0: ff ff ff ff ff Here it is after the UHCI controller has been at it. The only code to execute between these two dumps is this: pipe->qh.element = (u32)&tds[0]; (in uhci_control()) 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff 1fbc1fa0: bf 00 05 01 00 00 00 00 00 ff ff ff fd 03 00 00 1fbc1fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 1fbc1fd0: ff ff ff ff ff TD Chain before: 1fbc4870: 84 48 bc 1f 00 00 80 1c 2d 00 e0 00 95 1f bc 1f 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00 TD Chain after: 1fbc4870: 84 48 bc 1f ff 07 80 1c 2d 00 e0 00 95 1f bc 1f 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00 I'm wondering if I'm not the first person to have seen this. The problem (without detailed debugging) manifests its self exactly as described in this message: http://comments.gmane.org/gmane.linux.bios/55336 Thanks! Matt ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks
To: Alec Ari Cc: "seabios@seabios.org" Sent: Sunday, August 5, 2012 1:44 AM Subject: Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks >I get the same error. Thanks for the feedback! -Alec ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
