Date: Sat, 21 Apr 2018 01:10:20 -0700 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Jukka Ukkonen <jau789@gmail.com> Cc: Justin Hibbits <jrh29@alumni.cwru.edu>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: 11.1 release CD image panics very early during boot on ppc. Message-ID: <5770E2A2-9AD8-4B5A-A211-E04326B2A997@yahoo.com> In-Reply-To: <B750FF47-F65D-49FE-A2AD-A2935209294B@yahoo.com> References: <FBADE872-3319-4DE9-9E3C-797DE0CAEED0@gmail.com> <CAHSQbTBysTnBAxm-_PN1APug4iTgUFu160U7Aj0v-GSXhBTv4g@mail.gmail.com> <A0F75C7D-8785-4B37-8A5E-AC0327AE852F@gmail.com> <B750FF47-F65D-49FE-A2AD-A2935209294B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Apr-20, at 5:43 PM, Mark Millard <marklmi26-fbsd a tyahoo.com> = wrote: > On 2018-Apr-20, at 10:23 AM, Jukka Ukkonen <jau789@gmail.com> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5770E2A2-9AD8-4B5A-A211-E04326B2A997>