Re: Debian Jessie regression under qemu-system-sparc64
On 09/11/14 12:20, Mark Cave-Ayland wrote:
> Hi all,
>
> As part of the QEMU 2.2 release process, I've been testing various Linux
> images to make sure that there are no regressions under
> qemu-system-sparc64. However it looks as if in recent days something has
> badly broken:
>
>
> $ ./qemu-system-sparc64 -cdrom
> /home/build/src/qemu/image/sparc64/mini.iso -boot d -nographic
> OpenBIOS for Sparc64
> Configuration device id QEMU version 1 machine id 0
> kernel cmdline
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Nov 3 2014 20:17
> Type 'help' for detailed information
> Trying cdrom:f...
> Not a bootable ELF image
> Loading a.out image...
> Loaded 7680 bytes
> entry point is 0x4000
>
> Jumping to entry point 0000000000004000 for type 0000000000000005...
> switching to new context: entry point 0x4000 stack 0x00000000ffe8aa09
> SILO Version 1.4.14
> EXT2 superblock magic is wrong
> EXT2 superblock magic is wrong
> \
>
>
> Welcome to Debian GNU/Linux 8 (jessie)!
>
> This is a Debian installation CD-ROM, built on 20141109-00:31.
> Keep it once you have installed your system, as you can boot from it
> to repair the system on your hard disk if that ever becomes necessary.
>
> WARNING: You should completely back up all of your hard disks before
> proceeding. The installation procedure can completely and irreversibly
> erase them! If you haven't made backups yet, remove the rescue CD from
> the drive and press L1-A to get back to the OpenBoot prompt.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted
> by applicable law.
>
> [ ENTER - Boot install ] [ Type "expert" - Boot into expert mode ]
> [ Type "rescue" - Boot into rescue mode ]
> boot:
> Allocated 64 Megs of memory at 0x40000000 for kernel
> EXT2 superblock magic is wrong
> Uncompressing image...
> Loaded kernel version 3.16.7
> EXT2 superblock magic is wrong
> Loading initial ramdisk (5670802 bytes at 0x4400000 phys, 0x40C00000
> virt)...
> /
> [ 0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
> [ 0.000000] PROMLIB: Root node compatible: sun4u
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Initializing cgroup subsys cpuacct
> [ 0.000000] Linux version 3.16.0-4-sparc64
> (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) )
> #1 Debian 3.16.7-2 (2014-11-06)
> [ 0.000000] bootconsole [earlyprom0] enabled
> [ 0.000000] ARCH: SUN4U
> [ 0.000000] Ethernet address: 52:54:00:12:34:56
> [ 0.000000] MM: PAGE_OFFSET is 0xfffff80000000000 (max_phys_bits == 40)
> [ 0.000000] MM: VMALLOC [0x0000000100000000 --> 0x0000060000000000]
> [ 0.000000] MM: VMEMMAP [0x0000060000000000 --> 0x00000c0000000000]
> [ 0.000000] Kernel: Using 2 locked TLB entries for main kernel image.
> [ 0.000000] Remapping the kernel... done.
> [ 0.000000] OF stdout device is: /pci@1fe,0/ebus@3/su
> [ 0.000000] PROM: Built device tree with 51735 bytes of memory.
> [ 0.000000] Top of RAM: 0x7e80000, Total RAM: 0x7e80000
> [ 0.000000] Memory hole size: 0MB
> [ 0.000000] Kernel panic - not syncing: memblock_virt_alloc_try_nid:
> Failed to allocate 67108864 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0
> [ 0.000000]
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.0-4-sparc64
> #1 Debian 3.16.7-2
> [ 0.000000] Call Trace:
> [ 0.000000] [00000000008983b4] panic+0x98/0x208
> [ 0.000000] [0000000000ab8568] memblock_virt_alloc_try_nid+0x84/0x94
> [ 0.000000] [0000000000ab9754] sparse_init+0x1c/0x224
> [ 0.000000] [0000000000aabcb8] paging_init+0xd80/0xeb0
> [ 0.000000] [0000000000aa7068] setup_arch+0x2d4/0x718
> [ 0.000000] [0000000000aa4668] start_kernel+0x78/0x420
> [ 0.000000] [0000000000aa6d84] start_early_boot+0x1bc/0x1cc
> [ 0.000000] [0000000000897410] tlb_fixup_done+0x4c/0x5c
> [ 0.000000] [0000000000000000] (null)
> [ 0.000000] Press Stop-A (L1-A) to return to the boot prom
> [ 0.000000] ---[ end Kernel panic - not syncing:
> memblock_virt_alloc_try_nid: Failed to allocate 67108864 bytes align=0x0
> nid=-1 from=0x0 max_addr=0x0
> [ 0.000000]
> [ 0.000000] Unable to handle kernel NULL pointer dereference
> [ 0.000000] tsk->{mm,active_mm}->context = 0000000000000000
> [ 0.000000] tsk->{mm,active_mm}->pgd = fffff80000402000
> [ 0.000000] \|/ ____ \|/
> [ 0.000000] "@'/ .. \`@"
> [ 0.000000] /_| \__/ |_\
> [ 0.000000] \__U_/
> [ 0.000000] swapper(0): Oops [#1]
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.0-4-sparc64
> #1 Debian 3.16.7-2
> [ 0.000000] task: 0000000000a14470 ti: 00000000009fc000 task.ti:
> 00000000009fc000
> [ 0.000000] TSTATE: 0000004480e01601 TPC: 00000000004a36fc TNPC:
> 00000000004a3700 Y: 00000000 Not tainted
> [ 0.000000] TPC: <kstat_incr_irq_this_cpu+0x1c/0x60>
> [ 0.000000] g0: 0000000000a161a0 g1: 0000000000a2eaf8 g2:
> 0000000000000001 g3: 0000000000000000
> [ 0.000000] g4: 0000000000a14470 g5: 0000000000000000 g6:
> 00000000009fc000 g7: 0000000000000001
> [ 0.000000] o0: 0000000000000000 o1: 0000000000000000 o2:
> 0000000000000000 o3: 0000000000000020
> [ 0.000000] o4: 000000000000000e o5: 0000000000a8f000 sp:
> 00000000009fef31 ret_pc: 00000000004a36f4
> [ 0.000000] RPC: <kstat_incr_irq_this_cpu+0x14/0x60>
> [ 0.000000] l0: 0000000000b30320 l1: 0000000000b0f650 l2:
> 0000000000000001 l3: 0000000000b30448
> [ 0.000000] l4: 0000000000000000 l5: 0000000000b10b18 l6:
> 0000000000b30300 l7: 0000000000000000
> [ 0.000000] i0: 0000000000000000 i1: 0000000000b0f648 i2:
> 0000000000b30310 i3: 000000000000000e
> [ 0.000000] i4: 0000000000b30000 i5: 0000000000b30000 i6:
> 00000000009fefe1 i7: 00000000008aaf58
> [ 0.000000] I7: <timer_interrupt+0x38/0xa0>
> [ 0.000000] Call Trace:
> [ 0.000000] [00000000008aaf58] timer_interrupt+0x38/0xa0
> [ 0.000000] [00000000004209d4] tl0_irq14+0x14/0x20
> [ 0.000000] [00000000004db6c0] touch_softlockup_watchdog+0x0/0x20
> [ 0.000000] [0000000000ab8568] memblock_virt_alloc_try_nid+0x84/0x94
> [ 0.000000] [0000000000ab9754] sparse_init+0x1c/0x224
> [ 0.000000] [0000000000aabcb8] paging_init+0xd80/0xeb0
> [ 0.000000] [0000000000aa7068] setup_arch+0x2d4/0x718
> [ 0.000000] [0000000000aa4668] start_kernel+0x78/0x420
> [ 0.000000] [0000000000aa6d84] start_early_boot+0x1bc/0x1cc
> [ 0.000000] [0000000000897410] tlb_fixup_done+0x4c/0x5c
> [ 0.000000] [0000000000000000] (null)
> [ 0.000000] Disabling lock debugging due to kernel taint
> [ 0.000000] Caller[00000000008aaf58]: timer_interrupt+0x38/0xa0
> [ 0.000000] Caller[00000000004209d4]: tl0_irq14+0x14/0x20
> [ 0.000000] Caller[00000000008984e4]: panic+0x1c8/0x208
> [ 0.000000] Caller[0000000000ab8568]:
> memblock_virt_alloc_try_nid+0x84/0x94
> [ 0.000000] Caller[0000000000ab9754]: sparse_init+0x1c/0x224
> [ 0.000000] Caller[0000000000aabcb8]: paging_init+0xd80/0xeb0
> [ 0.000000] Caller[0000000000aa7068]: setup_arch+0x2d4/0x718
> [ 0.000000] Caller[0000000000aa4668]: start_kernel+0x78/0x420
> [ 0.000000] Caller[0000000000aa6d84]: start_early_boot+0x1bc/0x1cc
> [ 0.000000] Caller[0000000000897410]: tlb_fixup_done+0x4c/0x5c
> [ 0.000000] Caller[0000000000000000]: (null)
> [ 0.000000] Instruction DUMP: 92100018 40076593 901222f8 <c45a2048>
> 030028b1 c6008000 8600e001 c6208000 c4586160
> [ 0.000000] Kernel panic - not syncing: Aiee, killing interrupt handler!
> [ 0.000000] Press Stop-A (L1-A) to return to the boot prom
> [ 0.000000] ---[ end Kernel panic - not syncing: Aiee, killing
> interrupt handler!
>
>
> It looks like the regression has been introduced sometime between
> 4th-8th November:
>
> - Works, boots to the Debian installer
> http://d-i.debian.org/daily-images/sparc/20141104-00:20/mini.iso
>
> - Doesn't work, crashes as above
> http://d-i.debian.org/daily-images/sparc/20141108-00:22/mini.iso
>
> Does any know what has changed that could have caused this regression?
Panic over.
It seems that the latest build has increased the memory requirement
above QEMU's 128MB built-in default. Increasing the RAM to 256MB seems
to get things going again:
$ ./qemu-system-sparc64 -m 256 -cdrom
/home/build/src/qemu/image/sparc64/mini.iso -boot d -nographic
I guess everyone has more RAM in their SPARC hardware these days?
ATB,
Mark.
Reply to: