From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750813AbWFEVCW (ORCPT ); Mon, 5 Jun 2006 17:02:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750819AbWFEVCW (ORCPT ); Mon, 5 Jun 2006 17:02:22 -0400 Received: from mx1.redhat.com ([66.187.233.31]:38369 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1750813AbWFEVCV (ORCPT ); Mon, 5 Jun 2006 17:02:21 -0400 Date: Mon, 5 Jun 2006 17:02:10 -0400 From: Dave Jones To: Andrew Morton Cc: linux-kernel@vger.kernel.org, arjan@infradead.org, mingo@redhat.com Subject: Re: 2.6.17-rc5-mm3 Message-ID: <20060605210210.GG6143@redhat.com> Mail-Followup-To: Dave Jones , Andrew Morton , linux-kernel@vger.kernel.org, arjan@infradead.org, mingo@redhat.com References: <20060603232004.68c4e1e3.akpm@osdl.org> <20060605194844.GA6143@redhat.com> <20060605130626.3f2917a2.akpm@osdl.org> <20060605200947.GC6143@redhat.com> <20060605204456.GF6143@redhat.com> <20060605135354.81dc8449.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060605135354.81dc8449.akpm@osdl.org> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 05, 2006 at 01:53:54PM -0700, Andrew Morton wrote: > > > > Try reverting debug-shared-irqs.patch, or disable the sound driver? > > > Will turn off the sound driver, and see what happens. > > Win! It now boots. > So does Windows 95. Hey, it's my turn to play "optimist" today. :) > > I blew it up really easy with a socket-fuzzer though. > > (http://people.redhat.com/davej/sfuzz.c) > > But it kept running OK, yes? Yep, still ticking along (for now). > > [ 874.865028] ====================================== > > [ 874.943738] [ BUG: bad unlock ordering detected! ] > > [ 875.002919] -------------------------------------- > > [ 875.062134] sfuzz/23915 is trying to release lock (&sctp_port_alloc_lock) at: > > [ 875.149619] [] sctp_get_port_local+0xd0/0x285 [sctp] > > [ 875.222636] but the next lock to release is: > > [ 875.276019] (&sctp_port_hashtable[i].lock){-...}, at: [] sctp_get_port_local+0x90/0x285 [sctp] > > [ 875.393031] > > [ 875.393032] other info that might help us debug this: > > [ 875.476583] 1 locks held by sfuzz/23915: > > [ 875.526247] #0: (&sctp_port_alloc_lock){-...}, at: [] sctp_get_port_local+0x5b/0x285 [sctp] > > [ 875.641621] > > [ 875.641623] stack backtrace: > > [ 875.699891] [] show_trace_log_lvl+0x54/0xfd > > [ 875.764425] [] show_trace+0xd/0x10 > > [ 875.819622] [] dump_stack+0x19/0x1b > > [ 875.875924] [] lockdep_release+0x150/0x2d1 > > [ 875.939610] [] _spin_unlock+0x16/0x20 > > [ 875.998171] [] sctp_get_port_local+0xd0/0x285 [sctp] > > [ 876.072345] [] sctp_do_bind+0x9a/0x158 [sctp] > > [ 876.139315] [] sctp_autobind+0x3c/0x44 [sctp] > > [ 876.206310] [] sctp_inet_listen+0xe9/0x139 [sctp] > > [ 876.277539] [] sys_listen+0x4a/0x65 > > [ 876.334730] [] sys_socketcall+0x98/0x186 > > [ 876.397175] [] syscall_call+0x7/0xb > > This is a really really fussy "BUG", IMO. So we undid the locks in an > inappropriate order - big deal. > > But often these _are_ things which we should tune up, as an efficiency > thing, so it is interesting to hear about them. But calling it a "BUG" is > a bit alarmist. Maybe so, but it's still pretty grotty though. Dave -- http://www.codemonkey.org.uk