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>
index | next in thread | previous in thread | raw e-mail
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: > > >> 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)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5770E2A2-9AD8-4B5A-A211-E04326B2A997>