[gentoo-amd64] Alsa Problem With Kernel 2.6.37

[gentoo-amd64] Alsa Problem With Kernel 2.6.37

[Frank Peters]

Hello,

I would like to ask the list for some confirmation regarding a sudden
problem I am having with Alsa sound.  The 2.6.37 kernel was just released
and I immediately compiled and installed it.  This is the plain vanilla 
kernel source which is the same as is available at kernel.org.

Now, Alsa sound does not work.  Everything on my system is the same except
for the new kernel 2.6.37.

The problem, as far as I can determine, is that the usual sound devices
are not being detected.  The Alsa sound modules load properly and my sound
card appears in the list shown by lspci.  But doing an strace with any of the
Alsa utilities always shows the following:

open("/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = -1 ENODEV (No such device)
open("/dev/aloadC0", O_RDONLY|O_CLOEXEC) = -1 ENODEV (No such device)

These devices do exist.  I can reboot with kernel 2.6.36 and the sound
works normally, but for some reason, the new kernel 2.6.37 modules cannot detect
these devices.

There are two sound "cards" available on my machine.  One is the Intel HDA
built into the motherboard (which I don't ordinarily use) and the other is a
PCI M-Audio Delta 2496 (Alsa ice1712 driver).  Alsa modules for both cards show
the same failure, and both cards exhibit no problems with kernel 2.6.36.

I already posted a report of this issue on the Alsa-users list but received
no response.  Before I go posting more reports I just want to ask for some
confirmation.  Has anyone installed the new 2.6.37 kernel and gotten functioning
sound?

Frank Peters

[gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Nikos Chantziaras]

On 01/08/2011 06:28 PM, Frank Peters wrote:
> [...]
> I already posted a report of this issue on the Alsa-users list but received
> no response.  Before I go posting more reports I just want to ask for some
> confirmation.  Has anyone installed the new 2.6.37 kernel and gotten functioning
> sound?

No problems here with a SB Live 24-bit.  I don't use modules though, 
everything is compiled-in into the kernel.

Res: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Axial Astaroth]

No problems here with kernel 3.6.37 and my sound card:


00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High 
Definition Audio (rev 06)
Subsystem: Lenovo Device 38af
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel

Compiled as a module.

Att

[gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Duncan]

Frank Peters posted on Sat, 08 Jan 2011 11:28:17 -0500 as excerpted:

> I already posted a report of this issue on the Alsa-users list but
> received
> no response.  Before I go posting more reports I just want to ask for
> some confirmation.  Has anyone installed the new 2.6.37 kernel and
> gotten functioning sound?

I run the Linus live-git kernels so have been running the 2.6.37 series 
for some time now, and in fact am running 2.6.37 itself, ATM.  I don't use 
kernel modules here as I build everything in, but my sound (AMD 8xxx 
chipset, i810/ac97 alsa driver) is working and has been thru the whole 
cycle.  I don't believe it'd have been released with a lot of people not 
having sound, tho there might have conceivably been one or two reports in-
progress.

The hda driver still gets a lot of work each cycle, so it's reasonably 
possible it could fail (tho I imagine a lot of folks have it too, so it 
gets a lot of testing), but that it's happening with another driver too, 
suggests that you might have a different issue.  Are the devices actually 
showing up in /dev/?  Assuming you use udev, maybe it's the problem?  If 
you run them as modules not built-in, are the alsa kernel modules 
themselves actually loading?

FWIW, udev-164-r1 and alsa-utils-1.0.23-r1, here (~amd64).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Frank Peters]

On Sat, 8 Jan 2011 18:10:03 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:


>  Are the devices actually 
> showing up in /dev/?  Assuming you use udev, maybe it's the problem?  If 
> you run them as modules not built-in, are the alsa kernel modules 
> themselves actually loading?

