Re: [Alsa-user] Poorly supported HDA intel

Re: [Alsa-user] Poorly supported HDA intel

[Takashi Iwai]

At Fri, 20 Oct 2006 17:03:40 +0200,
Ricardo Cerqueira wrote:
> 
> 
> 
> On Fri, 20 Oct 2006 16:37:56 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> > At Fri, 20 Oct 2006 16:31:44 +0200,
> > Ricardo Cerqueira wrote:
> >>
> >> On Fri, 20 Oct 2006 16:16:45 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> >> >
> >> > I don't think there is any matching model for your device, so far.
> >> >
> >> > There is a patch floating around alsa-devel ML for the addition of
> >> > "asus" model right now.  This might suit with your device.
> >>
> >> You mean this thread?
> >>
> >> http://thread.gmane.org/gmane.linux.alsa.devel/40507/focus=40553
> > 
> > Check Tobin's post in today including a newer patch for ALSA HG tree.
> > 
> > http://thread.gmane.org/gmane.linux.alsa.devel/40974/focus=41309
> 
> OK, Tobin's patch works. There are are a couple of bugs I can see right
> away:
> 
> 1 - The Headphones mute control doesn't do anything (the Front control
> mutes the speakers and the headphones)
> 2 - The Front Mic mute doesn't do anything, either. Both the built-in
> mic and an external Mic are controlled by the "Mic" control.
> 
> Other than that, things seem to be working.

Let's move on alsa-devel.
[It's ASUS W5F laptop, in case someone didn't follow the thread on
 alsa-users]

Ricardo, what PCI SSID does it have?  Check lspci -nvv output.


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

Re: [Alsa-user] Poorly supported HDA intel

[Ricardo Cerqueira]

On Fri, 20 Oct 2006 17:14:42 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> 
> Let's move on alsa-devel.
> [It's ASUS W5F laptop, in case someone didn't follow the thread on
>  alsa-users]
> 
> Ricardo, what PCI SSID does it have?  Check lspci -nvv output.
> 

Ooops, got lost in the earlier messages... It's 1043:1263

--
RC


-------------------------------------------------------------------------
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

Re: [Alsa-user] Poorly supported HDA intel

[Ricardo Cerqueira]

On Fri, 20 Oct 2006 17:14:42 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 20 Oct 2006 17:03:40 +0200,
> Ricardo Cerqueira wrote:
>>
>>
>>
>> On Fri, 20 Oct 2006 16:37:56 +0200, Takashi Iwai <tiwai@suse.de> wrote:
>> > At Fri, 20 Oct 2006 16:31:44 +0200,
>> > Ricardo Cerqueira wrote:
>> >>
>> >> On Fri, 20 Oct 2006 16:16:45 +0200, Takashi Iwai <tiwai@suse.de>
> wrote:
>> >> >
>> >> > I don't think there is any matching model for your device, so far.
>> >> >
>> >> > There is a patch floating around alsa-devel ML for the addition of
>> >> > "asus" model right now.  This might suit with your device.
>> >>
>> >> You mean this thread?
>> >>
>> >> http://thread.gmane.org/gmane.linux.alsa.devel/40507/focus=40553
>> >
>> > Check Tobin's post in today including a newer patch for ALSA HG tree.
>> >
>> > http://thread.gmane.org/gmane.linux.alsa.devel/40974/focus=41309
>>
>> OK, Tobin's patch works. There are are a couple of bugs I can see right
>> away:
>>
>> 1 - The Headphones mute control doesn't do anything (the Front control
>> mutes the speakers and the headphones)
>> 2 - The Front Mic mute doesn't do anything, either. Both the built-in
>> mic and an external Mic are controlled by the "Mic" control.

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?


--
RC


-------------------------------------------------------------------------
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

Re: [Alsa-user] Poorly supported HDA intel

[Takashi Iwai]

