From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932363AbZE0Szk (ORCPT ); Wed, 27 May 2009 14:55:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757914AbZE0Szd (ORCPT ); Wed, 27 May 2009 14:55:33 -0400 Received: from mx-out2.daemonmail.net ([216.104.160.39]:40734 "EHLO mx-out2.daemonmail.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbZE0Szc (ORCPT ); Wed, 27 May 2009 14:55:32 -0400 From: "Michael S. Zick" Reply-To: lkml@morethan.org To: Andi Kleen Subject: Re: LOCK prefix on uni processor has its use Date: Wed, 27 May 2009 13:55:28 -0500 User-Agent: KMail/1.9.9 Cc: Harald Welte , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , linux-kernel@vger.kernel.org, Alan Cox References: <200905221139.26941.lkml@morethan.org> <200905271322.41768.lkml@morethan.org> <200905271333.21304.lkml@morethan.org> In-Reply-To: <200905271333.21304.lkml@morethan.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905271355.31237.lkml@morethan.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed May 27 2009, Michael S. Zick wrote: > On Wed May 27 2009, Michael S. Zick wrote: > > On Wed May 27 2009, Andi Kleen wrote: > > > Harald Welte writes: > > > > * All X86 instructions except rep-strings are atomic wrt interrupts. > > > > * The lock prefix has uses on a UP processor: It keeps DMA devices from > > > > interfering with a read-modify-write sequence > > > > > > In theory yes, but not in Linux -- normal drivers simply don't use LOCK in any way > > > on a UP kernel. > > > Note that there are there spin_{lock,unlock} symbols in the stack trace. This build has the 'lock' in LOCK_PREFIX. Mike > > > We discussed exactly this in the earlier subthread :) > > > > > > > Now the question is: Is this a valid operation of a driver? Should the driver > > > > do such things, or is such a driver broken? > > > > > > The driver is broken because if it relies on this it will not work on a UP kernel. > > > Also it's not portable and in general a bad idea. > > > > > > > When would that occur? I'm trying > > > > to come up with a case, but typically you e.g. allocate some DMA buffer and > > > > then don't touch it until the hardware has processed it. > > > > > > Is it known which driver has this problem? > > > > > > -Andi (who finds hpa's "timing theory" to be more believable anyways) > > > > > > > I still have not come up with a solid, testable, theory to explain the > > order of magnitude in up-time before the kernel locks with/with-out 'lock'. > > > > But we are definitely pecking around the edges of the problem. ;) > > > > Today's lockdep build has just passed its previous record by hard-coding > > the pci cache line size to be the same as the cpu's cache line size. (a WAFG). > > Until we hear back from the VIA-CPU people, I just guessed that since the > > chip set was designed for use with the processor... > > > > Ah, so - some information - - - > (caused by un-plug/re-plug usb mouse while ehci-hcd was caught in its failure > reporting loop) > > ehci_hcd 0000:00:10.4: port 6 resume error -19 > hub 1-0:1.0: hub_port_status failed (err = -32) > hub 1-0:1.0: connect-debounce failed, port 6 disabled > hub 1-0:1.0: over-current change on port 1 > ehci_hcd 0000:00:10.4: HC died; cleaning up > irq 23: nobody cared (try booting with the "irqpoll" option) > Pid: 2277, comm: syslogd Not tainted 2.6.30-rc7-ce1200v-09147lk-db #29 > Call Trace: > [] ? __report_bad_irq+0x24/0x90 > [] ? note_interrupt+0x145/0x180 > [] ? handle_fasteoi_irq+0xaf/0xe0 > [] ? handle_irq+0x17/0x20 > [] ? do_IRQ+0x3a/0xa0 > [] ? trace_hardirqs_on_caller+0x6b/0x170 > [] ? common_interrupt+0x2e/0x34 > [] ? __do_softirq+0x42/0x110 > [] ? tick_program_event+0x14/0x20 > [] ? hrtimer_interrupt+0xcc/0x1d0 > [] ? do_softirq+0x45/0x50 > [] ? irq_exit+0x6a/0x80 > [] ? smp_apic_timer_interrupt+0x49/0x80 > [] ? apic_timer_interrupt+0x2f/0x34 > [] ? lock_acquire+0x8e/0xa0 > [] ? start_this_handle+0x6a/0x3c0 > [] ? _spin_lock+0x3d/0x70 > [] ? start_this_handle+0x6a/0x3c0 > [] ? start_this_handle+0x6a/0x3c0 > [] ? kmem_cache_alloc+0x98/0x100 > [] ? lockdep_init_map+0x46/0x130 > [] ? journal_start+0xa0/0x100 > [] ? grab_cache_page_write_begin+0x30/0xc0 > [] ? up_read+0x14/0x30 > [] ? ext3_write_begin+0x98/0x200 > [] ? generic_file_buffered_write+0x108/0x300 > [] ? current_fs_time+0x13/0x20 > [] ? __generic_file_aio_write_nolock+0x24a/0x550 > [] ? __mutex_lock_common+0x2f0/0x3f0 > [] ? generic_file_aio_write+0x49/0xd0 > [] ? generic_file_aio_write+0x5e/0xd0 > [] ? validate_chain+0xe9/0x1000 > [] ? ext3_file_write+0x30/0xc0 > [] ? ext3_file_write+0x0/0xc0 > [] ? do_sync_readv_writev+0xbf/0x100 > [] ? lock_release_holdtime+0x6e/0xf0 > [] ? autoremove_wake_function+0x0/0x50 > [] ? might_fault+0x4f/0xa0 > [] ? security_file_permission+0xc/0x10 > [] ? rw_verify_area+0x66/0xd0 > [] ? rw_copy_check_uvector+0x7e/0x100 > [] ? do_readv_writev+0xaa/0x190 > [] ? ext3_file_write+0x0/0xc0 > [] ? vfs_writev+0x3c/0x50 > [] ? sys_writev+0x47/0x80 > [] ? sysenter_do_call+0x12/0x36 > handlers: > [] (usb_hcd_irq+0x0/0x90) > Disabling IRQ #23 > hub 1-0:1.0: hub_port_status failed (err = -19) > hub 1-0:1.0: connect-debounce failed, port 1 disabled > hub 1-0:1.0: cannot disable port 1 (err = -19) > hub 1-0:1.0: hub_port_status failed (err = -19) > hub 1-0:1.0: hub_port_status failed (err = -19) > hub 1-0:1.0: hub_port_status failed (err = -19) > hub 1-0:1.0: hub_port_status failed (err = -19) > hub 1-0:1.0: hub_port_status failed (err = -19) > usb 1-5: USB disconnect, address 3 > ehci_hcd 0000:00:10.4: force halt; handhake dc724014 00004000 00004000 -> -19 > > ================================= > [ INFO: inconsistent lock state ] > 2.6.30-rc7-ce1200v-09147lk-db #29 > --------------------------------- > inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. > hd-audio0/51 [HC0[0]:SC1[1]:HE1:SE0] takes: > (&irq_desc_lock_class){?.-...}, at: [] try_one_irq+0x21/0x130 > {IN-HARDIRQ-W} state was registered at: > [] 0xffffffff > irq event stamp: 95629480 > hardirqs last enabled at (95629480): [] _spin_unlock_irq+0x20/0x40 > hardirqs last disabled at (95629479): [] _spin_lock_irq+0xd/0x70 > softirqs last enabled at (95626922): [] do_softirq+0x45/0x50 > softirqs last disabled at (95629475): [] do_softirq+0x45/0x50 > > other info that might help us debug this: > 3 locks held by hd-audio0/51: > #0: ((bus->workq_name)){+.+...}, at: [] worker_thread+0x192/0x2d0 > #1: (&chip->irq_pending_work){+.+...}, at: [] worker_thread+0x192/0x2d0 > #2: (kernel/irq/spurious.c:21){+.-...}, at: [] run_timer_softirq+0xe0/0x1f0 > > stack backtrace: > Pid: 51, comm: hd-audio0 Not tainted 2.6.30-rc7-ce1200v-09147lk-db #29 > Call Trace: > [] ? print_usage_bug+0x174/0x1c0 > [] ? mark_lock+0x59b/0x5d0 > [] ? validate_chain+0x148/0x1000 > [] ? check_usage_backwards+0x0/0x90 > [] ? __lock_acquire+0x237/0x6a0 > [] ? lock_acquire+0x7b/0xa0 > [] ? try_one_irq+0x21/0x130 > [] ? _spin_lock+0x3d/0x70 > [] ? try_one_irq+0x21/0x130 > [] ? try_one_irq+0x21/0x130 > [] ? poll_spurious_irqs+0x43/0x60 > [] ? run_timer_softirq+0x16b/0x1f0 > [] ? run_timer_softirq+0xe0/0x1f0 > [] ? poll_spurious_irqs+0x0/0x60 > [] ? __do_softirq+0x68/0x110 > [] ? tick_program_event+0x14/0x20 > [] ? hrtimer_interrupt+0xcc/0x1d0 > [] ? do_softirq+0x45/0x50 > [] ? irq_exit+0x6a/0x80 > [] ? smp_apic_timer_interrupt+0x49/0x80 > [] ? apic_timer_interrupt+0x2f/0x34 > [] ? _spin_unlock_irq+0x26/0x40 > [] ? azx_irq_pending_work+0x92/0x120 > [] ? worker_thread+0x192/0x2d0 > [] ? azx_irq_pending_work+0x0/0x120 > [] ? worker_thread+0x1f5/0x2d0 > [] ? worker_thread+0x192/0x2d0 > [] ? autoremove_wake_function+0x0/0x50 > [] ? worker_thread+0x0/0x2d0 > [] ? kthread+0x47/0x80 > [] ? kthread+0x0/0x80 > [] ? kernel_thread_helper+0x7/0x10 > > Enjoy > > -- > 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/ > >