Fwd: FreeBSD Sparc 11.0 RC1 Install Problem

Marius Strobl marius at alchemy.franken.de
Thu Sep 8 22:12:33 UTC 2016

On Wed, Sep 07, 2016 at 11:26:11PM +0000, Chris wrote:
> On 09/07/16 21:51, Marius Strobl wrote:
> > On Wed, Aug 31, 2016 at 03:11:53PM +0000, Chris wrote:
> >>
> >> -------- Original Message --------
> >> Subject: FreeBSD Sparc 11.0 RC1 Install Problem
> >> Date: Wed, 31 Aug 2016 15:07:21 +0000
> >> From: Chris<xxx.syseng.yyy at gfsys.co.uk>
> >> Reply-To: syseng at gfsys.co.uk
> >> Newsgroups: comp.unix.bsd.freebsd.misc
> >>
> >> Hi,
> >>
> >> Have just installed the above on a V215 with a minor issue.
> >> After install shutdown, then reboot, the system hangs after
> >> the UHUB2 line. An earlier messages says:
> >>
> >> nexus0:<syscons>  type unknown, no driver attached
> >>
> >> Have been trying out various earlier releases over the
> >> past few months and one of the tips to solve an Xorg
> >> problem with console was to include the line:
> >>
> >> kern.vty=vt, in /boot/loader.conf
> >>
> >> This didn't solve the problem in the previous case,
> >> but was the clue here.
> >>
> >> When this is included, the system boots as normal. Don't
> >> know if this is a bug that has already been fixed, but
> >> syscons appears to be needed to run Xorg, isn't present
> >> and the system, and 11rc2 defaults to it. Just where is the
> >> code for syscons and how can it be included ?. A complete
> >> newbie to all this, embedded systems here, but the build
> >> procedures and Makefiles are well above my pay grade at
> >> present.
> >>
> >
> > Hi,
> >
> > while syscons(4) and vt(4) don't play well together on sparc64 when
> > both are compiled into the same kernel (as it's the case for 11.0-RC2
> > GENERIC), I can't actually trigger a boot hang with that combo.
> > Unfortunately, the information provided above also doesn't make much
> > sense; e. g. vt(4) already is the default with 11.0-RC2 GENERIC so
> > setting it via loader.conf is redundant and it remains unclear what
> > vt(4) is doing, i. e. whether it is driving some hardware (or at
> > least trying to).
> > How did you obtain the nexus0 line or see that the boot hangs after
> > uhub2; are you using LOM or serial console? Is there actually a
> > graphics card in that machine? What happens if you use a custom
> > built kernel without vt(4)?
> >
> > Marius
> >
> Hi,
> Thanks for the reply. I think I may have found the real cause, in
> that the problem showed up when I used the reboot command at the
> command line, rather than doing a power off and on via ilom or
> the power input. It's not really a serious issue, but suggests
> that that the reboot command is leaving some part of the hardware
> in an unexpected state prior to reboot. A power cycle of course,
> resets everything to a known state.

Well, `reboot` causes the kernel to tell the firmware to boot from
the same medium as previously used again. If this doesn't properly
reset the hardware, that's a firmware bug. For example, machfb(4)
for syscons(4) has a special handler which puts the display into
standby prior to a reboot, otherwise certain machines just will
hang when asked to boot again. What you are seening seems like
similar problem.

> The nexus line was among the stream of messages on a reboot and we
> are using ssh / terminal logins exclusively. There is a graphics
> card in the machine, a Sun XVR300, aka radeon 2250 with different
> firmware. It's not used at present though it does show up during boot
> as vga, fwir.

Vgapci(4) is just a glue driver which is needed for some things
and attaches to any PCI device which identifies as a display one
if no more specific driver is able to handle that device. Vgapci(4)
is not actually able to drive graphics hardware, though.

> Also seen by X, as far as it goes, before crashing.

Depending on the exact message, that like just means that X has
detected that card on the PCI bus, but not necessarily that both
kernel and X are able yo drive it.

> I've been away from it for a couple of days, but will try to get more
> info and report back. There is a sc line in the kernel config,
> but if there are conflicts, I guess it would be ok to remove
> that and other unneeded entries and rebuild the kernel ?. According
> to some docs, syscons needs the vga driver and another item in the
> kernel, neither of which are there at present, so it may be a good

That documentation apparently is x86-centric; for sparc64, no
VGA driver (probably the ISA one was meant in that documentation)
is needed and creator(4) as well as machfb(4) are the syscons(4)
drivers available, i. e. no specific driver for XVR300 so far.

It would be great if you could test whether a kernel built without
vt(4) also experiences the boot hang after a reboot.


More information about the freebsd-sparc64 mailing list