At Fri, 20 Oct 2006 17:48:00 +0200,
Ricardo Cerqueira wrote:
> 
> On Fri, 20 Oct 2006 17:14:42 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> > At Fri, 20 Oct 2006 17:03:40 +0200,
> > Ricardo Cerqueira wrote:
> >>
> >>
> >>
> >> On Fri, 20 Oct 2006 16:37:56 +0200, Takashi Iwai <tiwai@suse.de> wrote:
> >> > At Fri, 20 Oct 2006 16:31:44 +0200,
> >> > Ricardo Cerqueira wrote:
> >> >>
> >> >> On Fri, 20 Oct 2006 16:16:45 +0200, Takashi Iwai <tiwai@suse.de>
> > wrote:
> >> >> >
> >> >> > I don't think there is any matching model for your device, so far.
> >> >> >
> >> >> > There is a patch floating around alsa-devel ML for the addition of
> >> >> > "asus" model right now.  This might suit with your device.
> >> >>
> >> >> You mean this thread?
> >> >>
> >> >> http://thread.gmane.org/gmane.linux.alsa.devel/40507/focus=40553
> >> >
> >> > Check Tobin's post in today including a newer patch for ALSA HG tree.
> >> >
> >> > http://thread.gmane.org/gmane.linux.alsa.devel/40974/focus=41309
> >>
> >> OK, Tobin's patch works. There are are a couple of bugs I can see right
> >> away:
> >>
> >> 1 - The Headphones mute control doesn't do anything (the Front control
> >> mutes the speakers and the headphones)
> >> 2 - The Front Mic mute doesn't do anything, either. Both the built-in
> >> mic and an external Mic are controlled by the "Mic" control.
> 
> 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.


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

Re: [Alsa-user] Poorly supported HDA intel

[Ricardo Cerqueira]

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...

--
RC


-------------------------------------------------------------------------
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

Re: [Alsa-user] Poorly supported HDA intel

[Takashi Iwai]

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).


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

Re: [Alsa-user] Poorly supported HDA intel

[Ricardo Cerqueira]

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.

--
RC


-------------------------------------------------------------------------
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

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

[Takashi Iwai]

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?
For example, try the patch below to see whether you get 500 dummy
lines in codec#0 proc file.


Takashi

diff -r d7fe584f7395 pci/hda/hda_proc.c
--- a/pci/hda/hda_proc.c	Thu Oct 19 20:35:56 2006 +0200
+++ b/pci/hda/hda_proc.c	Fri Oct 20 18:42:07 2006 +0200
@@ -202,6 +202,9 @@ static void print_codec_info(struct snd_
 	hda_nid_t nid;
 	int i, nodes;
 
+	for (i = 0; i < 500; i++)
+		snd_iprintf(buffer, "[%d] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX\n", i);
+
 	snd_hda_get_codec_name(codec, buf, sizeof(buf));
 	snd_iprintf(buffer, "Codec: %s\n", buf);
 	snd_iprintf(buffer, "Address: %d\n", codec->addr);

-------------------------------------------------------------------------
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

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

[Ricardo Cerqueira]

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:

> For example, try the patch below to see whether you get 500 dummy
> lines in codec#0 proc file.
> 

[root@frolic ~]# cat /proc/asound/card0/codec#0 | tail
[76] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[77] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[78] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[79] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[80] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[81] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[82] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[83] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[84] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
[85] XXXXX DUMMY LINE XXX[root@frolic ~]#
[root@frolic ~]#
[root@frolic ~]# wc  /proc/asound/card0/codec#0
85 770 4095 /proc/asound/card0/codec#0

--
RC


-------------------------------------------------------------------------
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

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

[Ricardo Cerqueira]

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?)

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




> 
>> For example, try the patch below to see whether you get 500 dummy
>> lines in codec#0 proc file.
>>
> 
> [root@frolic ~]# cat /proc/asound/card0/codec#0 | tail
> [76] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [77] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [78] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [79] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [80] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [81] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [82] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [83] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [84] XXXXX DUMMY LINE XXXX XXXX DUMMY LINE XXXX
> [85] XXXXX DUMMY LINE XXX[root@frolic ~]#
> [root@frolic ~]#
> [root@frolic ~]# wc  /proc/asound/card0/codec#0
> 85 770 4095 /proc/asound/card0/codec#0
> 
> --
> RC
> 
> 
> -------------------------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------------------------
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

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

[Takashi Iwai]

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

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

[Takashi Iwai]

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@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.

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

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

[Ricardo Cerqueira]

Hi again;

On Mon, 23 Oct 2006 13:36:55 +0200, Takashi Iwai <tiwai@suse.de> wrote:

>>
>> 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.

2.6.18 (fedora's version), and gcc 4.1.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.

I do have it defined, so that's not it, either...

--
RC


-------------------------------------------------------------------------
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

Re: (no subject)

[Thierry Vignaud]

Ricardo Cerqueira <ricardo@cerqueira.org> writes:

> >>> > 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?)

core/info.c is kernel land, no glibc code is used there

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

-------------------------------------------------------------------------
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