drm2, i915kms cause instant lock-up

Steve Kargl sgk at troutmask.apl.washington.edu
Wed Feb 22 07:03:01 UTC 2017


On Tue, Feb 21, 2017 at 10:29:43PM -0800, Steve Kargl wrote:
> On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote:
> > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> > > Well, I found the guilty commit.  r313934 breaks loading
> > > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
> > > details below.
> > > 
> > > I'll also note that starting at r313902 or so, after 
> > > loading i915kms.ko console output on vt is slooooooow.
> > > A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user,
> > > and 1.08 sys, but the drawing on screen takes more than
> > > 30 seconds.  One can painfully watch each line of output
> > > be rastered across the screen.
> > > 
> > > Kib you can read the details below.  If you need more info,
> > > ping me.  I did notice that i686_mem.c used constants of the
> > > form 0xffffULL prior to the merge into x86_mem.c.  You now
> > > use 0xfffUL.  I have no idea whether this is related to 
> > > cause.
> > 
> > Well, yes, I found two instances more of such bugs, one seems to be innocent,
> > and another might be the issue.  Please try this on top of r313934 or
> > the latest HEAD.
> > 

(patch delete)

> 
> At -r313934 + patch seems to fix the hang on loading i915kms.ko and
> also the sloooow output to vt.  Thanks for the quick response.  I'll
> update to top of tree to check that there isn't any other problems.
> 

A kernel and modules from top of tree works as expected.  Thanks for
the fix.

-- 
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow


More information about the freebsd-current mailing list