Claas Lorenz
2014-Apr-05 11:53 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
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 at 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 at alum.mit.edu> >> Cc: <stable at 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 >>
Ilia Mirkin
2014-Apr-05 16:18 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz <cllorenz at uni-potsdam.de> wrote:> Hi, same for me. The screen does not freeze anymore and the bootGreat! 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=adbbdbac04f093c0abf946b1e93e4e5291808491. 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 at 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 at alum.mit.edu> >>> Cc: <stable at 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 >>> >
Claas Lorenz
2014-Apr-06 08:12 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
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 at 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=adbbdbac04f093c0abf946b1e93e4e5291808491. > 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 at 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 at alum.mit.edu> >>>> Cc: <stable at 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 >>>>
Seemingly Similar Threads
- [PATCH] acpi: allow non-optimus setups to load vbios from acpi
- [PATCH] acpi: allow non-optimus setups to load vbios from acpi
- [PATCH] acpi: allow non-optimus setups to load vbios from acpi
- [PATCH v2 1/4] drm/nouveau/acpi: ensure matching ACPI handle and supported functions
- [PATCH v2 3/4] drm/nouveau/acpi: check for function 0x1B before using it