Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2262227ybk; Mon, 11 May 2020 16:33:13 -0700 (PDT) X-Google-Smtp-Source: APiQypL2M7kuL+uxCc4NixFEEUHTLMr6JK1p6brdMCmA0kCtTe1sCoQxusL857aDMi4BzGNaLqcc X-Received: by 2002:a05:6402:14d7:: with SMTP id f23mr10466511edx.187.1589239993180; Mon, 11 May 2020 16:33:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589239993; cv=none; d=google.com; s=arc-20160816; b=DVx6+t6+sD9/MzmLpY3D07YlHKRyXYHt7dMFx4HvAW3Sb4e0kGprLILqgt2bvCYhmc bWVFGqAxW2XosrXVhX/d7YSI1rtSpqnzn5M63PJXxGZXeOCdDwkRoSrPisizIH+QN5o2 XHO74cjUXhDLzUOpMDuSJNCK1S09fwExt8hJurauI3Se7/uSWTwkMFr2VW1l0kVOAfpy Nwq5/iYwUHLLHeI1CaTRI/iz15dGCkf40+Pp2jDZbVzG3ptwx1USWh/VSVLuQ1y6WdPE XCs/KQ69A9Tudi5XZTtW2hyAr25+OwmrQqtIE+6SW+1ywf6tiIYwiZ4lNfTzBuvajfaG a6SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Gg6qs1e7aPVS3nvmNOQ2t6GKGFwC+Hlrkq9gnXIZBbw=; b=oocsCmOI2rP+s4/YRxFE0fkkKDUcUZJMucV2F+rN8o7edbj6ELm9jNLQqsjOyG9D13 GEmZXEg0juLMj3PJhX58vrC2Vnn7ij4iHjqDrwqypM5sjIoPTg+HvWVBbK9fLk0RmHjG 8vHRPuUUMZdt9Y1of6hQMMBM/mwOEZnZKMDmOQ9Of8ixpR4qA8r/1AraK4XXl3ouQf7K XbDjmAJr0VYQ0aoFiaDZh/5BUHqMdaePGoX9E+GqssPXeB/XEExGHW+7D7VUkmR/HoEQ bw9O7ASBxKFINWkKtViBr9jNw9nu4/VMPz/mNBqQ3eNU5t+lfAe2pMXbiB23EcQtI1um SLKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bo7si6747499edb.80.2020.05.11.16.32.34; Mon, 11 May 2020 16:33:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726415AbgEKXab convert rfc822-to-8bit (ORCPT + 99 others); Mon, 11 May 2020 19:30:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:34508 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbgEKXab (ORCPT ); Mon, 11 May 2020 19:30:31 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 50FB8206CC; Mon, 11 May 2020 23:30:30 +0000 (UTC) Date: Mon, 11 May 2020 19:30:28 -0400 From: Steven Rostedt To: Paul Menzel Cc: Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: ftrace: function radeon_init not traceable Message-ID: <20200511193028.3551d838@oasis.local.home> In-Reply-To: References: <01e29852-c9db-8181-e4fa-dda50f774cf6@molgen.mpg.de> <20200511145812.7206b095@gandalf.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 12 May 2020 01:07:44 +0200 Paul Menzel wrote: > >> > >> initcall_debug log_buf_len=32M trace_buf_size=57074K trace_clock=global trace_options=nooverwrite,funcgraph-abstime,funcgraph-cpu,funcgraph-duration,funcgraph-proc,funcgraph-tail,nofuncgraph-overhead,context-info,graph-time ftrace=function_graph ftrace_graph_max_depth=1 ftrace_graph_filter=radeon_init > >> > >> But ftrace “rejects” that: > >> > >> [ 0.075538] ftrace: allocating 30958 entries in 61 pages > >> [ 0.084542] ftrace: allocated 61 pages with 5 groups > >> [ 0.094184] ftrace: function radeon_init not traceable > >> > >> I believe it worked in the past. Is there a way to trace that init function? > > > > Did it every work for modules? radeon_init() isn't in the symbol table at > > boot up. > > > > [ 15.066951] systemd-journald[124]: Successfully sent stream file descriptor to service manager. > > [ 15.098265] hub 1-0:1.0: USB hub found > > [ 15.104006] systemd-journald[124]: Successfully sent stream file descriptor to service manager. > > [ 15.112965] hub 1-0:1.0: 2 ports detected > > [ 15.118116] probe of 1-0:1.0 returned 1 after 19873 usecs > > [ 15.124007] calling radeon_init+0x0/0x1000 [radeon] @ 133 > > > > The radeon_init is called after systemd is running, so it is definitely > > from a module. > > > > Perhaps you had it built in before? > > You are right. Probably I did. Can you suggest how to set up ftrace to > trace a module? In recent kernels there was a feature to function trace modules before they are loaded, but that feature isn't yet available on mainline. I could add it when I get a chance, but that wont be in the near future. Also, the function graph wont work for that either, as that isn't set up to preload before functions. But since you have ftrace_graph_max_depth of one, you don't need the graph, the limiting of the function (set_ftrace_filter) is good enough. But again, that only works after boot up. > > > > Probably because the filtering failed, so there is no filter. > > Is that the intended behavior? Or should nothing be traced? Well, it's just like writing something not acceptable in the filter functions. If it fails, it does not filter. So yes, it is expected behavior. -- Steve