2008/3/9, Zdenek Kabelac <[EMAIL PROTECTED]>: > 2008/3/7, Zdenek Kabelac <[EMAIL PROTECTED]>: > > > 2008/3/5, Zdenek Kabelac <[EMAIL PROTECTED]>: > > > > > 2008/3/5, Avi Kivity <[EMAIL PROTECTED]>: > > > > > > > Andi Kleen wrote: > > > > > Avi Kivity <[EMAIL PROTECTED]> writes: > > > > > > > > > >> Most likely movs emulation is broken for long counts. Please > post a > > > > >> disassembly of copy_user_generic_string to make sure we're > looking at > > > > >> the same code. > > > > >> > > > > > > > > > > Be careful -- this code is patched at runtime and what you > > > > > see in the vmlinux is not necessarily the same that is executed > > > > > > > > > > > > > > > > > > > > > > If the disassembled instruction isn't marked as an alternative in the > > > > source, then it can't be patched, right? > > > > > > > > > > Hello > > > > Any progress on this - It looks like I get this bug quite often when I > test > > device-mapper code. > > > > > > Hello > > I've made some more experiments and noticed few more things: > > a) - it is just enough to run parallel loop with cat LVM partition > >/dev/null and dmsetup status > > b) when I insert for() loop for zeroing allocated memory in the > dm-ioctl copy_params function my loop start once the memory crosses > exactly 4KB boundary (visible from register content) > > c) in my trace log I could usually always see this pattern: > [ 160.634897] [<ffffffff812ee5ba>] preempt_schedule_irq+0x5a/0xa0 > [ 160.634897] [<ffffffff8100cf46>] retint_kernel+0x26/0x30 > > from the look in the arch/x86/kernel/entry64.s I could really see > there is some potentiality for internal loop that may call > preempt_schedule_irq in upon some check in exit_intr - but having > actually now idea what's this all about... > > I've put there just some extra dump_stack trace in the > preempt_schedule_irq - and it's really being printed - but quite > slowly actually considering process eats 100% CPU > > So anyone has any idea what might be wrong ?
Hello I've some more news here - it looks I've found working setup on my C2D. All I need to do is compile my 64bit kernel with optimization for space. This will magical start to work - at least in this case. I'll now probably slowly try to figure out which directory with -Os compilation makes the difference. Also I've noticed that standard Debian 2.6.24-4-686 kernel loops in Qemu, but 486 version doesn't. So if anyone starts to get idea what could be wrong... ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
