Date: Thu, 29 Aug 2013 08:41:59 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@FreeBSD.org>, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-ID: <1377787319.1111.277.camel@revolution.hippie.lan> In-Reply-To: <CAJ-VmokTrMDJtw0OwjMamW-T=ZAx_6%2BhLxq=mxUbfLLA84ecPA@mail.gmail.com> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <op.w2k0j5i08527sy@212-182-167-131.ip.telfort.nl> <CAJ-VmokTrMDJtw0OwjMamW-T=ZAx_6%2BhLxq=mxUbfLLA84ecPA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ronald-freebsd8@klop.yi.org> wrote: > > > On Fri, 23 Aug 2013 17:26:38 +0200, Ian Lepore <ian@freebsd.org> 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: <Software, Yarrow> initialized > > localbus0: <Marvell device bus> on fdtbus0 > > nand0: <Marvell NAND controller> mem 0xf9300000-0xf93fffff on localbus0 > > nandbus0: <NAND bus> on nand0 > > lnand0: <Samsung NAND 512MiB 3,3V 8-bit> on nandbus0 > > lnand0: Found BBT table for chip > > simplebus0: <Flattened device tree simple bus> on fdtbus0 > > ic0: <Marvell Integrated Interrupt Controller> mem 0xf1020200-0xf102023b > > on simplebus0 > > timer0: <Marvell CPU Timer> mem 0xf1020300-0xf102032f irq 1 on simplebus0 > > Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 > > Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 > > gpio0: <Marvell Integrated GPIO Controller> mem 0xf1010100-0xf101011f irq > > 35,36,37,38,39,40,41 on simplebus0 > > rtc0: <Marvell Integrated RTC> mem 0xf1010300-0xf1010307 on simplebus0 > > mge0: <Marvell Gigabit Ethernet controller> mem 0xf1072000-0xf1073fff irq > > 12,13,14,11,46 on simplebus0 > > mge0: Ethernet address: 00:50:43:01:6f:12 > > miibus0: <MII bus> on mge0 > > e1000phy0: <Marvell 88E1116R Gigabit PHY> 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: <Marvell Cryptographic Engine and Security Accelerator> mem > > 0xf1030000-0xf103ffff irq 22 on simplebus0 > > ehci0: <Marvell Integrated USB 2.0 controller> mem 0xf1050000-0xf1050fff > > irq 48,19 on simplebus0 > > usbus0: EHCI version 1.0 > > usbus0: set host controller mode > > usbus0 on ehci0 > > cryptosoft0: <software crypto> > > 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: <Marvell> at usbus0 > > uhub0: <Marvell EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0 > > Root mount waiting for: usbus0 > > uhub0: 1 port with 1 removable, self powered > > Root mount waiting for: usbus0 > > ugen0.2: <USB 2.0> at usbus0 > > umass0: <USB 2.0 USB Flash Drive, class 0/0, rev 2.00/11.00, addr 2> 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: <USB 2.0 USB Flash Drive 1100> Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: 3894MB (7975296 512 byte sectors: 255H 63S/T 496C) > > da0: quirks=0x2<NO_6_BYTE> > > 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: <USB 2.0> 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<http://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@**freebsd.org<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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1377787319.1111.277.camel>