Bug 1349308

Created attachment 1171330 [details]
anaconda.log

Created attachment 1171331 [details]
console.log

Created attachment 1171332 [details]
ifcfg.log

Created attachment 1171333 [details]
ks.cfg

Created attachment 1171335 [details]
program.log

Created attachment 1171336 [details]
storage.log

Created attachment 1171337 [details]
sys.log

This looks like same deadlock as in Bug 1246048, where import and logging lock get taken in reverse order:

  3    Thread 0x3fff1b23910 (LWP 1700) 0x000003fffcffa52e -> AnaStorageThread
  5    Thread 0x3fffcd8e6f0 (LWP 1623) 0x000003fffcffa52e -> kdump spoke

thread 5
 ...
  import com_redhat_kdump.tui.spokes.%s
   com_redhat_kdump/tui/spokes/kdump.py, line 59, in KdumpSpoke ()
    pyanaconda/isys/__init__.py, line 174, in total_memory
     logging/__init__.py, line 1149, in info 
      threading.py, line 173, in acquire, _RLock__owner=4397806532880 (0x3fff1b23910)

thread 3 (AnaStorageThread)
 ...
  blivet/devices/disk.py, line 560, in __init__ 
   blivet/devices/disk.py, line 89, in __init__ (
    blivet/devices/storage.py, line 142, in __init__
     blivet/devices/storage.py, line 651, in updateSize 
      logging/__init__.py, line 464, in format 
       blivet/size.py, line 292, in humanReadable
        blivet/size.py, line 90, in _xlated_prefixes
         blivet/i18n.py, line 26, in <lambda> (x='mega')
          gettext.py, line 540, in ldgettext
           gettext.py, line 467, in translation
            gettext.py, line 131, in _expand_lang 
             PyImport_ImportModuleLevel (name=0x3fffcd11564 "locale"
             _PyImport_AcquireLock ()

Thanks for the backtraces, Jan.

kdump-anaconda-addon added a new call to getMemoryBounds in the class init for KdumpSpoke, which, as discussed in bug 1246048, isn't going to work. If the entry needs to have the memory bounds information, could edit_fields be populated in __init__ instead?

> How reproducible:
> sporadically

My experience so far is 1:20, more so on s390x. Can we expect a fix soon?

(In reply to David Shea from comment #12)
> Thanks for the backtraces, Jan.
> 
> kdump-anaconda-addon added a new call to getMemoryBounds in the class init
> for KdumpSpoke, which, as discussed in bug 1246048, isn't going to work. If
> the entry needs to have the memory bounds information, could edit_fields be
> populated in __init__ instead?

I'm not sure how to move edit_fields to __init__, maybe I can switch to parse /proc/meminfo and get MemTotal instead of using the total_memory provided by pyanaconda..

(In reply to Jan Stancek from comment #13)
> > How reproducible:
> > sporadically
> 
> My experience so far is 1:20, more so on s390x. Can we expect a fix soon?

Jan, I will work on it this week, but not sure it can be a quick fix because I'm traveling during the week.

Thanks
Dave

Created attachment 1172909 [details]
do not use total_mem function from ananconda lib

Jan, could you do a test with the fixed addon here, with extra kernel cmdline:
updates=http://people.redhat.com/ruyang/updates.img

Thanks
Dave

Created attachment 1172910 [details]
do not use total_mem function from ananconda lib

(In reply to Dave Young from comment #17)
> Jan, could you do a test with the fixed addon here, with extra kernel
> cmdline:
> updates=http://people.redhat.com/ruyang/updates.img
> 
> Thanks
> Dave

Seems to work OK, no deadlocks after 30 installs.

Pushed to internal git:
http://git.engineering.redhat.com/git/users/ruyang/kdump-anaconda-addon/.git/commit/?id=69da0f80a37d50433c7627106137eaa00b49bd94

Bao, can you pull and update the addon tarball in kexec-tools?

Qiao, can you provide a qa_ack?

(In reply to Dave Young from comment #21)
> Qiao, can you provide a qa_ack?

set qa_ack+.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2466.html