There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@vger.kernel.org # v2.6.35+ ---
Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply).
drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle;
- if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected) - return false; - dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false;
On Thu, Mar 27, 2014 at 9:37 AM, Ilia Mirkin imirkin@alum.mit.edu wrote:
There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@vger.kernel.org # v2.6.35+
Got it, thanks!
Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply).
drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle;
if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected)return false;dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false;-- 1.8.3.2
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you
2014-03-27 0:37 GMT+01:00 Ilia Mirkin imirkin@alum.mit.edu:
There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@vger.kernel.org # v2.6.35+
Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply).
drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle;
if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected)return false;dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false;-- 1.8.3.2
Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card):
[ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22
Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it.
Yours, Claas
On 27.03.2014 11:54, Patrick Clara wrote:
I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you
2014-03-27 0:37 GMT+01:00 Ilia Mirkin imirkin@alum.mit.edu:
There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@vger.kernel.org # v2.6.35+
Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply).
drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle;
if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected)return false;dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false;-- 1.8.3.2
On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz cllorenz@uni-potsdam.de wrote:
Hi, same for me. The screen does not freeze anymore and the boot
Great! And that's without the nouveau.config=NvBios= stuff that you added as a workaround, right?
succeeds. But now I have this kernel message during boot (for the second card):
[ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22
Do you want to have the complete dmesg log? I think this is a new bug.
New to you, perhaps :) Try http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ad.... Or you can try forcing runpm=1 and seeing what happens. Ideally it'll be able to suspend your second GPU, but... who knows. That logic is really designed around optimus.
Your patch works for the previous one, so you can close it.
Yours, Claas
On 27.03.2014 11:54, Patrick Clara wrote:
I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you
2014-03-27 0:37 GMT+01:00 Ilia Mirkin imirkin@alum.mit.edu:
There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@vger.kernel.org # v2.6.35+
Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply).
drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle;
if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected)return false;dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false;-- 1.8.3.2
Yes, it works without the workaround... and thanks for the suspend patch which works fine as well :-)
On 05.04.2014 18:18, Ilia Mirkin wrote:
On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz cllorenz@uni-potsdam.de wrote:
Hi, same for me. The screen does not freeze anymore and the boot
Great! And that's without the nouveau.config=NvBios= stuff that you added as a workaround, right?
succeeds. But now I have this kernel message during boot (for the second card):
[ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22
Do you want to have the complete dmesg log? I think this is a new bug.
New to you, perhaps :) Try http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ad.... Or you can try forcing runpm=1 and seeing what happens. Ideally it'll be able to suspend your second GPU, but... who knows. That logic is really designed around optimus.
Your patch works for the previous one, so you can close it.
Yours, Claas
On 27.03.2014 11:54, Patrick Clara wrote:
I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you
2014-03-27 0:37 GMT+01:00 Ilia Mirkin imirkin@alum.mit.edu:
There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@vger.kernel.org # v2.6.35+
Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply).
drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle;
if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected)return false;dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false;-- 1.8.3.2
dri-devel@lists.freedesktop.org
-
Ben Skeggs -
Claas Lorenz -
Ilia Mirkin -
Patrick Clara