* Re: linux-next: driver-core tree build failure
From: Greg KH @ 2008-11-19 6:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Kay Sievers, linux-next
In-Reply-To: <20081119132214.681066b4.sfr@canb.auug.org.au>
On Wed, Nov 19, 2008 at 01:22:14PM +1100, Stephen Rothwell wrote:
> Hi Kay,
>
> [Firstly, let me say that I appreciate all the work you are doing ...]
>
> On Wed, 19 Nov 2008 01:40:42 +0100 "Kay Sievers" <kay.sievers@vrfy.org> wrote:
> >
> > Is this the only one, or only the first failure you've seen with the
> > driver-core tree? Some of the patches we've been unable to test, and
> > unfortunately the maintainers didn't respond for weeks now.
>
> It is the first since that series of patches was added to the
> driver-core tree yesterday, but I have only built for powerpc and x86_64
> so far.
>
> The patch had a CC for Paul Mackerras but not for the list associated
> with the PowerPC archiecture (in MAINTAINERS - linuxppc-dev@ozlabs.org).
> Some maintainers are very busy and cannot (or don't) test every single
> patch sent to them but the patches would probably would receive more
> attention if CC'd to the associated list. [I am on the particular list
> and didn't see that patch posted.]
>
> [And the Acked-by: Geoff Levand would really only cover the ps3 part of
> the patch.]
>
> In any case, I assume it will be fixed tomorrow in Greg's tree.
Now fixed.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Greg KH @ 2008-11-19 6:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Kay Sievers
In-Reply-To: <20081119164317.9bfff78d.sfr@canb.auug.org.au>
On Wed, Nov 19, 2008 at 04:43:17PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 19 Nov 2008 11:30:31 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I have dropped the driver-core tree (and the usb tree that depends on it)
> > from linux-next for today.
>
> I had to drop the staging tree as well (since it depends on the usb
> tree), of course.
Right now there is no such dependancy (USB should build and apply just
fine without driver core, and staging depends on neither of these from
what I can see.)
But that's ok, I'll fix up the driver-core tree right now.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2008-11-19 5:43 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Kay Sievers
In-Reply-To: <20081119113031.28e2ae68.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Hi Greg,
On Wed, 19 Nov 2008 11:30:31 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I have dropped the driver-core tree (and the usb tree that depends on it)
> from linux-next for today.
I had to drop the staging tree as well (since it depends on the usb
tree), of course.
--
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
* linux-next: manual merge of the block tree
From: Stephen Rothwell @ 2008-11-19 3:21 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, Zhaolei, Fernando Luis Vázquez Cao
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
drivers/block/xen-blkfront.c between commit
68aee07f9bad2c830a898cf6d6bfc11ea24efc40 ("Release old elevator on change
elevator") from Linus' tree and commit
f7ed11048c85660828fa2017ea2e3da27235f76a ("xen-blkfront: set queue
paravirt flag") from the block tree.
I used the version from the block tree and will carry this fix for a
while but assume that you will fix the conflict in the block tree soon.
--
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: manual merge of the cifs tree
From: Stephen Rothwell @ 2008-11-19 2:32 UTC (permalink / raw)
To: David S. Miller
Cc: linux-next, Harvey Harrison, Jeff Layton, Steve French,
linux-cifs-client
In-Reply-To: <20081117134243.0d729c7a.sfr@canb.auug.org.au>
Hi Dave,
On Mon, 17 Nov 2008 13:42:43 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the cifs tree got a conflict in
> fs/cifs/connect.c between commit be859405487324ed548f1ba11dc949b8230ab991
> ("fs: replace NIPQUAD()") from the net tree and commit
> 14fbf50d695207754daeb96270b3027a3821121f ("cifs: reinstate sharing of SMB
> sessions sans races") from the cifs tree.
This conflict is now between Linus' tree and the net tree ...
I have fixed it up for today (see below) but assume you will fix it soon
in the net tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc fs/cifs/connect.c
index c7d3417,2df8e6d..0000000
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@@ -2221,44 -2078,43 +2221,44 @@@ cifs_mount(struct super_block *sb, stru
} else if (!rc) {
cFYI(1, ("Existing smb sess not found"));
pSesInfo = sesInfoAlloc();
- if (pSesInfo == NULL)
+ if (pSesInfo == NULL) {
rc = -ENOMEM;
- else {
- pSesInfo->server = srvTcp;
- sprintf(pSesInfo->serverName, "%pI4",
- &sin_server.sin_addr.s_addr);
- }
+ goto mount_fail_check;
+ }
+
+ /* new SMB session uses our srvTcp ref */
+ pSesInfo->server = srvTcp;
- sprintf(pSesInfo->serverName, "%u.%u.%u.%u",
- NIPQUAD(sin_server->sin_addr.s_addr));
++ sprintf(pSesInfo->serverName, "%pI4",
++ &sin_server->sin_addr.s_addr);
+
+ write_lock(&cifs_tcp_ses_lock);
+ list_add(&pSesInfo->smb_ses_list, &srvTcp->smb_ses_list);
+ write_unlock(&cifs_tcp_ses_lock);
+
+ /* volume_info.password freed at unmount */
+ if (volume_info.password) {
+ pSesInfo->password = volume_info.password;
+ /* set to NULL to prevent freeing on exit */
+ volume_info.password = NULL;
+ }
+ if (volume_info.username)
+ strncpy(pSesInfo->userName, volume_info.username,
+ MAX_USERNAME_SIZE);
+ if (volume_info.domainname) {
+ int len = strlen(volume_info.domainname);
+ pSesInfo->domainName = kmalloc(len + 1, GFP_KERNEL);
+ if (pSesInfo->domainName)
+ strcpy(pSesInfo->domainName,
+ volume_info.domainname);
+ }
+ pSesInfo->linux_uid = volume_info.linux_uid;
+ pSesInfo->overrideSecFlg = volume_info.secFlg;
+ down(&pSesInfo->sesSem);
- if (!rc) {
- /* volume_info.password freed at unmount */
- if (volume_info.password) {
- pSesInfo->password = volume_info.password;
- /* set to NULL to prevent freeing on exit */
- volume_info.password = NULL;
- }
- if (volume_info.username)
- strncpy(pSesInfo->userName,
- volume_info.username,
- MAX_USERNAME_SIZE);
- if (volume_info.domainname) {
- int len = strlen(volume_info.domainname);
- pSesInfo->domainName =
- kmalloc(len + 1, GFP_KERNEL);
- if (pSesInfo->domainName)
- strcpy(pSesInfo->domainName,
- volume_info.domainname);
- }
- pSesInfo->linux_uid = volume_info.linux_uid;
- pSesInfo->overrideSecFlg = volume_info.secFlg;
- down(&pSesInfo->sesSem);
- /* BB FIXME need to pass vol->secFlgs BB */
- rc = cifs_setup_session(xid, pSesInfo,
- cifs_sb->local_nls);
- up(&pSesInfo->sesSem);
- if (!rc)
- atomic_inc(&srvTcp->socketUseCount);
- }
+ /* BB FIXME need to pass vol->secFlgs BB */
+ rc = cifs_setup_session(xid, pSesInfo,
+ cifs_sb->local_nls);
+ up(&pSesInfo->sesSem);
}
/* search for existing tcon to this server share */
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2008-11-19 2:24 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Kay Sievers
In-Reply-To: <20081119132214.681066b4.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Wed, 19 Nov 2008 13:22:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 19 Nov 2008 01:40:42 +0100 "Kay Sievers" <kay.sievers@vrfy.org> wrote:
> >
> > Is this the only one, or only the first failure you've seen with the
> > driver-core tree? Some of the patches we've been unable to test, and
> > unfortunately the maintainers didn't respond for weeks now.
>
> In any case, I assume it will be fixed tomorrow in Greg's tree.
And maybe only the tested patches should have been put into Greg's
linux-next tree, hmmm?
--
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: driver-core tree build failure
From: Stephen Rothwell @ 2008-11-19 2:22 UTC (permalink / raw)
To: Kay Sievers; +Cc: Greg KH, linux-next
In-Reply-To: <ac3eb2510811181640r6c864c7en28a097d3e7c1ab75@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Hi Kay,
[Firstly, let me say that I appreciate all the work you are doing ...]
On Wed, 19 Nov 2008 01:40:42 +0100 "Kay Sievers" <kay.sievers@vrfy.org> wrote:
>
> Is this the only one, or only the first failure you've seen with the
> driver-core tree? Some of the patches we've been unable to test, and
> unfortunately the maintainers didn't respond for weeks now.
It is the first since that series of patches was added to the
driver-core tree yesterday, but I have only built for powerpc and x86_64
so far.
The patch had a CC for Paul Mackerras but not for the list associated
with the PowerPC archiecture (in MAINTAINERS - linuxppc-dev@ozlabs.org).
Some maintainers are very busy and cannot (or don't) test every single
patch sent to them but the patches would probably would receive more
attention if CC'd to the associated list. [I am on the particular list
and didn't see that patch posted.]
[And the Acked-by: Geoff Levand would really only cover the ps3 part of
the patch.]
In any case, I assume it will be fixed tomorrow in Greg's tree.
--
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
* linux-next: manual merge of the sched tree
From: Stephen Rothwell @ 2008-11-19 1:27 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-next, Peter Zijlstra, Kumar Gala
Hi all,
Today's linux-next merge of the sched tree got a conflict in
kernel/Makefile between commit 65ecc14a30ad21bed9aabdfd6a2ae1a1aaaa6a00
("Remove -mno-spe flags as they dont belong") from Linus' tree and commit
8bb8c4386d08f2cc5d871d22f220d35032213f84 ("sched, ftrace: trace sched.c")
from the sched tree.
I fixed it up (see below) and can carry it for a short while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc kernel/Makefile
index 03a45e7,46e67a3..0000000
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -19,12 -21,7 +19,11 @@@ CFLAGS_REMOVE_mutex-debug.o = -p
CFLAGS_REMOVE_rtmutex-debug.o = -pg
CFLAGS_REMOVE_cgroup-debug.o = -pg
CFLAGS_REMOVE_sched_clock.o = -pg
- CFLAGS_REMOVE_sched.o = -pg
endif
+ifdef CONFIG_FUNCTION_RET_TRACER
+CFLAGS_REMOVE_extable.o = -pg # For __kernel_text_address()
+CFLAGS_REMOVE_module.o = -pg # For __module_text_address()
+endif
obj-$(CONFIG_FREEZER) += freezer.o
obj-$(CONFIG_PROFILING) += profile.o
^ permalink raw reply
* Re: linux-next: driver-core tree build failure
From: Kay Sievers @ 2008-11-19 0:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next
In-Reply-To: <20081119113031.28e2ae68.sfr@canb.auug.org.au>
On Wed, Nov 19, 2008 at 01:30, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/kernel/vio.c: In function 'vio_register_device_node':
> arch/powerpc/kernel/vio.c:1246: error: incompatible type for argument 1 of 'dev_name'
>
> Caused by commit 92136135687b1f8f5d3f03baa3cec40dbc6e73e9 ("powerpc:
> struct device - replace bus_id with dev_name(), dev_set_name()").
>
> I have dropped the driver-core tree (and the usb tree that depends on it)
> from linux-next for today.
Yep, a '&' is missing. It should be
- __func__, viodev->dev.bus_id);
+ __func__, dev_name(&viodev->dev));
Is this the only one, or only the first failure you've seen with the
driver-core tree? Some of the patches we've been unable to test, and
unfortunately the maintainers didn't respond for weeks now.
Thanks,
Kay
^ permalink raw reply
* linux-next: driver-core tree build failure
From: Stephen Rothwell @ 2008-11-19 0:30 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi Greg,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/kernel/vio.c: In function 'vio_register_device_node':
arch/powerpc/kernel/vio.c:1246: error: incompatible type for argument 1 of 'dev_name'
Caused by commit 92136135687b1f8f5d3f03baa3cec40dbc6e73e9 ("powerpc:
struct device - replace bus_id with dev_name(), dev_set_name()").
I have dropped the driver-core tree (and the usb tree that depends on it)
from linux-next for today.
--
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: spinlock lockup with next-20081118 on powerpc
From: Stephen Rothwell @ 2008-11-18 23:44 UTC (permalink / raw)
To: ppc-dev; +Cc: linux-next, Jens Axboe
In-Reply-To: <20081119093023.48895b84.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
Hi all,
On Wed, 19 Nov 2008 09:30:23 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This was on a Power5 partition. I am attempting to reproduce the problem.
OK, it reproduces. The machine is a Power5 partition (IBM,9124-720
eServer OpenPower 720) with 1 (2 way threaded) cpu (gr, rev2.1, 1.5GHz),
2G of memory, 2 NUMA nodes running Ubuntu Gutsy.
--
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
* linux-next: spinlock lockup with next-20081118 on powerpc
From: Stephen Rothwell @ 2008-11-18 22:30 UTC (permalink / raw)
To: ppc-dev; +Cc: linux-next, Jens Axboe
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
Hi all,
I got this in my boot test last night:
Begin: Waiting for root file system... ...
BUG: spinlock lockup on CPU#1, vol_id/3246, c000000000b09700
Call Trace:
[c000000040ef7080] [c00000000000fb58] .show_stack+0x70/0x184 (unreliable)
[c000000040ef7130] [c00000000027adac] ._raw_spin_lock+0x140/0x17c
[c000000040ef71d0] [c0000000004ec648] ._spin_lock_irqsave+0x8c/0xc4
[c000000040ef7270] [c0000000000659dc] .lock_timer_base+0x38/0x90
[c000000040ef7310] [c000000000065b50] .__mod_timer+0x4c/0x11c
[c000000040ef73c0] [c00000000025ae9c] .blk_plug_device+0xc0/0xd8
[c000000040ef7440] [c00000000025bb90] .__make_request+0x498/0x518
[c000000040ef74f0] [c000000000259dc8] .generic_make_request+0x24c/0x2a4
[c000000040ef75b0] [c00000000025b6d0] .submit_bio+0x108/0x130
[c000000040ef7670] [c0000000001210e4] .submit_bh+0x174/0x1c0
[c000000040ef7700] [c0000000001259a8] .block_read_full_page+0x34c/0x3b4
[c000000040ef7820] [c000000000129a60] .blkdev_readpage+0x20/0x38
[c000000040ef78a0] [c0000000000c111c] .__do_page_cache_readahead+0x23c/0x2b8
[c000000040ef7980] [c0000000000c1370] .ondemand_readahead+0x1d8/0x210
[c000000040ef7a30] [c0000000000b7f20] .generic_file_aio_read+0x224/0x620
[c000000040ef7b60] [c0000000000f9020] .do_sync_read+0xc4/0x124
[c000000040ef7cf0] [c0000000000f98e0] .vfs_read+0xd8/0x1bc
[c000000040ef7d90] [c0000000000f9f0c] .sys_read+0x4c/0x8c
[c000000040ef7e30] [c0000000000084d4] syscall_exit+0x0/0x40
This was on a Power5 partition. I am attempting to reproduce the problem.
Any clues?
--
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-m68k.git
From: Stephen Rothwell @ 2008-11-18 21:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/m68k, Ralf Baechle, David Woodhouse,
Linux Kernel Development, linux-next
In-Reply-To: <Pine.LNX.4.64.0811182136060.27671@anakin>
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]
Hi Geert,
On Tue, 18 Nov 2008 21:49:01 +0100 (CET) Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> (Finally) I created an experimental git tree for Linux/m68k:
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git
>
> It contains more or less all patches I had in my quilt series at
> http://www.kernel.org/pub/linux/kernel/people/geert/linux-m68k-patches-2.6/
> A notable exception is m68k-PRIVATE-m68k-changes.diff, which hardcoded ARCH to
> m68k.
>
> I also created for-next and for-linus branches. Do they look OK?
They look good. I have added the for-linus branch as my m68k-current
tree and changed my m68k tree over to the for-next branch.
> If I did something wrong, please let me know.
> This is still experimental stuff, which may be rebased if needed.
That's fine as long as the commits in the for-next branch are: posted
somewhere relevant, reviewed, tested and destined for the next merge
window. (None of these requirements have changed from what should have
been in your quilt tree.)
I expect the for-linus branch to be fixes and stuff for the current
release.
--
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-m68k.git
From: Sam Ravnborg @ 2008-11-18 20:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/m68k, Ralf Baechle, David Woodhouse, Stephen Rothwell,
Linux Kernel Development, linux-next
In-Reply-To: <Pine.LNX.4.64.0811182136060.27671@anakin>
On Tue, Nov 18, 2008 at 09:49:01PM +0100, Geert Uytterhoeven wrote:
> (Finally) I created an experimental git tree for Linux/m68k:
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git
>
> It contains more or less all patches I had in my quilt series at
> http://www.kernel.org/pub/linux/kernel/people/geert/linux-m68k-patches-2.6/
> A notable exception is m68k-PRIVATE-m68k-changes.diff, which hardcoded ARCH to
> m68k.
>
> As suggested by David Woodhouse, I grouped the commits by topic. But unlike
> David's suggestion, I used topic branches, not topic repositories. Oh well,
> we'll see...
>
> I also created for-next and for-linus branches. Do they look OK?
>
> If I did something wrong, please let me know.
> This is still experimental stuff, which may be rebased if needed.
>
> In addition, one day I may pull from Ralf's repository that reflects the state
> of Linux/m68k CVS a few commits before our server died...
>
> Thanks for all your (past and future) help, suggestions, tips and tricks!
If you plan to keep it then it would be nice if
you could add a T: entry to MAINTAINERS.
This way we can find it again later...
Sam
^ permalink raw reply
* linux-m68k.git
From: Geert Uytterhoeven @ 2008-11-18 20:49 UTC (permalink / raw)
To: Linux/m68k
Cc: Ralf Baechle, David Woodhouse, Stephen Rothwell,
Linux Kernel Development, linux-next
(Finally) I created an experimental git tree for Linux/m68k:
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git
It contains more or less all patches I had in my quilt series at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-m68k-patches-2.6/
A notable exception is m68k-PRIVATE-m68k-changes.diff, which hardcoded ARCH to
m68k.
As suggested by David Woodhouse, I grouped the commits by topic. But unlike
David's suggestion, I used topic branches, not topic repositories. Oh well,
we'll see...
I also created for-next and for-linus branches. Do they look OK?
If I did something wrong, please let me know.
This is still experimental stuff, which may be rebased if needed.
In addition, one day I may pull from Ralf's repository that reflects the state
of Linux/m68k CVS a few commits before our server died...
Thanks for all your (past and future) help, suggestions, tips and tricks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: linux-next: procedures
From: Stephen Rothwell @ 2008-11-18 20:24 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-next, LKML, Andrew Morton, Linus
In-Reply-To: <20081118084757.5c92c878.randy.dunlap@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
Hi Randy,
On Tue, 18 Nov 2008 08:47:57 -0800 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> > The following will cause a tree to be temporarily dropped from linux-next:
> > - non-trivial conflicts with Linus' tree
> > - build failures
>
> One clarification, please.
>
> Does this mean build failures that _you_ see/experience during tree merging
> and not other reported build failures?
Build failures I see during merging will cause the tree to be dropped
immediately (this forces me to not spend time trying to fix others
problems), other build failures may take a day or two before the
offending tree gets identified and dropped (but hopefully it will be
fixed before that happens).
A tree being dropped during merging does not imply fault - it may well be
a combination of trees that is the problem and I am always open to people
explaining things to me. As long as we come up with a solution that I
can carry along. However, most of the build failures I have seen so far
have been unexpected impact on other architectures/configs (than those
tested by the author), procedures gone wrong or carelessness ...
Trees do get picked up again at the next opportunity i.e. I still
fetch, inspect and attempt to merge "dropped" trees just in case people
don't get around to telling me they are fixed.
--
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: sparc/firmware build failure
From: Stephen Rothwell @ 2008-11-18 20:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: David Miller, linux-next, jaswinder
In-Reply-To: <1227022637.27728.412.camel@macbook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi David,
On Tue, 18 Nov 2008 15:37:17 +0000 David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Wed, 2008-11-12 at 22:57 -0800, David Miller wrote:
> > > The firmware tree is still dropped. Please do a merge with Linus' tree
> > > and fix the conflicts.
> >
> > Yes, pretty please David :-)
>
> Apologies for the delay. This should be up to date again now.
Thanks for that.
--
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: lblnet tree build failure
From: Stephen Rothwell @ 2008-11-18 20:08 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-next
In-Reply-To: <200811180926.11318.paul.moore@hp.com>
[-- Attachment #1: Type: text/plain, Size: 271 bytes --]
Hi Paul,
On Tue, 18 Nov 2008 09:26:11 -0500 Paul Moore <paul.moore@hp.com> wrote:
>
> Okay, sorry about that, I'll get it fixed up for tomorrow.
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
* struct uart_port has no member named 'sysrq' (was: linux-next: parisc build failure)
From: Helge Deller @ 2008-11-18 19:24 UTC (permalink / raw)
To: Stephen Rothwell, linux-serial
Cc: Kyle McMartin, linux-parisc, linux-next, LKML, Alan Cox
In-Reply-To: <20081116231342.0cd747bd.sfr@canb.auug.org.au>
On Sunday 16 November 2008, Stephen Rothwell wrote:
> Hi Kyle,
>
> Today's linux-next build (parisc allmodconfig) failed like this:
>
> In file included from drivers/serial/mux.c:38:
> include/linux/serial_core.h: In function 'uart_handle_sysrq_char':
> include/linux/serial_core.h:450: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:451: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:451: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:453: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:456: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:473: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:474: error: 'struct uart_port' has no member named 'sysrq'
> include/linux/serial_core.h:477: error: 'struct uart_port' has no member named 'sysrq'
>
> This is happening in mainline as well. In fact, this has been happening
> back as far as I have results (Aug 27). The sysrq element of struct
> uart_port is dependent on CONFIG_SERIAL_CORE_CONSOLE while the references
> failing above are dependent on SUPPORT_SYSRQ which is defined if
> CONFIG_MAGIC_SYSRQ is defined in mux.c.
I assume you don't have CONFIG_SERIAL_CORE_CONSOLE set in your config, which is probably why this build failure shows up.
Looking at other serial drivers, which all seem to have similiar coding like mux.c, I'm wondering that it only shows up on parisc.
Anyway, since I assume we can't make the sysrq element of struct uart_port depended on SUPPORT_SYSRQ (since it depends on each serial driver if it wants to support the sysrq feature and we need to keep the size of struct uart_port constant), I think we need to add an additional check for CONFIG_SERIAL_CORE_CONSOLE to where we already check for SUPPORT_SYSRQ.
Proposed patch and RFC below.
-------
[RFC] [PATCH] check for SUPPORT_SYSRQ and CONFIG_SERIAL_CORE_CONSOLE before accessing the "sysrq" member of struct uart_port.
Serial drivers (like mux.c) can #define SUPPORT_SYSRQ to tell the core serial functions that they want to have SYSRQ-support built-in.
If SUPPORT_SYSRQ is defined, the functions uart_handle_sysrq_char() and uart_handle_break() in include/linux/serial_core.h unconditionally access the "sysrq" member of struct uart_port.
Since the "sysrq" member of struct uart_port is only compiled into the kernel if CONFIG_SERIAL_CORE_CONSOLE is defined, builds will break if
SUPPORT_SYSRQ is defined and CONFIG_SERIAL_CORE_CONSOLE is not defined.
This patch works around the problem by checking for SUPPORT_SYSRQ _and_ CONFIG_SERIAL_CORE_CONSOLE before accessing the "sysrq" member of struct uart_port.
Signed-off-by: Helge Deller <deller@gmx.de>
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 4e4f127..b9d79f1 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -446,7 +446,7 @@ int uart_resume_port(struct uart_driver *reg, struct uart_port *port);
static inline int
uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
{
-#ifdef SUPPORT_SYSRQ
+#if defined(SUPPORT_SYSRQ) && defined(CONFIG_SERIAL_CORE_CONSOLE)
if (port->sysrq) {
if (ch && time_before(jiffies, port->sysrq)) {
handle_sysrq(ch, port->info ? port->info->port.tty : NULL);
@@ -458,9 +458,6 @@ uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
#endif
return 0;
}
-#ifndef SUPPORT_SYSRQ
-#define uart_handle_sysrq_char(port,ch) uart_handle_sysrq_char(port, 0)
-#endif
/*
* We do the SysRQ and SAK checking like this...
@@ -468,7 +465,7 @@ uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
static inline int uart_handle_break(struct uart_port *port)
{
struct uart_info *info = port->info;
-#ifdef SUPPORT_SYSRQ
+#if defined(SUPPORT_SYSRQ) && defined(CONFIG_SERIAL_CORE_CONSOLE)
if (port->cons && port->cons->index == port->line) {
if (!port->sysrq) {
port->sysrq = jiffies + HZ*5;
^ permalink raw reply related
* Re: Can you add the staging tree to -next?
From: Stefan Richter @ 2008-11-18 18:36 UTC (permalink / raw)
To: Greg KH; +Cc: Geert Uytterhoeven, Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20081114173258.GC22980@kroah.com>
Greg KH wrote on November 14:
> On Fri, Nov 14, 2008 at 08:42:48AM +0100, Geert Uytterhoeven wrote:
>> Apart from the patches you receive against -next, is there any other
>> advantage, giving staging is disabled?
>
> That is a huge advantage, don't discount it. My staging tree has over
> 150 patches in it right now, and is quite diverged from what is in
> Linus's tree. I have been getting the same patches sent over and over
> to fix the same thing that is already resolved in my tree, as the
> developers are working against -next thinking that they were working
> with the latest development tree.
These people are missing that -next is not a development tree.
(Unless final integration tests count still as development.)
--
Stefan Richter
-=====-==--- =-== =--=-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: next-20081114: WARNING: at block/blk-barrier.c:246 blk_do_ordered()
From: Jens Axboe @ 2008-11-18 18:09 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: Miquel van Smoorenburg, LKML, linux-next
In-Reply-To: <a4423d670811181007o707540bahd3f1911b1d5a6f0d@mail.gmail.com>
On Tue, Nov 18 2008, Alexander Beregalov wrote:
> 2008/11/18 Alexander Beregalov <a.beregalov@gmail.com>:
> > 2008/11/17 Jens Axboe <jens.axboe@oracle.com>:
> >> On Mon, Nov 17 2008, Alexander Beregalov wrote:
> >>> 2008/11/15 Alexander Beregalov <a.beregalov@gmail.com>:
> >>> > 2008/11/15 Jens Axboe <jens.axboe@oracle.com>:
> >>> >> On Fri, Nov 14 2008, Alexander Beregalov wrote:
> >>> >>> WARNING: at block/blk-barrier.c:246 blk_do_ordered+0x22b/0x26a()
> >>> >>> Modules linked in:
> >>> >>> Pid: 0, comm: swapper Not tainted 2.6.28-rc4-next-20081114 #3
> >>> >>> Call Trace:
> >>> >>> <IRQ> [<ffffffff80236d63>] warn_on_slowpath+0x58/0x7d
> >>> >>> [<ffffffff802570e3>] ? mark_lock+0x1c/0x37a
> >>> >>> [<ffffffff803a69f9>] ? elv_rb_del+0x30/0x4b
> >>> >>> [<ffffffff803b1092>] ? cfq_remove_request+0x180/0x1d8
> >>> >>> [<ffffffff803afd03>] ? __cfq_slice_expired+0xd6/0xeb
> >>> >>> [<ffffffff803afd31>] ? cfq_slice_expired+0x19/0x1b
> >>> >>> [<ffffffff803b1832>] ? cfq_dispatch_requests+0x2c1/0x37e
> >>> >>> [<ffffffff803aa98c>] blk_do_ordered+0x22b/0x26a
> >>> >>> [<ffffffff803a6560>] elv_next_request+0x1d0/0x210
> >>> >>> [<ffffffff80439c7c>] scsi_request_fn+0x9e/0x539
> >>> >>> [<ffffffff80255c66>] ? put_lock_stats+0xe/0x27
> >>> >>> [<ffffffff803a827e>] blk_invoke_request_fn+0x3b/0x6e
> >>> >>> [<ffffffff803a87fd>] __blk_run_queue+0x25/0x29
> >>> >>> [<ffffffff803a8822>] blk_run_queue+0x21/0x35
> >>> >>> [<ffffffff80439509>] scsi_run_queue+0x2cf/0x379
> >>> >>> [<ffffffff8043a33e>] scsi_next_command+0x36/0x46
> >>> >>> [<ffffffff8043a509>] scsi_end_request+0x92/0xa4
> >>> >>> [<ffffffff8043aae7>] scsi_io_completion+0x1a7/0x3ad
> >>> >>> [<ffffffff80434551>] scsi_finish_command+0xe9/0xf2
> >>> >>> [<ffffffff8043afd5>] scsi_softirq_done+0x10e/0x117
> >>> >>> [<ffffffff803ac393>] blk_done_softirq+0x7f/0x8f
> >>> >>> [<ffffffff8023c173>] __do_softirq+0x70/0x101
> >>> >>> [<ffffffff8020cc0c>] call_softirq+0x1c/0x28
> >>> >>> [<ffffffff8020e229>] do_softirq+0x39/0x8a
> >>> >>> [<ffffffff8023bd78>] irq_exit+0x45/0xa2
> >>> >>> [<ffffffff8020e53a>] do_IRQ+0x16a/0x19c
> >>> >>> [<ffffffff8020bceb>] ret_from_intr+0x0/0xf
> >>> >>> <EOI> [<ffffffff80212e09>] ? mwait_idle+0x3e/0x48
> >>> >>> [<ffffffff80212e00>] ? mwait_idle+0x35/0x48
> >>> >>> [<ffffffff8020a940>] ? cpu_idle+0x51/0xba
> >>> >>> [<ffffffff80514f9c>] ? rest_init+0x70/0x72
> >>> >>> ---[ end trace 115cb4be7e150bb9 ]---
> >>> >>
> >>> >> I'm assuming this is new with -next and doesn't happen with 2.6.28-rc4?
> >>> > Yes.
> >>> >> Is it reproducible in -next?
> >>> > I have seen it only once yet.
> >>>
> >>> I have the same warning on 2.6.28-rc5-next-20081117, reproducible on dbench.
> > Bisected down to 70bfe2de81b32969db1b4939bf171bbe55bcf1ef
> > "elevator prevent flushing small requests to device"
> forget: revert fixes it.
That was my main culprit, thanks a lot for testing and taking the time
to bisect! I'll take a look at it and probably ask you to test a patch.
--
Jens Axboe
^ permalink raw reply
* Re: next-20081114: WARNING: at block/blk-barrier.c:246 blk_do_ordered()
From: Alexander Beregalov @ 2008-11-18 18:07 UTC (permalink / raw)
To: Jens Axboe, Miquel van Smoorenburg; +Cc: LKML, linux-next
In-Reply-To: <a4423d670811181005r3bbd99efk5b57a16fc3a7b767@mail.gmail.com>
2008/11/18 Alexander Beregalov <a.beregalov@gmail.com>:
> 2008/11/17 Jens Axboe <jens.axboe@oracle.com>:
>> On Mon, Nov 17 2008, Alexander Beregalov wrote:
>>> 2008/11/15 Alexander Beregalov <a.beregalov@gmail.com>:
>>> > 2008/11/15 Jens Axboe <jens.axboe@oracle.com>:
>>> >> On Fri, Nov 14 2008, Alexander Beregalov wrote:
>>> >>> WARNING: at block/blk-barrier.c:246 blk_do_ordered+0x22b/0x26a()
>>> >>> Modules linked in:
>>> >>> Pid: 0, comm: swapper Not tainted 2.6.28-rc4-next-20081114 #3
>>> >>> Call Trace:
>>> >>> <IRQ> [<ffffffff80236d63>] warn_on_slowpath+0x58/0x7d
>>> >>> [<ffffffff802570e3>] ? mark_lock+0x1c/0x37a
>>> >>> [<ffffffff803a69f9>] ? elv_rb_del+0x30/0x4b
>>> >>> [<ffffffff803b1092>] ? cfq_remove_request+0x180/0x1d8
>>> >>> [<ffffffff803afd03>] ? __cfq_slice_expired+0xd6/0xeb
>>> >>> [<ffffffff803afd31>] ? cfq_slice_expired+0x19/0x1b
>>> >>> [<ffffffff803b1832>] ? cfq_dispatch_requests+0x2c1/0x37e
>>> >>> [<ffffffff803aa98c>] blk_do_ordered+0x22b/0x26a
>>> >>> [<ffffffff803a6560>] elv_next_request+0x1d0/0x210
>>> >>> [<ffffffff80439c7c>] scsi_request_fn+0x9e/0x539
>>> >>> [<ffffffff80255c66>] ? put_lock_stats+0xe/0x27
>>> >>> [<ffffffff803a827e>] blk_invoke_request_fn+0x3b/0x6e
>>> >>> [<ffffffff803a87fd>] __blk_run_queue+0x25/0x29
>>> >>> [<ffffffff803a8822>] blk_run_queue+0x21/0x35
>>> >>> [<ffffffff80439509>] scsi_run_queue+0x2cf/0x379
>>> >>> [<ffffffff8043a33e>] scsi_next_command+0x36/0x46
>>> >>> [<ffffffff8043a509>] scsi_end_request+0x92/0xa4
>>> >>> [<ffffffff8043aae7>] scsi_io_completion+0x1a7/0x3ad
>>> >>> [<ffffffff80434551>] scsi_finish_command+0xe9/0xf2
>>> >>> [<ffffffff8043afd5>] scsi_softirq_done+0x10e/0x117
>>> >>> [<ffffffff803ac393>] blk_done_softirq+0x7f/0x8f
>>> >>> [<ffffffff8023c173>] __do_softirq+0x70/0x101
>>> >>> [<ffffffff8020cc0c>] call_softirq+0x1c/0x28
>>> >>> [<ffffffff8020e229>] do_softirq+0x39/0x8a
>>> >>> [<ffffffff8023bd78>] irq_exit+0x45/0xa2
>>> >>> [<ffffffff8020e53a>] do_IRQ+0x16a/0x19c
>>> >>> [<ffffffff8020bceb>] ret_from_intr+0x0/0xf
>>> >>> <EOI> [<ffffffff80212e09>] ? mwait_idle+0x3e/0x48
>>> >>> [<ffffffff80212e00>] ? mwait_idle+0x35/0x48
>>> >>> [<ffffffff8020a940>] ? cpu_idle+0x51/0xba
>>> >>> [<ffffffff80514f9c>] ? rest_init+0x70/0x72
>>> >>> ---[ end trace 115cb4be7e150bb9 ]---
>>> >>
>>> >> I'm assuming this is new with -next and doesn't happen with 2.6.28-rc4?
>>> > Yes.
>>> >> Is it reproducible in -next?
>>> > I have seen it only once yet.
>>>
>>> I have the same warning on 2.6.28-rc5-next-20081117, reproducible on dbench.
> Bisected down to 70bfe2de81b32969db1b4939bf171bbe55bcf1ef
> "elevator prevent flushing small requests to device"
forget: revert fixes it.
>>
>> How big is the file system, how much ram do you have, what are your
>> mount options, how many dbench clients, and what dbench version? I tried
>> reproducing it today with no luck on -git + for-2.6.29.
>
> /dev/root on / type xfs (rw,noatime,noquota)
> /dev/root 145G
> RAM 2G, Swap 3.9G
> x86_64 SMP
> dbench 3.0.4; 25 clients
>
^ permalink raw reply
* Re: next-20081114: WARNING: at block/blk-barrier.c:246 blk_do_ordered()
From: Alexander Beregalov @ 2008-11-18 18:05 UTC (permalink / raw)
To: Jens Axboe, Miquel van Smoorenburg; +Cc: LKML, linux-next
In-Reply-To: <20081117180604.GV26778@kernel.dk>
2008/11/17 Jens Axboe <jens.axboe@oracle.com>:
> On Mon, Nov 17 2008, Alexander Beregalov wrote:
>> 2008/11/15 Alexander Beregalov <a.beregalov@gmail.com>:
>> > 2008/11/15 Jens Axboe <jens.axboe@oracle.com>:
>> >> On Fri, Nov 14 2008, Alexander Beregalov wrote:
>> >>> WARNING: at block/blk-barrier.c:246 blk_do_ordered+0x22b/0x26a()
>> >>> Modules linked in:
>> >>> Pid: 0, comm: swapper Not tainted 2.6.28-rc4-next-20081114 #3
>> >>> Call Trace:
>> >>> <IRQ> [<ffffffff80236d63>] warn_on_slowpath+0x58/0x7d
>> >>> [<ffffffff802570e3>] ? mark_lock+0x1c/0x37a
>> >>> [<ffffffff803a69f9>] ? elv_rb_del+0x30/0x4b
>> >>> [<ffffffff803b1092>] ? cfq_remove_request+0x180/0x1d8
>> >>> [<ffffffff803afd03>] ? __cfq_slice_expired+0xd6/0xeb
>> >>> [<ffffffff803afd31>] ? cfq_slice_expired+0x19/0x1b
>> >>> [<ffffffff803b1832>] ? cfq_dispatch_requests+0x2c1/0x37e
>> >>> [<ffffffff803aa98c>] blk_do_ordered+0x22b/0x26a
>> >>> [<ffffffff803a6560>] elv_next_request+0x1d0/0x210
>> >>> [<ffffffff80439c7c>] scsi_request_fn+0x9e/0x539
>> >>> [<ffffffff80255c66>] ? put_lock_stats+0xe/0x27
>> >>> [<ffffffff803a827e>] blk_invoke_request_fn+0x3b/0x6e
>> >>> [<ffffffff803a87fd>] __blk_run_queue+0x25/0x29
>> >>> [<ffffffff803a8822>] blk_run_queue+0x21/0x35
>> >>> [<ffffffff80439509>] scsi_run_queue+0x2cf/0x379
>> >>> [<ffffffff8043a33e>] scsi_next_command+0x36/0x46
>> >>> [<ffffffff8043a509>] scsi_end_request+0x92/0xa4
>> >>> [<ffffffff8043aae7>] scsi_io_completion+0x1a7/0x3ad
>> >>> [<ffffffff80434551>] scsi_finish_command+0xe9/0xf2
>> >>> [<ffffffff8043afd5>] scsi_softirq_done+0x10e/0x117
>> >>> [<ffffffff803ac393>] blk_done_softirq+0x7f/0x8f
>> >>> [<ffffffff8023c173>] __do_softirq+0x70/0x101
>> >>> [<ffffffff8020cc0c>] call_softirq+0x1c/0x28
>> >>> [<ffffffff8020e229>] do_softirq+0x39/0x8a
>> >>> [<ffffffff8023bd78>] irq_exit+0x45/0xa2
>> >>> [<ffffffff8020e53a>] do_IRQ+0x16a/0x19c
>> >>> [<ffffffff8020bceb>] ret_from_intr+0x0/0xf
>> >>> <EOI> [<ffffffff80212e09>] ? mwait_idle+0x3e/0x48
>> >>> [<ffffffff80212e00>] ? mwait_idle+0x35/0x48
>> >>> [<ffffffff8020a940>] ? cpu_idle+0x51/0xba
>> >>> [<ffffffff80514f9c>] ? rest_init+0x70/0x72
>> >>> ---[ end trace 115cb4be7e150bb9 ]---
>> >>
>> >> I'm assuming this is new with -next and doesn't happen with 2.6.28-rc4?
>> > Yes.
>> >> Is it reproducible in -next?
>> > I have seen it only once yet.
>>
>> I have the same warning on 2.6.28-rc5-next-20081117, reproducible on dbench.
Bisected down to 70bfe2de81b32969db1b4939bf171bbe55bcf1ef
"elevator prevent flushing small requests to device"
>
> How big is the file system, how much ram do you have, what are your
> mount options, how many dbench clients, and what dbench version? I tried
> reproducing it today with no luck on -git + for-2.6.29.
/dev/root on / type xfs (rw,noatime,noquota)
/dev/root 145G
RAM 2G, Swap 3.9G
x86_64 SMP
dbench 3.0.4; 25 clients
^ permalink raw reply
* Re: linux-next: procedures
From: Randy Dunlap @ 2008-11-18 16:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Andrew Morton, Linus
In-Reply-To: <20081112173807.05cfadf0.sfr@canb.auug.org.au>
On Wed, 12 Nov 2008 17:38:07 +1100 Stephen Rothwell wrote:
...
> The following will cause a tree to be temporarily dropped from linux-next:
> - non-trivial conflicts with Linus' tree
> - build failures
Hi Stephen,
One clarification, please.
Does this mean build failures that _you_ see/experience during tree merging
and not other reported build failures?
Thanks,
~Randy
> - non-obvious conflicts with other trees (this will require
> us to come up with some way forward for the trees involved)
> - the contact for the tree being unresponsive
>
> Most conflicts will be notified to the contacts for the trees involved
> (some really trivial ones will not). Simple conflicts between trees I
> will try to fix up (if possible) and carry such resolutions as necessary.
>
> I will not, any more, carry fix up patches to make linux-next build or
> boot. If a tree is identified as causing such a problem, it will be
> dropped until the problem is fixed.
>
> This is all open to discussion ...
^ permalink raw reply
* Re: linux-next: sparc/firmware build failure
From: David Woodhouse @ 2008-11-18 15:37 UTC (permalink / raw)
To: David Miller; +Cc: sfr, linux-next, jaswinder
In-Reply-To: <20081112.225748.255613824.davem@davemloft.net>
On Wed, 2008-11-12 at 22:57 -0800, David Miller wrote:
> > The firmware tree is still dropped. Please do a merge with Linus' tree
> > and fix the conflicts.
>
> Yes, pretty please David :-)
Apologies for the delay. This should be up to date again now.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ 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