From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932195AbWGGRCt (ORCPT ); Fri, 7 Jul 2006 13:02:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932196AbWGGRCt (ORCPT ); Fri, 7 Jul 2006 13:02:49 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]:40860 "EHLO ug-out-1314.google.com") by vger.kernel.org with ESMTP id S932195AbWGGRCs (ORCPT ); Fri, 7 Jul 2006 13:02:48 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DtYj4mz1yyMd8+YQAZyOJDgCQ8GAtsLZsyLsL+dSvdZxWsy8ZDIVUBi6U3YffFmpPDvbQ7gpSJvcyzKQM0cLEds4GPWTGdQYoRkb/f+2b//a8oKtxb6YBtZdx+nQQ3gc9xzrNWMOhEfFjlc4tytGoOwRdi1NknIHHPqYdKaSQjM= Message-ID: Date: Fri, 7 Jul 2006 10:02:47 -0700 From: "Bret Towe" To: "Andrew Morton" Subject: Re: 2.6.18-rc1 bttv modprobe null pointer dereference Cc: linux-kernel@vger.kernel.org In-Reply-To: <20060706233521.686300d2.akpm@osdl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060706215225.290360bf.akpm@osdl.org> <20060706233521.686300d2.akpm@osdl.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 7/6/06, Andrew Morton wrote: > On Thu, 6 Jul 2006 22:19:09 -0700 > "Bret Towe" wrote: > > > > > Code: 4c 8b bf 48 01 00 00 48 8b bf c0 00 00 00 8b 5e 10 48 81 c7 > > > > RIP [] sysfs_add_file+0x2b/0xb0 > > > > RSP > > > > CR2: 0000000000000149 > > > > > > There don't seem to have been significant changes in bttv-driver.c for some > > > time, and we're seeing a few reports like this. I'm suspecting that either > > > a sysfs/driver-core change was wrong, or previously wrong driver behaviour > > > is now causing oopses. > > > > > > And Mauro is offline until July 12. > > > > > > Can you send the .config please? > > > > of course > > I spent ten minutes and got lost. I suspect videodev's class_device > handling is wrong, but I fail to spot it. > > This might tell us something. i dont see any new error messages in dmesg looking at the trace it looks like its dieing before it gets to where this patch would be used?