June 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 882523] New: devel:languages:python3/python3-pep8: Bug
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=882523 https://bugzilla.novell.com/show_bug.cgi?id=882523#c0 Summary: devel:languages:python3/python3-pep8: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: P5 - None Component: 3rd party software AssignedTo: speilicke(a)suse.com ReportedBy: kj0bugs(a)gmail.com QAContact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- The pep8-python3 utility requires the presence of python3-setuptools at run time, but the package spec flags it as a build dependency only. -- 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 0

[Bug 791288] New: curl only transfers 146Mb via sftp
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=791288 https://bugzilla.novell.com/show_bug.cgi?id=791288#c0 Summary: curl only transfers 146Mb via sftp Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86 OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: dogctba2(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 curl only transfer 146Mb while uploading a file via sftp. curl --version curl 7.25.0 (i586-suse-linux-gnu) libcurl/7.25.0 OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 libssh2/1.4.0 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP Reproducible: Always Steps to Reproduce: 1. create a file with ~160Mb: dd if=/dev/zero of=file bs=1024 count=160000 2. try to transfer via sftp: curl -k -T file -u root:pass sftp://localhost Actual Results: the file size is 160Mb but curl only transfers 146Mb, and stops, the connection is still stablished. Expected Results: expected full transfer of that file other details here: http://forums.opensuse.org/english/get-technical-help-here/applications/480… -- 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 6

[Bug 596037] New: Issue warning if repo is signed with an expired key
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

http://bugzilla.novell.com/show_bug.cgi?id=596037 http://bugzilla.novell.com/show_bug.cgi?id=596037#c0 Summary: Issue warning if repo is signed with an expired key Classification: openSUSE Product: openSUSE 11.3 Version: Milestone 4 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: ma(a)novell.com QAContact: qa(a)suse.de Found By: Community User Blocker: --- ---[opensuse] zypper: really no check for expiration of gpg keys?--- Meta data in OBS repo-md repositories (i.e., repomd. is usually signed with gpg. It seems that zypper does not check expiration of used gpg keys. (zypper 1.0.13 on openSUSE 11.1, in case that matters.) As an example: http://download.opensuse.org/repositories/Apache:/MirrorBrain/Apache_openSU… has a key that expired at April 1, 2010; i.e., 12 days ago. (The key has ID 0xBD6D129A and fingerprint EDDD C98D 96A0 F889 9AB0 7C78 9584 A164 BD6D 129A.) I would have expected a warning or an error when this repository is refreshed, but nothing as such happens. --- -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 4

[Bug 882480] New: apply reiser3 patches 00-29 sourced from http://www.spinics.net/lists/reiserfs-devel/msg03814.html
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=882480 https://bugzilla.novell.com/show_bug.cgi?id=882480#c0 Summary: apply reiser3 patches 00-29 sourced from http://www.spinics.net/lists/reiserfs-devel/msg03814.h tml Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: doiggl(a)velocitynet.com.au 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 SeaMonkey/2.26 Hello, Apply reiser3 patches 00-29. Patches Attached is patches.rpmify.tar.bz2 taken from: https://build.opensuse.org/package/show/Kernel:stable/kernel-vanilla with reiser3 patches 00-29 included The following reiser3 patches 00-29 included in directory /patches.rpmify/ Sourced from http://www.spinics.net/lists/reiserfs-devel/msg03814.html and its responses. How patch was constructed see [1] My understanding is the patches can be applied via the series.conf patch details [2] Question: can these r3 patches be used in a future release ? Cheers Glenn # patch size -old patches.rpmify.tar.bz2 3.31 KB -new patches.rpmify.tar.bz2 155 KB [1] [lines may hav wrapped] # cat p cd / rm -rf patches.rpmify mkdir patches.rpmify cp -v patches.rpmify.tar.bz2.original patches.rpmify.tar.bz2 bunzip2 -v patches.rpmify.tar.bz2 tar -xvf patches.rpmify.tar cp -v /r3patches/*h patches.rpmify/. rm patches.rpmify.tar tar -cvf patches.rpmify.tar patches.rpmify/* bzip2 -v patches.rpmify.tar ls -la patches.rpmify.tar.bz2 # ./p ‘patches.rpmify.tar.bz2.original’ -> ‘patches.rpmify.tar.bz2’ patches.rpmify.tar.bz2: done patches.rpmify/chipidea-clean-up-dependencies patches.rpmify/cloneconfig.diff patches.rpmify/firmware-path patches.rpmify/lustre-lloop-dont-change-logical-size patches.rpmify/rpm-kernel-config patches.rpmify/s390-add-slab-h-for-kzalloc-kfree patches.rpmify/split-package ‘/r3patches/01-29.patch’ -> ‘patches.rpmify/./01-29.patch’ ‘/r3patches/02-29.patch’ -> ‘patches.rpmify/./02-29.patch’ ‘/r3patches/03-29.patch’ -> ‘patches.rpmify/./03-29.patch’ ‘/r3patches/04-29.patch’ -> ‘patches.rpmify/./04-29.patch’ ‘/r3patches/05-29.patch’ -> ‘patches.rpmify/./05-29.patch’ ‘/r3patches/06-29.patch’ -> ‘patches.rpmify/./06-29.patch’ ‘/r3patches/07-29.patch’ -> ‘patches.rpmify/./07-29.patch’ ‘/r3patches/08-29.patch’ -> ‘patches.rpmify/./08-29.patch’ ‘/r3patches/09-29.patch’ -> ‘patches.rpmify/./09-29.patch’ ‘/r3patches/10-29.patch’ -> ‘patches.rpmify/./10-29.patch’ ‘/r3patches/11-29.patch’ -> ‘patches.rpmify/./11-29.patch’ ‘/r3patches/12-29.patch’ -> ‘patches.rpmify/./12-29.patch’ ‘/r3patches/13-29.patch’ -> ‘patches.rpmify/./13-29.patch’ ‘/r3patches/14-29.patch’ -> ‘patches.rpmify/./14-29.patch’ ‘/r3patches/15-29.patch’ -> ‘patches.rpmify/./15-29.patch’ ‘/r3patches/16-29.patch’ -> ‘patches.rpmify/./16-29.patch’ ‘/r3patches/17-29.patch’ -> ‘patches.rpmify/./17-29.patch’ ‘/r3patches/18-29.patch’ -> ‘patches.rpmify/./18-29.patch’ ‘/r3patches/19-29.patch’ -> ‘patches.rpmify/./19-29.patch’ ‘/r3patches/20-29.patch’ -> ‘patches.rpmify/./20-29.patch’ ‘/r3patches/21-29.patch’ -> ‘patches.rpmify/./21-29.patch’ ‘/r3patches/22-29.patch’ -> ‘patches.rpmify/./22-29.patch’ ‘/r3patches/23-29.patch’ -> ‘patches.rpmify/./23-29.patch’ ‘/r3patches/24-29.patch’ -> ‘patches.rpmify/./24-29.patch’ ‘/r3patches/25-29.patch’ -> ‘patches.rpmify/./25-29.patch’ ‘/r3patches/26-29.patch’ -> ‘patches.rpmify/./26-29.patch’ ‘/r3patches/27-29.patch’ -> ‘patches.rpmify/./27-29.patch’ ‘/r3patches/28-29.patch’ -> ‘patches.rpmify/./28-29.patch’ ‘/r3patches/29-29.patch’ -> ‘patches.rpmify/./29-29.patch’ patches.rpmify/01-29.patch patches.rpmify/02-29.patch patches.rpmify/03-29.patch patches.rpmify/04-29.patch patches.rpmify/05-29.patch patches.rpmify/06-29.patch patches.rpmify/07-29.patch patches.rpmify/08-29.patch patches.rpmify/09-29.patch patches.rpmify/10-29.patch patches.rpmify/11-29.patch patches.rpmify/12-29.patch patches.rpmify/13-29.patch patches.rpmify/14-29.patch patches.rpmify/15-29.patch patches.rpmify/16-29.patch patches.rpmify/17-29.patch patches.rpmify/18-29.patch patches.rpmify/19-29.patch patches.rpmify/20-29.patch patches.rpmify/21-29.patch patches.rpmify/22-29.patch patches.rpmify/23-29.patch patches.rpmify/24-29.patch patches.rpmify/25-29.patch patches.rpmify/26-29.patch patches.rpmify/27-29.patch patches.rpmify/28-29.patch patches.rpmify/29-29.patch patches.rpmify/chipidea-clean-up-dependencies patches.rpmify/cloneconfig.diff patches.rpmify/firmware-path patches.rpmify/lustre-lloop-dont-change-logical-size patches.rpmify/rpm-kernel-config patches.rpmify/s390-add-slab-h-for-kzalloc-kfree patches.rpmify/split-package patches.rpmify.tar: 6.244:1, 1.281 bits/byte, 83.98% saved, 993280 in, 159086 out. -rw-r--r-- 1 root root 159086 Jun 12 21:47 patches.rpmify.tar.bz2 [2]patch details # cat *h | grep -i "\#\[patch" | sort #[patch 01/29] reiserfs: use per-fs commit workqueues #[patch 02/29] reiserfs: cleanup, rename key and item accessors to more friendly names. #[patch 03/29 repost] reiserfs: cleanup, reformat comments to normal kernel style #[patch 04/29] reiserfs: cleanup, remove nblocks argument from journal_end #[patch 05/29] reiserfs: cleanup, remove sb argument from journal_end #[patch 06/29] reiserfs: cleanup, remove sb argument from journal_mark_dirty #[patch 07/29] reiserfs: cleanup, remove blocks arg from journal_join #[patch 08/29] reiserfs: cleanup, remove leading whitespace from labels #[patch 09/29] reiserfs: cleanup, remove unnecessary parens #[patch 10/29] reiserfs: cleanup, remove unnecessary parens in dirent creation #[patch 11/29] reiserfs: cleanup, make hash detection saner #[patch 12/29] reiserfs: balance_leaf refactor, reformat balance_leaf comments #[patch 13/29] reiserfs: balance_leaf refactor, move state variables into tree_balance #[patch 14/29] reiserfs: balance_leaf refactor, pull out balance_leaf_insert_left #[patch 16/29] reiserfs: balance_leaf refactor, pull out balance_leaf_insert_right #[patch 17/29] reiserfs: balance_leaf refactor, pull out balance_leaf_paste_right #[patch 18/29] reiserfs: balance_leaf refactor, pull out balance_leaf_new_nodes_insert #[patch 21/29] reiserfs: balance_leaf refactor, pull out balance_leaf_finish_node_paste #[patch 22/29] reiserfs: balance_leaf refactor, pull out balance_leaf{left, right, new_nodes, finish_node #[patch 23/29] reiserfs: balance_leaf refactor, format balance_leaf_insert_left #[patch 24/29] reiserfs: balance_leaf refactor, format balance_leaf_paste_left #[patch 25/29] reiserfs: balance_leaf refactor, format balance_leaf_insert_right #[patch 26/29] reiserfs: balance_leaf refactor, format balance_leaf_paste_right #[patch 28/29] reiserfs: balance_leaf refactor, format balance_leaf_finish_node Reproducible: Always Steps to Reproduce: Apply reiser3 patches 00-29. patches in patches.rpmify.tar.bz2 /patches.rpmify/ directory listing as follows: patches.rpmify/01-29.patch patches.rpmify/02-29.patch patches.rpmify/03-29.patch patches.rpmify/04-29.patch patches.rpmify/05-29.patch patches.rpmify/06-29.patch patches.rpmify/07-29.patch patches.rpmify/08-29.patch patches.rpmify/09-29.patch patches.rpmify/10-29.patch patches.rpmify/11-29.patch patches.rpmify/12-29.patch patches.rpmify/13-29.patch patches.rpmify/14-29.patch patches.rpmify/15-29.patch patches.rpmify/16-29.patch patches.rpmify/17-29.patch patches.rpmify/18-29.patch patches.rpmify/19-29.patch patches.rpmify/20-29.patch patches.rpmify/21-29.patch patches.rpmify/22-29.patch patches.rpmify/23-29.patch patches.rpmify/24-29.patch patches.rpmify/25-29.patch patches.rpmify/26-29.patch patches.rpmify/27-29.patch patches.rpmify/28-29.patch patches.rpmify/29-29.patch Expected Results: patches apply -- 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 2

[Bug 882430] New: "great" perftools (formerly google-perftools) causes ceph to segfault on SLE11 SP3
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=882430 https://bugzilla.novell.com/show_bug.cgi?id=882430#c0 Summary: "great" perftools (formerly google-perftools) causes ceph to segfault on SLE11 SP3 Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: x86-64 OS/Version: SLES 11 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: osynge(a)suse.com QAContact: qa-bugs(a)suse.de Found By: Development Blocker: No Dear all, This bug is created from: https://bugzilla.novell.com/show_bug.cgi?id=880676 The issue does not occur if gperftools is on newer operating systems. The issue is believed to only occur on 64 bit. If you link ceph to tcmalloc the system will segfault on SLE11sp3. If you do not link ceph to gperftools tcmalloc implementation ceph-mon does not crash on SLE11sp3. This issue does not occur on later versions of SUSE eg open SUSE 13.1. Best regards Owen Example crash: During restart ceph instance d52-54-00-d2-b7-c7:~ # rcceph restart === mon.d52-54-00-d2-b7-c7 === === mon.d52-54-00-d2-b7-c7 === Stopping Ceph mon.d52-54-00-d2-b7-c7 on d52-54-00-d2-b7-c7...done === mon.d52-54-00-d2-b7-c7 === Starting Ceph mon.d52-54-00-d2-b7-c7 on d52-54-00-d2-b7-c7... *** Caught signal (Segmentation fault) ** in thread 7fa1320f0780 It was installed and deployed from repo http://download.suse.de/ibs/Devel:/Storage:/0.5:/Staging/Cloud_4/ Example back trace: (gdb) bt #0 0x00007ffff5c411c0 in ?? () from /lib64/libunwind.so.7 #1 0x00007ffff5c422a9 in _ULx86_64_step () from /lib64/libunwind.so.7 #2 0x00007ffff7ba3415 in GetStackTrace (result=0x143f118, max_depth=30, skip_count=3) at src/stacktrace_libunwind-inl.h:114 #3 0x00007ffff7b943bf in RecordGrowth (growth=<optimized out>) at src/page_heap.cc:497 #4 tcmalloc::PageHeap::GrowHeap (this=0x147f000, n=<optimized out>) at src/page_heap.cc:523 #5 0x00007ffff7b946fb in tcmalloc::PageHeap::New (this=0x147f000, n=9) at src/page_heap.cc:154 #6 0x00007ffff7b9272b in tcmalloc::CentralFreeList::Populate (this=0x7ffff7dd0500 <tcmalloc::Static::central_cache_+77824>) at src/central_freelist.cc:318 #7 0x00007ffff7b9292d in tcmalloc::CentralFreeList::FetchFromSpansSafe (this=0x7ffff7dd0500 <tcmalloc::Static::central_cache_+77824>) at src/central_freelist.cc:285 #8 0x00007ffff7b929bb in tcmalloc::CentralFreeList::RemoveRange (this=0x7ffff7dd0500 <tcmalloc::Static::central_cache_+77824>, start=0x7fffffffba88, end=0x7fffffffba80, N=1) at src/central_freelist.cc:263 #9 0x00007ffff7b96ae9 in tcmalloc::ThreadCache::FetchFromCentralCache (this=0x150a098, cl=64, byte_size=73728) at src/thread_cache.cc:160 #10 0x00007ffff7b855cb in Allocate (cl=<optimized out>, size=<optimized out>, this=<optimized out>) at src/thread_cache.h:364 #11 do_malloc_small (size=73728, heap=<optimized out>) at src/tcmalloc.cc:1088 #12 do_malloc_no_errno (size=<optimized out>) at src/tcmalloc.cc:1095 #13 (anonymous namespace)::cpp_alloc (size=65538, nothrow=false) at src/tcmalloc.cc:1423 #14 0x00007ffff7ba4c38 in tc_newarray (size=140737488336048) at src/tcmalloc.cc:1631 #15 0x00007ffff6991394 in leveldb::ReadBlock (file=0x1c76f10, options=..., handle=..., result=0x7fffffffbcb0) at table/format.cc:125 #16 0x00007ffff6992e61 in leveldb::Table::BlockReader (arg=0x1c28100, options=..., index_value=...) at table/table.cc:179 #17 0x00007ffff69958a0 in leveldb::(anonymous namespace)::TwoLevelIterator::InitDataBlock (this=0x1c50d20) at table/two_level_iterator.cc:165 #18 0x00007ffff6995bea in leveldb::(anonymous namespace)::TwoLevelIterator::Seek (this=0x1c50d20, target=...) at table/two_level_iterator.cc:93 #19 0x00007ffff69924ec in Seek (k=..., this=<optimized out>) at table/iterator_wrapper.h:44 #20 leveldb::(anonymous namespace)::MergingIterator::Seek (this=0x1c3e760, target=...) at table/merger.cc:53 #21 0x00007ffff6979a44 in leveldb::(anonymous namespace)::DBIter::Seek (this=0x1c4cc80, target=...) at db/db_iter.cc:280 #22 0x00000000008513ea in LevelDBStore::LevelDBWholeSpaceIteratorImpl::lower_bound (this=0x1c2c1b0, prefix=..., to=...) at os/LevelDBStore.h:249 #23 0x0000000000850179 in LevelDBStore::get (this=0x1c8c780, prefix=..., keys=..., out=0x7fffffffc1a0) at os/LevelDBStore.cc:185 #24 0x0000000000545ab5 in MonitorDBStore::get (this=0x1c2c120, prefix=..., key=..., bl=...) at mon/MonitorDBStore.h:416 #25 0x0000000000545e5a in MonitorDBStore::get (this=0x1c2c120, prefix=..., key=...) at mon/MonitorDBStore.h:432 #26 0x00000000005af400 in Paxos::init (this=0x1d06500) at mon/Paxos.cc:63 #27 0x0000000000575e85 in Monitor::init_paxos (this=0x1ca6a00) at mon/Monitor.cc:611 #28 0x000000000057fe46 in Monitor::preinit (this=0x1ca6a00) at mon/Monitor.cc:499 #29 0x000000000053fc84 in main (argc=<optimized out>, argv=0x7fffffffe428) at ceph_mon.cc:653 -- 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 0

