* Re: linux-next: Tree for March 11 (staging/multimedia)
From: Greg KH @ 2009-03-11 18:24 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-media
In-Reply-To: <49B80140.5000304@oracle.com>
On Wed, Mar 11, 2009 at 11:21:52AM -0700, Randy Dunlap wrote:
> Greg KH wrote:
> > On Wed, Mar 11, 2009 at 10:12:39AM -0700, Randy Dunlap wrote:
> >> Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20090310:
> >>
> >> drivers/staging/go7007/go7007-v4l2.c:1830: error: 'VID_TYPE_CAPTURE' undeclared here (not in a function)
> >
> > Odd, nothing has changed in this driver, is this a v4l api change?
>
> I don't know if the vl4 API changed, but this error has been around
> for some time now. Just because it's just now being reported is one
> change. Surely other people build these drivers. ???
I do, and don't seem to get this error.
Ah, it's a CONFIG_VIDEO_V4L1_COMPAT issue. I'll see what needs to do to
fix this up.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for March 11 (staging/multimedia)
From: Randy Dunlap @ 2009-03-11 18:21 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, LKML, linux-media
In-Reply-To: <20090311181153.GA11088@suse.de>
Greg KH wrote:
> On Wed, Mar 11, 2009 at 10:12:39AM -0700, Randy Dunlap wrote:
>> Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20090310:
>>
>> drivers/staging/go7007/go7007-v4l2.c:1830: error: 'VID_TYPE_CAPTURE' undeclared here (not in a function)
>
> Odd, nothing has changed in this driver, is this a v4l api change?
I don't know if the vl4 API changed, but this error has been around
for some time now. Just because it's just now being reported is one
change. Surely other people build these drivers. ???
I do know that other video drivers (with one exception) don't set:
.vfl_type = VID_TYPE_CAPTURE,
at all, so maybe it's not needed (?).
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for March 11 (staging/multimedia)
From: Greg KH @ 2009-03-11 18:11 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-media
In-Reply-To: <49B7F107.7030303@oracle.com>
On Wed, Mar 11, 2009 at 10:12:39AM -0700, Randy Dunlap wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20090310:
>
>
> drivers/staging/go7007/go7007-v4l2.c:1830: error: 'VID_TYPE_CAPTURE' undeclared here (not in a function)
Odd, nothing has changed in this driver, is this a v4l api change?
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for March 11 (tracing)
From: Randy Dunlap @ 2009-03-11 17:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20090311225913.51589223.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20090310:
Building on i386 generates a ton of printk format warnings:
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 9 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 10 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 13 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 14 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 17 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 18 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 21 has type 'unsigned int'
kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 22 has type 'unsigned int'
include/trace/sched_event_types.h:11: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:11: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:21: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:21: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:31: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:31: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:41: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:41: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:53: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:53: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:65: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:65: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:85: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:85: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:98: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:98: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:108: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:108: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:118: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:118: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:128: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:128: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/sched_event_types.h:140: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/sched_event_types.h:140: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/irq_event_types.h:11: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/irq_event_types.h:11: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
include/trace/irq_event_types.h:21: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
include/trace/irq_event_types.h:21: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:8: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:8: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:16: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:16: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:25: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:25: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:34: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:34: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:47: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:47: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:60: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:60: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:75: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:75: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:90: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:90: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:105: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:105: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:114: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:114: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:124: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:124: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:132: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:132: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:142: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:142: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_event_types.h:156: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'unsigned int'
kernel/trace/trace_event_types.h:156: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for March 6 (ath9k)
From: Randy Dunlap @ 2009-03-11 17:19 UTC (permalink / raw)
To: John W. Linville
Cc: Gabor Juhos, Stephen Rothwell, linux-next-u79uwXL29TY76Z2rM5mHXA,
LKML, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20090306194045.GE3712-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
John W. Linville wrote:
> On Fri, Mar 06, 2009 at 11:41:02AM -0800, Randy Dunlap wrote:
>> Gabor Juhos wrote:
>>> Randy Dunlap írta:
>>>> Stephen Rothwell wrote:
>>>>> Hi all,
>>>>>
>>>>> Linus' release of -rc7 seems to have stirred people up a bit ...
>>>>>
>>>>> Changes since 20090305:
>>>> when CONFIG_RFKILL=n, ath9k/virtual.c causes:
>>>>
>>>> (.text+0x224e83): undefined reference to `ath_radio_disable'
>>>> (.text+0x224e8b): undefined reference to `ath_radio_enable'
>>>>
>>>>
>>> Hi,
>>>
>>> I have submitted a patch for this already:
>>> http://marc.info/?l=linux-wireless&m=123633468314970&w=2
>>>
>>> Should I send it to somewhere else as well?
>> It hasn't propagated into the linux-next merging yet...
>
> He just sent it today (or overnight). I'll get it into wireless-next.
>
> John
>
> P.S. I'm starting to think that RFKILL should just be mandatory...
This build error still happens in linux-next-20090311.
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: Tree for March 11 (staging/multimedia)
From: Randy Dunlap @ 2009-03-11 17:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Greg KH, linux-media
In-Reply-To: <20090311225913.51589223.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20090310:
drivers/staging/go7007/go7007-v4l2.c:1830: error: 'VID_TYPE_CAPTURE' undeclared here (not in a function)
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for March 10 (crypto & NLATTR)
From: Randy Dunlap @ 2009-03-11 16:55 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, geert, sfr, linux-next, linux-kernel, linux-crypto
In-Reply-To: <20090311010705.GA17260@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 10, 2009 at 01:17:00PM -0700, David Miller wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>> Date: Tue, 10 Mar 2009 13:08:31 -0700
>>
>>> I'll have to let David or Herbert answer that. From my quick look
>>> at the code, I don't see much use for nlattr.c when CONFIG_NET
>>> is not enabled.
>> We want to use the netlink attribute parsers even in non-networking
>> code, that's what he's trying to do here.
>
> OK the nlattr construction code really wants to depend on NET
> because they're skb-oriented. We could either move them back
> or just wrap them in ifdef CONFIG_NET.
>
> I think the latter is probably the simplest.
>
> How does this patch look? And Randy, does it fix the problem for
> you?
>
> nlattr: Fix build error with NET off
>
> We moved the netlink attribute support from net to lib in order
> for it to be available for general consumption. However, parts
> of the code (the bits that we don't need :) really depends on
> NET because the target object is sk_buff.
>
> This patch fixes this by wrapping them in CONFIG_NET.
>
> Some EXPORTs have been moved to make this work.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index 56c3ce7..80009a2 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -281,6 +281,7 @@ int nla_strcmp(const struct nlattr *nla, const char *str)
> return d;
> }
>
> +#ifdef CONFIG_NET
> /**
> * __nla_reserve - reserve room for attribute on the skb
> * @skb: socket buffer to reserve room on
> @@ -305,6 +306,7 @@ struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>
> return nla;
> }
> +EXPORT_SYMBOL(__nla_reserve);
>
> /**
> * __nla_reserve_nohdr - reserve room for attribute without header
> @@ -325,6 +327,7 @@ void *__nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>
> return start;
> }
> +EXPORT_SYMBOL(__nla_reserve_nohdr);
>
> /**
> * nla_reserve - reserve room for attribute on the skb
> @@ -345,6 +348,7 @@ struct nlattr *nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>
> return __nla_reserve(skb, attrtype, attrlen);
> }
> +EXPORT_SYMBOL(nla_reserve);
>
> /**
> * nla_reserve_nohdr - reserve room for attribute without header
> @@ -363,6 +367,7 @@ void *nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>
> return __nla_reserve_nohdr(skb, attrlen);
> }
> +EXPORT_SYMBOL(nla_reserve_nohdr);
>
> /**
> * __nla_put - Add a netlink attribute to a socket buffer
> @@ -382,6 +387,7 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
> nla = __nla_reserve(skb, attrtype, attrlen);
> memcpy(nla_data(nla), data, attrlen);
> }
> +EXPORT_SYMBOL(__nla_put);
>
> /**
> * __nla_put_nohdr - Add a netlink attribute without header
> @@ -399,6 +405,7 @@ void __nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
> start = __nla_reserve_nohdr(skb, attrlen);
> memcpy(start, data, attrlen);
> }
> +EXPORT_SYMBOL(__nla_put_nohdr);
>
> /**
> * nla_put - Add a netlink attribute to a socket buffer
> @@ -418,6 +425,7 @@ int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
> __nla_put(skb, attrtype, attrlen, data);
> return 0;
> }
> +EXPORT_SYMBOL(nla_put);
>
> /**
> * nla_put_nohdr - Add a netlink attribute without header
> @@ -436,6 +444,7 @@ int nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
> __nla_put_nohdr(skb, attrlen, data);
> return 0;
> }
> +EXPORT_SYMBOL(nla_put_nohdr);
>
> /**
> * nla_append - Add a netlink attribute without header or padding
> @@ -454,20 +463,13 @@ int nla_append(struct sk_buff *skb, int attrlen, const void *data)
> memcpy(skb_put(skb, attrlen), data, attrlen);
> return 0;
> }
> +EXPORT_SYMBOL(nla_append);
> +#endif
>
> EXPORT_SYMBOL(nla_validate);
> EXPORT_SYMBOL(nla_parse);
> EXPORT_SYMBOL(nla_find);
> EXPORT_SYMBOL(nla_strlcpy);
> -EXPORT_SYMBOL(__nla_reserve);
> -EXPORT_SYMBOL(__nla_reserve_nohdr);
> -EXPORT_SYMBOL(nla_reserve);
> -EXPORT_SYMBOL(nla_reserve_nohdr);
> -EXPORT_SYMBOL(__nla_put);
> -EXPORT_SYMBOL(__nla_put_nohdr);
> -EXPORT_SYMBOL(nla_put);
> -EXPORT_SYMBOL(nla_put_nohdr);
> EXPORT_SYMBOL(nla_memcpy);
> EXPORT_SYMBOL(nla_memcmp);
> EXPORT_SYMBOL(nla_strcmp);
> -EXPORT_SYMBOL(nla_append);
>
> Thanks,
--
~Randy
^ permalink raw reply
* Re: next-20090310: ext4 hangs
From: Alexander Beregalov @ 2009-03-11 16:07 UTC (permalink / raw)
To: Theodore Tso, Alexander Beregalov, linux-next@vger.kernel.org,
linux-ext4, LKML
In-Reply-To: <20090310154745.GF23075@mit.edu>
2009/3/10 Theodore Tso <tytso@mit.edu>:
> On Tue, Mar 10, 2009 at 05:18:55PM +0300, Alexander Beregalov wrote:
>> > Thanks for reporting this; does it show up on stock 2.6.29-rc7?
>> No, I can not reproduce it.
>> It is a slow system, I would not like to bisect it, only if it is the
>> last possibility.
>
> Just to be clear; you weren't able to reproduce it on stock 2.6.29-rc7
> ---- does it reproduce easily on linux-next?
Right.
But now I am not sure 2.6.29-rc7 is not affected, I will try to
reproduce it again.
>
> Next question --- does the system hang completely, or just the dbench
> process (and probably any process that tries touching the filesystem
System is responsible.
> that's hung up)? Do you have a serial console, or someone of
> recording all of the dumps coming from sysrq-t? The two stack traces
I can read dmesg.
> you gave weren't the ones causing the problem, but rather the ones
> waiting for the journal lock.
SysRq : Show State
<..>
kjournald2 D 0000000000557a0c 0 1547 2
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[0000000000557a0c] jbd2_journal_commit_transaction+0x208/0x1718
[000000000055d758] kjournald2+0x14c/0x318
[0000000000465d34] kthread+0x48/0x7c
[000000000042b364] kernel_thread+0x3c/0x54
[0000000000465c88] kthreadd+0xc8/0x12c
pdflush D 000000000055716c 0 2021 2
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052dd84] ext4_da_writepages+0x1a8/0x404
[0000000000490ec0] do_writepages+0x40/0x78
[00000000004d0ff8] __writeback_single_inode+0x198/0x330
[00000000004d15d8] generic_sync_sb_inodes+0x238/0x3c4
[00000000004d1984] writeback_inodes+0xb0/0x114
[00000000004915c0] background_writeout+0xc8/0x114
[0000000000492004] pdflush+0x128/0x1e0
[0000000000465d34] kthread+0x48/0x7c
[000000000042b364] kernel_thread+0x3c/0x54
[0000000000465c88] kthreadd+0xc8/0x12c
dbench D 000000000055716c 0 2024 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c7714] touch_atime+0x160/0x178
[00000000004c2a3c] vfs_readdir+0x88/0xb0
[00000000004eab90] compat_sys_getdents+0x3c/0x8c
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2025 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c7714] touch_atime+0x160/0x178
[00000000004c2a3c] vfs_readdir+0x88/0xb0
[00000000004eab90] compat_sys_getdents+0x3c/0x8c
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2026 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c7714] touch_atime+0x160/0x178
[000000000048b56c] generic_file_aio_read+0x578/0x620
[00000000004b5254] do_sync_read+0x90/0xe0
[00000000004b5c40] vfs_read+0x7c/0x11c
[00000000004b5d30] SyS_pread64+0x50/0x7c
[000000000043f778] sys32_pread64+0x20/0x34
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2027 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c757c] file_update_time+0xe0/0x118
[000000000048aef4] __generic_file_aio_write_nolock+0x280/0x380
[000000000048b930] generic_file_aio_write+0x58/0xc8
[0000000000526274] ext4_file_write+0xa8/0x15c
[00000000004b5174] do_sync_write+0x90/0xe0
[00000000004b5a40] vfs_write+0x7c/0x11c
[00000000004b5b30] SyS_pwrite64+0x50/0x7c
[000000000043f744] sys32_pwrite64+0x20/0x34
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2028 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052b958] ext4_da_write_begin+0x98/0x1a0
[000000000048a8dc] generic_file_buffered_write+0xe4/0x2b8
[000000000048afd0] __generic_file_aio_write_nolock+0x35c/0x380
[000000000048b930] generic_file_aio_write+0x58/0xc8
[0000000000526274] ext4_file_write+0xa8/0x15c
[00000000004b5174] do_sync_write+0x90/0xe0
[00000000004b5a40] vfs_write+0x7c/0x11c
[00000000004b5b30] SyS_pwrite64+0x50/0x7c
[000000000043f744] sys32_pwrite64+0x20/0x34
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055c010 0 2029 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055c010] jbd2_journal_release_jbd_inode+0x94/0xd8
[0000000000535bb4] ext4_clear_inode+0x2c/0x3c
[00000000004c7b1c] clear_inode+0xac/0x124
[0000000000527e48] ext4_free_inode+0x7c/0x3d4
[000000000052f884] ext4_delete_inode+0x218/0x29c
[00000000004c86b4] generic_delete_inode+0x8c/0x124
[00000000004c876c] generic_drop_inode+0x20/0x19c
[00000000004c77a4] iput+0x78/0x88
[00000000004c0200] do_unlinkat+0xf8/0x154
[00000000004c0270] SyS_unlink+0x14/0x24
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055cf84 0 2030 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055cf84] jbd2_log_wait_commit+0x144/0x1a8
[0000000000555cdc] jbd2_journal_stop+0x32c/0x37c
[0000000000557594] jbd2_journal_force_commit+0x34/0x48
[0000000000536d14] ext4_force_commit+0x30/0x50
[00000000005296b8] ext4_write_inode+0x80/0xa0
[00000000004d1044] __writeback_single_inode+0x1e4/0x330
[00000000004d11b0] sync_inode+0x20/0x40
[00000000005263ec] ext4_sync_file+0xc4/0x118
[00000000004d46f0] vfs_fsync+0x6c/0xa0
[00000000004d474c] do_fsync+0x28/0x44
[00000000004d47a4] SyS_fsync+0x14/0x28
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2031 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052b958] ext4_da_write_begin+0x98/0x1a0
[000000000048a8dc] generic_file_buffered_write+0xe4/0x2b8
[000000000048afd0] __generic_file_aio_write_nolock+0x35c/0x380
[000000000048b930] generic_file_aio_write+0x58/0xc8
[0000000000526274] ext4_file_write+0xa8/0x15c
[00000000004b5174] do_sync_write+0x90/0xe0
[00000000004b5a40] vfs_write+0x7c/0x11c
[00000000004b5b30] SyS_pwrite64+0x50/0x7c
[000000000043f744] sys32_pwrite64+0x20/0x34
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2032 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c7714] touch_atime+0x160/0x178
[00000000004c2a3c] vfs_readdir+0x88/0xb0
[00000000004eab90] compat_sys_getdents+0x3c/0x8c
[0000000000406154] linux_sparc_syscall32+0x34/0x40
dbench D 000000000055716c 0 2033 1
Call Trace:
[0000000000768bcc] schedule+0x18/0x40
[000000000055716c] start_this_handle+0x374/0x508
[0000000000557500] jbd2_journal_start+0xbc/0x11c
[000000000053a438] ext4_journal_start_sb+0x5c/0x84
[000000000052a9b8] ext4_dirty_inode+0xd4/0xf0
[00000000004d1a14] __mark_inode_dirty+0x2c/0x188
[00000000004c7714] touch_atime+0x160/0x178
[000000000048b56c] generic_file_aio_read+0x578/0x620
[00000000004b5254] do_sync_read+0x90/0xe0
[00000000004b5c40] vfs_read+0x7c/0x11c
[00000000004b5d30] SyS_pread64+0x50/0x7c
[000000000043f778] sys32_pread64+0x20/0x34
[0000000000406154] linux_sparc_syscall32+0x34/0x40
>
> I don't think is related to BZ #12579, although some of the symptoms
> look superficially the same.
>
> - Ted
>
> P.S. What are your dbench parameters, and how big is your filesystem,
> so I can try to reproduce it on my side? And how long do you
> typically need to run before this triggers? Thanks!
It is 2G filesystem, I run
`dbench -c /usr/share/dbench/client.txt 10` or 5 clients.
Yesterday it happened when I run it for the first time, but today I
run it 10 times before I got the deadlock.
So, I think I need to try it on 2.6.29-rc7 again.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Jason Baron @ 2009-03-11 15:12 UTC (permalink / raw)
To: Greg Banks
Cc: Martin Schwidefsky, Geert Uytterhoeven, Stephen Rothwell, Greg KH,
linux-next, Herbert Xu, Linux Kernel Development
In-Reply-To: <49B78D60.2070402@sgi.com>
On Wed, Mar 11, 2009 at 09:07:28PM +1100, Greg Banks wrote:
>
> I think this patch does the same thing more cleanly.
>
> When CONFIG_DYNAMIC_DEBUG is enabled, allow callers of pr_debug()
> to provide their own definition of pr_fmt() even if that definition
> uses tricks like
>
> #define pr_fmt(fmt) "%s:" fmt, __func__
>
patch looks good. I agree its simpler than what I proposed. However, I
don't think we want to add pr_fmt() in the dynamic_dev_dbg() path, since
dev_dbg() isn't doing that to start with. Other than that, I ack it.
thanks,
-Jason
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Takashi Iwai @ 2009-03-11 13:28 UTC (permalink / raw)
To: Mark Brown
Cc: Russell King, Stephen Rothwell, linux-next, Ben Dooks,
Alexander Schulz
In-Reply-To: <20090311112443.GA7939@rakim.wolfsonmicro.main>
At Wed, 11 Mar 2009 11:24:43 +0000,
Mark Brown wrote:
>
> On Wed, Mar 11, 2009 at 10:40:49AM +0000, Russell King wrote:
>
> > But, at the end of the day, these things have to be fixed one way or
> > other, whether that be by removing the offending commits, by reverting
> > the patches, or patching the specific bad changes back to how they
> > originally were. I really don't mind which option is taken, just so
> > long as the final outcome is the right one.
>
> Let's go with reverting things, then - that avoids having to drop the
> audio drivers and the subsequent work that was done on them.
>
> Takashi, here's an initial revert of the two hunks I mentioned
> previously - I've not checked the other two hunks yet.
OK, pulled that now.
Thanks,
Takashi
>
> The following changes since commit f455dfb106916d855d59686fe16575c2ceb2cb2a:
> Mark Brown (1):
> ASoC: Fix up merge with the ARM tree
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30
>
> Mark Brown (2):
> [ARM] Revert extraneous changes from the S3C audio header move
> Merge branch 's3c-iis-header' into for-2.6.30
>
> arch/arm/mach-s3c2410/include/mach/hardware.h | 3 +++
> arch/arm/mach-shark/include/mach/io.h | 3 +--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: linux-next: block/proc tree build failure
From: Geert Uytterhoeven @ 2009-03-11 12:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Jens Axboe, Alexey Dobriyan, linux-next, Geoff Levand
In-Reply-To: <20090311224418.f1a7cb5f.sfr@canb.auug.org.au>
On Wed, 11 Mar 2009, Stephen Rothwell wrote:
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/block/ps3vram.c: In function 'ps3vram_proc_init':
> drivers/block/ps3vram.c:555: error: 'struct proc_dir_entry' has no member named 'owner'
>
> Caused by the interaction of commit
> ce12b152a2e5c0f831853180e84f3ba6e3fee4a1 ("ps3/block: Replace mtd/ps3vram
> by block/ps3vram") from the block tree with commit
> 773c363c5607e8713efe49e1df11317dfa8f48fc ("proc 2/2: remove struct
> proc_dir_entry::owner") from the proc tree.
>
> I have applied the following patch that I will add as a merge fixup for
> the proc tree tomorrow and apply as long as necessary.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 11 Mar 2009 22:22:04 +1100
> Subject: [PATCH] proc: remove a new user of proc_dir_entry::owner
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
> drivers/block/ps3vram.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
> index 393ed67..23fc853 100644
> --- a/drivers/block/ps3vram.c
> +++ b/drivers/block/ps3vram.c
> @@ -552,7 +552,6 @@ static void __devinit ps3vram_proc_init(struct ps3_system_bus_device *dev)
> return;
> }
>
> - pde->owner = THIS_MODULE;
> pde->data = priv;
> }
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: linux-next: Tree for March 10 (crypto & NLATTR)
From: Geert Uytterhoeven @ 2009-03-11 12:25 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, randy.dunlap, sfr, linux-next, linux-kernel,
linux-crypto
In-Reply-To: <20090311010705.GA17260@gondor.apana.org.au>
On Wed, 11 Mar 2009, Herbert Xu wrote:
> On Tue, Mar 10, 2009 at 01:17:00PM -0700, David Miller wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > Date: Tue, 10 Mar 2009 13:08:31 -0700
> >
> > > I'll have to let David or Herbert answer that. From my quick look
> > > at the code, I don't see much use for nlattr.c when CONFIG_NET
> > > is not enabled.
> >
> > We want to use the netlink attribute parsers even in non-networking
> > code, that's what he's trying to do here.
>
> OK the nlattr construction code really wants to depend on NET
> because they're skb-oriented. We could either move them back
> or just wrap them in ifdef CONFIG_NET.
>
> I think the latter is probably the simplest.
>
> How does this patch look? And Randy, does it fix the problem for
> you?
>
> nlattr: Fix build error with NET off
>
> We moved the netlink attribute support from net to lib in order
> for it to be available for general consumption. However, parts
> of the code (the bits that we don't need :) really depends on
> NET because the target object is sk_buff.
>
> This patch fixes this by wrapping them in CONFIG_NET.
>
> Some EXPORTs have been moved to make this work.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks for taking care of this!
Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index 56c3ce7..80009a2 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -281,6 +281,7 @@ int nla_strcmp(const struct nlattr *nla, const char *str)
> return d;
> }
>
> +#ifdef CONFIG_NET
> /**
> * __nla_reserve - reserve room for attribute on the skb
> * @skb: socket buffer to reserve room on
> @@ -305,6 +306,7 @@ struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>
> return nla;
> }
> +EXPORT_SYMBOL(__nla_reserve);
>
> /**
> * __nla_reserve_nohdr - reserve room for attribute without header
> @@ -325,6 +327,7 @@ void *__nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>
> return start;
> }
> +EXPORT_SYMBOL(__nla_reserve_nohdr);
>
> /**
> * nla_reserve - reserve room for attribute on the skb
> @@ -345,6 +348,7 @@ struct nlattr *nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>
> return __nla_reserve(skb, attrtype, attrlen);
> }
> +EXPORT_SYMBOL(nla_reserve);
>
> /**
> * nla_reserve_nohdr - reserve room for attribute without header
> @@ -363,6 +367,7 @@ void *nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>
> return __nla_reserve_nohdr(skb, attrlen);
> }
> +EXPORT_SYMBOL(nla_reserve_nohdr);
>
> /**
> * __nla_put - Add a netlink attribute to a socket buffer
> @@ -382,6 +387,7 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
> nla = __nla_reserve(skb, attrtype, attrlen);
> memcpy(nla_data(nla), data, attrlen);
> }
> +EXPORT_SYMBOL(__nla_put);
>
> /**
> * __nla_put_nohdr - Add a netlink attribute without header
> @@ -399,6 +405,7 @@ void __nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
> start = __nla_reserve_nohdr(skb, attrlen);
> memcpy(start, data, attrlen);
> }
> +EXPORT_SYMBOL(__nla_put_nohdr);
>
> /**
> * nla_put - Add a netlink attribute to a socket buffer
> @@ -418,6 +425,7 @@ int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
> __nla_put(skb, attrtype, attrlen, data);
> return 0;
> }
> +EXPORT_SYMBOL(nla_put);
>
> /**
> * nla_put_nohdr - Add a netlink attribute without header
> @@ -436,6 +444,7 @@ int nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
> __nla_put_nohdr(skb, attrlen, data);
> return 0;
> }
> +EXPORT_SYMBOL(nla_put_nohdr);
>
> /**
> * nla_append - Add a netlink attribute without header or padding
> @@ -454,20 +463,13 @@ int nla_append(struct sk_buff *skb, int attrlen, const void *data)
> memcpy(skb_put(skb, attrlen), data, attrlen);
> return 0;
> }
> +EXPORT_SYMBOL(nla_append);
> +#endif
>
> EXPORT_SYMBOL(nla_validate);
> EXPORT_SYMBOL(nla_parse);
> EXPORT_SYMBOL(nla_find);
> EXPORT_SYMBOL(nla_strlcpy);
> -EXPORT_SYMBOL(__nla_reserve);
> -EXPORT_SYMBOL(__nla_reserve_nohdr);
> -EXPORT_SYMBOL(nla_reserve);
> -EXPORT_SYMBOL(nla_reserve_nohdr);
> -EXPORT_SYMBOL(__nla_put);
> -EXPORT_SYMBOL(__nla_put_nohdr);
> -EXPORT_SYMBOL(nla_put);
> -EXPORT_SYMBOL(nla_put_nohdr);
> EXPORT_SYMBOL(nla_memcpy);
> EXPORT_SYMBOL(nla_memcmp);
> EXPORT_SYMBOL(nla_strcmp);
> -EXPORT_SYMBOL(nla_append);
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* linux-next: Tree for March 11
From: Stephen Rothwell @ 2009-03-11 11:59 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 10552 bytes --]
Hi all,
Changes since 20090310:
The xfs tree still has a build failure and so is still the version from
next-20090306.
The net tee lost its 2 conficts.
The input tree lost its build failure.
The md tree lost its conflict and build failure, but gained another build
failure, so I used the tree from next-20090306.
The lblnet tree lost its conflict.
The watchdog tree lost its 2 conflicts.
The proc tree removed an struct element used by a new driver in the block
tree so I have applied a merge fixup patch.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 133 trees (counting Linus' and 18 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mach-at91/gpio.c
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
CONFLICT (rename/modify): Merge conflict in arch/arm/plat-pxa/dma.c
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/elf.h
Merging xtensa/master
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging cpus4096/auto-cpus4096-next
Merging tracing/auto-tracing-next
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (delete/modify): block/blktrace.c deleted in tracing/auto-tracing-next and modified in HEAD. Version HEAD of block/blktrace.c left in tree.
CONFLICT (content): Merge conflict in kernel/irq/handle.c
$ git rm -f block/blktrace.c
Applying: tracing: blktrace merge fix
Applying: trace: percpu fixup
Merging genirq/auto-genirq-next
CONFLICT (content): Merge conflict in kernel/irq/handle.c
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
CONFLICT (content): Merge conflict in lib/Makefile
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pcie/portdrv_pci.c
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mpc.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
Merging v4l-dvb/master
Merging quota/for_next
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
$ git reset --hard HEAD^
Merging xfs/master from next-20090306
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
CONFLICT (content): Merge conflict in fs/ext4/inode.c
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-shark/include/mach/io.h
CONFLICT (content): Merge conflict in sound/soc/pxa/pxa2xx-i2s.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in arch/x86/include/asm/timer.h
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/kernel/irq.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/powernow-k8.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/speedstep-ich.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/speedstep-lib.c
CONFLICT (delete/modify): arch/x86/mach-default/setup.c deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/mach-default/setup.c left in tree.
CONFLICT (delete/modify): arch/x86/mach-voyager/setup.c deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/mach-voyager/setup.c left in tree.
CONFLICT (content): Merge conflict in drivers/firmware/dcdbas.c
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134.h
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git rm -f arch/x86/mach-default/setup.c
$ git rm -f arch/x86/mach-voyager/setup.c
Applying: rr: x86 irqaction merge fixup
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
CONFLICT (content): Merge conflict in sound/isa/Kconfig
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in include/linux/slub_def.h
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging uclinux/for-next
Merging md/for-next
$ git reset --hard HEAD^
Merging next-20090306/md
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_proc.c
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/mm/init_32.c
CONFLICT (content): Merge conflict in arch/x86/mm/init_64.c
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
CONFLICT (content): Merge conflict in mm/Makefile
Applying: kmemcheck: arcgh/x86/mm/init.c merge fix
Merging generic-ipi/auto-generic-ipi-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
CONFLICT (add/add): Merge conflict in drivers/scsi/osd/osd_initiator.c
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging squashfs/master
Merging omap/for-next
Merging quilt/aoe
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in kernel/module.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
CONFLICT (content): Merge conflict in mm/vmalloc.c
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/media/video/v4l2-device.c
CONFLICT (content): Merge conflict in drivers/net/wimax/i2400m/usb-notif.c
CONFLICT (content): Merge conflict in drivers/sh/maple/maple.c
Applying: acpi: update thermal for bus_id removal
Applying: crypto: remove pr_fmt for now
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
Applying: proc: remove a new user of proc_dir_entry::owner
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: block/proc tree build failure
From: Stephen Rothwell @ 2009-03-11 11:44 UTC (permalink / raw)
To: Jens Axboe, Alexey Dobriyan; +Cc: linux-next, Geert Uytterhoeven
Hi Jens, Alexey,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/block/ps3vram.c: In function 'ps3vram_proc_init':
drivers/block/ps3vram.c:555: error: 'struct proc_dir_entry' has no member named 'owner'
Caused by the interaction of commit
ce12b152a2e5c0f831853180e84f3ba6e3fee4a1 ("ps3/block: Replace mtd/ps3vram
by block/ps3vram") from the block tree with commit
773c363c5607e8713efe49e1df11317dfa8f48fc ("proc 2/2: remove struct
proc_dir_entry::owner") from the proc tree.
I have applied the following patch that I will add as a merge fixup for
the proc tree tomorrow and apply as long as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 11 Mar 2009 22:22:04 +1100
Subject: [PATCH] proc: remove a new user of proc_dir_entry::owner
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/block/ps3vram.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 393ed67..23fc853 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -552,7 +552,6 @@ static void __devinit ps3vram_proc_init(struct ps3_system_bus_device *dev)
return;
}
- pde->owner = THIS_MODULE;
pde->data = priv;
}
--
1.6.1.3
^ permalink raw reply related
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Mark Brown @ 2009-03-11 11:24 UTC (permalink / raw)
To: Russell King
Cc: Takashi Iwai, Stephen Rothwell, linux-next, Ben Dooks,
Alexander Schulz
In-Reply-To: <20090311104049.GA14668@flint.arm.linux.org.uk>
On Wed, Mar 11, 2009 at 10:40:49AM +0000, Russell King wrote:
> But, at the end of the day, these things have to be fixed one way or
> other, whether that be by removing the offending commits, by reverting
> the patches, or patching the specific bad changes back to how they
> originally were. I really don't mind which option is taken, just so
> long as the final outcome is the right one.
Let's go with reverting things, then - that avoids having to drop the
audio drivers and the subsequent work that was done on them.
Takashi, here's an initial revert of the two hunks I mentioned
previously - I've not checked the other two hunks yet.
The following changes since commit f455dfb106916d855d59686fe16575c2ceb2cb2a:
Mark Brown (1):
ASoC: Fix up merge with the ARM tree
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30
Mark Brown (2):
[ARM] Revert extraneous changes from the S3C audio header move
Merge branch 's3c-iis-header' into for-2.6.30
arch/arm/mach-s3c2410/include/mach/hardware.h | 3 +++
arch/arm/mach-shark/include/mach/io.h | 3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Geert Uytterhoeven @ 2009-03-11 10:50 UTC (permalink / raw)
To: Greg Banks
Cc: Jason Baron, Martin Schwidefsky, Stephen Rothwell, Greg KH,
linux-next, Herbert Xu, Linux Kernel Development
In-Reply-To: <49B78D60.2070402@sgi.com>
On Wed, 11 Mar 2009, Greg Banks wrote:
> Jason Baron wrote:
> > On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
> >
> >> On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
> >> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> >>
> >>
> >>>> The same could be done with the problematic pr_fmt definition:
> >>>>
> >>>> #define pr_fmt(fmt) __func__ ": " fmt
> >>>>
> >>> No, that also doesn't work:
> >>>
> >>> | crypto/zlib.c:150: error: expected '}' before string constant
> >>> | crypto/zlib.c:150: error: expected ')' before '__func__'
> >>> | crypto/zlib.c:162: error: expected '}' before string constant
> >>> | crypto/zlib.c:162: error: expected ')' before '__func__'
> >>> | crypto/zlib.c:166: error: expected '}' before string constant
> >>> | crypto/zlib.c:166: error: expected ')' before '__func__'
> >>> | crypto/zlib.c:170: error: expected '}' before string constant
> >>> | crypto/zlib.c:170: error: expected ')' before '__func__'
> >>>
> >>>
> >>>>> BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
> >>>>> intended usage of your pr_fmt() infrastructure?
> >>>>>
> >>>> The indended use is a simple prefix to the format string. To paste an
> >>>> additional parameter is an interesting use of the pr_fmt macro ..
> >>>>
> >>> Bummer, I was so happy I could do things like
> >>>
> >>> | #define pr_fmt(fmt) "%s:%u: " fmt, __func__, __LINE__
> >>>
> >> Actually that seem like a nice thing to have. With the upstream version of
> >> dynamic_pr_debug this works, there the format string is used only on a printk.
> >> git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
> >> that pastes the format string to the _ddebug structure.
> >>
> >>
> >
> > hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
> > the 'fmt' arg into a series of strings. It doesn't look as pretty in the
> > dynamic debug control file:
> >
> > crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
> > \042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
> > __func__"
> >
> > with all those '\042' there, which are the '"' characters, but we
> > probably could live with it.
> >
> > patch below.
> >
> >
>
> I think this patch does the same thing more cleanly.
>
> When CONFIG_DYNAMIC_DEBUG is enabled, allow callers of pr_debug()
> to provide their own definition of pr_fmt() even if that definition
> uses tricks like
>
> #define pr_fmt(fmt) "%s:" fmt, __func__
>
> Signed-off-by: Greg Banks <gnb@sgi.com>
Thanks, much cleaner!
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
>
> include/linux/dynamic_debug.h | 4 ++--
> include/linux/kernel.h | 3 ++-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> Index: linux-git/include/linux/dynamic_debug.h
> ===================================================================
> --- linux-git.orig/include/linux/dynamic_debug.h
> +++ linux-git/include/linux/dynamic_debug.h
> @@ -57,7 +57,7 @@ extern int ddebug_remove_module(char *mo
> { KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
> DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
> if (__dynamic_dbg_enabled(descriptor)) \
> - printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
> + printk(KERN_DEBUG KBUILD_MODNAME ":" pr_fmt(fmt), \
> ##__VA_ARGS__); \
> } while (0)
>
> @@ -70,7 +70,7 @@ extern int ddebug_remove_module(char *mo
> DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
> if (__dynamic_dbg_enabled(descriptor)) \
> dev_printk(KERN_DEBUG, dev, \
> - KBUILD_MODNAME ": " fmt, \
> + KBUILD_MODNAME ": " pr_fmt(fmt),\
> ##__VA_ARGS__); \
> } while (0)
>
> Index: linux-git/include/linux/kernel.h
> ===================================================================
> --- linux-git.orig/include/linux/kernel.h
> +++ linux-git/include/linux/kernel.h
> @@ -359,8 +359,9 @@ static inline char *pack_hex_byte(char *
> #define pr_debug(fmt, ...) \
> printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> #elif defined(CONFIG_DYNAMIC_DEBUG)
> +/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
> #define pr_debug(fmt, ...) do { \
> - dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
> + dynamic_pr_debug(fmt, ##__VA_ARGS__); \
> } while (0)
> #else
> #define pr_debug(fmt, ...) \
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Russell King @ 2009-03-11 10:40 UTC (permalink / raw)
To: Takashi Iwai
Cc: Stephen Rothwell, linux-next, Ben Dooks, Mark Brown,
Alexander Schulz
In-Reply-To: <s5hzlfsgywo.wl%tiwai@suse.de>
On Wed, Mar 11, 2009 at 11:02:47AM +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2009 09:41:27 +0000, Russell King wrote:
> > Why do I want to pull stuff that I consider broken into my tree? Please
> > get rid of the use of __typesafe_io in the shark io.h header in your tree
> > or drop these patches entirely and ask the submitter to fix (whatever's
> > easier for you.)
>
> It's not too big issue to revert the changes, but it'd be better to
> fix the spot as Mark suggested. The continuous GIT tree history makes
> the life of others easier a lot.
Continuous git tree history is something that can be achieved if you're
either at the top of the submission tree, or if you're extremely good
at reviewing patches and throwing out anything which might be the
slightest bit controversial until such things have been agreed.
The issue here is that an inappropriate tree has accepted unreviewed
and questionable ARM specific changes as part of a different set of
patches. That's partly the fault of the submitter for mixing up the
patch set with irrelevant changes for the tree to which he's submitting
his changes.
There used to be a mantra with the kernel community: one patch to make
one logical change. That's very much the issue here - it sounds like
there was one patch making several changes, some of which were relevent
to the ALSA tree and others which weren't.
But, at the end of the day, these things have to be fixed one way or
other, whether that be by removing the offending commits, by reverting
the patches, or patching the specific bad changes back to how they
originally were. I really don't mind which option is taken, just so
long as the final outcome is the right one.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Greg Banks @ 2009-03-11 10:07 UTC (permalink / raw)
To: Jason Baron
Cc: Martin Schwidefsky, Geert Uytterhoeven, Stephen Rothwell, Greg KH,
linux-next, Herbert Xu, Linux Kernel Development
In-Reply-To: <20090310200200.GB3091@redhat.com>
Jason Baron wrote:
> On Tue, Mar 10, 2009 at 05:08:41PM +0100, Martin Schwidefsky wrote:
>
>> On Tue, 10 Mar 2009 16:29:50 +0100 (CET)
>> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>>
>>
>>>> The same could be done with the problematic pr_fmt definition:
>>>>
>>>> #define pr_fmt(fmt) __func__ ": " fmt
>>>>
>>> No, that also doesn't work:
>>>
>>> | crypto/zlib.c:150: error: expected '}' before string constant
>>> | crypto/zlib.c:150: error: expected ')' before '__func__'
>>> | crypto/zlib.c:162: error: expected '}' before string constant
>>> | crypto/zlib.c:162: error: expected ')' before '__func__'
>>> | crypto/zlib.c:166: error: expected '}' before string constant
>>> | crypto/zlib.c:166: error: expected ')' before '__func__'
>>> | crypto/zlib.c:170: error: expected '}' before string constant
>>> | crypto/zlib.c:170: error: expected ')' before '__func__'
>>>
>>>
>>>>> BTW, Martin: Is `#define pr_fmt(fmt) "%s: " fmt, __func__' a valid and
>>>>> intended usage of your pr_fmt() infrastructure?
>>>>>
>>>> The indended use is a simple prefix to the format string. To paste an
>>>> additional parameter is an interesting use of the pr_fmt macro ..
>>>>
>>> Bummer, I was so happy I could do things like
>>>
>>> | #define pr_fmt(fmt) "%s:%u: " fmt, __func__, __LINE__
>>>
>> Actually that seem like a nice thing to have. With the upstream version of
>> dynamic_pr_debug this works, there the format string is used only on a printk.
>> git commit 25b67b75587d43ff3f09ad88c03c70a38372d95d introduces the code
>> that pastes the format string to the _ddebug structure.
>>
>>
>
> hmmm...yeah, some macro magic in include/linux/dynamic_debug.h converts
> the 'fmt' arg into a series of strings. It doesn't look as pretty in the
> dynamic debug control file:
>
> crypto/zlib.c:333 [zlib]zlib_decompress_final - "\042%s: \042
> \042avail_in %u, avail_out %u (consumed %u, produced %u)\n\042,
> __func__"
>
> with all those '\042' there, which are the '"' characters, but we
> probably could live with it.
>
> patch below.
>
>
I think this patch does the same thing more cleanly.
When CONFIG_DYNAMIC_DEBUG is enabled, allow callers of pr_debug()
to provide their own definition of pr_fmt() even if that definition
uses tricks like
#define pr_fmt(fmt) "%s:" fmt, __func__
Signed-off-by: Greg Banks <gnb@sgi.com>
---
include/linux/dynamic_debug.h | 4 ++--
include/linux/kernel.h | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-git/include/linux/dynamic_debug.h
===================================================================
--- linux-git.orig/include/linux/dynamic_debug.h
+++ linux-git/include/linux/dynamic_debug.h
@@ -57,7 +57,7 @@ extern int ddebug_remove_module(char *mo
{ KBUILD_MODNAME, __func__, __FILE__, fmt, DEBUG_HASH, \
DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
if (__dynamic_dbg_enabled(descriptor)) \
- printk(KERN_DEBUG KBUILD_MODNAME ":" fmt, \
+ printk(KERN_DEBUG KBUILD_MODNAME ":" pr_fmt(fmt), \
##__VA_ARGS__); \
} while (0)
@@ -70,7 +70,7 @@ extern int ddebug_remove_module(char *mo
DEBUG_HASH2, __LINE__, _DPRINTK_FLAGS_DEFAULT }; \
if (__dynamic_dbg_enabled(descriptor)) \
dev_printk(KERN_DEBUG, dev, \
- KBUILD_MODNAME ": " fmt, \
+ KBUILD_MODNAME ": " pr_fmt(fmt),\
##__VA_ARGS__); \
} while (0)
Index: linux-git/include/linux/kernel.h
===================================================================
--- linux-git.orig/include/linux/kernel.h
+++ linux-git/include/linux/kernel.h
@@ -359,8 +359,9 @@ static inline char *pack_hex_byte(char *
#define pr_debug(fmt, ...) \
printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#elif defined(CONFIG_DYNAMIC_DEBUG)
+/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
#define pr_debug(fmt, ...) do { \
- dynamic_pr_debug(pr_fmt(fmt), ##__VA_ARGS__); \
+ dynamic_pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
#else
#define pr_debug(fmt, ...) \
--
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Takashi Iwai @ 2009-03-11 10:02 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, Ben Dooks, Mark Brown,
Alexander Schulz
In-Reply-To: <20090311094126.GA4619@flint.arm.linux.org.uk>
At Wed, 11 Mar 2009 09:41:27 +0000,
Russell King wrote:
>
> On Wed, Mar 11, 2009 at 10:18:40AM +0100, Takashi Iwai wrote:
> > At Wed, 11 Mar 2009 08:52:54 +0000,
> > Russell King wrote:
> > >
> > > On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > > > Hi Takashi,
> > > >
> > > > Today's linux-next merge of the sound tree got a conflict in
> > > > arch/arm/mach-shark/include/mach/io.h between commit
> > > > eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> > > > and new defconfig") from the arm tree and commit
> > > > 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> > > > headers") from the sound tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary.
> > >
> > > NAK to this patch.
> > >
> > > The greater concern is WTF are cleanup patches for the ARM architecture
> > > going via the sound tree. Especially patches which I have concerns about.
> > >
> > > > --- a/arch/arm/mach-shark/include/mach/io.h
> > > > +++ b/arch/arm/mach-shark/include/mach/io.h
> > > > @@@ -11,10 -11,10 +11,10 @@@
> > > > #ifndef __ASM_ARM_ARCH_IO_H
> > > > #define __ASM_ARM_ARCH_IO_H
> > > >
> > > > -#define PCIO_BASE 0xe0000000
> > > > -#define IO_SPACE_LIMIT 0xffffffff
> > > > +#define IO_SPACE_LIMIT 0xffffffff
> > > >
> > > > - #define __io(a) ((void __iomem *)(0xe0000000 + (a)))
> > > > -#define __io(a) __typesafe_io(PCIO_BASE + (a))
> > > > -#define __mem_pci(addr) (addr)
> > > > ++#define __io(a) __typesafe_io(0xe0000000 + (a))
> > >
> > > Do not use __typesafe_io() with the addition here without first ensuring
> > > that you've investigated whether it causes the compiler to mis-optimise
> > > the code.
> >
> > Hrm, is that particular change also in ARM tree, no? Judging from the
> > conflict-diff above, it looks like the patch just follows that...
> >
> > > Takashi - please remove all such patches from the sound tree. They
> > > should not be in there.
> >
> > Oh, I thought Mark already sent you Ben's patches.
>
> What is in my tree is:
>
> ------
> diff --git a/arch/arm/mach-shark/include/mach/io.h b/arch/arm/mach-shark/include/mach/io.h
> index c5cee82..9ccbcec 100644
> --- a/arch/arm/mach-shark/include/mach/io.h
> +++ b/arch/arm/mach-shark/include/mach/io.h
> @@ -11,10 +11,10 @@
> #ifndef __ASM_ARM_ARCH_IO_H
> #define __ASM_ARM_ARCH_IO_H
>
> -#define PCIO_BASE 0xe0000000
> -#define IO_SPACE_LIMIT 0xffffffff
> +#define IO_SPACE_LIMIT 0xffffffff
>
> -#define __io(a) ((void __iomem *)(PCIO_BASE + (a)))
> -#define __mem_pci(addr) (addr)
> +#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
> +
> +#define __mem_pci(addr) (addr)
>
> #endif
> ------
>
> which is basically the same thing from Alexander Schulz but without the
> addition of __typesafe_io(), and it's that which I'm objecting to.
OK, fair enough.
> > Sorry if it wasn't done yet.
>
> It seems not. Searching for all messages from Mark containing the
> string 'typesafe' results in no matches for messages since 1st January.
Hm, looks like there was some misunderstanding in communications.
> > Basically it's two patches to create a branch to move and update IIS
> > and audio.h headers. Since some drivers require these changes, they
> > have to be in the sound tree, too. Otherwise the tree gets
> > inconsistent and can't be built.
>
> Maybe, but the point here is that's not the only thing it does. It also
> makes other changes _as well_ that are not relevent to the changes you're
> talking about above.
>
> > The relevant changes are in another branch (s3c-iis-header) of asoc
> > tree so that it can be easily pulled to another tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git s3c-iis-header
> >
> > So, if you can pull these changes above into your GIT tree simply via
> > "git pull", everything will settle down (as both trees share the same
> > GIT objects).
>
> Why do I want to pull stuff that I consider broken into my tree? Please
> get rid of the use of __typesafe_io in the shark io.h header in your tree
> or drop these patches entirely and ask the submitter to fix (whatever's
> easier for you.)
It's not too big issue to revert the changes, but it'd be better to
fix the spot as Mark suggested. The continuous GIT tree history makes
the life of others easier a lot.
Thanks,
Takashi
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Mark Brown @ 2009-03-11 9:49 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, Takashi Iwai, linux-next, Ben Dooks,
Alexander Schulz
In-Reply-To: <20090311085254.GA30970@flint.arm.linux.org.uk>
On Wed, Mar 11, 2009 at 08:52:54AM +0000, Russell King wrote:
> The greater concern is WTF are cleanup patches for the ARM architecture
> going via the sound tree. Especially patches which I have concerns about.
The reason they're going via the ALSA tree is that Ben has also
submitted patches adding S3C64xx audio support which depends strongly on
the ARM tree changes moving the header files about. The ARM-generic
changes are also available in a split out branch via:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git
s3c-iis-header
Sorry about this - I'd been expecting Ben to also include this branch in
the code he's pushing to you and obviously hadn't reviewed them as well
as possible.
> Takashi - please remove all such patches from the sound tree. They
> should not be in there.
Could we instead revert the bits that cause issues? It'd be really good
to be able to get the audio drivers into the next merge window.
Re-reviewing the commit it looks like the shark header update that
changes to using typesafe_io() is just completely unrelated to the rest
of the series (commit 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 does that
change in an isolated hunk). I'll push a revert of that hunk to Takashi
this morning.
I'll also remove the change below which looks like a good change in
itself but doesn't appear to be relevant to the header renames:
diff --git a/arch/arm/mach-s3c2410/include/mach/hardware.h b/arch/arm/mach-s3c24
index 74d5a1a..db72beb 100644
--- a/arch/arm/mach-s3c2410/include/mach/hardware.h
+++ b/arch/arm/mach-s3c2410/include/mach/hardware.h
@@ -131,7 +131,4 @@ extern int s3c2412_gpio_set_sleepcfg(unsigned int
pin, unsig
/* machine specific hardware definitions should go after this */
-/* currently here until moved into config (todo) */
-#define CONFIG_NO_MULTIWORD_IO
-
#endif /* __ASM_ARCH_HARDWARE_H */
There are a couple of other hunks which look like they may warrant the
same treatment but I want to re-check just to make sure:
diff --git a/arch/arm/mach-s3c2410/include/mach/io.h b/arch/arm/mach-s3c2410/inc
lude/mach/io.h
index 9813dbf..c477771 100644
--- a/arch/arm/mach-s3c2410/include/mach/io.h
+++ b/arch/arm/mach-s3c2410/include/mach/io.h
@@ -9,7 +9,7 @@
#ifndef __ASM_ARM_ARCH_IO_H
#define __ASM_ARM_ARCH_IO_H
-#include <mach/hardware.h>
+#include <mach/map.h>
#define IO_SPACE_LIMIT 0xffffffff
diff --git a/arch/arm/plat-s3c24xx/clock-dclk.c b/arch/arm/plat-s3c24xx/clock-dclk.c
index 5b75a79..35219dc 100644
--- a/arch/arm/plat-s3c24xx/clock-dclk.c
+++ b/arch/arm/plat-s3c24xx/clock-dclk.c
@@ -18,6 +18,7 @@
#include <mach/regs-clock.h>
#include <mach/regs-gpio.h>
+#include <mach/hardware.h>
#include <plat/clock.h>
#include <plat/cpu.h>
^ permalink raw reply related
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Russell King @ 2009-03-11 9:41 UTC (permalink / raw)
To: Takashi Iwai
Cc: Stephen Rothwell, linux-next, Ben Dooks, Mark Brown,
Alexander Schulz
In-Reply-To: <s5h63igifin.wl%tiwai@suse.de>
On Wed, Mar 11, 2009 at 10:18:40AM +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2009 08:52:54 +0000,
> Russell King wrote:
> >
> > On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > > Hi Takashi,
> > >
> > > Today's linux-next merge of the sound tree got a conflict in
> > > arch/arm/mach-shark/include/mach/io.h between commit
> > > eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> > > and new defconfig") from the arm tree and commit
> > > 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> > > headers") from the sound tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary.
> >
> > NAK to this patch.
> >
> > The greater concern is WTF are cleanup patches for the ARM architecture
> > going via the sound tree. Especially patches which I have concerns about.
> >
> > > --- a/arch/arm/mach-shark/include/mach/io.h
> > > +++ b/arch/arm/mach-shark/include/mach/io.h
> > > @@@ -11,10 -11,10 +11,10 @@@
> > > #ifndef __ASM_ARM_ARCH_IO_H
> > > #define __ASM_ARM_ARCH_IO_H
> > >
> > > -#define PCIO_BASE 0xe0000000
> > > -#define IO_SPACE_LIMIT 0xffffffff
> > > +#define IO_SPACE_LIMIT 0xffffffff
> > >
> > > - #define __io(a) ((void __iomem *)(0xe0000000 + (a)))
> > > -#define __io(a) __typesafe_io(PCIO_BASE + (a))
> > > -#define __mem_pci(addr) (addr)
> > > ++#define __io(a) __typesafe_io(0xe0000000 + (a))
> >
> > Do not use __typesafe_io() with the addition here without first ensuring
> > that you've investigated whether it causes the compiler to mis-optimise
> > the code.
>
> Hrm, is that particular change also in ARM tree, no? Judging from the
> conflict-diff above, it looks like the patch just follows that...
>
> > Takashi - please remove all such patches from the sound tree. They
> > should not be in there.
>
> Oh, I thought Mark already sent you Ben's patches.
What is in my tree is:
------
diff --git a/arch/arm/mach-shark/include/mach/io.h b/arch/arm/mach-shark/include/mach/io.h
index c5cee82..9ccbcec 100644
--- a/arch/arm/mach-shark/include/mach/io.h
+++ b/arch/arm/mach-shark/include/mach/io.h
@@ -11,10 +11,10 @@
#ifndef __ASM_ARM_ARCH_IO_H
#define __ASM_ARM_ARCH_IO_H
-#define PCIO_BASE 0xe0000000
-#define IO_SPACE_LIMIT 0xffffffff
+#define IO_SPACE_LIMIT 0xffffffff
-#define __io(a) ((void __iomem *)(PCIO_BASE + (a)))
-#define __mem_pci(addr) (addr)
+#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
+
+#define __mem_pci(addr) (addr)
#endif
------
which is basically the same thing from Alexander Schulz but without the
addition of __typesafe_io(), and it's that which I'm objecting to.
> Sorry if it wasn't done yet.
It seems not. Searching for all messages from Mark containing the
string 'typesafe' results in no matches for messages since 1st January.
> Basically it's two patches to create a branch to move and update IIS
> and audio.h headers. Since some drivers require these changes, they
> have to be in the sound tree, too. Otherwise the tree gets
> inconsistent and can't be built.
Maybe, but the point here is that's not the only thing it does. It also
makes other changes _as well_ that are not relevent to the changes you're
talking about above.
> The relevant changes are in another branch (s3c-iis-header) of asoc
> tree so that it can be easily pulled to another tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git s3c-iis-header
>
> So, if you can pull these changes above into your GIT tree simply via
> "git pull", everything will settle down (as both trees share the same
> GIT objects).
Why do I want to pull stuff that I consider broken into my tree? Please
get rid of the use of __typesafe_io in the shark io.h header in your tree
or drop these patches entirely and ask the submitter to fix (whatever's
easier for you.)
As I said when Daniel proposed the change to Footbridge and I avoided
his patch for footbridge's io.h:
| On Mon, Feb 02, 2009 at 03:59:56PM +0000, Daniel Silverstone wrote:
| > Footbridge: __io() should __force to __iomem pointer
| >
| > This trivial patch fixes many warnings (around 850) by forcing
| > the return from __io() to be 'void __iomem *'. This stops sparse
| > warning about the implicit casting into an address space.
|
| I don't think gcc is bright enough to handle this - rather than doing
| the addition in the load/store instruction, I think you'll find that
| gcc will issue a separate add instruction with this.
|
| That's why I never converted any of the __io() macros which have an
| addition in them to use __typesafe_io().
the same applies to shark's io.h. The effect of this change has not been
evaluated and so should NOT be merged for mainline yet.
So, in case it still isn't clear, what I'm objecting to is replacing:
+#define __io(a) ((void __iomem *)(0xe0000000 + (a)))
with:
+#define __io(a) __typesafe_io(0xe0000000 + (a))
I repeat: please back this change out of your tree.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply related
* Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator
From: Ingo Molnar @ 2009-03-11 9:31 UTC (permalink / raw)
To: Tejun Heo
Cc: Sachin P. Sant, linux-next, Stephen Rothwell, linuxppc-dev, LKML
In-Reply-To: <49B75215.5010707@kernel.org>
* Tejun Heo <tj@kernel.org> wrote:
> Impact: remove spurious WARN on legacy SMP percpu allocator
>
> Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
> tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
> allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
> for UP but legacy SMP allocator was forgotten. Fix it.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
> ---
> (RESEND: cc'ing Ingo. :-)
>
> Oops, that was a stupid omission. This patch should fix it. Ingo,
> please pull from the following git vector to receive the first first
> four patches from the use-dynamic-percpu-allocator-by-default patchset
> (without the actual conversion which can disrupt archs) + this patch.
> I moved the actual conversion patch into #tj-percpu-exp branch, so the
> pull should be safe.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git tj-percpu
>
> Thanks.
Pulled into tip:core/percpu, thanks a lot Tejun!
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Takashi Iwai @ 2009-03-11 9:18 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, Ben Dooks, Mark Brown,
Alexander Schulz
In-Reply-To: <20090311085254.GA30970@flint.arm.linux.org.uk>
At Wed, 11 Mar 2009 08:52:54 +0000,
Russell King wrote:
>
> On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> > Hi Takashi,
> >
> > Today's linux-next merge of the sound tree got a conflict in
> > arch/arm/mach-shark/include/mach/io.h between commit
> > eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> > and new defconfig") from the arm tree and commit
> > 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> > headers") from the sound tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
>
> NAK to this patch.
>
> The greater concern is WTF are cleanup patches for the ARM architecture
> going via the sound tree. Especially patches which I have concerns about.
>
> > --- a/arch/arm/mach-shark/include/mach/io.h
> > +++ b/arch/arm/mach-shark/include/mach/io.h
> > @@@ -11,10 -11,10 +11,10 @@@
> > #ifndef __ASM_ARM_ARCH_IO_H
> > #define __ASM_ARM_ARCH_IO_H
> >
> > -#define PCIO_BASE 0xe0000000
> > -#define IO_SPACE_LIMIT 0xffffffff
> > +#define IO_SPACE_LIMIT 0xffffffff
> >
> > - #define __io(a) ((void __iomem *)(0xe0000000 + (a)))
> > -#define __io(a) __typesafe_io(PCIO_BASE + (a))
> > -#define __mem_pci(addr) (addr)
> > ++#define __io(a) __typesafe_io(0xe0000000 + (a))
>
> Do not use __typesafe_io() with the addition here without first ensuring
> that you've investigated whether it causes the compiler to mis-optimise
> the code.
Hrm, is that particular change also in ARM tree, no? Judging from the
conflict-diff above, it looks like the patch just follows that...
> Takashi - please remove all such patches from the sound tree. They
> should not be in there.
Oh, I thought Mark already sent you Ben's patches.
Sorry if it wasn't done yet.
Basically it's two patches to create a branch to move and update IIS
and audio.h headers. Since some drivers require these changes, they
have to be in the sound tree, too. Otherwise the tree gets
inconsistent and can't be built.
The relevant changes are in another branch (s3c-iis-header) of asoc
tree so that it can be easily pulled to another tree:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git s3c-iis-header
So, if you can pull these changes above into your GIT tree simply via
"git pull", everything will settle down (as both trees share the same
GIT objects).
Please let me know if any better solution comes up.
thanks,
Takashi
^ permalink raw reply
* Re: linux-next: manual merge of the sound tree with the arm tree
From: Russell King @ 2009-03-11 8:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Takashi Iwai, linux-next, Ben Dooks, Mark Brown, Alexander Schulz
In-Reply-To: <20090310144528.0fa208dd.sfr@canb.auug.org.au>
On Tue, Mar 10, 2009 at 02:45:28PM +1100, Stephen Rothwell wrote:
> Hi Takashi,
>
> Today's linux-next merge of the sound tree got a conflict in
> arch/arm/mach-shark/include/mach/io.h between commit
> eab184c2362567f2b2e951b7bd0e0d353a7e5091 ("[ARM] 5363/1: Shark cleanup
> and new defconfig") from the arm tree and commit
> 8150bc886be5ce3cc301a2baca1fcf2cf7bd7f39 ("S3C24XX: Move and update IIS
> headers") from the sound tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
NAK to this patch.
The greater concern is WTF are cleanup patches for the ARM architecture
going via the sound tree. Especially patches which I have concerns about.
> --- a/arch/arm/mach-shark/include/mach/io.h
> +++ b/arch/arm/mach-shark/include/mach/io.h
> @@@ -11,10 -11,10 +11,10 @@@
> #ifndef __ASM_ARM_ARCH_IO_H
> #define __ASM_ARM_ARCH_IO_H
>
> -#define PCIO_BASE 0xe0000000
> -#define IO_SPACE_LIMIT 0xffffffff
> +#define IO_SPACE_LIMIT 0xffffffff
>
> - #define __io(a) ((void __iomem *)(0xe0000000 + (a)))
> -#define __io(a) __typesafe_io(PCIO_BASE + (a))
> -#define __mem_pci(addr) (addr)
> ++#define __io(a) __typesafe_io(0xe0000000 + (a))
Do not use __typesafe_io() with the addition here without first ensuring
that you've investigated whether it causes the compiler to mis-optimise
the code.
Takashi - please remove all such patches from the sound tree. They
should not be in there.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* where should I map 0x8000,0000 ~ 0xfc00,0000 to ?
From: AA @ 2009-03-11 8:53 UTC (permalink / raw)
To: sachinp, sfr, linux-kernel; +Cc: linuxppc-dev, linux-next, linux-kernel
In-Reply-To: <COL104-W4161BE11903ACD5CE8A80EB9E0@phx.gbl>
[-- Attachment #1.1: Type: text/plain, Size: 559 bytes --]
Hi all
I am newer to linux.
My board is MPC750+MPC106, and I use MAPB for MPC106.
Due to 106 datasheet,
0x8000,0000 -- 0xFC00,0000 for PCI memory space.
As you know, user space is 0~0xbfff,ffff (3G).
0xc000,0000 ~ 0xffff,ffff(1G) is for kernel.
And my question is:
1) where should I map this address space to ?
2) user application can access this address space directly?
_________________________________________________________________
梦幻K图，百变造型，让你的照片与众不同，快来MClub试试吧！
http://club.msn.cn/?form=3
[-- Attachment #1.2: Type: text/html, Size: 789 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox