August 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 798287] New: r8169 driver after some time doesn't receive packets
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=798287 https://bugzilla.novell.com/show_bug.cgi?id=798287#c0 Summary: r8169 driver after some time doesn't receive packets Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: Ralf.Friedl(a)online.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.8.1.24) Gecko/20100228 SeaMonkey/1.1.19 I have a mainboard ASUS M5A97 EVO R2.0. Onboard it has a Realtek 8168 chip. This chip is recognized by the r8169 driver. After some days of normal/low use it happens that the driver doesn't receive packets. I can verify with tcpdump on another computer that it sends packets, but it doesn't receive the answers. This applies to all packets, ARP, ICMP, TCP, UDP. This can be fixed with reloading the driver (rmmod r8169; modprobe r8169). Then it would work again for some days. Yesterday I wanted to transfer a Suse ISO file to another computer also on gigabit Ethernet. Here the same effect happens always after 5-30 seconds. Reloading the driver again helps, but only for another few seconds. After searching the internet, I found recommendations to a r8168 driver from Realtek, see http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&PFi… I compiled and loaded this driver. With this driver I was able to transfer the ISO file and didn't have any problems since then. So whatever is different with this driver seems to fix the problem. Reproducible: Always Steps to Reproduce: 1. Use ASUS M5A97 EVO R2.0 (might also affect other boards / chip revisions) 2. Transfer large file over network interface Actual Results: After a few seconds, the driver doesn't receive any packets. Expected Results: File is transferred normally. Output from lspci: # lspci -nnQ -s 02:00.0 -v 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 09) Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard [1043:8505] Flags: bus master, fast devsel, latency 0, IRQ 90 I/O ports at e000 [size=256] Memory at fea04000 (64-bit, prefetchable) [size=4K] Memory at fea00000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel By the way, the option -Q to lspci displays RTL8111/8168 while the local file says RTL8111/8168B. The Realtek r8168 driver gives this output: r8168 Gigabit Ethernet driver 8.035.00-NAPI loaded r8168 0000:02:00.0: irq 90 for MSI/MSI-X eth%d: RTL8168F/8111F at 0xffffc90000030000, 50:46:5d:xx:xx:xx, IRQ 90 eth0: Identified chip type is 'RTL8168F/8111F'. -- 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 767931] New: System hang when switching off NVD9 on linux 3.4
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=767931 https://bugzilla.novell.com/show_bug.cgi?id=767931#c0 Summary: System hang when switching off NVD9 on linux 3.4 Classification: openSUSE Product: openSUSE 12.2 Version: Factory Platform: x86-64 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: srid(a)rkmail.ru QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Opera/9.80 (X11; Linux x86_64; U; ru) Presto/2.10.229 Version/11.64 I'm using Asus u30sd notebook with infamous nvidia optimus graphics. (geforce 520M aka NVD9) In kernel 3.3 for nvd9 was added support for switching it off via debugfs (/sys/kernel/debug/vgaswitcheroo/switch). It is a cool feature, it saved me hours of battery power, but it seems that in linux 3.4 it's broken. I have 'echo OFF > /sys/kernel/debug/vgaswitcheroo/switch' line in my /etc/init.d/boot.local to poweroff nvidia controller on boot. On cold start with kernel 3.4 the screen goes dark when kdm greeting is supposed to appear, and computer does not respond to any keys. If I am rebooting machine with already disabled nvidia graphics (for example, booting to 3.3 and switching off secondary card from there) the boot process stops just after line 'VGA switcheroo: switched nouveau off' appears on the screen. System boots normally without 'echo OFF > /sys/kernel/debug/vgaswitcheroo/switch' in /etc/init.d/boot.local Reproducible: Always Steps to Reproduce: 1. 2. 3. My lspci: lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05) 01:00.0 VGA compatible controller: nVidia Corporation GF119 [GeForce GT 520M] (rev ff) 03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) 04:00.0 Ethernet controller: Atheros Communications AR8151 v2.0 Gigabit Ethernet (rev c0) -- 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 782354] New: Full directory structure remains after removing of kernel-*-debuginfo
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=782354 https://bugzilla.novell.com/show_bug.cgi?id=782354#c0 Summary: Full directory structure remains after removing of kernel-*-debuginfo Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: Other OS/Version: openSUSE 12.2 Status: NEW Severity: Minor Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: arvidjaar(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1 It seems that kernel-*-debuginfo RPMs do not own directories under /usr/lib/debug/lib. So after deinstallation of RPM full directory structure remains. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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 765536] New: freeze with radeon hd 7750 pcie graphics card (probably kms conflict or wrong driver usage)
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=765536 https://bugzilla.novell.com/show_bug.cgi?id=765536#c0 Summary: freeze with radeon hd 7750 pcie graphics card (probably kms conflict or wrong driver usage) Classification: openSUSE Product: openSUSE 12.2 Version: Beta 1 Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: abittner(a)abittner.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5 I had this system running in very low quality framebuffer mode with milestone2 or milestone3, there I did a zypper dup to probably beta1 as the latest code pushed to these /update/12.2/.... path names on download.opensuse.org servers. anyways, when this system booted back up, it would show me the kde logon screen, but as soon as i login there or hit the virtual text consoles (alt+Fn keys) the whole system freezes, numlock doesnt react any more), whole screen goes blank and stays. only a hardware reset helps. I have tried grub2 booting safe/recovery mode or whatever this second entry is called there but that doesnt help either, and I have tried in the grub2 screen adding vesa or normal or such parameters and removing the splash stuff to the safemode or even the first entry and temporarily booting that alt+x/f10, but that only shows some kernel bootup messages up to two seconds counter, and those last lines already complaining about radeonhdfb conflicting with vesa or normal vga fb driver or whatever and it says its removing the default drivers, so I assume it wants to use radeonhd and its specialized fb driver for this new ati/amd graphics card too, but these gfx chipsets from the radeon hd 7xxx line differ from the older hardware releases quite a lot and maybe it freezes due to these incompatibilities or such. how do I make it bootup normal default vga/framebuffer mode without the freeze? the kernel/linux has to be able to use default plain vga/compatibility modes even with this dang graphics card. I could provide for some pcie IDs and more details if I could at least make it into this test system in any way whatsoever. Any ideas? Could attach photograph of screen of those frambuffer/radeonhd conflicting messages as well if needed. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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 7

