Mausproblem

[Sonic]

Hi!

Ich bin mir nicht ganz sicher, ob das wirklich in den Bereich Kernel gehört, aber ich dachte, ich probiers mal hier. Wenn das falsch war, belehrt mich eines besseren

Mein Problem: ich habe Debian Testing AMD64 mit Kernel 2.6.21 auf einem MacPro. Ursprünglich war es Kernel 2.6.18, aber der hatte so einige Probleme mit dem System, die nach dem Upgrade verschwunden sind. Seitdem habe ich aber ein neues Problem: Nachdem der Rechner eine Weile läuft (kann alles zwischen 10 Minuten und mehreren Stunden sein) fängt die Maus auf einmal an, sich nur noch extrem langsam und zeitversetzt zu bewegen. Gleichzeitig steigt der von uptime angezeigte Systemauslastungswert, aber mit top oder anderen Tools sehe ich nichts ungewöhnliches und wenn ich den Rechner über Tastatur steuere reagiert er auch mit normaler Geschwindigkeit.

Das Dumme ist, dass dieses Mausproblem nur nach einem kompletten Neustart des Systems verschwindet, X neuzustarten oder in Runlevel 1 und zurück nach 2 zu gehen bringt gar nichts. D.h. ich muss den Rechner im Moment ständig neu booten, und da ich im Grub-Bootmanager meine Tastatur nicht benutzen kann (ich kann genau einmal eine Taste drücken, dann reagiert er nicht mehr), kann ich auch nicht so ohne weiteres zum alten Kernel zurück (obwohl der wie gesagt auch buggy war, d.h. das wäre höchstens eine Notlösung).

Hat jemand eine Idee, was ich probieren könnte? Im Augenblick habe ich sozusagen das Win95-Feeling, und den Zustand möchte ich gerne beenden


P.S.: Ist mir jetzt gerade noch eingefallen: In dem moment, in dem die Maus langsam wird, erscheint manchmal (ungefähr jedes zweite mal) ein KDE-Hinweisfenster, dass eine neue Audio-CD eingelegt wurde (was nicht stimmt). Ich hatte dann mal auf Verdacht udev, hald u.ä. gestoppt, aber das hat auch nichts gebracht.

[gms]

was ist das für eine Mouse ?
Wenn es eine USB-Mouse ist, versuche diese einmal ein und auszustecken, vielleicht hift das als Notlösung.
Auf alle Fälle solltest du einmal die Logdateien durchstöbern ( /var/log/messages, dmesg ), ob dort etwas auffälliges zu diesem Zeitpunkt gemeldet wird.

Gruß
gms

[me]

Hi!

Du solltest mal den 2.6.22.1 Kernel probieren und konfiguriere deine Maus gleich mal bei X so um, dass sie das "evdev" Protokoll benutzt. Muss nicht unbedingt die Lösung sein, aber ein Ansatz

[Sonic]

Hi!

Danke für die schnellen Antworten!

Was die Mäuse angeht: ich habe eine Apple Mighty Mouse und eine Microsoft Laser Mouse 6000, die beide über USB angeschlossen sind. Ich hatte auch schon probiert, jeweils eine der beiden Mäuse nicht anzustecken, aber das Problem tritt trotzdem auf.

Auch das mit dem Abziehen der Mäuse, wenn sie langsam werden, habe ich mal ausprobiert, aber das Problem ist, dass sie nach dem erneuten Anstecken garnicht mehr erkannt werden.

Ansonsten habe ich jetzt mal meine xorg.conf auf evdev geändert, kann aber noch nicht sagen, ob das was gebracht hat. Nur zwei Sachen sind mir aufgefallen:

-Wenn ich die Option CorePointer benutze, dann startet X nicht (CorePointer ist in der config nur einmal vorhanden, d.h. das sollte das Problem nicht sein)

-horizontales Scrolling geht nicht (hatte dazu Option "HWHEELRelativeAxisButtons" "7 6" eingefügt)


In den logfiles habe ich bisher wenig interessantes gefunden, aber wenn das Problem das nächste mal auftritt, werde ich nochmal nachsehen. Das einzige, was mir komisch vorgekommen ist, sind die folgenden Zeilen, die glaube ich zeitgleich mit dem Mausproblem aufgetreten sind:

Code: Alles auswählen

Jul 27 19:35:35 arrakis kernel: hda: lost interrupt
Jul 27 19:36:35 arrakis kernel: hda: lost interrupt
Jul 27 19:37:35 arrakis kernel: ide-cd: cmd 0x3 timed out
Jul 27 19:37:35 arrakis kernel: hda: lost interrupt

Das mit dem 2.6.22er Kernel wäre noch ne Idee, aber ich wollte eigentlich gerne auf Testing bleiben (und mit Pinning kenne ich mich leider garnicht aus), von daher werde ich da glaube ich abwarten, bis das Teil in Testing landet

[gms]

Das mit dem 2.6.22er Kernel wäre noch ne Idee, aber ich wollte eigentlich gerne auf Testing bleiben (und mit Pinning kenne ich mich leider garnicht aus), von daher werde ich da glaube ich abwarten, bis das Teil in Testing landet

du kannst dir das Paket aber auch manuell herunterladen und mit "dpkg -i /pfad/zum/paket" installieren.
Danach sollten wir uns das Interrupt-Problem genauer anschauen. Wenn also mit dem neuen Kernel diese Fehler auch noch auftreten, dann poste bitte einmal die Ausgabe von "cat /proc/interrupts" und die Ausgabe von "dmesg" nach einem Bootvorgang ( letztere bitte auf NoPaste, da sie wahrscheinlich länger sein wird )

Gruß
gms

[Sonic]

Hi!

Habe jetzt 2.6.22 installiert, aber das Problem ist immer noch vorhanden (ich hab das Gefühl, es ist eher schlimmer geworden). Den dmesg-Output habe ich hochgeladen: http://nopaste.debianforum.de/6331

cat /proc/interrupts gibt folgendes aus:

Code: Alles auswählen

           CPU0       CPU1       CPU2       CPU3
  0:      20686      20652      20536      20538   IO-APIC-edge      timer
  8:          0          1          0          0   IO-APIC-edge      rtc
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 16:       4627       4585       4609       4611   IO-APIC-fasteoi   firewire_ohci, nvidia
 19:          1          1          1          1   IO-APIC-fasteoi   uhci_hcd:usb1, ehci_hcd:usb5
 20:       2477       2438       2487       2552   IO-APIC-fasteoi   uhci_hcd:usb2, ide0
 21:       3792       3785       3832       3794   IO-APIC-fasteoi   uhci_hcd:usb3, libata
 22:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 23:         59         35         62         40   IO-APIC-fasteoi   HDA Intel
1270:        385        407        376        366   PCI-MSI-edge      eth1
NMI:          0          0          0          0
LOC:      81714      81699      81677      81649
ERR:          0

Übrigens kommt die Meldung in /var/log/messages mit "lost interrupt" tatsächlich zeitgleich mit der Verlangsamung der Maus, d.h. wenn ich die bisherigen Indizien richtig verstehe, dann ist vermutlich das DVD-Laufwerk das Problem. Wie ist das, kann man Linux irgendwie dazu bringen, dieses Gerät völlig zu ignorieren? Wirklich brauchen tu ich es im Moment ohnehin nicht. Obwohl es natürlich cooler wäre, den Fehler einfach zu beheben

[gms]

teste bitte einmal den Kernelparameter "libata.atapi_enabled=1", aber Achtung, danach sollte dein DVD das Device /dev/sr0 bekommen

Gruß
gms

[Sonic]

Hi!

Ich weiß nicht, ob ich das richtig gemacht habe, aber wenn ich libata.atapi_enabled=1 in die /etc/sysctl.conf schreibe und anschließend sysctl -p ausführe passiert folgendes:

Code: Alles auswählen

sudo sysctl -p
error: "libata.atapi_enabled" is an unknown key

Wenn ich neu boote bekomme ich die selbe Fehlermeldung. Wo müsste ich den Parameter denn korrekterweise angeben? Irgendwo in /proc?

==Update==

