* Re: linux-next: avr32 build failure
From: Rusty Russell @ 2008-12-09 22:48 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Haavard Skinnemoen
In-Reply-To: <20081209174043.966eda84.sfr@canb.auug.org.au>
On Tuesday 09 December 2008 17:10:43 Stephen Rothwell wrote:
> Hi Rusty,
>
> The linux-next build (avr32 defconfig) failed like this:
>
> arch/avr32/lib/lib.a(findbit.o): In function `generic_find_next_le_bit':
> arch/avr32/lib/findbit.S:(.text+0xa6): multiple definition of `generic_find_next_le_bit'
> lib/lib.a(find_next_bit.o):find_next_bit.c:(.text+0x58): first defined here
OK, fixed by moving find_last_bit to its own file.
Thanks,
Rusty.
^ permalink raw reply
* Re: linux-next: manual merge of the net tree
From: J. Bruce Fields @ 2008-12-09 22:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, linux-next, Harvey Harrison, Chuck Lever
In-Reply-To: <20081209132136.c58c0ca5.sfr@canb.auug.org.au>
On Tue, Dec 09, 2008 at 01:21:36PM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the net tree got a conflict in
> fs/lockd/host.c between commit 3105d87fe1d311e80fd4781e82fa519fd5e2ffe2
> ("NLM: Support IPv6 scope IDs in nlm_display_address()") from the nfsd
> tree and various commits that replace the NIP* macros from the net tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks!
I could rebase nfsd onto net in this case if that'd simplify your life.
Assuming net never rebases that wouldn't cause additional conflicts for
you.
And that's more-or-less what we'll end up doing come the merge window
anyway.
(Or we could pull one of net or nfsd into the other.)
--b.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --cc fs/lockd/host.c
> index 472aac1,c48c263..0000000
> --- a/fs/lockd/host.c
> +++ b/fs/lockd/host.c
> @@@ -105,37 -104,25 +105,37 @@@ static void nlm_clear_port(struct socka
> }
> }
>
> -static void nlm_display_address(const struct sockaddr *sap,
> - char *buf, const size_t len)
> +static void nlm_display_ipv4_address(const struct sockaddr *sap, char *buf,
> + const size_t len)
> {
> const struct sockaddr_in *sin = (struct sockaddr_in *)sap;
> - snprintf(buf, len, NIPQUAD_FMT, NIPQUAD(sin->sin_addr.s_addr));
> ++ snprintf(buf, len, "%pI4", &sin->sin_addr.s_addr);
> +}
> +
> +static void nlm_display_ipv6_address(const struct sockaddr *sap, char *buf,
> + const size_t len)
> +{
> const struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)sap;
>
> + if (ipv6_addr_v4mapped(&sin6->sin6_addr))
> - snprintf(buf, len, NIPQUAD_FMT,
> - NIPQUAD(sin6->sin6_addr.s6_addr32[3]));
> ++ snprintf(buf, len, "%pI4",
> ++ &sin6->sin6_addr.s6_addr32[3]);
> + else if (sin6->sin6_scope_id != 0)
> - snprintf(buf, len, NIP6_FMT "%%%u", NIP6(sin6->sin6_addr),
> ++ snprintf(buf, len, "%pI6%%%u", &sin6->sin6_addr,
> + sin6->sin6_scope_id);
> + else
> - snprintf(buf, len, NIP6_FMT, NIP6(sin6->sin6_addr));
> ++ snprintf(buf, len, "%pI6", &sin6->sin6_addr);
> +}
> +
> +static void nlm_display_address(const struct sockaddr *sap,
> + char *buf, const size_t len)
> +{
> switch (sap->sa_family) {
> - case AF_UNSPEC:
> - snprintf(buf, len, "unspecified");
> - break;
> case AF_INET:
> - snprintf(buf, len, "%pI4", &sin->sin_addr.s_addr);
> + nlm_display_ipv4_address(sap, buf, len);
> break;
> case AF_INET6:
> - if (ipv6_addr_v4mapped(&sin6->sin6_addr))
> - snprintf(buf, len, "%pI4",
> - &sin6->sin6_addr.s6_addr32[3]);
> - else
> - snprintf(buf, len, "%pI6", &sin6->sin6_addr);
> + nlm_display_ipv6_address(sap, buf, len);
> break;
> default:
> snprintf(buf, len, "unsupported address family");
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree
From: David Miller @ 2008-12-09 21:42 UTC (permalink / raw)
To: greg; +Cc: sfr, linux-next, wangchen
In-Reply-To: <20081209154053.GA25934@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Tue, 9 Dec 2008 07:40:53 -0800
> On Mon, Dec 08, 2008 at 11:59:14PM -0800, David Miller wrote:
> > BTW, there is something else we can do.
> >
> > I can pull staging net driver changes into net-next-2.6
> >
> > We can either do it as a one-time thing to alleviate this
> > merge hassle, or we can try and make it a more ongoing
> > merge mechanism.
>
> I doubt you really want to do this, as there are some pretty big
> wireless driver additions in the staging tree right now, some under very
> heavy development.
>
> I have no problem with this kind of merge issues, I'll fix it up on my
> end, don't worry about it.
Ok, I just thought I'd offer :-)
^ permalink raw reply
* Re: linux-next: build failure
From: Jesse Barnes @ 2008-12-09 21:05 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Dave Airlie, linux-next, Eric Anholt, Venki Pallipadi
In-Reply-To: <20081209183404.637d3331.sfr@canb.auug.org.au>
On Monday, December 08, 2008 11:34 pm Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/gpu/drm/drm_gem.c: In function 'drm_gem_mmap':
> drivers/gpu/drm/drm_gem.c:519: error: '_PAGE_CACHE_WC' undeclared (first
> use in this function)
>
> Caused by commit 33b801854540a4f5205c0b2b4b91987e7f21af08 ("drm: GEM mmap
> support"). I tried to revert just that commit, but it lead me down a
> road of dependent commits, so I have reverted the whole drm tree for
> today.
>
> _PAGE_CACHE_WC appears to be defined only for x86 and, before the above
> commit, was not used outside arch/x86.
We might be able to use the new pgprot_writecombine function, but I think
that's only in an x86 branch atm... And it doesn't look like it's properly
stubbed out on non-x86, which means more #ifdefs.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* RE: next-20081209: fails to build IA64 allyesconfig
From: Luck, Tony @ 2008-12-09 18:55 UTC (permalink / raw)
To: Alexander Beregalov, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org
In-Reply-To: <a4423d670812090622h668b597ah7e4c9b4c5a1cbb@mail.gmail.com>
> GEN include/linux/bounds.h
> CC arch/ia64/kernel/asm-offsets.s
> In file included from include/linux/bitops.h:17,
> from include/linux/kernel.h:15,
> from include/linux/sched.h:52,
> from arch/ia64/kernel/asm-offsets.c:9:
> /home/alexb/linux-2.6/arch/ia64/include/asm/bitops.h: In function 'set_bit':
> /home/alexb/linux-2.6/arch/ia64/include/asm/bitops.h:47: error:
> implicit declaration of function 'BUILD_BUG_ON'
Same signature as http://marc.info/?l=linux-ia64&m=122723991902975&w=2
I was sure that I already applied that patch ... but I must have put
it into a temporary branch and forgot to merge it. I've applied it
for real this time and will push out soon.
-Tony
^ permalink raw reply
* RE: next-20081104 - kernel panic on ia64 box, at __mutex_lock_interruptible_slowpath
From: Luck, Tony @ 2008-12-09 18:50 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: sfr@canb.auug.org.au, linux-next@vger.kernel.org, LKML,
linux-ia64@vger.kernel.org
In-Reply-To: <20081209070730.GA12102@linux.vnet.ibm.com>
> next-20081204 kernel panic's, while booting up on ia64 box. This panic
> was not reproducible with the latest next-20081208 kernel.
I saw that too ... it was preceeded by an "impossible" WARN_ON message,
so I put it down to some experimental/untested code in linux-next.
-Tony
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree
From: Greg KH @ 2008-12-09 15:40 UTC (permalink / raw)
To: David Miller; +Cc: sfr, linux-next, wangchen
In-Reply-To: <20081208.235914.264894795.davem@davemloft.net>
On Mon, Dec 08, 2008 at 11:59:14PM -0800, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Mon, 8 Dec 2008 19:53:18 -0800
>
> > On Mon, Dec 08, 2008 at 12:35:57PM -0800, David Miller wrote:
> > > Because I have to do allmodconfig test builds _too_, and the build
> > > will fail for me if I do these reverts which really would suck.
> >
> > Ok, that's fine, as long as stephen can keep this patch in his tree,
> > I'll apply it to mine when you merge with Linus, as the staging tree
> > will probably be one of the last things before the next -rc1 window
> > closes.
>
> BTW, there is something else we can do.
>
> I can pull staging net driver changes into net-next-2.6
>
> We can either do it as a one-time thing to alleviate this
> merge hassle, or we can try and make it a more ongoing
> merge mechanism.
I doubt you really want to do this, as there are some pretty big
wireless driver additions in the staging tree right now, some under very
heavy development.
I have no problem with this kind of merge issues, I'll fix it up on my
end, don't worry about it.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the security-testing tree
From: David Howells @ 2008-12-09 15:28 UTC (permalink / raw)
To: Stephen Rothwell
Cc: dhowells, James Morris, linux-next, Miloslav Trmac, Al Viro
In-Reply-To: <20081209164026.022dfa39.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the security-testing tree got a conflict in
> drivers/char/tty_audit.c between commit
> 49518720d67042cf431e7f96aed5b0f5c51a84e3 ("[PATCH] Audit: Log TIOCSTI")
> from the audit-current tree and commit
> 66303bce9b924e35e435d35409d3abc371755767 ("CRED: Wrap task credential
> accesses in the tty driver") from the security-testing tree.
>
> The former moved the code that the latter was modifying. I fixed it up
> (see below) and can carry the fix as necessary.
Your changes look okay.
David
^ permalink raw reply
* [PATCH] simnet: convert to net_device_ops
From: Alexey Dobriyan @ 2008-12-09 15:08 UTC (permalink / raw)
To: Alexander Beregalov, davem; +Cc: linux-next, Netdev, linux-ia64
In-Reply-To: <a4423d670812090611v715309adq3e9d2d95254e2e16@mail.gmail.com>
On Tue, Dec 09, 2008 at 05:11:17PM +0300, Alexander Beregalov wrote:
> CC arch/ia64/hp/sim/simeth.o
> arch/ia64/hp/sim/simeth.c: In function 'simeth_probe1':
> arch/ia64/hp/sim/simeth.c:212: error: 'struct net_device' has no member named 'open'
[PATCH] simeth: convert to net_device_ops
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
arch/ia64/hp/sim/simeth.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
--- a/arch/ia64/hp/sim/simeth.c
+++ b/arch/ia64/hp/sim/simeth.c
@@ -167,6 +167,15 @@ netdev_read(int fd, unsigned char *buf, unsigned int len)
return ia64_ssc(fd, __pa(buf), len, 0, SSC_NETDEV_RECV);
}
+static const struct net_device_ops simeth_netdev_ops = {
+ .ndo_open = simeth_open,
+ .ndo_stop = simeth_close,
+ .ndo_start_xmit = simeth_tx,
+ .ndo_get_stats = simeth_get_stats,
+ .ndo_set_multicast_list = set_multicast_list, /* not yet used */
+
+};
+
/*
* Function shared with module code, so cannot be in init section
*
@@ -209,11 +218,7 @@ simeth_probe1(void)
local = netdev_priv(dev);
local->simfd = fd; /* keep track of underlying file descriptor */
- dev->open = simeth_open;
- dev->stop = simeth_close;
- dev->hard_start_xmit = simeth_tx;
- dev->get_stats = simeth_get_stats;
- dev->set_multicast_list = set_multicast_list; /* no yet used */
+ dev->netdev_ops = &simeth_netdev_ops;
err = register_netdev(dev);
if (err) {
^ permalink raw reply
* next-20081209: fails to build IA64 allyesconfig
From: Alexander Beregalov @ 2008-12-09 14:22 UTC (permalink / raw)
To: Luck, Tony, linux-ia64, linux-next
GEN include/linux/bounds.h
CC arch/ia64/kernel/asm-offsets.s
In file included from include/linux/bitops.h:17,
from include/linux/kernel.h:15,
from include/linux/sched.h:52,
from arch/ia64/kernel/asm-offsets.c:9:
/home/alexb/linux-2.6/arch/ia64/include/asm/bitops.h: In function 'set_bit':
/home/alexb/linux-2.6/arch/ia64/include/asm/bitops.h:47: error:
implicit declaration of function 'BUILD_BUG_ON'
^ permalink raw reply
* next-20081209: build problem at arch/ia64/hp/sim/simeth.c
From: Alexander Beregalov @ 2008-12-09 14:11 UTC (permalink / raw)
To: linux-next, Netdev, linux-ia64
CC arch/ia64/hp/sim/simeth.o
arch/ia64/hp/sim/simeth.c: In function 'simeth_probe1':
arch/ia64/hp/sim/simeth.c:212: error: 'struct net_device' has no
member named 'open'
arch/ia64/hp/sim/simeth.c:213: error: 'struct net_device' has no
member named 'stop'
arch/ia64/hp/sim/simeth.c:214: error: 'struct net_device' has no
member named 'hard_start_xmit'
arch/ia64/hp/sim/simeth.c:215: error: 'struct net_device' has no
member named 'get_stats'
arch/ia64/hp/sim/simeth.c:216: error: 'struct net_device' has no
member named 'set_multicast_list'
^ permalink raw reply
* byteorder headers on parisc
From: Alexey Dobriyan @ 2008-12-09 13:57 UTC (permalink / raw)
To: harvey.harrison; +Cc: linux-next, linux-kernel, sfr
In-Reply-To: <20081209185237.8bb715d7.sfr@canb.auug.org.au>
May I politely ask how this was compiled-tested?
It breaks every parisc config and it breaks every parisc config applied
against mainline too, so it's not some interaction issue.
CC arch/parisc/lib/iomap.o
arch/parisc/lib/iomap.c: In function 'iomem_read16':
arch/parisc/lib/iomap.c:154: error: implicit declaration of function '__fswab16'
arch/parisc/lib/iomap.c: In function 'iomem_read32':
arch/parisc/lib/iomap.c:164: error: implicit declaration of function '__fswab32'
commit e4fdb8c6aae569fec4c68c76fc0cdaa23ba9c77d
Author: Harvey Harrison <harvey.harrison@gmail.com>
Date: Tue Dec 2 03:28:17 2008 +0000
parisc: use the new byteorder headers
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Matthew Wilcox <willy@debian.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
diff --git a/arch/parisc/include/asm/byteorder.h b/arch/parisc/include/asm/byteorder.h
index db14831..83095c5 100644
--- a/arch/parisc/include/asm/byteorder.h
+++ b/arch/parisc/include/asm/byteorder.h
@@ -4,9 +4,10 @@
#include <asm/types.h>
#include <linux/compiler.h>
-#ifdef __GNUC__
+#define __BIG_ENDIAN
+#define __SWAB_64_THRU_32__
-static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 x)
+static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
{
__asm__("dep %0, 15, 8, %0\n\t" /* deposit 00ab -> 0bab */
"shd %%r0, %0, 8, %0" /* shift 000000ab -> 00ba */
@@ -14,8 +15,9 @@ static __inline__ __attribute_const__ __u16 ___arch__swab16(__u16 x)
: "0" (x));
return x;
}
+#define __arch_swab16 __arch_swab16
-static __inline__ __attribute_const__ __u32 ___arch__swab24(__u32 x)
+static inline __attribute_const__ __u32 __arch_swab24(__u32 x)
{
__asm__("shd %0, %0, 8, %0\n\t" /* shift xabcxabc -> cxab */
"dep %0, 15, 8, %0\n\t" /* deposit cxab -> cbab */
@@ -25,7 +27,7 @@ static __inline__ __attribute_const__ __u32 ___arch__swab24(__u32 x)
return x;
}
-static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 x)
+static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
{
unsigned int temp;
__asm__("shd %0, %0, 16, %1\n\t" /* shift abcdabcd -> cdab */
@@ -35,7 +37,7 @@ static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 x)
: "0" (x));
return x;
}
-
+#define __arch_swab32 __arch_swab32
#if BITS_PER_LONG > 32
/*
@@ -48,7 +50,8 @@ static __inline__ __attribute_const__ __u32 ___arch__swab32(__u32 x)
** HSHR 67452301 -> *6*4*2*0 into %0
** OR %0 | %1 -> 76543210 into %0 (all done!)
*/
-static __inline__ __attribute_const__ __u64 ___arch__swab64(__u64 x) {
+static inline __attribute_const__ __u64 __arch_swab64(__u64 x)
+{
__u64 temp;
__asm__("permh,3210 %0, %0\n\t"
"hshl %0, 8, %1\n\t"
@@ -58,25 +61,9 @@ static __inline__ __attribute_const__ __u64 ___arch__swab64(__u64 x) {
: "0" (x));
return x;
}
-#define __arch__swab64(x) ___arch__swab64(x)
-#define __BYTEORDER_HAS_U64__
-#elif !defined(__STRICT_ANSI__)
-static __inline__ __attribute_const__ __u64 ___arch__swab64(__u64 x)
-{
- __u32 t1 = ___arch__swab32((__u32) x);
- __u32 t2 = ___arch__swab32((__u32) (x >> 32));
- return (((__u64) t1 << 32) | t2);
-}
-#define __arch__swab64(x) ___arch__swab64(x)
-#define __BYTEORDER_HAS_U64__
-#endif
-
-#define __arch__swab16(x) ___arch__swab16(x)
-#define __arch__swab24(x) ___arch__swab24(x)
-#define __arch__swab32(x) ___arch__swab32(x)
-
-#endif /* __GNUC__ */
+#define __arch_swab64 __arch_swab64
+#endif /* BITS_PER_LONG > 32 */
-#include <linux/byteorder/big_endian.h>
+#include <linux/byteorder.h>
#endif /* _PARISC_BYTEORDER_H */
^ permalink raw reply related
* next-20081209: fail to build ia64/kvm
From: Alexander Beregalov @ 2008-12-09 13:09 UTC (permalink / raw)
To: linux-next, anthony.xu, xiantao.zhang, kvm-ia64
arch/ia64/kvm/kvm-ia64.c: In function 'kvm_relocate_vmm':
arch/ia64/kvm/kvm-ia64.c:1547: error: dereferencing pointer to incomplete type
arch/ia64/kvm/kvm-ia64.c:1548: error: dereferencing pointer to incomplete type
^ permalink raw reply
* next-20081209: pdflush: page allocation failure (xfs)
From: Alexander Beregalov @ 2008-12-09 12:54 UTC (permalink / raw)
To: linux-next, linux-mm, LKML, xfs
I got the message during compiling of the kernel.
(tainted by previous warning)
x86_64, 2Gb of RAM
pdflush: page allocation failure. order:0, mode:0x4000
Pid: 30415, comm: pdflush Tainted: G W 2.6.28-rc7-next-20081209 #3
Call Trace:
[<ffffffff8027c292>] __alloc_pages_internal+0x469/0x488
[<ffffffff802c170d>] ? bvec_alloc_bs+0xdc/0x11a
[<ffffffff8029b3b7>] alloc_slab_page+0x20/0x26
[<ffffffff8029b6b4>] __slab_alloc+0x26c/0x596
[<ffffffff802c170d>] ? bvec_alloc_bs+0xdc/0x11a
[<ffffffff802c170d>] ? bvec_alloc_bs+0xdc/0x11a
[<ffffffff8029bdbb>] kmem_cache_alloc+0x7b/0xbe
[<ffffffff802c170d>] bvec_alloc_bs+0xdc/0x11a
[<ffffffff802c17f4>] bio_alloc_bioset+0xa9/0x101
[<ffffffff802c18b6>] bio_alloc+0x10/0x1f
[<ffffffff80354781>] xfs_alloc_ioend_bio+0x23/0x52
[<ffffffff80354838>] xfs_submit_ioend+0x56/0xd4
[<ffffffff80354e9f>] xfs_page_state_convert+0x5e9/0x642
[<ffffffff803536bb>] ? xfs_count_page_state+0x97/0xb6
[<ffffffff803551cf>] xfs_vm_writepage+0xbe/0xf7
[<ffffffff8027c490>] __writepage+0x15/0x3b
[<ffffffff8027ce0b>] write_cache_pages+0x1cd/0x331
[<ffffffff8027c47b>] ? __writepage+0x0/0x3b
[<ffffffff8027cf91>] generic_writepages+0x22/0x28
[<ffffffff803550f3>] xfs_vm_writepages+0x45/0x4e
[<ffffffff8027cfc2>] do_writepages+0x2b/0x3b
[<ffffffff802b8e98>] __writeback_single_inode+0x186/0x2fa
[<ffffffff802b94c3>] ? generic_sync_sb_inodes+0x2bc/0x30a
[<ffffffff802b9433>] generic_sync_sb_inodes+0x22c/0x30a
[<ffffffff802b972b>] writeback_inodes+0x9d/0xf4
[<ffffffff8027d118>] wb_kupdate+0xa3/0x11e
[<ffffffff8027db96>] pdflush+0x11d/0x1d0
[<ffffffff8027d075>] ? wb_kupdate+0x0/0x11e
[<ffffffff8027da79>] ? pdflush+0x0/0x1d0
[<ffffffff80249cfd>] kthread+0x49/0x76
[<ffffffff8020c8fa>] child_rip+0xa/0x20
[<ffffffff802314de>] ? finish_task_switch+0x0/0xb9
[<ffffffff8020c2c0>] ? restore_args+0x0/0x30
[<ffffffff80249cb4>] ? kthread+0x0/0x76
[<ffffffff8020c8f0>] ? child_rip+0x0/0x20
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
CPU 2: hi: 0, btch: 1 usd: 0
CPU 3: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 109
CPU 1: hi: 186, btch: 31 usd: 154
CPU 2: hi: 186, btch: 31 usd: 76
CPU 3: hi: 186, btch: 31 usd: 39
Active_anon:46892 active_file:71530 inactive_anon:10315
inactive_file:243246 unevictable:0 dirty:15089 writeback:1402 unstable:0
free:1877 slab:116494 mapped:672 pagetables:401 bounce:0
DMA free:1452kB min:40kB low:48kB high:60kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
present:15072kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 1975 1975 1975
DMA32 free:6056kB min:5664kB low:7080kB high:8496kB
active_anon:187568kB inactive_anon:41260kB active_file:286120kB
inactive_file:972984kB unevictable:0kB present:2023256kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 1*4kB 1*8kB 0*16kB 1*32kB 2*64kB 2*128kB 2*256kB 1*512kB 0*1024kB
0*2048kB 0*4096kB = 1452kB
DMA32: 204*4kB 59*8kB 6*16kB 4*32kB 1*64kB 1*128kB 1*256kB 0*512kB
0*1024kB 0*2048kB 1*4096kB = 6056kB
314797 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 3911788kB
Total swap = 3911788kB
523088 pages RAM
22877 pages reserved
224954 pages shared
276682 pages non-shared
^ permalink raw reply
* Re: [PATCH] rfcomm/sock: fix build problem
From: David Miller @ 2008-12-09 12:44 UTC (permalink / raw)
To: a.beregalov-Re5JQEeQqe8AvxtiuMwx3w
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, mingo-X9Un+BFzKDI,
linux-next-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20081209123950.GA31294@orion>
From: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 9 Dec 2008 15:39:50 +0300
> net/bluetooth/rfcomm/sock.c: In function 'rfcomm_sock_ioctl':
> net/bluetooth/rfcomm/sock.c:795: error: 'sk' undeclared (first use in this function)
> net/bluetooth/rfcomm/sock.c:795: error: (Each undeclared identifier is reported only once
> net/bluetooth/rfcomm/sock.c:795: error: for each function it appears in.)
>
> It is a conflict between a418b893
> (Bluetooth: Enable per-module dynamic debug messages)
> and 45555c0e
> (bluetooth: fix warning in net/bluetooth/rfcomm/sock.c)
>
> Signed-off-by: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Already fixed in net-next-2.6.
BTW, your patch reintroduces a warning.
^ permalink raw reply
* [PATCH] rfcomm/sock: fix build problem
From: Alexander Beregalov @ 2008-12-09 12:39 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, mingo-X9Un+BFzKDI,
linux-next-u79uwXL29TY76Z2rM5mHXA
net/bluetooth/rfcomm/sock.c: In function 'rfcomm_sock_ioctl':
net/bluetooth/rfcomm/sock.c:795: error: 'sk' undeclared (first use in this function)
net/bluetooth/rfcomm/sock.c:795: error: (Each undeclared identifier is reported only once
net/bluetooth/rfcomm/sock.c:795: error: for each function it appears in.)
It is a conflict between a418b893
(Bluetooth: Enable per-module dynamic debug messages)
and 45555c0e
(bluetooth: fix warning in net/bluetooth/rfcomm/sock.c)
Signed-off-by: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/bluetooth/rfcomm/sock.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index ad00cbf..d63040f 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -787,9 +787,7 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
{
-#if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
struct sock *sk = sock->sk;
-#endif
int err;
BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
^ permalink raw reply related
* Re: linux-next: "aio: make the lookup_ioctx() lockless" causes s390 build bug
From: Kamalesh Babulal @ 2008-12-09 11:21 UTC (permalink / raw)
To: Jens Axboe
Cc: Heiko Carstens, Martin Schwidefsky, linux-next, Stephen Rothwell
In-Reply-To: <20081205220634.GR18255@kernel.dk>
* Jens Axboe <jens.axboe@oracle.com> [2008-12-05 23:06:35]:
> On Fri, Dec 05 2008, Heiko Carstens wrote:
> > Hi Jens,
> >
> > your patch "aio: make the lookup_ioctx() lockless" in linux-next
> > causes this build bug on s390:
> >
> > arch/s390/mm/pgtable.c: In function 's390_enable_sie':
> > arch/s390/mm/pgtable.c:266: error: invalid operands to binary || (have 'int' and 'struct hlist_head')
> > arch/s390/mm/pgtable.c:282: error: invalid operands to binary || (have 'int' and 'struct hlist_head')
> > make[1]: *** [arch/s390/mm/pgtable.o] Error 1
> > make: *** [arch/s390/mm] Error 2
> >
> > Could you please fix that? Thanks! ;)
>
> Something like this?
Hi Jens,
Thank you for the patch, it fixes the build failure.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
>
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index ef3635b..0767827 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -263,7 +263,7 @@ int s390_enable_sie(void)
> /* lets check if we are allowed to replace the mm */
> task_lock(tsk);
> if (!tsk->mm || atomic_read(&tsk->mm->mm_users) > 1 ||
> - tsk->mm != tsk->active_mm || tsk->mm->ioctx_list) {
> + tsk->mm != tsk->active_mm || !hlist_empty(&tsk->mm->ioctx_list)) {
> task_unlock(tsk);
> return -EINVAL;
> }
> @@ -279,7 +279,7 @@ int s390_enable_sie(void)
> /* Now lets check again if something happened */
> task_lock(tsk);
> if (!tsk->mm || atomic_read(&tsk->mm->mm_users) > 1 ||
> - tsk->mm != tsk->active_mm || tsk->mm->ioctx_list) {
> + tsk->mm != tsk->active_mm || !hlist_empty(&tsk->mm->ioctx_list)) {
> mmput(mm);
> task_unlock(tsk);
> return -EINVAL;
>
> --
> Jens Axboe
>
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH -next] rtc twl4030: rename ioctl function when RTC_INTF_DEV=n
From: Alessandro Zummo @ 2008-12-09 10:02 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, sameo, akpm
In-Reply-To: <493732D3.4020902@xenotime.net>
On Wed, 03 Dec 2008 17:30:59 -0800
Randy Dunlap <rdunlap@xenotime.net> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build error when RTC_INTF_DEV=n:
>
> drivers/rtc/rtc-twl4030.c:402: error: 'twl4030_rtc_ioctl' undeclared here (not in a function)
> make[3]: *** [drivers/rtc/rtc-twl4030.o] Error 1
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Marcel Holtmann @ 2008-12-09 9:12 UTC (permalink / raw)
To: David Miller; +Cc: sfr, linux-next, rmk
In-Reply-To: <20081209.010503.36680697.davem@davemloft.net>
Hi Dave,
> > On Tue, 09 Dec 2008 00:04:23 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> > > diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> > > index ad00cbf..ffaa6b0 100644
> > > --- a/net/bluetooth/rfcomm/sock.c
> > > +++ b/net/bluetooth/rfcomm/sock.c
> > > @@ -792,7 +792,7 @@ static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned lon
> > > #endif
> > > int err;
> > >
> > > - BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
> > > + BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
> >
> > I am not sure this is correct as there is a "sk" defined just above here
> > but surrounded by
> >
> > #if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
>
> Hmmm...
>
> BT_DBG is unconditionally defined these days. And it evaluates to
> pr_debug() which is conditional on other "DEBUG" or
> "DYNAMIC_PRINTK_DEBUG".
>
> This looks like a job for either __maybe_unused since I can't see
> a clean way to keep this issue inside of the BT_DBG() macro
> definition since it's varargs.
>
> So, I've gone with this for now:
>
> bluetooth: Fix unused var warning properly in rfcomm_sock_ioctl().
>
> As Stephen Rothwell points out, we don't want 'sock' here but
> rather we really do want 'sk'.
>
> This local var is protected by all sorts of bluetooth debugging
> kconfig vars, but BT_DBG() is just a straight pr_debug() call
> which is unconditional.
>
> pr_debug() evaluates it's args only if either DEBUG or
> CONFIG_DYNAMIC_PRINTK_DEBUG is defined.
>
> Solving this inside of the BT_DBG() macro is non-trivial since
> it's varargs. And these ifdefs are ugly.
>
> So, just mark this 'sk' thing __maybe_unused and kill the ifdefs.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/bluetooth/rfcomm/sock.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index ffaa6b0..d3fc6fc 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -787,12 +787,10 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
>
> static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
> {
> -#if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
> - struct sock *sk = sock->sk;
> -#endif
> + struct sock *sk __maybe_unused = sock->sk;
> int err;
>
> - BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
> + BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
>
> err = bt_sock_ioctl(sock, cmd, arg);
Acked-by: Marcel Holtmann <marcel@holtmann.org>
This looks actually pretty much how it should be. The ifdefs got added
because someone actually saw a compiler warning of an unused variable
when disabling CONFIG_BT_RFCOMM_TTY. So in 99% of the case this is
enabled, because otherwise it makes no sense, but for some really
embedded stuff where no TTYs are required they can disable it and shrink
their kernel a lot.
Regards
Marcel
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2008-12-09 9:05 UTC (permalink / raw)
To: sfr; +Cc: linux-next, marcel, rmk
In-Reply-To: <20081209195417.1b671249.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Dec 2008 19:54:17 +1100
> Hi Dave,
>
> On Tue, 09 Dec 2008 00:04:23 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> > diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> > index ad00cbf..ffaa6b0 100644
> > --- a/net/bluetooth/rfcomm/sock.c
> > +++ b/net/bluetooth/rfcomm/sock.c
> > @@ -792,7 +792,7 @@ static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned lon
> > #endif
> > int err;
> >
> > - BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
> > + BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
>
> I am not sure this is correct as there is a "sk" defined just above here
> but surrounded by
>
> #if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
Hmmm...
BT_DBG is unconditionally defined these days. And it evaluates to
pr_debug() which is conditional on other "DEBUG" or
"DYNAMIC_PRINTK_DEBUG".
This looks like a job for either __maybe_unused since I can't see
a clean way to keep this issue inside of the BT_DBG() macro
definition since it's varargs.
So, I've gone with this for now:
bluetooth: Fix unused var warning properly in rfcomm_sock_ioctl().
As Stephen Rothwell points out, we don't want 'sock' here but
rather we really do want 'sk'.
This local var is protected by all sorts of bluetooth debugging
kconfig vars, but BT_DBG() is just a straight pr_debug() call
which is unconditional.
pr_debug() evaluates it's args only if either DEBUG or
CONFIG_DYNAMIC_PRINTK_DEBUG is defined.
Solving this inside of the BT_DBG() macro is non-trivial since
it's varargs. And these ifdefs are ugly.
So, just mark this 'sk' thing __maybe_unused and kill the ifdefs.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/bluetooth/rfcomm/sock.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index ffaa6b0..d3fc6fc 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -787,12 +787,10 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
{
-#if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
- struct sock *sk = sock->sk;
-#endif
+ struct sock *sk __maybe_unused = sock->sk;
int err;
- BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
+ BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
err = bt_sock_ioctl(sock, cmd, arg);
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-12-09 8:54 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, marcel, rmk
In-Reply-To: <20081209.000423.18106461.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
Hi Dave,
On Tue, 09 Dec 2008 00:04:23 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> I just pushed the following fix for this, thanks Stephen:
>
> bluetooth: Fix rfcomm_sock_ioctl() build failure with debugging enabled.
>
> It's 'sock' not 'sk'.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/bluetooth/rfcomm/sock.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index ad00cbf..ffaa6b0 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -792,7 +792,7 @@ static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned lon
> #endif
> int err;
>
> - BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
> + BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
I am not sure this is correct as there is a "sk" defined just above here
but surrounded by
#if defined(CONFIG_BT_RFCOMM_TTY) || defined(CONFIG_BT_RFCOMM_DEBUG)
?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for December 9
From: Al Viro @ 2008-12-09 8:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20081209185237.8bb715d7.sfr@canb.auug.org.au>
On Tue, Dec 09, 2008 at 06:52:37PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20081208:
>
> Today's tree fails the powerpc allyesconfig build but succeeds with
> CONFIG_PROFILE_ALL_BRANCHES turned off.
>
> New trees:
> audit-current
> audit
FWIW, I've bumped the conflicting patch out of audit/for-linus and sent
pull request for rest of that queue. The rest will get thrown to
assorted trees, assuming that security folks are willing to host a rebased
version of [PATCH] Audit: Log TIOCSTI.
^ permalink raw reply
* Re: linux-next: m68k build failure
From: Stephen Rothwell @ 2008-12-09 8:50 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, geert, shemminger
In-Reply-To: <20081209.000052.32930290.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
Hi Dave,
On Tue, 09 Dec 2008 00:00:52 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Sorry about that. I just pushed a fix for this to net-next-2.6
> from Alexey D.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2008-12-09 8:04 UTC (permalink / raw)
To: sfr; +Cc: linux-next, marcel, rmk
In-Reply-To: <20081209172954.bab90ae4.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Dec 2008 17:29:54 +1100
> The linux-next build (arm xm_x2xx_defconfig) fails like this:
>
> net/bluetooth/rfcomm/sock.c: In function 'rfcomm_sock_ioctl':
> net/bluetooth/rfcomm/sock.c:795: error: 'sk' undeclared (first use in this function)
>
> Introduced (I think) by commit a418b893a6af11ae73c762ed5b76c1bad6dc19d8
> ("Bluetooth: Enable per-module dynamic debug messages").
I just pushed the following fix for this, thanks Stephen:
bluetooth: Fix rfcomm_sock_ioctl() build failure with debugging enabled.
It's 'sock' not 'sk'.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/bluetooth/rfcomm/sock.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index ad00cbf..ffaa6b0 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -792,7 +792,7 @@ static int rfcomm_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned lon
#endif
int err;
- BT_DBG("sk %p cmd %x arg %lx", sk, cmd, arg);
+ BT_DBG("sk %p cmd %x arg %lx", sock, cmd, arg);
err = bt_sock_ioctl(sock, cmd, arg);
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: m68k build failure
From: David Miller @ 2008-12-09 8:00 UTC (permalink / raw)
To: sfr; +Cc: linux-next, geert, shemminger
In-Reply-To: <20081209174534.17ad7991.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Dec 2008 17:45:34 +1100
> Hi Dave,
>
> The linux-next build (m68k defconfig) failed like this:
>
> drivers/net/hydra.c: In function 'hydra_init':
> /drivers/net/hydra.c:163: error: 'hydra_netdev_ops' undeclared (first use in this function)
>
> Caused by commit 5618f0d1193d6b051da9b59b0e32ad24397f06a4 ("hydra:
> convert to net_device_ops") which contains a typo in the net_device_ops
> structure naming (presumably cut and paste).
Sorry about that. I just pushed a fix for this to net-next-2.6
from Alexey D.
^ 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