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@xxxxxxxxxxxxx> wrote:
> >
> > On Fri, 20 Oct 2006 18:48:13 +0200, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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@xxxxxxx>
> >> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
