Re: sym0: CACHE INCORRECTLY CONFIGURED
Gruesse!
* Jochen Heller <linux@nordviertel.net> schrieb am [18.04.05 21:13]:
> Ich habe eine Sym53CXXX-Scsi-Karte in meinem Rechner an der ein
> HPScanJet IIcx hängt. Bisher klappte es (bis auf vorübergehende
> Aussetzer, bei denen ich jetzt nicht weiß, ob ich sie neu bewerten
> muss) immer tadellos zu scannen. Nun habe ich ein paar Wochen nicht
> gescannt und wollte es heute wieder tun, da erstaunt mich doch, dass
> xsane nicht den Scanner im Device-Dialog auflistet. Sane-find-scanner
> findet erwartungsgemäß dann auch nichts. Beim erneuten Hochfahren
> bemerkte ich, dass er den Scanner nicht erkennt und in
> der /var/log/messages entdecke ich folgendes:
>
> | Jan 28 21:48:25 localhost kernel: SCSI subsystem initialized
> | Jan 28 21:48:25 localhost kernel: ACPI: PCI interrupt 0000:00:0b.0[A]
> | -> GSI 17 (level, low) -> IRQ 169
> | Jan 28 21:48:25 localhost kernel: sym0: <810> rev 0x1 at pci
> | 0000:00:0b.0 irq 169
> | Jan 28 21:48:25 localhost kernel: sym0: No NVRAM, ID 7, Fast-10, SE,
> | parity checking
> | Jan 28 21:48:25 localhost kernel: CACHE TEST FAILED: reg dstat-sstat2
> | readback ffffffff.
> | Jan 28 21:48:25 localhost kernel: sym0: CACHE INCORRECTLY CONFIGURED.
> | Jan 28 21:48:25 localhost kernel: sym0: giving up ...
>
> Wenn ich das Modul entlade und neu starte erhalte ich noch eine Meldung,
> es läge ein "PCI parity error" vor. Durch googlen stieß ich im
> Linux-Kernel-Archiv zu genau dieser Frage auf die ermutigende Antwort:
> 'I think your card is toast".
Evtl. kam ja ein Kernel-Update in der Zwischenzeit oder du hast sonst
etwas hardware-seitig verändert. Es ist durchaus möglich das dadurch
einfach ein IRQ/IO-Konflikt vorliegt.
Du könntest mal nachschauen, ob ein
cat /proc/interrupts
zum einen die scsi-Karte anzeigt, ob diese sich Interrupts teilen muß
und ob du in der unteren Splate bei ERR: einen Wert größer 0 hast.
Ich würde testweise nochmal diverse Kernel-Parameter am lilo/grub Prompt
ausprobieren, und zwar jeweils einzel und auch in Kombination:
acpi=off
acpi=noirq
noapic
nolapic
pci=bios
pci=biosirq
Diese Kernel-Parameter sind vom 2.4.x Kernel, mir steht z.Zt. keine Doku
zum 2.6er zur Verfügung. Diese sollten aber weiterhin gültig sein, evtl.
noch mal unter $kernel_doku/kernel-parameters.txt nachschlagen.
Sinn des ganzen wäre, eine Umorganisierung der IRQ/IO-Verteilung zu
erzwingen, um Konflikte bei eben jener zu vermeiden. Bei jedem Boot mit
geänderter Kernel-Parameters würde ich die syslog beobachten, Scanner
suchen lassen und die /proc/interrupts kontrollieren.
Ansonsten hast du evtl. die Möglichkeiten:
a) Im SCSI-Bios alles auf default zu stellen
b) Explizit im SCSI-Bios die Parity-Prüfung abzustellen, ist IMHO für
Scanner nicht relevant.
c) Die Karte mal in einem anderen PCI-Slot versuchen.
> Schöne Grüße
>
> Jochen.
Gruß Gerhard
--
It's nice to be important...
but it's more important to be nice.
Reply to: