Bug#679519: Suddenly unable to replicate problem (Re: usbhid causes crashes in applications by memory corruption)
If you came here through an Internet search and are having similar problems, upgrading my kernel to a custom-compiled 3.5.0 seems to have fixed iwlwifi, provided the module has the following options: options iwlwifi 11n_disable=1 wd_disable=1 swcrypto=1 power_save=0 5ghz_disable=1 Development on iwlwifi seems to follow the 'rapid prototyping' approach, so it's always worth checking for bleeding-edge kernel source. On 25/07/12 13:00, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 679...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50101059.3000...@annaghvarn.plus.com
Bug#679519: Suddenly unable to replicate problem (Re: usbhid causes crashes in applications by memory corruption)
The laptop (Samsung NC110) which had this problem no longer has it, for no obvious reason. The kernel is unchanged. The one difference is that I was trying to boot a Knoppix installation from USB stick to see if it also had the usb problem and when the laptop couldn't see the device, I selected "Set BIOS defaults". This particular BIOS has very few user settings and the only one which was not default was to select AHCI mode for the SATA adaptor. After setting the defaults, I changed that one back. However, the USBHID problem has now gone away... BUT the iwlwifi is no longer working! (It seems to have exposed a known bug.) This looks like a BIOS bug of some kind, although I have no idea what can be happening. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500fdd2c.3050...@annaghvarn.plus.com
Bug#679519: Problem still occurs in linux-3.4-trunk-amd64 from Debian experimental (Re: usbhid causes crashes in applications by memory corruption)
And did you plug in a new HID device? Yes. Just to be clear, nothing untoward happens with usbhid.ko simply loaded, e.g directly via modprobe or automagically when a device is plugged in. But the first event, be it a mouse movement or a keystroke, causes particular applications to crash. I've tried various different USB hardware (including putting a hub in between) and the result is always the same. Can you test Linux 3.4, available from the experimental suite? If that still has the problem, we can pass this on to the upstream developers; if not, we can try to work out where it was fixed. Yes. I've now installed linux-3.4-trunk-amd64 from Debian experimental, and the same thing happens, reliably every time. For reference, when I just now crashed both cairo-dock and audacious from the same mouse movement (apparently), they report the following, with different addresses. I don't know what that means, if anything. *** glibc detected *** audacious: malloc(): memory corruption: 0x00f167d0 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x75b46)[0x7f6357659b46] /lib/x86_64-linux-gnu/libc.so.6(+0x78bb3)[0x7f635765cbb3] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7f635765e960] *** glibc detected *** cairo-dock: malloc(): memory corruption: 0x7f3fcc284020 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x75b46)[0x7f3fe1e77b46] /lib/x86_64-linux-gnu/libc.so.6(+0x78bb3)[0x7f3fe1e7abb3] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7f3fe1e7c960] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ffb1008.2040...@annaghvarn.plus.com
Bug#679519: unable to obtain better info (Re: usbhid causes crashes in applications by memory corruption))
After building a kernel with X86_CHECK_BIOS_CORRUPTION enabled, I set it to scan (almost) as advised. No corruption of the low memory was reported after running some hours either with or without usbhid loaded. (Booting with memory_corruption_check_size=640K caused an immediate kernel panic -- early exception 08 --though. Changing it to 620k allowed the boot to continue normally.) I took the opportunity to include kmemleak in the new kernel as well. After some uptime, one orphan object was always found, but it happened either with or without usbhid ever having been loaded. To judge from the traceback it was something ACPI-related anyway. So, basically, no progress. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ff1e897.2040...@annaghvarn.plus.com
Bug#679519: same on non-RT kernel (Re: usbhid causes crashes in applications by memory corruption)
Is that a standard (non-realtime) kernel? If not, can you also test a standard kernel configuration (linux-image-3.2.0-3-amd64)? Identical behaviour on linux-image-3.2.0-3-amd64 Please try booting with the extra kernel parameters: memory_corruption_check=1 memory_corruption_check_size=640K memory_corruption_check_period=5 Does that avoid the problem, and if so what does the kernel log show after you plug in the device? It seems that X86_CHECK_BIOS_CORRUPTION is disabled in the Debian kernels. I'm compiling a custom one with it enabled and will post any significant results. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fedd809.3090...@annaghvarn.plus.com
Bug#679519: linux-image-3.2.0-3-rt-amd64: usbhid causes crashes in applications by memory corruption
Package: src:linux Version: 3.2.21-2 X-Mailer: reportbug 4.12.6 Date: Fri, 29 Jun 2012 11:26:06 +0100 Severity: normal Tags: upstream When I plug in a USB mouse (or keyboard, but I don't normally do that) into this laptop, the first event -- mouse movement -- causes some applications to crash with a memory corruption message from malloc. Applications which reliably crash every time are audacious, cairo-dock and zenity. However, if re-started, they may or may not crash again. If usbhid is blacklisted, no crashes occur, although, obviously, the mouse does not work. I can use the built-in trackpad. I've tried a "vanilla" kernel compiled from source (although not the Debian way; sorry) and the result is the same. I don't know much about kernel modules and memory, so I don't know how to provide more useful information. Obviously usbhid must be in use on every linux desktop or laptop in the world, and I've found no other reports of similar problems. Am I the only person using 64-bit linux on a dual-core Intel Atom? Here is a backtrace from audacious: *** glibc detected *** audacious: malloc(): memory corruption: 0x01b79830 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x75b46)[0x7fd0f8eebb46] /lib/x86_64-linux-gnu/libc.so.6(+0x78bb3)[0x7fd0f8eeebb3] /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x70)[0x7fd0f8ef0960] /usr/lib/libXi.so.6(+0x9a84)[0x7fd0f786aa84] /usr/lib/x86_64-linux-gnu/libX11.so.6(_XEnq+0xd5)[0x7fd0f7ab7615] /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x44563)[0x7fd0f7ab4563] /usr/lib/x86_64-linux-gnu/libX11.so.6(_XEventsQueued+0x55)[0x7fd0f7ab4fa5] /usr/lib/x86_64-linux-gnu/libX11.so.6(XPending+0x5d)[0x7fd0f7aa663d] /usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x4b078)[0x7fd0f9b26078] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_check+0x1a3)[0x7fd0fa836643] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4aad6)[0x7fd0fa836ad6] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7fd0fa836f9a] /usr/lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_main+0x85)[0x7fd0f9edc2d5] audacious[0x40e030] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7fd0f8e94ead] audacious[0x40e5f1] === Memory map: 0040-0044 r-xp 08:01 387801 /usr/bin/audacious 0063f000-0064 r--p 0003f000 08:01 387801 /usr/bin/audacious 0064-00643000 rw-p 0004 08:01 387801 /usr/bin/audacious 00643000-00646000 rw-p 00:00 0 0176-01b94000 rw-p 00:00 0 [heap] 7fd0cea2b000-7fd0ceaba000 r--p 08:01 391784 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf 7fd0ceaba000-7fd0d2032000 r--p 08:01 456191 /usr/share/icons/gnome/icon-theme.cache 7fd0d2032000-7fd0d2ad7000 r--p 08:01 417515 /usr/share/icons/hicolor/icon-theme.cache 7fd0d2ad7000-7fd0d2b72000 r--p 08:01 391779 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf 7fd0d2b72000-7fd0d2b74000 r-xp 08:01 598420 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7fd0d2b74000-7fd0d2d73000 ---p 2000 08:01 598420 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7fd0d2d73000-7fd0d2d74000 r--p 1000 08:01 598420 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7fd0d2d74000-7fd0d2d75000 rw-p 2000 08:01 598420 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7fd0d2d75000-7fd0d2da3000 r-xp 08:01 492393 /usr/lib/x86_64-linux-gnu/libbluray.so.1.1.0 7fd0d2da3000-7fd0d2fa3000 ---p 0002e000 08:01 492393 /usr/lib/x86_64-linux-gnu/libbluray.so.1.1.0 7fd0d2fa3000-7fd0d2fa4000 r--p 0002e000 08:01 492393 /usr/lib/x86_64-linux-gnu/libbluray.so.1.1.0 7fd0d2fa4000-7fd0d2fa5000 rw-p 0002f000 08:01 492393 /usr/lib/x86_64-linux-gnu/libbluray.so.1.1.0 7fd0d2fa5000-7fd0d2fa7000 r-xp 08:01 468700 /lib/x86_64-linux-gnu/libutil-2.13.so 7fd0d2fa7000-7fd0d31a6000 ---p 2000 08:01 468700 /lib/x86_64-linux-gnu/libutil-2.13.so 7fd0d31a6000-7fd0d31a7000 r--p 1000 08:01 468700 /lib/x86_64-linux-gnu/libutil-2.13.so 7fd0d31a7000-7fd0d31a8000 rw-p 2000 08:01 468700 /lib/x86_64-linux-gnu/libutil-2.13.so 7fd0d31a8000-7fd0d31b6000 r-xp 08:01 493214 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7fd0d31b6000-7fd0d33b5000 ---p e000 08:01 493214 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7fd0d33b5000-7fd0d33b6000 r--p d000 08:01 493214 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7fd0d33b6000-7fd0d33b7000 rw-p e000 08:01 493214 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7fd0d33b7000-7fd0d33cf000 r-xp 08:01 492405 /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so 7fd0d33cf000-7fd0d35ce000 ---p 00018000 08:01 492405 /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so 7fd0d35ce000-7fd0d35cf000 r--p 00017000 08:01 492405 /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so 7fd0d35cf000-7fd0d35d rw-p 00018000 08:01 492405 /usr/lib/x86_64-linux-gnu/gvfs
Bug#668616: workaround by reverting /usr/share/initramfs-tools/hook-functions to 0.99
I copied /usr/share/initramfs-tools/hook-functions from a machine which had not been updated and this allowed update-initramfs to build a new, bootable ramdisk. Note For Googlers: I believe that the closed bug 659948 is a duplicate of this one, and it suggests "ln -s / /rootfs" as a workaround. This allows update-initramfs to complete, but the resultant ramdisk is not bootable - it doesn't refer to a real root file system. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc9fd68.9040...@annaghvarn.plus.com
Bug#665881: Fix available in latest kernel. (Re: ath5k reports "gain calibration timeout" errors and loses connectivity)
Replacing the ath5k driver code with the updated code from Linux 3.4-rc1 fixes this problem for me. (Specifically drivers/net/wireless/ath/ath5k/ath5k.h, base.c and phy.c - nothing else changed from 3.3.0) On 02/04/12 14:36, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 665...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8428a8.1030...@annaghvarn.plus.com
Bug#665881: not Debian-specific
I have just compiled a custom 3.3.0 kernel for an Acer netbook, previously running 3.0.0, and see the same problem as reported by Hans. In my case, after 36 hours of uptime with the new kernel, the ath5k began to report constant "gain calibration timeout" errors and connectivity was lost. Rebooting with the previous kernel without powering off did not restore wireless connectivity. The old ath5k was reporting "gain calibration timeout" too. Powering off and on, and booting the old 3.0 kernel seems to have restored correct functionality. Just to be clear, both kernels are compiled from source from kernel.org, not Debian builds. Steve -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f78b5f4.5030...@annaghvarn.plus.com
Bug#627933: Regression: hot plugging sdhc card on Acer Aspire One
I can confirm the same behaviour on the same hardware with kernel 3.0.0-1-686-pae from unstable. (In the "workaround" situation of booting with a card in the right-hand slot, everything works as expected: both cards can be inserted and ejected and generate the expected udev events. Subsequently, the first card to be inserted is always /dev/mmcblk0 regardless of physical postion.) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e3c2e66.3000...@annaghvarn.plus.com
