Re: xhci dead after resume

2015-01-08 Thread Remi Locherer
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



Re: RSDT corruption, acpidump problems

2015-01-08 Thread Kasper Steensig Jensen
On 2015/01/06 23:26, Mark Kettenis wrote:
  From: Kasper Steensig Jensen ksj...@student.aau.dk
  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 file
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=filest=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: RSDT corruption, acpidump problems

2015-01-08 Thread Kasper Steensig Jensen
On 2015/01/06 23:26, Mark Kettenis wrote:
  From: Kasper Steensig Jensen ksj...@student.aau.dk
  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 file
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=filest=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?