Bug#809611: d-i fails to boot on HP mv2120
On Sat, Jan 02, 2016 at 01:04:47AM +0100, Geert Stappers wrote:
> >
> > Output from the serial console is below:
> >
> > ------------------------------------------------------------------------------------
> > __ __ _ _
> > | \/ | __ _ _ ____ _____| | |
> > | |\/| |/ _` | '__\ \ / / _ \ | |
> > | | | | (_| | | \ V / __/ | |
> > |_| |_|\__,_|_| \_/ \___|_|_|
> > _ _ ____ _
> > | | | | | __ ) ___ ___ | |_
> > | | | |___| _ \ / _ \ / _ \| __|
> > | |_| |___| |_) | (_) | (_) | |_
> > \___/ |____/ \___/ \___/ \__| ** Forcing LOADER mode only **
> > ** MARVELL BOARD: RD-88F5182-NAS-P2 LE
> >
> > U-Boot 1.1.4 (Oct 12 2007 - 12:30:28) Marvell version:
> > 2.3.11_HP_1_3_1_Built@HP
> >
> > U-Boot code: 00200000 -> 0026FFF0 BSS: -> 0027FDBC
> <snip/>
> > Booting the image (@ 0x400000) with RamDisk (@ 0x600000)...
> > ## Booting image at 00400000 ...
> > Image Name: Debian kernel
> > Created: 2015-12-31 0:09:38 UTC
> > Image Type: ARM Linux Kernel Image (uncompressed)
> > Data Size: 1988600 Bytes = 1.9 MB
> > Load Address: 01000000
> > Entry Point: 01000000
> > Verifying Checksum ... OK
> > OK
> > ## Loading Ramdisk Image at 00600000 ...
> > Image Name: Debian installer
> > Created: 2015-12-31 0:09:38 UTC
> > Image Type: ARM Linux RAMDisk Image (uncompressed)
> > Data Size: 6286998 Bytes = 6 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> >
> > Starting kernel ...
> >
> > Uncompressing Linux... done, booting the kernel.
> <snip/>
> > [ 0.000000] Kernel command line: console=ttyS0,115200
>
> Only 'console=...'
>
> <snip/>
> > [ 0.000000] Virtual kernel memory layout:
> > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> > [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> > [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
> > [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
> > [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> > [ 0.000000] .text : 0xc0008000 - 0xc055abf0 (5451 kB)
> > [ 0.000000] .init : 0xc055b000 - 0xc05a6000 ( 300 kB)
> > [ 0.000000] .data : 0xc05a6000 - 0xc060fa60 ( 423 kB)
> > [ 0.000000] .bss : 0xc060fa60 - 0xc065632c ( 283 kB)
> > [ 0.000000] NR_IRQS:65
> > [ 0.000025] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps every 12884901885ns
>
> 12884901885ns
> 12884901us (micro)
> 12884ms
> 12s
>
> those twelve secondes _might_ explain twelve seconds.
>
> but from 12 seconds to almost 15 seconds, still lacks three seconds.
>
> I wonder what happens between '[ 0.000025]' and '[ 14.996063]'
> It is out of curiosity. The gap in logging is not the reason for te boot failure.
The 'wraps every x' output from the kernel is as far as I can tell
complete nonsense. I think there is a bug in the calculation, but I
haven't been able to figure out what it is yet (I think it might be an
overflow in one of the steps in the calculation).
Certainly here, 166MHz should be able to go 24 seconds in 32bits,
unless it is signed and resets to 0, which would really be 31 bits then.
And on systems with 56 or 64bit counters, it still claims to wrap in a
few minutes when in fact it should last decades if you do the math.
--
Len Sorensen
Reply to: