search for: galbraith

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > >> > t...

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: >  All DRM did was to slip a > WARN_ON_ONCE() that nouveau triggers into a kernel module where such > things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c into a WARN_ONCE(), and all is peachy, you get the...

...we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could convert to WARN_ONCE? Reviewed-By: Karol Herbst <karolherbst at gmail.com> On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > On 7/14/17 3:41 PM, Mike Galbraith wrote: >> >> On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: >>> >>> All DRM did was to slip a >>> WARN_ON_ONCE() that nouveau triggers into a kernel module where such >>> things no longer warn, they blow the box out of the water. >>...

On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > Urgh, is for some mysterious reason the __bug_table section of modules > > ending up in RO memory? > > > > I forever get lost in that link magic :/ > > +1 > > drm.ko >  20 __bug_table...

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > >> > t...

On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > > too much trouble, a bisect would be pretty useful. > > Bisection seemingly went fine, but the result is odd. > > e...

...l.com> wrote: > > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > >> > >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: > >>> > >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: > >>>> > >>>> On 12/18/17 7:06 PM, Mike Galbraith wrote: > >>>>> > >>>>> Greetings, > >>>>> > >>>>> Kernel bound workloads seem to trigger the below for whatever reason. > >>>>> I only see this when beating up NFS. There was a kworker wakeup > >>...

On 7/12/17 7:19 PM, Mike Galbraith wrote: > On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: >> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: >>> On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: >>>> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: &gt...

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > too much trouble, a bisect would be pretty useful. Bisection seemingly went fine, but the result is odd. e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit -Mike

On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: > On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > > > And if you revert that patch, does everything work again? > > Yes. Great, Dave, care to revert this in 4.18 so I can queue up that revert in older kernels as well? thanks, greg k-h

On Sun, Jun 17, 2018 at 12:38:06PM +0200, Mike Galbraith wrote: > On Sun, 2018-06-17 at 11:36 +0200, Greg KH wrote: > > > > And if you revert that patch, does everything work again? > > Yes. Great, Dave, care to revert this in 4.18 so I can queue up that revert in older kernels as well? thanks, greg k-h

Is it possible to configure rsync in server mode, to gain access to root protected files, without the user having to log in as root through ssh? I'd prefer to login as a regular user through ssh and access an rysnc server on the host that's running as root. As far as I can tell, however, that's not possible...am I wrong?

On 2017-12-18 08:01 PM, Tobias Klausmann wrote: > On 12/18/17 7:06 PM, Mike Galbraith wrote: >> Greetings, >> >> Kernel bound workloads seem to trigger the below for whatever reason. >>   I only see this when beating up NFS.  There was a kworker wakeup >> latency issue, but with a bandaid applied to fix that up, I can still >> trigger this. >...

On Thu, 2018-05-10 at 12:28 +0200, Mike Galbraith wrote: > On Thu, 2018-05-10 at 11:10 +0200, Mike Galbraith wrote: > > Greetings, > > > > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The > > below is from master.today. > > > > [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (...

Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. [ 1313.811031] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 1313.811035] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > On 2017-12-19 11:37 AM, Michel Dänzer wrote: >> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: >>> On 12/18/17 7:06 PM, Mike Galbraith wrote: >>>> Greetings, >>>> >>>> Kernel bound workloads seem to trigger the below for whatever reason. >>>>   I only see this when beating up NFS.  There was a kworker wakeup >>>> latency issue, but with a bandaid applied to fix that up,...

Greetings, When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The below is from master.today. [12594.640959] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [12594.693000] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [12594.713787] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [12594.743413] nouveau 0000:01:00.0: swiotlb buffer

...gt;> Cc: linux-nvme at lists.infradead.org >> Link: http://lkml.kernel.org/r/20170626102058.10200-3-hch at lst.de >> Signed-off-by: Thomas Gleixner <tglx at linutronix.de> >> Cc: Oleksandr Natalenko <oleksandr at natalenko.name> >> Cc: Mike Galbraith <efault at gmx.de> >> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > > I wonder if we're simply not getting the masks updated correctly. I'll > take a look. Can't make it trigger here. We do init for each present CPU, which means tha...

...gt;> Cc: linux-nvme at lists.infradead.org >> Link: http://lkml.kernel.org/r/20170626102058.10200-3-hch at lst.de >> Signed-off-by: Thomas Gleixner <tglx at linutronix.de> >> Cc: Oleksandr Natalenko <oleksandr at natalenko.name> >> Cc: Mike Galbraith <efault at gmx.de> >> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > > I wonder if we're simply not getting the masks updated correctly. I'll > take a look. Can't make it trigger here. We do init for each present CPU, which means tha...

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: >> > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not >> > too much trouble, a bisect...