From owner-freebsd-arm@FreeBSD.ORG Thu Aug 29 14:42:12 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 55DD9E97; Thu, 29 Aug 2013 14:42:12 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 166DF2CBE; Thu, 29 Aug 2013 14:42:11 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VF3QB-0006VX-Og; Thu, 29 Aug 2013 14:42:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7TEfxMT055648; Thu, 29 Aug 2013 08:41:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18QpOFwXicf52yTe5ZzKoLW Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 2013 08:41:59 -0600 Message-ID: <1377787319.1111.277.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Ronald Klop 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:42:12 -0000 On Thu, 2013-08-29 at 07:23 -0700, Adrian Chadd wrote: > Hm, which commit broke this? > > Did someone commit something to the random number framework that is hanging > the kernel early because there's not enough entropy? > As mentioned in the text below (which of course will get trimmed now by sensible mail clients because you top-posted in a bottom-posted thread), it has been broken since at least April. This problem is somewhat resistant to simple debugging -- the kernel isn't hung overall, but some userland processes become hung while waiting for something in the kernel. It's not a deadlock that witness can detect, it seems to be something more like waiting for IO to complete and it never does. Running newfs on a /dev/md# will hang for sure (but you can ^C out of it). While it's in this state, you cannot launch top or ps or any of the usual tools for figuring out what the system is doing -- the tools also hang, and they do NOT respond to a ^C when hung (but will exit with a kill -9 from another shell). -- Ian > > On 29 August 2013 07:15, Ronald Klop wrote: > > > 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. > > > > ______________________________**_________________ > > 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 > > " > > > _______________________________________________ > 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"