All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [LTP] [PATCH] fix "aio_error" test
From: Bian Naimeng @ 2010-10-08  7:29 UTC (permalink / raw)
  To: Mitani; +Cc: ltp-list, 當座 健市
In-Reply-To: <000b01cb6062$9848f210$c8dad630$@co.jp>

> Hi,
> 
> 
> "conformance/interfaces/aio_error/3-1" failed with following message:
> ------------
> conformance/interfaces/aio_error/3-1: execution: FAILED: Output: 
> aio_error/3-1.c bad aio_read return value()
> ------------
> 
> This testset seems to be the error root test for "aio_error()".
> Therefore, "aio_error()" must be called after failure of "aio_write()", 
> I think.
> But, "exit()" is called when expected failure of "aio_write()" occurred:
> ------------(3-1.c)
>         if (aio_write(&aiocb) != 0)
>  {
>                 printf(TNAME " bad aio_read return value()\n");
>                 exit(PTS_FAIL);
>  }
> ------------
> 
> I think that "exit()" must be called when "aio_write()" succeeded.
> 

  Agree.

> And the message of unexpected movement of "aio_write()" is 
> "aio_read()"'s one.
> And the indent of this program "3-1.c" seems to include both space and tab.
> I want to revise them, too.
> 
 
  Another one should be fix like this.

	if (ret != EINVAL)
	{
-		printf(TNAME " errno is not EINVAL %s\n", strerror(errno));
+		printf(TNAME " errno is not EINVAL %s\n", strerror(ret));
		return PTS_FAIL;
	}