Habe mittlerweile noch folgendes Vorgehen über Google gefunden und probiert:

Code: Alles auswählen

echo options libata atapi_enabled=1>/etc/modprobe.d/atapienable && update-initramfs -u

Aber soweit ich das sagen kann, hat das nicht funktioniert, zumindest habe ich nach einem Reboot unter /proc immer noch hda als DVD-Laufwerk und ein Gerät /dev/sr0 gibt es nicht. Ich habe gelesen, dass man das Ganze auch als Bootparameter für GRUB angeben kann, aber blöderweise kann ich ja im GRUB-Menü meine Tastatur nicht benutzen, und die Datei menu.lst, in der man das angeblich konfigurieren kann, hab ich auf meinem System nicht gefunden...

[Tintom]

..teste bitte einmal den Kernelparameter "libata.atapi_enabled=1"

Kernelparameter gibt man dem Bootloader (grub) mit.
Wen Grub startet einfach mal 'e' drücken, dann sollte sich ein Menü öffnen, in dem du die einzelnen Zeilen editieren kannst. Dort wählst Du die Zeile, die ungefähr so aussieht

Code: Alles auswählen

root=/dev/hda1 ro vga=791 resume=/dev/hda5

Das ist meine Zeile mit Kernelparametern, die Grub dem Kernel mitteilt. Die sieht bei dir geringfügig anders aus, erkennen kannst Du sie aber an dem 'root=/dev'-Eintrag. In diese Zeile hängst Du noch den Kernelparameter an, den gms vorgeschlagen hat.
Das sollte dann in etwa so aussehen

Code: Alles auswählen

root=/dev/hda1 ro vga=791 resume=/dev/hda5 libata.atapi_enabled=1

Anschließend mit 'Enter' bestätigen und der Kernel startet nur für dieses Mal mit der libata-Option. Willst du diese Option dauerhaft mitgeben, musst Du die Config-Datei von Grub editieren.

Gruß
Tino

[Sonic]

Hi!

wie gesagt, ich kann im GRUB-Menü meine Tastatur nicht benutzen, daher bringt mir das mit dem 'e' leider wenig. Ich hab jetzt mal etwas geforscht und den Parameter in die Datei /etc/grub.d/10_linux eingebaut und anschließend update-grub laufen lassen. Meine grub.cfg sieht jetzt folgendermaßen aus:

Code: Alles auswählen

### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
set root=(hd0,3)

font (hd0,3)/usr/share/grub/unifont.pff
set gfxmode=640x480
insmod gfxterm
insmod vbe
terminal gfxterm
defoptions=hda=noprobe hda=none
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###

### BEGIN /etc/grub.d/10_linux ###
menuentry "Debian GNU/Linux, linux 2.6.22-1-amd64" {
        linux   (hd0,3)/boot/vmlinuz-2.6.22-1-amd64 root=/dev/sda3 ro  libata.atapi_enabled=1
        initrd  (hd0,3)/boot/initrd.img-2.6.22-1-amd64
}
menuentry "Debian GNU/Linux, linux 2.6.22-1-amd64 (single-user mode)" {
        linux   (hd0,3)/boot/vmlinuz-2.6.22-1-amd64 root=/dev/sda3 ro single
        initrd  (hd0,3)/boot/initrd.img-2.6.22-1-amd64
}
### END /etc/grub.d/10_linux ###

Funktionieren tut es leider immer noch nicht. Nach einem Neustart finde ich immer noch /dev/hda und folgendes in dmesg:

Code: Alles auswählen

$ dmesg | grep atapi
Command line: BOOT_IMAGE=(hd0,3)/boot/vmlinuz-2.6.22-1-amd64 root=/dev/sda3 ro libata.atapi_enabled=1
Kernel command line: BOOT_IMAGE=(hd0,3)/boot/vmlinuz-2.6.22-1-amd64 root=/dev/sda3 ro libata.atapi_enabled=1
Unknown boot option `libata.atapi_enabled=1': ignoring

Schonmal danke für all Eure Tipps und sorry, dass ich immerzu nachhaken muss, aber irgendwie kommen Linux und ich im Moment nicht so ganz klar miteinander

[gms]

Code: Alles auswählen

$ dmesg | grep atapi
Command line: BOOT_IMAGE=(hd0,3)/boot/vmlinuz-2.6.22-1-amd64 root=/dev/sda3 ro libata.atapi_enabled=1
Kernel command line: BOOT_IMAGE=(hd0,3)/boot/vmlinuz-2.6.22-1-amd64 root=/dev/sda3 ro libata.atapi_enabled=1
Unknown boot option `libata.atapi_enabled=1': ignoring

