Re: [lkcd-devel] (no subject)

[Castor Fu <ca...@3p...>]

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.