[Bug 882411] New: fuser prints PIDs with "%6d" causing large PIDs to be glued together
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=882411 https://bugzilla.novell.com/show_bug.cgi?id=882411#c0 Summary: fuser prints PIDs with "%6d" causing large PIDs to be glued together 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: gerben(a)sgi.com 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 If you have kernel.pid_max set to something larger than 99999 you will get PIDs with 6 digits. In this case fuser will produce output like: 90594 92545 95039 95459 95484 96321 97059 99381101264105909107266108324111597112058112778113808114386115892 11634011692811844711863511866212092712094912133912137712266412557 81264441273851276511277821279161280461285201319471323681323711327 34132898133141133641135616137231138589138637138638139038143840144 31914517114693214939414939515138815455915640215908116164316804316 89671691781745131749521753821763021832481833121860151897181975321 98419200172200691202418205571213815215965216406218121219993221441 22652222872922957722957823038123099923408023655524012424111324237 0245389245543 on its standard output. This is caused by the printf("%6d", pptr->pid) statement. As a result of this constructs like: pids=$(fuser -m filesystem 2>/dev/null) for pid in $pids do kill -KILL $pid done will fail. E.g. such a construct is present in the High Availability product in: /usr/lib/ocf/resource.d/heartbeat/Filesystem which will lead to the unability to unmount a file system. BTW. "fuser -m -k -KILL filesystem" should work correctly. Reproducible: Always Steps to Reproduce: 1. As root set kernel.pid_max to something larger than 99999. E.g. # sysctl -w kernel.pid_max=999999 2. run the fuser command: $ fuser -m / 2>/dev/null Actual Results: 95484 96321 97059 99381101264105909107266 Expected Results: 95484 96321 97059 99381 101264 105909 107266 -- 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 2

[Bug 880866] New: Firmware bug Intel(R) Wireless 7260 chipset
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=880866 https://bugzilla.novell.com/show_bug.cgi?id=880866#c0 Summary: Firmware bug Intel(R) Wireless 7260 chipset Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: suse+build(a)de-korte.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=592916) --> (http://bugzilla.novell.com/attachment.cgi?id=592916) Crash log from /var/log/messages User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 The bundled firmware in kernel-firmware for the Intel(R) Wireless 7260 chipset is broken. In Factory, the firmware was updated ------------------------------------------------------------------- Wed Mar 19 09:02:11 CET 2014 - tiwai(a)suse.de ... * iwlwifi: update firmware for 7260 / 3160 devices There is a fixed version available in http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/pla…. With the above updated firmware, the problem no longer occurs and the 7260 is rock solid. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3. Although not directly security related, with the bundled firmware in 13.1, the 7260 will crash frequently and at times will be unusable. -- 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 8

[Bug 830468] New: YaST2 spins up unmounted harddisks for many harddisk-unrelated config tasks
by bugzilla_noreply＠novell.com 12 Jun '14

12 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=830468 https://bugzilla.novell.com/show_bug.cgi?id=830468#c0 Summary: YaST2 spins up unmounted harddisks for many harddisk-unrelated config tasks Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Minor Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: andreas_nordal_4(a)hotmail.com QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 When YaST2 is opened, it shows a lot of icons (bootloader, network, …). I have noticed that the first thing that happens when clicking many of those, is that all harddisks spin up. I have several harddisks that I like to keep spun down: 1. My backup harddisk. 2. My failed raid1 array that I'm perpetually rescuing data from. 3. My family's failed harddisk that I'm perpetually rescuing data from. 4. My backup-backup harddisk that vibrates and squeals like a pig. Problem 1 — inconvenience: After say, adjusting bootloader settings, I have to open a terminal and do `for i in c d e f g; do hdparm -Y /dev/sd$i; done` as root to spin them down again. Problem 2 — unnecessity: Some settings are just totally harddisk-unrelated, e.g. network settings! Arguably all settings are unrelated, because these harddisks are not part of the system. Problem 3 — fragility: Don't rely on my failed harddisks! You won't be able to read the partition table of my family's failed harddisk anyway, and this apparently broke kernel upgrading… Reproducible: Always Steps to Reproduce: 1. Open YaST2 2. Click the network settings Actual Results: Harddisks spin up. It gets noisy. The mere presence of my family's failed harddisk causes things to take extremely long time and/or fail. Expected Results: Unused harddisks should remain spun down. -- 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 3

