Linux за българи: Форуми

Apr  6 03:10:53 ssdo@tu-sofia BUG: unable to handle kernel paging request at virtual address fff7ffff
Apr  6 03:10:53 ssdo@tu-sofia printing eip:
Apr  6 03:10:53 ssdo@tu-sofia c01bd683
Apr  6 03:10:53 ssdo@tu-sofia *pde = 00003067
Apr  6 03:10:53 ssdo@tu-sofia *pte = 00000000
Apr  6 03:10:53 ssdo@tu-sofia Oops: 0002 [#1]
Apr  6 03:10:53 ssdo@tu-sofia SMP
Apr  6 03:10:53 ssdo@tu-sofia Modules linked in: shpchp pci_hotplug generic
Apr  6 03:10:53 ssdo@tu-sofia CPU:    0
Apr  6 03:10:53 ssdo@tu-sofia EIP:    0060:[<c01bd683>]    Not tainted VLI
Apr  6 03:10:53 ssdo@tu-sofia EFLAGS: 00010286   (2.6.19-gentoo-r5 #1)
Apr  6 03:10:53 ssdo@tu-sofia EIP is at ext3_clear_inode+0x1f/0x7e
Apr  6 03:10:53 ssdo@tu-sofia eax: c5a1b668   ebx: c5a1b5d0   ecx: c13a8720   edx: fff7ffff
Apr  6 03:10:53 ssdo@tu-sofia esi: c5a1b668   edi: 00000000   ebp: 0000004f   esp: c135bec4
Apr  6 03:10:53 ssdo@tu-sofia ds: 007b   es: 007b   ss: 0068
Apr  6 03:10:53 ssdo@tu-sofia Process kswapd0 (pid: 139, ti=c135a000 task=c13b6070 task.ti=c135a000)
Apr  6 03:10:53 ssdo@tu-sofia Stack: c5a1b668 c5a1b794 c135befc c0163ba1 c135befc c5a1b670 c5a1b668 c0163e2a
Apr  6 03:10:53 ssdo@tu-sofia c2ffaaa0 00000000 00000080 00000080 c0164035 00000080 c5a1b84c c5450318
Apr  6 03:10:53 ssdo@tu-sofia 0000a028 c12feac0 00000085 000000d0 c0140483 c013db62 c0525d80 00006127
Apr  6 03:10:53 ssdo@tu-sofia Call Trace:
Apr  6 03:10:53 ssdo@tu-sofia [<c0163ba1>] clear_inode+0x87/0xd5
Apr  6 03:10:53 ssdo@tu-sofia [<c0163e2a>] dispose_list+0x48/0xc3
Apr  6 03:10:53 ssdo@tu-sofia [<c0164035>] shrink_icache_memory+0x190/0x1b8
Apr  6 03:10:53 ssdo@tu-sofia [<c0140483>] shrink_slab+0xd9/0x142
Apr  6 03:10:53 ssdo@tu-sofia [<c0140844>] kswapd+0x2c1/0x3a4
Apr  6 03:10:53 ssdo@tu-sofia [<c012b314>] kthread+0xc0/0xec
Apr  6 03:10:53 ssdo@tu-sofia [<c01041c7>] kernel_thread_helper+0x7/0x10
Apr  6 03:10:53 ssdo@tu-sofia =======================
Apr  6 03:10:53 ssdo@tu-sofia Code: ff ff a1 44 89 73 c0 e9 b5 2b f9 ff 57 56 89 c6 53 8d 98 68 ff ff ff 8b 53 6c 8b 7b 54 85 d2 74 21 83 fa ff 74 1c 85 d2 74 11 90 <ff> 0a 0f 94 c0 84 c0 74 07 89 d0 e8 21 2b f9 ff c7 43 6c ff ff
Apr  6 03:10:53 ssdo@tu-sofia EIP: [<c01bd683>] ext3_clear_inode+0x1f/0x7e SS:ESP 0068:c135bec4

?????
Някой знае ли какво е това и как да го оправя
Машината е Gentoo с последния Kernel - linux-2.6.19-gentoo-r5

махни USB поддръжката ако не се използжа активно.
Blaklist на модулите:
 * usbcore
 * ehci_hcd

най-вероятно само със зачерняне на ehci_hcd ще стане.

zeridon,

Много ми е интересно как позна, че проблема е в USB поддръжката? Ядрото е гръмнало в кода на ext3 fs докато се е опитвало да намали броя на кешираните inodes. Какво общо има това с USB?

upsss

явно съм блял някъде. Днеска цял ден гоня мизерии с USB та може би за това, а и до някъде ме е подвело pci_hotplug-a

да имаш случайно пуснат nfsd ?

Проблемът не е в USB подсистемата.

Цитат

Ядрото е гръмнало в кода на ext3 fs докато се е опитвало да намали броя на кешираните inodes

И това не е точно така. kswapd е kernel thread, който се "събужда", когато има нужда да се освобождават memory pages, когато ядрото реши, че има вариант и да не успее да обслужи malloc()-овете на некой userspacе процес (иначе се "събужда" и периодично през някакъв интервал, доколкото знам). В такъв случай, или се swapin-ва на диска някакъв pagecache (т.е  заделена памет от някоя програма), който отдавна не е достъпван, или се "изхвърля" някаква vfs кеширана информация (в случая ext3 inode cache, но спокойно можеше и да е xfs или reiserfs такава например). Това може да се контролира през procfs, затова след малко.

Функцията ext3_clear_inode(), честно казано нямам идея каква работа върши, но се вижда, че е функцията, която прави проблема, а по веригата се разбира, че това се случва точно при "изхвърлянето на кешове" от страна на kswapd. Затова и ще проверя в kernel source-a:

Цитат

root@debian:/usr/src/linux-2.6.15# grep -r ext3_clear_inode * ... fs/ext3/super.c:static void ext3_clear_inode(struct inode *inode)

и там:

Цитат

static void ext3_clear_inode(struct inode *inode) {         struct ext3_block_alloc_info *rsv = EXT3_I(inode)->i_block_alloc_info; #ifdef CONFIG_EXT3_FS_POSIX_ACL        if (EXT3_I(inode)->i_acl &&            EXT3_I(inode)->i_acl != EXT3_ACL_NOT_CACHED) {                posix_acl_release(EXT3_I(inode)->i_acl);                EXT3_I(inode)->i_acl = EXT3_ACL_NOT_CACHED;        }        if (EXT3_I(inode)->i_default_acl &&            EXT3_I(inode)->i_default_acl != EXT3_ACL_NOT_CACHED) {                posix_acl_release(EXT3_I(inode)->i_default_acl);                EXT3_I(inode)->i_default_acl = EXT3_ACL_NOT_CACHED;        } #endif         ext3_discard_reservation(inode);         EXT3_I(inode)->i_block_alloc_info = NULL;         kfree(rsv); }

POSIX ACL глупостите ги изключвам, поради причини, които излизат извън темата. Проблемът не е и в ext3_discard_reservation(), както и в "зануляването" по-надолу, оттам следва, че вероятно се вика kfree() за нещо, което сочи наникъде ( ).  Това "нещо" е

Цитат

struct ext3_block_alloc_info *rsv = EXT3_I(inode)->i_block_alloc_info;

..което вече ме отмързя да гледам откъде се взема, главно защото проблемът не е точно мой

Имам много "силно" предположение, че поради някакъв бъг в това ядро или поради физически проблем с РАМ-та, некой е успял да маже глупости в паметта, точно там където се намират slab-овете за ext3_inode_cache, това доколкото знам е  свързан списък с указатели към някакви данни, просто указателите са замазани със стойности, които сочат към некви идиотски адреси.

Изводът е: или смени ядрото, или виж дали РАМ-та е наред. Евентуално, възможно е чрез procfs tunnable, /proc/sys/vm/vfs_cache_pressure, набивайки му стойност 0 (echo 0> /proc/sys/vm/vfs_cache_pressure) да кажеш на ядрото да не "изхвърля" vfs cache, което е малко лекомислено и тъпо, но за теста става. В общи линии това е.

gateway,

>> Ядрото е гръмнало в кода на ext3 fs докато се е опитвало да намали
>> броя на кешираните inodes
> И това не е точно така.

Точно така си е, и твоя анализ го потвърждава

Оф, аз не съм прочел като хората

gateway,

Мерси за отговора  
за ядрото съм 99% че си е наред (в офиса 40 човека сме с него )
така че ще проверя РАМ-та ако не е от нея ще го мислим ....