From: Castor Fu <ca...@3p...> - 2002-05-15 01:39:26
|
I needed to fix some stuff in 'lcrash' and noticed the following in dump_i386.c: static inline void fix_ssesp(struct pt_regs *regs, int cpu) { if (!user_mode(regs)) { if ((cpu == dump_header_asm.dha_dumping_cpu) && < regs->xss == __KERNEL_DS) > (0xffff & regs->xss) == __KERNEL_DS) return; dump_header_asm.dha_smp_regs[cpu].esp = (unsigned long)&(regs->esp); __asm__ __volatile__ ("movw %%ss, %%ax;" :"=a"(dump_header_asm.dha_smp_regs[cpu].xss)); } } The register save inline that we use (haven't looked to see if it's standard) leaves garbage in the high bits of regs->xss. This seems to give me better traces in 'lcrash' than I used to get. . . Should I go ahead and commit this? I haven't tried using my shiny sourceforge decoder ring yet. What are the review/commit processes? -castor -- |
From: Deepak K. G. N. <dk...@no...> - 2002-05-27 07:35:52
|
Hello List I am interested in contributing in LKCD project. Please let me know if anybody has any task in TODO list.. At present i m reviewing the source code of LKCD and lcrash and testing it on I386 platform.. FYI i have experience in Linux kernel hacking and system programming.. Looking for precious suggesions Thanks Deepak. |
From: Dhruv P. A. <dhr...@wi...> - 2003-09-09 11:59:36
|
Hi, I have linux-2.5.44 with lkcd patch installed with the following entries in=20 the config file ************************************************** # CONFIG_SMP is not set CONFIG_PREEMPT=3Dy =20 # Kernel hacking # CONFIG_SOFTWARE_SUSPEND is not set CONFIG_CRASH_DUMP=3Dy CONFIG_CRASH_DUMP_BLOCKDEV=3Dy # CONFIG_CRASH_DUMP_COMPRESS_RLE is not set CONFIG_CRASH_DUMP_COMPRESS_GZIP=3Dy *************************************************** On crashing from a non-interrupt context (i.e calling panic explictly),dump=20 hangs. However, dump is successful when i comment the CONFIG_PREEMPT option. Is this already reported for a premptive linux kernel? In which case is there a patch existing for this. Or am i missing something? Please suggest and guide. Regards, Dhruv |
From: Luc C. <luc...@ya...> - 2013-01-06 21:06:31
|
http://as9.pl/wp-content/themes/twentyten/ndold.php?yrbg=yrbg |
From: Bharata B R. <bh...@in...> - 2002-05-15 04:43:00
|
On Tue, May 14, 2002 at 06:39:20PM -0700, Castor Fu wrote: > I needed to fix some stuff in 'lcrash' and noticed the following > in dump_i386.c: > > static inline void > fix_ssesp(struct pt_regs *regs, int cpu) > { > if (!user_mode(regs)) { > if ((cpu == dump_header_asm.dha_dumping_cpu) && > < regs->xss == __KERNEL_DS) > > (0xffff & regs->xss) == __KERNEL_DS) > return; > dump_header_asm.dha_smp_regs[cpu].esp = > (unsigned long)&(regs->esp); > __asm__ __volatile__ ("movw %%ss, %%ax;" > :"=a"(dump_header_asm.dha_smp_regs[cpu].xss)); > } > } > > The register save inline that we use (haven't looked to see if it's standard) > leaves garbage in the high bits of regs->xss. > Looks like this is the correct thing to do. We need to clear out the higher order bits. > This seems to give me better traces in 'lcrash' than I used to get. . . > Though this looks like an obvious bug, I have never hit this. Would be interesting to know in which case you observed 'better' traces - panic dump (panic from inside the kernel or from module ? ) or non-disruptive dump or dump due to kernel fault ? > Should I go ahead and commit this? I haven't tried using my shiny > sourceforge decoder ring yet. What are the review/commit processes? > Yes, I think this should be fixed. Regards, Bharata. |
From: Castor Fu <ca...@3p...> - 2002-05-15 06:31:45
|
On Wed, 15 May 2002, Bharata B Rao wrote: > On Tue, May 14, 2002 at 06:39:20PM -0700, Castor Fu wrote: > > I needed to fix some stuff in 'lcrash' and noticed the following > > in dump_i386.c: > > > > static inline void > > fix_ssesp(struct pt_regs *regs, int cpu) > > { > > if (!user_mode(regs)) { > > if ((cpu == dump_header_asm.dha_dumping_cpu) && > > < regs->xss == __KERNEL_DS) > > > (0xffff & regs->xss) == __KERNEL_DS) > > return; > > dump_header_asm.dha_smp_regs[cpu].esp = > > (unsigned long)&(regs->esp); > > __asm__ __volatile__ ("movw %%ss, %%ax;" > > :"=a"(dump_header_asm.dha_smp_regs[cpu].xss)); > > } > > } > Looks like this is the correct thing to do. We need to clear out the higher > order bits. > > > This seems to give me better traces in 'lcrash' than I used to get. . . > > > Though this looks like an obvious bug, I have never hit this. Would be > interesting to know in which case you observed 'better' traces - panic dump > (panic from inside the kernel or from module ? ) or non-disruptive dump or > dump due to kernel fault ? They are panic dumps from inside the kernel. Our panic path is somewhat different but not at the beginning. Perhaps the path that we use leaves just the right things on the stack? > > Should I go ahead and commit this? I haven't tried using my shiny > > sourceforge decoder ring yet. What are the review/commit processes? > > > Yes, I think this should be fixed. OK, I went ahead and put it back. |