Re: [Nouveau] [PATCH 05/22] mm: export alloc_pages_vma

[Michal Hocko]

On Tue 25-06-19 12:52:18, Dan Williams wrote:
[...]
> > Documentation/process/stable-api-nonsense.rst
> 
> That document has failed to preclude symbol export fights in the past
> and there is a reasonable argument to try not to retract functionality
> that had been previously exported regardless of that document.

Can you point me to any specific example where this would be the case
for the core kernel symbols please?
-- 
Michal Hocko
SUSE Labs
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken

[Michal Hocko]

On Tue 25-06-19 20:15:28, John Hubbard wrote:
> On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
> > On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
> >> On 6/13/19 5:43 PM, Ira Weiny wrote:
> >>> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
>  On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote:
> >
> >> ...
> >>> So I think it is ok.  Frankly I was wondering if we should remove the 
> >>> public
> >>> type altogether but conceptually it seems ok.  But I don't see any users 
> >>> of it
> >>> so...  should we get rid of it in the code rather than turning the config 
> >>> off?
> >>>
> >>> Ira
> >>
> >> That seems reasonable. I recall that the hope was for those IBM Power 9
> >> systems to use _PUBLIC, as they have hardware-based coherent device (GPU)
> >> memory, and so the memory really is visible to the CPU. And the IBM team
> >> was thinking of taking advantage of it. But I haven't seen anything on
> >> that front for a while.
> > 
> > Does anyone know who those people are and can we encourage them to
> > send some patches? :)
> > 
> 
> I asked about this, and it seems that the idea was: DEVICE_PUBLIC was there
> in order to provide an alternative way to do things (such as migrate memory
> to and from a device), in case the combination of existing and near-future
> NUMA APIs was insufficient. This probably came as a follow-up to the early
> 2017-ish conversations about NUMA, in which the linux-mm recommendation was
> "try using HMM mechanisms, and if those are inadequate, then maybe we can
> look at enhancing NUMA so that it has better handling of advanced (GPU-like)
> devices".

Yes that was the original idea. It sounds so much better to use a common
framework rather than awkward special cased cpuless NUMA nodes with
a weird semantic. User of the neither of the two has shown up so I guess
that the envisioned HW just didn't materialized. Or has there been a
completely different approach chosen?

> In the end, however, _PUBLIC was never used, nor does anyone in the local
> (NVIDIA + IBM) kernel vicinity seem to have plans to use it.  So it really
> does seem safe to remove, although of course it's good to start with 
> BROKEN and see if anyone pops up and complains.

Well, I do not really see much of a difference. Preserving an unused
code which doesn't have any user in sight just adds a maintenance burden
whether the code depends on BROKEN or not. We can always revert patches
which remove the code once a real user shows up.
-- 
Michal Hocko
SUSE Labs
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken

[John Hubbard]

On 6/19/19 12:27 PM, Jason Gunthorpe wrote:
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
>> On 6/13/19 5:43 PM, Ira Weiny wrote:
>>> On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
 On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote:
>
>> ...
>>> So I think it is ok.  Frankly I was wondering if we should remove the public
>>> type altogether but conceptually it seems ok.  But I don't see any users of 
>>> it
>>> so...  should we get rid of it in the code rather than turning the config 
>>> off?
>>>
>>> Ira
>>
>> That seems reasonable. I recall that the hope was for those IBM Power 9
>> systems to use _PUBLIC, as they have hardware-based coherent device (GPU)
>> memory, and so the memory really is visible to the CPU. And the IBM team
>> was thinking of taking advantage of it. But I haven't seen anything on
>> that front for a while.
> 
> Does anyone know who those people are and can we encourage them to
> send some patches? :)
> 

I asked about this, and it seems that the idea was: DEVICE_PUBLIC was there
in order to provide an alternative way to do things (such as migrate memory
to and from a device), in case the combination of existing and near-future
NUMA APIs was insufficient. This probably came as a follow-up to the early
2017-ish conversations about NUMA, in which the linux-mm recommendation was
"try using HMM mechanisms, and if those are inadequate, then maybe we can
look at enhancing NUMA so that it has better handling of advanced (GPU-like)
devices".

In the end, however, _PUBLIC was never used, nor does anyone in the local
(NVIDIA + IBM) kernel vicinity seem to have plans to use it.  So it really
does seem safe to remove, although of course it's good to start with 
BROKEN and see if anyone pops up and complains.

thanks,
-- 
John Hubbard
NVIDIA
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 110997] NV50 fan runs at full speed after resume from suspend on kernels 5.1.8, 4.19.49

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110997

--- Comment #2 from Marc Meledandri  ---
Hi! Thanks so much for the quick turnaround on this one. Great that you had a
card on hand to test with.

I can confirm that this patch applied against stable kernel 5.1.15 resolves the
fan speed issue when resuming from suspend.

-- 
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 110997] NV50 fan runs at full speed after resume from suspend on kernels 5.1.8, 4.19.49

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110997

--- Comment #1 from Lyude Paul  ---
Created attachment 144637
  --> https://bugs.freedesktop.org/attachment.cgi?id=144637=edit
Fix for Tesla i2c regression

Hi! Turns out I actually have one of these GPUs in my drawer, so I was able to
reproduce this issue with no problems. Could you verify that the following
patch fixes your issue? If so, I'll add your Tested-by and send it out onto the
nouveau ML

-- 
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 110997] NV50 fan runs at full speed after resume from suspend on kernels 5.1.8, 4.19.49

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110997