First, I want to thank all those who took the time to confirm (even though,
from my perspective, it was all bad news :-( ).

The modules are loading without problem.  For example, the kernel
log reports the following:

kernel: ICE1712 0000:04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21

Both lspci and alsa-info.sh show that the sound card is there, and
this would not happen if the modules were not being properly loaded.
In other words the kernel can detect the card.

I don't use udev.  All modules are loaded manually and the devices
in /dev are permanent.  Permissions are also as they should be,
because an alsa script was used to create the devices.

The problem seems to be with the applications.  The open() routine
reports back "no device found."  Now, open() is a glibc routine but
it will ultimately call the kernel routines that are, I believe, contained
in the alsa modules.  Since kernel 2.6.36 works, it most likely is a
kernel 2.6.37 issue.

I'll have to recompile 2.6.37 with debugging output and see what
happens.

Frank Peters

Re: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Martin Herrman]

2011/1/8 Frank Peters <frank.peters@comcast.net>:

>
> First, I want to thank all those who took the time to confirm (even though,
> from my perspective, it was all bad news :-( ).
>
> The modules are loading without problem.  For example, the kernel
> log reports the following:
>
> kernel: ICE1712 0000:04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
>
> Both lspci and alsa-info.sh show that the sound card is there, and
> this would not happen if the modules were not being properly loaded.
> In other words the kernel can detect the card.
>
> I don't use udev.  All modules are loaded manually and the devices
> in /dev are permanent.  Permissions are also as they should be,
> because an alsa script was used to create the devices.
>
> The problem seems to be with the applications.  The open() routine
> reports back "no device found."  Now, open() is a glibc routine but
> it will ultimately call the kernel routines that are, I believe, contained
> in the alsa modules.  Since kernel 2.6.36 works, it most likely is a
> kernel 2.6.37 issue.
>
> I'll have to recompile 2.6.37 with debugging output and see what
> happens.
>
> Frank Peters
>
>

Hi Frank,

works perfect here.

04:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8788
[Oxygen HD Audio]
        Subsystem: ASUSTeK Computer Inc. Virtuoso 100 (Xonar D1)
        Flags: bus master, medium devsel, latency 32, IRQ 20
        I/O ports at d000 [size=256]
        Capabilities: [c0] Power Management version 2
        Kernel driver in use: AV200

I have compiled everything in the kernel, no modules.

Curious: why aren't you using udev?

Regards,

Martin

Re: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Frank Peters]

On Sat, 8 Jan 2011 22:20:28 +0100
Martin Herrman <martin@herrman.nl> wrote:

> works perfect here.

Thanks for the report -- even though, to me, it's bad news.

> 
> Curious: why aren't you using udev?
> 

I've been using Linux since 1998 and I like most the opportunity
for control that Linux allows.  To suit my minimalist needs, I have
customized my system to a great extent.  For example, I have completely
eliminated the complex and cumbersome initialization scripts that
are found in /etc/init.d, /etc/conf.d, and other locations.  In their
place I wrote my own very simple initialization script that automatically
boots into console (no login).  From there I can go to X (my usual action)
or just use the console for configuration, troubleshooting, or other tasks.

(I probably should not admit this.  If any Gentoo maintainers hear about
it they would flatly refuse to help if any problems arise.  But I think
that I understand the system well enough to take this approach safely.)

I have also eliminated udev as part of this simplification.  I know what's
on my machine and what has to be done to enable it.  I would rather not
have actions performed "automagically" for me whenever I plug in a USB
printer of storage device.  Part of the reason is philosophical and part
is just a desire to understand the OS better.

Linux allows many possibilities for customization and, IMO, that is half
the fun of using it.  Most distributions, including Gentoo, adhere to the
standard methods.  But if one has the inclination for exploration then
there is much that can be done to go well beyond the standard methods.

Frank Peters

[gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Duncan]

Frank Peters posted on Sat, 08 Jan 2011 18:11:27 -0500 as excerpted:

>> Curious: why aren't you using udev?
>> 
>> 
> I've been using Linux since 1998 and I like most the opportunity
> for control that Linux allows.  To suit my minimalist needs, I have
> customized my system to a great extent.  For example, I have completely
> eliminated the complex and cumbersome initialization scripts that
> are found in /etc/init.d, /etc/conf.d, and other locations.  In their
> place I wrote my own very simple initialization script that
> automatically boots into console (no login).  From there I can go to X
> (my usual action) or just use the console for configuration,
> troubleshooting, or other tasks.

