[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and to obtain the GPU power state. Obtaining the GPU state immediately after starting the graphical user session freezes the system.
This code triggers something, which is responsible for the freeze.
--- // Returns 1 if the card is disabled, 0 if enabled static int is_card_disabled(void) { u32 cfg_word; // read first config word which contains Vendor and Device ID. If all bits // are enabled, the device is assumed to be off pci_read_config_dword(dis_dev, 0, &cfg_word); // if one of the bits is not enabled (the card is enabled), the inverted // result will be non-zero and hence logical not will make it 0 ("false") return !~cfg_word; }
static int bbswitch_proc_show(struct seq_file *seqfp, void *p) { // show the card state. Example output: 0000:01:00:00 ON dis_dev_get(); seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev), is_card_disabled() ? "OFF" : "ON"); dis_dev_put(); return 0; } ---
Either dis_dev_get or pci_read_config_dword is the trigger.
Link to the bbswitch module source code: https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and to obtain the GPU power state. Obtaining the GPU state immediately after starting the graphical user session freezes the system.
This code triggers something, which is responsible for the freeze.
// Returns 1 if the card is disabled, 0 if enabled static int is_card_disabled(void) { u32 cfg_word; // read first config word which contains Vendor and Device ID. If all bits // are enabled, the device is assumed to be off pci_read_config_dword(dis_dev, 0, &cfg_word); // if one of the bits is not enabled (the card is enabled), the inverted // result will be non-zero and hence logical not will make it 0 ("false") return !~cfg_word; }
static int bbswitch_proc_show(struct seq_file *seqfp, void *p) { // show the card state. Example output: 0000:01:00:00 ON dis_dev_get(); seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev), is_card_disabled() ? "OFF" : "ON"); dis_dev_put(); return 0; }
Either dis_dev_get or pci_read_config_dword is the trigger.
What happens if you remove the call to is_card_disabled()? Does the system still freeze if you only do the dis_dev_get()/dis_dev_put()?
Link to the bbswitch module source code: https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Just tried it and the system didn't freeze. However it will freeze after some time (few minutes while working).
Seams to be pci_read_config_dword. Where is this exactly defined?
Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and to obtain the GPU power state. Obtaining the GPU state immediately after starting the graphical user session freezes the system.
This code triggers something, which is responsible for the freeze.
// Returns 1 if the card is disabled, 0 if enabled static int is_card_disabled(void) { u32 cfg_word; // read first config word which contains Vendor and Device ID. If all bits // are enabled, the device is assumed to be off pci_read_config_dword(dis_dev, 0, &cfg_word); // if one of the bits is not enabled (the card is enabled), the inverted // result will be non-zero and hence logical not will make it 0 ("false") return !~cfg_word; }
static int bbswitch_proc_show(struct seq_file *seqfp, void *p) { // show the card state. Example output: 0000:01:00:00 ON dis_dev_get(); seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev), is_card_disabled() ? "OFF" : "ON"); dis_dev_put(); return 0; }
Either dis_dev_get or pci_read_config_dword is the trigger.
What happens if you remove the call to is_card_disabled()? Does the system still freeze if you only do the dis_dev_get()/dis_dev_put()?
Link to the bbswitch module source code: https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
Just tried it and the system didn't freeze. However it will freeze after some time (few minutes while working).
Seams to be pci_read_config_dword. Where is this exactly defined?
pci_read_config_dword() is defined in include/linux/pci.h. It calls pci_bus_read_config_dword() which is defined by the PCI_OP_READ() macro in drivers/pci/access.c.
If I understand correctly, this:
dis_dev_get(); pci_read_config_dword(dis_dev, 0, &cfg_word); dis_dev_put();
causes an immediate system hang, but if you only do this:
dis_dev_get(); dis_dev_put();
the system hangs a few minutes later. Right?
Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and to obtain the GPU power state. Obtaining the GPU state immediately after starting the graphical user session freezes the system.
This code triggers something, which is responsible for the freeze.
// Returns 1 if the card is disabled, 0 if enabled static int is_card_disabled(void) { u32 cfg_word; // read first config word which contains Vendor and Device ID. If all bits // are enabled, the device is assumed to be off pci_read_config_dword(dis_dev, 0, &cfg_word); // if one of the bits is not enabled (the card is enabled), the inverted // result will be non-zero and hence logical not will make it 0 ("false") return !~cfg_word; }
static int bbswitch_proc_show(struct seq_file *seqfp, void *p) { // show the card state. Example output: 0000:01:00:00 ON dis_dev_get(); seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev), is_card_disabled() ? "OFF" : "ON"); dis_dev_put(); return 0; }
Either dis_dev_get or pci_read_config_dword is the trigger.
What happens if you remove the call to is_card_disabled()? Does the system still freeze if you only do the dis_dev_get()/dis_dev_put()?
Link to the bbswitch module source code: https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks for pointing it out.
Yeah that's right. The system will hang randomly a few minutes later, because some certain actions in the graphical user session will trigger the freeze.
I had a look at the function body of pci_read_config_dword:
#define PCI_OP_READ(size, type, len) \ int pci_bus_read_config_##size \ (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \ { \ int res; \ unsigned long flags; \ u32 data = 0; \ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \ raw_spin_lock_irqsave(&pci_lock, flags); \ res = bus->ops->read(bus, devfn, pos, len, &data); \ *value = (type)data; \ raw_spin_unlock_irqrestore(&pci_lock, flags); \ return res; \ }
I guess, that bus->ops->read(...) might be the trigger. Any hints how to continue debugging?
Cheers, Roland
Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas:
On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
Just tried it and the system didn't freeze. However it will freeze after some time (few minutes while working).
Seams to be pci_read_config_dword. Where is this exactly defined?
pci_read_config_dword() is defined in include/linux/pci.h. It calls pci_bus_read_config_dword() which is defined by the PCI_OP_READ() macro in drivers/pci/access.c.
If I understand correctly, this:
dis_dev_get(); pci_read_config_dword(dis_dev, 0, &cfg_word); dis_dev_put();
causes an immediate system hang, but if you only do this:
dis_dev_get(); dis_dev_put();
the system hangs a few minutes later. Right?
Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and to obtain the GPU power state. Obtaining the GPU state immediately after starting the graphical user session freezes the system.
This code triggers something, which is responsible for the freeze.
// Returns 1 if the card is disabled, 0 if enabled static int is_card_disabled(void) { u32 cfg_word; // read first config word which contains Vendor and Device ID. If all bits // are enabled, the device is assumed to be off pci_read_config_dword(dis_dev, 0, &cfg_word); // if one of the bits is not enabled (the card is enabled), the inverted // result will be non-zero and hence logical not will make it 0 ("false") return !~cfg_word; }
static int bbswitch_proc_show(struct seq_file *seqfp, void *p) { // show the card state. Example output: 0000:01:00:00 ON dis_dev_get(); seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev), is_card_disabled() ? "OFF" : "ON"); dis_dev_put(); return 0; }
Either dis_dev_get or pci_read_config_dword is the trigger.
What happens if you remove the call to is_card_disabled()? Does the system still freeze if you only do the dis_dev_get()/dis_dev_put()?
Link to the bbswitch module source code: https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
Thanks for pointing it out.
Yeah that's right. The system will hang randomly a few minutes later, because some certain actions in the graphical user session will trigger the freeze.
I had a look at the function body of pci_read_config_dword:
#define PCI_OP_READ(size, type, len) \ int pci_bus_read_config_##size \ (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \ { \ int res; \ unsigned long flags; \ u32 data = 0; \ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \ raw_spin_lock_irqsave(&pci_lock, flags); \ res = bus->ops->read(bus, devfn, pos, len, &data); \ *value = (type)data; \ raw_spin_unlock_irqrestore(&pci_lock, flags); \ return res; \ }
I guess, that bus->ops->read(...) might be the trigger. Any hints how to continue debugging?
It's not likely that the problem is in the bus->ops->read() path. That is used by every device driver, so a problem there would cause more serious problems than what you're seeing.
My guess would be some problem in the video driver or the bbswitch thing.
Am 30.08.2016 um 01:54 schrieb Bjorn Helgaas:
On Mon, Aug 29, 2016 at 09:55:56PM +0200, Roland Singer wrote:
Just tried it and the system didn't freeze. However it will freeze after some time (few minutes while working).
Seams to be pci_read_config_dword. Where is this exactly defined?
pci_read_config_dword() is defined in include/linux/pci.h. It calls pci_bus_read_config_dword() which is defined by the PCI_OP_READ() macro in drivers/pci/access.c.
If I understand correctly, this:
dis_dev_get(); pci_read_config_dword(dis_dev, 0, &cfg_word); dis_dev_put();
causes an immediate system hang, but if you only do this:
dis_dev_get(); dis_dev_put();
the system hangs a few minutes later. Right?
Am 29.08.2016 um 21:07 schrieb Bjorn Helgaas:
On Mon, Aug 29, 2016 at 08:46:17PM +0200, Roland Singer wrote:
Hi Bjorn,
I am using the bbswitch kernel module to switch off/on the GPU and to obtain the GPU power state. Obtaining the GPU state immediately after starting the graphical user session freezes the system.
This code triggers something, which is responsible for the freeze.
// Returns 1 if the card is disabled, 0 if enabled static int is_card_disabled(void) { u32 cfg_word; // read first config word which contains Vendor and Device ID. If all bits // are enabled, the device is assumed to be off pci_read_config_dword(dis_dev, 0, &cfg_word); // if one of the bits is not enabled (the card is enabled), the inverted // result will be non-zero and hence logical not will make it 0 ("false") return !~cfg_word; }
static int bbswitch_proc_show(struct seq_file *seqfp, void *p) { // show the card state. Example output: 0000:01:00:00 ON dis_dev_get(); seq_printf(seqfp, "%s %s\n", dev_name(&dis_dev->dev), is_card_disabled() ? "OFF" : "ON"); dis_dev_put(); return 0; }
Either dis_dev_get or pci_read_config_dword is the trigger.
What happens if you remove the call to is_card_disabled()? Does the system still freeze if you only do the dis_dev_get()/dis_dev_put()?
Link to the bbswitch module source code: https://github.com/Bumblebee-Project/bbswitch/blob/master/bbswitch.c#L333
Am 29.08.2016 um 18:02 schrieb Bjorn Helgaas:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote: > Hi, > > hope somebody can help me fix this kernel problem which affects the following machines: > > - Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected) > - MSI GE62 Apache Pro (i7-6700HQ/GTX 960M) > - Gigabyte P35V5 (i7-6700HQ/GTX 970M) > - Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016) > > > The kernel freezes if the graphical user session (Xorg & Wayland) is > started with a switched off discrete GPU card (NVIDIA). > If the discrete GPU is switched off after the graphical session start, > then everything works as expected, until the graphical session is restarted. > > This problem seams to be linked to specific BIOS settings. If the computer > is started with the following command line: > > acpi_osi=! acpi_osi="Windows 2009" > > then the kernel freeze does not occur anymore. However this required a special > ACPI DSDT firmware patch for the Razer Blade 2016 laptop: > > https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt > > I strongly recommend to fix this in the kernel and I am ready to help and solve > this problem with some help. > > Here is a link to the GitHub issue with further information: > > https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121... > > Here are some more detailed information: > > https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt > > Hope somebody can help.
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30 August 2016 at 14:06, Bjorn Helgaas helgaas@kernel.org wrote:
On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
Thanks for pointing it out.
Yeah that's right. The system will hang randomly a few minutes later, because some certain actions in the graphical user session will trigger the freeze.
I had a look at the function body of pci_read_config_dword:
#define PCI_OP_READ(size, type, len) \ int pci_bus_read_config_##size \ (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \ { \ int res; \ unsigned long flags; \ u32 data = 0; \ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \ raw_spin_lock_irqsave(&pci_lock, flags); \ res = bus->ops->read(bus, devfn, pos, len, &data); \ *value = (type)data; \ raw_spin_unlock_irqrestore(&pci_lock, flags); \ return res; \ }
I guess, that bus->ops->read(...) might be the trigger. Any hints how to continue debugging?
It's not likely that the problem is in the bus->ops->read() path. That is used by every device driver, so a problem there would cause more serious problems than what you're seeing.
My guess would be some problem in the video driver or the bbswitch thing.
FWIW I'm inclined to call it a bbswitch bug. It can (and does when needed) power off the dedicated GPU.
Depending on the platform different methods are used:
Sometimes the GPU driver will get 0xffffffff (or similar) when trying to read from the device mmio space. While one can say that the driver should attribute for this, IMHO it's a bad idea to have two drivers controlling the same hardware, let alone without any coordination between them.
IIRC in some cases the device can disappear from the PCI bus (not 100% sure this one). In which case a simple read can lead to a wide range of fireworks.
Disclaimer: it's been a while since I've looked into bbswitch so things might have changed/improved.
Regards, Emil
I tried these scenarios:
1. Booted the system without the bbswitch module. The nouveau module was loaded and is responsible for the power management of the GPU. The graphical session freezes after some minutes...
2. Booted the system without bbswitch and with nouveau blacklisted. Manually loaded bbswitch to switch off the discrete GPU. Same freeze after a while or by explicitly obtaining the GPU state.
Is there a possibility to switch off the discrete card without bbswitch? If this is possible, then I could test this without nouveau and bbswitch at all. If the system hangs, then it is not the video driver nor bbswitch.
Am 30.08.2016 um 16:08 schrieb Emil Velikov:
On 30 August 2016 at 14:06, Bjorn Helgaas helgaas@kernel.org wrote:
On Tue, Aug 30, 2016 at 12:08:57PM +0200, Roland Singer wrote:
Thanks for pointing it out.
Yeah that's right. The system will hang randomly a few minutes later, because some certain actions in the graphical user session will trigger the freeze.
I had a look at the function body of pci_read_config_dword:
#define PCI_OP_READ(size, type, len) \ int pci_bus_read_config_##size \ (struct pci_bus *bus, unsigned int devfn, int pos, type *value) \ { \ int res; \ unsigned long flags; \ u32 data = 0; \ if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; \ raw_spin_lock_irqsave(&pci_lock, flags); \ res = bus->ops->read(bus, devfn, pos, len, &data); \ *value = (type)data; \ raw_spin_unlock_irqrestore(&pci_lock, flags); \ return res; \ }
I guess, that bus->ops->read(...) might be the trigger. Any hints how to continue debugging?
It's not likely that the problem is in the bus->ops->read() path. That is used by every device driver, so a problem there would cause more serious problems than what you're seeing.
My guess would be some problem in the video driver or the bbswitch thing.
FWIW I'm inclined to call it a bbswitch bug. It can (and does when needed) power off the dedicated GPU.
Depending on the platform different methods are used:
Sometimes the GPU driver will get 0xffffffff (or similar) when trying to read from the device mmio space. While one can say that the driver should attribute for this, IMHO it's a bad idea to have two drivers controlling the same hardware, let alone without any coordination between them.
IIRC in some cases the device can disappear from the PCI bus (not 100% sure this one). In which case a simple read can lead to a wide range of fireworks.
Disclaimer: it's been a while since I've looked into bbswitch so things might have changed/improved.
Regards, Emil -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer roland.singer@desertbit.com wrote:
I tried these scenarios:
Booted the system without the bbswitch module. The nouveau module was loaded and is responsible for the power management of the GPU. The graphical session freezes after some minutes...
Booted the system without bbswitch and with nouveau blacklisted. Manually loaded bbswitch to switch off the discrete GPU. Same freeze after a while or by explicitly obtaining the GPU state.
Is there a possibility to switch off the discrete card without bbswitch? If this is possible, then I could test this without nouveau and bbswitch at all. If the system hangs, then it is not the video driver nor bbswitch.
You can use acpi_call (a random search points to https://github.com/mkottman/acpi_call, but I don't know if that's the "official" version) - need to find the right method to call, but that's basically all it takes to acpi-suspend a gpu.
Separately, there was a recent fix to ... something, including but not limited to nouveau, involving hangs on gpu suspend on newer laptops. I don't think it's upstream yet. Look for patches from Lukas Wunner.
-ilia
On Tue, Aug 30, 2016 at 11:44 AM, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer roland.singer@desertbit.com wrote:
I tried these scenarios:
Booted the system without the bbswitch module. The nouveau module was loaded and is responsible for the power management of the GPU. The graphical session freezes after some minutes...
Booted the system without bbswitch and with nouveau blacklisted. Manually loaded bbswitch to switch off the discrete GPU. Same freeze after a while or by explicitly obtaining the GPU state.
Is there a possibility to switch off the discrete card without bbswitch? If this is possible, then I could test this without nouveau and bbswitch at all. If the system hangs, then it is not the video driver nor bbswitch.
You can use acpi_call (a random search points to https://github.com/mkottman/acpi_call, but I don't know if that's the "official" version) - need to find the right method to call, but that's basically all it takes to acpi-suspend a gpu.
Separately, there was a recent fix to ... something, including but not limited to nouveau, involving hangs on gpu suspend on newer laptops. I don't think it's upstream yet. Look for patches from Lukas Wunner.
Er oops. Looks like I misremembered. Patches are from Peter Wu, and at least one of them is in v4.8-rc1:
commit 692a17dcc2922a91c6bcf11b3321503a3377b1b1 Author: Peter Wu peter@lekensteyn.nl Date: Fri Jul 15 15:12:18 2016 +0200
drm/nouveau/acpi: fix lockup with PCIe runtime PM
along with a number of other related patches. It's not clear which kernel you were trying this with... can you give v4.8-rcN a shot?
-ilia
On 30 August 2016 at 16:25, Roland Singer roland.singer@desertbit.com wrote:
I tried these scenarios:
Booted the system without the bbswitch module. The nouveau module was loaded and is responsible for the power management of the GPU. The graphical session freezes after some minutes...
Booted the system without bbswitch and with nouveau blacklisted. Manually loaded bbswitch to switch off the discrete GPU. Same freeze after a while or by explicitly obtaining the GPU state.
Is there a possibility to switch off the discrete card without bbswitch? If this is possible, then I could test this without nouveau and bbswitch at all. If the system hangs, then it is not the video driver nor bbswitch.
As Ilia mentioned acpi_call should do it. You can also check with the nouveau/bbwswitch code to see which ones they use in your case and bash it manually. It might be that the 'wrong one' gets used thus things going horribly wrong.
Regards, Emil
I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel. The result is the same. There is no difference if bbswitch of acpi_call is used. However I noticed following:
1. The nouveau driver is broken in both kernel version and is responsible for the freezes while gathering power state information with bbswitch. Sometimes while shutting the system down, everything except the LCD screen is switched off. This only happens with nouveau. I noticed following error log messages:
kernel: nouveau 0000:01:00.0: fb: 6144 MiB GDDR5 kernel: nouveau 0000:01:00.0: priv: HUB0: 10ecc0 ffffffff (1e40822c) kernel: nouveau 0000:01:00.0: DRM: VRAM: 6144 MiB kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB kernel: nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid kernel: nouveau 0000:01:00.0: DRM: DCB version 4.1 kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid
2. -> Boot with nouveau module loaded -> switch off the discrete GPU with bbswitch or acpi_call -> start X11 -> obtaining power state with bbswitch freezes the system -> or working with the system for some minutes freezes the system
3. -> Boot with nouveau module blacklisted -> switch off the discrete GPU -> start X11 -> system immediately freezes
4. -> Boot with nouveau module blacklisted -> switch off the discrete GPU -> start Wayland -> system runs - Note: I tried this for couple of days with 4.6 and 4.7 mainline and the system freezed randomly after some time. However I have to test if this is still present with 4.7.2 and 4.8 mainline. Right now it seams to be fine. -> running Xwayland (does not depend on the GPU power state) kills performance! the system freezes for several seconds... So working with Wayland is also no solution.
My conclusion:
1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs. I would love to help here.
2. X11 is just broken and is not capable to start the graphical session if the nvidia GPU is not handled by any video driver (kernel module). Even forcing X11 to ignore the discrete GPU doesn't help.
Setting the command line arguments to:
acpi_osi=! acpi_osi="Windows 2009"
fixes the issues with X11 but other things break... What the hell is going on?! :/
Am 30.08.2016 um 17:48 schrieb Emil Velikov:
On 30 August 2016 at 16:25, Roland Singer roland.singer@desertbit.com wrote:
I tried these scenarios:
Booted the system without the bbswitch module. The nouveau module was loaded and is responsible for the power management of the GPU. The graphical session freezes after some minutes...
Booted the system without bbswitch and with nouveau blacklisted. Manually loaded bbswitch to switch off the discrete GPU. Same freeze after a while or by explicitly obtaining the GPU state.
Is there a possibility to switch off the discrete card without bbswitch? If this is possible, then I could test this without nouveau and bbswitch at all. If the system hangs, then it is not the video driver nor bbswitch.
As Ilia mentioned acpi_call should do it. You can also check with the nouveau/bbwswitch code to see which ones they use in your case and bash it manually. It might be that the 'wrong one' gets used thus things going horribly wrong.
Regards, Emil
On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer roland.singer@desertbit.com wrote:
My conclusion:
- Nouveau has couple of problems with GTX 9** M Nvidia GPUs. I would love to help here.
nouveau + bbswitch will always end in tears. You're going behind the driver's back and messing around with state it believes it is managing. What if you just use nouveau and let it auto-power-off the GPU like it's designed to, with v4.8-rc?
-ilia
I configured bbswitch to not set any states automatically... So it's possible to obtain and verify the GPU power state.
However I removed the bbswitch module and booted with nouveau.
Kernel 4.7.2: nouveau switches the discrete GPU off. I can't trigger the freeze, because bbswitch is missing. I'll work with the system and see if it will freeze.
Kernel 4.8-rc4: nouveau does not care about the power state and the discrete GPU is never switched off. I will notice this, because the second cooling FAN will stop... Same log messages as send before.
Am 30.08.2016 um 19:43 schrieb Ilia Mirkin:
On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer roland.singer@desertbit.com wrote:
My conclusion:
- Nouveau has couple of problems with GTX 9** M Nvidia GPUs. I would love to help here.
nouveau + bbswitch will always end in tears. You're going behind the driver's back and messing around with state it believes it is managing. What if you just use nouveau and let it auto-power-off the GPU like it's designed to, with v4.8-rc?
-ilia
On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer roland.singer@desertbit.com wrote:
I configured bbswitch to not set any states automatically... So it's possible to obtain and verify the GPU power state.
However I removed the bbswitch module and booted with nouveau.
Kernel 4.7.2: nouveau switches the discrete GPU off. I can't trigger the freeze, because bbswitch is missing. I'll work with the system and see if it will freeze.
Kernel 4.8-rc4: nouveau does not care about the power state and the discrete GPU is never switched off. I will notice this, because the second cooling FAN will stop... Same log messages as send before.
That's surprising. I believe there's an issue with the new logic when there's an HDMI audio subdevice. However that only appears if there's a cable plugged in, at least in the systems Peter tested. You should be able to see whether it's there or not with 'lspci'.
You can check for sure by looking in the vgaswitcheroo state. It should say DynOff when it's powered off.
Either way, I think using bbswitch + nouveau isn't supported by anyone, so if you want to use it that way, you're on your own. (You may want to load nouveau with runpm=0 so that nouveau doesn't try to manage the GPU suspend stuff.)
-ilia
On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote:
On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer roland.singer@desertbit.com wrote:
I configured bbswitch to not set any states automatically... So it's possible to obtain and verify the GPU power state.
However I removed the bbswitch module and booted with nouveau.
Kernel 4.7.2: nouveau switches the discrete GPU off. I can't trigger the freeze, because bbswitch is missing. I'll work with the system and see if it will freeze.
Kernel 4.8-rc4: nouveau does not care about the power state and the discrete GPU is never switched off. I will notice this, because the second cooling FAN will stop... Same log messages as send before.
That's surprising. I believe there's an issue with the new logic when there's an HDMI audio subdevice. However that only appears if there's a cable plugged in, at least in the systems Peter tested. You should be able to see whether it's there or not with 'lspci'.
I doubt that the audio device is responsible here, that should only show up after following very specific steps (runtime suspend/resume (PCI or ACPI magic), remove PCI device, rescan bus).
You can check for sure by looking in the vgaswitcheroo state. It should say DynOff when it's powered off.
Either way, I think using bbswitch + nouveau isn't supported by anyone, so if you want to use it that way, you're on your own. (You may want to load nouveau with runpm=0 so that nouveau doesn't try to manage the GPU suspend stuff.)
I understood that Roland's intent is to check the power state, not use the suspend functionality of bbswitch, if you load bbswitch without module options amd do not write to /proc/bbswitch, then it allows you to read out the actual status (you could also just use lspci -H1 for that though).
Am 30.08.2016 um 21:21 schrieb Peter Wu:
On Tue, Aug 30, 2016 at 02:13:46PM -0400, Ilia Mirkin wrote:
On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer roland.singer@desertbit.com wrote:
I configured bbswitch to not set any states automatically... So it's possible to obtain and verify the GPU power state.
However I removed the bbswitch module and booted with nouveau.
Kernel 4.7.2: nouveau switches the discrete GPU off. I can't trigger the freeze, because bbswitch is missing. I'll work with the system and see if it will freeze.
Kernel 4.8-rc4: nouveau does not care about the power state and the discrete GPU is never switched off. I will notice this, because the second cooling FAN will stop... Same log messages as send before.
That's surprising. I believe there's an issue with the new logic when there's an HDMI audio subdevice. However that only appears if there's a cable plugged in, at least in the systems Peter tested. You should be able to see whether it's there or not with 'lspci'.
I doubt that the audio device is responsible here, that should only show up after following very specific steps (runtime suspend/resume (PCI or ACPI magic), remove PCI device, rescan bus).
You can check for sure by looking in the vgaswitcheroo state. It should say DynOff when it's powered off.
Either way, I think using bbswitch + nouveau isn't supported by anyone, so if you want to use it that way, you're on your own. (You may want to load nouveau with runpm=0 so that nouveau doesn't try to manage the GPU suspend stuff.)
I understood that Roland's intent is to check the power state, not use the suspend functionality of bbswitch, if you load bbswitch without module options amd do not write to /proc/bbswitch, then it allows you to read out the actual status (you could also just use lspci -H1 for that though).
lspci -H1 works perfect. Thanks. Just tried to verify the output with lspci -H1. I unloaded the nouveau module and modprobe freezed with:
$ modprobe -r nouveau nouveau 0000:01:00.0: pci: failed to adjust lnkctl speed nouveau 0000:01:00.0: fb: init failed. -22 nouveau 0000:01:00.0: init failed with -22 nouveau: DRM:00000000:00000000: init failed with -22 nouveau: DRM:00000000:00000000: init failed with -22
Am 30.08.2016 um 20:13 schrieb Ilia Mirkin:
On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer roland.singer@desertbit.com wrote:
I configured bbswitch to not set any states automatically... So it's possible to obtain and verify the GPU power state.
However I removed the bbswitch module and booted with nouveau.
Kernel 4.7.2: nouveau switches the discrete GPU off. I can't trigger the freeze, because bbswitch is missing. I'll work with the system and see if it will freeze.
Kernel 4.8-rc4: nouveau does not care about the power state and the discrete GPU is never switched off. I will notice this, because the second cooling FAN will stop... Same log messages as send before.
That's surprising. I believe there's an issue with the new logic when there's an HDMI audio subdevice. However that only appears if there's a cable plugged in, at least in the systems Peter tested. You should be able to see whether it's there or not with 'lspci'.
You can check for sure by looking in the vgaswitcheroo state. It should say DynOff when it's powered off.
Either way, I think using bbswitch + nouveau isn't supported by anyone, so if you want to use it that way, you're on your own. (You may want to load nouveau with runpm=0 so that nouveau doesn't try to manage the GPU suspend stuff.)
-ilia
Kernel 4.8-rc4:
While running lspci, following kernel log message was printed on the TTY:
nouveau: 0000:01:00:0: priv: HUB0: 6013d4 0000573f (1f408200) nouveau: 0000:01:00:0: priv: HUB0: 10ecc0 ffffffff (1940822c)
This is my output of lspci:
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 07) 00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06) 00:08.0 System peripheral: Intel Corporation Skylake Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31) 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #0 (rev 31) 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #1 (rev 31) 00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 (rev f1) 00:1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6 (rev f1) 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1) 00:1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13 (rev f1) 00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO UART #0 (rev 31) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31) 00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31) 00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31) 01:00.0 3D controller: NVIDIA Corporation GM204M [GeForce GTX 970M] (rev a1) 3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 3d:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)
On 30 August 2016 at 18:37, Roland Singer roland.singer@desertbit.com wrote:
I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel. The result is the same. There is no difference if bbswitch of acpi_call is used. However I noticed following:
- The nouveau driver is broken in both kernel version and is responsible for the freezes while gathering power state information with bbswitch. Sometimes while shutting the system down, everything except the LCD screen is switched off. This only happens with nouveau. I noticed following error log messages:
I second Ilia here. Using bbswitch in conjunction with any driver (be that nouveau or the proprietary one) is a bad idea.
kernel: nouveau 0000:01:00.0: fb: 6144 MiB GDDR5 kernel: nouveau 0000:01:00.0: priv: HUB0: 10ecc0 ffffffff (1e40822c) kernel: nouveau 0000:01:00.0: DRM: VRAM: 6144 MiB kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB kernel: nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid kernel: nouveau 0000:01:00.0: DRM: DCB version 4.1 kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid
- -> Boot with nouveau module loaded -> switch off the discrete GPU with bbswitch or acpi_call -> start X11 -> obtaining power state with bbswitch freezes the system -> or working with the system for some minutes freezes the system
(If Ilia's suggestions does not help) Confirm if the freeze is due to/as the GPU is powered on or off.
- -> Boot with nouveau module blacklisted -> switch off the discrete GPU -> start X11 -> system immediately freezes
It's perfectly possible that the discrete GPU is set as boot one and X goes angry since there's no driver/way to bring it up.
- -> Boot with nouveau module blacklisted -> switch off the discrete GPU -> start Wayland -> system runs - Note: I tried this for couple of days with 4.6 and 4.7 mainline and the system freezed randomly after some time. However I have to test if this is still present with 4.7.2 and 4.8 mainline. Right now it seams to be fine. -> running Xwayland (does not depend on the GPU power state) kills performance! the system freezes for several seconds... So working with Wayland is also no solution.
My conclusion:
Nouveau has couple of problems with GTX 9** M Nvidia GPUs. I would love to help here.
X11 is just broken and is not capable to start the graphical session if the nvidia GPU is not handled by any video driver (kernel module). Even forcing X11 to ignore the discrete GPU doesn't help.
Out of curiosity: how did you force X to ignore the device ?
Setting the command line arguments to:
acpi_osi=! acpi_osi="Windows 2009"fixes the issues with X11 but other things break... What the hell is going on?! :/
You can check if it's the boot_vga assumption with
Check wh
You're a victum of the Windows specific fun (quirks?) in
Am 30.08.2016 um 17:48 schrieb Emil Velikov:
On 30 August 2016 at 16:25, Roland Singer roland.singer@desertbit.com wrote:
I tried these scenarios:
Booted the system without the bbswitch module. The nouveau module was loaded and is responsible for the power management of the GPU. The graphical session freezes after some minutes...
Booted the system without bbswitch and with nouveau blacklisted. Manually loaded bbswitch to switch off the discrete GPU. Same freeze after a while or by explicitly obtaining the GPU state.
Is there a possibility to switch off the discrete card without bbswitch? If this is possible, then I could test this without nouveau and bbswitch at all. If the system hangs, then it is not the video driver nor bbswitch.
As Ilia mentioned acpi_call should do it. You can also check with the nouveau/bbwswitch code to see which ones they use in your case and bash it manually. It might be that the 'wrong one' gets used thus things going horribly wrong.
Regards, Emil
On 30 August 2016 at 19:09, Emil Velikov emil.l.velikov@gmail.com wrote:
On 30 August 2016 at 18:37, Roland Singer roland.singer@desertbit.com wrote:
I am running 4.7.2, but I also just tried the 4.8.0-rc4 mainline kernel. The result is the same. There is no difference if bbswitch of acpi_call is used. However I noticed following:
- The nouveau driver is broken in both kernel version and is responsible for the freezes while gathering power state information with bbswitch. Sometimes while shutting the system down, everything except the LCD screen is switched off. This only happens with nouveau. I noticed following error log messages:
I second Ilia here. Using bbswitch in conjunction with any driver (be that nouveau or the proprietary one) is a bad idea.
kernel: nouveau 0000:01:00.0: fb: 6144 MiB GDDR5 kernel: nouveau 0000:01:00.0: priv: HUB0: 10ecc0 ffffffff (1e40822c) kernel: nouveau 0000:01:00.0: DRM: VRAM: 6144 MiB kernel: nouveau 0000:01:00.0: DRM: GART: 1048576 MiB kernel: nouveau 0000:01:00.0: DRM: Pointer to TMDS table invalid kernel: nouveau 0000:01:00.0: DRM: DCB version 4.1 kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid
- -> Boot with nouveau module loaded -> switch off the discrete GPU with bbswitch or acpi_call -> start X11 -> obtaining power state with bbswitch freezes the system -> or working with the system for some minutes freezes the system
(If Ilia's suggestions does not help) Confirm if the freeze is due to/as the GPU is powered on or off.
- -> Boot with nouveau module blacklisted -> switch off the discrete GPU -> start X11 -> system immediately freezes
It's perfectly possible that the discrete GPU is set as boot one and X goes angry since there's no driver/way to bring it up.
- -> Boot with nouveau module blacklisted -> switch off the discrete GPU -> start Wayland -> system runs - Note: I tried this for couple of days with 4.6 and 4.7 mainline and the system freezed randomly after some time. However I have to test if this is still present with 4.7.2 and 4.8 mainline. Right now it seams to be fine. -> running Xwayland (does not depend on the GPU power state) kills performance! the system freezes for several seconds... So working with Wayland is also no solution.
My conclusion:
Nouveau has couple of problems with GTX 9** M Nvidia GPUs. I would love to help here.
X11 is just broken and is not capable to start the graphical session if the nvidia GPU is not handled by any video driver (kernel module). Even forcing X11 to ignore the discrete GPU doesn't help.
Out of curiosity: how did you force X to ignore the device ?
Setting the command line arguments to:
acpi_osi=! acpi_osi="Windows 2009"fixes the issues with X11 but other things break... What the hell is going on?! :/
You can check if it's the boot_vga assumption with
[Sorry about that] ... cat /sys/class/drm/card*/device/{boot_vga,vendor}
If the output changes them my assumption holds true. -Emil
Am 30.08.2016 um 20:09 schrieb Emil Velikov:
I second Ilia here. Using bbswitch in conjunction with any driver (be that nouveau or the proprietary one) is a bad idea.
I removed bbswitch from my system and will use vgaswitcheroo to check the GPU power state from now.
(If Ilia's suggestions does not help) Confirm if the freeze is due to/as the GPU is powered on or off.
Yeah, the freeze is caused by the switched off GPU. Waited for the nouveau driver to switch it off, before starting the graphical user interface...
Out of curiosity: how did you force X to ignore the device ?
I tried to tell X11 to ignore the device with the following configuration:
Section "Device" Identifier "Nvidia" VendorName "NVIDIA Corporation" Option "Ignore" "true" EndSection
You can check if it's the boot_vga assumption with cat /sys/class/drm/card*/device/{boot_vga,vendor} If the output changes them my assumption holds true.
Output did not change:
1 0x8086
0x8086 is the vendor ID of intel. So that's ok...
On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
1. Load nouveau. 2. Wait for it to runtime suspend. 2. Invoke 'lspci', this resumes the Nvidia PCI device via nouveau. 3. lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
If you use the external bbswitch module, the effect is the same. I have been trying to debug this for some time on nouveau with no luck. The PCI/PM D3cold patches from Mika makes no difference.
Runtime resume via nouveau triggers some ACPI methods (I'll assume the Windows 8-style PR method and take the Clevo P651 as example):
_SB.PCI0.PEG0.PG00._ON () -> _SB.PCI0.PGON (0)
Then:
Method (PGON, 1, Serialized) { PION = Arg0 // note: 0 for PG00 // ... If ((OSYS != 0x07DF)) { /* Not Windows 2015 (Windows 10), see below */ } Else { LKEN (PION) } // this is the infinite loop: it tries to bring the PCIe link to // full speed, but fails to do so. While ((_SB.PCI0.PEG0.LNKS < 0x07)) { Local0 = 0x20 While (Local0) { If ((_SB.PCI0.PEG0.LNKS < 0x07)) { Stall (0x64) Local0-- } Else { Break } } If ((Local0 == Zero)) { _SB.PCI0.PEG0.RTLK = One Stall (0x64) } } // ... }
Without any workaround, this piece of code is invoked:
Method (LKEN, 1, NotSerialized) { Local3 = (CPEX & 0x0F) // CPEX at 0x5ff9be7f and has value 000506e3 If ((Local3 == Zero)) { /* Similar to below, but with Q0L0 -> P0L0 (register 0xBC bit 6) */ } ElseIf ((Local3 != Zero)) { If ((Arg0 == Zero)) { /* Enter L0 Activate state. * (LKDS tries to enter L2, deep-energy-saving state.) */ Q0L0 = One // register 0x249 bit 0; _SB.PCI0.OPG0.Q0L0 00:01.0 Sleep (0x10) Local0 = Zero While (Q0L0) { If ((Local0 > 0x04)) { Break } Sleep (0x10) Local0++ } } else { /* other cases, but we are only interested in PGON(0) */ } } }
The acpi_osi="!Windows 2015" workaround will invoke this instead:
If ((OSYS != 0x07DF)) { If ((PION == Zero)) { P0AP = Zero /* PGOF writes 3 */ P0RM = Zero /* PGOF writes 1 */ } If ((PBGE != Zero)) { /* Observed to be false (PBGE == 0) */ If (SBDL (PION)) { PUAB (PION) CBDL = GUBC (PION) MBDL = GMXB (PION) If ((CBDL > MBDL)) { CBDL = MBDL /* _SB_.PCI0.MBDL */ } PDUB (PION, CBDL) } } If ((PION == Zero)) { P0LD = Zero /* Link Disable = 0, PGOF sets 1 instead. */ P0TR = One /* Train? (PGOF does not set this). */ TCNT = Zero While ((TCNT < LDLY)) { /* LDLY = 300 */ If ((P0VC == Zero)) { /* VC Negotiation Pending 0 means VC negotation is complete. */ Break } Sleep (0x10) TCNT += 0x10 /* At most 19 iterations, sleeping for 304ms. */ } } }
The comments above are my own interpretation based on the acpidumps I extracted from the machine. These notes and ACPI tables can be found at https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt https://github.com/Lekensteyn/acpi-stuff/tree/master/dsl/Clevo_P651RA
Other affected devices have similar code, differences are small: - No check for LNKS (avoids the infinite loop, but device is still off) - Instead of a check for != "Windows 2015", they check for == "Windows 2009" or even for == "Windows 2009" || "Windows 2013" (Dell Inspiron 7559).
The tested kernels (with bbswitch or nouveau) were Linux 4.4.0, 4.6, 4.7 (nouveau + PCI/PM + nouveau PR patches). The PCIe device is something from the GTX 9xxM family in all cases.
I have a bunch of PCI config dumps from Windows and Linux, but there is nothing extraordinary. Also did an ACPI trace via a Checked/Debug build of Windows, but it just confirms that the ACPI method we use for the Nvidia device is the correct one.
Let me know if you need more information, I would be glad to provide.
Kind regards, Peter
On Tue, Aug 23, 2016 at 11:23:45AM +0200, Roland Singer wrote:
Hi,
hope somebody can help me fix this kernel problem which affects the following machines:
- Clevo P651RA (i7-6700HQ/GTX 965M, part of the P6xxRx family which are also affected)
- MSI GE62 Apache Pro (i7-6700HQ/GTX 960M)
- Gigabyte P35V5 (i7-6700HQ/GTX 970M)
- Razer Blade 14" (2016) (i7-6700HQ/GTX 970M) (BIOS 5.11, 04/07/2016)
The kernel freezes if the graphical user session (Xorg & Wayland) is started with a switched off discrete GPU card (NVIDIA). If the discrete GPU is switched off after the graphical session start, then everything works as expected, until the graphical session is restarted.
This problem seams to be linked to specific BIOS settings. If the computer is started with the following command line:
acpi_osi=! acpi_osi="Windows 2009"
then the kernel freeze does not occur anymore. However this required a special ACPI DSDT firmware patch for the Razer Blade 2016 laptop:
https://github.com/m4ng0squ4sh/razer_blade_14_2016_acpi_dsdt
I strongly recommend to fix this in the kernel and I am ready to help and solve this problem with some help.
Here is a link to the GitHub issue with further information:
https://github.com/Bumblebee-Project/Bumblebee/issues/764#issuecomment-24121...
Here are some more detailed information:
https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
Hope somebody can help.
Am 30.08.2016 um 21:53 schrieb Peter Wu:
On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
- Load nouveau.
- Wait for it to runtime suspend.
- Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
- lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
I can confirm this. Same result on my machine.
Here is a link to my ACPI tables: https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+fi...
The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
Method (PGON, 1, Serialized) { /* ... */
GPPR (PION, One) If ((OSYS == 0x07D9)) /* Is Windows 2009 - In my case, setting to Windows 2009 only works! */ { If ((PION == Zero)) { P0AP = Zero P0RM = Zero } ElseIf ((PION == One)) { P1AP = Zero P1RM = Zero } ElseIf ((PION == 0x02)) { P2AP = Zero P2RM = Zero }
If ((PBGE != Zero)) { If (SBDL (PION)) { PUAB (PION) CBDL = GUBC (PION) MBDL = GMXB (PION) If ((CBDL > MBDL)) { CBDL = MBDL /* _SB_.PCI0.MBDL */ }
PDUB (PION, CBDL) } }
If ((PION == Zero)) { P0LD = Zero P0TR = One TCNT = Zero While ((TCNT < LDLY)) { If ((P0VC == Zero)) { Break }
Sleep (0x10) TCNT += 0x10 } } ElseIf ((PION == One)) { P1LD = Zero P1TR = One TCNT = Zero While ((TCNT < LDLY)) { If ((P1VC == Zero)) { Break }
Sleep (0x10) TCNT += 0x10 } } ElseIf ((PION == 0x02)) { P2LD = Zero P2TR = One TCNT = Zero While ((TCNT < LDLY)) { If ((P2VC == Zero)) { Break }
Sleep (0x10) TCNT += 0x10 } } } Else { LKEN (PION) }
/* ... */
Return (Zero) }
If not set to Windows 2009, then this is triggered:
Method (LKEN, 1, NotSerialized) { Local3 = (CPEX & 0x0F) If ((Local3 == Zero)) { If ((Arg0 == Zero)) { P0L0 = One Sleep (0x10) Local0 = Zero While (P0L0) { If ((Local0 > 0x04)) { Break }
Sleep (0x10) Local0++ } } ElseIf ((Arg0 == One)) { P1L0 = One Sleep (0x10) Local0 = Zero While (P0L0) { If ((Local0 > 0x04)) { Break }
Sleep (0x10) Local0++ } } ElseIf ((Arg0 == 0x02)) { P2L0 = One Sleep (0x10) Local0 = Zero While (P0L0) { If ((Local0 > 0x04)) { Break }
Sleep (0x10) Local0++ } } } ElseIf ((Local3 != Zero)) { If ((Arg0 == Zero)) { Q0L0 = One Sleep (0x10) Local0 = Zero While (Q0L0) { If ((Local0 > 0x04)) { Break }
Sleep (0x10) Local0++ } } ElseIf ((Arg0 == One)) { Q1L0 = One Sleep (0x10) Local0 = Zero While (Q1L0) { If ((Local0 > 0x04)) { Break }
Sleep (0x10) Local0++ } } ElseIf ((Arg0 == 0x02)) { Q2L0 = One Sleep (0x10) Local0 = Zero While (Q2L0) { If ((Local0 > 0x04)) { Break }
Sleep (0x10) Local0++ } } } }
Is it possible to override the specific ACPI table functions (SSDT) in the DSDT? This way I could try to debug to find some more information...
On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
Am 30.08.2016 um 21:53 schrieb Peter Wu:
On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
- Load nouveau.
- Wait for it to runtime suspend.
- Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
- lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
I can confirm this. Same result on my machine.
Here is a link to my ACPI tables: https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+fi...
The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
Method (PGON, 1, Serialized) { /* ... */ GPPR (PION, One) If ((OSYS == 0x07D9)) /* Is Windows 2009 - In my case, setting to Windows 2009 only works! */ {
[..]
} Else { LKEN (PION) } /* ... */ Return (Zero) }If not set to Windows 2009, then this is triggered:
Method (LKEN, 1, NotSerialized) {
[..]
}
Yep, this is the same code. I stripped out irrelevant parts from the previous mail for brevity.
Is it possible to override the specific ACPI table functions (SSDT) in the DSDT? This way I could try to debug to find some more information...
See Documentation/acpi/initrd_table_override.txt and note that it is important that the tables are really located at /kernel/firmware/acpi/ in your initrd (which must be the first, even before any possible microcode updates).
What are you trying to do? For ACPI method tracing, see Documentation/acpi/method-tracing.txt
Am 31.08.2016 um 13:46 schrieb Peter Wu:
On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
Am 30.08.2016 um 21:53 schrieb Peter Wu:
On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
- Load nouveau.
- Wait for it to runtime suspend.
- Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
- lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
I can confirm this. Same result on my machine.
Here is a link to my ACPI tables: https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+fi...
The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
Method (PGON, 1, Serialized) { /* ... */ GPPR (PION, One) If ((OSYS == 0x07D9)) /* Is Windows 2009 - In my case, setting to Windows 2009 only works! */ {[..]
} Else { LKEN (PION) } /* ... */ Return (Zero) }If not set to Windows 2009, then this is triggered:
Method (LKEN, 1, NotSerialized) {[..]
}Yep, this is the same code. I stripped out irrelevant parts from the previous mail for brevity.
Is it possible to override the specific ACPI table functions (SSDT) in the DSDT? This way I could try to debug to find some more information...
See Documentation/acpi/initrd_table_override.txt and note that it is important that the tables are really located at /kernel/firmware/acpi/ in your initrd (which must be the first, even before any possible microcode updates).
What are you trying to do? For ACPI method tracing, see Documentation/acpi/method-tracing.txt
Oh, you're right.
Thanks. Right now I am overriding the DSDT, but I am not able to override the SSDT, because I have to fix and compile all the SSDT files. There are too many compile errors... Wanted to find the exact line which is responsible for the hickup.
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
- Load nouveau.
- Wait for it to runtime suspend.
- Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
- lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
I noticed following:
1. Blacklist nouveau 2. Boot to GDM login manager (Wayland) 3. Switch to TTY with CTRL+ALT+FN2 4. Load bbswitch 5. Switch off GPU 6. run lspci -> no freeze 7. Switch to GDM 8. Login to a Wayland session (X11 won't work) 9. run lspci in a GUI terminal -> system freezes
On Wed, Aug 31, 2016 at 02:21:31PM +0200, Roland Singer wrote:
Am 31.08.2016 um 13:46 schrieb Peter Wu:
On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
Am 30.08.2016 um 21:53 schrieb Peter Wu:
On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
[+cc linux-acpi, linux-kernel, dri-devel]
Hi Roland,
I have no idea how to debug this problem. Are you seeing something that suggests it may be a PCI problem?
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
- Load nouveau.
- Wait for it to runtime suspend.
- Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
- lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
I can confirm this. Same result on my machine.
Here is a link to my ACPI tables: https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4722651/+fi...
The specific source for the NVIDIA card can be found in the ssdt5.dsl file.
Method (PGON, 1, Serialized) { /* ... */ GPPR (PION, One) If ((OSYS == 0x07D9)) /* Is Windows 2009 - In my case, setting to Windows 2009 only works! */ {[..]
} Else { LKEN (PION) } /* ... */ Return (Zero) }If not set to Windows 2009, then this is triggered:
Method (LKEN, 1, NotSerialized) {[..]
}Yep, this is the same code. I stripped out irrelevant parts from the previous mail for brevity.
Is it possible to override the specific ACPI table functions (SSDT) in the DSDT? This way I could try to debug to find some more information...
See Documentation/acpi/initrd_table_override.txt and note that it is important that the tables are really located at /kernel/firmware/acpi/ in your initrd (which must be the first, even before any possible microcode updates).
What are you trying to do? For ACPI method tracing, see Documentation/acpi/method-tracing.txt
Oh, you're right.
Thanks. Right now I am overriding the DSDT, but I am not able to override the SSDT, because I have to fix and compile all the SSDT files. There are too many compile errors... Wanted to find the exact line which is responsible for the hickup.
Have you disassembled with externs included? That is,
iasl -e *.dat -d ssdtX.dat
If you are sure that the remaining errors are harmless, you can use the '-f' option to ignore errors. You can also use the `-ve` option to suppress warnings and remarks so you can focus on the errors.
If you look at my notes.txt, you will see that _OFF always executes the same code. PGON differs. When the problem occurs, "Q0L0" somehow always reads back as non-zero and LNKS < 7.
Yes I suspect there is an ACPI and/ or PCI problem, possibly device-specific. Steps to reproduce on the affected machines:
- Load nouveau.
- Wait for it to runtime suspend.
- Invoke 'lspci', this resumes the Nvidia PCI device via nouveau.
- lspci never returns, few moments later an AML_INFINITE_LOOP is reported.
I noticed following:
- Blacklist nouveau
- Boot to GDM login manager (Wayland)
- Switch to TTY with CTRL+ALT+FN2
- Load bbswitch
- Switch off GPU
- run lspci -> no freeze
- Switch to GDM
- Login to a Wayland session (X11 won't work)
- run lspci in a GUI terminal -> system freezes
Is nouveau somehow loaded anyway? All those extra components (X11, Wayland, etc.) are unnecessary to reproduce the core problem. It occurs whenever the device is being resumed (either via DSM/_PS0 or via power resource PG00._ON).
Thanks. Right now I am overriding the DSDT, but I am not able to override the SSDT, because I have to fix and compile all the SSDT files. There are too many compile errors... Wanted to find the exact line which is responsible for the hickup.
Have you disassembled with externs included? That is,
iasl -e *.dat -d ssdtX.datIf you are sure that the remaining errors are harmless, you can use the '-f' option to ignore errors. You can also use the `-ve` option to suppress warnings and remarks so you can focus on the errors.
Thanks, I'll try that.
If you look at my notes.txt, you will see that _OFF always executes the same code. PGON differs. When the problem occurs, "Q0L0" somehow always reads back as non-zero and LNKS < 7.
Oh you're Lekensteyn ^^
I don't have LNKS and no while loop after calling LKEN ?!
I noticed following:
- Blacklist nouveau
- Boot to GDM login manager (Wayland)
- Switch to TTY with CTRL+ALT+FN2
- Load bbswitch
- Switch off GPU
- run lspci -> no freeze
- Switch to GDM
- Login to a Wayland session (X11 won't work)
- run lspci in a GUI terminal -> system freezes
Is nouveau somehow loaded anyway? All those extra components (X11, Wayland, etc.) are unnecessary to reproduce the core problem. It occurs whenever the device is being resumed (either via DSM/_PS0 or via power resource PG00._ON).
Sorry that was nonsense. The steps to reproduce the problem are still valid. I didn't wait enough to power it down...
But whats interesting:
1. Blacklist nouveau 2. Load bbswitch 3. Power off GPU with bbswitch 4. Power on GPU with bbswitch 5. Run lspci 6. Power off GPU with bbswitch 7. Run lspci -> freeze
So setting the GPU power state with bbswitch works as expected. Powering it on is also fine. I did this a couple of times. But powering it off and letting lspci powering it on, ends in a race.
It might be, that lspci does not only power the GPU on, but triggers another pci action which causes the race condition. Does this have something to do with your quote about the retrain bit?
Here is Peter Wu's reply, which was not send to the mailing list, because I had to resend my e-mail to him due to a failure...
-------- Forwarded Message -------- Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BIOS Date: Wed, 31 Aug 2016 18:08:53 +0200 From: Peter Wu peter@lekensteyn.nl To: Roland Singer roland.singer@desertbit.com
On Wed, Aug 31, 2016 at 05:56:18PM +0200, Roland Singer wrote:
If you look at my notes.txt, you will see that _OFF always executes the same code. PGON differs. When the problem occurs, "Q0L0" somehow always reads back as non-zero and LNKS < 7.
Oh you're Lekensteyn ^^
Yes, that's me :) I wrote bbswitch, did the Optimus and PR3 ACPI support in nouveau so I am fairly certain what happens behind the scenes.
I don't have LNKS and no while loop after calling LKEN ?!
Yes that is what I said in https://www.spinics.net/lists/linux-pci/msg53694.html:
"Other affected devices have similar code, differences are small: No check for LNKS (avoids the infinite loop, but device is still off)"
I noticed following:
- Blacklist nouveau
- Boot to GDM login manager (Wayland)
- Switch to TTY with CTRL+ALT+FN2
- Load bbswitch
- Switch off GPU
- run lspci -> no freeze
- Switch to GDM
- Login to a Wayland session (X11 won't work)
- run lspci in a GUI terminal -> system freezes
Is nouveau somehow loaded anyway? All those extra components (X11, Wayland, etc.) are unnecessary to reproduce the core problem. It occurs whenever the device is being resumed (either via DSM/_PS0 or via power resource PG00._ON).
Sorry that was nonsense. The steps to reproduce the problem are still valid. I didn't wait enough to power it down...
But whats interesting:
- Blacklist nouveau
- Load bbswitch
- Power off GPU with bbswitch
- Power on GPU with bbswitch
- Run lspci
- Power off GPU with bbswitch
- Run lspci -> freeze
So setting the GPU power state with bbswitch works as expected. Powering it on is also fine. I did this a couple of times. But powering it off and letting lspci powering it on, ends in a race.
In some cases I also found that it does always happen at the first try, but with nouveau it always seem to happen.
It might be, that lspci does not only power the GPU on, but triggers another pci action which causes the race condition. Does this have something to do with your quote about the retrain bit?
That is an interesting hypothesis. Even if you invoke `lspci -s01:00.0` for example, it will always probe for all devices. So maybe interaction with its parent device (PCI root port 00:02.0) causes issues.
However I also tested without lspci before, and the problem still exists. You can trigger runtime resume via (as root):
echo > /sys/bus/pci/0000:01:00.0/power/control on
Set it to "auto" to make it sleep again.
On 08/31/16 22:06, Roland Singer wrote:
Here is Peter Wu's reply, which was not send to the mailing list, because I had to resend my e-mail to him due to a failure...
-------- Forwarded Message -------- Subject: Re: Fwd: Re: Kernel Freeze with American Megatrends BIOS Date: Wed, 31 Aug 2016 18:08:53 +0200 From: Peter Wu peter@lekensteyn.nl To: Roland Singer roland.singer@desertbit.com
On Wed, Aug 31, 2016 at 05:56:18PM +0200, Roland Singer wrote:
If you look at my notes.txt, you will see that _OFF always executes the same code. PGON differs. When the problem occurs, "Q0L0" somehow always reads back as non-zero and LNKS < 7.
Oh you're Lekensteyn ^^
Yes, that's me :) I wrote bbswitch, did the Optimus and PR3 ACPI support in nouveau so I am fairly certain what happens behind the scenes.
Awesome! Thanks for all your efforts! Great work :)
I don't have LNKS and no while loop after calling LKEN ?!
Yes that is what I said in https://www.spinics.net/lists/linux-pci/msg53694.html:
"Other affected devices have similar code, differences are small: No check for LNKS (avoids the infinite loop, but device is still off)"
Ah ok, missed that.
It might be, that lspci does not only power the GPU on, but triggers another pci action which causes the race condition. Does this have something to do with your quote about the retrain bit?
That is an interesting hypothesis. Even if you invoke `lspci -s01:00.0` for example, it will always probe for all devices. So maybe interaction with its parent device (PCI root port 00:02.0) causes issues.
However I also tested without lspci before, and the problem still exists. You can trigger runtime resume via (as root):
echo > /sys/bus/pci/0000:01:00.0/power/control onSet it to "auto" to make it sleep again.
Just tried it over and over again. I don't have any problems switching the GPU power state with bbswitch. So, switching the GPU on is just fine. There must be something else, which does not cooperate well while switching it on (lspci)...
I can confirm,, that `lspci -s01:00.0` also freezes the system.
Trying to trigger runtime resume with `/sys/bus/pci/0000:01:00.0/power/control` did not work for me. The GPU just stayed off. Any hints how to get some more information?
dri-devel@lists.freedesktop.org
-
Bjorn Helgaas -
Emil Velikov -
Ilia Mirkin -
Peter Wu -
Roland Singer