lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 28 Feb 2009 11:57:32 -0800
From:	Eric Anholt <eric@...olt.net>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>,
	Sitsofe Wheeler <sitsofe@...oo.com>, airlied@...ux.ie,
	keithp@...thp.com, dri-devel@...ts.sourceforge.net,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: i915 X lockup

On Sat, 2009-02-28 at 19:24 +0100, Bruno Prémont wrote:
> On Sat, 28 February 2009 Eric Anholt <eric@...olt.net> wrote:
> > On Sat, 2009-02-28 at 00:47 -0800, Andrew Morton wrote:
> > > The kernel deadlocked on struct_mutex, did it not?  That's a kernel
> > > bug regardless of what userspace you're running.
> > > 
> > > Do we know why this happened?
> > 
> > Userland went stomping all over the device state that the kernel
> > thinks it controls since you went and turned on the KMS option
> > asserting "I'm not going to run old userland", so the GPU got hung,
> > and further software using the GPU hung, and then somebody waiting
> > for someone else finishing using the GPU (struct_mutex) got hung.
> > 
> > The only proposal to prevent it is to use the "don't let userland map
> > my PCI device any more" support we now have available to us, which
> > would make X fail early on.  The unfortunate side-effect of that is
> > that we lose the ability to run incredibly useful userland debug
> > tools that do read-only access to registers.  We're moving bits of
> > those into debugfs for 2.6.30, but it's work that's not done even for
> > the tools we have today.
> 
> I also saw/see Xorg lockup...
> 
> I'm running xf86-video-intel-2.6.1 (2.6.2 released only very recently)
> and kernel with KMS disabled (KMS not capable of getting framebuffer
> properly configured it seems, at least display remains black)
> 
> For me it's a deadlock between intel driver dispatching GEM requests
> and events (see log below).
> For me each time it happends was while interacting with a webbrowser,
> though it does not happend very often.
> 
> Connecting to the notebook via ssh I can kill -KILL Xorg (kill -TERM
> does not work).
> When doing this GPU gets at least confused though in order to get
> vesafb back working it's sufficient to start Xorg with vesa driver
> (running with intel driver before rebooting leads to locked X and
> need to retry the killing)

You have a completely different problem.

Your GPU is hung in doing something that should work.  8xx support is
notoriously bad right now, and we haven't managed to get the developer
time on fixing it that we need, though I keep pushing for it.  My only
855 has a dead disk, or I probably would have poked at it by now.

-- 
Eric Anholt
eric@...olt.net                         eric.anholt@...el.com



Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