[Bug 799475] New:=?UTF-8?Q?=20kernel=20bug=20in=20=E2=80=A6?=/mm/slab.c:3175 and subsequent deep freeze
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=799475 https://bugzilla.novell.com/show_bug.cgi?id=799475#c0 Summary: kernel bug in …/mm/slab.c:3175 and subsequent deep freeze Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: avsco(a)mail.ru QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Preface. I'm using openSUSE ocassionally, not on a day-by-day basis. To make things worse, my desktop has Intel ICH10R fake-RAID, so I'm not usually surprised when the mirror drops to “verify” state after some graceful openSUSE shutdown or after pressing the Reset button during a stalled shutdown, as well as when openSUSE turns into a pumpkin in several months after installation and doesn't want to start until I reinstall it. This time it looked the same, when [after applying recent updates a month ago, I guess] openSUSE stopped loading, falling back to single-user mode after failing /home mount operation, perhaps, — it's hard to tell from the intermixed systemd output. But today I looked more carefully at the previous messages in scrollback buffer, and noticed that there was actually a crash report up there. As this report was not written to any file (at least I didn't find any), I wrote down the first lines: > kernel bug in …/mm/slab.c:3175 > invalid opcode: 0000 > pid = mount, sig = SEGV > Trace: > ... __kmalloc+0x153/0x190 > ... ext4_kvzalloc+0x1d/0x60 (numbers in this line are the same as in latter reports) > ... ext4_fill_super+0x1556/0x2840 > ..... Then it turned out that booting in failsafe mode allowed to enter KDE without a problem. And, having found no information on that specific bug, I decided to apply the current updates as well. Although no updates for kernel were available at this time, the situation has worsened. At first, half of attempts to boot in normal mode resulted in giving 3 crash reports, ending with a deep freeze; the other half still dropped to single-user mode after 1 crash report. But, after some tryouts, the 3-crash way absolutely prevailed, so I now have no other option but to photograph the screen (see the attachments). It now proceeds as this: 1. The boot process starts as usual, mounting some partitions and starting some services. 2. The original …/mm/slab.c:3175 crash occurs (at least I suppose so, because call traces look similar) and immediately goes another one, as depicted in trace01.png. 3. The computer freezes, which looks like a 100 % processor core load: generally unresponsive, but may occasionally react to scrollback keys. 4. After 45 seconds, the third crash report is displayed, as depicted in trace02.png, and the computer ultimately hangs, which looks like an idle halt. The resulting freeze is so deep that SysRq keys stop working and I have to press the Reset button. The failsafe mode still worked, though, so I finally figured out what options do the trick: > nohz=off highres=off When both are present, the system boots to KDE just fine, as it always did earlier. When any of this options is missing, then the 3-crash issue is sure to occur. Further details. All filesystems, including the mentioned /home, are ext4 residing on LVM2 volumes, with the exception of /boot on raw partition. I did no change to disks in recent months/years, nor to other hardware (except to videocard, but I doubt it could influence a filesystem driver or timer module). Any hints on how to debug this? Reproducible: Always -- 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 25

