Re: [Nouveau] Possible 3.13-rc nouveau regression with GT 560 Ti
On 02/01/14 02:40, Ilia Mirkin wrote: On Wed, Jan 1, 2014 at 9:36 PM, Sid Boyce wrote: On 01/01/14 18:46, Ilia Mirkin wrote: On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce wrote: On 01/01/14 00:55, Ilia Mirkin wrote: On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce wrote: On 31/12/13 10:36, Ilia Mirkin wrote: Having a dmesg would be nice. One thing I can think of off-hand is that 3.13-rc has MSI turned on by default. You can turn it off by adding "nouveau.config=NvMSI=0" to your kernel cmdline. If that doesn't help, a bisect restricted to drivers/gpu/drm/nouveau should show the offending commit fairly quickly. -ilia Adding "nouveau.config=NvMSI=0" to the command line fixed the problem. So it looks like commit 049ffa8ab33a63b3bff672d1a0ee6a35ad253fe8 introduced it. Any chance you might mmiotrace the blob (version 325 or later) to see which registers it fiddles with? Or alternatively, if you have a NVCE card (you never did end up providing the logs which would have made that apparent), could you try replacing nvc3_mc_oclass with nvc0_mc_oclass for the 0xce case in drivers/gpu/drm/nouveau/core/engine/device/nvc0.c? (and boot without the MSI disabling.) The switch has already been made for NVC8 in 0bae1d61c75 -- perhaps there are more "odd" ones. -ilia Fails exactly the same. case 0xc3: device->cname = "GF106"; device->oclass[NVDEV_SUBDEV_VBIOS ] = &nouveau_bios_oclass; device->oclass[NVDEV_SUBDEV_GPIO ] = &nv50_gpio_oclass; device->oclass[NVDEV_SUBDEV_I2C] = &nv94_i2c_oclass; device->oclass[NVDEV_SUBDEV_CLOCK ] = &nvc0_clock_oclass; device->oclass[NVDEV_SUBDEV_THERM ] = &nva3_therm_oclass; device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass; device->oclass[NVDEV_SUBDEV_DEVINIT] = &nvc0_devinit_oclass; device->oclass[NVDEV_SUBDEV_MC ] = nvc0_mc_oclass; < device->oclass[NVDEV_SUBDEV_BUS] = nvc0_bus_oclass; device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass; That's the 0xc3 case... you have a nvce card, not nvc3 -- you would need to change the NVDEV_SUBDEV_MC line to nvc0_mc_oclass for the 0xce case. The dmesg and Xorg.0.log with the problem captured across a ssh link. # ps fax|grep X 5633 pts/0S+ 0:00 \_ grep --color=auto X 5160 tty7 Ss+0:08 \_ /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth /var/lib/kdm/AuthFiles/A:0-yqspza Also # echo mmiotrace > /sys/kernel/debug/tracing/current_tracer -bash: echo: write error: Invalid argument. Take a look at https://wiki.ubuntu.com/X/MMIOTracing -ilia Of course it's a GF114. Made the change and it boots without the command line change. Great! Care to send a patch? -ilia Here it is. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks --- /usr/src/linux-3.13.0-rc6/drivers/gpu/drm/nouveau/core/engine/device/nvc0.c 2013-11-23 13:03:23.797604441 + +++ /usr/src/linux-3.13.0-rc61/drivers/gpu/drm/nouveau/core/engine/device/nvc0.c 2014-01-02 02:13:32.445643092 + @@ -161,7 +161,7 @@ device->oclass[NVDEV_SUBDEV_THERM ] = &nva3_therm_oclass; device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass; device->oclass[NVDEV_SUBDEV_DEVINIT] = &nvc0_devinit_oclass; - device->oclass[NVDEV_SUBDEV_MC ] = nvc3_mc_oclass; + device->oclass[NVDEV_SUBDEV_MC ] = nvc0_mc_oclass; device->oclass[NVDEV_SUBDEV_BUS] = nvc0_bus_oclass; device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass; device->oclass[NVDEV_SUBDEV_FB ] = nvc0_fb_oclass; ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Possible 3.13-rc nouveau regression with GT 560 Ti
On Wed, Jan 1, 2014 at 9:36 PM, Sid Boyce wrote: > On 01/01/14 18:46, Ilia Mirkin wrote: >> >> On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce wrote: >>> >>> On 01/01/14 00:55, Ilia Mirkin wrote: On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce wrote: > > On 31/12/13 10:36, Ilia Mirkin wrote: >> >> Having a dmesg would be nice. One thing I can think of off-hand is >> that 3.13-rc has MSI turned on by default. You can turn it off by >> adding "nouveau.config=NvMSI=0" to your kernel cmdline. If that >> doesn't help, a bisect restricted to drivers/gpu/drm/nouveau should >> show the offending commit fairly quickly. >> >> -ilia >> > Adding "nouveau.config=NvMSI=0" to the command line fixed the problem. > So it looks like commit 049ffa8ab33a63b3bff672d1a0ee6a35ad253fe8 > introduced > it. Any chance you might mmiotrace the blob (version 325 or later) to see which registers it fiddles with? Or alternatively, if you have a NVCE card (you never did end up providing the logs which would have made that apparent), could you try replacing nvc3_mc_oclass with nvc0_mc_oclass for the 0xce case in drivers/gpu/drm/nouveau/core/engine/device/nvc0.c? (and boot without the MSI disabling.) The switch has already been made for NVC8 in 0bae1d61c75 -- perhaps there are more "odd" ones. -ilia >>> Fails exactly the same. >>> case 0xc3: >>> device->cname = "GF106"; >>> >>> device->oclass[NVDEV_SUBDEV_VBIOS ] = >>> &nouveau_bios_oclass; >>> device->oclass[NVDEV_SUBDEV_GPIO ] = >>> &nv50_gpio_oclass; >>> device->oclass[NVDEV_SUBDEV_I2C] = &nv94_i2c_oclass; >>> device->oclass[NVDEV_SUBDEV_CLOCK ] = >>> &nvc0_clock_oclass; >>> device->oclass[NVDEV_SUBDEV_THERM ] = >>> &nva3_therm_oclass; >>> device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass; >>> device->oclass[NVDEV_SUBDEV_DEVINIT] = >>> &nvc0_devinit_oclass; >>> device->oclass[NVDEV_SUBDEV_MC ] = nvc0_mc_oclass; >>> < >>> device->oclass[NVDEV_SUBDEV_BUS] = nvc0_bus_oclass; >>> device->oclass[NVDEV_SUBDEV_TIMER ] = >>> &nv04_timer_oclass; >> >> That's the 0xc3 case... you have a nvce card, not nvc3 -- you would >> need to change the NVDEV_SUBDEV_MC line to nvc0_mc_oclass for the 0xce >> case. >> >>> The dmesg and Xorg.0.log with the problem captured across a ssh link. >>> >>> # ps fax|grep X >>> 5633 pts/0S+ 0:00 \_ grep --color=auto X >>> 5160 tty7 Ss+0:08 \_ /usr/bin/Xorg -br :0 vt7 -nolisten tcp >>> -auth >>> /var/lib/kdm/AuthFiles/A:0-yqspza >>> >>> Also >>> # echo mmiotrace > /sys/kernel/debug/tracing/current_tracer >>> -bash: echo: write error: Invalid argument. >> >> Take a look at https://wiki.ubuntu.com/X/MMIOTracing >> >>-ilia >> > Of course it's a GF114. > Made the change and it boots without the command line change. Great! Care to send a patch? -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Possible 3.13-rc nouveau regression with GT 560 Ti
On 01/01/14 18:46, Ilia Mirkin wrote: On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce wrote: On 01/01/14 00:55, Ilia Mirkin wrote: On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce wrote: On 31/12/13 10:36, Ilia Mirkin wrote: Having a dmesg would be nice. One thing I can think of off-hand is that 3.13-rc has MSI turned on by default. You can turn it off by adding "nouveau.config=NvMSI=0" to your kernel cmdline. If that doesn't help, a bisect restricted to drivers/gpu/drm/nouveau should show the offending commit fairly quickly. -ilia Adding "nouveau.config=NvMSI=0" to the command line fixed the problem. So it looks like commit 049ffa8ab33a63b3bff672d1a0ee6a35ad253fe8 introduced it. Any chance you might mmiotrace the blob (version 325 or later) to see which registers it fiddles with? Or alternatively, if you have a NVCE card (you never did end up providing the logs which would have made that apparent), could you try replacing nvc3_mc_oclass with nvc0_mc_oclass for the 0xce case in drivers/gpu/drm/nouveau/core/engine/device/nvc0.c? (and boot without the MSI disabling.) The switch has already been made for NVC8 in 0bae1d61c75 -- perhaps there are more "odd" ones. -ilia Fails exactly the same. case 0xc3: device->cname = "GF106"; device->oclass[NVDEV_SUBDEV_VBIOS ] = &nouveau_bios_oclass; device->oclass[NVDEV_SUBDEV_GPIO ] = &nv50_gpio_oclass; device->oclass[NVDEV_SUBDEV_I2C] = &nv94_i2c_oclass; device->oclass[NVDEV_SUBDEV_CLOCK ] = &nvc0_clock_oclass; device->oclass[NVDEV_SUBDEV_THERM ] = &nva3_therm_oclass; device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass; device->oclass[NVDEV_SUBDEV_DEVINIT] = &nvc0_devinit_oclass; device->oclass[NVDEV_SUBDEV_MC ] = nvc0_mc_oclass; < device->oclass[NVDEV_SUBDEV_BUS] = nvc0_bus_oclass; device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass; That's the 0xc3 case... you have a nvce card, not nvc3 -- you would need to change the NVDEV_SUBDEV_MC line to nvc0_mc_oclass for the 0xce case. The dmesg and Xorg.0.log with the problem captured across a ssh link. # ps fax|grep X 5633 pts/0S+ 0:00 \_ grep --color=auto X 5160 tty7 Ss+0:08 \_ /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth /var/lib/kdm/AuthFiles/A:0-yqspza Also # echo mmiotrace > /sys/kernel/debug/tracing/current_tracer -bash: echo: write error: Invalid argument. Take a look at https://wiki.ubuntu.com/X/MMIOTracing -ilia Of course it's a GF114. Made the change and it boots without the command line change. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 64774] nouveau GF108 kernel crash in optimus mode when enabling external display output
https://bugs.freedesktop.org/show_bug.cgi?id=64774 --- Comment #26 from Ilia Mirkin --- FWIW, my patch, which was deemed inappropriate for inclusion: http://marc.info/?l=dri-devel&m=137713025702333&w=2 Later in the thread, another patch was proposed: http://marc.info/?l=dri-devel&m=137715564208095&w=2 However I don't think it has made it upstream yet as Ben had some concerns. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 64774] nouveau GF108 kernel crash in optimus mode when enabling external display output
https://bugs.freedesktop.org/show_bug.cgi?id=64774 Pawel Sikora changed: What|Removed |Added CC||pl...@agmk.net --- Comment #25 from Pawel Sikora --- fc20 crash: https://bugzilla.redhat.com/show_bug.cgi?id=1047169 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] drm-nouveau-next - write trapped by fbcon
On Wed, 1 Jan 2014 15:43:16 -0500 Ilia Mirkin wrote: > On Wed, Jan 1, 2014 at 3:29 PM, Michele Baldessari > > FWIW a Fedora user got those messages on stock 3.13-rc6 with and > > without the "nouveau.config=nvMSI=0" boot option: > > [ 10.812029] nouveau E[ PFB][:01:00.0] trapped write at > > 0x525500 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/FB > > reason: PAGE_NOT_PRESENT > > > > This is via BZ https://bugzilla.redhat.com/show_bug.cgi?id=927451 > > That bug is about someone with a NV84, so my comment about NVAA/NVAC > similarities doesn't apply. But it's good to know that MSI isn't at > fault (probably). I guess it's bisect time. ACK. I'll try to bisect with the user and report back. Thanks, Michele ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] drm-nouveau-next - write trapped by fbcon
On Wed, Jan 1, 2014 at 3:29 PM, Michele Baldessari wrote: > On Wed, Dec 11, 2013 at 07:21:05AM -0500, Ilia Mirkin wrote: >> >> On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote: >> >> > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont wrote: >> >> > > With drm-nouveau-next branch on top of 3.13-rc2 and a few sound >> >> > > commits >> >> > > I get following errors in kernel log (repeating much more often). >> >> > > (once there was a corrupted fbcon with matrix-like strings of >> >> > > unrecognizable glyph-strings hanging down from screen top border) >> >> > > >> >> > > These errors do stop once I switch to Xorg. >> >> > > >> >> > > [ 13.825627] nouveau E[ PFB][:02:00.0] trapped write at >> >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB >> >> > > reason: PAGE_NOT_PRESENT >> >> > > [ 13.826506] nouveau E[ PFB][:02:00.0] trapped write at >> >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB >> >> > > reason: PAGE_NOT_PRESENT >> >> > > [ 13.827319] nouveau E[ PFB][:02:00.0] trapped write at >> >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB >> >> > > reason: PAGE_NOT_PRESENT >> >> > > [ 13.828139] nouveau E[ PFB][:02:00.0] trapped write at >> >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB >> >> > > reason: PAGE_NOT_PRESENT >> >> > > [ 13.828957] nouveau E[ PFB][:02:00.0] trapped write at >> >> > > 0x400300 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB >> >> > > reason: PAGE_NOT_PRESENT >> >> > > >> >> > > System MBA2,1 with: >> >> > > 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 >> >> > > [GeForce 9400M] [10de:0870] (rev b1) >> >> > >> >> > Do you also see these in 3.13-rc2 + >> >> > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=a7e4201f0f7d47e03b851f06f8987856e8d33083 >> >> > ? If not, you can reorder the patches (git rebase -i) and bisect the >> >> > rest. Basically the GPU is trying to write to some address that is >> >> > either completely bogus or is stale, and its internal MMU won't let >> >> > it. >> >> >> >> If I remember correctly these did not happen with Linus' rc2 but only >> >> do happen with drm-nouveau-next on top of it. >> >> >> >> I will check and bisect though probably will not get time to complete >> >> bisect before late Saturday. >> >> >> >> >> >> A display glitch during kernel boot with fbcon might be related to this. >> >> (very wild guess based on when the trapped writes happen) >> >> The penguin logo shown by fbcon looks like memcopy'ed to a tiled >> >> framebuffer without respecting the fact that framebuffer is tiled. >> > >> > It was introduced somewhere between 3.12 and 3.13-rc2 though does not >> > happen >> > on every boot and when it happens it might be only a couple of trapped >> > writes >> > or a whole lot flooding complete log buffer. >> > >> > Visually it manifests itself as a scrambled framebuffer >> > (looking like tiled versus untiled writing to framebuffer). >> > When it happens, it seem to be correlated to call to dialog to ask for >> > luks password and screen scrambling happens when boot messages >> > (kernel/userspace) show/scroll by [they wipe out some scrambled area >> > when scrolling by]. >> > >> > Unfortunately it will be rather hard to bisect because sometimes it does >> > not >> > happen. >> > Adding drm-nouveau-next on top of rc2/rc3 does no apparent difference. >> >> A shot in the dark -- try booting with nouveau.config=NvMSI=0. We >> already disable MSI for NVAA, perhaps we should do it for NVAC as >> well. Although the blob drivers have it enabled... but we could be >> doing something wrong. > > Hi Ilia, > > FWIW a Fedora user got those messages on stock 3.13-rc6 with and without the > "nouveau.config=nvMSI=0" boot option: > [ 10.812029] nouveau E[ PFB][:01:00.0] trapped write at > 0x525500 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/FB reason: > PAGE_NOT_PRESENT > > This is via BZ https://bugzilla.redhat.com/show_bug.cgi?id=927451 That bug is about someone with a NV84, so my comment about NVAA/NVAC similarities doesn't apply. But it's good to know that MSI isn't at fault (probably). I guess it's bisect time. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] drm-nouveau-next - write trapped by fbcon
On Wed, Dec 11, 2013 at 07:21:05AM -0500, Ilia Mirkin wrote: > >> On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote: > >> > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont wrote: > >> > > With drm-nouveau-next branch on top of 3.13-rc2 and a few sound commits > >> > > I get following errors in kernel log (repeating much more often). > >> > > (once there was a corrupted fbcon with matrix-like strings of > >> > > unrecognizable glyph-strings hanging down from screen top border) > >> > > > >> > > These errors do stop once I switch to Xorg. > >> > > > >> > > [ 13.825627] nouveau E[ PFB][:02:00.0] trapped write at > >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB > >> > > reason: PAGE_NOT_PRESENT > >> > > [ 13.826506] nouveau E[ PFB][:02:00.0] trapped write at > >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB > >> > > reason: PAGE_NOT_PRESENT > >> > > [ 13.827319] nouveau E[ PFB][:02:00.0] trapped write at > >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB > >> > > reason: PAGE_NOT_PRESENT > >> > > [ 13.828139] nouveau E[ PFB][:02:00.0] trapped write at > >> > > 0x408280 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB > >> > > reason: PAGE_NOT_PRESENT > >> > > [ 13.828957] nouveau E[ PFB][:02:00.0] trapped write at > >> > > 0x400300 on channel 0xfee0 [unknown] BAR/PFIFO_WRITE/FB > >> > > reason: PAGE_NOT_PRESENT > >> > > > >> > > System MBA2,1 with: > >> > > 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 > >> > > [GeForce 9400M] [10de:0870] (rev b1) > >> > > >> > Do you also see these in 3.13-rc2 + > >> > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=a7e4201f0f7d47e03b851f06f8987856e8d33083 > >> > ? If not, you can reorder the patches (git rebase -i) and bisect the > >> > rest. Basically the GPU is trying to write to some address that is > >> > either completely bogus or is stale, and its internal MMU won't let > >> > it. > >> > >> If I remember correctly these did not happen with Linus' rc2 but only > >> do happen with drm-nouveau-next on top of it. > >> > >> I will check and bisect though probably will not get time to complete > >> bisect before late Saturday. > >> > >> > >> A display glitch during kernel boot with fbcon might be related to this. > >> (very wild guess based on when the trapped writes happen) > >> The penguin logo shown by fbcon looks like memcopy'ed to a tiled > >> framebuffer without respecting the fact that framebuffer is tiled. > > > > It was introduced somewhere between 3.12 and 3.13-rc2 though does not happen > > on every boot and when it happens it might be only a couple of trapped > > writes > > or a whole lot flooding complete log buffer. > > > > Visually it manifests itself as a scrambled framebuffer > > (looking like tiled versus untiled writing to framebuffer). > > When it happens, it seem to be correlated to call to dialog to ask for > > luks password and screen scrambling happens when boot messages > > (kernel/userspace) show/scroll by [they wipe out some scrambled area > > when scrolling by]. > > > > Unfortunately it will be rather hard to bisect because sometimes it does not > > happen. > > Adding drm-nouveau-next on top of rc2/rc3 does no apparent difference. > > A shot in the dark -- try booting with nouveau.config=NvMSI=0. We > already disable MSI for NVAA, perhaps we should do it for NVAC as > well. Although the blob drivers have it enabled... but we could be > doing something wrong. Hi Ilia, FWIW a Fedora user got those messages on stock 3.13-rc6 with and without the "nouveau.config=nvMSI=0" boot option: [ 10.812029] nouveau E[ PFB][:01:00.0] trapped write at 0x525500 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT This is via BZ https://bugzilla.redhat.com/show_bug.cgi?id=927451 hth, Michele -- Michele Baldessari C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Possible 3.13-rc nouveau regression with GT 560 Ti
On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce wrote: > On 01/01/14 00:55, Ilia Mirkin wrote: >> >> On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce >> wrote: >>> >>> On 31/12/13 10:36, Ilia Mirkin wrote: Having a dmesg would be nice. One thing I can think of off-hand is that 3.13-rc has MSI turned on by default. You can turn it off by adding "nouveau.config=NvMSI=0" to your kernel cmdline. If that doesn't help, a bisect restricted to drivers/gpu/drm/nouveau should show the offending commit fairly quickly. -ilia >>> Adding "nouveau.config=NvMSI=0" to the command line fixed the problem. >>> So it looks like commit 049ffa8ab33a63b3bff672d1a0ee6a35ad253fe8 >>> introduced >>> it. >> >> Any chance you might mmiotrace the blob (version 325 or later) to see >> which registers it fiddles with? Or alternatively, if you have a NVCE >> card (you never did end up providing the logs which would have made >> that apparent), could you try replacing nvc3_mc_oclass with >> nvc0_mc_oclass for the 0xce case in >> drivers/gpu/drm/nouveau/core/engine/device/nvc0.c? (and boot without >> the MSI disabling.) The switch has already been made for NVC8 in >> 0bae1d61c75 -- perhaps there are more "odd" ones. >> >>-ilia >> > Fails exactly the same. > case 0xc3: > device->cname = "GF106"; > > device->oclass[NVDEV_SUBDEV_VBIOS ] = &nouveau_bios_oclass; > device->oclass[NVDEV_SUBDEV_GPIO ] = &nv50_gpio_oclass; > device->oclass[NVDEV_SUBDEV_I2C] = &nv94_i2c_oclass; > device->oclass[NVDEV_SUBDEV_CLOCK ] = &nvc0_clock_oclass; > device->oclass[NVDEV_SUBDEV_THERM ] = &nva3_therm_oclass; > device->oclass[NVDEV_SUBDEV_MXM] = &nv50_mxm_oclass; > device->oclass[NVDEV_SUBDEV_DEVINIT] = &nvc0_devinit_oclass; > device->oclass[NVDEV_SUBDEV_MC ] = nvc0_mc_oclass; > < > device->oclass[NVDEV_SUBDEV_BUS] = nvc0_bus_oclass; > device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass; That's the 0xc3 case... you have a nvce card, not nvc3 -- you would need to change the NVDEV_SUBDEV_MC line to nvc0_mc_oclass for the 0xce case. > > The dmesg and Xorg.0.log with the problem captured across a ssh link. > > # ps fax|grep X > 5633 pts/0S+ 0:00 \_ grep --color=auto X > 5160 tty7 Ss+0:08 \_ /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth > /var/lib/kdm/AuthFiles/A:0-yqspza > > Also > # echo mmiotrace > /sys/kernel/debug/tracing/current_tracer > -bash: echo: write error: Invalid argument. Take a look at https://wiki.ubuntu.com/X/MMIOTracing -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
