Bug 490515

Created attachment 335526 [details]
vncserver.log (F-11-Alpha-ppc)

Works in F-11-Alpha-ppc (which uses tightVNC).  Could this be related to tigerVNC server running in anaconda install environment?

After some testing problem is not in Xorg/Xvnc so it must be somewhere in anaconda, I think.

I can reproduce with a ppc mini with today's rawhide.  However it works on the ps3 which is ppc64.

Odd, the system I'm unable to get a display on is an IBM power5 (ppc64).  I'm not able to see miniwm over X, or VNC ... nothing obvious jumps out from the logs so I'm somewhat perplexed on how to proceed.

Tested VNC, X server and text-mode install ... all hang while transitioning to stage#2 anaconda.  I've pasted sysrq-t output at http://fpaste.org/paste/6404 which shows a *ton* of  mv88e6131_switch_driver+0xfea ... not sure what that is..

Still present anaconda version 11.5.0.33

= The Summary =

Unable to proceed to stage#2 anaconda.  Tested stage#2 UI methods include X, text-mode, and VNC.  The screen just sits at a black screen with a cursor (VNC and X).  And nothing happens for text-mode.

For completeness, the mv88e6131_switch_driver is just detritus in the calltrace, accidently chosen because it's likely the nearest symbol. It should probably just be ignored (in fact, it's not a function at all, but a static struct. :) in the traces.

(The mv88e6131 driver is, sadly, boolean so built in everywhere, whether that's sensible is another bug, but none of its codepaths should be involved in what's going on.)

cheers, Kyle

On my ppc mini where I see this, one of the anaconda processes is taking up all the cpu.  Stracing it shows a never ending stream of:

 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 rt_sigaction(SIGSEGV, {0xff33e00, [], 0}, {0xff33e00, [], 0}, 8) = 0

I see the same segfaults while strace'ing anaconda.

# ps aux | grep anaconda 
root      2049 99.7  0.8  67756 31120 hvc0     R    14:22 185:44 /usr/bin/python /usr/bin/anaconda --stage2 http://gromit.redhat.com/pub/fedora/linux/development/ppc/os/images/install.img --serial -T --selinux --virtpconsole /dev/hvc0 --lang en_US.UTF-8 --repo http://gromit.redhat.com/pub/fedora/linux/development/ppc/os

# /tmp/strace -f -p  2049

--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {0xff33e00, [], 0}, {0xff33e00, [], 0}, 8) = 0
sigreturn()                             = ? (mask now [ILL ABRT FPE SEGV ALRM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF IO PWR UNUSED RTMIN])
^C--- SIGSEGV (Segmentation fault) @ 0 (0) ---

Oddly, turning on print-fatal-signals (/proc/sys/kernel/print-fatal-signals) doesn't seem to display anything, but clumens tried gdb which produced this tombstone:

gdb/2248: potentially unexpected fatal signal 11.

NIP: 000000000fab85f8 LR: 000000000fab7e28 CTR: 000000000fabb160
REGS: c0000000e2c13ea0 TRAP: 0300   Not tainted  (2.6.29-0.258.rc8.git2.fc11.ppc64)
MSR: 000000000000f032 <EE,PR,FP,ME,IR,DR>  CR: 44044844  XER: 00000000
DAR: 00000000cccccce0, DSISR: 0000000042000000
TASK = c0000000e288cce0[2248] 'gdb' THREAD: c0000000e2c10000 CPU: 2
GPR00: 00000000cccccccc 00000000ffab44a0 00000000f80004a0 000000000fbe2028 
GPR04: 0000000000000048 0000000000000000 fffffffffefefeff 000000000fbe2250 
GPR08: 0000000000001000 000000000fbe20b0 00000000107e8980 00000000cccccccc 
GPR12: 0000000024044842 00000000104050b8 0000000010400000 0000000000000000 
GPR16: 000000000fbe10a8 000000000fb9a458 000000000000000a 000000000000000a 
GPR20: 0000000000000001 000000000fbe2060 0000000000000003 000000000fbe2058 
GPR24: 0000000067000060 0000000067000010 00000000107e8980 0000000000000048 
GPR28: 000000000fbe201c 0000000000000050 000000000fbe0ff4 000000000fbe2028 
NIP [000000000fab85f8] 0xfab85f8
LR [000000000fab7e28] 0xfab7e28

Running from a shell on the machine in question:

>>> libiscsi.get_firmware_initiator_name()

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: Unknown error
>>> try: 
...     libiscsi.get_firmware_initiator_name()
... except:
...     print "whoops"
... 
Segmentation fault

And yet if you catch just the IOError:

>>> try:
...     libiscsi.get_firmware_initiator_name()
... except IOError:
...     print "whoops"
... 

whoops


And apparently this is not reproducable in userland.

Testing anaconda-11.5.0.34 with http://people.atrpms.net/~hdegoede/updates.img resolves the issue.

*** Bug 491306 has been marked as a duplicate of this bug. ***

This is worked around in iscsi-initiator-utils-6.2.0.870-7.fc11, which is being tagged in to the beta. I'm opening a new bug to track the real issue, as this workaround is supposed to be a temporary solution.

Note the work around is to replace fw_get_entry() calls in libiscsi with fwparam_ibft_sysfs() calls, so that fwparam_ppc() no longer gets called,
fwparam_ppc() evidently causes memory corruption on ppc machines.

This means we loose the capability to automatically discover firmware configured iscsi disks on ppc, but that is way better then not installing :)

The new bug for tracking the fwparam_ppc() issue is bug 491363 .

Latest rawhide boot.iso gets through to the graphical welcome screen, thanks :)

Confirmed fixed as well on IBM power5 ppc64 with 2009-03-23 rawhide.