Created attachment 518622 [details] kernel trace Description of problem: Several seconds after mounting cifs, kernel halts. Version-Release number of selected component (if applicable): kernel 3.0.1 kernel 3.0.2 How reproducible: Steps to Reproduce: 1. mount cifs, access the cifs vfs 2. wait 3. Actual results: kernel panic Expected results: Additional info: attached please find some trace info.
Created attachment 518623 [details] A longer trace
Well, that's very odd -- it fell down inside of __kmalloc. Could you follow the directions here and post the listing of where it crashed? http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses ...also, what slab allocator are you using in this kernel? Something like this on the kernel config in the build directory should tell you: $ egrep 'CONFIG_SL.?B' /path/to/.config CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_SLABINFO=y # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set
the slab config is: CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y CONFIG_SLABINFO=y # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set don't have the time to run the gdb test right now. i'll post the result later. thanks.
F16 is moving to 3.1-rc now. While Jeff is looking, you might try the latest F16 kernel build from koji and see if it recreates.
Thanks, I'll set the needinfo flag. Let me know when you have the gdb listing...
(In reply to comment #4) > F16 is moving to 3.1-rc now. While Jeff is looking, you might try the latest > F16 kernel build from koji and see if it recreates. I tried 3.1-rc2 and the panic is still there.
here is all the gdb lists. (gdb) l *(__kmalloc+0x97) 0xffffffff810b21cf is in __kmalloc (mm/slub.c:1947). 1942 static void flush_cpu_slab(void *d) 1943 { 1944 struct kmem_cache *s = d; 1945 1946 __flush_cpu_slab(s, smp_processor_id()); 1947 } 1948 1949 static void flush_all(struct kmem_cache *s) 1950 { 1951 on_each_cpu(flush_cpu_slab, s, 1); (gdb) l *(kmem_cache_alloc+0x5f) 0xffffffff810b1cbf is in kmem_cache_alloc (mm/slub.c:1947). 1942 static void flush_cpu_slab(void *d) 1943 { 1944 struct kmem_cache *s = d; 1945 1946 __flush_cpu_slab(s, smp_processor_id()); 1947 } 1948 1949 static void flush_all(struct kmem_cache *s) 1950 { 1951 on_each_cpu(flush_cpu_slab, s, 1); ========= thanks
here is the gdb list. (gdb) l *(__kmalloc+0x97) 0xffffffff810b21cf is in __kmalloc (mm/slub.c:1947). 1942 static void flush_cpu_slab(void *d) 1943 { 1944 struct kmem_cache *s = d; 1945 1946 __flush_cpu_slab(s, smp_processor_id()); 1947 } 1948 1949 static void flush_all(struct kmem_cache *s) 1950 { 1951 on_each_cpu(flush_cpu_slab, s, 1); (gdb) l *(kmem_cache_alloc+0x5f) 0xffffffff810b1cbf is in kmem_cache_alloc (mm/slub.c:1947). 1942 static void flush_cpu_slab(void *d) 1943 { 1944 struct kmem_cache *s = d; 1945 1946 __flush_cpu_slab(s, smp_processor_id()); 1947 } 1948 1949 static void flush_all(struct kmem_cache *s) 1950 { 1951 on_each_cpu(flush_cpu_slab, s, 1); ========= thanks
After changing the slab allocator to CONFIG_SLAB, the kernel oops inside another code piece. (gdb) l *(__free_pages+0x1) 0xffffffff8108be68 is in __free_pages (/usr/src/linux/arch/x86/include/asm/atomic.h:25). 20 * 21 * Atomically reads the value of @v. 22 */ 23 static inline int atomic_read(const atomic_t *v) 24 { 25 return (*(volatile int *)&(v)->counter); 26 } 27 28 /** 29 * atomic_set - set atomic variable
Do you have /sbin/mount.cifs installed? If not then this patch may help: http://marc.info/?l=linux-cifs&m=131345112022031&w=2 ...could you test it and let me know if it does?
I just tried this patch and it fixed the problem so far for me (no instant crash) but will follow up if there are further problems. Justin.
(In reply to comment #10) > Do you have /sbin/mount.cifs installed? If not then this patch may help: > > http://marc.info/?l=linux-cifs&m=131345112022031&w=2 > > ...could you test it and let me know if it does? Patch applied, so far so good. Nice, thanks very much.
Could you also test with the kernel here and let me know if it also works? https://koji.fedoraproject.org/koji/taskinfo?taskID=3298071
(In reply to comment #13) > Could you also test with the kernel here and let me know if it also works? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=3298071 yes it works.
*** This bug has been marked as a duplicate of bug 727927 ***