[Nouveau] [Bug 93875] Random Xorg Crash when Away from Computer

2016-02-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=93875

Christopher M. Penalver  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Christopher M. Penalver  
---
fd_mi...@ptaff.ca, thank you for reporting this and helping make Ubuntu better.
However, you are using a downstream version of the xorg stack, and kernel.

Please follow these instructions to have apport report a new bug about your
crash that can be dealt with by the automatic retracer. First, execute at a
terminal:
cd /var/crash && sudo rm * ; sudo apt-get update && sudo apt-get -y
dist-upgrade && sudo service apport start force_start=1

If you are running the Ubuntu Stable Release you might need to enable apport in
/etc/default/apport and restart. Now reproduce the crash, then open a terminal,
navigate to your /var/crash directory and file your report with:
sudo ubuntu-bug /var/crash/_my_crash_report.crash

where _my_crash_report.crash is the crash you would like to report. By default,
this sends the crash to the Ubuntu Error Tracker infrastructure, which is
different than Launchpad. For more on this, please see
https://wiki.ubuntu.com/ErrorTracker .  

However, if after doing this you would still like to have a crash report posted
to Launchpad, for example to ease triage and add others to your report, one
would need to open the following file via a terminal:
sudo nano /etc/apport/crashdb.conf

and comment out the line:
'problem_types': ['Bug', 'Package'],

by changing it to:
# 'problem_types': ['Bug', 'Package'],

Save, close, and file the crash report via:
sudo ubuntu-bug /var/crash/FILENAME.crash

Where FILENAME is the actual name of the file found in the folder.

However, this report is being closed since the process outlined above will deal
with this issue more efficiently.

Also, please do not attach your crash report manually to this report and reopen
it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

-- 
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 93932] Xorg/Nouveau crashes with Segmentation fault when setting i7-Skylake iGPU as primary grapics device in BIOS

2016-02-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=93932

Christopher M. Penalver  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Christopher M. Penalver  
---
Matthias, thank you for reporting this and helping make Ubuntu better. However,
your crash report is manually attached.

Please follow these instructions to have apport report a new bug about your
crash that can be dealt with by the automatic retracer. First, execute at a
terminal:
cd /var/crash && sudo rm * ; sudo apt-get update && sudo apt-get -y
dist-upgrade && sudo service apport start force_start=1

If you are running the Ubuntu Stable Release you might need to enable apport in
/etc/default/apport and restart. Now reproduce the crash, then open a terminal,
navigate to your /var/crash directory and file your report with:
sudo ubuntu-bug /var/crash/_my_crash_report.crash

where _my_crash_report.crash is the crash you would like to report. By default,
this sends the crash to the Ubuntu Error Tracker infrastructure, which is
different than Launchpad. For more on this, please see
https://wiki.ubuntu.com/ErrorTracker .  

However, if after doing this you would still like to have a crash report posted
to Launchpad, for example to ease triage and add others to your report, one
would need to open the following file via a terminal:
sudo nano /etc/apport/crashdb.conf

and comment out the line:
'problem_types': ['Bug', 'Package'],

by changing it to:
# 'problem_types': ['Bug', 'Package'],

Save, close, and file the crash report via:
sudo ubuntu-bug /var/crash/FILENAME.crash

Where FILENAME is the actual name of the file found in the folder.

However, this report is being closed since the process outlined above will deal
with this issue more efficiently.

Also, please do not attach your crash report manually to this report and reopen
it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

-- 
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] Dealing with opencl kernel parameters in nouveau now that RES support is gone