Lyude Paul  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

-- 
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 05/22] mm: export alloc_pages_vma

[Dan Williams]

On Tue, Jun 25, 2019 at 12:01 PM Michal Hocko  wrote:
>
> On Tue 25-06-19 11:03:53, Dan Williams wrote:
> > On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko  wrote:
> > >
> > > On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > > > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > > > > I asked for this simply because it was not exported historically. In
> > > > > general I want to establish explicit export-type criteria so the
> > > > > community can spend less time debating when to use EXPORT_SYMBOL_GPL
> > > > > [1].
> > > > >
> > > > > The thought in this instance is that it is not historically exported
> > > > > to modules and it is safer from a maintenance perspective to start
> > > > > with GPL-only for new symbols in case we don't want to maintain that
> > > > > interface long-term for out-of-tree modules.
> > > > >
> > > > > Yes, we always reserve the right to remove / change interfaces
> > > > > regardless of the export type, but history has shown that external
> > > > > pressure to keep an interface stable (contrary to
> > > > > Documentation/process/stable-api-nonsense.rst) tends to be less for
> > > > > GPL-only exports.
> > > >
> > > > Fully agreed.  In the end the decision is with the MM maintainers,
> > > > though, although I'd prefer to keep it as in this series.
> > >
> > > I am sorry but I am not really convinced by the above reasoning wrt. to
> > > the allocator API and it has been a subject of many changes over time. I
> > > do not remember a single case where we would be bending the allocator
> > > API because of external modules and I am pretty sure we will push back
> > > heavily if that was the case in the future.
> >
> > This seems to say that you have no direct experience of dealing with
> > changing symbols that that a prominent out-of-tree module needs? GPU
> > drivers and the core-mm are on a path to increase their cooperation on
> > memory management mechanisms over time, and symbol export changes for
> > out-of-tree GPU drivers have been a significant source of friction in
> > the past.
>
> I have an experience e.g. to rework semantic of some gfp flags and that is
> something that users usualy get wrong and never heard that an out of
> tree code would insist on an old semantic and pushing us to the corner.
>
> > > So in this particular case I would go with consistency and export the
> > > same way we do with other functions. Also we do not want people to
> > > reinvent this API and screw that like we have seen in other cases when
> > > external modules try reimplement core functionality themselves.
> >
> > Consistency is a weak argument when the cost to the upstream community
> > is negligible. If the same functionality was available via another /
> > already exported interface *that* would be an argument to maintain the
> > existing export policy. "Consistency" in and of itself is not a
> > precedent we can use more widely in default export-type decisions.
> >
> > Effectively I'm arguing EXPORT_SYMBOL_GPL by default with a later
> > decision to drop the _GPL. Similar to how we are careful to mark sysfs
> > interfaces in Documentation/ABI/ that we are not fully committed to
> > maintaining over time, or are otherwise so new that there is not yet a
> > good read on whether they can be made permanent.
>
> Documentation/process/stable-api-nonsense.rst

That document has failed to preclude symbol export fights in the past
and there is a reasonable argument to try not to retract functionality
that had been previously exported regardless of that document.

> Really. If you want to play with GPL vs. EXPORT_SYMBOL else this is up
> to you but I do not see any technical argument to make this particular
> interface to the page allocator any different from all others that are
> exported to modules.

I'm failing to find any practical substance to your argument, but in
the end I agree with Chrishoph, it's up to MM maintainers.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 05/22] mm: export alloc_pages_vma

[Michal Hocko]

On Tue 25-06-19 11:03:53, Dan Williams wrote:
> On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko  wrote:
> >
> > On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > > > I asked for this simply because it was not exported historically. In
> > > > general I want to establish explicit export-type criteria so the
> > > > community can spend less time debating when to use EXPORT_SYMBOL_GPL
> > > > [1].
> > > >
> > > > The thought in this instance is that it is not historically exported
> > > > to modules and it is safer from a maintenance perspective to start
> > > > with GPL-only for new symbols in case we don't want to maintain that
> > > > interface long-term for out-of-tree modules.
> > > >
> > > > Yes, we always reserve the right to remove / change interfaces
> > > > regardless of the export type, but history has shown that external
> > > > pressure to keep an interface stable (contrary to
> > > > Documentation/process/stable-api-nonsense.rst) tends to be less for
> > > > GPL-only exports.
> > >
> > > Fully agreed.  In the end the decision is with the MM maintainers,
> > > though, although I'd prefer to keep it as in this series.
> >
> > I am sorry but I am not really convinced by the above reasoning wrt. to
> > the allocator API and it has been a subject of many changes over time. I
> > do not remember a single case where we would be bending the allocator
> > API because of external modules and I am pretty sure we will push back
> > heavily if that was the case in the future.
> 
> This seems to say that you have no direct experience of dealing with
> changing symbols that that a prominent out-of-tree module needs? GPU
> drivers and the core-mm are on a path to increase their cooperation on
> memory management mechanisms over time, and symbol export changes for
> out-of-tree GPU drivers have been a significant source of friction in
> the past.

I have an experience e.g. to rework semantic of some gfp flags and that is
something that users usualy get wrong and never heard that an out of
tree code would insist on an old semantic and pushing us to the corner.