[Bug 881912] New: Soft lockup in utimes_common on ext3 with quota
by bugzilla_noreply＠novell.com 11 Jun '14

11 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=881912 https://bugzilla.novell.com/show_bug.cgi?id=881912#c0 Summary: Soft lockup in utimes_common on ext3 with quota Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: i686 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: jimc(a)math.ucla.edu QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Kernel version: kernel-default-3.14.1-24.3.geafcebd.i586 (Tumbleweed) Rest of OS: OpenSuSE 13.1 Affected filesystem: ext3 on RAID-5 (Megaraid) accessed locally, with user (but not group) quotas. Some of our users have bloated system mailboxes, 500Mbyte and up, and configure their mailers to expunge (via IMAP) on every deletion, requiring copying ridiculous amounts of data frequently, whereupon they complain about sluggish response. The IMAP daemon (WU-imap) is accessing the maibox file locally. Nothing ever accesses the mailbox over NFS, although unrelated files in the same filesystem (non-SuSE software) may be read by clients via NFS, not much traffic. Home directories, in other filesystems, are served read-write to clients. Also, user sessions on this machine may access files on other hosts by NFS, usually reading, sometimes writing. All mounting is done by autofs. Formerly the clients mounted using Nfsvers=3 in /etc/nfsmount.conf, and hard mounts (and similarly for this server when mounting other hosts as a client). We switched to Nfsvers=4 and soft mounts. Very soon thereafter, we started getting soft lockups. It was always in utime(2) called from imapd, in code where a spinlock is plausible. But it must be noted that almost all of the I/O activity and almost all of the calls to utime(2) were done by imapd. After five of these over 2 days we reverted to the status quo ante (Nfsvers=3, hard mounts), and no further soft lockups were seen over 2 days; however it was the weekend and the imapd activity was quite a bit less. If another soft lockup is seen, I'll post it (and most likely we will go back to Nfsvers=4 and soft mounts). I really doubt that the hard vs. soft mount issue is relevant here, but the NFS versions use completely different code and would be very relevant. Except that the affected files are never accessed by NFS; the bulk of NFS activity is on filesystems other than this one. Why are we running the Tumbleweed kernel? See Bug 880599; a fix for that problem is in the newer kernel. But the distro's standard kernel receives fixes that Tumbleweed doesn't (or it looks that way), so if bug 880599 were resolved we would revert to kernel 3.11.10. Since I can't make the soft lockup happen on command, and since it will be hard to test patched kernels on the production system, I don't have much hope for making progress suppressing the soft lockups. I'm mainly posting this bug report to have it on record that something is happening, in case someone else (or we) discovers a way to test fixes efficiently, or spots a coding error in utimes(2). Also, this issue is off topic for bug 880599 but I plan to insert a cross-reference there, in case there actually is some connection. (Note to readers: a soft lockup is a detected infinite loop in kernel code, and a very common culprit is using a spinlock when the holder fails to release the lock.) -- 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 4