2016-02-23 Thread Ilia Mirkin 
On Tue, Feb 23, 2016 at 7:12 AM, Pierre Moreau  wrote:
> On 11:43 AM - Feb 23 2016, Hans de Goede wrote:
>> Hi,
>>
>
> [snip]
>
>>
>> >You may have to add LOAD64/STORE64 for 64-bit
>> >addresses though. Or we could decree that all addressing on global
>> >memory shall be 64-bit (and thus read the .xy components of the
>> >address source).
>>
>> I would prefer to keep LOAD / STORE semantics the same as with
>> other LOAD / STORE -s to / from 1d buffers.
>>
>> I think that in the end the tgsi backend for llvm will get both
>> a 32 bit and a 64 bit mode, like the nvptx backend already has.
>>
>> And then the 64 bit backend will use a new LOAD64 / STORE64
>> also do not forget that keeping 64 bit pointers takes twice as
>> much registers, so 32 bit will likely be optimal in a lot of
>> cases. I guess since OpenCL does not give the user a way
>> to select which mode to use we will end up with some sort
>> of heuristic based on the amount of memory on the card or
>> some such.
>>
>> After all using 64 bit pointers does not make a lot of sense
>> on a card with only 1 GB of RAM (yes I know we're talking virtual
>> address space here).
>>
>> Anyways this all really is too soon to tell. Maybe the performance
>> impact of using 64 bit pointers is negligible. But I think it would
>> be good (and consistent) to keep LOAD / STORE taking 32 bit addresses
>> even for MEMORY and add a LOAD64 / STORE64 when I get around to
>> implementing a 64 bit mode for the llvm tgsi backend (or when others
>> need them).
>>
>> >>>Another way of looking at it is that instead of having the hacky
>> >>>RES[12345] being hardcoded to mean something special, you now have a
>> >>>dedicated file called 'MEMORY', which has identical semantics.
>> >>
>> >>
>> >>I'm all for getting rid of the RES[12345] hack :)
>> >>
>> >>I guess where you write "you now have a dedicated file called 'MEMORY'"
>> >>You mean up to X dedicated MEMORY[#] files, one for each of GLOBAL, SHARED
>> >>and LOCAL at least, and probably as discussed one for INPUT ?
>> >>
>> >>This all sounds good to me, as said my worry was that MEMORY would have
>> >>an implied base address like BUFFER has, now that you've
>> >>made clear that MEMORY does not have this I'm happy :)
>> >
>> >There's a bit of a wrinkle here, and it's questionable whether we want
>> >to allow for this somehow, but... Tesla actually has no way to address
>> >global memory. It's always done with a base offset (which can be set
>> >to 0). The trick is that it can only address 32 bits at a time,
>> >there's no 64-bit addressing. But it has *16* such "global" memory
>> >spaces, i.e. which are each base + up to 32-bit offset [and ultimately
>> >only 40 bits of addressability]. I don't know if OpenCL provides
>> >something good for that, if it does we can use semantic indices on the
>> >GLOBAL to make it like
>> >
>> >DCL MEMORY[0], GLOBAL[0]
>> >DCL MEMORY[1], GLOBAL[1]
>> >
>> >etc. But again, this is pretty optional.
>>
>> I think that for Tesla we can just only support the tgsi32 target
>> and not the tgsi64 target, at least that is how I envision things
>> today, who knows what tomorrow will bring :)
>
> Fermi is the first family supporting 64 bit addresses, on top of 32 bit
> addresses, while Kepler can only do 64 bit IIRC (or is it Maxwell which 
> dropped
> the 32 bit support?).

I've only ever seen the blob do 64-bit addressing in OpenGL shaders on
Fermi+. However Hans assures me that 32-bit addressing actually works
fine, presumably the upper 8 bits are set to 0 or some constant
supplied via some register somewhere. All of the SM20+ ISA's have a
separate "wide address" bit in their gmem-using instructions. (aka "E"
in nvdisasm)

Anyways, the only reason to add LOAD64 is not to muddy LOAD semantics.
LOAD should remain 32-bit (single-component), while LOAD64 would be
defined only for 1d entities and combine the first 2 components of the
address source.

I think Hans and I are in agreement on most points now... the only
issue is that we don't really control where in VA space buffers are
allocated, so you even if you have 1MB of vram, it might end up being
somewhere in far-off 40-bit land. Ben has promised to provide such
control in the future, but who knows when that work will land.

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Dealing with opencl kernel parameters in nouveau now that RES support is gone

2016-02-23 Thread Pierre Moreau 
On 11:43 AM - Feb 23 2016, Hans de Goede wrote:
> Hi,
> 

[snip]

> 
> >You may have to add LOAD64/STORE64 for 64-bit
> >addresses though. Or we could decree that all addressing on global
> >memory shall be 64-bit (and thus read the .xy components of the
> >address source).
> 
> I would prefer to keep LOAD / STORE semantics the same as with
> other LOAD / STORE -s to / from 1d buffers.
> 
> I think that in the end the tgsi backend for llvm will get both
> a 32 bit and a 64 bit mode, like the nvptx backend already has.
> 
> And then the 64 bit backend will use a new LOAD64 / STORE64
> also do not forget that keeping 64 bit pointers takes twice as
> much registers, so 32 bit will likely be optimal in a lot of
> cases. I guess since OpenCL does not give the user a way
> to select which mode to use we will end up with some sort
> of heuristic based on the amount of memory on the card or
> some such.
> 
> After all using 64 bit pointers does not make a lot of sense
> on a card with only 1 GB of RAM (yes I know we're talking virtual
> address space here).
> 
> Anyways this all really is too soon to tell. Maybe the performance
> impact of using 64 bit pointers is negligible. But I think it would
> be good (and consistent) to keep LOAD / STORE taking 32 bit addresses
> even for MEMORY and add a LOAD64 / STORE64 when I get around to
> implementing a 64 bit mode for the llvm tgsi backend (or when others
> need them).
> 
> >>>Another way of looking at it is that instead of having the hacky
> >>>RES[12345] being hardcoded to mean something special, you now have a
> >>>dedicated file called 'MEMORY', which has identical semantics.
> >>
> >>
> >>I'm all for getting rid of the RES[12345] hack :)
> >>
> >>I guess where you write "you now have a dedicated file called 'MEMORY'"
> >>You mean up to X dedicated MEMORY[#] files, one for each of GLOBAL, SHARED
> >>and LOCAL at least, and probably as discussed one for INPUT ?
> >>
> >>This all sounds good to me, as said my worry was that MEMORY would have
> >>an implied base address like BUFFER has, now that you've
> >>made clear that MEMORY does not have this I'm happy :)
> >
> >There's a bit of a wrinkle here, and it's questionable whether we want
> >to allow for this somehow, but... Tesla actually has no way to address
> >global memory. It's always done with a base offset (which can be set
> >to 0). The trick is that it can only address 32 bits at a time,
> >there's no 64-bit addressing. But it has *16* such "global" memory
> >spaces, i.e. which are each base + up to 32-bit offset [and ultimately
> >only 40 bits of addressability]. I don't know if OpenCL provides
> >something good for that, if it does we can use semantic indices on the
> >GLOBAL to make it like
> >
> >DCL MEMORY[0], GLOBAL[0]
> >DCL MEMORY[1], GLOBAL[1]
> >
> >etc. But again, this is pretty optional.
> 
> I think that for Tesla we can just only support the tgsi32 target
> and not the tgsi64 target, at least that is how I envision things
> today, who knows what tomorrow will bring :)

Fermi is the first family supporting 64 bit addresses, on top of 32 bit
addresses, while Kepler can only do 64 bit IIRC (or is it Maxwell which dropped
the 32 bit support?).

Regards,
Pierre

> 
> Regards,
> 
> Hans
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [GIT,PULL] Signed firmware for NVIDIA Maxwell 2 GPUs

2016-02-23 Thread Alexandre Courbot 

Hi linux-firmware maintainers,

The following changes since commit f66eccaab7d605d433cb82e389441b21ec99b40f:

  Update Intel OPA hfi1 firmware (2016-02-15 08:34:16 -0500)

are available in the git repository at:

  https://github.com/Gnurou/linux-firmware.git secboot

for you to fetch changes up to 8d1fd61a3723ab8cb6b7bfeb8be38e16282cc1ed:

  nvidia: Add GM20B signed firmware (2016-02-23 18:48:41 +0900)

These two patches add the NVIDIA-released firmwares necessary to enable 
rendering on desktop and mobile Maxwell 2 GPUs. Kernel support is ready 
to be merged once this pull request is officially accepted.


Thanks!


Alexandre Courbot (2):
  nvidia: Add GM200, GM204 and GM206 signed firmware
  nvidia: Add GM20B signed firmware

 WHENCE |  61 
