Created attachment 116971 [details] /var/crash log Using 3.11 and 3.12 Can provide more detailed logs upon request. ProblemType: KernelOops Annotation: This occured during a previous suspend and prevented it from resumin g properly. Architecture: amd64 Date: Sun Dec 1 02:35:41 2013 DistroRelease: Ubuntu 13.10 ExecutablePath: /usr/share/apport/apportcheckresume ExecutableTimestamp: 1382617300 Failure: suspend/resume InterpreterPath: /usr/bin/python3.3 Package: linux-image-3.12.0-031200-generic ProcCmdline: /usr/bin/python3 /usr/share/apport/apportcheckresume ProcCwd: / ProcEnviron: TERM=linux PATH=(custom, no user) ProcMaps: 00400000-0071d000 r-xp 00000000 fc:01 7865303 /usr/b in/python3.3 0091c000-0091d000 r--p 0031c000 fc:01 7865303 /usr/b in/python3.3 0091d000-009b6000 rw-p 0031d000 fc:01 7865303 /usr/b in/python3.3
1: Is there a factory BIOS and does it also have the same issue? 2: With coreboot, does this always happen or it happens from some kernel version?
Created attachment 117051 [details] attachment-26880-0.html Hi Aaron, 1. It does not happen with the factory bios for use with chromeos only. 2. With coreboot it always happens. I have used 3.11 and 3.12 and it occurs. Thanks, Chris On Sun, Dec 1, 2013 at 6:53 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=66261 > > Aaron Lu <aaron.lu@intel.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|NEW |NEEDINFO > CC| |aaron.lu@intel.com > > --- Comment #1 from Aaron Lu <aaron.lu@intel.com> --- > 1: Is there a factory BIOS and does it also have the same issue? > 2: With coreboot, does this always happen or it happens from some kernel > version? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Does the two firmware have the same ACPI table?
I think you can ask this on coreboot's mailing list, they may know better.
Created attachment 117061 [details] attachment-24747-0.html My guess is that there is some difference. The device in question is an Acer C7 'Parrot' Chromebook. The coreboot support is from Google. They and SEG engineering committed the changes for this board to the coreboot repository. On Sun, Dec 1, 2013 at 7:13 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=66261 > > --- Comment #3 from Aaron Lu <aaron.lu@intel.com> --- > Does the two firmware have the same ACPI table? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Created attachment 117071 [details] attachment-24951-0.html Hi Aaron, I will ask. I should think they have the same tables since the support came from Google. Thanks, Chris On Sun, Dec 1, 2013 at 7:19 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=66261 > > --- Comment #4 from Aaron Lu <aaron.lu@intel.com> --- > I think you can ask this on coreboot's mailing list, they may know better. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Created attachment 117081 [details] attachment-27480-0.html This is the commit for the Acer C7 'Parrot'. The acpi tables are there. http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=a7198b34ccf120df2a9e5b9f104812e96916ad08 Thanks, Chris On Sun, Dec 1, 2013 at 7:19 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=66261 > > --- Comment #4 from Aaron Lu <aaron.lu@intel.com> --- > I think you can ask this on coreboot's mailing list, they may know better. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
BTW, it's not clear to me what's the problem. Does the kernel oops upon you issue reboot command or you have problems with resuming?
Hi Aaron, The system resumes but immediately there is a kernel oops and then the system reboots. I do not issue any reboot command. I am trying to gather better documentation of the issue but have space issues. Thanks, Chris -----Original Message----- From: bugzilla-daemon@bugzilla.kernel.org [mailto:bugzilla-daemon@bugzilla.kernel.org] Sent: Wednesday, December 11, 2013 00:10 To: christopherlang1@gmail.com Subject: [Bug 66261] Kernel oops upon reboot from suspend - Flashed Acer C7 using coreboot https://bugzilla.kernel.org/show_bug.cgi?id=66261 --- Comment #8 from Aaron Lu <aaron.lu@intel.com> --- BTW, it's not clear to me what's the problem. Does the kernel oops upon you issue reboot command or you have problems with resuming? -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
Is it possible to capture a picture when the kernel oops? BTW, what's the value of kernel.panic? You can check it by: $ sysctl kernel.panic
Created attachment 118221 [details] attachment-7397-0.html Hi Aaron, kernel.panic is 0. It reboots to quickly to allow for a screen shot. I can gather more doc once I free some space. Is there anything I should try in the meantime? Thanks, Chris On Wed, Dec 11, 2013 at 9:18 PM, <bugzilla-daemon@bugzilla.kernel.org>wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=66261 > > --- Comment #10 from Aaron Lu <aaron.lu@intel.com> --- > Is it possible to capture a picture when the kernel oops? BTW, what's the > value > of kernel.panic? You can check it by: > $ sysctl kernel.panic > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Created attachment 118711 [details] attachment-1204-0.html Hi Aaron, For my kernel oops (and unwanted reboot) on resume from suspend using coreboot on an Acer C7, I have a debug kernel now and built it with panic on oops but it does not. I also tried the Ubuntu debugging kernel suspend procedure with pm_suspend and I get the following from dmesg after the system reboots while resuming. [ 5.898325] Magic number: 9:795:192 [ 5.898374] acpi device:1e: hash matches I could not find any specific device with a 1e in the address running lspci. I also spoke to someone on the coreboot mailing list and they said the acpi tables are the same in coreboot as for the C7 production bios. So far as I can tell I have a proper environment set-up for gathering a core file. Any ideas on how to proceed? Thanks, Chris On Thu, Dec 12, 2013 at 7:10 PM, Christopher Lang < christopherlang1@gmail.com> wrote: > Hi Aaron, > > kernel.panic is 0. It reboots to quickly to allow for a screen shot. I can > gather more doc once I free some space. Is there anything I should try in > the meantime? > > Thanks, > > Chris > > > > On Wed, Dec 11, 2013 at 9:18 PM, <bugzilla-daemon@bugzilla.kernel.org>wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=66261 >> >> --- Comment #10 from Aaron Lu <aaron.lu@intel.com> --- >> Is it possible to capture a picture when the kernel oops? BTW, what's the >> value >> of kernel.panic? You can check it by: >> $ sysctl kernel.panic >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. >> You reported the bug. >> > >
(In reply to christopherlang1 from comment #12) > Created attachment 118711 [details] > attachment-1204-0.html > > Hi Aaron, > > For my kernel oops (and unwanted reboot) on resume from suspend using > coreboot on an Acer C7, I have a debug kernel now and built it with panic > on oops but it does not. I also tried the Ubuntu debugging kernel suspend > procedure with pm_suspend and I get the following from dmesg after the > system reboots while resuming. > > [ 5.898325] Magic number: 9:795:192 > [ 5.898374] acpi device:1e: hash matches > > I could not find any specific device with a 1e in the address running > lspci. I also spoke to someone on the coreboot mailing list and they said > the acpi tables are the same in coreboot as for the C7 production bios. acpi device:1e is somewhere at: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:1e You can check if it is there on your system. But I doubt if it is related here, as it shouldn't have a driver bound to it. BTW, you can do some basic debugging according to: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt In short, you can do: # cd /sys/power # echo devices > pm_test # echo mem > state see if anything goes wrong. If not, proceed to next level platform and start again.
I believe I have the same bug, I am using Debian Testing (linux-image-3.11-2-686-pae) on an Acer C710-2615 Chromebook, with a pre-built coreboot firmware. I tested reboot, platform, shutdown modes as indicated in the debugging link, all worked. Kernel.panic was also at 0 after reboot
Created attachment 119231 [details] attachment-3340-0.html Hi Aaron, Thanks for all of the info. I ran all of the tests ok. Chris On Thu, Dec 19, 2013 at 12:54 AM, <bugzilla-daemon@bugzilla.kernel.org>wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=66261 > > --- Comment #13 from Aaron Lu <aaron.lu@intel.com> --- > (In reply to christopherlang1 from comment #12) > > Created attachment 118711 [details] > > attachment-1204-0.html > > > > Hi Aaron, > > > > For my kernel oops (and unwanted reboot) on resume from suspend using > > coreboot on an Acer C7, I have a debug kernel now and built it with panic > > on oops but it does not. I also tried the Ubuntu debugging kernel suspend > > procedure with pm_suspend and I get the following from dmesg after the > > system reboots while resuming. > > > > [ 5.898325] Magic number: 9:795:192 > > [ 5.898374] acpi device:1e: hash matches > > > > I could not find any specific device with a 1e in the address running > > lspci. I also spoke to someone on the coreboot mailing list and they said > > the acpi tables are the same in coreboot as for the C7 production bios. > > acpi device:1e is somewhere at: > /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:1e > You can check if it is there on your system. But I doubt if it is related > here, > as it shouldn't have a driver bound to it. > > BTW, you can do some basic debugging according to: > https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt > In short, you can do: > # cd /sys/power > # echo devices > pm_test > # echo mem > state > see if anything goes wrong. If not, proceed to next level platform and > start > again. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug. >
Perhaps this is better solved in coreboot community, I don't see much we can do here.