PCI Soundkarte wird von Alsa nicht mehr erkannt [solved]

[Jan Seiffert]

Stefan U. Hegner schrieb:
> Moin Jan,
> 
> Am 03.05.2012 21:03, schrieb Jan Seiffert:
>> *murmel murmel*
>> acpi=off ist heutzutage keine Lösung.

Und wenn ich mir dein dmesg an gucke ist es das wirklich nicht für den Hobel.

>>
>> hast du mal
>> pci=nocrs
>> ausprobiert?
>>
>> PS: ich dachte das du das dmesg mal rausrückst...
>>
>>   
> ... habe endlich mal meine Kiste neu gebootet ;-).
> 
> Habe die Bootline mal geändert auf "pci=nocrs" aber leider ohne den
> gewünschten Erfolg. Die SB X-Fi wird in /proc/asound/cards und
> /proc/asound/modules nicht mehr angelistet.
> 

Kein wunder, aus dem dmesg:
PCI: Unknown option `nocrs'

> Anbei auch den gewünschten dmesg. - Vielleicht hast Du ja noch eine
> schlaue Idee?

[   15.530519] cannot find the slot for index 0 (range 0-1), error: -16
[   15.530526] SB-XFi: probe of 0000:03:03.0 failed with error -16

Dein Soundkartenproblem hat nichts, aber auch garnichts mit ACPI zu tun.
-16 ist -EBUSY. Man beachte die Zeile über der Zeile die mit SB-XFI beginnt.

Der XFi Treiber, in ./sound/pci/ctxfi/xfi.c::ct_card_probe()@60 macht als erstes,
bevor er _überhaupt mit der HW spricht_, ein:
err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);

Das kommt in ./sound/core/init.c::snd_card_create()@148 raus, und das erzeugt die
Zeile über der des Treibers:
	if (idx < 0)
		err = -ENODEV;
	else if (idx < snd_ecards_limit) {
		if (snd_cards_lock & (1 << idx))
			err = -EBUSY;	/* invalid */
	} else if (idx >= SNDRV_CARDS)
		err = -ENODEV;
	if (err < 0) {
		mutex_unlock(&snd_card_mutex);
		snd_printk(KERN_ERR "cannot find the slot for index %d (range 0-%i), error: %d\n",
			 idx, snd_ecards_limit - 1, err);
		goto __error;
	}

Er scheint mit ACPI mehr Soundkarten/sie in anderer Reihenfolge zu finden.
Ich tippe du hast irgendwo fest einen index für die XFi vergeben
(irgendwo in /etc/mod...), oder irgendwie was anderes an ALSA conf fun.

Reparier das (z.B. _wirklich allen_ Karten einen Index geben), dann klappts auch
mit dem Nachbarn^wACPI.

Und überhaupt. Was hast du in der Kiste alles drin?
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000 mask F80000000 write-back
[    0.000000]   1 base 080000000 mask FC0000000 write-back
[    0.000000]   2 base 0C0000000 mask FF0000000 write-back
[    0.000000]   3 base 0D0000000 mask FF8000000 write-back
[    0.000000]   4 base 100000000 mask F00000000 write-back
[    0.000000]   5 base 200000000 mask FE0000000 write-back
[    0.000000]   6 base 220000000 mask FF8000000 write-back
[    0.000000]   7 base 0D7F00000 mask FFFF00000 uncachable

Gibts für die Hütte ein BIOS-Update? Sonst probier mal mtrr-cleanup, dann geht vielleicht
das:
[   15.344778] mtrr: no more MTRRs available
beim Init deiner Graka weg...

[    0.673783] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported

Really? BIOS-Update? Neuer Kernel?

[  908.746464] ata1.01: failed command: IDENTIFY DEVICE

Kontrollier mal die Verkabelung deiner PATA Festplatte (einmal abziehen und neu anstecken).
Gibts für das Ding ein Firmware-update?
Könnte auch der SmartD sein. Es gibt Platten die mögen es nicht besonders
zwei Herren zu dienen, z.B. OS und SmartD, also letzteren mal von der Platte fernhalten.

> 
> Bevor ich auf squeeze gegangen bin hatte ich lange Jahre einen
> custom-kernel gebaut. Bin eigentlich ganz froh, dass jetzt der
> Debian-Kernel auf dieser HW tut - eben bis auf diese "Macke". Habe daher
> wenig Lust, einen eigenen Kernel zu basteln um möglicherweise so das
> "acpi=off" zu umgehen.
> 

*kopfschüttel*

> Sonnige Grüße
> 
> Stefan.
> 
> 

Gruss
	Jan

-- 
> I've never waited forever.
Your lack of dedication is disappointing.