-

 nvidia/gm200/acr/bl.bin| Bin 0 -> 832 bytes
 nvidia/gm200/acr/ucode_load.bin| Bin 0 -> 10144 bytes
 nvidia/gm200/acr/ucode_unload.bin  | Bin 0 -> 1440 bytes
 nvidia/gm200/gr/fecs_bl.bin| Bin 0 -> 576 bytes
 nvidia/gm200/gr/fecs_data.bin  | Bin 0 -> 1968 bytes
 nvidia/gm200/gr/fecs_inst.bin  | Bin 0 -> 16271 bytes
 nvidia/gm200/gr/fecs_sig.bin   | Bin 0 -> 76 bytes
 nvidia/gm200/gr/gpccs_bl.bin   | Bin 0 -> 576 bytes
 nvidia/gm200/gr/gpccs_data.bin | Bin 0 -> 2056 bytes
 nvidia/gm200/gr/gpccs_inst.bin | Bin 0 -> 9768 bytes
 nvidia/gm200/gr/gpccs_sig.bin  | Bin 0 -> 76 bytes
 nvidia/gm200/gr/sw_bundle_init.bin | Bin 0 -> 7616 bytes
 nvidia/gm200/gr/sw_ctx.bin | Bin 0 -> 5592 bytes
 nvidia/gm200/gr/sw_method_init.bin | Bin 0 -> 10800 bytes
 nvidia/gm200/gr/sw_nonctx.bin  | Bin 0 -> 1440 bytes
 nvidia/gm204/acr/bl.bin|   1 +
 nvidia/gm204/acr/ucode_load.bin|   1 +
 nvidia/gm204/acr/ucode_unload.bin  |   1 +
 nvidia/gm204/gr/fecs_bl.bin|   1 +
 nvidia/gm204/gr/fecs_data.bin  | Bin 0 -> 1968 bytes
 nvidia/gm204/gr/fecs_inst.bin  |   1 +
 nvidia/gm204/gr/fecs_sig.bin   | Bin 0 -> 76 bytes
 nvidia/gm204/gr/gpccs_bl.bin   |   1 +
 nvidia/gm204/gr/gpccs_data.bin | Bin 0 -> 2056 bytes
 nvidia/gm204/gr/gpccs_inst.bin |   1 +
 nvidia/gm204/gr/gpccs_sig.bin  | Bin 0 -> 76 bytes
 nvidia/gm204/gr/sw_bundle_init.bin |   1 +
 nvidia/gm204/gr/sw_ctx.bin |   1 +
 nvidia/gm204/gr/sw_method_init.bin |   1 +
 nvidia/gm204/gr/sw_nonctx.bin  |   1 +
 nvidia/gm206/acr/bl.bin|   1 +
 nvidia/gm206/acr/ucode_load.bin| Bin 0 -> 10144 bytes
 nvidia/gm206/acr/ucode_unload.bin  | Bin 0 -> 1440 bytes
 nvidia/gm206/gr/fecs_bl.bin|   1 +
 nvidia/gm206/gr/fecs_data.bin  | Bin 0 -> 1968 bytes
 nvidia/gm206/gr/fecs_inst.bin  |   1 +
 nvidia/gm206/gr/fecs_sig.bin   | Bin 0 -> 76 bytes
 nvidia/gm206/gr/gpccs_bl.bin   |   1 +
 nvidia/gm206/gr/gpccs_data.bin | Bin 0 -> 2056 bytes
 nvidia/gm206/gr/gpccs_inst.bin |   1 +
 nvidia/gm206/gr/gpccs_sig.bin  | Bin 0 -> 76 bytes
 nvidia/gm206/gr/sw_bundle_init.bin |   1 +
 nvidia/gm206/gr/sw_ctx.bin |   1 +
 nvidia/gm206/gr/sw_method_init.bin |   1 +
 nvidia/gm206/gr/sw_nonctx.bin  |   1 +
 nvidia/gm20b/acr/bl.bin| Bin 0 -> 832 bytes
 nvidia/gm20b/acr/ucode_load.bin| Bin 0 -> 18592 bytes
 nvidia/gm20b/gr/fecs_bl.bin| Bin 0 -> 576 bytes
 nvidia/gm20b/gr/fecs_data.bin  | Bin 0 -> 1964 bytes
 nvidia/gm20b/gr/fecs_inst.bin  | Bin 0 -> 17021 bytes
 nvidia/gm20b/gr/fecs_sig.bin   | Bin 0 -> 76 bytes
 nvidia/gm20b/gr/gpccs_data.bin | Bin 0 -> 2068 bytes
 nvidia/gm20b/gr/gpccs_inst.bin | Bin 0 -> 9964 bytes
 nvidia/gm20b/gr/sw_bundle_init.bin | Bin 0 -> 7616 bytes
 nvidia/gm20b/gr/sw_ctx.bin | Bin 0 -> 5448 bytes
 nvidia/gm20b/gr/sw_method_init.bin |   1 +
 nvidia/gm20b/gr/sw_nonctx.bin  | Bin 0 -> 1432 bytes
 58 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 nvidia/gm200/acr/bl.bin
 create mode 100644 nvidia/gm200/acr/ucode_load.bin
 create mode 100644 nvidia/gm200/acr/ucode_unload.bin
 create mode 100644 nvidia/gm200/gr/fecs_bl.bin
 create mode 100644 nvidia/gm200/gr/fecs_data.bin
 create mode 100644 nvidia/gm200/gr/fecs_inst.bin
 create mode 100644 nvidia/gm200/gr/fecs_sig.bin
 create mode 100644 nvidia/gm200/gr/gpccs_bl.bin
 create mode 100644 nvidia/gm200/gr/gpccs_data.bin
 create mode 100644 nvidia/gm200/gr/gpccs_inst.bin
 create mode 100644 nvidia/gm200/gr/gpccs_sig.bin
 create mode 100644 nvidia/gm200/gr/sw_bundle_init.bin
 create mode 100644 nvidia/gm200/gr/sw_ctx.bin
 create mode 100644 nvidia/gm200/gr/sw_method_init.bin
 create mode 100644 nvidia/gm200/gr/sw_nonctx.bin
 create mode 12 nvidia/gm204/acr/bl.bin
 create mode 12 nvidia/gm204/acr/ucode_load.bin
 create mode 12 nvidia/gm204/acr/ucode_unload.bin
 create mode 12 nvidia/gm204/gr/fecs_bl.bin
 create mode 100644 nvidia/gm204/gr/fecs_data.bin
 create mode 12 nvidia/gm204/gr/fecs_inst.bin