> 
> Signed-off-by: Tomonori Mitani <mitani@ryobi.co.jp>
> ============
> ---
> a/testcases/open_posix_testsuite/conformance/interfaces/aio_error/3-1.c	2010
> -09-22 22:31:24.000000000 +0900
> +++
> b/testcases/open_posix_testsuite/conformance/interfaces/aio_error/3-1.c	2010
> -09-30 09:51:42.000000000 +0900
> @@ -36,42 +36,41 @@
>  
>  int main()
>  {
> -
> -        char tmpfname[256];
> +	char tmpfname[256];
>  #define BUF_SIZE 512
> -        char buf[BUF_SIZE];
> -        int fd;
> -        struct aiocb aiocb;
> +	char buf[BUF_SIZE];
> +	int fd;
> +	struct aiocb aiocb;
>  	int ret=0;
>  
>  	if (sysconf(_SC_ASYNCHRONOUS_IO) != 200112L)
>  		return PTS_UNSUPPORTED;
>  
> -        snprintf(tmpfname, sizeof(tmpfname), "/tmp/pts_aio_error_3_1_%d",
> -                  getpid());
> -        unlink(tmpfname);
> -        fd = open(tmpfname, O_CREAT | O_RDWR | O_EXCL,
> -                  S_IRUSR | S_IWUSR);
> -        if (fd == -1)
> -        {
> -                printf(TNAME " Error at open(): %s\n",
> -                       strerror(errno));
> -                exit(PTS_UNRESOLVED);
> -        }
> +	snprintf(tmpfname, sizeof(tmpfname), "/tmp/pts_aio_error_3_1_%d",
> +			 getpid());
> +	unlink(tmpfname);
> +	fd = open(tmpfname, O_CREAT | O_RDWR | O_EXCL,
> +			  S_IRUSR | S_IWUSR);
> +	if (fd == -1)
> +	{
> +		printf(TNAME " Error at open(): %s\n",
> +			   strerror(errno));
> +		exit(PTS_UNRESOLVED);
> +	}
>  
> -        unlink(tmpfname);
> +	unlink(tmpfname);
>  
>  	memset (&aiocb, 0, sizeof (struct aiocb));
>  
> -        aiocb.aio_fildes = fd;
> -        aiocb.aio_buf = buf;
> -        aiocb.aio_reqprio = -1;
> -        aiocb.aio_nbytes = BUF_SIZE;
> +	aiocb.aio_fildes = fd;
> +	aiocb.aio_buf = buf;
> +	aiocb.aio_reqprio = -1;
> +	aiocb.aio_nbytes = BUF_SIZE;
>  
> -        if (aio_write(&aiocb) != 0)
> +	if (aio_write(&aiocb) == 0)
>  	{
> -                printf(TNAME " bad aio_read return value()\n");
> -                exit(PTS_FAIL);
> +		printf(TNAME " bad aio_write return value()\n");
> +		exit(PTS_FAIL);
>  	}
>  
>  	while (aio_error (&aiocb) == EINPROGRESS);
> ============
> 
> 
> Regards--
> 
> -Tomonori Mitani
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list

-- 
Regards
Bian Naimeng


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

^ permalink raw reply

* Re: [PATCH 10/18] fs: Factor inode hash operations into functions
From: Christoph Hellwig @ 2010-10-08  7:29 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-11-git-send-email-david@fromorbit.com>

On Fri, Oct 08, 2010 at 04:21:24PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Before replacing the inode hash locking with a more scalable
> mechanism, factor the removal of the inode from the hashes rather
> than open coding it in several places.
> 
> Based on a patch originally from Nick Piggin.

Looks good as an equal transformation, but what code is doing with
remove_inode_hash looks really buggy.  It's doing a re-hash of a live
inode which is probably causing enough problems by itself, but should
at least have locks for it.  Anyway, that's something for the coda folks
to sort out.

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply

* [PATCH V2 -tip] lib,x86_64: improve the performance of memcpy() for unaligned copy
From: Miao Xie @ 2010-10-08  7:28 UTC (permalink / raw)
  To: Ingo Molnar, Andi Kleen, Ma Ling, H. Peter Anvin, Thomas Gleixner,
	ykzhao
  Cc: Linux Kernel

memcpy of x86_64 hasn't been optimized for the unaligned copy like other
architecture, this patch fixed this problem.

I have tested this patch by my benchmark tool(doing 500 bytes memory copy
for 5,000,000 times)with various alignments and buffer sizes on my Core2
box.

Len	Src/Dst	Old memcpy	New memcpy
	align
---	-------	-------------	-------------
1	0/0	0s 47015us	0s 28265us
1	0/4	0s 28201us	0s 28199us
1	4/0	0s 28200us	0s 28199us
1	4/4	0s 28199us	0s 28206us
7	0/0	0s 24441us	0s 24438us
7	0/4	0s 24439us	0s 24438us
7	4/0	0s 24439us	0s 24438us
7	4/4	0s 24439us	0s 24439us
8	0/0	0s 20699us	0s 20687us
8	0/4	0s 20689us	0s 20901us
8	4/0	0s 20692us	0s 20679us
8	4/4	0s 20679us	0s 20679us
16	0/0	0s 18807us	0s 18802us
16	0/4	0s 26319us	0s 18800us
16	4/0	0s 18800us	0s 18806us
16	4/4	0s 26317us	0s 18803us
32	0/0	0s 35728us	0s 18800us
32	0/4	0s 35716us	0s 18800us
32	4/0	0s 35717us	0s 18800us
32	4/4	0s 35724us	0s 18803us
48	0/0	0s 26897us	0s 30080us
48	0/4	0s 33837us	0s 33838us
48	4/0	0s 27600us	0s 30079us
48	4/4	0s 30087us	0s 33854us
64	0/0	0s 41369us	0s 45115us
64	0/4	0s 62042us	0s 65800us
64	4/0	0s 56400us	0s 58278us
64	4/4	0s 84596us	0s 84606us
80	0/0	0s 35877us	0s 37611us
80	0/4	0s 77083us	0s 56404us
80	4/0	0s 52652us	0s 55611us
80	4/4	0s 75200us	0s 78968us
128	0/0	0s 52642us	0s 56403us
128	0/4	0s 95883us	0s 95891us
128	4/0	0s 114683us	0s 108511us
128	4/4	0s 144780us	0s 110927us
256	0/0	0s 80832us	0s 86489us
256	0/4	0s 178586us	0s 163562us
256	4/0	0s 208670us	0s 181719us
256	4/4	0s 270705us	0s 148525us
512	0/0	0s 156049us	0s 148348us
512	0/4	0s 313933us	0s 298908us
512	4/0	0s 411671us	0s 329025us
512	4/4	0s 516971us	0s 208746us
1024	0/0	0s 297067us	0s 274019us
1024	0/4	0s 584703us	0s 569604us
1024	4/0	0s 818104us	0s 616419us
1024	4/4	1s 22839us	0s 328953us
2048	0/0	0s 577077us	0s 524148us
2048	0/4	1s 125953us	1s 111258us
2048	4/0	1s 894000us	1s 202724us
2048	4/4	2s 331807us	0s 822437us
4096	0/0	1s 25881us	1s 34128us
4096	0/4	2s 619273us	2s 606489us
4096	4/0	3s 553989us	2s 390272us
4096	4/4	4s 737789us	1s 433213us

Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
 arch/x86/lib/memcpy_64.S |  135 +++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 134 insertions(+), 1 deletions(-)

diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 75ef61e..b0224f8 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -46,9 +46,39 @@ ENTRY(memcpy)
 	 * Use 32bit CMP here to avoid long NOP padding.
 	 */
 	cmp  $0x20, %edx
-	jb .Lhandle_tail
+	jbe .Lhandle_tail
 
 	/*
+	 * the code for unaligned copy is good for large-size copy(>100),
+	 * so if the size is small, we needn't check dst and src is aligned
+	 * or not.
+	 */
+	cmp $100, %edx
+	jb .Lboth_aligned
+
+	/*
+	 * unaligned access always leads to bad performance, so in order to
+	 * avoid unaligned access, we align the address(both src and dest)
+	 * first, and then copy from a aligned src to an aligned dst by using
+	 * shifts.
+	 * But we found if src is aligned, although dest is unaligned, the
+	 * performance of generic memory copy (That is reading data aligned
+	 * from the source and writing data unaligned to the dest) is better
+	 * than the one that uses shifts to avoid unaligned access.
+	 * So if src is aligned, we needn't check dest is aligned or not, just
+	 * goto .Lboth_aligned
+	 */
+	test $7, %esi		/* src align check */
+	jz .Lboth_aligned
+
+	/* if dest and src both are unaligned, goto unaligned copy */
+	test $7, %edi
+	jnz .Ldst_unaligned
+
+	jmp .Lsrc_unaligned_dst_aligned
+
+.Lboth_aligned:
+	/*
 	 * We check whether memory false dependece could occur,
 	 * then jump to corresponding copy mode.
 	 */
@@ -166,6 +196,109 @@ ENTRY(memcpy)
 
 .Lend:
 	retq
+
+	.p2align 4
+.Ldst_unaligned:
+	movq %rdi, %rcx
+	andq $7, %rcx		/* Align the destination */
+	negq %rcx
+	andq $7, %rcx
+	subq %rcx, %rdx
+
+	/* tune dst address */
+	movq (%rsi), %r8
+	movq %r8, (%rdi)
+	addq %rcx, %rdi
+	addq %rcx, %rsi
+
+	test $7, %esi		/* src align check */
+	jz .Lboth_aligned
+
+	.p2align 4
+.Lsrc_unaligned_dst_aligned:
+	push %rbx
+	push %r12
+	push %r13
+	push %r14
+	push %r15
+	/*
+	 * Calculate how to shift a word read at the memory operation
+	 * aligned srcp to make it aligned for copy.
+	 */
+	movq %rsi, %r14
+	andq $7, %r14
+	shlq $3, %r14
+	
+	movq $64, %r15
+	subq %r14, %r15
+
+	andq $-8, %rsi		/* src aligned */
+	movq 0*8(%rsi), %r8
+
+	movq %rdx, %rbx
+	shrq $5, %rbx
+	jz .Lsrc_unaligned_less32
+
+	/*
+	 * %r8 : store src[0]
+	 * %r9 : store src[1]
+	 * %r10: store src[2]
+	 * %r11: store src[3]
+	 * %r12: store src[4]
+	 * %r13: store the tmp data
+	 */ 
+	.p2align 4
+.Lsrc_unaligned_loop32:
+	movq 1*8(%rsi), %r9
+	movq 2*8(%rsi), %r10
+	movq 3*8(%rsi), %r11
+	movq 4*8(%rsi), %r12
+
+	movq %r9, %r13
+	movb %r14b, %cl
+	shrq %cl, %r8
+	shrq %cl, %r13
+	movb %r15b, %cl
+	shlq  %cl, %r9
+	orq %r8, %r9
+	movq %r10, %r8
+	shlq  %cl, %r10
+	orq %r13, %r10
+
+	movq %r11, %r13
+	movb %r14b, %cl
+	shrq %cl, %r8
+	shrq %cl, %r13
+	movb %r15b, %cl
+	shlq  %cl, %r11
+	orq %r8, %r11	
+	movq %r12, %r8
+	shlq  %cl, %r12
+	orq %r13, %r12
+
+	movq %r9, 0*8(%rdi)
+	movq %r10, 1*8(%rdi)
+	movq %r11, 2*8(%rdi)
+	movq %r12, 3*8(%rdi)
+	
+	leaq 4*8(%rdi), %rdi
+	leaq 4*8(%rsi), %rsi
+	decq %rbx
+	jnz .Lsrc_unaligned_loop32
+
+	.p2align 4
+.Lsrc_unaligned_less32:
+	shrq $3, %r14
+	addq %r14, %rsi
+	pop %r15
+	pop %r14
+	pop %r13
+	pop %r12
+	pop %rbx
+	andq $31, %rdx
+	jnz .Lhandle_tail
+	retq
+	
 	CFI_ENDPROC
 ENDPROC(memcpy)
 ENDPROC(__memcpy)
-- 
1.7.0.1

^ permalink raw reply related

* Re: [PATCH 1/2] ACPI: Do not export hid/modalias sysfs file for ACPI objects without a HID
From: Thomas Renninger @ 2010-10-08  7:27 UTC (permalink / raw)
  To: Zhang Rui
  Cc: lenb@kernel.org, kay.sievers@vrfy.org, linux-acpi@vger.kernel.org,
	Bjorn Helgaas
In-Reply-To: <1286497581.2111.3753.camel@rui>

On Friday 08 October 2010 02:26:21 Zhang Rui wrote:
> On Fri, 2010-10-01 at 16:53 +0800, Thomas Renninger wrote:
> > Boot and compile tested.
> > The fact that pnp.ids can now be empty needs testing on some
> > further machines, though.
...
> > -	result = device_create_file(&dev->dev, &dev_attr_hid);
> > -	if (result)
> > -		goto end;
> > +	if (!list_empty(&dev->pnp.ids)) {
> > +		result = device_create_file(&dev->dev, &dev_attr_hid);
> > +		if (result)
> > +			goto end;
> >  
> > -	result = device_create_file(&dev->dev, &dev_attr_modalias);
> > -	if (result)
> > -		goto end;
> > +		result = device_create_file(&dev->dev, &dev_attr_modalias);
> > +		if (result)
> > +			goto end;
> > +	}
> >  
> 
> the "hid" attribute exports the first entry of the device.pnp..ids list,
> while "modalias" exports all the entries.
> now it seems that the "hid" file is redundant, right?
Yep. You need some parsing, but udev is already doing that.
But it's sysfs api..., you'd need to add a:
printk_once("Deprecated HID file accessed by %s, use modalias instead\n",
              current->comm);
and deprecate that for some years.

    Thomas

^ permalink raw reply

* Re: [PATCH 09/18] fs: rework icount to be a locked variable
From: Christoph Hellwig @ 2010-10-08  7:27 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel, chris.mason, linux-btrfs
In-Reply-To: <1286515292-15882-10-git-send-email-david@fromorbit.com>

> index 2953e9f..9f04478 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -1964,8 +1964,14 @@ void btrfs_add_delayed_iput(struct inode *inode)
>  	struct btrfs_fs_info *fs_info = BTRFS_I(inode)->root->fs_info;
>  	struct delayed_iput *delayed;
>  
> -	if (atomic_add_unless(&inode->i_count, -1, 1))
> +	/* XXX: filesystems should not play refcount games like this */
> +	spin_lock(&inode->i_lock);
> +	if (inode->i_ref > 1) {
> +		inode->i_ref--;
> +		spin_unlock(&inode->i_lock);
>  		return;
> +	}
> +	spin_unlock(&inode->i_lock);

Yeah, all that i_count/i_ref mess in btrfs needs some serious work.
Chris?

> +
> +/*
> + * inode_lock must be held
> + */
> +void iref_locked(struct inode *inode)
> +{
> +	inode->i_ref++;
> +}
>  EXPORT_SYMBOL_GPL(iref_locked);

I'm a big fan of _GPL exports, but adding this for a trivial counter
increment seems a bit weird. 

>  int iref_read(struct inode *inode)
>  {
> -	return atomic_read(&inode->i_count);
> +	int ref;
> +
> +	spin_lock(&inode->i_lock);
> +	ref = inode->i_ref;
> +	spin_unlock(&inode->i_lock);
> +	return ref;
>  }

There's no need to lock a normal 32-bit variable for readers.

> +		inode->i_ref--;
> +		if (inode->i_ref == 0) {

		if (--inode->i_ref == 0) {

might be a bit more idiomatic.


^ permalink raw reply

* Re: [PATCH 03/18] fs: keep inode with backing-dev
From: Dave Chinner @ 2010-10-08  7:27 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <20101008070154.GB23595@lst.de>

On Fri, Oct 08, 2010 at 03:01:54AM -0400, Christoph Hellwig wrote:
> On Fri, Oct 08, 2010 at 04:21:17PM +1100, Dave Chinner wrote:
> > From: Nick Piggin <npiggin@suse.de>
> > 
> > Having inode on writeback lists of a different bdi than
> > inode->i_mapping->backing_dev_info makes it very difficult to do
> > per-bdi locking of the writeback lists. Add functions to move these
> > inodes over when the mapping backing dev is changed.
> > 
> > Also, rename i_mapping.backing_dev_info to i_mapping.a_bdi while we're
> > here. Succinct is nice, and it catches conversion errors.
> 
> NAK.  This is fixed by my patch to always use s_bdi for writeback
> purposed that hit Linus' tree two days ago.

Great. I'll drop it from the series then.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply

* Re: [PATCH 08/18] fs: add inode reference coutn read accessor
From: Christoph Hellwig @ 2010-10-08  7:24 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-9-git-send-email-david@fromorbit.com>

On Fri, Oct 08, 2010 at 04:21:22PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> To remove most of the remaining direct references to the inode
> reference count, add an iref_read() accessor function to read the
> current reference count.  New users of this function should be
> frowned upon, as there is rarely a good reason for looking at the
> current reference count.

IMHO adding this is rather pointless, it's not really buying us
anything.

But at least it looks correct.


^ permalink raw reply

* [Buildroot] [PATCH] New package: rrdtool
From: Peter Korsgaard @ 2010-10-08  7:23 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <4CA4A545.9050302@zacarias.com.ar>

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 Gustavo> Add new rrdtool package to make nitfy graphs.
 Gustavo> Using the 1.2 branch as a good compromise of size versus features.
 Gustavo> Enjoy.

Thanks, committed with a small tweak (use install hook to remove
examples).

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Johannes Sixt @ 2010-10-08  7:23 UTC (permalink / raw)
  To: Jonathan Nieder
  Cc: Sverre Rabbelier, David Barr, Git Mailing List,
	Ramkumar Ramachandra
In-Reply-To: <20101008070511.GA4671@burratino>

Am 10/8/2010 9:05, schrieb Jonathan Nieder:
> Johannes Sixt wrote:
>> Am 10/7/2010 22:28, schrieb Jonathan Nieder:
> 
>>> | For a command (like filter-branch --subdirectory-filter) that wants
>>> | to commit a lot of trees that already exist in the object db, writing
>>> | undeltified objects as loose files only to repack them later can
>>> | involve a significant amount[*] of overhead.
>>
>> 1. But when an object already exists in the db, it won't be written again,
>> will it?
> 
> In David's application, the trees already exist, but the commits are new.

But then what has this to do with "allow filemodify to set the root"?

> I suppose supporting M 040000 <tree> "" and C <path> "" could still
> be a good idea in that case anyway, for the convenience of front-end
> authors.

What is the special new thing here? That "" means 'empty string' == 'tree
at the root'? If so:

1. Then this is the missing piece in the justification. Then I could buy
that the observed speed-up is due to the reuse of an existing tree object
(which avoids parsing it and re-constructing it from its pieces because
fast-imports syntax didn't allow it otherwise). But it has nothing to do
with new loose objects (the re-constructed object would be identical to an
existing one).

2. Without this patch, would this syntax create a tree object with a name
consisting of two double-quotes in the root? Or would it be a syntax
error? How would one construct such an entry with this patch?

-- Hannes

^ permalink raw reply

* PROBLEM: brcm80211 hangs on 2.6.36-0.34.rc6.git3.fc15.x86_64
From: Jon Masters @ 2010-10-08  6:58 UTC (permalink / raw)
  To: linux-wireless; +Cc: Brett Rudley, Henry Ptasinski, Nohee Ko, Jon Masters, LKML

Folks,

I tried building the new brcm80211 driver from staging-next on Fedora rawhide
kernel 2.6.36-0.34.rc6.git3.fc15.x86_64. Now, of course, it's not the
staging-next kernel (I'll try that now this doesn't work) but perhaps this
report will still be of use to the Broadcom/other wireless folks.

After loading the module, the system hangs soon thereafter and does not respond
to any sysrq. I tried setting panic_on_oops and configuring kdump but I can't
get the system to panic in any case, and setting pause_on_oops doesn't give me
enough output, either. So the best I have at this time of night is the output
from a netconsole, which actually seems to work well enough (I don't see any
further output on the console itself).

This is happening on a brand new ASUS Eee PC 1015PEM netbook, which contains
the following Broadcom part:

02:00.0 0280: 14e4:4727 (rev 01)
        Subsystem: 1a3b:2047
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at fbffc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [58] Vendor Specific Information: Len=78 <?>
        Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [d0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [13c] Virtual Channel
        Capabilities: [160] Device Serial Number XX-XX-XX-XX-XX-XX-XX-XX
        Capabilities: [16c] Power Budgeting <?>
        Kernel modules: brcm80211

The firmware files have been installed correctly also. I will poke some
more, trying a pure upstream Linus tree and next-staging next, and I am
happy to try patches sent to me and let folks know what happens.

Jon.

--- output from netconsole ---

[  366.771940] console [netcon0] enabled
[  366.774936] netconsole: network logging started
[  392.980995] wl_pci_probe: bus 2 slot 0 func 0 irq 10
[  392.984887] brcm80211 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[  392.988883] brcm80211 0000:02:00.0: setting latency timer to 64
[  392.993356] PCI/DMA
[  393.122108] wlc_protection_upd: idx 2, val -1
[  393.126243] wlc_protection_upd: idx 1, val 0
[  393.130048] wlc_protection_upd: idx 12, val -1
[  393.133375] wlc_protection_upd: idx 11, val 0
[  393.137747] wlc_protection_upd: idx 14, val -1
[  393.142379] wlc_protection_upd: idx 13, val 0
[  393.146843] wlc_protection_upd: idx 15, val -1
[  393.151222] wlc_protection_upd: idx 4, val 2
[  393.155321] wl0: wlc_bmac_attach: vendor 0x14e4 device 0x4727
[  393.159746] Found chip type AI (0x13814313)
[  393.170595] Changing max_res_mask to 0xffff
[  393.174493] Changing min_res_mask to 0x200d
[  393.184581] Applying 4313 WARs
[  393.188558] wl0: wlc_bmac_corereset
[  393.192948] wl0: wlc_bmac_phy_reset
[  393.196628] wl0: wlc_bmac_core_phypll_ctl
[  393.200378] wl0: validate_chip_access
[  393.204171] wl0: wlc_setxband: bandunit 0
[  393.207939] wl0: wlc_bmac_corereset
[  393.211729] wl0: wlc_bmac_phy_reset
[  393.215377] wl0: wlc_bmac_core_phypll_ctl
[  393.219456] wl0: dma_attach: DMA64 osh ffff88007a9c9738 flags 0x0 ntxd 256 nrxd 256 rxbufsize 2048 rxextheadroom -1 nrxpost 32 rxoffset 38 dmaregstx ffffc90023788200 dmaregsrx ffffc90023788220
[  393.227474] ddoffsetlow 0x0 ddoffsethigh 0x80000000 dataoffsetlow 0x0 dataoffsethigh 0x80000000 addrext 1
[  393.231906] wl0: dma_attach: DMA64 osh ffff88007a9c9738 flags 0x0 ntxd 256 nrxd 0 rxbufsize 0 rxextheadroom -1 nrxpost 0 rxoffset 0 dmaregstx ffffc90023788240 dmaregsrx (null)
[  393.240982] ddoffsetlow 0x0 ddoffsethigh 0x80000000 dataoffsetlow 0x0 dataoffsethigh 0x80000000 addrext 1
[  393.246000] wl0: dma_attach: DMA64 osh ffff88007a9c9738 flags 0x0 ntxd 256 nrxd 0 rxbufsize 0 rxextheadroom -1 nrxpost 0 rxoffset 0 dmaregstx ffffc90023788280 dmaregsrx (null)
[  393.255802] ddoffsetlow 0x0 ddoffsethigh 0x80000000 dataoffsetlow 0x0 dataoffsethigh 0x80000000 addrext 1
[  393.260887] wl0: dma_attach: DMA64 osh ffff88007a9c9738 flags 0x0 ntxd 256 nrxd 0 rxbufsize 0 rxextheadroom -1 nrxpost 0 rxoffset 0 dmaregstx ffffc900237882c0 dmaregsrx (null)
[  393.270665] ddoffsetlow 0x0 ddoffsethigh 0x80000000 dataoffsetlow 0x0 dataoffsethigh 0x80000000 addrext 1
[  393.275879] wl0: wlc_coredisable
[  393.281137] wl0: wlc_bmac_core_phypll_ctl
[  393.286282] wl0: wlc_bmac_xtal: want 0
[  393.291265] wlc_protection_upd: idx 15, val -1
[  393.296230] wlc_bmac_copyfrom_vars, nvram vars totlen=2299
[  393.301390] wl0: wlc_stf_spatial_policy_set: val 0
[  393.306505] wl0: wlc_stf_txcore_set: Nsts 1 core_mask 1
[  393.311730] wl0: wlc_stf_txcore_set: Nsts 2 core_mask 3
[  393.316921] wl0: wlc_stf_txcore_set: Nsts 3 core_mask 7
[  393.322211] wl0: wlc_stf_txcore_set: Nsts 4 core_mask f
[  393.327403] wlc_protection_upd: idx 3, val 1
[  393.332647] wlc_protection_upd: idx 10, val 1
[  393.337935] wl0: wlc_channel_mgr_attach
[  393.343153] wlc_protection_upd: idx 3, val 1
[  393.348767] wl0: wlc_doiovar
[  393.352219] wl0: wlc_doiovar: id 1
[  393.568224] phy0: Selected rate control algorithm 'minstrel_ht'
[  393.600350]  (Compiled in . at 23:27:00 on Oct  7 2010)
[  393.605803] cfg80211: Calling CRDA for country: US
[  393.713588] cfg80211: Regulatory domain changed to country: US
[  393.718232]     (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[  393.722941]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[  393.727656]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[  393.728696] wl0: wlc_up:
[  393.728821] wl0: wlc_bmac_hw_up:
[  393.728829] wl0: wlc_bmac_xtal: want 1
[  393.728931] wl0: wlc_bmac_up_prep:
[  393.728938] wl0: wlc_bmac_xtal: want 1
[  393.729119] wl0: wlc_bmac_xtal: want 0
[  393.729597] wl0: wlc_doiovar
[  393.729605] wl0: wlc_doiovar: id 3
[  393.729613] wl0: wlc_doiovar
[  393.729619] wl0: wlc_doiovar: id 3
[  393.729626] wl0: wlc_doiovar
[  393.729632] wl0: wlc_doiovar: id 2
[  393.729640] wl0: wlc_doiovar
[  393.729647] wl0: wlc_doiovar: id 2
[  393.735224] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  393.775787]     (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  393.777961]     (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  393.780242]     (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  393.782427]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[  393.972913] ------------[ cut here ]------------
[  393.976695] WARNING: at net/mac80211/tx.c:1464 ieee80211_tx+0x1f2/0x225 [mac80211]()
[  393.980693] Hardware name: 1015PEM
[  393.984672] tx refused but queue active
[  393.987701] Modules linked in: arc4 ecb brcm80211 netconsole configfs sco bnep l2cap bluetooth cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_realtek snd_hda_intel uvcvideo microcode snd_hda_codec mac80211 videodev snd_hwdep v4l1_compat snd_seq v4l2_compat_ioctl32 eeepc_wmi snd_seq_device sparse_keymap snd_pcm cfg80211 atl1c joydev rfkill snd_timer snd soundcore snd_page_alloc shpchp wmi ipv6 cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
[  394.011827] Pid: 52, comm: kworker/u:2 Not tainted 2.6.36-0.34.rc6.git3.fc15.x86_64 #1
[  394.015619] Call Trace:
[  394.018946]  [<ffffffff810511dc>] warn_slowpath_common+0x85/0x9d
[  394.022272]  [<ffffffff81051297>] warn_slowpath_fmt+0x46/0x48
[  394.025541]  [<ffffffffa0280563>] ieee80211_tx+0x1f2/0x225 [mac80211]
[  394.030437]  [<ffffffffa0280705>] ieee80211_xmit+0x16f/0x183 [mac80211]
[  394.034881]  [<ffffffff8104ae42>] ? get_parent_ip+0x11/0x41
[  394.039746]  [<ffffffffa02817bd>] ? ieee80211_tx_skb+0x42/0x59 [mac80211]
[  394.044249]  [<ffffffffa02817bd>] ? ieee80211_tx_skb+0x42/0x59 [mac80211]
[  394.049202]  [<ffffffffa02817ca>] ieee80211_tx_skb+0x4f/0x59 [mac80211]
[  394.053710]  [<ffffffffa0283fec>] ieee80211_send_probe_req+0xd4/0xeb [mac80211]
[  394.058858]  [<ffffffffa026e283>] ieee80211_scan_work+0x383/0x441 [mac80211]
[  394.063561]  [<ffffffff81067bfb>] process_one_work+0x1ee/0x355
[  394.068896]  [<ffffffff81067b6d>] ? process_one_work+0x160/0x355
[  394.074173]  [<ffffffff8107db9e>] ? lock_acquired+0x1fd/0x20c
[  394.079432]  [<ffffffffa026df00>] ? ieee80211_scan_work+0x0/0x441 [mac80211]
[  394.084514]  [<ffffffff81068ce0>] worker_thread+0x104/0x19b
[  394.090828]  [<ffffffff81068bdc>] ? worker_thread+0x0/0x19b
[  394.095863]  [<ffffffff8106c63c>] kthread+0x9d/0xa5
[  394.099364]  [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10
[  394.102983]  [<ffffffff8149e850>] ? restore_args+0x0/0x30
[  394.106437]  [<ffffffff8106c59f>] ? kthread+0x0/0xa5
[  394.112118]  [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10
[  394.117614] ---[ end trace fb5725ec65dccb06 ]---
[  394.183446] ------------[ cut here ]------------
[  394.187555] WARNING: at net/mac80211/tx.c:1464 ieee80211_tx+0x1f2/0x225 [mac80211]()
[  394.191822] Hardware name: 1015PEM
[  394.196254] tx refused but queue active
[  394.200583] Modules linked in: arc4 ecb brcm80211 netconsole configfs sco bnep l2cap bluetooth cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_realtek snd_hda_intel uvcvideo microcode snd_hda_codec mac80211 videodev snd_hwdep v4l1_compat snd_seq v4l2_compat_ioctl32 eeepc_wmi snd_seq_device sparse_keymap snd_pcm cfg80211 atl1c joydev rfkill snd_timer snd soundcore snd_page_alloc shpchp wmi ipv6 cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
[  394.239443] Pid: 52, comm: kworker/u:2 Tainted: G        W   2.6.36-0.34.rc6.git3.fc15.x86_64 #1
[  394.245500] Call Trace:
[  394.251604]  [<ffffffff810511dc>] warn_slowpath_common+0x85/0x9d
[  394.257231]  [<ffffffff81051297>] warn_slowpath_fmt+0x46/0x48
[  394.263143]  [<ffffffffa0280563>] ieee80211_tx+0x1f2/0x225 [mac80211]
[  394.268589]  [<ffffffffa0280705>] ieee80211_xmit+0x16f/0x183 [mac80211]
[  394.274316]  [<ffffffff8104ae42>] ? get_parent_ip+0x11/0x41
[  394.279961]  [<ffffffffa02817bd>] ? ieee80211_tx_skb+0x42/0x59 [mac80211]
[  394.285447]  [<ffffffffa02817bd>] ? ieee80211_tx_skb+0x42/0x59 [mac80211]
[  394.291381]  [<ffffffffa02817ca>] ieee80211_tx_skb+0x4f/0x59 [mac80211]
[  394.296799]  [<ffffffffa0283fec>] ieee80211_send_probe_req+0xd4/0xeb [mac80211]
[  394.302638]  [<ffffffffa026e283>] ieee80211_scan_work+0x383/0x441 [mac80211]
[  394.308380]  [<ffffffff81067bfb>] process_one_work+0x1ee/0x355
[  394.314005]  [<ffffffff81067b6d>] ? process_one_work+0x160/0x355
[  394.319681]  [<ffffffff8107db9e>] ? lock_acquired+0x1fd/0x20c
[  394.325185]  [<ffffffffa026df00>] ? ieee80211_scan_work+0x0/0x441 [mac80211]
[  394.331011]  [<ffffffff81068ce0>] worker_thread+0x104/0x19b
[  394.336679]  [<ffffffff81068bdc>] ? worker_thread+0x0/0x19b
[  394.342100]  [<ffffffff8106c63c>] kthread+0x9d/0xa5
[  394.347845]  [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10
[  394.353409]  [<ffffffff8149e850>] ? restore_args+0x0/0x30
[  394.358774]  [<ffffffff8106c59f>] ? kthread+0x0/0xa5
[  394.364528]  [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10
[  394.370185] ---[ end trace fb5725ec65dccb07 ]---
[  394.436596] ------------[ cut here ]------------
[  394.441966] WARNING: at net/mac80211/tx.c:1464 ieee80211_tx+0x1f2/0x225 [mac80211]()
[  394.447790] Hardware name: 1015PEM
[  394.453188] tx refused but queue active
[  394.458810] Modules linked in: arc4 ecb brcm80211 netconsole configfs sco bnep l2cap bluetooth cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_realtek snd_hda_intel uvcvideo microcode snd_hda_codec mac80211 videodev snd_hwdep v4l1_compat snd_seq v4l2_compat_ioctl32 eeepc_wmi snd_seq_device sparse_keymap snd_pcm cfg80211 atl1c joydev rfkill snd_timer snd soundcore snd_page_alloc shpchp wmi ipv6 cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
[  394.497956] Pid: 52, comm: kworker/u:2 Tainted: G        W   2.6.36-0.34.rc6.git3.fc15.x86_64 #1
[  394.503916] Call Trace:
[  394.509699]  [<ffffffff810511dc>] warn_slowpath_common+0x85/0x9d
[  394.515231]  [<ffffffff81051297>] warn_slowpath_fmt+0x46/0x48
[  394.520826]  [<ffffffffa0280563>] ieee80211_tx+0x1f2/0x225 [mac80211]
[  394.526228]  [<ffffffffa0280705>] ieee80211_xmit+0x16f/0x183 [mac80211]
[  394.531645]  [<ffffffff8104ae42>] ? get_parent_ip+0x11/0x41
[  394.537029]  [<ffffffffa02817bd>] ? ieee80211_tx_skb+0x42/0x59 [mac80211]
[  394.542575]  [<ffffffffa02817bd>] ? ieee80211_tx_skb+0x42/0x59 [mac80211]
[  394.547913]  [<ffffffffa02817ca>] ieee80211_tx_skb+0x4f/0x59 [mac80211]
[  394.553395]  [<ffffffffa0283fec>] ieee80211_send_probe_req+0xd4/0xeb [mac80211]
[  394.558713]  [<ffffffffa026e283>] ieee80211_scan_work+0x383/0x441 [mac80211]
[  394.564177]  [<ffffffff81067bfb>] process_one_work+0x1ee/0x355
[  394.569633]  [<ffffffff81067b6d>] ? process_one_work+0x160/0x355
[  394.575097]  [<ffffffff8107db9e>] ? lock_acquired+0x1fd/0x20c
[  394.580602]  [<ffffffffa026df00>] ? ieee80211_scan_work+0x0/0x441 [mac80211]
[  394.585902]  [<ffffffff81068ce0>] worker_thread+0x104/0x19b
[  394.591438]  [<ffffffff81068bdc>] ? worker_thread+0x0/0x19b
[  394.596747]  [<ffffffff8106c63c>] kthread+0x9d/0xa5
[  394.602178]  [<ffffffff8100ab64>] kernel_thread_helper+0x4/0x10
[  394.607425]  [<ffffffff8149e850>] ? restore_args+0x0/0x30
[  394.612798]  [<ffffffff8106c59f>] ? kthread+0x0/0xa5
[  394.618105]  [<ffffffff8100ab60>] ? kernel_thread_helper+0x0/0x10
[  394.623491] ---[ end trace fb5725ec65dccb08 ]---
[  394.630148] wl0: wlc_bmac_xtal: want 1

^ permalink raw reply

* Re: [PATCH 0/3][RFC] Improve load balancing when tasks have large weight differential
From: Mike Galbraith @ 2010-10-08  7:22 UTC (permalink / raw)
  To: Nikhil Rao; +Cc: Ingo Molnar, Peter Zijlstra, Venkatesh Pallipadi, linux-kernel
In-Reply-To: <AANLkTinf7fj5A4DnQOWdj8QeMhf4exPGgpMUdTGA9mTC@mail.gmail.com>

On Wed, 2010-10-06 at 01:23 -0700, Nikhil Rao wrote:
> On Sun, Oct 3, 2010 at 8:08 PM, Mike Galbraith <efault@gmx.de> wrote:
> > On Wed, 2010-09-29 at 12:32 -0700, Nikhil Rao wrote:
> >> The closest I have is a quad-core dual-socket machine (MC, CPU
> >> domains). And I'm having trouble reproducing it on that machine as
> >> well :-( I ran 5 soaker threads (one of them niced to -15) for a few
> >> hours and didn't see the problem. Can you please give me some trace
> >> data & schedstats to work with?
> >
> > Booting with isolcpus or offlining the excess should help.
> >
> 
> Sorry for the late reply. Booting with isolcpus did the trick, thanks.
> 
> ... and now to dig into why this is happening.

I was poking it (again) yesterday, and it's kind of annoying.  I can't
call this behavior black/white broken.  It's freeing up a cache for a
very high priority task, which is kinda nice, but SMP nice is costing
25% of my box's processor power in this case too.  Hrmph.

	-Mike


^ permalink raw reply

* Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
From: Cousson, Benoit @ 2010-10-08  7:22 UTC (permalink / raw)
  To: Varadarajan, Charulatha
  Cc: Peter Ujfalusi, linux-omap@vger.kernel.org,
	alsa-devel@alsa-project.org, Kamat, Nishant, Datta, Shubhrajyoti,
	Basak, Partha, Girdwood, Liam, jhnikula@gmail.com,
	broonie@opensource.wolfsonmicro.com, ABRAHAM, KISHON VIJAY
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB030CF14091@dbde02.ent.ti.com>

Hi Charu,

On 10/8/2010 8:20 AM, Varadarajan, Charulatha wrote:
>
>
>> From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com]
>> Sent: Wednesday, October 06, 2010 12:47 PM
>> To: Varadarajan, Charulatha
>> Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat,
>> Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam;
>> jhnikula@gmail.com; broonie@opensource.wolfsonmicro.com; ABRAHAM, KISHON
>> VIJAY
>> Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx
>> devices
>>
>> Hello,
>
> Thanks for the quick response.
>
>>
>> On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:
>>> This patch series is targeted to implement mcbsp driver in
>>> hwmod way and to make use of pm_runtime APIs.
>>>
>>> This patch series is tested on OMAP3&  4 and yet to be tested
>>> on OMAP2.
>>>
>>> There are few clarifications required so that the next patch series
>>> can be implemented after aligning.
>>>
>>> 1. Audio layer is making use of mcbsp and it's dma base addresses and
>>> is closely coupled with omap-mcbsp.
>>> This can be handled either by
>>> a. providing an API with which Audio layer can get these addresses.
>>> (or)
>>> b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
>>> [1]
>>>
>>> Option (a) would only be a workaround to handle the situation. As
>>> audio is the only user for mcbsp, option (b) is better. If option(b)
>>> is agreed upon, the same can be addressed on top of the mcbsp hwmod
>>> series.
>>
>> it is true that at the moment only audio is using the McBSP ports, but
>> McBSP is
>> really flexible, it can run for example in SPI mode, and it can be
>> configured to
>> use other serial protocols.
>
> Yes.
>
>> I would go with option c.
>> Since ASoC is moving to multi-component (the conversion is already in
>> linux-
>> next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are
>> platform drivers.
>> So if the plat-omap/mcbsp would register the platform device for McBSP
>> clients
>> (we have only ASoC client at the moment), and use platform data to pass
>> the
>> needed information to the McBSP client driver, than we do not need new API.
>
> Sorry I am confused.
>
> With hwmod implementation, there is a device register code for mcbsp
> devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
> address, dma info are not part of pdata and are available to the driver
> only after probe. I do not understand how the multi-component design in
> ASOC can avoid the new API.
>
> Also with this multi-component approach in ASOC, two device
> registrations happens for a single mcbsp device with two different
> rames ("omap-mcbsp-dai.id"&  "omap-mcbsp.id"). Please explain if this
> what is expected?
>
>> We still need to modify the ASoC drivers to make use of this platform data,
>> but
>> at least we are going to keep the door open for others to use the McBSP
>> ports
>> for other than audio.
>
> Agreed. But the current omap-mcbsp driver cannot work standalone for
> OMAP3/4 due to the issues stated below:
> 1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
> registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
> are limited to 32-bit data accesses and hence poll mode would not work [x].
> 2. DMA transfers would also not work as it requires a patch similar to [y].
>
> Patches [x]&  [y] were rejected as there are no users other than asoc.
> If it is not agreed to move omap-mcbsp driver to asoc layer, we need to
> get the omap-mcbsp driver working as a standalone driver. Otherwise it
> is of no use keeping the mcbsp driver in plat-omap.
>
> Once [x]&  [y] patches are upstreamed, audio layer needs to be modified
> to make use of omap-mcbsp APIs rather than Audio layer calling dma
> APIs directly to transfer data.
>
> Coming back to the original question. Either we need to fix the broken
> legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
> layer. What do you say?
>
> [x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19531.html
> [y] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg04085.html
>>
>>> 2. Sidetone feature is available only in OMAP3 (McBSP2&3) which has
>>> different base address and sys configs compared to it's mcbsp port.
>>> Hence the mcbsp is considered as a single device with two hwmods
>>> for McBSP2&3 devices in OMAP3.
>>
>> Sounds fair enough.
>
> Thanks.
>
>>
>>> 3. Autoidle needs to be disabled for sidetone before enabling the
>> sidetone
>>> feature. There was a design proposed by Kishon [2] to add an API in
>> hwmod
>>> to modify the autoidle bit but was not agreed upon. How do we handle
>> this
>>> situation where the device has to disable or enable the autoidle bit at
>>> runtime?
>>
>> Yeah, this is really annoying problem. The McBSP ST should block autoidle
>> from
>> McBSP side, but it does not.
>> If you can not get through the proposed API, we should consider to switch
>> the
>> corresponding McBSP port to NoIdle, when the ST is in use (and restore the
>> idle
>> mode, when the ST has been disabled).
>> When McBSP is in NoIdle the interface clock is not going to be gated, so
>> ST
>> block will be running without a problem (ST needs the iface clock for
>> operation)
>>
>> What do you think?
>
> I think it might not be possible to handle this, as the clocks are the same for ST and mcbsp port. pm_runtime APIs are not called during ST enable/disable as clocks are already enabled while enabling mcbsp port. Hence the idle bit change cannot happen even if the oh->flags are modified runtime during ST enable/disable.

This is mainly because of the 2 hwmods for 1 device implementation, 
which make perfect sense in theory, but because of that bug, becomes 
tricky to handle it in the fmwk.

FYI, SDMA and MUSB are as well requiring some sysconfig change during 
runtime. So a couple of API will have to be implemented.
I guess we don't have the choice. Now, it is just a matter of having the 
right implementation.
I'll comment on that patch directly.

Benoit


>
>>>
>>> [1] https://patchwork.kernel.org/patch/225582/
>>> [2] https://patchwork.kernel.org/patch/134371/
>>>
>>> We would resend the same patch series by including alsa mailing list
>>> (alsa-devel@alsa-project.org)
>>>
>>> <<snip>>
>>
>> --
>> Péter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: [PATCH 07/18] exofs: use iput() for inode reference count decrements
From: Christoph Hellwig @ 2010-10-08  7:21 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-8-git-send-email-david@fromorbit.com>

On Fri, Oct 08, 2010 at 04:21:21PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Direct modification of the inode reference count is a no-no. Convert
> the exofs decrements to call iput() instead of acting directly on
> i_count.

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

The real question is why exofs got along with this so long.


^ permalink raw reply

* [Buildroot] [git commit master 1/1] package: Add rrdtool package
From: Peter Korsgaard @ 2010-10-08  7:20 UTC (permalink / raw)
  To: buildroot


commit: http://git.buildroot.net/buildroot/commit/?id=5d73b07ee731a890e13b00b529f74b093d5ca8d4
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

[Peter: use hook to remove examples]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 CHANGES                    |    2 +-
 package/Config.in          |    3 +++
 package/rrdtool/Config.in  |   15 +++++++++++++++
 package/rrdtool/rrdtool.mk |   28 ++++++++++++++++++++++++++++
 4 files changed, 47 insertions(+), 1 deletions(-)
 create mode 100644 package/rrdtool/Config.in
 create mode 100644 package/rrdtool/rrdtool.mk

diff --git a/CHANGES b/CHANGES
index 41406b8..3cf4a0f 100644
--- a/CHANGES
+++ b/CHANGES
@@ -21,7 +21,7 @@
 
 	Alpha, Cris, IA64 and Sparc64 architecture support removed.
 
-	New packages: gst-ffmpeg, libmpeg2, librsvg, xz
+	New packages: gst-ffmpeg, libmpeg2, librsvg, rrdtool, xz
 
 	Updated/fixed packages: acpid, alsa-lib, argus, at, autoconf,
 	automake, avahi, axel, beecrypt, berkeleydb, bind, bmon, boa,
diff --git a/package/Config.in b/package/Config.in
index 5e08d59..3b6cd19 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -85,6 +85,9 @@ endmenu
 
 menu "Graphic libraries and applications (graphic/text)"
 
+comment "Graphic applications"
+source "package/rrdtool/Config.in"
+
 comment "graphic libraries"
 source "package/directfb/Config.in"
 source "package/directfb-examples/Config.in"
diff --git a/package/rrdtool/Config.in b/package/rrdtool/Config.in
new file mode 100644
index 0000000..d315b57
--- /dev/null
+++ b/package/rrdtool/Config.in
@@ -0,0 +1,15 @@
+config BR2_PACKAGE_RRDTOOL
+	bool "rrdtool"
+	depends on BR2_USE_WCHAR
+	select BR2_PACKAGE_FREETYPE
+	select BR2_PACKAGE_LIBART
+	select BR2_PACKAGE_LIBPNG
+	select BR2_PACKAGE_ZLIB
+	help
+	  RRDtool is the OpenSource industry standard, high performance
+	  data logging and graphing system for time series data.
+
+	  http://oss.oetiker.ch/rrdtool/
+
+comment "rrdtool requires a toolchain with WCHAR support"
+	depends on !BR2_USE_WCHAR
diff --git a/package/rrdtool/rrdtool.mk b/package/rrdtool/rrdtool.mk
new file mode 100644
index 0000000..80789c6
--- /dev/null
+++ b/package/rrdtool/rrdtool.mk
@@ -0,0 +1,28 @@
+#############################################################
+#
+# rrdtool
+#
+#############################################################
+
+RRDTOOL_VERSION = 1.2.30
+RRDTOOL_SITE = http://oss.oetiker.ch/rrdtool/pub
+RRDTOOL_DEPENDENCIES = host-pkg-config freetype libart libpng zlib
+RRDTOOL_INSTALL_STAGING = YES
+RRDTOOL_CONF_ENV = rd_cv_ieee_works=yes rd_cv_null_realloc=nope \
+			ac_cv_func_mmap_fixed_mapped=yes
+RRDTOOL_CONF_OPT = --disable-perl --disable-python --disable-ruby \
+			--disable-tcl --program-transform-name=''
+
+define RRDTOOL_REMOVE_EXAMPLES
+	rm -rf $(TARGET_DIR)/usr/share/rrdtool/examples
+endef
+
+RRDTOOL_POST_INSTALL_TARGET_HOOKS += RRDTOOL_REMOVE_EXAMPLES
+
+define RRDTOOL_UNINSTALL_TARGET_CMDS
+	$(MAKE) DESTDIR=$(TARGET_DIR) -C $(@D) uninstall
+	rm -rf $(TARGET_DIR)/usr/share/rrdtool
+	rm -f $(TARGET_DIR)/usr/lib/librrd*
+endef
+
+$(eval $(call AUTOTARGETS,package,rrdtool))
-- 
1.7.1

^ permalink raw reply related

* Re: [PATCH 06/18] fs: Clean up inode reference counting
From: Christoph Hellwig @ 2010-10-08  7:20 UTC (permalink / raw)
  To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-7-git-send-email-david@fromorbit.com>

On Fri, Oct 08, 2010 at 04:21:20PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Lots of filesystem code open codes the act of getting a reference to
> an inode.  Factor the open coded inode lock, increment, unlock into
> a function iref().  Then rename __iget to iref_locked so that nothing
> is directly incrementing the inode reference count for trivial
> operations.
> 
> Originally based on a patch from Nick Piggin.

> +++ b/fs/anon_inodes.c
> @@ -111,10 +111,9 @@ struct file *anon_inode_getfile(const char *name,
>  	path.mnt = mntget(anon_inode_mnt);
>  	/*
>  	 * We know the anon_inode inode count is always greater than zero,
> -	 * so we can avoid doing an igrab() and we can use an open-coded
> -	 * atomic_inc().
> +	 * so we can avoid doing an igrab() by using iref().

I don't think there's a point keeping this comment.

> @@ -297,7 +297,7 @@ static void inode_wait_for_writeback(struct inode *inode)
>  
>  /*
>   * Write out an inode's dirty pages.  Called under inode_lock.  Either the
> - * caller has ref on the inode (either via __iget or via syscall against an fd)
> + * caller has ref on the inode (either via iref_locked or via syscall against an fd)

I'd say just drop the mentioning of how we got a reference to the inode,
it's just too confusing in this context.

> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -313,11 +313,20 @@ static void init_once(void *foo)
>  
>  	inode_init_once(inode);
>  }
> +EXPORT_SYMBOL_GPL(iref_locked);

I think the export is placed incorrectly here.

> +
> +void iref(struct inode *inode)
> +{
> +	spin_lock(&inode_lock);
> +	iref_locked(inode);
> +	spin_unlock(&inode_lock);
> +}
> +EXPORT_SYMBOL_GPL(iref);


> +void iref_locked(struct inode *inode)
>  {
>  	atomic_inc(&inode->i_count);
>  }

Please add a kerneldoc comment for both exported functions.
Also what's the point of taking inode_lock in iref when the only thing
we do is an atomic_in?  It's probably better only having iref for now
and only introduce iref_locked once the non-atomic increment needs
i_lock.

Also any chance to get an assert under a debug option the the reference
count really is non-zero?



^ permalink raw reply

* RE: [RFC][QEMU] ATI graphics VBIOS passthru support
From: Kay, Allen M @ 2010-10-08  7:20 UTC (permalink / raw)
  To: Huang2, Wei, Ian Jackson; +Cc: Xen-devel
In-Reply-To: <EE335F95F28A664DB4A21289D2AA053B8E1EA1CF@SAUSEXMBP01.amd.com>


[-- Attachment #1.1: Type: text/plain, Size: 2602 bytes --]

Hi Wei,

Is Catalyst driver the one on AMD website?  I think that's what I have in my win7 guest and it matches the symptom you are describing.  "lspci" reports my ATI card is a V5700 - although it says v3750 on the box.  Where can I get a working driver?

The patch looks reasonable to me in general.

Allen

From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
Sent: Thursday, October 07, 2010 9:06 PM
To: Kay, Allen M; Ian Jackson
Cc: Xen-devel
Subject: RE: [RFC][QEMU] ATI graphics VBIOS passthru support

Hi Allen,

Thanks for testing it out. We have tested this patch with Radeon 4850, 4870, FirePro V5700 and FirePro M5800. Unfortunately we don't have V3750 at hand. It is very possible this patch isn't compatible with V3750. We will try to get hold of one for debugging. For graphics which work with this path, users should be able to get rid of emulated gfx (such as Cirrus). I have successfully installed a Windows guest VM using this patch.

I also want to point out that there is still an issue. Users will see a black screen after installing Catalyst driver. Even though the screen appears to be black, the driver is actually functioning correctly (3DMark can be run with external monitor). Our driver team is currently debugging it and they believe this is easy to fix.

What is your opinion on this patch (and the solution) in general?

-Wei

From: Kay, Allen M [mailto:allen.m.kay@intel.com]
Sent: Thursday, October 07, 2010 6:58 PM
To: Huang2, Wei; Ian Jackson
Cc: Xen-devel
Subject: RE: [RFC][QEMU] ATI graphics VBIOS passthru support

Hi Wei,

This patch did not cause any problems with Intel IGD passthrough for me.  However, the monitor remained blank if I pass through ATI Firepro V3750 either as the primary display device or the secondary device (gfx_passthru=1/0).  Passing it through as the secondary device used to work.

Have you tested the patch with this graphics card?

Allen

From: Huang2, Wei [mailto:Wei.Huang2@amd.com]
Sent: Thursday, October 07, 2010 9:57 AM
To: Ian Jackson
Cc: Xen-devel; Kay, Allen M
Subject: [RFC][QEMU] ATI graphics VBIOS passthru support

Hi Ian,

There have been a lot of interest on gfx passthru recently. This patch enables ATI VBIOS in passthru mode. The guest VM system BIOS (including Windows boot logo) can now show in passthru screen. We have tested with various Windows and Linux guest VMs. Please help review it. We are also looking forward to comments and suggestions from Xen community users.

Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Wei Wang <wei.wang2@amd.com>



[-- Attachment #1.2: Type: text/html, Size: 8097 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply

* Re: [Xenomai-help] kernel oopses when killing realtime task
From: Gilles Chanteperdrix @ 2010-10-08  7:20 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Jan Kiszka, xenomai
In-Reply-To: <20101008070148.GB2255@domain.hid>

Pavel Machek wrote:
> Hi!
> 
>>> I have... quite an interesting setup here.
>>>
>>> SMP machine, with special PCI card; that card has GPIOs and serial
>>> ports. Unfortunately, there's only one interrupt, shared between
>>> serials and GPIO pins, and serials are way too complex to be handled
>>> by realtime layer.
>>>
>>> So I ended up with
>>>
>>>         // we also have an interrupt handler:                                                                                                                 
>>>         ret = rtdm_irq_request(&my_context->irq_handle,
>>>         gpio_rt_config.irq, demo_interrupt,
>>>                                RTDM_IRQTYPE_SHARED,
>>>         context->device->proc_name, my_context);
>>>
>>> and 
>>>
>>> static int demo_interrupt(rtdm_irq_t *irq_context)
>>> {
>>>         struct demodrv_context *ctx;
>>>         int           dev_id;
>>>         int           ret = RTDM_IRQ_HANDLED; // usual return value                                                                                           
>>>         unsigned pending, output;
>>>
>>>         ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
>>>         dev_id    = ctx->dev_id;
>>>
>>>         if (!ctx->ready) {
>>>                 printk(KERN_CRIT "Unexpected interrupt\n");
>>>                 return XN_ISR_PROPAGATE;
>> Who sets ready and when? Looks racy.
> 
> Debugging aid; yes, this one is racy.
> 
>>>         rtdm_lock_put(&ctx->lock);
>>>  
>>>         /* We need to propagate the interrupt, so that PMC-6L serials                                                                                         
>>>            work. Result is that interrupt latencies can't be                                                                                                  
>>>            guaranteed when serials are in use.  */
>>>
>>>          return RTDM_IRQ_HANDLED;
>>> }
>>>
>>> Unregistration is:
>>>         my_context->ready = 0;
>>>         rtdm_irq_disable(&my_context->irq_handle);
>> Where is rtdm_irq_free? Again, this ready flag looks racy.
> 
> Aha, sorry, I quoted wrong snippet. rtdm_irq_free() follows
> immediately, like this:
> 
> int demo_close_rt(struct rtdm_dev_context   *context,
>                   rtdm_user_info_t          *user_info)
> {
>         struct demodrv_context  *my_context;
>         rtdm_lockctx_t          lock_ctx;
>         // get the context                                                                                                                                    
>         my_context = (struct demodrv_context *)context->dev_private;
> 
>         // if we need to do some stuff with preemption disabled:                                                                                              
>         rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
> 
>         my_context->ready = 0;
>         rtdm_irq_disable(&my_context->irq_handle);
> 
> 
>         // free irq in RTDM                                                                                                                                   
>         rtdm_irq_free(&my_context->irq_handle);
> 
>         // destroy our interrupt signal/event                                                                                                                 
>         rtdm_event_destroy(&my_context->irq_event);
> 
>         // other stuff here                                                                                                                                   
>         rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
> 
>         return 0;
> }
> 
> Now... I'm aware that lock_get/put around irq_free should be
> unneccessary, as should be irq_disable and my ->ready flag. Those were
> my attempts to work around the problem. I'll attach the full source at
> the end.
> 
>>> Unfortunately, when the userspace app is ran and killed repeatedly (so
>>> that interrupt is registered/unregistered all the time), I get
>>> oopses in __ipipe_dispatch_wired() -- it seems to call into the NULL
>>> pointer.
>>>
>>> I decided that "wired" interrupt when the source is shared between
>>> Linux and Xenomai, is wrong thing, so I disable "wired" interrupts
>>> altogether, but that only moved oops to __virq_end. 
>> This is wrong. The only way to get a determistically shared IRQs across
>> domains is via the wired path, either using the pattern Gilles cited or,
>> in a slight variation, signaling down via a separate rtdm_nrtsig.
> 
> For now, I'm trying to get it not to oops; deterministic latencies are
> the next topic :-(.

Another remark, Xenomai releases of a given branch are ABI and API
compatible, so, upgrade to the latest version of the 2.4 branch, which
is 2.4.9.1 will not hurt. In the same vein, I-pipe patches are backward
compatibles, so, upgrade to
http://download.gna.org/adeos/patches/v2.6/x86/older/adeos-ipipe-2.6.27-x86-2.2-03.patch

is recommended if it is not the I-pipe you are using.

It would be nice if you could at least test these versions, if they
work, we would know whether the issue you have has been solved since the
release of these versions.

-- 
                                                                Gilles.


^ permalink raw reply

* Re: H55 chipset and KMS with HDMI/VGA
From: milk @ 2010-10-08  7:19 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <89k77n$p5gqkk@fmsmga001.fm.intel.com>

On Thu, Oct 7, 2010 at 1:09 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> To fix the first:
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi
> and we hope to have a complete patch shortly. (Zhenyu did you get a chance
> to update the patches?)

Cool. I'll rebuild the kernel tomorrow night and see if this works.

>
> For the second issue with the wavering VGA, could you please attach your
> Xorg.log and an intel_reg_dumper output to
> https://bugs.freedesktop.org/show_bug.cgi?id=28306 (and obviously look
> carefully at that bug to see if the video of the symptoms are indeed the
> same.) An alternative explanation might be that is a self-refresh issue
> instead.

Yup, thats the same symptoms. I've posted to the bug.

-milki

-- 
Hope is a dimension of the spirit. It is not outside us, but within
us. When you lose it, you must seek it again within yourself and in
people around you -- not in objects or even events.    -
-Vaclav Havel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [tip:core/memblock] memblock/arm: Fix memblock_region_is_memory() typo
From: tip-bot for Yinghai Lu @ 2010-10-08  7:18 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, hpa, mingo, yinghai, balbi, khilman, tomi.valkeinen,
	notasas, benh, tglx, mingo
In-Reply-To: <4CABFADA.9020305@kernel.org>

Commit-ID:  5fd03ddab7fdbc44bfb2d183a4531c26a8dbca5a
Gitweb:     http://git.kernel.org/tip/5fd03ddab7fdbc44bfb2d183a4531c26a8dbca5a
Author:     Yinghai Lu <yinghai@kernel.org>
AuthorDate: Tue, 5 Oct 2010 21:28:10 -0700
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 8 Oct 2010 09:14:36 +0200

memblock/arm: Fix memblock_region_is_memory() typo

Fix typo in commit dbe3039 ("memblock/arm: Use memblock_region_is_memory()
for omap fb") - it should be memblock_is_region_memory().

Reported-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: ext Grazvydas Ignotas <notasas@gmail.com>
LKML-Reference: <4CABFADA.9020305@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/arm/plat-omap/fb.c    |    2 +-
 drivers/video/omap2/vram.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 441af2b..7193481 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -173,7 +173,7 @@ static int check_fbmem_region(int region_idx, struct omapfb_mem_region *rg,
 
 static int valid_sdram(unsigned long addr, unsigned long size)
 {
-	return memblock_region_is_memory(addr, size);
+	return memblock_is_region_memory(addr, size);
 }
 
 static int reserve_sdram(unsigned long addr, unsigned long size)
diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 34514a8..fed2a72 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -555,7 +555,7 @@ void __init omap_vram_reserve_sdram_memblock(void)
 
 	if (paddr) {
 		if ((paddr & ~PAGE_MASK) ||
-		    !memblock_region_is_memory(paddr, size)) {
+		    !memblock_is_region_memory(paddr, size)) {
 			pr_err("Illegal SDRAM region for VRAM\n");
 			return;
 		}

^ permalink raw reply related

* [Buildroot] buildroot not support c++ compliing
From: Thomas Petazzoni @ 2010-10-08  7:18 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1286511827.3703.11.camel@olyvine-desktop.logiways-sz.cn>

Hello,

On Fri, 08 Oct 2010 12:23:47 +0800
"olyvine.chen at logiways.com.cn" <olyvine.chen@logiways.com.cn> wrote:

>   I now try to add package libmusicbrainz to buildroot, but many
> errors happen, such as the following:
> 
> *************************************************************************
> 
> buildroot/output/build/libmusicbrainz-3.0.2/src/artist.cpp:23:18:
> error: string: No such file or directory
> 
> *************************************************************************
>   it seems indicate that no c++ library available, then how to enable
> c ++ compiling for buildroot? 
>         
>   I enabled glibc via:
>   Toolchain => Toolchain type (External toolchain) => External
> toolchain C library (glibc)

Which external toolchain are you using ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [PATCH 1/1] Added the ability to patch ltmain.sh based on version
From: Martin Banky @ 2010-10-08  7:18 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <[PATCH 2/7] Added the ability to patch ltmain.sh based on version>

There are two versions of ltmain.sh in use in the buildroot system, 1.5.x and
2.2.x. buildroot-libtool.patch would only patch 1.5.x, which meant that for
2.2.x, a separate patch for the affected package had to be maintained. Modified
Makefile.autotools.in to check the version of ltmain.sh and apply the correct
patch.

Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
---
 package/Makefile.autotools.in        |   23 ++++++++---
 package/buildroot-libtool-v1.5.patch |   69 ++++++++++++++++++++++++++++++++++
 package/buildroot-libtool-v2.2.patch |   64 +++++++++++++++++++++++++++++++
 package/buildroot-libtool.patch      |   69 ----------------------------------
 4 files changed, 150 insertions(+), 75 deletions(-)
 create mode 100644 package/buildroot-libtool-v1.5.patch
 create mode 100644 package/buildroot-libtool-v2.2.patch
 delete mode 100644 package/buildroot-libtool.patch

diff --git a/package/Makefile.autotools.in b/package/Makefile.autotools.in
index 589079b..87c3092 100644
--- a/package/Makefile.autotools.in
+++ b/package/Makefile.autotools.in
@@ -139,10 +139,16 @@ $(2)_POST_PATCH_HOOKS += UPDATE_CONFIG_HOOK
 #
 define LIBTOOL_PATCH_HOOK
 	@$(call MESSAGE,"Patching libtool")
-	$(Q)if test "$$($$(PKG)_LIBTOOL_PATCH)" = "YES" -a \
-	"$$($$(PKG)_AUTORECONF)" != "YES"; then \
-	for i in `find $$($$(PKG)_SRCDIR) -name ltmain.sh`; do \
-		toolchain/patch-kernel.sh $$$${i%/*} package buildroot-libtool.patch; \
+	$(Q)if test "$$($$(PKG)_LIBTOOL_PATCH)" = "YES" \
+		-a "$$($$(PKG)_AUTORECONF)" != "YES"; then \
+		for i in `find $$($$(PKG)_SRCDIR) -name ltmain.sh`; do \
+			ltmain_version=`sed -n '/^[ 	]*VERSION=/{s/^[ 	]*VERSION=//;p;q;}' $$$$i | \
+			sed -e 's/\([0-9].[0-9]*\).*/\1/' -e 's/\"//'`; \
+			if test $$$${ltmain_version} = '1.5'; then \
+				toolchain/patch-kernel.sh $$$${i%/*} package buildroot-libtool-v1.5.patch; \
+			elif test $$$${ltmain_version} = "2.2"; then\
+				toolchain/patch-kernel.sh $$$${i%/*} package buildroot-libtool-v2.2.patch; \
+			fi \
 		done \
 	fi
 endef
@@ -158,9 +164,14 @@ endif
 define AUTORECONF_HOOK
 	@$(call MESSAGE,"Autoreconfiguring")
 	$(Q)cd $$($$(PKG)_SRCDIR) && $(AUTORECONF) $$($$(PKG)_AUTORECONF_OPT)
-	$(Q)if test "$($$(PKG)_LIBTOOL_PATCH)" = "YES"; then \
+	$(Q)if test "$$($$(PKG)_LIBTOOL_PATCH)" = "YES"; then \
 		for i in `find $$($$(PKG)_SRCDIR) -name ltmain.sh`; do \
-		toolchain/patch-kernel.sh $${i%/*} package buildroot-libtool.patch; \
+			ltmain_version=`sed -n '/^[ 	]*VERSION=/{s/^[ 	]*VERSION=//;p;q;}' $$$$i | sed 's/\([0-9].[0-9]*\).*/\1/'`; \
+			if test $$$${ltmain_version} = "1.5"; then \
+				toolchain/patch-kernel.sh $$$${i%/*} package buildroot-libtool-v1.5.patch; \
+			elif test $$$${ltmain_version} = "2.2"; then\
+				toolchain/patch-kernel.sh $$$${i%/*} package buildroot-libtool-v2.2.patch; \
+			fi \
 		done \
 	fi
 endef
diff --git a/package/buildroot-libtool-v1.5.patch b/package/buildroot-libtool-v1.5.patch
new file mode 100644
index 0000000..57a7c58
--- /dev/null
+++ b/package/buildroot-libtool-v1.5.patch
@@ -0,0 +1,69 @@
+--- a/ltmain.sh	2006-03-11 13:49:04.000000000 -0500
++++ b/ltmain.sh	2008-04-30 09:55:28.000000000 -0400
+@@ -273,8 +273,9 @@ func_infer_tag ()
+ 	# line option must be used.
+ 	if test -z "$tagname"; then
+ 	  $echo "$modename: unable to infer tagged configuration"
+-	  $echo "$modename: specify a tag with \`--tag'" 1>&2
+-	  exit $EXIT_FAILURE
++	  $echo "$modename: defaulting to \`CC'"
++	  $echo "$modename: if this is not correct, specify a tag with \`--tag'"
++#	  exit $EXIT_FAILURE
+ #        else
+ #          $echo "$modename: using $tagname tagged configuration"
+ 	fi
+@@ -2407,8 +2408,14 @@ EOF
+ 	    absdir="$abs_ladir"
+ 	    libdir="$abs_ladir"
+ 	  else
+-	    dir="$libdir"
+-	    absdir="$libdir"
++            # Adding 'libdir' from the .la file to our library search paths
++            # breaks crosscompilation horribly.  We cheat here and don't add
++            # it, instead adding the path where we found the .la.  -CL
++	    dir="$abs_ladir"
++	    absdir="$abs_ladir"
++	    libdir="$abs_ladir"
++	    #dir="$libdir"
++	    #absdir="$libdir"
+ 	  fi
+ 	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
+ 	else
+@@ -2545,7 +2552,7 @@ EOF
+ 	   { test "$use_static_libs" = no || test -z "$old_library"; }; then
+ 	  if test "$installed" = no; then
+ 	    notinst_deplibs="$notinst_deplibs $lib"
+-	    need_relink=yes
++	    need_relink=no
+ 	  fi
+ 	  # This is a shared library
+ 
+@@ -5606,6 +5623,10 @@ fi\
+ 	    # Replace all uninstalled libtool libraries with the installed ones
+ 	    newdependency_libs=
+ 	    for deplib in $dependency_libs; do
++              # Replacing uninstalled with installed can easily break crosscompilation,
++              # since the installed path is generally the wrong architecture.  -CL
++              newdependency_libs="$newdependency_libs $deplib"
++              continue
+ 	      case $deplib in
+ 	      *.la)
+ 		name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'`
+@@ -5927,10 +5948,13 @@ relink_command=\"$relink_command\""
+ 	  # At present, this check doesn't affect windows .dll's that
+ 	  # are installed into $libdir/../bin (currently, that works fine)
+ 	  # but it's something to keep an eye on.
+-	  if test "$inst_prefix_dir" = "$destdir"; then
+-	    $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2
+-	    exit $EXIT_FAILURE
+-	  fi
++	  #
++	  # This breaks install into our staging area.  -PB
++	  # 
++	  # if test "$inst_prefix_dir" = "$destdir"; then
++	  #   $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2
++	  #   exit $EXIT_FAILURE
++	  # fi
+ 
+ 	  if test -n "$inst_prefix_dir"; then
+ 	    # Stick the inst_prefix_dir data into the link command.
diff --git a/package/buildroot-libtool-v2.2.patch b/package/buildroot-libtool-v2.2.patch
new file mode 100644
index 0000000..0df00ae
--- /dev/null
+++ b/package/buildroot-libtool-v2.2.patch
@@ -0,0 +1,64 @@
+--- a/ltmain.sh	2009-11-16 06:23:18.000000000 -0700
++++ b/ltmain.sh	2010-09-18 20:25:06.000000000 -0700
+@@ -1048,8 +1048,8 @@ func_infer_tag ()
+ 	# was found and let the user know that the "--tag" command
+ 	# line option must be used.
+ 	if test -z "$tagname"; then
+-	  func_echo "unable to infer tagged configuration"
+-	  func_fatal_error "specify a tag with \`--tag'"
++	  func_echo "defaulting to \`CC'"
++	  func_echo "if this is not correct, specify a tag with \`--tag'"
+ #	else
+ #	  func_verbose "using $tagname tagged configuration"
+ 	fi
+@@ -2018,8 +2018,11 @@ func_mode_install ()
+ 	  # At present, this check doesn't affect windows .dll's that
+ 	  # are installed into $libdir/../bin (currently, that works fine)
+ 	  # but it's something to keep an eye on.
+-	  test "$inst_prefix_dir" = "$destdir" && \
+-	    func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir"
++	  #
++	  # This breaks install into our staging area.  -PB
++	  #
++	  # test "$inst_prefix_dir" = "$destdir" && \
++	  #   func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir"
+ 
+ 	  if test -n "$inst_prefix_dir"; then
+ 	    # Stick the inst_prefix_dir data into the link command.
+@@ -5412,8 +5415,14 @@ func_mode_link ()
+ 	    absdir="$abs_ladir"
+ 	    libdir="$abs_ladir"
+ 	  else
+-	    dir="$libdir"
+-	    absdir="$libdir"
++            # Adding 'libdir' from the .la file to our library search paths
++            # breaks crosscompilation horribly.  We cheat here and don't add
++            # it, instead adding the path where we found the .la.  -CL
++	    dir="$abs_ladir"
++	    absdir="$abs_ladir"
++	    libdir="$abs_ladir"
++	    #dir="$libdir"
++	    #absdir="$libdir"
+ 	  fi
+ 	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
+ 	else
+@@ -5564,7 +5573,7 @@ func_mode_link ()
+ 	  *)
+ 	    if test "$installed" = no; then
+ 	      notinst_deplibs="$notinst_deplibs $lib"
+-	      need_relink=yes
++	      need_relink=no
+ 	    fi
+ 	    ;;
+ 	  esac
+@@ -8052,6 +8061,10 @@ EOF
+ 	    # Replace all uninstalled libtool libraries with the installed ones
+ 	    newdependency_libs=
+ 	    for deplib in $dependency_libs; do
++              # Replacing uninstalled with installed can easily break crosscompilation,
++              # since the installed path is generally the wrong architecture.  -CL
++              newdependency_libs="$newdependency_libs $deplib"
++              continue
+ 	      case $deplib in
+ 	      *.la)
+ 		func_basename "$deplib"
diff --git a/package/buildroot-libtool.patch b/package/buildroot-libtool.patch
deleted file mode 100644
index 57a7c58..0000000
--- a/package/buildroot-libtool.patch
+++ /dev/null
@@ -1,69 +0,0 @@
---- a/ltmain.sh	2006-03-11 13:49:04.000000000 -0500
-+++ b/ltmain.sh	2008-04-30 09:55:28.000000000 -0400
-@@ -273,8 +273,9 @@ func_infer_tag ()
- 	# line option must be used.
- 	if test -z "$tagname"; then
- 	  $echo "$modename: unable to infer tagged configuration"
--	  $echo "$modename: specify a tag with \`--tag'" 1>&2
--	  exit $EXIT_FAILURE
-+	  $echo "$modename: defaulting to \`CC'"
-+	  $echo "$modename: if this is not correct, specify a tag with \`--tag'"
-+#	  exit $EXIT_FAILURE
- #        else
- #          $echo "$modename: using $tagname tagged configuration"
- 	fi
-@@ -2407,8 +2408,14 @@ EOF
- 	    absdir="$abs_ladir"
- 	    libdir="$abs_ladir"
- 	  else
--	    dir="$libdir"
--	    absdir="$libdir"
-+            # Adding 'libdir' from the .la file to our library search paths
-+            # breaks crosscompilation horribly.  We cheat here and don't add
-+            # it, instead adding the path where we found the .la.  -CL
-+	    dir="$abs_ladir"
-+	    absdir="$abs_ladir"
-+	    libdir="$abs_ladir"
-+	    #dir="$libdir"
-+	    #absdir="$libdir"
- 	  fi
- 	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
- 	else
-@@ -2545,7 +2552,7 @@ EOF
- 	   { test "$use_static_libs" = no || test -z "$old_library"; }; then
- 	  if test "$installed" = no; then
- 	    notinst_deplibs="$notinst_deplibs $lib"
--	    need_relink=yes
-+	    need_relink=no
- 	  fi
- 	  # This is a shared library
- 
-@@ -5606,6 +5623,10 @@ fi\
- 	    # Replace all uninstalled libtool libraries with the installed ones
- 	    newdependency_libs=
- 	    for deplib in $dependency_libs; do
-+              # Replacing uninstalled with installed can easily break crosscompilation,
-+              # since the installed path is generally the wrong architecture.  -CL
-+              newdependency_libs="$newdependency_libs $deplib"
-+              continue
- 	      case $deplib in
- 	      *.la)
- 		name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'`
-@@ -5927,10 +5948,13 @@ relink_command=\"$relink_command\""
- 	  # At present, this check doesn't affect windows .dll's that
- 	  # are installed into $libdir/../bin (currently, that works fine)
- 	  # but it's something to keep an eye on.
--	  if test "$inst_prefix_dir" = "$destdir"; then
--	    $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2
--	    exit $EXIT_FAILURE
--	  fi
-+	  #
-+	  # This breaks install into our staging area.  -PB
-+	  # 
-+	  # if test "$inst_prefix_dir" = "$destdir"; then
-+	  #   $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2
-+	  #   exit $EXIT_FAILURE
-+	  # fi
- 
- 	  if test -n "$inst_prefix_dir"; then
- 	    # Stick the inst_prefix_dir data into the link command.
-- 
1.7.3.1

^ permalink raw reply related

* [Buildroot] [PATCH 0/1] Updated and cleaned up patch
From: Martin Banky @ 2010-10-08  7:18 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <[PATCH 2/7] Added the ability to patch ltmain.sh based on version>

Sorry to do this, but here is a cleaned-up and updated patch for this.

Martin

[PATCH 1/1] Added the ability to patch ltmain.sh based on version

^ permalink raw reply

* Re: [PATCH 00/33] Staging: Fixed <module-objs> to <module>-y
From: matt mooney @ 2010-10-08  7:16 UTC (permalink / raw)
  To: T Dent; +Cc: greg, linux-kernel, kernel-janitors, sam, linux-kbuild
In-Reply-To: <AANLkTi=Hc2eWzOQ_xKBYsqfwkkiKGU0v42jUhLQ8K7dU@mail.gmail.com>

On Thu, Oct 7, 2010 at 6:35 PM, T Dent <tdent48227@gmail.com> wrote:
> I patch against the next-20101006 tree.
>
> The patch series replace use of <module>-objs with <module>-y in the
> staging directory.

Commit messages are written in the present tense. You happen to be
using two different tenses within the commit message, which is truly
odd.  And why did you not split apart those atrocious statements with
the infinite column width?

This patch series adds little benefit.  As Sam has suggested, a more
general cleanup would be a better goal, and staging is an area that
needs extra attention some of which has already been pointed out in
other emails.

-mfm

-- 
GPG-Key: 9AFE00EA

^ permalink raw reply

* Re: [PATCH 00/33] Staging: Fixed <module-objs> to <module>-y
From: matt mooney @ 2010-10-08  7:16 UTC (permalink / raw)
  To: T Dent; +Cc: greg, linux-kernel, kernel-janitors, sam, linux-kbuild
In-Reply-To: <AANLkTi=Hc2eWzOQ_xKBYsqfwkkiKGU0v42jUhLQ8K7dU@mail.gmail.com>

On Thu, Oct 7, 2010 at 6:35 PM, T Dent <tdent48227@gmail.com> wrote:
> I patch against the next-20101006 tree.
>
> The patch series replace use of <module>-objs with <module>-y in the
> staging directory.

Commit messages are written in the present tense. You happen to be
using two different tenses within the commit message, which is truly
odd.  And why did you not split apart those atrocious statements with
the infinite column width?

This patch series adds little benefit.  As Sam has suggested, a more
general cleanup would be a better goal, and staging is an area that
needs extra attention some of which has already been pointed out in
other emails.

-mfm

-- 
GPG-Key: 9AFE00EA

^ permalink raw reply

* Re: XenVGAPassthroughTestedAdapters up to date?
From: hurenkam @ 2010-10-08  7:15 UTC (permalink / raw)
  To: Jean Guyader; +Cc: Eric Stein, xen-devel
In-Reply-To: <AANLkTinTzJgh0VDgXWHLni+YpcGZu9ycs_9HOBJJrxFp@mail.gmail.com>

>> What patches did you apply? VGA passthru was first introduced in Xen 4.0,
>> it wasn't in Xen 3.4. Or has it been added recently?
>>
>> Also, what dom0 kernel did you use?
>> What grub settings (for device hiding etc)?
>>
> 
> I use normal device pass throught, I forgot to mentioned that was
> passing it through as a secondary display adapter so no need to do any
> fancy VGA tweak for that.
> 
> I used SLE 2.6.32 xen as dom0 + XCI patch queue.
> I used pci back directly to hide the device from dom0 after boot (echo
> the gpu BDF into sysfs).
> 
> Jean

I have a similar experience using Xen 4.0.1, with linux pvops kernel
(2.6.32).

Somehow, i never seemed to get the 'Bios boot' to work, however, when
passing these cards through to the DomU, then the following
combinations
seem to work fine once started:
- Ubuntu Lucid (64bit) + Catalyst (10.7 or 10.8)   (primary or
secondary)
- Windows XP (32bit) + Catalyst (10.7 or 10.8)     (primary, have not
tried as secondary)
- Windows 7 (64bit) + Catalyst 10.9                (primary, have not
tried as secondary)
Note that when trying the opensource driver on ubuntu, it exits with
errors, which seem
to indicate it can't find the Bios.

I have a Asus P7P55D-Evo mainboard, with two Asus EAH4350 graphic
cards, 
both cards are passed through to a domU, both don't show bios messages
on
boot (even when i use graphics passthru setting), but they work fine
with the installed drivers after the domains have booted.
For me, that's good enough ;-)


Regards,
Mark.

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.