From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 14:15:43 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94780273 for ; Thu, 29 Aug 2013 14:15:43 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by mx1.freebsd.org (Postfix) with ESMTP id 08F382AEC for ; Thu, 29 Aug 2013 14:15:42 +0000 (UTC) Received: from cpsps-ews09.kpnxchange.com ([10.94.84.176]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:15:36 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews09.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:15:36 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 29 Aug 2013 16:15:36 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 2B2DFC3E1 for ; Thu, 29 Aug 2013 16:15:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Date: Thu, 29 Aug 2013 16:15:31 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1377271598.1111.78.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 29 Aug 2013 14:15:36.0639 (UTC) FILETIME=[3B5574F0:01CEA4C2] X-RcptDomain: freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:15:43 -0000 On Fri, 23 Aug 2013 17:26:38 +0200, 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 My Sheevaplug does not finish booting anymore either. ## Starting application at 0x00900000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #12: Thu Aug 29 15:14:50 CEST 2013 root@mailjail.klop.ws:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 518934528 (494 MB) SOC: Marvell 88F6281 rev A0, TClock 200MHz Instruction cache prefetch enabled, data cache prefetch enabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy random: initialized localbus0: on fdtbus0 nand0: mem 0xf9300000-0xf93fffff on localbus0 nandbus0: on nand0 lnand0: on nandbus0 lnand0: Found BBT table for chip simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on simplebus0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: 00:50:43:01:6f:12 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1066,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0 on ehci0 cryptosoft0: Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 Root mount waiting for: usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:/dev/da0s2 []... mountroot: waiting for device /dev/da0s2 ... da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) da0: quirks=0x2 Setting hostuuid: 64f53bc5-bfde-11d3-902f-005043016d4c. Setting hostid: 0x2afd1481. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point ^C or ^T don't do anything. But when I remove the usb-stick it prints info about it. ugen0.2: at usbus0 (disconnected) umass0: at uhub0, port 1, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 3 refs (da0:umass-sim0:0:0:0): removing device entry If I can help to resolve this, than I can spend some time on it. I can program, but am not aware of the kernel internals. I can break into the debugger. Ronald.