> > So in this particular case I would go with consistency and export the
> > same way we do with other functions. Also we do not want people to
> > reinvent this API and screw that like we have seen in other cases when
> > external modules try reimplement core functionality themselves.
> 
> Consistency is a weak argument when the cost to the upstream community
> is negligible. If the same functionality was available via another /
> already exported interface *that* would be an argument to maintain the
> existing export policy. "Consistency" in and of itself is not a
> precedent we can use more widely in default export-type decisions.
> 
> Effectively I'm arguing EXPORT_SYMBOL_GPL by default with a later
> decision to drop the _GPL. Similar to how we are careful to mark sysfs
> interfaces in Documentation/ABI/ that we are not fully committed to
> maintaining over time, or are otherwise so new that there is not yet a
> good read on whether they can be made permanent.

Documentation/process/stable-api-nonsense.rst
Really. If you want to play with GPL vs. EXPORT_SYMBOL else this is up
to you but I do not see any technical argument to make this particular
interface to the page allocator any different from all others that are
exported to modules.
-- 
Michal Hocko
SUSE Labs
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 05/22] mm: export alloc_pages_vma

[Dan Williams]

On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko  wrote:
>
> On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > > I asked for this simply because it was not exported historically. In
> > > general I want to establish explicit export-type criteria so the
> > > community can spend less time debating when to use EXPORT_SYMBOL_GPL
> > > [1].
> > >
> > > The thought in this instance is that it is not historically exported
> > > to modules and it is safer from a maintenance perspective to start
> > > with GPL-only for new symbols in case we don't want to maintain that
> > > interface long-term for out-of-tree modules.
> > >
> > > Yes, we always reserve the right to remove / change interfaces
> > > regardless of the export type, but history has shown that external
> > > pressure to keep an interface stable (contrary to
> > > Documentation/process/stable-api-nonsense.rst) tends to be less for
> > > GPL-only exports.
> >
> > Fully agreed.  In the end the decision is with the MM maintainers,
> > though, although I'd prefer to keep it as in this series.
>
> I am sorry but I am not really convinced by the above reasoning wrt. to
> the allocator API and it has been a subject of many changes over time. I
> do not remember a single case where we would be bending the allocator
> API because of external modules and I am pretty sure we will push back
> heavily if that was the case in the future.

This seems to say that you have no direct experience of dealing with
changing symbols that that a prominent out-of-tree module needs? GPU
drivers and the core-mm are on a path to increase their cooperation on
memory management mechanisms over time, and symbol export changes for
out-of-tree GPU drivers have been a significant source of friction in
the past.

> So in this particular case I would go with consistency and export the
> same way we do with other functions. Also we do not want people to
> reinvent this API and screw that like we have seen in other cases when
> external modules try reimplement core functionality themselves.

Consistency is a weak argument when the cost to the upstream community
is negligible. If the same functionality was available via another /
already exported interface *that* would be an argument to maintain the
existing export policy. "Consistency" in and of itself is not a
precedent we can use more widely in default export-type decisions.

Effectively I'm arguing EXPORT_SYMBOL_GPL by default with a later
decision to drop the _GPL. Similar to how we are careful to mark sysfs
interfaces in Documentation/ABI/ that we are not fully committed to
maintaining over time, or are otherwise so new that there is not yet a
good read on whether they can be made permanent.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 110996] swaywm (wayland) crashes when turning off monitors through dpms

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110996

Sjon  changed:

   What|Removed |Added

 Attachment #144636|text/plain  |application/gzip
  mime type||

-- 
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 110996] swaywm (wayland) crashes when turning off monitors through dpms

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110996

--- Comment #2 from Sjon  ---
Created attachment 144636
  --> https://bugs.freedesktop.org/attachment.cgi?id=144636=edit
filtered kernel messages with drm.debug=0x14 nouveau.debug=disp=trace

I'm not sure what caused the 'core notifier timeout' messages to start - but
there was at least half an hour between that error and the actual crash. I'll
attach the requested log - it's huge and doesn't show the same hang. The
problem did occur, my monitors turned off and my machine needed a reboot

-- 
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] NOUVEAU_LEGACY_CTX_SUPPORT Fan Speed

[Mar Mel]

Done. Thanks!

Bug 110997 - NV50 fan runs at full speed after resume from suspend on kernels 
5.1.8, 4.19.49
https://bugs.freedesktop.org/show_bug.cgi?id=110997


On Tuesday, June 25, 2019, 11:21:24 AM EDT, Ilia Mirkin  
wrote: 





Hi Mar,

Could you file a bug (bugs.freedesktop.org under xorg -> Driver/nouveau) with a 
summary of this info (i.e. a problem statement, that reverting the commit in 
question fixes it, the lspci output) and additionally, your VBIOS. You can 
obtain this with nouveau loaded by doing

cp /sys/kernel/debug/dri/0/vbios.rom /tmp

This will help centralize all the info.

Thanks,

  -ilia

On Sun, Jun 23, 2019 at 12:34 AM Mar Mel  wrote:
> 
> 
> Sure:
> 
> $ lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT200 [GeForce 
> GTX 260] [10de:05e2] (rev a1)
> 
> 
> 
>  
>  
>  On Saturday, June 22, 2019, 2:19:31 PM EDT, Ilia Mirkin 
> wrote: 
> 
> 
> 
> 
> 
> Mar - can you provide the output of
> 
> lspci -nn -d 10de:
> 
> On Sat, Jun 22, 2019 at 2:17 PM Lyude Paul  wrote:
>> Hi, is this actually an nv50 GPU, or some other model? I can try to take a 
>> closer look at this
>> 
>> On Sun, 2019-06-16 at 10:28 -0400, Ilia Mirkin wrote:
>>> I don't really see anything between v5.0..v5.1 which would account for 
>>> this. Could have been a subtle change to the i2c logic somewhere. The 
>>> fastest way to identify the problem would be to do a bisect on the kernel 
>>> to identify the commit that caused this. There are many guides for this 
>>> online.
>>> 
>>> On Sat, Jun 15, 2019 at 12:17 PM Mar Mel  wrote:
 
 
 Unfortunately, even with this change now reverted in kernel 5.1.10, the 
 fan speed issue persists.
 
 If someone could point me in the direction of a relevant commit(s) I'll 
 happily file a bug report.
 
 
  
  
  On Thursday, June 13, 2019, 11:19:25 AM EDT, Mar Mel 
 wrote: 
 
 
 
 
 
 As of kernel 5.1.9, on resume from suspend, my NV50 fan runs at full 
 speed. 
 
 Not sure if it has to do with this new config option 
 (NOUVEAU_LEGACY_CTX_SUPPORT)?
 
 This issue is not present using kernel 5.0.21.
 
 Years ago I filed a similar issue:
 
 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 
 adt7475 on kernels 3.3.x+
 
 Thanks.
 
 
 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 a...
 
 
 
 
 
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/nouveau
>>> ___Nouveau mailing 
>>> listNouveau@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/nouveau
>> -- Cheers,
>>  Lyude Paul
>> 
> 
> 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 110997] New: NV50 fan runs at full speed after resume from suspend on kernels 5.1.8, 4.19.49

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110997

Bug ID: 110997
   Summary: NV50 fan runs at full speed after resume from suspend
on kernels 5.1.8, 4.19.49
   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: m.meledan...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 144635
  --> https://bugs.freedesktop.org/attachment.cgi?id=144635=edit
vbios.rom

As of stable kernels 5.1.8 and 4.19.49, the GTX 260 fan runs at full speed
after resuming from suspend.

This behavior regressed as of commit 342406e4fbba9a174125fbfe6aeac3d64ef90f76
drm/nouveau/i2c: Disable i2c bus access after ->fini()
https://lkml.org/lkml/2019/6/7/673

Reverting this single commit when building the respective stable kernels fixes
the fan speed issue.

$ lspci -nn -d 10de:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT200 [GeForce GTX
260] [10de:05e2] (rev a1)

Discussion on Nouveau mailing list:
https://lists.freedesktop.org/archives/nouveau/2019-June/032620.html

-- 
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] NOUVEAU_LEGACY_CTX_SUPPORT Fan Speed

[Ilia Mirkin]

Hi Mar,

Could you file a bug (bugs.freedesktop.org under xorg -> Driver/nouveau)
with a summary of this info (i.e. a problem statement, that reverting the
commit in question fixes it, the lspci output) and additionally, your
VBIOS. You can obtain this with nouveau loaded by doing

cp /sys/kernel/debug/dri/0/vbios.rom /tmp

This will help centralize all the info.

Thanks,

  -ilia

On Sun, Jun 23, 2019 at 12:34 AM Mar Mel  wrote:

> Sure:
>
> $ lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT200
> [GeForce GTX 260] [10de:05e2] (rev a1)
>
>
> On Saturday, June 22, 2019, 2:19:31 PM EDT, Ilia Mirkin <
> imir...@alum.mit.edu> wrote:
>
>
> Mar - can you provide the output of
>
> lspci -nn -d 10de:
>
> On Sat, Jun 22, 2019 at 2:17 PM Lyude Paul  wrote:
>
> Hi, is this actually an nv50 GPU, or some other model? I can try to take a
> closer look at this
>
> On Sun, 2019-06-16 at 10:28 -0400, Ilia Mirkin wrote:
>
> I don't really see anything between v5.0..v5.1 which would account for
> this. Could have been a subtle change to the i2c logic somewhere. The
> fastest way to identify the problem would be to do a bisect on the kernel
> to identify the commit that caused this. There are many guides for this
> online.
>
> On Sat, Jun 15, 2019 at 12:17 PM Mar Mel  wrote:
>
> Unfortunately, even with this change now reverted in kernel 5.1.10, the
> fan speed issue persists.
>
> If someone could point me in the direction of a relevant commit(s) I'll
> happily file a bug report.
>
> On Thursday, June 13, 2019, 11:19:25 AM EDT, Mar Mel 
> wrote:
>
>
> As of kernel 5.1.9, on resume from suspend, my NV50 fan runs at full
> speed.
>
> Not sure if it has to do with this new config option (
> NOUVEAU_LEGACY_CTX_SUPPORT)?
>
> This issue is not present using kernel 5.0.21.
>
> Years ago I filed a similar issue:
>
> 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50
> adt7475 on kernels 3.3.x+
> 
>
> Thanks.
>
>
> 60704 – [nouveau, git regression] - I2C PWM fan control broken on nv50 a...
>
> 
>
>
> ___
> 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
>
> --
>
> Cheers,
> Lyude Paul
>
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 110996] swaywm (wayland) crashes when turning off monitors through dpms

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110996

--- Comment #1 from Ilia Mirkin  ---
What was the first group of errors before the first "core notifier timeout"?
That should help inform why there was a gpu hang. Actually, can you reproduce
when booted with

drm.debug=0x14 nouveau.debug=disp=trace

and then reproducing this issue. Only the first few sets of errors are
interesting (really the first, usually), everything after that is just
follow-on fail.

Looks like there are two bugs here, BTW:

1. We hang the EVO engine somehow
2. We have some kind of page map fail with evo_wait (hence the BUG at the end)

-- 
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 110996] New: swaywm (wayland) crashes when turning off monitors through dpms

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110996

Bug ID: 110996
   Summary: swaywm (wayland) crashes when turning off monitors
through dpms
   Product: xorg
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: s...@hortensius.net
QA Contact: xorg-t...@lists.x.org

My wayland setup always crashes when powering my 2 DP monitors down through
dpms. Afterwards I can't get the monitors to power on (through ssh) - only fix
is a reboot.
This is a GTX 1080 Ti btw

nouveau :01:00.0: NVIDIA GP102 (132000a1)
nouveau :01:00.0: bios: version 86.02.39.00.3d
nouveau :01:00.0: fb: 11264 MiB GDDR5X
[TTM] Zone  kernel: Available graphics memory: 16407230 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
nouveau :01:00.0: DRM: VRAM: 11264 MiB
nouveau :01:00.0: DRM: GART: 536870912 MiB
nouveau :01:00.0: DRM: BIT table 'A' not found
nouveau :01:00.0: DRM: BIT table 'L' not found
nouveau :01:00.0: DRM: TMDS table version 2.0
nouveau :01:00.0: DRM: DCB version 4.1
nouveau :01:00.0: DRM: DCB outp 00: 01000f42 00020030
nouveau :01:00.0: DRM: DCB outp 01: 04811f96 04600020
nouveau :01:00.0: DRM: DCB outp 02: 04011f92 00020020
nouveau :01:00.0: DRM: DCB outp 03: 04822f86 04600010
nouveau :01:00.0: DRM: DCB outp 04: 04022f82 00020010
nouveau :01:00.0: DRM: DCB outp 06: 02033f62 00020020
nouveau :01:00.0: DRM: DCB outp 07: 02844f76 04600010
nouveau :01:00.0: DRM: DCB outp 08: 02044f72 00020010
nouveau :01:00.0: DRM: DCB conn 00: 1031
nouveau :01:00.0: DRM: DCB conn 01: 02000146
nouveau :01:00.0: DRM: DCB conn 02: 01000246
nouveau :01:00.0: DRM: DCB conn 03: 00020361
nouveau :01:00.0: DRM: DCB conn 04: 00010446
nouveau :01:00.0: DRM: MM: using COPY for buffer copies
nouveau :01:00.0: fb0: nouveaufb frame buffer device
[drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 1

...

nouveau :01:00.0: DRM: core notifier timeout
nouveau :01:00.0: bus: MMIO read of  FAULT at 616e18 [ IBUS ]
nouveau :01:00.0: bus: MMIO read of  FAULT at 616d48 [ IBUS ]
nouveau :01:00.0: DRM: core notifier timeout
nouveau :01:00.0: DRM: base-1: timeout
nouveau :01:00.0: DRM: base-1: timeout
nouveau :01:00.0: bus: MMIO read of  FAULT at 616618 [ IBUS ]
nouveau :01:00.0: bus: MMIO read of  FAULT at 616618 [ IBUS ]
nouveau :01:00.0: DRM: core notifier timeout
nouveau :01:00.0: DRM: base-0: timeout
nouveau :01:00.0: DRM: base-0: timeout
nouveau :01:00.0: DRM: base-1: timeout
nouveau :01:00.0: DRM: base-0: timeout
nouveau :01:00.0: DRM: base-1: timeout
nouveau :01:00.0: DRM: base-0: timeout

..repeated for ~ an hour, unknown cause...

BUG: unable to handle kernel paging request at aa2b3e7f6000
#PF error: [WRITE]
PGD 80ed39067 P4D 80ed39067 PUD 0 
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 7 PID: 728 Comm: sway Tainted: G   OE 5.1.14-arch1-1-ARCH #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extreme4, BIOS
P2.90 07/11/2013
RIP: 0010:evo_wait+0x5a/0x130 [nouveau]
Code: 00 00 c1 eb 02 4c 89 f7 e8 b3 64 c2 d5 89 da 44 01 e3 48 8d 04 95 00 00
00 00 81 fb f7 03 00 00 0f 86 86 00 00 00 48 8b 45 70  04 90 00 00 00 20 f6
45 58 01 74 09 48 8b 7d 28 e8 50 e2 ff ff
RSP: 0018:aa2a838cbae0 EFLAGS: 00010212
RAX: aa2a83a05000 RBX: 2eb7c402 RCX: 8ecc7dc1b000
RDX: 2eb7c400 RSI: 0002 RDI: 8ecc7a84ec10
RBP: 8ecc7a84eb48 R08:  R09: 0004
R10: 8ecc8ec03980 R11: 8ecc8933f600 R12: 0002
R13: 8ecc893be350 R14: 8ecc7a84ec10 R15: 8ecc893be000
FS:  7fe98e9c53c0() GS:8ecc8f1c() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: aa2b3e7f6000 CR3: 0007e4196004 CR4: 000606e0
Call Trace:
 base507c_update+0x20/0x70 [nouveau]
 nv50_disp_atomic_commit_wndw.isra.0+0x5e/0x80 [nouveau]
 nv50_disp_atomic_commit_tail+0x4bb/0x6c0 [nouveau]
 nv50_disp_atomic_commit+0x16d/0x1f0 [nouveau]
 drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]
 drm_mode_obj_set_property_ioctl+0x159/0x2b0 [drm]
 ? drm_connector_set_obj_prop+0x90/0x90 [drm]
 drm_connector_property_set_ioctl+0x39/0x60 [drm]
 drm_ioctl_kernel+0xb0/0xf0 [drm]
 drm_ioctl+0x233/0x400 [drm]
 ? drm_connector_set_obj_prop+0x90/0x90 [drm]
 ? unix_stream_recvmsg+0x53/0x70
 ? unix_state_double_unlock+0x40/0x40
 nouveau_drm_ioctl+0x63/0xb0 [nouveau]
 do_vfs_ioctl+0x40c/0x670
 ksys_ioctl+0x5e/0x90
 __x64_sys_ioctl+0x16/0x20
 do_syscall_64+0x5b/0x190
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 

