Re: [Nouveau] GM108GLM?
hi, give the drm-next kernel tree a try. Sadly the reclocking improvements didn't land with 4.9, so 4.10 is required. Greetings. On 7 December 2016 10:26:44 a.m. GMT+01:00, "Sune Mølgaard" wrote: >Hi again, > >It works :-) > >Reclocking, however, is another kettle of fish. > >Trying #echo 0f > /sys/kernel/debug/dri/0/pstate hangs X. > >Trying the same with no X running reveals: > >Dec 7 10:08:42 dell-smo kernel: [ 728.831020] nouveau :08:00.0: >clk: unable to find matching pll values > >a number of time as then soft lockup. > >Very much akin to >https://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau&date=2016-04-14 >, actually, so what I gather from that is that I need to provide you >guys with some info about the card, so which do you need, and how do I >extract them? > >Best regards, > >Sune Mølgaard > >On 2016-10-27 11:06, Pierre Moreau wrote: >> Hello, >> >> The idea was to use the modesetting DDX instead of Nouveau’s one for >Maxwell+ >> as EXA was [broken][1]. But you can give a try at Ilia’s >[patches][2], which >> fix the Nouveau DDX for GM10x and GM20x (I don’t think it has been >tested on a >> GM108 yet). >> >> Best regards, >> Pierre Moreau >> >> [1]: >https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=3e2e0faa2ee1cce9c1bb5c7ad80d0592460f3edc >> [2]: https://github.com/imirkin/xf86-video-nouveau/ >> >> >> On 11:29 am - Oct 18 2016, Sune Mølgaard wrote: >>> Hi, >>> >>> It would seem like it (attachments are from 4.9-rc1, btw), but it >>> doesn't look like there is any support in the Xorg driver. >>> >>> How can I help with that? >>> >>> Best regards, >>> >>> Sune Mølgaard >>> Translucent ApS >>> >>> On 2016-04-22 09:33, Pierre Moreau wrote: Hello, A patch was merged yesterday to recognise GM108 (see >https://github.com/skeggsb/nouveau/commit/3da1f2a19e5e8dc8d68a4400d9cca01c64ecd59e). I guess it will make it into 4.7. Pierre >>> >> >>> lspci - >>> 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI >(rev 09) >>> Subsystem: Lenovo Broadwell-U Host Bridge -OPI >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- >SERR- >> Latency: 0 >>> Capabilities: >>> Kernel driver in use: bdw_uncore >>> >>> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U >Integrated Graphics (rev 09) (prog-if 00 [VGA controller]) >>> Subsystem: Lenovo Broadwell-U Integrated Graphics >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- >SERR- >> Latency: 0 >>> Interrupt: pin A routed to IRQ 49 >>> Region 0: Memory at f200 (64-bit, non-prefetchable) [size=16M] >>> Region 2: Memory at c000 (64-bit, prefetchable) [size=512M] >>> Region 4: I/O ports at 4000 [size=64] >>> [virtual] Expansion ROM at 000c [disabled] [size=128K] >>> Capabilities: >>> Kernel driver in use: i915 >>> Kernel modules: i915 >>> >>> 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller >(rev 09) >>> Subsystem: Lenovo Broadwell-U Audio Controller >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >SERR- >> Latency: 0, Cache Line Size: 64 bytes >>> Interrupt: pin A routed to IRQ 50 >>> Region 0: Memory at f423 (64-bit, non-prefetchable) [size=16K] >>> Capabilities: >>> Kernel driver in use: snd_hda_intel >>> Kernel modules: snd_hda_intel >>> >>> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI >Controller (rev 03) (prog-if 30 [XHCI]) >>> Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- >SERR- >> Latency: 0 >>> Interrupt: pin A routed to IRQ 42 >>> Region 0: Memory at f422 (64-bit, non-prefetchable) [size=64K] >>> Capabilities: >>> Kernel driver in use: xhci_hcd >>> >>> 00:16.0 Communication controller: Intel Corporation Wildcat Point-LP >MEI Controller #1 (rev 03) >>> Subsystem: Lenovo Wildcat Point-LP MEI Controller >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >SERR- >> Latency: 0 >>> Interrupt: pin A routed to IRQ 46 >>> Region 0: Memory at f4239000 (64-bit, non-prefetchable) [size=32] >>> Capabilities: >>> Kernel driver in use: mei_me >>> Kernel modules: mei_me >>> >>> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection >(3) I218-V (rev 03
Re: [Nouveau] [PATCH v3 2/2] Do not register interface if Apple GMUX detected
On Thu, Dec 08, 2016 at 12:57:09AM +0100, Pierre Moreau wrote:
> The Apple GMUX is the one managing the backlight, so there is no need for
> Nouveau to register its own backlight interface.
>
> v2: Do not split information message on two lines as it prevents from grepping
> it, as pointed out by Lukas Wunner
>
> v3: Add a missing end-of-line character to the printed message
>
> Signed-off-by: Pierre Moreau
Reviewed-by: Lukas Wunner
Thanks,
Lukas
> ---
> drm/nouveau/nouveau_backlight.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index a34cd35..8b1ca4a 100644
> --- a/drm/nouveau/nouveau_backlight.c
> +++ b/drm/nouveau/nouveau_backlight.c
> @@ -30,6 +30,7 @@
> * Register locations derived from NVClock by Roderick Colenbrander
> */
>
> +#include
> #include
> #include
>
> @@ -267,6 +268,11 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nvif_device *device = &drm->device;
> struct drm_connector *connector;
>
> + if (apple_gmux_present()) {
> + NV_INFO(drm, "Apple GMUX detected: not registering Nouveau
> backlight interface\n");
> + return 0;
> + }
> +
> INIT_LIST_HEAD(&drm->bl_connectors);
>
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> --
> 2.10.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v3 2/2] Do not register interface if Apple GMUX detected
The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.
v2: Do not split information message on two lines as it prevents from grepping
it, as pointed out by Lukas Wunner
v3: Add a missing end-of-line character to the printed message
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_backlight.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index a34cd35..8b1ca4a 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -30,6 +30,7 @@
* Register locations derived from NVClock by Roderick Colenbrander
*/
+#include
#include
#include
@@ -267,6 +268,11 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = &drm->device;
struct drm_connector *connector;
+ if (apple_gmux_present()) {
+ NV_INFO(drm, "Apple GMUX detected: not registering Nouveau
backlight interface\n");
+ return 0;
+ }
+
INIT_LIST_HEAD(&drm->bl_connectors);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
--
2.10.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 1/2] nouveau/bl: Assign different names to interfaces
Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539
v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.
v3:
* Define a macro for the size of the backlight name, to avoid defining
it multiple times;
* Use snprintf in place of sprintf.
v4:
* Do not create similarly named interfaces when reaching the maximum
amount of unique names, but fail instead, as pointed out by Lukas Wunner
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_backlight.c | 74 ++---
drm/nouveau/nouveau_display.h | 10 ++
drm/nouveau/nouveau_drm.c | 2 ++
drm/nouveau/nouveau_drv.h | 1 +
4 files changed, 83 insertions(+), 4 deletions(-)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 5e2c568..a34cd35 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,35 @@
*/
#include
+#include
#include "nouveau_drv.h"
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
+static struct ida bl_ida;
+#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
+
+struct backlight_connector {
+ struct list_head head;
+ int id;
+};
+
+static bool
+nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE], struct
backlight_connector
+ *connector)
+{
+ const int nb = ida_simple_get(&bl_ida, 0, 0, GFP_KERNEL);
+ if (nb < 0 || nb >= 100)
+ return false;
+ if (nb > 0)
+ snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
+ else
+ snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight");
+ connector->id = nb;
+ return true;
+}
+
static int
nv40_get_intensity(struct backlight_device *bd)
{
@@ -74,6 +98,8 @@ nv40_backlight_init(struct drm_connector *connector)
struct nvif_object *device = &drm->device.object;
struct backlight_properties props;
struct backlight_device *bd;
+ struct backlight_connector bl_connector;
+ char backlight_name[BL_NAME_SIZE];
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,10 +107,19 @@ nv40_backlight_init(struct drm_connector *connector)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 31;
- bd = backlight_device_register("nv_backlight", connector->kdev, drm,
+ if (!nouveau_get_backlight_name(backlight_name, &bl_connector)) {
+ NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
+ return 0;
+ }
+ bd = backlight_device_register(backlight_name , connector->kdev, drm,
&nv40_bl_ops, &props);
- if (IS_ERR(bd))
+
+ if (IS_ERR(bd)) {
+ if (bl_connector.id > 0)
+ ida_simple_remove(&bl_ida, bl_connector.id);
return PTR_ERR(bd);
+ }
+ list_add(&bl_connector.head, &drm->bl_connectors);
drm->backlight = bd;
bd->props.brightness = nv40_get_intensity(bd);
backlight_update_status(bd);
@@ -182,6 +217,8 @@ nv50_backlight_init(struct drm_connector *connector)
struct backlight_properties props;
struct backlight_device *bd;
const struct backlight_ops *ops;
+ struct backlight_connector bl_connector;
+ char backlight_name[BL_NAME_SIZE];
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,11 +240,20 @@ nv50_backlight_init(struct drm_connector *connector)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 100;
- bd = backlight_device_register("nv_backlight", connector->kdev,
+ if (!nouveau_get_backlight_name(backlight_name, &bl_connector)) {
+ NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
+ return 0;
+ }
+ bd = backlight_device_register(backlight_name , connector->kdev,
nv_encoder, ops, &props);
- if (IS_ERR(bd))
+
+ if (IS_ERR(bd)) {
+ if (bl_connector.id > 0)
+ ida_simple_remove(&bl_ida, bl_connector.id);
Re: [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
On 12/07/2016 07:57 PM, Alexandre Courbot wrote: > On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote: >> On 07/12/16 06:39 PM, Alexandre Courbot wrote: >>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote: That's right -- nouveau currently requires 4k page sizes to work. This is a software limitation, not a hardware one though. >>> >>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM? >> >> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu). > > Thanks for the precision. I will check if Tegra iGPUs are also > affected by this - if they are then it gives me a good excuse to take > care of this bug. I *should* have this fixed with a large chunk of MMU work I have pending (I had to drop it temporarily to work on atomic/mst support, but it'll be picked up, rebased, and finished in the near future). I haven't actually tested on 64KiB pages yet, but, I plan to before releasing it. > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > signature.asc Description: OpenPGP digital signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot wrote: > On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote: >> On 07/12/16 06:39 PM, Alexandre Courbot wrote: >>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote: That's right -- nouveau currently requires 4k page sizes to work. This is a software limitation, not a hardware one though. >>> >>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM? >> >> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu). > > Thanks for the precision. I will check if Tegra iGPUs are also > affected by this - if they are then it gives me a good excuse to take > care of this bug. For the most part it's confusion in the (nouveau) code as to what's a gpu page and what's a cpu page (and the shifts involved). There are some fringe issues that will need to be addressed, like the fact that it's no longer a 1:1 mapping, which might be assumed in some places. However I thought that 64K-pages were frowned upon nowadays for the kernel - outside of HPC loads, most of the kernel memory becomes pagecache, and files don't tend to be 64K-sized, so you have tons of wasted memory (since you never cache multiple files in the same page). But don't take that as me disapproving of such a project. It'd esp be nice to do something like this outside of the PPC64 environment, where BE concerns mix in with the 64K page concerns, and nothing works as a result. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94727] [NV30/NV40] nouveau/pushbuf.c:238: pushbuf_krel: Assertion `bkref` failed.
https://bugs.freedesktop.org/show_bug.cgi?id=94727 --- Comment #9 from Olivier Fourdan --- Created attachment 128368 --> https://bugs.freedesktop.org/attachment.cgi?id=128368&action=edit Backtrace of Xwayland on a G71 Thanks for pointing out that it was on a G71, I have been able to reproduce using my own old G71 (Dell m1710) with Fedora 25! Didn't have much luck trying to run Xwayland through apitrace, but I have a corefile of Xwayland, backtrace attached, if that's of any help... -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98852] Nvidia graphics card fan not running or to slow, danger of overheating
https://bugs.freedesktop.org/show_bug.cgi?id=98852 --- Comment #17 from Egon Niessner --- Thanks for your help! With `cmake -G"Unix Makefiles" . I could translate the envytools Package. Here the Output with the nouveau driver and not runnung fan: nvapeek e114 10 e114: 0001 8000 Here the Output with the original nvidia driver (Installed is the original NVIDIA Package NVIDIA-Linux-x86_64-340.96.run) nvapeek e114 120 e114: 0001 0020 0003 e124: 1000 0001010e e134: 000f4240 0007 1000 e144: 0001010e 000f4240 0007 e154: 1000 0001010e e164: 000f4240 0007 1000 e174: 0001010e 000f4240 0007 e184: 0012 0001 e194: 000d e1a4: 0001 000c 0022 e1b4: 0001 fe7f 3047 0002 ... e1d4: 001f 0001 e1e4: 0001 0003 0003 e1f4: 000c 0002 0002 0003103c e204: 0002 -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98852] Nvidia graphics card fan not running or to slow, danger of overheating
https://bugs.freedesktop.org/show_bug.cgi?id=98852 --- Comment #16 from Pierre Moreau --- There is a ninja package on Arch Linux, I would guess that something similar exists on openSUSE. Try with `cmake -G"Unix Makefile" .` instead, or clear the CMake cache (delete CMakeCache.txt and CMakeFiles should be enough I think), and try again to run `cmake .`. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98852] Nvidia graphics card fan not running or to slow, danger of overheating
https://bugs.freedesktop.org/show_bug.cgi?id=98852 --- Comment #15 from Karol Herbst --- (In reply to Egon Niessner from comment #14) > I downloaded the envytools Software from your link and tried an installation. > I got following error messages: > > inux-234d:/home/nie1/envytools/envytools-master # cmake . -G Ninja > CMake Error: CMake was unable to find a build program corresponding to > "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a > different build tool. > CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage > CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage > -- Configuring incomplete, errors occurred! > > > > > linux-234d:/home/nie1/envytools/envytools-master # cmake . > CMake Error: CMake was unable to find a build program corresponding to > "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a > different build tool. > CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage > CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage > -- Configuring incomplete, errors occurred! > > > On the system the whole linux kernel development environment is installed > and all packages mentioned in the envytools description. > What have I to do, that the compilation is possible ? drop the "-G Ninja" -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98852] Nvidia graphics card fan not running or to slow, danger of overheating
https://bugs.freedesktop.org/show_bug.cgi?id=98852 --- Comment #14 from Egon Niessner --- I downloaded the envytools Software from your link and tried an installation. I got following error messages: inux-234d:/home/nie1/envytools/envytools-master # cmake . -G Ninja CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! linux-234d:/home/nie1/envytools/envytools-master # cmake . CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! On the system the whole linux kernel development environment is installed and all packages mentioned in the envytools description. What have I to do, that the compilation is possible ? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote: > On 07/12/16 06:39 PM, Alexandre Courbot wrote: >> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote: >>> That's right -- nouveau currently requires 4k page sizes to work. This is a >>> software limitation, not a hardware one though. >> >> Looking at the trace I wonder - is the limitation in Nouveau or in TTM? > > Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu). Thanks for the precision. I will check if Tegra iGPUs are also affected by this - if they are then it gives me a good excuse to take care of this bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
On 07/12/16 06:39 PM, Alexandre Courbot wrote: > On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote: >> That's right -- nouveau currently requires 4k page sizes to work. This is a >> software limitation, not a hardware one though. > > Looking at the trace I wonder - is the limitation in Nouveau or in TTM? Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GM108GLM?
Hi again, It works :-) Reclocking, however, is another kettle of fish. Trying #echo 0f > /sys/kernel/debug/dri/0/pstate hangs X. Trying the same with no X running reveals: Dec 7 10:08:42 dell-smo kernel: [ 728.831020] nouveau :08:00.0: clk: unable to find matching pll values a number of time as then soft lockup. Very much akin to https://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau&date=2016-04-14 , actually, so what I gather from that is that I need to provide you guys with some info about the card, so which do you need, and how do I extract them? Best regards, Sune Mølgaard On 2016-10-27 11:06, Pierre Moreau wrote: > Hello, > > The idea was to use the modesetting DDX instead of Nouveau’s one for Maxwell+ > as EXA was [broken][1]. But you can give a try at Ilia’s [patches][2], which > fix the Nouveau DDX for GM10x and GM20x (I don’t think it has been tested on a > GM108 yet). > > Best regards, > Pierre Moreau > > [1]: > https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=3e2e0faa2ee1cce9c1bb5c7ad80d0592460f3edc > [2]: https://github.com/imirkin/xf86-video-nouveau/ > > > On 11:29 am - Oct 18 2016, Sune Mølgaard wrote: >> Hi, >> >> It would seem like it (attachments are from 4.9-rc1, btw), but it >> doesn't look like there is any support in the Xorg driver. >> >> How can I help with that? >> >> Best regards, >> >> Sune Mølgaard >> Translucent ApS >> >> On 2016-04-22 09:33, Pierre Moreau wrote: >>> Hello, >>> >>> A patch was merged yesterday to recognise GM108 (see >>> https://github.com/skeggsb/nouveau/commit/3da1f2a19e5e8dc8d68a4400d9cca01c64ecd59e). >>> I guess it will make it into 4.7. >>> >>> Pierre >> > >> lspci - >> 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09) >> Subsystem: Lenovo Broadwell-U Host Bridge -OPI >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- > Latency: 0 >> Capabilities: >> Kernel driver in use: bdw_uncore >> >> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated >> Graphics (rev 09) (prog-if 00 [VGA controller]) >> Subsystem: Lenovo Broadwell-U Integrated Graphics >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- > Latency: 0 >> Interrupt: pin A routed to IRQ 49 >> Region 0: Memory at f200 (64-bit, non-prefetchable) [size=16M] >> Region 2: Memory at c000 (64-bit, prefetchable) [size=512M] >> Region 4: I/O ports at 4000 [size=64] >> [virtual] Expansion ROM at 000c [disabled] [size=128K] >> Capabilities: >> Kernel driver in use: i915 >> Kernel modules: i915 >> >> 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09) >> Subsystem: Lenovo Broadwell-U Audio Controller >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 50 >> Region 0: Memory at f423 (64-bit, non-prefetchable) [size=16K] >> Capabilities: >> Kernel driver in use: snd_hda_intel >> Kernel modules: snd_hda_intel >> >> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI >> Controller (rev 03) (prog-if 30 [XHCI]) >> Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- >> SERR- > Latency: 0 >> Interrupt: pin A routed to IRQ 42 >> Region 0: Memory at f422 (64-bit, non-prefetchable) [size=64K] >> Capabilities: >> Kernel driver in use: xhci_hcd >> >> 00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI >> Controller #1 (rev 03) >> Subsystem: Lenovo Wildcat Point-LP MEI Controller >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > Latency: 0 >> Interrupt: pin A routed to IRQ 46 >> Region 0: Memory at f4239000 (64-bit, non-prefetchable) [size=32] >> Capabilities: >> Kernel driver in use: mei_me >> Kernel modules: mei_me >> >> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) >> I218-V (rev 03) >> Subsystem: Lenovo Ethernet Connection (3) I218-V >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > S
Re: [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote: > That's right -- nouveau currently requires 4k page sizes to work. This is a > software limitation, not a hardware one though. Looking at the trace I wonder - is the limitation in Nouveau or in TTM? > > > On Dec 1, 2016 5:13 PM, "Jeremy Linton" wrote: > > Hi, > > I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau driver > failed to claim the device with : > > [drm] Initialized > nouveau :01:00.0: NVIDIA G94 (094100a1) > nouveau :01:00.0: bios: version 62.94.0d.00.04 > nouveau: probe of :01:00.0 failed with error -22 > > Which with a little bit of debugging seems to be a failure in: > > [77216.692605] [] ttm_bo_validate+0xb0/0x1e8 [ttm] > [77216.698697] [] ttm_bo_init+0x354/0x410 [ttm] > [77216.704706] [] nouveau_bo_new+0x1f4/0x314 [nouveau] > [77216.711308] [] nv50_display_create+0x10c/0xa1c > [nouveau] > [77216.718340] [] nouveau_display_create+0x50c/0x59c > [nouveau] > [77216.725632] [] nouveau_drm_load+0x22c/0x8c0 [nouveau] > [77216.732286] [] drm_dev_register+0xc0/0xf0 [drm] > [77216.738409] [] drm_get_pci_dev+0xbc/0x188 [drm] > [77216.744663] [] nouveau_drm_probe+0x180/0x208 [nouveau] > [77216.751354] [] local_pci_probe+0x50/0xb4 > [77216.756827] [] pci_device_probe+0xf8/0x148 > [77216.762474] [] driver_probe_device+0x284/0x420 > [77216.768467] [] __driver_attach+0x120/0x124 > [77216.774115] [] bus_for_each_dev+0x6c/0xac > [77216.779673] [] driver_attach+0x2c/0x34 > [77216.784972] [] bus_add_driver+0x244/0x2b0 > [77216.790531] [] driver_register+0x68/0xfc > [77216.796004] [] __pci_register_driver+0x60/0x6c > [77216.802047] [] drm_pci_init+0x108/0x138 [drm] > [77216.808146] [] nouveau_drm_init+0x158/0x1 [nouveau] > [77216.814922] [] do_one_initcall+0x44/0x128 > [77216.820483] [] do_init_module+0x68/0x1e0 > [77216.825957] [] load_module+0xfac/0x12bc > [77216.831343] [] SyS_finit_module+0xe4/0xf0 > [77216.836902] [] el0_svc_naked+0x24/0x28 > > By default fedora is using a 64k page kernel, switching to a mainline > 4.9-rc7 kernel using the same configuration the same problem exists (there > are a couple others, mentioned briefly in the defect). Changing the mainline > kernel from 64k to 4k pages corrects the problem and a terminal display can > be seen. > > The fedora defect is: > https://bugzilla.redhat.com/show_bug.cgi?id=1400623 > > > Thanks, > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
