| Message ID | 1395877041-8646-1-git-send-email-imirkin@alum.mit.edu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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=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@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=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@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 >>>>
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;
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(-)