war mein Fehler, ich habe nicht bedacht, daß du mit einer initrd bootest und libata daher erst nach der Überprüfung der Bootoptionen geladen wird.

Nachdem ich schon lange keine initrd's verwende habe und die initrd's mit dem 2.6er auf initramfs umgestellt wurden, habe ich die passenden Kommandos ergoggelt:

echo "libata atapi_enabled=1" >> /etc/initramfs-tools/modules
update-initramfs -u

achte bitte auf etwaige Fehlermeldungen! Laut deiner grub.cfg hast du die älteren Kernel deinstalliert, daher wenn die initrd aus irgendeinem Grund falsch erzeugt wird, hast du keinen Backupkernel, mit dem du noch booten könntest !

wenn ich die bisherigen Indizien richtig verstehe, dann ist vermutlich das DVD-Laufwerk das Problem. Wie ist das, kann man Linux irgendwie dazu bringen, dieses Gerät völlig zu ignorieren?

setzte vor dem "update-initramfs" auch noch dieses Kommandos ab:

Code: Alles auswählen

echo "ide_core ide0=noprobe ide1=noprobe hda=noprobe" >> /etc/initramfs-tools/modules

dein Bios ist übrigens buggy, daher wird das Bios (MMCONFIG) nicht für die PCI Konfiguration herangezogen:

ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at d0000000 is not E820-reserved
PCI: Not using MMCONFIG.

das könnten wir auch einmal versuchen:

ACPI: System BIOS is requesting _OSI(Linux)
ACPI: Please test with "acpi_osi=!Linux"
Please send dmidecode to linux-acpi@vger.kernel.org

Dein Bios fragt also nach dem laufenden Betriebssystem, momentan "antwortet" der Kernel mit "Linux", hier könnten wir einmal dem Bios ein anderes Betriebssystem vorgaukeln. Für Windows XP muß dafür "Windows 2001" und für Vista "Windows 2006" gesetzt werden, für Mac ist mir jedoch nichts bekannt, wir könnten aber auch den DSDT dekompilieren und einmal dort reingucken

Gruß
gms

[Sonic]

echo "libata atapi_enabled=1" >> /etc/initramfs-tools/modules
echo "ide_core ide0=noprobe ide1=noprobe hda=noprobe" >> /etc/initramfs-tools/modules
update-initramfs -u

Hab das jetzt mal ausgeführt (Fehlermeldungen gab es keine), ich glaube aber, dass das nach einem Reboot immer noch keine Wirkung hat:

Code: Alles auswählen

# cat /proc/ide/hda/driver
ide-cdrom version 4.61
# cat /proc/ide/hda/settings
name                    value           min             max             mode
----                    -----           ---             ---             ----
current_speed           66              0               70              rw
dsc_overlap             0               0               1               rw
init_speed              66              0               70              rw
io_32bit                0               0               3               rw
keepsettings            0               0               1               rw
nice1                   1               0               1               rw
number                  0               0               3               rw
pio_mode                write-only      0               255             w
unmaskirq               0               0               1               rw
using_dma               1               0               1               rw

# ls /dev/s*
/dev/sda   /dev/sda3  /dev/sdb   /dev/sdc1      /dev/sndstat  /dev/stdout
/dev/sda1  /dev/sda4  /dev/sdb1  /dev/sdc2      /dev/stderr
/dev/sda2  /dev/sda5  /dev/sdc   /dev/snapshot  /dev/stdin

/dev/shm:

/dev/snd:
controlC0  pcmC0D0c  pcmC0D0p  pcmC0D1c  pcmC0D1p  pcmC0D2c  timer

