[REGRESSION] nouveau: Resume hung after protecting against client races (MBA3,1)
Hi Ben, The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem. Thanks, Henrik
[REGRESSION] nouveau: Resume hung after protecting against client races (MBA3,1)
Hi Ben, The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem. Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 3.7-rc6
> Yeah, the utter lack of a vbt fits very nicely, thanks for checking, > I've merged the patch into drm-intel-fixes and will forward it for > inclusion into 3.7 rsn. Great, thanks. One thing about that patch: if we would ever encounter a non-zero edp.bpp < 3, display_bpc would not be clamped. I suppose monochrome screens went out of fashion twenty years ago, but who knows... Thanks, Henrik
Linux 3.7-rc6
Hi Daniel,
> >> My apologies for the long delay in answering, I've somehow mixed up
> >> different bugreports and thought I've sent you a patch to test
> >> already. Anyway, please test
> >>
> >> https://patchwork.kernel.org/patch/1728111/
> >
> > Tested-by: Henrik Rydberg
>
> Can you please boot with drm.debug=0xe added to your kernel cmdline
> with that patch applied and attach the full dmesg?
Are you looking for something in particular? The patch obviously works
because edp_bpp is never set. The reason seems to be
[1.634759] [drm:intel_parse_bios], VBT signature missing
In the source, a few lines above that message, we have something that
looks suspciciously like an off-by-one error:
/* Scour memory looking for the VBT signature */
for (i = 0; i + 4 < size; i++) {
If that matters or not, I do not know. Any more tests would have to
wait until tomorrow.
Thanks,
Henrik
Linux 3.7-rc6
Hi Daniel, > My apologies for the long delay in answering, I've somehow mixed up > different bugreports and thought I've sent you a patch to test > already. Anyway, please test > > https://patchwork.kernel.org/patch/1728111/ Tested-by: Henrik Rydberg Thanks, Henrik
Re: Linux 3.7-rc6
Hi Daniel,
My apologies for the long delay in answering, I've somehow mixed up
different bugreports and thought I've sent you a patch to test
already. Anyway, please test
https://patchwork.kernel.org/patch/1728111/
Tested-by: Henrik Rydberg rydb...@euromail.se
Can you please boot with drm.debug=0xe added to your kernel cmdline
with that patch applied and attach the full dmesg?
Are you looking for something in particular? The patch obviously works
because edp_bpp is never set. The reason seems to be
[1.634759] [drm:intel_parse_bios], VBT signature missing
In the source, a few lines above that message, we have something that
looks suspciciously like an off-by-one error:
/* Scour memory looking for the VBT signature */
for (i = 0; i + 4 size; i++) {
If that matters or not, I do not know. Any more tests would have to
wait until tomorrow.
Thanks,
Henrik
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc6
Yeah, the utter lack of a vbt fits very nicely, thanks for checking, I've merged the patch into drm-intel-fixes and will forward it for inclusion into 3.7 rsn. Great, thanks. One thing about that patch: if we would ever encounter a non-zero edp.bpp 3, display_bpc would not be clamped. I suppose monochrome screens went out of fashion twenty years ago, but who knows... Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.7-rc6
Hi Daniel, My apologies for the long delay in answering, I've somehow mixed up different bugreports and thought I've sent you a patch to test already. Anyway, please test https://patchwork.kernel.org/patch/1728111/ Tested-by: Henrik Rydberg rydb...@euromail.se Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 3.7-rc6
Hi Daniel, > > As advertised, this patch breaks the Macbook Pro Retina, which seems > > unfair. The patch below is certainly not the best remedy, but it does > > work. Tested on a MacbookPro10,1. > > My apologies for the long delay in answering, I've somehow mixed up > different bugreports and thought I've sent you a patch to test > already. Anyway, please test > > https://patchwork.kernel.org/patch/1728111/ Thanks for the patch! I will try it out tomorrow and let you know. Henrik
Re: Linux 3.7-rc6
Hi Daniel, As advertised, this patch breaks the Macbook Pro Retina, which seems unfair. The patch below is certainly not the best remedy, but it does work. Tested on a MacbookPro10,1. My apologies for the long delay in answering, I've somehow mixed up different bugreports and thought I've sent you a patch to test already. Anyway, please test https://patchwork.kernel.org/patch/1728111/ Thanks for the patch! I will try it out tomorrow and let you know. Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 3.7-rc6
> drm/i915: do not ignore eDP bpc settings from vbt
As advertised, this patch breaks the Macbook Pro Retina, which seems
unfair. The patch below is certainly not the best remedy, but it does
work. Tested on a MacbookPro10,1.
Thanks,
Henrik
---
From: Henrik Rydberg <rydb...@euromail.se>
Date: Tue, 20 Nov 2012 11:16:05 +0100
Subject: [PATCH] drm/i915: Ignore eDP bpc settings from vbt based on dmi data
Status: O
Content-Length: 1637
Lines: 51
Commit 2f4f649a6 breaks the Retina display on MacBookPro10 laptops.
This patch reintroduces the logic reverted by that patch, but only
for the Retina machines.
Signed-off-by: Henrik Rydberg
---
drivers/gpu/drm/i915/intel_display.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4154bcd..97658d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3776,6 +3776,24 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
&& !(dev_priv->quirks & QUIRK_LVDS_SSC_DISABLE);
}
+static int dmi_ignore_bpc_from_vbt_callback(const struct dmi_system_id *id)
+{
+ DRM_INFO("Ignoring bpc from vbt on %s\n", id->ident);
+ return 1;
+}
+
+static const struct dmi_system_id dmi_ignore_bpc_from_vbt[] = {
+ {
+ .callback = dmi_ignore_bpc_from_vbt_callback,
+ .ident = "Apple MacBook Pro Retina",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro10"),
+ },
+ },
+ { } /* terminating entry */
+};
+
/**
* intel_choose_pipe_bpp_dither - figure out what color depth the pipe should
send
* @crtc: CRTC structure
@@ -3841,7 +3859,8 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
}
}
- if (intel_encoder->type == INTEL_OUTPUT_EDP) {
+ if (intel_encoder->type == INTEL_OUTPUT_EDP &&
+ !dmi_check_system(dmi_ignore_bpc_from_vbt)) {
/* Use VBT settings if we have an eDP panel */
unsigned int edp_bpc = dev_priv->edp.bpp / 3;
--
1.8.0
Re: Linux 3.7-rc6
drm/i915: do not ignore eDP bpc settings from vbt
As advertised, this patch breaks the Macbook Pro Retina, which seems
unfair. The patch below is certainly not the best remedy, but it does
work. Tested on a MacbookPro10,1.
Thanks,
Henrik
---
From: Henrik Rydberg rydb...@euromail.se
Date: Tue, 20 Nov 2012 11:16:05 +0100
Subject: [PATCH] drm/i915: Ignore eDP bpc settings from vbt based on dmi data
Status: O
Content-Length: 1637
Lines: 51
Commit 2f4f649a6 breaks the Retina display on MacBookPro10 laptops.
This patch reintroduces the logic reverted by that patch, but only
for the Retina machines.
Signed-off-by: Henrik Rydberg rydb...@euromail.se
---
drivers/gpu/drm/i915/intel_display.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4154bcd..97658d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3776,6 +3776,24 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
!(dev_priv-quirks QUIRK_LVDS_SSC_DISABLE);
}
+static int dmi_ignore_bpc_from_vbt_callback(const struct dmi_system_id *id)
+{
+ DRM_INFO(Ignoring bpc from vbt on %s\n, id-ident);
+ return 1;
+}
+
+static const struct dmi_system_id dmi_ignore_bpc_from_vbt[] = {
+ {
+ .callback = dmi_ignore_bpc_from_vbt_callback,
+ .ident = Apple MacBook Pro Retina,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro10),
+ },
+ },
+ { } /* terminating entry */
+};
+
/**
* intel_choose_pipe_bpp_dither - figure out what color depth the pipe should
send
* @crtc: CRTC structure
@@ -3841,7 +3859,8 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
}
}
- if (intel_encoder-type == INTEL_OUTPUT_EDP) {
+ if (intel_encoder-type == INTEL_OUTPUT_EDP
+ !dmi_check_system(dmi_ignore_bpc_from_vbt)) {
/* Use VBT settings if we have an eDP panel */
unsigned int edp_bpc = dev_priv-edp.bpp / 3;
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Sun, Oct 21, 2012 at 09:10:24AM +0200, Henrik Rydberg wrote: > On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: > > Hi Ben, > > > > 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty > > badly. Not surprisingly, > > > > commit 3863c9bc887e9638a9d905d55f6038641ece78d6 > > Author: Ben Skeggs > > Date: Sat Jul 14 19:09:17 2012 +1000 > > > > drm/nouveau/instmem: completely new implementation, as a subdev module > > > > is the first bad commit. Standing on that commit, booting and then > > starting X yields the output below. Hints are especially appreciated, > > considering the patch is almost 8000 lines. > > Going through one suspend/resume cycle makes the corruption go away, > and there are no more errors in dmesg. Oddly enough, I have seen > something very similar when using i915 on the MBP10. Builtin modules > and systemd in both cases. Maybe this is a general drm issue. Any > thoughts? This is still a problem in Linus' tree. The screen corruption happens during boot, in text mode, presumably in conjunction with alloction of the nouveaufb device. It is 100% reproducible, and there is no advanced graphics involved, just simple text console. Booting from efi or bios does not matter. Modules are builtin. Suspending and resuming once makes the problem go away every time. Since this is a simple usecase, and the failing commit has been bisected, it ought to be possible to find the problem. Unfortunately, I am not familiar enough with the nouveau code to find the problem in an 8000-line patch. Please help. :-) Thanks, Henrik
Re: [REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Sun, Oct 21, 2012 at 09:10:24AM +0200, Henrik Rydberg wrote: On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: Hi Ben, 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty badly. Not surprisingly, commit 3863c9bc887e9638a9d905d55f6038641ece78d6 Author: Ben Skeggs bske...@redhat.com Date: Sat Jul 14 19:09:17 2012 +1000 drm/nouveau/instmem: completely new implementation, as a subdev module is the first bad commit. Standing on that commit, booting and then starting X yields the output below. Hints are especially appreciated, considering the patch is almost 8000 lines. Going through one suspend/resume cycle makes the corruption go away, and there are no more errors in dmesg. Oddly enough, I have seen something very similar when using i915 on the MBP10. Builtin modules and systemd in both cases. Maybe this is a general drm issue. Any thoughts? This is still a problem in Linus' tree. The screen corruption happens during boot, in text mode, presumably in conjunction with alloction of the nouveaufb device. It is 100% reproducible, and there is no advanced graphics involved, just simple text console. Booting from efi or bios does not matter. Modules are builtin. Suspending and resuming once makes the problem go away every time. Since this is a simple usecase, and the failing commit has been bisected, it ought to be possible to find the problem. Unfortunately, I am not familiar enough with the nouveau code to find the problem in an 8000-line patch. Please help. :-) Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: > Hi Ben, > > 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty > badly. Not surprisingly, > > commit 3863c9bc887e9638a9d905d55f6038641ece78d6 > Author: Ben Skeggs > Date: Sat Jul 14 19:09:17 2012 +1000 > > drm/nouveau/instmem: completely new implementation, as a subdev module > > is the first bad commit. Standing on that commit, booting and then > starting X yields the output below. Hints are especially appreciated, > considering the patch is almost 8000 lines. Going through one suspend/resume cycle makes the corruption go away, and there are no more errors in dmesg. Oddly enough, I have seen something very similar when using i915 on the MBP10. Builtin modules and systemd in both cases. Maybe this is a general drm issue. Any thoughts? Thanks, Henrik
Re: [REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote: Hi Ben, 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty badly. Not surprisingly, commit 3863c9bc887e9638a9d905d55f6038641ece78d6 Author: Ben Skeggs bske...@redhat.com Date: Sat Jul 14 19:09:17 2012 +1000 drm/nouveau/instmem: completely new implementation, as a subdev module is the first bad commit. Standing on that commit, booting and then starting X yields the output below. Hints are especially appreciated, considering the patch is almost 8000 lines. Going through one suspend/resume cycle makes the corruption go away, and there are no more errors in dmesg. Oddly enough, I have seen something very similar when using i915 on the MBP10. Builtin modules and systemd in both cases. Maybe this is a general drm issue. Any thoughts? Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
Hi Ben, 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty badly. Not surprisingly, commit 3863c9bc887e9638a9d905d55f6038641ece78d6 Author: Ben Skeggs Date: Sat Jul 14 19:09:17 2012 +1000 drm/nouveau/instmem: completely new implementation, as a subdev module is the first bad commit. Standing on that commit, booting and then starting X yields the output below. Hints are especially appreciated, considering the patch is almost 8000 lines. Thanks, Henrik --- [0.611281] nouveau :02:00.0: setting latency timer to 64 [0.611291] nouveau :02:00.0: enabling device (0006 -> 0007) [0.611861] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0af100a2 [0.611869] nouveau [ DEVICE][:02:00.0] Chipset: NVAF [0.611876] nouveau [ DEVICE][:02:00.0] Family : NV50 [0.616624] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [0.697355] nouveau [ VBIOS][:02:00.0] ... appears to be valid [0.697364] nouveau [ VBIOS][:02:00.0] using image from PRAMIN [0.697541] nouveau [ VBIOS][:02:00.0] BIT signature found [0.697550] nouveau [ VBIOS][:02:00.0] version 70.89.13.00 [0.800761] nouveau [ PFB][:02:00.0] RAM type: DDR1 [0.800807] nouveau [ PFB][:02:00.0] RAM size: 256 MiB [0.819745] [drm] nouveau :02:00.0: Detected an NV50 generation card (0x0af100a2) [0.819761] [drm] nouveau :02:00.0: BIT BIOS found [0.819767] [drm] nouveau :02:00.0: Bios version 70.89.13.00 [0.819776] [drm] nouveau :02:00.0: TMDS table version 2.0 [0.819782] [drm] nouveau :02:00.0: MXM: no VBIOS data, nothing to do [0.819789] [drm] nouveau :02:00.0: DCB version 4.0 [0.819795] [drm] nouveau :02:00.0: DCB outp 00: 040001b6 0f220010 [0.819801] [drm] nouveau :02:00.0: DCB outp 01: 020112a6 0f220010 [0.819807] [drm] nouveau :02:00.0: DCB outp 02: 02011262 00020010 [0.819813] [drm] nouveau :02:00.0: DCB conn 00: 2047 [0.819820] [drm] nouveau :02:00.0: DCB conn 01: 00101146 [0.822388] [drm] nouveau :02:00.0: 512 MiB GART (aperture) [2.554491] [drm] nouveau :02:00.0: 4 available performance level(s) [2.554502] [drm] nouveau :02:00.0: 0: core 405MHz shader 405MHz memory 405MHz voltage 900mV [2.554513] [drm] nouveau :02:00.0: 1: core 450MHz shader 810MHz memory 450MHz voltage 900mV [2.554523] [drm] nouveau :02:00.0: 2: core 450MHz shader 810MHz memory 450MHz voltage 900mV [2.554533] [drm] nouveau :02:00.0: 3: core 450MHz shader 950MHz memory 450MHz voltage 900mV [2.554542] [drm] nouveau :02:00.0: c: core 405MHz shader 810MHz [2.780162] [drm] nouveau :02:00.0: MM: using M2MF for buffer copies [2.867850] [drm] nouveau :02:00.0: allocated 1366x768 fb: 0x5, bo 88006ec7c800 [2.924536] fb0: nouveaufb frame buffer device [2.924623] [drm] Initialized nouveau 1.0.0 20120316 for :02:00.0 on minor 0 [6.352282] nouveau E[ PFB][:02:00.0] trapped write at 0x434180 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.354595] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.356811] nouveau E[ PFB][:02:00.0] trapped write at 0x430100 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.358992] nouveau E[ PFB][:02:00.0] trapped write at 0x438200 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.361159] nouveau E[ PFB][:02:00.0] trapped write at 0x448140 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.363304] nouveau E[ PFB][:02:00.0] trapped write at 0x430100 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.365415] nouveau E[ PFB][:02:00.0] trapped write at 0x448140 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.367474] nouveau E[ PFB][:02:00.0] trapped write at 0x438200 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.369537] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.371566] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.373570] nouveau E[ PFB][:02:00.0] trapped write at 0x448140 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.375544] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.377493] nouveau E[ PFB][:02:00.0] trapped write at 0x434180 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.379406] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.381281] nouveau E[
[REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)
Hi Ben, 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty badly. Not surprisingly, commit 3863c9bc887e9638a9d905d55f6038641ece78d6 Author: Ben Skeggs bske...@redhat.com Date: Sat Jul 14 19:09:17 2012 +1000 drm/nouveau/instmem: completely new implementation, as a subdev module is the first bad commit. Standing on that commit, booting and then starting X yields the output below. Hints are especially appreciated, considering the patch is almost 8000 lines. Thanks, Henrik --- [0.611281] nouveau :02:00.0: setting latency timer to 64 [0.611291] nouveau :02:00.0: enabling device (0006 - 0007) [0.611861] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0af100a2 [0.611869] nouveau [ DEVICE][:02:00.0] Chipset: NVAF [0.611876] nouveau [ DEVICE][:02:00.0] Family : NV50 [0.616624] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [0.697355] nouveau [ VBIOS][:02:00.0] ... appears to be valid [0.697364] nouveau [ VBIOS][:02:00.0] using image from PRAMIN [0.697541] nouveau [ VBIOS][:02:00.0] BIT signature found [0.697550] nouveau [ VBIOS][:02:00.0] version 70.89.13.00 [0.800761] nouveau [ PFB][:02:00.0] RAM type: DDR1 [0.800807] nouveau [ PFB][:02:00.0] RAM size: 256 MiB [0.819745] [drm] nouveau :02:00.0: Detected an NV50 generation card (0x0af100a2) [0.819761] [drm] nouveau :02:00.0: BIT BIOS found [0.819767] [drm] nouveau :02:00.0: Bios version 70.89.13.00 [0.819776] [drm] nouveau :02:00.0: TMDS table version 2.0 [0.819782] [drm] nouveau :02:00.0: MXM: no VBIOS data, nothing to do [0.819789] [drm] nouveau :02:00.0: DCB version 4.0 [0.819795] [drm] nouveau :02:00.0: DCB outp 00: 040001b6 0f220010 [0.819801] [drm] nouveau :02:00.0: DCB outp 01: 020112a6 0f220010 [0.819807] [drm] nouveau :02:00.0: DCB outp 02: 02011262 00020010 [0.819813] [drm] nouveau :02:00.0: DCB conn 00: 2047 [0.819820] [drm] nouveau :02:00.0: DCB conn 01: 00101146 [0.822388] [drm] nouveau :02:00.0: 512 MiB GART (aperture) [2.554491] [drm] nouveau :02:00.0: 4 available performance level(s) [2.554502] [drm] nouveau :02:00.0: 0: core 405MHz shader 405MHz memory 405MHz voltage 900mV [2.554513] [drm] nouveau :02:00.0: 1: core 450MHz shader 810MHz memory 450MHz voltage 900mV [2.554523] [drm] nouveau :02:00.0: 2: core 450MHz shader 810MHz memory 450MHz voltage 900mV [2.554533] [drm] nouveau :02:00.0: 3: core 450MHz shader 950MHz memory 450MHz voltage 900mV [2.554542] [drm] nouveau :02:00.0: c: core 405MHz shader 810MHz [2.780162] [drm] nouveau :02:00.0: MM: using M2MF for buffer copies [2.867850] [drm] nouveau :02:00.0: allocated 1366x768 fb: 0x5, bo 88006ec7c800 [2.924536] fb0: nouveaufb frame buffer device [2.924623] [drm] Initialized nouveau 1.0.0 20120316 for :02:00.0 on minor 0 [6.352282] nouveau E[ PFB][:02:00.0] trapped write at 0x434180 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.354595] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.356811] nouveau E[ PFB][:02:00.0] trapped write at 0x430100 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.358992] nouveau E[ PFB][:02:00.0] trapped write at 0x438200 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.361159] nouveau E[ PFB][:02:00.0] trapped write at 0x448140 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.363304] nouveau E[ PFB][:02:00.0] trapped write at 0x430100 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.365415] nouveau E[ PFB][:02:00.0] trapped write at 0x448140 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.367474] nouveau E[ PFB][:02:00.0] trapped write at 0x438200 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.369537] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.371566] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.373570] nouveau E[ PFB][:02:00.0] trapped write at 0x448140 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.375544] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.377493] nouveau E[ PFB][:02:00.0] trapped write at 0x434180 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [6.379406] nouveau E[ PFB][:02:00.0] trapped write at 0x44c1c0 on channel 0xfee0 BAR/PFIFO_WRITE/FB reason: VRAM_LIMIT [
[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset
The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. Signed-off-by: Henrik Rydberg --- Hi Ben, this patch is still needed in 3.6-rc1, so perhaps we should apply it after all. I have been running it without problems for a long time now. Thanks, Henrik drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 1cdfd6e..1866dbb 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; } -- 1.7.11.4
[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset
The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. Signed-off-by: Henrik Rydberg rydb...@euromail.se --- Hi Ben, this patch is still needed in 3.6-rc1, so perhaps we should apply it after all. I have been running it without problems for a long time now. Thanks, Henrik drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 1cdfd6e..1866dbb 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; } -- 1.7.11.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Mon, Jul 09, 2012 at 03:13:25PM +0200, Henrik Rydberg wrote: On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: Thanks for tracking down the source of this corruption. I don't have any such hardware, so until someone can figure it out, I think we should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) It seems the suspend/resume problem is unrelated (bad systemd update), so I am fine with applying this as is. Obviously not the best solution, and if I have time I will continue to look for problems in the nva3 copy code, but for now, Signed-off-by: Henrik Rydberg rydb...@euromail.se I have not encountered the problem in a long while, and I do not have the patch applied. It is entirely possible that this was fixed by something else. Unless you have already applied the patch, I would suggest holding on to it to see if the problem reappears. Sorry for the churn. ... and there it was again, hours after giving up on it. Oh well. What makes this bug particularly difficult is that as soon as the patch is applied, the problem disappears and does not show itself again - with or without the patch applied. Sounds very much like the problem is a failure state that does not get reset by current mainline, but somehow gets reset with the patch applied. I also learnt that the problem is not in the nva3_copy code itself; I reverted nva3_copy.c and nva3_pm.c back to v3.4, but the problem persisted. A DMA problem elsewhere, in the drm code or in the pci layer, seems more likely than this particular hardware having problems with this particular copy engine. As it stands, though, applying the patch is the only thing known to work. Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Mon, Jul 09, 2012 at 03:13:25PM +0200, Henrik Rydberg wrote: > On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: > > On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: > > > > Thanks for tracking down the source of this corruption. I don't have > > > > any such hardware, so until someone can figure it out, I think we > > > > should apply this patch. > > > > > > In that case, I would have to massage the patch a bit first; it > > > creates a problem with suspend/resume. Might be something with > > > nva3_pm.c, who knows. I am really stabbing in the dark here. :-) > > > > It seems the suspend/resume problem is unrelated (bad systemd update), > > so I am fine with applying this as is. Obviously not the best > > solution, and if I have time I will continue to look for problems in > > the nva3 copy code, but for now, > > > > Signed-off-by: Henrik Rydberg > > I have not encountered the problem in a long while, and I do not have > the patch applied. It is entirely possible that this was fixed by > something else. Unless you have already applied the patch, I would > suggest holding on to it to see if the problem reappears. > > Sorry for the churn. ... and there it was again, hours after giving up on it. Oh well. What makes this bug particularly difficult is that as soon as the patch is applied, the problem disappears and does not show itself again - with or without the patch applied. Sounds very much like the problem is a failure state that does not get reset by current mainline, but somehow gets reset with the patch applied. I also learnt that the problem is not in the nva3_copy code itself; I reverted nva3_copy.c and nva3_pm.c back to v3.4, but the problem persisted. A DMA problem elsewhere, in the drm code or in the pci layer, seems more likely than this particular hardware having problems with this particular copy engine. As it stands, though, applying the patch is the only thing known to work. Thanks, Henrik
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: > On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: > > > Thanks for tracking down the source of this corruption. I don't have > > > any such hardware, so until someone can figure it out, I think we > > > should apply this patch. > > > > In that case, I would have to massage the patch a bit first; it > > creates a problem with suspend/resume. Might be something with > > nva3_pm.c, who knows. I am really stabbing in the dark here. :-) > > It seems the suspend/resume problem is unrelated (bad systemd update), > so I am fine with applying this as is. Obviously not the best > solution, and if I have time I will continue to look for problems in > the nva3 copy code, but for now, > > Signed-off-by: Henrik Rydberg I have not encountered the problem in a long while, and I do not have the patch applied. It is entirely possible that this was fixed by something else. Unless you have already applied the patch, I would suggest holding on to it to see if the problem reappears. Sorry for the churn. Thanks, Henrik
Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: Thanks for tracking down the source of this corruption. I don't have any such hardware, so until someone can figure it out, I think we should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) It seems the suspend/resume problem is unrelated (bad systemd update), so I am fine with applying this as is. Obviously not the best solution, and if I have time I will continue to look for problems in the nva3 copy code, but for now, Signed-off-by: Henrik Rydberg rydb...@euromail.se I have not encountered the problem in a long while, and I do not have the patch applied. It is entirely possible that this was fixed by something else. Unless you have already applied the patch, I would suggest holding on to it to see if the problem reappears. Sorry for the churn. Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote:
> > Thanks for tracking down the source of this corruption. I don't have
> > any such hardware, so until someone can figure it out, I think we
> > should apply this patch.
>
> In that case, I would have to massage the patch a bit first; it
> creates a problem with suspend/resume. Might be something with
> nva3_pm.c, who knows. I am really stabbing in the dark here. :-)
It seems the suspend/resume problem is unrelated (bad systemd update),
so I am fine with applying this as is. Obviously not the best
solution, and if I have time I will continue to look for problems in
the nva3 copy code, but for now,
Signed-off-by: Henrik Rydberg
Thanks,
Henrik
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
> Thanks for tracking down the source of this corruption. I don't have > any such hardware, so until someone can figure it out, I think we > should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) Thanks, Henrik
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
Hi Ben, Dave, Since 3.5-rc0, I have been experiencing occasional screen corruption on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver version is xf86-video-nouvea-1.0.1-1 (arch). I do not know what the root problem is, but I have been able to isolate the symptoms to the usage of nva3_copy.c. The patch below is the least intrusive way I could find which kills the symptoms. Hopefully this will sched some light on the true problem, such that a fix can be found for 3.5. Thanks, Henrik The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. --- drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 19706f0..b466937 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; }
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
Hi Ben, Dave, Since 3.5-rc0, I have been experiencing occasional screen corruption on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver version is xf86-video-nouvea-1.0.1-1 (arch). I do not know what the root problem is, but I have been able to isolate the symptoms to the usage of nva3_copy.c. The patch below is the least intrusive way I could find which kills the symptoms. Hopefully this will sched some light on the true problem, such that a fix can be found for 3.5. Thanks, Henrik The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. --- drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 19706f0..b466937 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
Thanks for tracking down the source of this corruption. I don't have any such hardware, so until someone can figure it out, I think we should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: Thanks for tracking down the source of this corruption. I don't have any such hardware, so until someone can figure it out, I think we should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) It seems the suspend/resume problem is unrelated (bad systemd update), so I am fine with applying this as is. Obviously not the best solution, and if I have time I will continue to look for problems in the nva3 copy code, but for now, Signed-off-by: Henrik Rydberg rydb...@euromail.se Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Dave,
> just two changes, one udl endian fix, one nouveau memory corruption on
> some GPUs.
I have been tracking an elusive memory corruption bug appearing on my
MacBookAir3,1 (nv50) since -rc0, but unfortunately it seems to be
different from the one fixed here. The problem is of the random kind,
which made bisection tricky. It seems the patch below fixes the
symptoms, but I have no idea why:
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7f80ed5..bff34f4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -935,7 +935,6 @@ nouveau_bo_move_init(struct nouveau_channel *chan)
{ "COPY", 0, 0xa0b5, nve0_bo_move_copy, nvc0_bo_move_init },
{ "COPY1", 5, 0x90b8, nvc0_bo_move_copy, nvc0_bo_move_init },
{ "COPY0", 4, 0x90b5, nvc0_bo_move_copy, nvc0_bo_move_init },
- { "COPY", 0, 0x85b5, nva3_bo_move_copy, nv50_bo_move_init },
{ "CRYPT", 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init },
{ "M2MF", 0, 0x9039, nvc0_bo_move_m2mf, nvc0_bo_move_init },
{ "M2MF", 0, 0x5039, nv50_bo_move_m2mf, nv50_bo_move_init },
With the patch applied, the log shows this:
Jun 27 07:01:15 polaris kernel: [drm] nouveau :02:00.0: MM: using M2MF for
buffer copies
Without the patch applied, when the problem appears, the log shows this:
Jun 27 06:50:34 polaris kernel: [drm] nouveau :02:00.0: MM: using COPY for
buffer copies
As I start X, and when the stars are in the right position, I get a bunch of
errors like these:
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320251 203afd00 04000e00
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x00203abe80 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: VRAM_LIMIT
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320151 40442000 0400
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x004041 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: NULL_DMAOBJ
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320251 203c7600 04000e00
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x00203c3780 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: VRAM_LIMIT
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320151 40855000 0400
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x004082 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: NULL_DMAOBJ
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
OUT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00340241 2014bb80 05000e00
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: VM: trapped write
at 0x002014ad00 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_OUT reason: VRAM_LIMIT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
OUT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00340241 2014bb80 05000e00
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: VM: trapped write
at 0x00201770f0 on ch 2
Re: [git pull] drm fixes
Hi Dave,
just two changes, one udl endian fix, one nouveau memory corruption on
some GPUs.
I have been tracking an elusive memory corruption bug appearing on my
MacBookAir3,1 (nv50) since -rc0, but unfortunately it seems to be
different from the one fixed here. The problem is of the random kind,
which made bisection tricky. It seems the patch below fixes the
symptoms, but I have no idea why:
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7f80ed5..bff34f4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -935,7 +935,6 @@ nouveau_bo_move_init(struct nouveau_channel *chan)
{ COPY, 0, 0xa0b5, nve0_bo_move_copy, nvc0_bo_move_init },
{ COPY1, 5, 0x90b8, nvc0_bo_move_copy, nvc0_bo_move_init },
{ COPY0, 4, 0x90b5, nvc0_bo_move_copy, nvc0_bo_move_init },
- { COPY, 0, 0x85b5, nva3_bo_move_copy, nv50_bo_move_init },
{ CRYPT, 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init },
{ M2MF, 0, 0x9039, nvc0_bo_move_m2mf, nvc0_bo_move_init },
{ M2MF, 0, 0x5039, nv50_bo_move_m2mf, nv50_bo_move_init },
With the patch applied, the log shows this:
Jun 27 07:01:15 polaris kernel: [drm] nouveau :02:00.0: MM: using M2MF for
buffer copies
Without the patch applied, when the problem appears, the log shows this:
Jun 27 06:50:34 polaris kernel: [drm] nouveau :02:00.0: MM: using COPY for
buffer copies
As I start X, and when the stars are in the right position, I get a bunch of
errors like these:
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320251 203afd00 04000e00
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x00203abe80 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: VRAM_LIMIT
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320151 40442000 0400
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x004041 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: NULL_DMAOBJ
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320251 203c7600 04000e00
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x00203c3780 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: VRAM_LIMIT
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
IN
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00320151 40855000 0400
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:52 polaris kernel: [drm] nouveau :02:00.0: VM: trapped read at
0x004082 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_IN reason: NULL_DMAOBJ
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
OUT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00340241 2014bb80 05000e00
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: VM: trapped write
at 0x002014ad00 on ch 2 [0x0829] PGRAPH/DISPATCH/M2M_OUT reason: VRAM_LIMIT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
OUT
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP_M2MF
00340241 2014bb80 05000e00
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - TRAP
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: PGRAPH - ch 2
(0x829000) subc 0 class 0x5039 mthd 0x0328 data 0x
Jun 27 06:51:53 polaris kernel: [drm] nouveau :02:00.0: VM: trapped write
at 0x00201770f0 on ch 2 [0x0829]
[PATCH] nouveau: Set special lane map for the right chipset
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-off-by: Henrik Rydberg
---
Hi Dave,
This patch fixes a regression in 3.4, tested against -rc2. Resending
for your convenience, in case it got lost.
Thanks,
Henrik
drivers/gpu/drm/nouveau/nv50_sor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_sor.c
b/drivers/gpu/drm/nouveau/nv50_sor.c
index a7844ab..2746402 100644
--- a/drivers/gpu/drm/nouveau/nv50_sor.c
+++ b/drivers/gpu/drm/nouveau/nv50_sor.c
@@ -42,7 +42,7 @@ nv50_sor_dp_lane_map(struct drm_device *dev, struct dcb_entry
*dcb, u8 lane)
struct drm_nouveau_private *dev_priv = dev->dev_private;
static const u8 nvaf[] = { 24, 16, 8, 0 }; /* thanks, apple.. */
static const u8 nv50[] = { 16, 8, 0, 24 };
- if (dev_priv->card_type == 0xaf)
+ if (dev_priv->chipset == 0xaf)
return nvaf[lane];
return nv50[lane];
}
--
1.7.9.5
[PATCH] nouveau: Set special lane map for the right chipset
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-off-by: Henrik Rydberg rydb...@euromail.se
---
Hi Dave,
This patch fixes a regression in 3.4, tested against -rc2. Resending
for your convenience, in case it got lost.
Thanks,
Henrik
drivers/gpu/drm/nouveau/nv50_sor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_sor.c
b/drivers/gpu/drm/nouveau/nv50_sor.c
index a7844ab..2746402 100644
--- a/drivers/gpu/drm/nouveau/nv50_sor.c
+++ b/drivers/gpu/drm/nouveau/nv50_sor.c
@@ -42,7 +42,7 @@ nv50_sor_dp_lane_map(struct drm_device *dev, struct dcb_entry
*dcb, u8 lane)
struct drm_nouveau_private *dev_priv = dev-dev_private;
static const u8 nvaf[] = { 24, 16, 8, 0 }; /* thanks, apple.. */
static const u8 nv50[] = { 16, 8, 0, 24 };
- if (dev_priv-card_type == 0xaf)
+ if (dev_priv-chipset == 0xaf)
return nvaf[lane];
return nv50[lane];
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: Set special lane map for the right chipset
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-off-by: Henrik Rydberg
---
drivers/gpu/drm/nouveau/nv50_sor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_sor.c
b/drivers/gpu/drm/nouveau/nv50_sor.c
index a7844ab..2746402 100644
--- a/drivers/gpu/drm/nouveau/nv50_sor.c
+++ b/drivers/gpu/drm/nouveau/nv50_sor.c
@@ -42,7 +42,7 @@ nv50_sor_dp_lane_map(struct drm_device *dev, struct dcb_entry
*dcb, u8 lane)
struct drm_nouveau_private *dev_priv = dev->dev_private;
static const u8 nvaf[] = { 24, 16, 8, 0 }; /* thanks, apple.. */
static const u8 nv50[] = { 16, 8, 0, 24 };
- if (dev_priv->card_type == 0xaf)
+ if (dev_priv->chipset == 0xaf)
return nvaf[lane];
return nv50[lane];
}
--
1.7.9.5
[PATCH] nouveau: Set special lane map for the right chipset
The refactoring of the nv50 logic, introduced in 8663bc7c, modified the
test for the special lane map used on some Apple computers with Nvidia
chipsets. The tested MBA3,1 would still boot, but resume from suspend
stopped working. This patch restores the old test, which fixes the problem.
Signed-off-by: Henrik Rydberg rydb...@euromail.se
---
drivers/gpu/drm/nouveau/nv50_sor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_sor.c
b/drivers/gpu/drm/nouveau/nv50_sor.c
index a7844ab..2746402 100644
--- a/drivers/gpu/drm/nouveau/nv50_sor.c
+++ b/drivers/gpu/drm/nouveau/nv50_sor.c
@@ -42,7 +42,7 @@ nv50_sor_dp_lane_map(struct drm_device *dev, struct dcb_entry
*dcb, u8 lane)
struct drm_nouveau_private *dev_priv = dev-dev_private;
static const u8 nvaf[] = { 24, 16, 8, 0 }; /* thanks, apple.. */
static const u8 nv50[] = { 16, 8, 0, 24 };
- if (dev_priv-card_type == 0xaf)
+ if (dev_priv-chipset == 0xaf)
return nvaf[lane];
return nv50[lane];
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
