2008/3/11, Zdenek Kabelac <[EMAIL PROTECTED]>: > 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.
Argh - being stupid here - it looks like these 'working' kernels were not SMP actually. As long as the SMP is used - I still get the busy loop :( Now being clueless.... Zdenek ------------------------------------------------------------------------- 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