Laut deiner grub.cfg hast du die älteren Kernel deinstalliert, daher wenn die initrd aus irgendeinem Grund falsch erzeugt wird, hast du keinen Backupkernel, mit dem du noch booten könntest !

Naja, doch, die älteren Kernels sind schon noch vorhanden, ich habe sie nur jetzt beim Pasten aus Platzgründen rausgelöscht. Aber nutzen tut mir das ja trotzdem nichts: Ich kann ja im GRUB-Menü meine Tastatur nicht benutzen, von daher kann ich sie ohnehin nicht auswählen.

dein Bios ist übrigens buggy, daher wird das Bios (MMCONFIG) nicht für die PCI Konfiguration herangezogen:

Hm, ich dachte immer, die MacPros hätten gar kein BIOS, sondern stattessen EFI?

Dein Bios fragt also nach dem laufenden Betriebssystem, momentan "antwortet" der Kernel mit "Linux", hier könnten wir einmal dem Bios ein anderes Betriebssystem vorgaukeln. Für Windows XP muß dafür "Windows 2001" und für Vista "Windows 2006" gesetzt werden, für Mac ist mir jedoch nichts bekannt, wir könnten aber auch den DSDT dekompilieren und einmal dort reingucken

Klar, wenn das hilft können wir das gerne mal austesten. Ich hab aber keine Ahnung, wie das funktioniert, d.h. Copy-n-Paste-fähige Anweisungen wären super

[gms]

Hab das jetzt mal ausgeführt (Fehlermeldungen gab es keine), ich glaube aber, dass das nach einem Reboot immer noch keine Wirkung hat:

