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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jukka A. Ukkonen

I had a bit of an accident with my old PowerMac G4 which had been
running FreeBSD-10.4. To fix the mess I had to boot the system from
a CD image. So, I decided to try 11.1 while at it. To my astonishment
and disappointment the 11.1 images (both CD and DVD) paniced
very early on during the boot. The messages flashed past the screen
so quickly that I cannot be really sure about anything, but it kind of
seemed like the issue might be yet another installment of the SPRG
related problems (in ofw_machdep.c) which have been troubling
ppc64 systems before.
The 10.4 CD image boots just fine on ppc.

--jau

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Justin Hibbits-2
Hi,

On Sun, Apr 15, 2018 at 2:10 AM, Jukka Ukkonen <[hidden email]> wrote:

>
> I had a bit of an accident with my old PowerMac G4 which had been
> running FreeBSD-10.4. To fix the mess I had to boot the system from
> a CD image. So, I decided to try 11.1 while at it. To my astonishment
> and disappointment the 11.1 images (both CD and DVD) paniced
> very early on during the boot. The messages flashed past the screen
> so quickly that I cannot be really sure about anything, but it kind of
> seemed like the issue might be yet another installment of the SPRG
> related problems (in ofw_machdep.c) which have been troubling
> ppc64 systems before.
> The 10.4 CD image boots just fine on ppc.
>
> --jau

Can you try booting with 'boot -v' and also setting at the loader
debug.debugger_on_panic=1?  I think it's set to 0 on release ISOs, so
this should let you get a screen capture.

- Justin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Jukka A. Ukkonen

> On 17 Apr 2018, at 18.11, Justin Hibbits <[hidden email]> wrote:
>
> Hi,
>
>> On Sun, Apr 15, 2018 at 2:10 AM, Jukka Ukkonen <[hidden email]> wrote:
>>
>> I had a bit of an accident with my old PowerMac G4 which had been
>> running FreeBSD-10.4. To fix the mess I had to boot the system from
>> a CD image. So, I decided to try 11.1 while at it. To my astonishment
>> and disappointment the 11.1 images (both CD and DVD) paniced
>> very early on during the boot. The messages flashed past the screen
>> so quickly that I cannot be really sure about anything, but it kind of
>> seemed like the issue might be yet another installment of the SPRG
>> related problems (in ofw_machdep.c) which have been troubling
>> ppc64 systems before.
>> The 10.4 CD image boots just fine on ppc.
>>
>> --jau
>
> Can you try booting with 'boot -v' and also setting at the loader
> debug.debugger_on_panic=1?  I think it's set to 0 on release ISOs, so
> this should let you get a screen capture.
>
> - Justin

I will try, but it might have to wait until the weekend.

--jau

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Jukka A. Ukkonen
In reply to this post by Justin Hibbits-2

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


> On 17 Apr 2018, at 18.11, Justin Hibbits <[hidden email]> wrote:
>
> Hi,
>
>> On Sun, Apr 15, 2018 at 2:10 AM, Jukka Ukkonen <[hidden email]> wrote:
>>
>> I had a bit of an accident with my old PowerMac G4 which had been
>> running FreeBSD-10.4. To fix the mess I had to boot the system from
>> a CD image. So, I decided to try 11.1 while at it. To my astonishment
>> and disappointment the 11.1 images (both CD and DVD) paniced
>> very early on during the boot. The messages flashed past the screen
>> so quickly that I cannot be really sure about anything, but it kind of
>> seemed like the issue might be yet another installment of the SPRG
>> related problems (in ofw_machdep.c) which have been troubling
>> ppc64 systems before.
>> The 10.4 CD image boots just fine on ppc.
>>
>> --jau
>
> Can you try booting with 'boot -v' and also setting at the loader
> debug.debugger_on_panic=1?  I think it's set to 0 on release ISOs, so
> this should let you get a screen capture.
>
> - Justin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

freebsd-ppc mailing list
On 2018-Apr-20, at 10:23 AM, Jukka Ukkonen <[hidden email]> 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.)


>> On 17 Apr 2018, at 18.11, Justin Hibbits <[hidden email]> wrote:
>>
>> Hi,
>>
>>> On Sun, Apr 15, 2018 at 2:10 AM, Jukka Ukkonen <[hidden email]> wrote:
>>>
>>> I had a bit of an accident with my old PowerMac G4 which had been
>>> running FreeBSD-10.4. To fix the mess I had to boot the system from
>>> a CD image. So, I decided to try 11.1 while at it. To my astonishment
>>> and disappointment the 11.1 images (both CD and DVD) paniced
>>> very early on during the boot. The messages flashed past the screen
>>> so quickly that I cannot be really sure about anything, but it kind of
>>> seemed like the issue might be yet another installment of the SPRG
>>> related problems (in ofw_machdep.c) which have been troubling
>>> ppc64 systems before.
>>> The 10.4 CD image boots just fine on ppc.
>>>
>>> --jau
>>
>> Can you try booting with 'boot -v' and also setting at the loader
>> debug.debugger_on_panic=1?  I think it's set to 0 on release ISOs, so
>> this should let you get a screen capture.
>>
>> - Justin

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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

freebsd-ppc mailing list


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 <[hidden email]> 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)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[hidden email]"