Re: RSDT corruption, acpidump problems
>>On 2015/01/06 23:26, Mark Kettenis wrote:
>>> > From: Kasper Steensig Jensen
>>> > Date: Tue, 6 Jan 2015 21:23:53 +
>>> >
>>> > >On 2015/01/05 15:17, Kasper Steensig Jensen wrote:
>>> > >> acpidump not working because corrupted RSDT. When the command acpidump
>>> > >> -o mydump is run it gives the error "apidump: RSDT is corrupted"
>>> > >> ACPI has been tested and is working on Debian, FreeBSD
>>> >
>>> > >Can you get an acpidump from FreeBSD?
>>> >
>>> > >> so it can't be a problem with the laptop.
>>> >
>>> > >Yes it can, but these other OS might be ignoring it.
>>> >
>>> > >> UKC> disable mpbios
>>> > >> 53 mpbios0 disabled
>>> >
>>> > >why?
>>> >
>>> > >Can you get an acpidump from FreeBSD?
>>> > FreeBSD is currently not installed on the laptop but would a Debian
>>> > acpidump be good enough? I can install FreeBSD if it's required.
>>>
>>> Might be. I'm not really familliar with the Linux acpidump tool, but
>>> if it dumps all the tables in raw format, it might be useful.
>>>
>>> The mailing lists will strip attachments, so best if you put it on a
>>> webserver somewhere from where we can download it.
>>
>>It looks like you may be able to do this with linux's acpidump:
>>
>>acpidump > acpidump.out
>>
>>- this should produce a text file
>>
>>acpixtract -a acpidump.out
>>
>>- this should convert it into a number of .dat files which are what
>>might be useful to us (you should also be able to run "iasl -d "
>>to disassemble them); tar up the .dat files and put them online
>>somewhere.
>>
>>> Anyway, what we need to figure out is why mapping the RSDT table
>>> fails. If you happen to have some hacking skills you could try to
>>> figure out which "return NULL" in sys/dev/acpi.c:acpi_maptable()
>>> you're hitting on that laptop.
>
>Here is a link to the acpidump archive file:
>
>https://cloud.prozum.dk/public.php?service=files&t=78661b263f4932df157c13a94c5209e7
>
>On Debian I also got the error "Wrong checksum for XDST",
>I can still read the battery on Debian which I can't on OpenBSD.
>
>I also found the "return NULL" that I am hitting in
>sys/dev/acpi.c:acpi_maptable()
>It is the 4th NULL which is in the codeblock:
>
>if (acpi_checksum(hdr, len)) {
>acpi_unmap(&handle);
>return NULL;
>}
>
>It is definitely the checksum that something is wrong with,
>I don't know how to fix it though.
By commenting the code segmenting out which makes it ignore the checksum
I could get apm to detect my battery and batterylife.
This is bad practice and I would like not to do it this way but it makes it
work.
Is it possible that my laptop doesn't live up to the ACPI specs or something?
Re: RSDT corruption, acpidump problems
>On 2015/01/06 23:26, Mark Kettenis wrote:
>> > From: Kasper Steensig Jensen
>> > Date: Tue, 6 Jan 2015 21:23:53 +
>> >
>> > >On 2015/01/05 15:17, Kasper Steensig Jensen wrote:
>> > >> acpidump not working because corrupted RSDT. When the command acpidump
>> > >> -o mydump is run it gives the error "apidump: RSDT is corrupted"
>> > >> ACPI has been tested and is working on Debian, FreeBSD
>> >
>> > >Can you get an acpidump from FreeBSD?
>> >
>> > >> so it can't be a problem with the laptop.
>> >
>> > >Yes it can, but these other OS might be ignoring it.
>> >
>> > >> UKC> disable mpbios
>> > >> 53 mpbios0 disabled
>> >
>> > >why?
>> >
>> > >Can you get an acpidump from FreeBSD?
>> > FreeBSD is currently not installed on the laptop but would a Debian
>> > acpidump be good enough? I can install FreeBSD if it's required.
>>
>> Might be. I'm not really familliar with the Linux acpidump tool, but
>> if it dumps all the tables in raw format, it might be useful.
>>
>> The mailing lists will strip attachments, so best if you put it on a
>> webserver somewhere from where we can download it.
>
>It looks like you may be able to do this with linux's acpidump:
>
>acpidump > acpidump.out
>
>- this should produce a text file
>
>acpixtract -a acpidump.out
>
>- this should convert it into a number of .dat files which are what
>might be useful to us (you should also be able to run "iasl -d "
>to disassemble them); tar up the .dat files and put them online
>somewhere.
>
>> Anyway, what we need to figure out is why mapping the RSDT table
>> fails. If you happen to have some hacking skills you could try to
>> figure out which "return NULL" in sys/dev/acpi.c:acpi_maptable()
>> you're hitting on that laptop.
Here is a link to the acpidump archive file:
https://cloud.prozum.dk/public.php?service=files&t=78661b263f4932df157c13a94c5209e7
On Debian I also got the error "Wrong checksum for XDST",
I can still read the battery on Debian which I can't on OpenBSD.
I also found the "return NULL" that I am hitting in
sys/dev/acpi.c:acpi_maptable()
It is the 4th NULL which is in the codeblock:
if (acpi_checksum(hdr, len)) {
acpi_unmap(&handle);
return NULL;
}
It is definitely the checksum that something is wrong with,
I don't know how to fix it though.
Re: xhci dead after resume
On Mon, Jan 05, 2015 at 01:40:10PM +0100, Martin Pieuchot wrote: > On 02/01/15(Fri) 13:42, Martin Pieuchot wrote: > > On 02/01/15(Fri) 09:47, Remi Locherer wrote: > > > On Thu, Jan 01, 2015 at 09:32:20PM +0100, Remi Locherer wrote: > > > > >Synopsis: xhci dead after resume > > > > >Category: kernel > > > > >Environment: > > > > System : OpenBSD 5.6 > > > > Details : OpenBSD 5.6-current (GENERIC.MP) #735: Sat Dec 27 > > > > 13:55:58 MST 2014 > > > > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > Architecture: OpenBSD.amd64 > > > > Machine : amd64 > > > > > > > > >Description: > > > > After resuming the notebook devices do not attach to the xhci > > > > port > > > > anymore while devices on the ehci port still work fine. I tried > > > > a mouse, usb stick and cdrom. The cdrom gets power from the port > > > > so I can open the tray but it does not attach. > > > > > > > > >Fix: > > > > After a reboot the xhci port works again > > > > > > dmesg from a kernel compiled with XHCI_DEBUG including a suspend-resume > > > cycle: > > > > Apparently Renesas HC need to be completely reconfigure upon resume. > > Linux have a quirk for such piece of hardware. I'll try to bake a diff > > unless someone... ok I can dream :) > > I just committed a workaround for this issue as I couldn't find any > documentation for a proper fix. Anyway I can no longer reproduce the > problem. > > Let me know if it still does not work on your machine. > > Regards, > Martin > I tested with the snapshot from January 7. Now the xhci port works fine after resume. Thanks! Remi
