lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Sat, 27 Jun 2009 18:08:10 -0500
From:	Rob Landley <rob@...dley.net>
To:	linux-kernel@...r.kernel.org, jk@...abs.org,
	benh@...nel.crashing.org
Subject: Can't boot 2.6.30 powerpc kernel under qemu.

The 2.6.29 kernel booted just fine (and 2.6.28, and 2.6.27...), but the 2.6.30 
kernel does this right after openbios hands over control:

  invalid/unsupported opcode: 00 - 12 - 00 (00009024) 0000938c 0

Which is usually qemu's way of saying "code jumped off into la-la land".

I bisected the problem in the linux kernel repository, and wound up here:

60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
commit 60ee031940c1b09c137b617a8829e2f081961fe0
Author: Jeremy Kerr <jk@...abs.org>
Date:   Tue Feb 17 11:44:14 2009 +1100

    powerpc/spufs: Use correct return value for spu_handle_mm_fault
    
    Currently, spu_handle_mm_fault disregards the 'ret' variable and always
    returns -EFAULT on error.
    
    This change refactos spu_handle_mm_fault a little, to return the
    ret variable as appropriate. This allows us to combine the error and
    sucess paths.
    
    Also, remove the #if-0-ed IS_VALID_EA() check, it has never been
    used.
    
    Signed-off-by: Jeremy Kerr <jk@...abs.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>

I'm building the kernel with the attached .config, and booting qemu with:

qemu-system-ppc -M g3beige -nographic -no-reboot -kernel "zImage-powerpc" -hda
  "image-powerpc.sqf" -append "root=/dev/hda rw init=/usr/sbin/init.sh panic=1
  PATH=/usr/bin console=ttyS0"

Here's a simpler qemu invocation so you don't need a root filesystem image to 
test it.  (If you get bootup messages on stdout, it's working, and if you get 
an unsupported opcode message right after openbios hands over control, it's 
not):

qemu-system-ppc -nographic -no-reboot -kernel zImage-powerpc \
  -hda /dev/null -append "panic=1 console=ttyS0"

I'm testing with qemu svn 6657 (which is now qemu git 2d18e637e5ec), which is 
the last version in the repository before some unrelated openbios changes 
started a series of bugs that haven't quite been resolved yet.  You can use 
the v0.10.0 release if you prefer, but you'll have to update the openbios-ppc 
image to the one from svn 6657.

I'm stumped.  Help?

Thanks,

Rob

P.S.  Is there a powerpc list I should have cc:'d this to?  vger.kernel.org 
just has kvm-ppc, no other "ppc" or "power".  Google suggests ozlabs, but 
their mailing lists only see to have cell, which this isn't...
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

View attachment "config-linux" of type "text/plain" (25364 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