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.
> 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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"