Date: Thu, 29 Aug 2013 16:41:55 +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.w2k1r5sc8527sy@212-182-167-131.ip.telfort.nl> 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, 29 Aug 2013 16:23:20 +0200, Adrian Chadd <adrian@freebsd.org>
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?
>
>
>
> -adrian
As Ian pointed out, it hangs on 'df'. I added 'set -x' to
initrandom_start() in /etc/rc.d/initrandom which gives this output.
+ sysctl kern.random
+ soft_random_generator='kern.random.adaptors: yarrow
kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 192
kern.random.yarrow.slowthresh: 256
kern.random.yarrow.slowoverthresh: 2
kern.random.sys.seeded: 1
kern.random.sys.harvest.ethernet: 1
kern.random.sys.harvest.point_to_point: 1
kern.random.sys.harvest.interrupt: 1
kern.random.sys.harvest.swi: 0'
+ echo -n 'Entropy harvesting:'
Entropy harvesting:+ [ ! -z 'kern.random.adaptors: yarrow
kern.random.yarrow.gengateinterval: 10
kern.random.yarrow.bins: 10
kern.random.yarrow.fastthresh: 192
kern.random.yarrow.slowthresh: 256
kern.random.yarrow.slowoverthresh: 2
kern.random.sys.seeded: 1
kern.random.sys.harvest.ethernet: 1
kern.random.sys.harvest.point_to_point: 1
kern.random.sys.harvest.interrupt: 1
kern.random.sys.harvest.swi: 0' ]
+ [ -w /dev/random ]
+ checkyesno harvest_interrupt
+ eval '_value=$harvest_interrupt'
+ _value=YES
+ debug 'checkyesno: harvest_interrupt is set to YES.'
+ return 0
+ /sbin/sysctl kern.random.sys.harvest.interrupt=1
+ echo -n ' interrupts'
interrupts+ checkyesno harvest_ethernet
+ eval '_value=$harvest_ethernet'
+ _value=YES
+ debug 'checkyesno: harvest_ethernet is set to YES.'
+ return 0
+ /sbin/sysctl kern.random.sys.harvest.ethernet=1
+ echo -n ' ethernet'
ethernet+ checkyesno harvest_p_to_p
+ eval '_value=$harvest_p_to_p'
+ _value=YES
+ debug 'checkyesno: harvest_p_to_p is set to YES.'
+ return 0
+ /sbin/sysctl kern.random.sys.harvest.point_to_point=1
+ echo -n ' point_to_point'
point_to_point+ [ -w /dev/random ]
+ feed_dev_random /entropy
+ [ -f /entropy -a -r /entropy -a -s /entropy ]
+ cat /entropy
+ dd of=/dev/random bs=8k
+ better_than_nothing
+ dd of=/dev/random bs=8k
+ kenv
+ dmesg
+ df -ib
db> ps
pid ppid pgrp uid state wmesg wchan cmd
47 43 17 0 R+ CPU 0 df
44 36 17 0 S+ piperd 0xc3e9c720 dd
43 36 17 0 S+ wait 0xc3e3a960 sh
36 17 17 0 S+ wait 0xc3e3b320 sh
17 1 17 0 Ss+ wait 0xc3e3b640 sh
16 0 0 0 DL - 0xc0cca3b0 [schedcpu]
15 0 0 0 DL syncer 0xc0cdb7cc [syncer]
9 0 0 0 DL vlruwt 0xc3e40000 [vnlru]
8 0 0 0 DL psleep 0xc0cdb550 [bufdaemon]
7 0 0 0 DL pollid 0xc0cc9b68 [idlepoll]
6 0 0 0 RL [pagezero]
5 0 0 0 DL psleep 0xc0cea7c4 [pagedaemon]
4 0 0 0 DL ccb_scan 0xc0cbdd10 [xpt_thrd]
14 0 0 0 DL (threaded) [usb]
100028 D - 0xc3d1cd34 [usbus0]
100027 D - 0xc3d1cd04 [usbus0]
100026 D - 0xc3d1ccd4 [usbus0]
100025 D - 0xc3d1cca4 [usbus0]
13 0 0 0 DL - 0xc0cc0a44 [yarrow]
3 0 0 0 DL crypto_r 0xc0cde6c0 [crypto returns]
2 0 0 0 DL crypto_w 0xc0cde6b0 [crypto]
12 0 0 0 DL (threaded) [geom]
100008 D - 0xc0ce81a8 [g_down]
100007 D - 0xc0ce81a4 [g_up]
100006 D - 0xc0ce81a0 [g_event]
11 0 0 0 WL (threaded) [intr]
100024 I [intr19: ehci0]
100023 I [intr22: cesa0]
100022 I [swi0: uart uart]
100021 I [intr13: mge0]
100020 I [intr12: mge0]
100018 I [swi5: fast taskq]
100016 I [swi6: Giant taskq]
100015 I [swi6: task queue]
100012 I [swi2: cambio]
100005 I [swi3: vm]
100004 I [swi1: netisr 0]
100003 I [swi4: clock]
10 0 0 0 RL [idle]
1 0 1 0 SLs wait 0xc3466640 [init]
0 0 0 0 DLs (threaded) [kernel]
100019 D - 0xc3453c80 [nand taskq]
100017 D - 0xc3454480 [thread taskq]
100014 D - 0xc3454d80 [ffs_trim taskq]
100013 D - 0xc3454e00 [kqueue taskq]
100000 D swapin 0xc0ce81c8 [swapper]
Regards,
Ronald.
>
>
>
> 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?op.w2k1r5sc8527sy>