Re: [PATCH 05/22] mm: export alloc_pages_vma

[Michal Hocko]

On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > I asked for this simply because it was not exported historically. In
> > general I want to establish explicit export-type criteria so the
> > community can spend less time debating when to use EXPORT_SYMBOL_GPL
> > [1].
> > 
> > The thought in this instance is that it is not historically exported
> > to modules and it is safer from a maintenance perspective to start
> > with GPL-only for new symbols in case we don't want to maintain that
> > interface long-term for out-of-tree modules.
> > 
> > Yes, we always reserve the right to remove / change interfaces
> > regardless of the export type, but history has shown that external
> > pressure to keep an interface stable (contrary to
> > Documentation/process/stable-api-nonsense.rst) tends to be less for
> > GPL-only exports.
> 
> Fully agreed.  In the end the decision is with the MM maintainers,
> though, although I'd prefer to keep it as in this series.

I am sorry but I am not really convinced by the above reasoning wrt. to
the allocator API and it has been a subject of many changes over time. I
do not remember a single case where we would be bending the allocator
API because of external modules and I am pretty sure we will push back
heavily if that was the case in the future.

So in this particular case I would go with consistency and export the
same way we do with other functions. Also we do not want people to
reinvent this API and screw that like we have seen in other cases when
external modules try reimplement core functionality themselves.

Thanks!
-- 
Michal Hocko
SUSE Labs

[Nouveau] [Bug 110993] GP107GLM [Quadro P1000 Mobile]: frequent failure to initialize displays on Thunderbolt dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110993

--- Comment #2 from Markus Wanner  ---
Created attachment 144634
  --> https://bugs.freedesktop.org/attachment.cgi?id=144634=edit
test run 2 - annotated kern.log

For the second run, I re-enabled the runpm_fixes and tried to perform the exact
same steps as during run 1 to check if that makes a difference.  Same starting
conditions otherwise: dock already attached, but no monitors plugged into the
dock or the laptop.

Jun 21 10:49:13 calaton kernel: [  199.796511]: login
Jun 21 10:49:47 calaton kernel: [  234.186963]: plug HDMI into laptop directly,
works
Jun 21 10:50:00 calaton kernel: [  246.472930]: pull HDMI cable from laptop
Jun 21 10:51:34 calaton kernel: [  341.384332]: plug HDMI cable into dock - not
recognized, display lights up, but goes back into standby
Jun 21 10:52:20 calaton kernel: [  386.757948]: plug DP into dock - not
recognized, display lights up, but goes back into standby
Jun 21 10:52:57 calaton kernel: [  424.339095]: pull HDMI cable out of dock -
no change, display lights up, but goes back into standby
Jun 21 10:53:36 calaton kernel: [  462.525517]: plug HDMI cable into laptop -
recognized
Jun 21 10:53:51 calaton kernel: [  477.800605]: unplug the Dock - no change,
Levovo on HDMI and internal display remain active.
Jun 21 10:54:51 calaton kernel: [  537.523191]: re-plug the Dock - Dell not
recognized
Jun 21 10:55:16 calaton kernel: [  562.760425]: pull the HDMI cable
Jun 21 10:55:57 calaton kernel: [  604.330288]: plug HDMI cable into dock -
neither Dell nor Lenovo recognized
Jun 21 10:56:40 calaton kernel: [  647.138495]: pull the dock
Jun 21 10:56:55 calaton kernel: [  662.366295]: plug the Dock again
Jun 21 10:58:26 calaton kernel: [  752.986238]: pull the dock
Jun 21 10:58:41 calaton kernel: [  768.201244]: plug the Dock again
Jun 21 10:59:53 calaton kernel: [  840.353587]: pull the dock, pull the HDMI
from the dock
Jun 21 11:00:08 calaton kernel: [  855.417667]: plug the dock (with only the DP
display attached)
Jun 21 11:01:48 calaton kernel: [  955.154927]: pull the dock
Jun 21 11:02:03 calaton kernel: [  970.227148]: re-plug the dock (with only the
HDMI display attached)
Jun 21 11:03:14 calaton kernel: [ 1040.747229]: pull the dock, pull the HDMI
from the dock, re-attach DP to the dock
Jun 21 11:03:29 calaton kernel: [ 1055.830960]: attach HDMI to laptop -
recognized properly

/sys/class/drm/card0-eDP-1/status:connected
/sys/class/drm/card1-DP-1/status:disconnected
/sys/class/drm/card1-DP-2/status:disconnected
/sys/class/drm/card1-HDMI-A-1/status:connected
/sys/class/drm/card1-eDP-2/status:disconnected

Jun 21 11:05:00 calaton kernel: [ 1146.466630]: re-plug the dock (with HDMI
already attached, DP on dock)
Jun 21 11:06:28 calaton kernel: [ 1234.650085]: unplug the DP from the dock
Jun 21 11:07:00 calaton kernel: [ 1266.460845]: re-plug the DP to the dock
Jun 21 11:07:30 calaton kernel: [ 1297.127079]: unplug the dock from the laptop

