Re: (Was Re: [Alsa-user] Poorly supported HDA intel)

[Takashi Iwai <tiwai@suse.de>]

At Fri, 20 Oct 2006 19:16:19 +0200,
Ricardo Cerqueira wrote:
> 
> On Fri, 20 Oct 2006 18:55:56 +0200, Ricardo Cerqueira <alsa-users@cerqueira.org> wrote:
> > 
> > On Fri, 20 Oct 2006 18:48:13 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> >> At Fri, 20 Oct 2006 18:35:43 +0200,
> >> Ricardo Cerqueira wrote:
> >>>
> >>>
> >>>
> >>> On Fri, 20 Oct 2006 18:18:09 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> >>> > At Fri, 20 Oct 2006 17:55:23 +0200,
> >>> > Ricardo Cerqueira wrote:
> >>> >>
> >>> >> On Fri, 20 Oct 2006 17:52:56 +0200, Takashi Iwai <tiwai@suse.de>
> >> wrote:
> >>> >> > At Fri, 20 Oct 2006 17:48:00 +0200,
> >>> >>
> >>> >> >>
> >>> >> >> Hmmm. I was trying to look into codec#0 to check the pin
> >> assignments,
> >>> >> > and I
> >>> >> >> realized it's being cut off at byte 4096, and I'm missing
> >>> > information.
> >>> >> > Looks
> >>> >> >> like something is limiting that proc entry's size to 4k, do you
> >> have
> >>> > any
> >>> >> > idea
> >>> >> >> where?
> >>> >> >
> >>> >> > Are your using HG version of driver?
> >>> >> > This bug should have been fixed recently.
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> Yes, pulled about 14 hours ago...
> >>> >
> >>> > Strange, it works for me.  I tested to print extra data up to 32k
> >>> > bytes on my i386 machine, and it looks OK.
> >>> >
> >>> > Check alsa-kernel hg tree whether you have a changeset 4658
> >>> > "Fix re-use of va_list" (although it should work even without this
> >>> > patch on i386).
> >>>
> >>> Yes, I'm at changeset 4662... I checked core/info.c by hand, and the
> >> va_list
> >>> change is there... I just tried cloning fresh copies of alsa-kernel and
> >>> alsa-driver, and the result is the same.
> >>
> >> Weird.  Could you check whether really it's 4k boundary problem?
> > 
> > Looks like it is:
> 
> OK... The resize call is never reached (the break clause is always true).
> I added a small printk before the size test, and got:
> 
> DEBUG - res=48 and len=74
> DEBUG - res=25 and len=26
> DEBUG - res=0 and len=1
> DEBUG - res=0 and len=1
> DEBUG - res=0 and len=1
> 
> And from here on, vsnprintf always returns 0.

> From my understanding of
> the documentation, it shouldn't happen, but... (maybe a glibc bug?)

Unless you call like vsnprintf(buf, len, "").  But I don't think it's
this case.

The kernel code uses its own implementation of vsnprintf(), so it
should be a bug of kernel.

Which version of kernel and gcc are you using?  It has worked fine
with my machines, 2.6.18, 19-git and gcc 4.1.

> Changing the "if (res < len)" to "if (res && res < len)" solves it, but I
> don't know if there'll be other side effects.

We should check whether fmt is an empty string.  Otherwise
res must return a positive value, so it should be OK.
The patch is below.


Takashi

diff -r d7fe584f7395 core/info.c
--- a/core/info.c	Thu Oct 19 20:35:56 2006 +0200
+++ b/core/info.c	Mon Oct 23 13:06:05 2006 +0200
@@ -117,6 +117,8 @@ int snd_iprintf(struct snd_info_buffer *
 	might_sleep();
 	if (buffer->stop || buffer->error)
 		return 0;
+	if (!*fmt)
+		return 0;
 	len = buffer->len - buffer->size;
 	va_start(args, fmt);
 	for (;;) {
@@ -124,7 +126,7 @@ int snd_iprintf(struct snd_info_buffer *
 		va_copy(ap, args);
 		res = vsnprintf(buffer->buffer + buffer->curr, len, fmt, ap);
 		va_end(ap);
-		if (res < len)
+		if (res && res < len)
 			break;
 		err = resize_info_buffer(buffer, buffer->len + PAGE_SIZE);
 		if (err < 0)

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642