From owner-freebsd-ppc@freebsd.org Sat Apr 21 08:10:30 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BFFCFAD894 for ; Sat, 21 Apr 2018 08:10:30 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic316-22.consmr.mail.ne1.yahoo.com (sonic316-22.consmr.mail.ne1.yahoo.com [66.163.187.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0409732AB for ; Sat, 21 Apr 2018 08:10:29 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: vWwurOUVM1lW0VGtKMHaaeDZ78IQGBLLT1y2mw2PF3.5JO72dWUIQ9gq0meB.rT wlGuBb8VIGxWNWJwvc9ZWHXRKxGzEATld3ZZaPON6rr7wxoo9QA.JflldxiJbpEAwmfMdtxCwk.v 9mtAd5xuenG.V9m_RmKAkVD7i70Do4n8H9EW6NAHjrS7jlRFTX1XTQMkaFnP6h5nI450dnh6lFzr WLFO.MczFqifuOmJj.5wIkmDiCXeX.wU9_tQ49s46vhMWw8WPscaczle0P4OLWNrS9rE8HDHKjr_ lAWcNw1iHtYRBT5dClKxgP5UiuPZFEVIw5ghtM3fI56b41myY27YrEZWLpdiKMZBagdiS04qtWh3 k2mq1vumVAtfPdMtkiArnXTThyLfStg3OVgmA5g35uPqGtb9FnkQ4GeVNtsiRUZBoywC9Cw6X84N afjIv7QNQNqqUK2MAcZKvoeQrcEuxx6LeOTTN9nqnJVEW7HzeW1MGhtko.u78CZiRer5YBfeOoIU yQFB5TwOQOh77cqOPqV2bq01RJ4JS3zGLo5vxFoZGfC7DqhXvjIqxasLAu4MZZYT0VUUZBk0Gcy2 LQg18dBrJ04yzkg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sat, 21 Apr 2018 08:10:23 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp415.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 21e4afd4ecf8e319c37122e1e054ab41; Sat, 21 Apr 2018 08:10:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: 11.1 release CD image panics very early during boot on ppc. From: Mark Millard In-Reply-To: Date: Sat, 21 Apr 2018 01:10:20 -0700 Cc: Justin Hibbits , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <5770E2A2-9AD8-4B5A-A211-E04326B2A997@yahoo.com> References: To: Jukka Ukkonen X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 08:10:30 -0000 On 2018-Apr-20, at 5:43 PM, Mark Millard = wrote: > On 2018-Apr-20, at 10:23 AM, Jukka Ukkonen wrote: >=20 >=20 >> So, I tried setting debug.debugger_on_panic=3D1 and =E2=80=9Dboot = -v=E2=80=9D. >> The first time I tried the ofw did not see the full-HD display >> which was connected to another system via a KVM switch at >> that time. I only got the KVM switched to the correct system >> only when I had got the booting stopped at the ofw prompt. >> So, the early boot assumed a very traditional 80 columns by >> 25 to 30 lines display with a large font. Surprisingly the 11.1 CD >> booted just fine. Obviously I wanted to double check and rebooted >> the system. This time the display was connected via the KVM >> switch to the system right from the start. The ofw obviously figured >> out the true full-HD resolution and used a tiny font. When the kernel=20= >> got control of the system it selected a bit larger font, showed some >> of the autoconfig messages, and went down hard no matter whether >> I set the debug.debugger_on_panic=3D1 or not. >> This raises the obvious assumption that there must be something >> going awry with how vt and ofw communicate and how they try to >> control the display. Supposedly this could lead to mismanagement >> of a large chunk of memory such that even the debugger is left >> totally powerless when the crash happens. Because vt is new to 11.1 >> and the properly booting 10.4 uses sc, memory corruption seems >> like a plausible explanation to the mysterious crash. >>=20 >> I hope this helps. >>=20 >> --jau >=20 > It has been a long time since I've booted an old PowerMac with > vt on my larger displays. I actually build a kernel with both > vt and sc in it (no PS3 support) and normally boot sc. >=20 > My historical reason for avoiding vt was the early stages having > a fixed sized memory area tied to what was to be displayed and it > going out of bounds of that area and trashing things when I had a > large enough display attached. >=20 > But it has been a very long time since I've done such experiments > in this area. So take this note as only suggestive. >=20 > As I remember, the display types that had the problem were > 2560x1440 or something like that. vt would boot fine for > smaller displays that I used, such as 1920x1200, as I > remember. >=20 > Looking in the list history (10.x time frames): >=20 > = https://lists.freebsd.org/pipermail/freebsd-ppc/2014-September/007260.html= > = https://lists.freebsd.org/pipermail/freebsd-ppc/2014-September/007263.html= >=20 > It mattered for GeForce 7800 GT vs. Radeon X1950 for the 2560x1440 > behavior. >=20 > As I remember, the maximum screen size involved in the kernel > was changed as Nathan indicates, but still to some fixed figures > for the early code. Likely still a problem for a sufficiently > large display. (Beyond what I have access to now.) >=20 > (The xf86-video-scfb suggestion did not work for the X1950. I stopped > using X on the old PowerMac long ago.) It looks like later there was a size increase to 4096x2400: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210382 https://svnweb.freebsd.org/base?view=3Drevision&revision=3D303043 Looking at the modern code quickly, what I see is (material from multiple files): #ifdef SC_HISTORY_SIZE #define VBF_DEFAULT_HISTORY_SIZE SC_HISTORY_SIZE #else #define VBF_DEFAULT_HISTORY_SIZE 500 #endif #ifndef VT_FB_MAX_WIDTH #define VT_FB_MAX_WIDTH 4096 #endif #ifndef VT_FB_MAX_HEIGHT #define VT_FB_MAX_HEIGHT 2400 #endif #define PIXEL_WIDTH(w) ((w) / 8) #define PIXEL_HEIGHT(h) ((h) / 16) #define _VTDEFH MAX(100, PIXEL_HEIGHT(VT_FB_MAX_HEIGHT)) #define _VTDEFW MAX(200, PIXEL_WIDTH(VT_FB_MAX_WIDTH)) (NOTE: _VTDEFH =3D=3D 2400/16 =3D=3D 150 and _VTDEFW =3D=3D 4096/8 =3D=3D= 512) (So if the SC_HISTORY_SIZE default is 100, as documented, and is defined, it is smaller than _VTDEFH.) static term_char_t vt_constextbuf[(_VTDEFW) * = (VBF_DEFAULT_HISTORY_SIZE)]; static term_char_t *vt_constextbufrows[VBF_DEFAULT_HISTORY_SIZE]; (NOTE: The above is problematical for: SC_HISTORY_SIZE =3D=3D 100 =3D=3D VBF_DEFAULT_HISTORY_SIZE but _VTDEFH =3D=3D 150 =3D=3D .vw_buf.vb_scr_size.tp_row) .vw_buf =3D { .vb_buffer =3D &vt_constextbuf[0], .vb_rows =3D &vt_constextbufrows[0], .vb_history_size =3D VBF_DEFAULT_HISTORY_SIZE, .vb_flags =3D VBF_STATIC, . . . .vb_scr_size =3D { .tp_row =3D _VTDEFH, .tp_col =3D _VTDEFW, }, . . . vtbuf_init(struct vt_buf *vb, const term_pos_t *p) { . . . vb->vb_scr_size =3D *p; vb->vb_history_size =3D VBF_DEFAULT_HISTORY_SIZE; if ((vb->vb_flags & VBF_STATIC) =3D=3D 0) { sz =3D vb->vb_history_size * p->tp_col * = sizeof(term_char_t); vb->vb_buffer =3D malloc(sz, M_VTBUF, M_WAITOK | = M_ZERO); sz =3D vb->vb_history_size * sizeof(term_char_t *); vb->vb_rows =3D malloc(sz, M_VTBUF, M_WAITOK | M_ZERO); } . . . vtbuf_grow(struct vt_buf *vb, const term_pos_t *p, unsigned int = history_size) { . . . vb->vb_history_size =3D history_size; vb->vb_buffer =3D new; vb->vb_rows =3D rows; vb->vb_flags &=3D ~VBF_STATIC; vb->vb_scr_size =3D *p; vtbuf_init_rows(vb); . . . (NOTE: That last vtbuf_init_rows(vb) can increase vb->vb_history_size without adjusting the allocations associated with vb->vb_rows and vb->vb_buffer, despite overwriting the content of vb->vb_rows based on the potentially larger size and referencing more based off of vb->vb_buffer:) static void vtbuf_init_rows(struct vt_buf *vb) { int r; =20 vb->vb_history_size =3D MAX(vb->vb_history_size, = vb->vb_scr_size.tp_row); =20 for (r =3D 0; r < vb->vb_history_size; r++) vb->vb_rows[r] =3D &vb->vb_buffer[r * = vb->vb_scr_size.tp_col]; } (NOTE: No call to vtbuf_init when vtbuf_init_rows increases = vb->vb_history_size .) May be some of this is tied to what you ware seeing. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)