Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753868Ab2HOJnW (ORCPT ); Wed, 15 Aug 2012 05:43:22 -0400 Received: from smtprelay.restena.lu ([158.64.1.62]:59534 "EHLO smtprelay.restena.lu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752769Ab2HOJnT convert rfc822-to-8bit (ORCPT ); Wed, 15 Aug 2012 05:43:19 -0400 Date: Wed, 15 Aug 2012 11:42:36 +0200 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= To: Jiri Kosina Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org Subject: Re: [PATCH 0/7] HID: picoLCD updates Message-ID: <20120815114236.0f7db40e@neptune.home> In-Reply-To: References: <20120730213656.0a9f6d30@neptune.home> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5647 Lines: 110 Hi Jiri, On Wed, 15 August 2012 Jiri Kosina wrote: > On Mon, 30 Jul 2012, Bruno Prémont wrote: > > Hi, > > > > This series updates picoLCD driver: > > - split the driver functions into separate files which get included > > depending on Kconfig selection > > (implementation for CIR using RC_CORE will follow later) > > - drop private framebuffer refcounting in favor of refcounting added > > to fb_info some time ago > > - fix various bugs issues > > - disabled firmware version checking in probe() as it does not work > > anymore since commit 4ea5454203d991ec85264f64f89ca8855fce69b0 > > [HID: Fix race condition between driver core and ll-driver] > > I have now applied the series to my 'picolcd' branch, except for 6/7, > please see the comment I sent to it separately. Will respin that one soon > > Note: I still get weird behavior on quick unbind/bind sequences > > issued via sysfs (CONFIG_SMP=n system) that are triggered by framebuffer > > support and apparently more specifically fb_defio part of it. > > > > Unfortunately I'm out of ideas as to how to track down the problem which > > shows either as SLAB corruption (detected with SLUB debugging, e.g. > > Would be nice to have this sorted out before the next merge window indeed, > so that it can go in together with the rest of the changes. > > > > > [ 6383.521833] ============================================================================= > > [ 6383.530020] BUG kmalloc-64 (Not tainted): Object already free > > [ 6383.530020] ----------------------------------------------------------------------------- > > [ 6383.530020] > > [ 6383.530020] INFO: Slab 0xdde0ea20 objects=51 used=40 fp=0xcef516e0 flags=0x40000080 > > [ 6383.530020] INFO: Object 0xcef51190 @offset=400 fp=0xcef51f50 > > [ 6383.530020] > > [ 6383.530020] Bytes b4 cef51180: cc cc cc cc d0 12 f5 ce 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ > > [ 6383.530020] Object cef51190: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > > [ 6383.530020] Object cef511a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > > [ 6383.530020] Object cef511b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > > [ 6383.530020] Object cef511c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. > > [ 6383.530020] Redzone cef511d0: bb bb bb bb .... > > [ 6383.530020] Padding cef511d8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ > > [ 6383.530020] Pid: 1922, comm: bash Not tainted 3.5.0-jupiter-00003-g8d858b1-dirty #2 > > [ 6383.530020] Call Trace: > > [ 6383.530020] [] print_trailer+0x11c/0x130 > > [ 6383.530020] [] object_err+0x35/0x40 > > [ 6383.530020] [] free_debug_processing+0x99/0x200 > > [ 6383.530020] [] __slab_free+0x2e/0x280 > > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > > [ 6383.530020] [] ? __usbhid_submit_report+0xc0/0x3c0 > > [ 6383.530020] [] ? kfree+0xfa/0x110 > > [ 6383.530020] [] ? picolcd_debug_out_report+0x8c4/0x8e0 [hid_picolcd] > > [ 6383.530020] [] kfree+0xfa/0x110 > > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > > [ 6383.530020] [] ? hid_submit_out+0xa4/0x120 > > [ 6383.530020] [] hid_submit_out+0xa4/0x120 > > [ 6383.530020] [] __usbhid_submit_report+0x158/0x3c0 > > [ 6383.530020] [] usbhid_submit_report+0x1b/0x30 > > [ 6383.530020] [] picolcd_fb_reset+0xb9/0x180 [hid_picolcd] > > [ 6383.530020] [] picolcd_init_framebuffer+0x20d/0x2e0 [hid_picolcd] > > [ 6383.530020] [] picolcd_probe+0x3cc/0x580 [hid_picolcd] > > [ 6383.530020] [] hid_device_probe+0x67/0xf0 > > [ 6383.530020] [] ? driver_sysfs_add+0x57/0x80 > > [ 6383.530020] [] driver_probe_device+0xbd/0x1c0 > > [ 6383.530020] [] ? hid_match_device+0x7b/0x90 > > [ 6383.530020] [] driver_bind+0x75/0xd0 > > [ 6383.530020] [] ? driver_unbind+0x90/0x90 > > [ 6383.530020] [] drv_attr_store+0x27/0x30 > > [ 6383.530020] [] sysfs_write_file+0xac/0xf0 > > [ 6383.530020] [] vfs_write+0x9c/0x130 > > [ 6383.530020] [] ? sys_dup3+0x11f/0x160 > > [ 6383.530020] [] ? sysfs_poll+0x90/0x90 > > [ 6383.530020] [] sys_write+0x3d/0x70 > > [ 6383.530020] [] sysenter_do_call+0x12/0x26 > > So I am wondering whether the path this happens on is > > if (!test_bit(HID_OUT_RUNNING, &usbhid->iofl)) { > usbhid_restart_out_queue(usbhid); > > in __usbhid_submit_report(). It would then indicate perhaps some race with > iofl handling. Huh, that specific test_bit hunk I can't find in __usbhid_submit_report, is that 3.6 material? I'm running my tests against 3.5... The nearest I have is: if (!test_bit(HID_OUT_RUNNING, &usbhid->iofl)) if (!irq_out_pump_restart(hid)) set_bit(HID_OUT_RUNNING, &usbhid->iofl); > Could you please stick some printk() just before and after this > usbhid_restart_out_queue() call, so that we know that it's this triggering > it? Thanks, Bruno -- 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/