Again, the attached log is annotated with actions and observations.

-- 
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 18/22] mm: mark DEVICE_PUBLIC as broken

[Christoph Hellwig]

On Tue, Jun 25, 2019 at 11:44:28AM +, Jason Gunthorpe wrote:
> Which tree and what does the resolution look like?

Looks like in -mm.  The current commit in linux-next is:

commit 0d23b042f26955fb35721817beb98ba7f1d9ed9f
Author: Robin Murphy 
Date:   Fri Jun 14 10:42:14 2019 +1000

mm: clean up is_device_*_page() definitions


> Also, I don't want to be making the decision if we should keep/remove
> DEVICE_PUBLIC, so let's get an Ack from Andrew/etc?
> 
> My main reluctance is that I know there is HW out there that can do
> coherent, and I want to believe they are coming with patches, just
> too slowly. But I'd also rather those people defend themselves :P

Lets keep everything as-is for now.  I'm pretty certain nothing
will show up, but letting this linger another release or two
shouldn't be much of a problem.  And if we urgently feel like removing
it we can do it after -rc1.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 110993] GP107GLM [Quadro P1000 Mobile]: frequent failure to initialize displays on Thunderbolt dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110993

--- Comment #1 from Markus Wanner  ---
Created attachment 144633
  --> https://bugs.freedesktop.org/attachment.cgi?id=144633=edit
test run 1 - annotated kern.log

Starting condition: dock already attached, but no monitors plugged into the
dock or the laptop.  Using nouveau without runpm_fixes.

The attached log is collected from /var/log/kern.log via ssh, so as to preserve
most of the data even in case of a crash.  I annotated it with actions
performed and observations made at the following points in time:

Jun 21 10:32:37 calaton kernel: [   71.352739]: login
Jun 21 10:33:30 calaton kernel: [  124.428250]: plug in HDMI cable into laptop
directly

Observation after a couple of seconds: works, proper image shown on the Lenovo
display.  The grep command yields:

/sys/class/drm/card0-eDP-1/status:connected
/sys/class/drm/card1-DP-1/status:disconnected
/sys/class/drm/card1-DP-2/status:disconnected
/sys/class/drm/card1-HDMI-A-1/status:connected
/sys/class/drm/card1-eDP-2/status:disconnected

Jun 21 10:34:59 calaton kernel: [  213.433544]: pull out HDMI cable - all fine
Jun 21 10:35:45 calaton kernel: [  259.672821]: plug HDMI cable into dock - not
recognized, display lights up, but goes back into standby
Jun 21 10:36:57 calaton kernel: [  331.284818]: plug Dell (DP) into dock - not
recognized, display lights up, but goes back into standby
Jun 21 10:37:22 calaton kernel: [  356.470787]: pull HDMI cable out of dock -
no change, display lights up, but goes back into standby
Jun 21 10:38:42 calaton kernel: [  436.169622]: plug HDMI cable into laptop -
recognized
Jun 21 10:39:00 calaton kernel: [  453.731368]: unplug the Dock - no change,
Levovo on HDMI and internal display remain active.
Jun 21 10:40:10 calaton kernel: [  524.314909]: re-plug the Dock - Dell not
recognized
Jun 21 10:41:10 calaton kernel: [  584.005627]: pull HDMI cable from the laptop
Jun 21 10:41:31 calaton kernel: [  604.833610]: plug HDMI cable into dock -
neither Dell nor Lenovo recognized
Jun 21 10:42:32 calaton kernel: [  665.790854]: pull the Dock
Jun 21 10:42:47 calaton kernel: [  681.020228]: plug the Dock again
Jun 21 10:44:05 calaton kernel: [  759.618299]: crash, laptop fully
unresponsive to keyboard, mouse or network inputs

