January 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 915996] New: LibreOffice doesn't show internal Help
by bugzilla_noreply＠novell.com 07 Aug '18

07 Aug '18

http://bugzilla.opensuse.org/show_bug.cgi?id=915996 Bug ID: 915996 Summary: LibreOffice doesn't show internal Help Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: LibreOffice Assignee: bnc-team-ooo(a)forge.provo.novell.com Reporter: lazy.kent(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- LibreOffice v4.4.0.2 doesn't show internal Help. Using locale "ru_RU". Calling Help from the menu "Help" or "F1" key opens a browser with URL https://help.libreoffice.org/scalc/.uno:HelpIndex?Language=ru&System=UNIX&V… (in case of calc) or https://help.libreoffice.org/swriter/.uno:HelpIndex?Language=ru&System=UNIX… (in case of writer). Installed packages: % rpm -qa | grep libreoffice libreoffice-math-4.4.0.2-1.1.x86_64 libreoffice-draw-4.4.0.2-1.1.x86_64 libreoffice-l10n-en-4.4.0.2-1.1.noarch libreoffice-icon-theme-crystal-4.4.0.2-1.1.noarch libreoffice-calc-extensions-4.4.0.2-1.1.x86_64 libreoffice-calc-4.4.0.2-1.1.x86_64 libreoffice-gnome-4.4.0.2-1.1.x86_64 libreoffice-icon-theme-oxygen-4.4.0.2-1.1.noarch libreoffice-writer-4.4.0.2-1.1.x86_64 libreoffice-branding-openSUSE-4.0-5.1.noarch libreoffice-4.4.0.2-1.1.x86_64 libreoffice-impress-4.4.0.2-1.1.x86_64 libreoffice-mailmerge-4.4.0.2-1.1.x86_64 libreoffice-base-4.4.0.2-1.1.x86_64 libreoffice-pyuno-4.4.0.2-1.1.x86_64 libreoffice-templates-ru-3.3-13.1.noarch libreoffice-icon-theme-galaxy-4.4.0.2-1.1.noarch libreoffice-filters-optional-4.4.0.2-1.1.x86_64 libreoffice-writer-extensions-4.4.0.2-1.1.x86_64 libreoffice-l10n-ru-4.4.0.2-1.1.noarch openSUSE Tumbleweed x86_64. And I remember, it was OK in 4.4.0.1. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1011205] New: VUL-0: CVE-2016-4332: hdf5: Shareable Message Type Code Execution Vulnerability
by bugzilla_noreply＠novell.com 06 Aug '18

06 Aug '18

http://bugzilla.suse.com/show_bug.cgi?id=1011205 Bug ID: 1011205 Summary: VUL-0: CVE-2016-4332: hdf5: Shareable Message Type Code Execution Vulnerability Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: dmitry(a)roshchin.org Reporter: abergmann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Security Response Team Blocker: --- CVE-2016-4332 The library's failure to check if certain message types support a particular flag, the HDF5 1.8.16 library will cast the structure to an alternative structure and then assign to fields that aren't supported by the message type and the library will write outside the bounds of the heap buffer. This can lead to code execution under the context of the library. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4332 http://www.cvedetails.com/cve/CVE-2016-4332/ http://www.talosintelligence.com/reports/TALOS-2016-0178/ -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 953297] New: grub2-xen.rpm should be noarch
by bugzilla_noreply＠novell.com 06 Aug '18

06 Aug '18

http://bugzilla.suse.com/show_bug.cgi?id=953297 Bug ID: 953297 Summary: grub2-xen.rpm should be noarch Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- grub2 contains pvgrub for Xen PV guests. The subpackage should be noarch because the resulting single binary runs only in guest context. It is firmware. It would be nice of there would be two subpackages: grub2-x86_64-xen.noarch.rpm and grub2-i386-xen.noarch.rpm, this would allow to both 32bit and 64bit PV guests. I think right now the 64bit pvgrub can not boot 32bit PV and via versa. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 994769] New: no usable gpus found issue of BOINC
by bugzilla_noreply＠novell.com 31 Jul '18

