Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752831Ab3JYJQG (ORCPT ); Fri, 25 Oct 2013 05:16:06 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:58790 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752313Ab3JYJQE (ORCPT ); Fri, 25 Oct 2013 05:16:04 -0400 From: "Rafael J. Wysocki" To: Linus Torvalds Cc: Knut Petersen , Ingo Molnar , Thomas Gleixner , Paul McKenney , =?ISO-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Viresh Kumar , Greg Kroah-Hartman , Greg KH , linux-kernel , cpufreq@vger.kernel.org, Linux PM list , Viresh Kumar Subject: Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown Date: Fri, 25 Oct 2013 11:28:02 +0200 Message-ID: <2582195.phiuskXt0x@vostro.rjw.lan> User-Agent: KMail/4.10.5 (Linux/3.11.0+; KDE/4.10.5; x86_64; ; ) In-Reply-To: References: <525BD08C.2080101@t-online.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2476 Lines: 55 On Friday, October 25, 2013 10:02:22 AM Linus Torvalds wrote: > Adding more people, so quoting the whole email for them. > > We definitely have some module unload issues. Guys, try the following > a few times to unload modules: > > lsmod | grep ' 0 '| cut -d' ' -f1 | xargs sudo rmmod > > (a few times because unloading one module will then potentially make > other modules unloadable). > > On my machine, I can trigger this, for example: > > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 3217 at fs/sysfs/file.c:498 sysfs_attr_ns+0x91/0xa0() > sysfs: kobject (null) without dirent > Modules linked in: fuse nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_$ > CPU: 0 PID: 3217 Comm: rmmod Not tainted 3.12.0-rc6-00284-ge6036c0b8896 #19 > Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013 > 0000000000000009 ffff8800aca35df8 ffffffff8160aab5 ffff8800aca35e40 > ffff8800aca35e30 ffffffff810514b8 ffffffffa013f080 ffff8801194a6040 > 0000000000000800 0000000000000000 0000000000c5b3e0 ffff8800aca35e90 > Call Trace: > [] dump_stack+0x45/0x56 > [] warn_slowpath_common+0x78/0xa0 > [] warn_slowpath_fmt+0x47/0x50 > [] ? module_refcount+0xb0/0xb0 > [] sysfs_attr_ns+0x91/0xa0 > [] sysfs_remove_file+0x1a/0x50 > [] cpufreq_sysfs_remove_file+0x13/0x30 > [] acpi_cpufreq_exit+0x2e/0xcde [acpi_cpufreq] > [] SyS_delete_module+0x15d/0x2c0 > [] ? do_notify_resume+0x59/0x90 > [] system_call_fastpath+0x16/0x1b > ---[ end trace f887112caaa5c4ab ]--- > > so at least we have a cpufreq/sysfs interaction bug. There may be others. > > This particular cpufreq issue may be triggered by the fact that > acpi-cpufreq isn't actually in use (pstate is). Or it might be some > generic cpufreq/sysfs bug. Rafael, Greg, ideas? I *think* that this indeed is related to acpi-cpufreq being unused. That said, we've been fixing sysfs-related bugs in cpufreq recently and we may have overlooked something. I'll have a deeper look at that. Rafael -- 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/