Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Aug 2013 09:26:38 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Andrew Turner <andrew@fubar.geek.nz>
Cc:        freebsd-arm@FreeBSD.org
Subject:   Re: Reminder: Removal of WITHOUT_ARM_EABI
Message-ID:  <1377271598.1111.78.camel@revolution.hippie.lan>
In-Reply-To: <20130820091527.42127170@bender.Home>
References:  <20130820091527.42127170@bender.Home>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2013-08-20 at 09:15 +0100, Andrew Turner wrote:
> I am planning on removing WITHOUT_ARM_EABI before 10.0 is released. As
> this is planned on happening soon it this change is likely to happen
> within the next two weeks, after a short heads up.
> 
> This is a reminder for people who have not yet moved to the ARM EABI to
> do so now as their build will break when this option is removed.
> 

It turns out that on DreamPlug (armv5te) the unit won't boot all the way
to multiuser mode with EABI, building with gcc or clang.  I first
discovered this a few days ago when I realized I was still building with
OABI on dreamplug and tried to switch.  I tried going back to a revision
in late July but that didn't make any difference.  The before getting
any further with bisecting I heard from Ilya Bakulin on irc that the
problems I'm seeing (hanging in rc.d/initrandom and rc.d/var) go back to
at least April.

The rc.d/initrandom problem seems to be while running the 'df' command
to "generate entropy."  In rc.d/var the problem is while running newfs
on /dev/md0, and I can more readily confirm that -- if I use ^C to get
past the hangs in rc.d processing it'll limp its way to multiuser mode,
and if you manually try to "newfs /dev/md0" it definitely hangs the same
way.  When it's hung in that state, a ^T gives no info, but a ^C does
break out of the hang.  I've been unable to get any more info about
how/why it's hung.

I can understand a desire to not let any 10.0 release get into the wild
with OABI support, but I'm not sure that removing the ability to even
try OABI to see if it fixes a problem is a good idea.  EABI just doesn't
have enough testing to declare that it's solid (because clearly it's not
yet solid).  Can we declare that OABI isn't supported without removing
the ability to fall back to it for testing purposes?  I wouldn't mind if
enabling it requires something like WITH_UNSUPPORTED_OABI_FOR_TESTING.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1377271598.1111.78.camel>