Date: Thu, 19 Jan 2017 13:51:59 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 216123] ofwfb: r269278 broke booting on Power Mac G4 Message-ID: <bug-216123-8-bqiGGt8AJf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-216123-8@https.bugs.freebsd.org/bugzilla/> References: <bug-216123-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216123 --- Comment #8 from Tom Lane <tgl@sss.pgh.pa.us> --- Created attachment 179069 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D179069&action= =3Dedit Minimum part of reverting r269278 to get CURRENT to boot I've not had any luck bringing a kernel debugger to bear, but I've experime= nted with the r269278 patch some more, and I can report that the portions attach= ed to this comment are the minimum needed to make it work. Without the seemingly-superfluous OF_open call in ofwfb_initialize, it freezes during b= oot in the way previously described. If the set-depth method call isn't removed from ofwfb_init, it boots but the screen display is completely messed up --- looks like it has the wrong idea about the framebuffer stride. I'm not sure what to make of this. I do not understand the division of lab= or between ofwfb_initialize and ofwfb_init, nor what the intended call sequence is, but I sort of suspect that the actual call sequence is different from w= hat the code's author expected. Obviously, this is still not a committable patch; the "extra" OF_open call might be safe enough, but removing the set-depth call would presumably represent a loss on better hardware. But perhaps this will give somebody an idea of what to pursue. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216123-8-bqiGGt8AJf>