| 1 |
On Sat, 8 Jan 2011 18:10:03 +0000 (UTC) |
| 2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
| 3 |
|
| 4 |
|
| 5 |
> Are the devices actually |
| 6 |
> showing up in /dev/? Assuming you use udev, maybe it's the problem? If |
| 7 |
> you run them as modules not built-in, are the alsa kernel modules |
| 8 |
> themselves actually loading? |
| 9 |
|
| 10 |
First, I want to thank all those who took the time to confirm (even though, |
| 11 |
from my perspective, it was all bad news :-( ). |
| 12 |
|
| 13 |
The modules are loading without problem. For example, the kernel |
| 14 |
log reports the following: |
| 15 |
|
| 16 |
kernel: ICE1712 0000:04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 |
| 17 |
|
| 18 |
Both lspci and alsa-info.sh show that the sound card is there, and |
| 19 |
this would not happen if the modules were not being properly loaded. |
| 20 |
In other words the kernel can detect the card. |
| 21 |
|
| 22 |
I don't use udev. All modules are loaded manually and the devices |
| 23 |
in /dev are permanent. Permissions are also as they should be, |
| 24 |
because an alsa script was used to create the devices. |
| 25 |
|
| 26 |
The problem seems to be with the applications. The open() routine |
| 27 |
reports back "no device found." Now, open() is a glibc routine but |
| 28 |
it will ultimately call the kernel routines that are, I believe, contained |
| 29 |
in the alsa modules. Since kernel 2.6.36 works, it most likely is a |
| 30 |
kernel 2.6.37 issue. |
| 31 |
|
| 32 |
I'll have to recompile 2.6.37 with debugging output and see what |
| 33 |
happens. |
| 34 |
|
| 35 |
Frank Peters |
Archives