Re: [alsa-devel] [Alsa-user] Impossible to make subwoofer work on a Dell XPS M1710w
![](https://secure.gravatar.com/avatar/ef236095877ef3e6f14b26ec016ddf3e.jpg?s=120&d=mm&r=g)
[crossposting to alsa-devel as adviced in ALSA-Configuration.txt]
The model option is _the_ important option for HD-audio driver. It overrides the configuration preset. As default, the driver reads the PCI (subsystem) IDs to identify which configuration preset to use. If not found, the driver does a guess work from the BIOS setup in most cases.
Now, since many laptops are shipped with broken BIOS and the guess work is imperfect, you often face the famous problem -- "sound doesn't work" (great words that explain everything). Then you can pass model option for the preset designed for anohter hardware (e.g. model=thinkpad) to make the driver probe as if it's such a hardware. If you are lucky, your device is similar with others, and the driver works with such a preset. If not, we'd need to hack another preset for matching with your device.
The list of available model option is found in ALSA-Configuration.txt.
So it seems the Dell XPS M1710 isn't yet listed among the known models and also does not seem to be detected properly (as of hg20070816).
'lspci -v' gives: ... 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
'lspci -nv' gives: ... 00:1b.0 Class 0403: 8086:27d8 (rev 01) Subsystem: 1028:01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
Anything else I could do to help getting it (fully) supported ?
Best, Michael
![](https://secure.gravatar.com/avatar/5b19e9d0e834ea10ef75803718ad564b.jpg?s=120&d=mm&r=g)
At Fri, 17 Aug 2007 19:09:36 +0200, Michael Gerdau wrote:
[crossposting to alsa-devel as adviced in ALSA-Configuration.txt]
The model option is _the_ important option for HD-audio driver. It overrides the configuration preset. As default, the driver reads the PCI (subsystem) IDs to identify which configuration preset to use. If not found, the driver does a guess work from the BIOS setup in most cases.
Now, since many laptops are shipped with broken BIOS and the guess work is imperfect, you often face the famous problem -- "sound doesn't work" (great words that explain everything). Then you can pass model option for the preset designed for anohter hardware (e.g. model=thinkpad) to make the driver probe as if it's such a hardware. If you are lucky, your device is similar with others, and the driver works with such a preset. If not, we'd need to hack another preset for matching with your device.
The list of available model option is found in ALSA-Configuration.txt.
So it seems the Dell XPS M1710 isn't yet listed among the known models and also does not seem to be detected properly (as of hg20070816).
The sigmatel codec support is somewhat different from other codes. It tries to be as generic as possible, based only on the pin configuration without pre-defined mixer definitions and init verbs.
Do you mean a problem with the missing LFE? The missing LFE sounds like a different problem. AFAIK, the device itself _is_ set up properly as expected. It's likely a feature regression due to the improvements on the support of other devices with STAC codec chips. Or any other issue? Maybe it's better to describe the problem again here for guys who only read alsa-devel ML (I mostly do so, too). And, if it's about debugging, let's discuss on alsa-devel ML and drop Cc from alsa-users.
'lspci -v' gives: ... 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
'lspci -nv' gives: ... 00:1b.0 Class 0403: 8086:27d8 (rev 01) Subsystem: 1028:01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
Anything else I could do to help getting it (fully) supported ?
Why not patch the code :)
... or, we'd need more detailed information. Which codec chip is on it, and which pin widget corresponds to the actual I/O, especially the pin NID of the missing feature must be identified. It can be done only by the owner (tester) of the hardware. Developers don't have your device.
As a hint, if it's really a regression, try to revert to the version it did work. Check /proc/asound/card0/codec#* file to see which widget is changed by the LFE volume. That's the vital information.
Takashi
![](https://secure.gravatar.com/avatar/c33979e4f62067cd6c6e6ded4b5fc786.jpg?s=120&d=mm&r=g)
I looked it up, and according to the information here (Subsystem: Dell Unknown device 01ce, Dell XPS M1710), your system should have a Stac9200 in it and it has been supported (in hg) since Feb 13. Make sure you are not specifying any model in the /etc/modprobe.conf or /etc/modprobe.d/* files.
Also, if you are still having issues, run http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh and post the resulting file. It will have most of the debugging info that we need.
Tobin
On Fri, 2007-08-17 at 19:41 +0200, Takashi Iwai wrote:
At Fri, 17 Aug 2007 19:09:36 +0200, Michael Gerdau wrote:
[crossposting to alsa-devel as adviced in ALSA-Configuration.txt]
The model option is _the_ important option for HD-audio driver. It overrides the configuration preset. As default, the driver reads the PCI (subsystem) IDs to identify which configuration preset to use. If not found, the driver does a guess work from the BIOS setup in most cases.
Now, since many laptops are shipped with broken BIOS and the guess work is imperfect, you often face the famous problem -- "sound doesn't work" (great words that explain everything). Then you can pass model option for the preset designed for anohter hardware (e.g. model=thinkpad) to make the driver probe as if it's such a hardware. If you are lucky, your device is similar with others, and the driver works with such a preset. If not, we'd need to hack another preset for matching with your device.
The list of available model option is found in ALSA-Configuration.txt.
So it seems the Dell XPS M1710 isn't yet listed among the known models and also does not seem to be detected properly (as of hg20070816).
The sigmatel codec support is somewhat different from other codes. It tries to be as generic as possible, based only on the pin configuration without pre-defined mixer definitions and init verbs.
Do you mean a problem with the missing LFE? The missing LFE sounds like a different problem. AFAIK, the device itself _is_ set up properly as expected. It's likely a feature regression due to the improvements on the support of other devices with STAC codec chips. Or any other issue? Maybe it's better to describe the problem again here for guys who only read alsa-devel ML (I mostly do so, too). And, if it's about debugging, let's discuss on alsa-devel ML and drop Cc from alsa-users.
'lspci -v' gives: ... 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
'lspci -nv' gives: ... 00:1b.0 Class 0403: 8086:27d8 (rev 01) Subsystem: 1028:01ce Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at efffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) ...
Anything else I could do to help getting it (fully) supported ?
Why not patch the code :)
... or, we'd need more detailed information. Which codec chip is on it, and which pin widget corresponds to the actual I/O, especially the pin NID of the missing feature must be identified. It can be done only by the owner (tester) of the hardware. Developers don't have your device.
As a hint, if it's really a regression, try to revert to the version it did work. Check /proc/asound/card0/codec#* file to see which widget is changed by the LFE volume. That's the vital information.
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
![](https://secure.gravatar.com/avatar/ef236095877ef3e6f14b26ec016ddf3e.jpg?s=120&d=mm&r=g)
Do you mean a problem with the missing LFE? The missing LFE sounds like a different problem. AFAIK, the device itself _is_ set up properly as expected.
I mean the missing LFE.
I can confirm the device otherwise works as adverticed. In fact I only (kind of) miss the LFE since I read in another post it should be there :-)
And, if it's about debugging, let's discuss on alsa-devel ML and drop Cc from alsa-users.
I've run the current alsa-info.sh as suggested by Tobis Davis (thanks for the pointer BTW) and had it upload the result automatically.
Why not patch the code :)
That was my first idea :)
When I boldly started looking at it I realized I'm in for a steep learning curve. Not that I won't walk that road, but it will take me some time...
For a start I downloaded "Writing an alsa driver" and alsa-driver-api and will start reading it "real soon" (TM)
As a hint, if it's really a regression, try to revert to the version it did work. Check /proc/asound/card0/codec#* file to see which widget is changed by the LFE volume. That's the vital information.
I don't know whether it actually is a regression or a not-yet-implemented feature. I do own my XPS M1710 since around March/April 2007 and I don't recall to have seen it. However sound worked right from the start and until recently I wasn't even aware there should be a LFE control. In fact the only "evidence" I have there should be one is already mentioned other post.
That having said: The link http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh should probably go into ALSA-Configuration.txt
I also suggest to add a troubleshooting section into the navigation block of the entry page of alsa wiki (or move the existing one there -- I have not been able to easily find an existing one though) which mentions this link as well as all other stuff that a user should be aware of when reporting a problem.
If it isn't easy to provide concise troubleshooting instructions it would at least be helpful to give an overview where and how to find the relevant info in the wiki.
After all the user having a problem often is just starting learning alsa.
Best, Michael
![](https://secure.gravatar.com/avatar/c33979e4f62067cd6c6e6ded4b5fc786.jpg?s=120&d=mm&r=g)
I was looking over some other Dell INF files, and found a newer pin def listing for this system. Try this patch and see if it fixes your Center/LFE settings.
Tobin
On Sun, 2007-08-19 at 15:31 +0200, Michael Gerdau wrote:
Do you mean a problem with the missing LFE? The missing LFE sounds like a different problem. AFAIK, the device itself _is_ set up properly as expected.
I mean the missing LFE.
I can confirm the device otherwise works as adverticed. In fact I only (kind of) miss the LFE since I read in another post it should be there :-)
And, if it's about debugging, let's discuss on alsa-devel ML and drop Cc from alsa-users.
I've run the current alsa-info.sh as suggested by Tobis Davis (thanks for the pointer BTW) and had it upload the result automatically.
Why not patch the code :)
That was my first idea :)
When I boldly started looking at it I realized I'm in for a steep learning curve. Not that I won't walk that road, but it will take me some time...
For a start I downloaded "Writing an alsa driver" and alsa-driver-api and will start reading it "real soon" (TM)
As a hint, if it's really a regression, try to revert to the version it did work. Check /proc/asound/card0/codec#* file to see which widget is changed by the LFE volume. That's the vital information.
I don't know whether it actually is a regression or a not-yet-implemented feature. I do own my XPS M1710 since around March/April 2007 and I don't recall to have seen it. However sound worked right from the start and until recently I wasn't even aware there should be a LFE control. In fact the only "evidence" I have there should be one is already mentioned other post.
That having said: The link http://bulletproof.servebeer.com/alsa/scripts/alsa-info.sh should probably go into ALSA-Configuration.txt
I also suggest to add a troubleshooting section into the navigation block of the entry page of alsa wiki (or move the existing one there -- I have not been able to easily find an existing one though) which mentions this link as well as all other stuff that a user should be aware of when reporting a problem.
If it isn't easy to provide concise troubleshooting instructions it would at least be helpful to give an overview where and how to find the relevant info in the wiki.
After all the user having a problem often is just starting learning alsa.
Best, Michael _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
![](https://secure.gravatar.com/avatar/ef236095877ef3e6f14b26ec016ddf3e.jpg?s=120&d=mm&r=g)
Hi Tobin,
I was looking over some other Dell INF files, and found a newer pin def listing for this system. Try this patch and see if it fixes your Center/LFE settings.
It does. Thanks alot, best, Michael
![](https://secure.gravatar.com/avatar/c33979e4f62067cd6c6e6ded4b5fc786.jpg?s=120&d=mm&r=g)
I'll go ahead and combine it with another Dell patch I'm submitting. Great to hear that your sound is working now.
On Sun, 2007-08-19 at 21:13 +0200, Michael Gerdau wrote:
Hi Tobin,
I was looking over some other Dell INF files, and found a newer pin def listing for this system. Try this patch and see if it fixes your Center/LFE settings.
It does. Thanks alot, best, Michael
![](https://secure.gravatar.com/avatar/ef236095877ef3e6f14b26ec016ddf3e.jpg?s=120&d=mm&r=g)
I'll go ahead and combine it with another Dell patch I'm submitting. Great to hear that your sound is working now.
Seems my testing yesterday was flawed. When today I retried I had no sound. Reverting the patch brought back my sound.
Sorry for my poor testing, Michael
![](https://secure.gravatar.com/avatar/c33979e4f62067cd6c6e6ded4b5fc786.jpg?s=120&d=mm&r=g)
On Sun, 2007-08-19 at 15:31 +0200, Michael Gerdau wrote:
I've run the current alsa-info.sh as suggested by Tobis Davis (thanks for the pointer BTW) and had it upload the result automatically.
Yes, but where's the link or the alsa-info.txt file? You still need to post this for us to be able to read it.
![](https://secure.gravatar.com/avatar/ef236095877ef3e6f14b26ec016ddf3e.jpg?s=120&d=mm&r=g)
I've run the current alsa-info.sh as suggested by Tobis Davis (thanks for the pointer BTW) and had it upload the result automatically.
Yes, but where's the link or the alsa-info.txt file? You still need to post this for us to be able to read it.
Apparently I've been too stupid to understand it in the first place.
I've rerun it after applying your patch (which provided me with a LFE control, thanks alot) and it ended as http://pastebin.ca/663596
I have not written down the ID of the previous file but I have saved away a copy of it. If there is interest I would try and upload that.
Best, Michael
![](https://secure.gravatar.com/avatar/c33979e4f62067cd6c6e6ded4b5fc786.jpg?s=120&d=mm&r=g)
If the patch that I sent you works, then this info is moot at this point. Not to worry.
On Sun, 2007-08-19 at 21:12 +0200, Michael Gerdau wrote:
I've run the current alsa-info.sh as suggested by Tobis Davis (thanks for the pointer BTW) and had it upload the result automatically.
Yes, but where's the link or the alsa-info.txt file? You still need to post this for us to be able to read it.
Apparently I've been too stupid to understand it in the first place.
I've rerun it after applying your patch (which provided me with a LFE control, thanks alot) and it ended as http://pastebin.ca/663596
I have not written down the ID of the previous file but I have saved away a copy of it. If there is interest I would try and upload that.
Best, Michael
![](https://secure.gravatar.com/avatar/0b9d14090e32a1cdf23ac9b4ac323e8c.jpg?s=120&d=mm&r=g)
Hi,
I am the ALSA user that started this thread in the alsa-users list.
I found that my strategy of adding the "index=0" option and praying was nos stable enough, and each time I updated alsa or my kernel I had to pray again to get the subwoofer working.
I tried Tobin's patch and finally I got the LFE control again (which I had lost 4 hours ago by updating alsa and the kernel).
If there is anything I can do to get this problem solved, just let me know and I'll be more than glad to help.
Regards, - Celso Gorrín.
![](https://secure.gravatar.com/avatar/5b19e9d0e834ea10ef75803718ad564b.jpg?s=120&d=mm&r=g)
At Thu, 23 Aug 2007 04:36:34 -0400, Celso Gorrín wrote:
Hi,
I am the ALSA user that started this thread in the alsa-users list.
I found that my strategy of adding the "index=0" option and praying was nos stable enough, and each time I updated alsa or my kernel I had to pray again to get the subwoofer working.
I tried Tobin's patch and finally I got the LFE control again (which I had lost 4 hours ago by updating alsa and the kernel).
If there is anything I can do to get this problem solved, just let me know and I'll be more than glad to help.
Please check ALSA bug#3319, try the patch, and give a report back: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3319
thanks,
Takashi
![](https://secure.gravatar.com/avatar/53d0f967d21e6b4783722a147b7756c8.jpg?s=120&d=mm&r=g)
Iam trying to compile alsa 1.0.14 agains Mandriva Linux kernel 2.6.17-13mdv And I get a floating point exception.
I No idea how I get a floating point exception.
Anyway, here is the error
..... make[2]: Leaving directory `/usr/local/src/alsa-driver-1.0.14/misc' make[1]: Leaving directory `/usr/local/src/alsa-driver-1.0.14' make -C /lib/modules/2.6.17-13mdv/source SUBDIRS=/usr/local/src/alsa-driver-1.0.14 O=/lib/modules/2.6.17-13mdv/build CPP="gcc -E" CC="gcc" modules make[1]: Entering directory `/usr/src/linux-2.6.17-13mdv'
WARNING: Symbol version dump /usr/src/linux-2.6.17-13mdv/Module.symvers is missing; modules will have no dependencies and modversions.
CC [M] /usr/local/src/alsa-driver-1.0.14/acore/hwdep.o /bin/sh: line 1: 9628 Floating point exception(core dumped) scripts/basic/fixdep /usr/local/src/alsa-driver-1.0.14/acore/.hwdep.o.d /usr/local/src/alsa-driver-1.0.14/acore/hwdep.o 'gcc -Wp,-MD,/usr/local/src/alsa-driver-1.0.14/acore/.hwdep.o.d -nostdinc -isystem /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/include -I/usr/local/src/alsa-driver-1.0.14/include -D__KERNEL__ -Iinclude -Iinclude2 -I/usr/src/linux-2.6.17-13mdv/include -include include/linux/autoconf.h -I/usr/local/src/alsa-driver-1.0.14/acore -I/usr/local/src/alsa-driver-1.0.14/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -ffreestanding -I/usr/src/linux-2.6.17-13mdv/include/asm-i386/mach-default -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DALSA_BUILD -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hwdep)" -D"KBUILD_MODNAME=KBUILD_STR(snd_hwdep)" -c -o /usr/local/src/alsa-driver-1.0.14/acore/hwdep.o /usr/local/src/alsa-driver-1.0.14/acore/hwdep.c'
/usr/local/src/alsa-driver-1.0.14/acore/.hwdep.o.tmp
make[4]: *** [/usr/local/src/alsa-driver-1.0.14/acore/hwdep.o] Error 136 make[3]: *** [/usr/local/src/alsa-driver-1.0.14/acore] Error 2 make[2]: *** [_module_/usr/local/src/alsa-driver-1.0.14] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.17-13mdv' make: *** [compile] Error 2
![](https://secure.gravatar.com/avatar/5b19e9d0e834ea10ef75803718ad564b.jpg?s=120&d=mm&r=g)
At Fri, 17 Aug 2007 13:32:52 -0700 (PDT), Bill Unruh wrote:
Iam trying to compile alsa 1.0.14 agains Mandriva Linux kernel 2.6.17-13mdv And I get a floating point exception.
I No idea how I get a floating point exception.
It appears rather like a compiler internal error, or something to do with your toolchain. It's hard to make the compiler giving such an error intentionally ;)
Takashi
Anyway, here is the error
..... make[2]: Leaving directory `/usr/local/src/alsa-driver-1.0.14/misc' make[1]: Leaving directory `/usr/local/src/alsa-driver-1.0.14' make -C /lib/modules/2.6.17-13mdv/source SUBDIRS=/usr/local/src/alsa-driver-1.0.14 O=/lib/modules/2.6.17-13mdv/build CPP="gcc -E" CC="gcc" modules make[1]: Entering directory `/usr/src/linux-2.6.17-13mdv'
WARNING: Symbol version dump /usr/src/linux-2.6.17-13mdv/Module.symvers is missing; modules will have no dependencies and modversions.
CC [M] /usr/local/src/alsa-driver-1.0.14/acore/hwdep.o /bin/sh: line 1: 9628 Floating point exception(core dumped) scripts/basic/fixdep /usr/local/src/alsa-driver-1.0.14/acore/.hwdep.o.d /usr/local/src/alsa-driver-1.0.14/acore/hwdep.o 'gcc -Wp,-MD,/usr/local/src/alsa-driver-1.0.14/acore/.hwdep.o.d -nostdinc -isystem /usr/lib/gcc/i586-mandriva-linux-gnu/4.1.1/include -I/usr/local/src/alsa-driver-1.0.14/include -D__KERNEL__ -Iinclude -Iinclude2 -I/usr/src/linux-2.6.17-13mdv/include -include include/linux/autoconf.h -I/usr/local/src/alsa-driver-1.0.14/acore -I/usr/local/src/alsa-driver-1.0.14/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2 -fno-omit-frame-pointer -fno-optimize-sibling-calls -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -ffreestanding -I/usr/src/linux-2.6.17-13mdv/include/asm-i386/mach-default -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DALSA_BUILD -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hwdep)" -D"KBUILD_MODNAME=KBUILD_STR(snd_hwdep)" -c -o /usr/local/src/alsa-driver-1.0.14/acore/hwdep.o /usr/local/src/alsa-driver-1.0.14/acore/hwdep.c'
/usr/local/src/alsa-driver-1.0.14/acore/.hwdep.o.tmp
make[4]: *** [/usr/local/src/alsa-driver-1.0.14/acore/hwdep.o] Error 136 make[3]: *** [/usr/local/src/alsa-driver-1.0.14/acore] Error 2 make[2]: *** [_module_/usr/local/src/alsa-driver-1.0.14] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.17-13mdv' make: *** [compile] Error 2
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
![](https://secure.gravatar.com/avatar/53d0f967d21e6b4783722a147b7756c8.jpg?s=120&d=mm&r=g)
On Mon, 20 Aug 2007, Takashi Iwai wrote:
At Fri, 17 Aug 2007 13:32:52 -0700 (PDT), Bill Unruh wrote:
Iam trying to compile alsa 1.0.14 agains Mandriva Linux kernel 2.6.17-13mdv And I get a floating point exception.
I No idea how I get a floating point exception.
It appears rather like a compiler internal error, or something to do with your toolchain. It's hard to make the compiler giving such an error intentionally ;)
It seems to have bee some problem in the packaged fixdep in the kernel source tree. I tried on another machine and everything worked fine. Sorry for the false alarm.
participants (5)
-
Bill Unruh
-
Celso Gorrín
-
Michael Gerdau
-
Takashi Iwai
-
Tobin Davis