> I have also eliminated udev as part of this simplification.  I know
> what's on my machine and what has to be done to enable it.  I would
> rather not have actions performed "automagically" for me whenever I plug
> in a USB printer of storage device.  Part of the reason is philosophical
> and part is just a desire to understand the OS better.

Wow. I understand exactly why you do it, because I'm the same way, only 
the Gentoo initscripts are reasonable enough for me and I've enjoyed 
watching openrc/baselayout2 develop -- in fact, since I actually /grok/ 
bash scripting at a reasonable level, its the one area I can quite 
frequently not only submit bug reports, but trace the code and suggest 
patches, which I've done on a number of occasions.  (In one case, once I 
started hitting an error and traced it, it was quite apparent the error 
path/case had never been tested at all, as the logic was apparent but the 
code simply didn't and couldn't work as intended.  By the time the 
original bug was fixed I think I'd had patches for two others taken and 
helped work on a third, in addition to the one for the original triggering 
bug.)

Also, I remember static dev and highly prefer a dynamic dev, since that 
makes it that way, it's a simple binary-case (1) device there, the kernel 
detects the hardware and created a device, any problem must be above that 
level, (0) device not there, kernel/module/detection problem, that you 
don't get if the device node always exists regardless of whether the 
kernel knows what to do with the device or not, since it's a static file.  
But I definitely understand the appeal and simplicity of doing it the 
other way, avoiding all the layers on layers of "automagic".

But it seems I often have at least one and sometimes two or three 
initscripts that I've highly modified, either to cover "advanced" 
functionality the script doesn't offer on its own (back when md-raid first 
got partitioning support, my version of the script handled that way before 
Gentoo's did, and I had a bug open for some time on it before Gentoo 
finally added that feature based on my work and that of another user, as 
well as the md-raid initscript maintainer; I'm doing similar now with 
additional file-specific bind-mounts into the bind/named chroot), or to 
delete complexity I don't need, sometimes both (I simplify the script, 
cutting out what I don't need, to better undestand it before adding my own 
advanced functionality).

> Linux allows many possibilities for customization and, IMO, that is half
> the fun of using it.  Most distributions, including Gentoo, adhere to
> the standard methods.  But if one has the inclination for exploration
> then there is much that can be done to go well beyond the standard
> methods.

And of course, Gentoo makes maintaining customization much easier than 
many distributions. =:^)  I pretty much learned bash, at least the 
scripting side, by rewriting the Mandrake rc.sysinit script, modularizing 
it, etc.  Then I upgraded to the next version, and had to do it again...  
Then I upgraded again, and shortly thereafter, started running cooker 
(rolling "testing" version), at which point I gave up.  Gentoo's rolling 
updates and configuration update management tools make it relatively easy 
to avoid having a custom config broken.

....

Meanwhile, I see you've fixed the problem, but it's worth noting that lspci 
lists devices based on generic pci-bus device queries, not what the kernel 
has drivers for.  Just because lspci lists it doesn't mean the kernel can 
handle that device, only that the device returned certain information when 
the kernel queried for devices on that bus.

Unless you use the -k switch, enabled by default with -v, that is (and 
only on 2.6 kernels, which we're dealing with of course, but...).  -k 
shows kernel drivers handling and/or that can handle a device.  In that 
case, you get that information too if the kernel can handle the device, 
but devices that the kernel knows not how to handle will still be listed, 
just without any assigned kernel driver.

Maybe you meant that lspci -v (or -k) was saying it had assigned a driver 
to it, but that's not what you said, you said lspci wouldn't show the 
sound card as there if the module wasn't loaded, and that's not correct, 
as it'd still be a device on the bus and would respond to queries (with 
the results printed) as such.

This is an important distinction, because lspci can thus be used to see 
devices that the kernel does NOT have drivers for (or doesn't have them 
built and available).  Using lspci to see what hardware a machine has 
(once Linux boots on it at all), so one can google for support status and 
what driver to use, especially on second-hand equipment where a manual 
isn't available, and/or where it's easier to run lspci than to crack open 
the box to look, is a very important usage case for it.  If lspci didn't 
list devices the kernel wasn't configured with drivers for, that wouldn't 
work, so I'm very glad it DOES list them. =:^)

alsa-info.sh, OTOH, I don't know.  You may be correct about it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: Alsa Problem With Kernel 2.6.37

