[Nouveau] Fwd: [bisected] nouveau failure with 3.9-rc1 and ongoing
Hiya, I sent the enclosed email to linux-kernel before realizing that it would, perhaps, be more proper to send it here, which I hereby do. I shall be happy to try out any and all patches. Best regards, Sune Mølgaard Original Message Subject: [bisected] nouveau failure with 3.9-rc1 and ongoing Date: Tue, 12 Mar 2013 19:57:55 +0100 From: Sune Mølgaard s...@molgaard.org To: linux-ker...@vger.kernel.org Hiya, Between 3.8 and 3.9-rc1, the following occurs: Upon boot, when KMS kicks in, I get a blank screen. Keyboard responds correctly to Num Lock on/off, but machine is unreachable on the network. Git bisection says: eb6313add6dddf07ea3e50c4caa33a9c3b2379f1 is the first bad commit commit eb6313add6dddf07ea3e50c4caa33a9c3b2379f1 Author: Ben Skeggs bske...@redhat.com Date: Mon Feb 11 09:52:58 2013 +1000 drm/nv50: initial kms support for off-chip TMDS/DP encoders Signed-off-by: Ben Skeggs bske...@redhat.com :04 04 41f69d26a80082e19d3c76e6556ad5ef9eb2677d 216d501e053e9d05136929593e90259c2e59dff0 M drivers But even though I marked that last bisection kernel good (since it didn't cause a black-out), it does have problems, namely that GTK themes are reset, and xrandr seems non-functional, inasmuch as my left-ward, secondary screen now seems to be treated as being situated to the right. No previous kernel in the bisection exercise caused anything of the like. I'd be happy to try out any and all patches proposed, and as for the physical card, this is the relevant part: 02:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT] (rev a2) Please let me know if there is anything else I can do to help resolve this! Best regards, Sune Mølgaard -- What a gorgeous day. What effulgent sunshine. It was a day of this sort the McGillicuddy brothers murdered their mother with an axe. - W. C. Fields ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 62305] New: No HDMI Audio out (pass-thru) on Geforce 7600 Go
https://bugs.freedesktop.org/show_bug.cgi?id=62305 Priority: medium Bug ID: 62305 Assignee: nouveau@lists.freedesktop.org Summary: No HDMI Audio out (pass-thru) on Geforce 7600 Go QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: d...@nostar.net Hardware: All Status: NEW Version: unspecified Component: Driver/nouveau Product: xorg -- 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 62305] No HDMI Audio out (pass-thru) on Geforce 7600 Go
https://bugs.freedesktop.org/show_bug.cgi?id=62305 --- Comment #1 from Doug McLain d...@nostar.net --- I have an hp dv9347cl laptop with a Geforce Go 7600. HDMI audio out works in windows using an older nvidia driver. It does not work in linux using the nouveau driver. I also have a Geforce 9400GT card in my desktop with the SPDIF jumpers, connected to my MB, that works great in Linux using the Nouveau. This tells me that there is at least the potential for HDMI Audio pass-thru to work correctly on my laptop. -- 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] Fwd: [bisected] nouveau failure with 3.9-rc1 and ongoing
On Wed, Mar 13, 2013 at 06:22:38PM +0100, Sune Mølgaard wrote: Hiya, I sent the enclosed email to linux-kernel before realizing that it would, perhaps, be more proper to send it here, which I hereby do. I shall be happy to try out any and all patches. Best regards, Sune Mølgaard Original Message Subject: [bisected] nouveau failure with 3.9-rc1 and ongoing Date: Tue, 12 Mar 2013 19:57:55 +0100 From: Sune Mølgaard s...@molgaard.org To: linux-ker...@vger.kernel.org Hiya, Between 3.8 and 3.9-rc1, the following occurs: Upon boot, when KMS kicks in, I get a blank screen. Keyboard responds correctly to Num Lock on/off, but machine is unreachable on the network. Git bisection says: eb6313add6dddf07ea3e50c4caa33a9c3b2379f1 is the first bad commit commit eb6313add6dddf07ea3e50c4caa33a9c3b2379f1 Author: Ben Skeggs bske...@redhat.com Date: Mon Feb 11 09:52:58 2013 +1000 drm/nv50: initial kms support for off-chip TMDS/DP encoders Signed-off-by: Ben Skeggs bske...@redhat.com :04 04 41f69d26a80082e19d3c76e6556ad5ef9eb2677d 216d501e053e9d05136929593e90259c2e59dff0 Mdrivers I think it may be already fixed by commit 94f54f5336aac6801f2a14dcb12467e41b35456a drm/nv50: encoder creation failure doesn't mean full init failure (post 3.9-rc2) But even though I marked that last bisection kernel good (since it didn't cause a black-out), it does have problems, namely that GTK themes are reset, and xrandr seems non-functional, inasmuch as my left-ward, secondary screen now seems to be treated as being situated to the right. No previous kernel in the bisection exercise caused anything of the like. Not sure about this one... Marcin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58984] DRM NOUVEAU: probe of 0001:01:00.0 failed with error -12
https://bugs.freedesktop.org/show_bug.cgi?id=58984 --- Comment #14 from Marcin Slusarz marcin.slus...@gmail.com --- As you mentioned in the mailing list post that there are other problems after fixing this bug, I think the problem is more widespread. If page size on GPU is unconnected to page size on CPU (I think it's more likely than the other option), we need to have our own macros for PAGE_SHIFT / PAGE_MASK / PAGE_SIZE for GPU and use them everywhere, OR use existing CPU macros consistently (there are a lot of places using 12 constant). Either way it's not as simple as this oneliner... -- 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] Fix unaligned accesses for SPARC
On Tue, Mar 12, 2013 at 10:18:41PM -0500, Patrick Baggett wrote:
The nouveau driver makes a number of unaligned accesses via the
ROM16(), ROM32() and ROM64() macros which fault on SPARC (but would be
transparently handled by x86 hardware). Making use of get_unaligned()
macro fixes the problem for me.
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.h
b/drivers/gpu/drm/nouveau/nouveau_bios.h
index 7ccd28f..92031f6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.h
@@ -26,6 +26,8 @@
#include nvreg.h
+#include asm/unaligned.h
+
#define DCB_MAX_NUM_ENTRIES 16
#define DCB_MAX_NUM_I2C_ENTRIES 16
#define DCB_MAX_NUM_GPIO_ENTRIES 32
@@ -33,10 +35,10 @@
#define DCB_LOC_ON_CHIP 0
-#define ROM16(x) le16_to_cpu(*(u16 *)(x))
-#define ROM32(x) le32_to_cpu(*(u32 *)(x))
+#define ROM16(x) le16_to_cpu(get_unaligned((u16 *)(x)))
+#define ROM32(x) le32_to_cpu(get_unaligned((u32 *)(x)))
#define ROM48(x) ({ u8 *p = (x); (u64)ROM16(p[4]) 32 |
ROM32(p[0]); })
-#define ROM64(x) le64_to_cpu(*(u64 *)(x))
+#define ROM64(x) le64_to_cpu(get_unaligned((u64 *)(x)))
#define ROMPTR(d,x) ({\
struct nouveau_drm *drm = nouveau_drm((d)); \
ROM16(x) ? drm-vbios.data[ROM16(x)] : NULL; \
Please take a look at Documentation/SubmittingPatches and resubmit after
adapting.
IMHO, I think you should submit this patch only once you figure out how to
correctly boot and use at least basic accelerated operations, because I'm not
100% sure this is correct - 1. you have other severe issues with nouveau which
may or may not be connected to this code, 2. sparc defines get_unaligned to
__get_unaligned_be, so maybe you need to use _le variant? or maybe use
get_unaligned_le* without le*_to_cpu?.
Marcin
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58984] DRM NOUVEAU: probe of 0001:01:00.0 failed with error -12
https://bugs.freedesktop.org/show_bug.cgi?id=58984 --- Comment #15 from Patrick Baggett baggett.patr...@gmail.com --- Hmm, that does make sense. Alright then, since you seem to have more of an idea of what is going on, how can I help? Which makes sense / is the right route? A private PAGE_SHIFT|MASK|SIZE for GPUs or using the system page size consistently? Are all NV GPUs that support paging using 4K pages? (I say support paging because I had an NV17 GPU that worked fine on SPARC, OpenGL games worked and all). Should I just audit nouveau/*.c for any usage of 12 and try changing it to PAGE_SHIFT to see what happens? Guide me and I'll do all the annoying busy work. ;) Patrick -- 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] Fix unaligned accesses for SPARC
Marcin,
I had the same messages on NV17, which worked extremely well (OpenGL games
worked fine). The kernel will properly emulate the unaligned access, it
just causes a trap which is slow. If the unaligned access caused an error,
the NV17 card would have been unable to function given the number of
erroneous accesses.
Using __get_unaligned_le would probably remove one byteswap though.
Patrick
On Wed, Mar 13, 2013 at 4:29 PM, Marcin Slusarz marcin.slus...@gmail.comwrote:
On Tue, Mar 12, 2013 at 10:18:41PM -0500, Patrick Baggett wrote:
The nouveau driver makes a number of unaligned accesses via the
ROM16(), ROM32() and ROM64() macros which fault on SPARC (but would be
transparently handled by x86 hardware). Making use of get_unaligned()
macro fixes the problem for me.
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.h
b/drivers/gpu/drm/nouveau/nouveau_bios.h
index 7ccd28f..92031f6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.h
@@ -26,6 +26,8 @@
#include nvreg.h
+#include asm/unaligned.h
+
#define DCB_MAX_NUM_ENTRIES 16
#define DCB_MAX_NUM_I2C_ENTRIES 16
#define DCB_MAX_NUM_GPIO_ENTRIES 32
@@ -33,10 +35,10 @@
#define DCB_LOC_ON_CHIP 0
-#define ROM16(x) le16_to_cpu(*(u16 *)(x))
-#define ROM32(x) le32_to_cpu(*(u32 *)(x))
+#define ROM16(x) le16_to_cpu(get_unaligned((u16 *)(x)))
+#define ROM32(x) le32_to_cpu(get_unaligned((u32 *)(x)))
#define ROM48(x) ({ u8 *p = (x); (u64)ROM16(p[4]) 32 |
ROM32(p[0]); })
-#define ROM64(x) le64_to_cpu(*(u64 *)(x))
+#define ROM64(x) le64_to_cpu(get_unaligned((u64 *)(x)))
#define ROMPTR(d,x) ({\
struct nouveau_drm *drm = nouveau_drm((d)); \
ROM16(x) ? drm-vbios.data[ROM16(x)] : NULL; \
Please take a look at Documentation/SubmittingPatches and resubmit after
adapting.
IMHO, I think you should submit this patch only once you figure out how to
correctly boot and use at least basic accelerated operations, because I'm
not
100% sure this is correct - 1. you have other severe issues with nouveau
which
may or may not be connected to this code, 2. sparc defines get_unaligned to
__get_unaligned_be, so maybe you need to use _le variant? or maybe use
get_unaligned_le* without le*_to_cpu?.
Marcin
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58984] DRM NOUVEAU: probe of 0001:01:00.0 failed with error -12
https://bugs.freedesktop.org/show_bug.cgi?id=58984 --- Comment #16 from Marcin Kościelnicki koria...@0x04.net --- (In reply to comment #15) Which makes sense / is the right route? A private PAGE_SHIFT|MASK|SIZE for GPUs or using the system page size consistently? Are all NV GPUs that support paging using 4K pages? (I say support paging because I had an NV17 GPU that worked fine on SPARC, OpenGL games worked and all). All nvidia GPUs all the way back to NV01 support 4kB pages (with NV50-gen ones also supporting 16kB + 64kB and NVC0-gen also supporting 128kB, but these sizes are usually only used for VRAM and not system RAM). -- 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
