Which kernel do you want me to try this with? I have tried two
different kernels with two different errors. (Both have been sent at
different times in the past couple days.) The registers listed here
from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT,
MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for
invariants), but the text segment was correct.
Without debug, I get the trap 9. With debug, I get a trap 12
immediately followed by a panic with mutex shced lock recursion.
I rebuilt the kernel with out the debugging and check the state of
things. The code is correct and the esi register had the expected
value.
Jim Bloom
[EMAIL PROTECTED]
P.S. I am hitting the same problem Robert Watson mentioned. I don't
have room for three kernels on the machine.
John Baldwin wrote:
>
> On 06-Feb-01 Jim Bloom wrote:
> > Here are the registers (subject to typing errors):
> >
> > cs 0xc2fb0008
> > ds 0xa000010
> > es 0x10
> > fs 0x18
> > ss 0x10
> > eax 0x12
> > ecx 0x20
> > edx 0xc00b8f00
> > ebx 0x2
> > esp 0xc2fbee1c
> > ebp 0xc2fbee28
> > esi 0x100
> > edi 0xc0290990 __set_sysctl_set_sym_sysctl__kern_fscale+0x4
> > eip 0xc0266fcc Debugger+44
> > efl 0x56
> >
> > Jim Bloom
> > [EMAIL PROTECTED]
>
> Erm, this doesn't look good:
>
> movl $GPROC0_SEL*8, %esi /* GSEL(entry, SEL_KPL) */
> ltr %si
>
> #define GPROC0_SEL 4 /* Task state process slot zero and up */
>
> Thus, %esi should be 32 == 0x20, not 0x100. :( I have no clue why that is
> screwed up, unless something is overwriting your code segment. Can you panic
> it and do an x/i of sw1b+0x72? It should look something like this:
>
> 121: be 20 00 00 00 mov $0x20,%esi
> 126: 0f 00 de ltr %si
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
