I'm seeing my mipsel kernel hang during nfs writes where the size is
over 30K bytes. I'd like to debug this, trouble is when I use kgdb to
step into sys_write, I eventually step down into "atomic_add()," which
is in atomic.h. When I try to step through or over this function, gdb
goes into the weeds, never to return, and there's no reviving the
target system.
Here is my backtrace, right before gdb goes into the weeds:
(gdb) bt
#0 rpc_init_task (task=0x81855d30, clnt=0x803e3ba0, callback=0, flags=0)
at /linux/include/asm/atomic.h:133
#1 0x802c8ff0 in rpc_call_sync (clnt=0x803e3ba0, msg=0x81855df0, flags=0) at clnt.c:259
#2 0x8018eb04 in nfs_proc_getattr (inode=0x8185c960, fattr=0x81855e28)
at /linux/include/linux/sunrpc/clnt.h:129
#3 0x8018aae4 in __nfs_revalidate_inode (server=0x2, inode=0x8185c960) at inode.c:934
#4 0x801886f4 in nfs_file_write (file=0x81de27c0, buf=0x100000c8 "", count=65536, ppos=0x81de27e0)
at /linux/include/linux/nfs_fs.h:284
#5 0x80145f04 in sys_write (fd=3, buf=0x100000c8 "", count=65536) at read_write.c:208
(gdb) s
The code in atomic_add() is:
extern __inline__ void atomic_add(int i, atomic_t * v)
{
unsigned long temp;
__asm__ __volatile__(
"1: ll %0, %1 # atomic_add\n"
" addu %0, %2 \n"
" sc %0, %1 \n"
" beqz %0, 1b \n"
: "=&r" (temp), "=m" (v->counter)
: "Ir" (i), "m" (v->counter));
}
Is it the fact that this is __asm__ confusing gdb? Or is it a problem
with inline? Both? Neither?
Any suggestions?
Thanks,
Dave
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
