11.1 release CD image panics very early during boot on ppc.

Sat Apr 21 08:10:30 UTC 2018

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 at gmail.com> wrote:
> 
> 
>> So, I tried setting debug.debugger_on_panic=1 and ”boot -v”.
>> 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 
>> 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=1 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.
>> 
>> I hope this helps.
>> 
>> --jau
> 
> 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.
> 
> 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.
> 
> But it has been a very long time since I've done such experiments
> in this area. So take this note as only suggestive.
> 
> 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.
> 
> Looking in the list history (10.x time frames):
> 
> https://lists.freebsd.org/pipermail/freebsd-ppc/2014-September/007260.html
> https://lists.freebsd.org/pipermail/freebsd-ppc/2014-September/007263.html
> 
> It mattered for GeForce 7800 GT vs. Radeon X1950 for the 2560x1440
> behavior.
> 
> 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.)
> 
> (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=210382
https://svnweb.freebsd.org/base?view=revision&revision=303043

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  == 2400/16 == 150 and _VTDEFW == 4096/8 == 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 == 100 == VBF_DEFAULT_HISTORY_SIZE
but _VTDEFH == 150 == .vw_buf.vb_scr_size.tp_row)

         .vw_buf = {
                .vb_buffer = &vt_constextbuf[0],
                .vb_rows = &vt_constextbufrows[0],
                .vb_history_size = VBF_DEFAULT_HISTORY_SIZE,

                .vb_flags = VBF_STATIC,
. . .
                .vb_scr_size = {
                        .tp_row = _VTDEFH,
                        .tp_col = _VTDEFW,
                },
. . .

vtbuf_init(struct vt_buf *vb, const term_pos_t *p)
{
. . .
         vb->vb_scr_size = *p;
         vb->vb_history_size = VBF_DEFAULT_HISTORY_SIZE;

         if ((vb->vb_flags & VBF_STATIC) == 0) {
                 sz = vb->vb_history_size * p->tp_col * sizeof(term_char_t);
                 vb->vb_buffer = malloc(sz, M_VTBUF, M_WAITOK | M_ZERO);

                 sz = vb->vb_history_size * sizeof(term_char_t *);
                 vb->vb_rows = 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 = history_size;
         vb->vb_buffer = new;
         vb->vb_rows = rows;
         vb->vb_flags &= ~VBF_STATIC;
         vb->vb_scr_size = *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;

         vb->vb_history_size = MAX(vb->vb_history_size, vb->vb_scr_size.tp_row);

         for (r = 0; r < vb->vb_history_size; r++)
                 vb->vb_rows[r] = &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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)