On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote: > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote: > > > > > > Well, the good news seems to be that r313254 and older are 'ok'. > > > So, something between r313943 and r313254 is triggering a the > > > problem. I'm still bisecting, but it might take a day or two. > > > > > > > I've been able to narrow the range down to r313854 to r313943. > > If I had to guess, the issue may be related to > > > > Author: kib > > Date: Fri Feb 17 21:08:32 2017 > > New Revision: 313898 > > URL: https://svnweb.freebsd.org/changeset/base/313898 > > > > Log: > > Merge i386 and amd64 mtrr drivers. > > > > I won't be able to investigate until later tonight (~ 10 hours from now). > > >From what I see in other messages, you are using i386 kernel on Core2 > class machine, am I right ? Did r313897 worked fine ? > > r313898 has a bug for i386 architecture, which was fixed in r313934. > Could you compile kernel from r313898 sources with r313934 applied on > top of it ? I mean, take r313898 and apply the changes from r313934 > either manually or with patch, but not take any further changes from > svn after r313898. > I just completed the bisection. r313934 is the problem. 'svn update -r 313933' boots and I can load drm2.ko. 'svn update -r 313934' boots and hangs on loading the module. As I noted in another reply I just sent, around -r313902 I can load the i915kms.ko but console output to vt is sloooow. Perhaps, a locking issue that 313934 exacerbated. -- Steve 20161221 https://www.youtube.com/watch?v=IbCHE-hONowReceived on Wed Feb 22 2017 - 04:37:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC