Date: Thu, 29 Aug 2013 07:23:20 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Ronald Klop <ronald-freebsd8@klop.yi.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-ID: <CAJ-VmokTrMDJtw0OwjMamW-T=ZAx_6%2BhLxq=mxUbfLLA84ecPA@mail.gmail.com> In-Reply-To: <op.w2k0j5i08527sy@212-182-167-131.ip.telfort.nl> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan> <op.w2k0j5i08527sy@212-182-167-131.ip.telfort.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -adrian 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> > " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokTrMDJtw0OwjMamW-T=ZAx_6%2BhLxq=mxUbfLLA84ecPA>