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-hONowReceived on Wed Feb 22 2017 - 06:03:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC