[Nouveau] Problem with external monitor on laptop
I am running opensuse Leap 15 on an Alienware laptop. When I plug a monitor into the HDMI socket xrandr shows that is disconnected. How can I get the system to send an event or something so it will look and see that a monitor is there. If I cycle power on the computer with the monitor connected both monitors come up connected. The command xrandr --auto does not bring the disconnected monitor to life. The output of xrandr on the system with both monitors is: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 409mm x 230mm 1920x1080 60.00*+ 1680x1050 59.95 1400x1050 59.98 1280x1024 59.89 1280x960 59.94 1152x864 59.96 1024x768 59.92 800x600 59.86 640x480 59.38 720x400 59.55 640x400 59.95 640x350 59.77 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) HDMI-2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 698mm x 392mm 1920x1080 60.00*+ 50.0059.94 1680x1050 59.88 1600x900 60.00 1280x1024 75.0260.02 1440x900 59.90 1280x800 59.91 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0370.0760.00 832x624 74.55 800x600 72.1975.0060.3256.25 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.6760.0059.94 720x400 70.08 Any input or guidance will be appreciated. Don ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 107003] New: Timeout in nvkm_falcon_v1_clear_interrupt on gp104
https://bugs.freedesktop.org/show_bug.cgi?id=107003 Bug ID: 107003 Summary: Timeout in nvkm_falcon_v1_clear_interrupt on gp104 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: mine...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 140286 --> https://bugs.freedesktop.org/attachment.cgi?id=140286=edit Dmesg captured of timeout occuring Increasing the timeout duration doesn't fix the problem. A cursory look at the code would suggest that the clear interrupt mask fails to be written to the io space of falcon, but that's the extent of my knowledge. Attached dmesg shows the issue occuring. -- 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] [PATCH] drm/nouveau/secboot/acr: Remove VLA usage
On Fri, Jun 22, 2018 at 11:34 PM, Kees Cook wrote:
> On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst wrote:
>> On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
>>> In the quest to remove all stack VLA usage from the kernel[1], this
>>> allocates the working buffers before starting the writing so it won't
>>> abort in the middle. This needs an initial walk of the lists to figure
>>> out how large the buffer should be.
>>>
>>> [1]
>>> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>>>
>>> Signed-off-by: Kees Cook
>>> ---
>>> .../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
>>> .../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
>>> 2 files changed, 37 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> index a721354249ce..d02e183717dc 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>>> @@ -414,6 +414,20 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
>>> list_head *imgs,
>>> {
>>> struct ls_ucode_img *_img;
>>> u32 pos = 0;
>>> + u32 max_desc_size = 0;
>>> + u8 *gdesc;
>>> +
>>> + /* Figure out how large we need gdesc to be. */
>>> + list_for_each_entry(_img, imgs, node) {
>>> + const struct acr_r352_ls_func *ls_func =
>>> +
>>> acr->func->ls_func[_img->falcon_id];
>>> +
>>> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
>>> + }
>>> +
>>> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
>>> + if (!gdesc)
>>> + return -ENOMEM;
>>>
>>> nvkm_kmap(wpr_blob);
>>>
>>> @@ -421,7 +435,6 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
>>> list_head *imgs,
>>> struct ls_ucode_img_r352 *img = ls_ucode_img_r352(_img);
>>> const struct acr_r352_ls_func *ls_func =
>>>
>>> acr->func->ls_func[_img->falcon_id];
>>> - u8 gdesc[ls_func->bl_desc_size];
>>>
>>
>> if there are no guarantees that (ls_func->bl_desc_size & 0x4 == 0),
>> then we need to memset a bit more, because 4 bytes at the time are
>> actually copied inside nvkm_gpuobj_memcpy_to later in that code, but
>> the last 4 bytes are only partly memset to 0.
>
> I think this is unchanged from the original code, yes? The memset() is
> always against bl_desc_size; I haven't changed that.
>
right, but I think before we would upload undefined data (because we
run out of bounds for cerain bl_desc_size), now we get what ever was
left inside the buffer from the previous iteration. Both cases are not
good. It isn't an issue with your patch, the code before wasn't 100%
correct either. But maybe that's fine, because bl_desc_size is always
a multple of 0x4.
>> If ls_func->bl_desc_size is always a multiple of 0x4, then it isn't as
>> important, but still better to be fixed. Or maybe
>> nvkm_gpuobj_memcpy_to should do that handling and check if the size is
>> a multiple of 0x4 and otherwise handle that case?
>>
>> Same is valid for the changes in the r367 file.
>
> Should I resend with both the allocation and the memset getting
> rounded up to the next multiple of 4?
Yeah, I think copying 0 is better than random data.
Your patch is fine as it is though, because it doesn't add a new
issue, it just showed us there is a potential one. We should keep that
in mind and see how we want to fix that up. I can imagine that this
might cause some issues in some places, maybe it is totally fine.
Thanks
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/secboot/acr: Remove VLA usage
On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst wrote:
> On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> allocates the working buffers before starting the writing so it won't
>> abort in the middle. This needs an initial walk of the lists to figure
>> out how large the buffer should be.
>>
>> [1]
>> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>>
>> Signed-off-by: Kees Cook
>> ---
>> .../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
>> .../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
>> 2 files changed, 37 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> index a721354249ce..d02e183717dc 100644
>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
>> @@ -414,6 +414,20 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
>> list_head *imgs,
>> {
>> struct ls_ucode_img *_img;
>> u32 pos = 0;
>> + u32 max_desc_size = 0;
>> + u8 *gdesc;
>> +
>> + /* Figure out how large we need gdesc to be. */
>> + list_for_each_entry(_img, imgs, node) {
>> + const struct acr_r352_ls_func *ls_func =
>> +
>> acr->func->ls_func[_img->falcon_id];
>> +
>> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
>> + }
>> +
>> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
>> + if (!gdesc)
>> + return -ENOMEM;
>>
>> nvkm_kmap(wpr_blob);
>>
>> @@ -421,7 +435,6 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
>> list_head *imgs,
>> struct ls_ucode_img_r352 *img = ls_ucode_img_r352(_img);
>> const struct acr_r352_ls_func *ls_func =
>>
>> acr->func->ls_func[_img->falcon_id];
>> - u8 gdesc[ls_func->bl_desc_size];
>>
>
> if there are no guarantees that (ls_func->bl_desc_size & 0x4 == 0),
> then we need to memset a bit more, because 4 bytes at the time are
> actually copied inside nvkm_gpuobj_memcpy_to later in that code, but
> the last 4 bytes are only partly memset to 0.
I think this is unchanged from the original code, yes? The memset() is
always against bl_desc_size; I haven't changed that.
> If ls_func->bl_desc_size is always a multiple of 0x4, then it isn't as
> important, but still better to be fixed. Or maybe
> nvkm_gpuobj_memcpy_to should do that handling and check if the size is
> a multiple of 0x4 and otherwise handle that case?
>
> Same is valid for the changes in the r367 file.
Should I resend with both the allocation and the memset getting
rounded up to the next multiple of 4?
-Kees
--
Kees Cook
Pixel Security
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/secboot/acr: Remove VLA usage
On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the working buffers before starting the writing so it won't
> abort in the middle. This needs an initial walk of the lists to figure
> out how large the buffer should be.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook
> ---
> .../nouveau/nvkm/subdev/secboot/acr_r352.c| 25 ---
> .../nouveau/nvkm/subdev/secboot/acr_r367.c| 16 +++-
> 2 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> index a721354249ce..d02e183717dc 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c
> @@ -414,6 +414,20 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
> {
> struct ls_ucode_img *_img;
> u32 pos = 0;
> + u32 max_desc_size = 0;
> + u8 *gdesc;
> +
> + /* Figure out how large we need gdesc to be. */
> + list_for_each_entry(_img, imgs, node) {
> + const struct acr_r352_ls_func *ls_func =
> +
> acr->func->ls_func[_img->falcon_id];
> +
> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
> + }
> +
> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
> + if (!gdesc)
> + return -ENOMEM;
>
> nvkm_kmap(wpr_blob);
>
> @@ -421,7 +435,6 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
> struct ls_ucode_img_r352 *img = ls_ucode_img_r352(_img);
> const struct acr_r352_ls_func *ls_func =
>
> acr->func->ls_func[_img->falcon_id];
> - u8 gdesc[ls_func->bl_desc_size];
>
if there are no guarantees that (ls_func->bl_desc_size & 0x4 == 0),
then we need to memset a bit more, because 4 bytes at the time are
actually copied inside nvkm_gpuobj_memcpy_to later in that code, but
the last 4 bytes are only partly memset to 0.
If ls_func->bl_desc_size is always a multiple of 0x4, then it isn't as
important, but still better to be fixed. Or maybe
nvkm_gpuobj_memcpy_to should do that handling and check if the size is
a multiple of 0x4 and otherwise handle that case?
Same is valid for the changes in the r367 file.
> nvkm_gpuobj_memcpy_to(wpr_blob, pos, >wpr_header,
> sizeof(img->wpr_header));
> @@ -447,6 +460,8 @@ acr_r352_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
>
> nvkm_done(wpr_blob);
>
> + kfree(gdesc);
> +
> return 0;
> }
>
> @@ -771,7 +786,11 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
> *falcon,
> struct fw_bl_desc *hsbl_desc;
> void *bl, *blob_data, *hsbl_code, *hsbl_data;
> u32 code_size;
> - u8 bl_desc[bl_desc_size];
> + u8 *bl_desc;
> +
> + bl_desc = kzalloc(bl_desc_size, GFP_KERNEL);
> + if (!bl_desc)
> + return -ENOMEM;
>
> /* Find the bootloader descriptor for our blob and copy it */
> if (blob == acr->load_blob) {
> @@ -802,7 +821,6 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
> *falcon,
> code_size, hsbl_desc->start_tag, 0, false);
>
> /* Generate the BL header */
> - memset(bl_desc, 0, bl_desc_size);
> acr->func->generate_hs_bl_desc(load_hdr, bl_desc, offset);
>
> /*
> @@ -811,6 +829,7 @@ acr_r352_load(struct nvkm_acr *_acr, struct nvkm_falcon
> *falcon,
> nvkm_falcon_load_dmem(falcon, bl_desc, hsbl_desc->dmem_load_off,
> bl_desc_size, 0);
>
> + kfree(bl_desc);
> return hsbl_desc->start_tag << 8;
> }
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> index 866877b88797..978ad0790367 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c
> @@ -265,6 +265,19 @@ acr_r367_ls_write_wpr(struct acr_r352 *acr, struct
> list_head *imgs,
> {
> struct ls_ucode_img *_img;
> u32 pos = 0;
> + u32 max_desc_size = 0;
> + u8 *gdesc;
> +
> + list_for_each_entry(_img, imgs, node) {
> + const struct acr_r352_ls_func *ls_func =
> +
> acr->func->ls_func[_img->falcon_id];
> +
> + max_desc_size = max(max_desc_size, ls_func->bl_desc_size);
> + }
> +
> + gdesc = kmalloc(max_desc_size, GFP_KERNEL);
> + if (!gdesc)
> + return -ENOMEM;
>
> nvkm_kmap(wpr_blob);
>
> @@ -272,7 +285,6 @@
