Bug#778239: Strange GRE packet forwarding slowness in 3.16.7-ckt2-1~bpo70+1
On 18.02.2015 02:25, Ben Hutchings wrote: On Wed, 2015-02-18 at 00:14 +0100, Sven Hartge wrote: On Thu, 12 Feb 2015 16:33:09 +0100 Sven Hartge s...@svenhartge.de wrote: I have encountered a strange slowness on a router/packetfilter system (Wheezy 7.8 with backported kernel 3.16.7-ckt2-1~bpo70+1) of mine while forwarding GRE packets. Could this be the fix for this bug: https://lists.ubuntu.com/archives/kernel-team/2014-December/052158.html gre: Set inner mac header in gro complete I don't know. I cannot confirm this myself right now, as the only systems affected are in production and I am not able to set up a lab installation right now. As that went into 3.16.7-ckt3, it is therefore included in the current packages in testing/unstable. Well, I've got a window for testing later today. I will report back, if this release fixes the problem I am seeing. Grüße, Sven. signature.asc Description: OpenPGP digital signature
Bug#778239: Strange GRE packet forwarding slowness in 3.16.7-ckt2-1~bpo70+1
On 18.02.2015 09:17, Sven Hartge wrote: On 18.02.2015 02:25, Ben Hutchings wrote: On Wed, 2015-02-18 at 00:14 +0100, Sven Hartge wrote: On Thu, 12 Feb 2015 16:33:09 +0100 Sven Hartge s...@svenhartge.de wrote: I have encountered a strange slowness on a router/packetfilter system (Wheezy 7.8 with backported kernel 3.16.7-ckt2-1~bpo70+1) of mine while forwarding GRE packets. Could this be the fix for this bug: https://lists.ubuntu.com/archives/kernel-team/2014-December/052158.html gre: Set inner mac header in gro complete I don't know. I cannot confirm this myself right now, as the only systems affected are in production and I am not able to set up a lab installation right now. As that went into 3.16.7-ckt3, it is therefore included in the current packages in testing/unstable. Well, I've got a window for testing later today. I will report back, if this release fixes the problem I am seeing. Yes, this patch fixes this problem for me. Should I close the bug or do you want to do it? Grüße, Sven. signature.asc Description: OpenPGP digital signature
Bug#773250: linux-image-3.18.0-trunk-amd64: USB keyboard not recognized at the time cryptsetup prompt shows up
Same problem as previously mentioned. I have an Apple MacBook with luks, my keyboard is recognized (I can navigate in the GRUB option menu), but typing the passphrase to access the disk and boot on my system has no effect. Moreover, I am compiling my own kernels for my distribution and the problem occurred at 3.18.x and higher (I just tried with 3.19.0 right now, the problem is still here). So, the problem comes from a modification of the kernel settings and not because of some tweaks from specific to linux-image-3.18.0-trunk-amd64. The new kernel series may need to tick a new box in the menuconfig phase, but I can tell which one. I am still looking for some clues that could lead to a resolution of the problem (if a least I could see where it fails it would be a starting point). So, any hint is welcome ! Regards -- Emmanuel Fleury Experience is one thing you can't get for nothing. -- Oscar Wilde signature.asc Description: OpenPGP digital signature
Bug#773250: linux-image-3.18.0-trunk-amd64: USB keyboard not recognized at the time cryptsetup prompt shows up
Update... It seems that the 'xhci-hcd' module was split into 'xhci-pci' and 'xhci-platform' since kernel version 3.18. Adding the 'xhci-pci' module to initramfs fixes the issue for me. It worked for me too... I should have read this thread till the last post... Sorry. -- Emmanuel Fleury A good compromise leaves everyone mad. -- Calvin Hobbes (Bill Waterson) signature.asc Description: OpenPGP digital signature
Re: Dvb usb device crashes khubd in kernel 3.16.7-ckt4-3, how to debug?
On 18.02.2015 17:26, Tilman Schröder wrote: Hello everybody, on recent kernels, my dvb usb device does not work any more and crashes khubd when I remove it. It has worked perfectly on wheezy and works perfectly in Windows, so it is no hardware failure. Since I do not know a lot about the kernel internals I have no idea how to debug this. Can somebody help me with this? [...] hangs and cannot be killed/stopped by Ctrl+C. dmesg shows [...] The same happens when I just unplug the device instead of (forcing) a module removal, but I did not yet check whether all the hexadecimal numbers are the same in both cases. These messages are repeated every 120 seconds. This is the dmesg output when I remove the device: [ 1449.634219] usb 6-3: USB disconnect, device number 2 [ 1680.100304] INFO: task khubd:77 blocked for more than 120 seconds. [ 1680.100318] Tainted: P O 3.16.0-4-amd64 #1 [ 1680.100322] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 1680.100327] khubd D 8801190db178 077 2 0x [ 1680.100338] 8801190dad20 0046 00013280 880036f33fd8 [ 1680.100346] 00013280 8801190dad20 8800d8824400 8800d91e [ 1680.100354] 88011947d278 88003667d890 88003667d800 880036659400 [ 1680.100362] Call Trace: [ 1680.100391] [a105b8c5] ? dvb_unregister_frontend+0xb5/0x110 [dvb_core] [ 1680.100402] [810a7840] ? prepare_to_wait_event+0xf0/0xf0 [ 1680.100413] [a10767f5] ? dvb_usb_adapter_frontend_exit+0x35/0x60 [dvb_usb] [ 1680.100422] [a1075401] ? dvb_usb_exit+0x31/0xa0 [dvb_usb] [ 1680.100433] [a10754ab] ? dvb_usb_device_exit+0x3b/0x50 [dvb_usb] [ 1680.100483] [a006b79c] ? usb_unbind_interface+0x6c/0x2b0 [usbcore] [ 1680.100500] [813a145a] ? __device_release_driver+0x7a/0xf0 [ 1680.100507] [813a14ee] ? device_release_driver+0x1e/0x30 [ 1680.100514] [813a0df3] ? bus_remove_device+0x103/0x180 [ 1680.100521] [8139d886] ? device_del+0x116/0x1b0 [ 1680.100546] [a0069200] ? usb_disable_device+0xa0/0x280 [usbcore] [ 1680.100571] [a005ee01] ? usb_disconnect+0x91/0x280 [usbcore] [ 1680.100596] [a006137c] ? hub_thread+0xaac/0x1740 [usbcore] [ 1680.100606] [8109f3c4] ? check_preempt_wakeup+0xe4/0x1d0 [ 1680.100614] [810a7840] ? prepare_to_wait_event+0xf0/0xf0 [ 1680.100639] [a00608d0] ? hub_port_debounce+0x130/0x130 [usbcore] [ 1680.100648] [81087ddd] ? kthread+0xbd/0xe0 [ 1680.100655] [81087d20] ? kthread_create_on_node+0x180/0x180 [ 1680.100664] [8150f6bc] ? ret_from_fork+0x7c/0xb0 [ 1680.100671] [81087d20] ? kthread_create_on_node+0x180/0x180 [...] Has anyone a suggestion on how to fix this? Thanks in advance! Sincerely, Tilman -- Secure communication? GPG: 0xC2CE100970755E61 at keys.gnupg.net signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#776816: Acknowledgement (firmware-realtek: fails to connect after a few suspends (or some uptime?))
Processing control commands: severity -1 grave Bug #776816 [firmware-realtek] firmware-realtek: fails to connect after a few suspends (or some uptime?) Severity set to 'grave' from 'normal' fixed -1 0.36+wheezy.1 Bug #776816 [firmware-realtek] firmware-realtek: fails to connect after a few suspends (or some uptime?) Marked as fixed in versions firmware-nonfree/0.36+wheezy.1. -- 776816: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776816 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b776816.142431995913471.transcr...@bugs.debian.org
Bug#776816: Acknowledgement (firmware-realtek: fails to connect after a few suspends (or some uptime?))
Control: severity -1 grave Control: fixed -1 0.36+wheezy.1 I am now pretty sure this is a bug, a regression, even, in the realtek firmware. I downgraded to the wheezy version 4 days ago, and problems went away (hence the fixed above). Now that I upgraded again, problems are back. Since this is a fairly serious regression, I think it's fair to mark this as release-critical (hence the severity change). More details on the wifi adapter: 04:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01) Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8195] Physical Slot: 0 Flags: bus master, fast devsel, latency 0, IRQ 17 I/O ports at 2000 [size=256] Memory at f010 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00 Kernel driver in use: rtl8192ce I'm of course available to debug any problems with this. A. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fva2o7cd@marcos.anarc.at
Dvb usb device crashes khubd in kernel 3.16.7-ckt4-3, how to debug?
Hello everybody, on recent kernels, my dvb usb device does not work any more and crashes khubd when I remove it. It has worked perfectly on wheezy and works perfectly in Windows, so it is no hardware failure. Since I do not know a lot about the kernel internals I have no idea how to debug this. Can somebody help me with this? When the device is plugged in, it is recognised by the kernel as the output of dmesg shows: [ 1162.196344] usb 8-3: new high-speed USB device number 2 using ehci-pci [ 1162.329106] usb 8-3: New USB device found, idVendor=2040, idProduct=7070 [ 1162.329118] usb 8-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1162.329125] usb 8-3: Product: Nova-T Stick [ 1162.329131] usb 8-3: Manufacturer: Hauppauge [ 1162.329137] usb 8-3: SerialNumber: 4033414762 [ 1163.368805] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware [ 1163.369577] usb 8-3: firmware: direct-loading firmware dvb-usb-dib0700-1.20.fw [ 1163.589144] dib0700: firmware started successfully. [ 1164.092283] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. [ 1164.092452] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 1164.092650] DVB: registering new adapter (Hauppauge Nova-T Stick) [ 1164.319560] usb 8-3: DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 1164.543554] DiB0070: successfully identified [ 1164.572050] Registered IR keymap rc-dib0700-rc5 [ 1164.572354] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb8/8-3/rc/rc0/input19 [ 1164.572628] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb8/8-3/rc/rc0 [ 1164.572782] dvb-usb: schedule remote query interval to 50 msecs. [ 1164.572790] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. [ 1164.572985] usbcore: registered new interface driver dvb_usb_dib0700 and the device files show up in /dev/dvb/adapter0/: $ ls -hl /dev/dvb/adapter0/ insgesamt 0 crw-rw+ 1 root video 212, 0 Feb 16 07:18 demux0 crw-rw+ 1 root video 212, 1 Feb 16 07:18 dvr0 crw-rw+ 1 root video 212, 3 Feb 16 07:18 frontend0 crw-rw+ 1 root video 212, 2 Feb 16 07:18 net0 However, no program can open those devices: $ dvbscan -adapter 0 -frontend 0 -demux 0 Failed to open frontend Being root does not help, my normal user is a member of the group video. Sometimes, and I do not have a clue when, the device works for some reason. Last time it worked was when I upgraded from kernel 3.16.7-ckt2-1 to 3.16.7-ckt4-3 and I thought the issue was gone, but it was not. Sometimes, after a reboot, it works perfectly again. $ lsmod | grep dvb dvb_usb_dib0700 139644 1 dib800060545 1 dvb_usb_dib0700 dib7000m 21743 1 dvb_usb_dib0700 dib009034003 1 dvb_usb_dib0700 dib007016978 2 dvb_usb_dib0700 dib7000p 35124 2 dvb_usb_dib0700 dib3000mc 21781 1 dvb_usb_dib0700 dibx000_common 17270 5 dib8000,dvb_usb_dib0700,dib3000mc,dib7000m,dib7000p dvb_usb22450 1 dvb_usb_dib0700 dvb_core 102010 3 dib8000,dvb_usb,dib7000p rc_core22404 4 dvb_usb,dvb_usb_dib0700,rc_dib0700_rc5 i2c_core 46012 12 drm,i2c_i801,dib0070,dib0090,dib8000,dvb_usb,dvb_usb_dib0700,nvidia,dib3000mc,dibx000_common,dib7000m,dib7000p usbcore 195340 9 btusb,uhci_hcd,snd_usb_audio,dvb_usb,dvb_usb_dib0700,snd_usbmidi_lib,ehci_hcd,ehci_pci,usbhid The lsmod output shows that dvb_usb_dib0700 is in use by something, but the device files are not opened by any process: $ lsof /dev/dvb/adapter0/demux0 $ lsof /dev/dvb/adapter0/dvr0 $ lsof /dev/dvb/adapter0/frontend0 $ lsof /dev/dvb/adapter0/net0 Unloading the module does not work at all: $ sudo rmmod dvb_usb_dib0700 rmmod: ERROR: Module dvb_usb_dib0700 is in use and $ sudo rmmod -f dvb_usb_dib0700 hangs and cannot be killed/stopped by Ctrl+C. dmesg shows [ 3750.585089] usbcore: deregistering interface driver dvb_usb_dib0700 [ 3960.108120] INFO: task rmmod:4281 blocked for more than 120 seconds. [ 3960.108127] Tainted: P RO 3.16.0-4-amd64 #1 [ 3960.108128] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 3960.108130] rmmod D 88008c566ef8 0 4281 4280 0x0004 [ 3960.108135] 88008c566aa0 0086 00013280 88011721ffd8 [ 3960.108138] 00013280 88008c566aa0 8800d8377000 8800d8a1a000 [ 3960.108140] 8800d3811278 7fff1797b922 8800d7da7800 [ 3960.108143] Call Trace: [ 3960.108158] [a11528c5] ? dvb_unregister_frontend+0xb5/0x110 [dvb_core] [ 3960.108162] [810a7840] ? prepare_to_wait_event+0xf0/0xf0 [ 3960.108166] [a117a7f5] ? dvb_usb_adapter_frontend_exit+0x35/0x60 [dvb_usb] [ 3960.108170] [a1179401] ? dvb_usb_exit+0x31/0xa0 [dvb_usb] [ 3960.108173] [a11794ab] ?
linux-2.6_2.6.32-48squeeze11_multi.changes ACCEPTED into squeeze-lts
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 18 Feb 2015 02:41:42 + Source: linux-2.6 Binary: linux-tools-2.6.32 linux-source-2.6.32 linux-doc-2.6.32 linux-manual-2.6.32 linux-patch-debian-2.6.32 firmware-linux-free linux-support-2.6.32-5 linux-base linux-libc-dev linux-headers-2.6.32-5-all linux-headers-2.6.32-5-all-alpha linux-headers-2.6.32-5-common linux-image-2.6.32-5-alpha-generic linux-headers-2.6.32-5-alpha-generic linux-image-2.6.32-5-alpha-smp linux-headers-2.6.32-5-alpha-smp linux-image-2.6.32-5-alpha-legacy linux-headers-2.6.32-5-alpha-legacy linux-headers-2.6.32-5-all-amd64 linux-image-2.6.32-5-amd64 linux-headers-2.6.32-5-amd64 linux-image-2.6.32-5-amd64-dbg linux-headers-2.6.32-5-common-openvz linux-image-2.6.32-5-openvz-amd64 linux-headers-2.6.32-5-openvz-amd64 linux-image-2.6.32-5-openvz-amd64-dbg linux-headers-2.6.32-5-common-vserver linux-image-2.6.32-5-vserver-amd64 linux-headers-2.6.32-5-vserver-amd64 linux-image-2.6.32-5-vserver-amd64-dbg linux-headers-2.6.32-5-common-xen linux-image-2.6.32-5-xen-amd64 linux-headers-2.6.32-5-xen-amd64 linux-image-2.6.32-5-xen-amd64-dbg xen-linux-system-2.6.32-5-xen-amd64 linux-headers-2.6.32-5-all-armel linux-image-2.6.32-5-iop32x linux-headers-2.6.32-5-iop32x linux-image-2.6.32-5-ixp4xx linux-headers-2.6.32-5-ixp4xx linux-image-2.6.32-5-kirkwood linux-headers-2.6.32-5-kirkwood linux-image-2.6.32-5-orion5x linux-headers-2.6.32-5-orion5x linux-image-2.6.32-5-versatile linux-headers-2.6.32-5-versatile linux-headers-2.6.32-5-all-hppa linux-image-2.6.32-5-parisc linux-headers-2.6.32-5-parisc linux-image-2.6.32-5-parisc-smp linux-headers-2.6.32-5-parisc-smp linux-image-2.6.32-5-parisc64 linux-headers-2.6.32-5-parisc64 linux-image-2.6.32-5-parisc64-smp linux-headers-2.6.32-5-parisc64-smp linux-headers-2.6.32-5-all-i386 linux-image-2.6.32-5-486 linux-headers-2.6.32-5-486 linux-image-2.6.32-5-686 linux-headers-2.6.32-5-686 linux-image-2.6.32-5-686-bigmem linux-headers-2.6.32-5-686-bigmem linux-image-2.6.32-5-686-bigmem-dbg linux-image-2.6.32-5-openvz-686 linux-headers-2.6.32-5-openvz-686 linux-image-2.6.32-5-openvz-686-dbg linux-image-2.6.32-5-vserver-686 linux-headers-2.6.32-5-vserver-686 linux-image-2.6.32-5-vserver-686-bigmem linux-headers-2.6.32-5-vserver-686-bigmem linux-image-2.6.32-5-vserver-686-bigmem-dbg linux-image-2.6.32-5-xen-686 linux-headers-2.6.32-5-xen-686 linux-image-2.6.32-5-xen-686-dbg xen-linux-system-2.6.32-5-xen-686 linux-headers-2.6.32-5-all-ia64 linux-image-2.6.32-5-itanium linux-headers-2.6.32-5-itanium linux-image-2.6.32-5-mckinley linux-headers-2.6.32-5-mckinley linux-image-2.6.32-5-vserver-itanium linux-headers-2.6.32-5-vserver-itanium linux-image-2.6.32-5-vserver-mckinley linux-headers-2.6.32-5-vserver-mckinley linux-headers-2.6.32-5-all-m68k linux-image-2.6.32-5-amiga linux-headers-2.6.32-5-amiga linux-image-2.6.32-5-atari linux-headers-2.6.32-5-atari linux-image-2.6.32-5-bvme6000 linux-headers-2.6.32-5-bvme6000 linux-image-2.6.32-5-mac linux-headers-2.6.32-5-mac linux-image-2.6.32-5-mvme147 linux-headers-2.6.32-5-mvme147 linux-image-2.6.32-5-mvme16x linux-headers-2.6.32-5-mvme16x linux-headers-2.6.32-5-all-mips linux-image-2.6.32-5-r4k-ip22 linux-headers-2.6.32-5-r4k-ip22 linux-image-2.6.32-5-r5k-ip32 linux-headers-2.6.32-5-r5k-ip32 linux-image-2.6.32-5-sb1-bcm91250a linux-headers-2.6.32-5-sb1-bcm91250a linux-image-2.6.32-5-sb1a-bcm91480b linux-headers-2.6.32-5-sb1a-bcm91480b linux-image-2.6.32-5-4kc-malta linux-headers-2.6.32-5-4kc-malta linux-image-2.6.32-5-5kc-malta linux-headers-2.6.32-5-5kc-malta linux-headers-2.6.32-5-all-mipsel linux-image-2.6.32-5-r5k-cobalt linux-headers-2.6.32-5-r5k-cobalt linux-headers-2.6.32-5-all-powerpc linux-image-2.6.32-5-powerpc linux-headers-2.6.32-5-powerpc linux-image-2.6.32-5-powerpc-smp linux-headers-2.6.32-5-powerpc-smp linux-image-2.6.32-5-powerpc64 linux-headers-2.6.32-5-powerpc64 linux-image-2.6.32-5-vserver-powerpc linux-headers-2.6.32-5-vserver-powerpc linux-image-2.6.32-5-vserver-powerpc64 linux-headers-2.6.32-5-vserver-powerpc64 linux-headers-2.6.32-5-all-s390 linux-image-2.6.32-5-s390x linux-headers-2.6.32-5-s390x linux-image-2.6.32-5-s390x-tape linux-image-2.6.32-5-vserver-s390x linux-headers-2.6.32-5-vserver-s390x linux-headers-2.6.32-5-all-sh4 linux-image-2.6.32-5-sh7751r linux-headers-2.6.32-5-sh7751r linux-image-2.6.32-5-sh7785lcr linux-headers-2.6.32-5-sh7785lcr linux-headers-2.6.32-5-all-sparc linux-image-2.6.32-5-sparc64 linux-headers-2.6.32-5-sparc64 linux-image-2.6.32-5-sparc64-smp linux-headers-2.6.32-5-sparc64-smp linux-image-2.6.32-5-vserver-sparc64 linux-headers-2.6.32-5-vserver-sparc64 linux-headers-2.6.32-5-all-sparc64 Architecture: all source Version: 2.6.32-48squeeze11 Distribution: squeeze-lts Urgency: medium Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Changed-By: Ben Hutchings b...@decadent.org.uk Description:
Bug#777759: linux-image-3.16.0-4-amd64: When I use bluetooth speakers for audio output Wi-Fi stops working
The upstream maintainer suggested to disable iwlwifi module option bt_coex. I created a file /etc/modprobe.d/iwlwifi.conf with the following content: options iwlwifi bt_coex_active=0 Since I did that and rebooted I can't reproduce this bug anymore. After my confirmation the upstream maintainer closed the bug. I don't really understand why. As I understand it he expects users to read the iwlwifi documentation and try to disable module option bt_coex when they have Wi-Fi Bluetooth problems. In my view it's a bug. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1424259642.2584.81.ca...@stefan-nagy.at
Processed: tagging 778463
Processing commands for cont...@bugs.debian.org: tags 778463 + upstream patch Bug #778463 [src:linux] linux-image-3.16.0-4-amd64: Atheros BT devices(ath3k) fail to work on USB3.0 buses Added tag(s) upstream and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 778463: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778463 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.142426379121832.transcr...@bugs.debian.org
Processing of linux-2.6_2.6.32-48squeeze11_multi.changes
linux-2.6_2.6.32-48squeeze11_multi.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.32-48squeeze11.dsc linux-2.6_2.6.32-48squeeze11.diff.gz linux-support-2.6.32-5_2.6.32-48squeeze11_all.deb firmware-linux-free_2.6.32-48squeeze11_all.deb linux-base_2.6.32-48squeeze11_all.deb linux-source-2.6.32_2.6.32-48squeeze11_all.deb linux-patch-debian-2.6.32_2.6.32-48squeeze11_all.deb linux-doc-2.6.32_2.6.32-48squeeze11_all.deb linux-manual-2.6.32_2.6.32-48squeeze11_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yo42n-00076m...@franck.debian.org
Bug#778372: linux-source-3.16: Boot-process hangs early on FSC Futro S500
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 15 Feb 2015 00:46:50 + Ben Hutchings b...@decadent.org.uk wrote: Is this also reproducible with linux-image-3.16.0-4-amd64? Are any additional patches applied to your custom kernel? Ben. Hi, Ben, actually I cannot tell, if it also happens with the stock kernel, because I have always been using my custom kernel-configuration. The hang also appears very rarely and I have not seen it on any other hardware yet. There were no other changes made to the kernel, because I don't read any sourcecode so far. But I plan to build a custom kernel, that enables CPU-frequency-scaling, maybe try initrd-ACPI-override first. I need to identify first which part of ACPI actually does the frequency-scaling. ACPI-information to extract this from was posted there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769778 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=DSDT.dsl.xz;att=1;bug=769778 Greetings Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTkf+wACgkQ5+rBHyUt5wsW/QCcDw4l3fZ4mx5UjeKNfKUPSuzW c9kAoIg0XCzaZ30I/JAYRwh4bLMjHOBw =9hkD -END PGP SIGNATURE-
Bug#778239: marked as done (Strange GRE packet forwarding slowness in 3.16.7-ckt2-1~bpo70+1)
Your message dated Wed, 18 Feb 2015 12:54:23 + with message-id 1424264063.23608.83.ca...@decadent.org.uk and subject line Re: Bug#778239: Strange GRE packet forwarding slowness in 3.16.7-ckt2-1~bpo70+1 has caused the Debian Bug report #778239, regarding Strange GRE packet forwarding slowness in 3.16.7-ckt2-1~bpo70+1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 778239: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778239 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.16.7-ckt2-1~bpo70+1 Severity: normal Hi! I have encountered a strange slowness on a router/packetfilter system (Wheezy 7.8 with backported kernel 3.16.7-ckt2-1~bpo70+1) of mine while forwarding GRE packets. The system in question does not terminate the GRE tunnels itself, it merely forwards those packets from one interface to another. This problem occurred after a reboot from a 3.12-bpo to the current 3.16.7-ckt2-1~bpo70+1. This problem reminded me of http://lists.openwall.net/netdev/2014/07/08/132 and http://patchwork.ozlabs.org/patch/324953/ and as described on those mailing-list exchanges, after disabling GSO and GRO on the involved interfaces, the forwarding speed for GRE packets was back to normal. What puzzles me is the fact that this bug should be fixed since 3.14.x and 3.15.x and sure enough, I can find the code changes from the patch from patchwork in the current kernel code in the Debian package. But the symptoms are the same as described: with active GRO/GSO the GRE tunnels max out at about 200kbit/s, after disabling GRO/GSO the possible bandwidth is only limited by the speed of the interfaces and connections involved. The hardware is like this: 14:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 14:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 0e:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 0e:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) ixgbe :14:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16 ixgbe :14:00.0: PCI Express bandwidth of 32GT/s available ixgbe :14:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) ixgbe :14:00.0: MAC: 2, PHY: 14, SFP+: 5, PBA No: FF-0FF ixgbe :14:00.0: 00:10:f3:33:d3:e8 ixgbe :14:00.0: Intel(R) 10 Gigabit Network Connection I created two LACP bonds (bond0 and bond1) out of two interfaces and on top of those two bonds there are several VLANs. The GRE packets are forwarded from a VLAN on bond0 to a VLAN on bond1. The regain the full bandwidth I disabled GSO and GRO on each of the four slave interfaces and both bond interfaces. Grüße, Sven. signature.asc Description: OpenPGP digital signature ---End Message--- ---BeginMessage--- Version: 3.16.7-ckt4-3 On Wed, 2015-02-18 at 10:46 +0100, Sven Hartge wrote: On 18.02.2015 09:17, Sven Hartge wrote: On 18.02.2015 02:25, Ben Hutchings wrote: On Wed, 2015-02-18 at 00:14 +0100, Sven Hartge wrote: On Thu, 12 Feb 2015 16:33:09 +0100 Sven Hartge s...@svenhartge.de wrote: I have encountered a strange slowness on a router/packetfilter system (Wheezy 7.8 with backported kernel 3.16.7-ckt2-1~bpo70+1) of mine while forwarding GRE packets. Could this be the fix for this bug: https://lists.ubuntu.com/archives/kernel-team/2014-December/052158.html gre: Set inner mac header in gro complete I don't know. I cannot confirm this myself right now, as the only systems affected are in production and I am not able to set up a lab installation right now. As that went into 3.16.7-ckt3, it is therefore included in the current packages in testing/unstable. Well, I've got a window for testing later today. I will report back, if this release fixes the problem I am seeing. Yes, this patch fixes this problem for me. Should I close the bug or do you want to do it? I'm closing it. Ben. -- Ben Hutchings To err is human; to really foul things up requires a computer. signature.asc Description: This is a digitally signed message part ---End Message---