scheint so ( ich hasse initrd's ). Poste bitte nochmals die dmesg Ausgabe.

aja, doch, die älteren Kernels sind schon noch vorhanden, ich habe sie nur jetzt beim Pasten aus Platzgründen rausgelöscht. Aber nutzen tut mir das ja trotzdem nichts: Ich kann ja im GRUB-Menü meine Tastatur nicht benutzen, von daher kann ich sie ohnehin nicht auswählen.

grub läßt sich so einrichten, daß er beim nächsten Bootvorgang einen Fallback-Kernel bootet. Ich muß jetzt aber schon dringend weg, genaueres poste ich dir dazu morgen ( vielleicht kommst du aber auch selber drauf, oder jemand meldet sich dazu )

dein Bios ist übrigens buggy, daher wird das Bios (MMCONFIG) nicht für die PCI Konfiguration herangezogen:

Hm, ich dachte immer, die MacPros hätten gar kein BIOS, sondern stattessen EFI?

stimmt schon, aus sicht des Betriebssystems ( egal ob Linux oder Windows ) ist das aber auch nur ein BIOS, welches normale BIOS Funktionalität ( z.B. ACPI ) zur Verfügung stellt.

Dein Bios fragt also nach dem laufenden Betriebssystem, momentan "antwortet" der Kernel mit "Linux", hier könnten wir einmal dem Bios ein anderes Betriebssystem vorgaukeln. Für Windows XP muß dafür "Windows 2001" und für Vista "Windows 2006" gesetzt werden, für Mac ist mir jedoch nichts bekannt, wir könnten aber auch den DSDT dekompilieren und einmal dort reingucken

Klar, wenn das hilft können wir das gerne mal austesten. Ich hab aber keine Ahnung, wie das funktioniert, d.h. Copy-n-Paste-fähige Anweisungen wären super

die Wahrscheinlichkeit, daß das hilft schätze ich eher gering ein, aber versuchen kann man es ja

Gruß
gms

[Sonic]

Hi!

Habe den neuen dmesg-Output hochgeladen: http://nopaste.debianforum.de/6334


Ansonsten harre ich der Dinge, die da kommen und wünsche einen angenehmen Abend!

Sonic

[gms]

setzte bitte auch einmal die Bootoption "combined_mode=libata", schmeiß die "ide_core" Zeile wieder aus /etc/initramfs-tools/modules raus (die wahr anscheinend völlig falsch, das dürften "ide" Optionen sein) und erstelle eine neue initrd mit dem Kommando "update-initramfs -u".
Nachdem es bei meinem "initrd" Test auch nicht zum Erfolg geführt hat, obwohl ich dort noch zusätzliche Optionen ( wie z.B ide0=noprobe, hda=none), gleichzeitig an allen erdenklichen Stellen ( /etc/modprobe.d, /etc/initramfs/modules und /boot/grub/menu.lst ) gesetzt hatte, habe ich nicht viel Hoffnung, daß dieser Test bei dir funktioniert und das CD Laufwerk nicht mehr als "hda" angesprochen wird.

Als zweiten Test würde ich daher vorschlagen, daß wir mit einem Quick-and-dirty Test überprüfen, ob wir überhaupt am richtigen Weg sind. Dazu erstellen wir eine initrd ohne jeglichen IDE Support:

Code: Alles auswählen

echo "sr_mod" >>/etc/initramfs-tools/modules
echo "options libata atapi_enabled=1" >>/etc/modprobe.d/local
mkdir /lib/modules/2.6.22-1-amd64-tmp
mv  /lib/modules/2.6.22-1-amd64/kernel/drivers/ide /lib/modules/2.6.22-1-amd64-tmp/ 
depmod -a
update-initramfs -u

Wenn damit das "hda lost interrupt" Problem gelöst sein sollte, können wir entscheiden, wie wir die initrd vernünftiger anpassen und trotzdem sicherstellen, daß die ide-Treiber nicht in die initrd gelangen ( MODULES=dep in /etc/intiramfs-tools/initramfs.conf ist ein Versuch wert, ansonsten müßten wir eine Modulliste erstellen ).

Gruß
gms

[Sonic]

setzte bitte auch einmal die Bootoption "combined_mode=libata", schmeiß die "ide_core" Zeile wieder aus /etc/initramfs-tools/modules raus (die wahr anscheinend völlig falsch, das dürften "ide" Optionen sein) und erstelle eine neue initrd mit dem Kommando "update-initramfs -u".

Hab ich probiert und wie erwartet hat's nichts gebracht.

Als zweiten Test würde ich daher vorschlagen, daß wir mit einem Quick-and-dirty Test überprüfen, ob wir überhaupt am richtigen Weg sind. Dazu erstellen wir eine initrd ohne jeglichen IDE Support:

Hab ich jetzt ebenfalls gemacht und dadurch verschwindet auf jeden Fall schonmal /proc/ide, in dmesg taucht hda auch nicht mehr auf. Ein /dev/sr0 habe ich zwar immer noch nicht, aber so dringend brauche ich das DVD-Laufwerk im Moment auch nicht.

Ob es was gg. das lost interrupt-Problem nützt wird man sehen. Wie gesagt tritt das ja nur sporadisch auf, d.h. manchmal erst nach ein paar Stunden. Ich werd den Rechner jetzt einfach mal ne Weile laufen lassen und dann sehen, was passiert.

Bei der Gelegenheit noch ne andere Frage: Im dmesg-Output ist mir folgende Zeile aufgefallen:

Code: Alles auswählen

Please send dmidecode to linux-acpi@vger.kernel.org

Ist das die Geschichte, die Du mit "DSDT dekompilieren" meintest? Hilft das irgendwas, den an besagte Liste zu schicken? Ich meine, hey, wenn dadurch der MacPro-Support in künftigen Kernels potenziell besser würde, wäre das ja durchaus ne E-Mail wert

[gms]

Ein /dev/sr0 habe ich zwar immer noch nicht, aber so dringend brauche ich das DVD-Laufwerk im Moment auch nicht.

alternativ könnte auch ein "/dev/scd0" angelegt worden sein

Bei der Gelegenheit noch ne andere Frage: Im dmesg-Output ist mir folgende Zeile aufgefallen:

Code: Alles auswählen

Please send dmidecode to linux-acpi@vger.kernel.org

Ist das die Geschichte, die Du mit "DSDT dekompilieren" meintest? Hilft das irgendwas, den an besagte Liste zu schicken? Ich meine, hey, wenn dadurch der MacPro-Support in künftigen Kernels potenziell besser würde, wäre das ja durchaus ne E-Mail wert

Ich würde nicht zuviel Hoffnung darin setzen, aber schaden wird es auch nicht

Für das besagte "dmidecode" mußt du dir nur das gleichnamige Paket installieren und die Ausgabe an diese Liste posten. Allerdings wird diese "Bitte nach dem dmidecode" dadurch ausgelöst, daß das Bios nach dem laufenden Betriebssystem fragt und vorher wird auch noch eine Test vorgeschlagen:

Code: Alles auswählen

ACPI: System BIOS is requesting _OSI(Linux) 
ACPI: Please test with "acpi_osi=!Linux"
Please send dmidecode to linux-acpi@vger.kernel.org

Ich bin mir daher noch nicht sicher, welchen dmidecode die wollen ( vor diesem Test, nacher, oder vorher und nachher,sofern der überhaupt unterschiedlich ist ). Muß mich da auch erst schlau machen.

Den DSDT wollte ich dekompilieren, damit wir sehen, auf welchen anderen Wert wir "acpi_osi" setzen müßten, damit wir überhaupt einen Effekt erzielen können. Dazu mußt du nur das Paket "iasl" installieren und dann folgende Kommandos ausführen:

Code: Alles auswählen

cat /proc/acpi/dsdt > dsdt.aml 
iasl -d dsdt.aml > dsdt.asl

Die dsdt.asl Datei poste dann bitte auch auf NoPaste ( ist hoffentlich nicht zu groß dafür )

Gruß
gms

[gms]

zum DVD Laufwerk: schau bitte auch einmal mit dmesg oder /var/log/messages nach, ob das DVD Laufwerk überhaupt angesprochen wird ( nach DVD oder ATAPI suchen )
Sollte dann ungefähr so ausschauen:

Code: Alles auswählen

ataX.YY: ATAPI: SONY DVD RW DW-D150A, max UDMA/33

Wenn dieser Eintrag nicht existiert, kann es auch kein Device für dieses Laufwerk geben
Wenn du nachher noch nach CD_ROM suchst und etwas ähnliches wie hier findest:

Code: Alles auswählen

sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0

wäre das natürlich noch besser.

In der letzten dmesg-Ausgabe habe ich auch noch eine andere Fehlermeldung zu dem Interrupt-Problem gefunden, die ich der Vollständigkeit halber auch noch hier poste:

Code: Alles auswählen

hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request.
cdrom_pc_intr, write: dev hda: type=d, flags=1088
 sector 0, nr/cnr 0/0
bio 0000000000000000, biotail 0000000000000000, buffer 0000000000000000, data 0000000000000000, len 0
hda: cdrom_pc_intr: The drive appears confused (ireason = 0xd0). Trying to recover by ending request. 

[Sonic]

zum DVD Laufwerk: schau bitte auch einmal mit dmesg oder /var/log/messages nach, ob das DVD Laufwerk überhaupt angesprochen wird ( nach DVD oder ATAPI suchen )

Also in /var/log/messages hab ich folgendes gefunden:

Code: Alles auswählen

ACPI: SSDT 7D773000, 0892 (r1 SataRe  SataPri     1000 INTL 20050309)

bei dmesg gab grep -i atapi und grep -i dvd gar kein Ergebnis

Wenn dieser Eintrag nicht existiert, kann es auch kein Device für dieses Laufwerk geben
Wenn du nachher noch nach CD_ROM suchst und etwas ähnliches wie hier findest:

Da finde ich bei dmesg gar nichts und bei /var/log/messages nur alte Einträge, d.h. bevor das IDE-Subsystem deaktiviert wurde.

Die dsdt.asl Datei poste dann bitte auch auf NoPaste ( ist hoffentlich nicht zu groß dafür )

Hab ich probiert, ist aber leider zu groß (164 KB). Keine Ahnung, ob das das richtige ist, aber ich hab einfach mal nach OSI in der Datei gesucht und dabei folgendes gefunden:

Code: Alles auswählen

    Scope (\_SB)
    {
        Method (_INI, 0, NotSerialized)
        {
            If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Darwin"))
                {
                    Store (0x2710, OSYS)
                    Store ("OS is Darwin, OSYS ==", Debug)
                    Store (OSYS, Debug)
                }
                Else
                {
                    If (_OSI ("Linux"))
                    {
                        Store ("OS is Linux", Debug)
                        Store (0x03E8, OSYS)
                    }
                    Else
                    {
                        Store ("OS is Defaulting to 2001", Debug)
                        Store (0x07D1, OSYS)
                    }
                }
            }
            Else
            {
                Store ("OS is Defaulting to NT 5.0 support", Debug)
                Store (0x07D0, OSYS)
            }

            Store (0x35, SMIF)
            Store (0x00, TRP0)
        }

Das mit dem dmidecode hab ich jetzt erstmal sein lassen, klingt ja dann doch eher wirr

Die Sache mit dem "drive appears to be confused" hatte ich übrigens auf diesem Rechner schon immer, deshalb hat auch lange Zeit das Installieren von einer Debian-CD nicht geklappt: Er hat immer gebootet und dann behauptet, er findet die Installations-CD nicht, nach irgedeinem Kernel-Update (von 2.6.17 auf .18 glaube ich) ging es dann aber...

[gms]

Keine Ahnung, ob das das richtige ist, aber ich hab einfach mal nach OSI in der Datei gesucht

ja, das ist genau die Stelle welche ich gesucht habe. Wir könnten also den Linux Kernel überreden, sich als "Darwin" oder "OTHER" zu melden. Vermutlich muß dazu nur der Kernel-Parameter "acpi_os_name" gesetzt werden:

acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS
Format: To spoof as Windows 98: ="Microsoft Windows"

Kannst du schon eine Aussage zur Stabilität der Maus treffen ?
Möchtest du den Debian-Standardkernel mit der initrd unbedingt behalten, oder bist du bereit dir einen eigenen Kernel zu bauen ?

Habe hier http://gentoo-wiki.com/HOWTO_Dual_boot_ ... acBook_Pro
nämlich einen Verweis auf einen Kernelpatch für den Mac Pro gefunden.
Dazu müßtest du aber einen eigenen Kernel bauen.

Gruß
gms

[Sonic]

ja, das ist genau die Stelle welche ich gesucht habe. Wir könnten also den Linux Kernel überreden, sich als "Darwin" oder "OTHER" zu melden

OK, kann man machen. Und nur nochmal für Doofe: Was genau könnte das bewirken?

Kannst du schon eine Aussage zur Stabilität der Maus treffen ?

Also bis jetzt siehts sehr gut aus. Ich hatte den Rechner gestern und heute mehrere Stunden an und keinerlei Schwierigkeiten. sieht also ganz danach aus als hätten wir das ursprüngliche Problem gelöst

Möchtest du den Debian-Standardkernel mit der initrd unbedingt behalten, oder bist du bereit dir einen eigenen Kernel zu bauen ?

Naja, meine Priorität ist vor allem ein möglichst geringer Wartungsaufwand. Wenn mir das beim nächsten aptitude upgrade nicht um die Ohren fliegt können wir gerne einen selfmade-Kernel bauen (wobei ich da nochmal auf das Grub-Problem hinweisen möchte: failsafe-Versionen dürften komplizierter werden)

Habe hier http://gentoo-wiki.com/HOWTO_Dual_boot_ ... acBook_Pro
nämlich einen Verweis auf einen Kernelpatch für den Mac Pro gefunden.
Dazu müßtest du aber einen eigenen Kernel bauen.

Ja, diese mactel-Seite hab ich auch gefunden, aber wenn ich da ins SVN reinschaue (http://mactel-linux.svn.sourceforge.net ... es-2.6.22/) sehe ich eigentlich nichts, was auf meinen Rechner eine Auswirkung hat. Sigmatel Audio, appletouch und IR habe ich ja nicht, das sind glaube ich eher so Laptop-Sachen. Aber probieren könnte mans natürlich trotzdem...


Ciao, und schonmal danke!

Sonic