My Kernel bug is celebrating 2 years. Can you help me fix it?
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information: https://bugzilla.redhat.com/show_bug.cgi?id=787299 I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186 But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel? Thank you, Peter P.S Yes, it works on Windows. -- Peter
Am 04.03.2014 22:26, schrieb Peter Senna Tschudin:
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information:
https://bugzilla.redhat.com/show_bug.cgi?id=787299
I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state
I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186
But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? You need to create a kernel with networksupport, setup "netconsole" you need a second computer to receive the issues.
How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel?
never heard about that until now, obviously there is a bug in several acpi's that can be triggered. If your systems works with nox2apic as bootparameter you should be happy since a workaround is available. Information about it is used can be find here: http://lxr.free-electrons.com/ident?a=microblaze;i=nox2apic re, wh
Thank you,
Peter
P.S Yes, it works on Windows.
Dear Peter Senna Tschudin, On Tue, 4 Mar 2014 22:26:37 +0100, Peter Senna Tschudin wrote:
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information:
https://bugzilla.redhat.com/show_bug.cgi?id=787299
I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state
I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186
But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel?
Something I would try in this situation is to boot with mem=<some value smaller than the amount of RAM>, and then have the kernel write some debugging informations manually at a fixed location in RAM that has been reserved by lowering the amount of RAM using mem=. Then, when you reboot, you can dump what has been left in this memory location. Of course this requires that 1/ this memory location is not overwritten by the BIOS/bootloader and 2/ that you can do a warm reset to not loose the contents of the memory. Since I don't do much x86 kernel hacking, I never had to do that on x86, but I've used this trick a few times on ARM platforms. If that works, then it means you can put some debugging details all over the kernel to find where things hand exactly during the resume process. Another embedded trick is to find a LED that you can easily turn on/off. It is very useful to see if you reach a given portion of code or not. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
[+cc Stoney, Yinghai, Suresh, Joerg, Jiang, Pavel, Rafael, linux-pm] Let's add some folks who know about x2apic and VT-d. It's hard for people to magically pick stuff out of the LKML firehose :) On Tue, Mar 4, 2014 at 2:26 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information:
https://bugzilla.redhat.com/show_bug.cgi?id=787299
I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state
I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186
But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel?
Thank you,
Peter
P.S Yes, it works on Windows.
-- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 03/06/2014 01:27 PM, Bjorn Helgaas wrote:
[+cc Stoney, Yinghai, Suresh, Joerg, Jiang, Pavel, Rafael, linux-pm]
Let's add some folks who know about x2apic and VT-d. It's hard for people to magically pick stuff out of the LKML firehose :)
On Tue, Mar 4, 2014 at 2:26 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information:
https://bugzilla.redhat.com/show_bug.cgi?id=787299
I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state
I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186
But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel?
Thank you,
Peter
P.S Yes, it works on Windows.
Windows 7 doesn't use x2apic mode. Windows 8 does and this same problem happened with this model: see http://forums.toshiba.com/t5/Windows-8-8-1/Resume-from-standby-issue-on-R830... Seems like your model was recently added to Toshiba's Windows 8 compatibility list: http://support.toshiba-tie.co.jp/windows8/list_au.htm Check for a more recent BIOS update that may fix this problem. Regards, Peter Hurley PS - kernel bugs are better filed on the kernel bugzilla https://bugzilla.kernel.org/
On Thu, Mar 6, 2014 at 8:08 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
On 03/06/2014 01:27 PM, Bjorn Helgaas wrote:
[+cc Stoney, Yinghai, Suresh, Joerg, Jiang, Pavel, Rafael, linux-pm]
Let's add some folks who know about x2apic and VT-d. It's hard for people to magically pick stuff out of the LKML firehose :)
On Tue, Mar 4, 2014 at 2:26 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information:
https://bugzilla.redhat.com/show_bug.cgi?id=787299
I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state
I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186
But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel?
Thank you,
Peter
P.S Yes, it works on Windows.
Windows 7 doesn't use x2apic mode. Windows 8 does and this same problem happened with this model: see http://forums.toshiba.com/t5/Windows-8-8-1/Resume-from-standby-issue-on-R830... Thank you for the information. The model is similar to mine, probably the same motherboard. My tests were with Windows 7.
Seems like your model was recently added to Toshiba's Windows 8 compatibility list: http://support.toshiba-tie.co.jp/windows8/list_au.htm
Check for a more recent BIOS update that may fix this problem.
I do that weekly since February last year, and there are no updates available. The bad news is that the model was discontinued, so it is possible that there will be no more BIOS updates. I'll write to Toshiba Europe GmbH asking for a fix, by my hopes in getting an answer are low.
Regards, Peter Hurley
PS - kernel bugs are better filed on the kernel bugzilla https://bugzilla.kernel.org/
Thank you! -- Peter
[ +cc linux-acpi ] On 03/07/2014 10:01 AM, Peter Senna Tschudin wrote:
On Thu, Mar 6, 2014 at 8:08 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
On 03/06/2014 01:27 PM, Bjorn Helgaas wrote:
[+cc Stoney, Yinghai, Suresh, Joerg, Jiang, Pavel, Rafael, linux-pm]
Let's add some folks who know about x2apic and VT-d. It's hard for people to magically pick stuff out of the LKML firehose :)
On Tue, Mar 4, 2014 at 2:26 PM, Peter Senna Tschudin <peter.senna@gmail.com> wrote:
I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information:
https://bugzilla.redhat.com/show_bug.cgi?id=787299
I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state
I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186
But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel?
Thank you,
Peter
P.S Yes, it works on Windows.
Windows 7 doesn't use x2apic mode. Windows 8 does and this same problem happened with this model: see http://forums.toshiba.com/t5/Windows-8-8-1/Resume-from-standby-issue-on-R830... Thank you for the information. The model is similar to mine, probably the same motherboard. My tests were with Windows 7.
And more importantly, probably the same system firmware.
Seems like your model was recently added to Toshiba's Windows 8 compatibility list: http://support.toshiba-tie.co.jp/windows8/list_au.htm
Check for a more recent BIOS update that may fix this problem. I do that weekly since February last year, and there are no updates available. The bad news is that the model was discontinued, so it is possible that there will be no more BIOS updates. I'll write to Toshiba Europe GmbH asking for a fix, by my hopes in getting an answer are low.
Ok.
Regards, Peter Hurley
PS - kernel bugs are better filed on the kernel bugzilla https://bugzilla.kernel.org/
Thank you!
I would file it under ACPI; perhaps a simple means of determining this system firmware does not reliably support x2apic can be found (or perhaps not). Please read REPORTING-BUGS; the latest is here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/REPORTI... Good luck, Peter Hurley
participants (5)
-
Bjorn Helgaas -
Peter Hurley -
Peter Senna Tschudin -
Thomas Petazzoni -
walter harms