31 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=994769 Bug ID: 994769 Summary: no usable gpus found issue of BOINC Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mustafaxfe(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, I have started to use OpenSUSE Leap 42.1 approximately one mount. I have been supporting BOINC at least 1 years. I have installed BOINC unstable (7.6.32) from OpenSUSE software page ( 1 Click Install page). I gave these commands before running BOINC(I found these commands from: https://forums.opensuse.org/showthread.php/518018-Running-BOINC) : 1. systemctl start boinc-client.service 2. /usr/sbin/usermod -G boinc -a username 3. chmod g+rw /var/lib/boinc 4. chmod g+rw /var/lib/boinc/*.* 5. ln -s /var/lib/boinc/gui_rpc_auth.cfg /home/username/gui_rpc_auth.cfg Finally log out and log in and it takes effect But When I check Event Log from boinc-manager ( Tools -> Event Log or simply shift-ctrl-e ) It says " no usable gpus found ". I have installed Amd firepro drivers and also AMD APP Opencl sdk. But Boinc gives this issue. I searched internet and found a solution. "xhost +si:localuser:boinc" after giving this command you need to restart boinc: "systemctl restart boinc-client.service" And BOINC founds my gpu and runs opencl apps. But I am giving every time this command (xhost +si:localuser:boinc) after log in. Where should I add this command to boot with. Also I want to enable boinc-client.service not starting by hand. So (xhost +si:localuser:boinc) should call before starting boinc service (systemctl start boinc-client.service) -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 800701] New: X windows is corrupt after logging in on an AMD A10-5800K APU
by bugzilla_noreply＠novell.com 31 Jul '18

31 Jul '18

https://bugzilla.novell.com/show_bug.cgi?id=800701 https://bugzilla.novell.com/show_bug.cgi?id=800701#c0 Summary: X windows is corrupt after logging in on an AMD A10-5800K APU Classification: openSUSE Product: openSUSE Factory Version: 12.3 Beta 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Xen AssignedTo: jdouglas(a)suse.com ReportedBy: ajbiii(a)comcast.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Installed 12.3. The regular kernel and X windows works fine. Reboot to the xen kernel. The login screen is displayed correctly. After logging in, the display is corrupt. The mouse pointer is ok and I can see that the menu is active by putting the cursor in the lower left corner and clicking but the display is unusable. Just an aside: The xen kernel wouldn't even boot on the APU with 12.1 or 12.2. Reproducible: Always Steps to Reproduce: 1. Install 12.3 on an AMD Trinity APU. 2. Boot regular kernel, log in and verify X is working. 3. Reboot with the xen kernel. 4. Log in and observe the corruption Actual Results: Screen is corrupt Expected Results: Normal X windows operation -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 23

[Bug 902352] New: snapperd crashed shortly after boot
by bugzilla_noreply＠novell.com 29 Jul '18

29 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=902352 Bug ID: 902352 Summary: snapperd crashed shortly after boot Classification: openSUSE Product: openSUSE Factory Version: NO 13.2 BUGS!! Hardware: i686 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: aschnell(a)suse.com Reporter: mpluskal(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After reboot of recent opensuse factory, I have noticed that snapperd crashed (for no apparent reason): # systemd-coredumpctl gdb 3614 TIME PID UID GID SIG EXE Tue 2014-10-21 22:11:37 CEST 3614 0 0 6 /usr/sbin/snapperd GNU gdb (GDB; openSUSE Factory) 7.8 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... warning: /etc/gdbinit.d/gdb-heap.py: No such file or directory Reading symbols from /usr/sbin/snapperd...Reading symbols from /usr/lib/debug/usr/sbin/snapperd.debug...done. done. [New LWP 3614] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `/usr/sbin/snapperd'. Program terminated with signal SIGABRT, Aborted. #0 0xb77bae60 in __kernel_vsyscall () (gdb) bt full #0 0xb77bae60 in __kernel_vsyscall () No symbol table info available. #1 0xb73f2437 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = <optimized out> resultvar = <optimized out> pid = -1219051520 selftid = 3614 #2 0xb73f3b8e in __GI_abort () at abort.c:78 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x83fd424, sa_sigaction = 0x83fd424}, sa_mask = {__val = {64, 3074638989, 3075918176, 3078479804, 3077059232, 5, 3220034192, 3078403714, 3077059672, 3070747136, 1, 5, 0, 3075915776, 3075918176, 3075922024, 3220034164, 3076988956, 3076153812, 3076093316, 138392728, 3075915776, 3075918176, 3074203892, 3075918176, 3074619692, 3076988928, 3076988928, 3075919228, 138400804, 138399352, 3078429072}}, sa_flags = 138392632, sa_restorer = 0xb73f3a80 <__GI_abort>} sigs = {__val = {32, 0 <repeats 31 times>}} #3 0xb75ddfe5 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 terminating = true t = <optimized out> #4 0xb75dbc53 in __cxxabiv1::__terminate (handler=0xb75dde50 <__gnu_cxx::__verbose_terminate_handler()>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38 No locals. #5 0xb75dab75 in __cxa_call_terminate (ue_header=0x83fb468) at ../../../../libstdc++-v3/libsupc++/eh_call.cc:54 No locals. #6 0xb75db791 in __cxxabiv1::__gxx_personality_v0 (version=1, actions=6, exception_class=5138137972254386944, ue_header=0x83fb468, context=0xbfedd550) at ../../../../libstdc++-v3/libsupc++/eh_personality.cc:670 action_record = <optimized out> p = <optimized out> thrown_ptr = 0x0 info = {Start = 3078108587, LPStart = 0, ttype_base = 0, TType = 0x0, action_table = 0xfffffffc <error: Cannot access memory at address 0xfffffffc>, ttype_encoding = 0 '\000', call_site_encoding = 192 '\300'} landing_pad = <optimized out> ip = <optimized out> handler_switch_value = 0 foreign_exception = false found_type = <optimized out> language_specific_data = 0xb779200c "\377\233\021\001\005>\005\342\001\003" ip_before_insn = 0 #7 0xb758506c in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x83fb468, context=context@entry=0xbfedd550) at ../../../libgcc/unwind.inc:62 fs = {regs = {reg = {{loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = { reg = 4294967276, offset = -20, exp = 0xffffffec <error: Cannot access memory at address 0xffffffec>}, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = { reg = 4294967288, offset = -8, exp = 0xfffffff8 <error: Cannot access memory at address 0xfffffff8>}, how = REG_SAVED_OFFSET}, {loc = {reg = 4294967280, offset = -16, exp = 0xfffffff0 <error: Cannot access memory at address 0xfffffff0>}, how = REG_SAVED_OFFSET}, {loc = {reg = 4294967284, offset = -12, exp = 0xfffffff4 <error: Cannot access memory at address 0xfffffff4>}, how = REG_SAVED_OFFSET}, {loc = {reg = 4294967292, offset = -4, exp = 0xfffffffc <error: Cannot access memory at address 0xfffffffc>}, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = { reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}, {loc = {reg = 0, offset = 0, exp = 0x0}, how = REG_UNSAVED}}, prev = 0x0, cfa_offset = 64, cfa_reg = 4, cfa_exp = 0x0, cfa_how = CFA_REG_OFFSET}, pc = 0xb772a690 <snapper::Snapper::~Snapper()+144>, personality = 0x8053950 <__gxx_personality_v0@plt>, data_align = -4, code_align = 1, retaddr_column = 8, fde_encoding = 27 '\033', lsda_encoding = 27 '\033', saw_z = 1 '\001', signal_frame = 0 '\000', eh_ptr = 0x0} match_handler = 4 code = _URC_NO_REASON #8 0xb75855ad in _Unwind_Resume (exc=exc@entry=0x83fb468) at ../../../libgcc/unwind.inc:230 this_context = {reg = {0xbfedd5d4, 0x0, 0xbfedd5d8, 0xbfedd5dc, 0x0, 0xbfedd5e8, 0xbfedd5e0, 0xbfedd5e4, 0xbfedd5ec, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, cfa = 0xbfedd5f0, ra = 0xb774b85f <snapper::logStreamClose(snapper::LogLevel, char const*, unsigned int, char const*, std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >*)+431>, lsda = 0x0, bases = { tbase = 0x0, dbase = 0xb758c000, func = 0xb7585550 <_Unwind_Resume>}, flags = 1073741824, version = 0, args_size = 0, by_value = '\000' <repeats 17 times>} cur_context = {reg = {0xbfedd5d4, 0x0, 0xbfedd5d8, 0xbfedd62c, 0x0, 0xbfedd638, 0xbfedd630, 0xbfedd634, 0xbfedd63c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, cfa = 0xbfedd640, ra = 0xb772a6dd <snapper::Snapper::~Snapper()+221>, lsda = 0xb779200c, bases = {tbase = 0x0, dbase = 0xb779b000, func = 0xb772a600 <snapper::Snapper::~Snapper()>}, flags = 1073741824, version = 0, args_size = 0, by_value = '\000' <repeats 17 times>} code = <optimized out> #9 0xb774b85f in ~basic_string (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/basic_string.h:539 No locals. #10 snapper::logStreamClose (level=level@entry=snapper::MILESTONE, file=file@entry=0xb777ade3 "Snapper.cc", line=line@entry=112, func=func@entry=0xb777b348 <snapper::Snapper::~Snapper()::__FUNCTION__> "~Snapper", stream=stream@entry=0x83fca40) at Log.cc:64 No locals. #11 0xb772a6dd in snapper::Snapper::~Snapper (this=0xb67007f0, __in_chrg=<optimized out>) at Snapper.cc:112 __buf = 0x83fca40 ---Type <return> to continue, or q <return> to quit--- #12 0x08063118 in MetaSnapper::~MetaSnapper (this=0x83fd498, __in_chrg=<optimized out>) at MetaSnapper.cc:117 No locals. #13 0x08063197 in ~_List_node (this=0x83fd490, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_list.h:106 No locals. #14 destroy<std::_List_node<MetaSnapper> > (this=<optimized out>, __p=0x83fd490) at /usr/include/c++/4.8/ext/new_allocator.h:124 No locals. #15 _M_clear (this=0x80788e8 <meta_snappers>) at /usr/include/c++/4.8/bits/list.tcc:75 __tmp = 0x83fd490 __cur = 0x80788e8 <meta_snappers> #16 ~_List_base (this=0x80788e8 <meta_snappers>, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_list.h:378 No locals. #17 ~list (this=0x80788e8 <meta_snappers>, __in_chrg=<optimized out>) at /usr/include/c++/4.8/bits/stl_list.h:438 No locals. #18 MetaSnappers::~MetaSnappers (this=0x80788e8 <meta_snappers>, __in_chrg=<optimized out>) at MetaSnapper.cc:196 No locals. #19 0xb73f52f1 in __run_exit_handlers (status=status@entry=0, listp=0xb756c3c4 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82 atfct = <optimized out> onfct = <optimized out> cxafct = <optimized out> f = <optimized out> #20 0xb73f534d in __GI_exit (status=0) at exit.c:104 No locals. #21 0xb73dd99b in __libc_start_main (main=0x8053ca0 <main(int, char**)>, argc=1, argv=0xbfedd7a4, init=0x8069a10 <__libc_csu_init>, fini=0x8069a80 <__libc_csu_fini>, rtld_fini=0xb77cc660 <_dl_fini>, stack_end=0xbfedd79c) at libc-start.c:319 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1219051520, 0, 0, 0, -2067208107, 617901124}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x805462f <_start>}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1}}} not_first_call = <optimized out> #22 0x08054650 in _start () at ../sysdeps/i386/start.S:115 No locals. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 879402] New: date format of atq is unusable for sorting
by bugzilla_noreply＠novell.com 29 Jul '18

29 Jul '18

https://bugzilla.novell.com/show_bug.cgi?id=879402 https://bugzilla.novell.com/show_bug.cgi?id=879402#c0 Summary: date format of atq is unusable for sorting Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: martin(a)oneiros.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 The atq in 13.1 uses a date/time format that is unsuitable for sorting by date/time and there is no way to set the date format used (e.g. to ISO8601). Reproducible: Always Steps to Reproduce: 1. Set up some jobs with at 2. Run atq Actual Results: > atq 1377 Thu May 29 15:04:00 2014 a ms 1387 Thu May 22 21:59:00 2014 a ms 1376 Thu May 29 18:39:00 2014 a ms 1372 Wed May 28 21:32:00 2014 a ms 1 Fri May 23 21:04:00 2014 a ms 1361 Sun May 25 08:04:00 2014 a ms 1373 Thu May 29 09:29:00 2014 a ms 1367 Tue May 27 20:02:00 2014 a ms 4 Fri May 23 22:03:00 2014 a ms 1369 Wed May 28 21:04:00 2014 a ms 7 Sat May 24 19:04:00 2014 a ms 10 Sat May 24 23:03:00 2014 a ms Expected Results: The date format should be ISO 8601 - or there should be a switch to set the date format used. The atq up to 12.3 used ISO 8601, so this is a regression. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612075 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 13

[Bug 987158] New: Konqueror results positive to POODLE vulnerability in Leap 42.1
by bugzilla_noreply＠novell.com 29 Jul '18

29 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=987158 Bug ID: 987158 Summary: Konqueror results positive to POODLE vulnerability in Leap 42.1 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Critical Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: stakanov(a)freenet.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Go to https://www.ssllabs.com/ssltest/viewMyClient.html Run he testcase for Konqueror. It results positive to the POODLE vulnerability (SSL3). I do not think that this is acceptable for a browser that, even if used little by users to go on the net is by default vulnerable. Second and for me more important: is this system wide? If it is, it may also cause a problem to startTLS in Kmail I guess, since AFAIK Kmail follows the overall system wide settings. Still, a browser delivered in a OS today should not present any more the POODLE problematic. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 984047] New: BUG: unable to handle kernel NULL pointer dereference at (null)
by bugzilla_noreply＠novell.com 27 Jul '18

27 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=984047 Bug ID: 984047 Summary: BUG: unable to handle kernel NULL pointer dereference at (null) Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: vanjab(a)icetec.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On the latest Leap(4.1.21-14-xen) running Xen kernel we get deadlocks when switching console (either by Ctl-Alt-F1, or by logging out in graphical session). Reproduce by: a) start with xen kernel b) once up and showing login screen try to switch to textual console via Ctl-Alt-Fn c) or graphically login and then log out (logout seems to trigger console switch) Locked processes (and the whole GUI and eventually the server): /sbin/agetty /sbin/showconsole Kernel has an error in the log: Jun 08 14:46:29 az-waltham-push kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jun 08 14:46:29 az-waltham-push kernel: IP: [< (null)>] (null) Jun 08 14:46:29 az-waltham-push kernel: PGD ec58e067 PUD f8839067 PMD 0 Jun 08 14:46:29 az-waltham-push kernel: Oops: 0010 [#1] SMP Jun 08 14:46:29 az-waltham-push kernel: Modules linked in: bnep bluetooth rfkill tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables af_packet bridge stp llc iscsi_ibft iscsi_boot_sysfs xfs libcrc32c blktap blktap2 ipmi_ssif pciback coretemp crc Jun 08 14:46:29 az-waltham-push kernel: crc32c_intel ttm xhci_pci ehci_pci ehci_hcd xhci_hcd drm i2c_core usbcore usb_common sg Jun 08 14:46:29 az-waltham-push kernel: CPU: 6 PID: 1749 Comm: X Not tainted 4.1.21-14-xen #1 Jun 08 14:46:29 az-waltham-push kernel: Hardware name: Silicon Mechanics Rackform iServ R135.v5.1/X10SLM+-LN4F, BIOS 3.0 04/24/2015 Jun 08 14:46:29 az-waltham-push kernel: task: ffff8801d6f5a3d0 ti: ffff8801cdb7c000 task.ti: ffff8801cdb7c000 Jun 08 14:46:29 az-waltham-push kernel: RIP: e030:[<0000000000000000>] [< (null)>] (null) Jun 08 14:46:29 az-waltham-push kernel: RSP: e02b:ffff8801cdb7f3d0 EFLAGS: 00010206 Jun 08 14:46:29 az-waltham-push kernel: RAX: 4000000001000000 RBX: ffff8801e97d39c0 RCX: 0000000000000002 Jun 08 14:46:29 az-waltham-push kernel: RDX: 4000000001000000 RSI: 0000000000000000 RDI: ffff8801e97d39c0 Jun 08 14:46:29 az-waltham-push kernel: RBP: ffff8801e58d1000 R08: 00000000000f6fff R09: 000000000000003c Jun 08 14:46:29 az-waltham-push kernel: R10: 0000000000007ff0 R11: ffffffffa00891b9 R12: ffff8801e97d39c0 Jun 08 14:46:29 az-waltham-push kernel: R13: 0000000000000000 R14: 00000000000007e9 R15: 0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: FS: 00007f70bba028c0(0000) GS:ffff8801e4780000(0000) knlGS:0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 08 14:46:29 az-waltham-push kernel: CR2: 0000000000000000 CR3: 00000001cc57d000 CR4: 0000000000042660 Jun 08 14:46:29 az-waltham-push kernel: Stack: Jun 08 14:46:29 az-waltham-push kernel: ffffffff8013c1ed 0000000000000001 ffffffff8004eeb9 00000000f6005000 Jun 08 14:46:29 az-waltham-push kernel: ffffc90001800000 00000000f67ee000 ffff8801e97d39c0 ffff8801e58d1000 Jun 08 14:46:29 az-waltham-push kernel: 0000000000000000 4000000001000000 00000000000007e9 0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: Call Trace: Jun 08 14:46:29 az-waltham-push kernel: Inexact backtrace: Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8013c1ed>] ? free_pages_prepare+0x1dd/0x2d0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8004eeb9>] ? iomem_map_sanity_check+0x89/0xd0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8013d176>] ? free_hot_cold_page+0x26/0x1a0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa008cbd2>] ? ttm_put_pages+0x152/0x1c0 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0084384>] ? ttm_mem_global_free_zone+0x24/0x80 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa008cc99>] ? ttm_pool_unpopulate+0x59/0x70 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00851ed>] ? ttm_tt_destroy+0x5d/0x70 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00898c1>] ? ttm_bo_move_memcpy+0x361/0x630 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8001377e>] ? __switch_to+0x22e/0x940 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801718ad>] ? free_vmap_area_noflush+0x2d/0x60 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0086f86>] ? ttm_bo_handle_move_mem+0x256/0x5b0 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0087a11>] ? ttm_bo_mem_space+0x181/0x350 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00880c8>] ? ttm_bo_validate+0x1e8/0x200 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa01214ca>] ? ast_bo_pin+0x7a/0xa0 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa011f077>] ? ast_crtc_do_set_base.isra.14.constprop.24+0xe7/0x390 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa011d2b5>] ? ast_set_index_reg_mask+0x45/0x70 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa011feac>] ? ast_crtc_mode_set+0xb8c/0xc90 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00e08fb>] ? drm_crtc_helper_set_mode+0x2eb/0x520 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00e197b>] ? drm_crtc_helper_set_config+0x8bb/0xae0 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa01476d8>] ? drm_mode_set_config_internal+0x68/0x100 [drm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00ec280>] ? restore_fbdev_mode+0xc0/0xe0 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00ee130>] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x60 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00ee192>] ? drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80386d2e>] ? fb_set_var+0x15e/0x3b0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0291de5>] ? btrfs_buffer_uptodate+0x55/0x80 [btrfs] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa02b0fe7>] ? btrfs_get_token_32+0x57/0xf0 [btrfs] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8037e10b>] ? fbcon_blank+0x1cb/0x2b0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff803fac05>] ? do_unblank_screen+0xa5/0x1c0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff803f1414>] ? vt_ioctl+0x584/0x10f0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8003cdcc>] ? ptep_set_access_flags+0x4c/0x80 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80161ef5>] ? do_wp_page+0x235/0x650 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff803e4647>] ? tty_ioctl+0x207/0xd30 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801644b5>] ? handle_mm_fault+0xdc5/0x1920 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801a41df>] ? do_vfs_ioctl+0x2ff/0x520 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8031af99>] ? lockref_put_or_lock+0x9/0x50 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801a870e>] ? dput+0x10e/0x220 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff800e10cc>] ? __audit_syscall_entry+0xac/0xf0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80022bfb>] ? syscall_trace_enter_phase1+0xfb/0x160 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801a4481>] ? SyS_ioctl+0x81/0xa0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80064f7c>] ? task_work_run+0xac/0xe0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff805f205d>] ? system_call_fastpath+0x16/0x76 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff805f2010>] ? __entry_text_start+0x8/0x8 Jun 08 14:46:29 az-waltham-push kernel: Code: Bad RIP value. Jun 08 14:46:29 az-waltham-push kernel: RIP [< (null)>] (null) Jun 08 14:46:29 az-waltham-push kernel: RSP <ffff8801cdb7f3d0> Jun 08 14:46:29 az-waltham-push kernel: CR2: 0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: ---[ end trace dddd722ac706bdd1 ]--- Hardware: - as you can see from the log above, it is a plain Silicon Mechanics server with supermicro X10SLM+-LN4F motherboard (ASpeed VGA controller) Tried on multiple servers in case hardware was to blame, but it always locked just the same. I can provide more info if needed. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1021353] New: ocserv randomly misbuilds man pages
by bugzilla_noreply＠novell.com 24 Jul '18

24 Jul '18

http://bugzilla.opensuse.org/show_bug.cgi?id=1021353 Bug ID: 1021353 Summary: ocserv randomly misbuilds man pages Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE 42.2 Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: i(a)marguerite.su Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- when building the ocserv package on a multi-core machine it randomly misbuilds man pages ocpasswd.8 ocserv.8 occtl.8 where one of them contains content that should have been in another The problem goes away when changing -make V=1 %{?_smp_mflags} +make V=1 so there is probably some race condition where the concurrently running man-page generators creates a single temp file -- You are receiving this mail because: You are on the CC list for the bug.

1 13