On 30 July 2010 22:10, Jason Wessel <jason.wessel@xxxxxxxxxxxxx> wrote: > On 07/28/2010 08:30 PM, Pedro Ribeiro wrote: >> Hi all, >> >> I hit a bug when resuming with TuxOnIce. At the middle of a resume, it >> says Compress Read -22 and locks up. I caught the stack trace with kdb >> and took photos of that. >> I'm running 2.6.35-rc6 on a Lenovo T400. I have an encrypted LUKS >> partition (aes-cbc-essiv-128) which contains an LVM2 with my root, >> swap and home partitions inside. >> >> It seems that kcryptd caused the trouble. I've had other lockups with >> TuxOnIce that relate to kcryptd too, but I never caught them with kdb, >> >> After printing the stack trace I decided to see the output of the ps >> command. As I was scrolling the processes shown, kdb oops'ed and >> called itself. I also took photos of that kdb's own stack trace. I >> then tried the ps command again, but this time the stack trace was >> looping every few seconds (I took another photo of that). After a >> while it just panicked and kept calling itself on a loop. I rebooted >> and was able to successfully resume the TuxOnIce image. >> >> The stack trace means little to me, but might be helpful to you. >> >> The photos are: >> kcryptd_oops [1,2,3] - TuxOnIce compress read -22 error >> kdb_oops [1,2,3,4] - KDB oopses when scrolling output of kdb ps command >> > > You don't happen to have the vmlinux file around which corresponded to > that crashed kernel do you? > > If so, can you run: > > addr2line -f -e vmlinux 0xffffffff81030512 > addr2line -f -e vmlinux 0xffffffff810ad1d0 > addr2line -f -e vmlinux 0xffffffff810add3c > > And send me the output? > > I have a pretty good idea about what the problem is but it would be > interesting to know the exact failure point if the vmlinux file will > tell us. In a nut shell, the "ps" command in kdb does not use > probe_kernel_address() to safely read memory in all instances. > Presently the ps function assumes that if the task struct was ok the > rest of memory accesses in this region would be ok as well. > Not sure if this is what you want... addr2line -f -e vmlinux 0xffffffff81030512: task_curr ??:0 addr2line -f -e vmlinux 0xffffffff810ad1d0 kdb_ps1 ??:0 addr2line -f -e vmlinux 0xffffffff810add3c kdb_task_state_char ??:0 > > >> kdb_blows_up - final stack trace being shown in a cycle before PANIC: >> > Once kdb oopses the system is pretty much toast. There are some limited > things you can do at that point like at least get a stack trace so the > original problem can be found. > > Jason. > Can you tell me how to do that? So that when it happens next time I have the chance to take a photo... Regards, Pedro _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
