Date: Thu, 29 Aug 2013 16:15:31 +0200 From: "Ronald Klop" <ronald-freebsd8@klop.yi.org> To: freebsd-arm@freebsd.org Subject: Re: Reminder: Removal of WITHOUT_ARM_EABI Message-ID: <op.w2k0j5i08527sy@212-182-167-131.ip.telfort.nl> In-Reply-To: <1377271598.1111.78.camel@revolution.hippie.lan> References: <20130820091527.42127170@bender.Home> <1377271598.1111.78.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.w2k0j5i08527sy>