Im letzten Moment wurde eine bedeutsame Änderung in den Kernel eingebracht: Die Unterstützung für das x32-ABI, das im September 2011 erstmals vorgestellt wurde. Es handelt sich dabei um eine Schnittstelle für 32-Bit-Programme auf 64-Bit-Rechnern. Programme, die mit dem 32-Bit-Adressraum auskommen, sollten von den Vorteilen der 64-Bit-Prozessoren profitieren, dabei aber kompakteren Code verwenden und dadurch in den meisten Fällen etwas schneller sein als die bisherigen x86-ABIs in 32 und 64 Bit. Eine vollständige Entwicklungsumgebung dafür steht bereits zur Verfügung. Das neue ABI dürfte in erster Linie für die Entwickler von Software für massiv parallele Rechner interessant sein, wo jedes Prozent mehr Leistung wichtig ist.
Manche alte HW macht auf 64 Bit Systemen Probleme.
So hat der emu10k1 Soundchip von Creative Labs nur 31 Adressleitungen, was dazu führt, daß Soundfontdateien nur innerhalb der ersten 2 GB geladen werden dürfen.
Bei 32 Bit Betriebssystemen hat das keine Probleme bereitet, weil dort das OS maximal die unteren 2 GB verwendet hat und der Soundchip somit via DMA auf diese Daten zugreifen konnte.
Bei einem 64 Bit Linux Kernel geht das nun nicht mehr, wenn genug RAM im Rechner steckt, was dazu führt, daß asfxload einen Fehler ausspruckt, daß nicht genug Platz vorhanden wäre, wenn man versucht eine große Soundfontdatei in den Speicher zu laden.
Ich kenne die Möglichkeit im Linuxkernel einen Wert im Quellcode zu ändern und den Kernel dann neu zu compilieren, damit obiges auch auf 64 Bit Kernel funktioniert, aber das ist nur ein Workarround der immer selbstgebackene Kernel vorraussetzt.
Ich halte launchpad für den falschen Ort solch einen Bug zu Melden.
Da du dir den Kernel ja auch schon selber übersetzt hast, hast du sicher schon den vanilla Kernel versucht. Dann schildere das Problem lieber mal auf https://bugzilla.kernel.org/
Im Betroffenen Modul steht doch sicher auch der Maintainer des Modul vielleicht kann man ihn ja auch darauf mal aufmerksam machen.
Der Bug ist vom 16.01.2008 (!), das ist viel zulange her. Einen "confirmed" Bug jahrelang als "undecided" und "unassigned" vor sich hinverrotten zu lassen, bringt wohl niemandem etwas. Ich schließe mich deshalb dem Vorschlag von Nille02 an.
Manche alte HW macht auf 64 Bit Systemen Probleme.
So hat der emu10k1 Soundchip von Creative Labs nur 31 Adressleitungen, was dazu führt, daß Soundfontdateien nur innerhalb der ersten 2 GB geladen werden dürfen.
Bei 32 Bit Betriebssystemen hat das keine Probleme bereitet, weil dort das OS maximal die unteren 2 GB verwendet hat und der Soundchip somit via DMA auf diese Daten zugreifen konnte.
Bei einem 64 Bit Linux Kernel geht das nun nicht mehr, wenn genug RAM im Rechner steckt, was dazu führt, daß asfxload einen Fehler ausspruckt, daß nicht genug Platz vorhanden wäre, wenn man versucht eine große Soundfontdatei in den Speicher zu laden.
PS:
Ich kenne die Möglichkeit im Linuxkernel einen Wert im Quellcode zu ändern und den Kernel dann neu zu compilieren, damit obiges auch auf 64 Bit Kernel funktioniert, aber das ist nur ein Workarround der immer selbstgebackene Kernel vorraussetzt.
Eine saubere Lösung wäre mir hier viel lieber.
Interessantes Problem. Was sagt denn der Treiber Dev dazu? Bzw warum wird der Workaround nicht eingepflegt?
Hier gibt es einen Bugreport dazu.
https://bugs.launchpad.net/ubuntu/+source/awesfx/+bug/183456
Warum kein Workaraound eingepflegt wird, weiß ich nicht (mehr).
Ich halte launchpad für den falschen Ort solch einen Bug zu Melden.
Da du dir den Kernel ja auch schon selber übersetzt hast, hast du sicher schon den vanilla Kernel versucht. Dann schildere das Problem lieber mal auf https://bugzilla.kernel.org/
Im Betroffenen Modul steht doch sicher auch der Maintainer des Modul vielleicht kann man ihn ja auch darauf mal aufmerksam machen.
Der Bug ist vom 16.01.2008 (!), das ist viel zulange her. Einen "confirmed" Bug jahrelang als "undecided" und "unassigned" vor sich hinverrotten zu lassen, bringt wohl niemandem etwas.
Ich schließe mich deshalb dem Vorschlag von Nille02 an.