Re: [Regression] 83f45fc turns machine's screen off

On Mon, Dec 15, 2014 at 8:31 AM, Daniel Vetter wrote: [---snip---] > Sorry for the delay. Absolutely no difference in the relevant parts of the > log. There could be the chance that something is hidden somewhere, so can > please grab a new set of logs but this time with drm.debug=0xe? Thanks fo

Re: [Regression] 83f45fc turns machine's screen off

Hi Daniel, > On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter > wrote: >> Adding relevant mailing lists. >> >> >> On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty wrote: >>> Hi, >>> >>> The following commit permanently turns my

Re: [Regression] 83f45fc turns machine's screen off

Hi Daniel, Thanks for your reply and very sorry for the belated reply, some gmail filtering issues... On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter wrote: > Adding relevant mailing lists. > > > On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty wrote: >> Hi, >>

[Regression] 83f45fc turns machine's screen off

Hi, The following commit permanently turns my screen off when x server is started (i3 330M Ironlake): [83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb reference for the idr Reverting this commit fixed the issue. Thanks in advance. Emmanuel -- To unsubscribe from this list: s

Re: commit 94fc5d9: chromium-sandbox core dumped

Hi Linus, On Tue, Aug 20, 2013 at 1:26 AM, Linus Torvalds wrote: > On Mon, Aug 19, 2013 at 1:25 PM, Linus Torvalds > wrote: >> >> I suspect that last "return 0" at the end should be "return 1". Does >> that fix things for you? Untested. > > Ok. Confirmed. I reproduced the bug that Richard Genoud

commit 94fc5d9: chromium-sandbox core dumped

Hi, The following commit breaks chromium on my machine: commit 94fc5d9de5bd757ad46f0d94bc4ebf617c4487f6 Author: Richard Genoud Date: Mon Aug 19 18:30:31 2013 +0200 proc: return on proc_readdir error Chromium breaks with: [269:269:0819/203839:FATAL:zygote_host_impl_linux.cc(195)] Check f

Re: [PATCH -next] ipc: make refcounter atomic (was Re: linux-next: Tree for Apr 23 [ Call-Traces: lib/debugobjects.c | kernel/rcupdate.c | kernel/rcutree.c ])

_getref_and_unlock() and sem_getref() trigger >>> a warning but proceed >>> to freeing up any held locks. >>> >>> Signed-off-by: Davidlohr Bueso >>> Suggested-by: Linus Torvalds >>> CC: Rik van Riel >>> CC: Paul McKenney >>&g

Re: ipc,sem: sysv semaphore scalability

Hi Davidlohr, On Sun, Mar 31, 2013 at 12:01 PM, Davidlohr Bueso wrote: > Specially dropping the rcu read lock before the continue statement > (sorry for not mentioning this in the last email). I was missing this indeed, thanks. Still the same issues however... I'll do some more testing on the sa

Re: ipc,sem: sysv semaphore scalability

Hi Linus, On Sun, Mar 31, 2013 at 12:22 AM, Linus Torvalds wrote: > On Fri, Mar 29, 2013 at 10:57 PM, Emmanuel Benisty > wrote: >> On Sat, Mar 30, 2013 at 12:10 PM, Linus Torvalds >>> >>> This came from the gcc build? >> >> yes, very early in the bu

Re: ipc,sem: sysv semaphore scalability

On Sat, Mar 30, 2013 at 12:10 PM, Linus Torvalds wrote: >> Another shot in >> the dark, I had this weird message when trying to build gcc: >> semop(2): encountered an error: Identifier removed > > This came from the gcc build? yes, very early in the build process, IIRC this line was repeated a fe

Re: ipc,sem: sysv semaphore scalability

On Sat, Mar 30, 2013 at 10:46 AM, Linus Torvalds wrote: > On Fri, Mar 29, 2013 at 8:02 PM, Emmanuel Benisty wrote: >> >> Then I start building a random package and the problems start. They >> may also happen without compiling but this seems to trigger the bug >> quite

Re: ipc,sem: sysv semaphore scalability

Hi Davidlohr, On Sat, Mar 30, 2013 at 9:08 AM, Davidlohr Bueso wrote: > Not sure which one liner you refer to, but, if you haven't already done > so, please try with these fixes (queued in linux-next): > > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=a9cead0347283f3e

Re: ipc,sem: sysv semaphore scalability

Hi Linus, On Sat, Mar 30, 2013 at 6:16 AM, Linus Torvalds wrote: > Emmanuel, can you try the attached patch? I think it applies cleanly > on top of the scalability series too without any changes, but I didn't > check if the patches perhaps changed some of the naming or something. I had to slight

Re: ipc,sem: sysv semaphore scalability

On Mon, Mar 25, 2013 at 10:53 PM, Rik van Riel wrote: > On 03/25/2013 11:20 AM, Emmanuel Benisty wrote: >> >> On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel wrote: >>>>> >>>>> With the first four patches only, I got some X server freeze (just >>

Re: ipc,sem: sysv semaphore scalability

On Mon, Mar 25, 2013 at 9:03 PM, Rik van Riel wrote: >>> With the first four patches only, I got some X server freeze (just >>> tried once). >> >> >> Could you try booting with panic=1 so the kernel panics on the first >> oops? > > > Sorry that should be "oops=panic" > > >> Maybe that way (if we a

Re: ipc,sem: sysv semaphore scalability

On Mon, Mar 25, 2013 at 9:01 PM, Rik van Riel wrote: > On 03/25/2013 09:47 AM, Emmanuel Benisty wrote: >> >> On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds >> wrote: >>> >>> And you never see this problem without Rik's patches? >> >> &g

Re: ipc,sem: sysv semaphore scalability

On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds wrote: > And you never see this problem without Rik's patches? No, never. > Could you bisect > *which* patch it starts with? Are the first four ones ok (the moving > of the locking around, but without the fine-grained ones), for > example? With t

Re: ipc,sem: sysv semaphore scalability

On Sun, Mar 24, 2013 at 2:45 AM, Linus Torvalds wrote: > On Fri, Mar 22, 2013 at 8:19 PM, Emmanuel Benisty wrote: >> >> I could reproduce it but could you please let me know what would be >> the right tools I should use to catch the original oops? >> This is what I

Re: ipc,sem: sysv semaphore scalability

Hi Linus, On Fri, Mar 22, 2013 at 10:37 PM, Linus Torvalds wrote: > On Fri, Mar 22, 2013 at 4:04 AM, Emmanuel Benisty wrote: >> >> I was trying your patchset and my machine died while building a >> package. I could reproduce the bug the (only) two times I tried. >

Re: ipc,sem: sysv semaphore scalability

Hi Rik, On Thu, Mar 21, 2013 at 2:55 AM, Rik van Riel wrote: > This series makes the sysv semaphore code more scalable, > by reducing the time the semaphore lock is held, and making > the locking more scalable for semaphore arrays with multiple > semaphores. I was trying your patchset and my mac

Re: [RFC PATCH 0/2] ipc: do not hold ipc lock more than necessary

On Sat, Mar 2, 2013 at 2:08 PM, Michel Lespinasse wrote: > On Sat, Mar 2, 2013 at 12:43 PM, Emmanuel Benisty wrote: >> Hi, >> >> On Sat, Mar 2, 2013 at 7:16 AM, Davidlohr Bueso >> wrote: >>> The following set of not-thoroughly-tested patches are based on t

Re: [RFC PATCH 0/2] ipc: do not hold ipc lock more than necessary

Hi, On Sat, Mar 2, 2013 at 7:16 AM, Davidlohr Bueso wrote: > The following set of not-thoroughly-tested patches are based on the > discussion of holding the ipc lock unnecessarily, such as for permissions > and security checks: > > https://lkml.org/lkml/2013/2/28/540 > > Patch 0/1: Introduces new

Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote: > On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote: >> >> Al, that -><- close to volunteering for maintaining that FPOS kernel-side... >> > > This would be fantastic. And that would solve this very much worrying issue [1], quoting: "(Yes,