Re: 2.6.22-rc1-mm1: boot failure under qemu

[H. Peter Anvin]

Jeremy Fitzhardinge wrote:
> rax 000000004050ffff rbx 0000000000009000 rcx 0000000000000000 rdx 0000000000007b00
> rsi 000000000001fc05 rdi 0000000000040000 rsp 0000000000008f9a rbp 0000000000008100
> r8  0000000000000000 r9  0000000000000000 r10 0000000000000000 r11 0000000000000000
> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000
> rip 0000000000001062 rflags 00033046
> cs 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> ds 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> es 8100 (00081000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> ss 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> fs 9900 (00099000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
> gs 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)

> 
>         else
>                 while (num != 0)
>                         tmp[i++] = digits[do_div(num, base)];
>     1050:       66 89 f0                mov    %esi,%eax
>     1053:       66 31 d2                xor    %edx,%edx
>     1056:       66 f7 f5                div    %ebp
>     1059:       66 89 c6                mov    %eax,%esi
>     105c:       67 66 8b 44 24 28       addr32 mov 0x28(%esp),%eax
>     1062:       67 8a 14 10             addr32 mov (%eax,%edx,1),%dl
>     1066:       67 66 8b 44 24 2c       addr32 mov 0x2c(%esp),%eax
>     106c:       67 88 54 04 3e          addr32 mov %dl,0x3e(%esp,%eax,1)
> 
> 
> 0x1062 is in number (/home/jeremy/hg/xen/paravirt/linux/arch/i386/boot/printf.c:109).
> 104             i = 0;
> 105             if (num == 0)
> 106                     tmp[i++] = '0';
> 107             else
> 108                     while (num != 0)
> 109                             tmp[i++] = digits[do_div(num, base)];
> 110             if (i > precision)
> 111                     precision = i;
> 112             size -= precision;
> 113             if (!(type & (ZEROPAD + LEFT)))
> 
> 
> I haven't tried booting on real hardware, but this is a definite
> regression from the old setup code.
> 

Hmmm...

There are a number of highly odd things about your dump, in particular,
%es == 0x8100 at this point, which means the constraint %cs == %ds ==
%es == %ss has been violated in this code; this should only happen
locally inside an assembly routine or asm() statement.  Another bizarre
thing is that %ebp, which apparently is supposed to contain the base at
this point, is *also* set to 0x8100.

Finally, the total zincher is the flags -- VM RF IOPL=3.  In real mode.
 That's nuttier than Dick Cheney.

I have been using Qemu (as well as Bochs) to develop and test the code,
so obviously it Works For Me[TM].  Please describe the entry conditions
in more detail; in particular, what did you use to load the kernel?

Also, could you send me your .config and simulation image?

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/