[Bug 856770] New: Ralink RT3290 Wifi support
by bugzilla_noreply＠novell.com 11 Jun '14

11 Jun '14

https://bugzilla.novell.com/show_bug.cgi?id=856770 https://bugzilla.novell.com/show_bug.cgi?id=856770#c0 Summary: Ralink RT3290 Wifi support Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: amoebaworks(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Installed OpenSUSE 13.1 and my wifi has never worked properly. It can auth to the router but then seconds later it crashes and tries to re-establish a few times but then it crashes completely. I have unchecked "Enable Wireless" and recheck it to get back to doing the auth, crash, retry cycle. If I've lucked out and had the wifi up for a bit the speed is horrible. I asked the forum and someone resolved their issue with a 3.12 kernel. I could not install the 3.12 kernel but someone else mentioned that the patches were backported to the 3.11.8+ kernel and I should ask the devs to release that version of the kernel. Easier said than done I imagine. See more here: http://forums.opensuse.org/english/get-technical-help-here/install-boot-log… Reproducible: Always Steps to Reproduce: 1. Start up computer 2. Wifi connects for a little bit then becomes unavailable seconds later. Usually with some traffic going on it through Firefox. Actual Results: Wifi is unavailable after a few seconds after startup. Expected Results: Wifi is available. # hwinfo --wlan 24: PCI 200.0: 0282 WLAN controller [Created at pci.319] Unique ID: S6TQ.MxvvoCwdjwB Parent ID: CvwD.nV9PPa_ZQ2D SysFS ID: /devices/pci0000:00/0000:00:05.0/0000:02:00.0 SysFS BusID: 0000:02:00.0 Hardware Class: network Model: "RaLink WLAN controller" Vendor: pci 0x1814 "RaLink" Device: pci 0x3290 SubVendor: pci 0x103c "Hewlett-Packard Company" SubDevice: pci 0x18ec Driver: "rt2800pci" Driver Modules: "rt2800pci" Device File: wlo1 Features: WLAN Memory Range: 0xf0210000-0xf021ffff (rw,non-prefetchable) IRQ: 48 (no events) HW Address: xxxxxxxxxxxxxxxxx Link detected: no WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 2.484 WLAN encryption modes: WEP40 WEP104 TKIP CCMP WLAN authentication modes: open sharedkey wpa-psk wpa-eap Module Alias: "pci:v00001814d00003290sv0000103Csd000018ECbc02sc80i00" Driver Info #0: Driver Status: rt2800pci is active Driver Activation Cmd: "modprobe rt2800pci" Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #5 (PCI bridge) -- 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 3