Re: system gets stuck in a lock during boot

[Justin P. Mattock]

Li Zefan wrote:
> Peter Zijlstra wrote:
>    
> > On Mon, 2009-08-24 at 10:41 +0800, Li Zefan wrote:
> >
> >      
> > > > @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
> > > >                  entry = trace_create_file("enable", 0644, call->dir, call,
> > > >                                            enable);
> > > >
> > > > -       if (call->id)
> > > > +       if (call->id&&  call->profile_enable)
> > > >          
> > > We do an extra check on ->profile_enable, shouldn't cause bug..
> > >
> > >        
> > > >                  entry = trace_create_file("id", 0444, call->dir, call,
> > > >                                            id);
> > > >          
> > > Any way, I don't think this commit does the right thing:
> > >
> > >    - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
> > >      except events/ftrace/<event>/id.
> > >
> > >    - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
> > >
> > > I think it's better to skip ftrace/ dir in perf tool code, instead of
> > > skipping creating id files in ftrace code.
> > >        
> > No, it does do the right thing. Your patch breaks things because not all
> > tracepoints are created through TRACE_EVENT() and will thus not have
> > their profile_enable/disable hooks set.
> >
> > By giving them an ID file, there is no way to distinguish good from bad
> > tracepoints.
> >
> >      
>
> But removing the id file from events/ftrace/ might break some ftrace
> binary parsers?
>
> And this commit makes 'id' file disapeared with CONFIG_EVENT_PROFILE=n.
>
>    
> > Expempting ftrace is no solid solution, suppose someone else does a
> > TRACE_EVENT_FORMAT() tracepoint, how would you know you could use it as
> > a profile event source?
> >
> >      
>
> Agree.
>
>    
> > The id files really must stay conditional.
> >
> >      
>
> I don't think it's a good idea to connect it with perfcounter
> this way. Wouldn't adding a 'profilable' file more intuitive?
>
>    
> > Aside from that, you only add #ifdef fuzz back which with his config is
> > moot, and shouldn't result in anything but a slightly bigger structure
> > to begin with.
> >
> >      
>
> Yeah, actually I still fail to see where the bug is, maybe
> the commit that Justin bisected down is not the real culprit..
>
>
>    
FWIW, here is the git bisect log:

git bisect start
# bad: [6c30c53fd5ae6a99a23ad78e90c428d2c8ffb07f] Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2
git bisect bad 6c30c53fd5ae6a99a23ad78e90c428d2c8ffb07f
# good: [b600ffaebcc4791add19e04306f0478a963abe71] Merge branch 
'irq-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good b600ffaebcc4791add19e04306f0478a963abe71
# good: [ae83060026537885fd23737af161fee8afd04f4b] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good ae83060026537885fd23737af161fee8afd04f4b
# bad: [b637dc0dba6a243da2c74f5d02b42ba5eeb9425e] Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
git bisect bad b637dc0dba6a243da2c74f5d02b42ba5eeb9425e
# bad: [cf7fdd57f978d40ceb9a0f58a25f5cf9c84d6f33] USB: fix oops on 
disconnect in cdc-acm
git bisect bad cf7fdd57f978d40ceb9a0f58a25f5cf9c84d6f33
# good: [131f7340b4f93f9a4a8e5a65abbd352b34d0ee08] Merge branch 
'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect good 131f7340b4f93f9a4a8e5a65abbd352b34d0ee08
# good: [c0c60c4b9ab45bb02b20796401dd6a90770fd0ee] ARM: 5639/1: arm: 
clkdev.c should include <linux/clk.h>
git bisect good c0c60c4b9ab45bb02b20796401dd6a90770fd0ee
# bad: [da758ddede96dd850945d3417ff75209a666ba0d] Merge branch 
'perfcounters-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect bad da758ddede96dd850945d3417ff75209a666ba0d
# good: [389623fef0e8b088f293c437d3b7094fe82349fd] Merge 
git://git.infradead.org/mtd-2.6
git bisect good 389623fef0e8b088f293c437d3b7094fe82349fd
# bad: [af6af30c0fcd77e621638e53ef8b176bca8bd3b4] ftrace: Fix 
perf-tracepoint OOPS
git bisect bad af6af30c0fcd77e621638e53ef8b176bca8bd3b4
# good: [2cdbc46d7b2cb0acb68c3ecad93b000552121fa6] perf: Auto-detect libbfd
git bisect good 2cdbc46d7b2cb0acb68c3ecad93b000552121fa6
# good: [386c0b702b1ea81c0f54f5c9832a3d4a52270f14] perf report: Add 
missing command line options to man page
git bisect good 386c0b702b1ea81c0f54f5c9832a3d4a52270f14

all I know is with 2.6.31-rc5 booted fine, as soon I loaded 2.6.31-rc6
I hit this stuckage(I can write it manually down if you need it,
seems ohci1394_dma gets a panic).

Justin P. Mattock

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/