Oops - woher?

[Jan 'RedBully' Seiffert]

Florian Schwarz wrote:
> Jan 'RedBully' Seiffert schrieb:
>> Florian Schwarz wrote:
>>> Jan-Benedict Glaw schrieb:
>>>> On Thu, 2006-10-26 19:21:44 +0200, Florian Schwarz <floh at linland.de> wrote:
>>>>> Das ganze ist nen Debian mit orig. Debian Kernel 2.6.18-1-k7.
>> v--Hier ist nichts drueber?
> 
> Also auf meiner SSH Konsole habe ich mehr nicht entdeckt.
> 
Na dann von mir aus in den logs ;)
Da oben ist die Zeile, warum ihm das ueberhaupt nicht schmeckt, sowas
wie NULL-Pointer, Illigal Instruction (er ist ins Nirvana gesprungen),
oder use of unmaped Object (der Pointer Zeigte irgendwo hin, aber nicht
auf allozierten Speicher)

[snip: top of oops]
>>>> Mehr kommt nicht?  Eigentlich sollte er noch den Stack abrollen und
>>>> dabei dekodieren, sodaß ksymoops überflüssig ist. Zudem hat's hier
>>>> keinerlei sinnvollen Output erzeugt.
>>> Das war das, was mir der syslogd auf die SSH Konsole gekotzt hat. Auf
>>> der "richtigen" Konsole stand noch mehr, aber ich weiß nicht wie ich das
>>> ordentlich logge. In der messages habe ich noch was gefunden, hängt ma
>>> wieder als Datei an. Obs taugt - keine Ahnung!
> 
>> Wenn du die Moeglichkeit hast (besonders wenn der Bug wiederkommend
>> ist), versuch doch mal im Kernel ein paar debug optionen anzumachen.
> 
> Da müsste ich bei Gelegenheit mal nen neuen Kernel bauen.
> 
>> Interressant waere noch, welche Kernelversion, tritt das Problem mit
>> aelteren Kerneln nicht auf, was ist der (halbswegs) genaue weg, das
>> nachzubauen. Achso, kannst du noch was zu deiner Hardware sagen?
> 
> Das Problem tritt bei der aktuell von mir eingesetzten Kernelversion auf
> (Debian Kernel 2.6.18-1-k7) als auch bei älteren Debian Kerneln.
> Soweit ich das sehe tritt das vor allem bei nen bissl I/O Load auf
> irgend na Platte auf. Aber das ist auch rein subjektiv.
> 
Irgendwas klingelt da, es hatten mehrere Leute in letzter Zeit probleme
mit Systemen die unter I/O-Last "wegklappen".
Schon mal einen der 19rc-er ausprobiert?

> Zur Hardware: AMD Sempron 2800 auf VIA K8T800, 1 GB Speicher, 4 IDE
> Platten, sonst nix besonderes eigentlich.
> 
Alle am Onboard Controller? SATA? RAID MD/LVM? Server/Desktop?
Netzwerktraffic dazu? 1 oder 2 Ramriegel, mal mit nur einem Probiert?
In der 18ner Serie ist glaub ich der VIA-Quirk manchmal "broken", nagut,
vorher war er es in den genau gegenteiligen faellen....

[snip: tail of oops]
>> Es hat heut mittag jemand einen recht aehnlichen Stacktrace auf lkml
>> geposted (seiner ist ein wenig weiter gekommen: dispose_list ->
>> xfs_fs_destroy_inode -> kmem_cache_free -> cache_flusharray ->
>> xfs_finish_reclaim -> free_block BOOM ), ungluecklicher weise hatte er
>> anscheinend ein binary-only Modul geladen.
>> Da scheint was im Busch zu sein. Die Linux Matroschka schlaegt wieder zu...
>>
>> Hmmm, auch wenns bremst, vielleicht hilft DEBUG_SLAB, mir kommt das so
>> vor, als haette da was ne verkette Liste zerstoert. (oder der Stack ist
>> am Ende)
> 
> DEBUG_SLAB?
> 
Kernel hacking -> Kernel debugging -> Debug slab memory allocations

Unteranderem: Wenn Speicher im Kernel freigegeben wird, wird er sofort
mit einem Bitmuster ueberschrieben. Falls nun da jemand noch
reinschreibt (stale pointer), wir das erkannt.

Schau dich einfach da mal unter "Kernel hacking" ein bischen um. Du
kannst ja den Fehler "einfach" herbei fuehren.
Damits nicht so weh tut, alles was geht vorher ro mounten ;)

> Gruß,
> Floh
> 
Gruss
	Jan

-- 
public enum BOOL
{
  TRUE,
  FALSE,
  NOT_TRUE_OR_FALSE
}