From owner-freebsd-arm@FreeBSD.ORG Wed Aug 28 17:01:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C0C0AE5E; Wed, 28 Aug 2013 17:01:03 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C1FC281E; Wed, 28 Aug 2013 17:01:03 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d17so3101965eek.14 for ; Wed, 28 Aug 2013 10:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HTpaqFl/k2di+8CBqwFwtJt2XebrjkQGwFiAkBRlSa4=; b=vfmWQj+o/paRFenaKHO6jwJiEGchwranykGIJuSQYrIg8tEJ0NGdKBVvZJzqAuZoU6 2tLQ46APW1u0aRQITsE/YzsYHatrDyLioSU013y0AVhh9C1gVKBFfpyEPwUCCOgZDP3I SkKe6md+JxulOcJlbbO60bzcn32HLCnNzZ9wiOqCwg7fGzfpva/Wrqph8DMY3HcbVps9 u7MjmZIZOEN+6Ad1UeOkxPtFg2MVYvXHZR1i//9DWTZ+HMIHAKKkUWJDUs+U10IuKu6V Gt4GBkTe+LOKUbWnn18a3FGR1FSpMVWZxZihTokqPXp6+UBRUccqLQn15b4JpgRTzMyZ q5DA== X-Received: by 10.15.86.11 with SMTP id h11mr3048377eez.80.1377709261420; Wed, 28 Aug 2013 10:01:01 -0700 (PDT) Received: from [192.168.0.10] (46-126-92-160.dynamic.hispeed.ch. [46.126.92.160]) by mx.google.com with ESMTPSA id p5sm38955603eeg.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 10:01:00 -0700 (PDT) Message-ID: <521E2CCB.4070804@gmail.com> Date: Wed, 28 Aug 2013 19:00:59 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> In-Reply-To: <1377271598.1111.78.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:01:03 -0000 Well, here's my input on this: I've got around building a working kernel using CLANG (added option SCTP which fixed the alignment issue) and then got stuck at entropy harvesting. ^T doesn't do anything, nor does ^C. So I rebuilt everything with -DWITHOUT_ARM_EABI. There I get: Process (pid 1) got signal 11 Does a CLANG compiled world without EABI even work? Cheers, Mat On 23/08/13 17:26, Ian Lepore wrote: > 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 > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"