[Rich Freeman]

On Sat, Jan 8, 2011 at 6:11 PM, Frank Peters <frank.peters@comcast.net> wrote:
> (I probably should not admit this.  If any Gentoo maintainers hear about
> it they would flatly refuse to help if any problems arise.  But I think
> that I understand the system well enough to take this approach safely.)

echo "Frank Peters" >> /cvs/blacklist
cvs commit

Seriously, though, lots of people use Gentoo as a starting point to do
lots of crazy things, since it has many of the advantages of LFS and
few of the disadvantages.  As long as you know what you're doing and
don't send devs on wild goose chases nobody minds.  In fact, if you're
doing something really exotic with Gentoo (not sure if this qualifies)
pr@g.o or David Abbot might be interested.

If the devs didn't like getting their hands dirty they'd probably be
running Ubuntu...  :)

Rich

Re: [gentoo-amd64] Alsa Problem With Kernel 2.6.37[Solved]

[Frank Peters]

On Sat, 8 Jan 2011 11:28:17 -0500
Frank Peters <frank.peters@comcast.net> wrote:

> 
> The problem, as far as I can determine, is that the usual sound devices
> are not being detected.
>

The problem has been solved.  When I compiled the new 2.6.27 kernel, the
CONFIG_SND_DYNAMIC_MINORS option was set [=yes].  Unless one is using
udev, which I am not, this option should be unset [=no], otherwise alsa will
try to dynamically create the device.

Somehow, I must have overlooked the setting of this option and it caused
the problem.

Anyway, thanks again to all those who responded.

Frank Peters

Re: [gentoo-amd64] Alsa Problem With Kernel 2.6.37[Solved]

[Zhu Sha Zang]

Em 08-01-2011 23:08, Frank Peters escreveu:
> On Sat, 8 Jan 2011 11:28:17 -0500
> Frank Peters <frank.peters@comcast.net> wrote:
>
>> The problem, as far as I can determine, is that the usual sound devices
>> are not being detected.
>>
> The problem has been solved.  When I compiled the new 2.6.27 kernel, the
> CONFIG_SND_DYNAMIC_MINORS option was set [=yes].  Unless one is using
> udev, which I am not, this option should be unset [=no], otherwise alsa will
> try to dynamically create the device.
>
> Somehow, I must have overlooked the setting of this option and it caused
> the problem.
>
> Anyway, thanks again to all those who responded.
>
> Frank Peters
>
Ok, i'm using udev, CONFIG_SND_DYNAMIC_MINORS is set to y, my sound are
working because i've used alsaconf inside the last kernel but if i try
to use alsaconf inside 2.6.37 my

00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset
High Definition Audio (rev 06)
        Subsystem: Lenovo Device 38af
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel

aren't detected.

AAAAAAAAND, if i try deactivate CONFIG_SND_DYNAMIC_MINORS the only way 
to do it is deactivate intel-hda support too.

What can i do?

Re: [gentoo-amd64] Alsa Problem With Kernel 2.6.37[Solved]

[Frank Peters]

On Sat, 22 Jan 2011 10:00:38 -0200
Zhu Sha Zang <zhushazang@yahoo.com.br> wrote:

>         Kernel driver in use: HDA Intel
>         Kernel modules: snd-hda-intel
> 
> aren't detected.
> 

You may want to try strace (emerge strace) to possibly find out
why the hardware is not being detected.  Just do:

strace amixer

The output may show where the problem lies.

Frank Peters

Re: [gentoo-amd64] Alsa Problem With Kernel 2.6.37[Solved]

[Zhu Sha Zang]

My fault, the hardware don't detected only by alsaconf utilitie.

Att

Em 22-01-2011 13:24, Frank Peters escreveu:
> On Sat, 22 Jan 2011 10:00:38 -0200
> Zhu Sha Zang <zhushazang@yahoo.com.br> wrote:
> 
>>         Kernel driver in use: HDA Intel
>>         Kernel modules: snd-hda-intel
>>
>> aren't detected.
>>
> 
> You may want to try strace (emerge strace) to possibly find out
> why the hardware is not being detected.  Just do:
> 
> strace amixer
> 
> The output may show where the problem lies.
> 
> Frank Peters
>