Oops - woher?

[Florian Schwarz]

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.

>>>> neutron kernel: Oops: 0000 [#1]
>>>> neutron kernel: SMP
>>>> neutron kernel: CPU:    0
>>>> neutron kernel: EIP is at xfs_fs_clear_inode+0x6a/0xa2 [xfs]
>>>> neutron kernel: eax: efe7f230   ebx: efe7e21c   ecx: 00000000   edx: 00000000
>>>> neutron kernel: esi: efe7e200   edi: 014be880   ebp: c1a69f24   esp: c1a69ef0
>>>> neutron kernel: Process kswapd0 (pid: 143, ti=c1a68000 task=c19d1ab0 task.ti=c1a68000)
>>>> neutron kernel:        00000000 00000080 0000002c c016dede 00000080 efe7e3a4 ce4f06a4 000092e0
>>>> neutron kernel:        c18deac0 00000081 000000d0 c014761f 0024b800 00000000 0024b800 000330f5
>>>> neutron kernel: Call Trace:
>>>> neutron kernel: Code: 3c 85 80 31 31 c0 8d 04 3a ff 80 00 01 00 00 8b 41 10 03 14 85 80 31 31 c0 ff 8a ec 00 00 00 8b 46 10 85 c0 74 08 8b 48 08 31 d2 <ff> 51 5c 8d 43 f8 e8 44 52 94 c7 83 63 e4 f7 c6 43 f8 01 8b 46
>>>> neutron kernel: EIP: [pg0+945495906/1070019584] xfs_fs_clear_inode+0x6a/0xa2 [xfs] SS:ESP 0068:c1a69ef0
>>>> neutron kernel: Stack: efe7e21c efe7e360 00000000 c016da24 efe7e224 efe7e21c c016dccf ece6139c
>>> 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.

Zur Hardware: AMD Sempron 2800 auf VIA K8T800, 1 GB Speicher, 4 IDE
Platten, sonst nix besonderes eigentlich.

>> Oct 26 16:08:32 neutron kernel: f893cf62
>> Oct 26 16:08:32 neutron kernel: Modules linked in: aes nfsd exportfs lockd nfs_acl sunrpc ipv6 capi capifs parport_pc parport floppy pcspkr
>> 8139too 8139cp mii uhci_hcd shpchp pci_hotplug amd64_agp agpgart dm_snapshot dm_mirror blowfish sha256 dm_crypt dm_mod sata_promise sg sata_
>> via libata snd_via82xx gameport snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_r
>> awmidi snd_seq_device snd soundcore it87 hwmon_vid eeprom i2c_isa i2c_viapro i2c_core capidrv kernelcapi nls_utf8 nls_iso8859_15 nls_cp850 s
>> d_mod usb_storage scsi_mod ehci_hcd usbcore hisax crc_ccitt isdn slhc ide_generic ide_cd cdrom genrtc xfs ide_disk generic via82cxxx ide_cor
>> e evdev
>> Oct 26 16:08:32 neutron kernel: EIP:    0060:[pg0+945495906/1070019584]    Not tainted VLI
>> Oct 26 16:08:32 neutron kernel: EFLAGS: 00010246   (2.6.18-1-k7 #1)
>> Oct 26 16:08:32 neutron kernel:  [clear_inode+171/216] clear_inode+0xab/0xd8
>> Oct 26 16:08:32 neutron kernel:  [dispose_list+70/194] dispose_list+0x46/0xc2
>> Oct 26 16:08:32 neutron kernel:  [shrink_icache_memory+403/443] shrink_icache_memory+0x193/0x1bb
>> Oct 26 16:08:32 neutron kernel:  [shrink_slab+211/316] shrink_slab+0xd3/0x13c
>> Oct 26 16:08:32 neutron kernel:  [kswapd+693/928] kswapd+0x2b5/0x3a0
>> Oct 26 16:08:32 neutron kernel:  [autoremove_wake_function+0/45] autoremove_wake_function+0x0/0x2d
>> Oct 26 16:08:32 neutron kernel:  [kswapd+0/928] kswapd+0x0/0x3a0
>> Oct 26 16:08:32 neutron kernel:  [kthread+194/239] kthread+0xc2/0xef
>> Oct 26 16:08:32 neutron kernel:  [kthread+0/239] kthread+0x0/0xef
>> Oct 26 16:08:32 neutron kernel:  [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb
>>
> 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?

Gruß,
Floh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20061026/b597b062/attachment.sig>