At Mon, 23 Oct 2006 13:12:21 +0200, I wrote: > > 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. Possibly you're using snd_compat_vsnprintf() fuction and this looks broken for over-4k strings. But, this wrapper is necessary only for pretty old kernels. All 2.6 kernels should have a native vsnprintf(). Check whether alsa-driver/include/config.h whether you have CONFIG_HAVE_VSNPRINTF there. If not, check config.log for details. Takashi ------------------------------------------------------------------------- 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
