Bug 58201

Created attachment 101631 [details]
config file to build the kernel (taken from arch linux)

Created attachment 101641 [details]
output of /proc/cpuinfo

Created attachment 101651 [details]
output of dmidecode

Created attachment 101661 [details]
output of lspci -vvv as root

Created attachment 101671 [details]
output of proc/module

Could you do a bisect between 3.8.13 and 3.9.0 to find which commit cause this regression?

Please provide the output of acpidump.

Created attachment 101701 [details]
outout of acpidump

I will try to do the bisect. Can you confirm that a "bisect" is the process described in "http://wiki.gentoo.org/wiki/Kernel_git-bisect" ?

Yes. That should work.
BTW, could you provide more panic log? There maybe  more clues to find the cause.

When the panic occurs, i can not scroll and i found nothing in the log. I wrote down the text but if you have a solution to see the beginning of the text, I can send more log.

Created attachment 101751 [details]
output of git bisect

I finished the bisect.

the error is with the commit
ACPI / PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.c
b3785492268f9f3cdaa9722facb84b266dcf8bf6 is the first bad commit
commit b3785492268f9f3cdaa9722facb84b266dcf8bf6
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Feb 1 23:43:02 2013 +0100

    ACPI / PM: Do not power manage devices in unknown initial states
    
    In general, for ACPI device power management to work, the initial
    power states of devices must be known (otherwise, we wouldn't be able
    to keep track of power resources, for example).  Hence, if it is
    impossible to determine the initial ACPI power states of some
    devices, they can't be regarded as power-manageable using ACPI.
    
    For this reason, modify acpi_bus_get_power_flags() to clear the
    power_manageable flag if acpi_bus_init_power() fails and add some
    extra fallback code to acpi_bus_init_power() to cover broken
    BIOSes that provide _PS0/_PS3 without _PSC for some devices.
    
    Verified to work on my HP nx6325 that has this problem.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Tested-by: Peter Wu <lekensteyn@gmail.com>

Thanks for bisect. Please try the following patch.

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5deb9bd..8adc983 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1186,7 +1186,7 @@ static void acpi_bus_get_power_flags(struct acpi_device *device)
                device->power.states[ACPI_STATE_D3_COLD].flags.os_accessible = 1;
 
        if (acpi_bus_init_power(device)) {
-               acpi_free_power_resources_lists(device);
+               //acpi_free_power_resources_lists(device);
                device->flags.power_manageable = 0;
        }
 }

There is no change with this patch. I have the same kernel panic on boot.

Ok. How about this patch? Currently, have no idea about the cause since we can not see the whole log. Just comment some codes of the bad commit.

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index dd314ef..1776663 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -332,10 +332,10 @@ int acpi_bus_init_power(struct acpi_device *device)
                        return result;
        } else if (state == ACPI_STATE_UNKNOWN) {
                /* No power resources and missing _PSC? Try to force D0. */
-               state = ACPI_STATE_D0;
-               result = acpi_dev_pm_explicit_set(device, state);
-               if (result)
-                       return result;
+//             state = ACPI_STATE_D0;
+//             result = acpi_dev_pm_explicit_set(device, state);
+//             if (result)
+//                     return result;
        }
        device->power.state = state;
        return 0;

I can boot without problem with this patch.

Thanks for test. Please try change the bootup resolution to get more panic log.
Follow the "Update Grub2 configuration" of this link.
http://wiki.sabayon.org/index.php?title=HOWTO:_Using_Custom_Framebuffer_Resolution_with_GRUB2

Let's further narrow the gap, try following the patch. 
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index dd314ef..7a140c7 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -332,7 +332,7 @@ int acpi_bus_init_power(struct acpi_device *device)
                        return result;
        } else if (state == ACPI_STATE_UNKNOWN) {
                /* No power resources and missing _PSC? Try to force D0. */
-               state = ACPI_STATE_D0;
+//             state = ACPI_STATE_D0;
                result = acpi_dev_pm_explicit_set(device, state);
                if (result)
                        return result;

-----


This patch is to produce a log of printing the device path at the panic place
and then sleep 10s to ensure you can get the log before panic.
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 34f5ef1..ed1298c 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -44,6 +44,7 @@
 #include <linux/sysfs.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
+#include <linux/delay.h>
 #include "sleep.h"
 #include "internal.h"

@@ -818,6 +819,9 @@ static void acpi_release_power_resource(struct device *dev)
        struct acpi_device *device = to_acpi_device(dev);
        struct acpi_power_resource *resource;

+       acpi_handle_info(device->handle, "%s \n", __func__);
+       msleep(10000);
+
        resource = container_of(device, struct acpi_power_resource, device);

        mutex_lock(&power_resource_list_lock);

Created attachment 101951 [details]
journalctl log with patch described in comment 18

With the patch in comment 18, I can boot without any problem.

When I use a different resolution for GRUB, the size of screen is modified but then the sceen stays blank. I tried all values given by GRUB with the option vga=ask. Therefore I can not give the whole log when there is an error.

Hi, please try the following patch.

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index dd314ef..1ef070a 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -332,8 +332,8 @@ int acpi_bus_init_power(struct acpi_device *device)
                        return result;
        } else if (state == ACPI_STATE_UNKNOWN) {
                /* No power resources and missing _PSC? Try to force D0. */
-               state = ACPI_STATE_D0;
-               result = acpi_dev_pm_explicit_set(device, state);
+//             state = ACPI_STATE_D0;
+               result = acpi_dev_pm_explicit_set(device, ACPI_STATE_D0);
                if (result)
                        return result;
        }

Created attachment 102091 [details]
log kernel panic with patch of the comment #21

I can not boot with the patch of the comment 21.

I have taken a photo of the log. After a sleep, I had the same panic as previously.

Created attachment 102591 [details]
DSDT.hex

Pleae override the DSDT table with attachment and try again.

cd (kernel source)
cp DSDT.hex include/
make menuconfig

Make the following change.
CONFIG_ACPI_CUSTOM_DSDT_FILE="DSDT.hex"
CONFIG_ACPI_CUSTOM_DSDT=y

Compile and install kernel.

BTW, is there new bios for this machine to upgrade?

I can boot without problem with the custom DSDT file.

There is a new bios but toshiba gives only an executable without any readme. I can try to update the bios if you think it is usefull.

Ok. Please try.

I found there is a Bios problem. PCI0's _PS0 and _PS3 call SPS0/SPS3() but SPS0/SPS3() are not  actually defined in any ACPI tables. My DSDT table is to remove the code of calling SPS0/SPS3(). Why this issue doesn't happen before commit b3785492 is that PCI0's _PS0 was never called.

I had the same panic with the updated bios v6.30.

I had contacted TOSHIBA but they do not seem to care.

When I wait for a proper solution what is the best solution:
  -compile the kernel with the custom DSDT table or
  -compile the kernel with the patch of comment 18.

Thank for your help.

Please provide the new acpidump.

Created attachment 102721 [details]
output of acpidump with bios v6.30

the output of acpidump with the updated bios

Created attachment 102961 [details]
debug.patch

Hi, Please try this debug patch. This is also not final solution. Currently, I can set the SPS0/SPS1() method in the SSDT2/SSDT7.(Sorry, previously my iasl version was a little old and can't translate the SSDT tables on this macine.) I found the SPS0/SPS1() will access SMI io port. This is suspicious. So this debug.patch is to prevent from accessing SMI io port.

Created attachment 103021 [details]
journalctl log with patch described in comment 30

I can boot with the patch from comment 30. However I had many error like (taken from the log):

ACPI: Unable to enable ACPI
usb 3-1: device not accepting address 3, error -110

Created attachment 103051 [details]
debug.patch

Ok. Please try this patch which only prohibits to accessing SMI ioport when issue takes place.

Created attachment 103131 [details]
systemd log with updated bios and patch from comment 32

I can boot whitout any problem with patch from comment 32.

I send the log because there is somme acpi warning and error:
ACPI Error: Null physical address for ACPI table [(null)] (20130117/tbutils-468)
ACPI Warning: BIOS XSDT has NULL entry, using RSDT (20130117/tbutils-682)

Created attachment 103471 [details]
ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization

I suppose you'll be able to boot with this patch too, then.  Can you please try it?

The warning message is from the ACPI core that doesn't like the XSDT table in your system and uses the RSDT one instead.  In indicates a BIOS bug.

You were right. I can boot without any problem with the patch from the comment #34.

Thanks for the confirmation!

Thanks for the fix, much appreciated.

Is the next 3.9.x kernel targeted?

Yes, it should be picked up by the -stable team after it's been merged into the mainline.

Fixed by commit a086bdf (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization).

I need to reopen this bug, because it turns out that commit a086bdf leads to a regression in 3.9.

Moreover, the Tianyu's analysis of the problem turns out to be incorrect and I should have double checked it.

(In reply to comment #41)
> Moreover, the Tianyu's analysis of the problem turns out to be incorrect and
> I
> should have double checked it.

Well, it is correct.  However, the BIOS bug may trigger a bug in the kernel causes the original crash to happen.

Created attachment 105121 [details]
ACPI / PM: Try to run _PS0 for devices without _PSC after all

Jerome, can you please test this patch on 3.10-rc6 and report back?

(In reply to comment #43)
> Created an attachment (id=105121) [details]
> ACPI / PM: Try to run _PS0 for devices without _PSC after all
> 
> Jerome, can you please test this patch on 3.10-rc6 and report back?

Well, I'm taking this back, please don't try this patch. :-)

We'll address the regression introduced by commit a086bdf in a way that's unrelated to this report.

So again: fixed by commit a086bdf (ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization).

Created attachment 105201 [details]
log with patch of the comment #44

It's too late. I just finished to test the patch. I send the log if it can be usefull. I can boot with the new patch but there is many errors in the log. For example :

juin 18 13:41:14 toshiba kernel: ACPI Error: [IRG*] Namespace lookup failure, AE_NOT_FOUND (20130328/psargs-359)
juin 18 13:41:14 toshiba kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.GLAN._PRW] (Node ffff8801c8035b90), AE_NOT_FOUND (20130328/psparse-537)

Well, sorry about that, but thanks for the information. :-)

It pretty much confirms what I thought would happen: things break left and right.