[Bug 808558] New: internal bluetooth interface BCM20702A0 not recognized and loaded by the kernel
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=808558 https://bugzilla.novell.com/show_bug.cgi?id=808558#c0 Summary: internal bluetooth interface BCM20702A0 not recognized and loaded by the kernel Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: peter-mailbox(a)web.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0 Hello, I've a notebook with an embedded bluetooth interface. The interface is from Broadcom (Broadcom BCM20702A0, ID 0489:e031 Foxconn/Hon Hai) but not (yet) identified by the kernel. Also, the interface needs a firmware and the logic of loading it is also not (yet) in the kernel - that's what I understood from below ;-) There are hints in the web, that the interface works in principle: https://bbs.archlinux.org/viewtopic.php?id=133093 but is not yet in the kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065400 I'm running 12.2 with kernel 3.4.28-2.20-desktop x86_64 and I had a look for kernel-source-3.7.10-1.1.1.src from 12.3, but I can't find any relevant changes in /usr/src/linux/drivers/bluetooth/btusb.c So what's about the bug, when will it be solved and patched in the kernel? Thank's a lot Peter Reproducible: Always Steps to Reproduce: 1. switch on bluetooth (hardware switch) 2. have a look in /var/log/messges 3. have a look in KDE bluetooth integration Actual Results: bluetooth interface is not identified, no module loaded KDE bluetooth integration says 'no bluetooth adapters have bin found' Expected Results: bluetooth interface should be identified firmware should be loaded when I try the hints from https://bbs.archlinux.org/viewtopic.php?id=133093 so copy firmware to /lib/firmware modprobe btusb switch on bluetooth (hardware switch) use ./bcmfwup.py echo "0489 e031" >> /sys/bus/usb/drivers/btusb/new_id bluetoothd recognized the interface and I able to connect a bluetooth device (e.g. mobile phone) with KDE bluetooth integration -- 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 774557] New: Kernel 3.4.6 needs patch to make Realtek 8111 NIC work (backport from 3.5)
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=774557 https://bugzilla.novell.com/show_bug.cgi?id=774557#c0 Summary: Kernel 3.4.6 needs patch to make Realtek 8111 NIC work (backport from 3.5) Classification: openSUSE Product: openSUSE 12.2 Version: RC 2 Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: omega(a)online.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 Realtek 8111 NIC with r8169 kernel modul frequently gets stuck; network connectivity is lost for several seconds until the kernel watchdog kicks in and brings the NIC back to life. This makes any box with this NIC unusable. I observed this issue already with openSUSE 12.1 Tumbleweed and kernel 3.4 and could only solve the problem by stepping back to kernel 3.1. This is a quite frequently observed problem with these on-board Realtek chipsets. A patch was recently posted here: https://bugzilla.kernel.org/attachment.cgi?id=73504 (see https://bugzilla.kernel.org/show_bug.cgi?id=14962#c27 for details). The patch has made it into kernel 3.5 but not into 3.4.6 or 3.4.7. To my knowledge openSUSE delivers kernels with extra patches. I therefore suggest to integrate that simple patch into the openSuSE kernel 3.4. Reproducible: Always Steps to Reproduce: Use a box with a mainboard with Realtek 8111B chipset, install 3.4er kernel, initiate some network activity while pinging another host. The pings will stop every now and then and, when the NIC comes back to live, the roundtrip time shown is about 10 to 20 seconds(!). I will ask Francois Romieu to backport his patch to 3.4.6 and 3.4.7 kernel series. -- 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 27

[Bug 837482] New: Atheros AR8161 wired lan didn't work compat-drivers-... rpms
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=837482 https://bugzilla.novell.com/show_bug.cgi?id=837482#c0 Summary: Atheros AR8161 wired lan didn't work compat-drivers-... rpms Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: spst(a)freemail.hu QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36 I have an Gigabyte Z77-DS3H motherboard with integrated Atheros AR8161 wired lan interface. After kernel update to 3.4.47 and install compat-drivers-script-.. and compat-drivers-kmp-.. rpms but my Atheros AR8161 wired lan wasn't working. Yast doesn't recognize lan and eth0. There is any lan connections. It worked with 3.4.33 kernel and compat- wireless-script-.. and compat-wireless-kmp-... rpms but rpms changed to compat-drivers-... and it doesn't work. Reproducible: Always Steps to Reproduce: 1.Update to 3.4.47 kernel 2.Uninstall compat-wireless-.. rpms 3.Install compat-drivers-.. rpms 4.Try to setup lan card on Yast -- 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 795937] New: DRBD disconnecting on heavy load: "BAD! BarrierAck #XXX received, expected #XXX"
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=795937 https://bugzilla.novell.com/show_bug.cgi?id=795937#c0 Summary: DRBD disconnecting on heavy load: "BAD! BarrierAck #XXX received, expected #XXX" Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: servizioclienti(a)livenet.it QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11 I'm experiencing the same problem as in bug 714510 I reported a year ago, closed WONTFIX. This is a freshly installed 12.2 with updates. On heavy load (rsync over gigabit, disks are hw raid on both sides), the primary prints on logs Dec 26 22:21:29 maria kernel: [ 4406.648798] block drbd1: BAD! BarrierAck #221567884 received, expected #221567882! Dec 26 22:21:29 maria kernel: [ 4406.648808] block drbd1: peer( Secondary -> Unknown ) conn( Connected -> ProtocolError ) pdsk( UpToDate -> DUnknown ) Dec 26 22:21:29 maria kernel: [ 4406.648840] block drbd1: new current UUID EBAFCE24637DB1EB:B7914897B687272B:DD55206DD0404A9D:DD54206DD0404A9D Dec 26 22:21:29 maria kernel: [ 4406.648858] block drbd1: asender terminated Dec 26 22:21:29 maria kernel: [ 4406.648861] block drbd1: Terminating drbd1_asender Dec 26 22:21:29 maria kernel: [ 4406.649372] block drbd1: Connection closed Dec 26 22:21:29 maria kernel: [ 4406.649378] block drbd1: conn( ProtocolError -> Unconnected ) Dec 26 22:21:29 maria kernel: [ 4406.649386] block drbd1: receiver terminated The secondary writes Dec 26 22:21:29 annunziata kernel: [ 341.664099] block drbd1: meta connection shut down by peer. Dec 26 22:21:29 annunziata kernel: [ 341.664109] block drbd1: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown ) Dec 26 22:21:29 annunziata kernel: [ 341.664145] block drbd1: error receiving Data, l: 45080! Dec 26 22:21:29 annunziata kernel: [ 341.714355] block drbd1: asender terminated Dec 26 22:21:29 annunziata kernel: [ 341.714362] block drbd1: Terminating drbd1_asender Dec 26 22:21:29 annunziata kernel: [ 341.714560] block drbd1: Connection closed Dec 26 22:21:29 annunziata kernel: [ 341.714565] block drbd1: conn( NetworkFailure -> Unconnected ) Dec 26 22:21:29 annunziata kernel: [ 341.714570] block drbd1: receiver terminated (and then the connection restarts) While the connection restarts (two-three seconds) disks freeze. Sometimes connection stucks in 'syncing 100%' state and I need to reboot both sides (drbd stop and start doesn't work). Only once I've seen the primary to reboot. Building the module from source tarball (http://oss.linbit.com/drbd/8.3/drbd-8.3.11.tar.gz) the problem disappears, so I think you need to check differences between original sources and your sources. Does openSUSE team think that drbd module is not important? Valerio Reproducible: Always Steps to Reproduce: 1. install two opensuse 12.2 2. configure a drbd disk pri/sec and do strong traffic 3. check logs Actual Results: disconnections and locks Expected Results: none of the above -- 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 784219] New: kernel Call Traces from io_schedule
by bugzilla_noreply＠novell.com 08 Aug '14

08 Aug '14

https://bugzilla.novell.com/show_bug.cgi?id=784219 https://bugzilla.novell.com/show_bug.cgi?id=784219#c0 Summary: kernel Call Traces from io_schedule Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: meissner(a)suse.com ReportedBy: rommel(a)suse.com QAContact: qa-bugs(a)suse.de CC: jeffm(a)suse.com Found By: --- Blocker: --- When testing the prepared maintenance update Products: SUSE Linux 12.2 (debug, multiarch) Category: security openSUSE Maintenance ID: 970 openSUSE Review ID: 137259 Repository URL: http://download.opensuse.org/repositories/openSUSE:/Maintenance:/970/openSU… Packager: jeff_mahoney Bugs: 762693 765230 771392 772566 772831 772923 773406 774523 774859 776925 778630 779432 780624 781134 with newburn I got some kernel call traces like Oct 9 00:45:03 boxer kernel: INFO: task rs:main Q:Reg:24427 blocked for more than 480 seconds. Oct 9 00:45:03 boxer kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 9 00:45:03 boxer kernel: ffff880120721a08 0000000000000082 ffff88011ff06100 ffff880120721fd8 Oct 9 00:45:03 boxer kernel: ffff880120721fd8 ffff880120721fd8 ffff88011aef2600 ffff88011ff06100 Oct 9 00:45:03 boxer kernel: ffffffff81009a05 ffff88011ff06100 ffff880127c53568 0000000000000002 Oct 9 00:45:03 boxer kernel: Call Trace: Oct 9 00:45:03 boxer kernel: [<ffffffff8158c4ba>] io_schedule+0x8a/0xd0 Oct 9 00:45:03 boxer kernel: [<ffffffff810fe929>] sleep_on_page+0x9/0x10 Oct 9 00:45:03 boxer kernel: [<ffffffff8158abcf>] __wait_on_bit+0x4f/0x80 Oct 9 00:45:03 boxer kernel: [<ffffffff810fea40>] wait_on_page_bit+0x70/0x80 Oct 9 00:45:03 boxer kernel: [<ffffffff810ff9da>] grab_cache_page_write_begin+0xaa/0x100 Oct 9 00:45:03 boxer kernel: [<ffffffff811f7451>] ext4_da_write_begin+0xa1/0x230 Oct 9 00:45:03 boxer kernel: [<ffffffff810ff5d1>] generic_file_buffered_write+0x121/0x2d0 Oct 9 00:45:03 boxer kernel: [<ffffffff8110052a>] __generic_file_aio_write+0x21a/0x410 Oct 9 00:45:03 boxer kernel: [<ffffffff81100790>] generic_file_aio_write+0x70/0xf0 Oct 9 00:45:03 boxer kernel: [<ffffffff811f0b67>] ext4_file_write+0xb7/0x260 Oct 9 00:45:03 boxer kernel: [<ffffffff8115cffe>] do_sync_write+0xbe/0x100 Oct 9 00:45:03 boxer kernel: [<ffffffff8115d8c7>] vfs_write+0xa7/0x180 Oct 9 00:45:03 boxer kernel: [<ffffffff8115dbf7>] sys_write+0x47/0x90 Oct 9 00:45:03 boxer kernel: [<ffffffff8159437d>] system_call_fastpath+0x1a/0x1f Oct 9 00:45:03 boxer kernel: [<00007fdd3fe8228d>] 0x7fdd3fe8228c and Oct 9 00:37:03 boxer kernel: INFO: task memtst:31391 blocked for more than 480 seconds. Oct 9 00:37:03 boxer kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Oct 9 00:37:03 boxer kernel: ffff8800a076f718 0000000000000082 ffff8800a49ae440 ffff8800a076ffd8 Oct 9 00:37:03 boxer kernel: ffff8800a076ffd8 ffff8800a076ffd8 ffffffff81a14020 ffff8800a49ae440 Oct 9 00:37:03 boxer kernel: ffffffff81009a05 ffff8800a49ae440 ffff880127c13568 0000000000000002 Oct 9 00:37:03 boxer kernel: Call Trace: Oct 9 00:37:03 boxer kernel: [<ffffffff8158c4ba>] io_schedule+0x8a/0xd0 Oct 9 00:37:03 boxer kernel: [<ffffffff810fe929>] sleep_on_page+0x9/0x10 Oct 9 00:37:03 boxer kernel: [<ffffffff8158abcf>] __wait_on_bit+0x4f/0x80 Oct 9 00:37:03 boxer kernel: [<ffffffff810fea40>] wait_on_page_bit+0x70/0x80 Oct 9 00:37:03 boxer kernel: [<ffffffff81111c1b>] shrink_page_list+0x29b/0x940 Oct 9 00:37:03 boxer kernel: [<ffffffff81112774>] shrink_inactive_list+0x1f4/0x4f0 Oct 9 00:37:03 boxer kernel: [<ffffffff811131d2>] shrink_mem_cgroup_zone+0x3b2/0x520 Oct 9 00:37:03 boxer kernel: [<ffffffff811133b0>] shrink_zone+0x70/0x90 Oct 9 00:37:03 boxer kernel: [<ffffffff81113733>] do_try_to_free_pages+0x103/0x560 Oct 9 00:37:03 boxer kernel: [<ffffffff81113e91>] try_to_free_pages+0x91/0x180 Oct 9 00:37:03 boxer kernel: [<ffffffff81108108>] __alloc_pages_nodemask+0x578/0xa00 Oct 9 00:37:03 boxer kernel: [<ffffffff81143468>] alloc_pages_vma+0xb8/0x1a0 Oct 9 00:37:03 boxer kernel: [<ffffffff81151314>] do_huge_pmd_anonymous_page+0x154/0x380 Oct 9 00:37:03 boxer kernel: [<ffffffff81590839>] do_page_fault+0x149/0x490 Oct 9 00:37:03 boxer kernel: [<ffffffff8158dc75>] page_fault+0x25/0x30 Oct 9 00:37:03 boxer kernel: [<0000000000401685>] 0x401684 How to reproduce: install qa_test_newburn from IBS QA:Head and run /usr/lib/ctcs2/tools/test_newburn-run (in this case I lowered the execution time in that script from 24h to 8h) At this point I don't know if this is a regression when compared to the GM kernel. Please advise how to read/rate these messages. -- 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 11