Re: Recent problems with -current on alpha...

From: Bruce Evans (bde_at_zeta.org.au)
Date: 02/27/04

  • Next message: Ken Smith: "Re: Recent problems with -current on alpha..." 
    Date: Sat, 28 Feb 2004 02:00:44 +1100 (EST)
To: Ken Smith <kensmith@cse.Buffalo.EDU>

    On Thu, 26 Feb 2004, Ken Smith wrote:

    > With lots of help from Andrew Gallatin and Marcel Moolenaar I think I've
    > located the problem with -current on alpha and I have a very rough
    > patch that gets the cluster's Alpha reference machine to the point
    > it boots and runs. In a nutshell the promcons stuff used to allow
    > debugging info to be printed to the console from a very early point
    > in the boot doesn't work any more. Things like make_dev() require
    > the machine to have progressed to the point that more of the VM
    > system is functional than before (this seems to have begun with the
    > device megapatches).

    make_dev() doesn't need vm for the first DEVT_STASH (default 50)
    allocations. syscons console initialization depends on this. The
    unlogged reason that rev.1.412 of syscons.c didn't work is that it was
    committed before make_dev() could handle it, so the system crashed
    early iff syscons was the console. Perhaps the promcons initialization
    is even earlier than i386 console initialization. I'm not familiar
    with it, but it is hard for it to be much earlier -- i386 console
    initialization is done in the first C function called from locore.

    Another thing that can cause problems is using printf() before the
    console has been initialized. I hade a printf() in make_dev(). When
    syscons started calling make_dev() early, this printf() caused much
    the same crash as rev.1.412 of syscons.c. Hmm, it was actually the
    same crash. Both crashes were cause by a printf() in make_dev(), and
    both were fixed by removing the printf(). In -current, the removal
    was in rev.1.139 of kern_conf.c.

    > My patch moves the initialization of the promcons stuff until after
    > the VM system is initialzed and comments out all the printf()'s I
    > could find that might have happened before the console is initialized.

    This would break use of ddb until after the vm system is initialized
    (unless it is already broken). i386 console initialization tries hard
    to initiatialize the console as early as possible so that it can be
    used for debugging. This is less needed with gdb, but early printfs
    still need a console.

    The make_dev() line in promcons.c was last changed in Y2K, so it console
    initialization is apparently already done late for alphas (which is OK
    iff the firmware console is used early). The problem might be simply a
    stray printf done early. Try avoiding such printfs, and this works then
    debug why early printfs cause crashes. They should just go to a buffer
    that gets printed later, or at least get counter so that they can be
    warned about later. The buffer can't be the message buffer, since the
    message buffer is not initialized until later, at least on i386's.
    printf already takes care not to use a nonexistent message buffer but
    doesn't take care to warn about dropped messages.

    Bruce
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Ken Smith: "Re: Recent problems with -current on alpha..."

    Relevant Pages

    • Re: Create a console app under EmbeddedVC4, and debug it
      ... don't typically use printf, so I don't know if that will work or not. ... > from Embedded VC4. ... > I understand that WinMain is a console application, however, I really want ... > since we have some existing code that we want to compile it. ...
      (microsoft.public.windowsce.embedded)
    • Re: Recent problems with -current on alpha...
      ... >> My patch moves the initialization of the promcons stuff until after ... >> could find that might have happened before the console is initialized. ... I don't know if this patch is an appropriate short-term fix (I'd tend ... patch beast seems to boot and runs just fine. ...
      (freebsd-current)
    • Re: How to implement diagnostic messages?
      ... eventually, I made a macro which hooked printf to one of my own functions, and mostly ended up just redirecting its output to a log file and to an in-program console. ... later, I also added a "dbgprintf" function, which also accepts an integer parameter giving its "debug level", but have not ended up widely using it. ... the idea here would be that dbgprintf would also redirect to the console, and to the log file, but that the debug-level could be used to cull lower-priority messages. ...
      (comp.programming)
    • Re: mtx_lock_do_what_i_mean()
      ... kernel from anything to which we have a TTY attached. ... at printf() as a means to write to the message buffer only. ... and 2) something you can do by going through the TTY ... The fact that currently the console is used by both does ...
      (freebsd-arch)
    • Re: Machine wedges solid after one serial-port source-line addition...
      ... (My original hack-patches without ... All it does is notify the console whenever a serial port DCD ... You are calling printf() from a fast interrupt handler. ...
      (freebsd-hackers)