-- 
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: [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken

[Jason Gunthorpe]

On Tue, Jun 25, 2019 at 09:29:15AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 20, 2019 at 09:26:48PM +0200, Michal Hocko wrote:
> > On Thu 13-06-19 11:43:21, Christoph Hellwig wrote:
> > > The code hasn't been used since it was added to the tree, and doesn't
> > > appear to actually be usable.  Mark it as BROKEN until either a user
> > > comes along or we finally give up on it.
> > 
> > I would go even further and simply remove all the DEVICE_PUBLIC code.
> 
> I looked into that as I now got the feedback twice.  It would
> create a conflict with another tree cleaning things up around the
> is_device_private defintion, but otherwise I'd be glad to just remove
> it.
> 
> Jason, as this goes through your tree, do you mind the additional
> conflict?

Which tree and what does the resolution look like?

Also, I don't want to be making the decision if we should keep/remove
DEVICE_PUBLIC, so let's get an Ack from Andrew/etc?

My main reluctance is that I know there is HW out there that can do
coherent, and I want to believe they are coming with patches, just
too slowly. But I'd also rather those people defend themselves :P

Thanks,
Jason

[Nouveau] [Bug 110993] New: GP107GLM [Quadro P1000 Mobile]: frequent failure to initialize displays on Thunderbolt dock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110993

Bug ID: 110993
   Summary: GP107GLM [Quadro P1000 Mobile]: frequent failure to
initialize displays on Thunderbolt dock
   Product: xorg
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: mar...@bluegap.ch
QA Contact: xorg-t...@lists.x.org

When connecting to the Thunderbolt 3 Dock, the monitors attached to it more
often remain black rather than showing a proper image.  Sometimes the Laptop
freezes entirely, other times just one of the two comes up, most of the time,
they remain black and eventually enter standby.

I'm using a Lenovo P1 featuring a Quadro P1000 Mobile GPU.  An integrated GPU
is wired to the internal display as eDP-1.  The Nvidia card exposes an HDMI
port on the laptop.  Plugging a monitor there directly usually works.  Vie the
docking station, I get another 3 ports controlled by the Nvidia GPU.  These are
either HDMI or DisplayPort.  I have two monitors for experimentation, a Dell
one and a Lenovo one.

I'm running a Linux 5.2-rc5 kernel and the nouveau driver compiled from a
current checkout of the git repo of Ben Skeggs
(https://github.com/skeggsb/nouveau/tree/f91e915b6a12c281aed4401a869881f293b72d4e).
 Most of the time, I'm running with the runpm_fixes of Karol Herbst (that is
the last five revisions from
https://github.com/karolherbst/nouveau/tree/runpm_fixes).

The output of `grep . /sys/class/drm/card*-*/status` after a start w/o the dock
or any display attached is:

/sys/class/drm/card0-eDP-1/status:connected
/sys/class/drm/card1-DP-1/status:disconnected
/sys/class/drm/card1-DP-2/status:disconnected
/sys/class/drm/card1-HDMI-A-1/status:connected
/sys/class/drm/card1-eDP-2/status:disconnected

I'll provide further details of what I did together with the corresponding
kernel logs with tracing enabled in follow-up comments and attachments.

-- 
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 110988] New: [NV49] Graphical issues on KDE desktop with GeForce 7950 GX2

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110988

Bug ID: 110988
   Summary: [NV49] Graphical issues on KDE desktop with GeForce
7950 GX2
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: praiogr...@gmail.com
QA Contact: nouveau@lists.freedesktop.org

SUMMARY
Since I did a new installation of openSUSE tumbleweed on 29th March 2019, I
have severe graphical issues on my desktop:
https://abload.de/image.php?img=desktop3w4ks2.png
https://abload.de/image.php?img=desktop4myjjn.png
https://abload.de/image.php?img=desktop5xwk6d.png
https://abload.de/image.php?img=desktop6k8jb2.png

Before this new installation, everything was fine. Unfortunately, I don't know
which version the old driver had. I didn't expect such a problem so I didn't
pay attention for it. The old system was installed round about one year ago.
There the driver was locked and never updated.

Problems now appear as soon as the desktop is fully loaded.
Games like 0 A.D. or Supertux seem not to be affected or only at a lesser
extent.

STEPS TO REPRODUCE
1. installation
2. booting system

OBSERVED RESULT
- KDE-Menu is semi-transparent (see second picture:
https://abload.de/image.php?img=desktop4myjjn.png )
- Icon titles are overlapped with colored blocks (see third picture in the
upper line: https://abload.de/image.php?img=desktop5xwk6d.png )
- Program windows are overlapped with colored fields (see fourth picture:
https://abload.de/image.php?img=desktop6k8jb2.png )

EXPECTED RESULT
- Clear desktop presentation

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kernel 5.1.7-1, openSUSE tumbleweed 64-bit (current version)
(available in About System)
KDE Plasma Version: 5.16.0
KDE Frameworks Version: 5.58.0
Qt Version: 5.12.3

MY HARDWARE/DRIVER:
Motherboard: Asus P5N32-E SLI Plus
CPU: Intel Core2 Duo E8200 @ 2,66GHz
RAM: 4 GiB
Graphics card: [NV49] Gigabyte Nvidia GeForce 7950 GX2 with 2x 512 GDDR3
Graphics Driver: nouveau 
Graphics Renderer: NV49
OpenGL Version: 2.1 Mesa 19.0.5

ADDITIONAL INFORMATION
There are no problems when booting Windows XP. So I exclude defective hardware.

-- 
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

Re: [Nouveau] [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken

[Christoph Hellwig]

On Thu, Jun 20, 2019 at 09:26:48PM +0200, Michal Hocko wrote:
> On Thu 13-06-19 11:43:21, Christoph Hellwig wrote:
> > The code hasn't been used since it was added to the tree, and doesn't
> > appear to actually be usable.  Mark it as BROKEN until either a user
> > comes along or we finally give up on it.
> 
> I would go even further and simply remove all the DEVICE_PUBLIC code.

I looked into that as I now got the feedback twice.  It would
create a conflict with another tree cleaning things up around the
is_device_private defintion, but otherwise I'd be glad to just remove
it.

Jason, as this goes through your tree, do you mind the additional
conflict?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 05/22] mm: export alloc_pages_vma

[Christoph Hellwig]

On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> I asked for this simply because it was not exported historically. In
> general I want to establish explicit export-type criteria so the
> community can spend less time debating when to use EXPORT_SYMBOL_GPL
> [1].
> 
> The thought in this instance is that it is not historically exported
> to modules and it is safer from a maintenance perspective to start
> with GPL-only for new symbols in case we don't want to maintain that
> interface long-term for out-of-tree modules.
> 
> Yes, we always reserve the right to remove / change interfaces
> regardless of the export type, but history has shown that external
> pressure to keep an interface stable (contrary to
> Documentation/process/stable-api-nonsense.rst) tends to be less for
> GPL-only exports.

Fully agreed.  In the end the decision is with the MM maintainers,
though, although I'd prefer to keep it as in this series.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau