Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757028Ab1DHVs6 (ORCPT ); Fri, 8 Apr 2011 17:48:58 -0400 Received: from sour.ops.eusc.inter.net ([84.23.254.154]:65219 "EHLO sour.ops.eusc.inter.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515Ab1DHVs4 (ORCPT ); Fri, 8 Apr 2011 17:48:56 -0400 X-Greylist: delayed 1332 seconds by postgrey-1.27 at vger.kernel.org; Fri, 08 Apr 2011 17:48:56 EDT X-Trace: 4d7c73656261737469616e2e6b6c6f736b6140736e6166752e64657c38352e3137 382e38302e3233327c3151384a43552d303030456f482d47497c31333032323938 303032 Message-ID: <4D9F7D90.4040302@snafu.de> Date: Fri, 08 Apr 2011 23:26:40 +0200 From: Oncaphillis Reply-To: oncaphillis@snafu.de User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kernel development list Subject: Kernel BUG in 2.6.38.2 slub.c when communicating via usb Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 85.178.80.232 X-SA-Exim-Mail-From: oncaphillis@snafu.de X-SA-Exim-Scanned: No (on sour.ops.eusc.inter.net); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4481 Lines: 106 We are experiencing sporadic kernel bug messages and total kernel freezes during usb communication via libusb-1.0.8 The communication should work as follows: - Send a 2 byte sequence to endpoint #4 selecting the register to which the command should be send - The device should answer with the same two byte sequence on Endpoint #8 - Send a 2 byte command sequence to endpoint #4 - The device should acknowledge the command by returning the same two bytes on endpoint #8 - The device may also initiate inbound data transfer on endpoint #8 to inform about status changes. We send the register selection and command data via libusb_bulk_transfer() with a time out of 10000 ms and read the reply via libusb_interrupt_transfer with a time out of 100 ms as specified for our device We also periodically read on endpoint #8 to get the status changes. Sometimes we run into the following situation. - We send the 2 byte register selection sequence via libusb_bulk_transfer - We try to read the response via libusb_interrupt_transfer but run into a time out or read junk (seems to be zero) - If we look at the USB communication via USB analyser we actually see the inbound transfer of the correct two bytes and the ACK by the kernel, but this data never ends up as a valid result of libusb_interrupt_transfer. Sometimes we get a timeout, sometimes we read junk. - Since we got a time out or junk data we retry the read up to 30 times. Within this polling we see the following kernel bug message in dmesg. Sometimes the kernel freezes completely This BUG message is actually from a 2.6.30.10 kernel, but the message is almost the same referring to a different line in slug.c wher e it seems to complain that someone tries to free memory that has never been allocated. The stack trace varies even for the same kernel versions. The whole issue seems to vanish if the libusb has been compiled with --enable-timerfd The chipset on the host side is an Intel 82801I. The device Is A Sparta Xilinx FPGA which seems to talk nicely to windows A detailed screen shot of a USB analyzation can be found under http://www.oncaphillis.net/usb.pdf ------------[ cut here ]------------ kernel BUG at mm/slub.c:2808! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/bConfigurationValue CPU 3 Modules linked in: Pid: 4314, comm: rrdupdate Not tainted 2.6.30.10 #2 To Be Filled By O.E.M. RIP: 0010:[] [] kfree+0x7c/0xdb RSP: 0000:ffff880077de1d38 EFLAGS: 00010246 RAX: 4000000000000000 RBX: ffff88007a07a772 RCX: ffff88007acea7e0 RDX: ffffe20000000000 RSI: ffffe20001ab1ab0 RDI: ffff88007a07a772 RBP: ffff880077de1d58 R08: 0000000000000000 R09: 0000000000000008 R10: 00000000f7f5e000 R11: 00000000f7f5d5b8 R12: ffff88007c081c80 R13: ffffffff802c9cd8 R14: 00000000f7f5e000 R15: ffff880077de1f58 FS: 0000000000000000(0000) GS:ffff88000105b000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b CR2: 00000000f7f5d5b8 CR3: 0000000079940000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rrdupdate (pid: 4314, threadinfo ffff880077de0000, task ffff8800790d8b40) Stack: 00000000f7f5e000 0000000000000000 ffff88007c081c80 ffff880077d77800 ffff880077de1e48 ffffffff802c9cd8 0000000000000080 ffff880077d77800 0000000000000001 00000000f7f3d000 ffff880077df2000 ffff880077df2000 Call Trace: [] load_elf_binary+0xfda/0x1862 [] ? compat_copy_strings+0x1b8/0x1ca [] search_binary_handler+0xb0/0x23f [] compat_do_execve+0x246/0x36f [] sys32_execve+0x3e/0x5c [] ia32_ptregs_common+0x25/0x4c Code: ba 00 00 00 00 00 e2 ff ff 48 c1 e8 0c 48 6b f0 38 48 01 d6 66 83 3e 00 79 04 48 8b 76 10 48 8b 06 84 c0 78 14 66 a9 00 c0 75 04 <0f> 0b eb fe 48 89 f7 e8 35 13 fe ff eb 48 48 8b 4d 08 48 8b 7e RIP [] kfree+0x7c/0xdb RSP ---[ end trace ba800619f794f281 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/