On Tue, 2001-10-02 at 03:29, Mihai RUSU wrote: > > well cum era faza aia ?? itworksforme :)
:-P > si 2.4.9 nu a zis nimic in afara ca imi umple logurile cu sending pkt too > big to self (de la driverul de eepro100 din kernel) Uite unu' care vede probleme pe 2.4.9 fara XFS: We've been seeing some corruption with 2.4.9 without XFS. The last one I looked closely at we have a thread that has just allocated an inode, alloc_inode, which gets it from the inode_cachep kmem_cache_t. The inode is within a certain page that is full of characters that were written by syslog to /var/log/messages. I chased the inode_cachep slab_t structures and there is one next pointer that points to the start of a page (the next page after the one the inode is in). This is wrong as these pointers are offset from the start of a page. I followed all the prev pointers and all the slab_t's are correct and I can see where the bad next pointer is. For this problem, many fields in the inode are OK but the dentry list is bad. Oopsed in d_instantiate. We have had a few scatterred oopses for a few releases (2.4.7, 2.4.8, and now 2.4.9). This is the first one I really chased down in detail to see that it looked like something went wrong in the inode_cachep. I'm wondering if there isn't a bug somewhere in the way the slabs are freed (if all elements are no longer available) racing with a corresnding allocate. Or, maybe someone freed an inode twice or ... Anyway, just chimming in that we are seeing memory corruption on 2.4.9, too. -- Florin Andrei "In theory, under the new computer security law, anyone whose computer was infected by Nimda/CodeRed could be imprisoned for life -- the new law says nothing about intent. So, basically we would have a few million Microsoft Windows users serving life sentences..." - Dan Hollis --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
