search for: do_idl

Hi, pxelinux(2.08 or later) waits forever after "boot:" prompt on vmware (4.52). pxelinux(2.07) works. After I comment out DO_IDLE in ui.inc (2.08 or later), it works. but I'm not sure why... (vmware bug?) Thanks, Kaz --- ui.inc.orig Wed Aug 4 00:58:38 2004 +++ ui.inc Wed Aug 4 01:07:39 2004 @@ -60,7 +60,7 @@ cmp dx,ax ; Has the timer advanced? je tick_loop...

...] handle_fasteoi_irq+0xc0/0x198 [ 162.485417] generic_handle_irq+0x24/0x38 [ 162.490334] __handle_domain_irq+0x84/0xf0 [ 162.493834] gic_handle_irq+0x58/0xa8 [ 162.498464] el1_irq+0xb4/0x130 [ 162.500621] arch_cpu_idle+0x18/0x28 [ 162.504729] default_idle_call+0x1c/0x34 [ 162.508005] do_idle+0x17c/0x1f0 [ 162.510184] cpu_startup_entry+0x20/0x28 [ 162.515050] rest_init+0x250/0x260 [ 162.518228] start_kernel+0x3f0/0x41c [ 162.522987] BUG: sleeping function called from invalid context at mm/mempool.c:320 [ 162.533762] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0...

...] handle_fasteoi_irq+0xc0/0x198 [ 162.485417] generic_handle_irq+0x24/0x38 [ 162.490334] __handle_domain_irq+0x84/0xf0 [ 162.493834] gic_handle_irq+0x58/0xa8 [ 162.498464] el1_irq+0xb4/0x130 [ 162.500621] arch_cpu_idle+0x18/0x28 [ 162.504729] default_idle_call+0x1c/0x34 [ 162.508005] do_idle+0x17c/0x1f0 [ 162.510184] cpu_startup_entry+0x20/0x28 [ 162.515050] rest_init+0x250/0x260 [ 162.518228] start_kernel+0x3f0/0x41c [ 162.522987] BUG: sleeping function called from invalid context at mm/mempool.c:320 [ 162.533762] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0...

Hi all, I am wondering about the following suggested change: In isolinux.asm, line 50 (at least in my Debian patched version), add the line "hlt" inside the "DO_IDLE" macro. Explanation: When running isolinux on a vmware box, the boot menu takes up all available CPU. This change seems to solve this problem. I have read elsewhere that such a change will not go in, as the system is set up to perform polling. From looking at the keyboard code, I see no r...

...t; [ 162.485417] generic_handle_irq+0x24/0x38 > [ 162.490334] __handle_domain_irq+0x84/0xf0 > [ 162.493834] gic_handle_irq+0x58/0xa8 > [ 162.498464] el1_irq+0xb4/0x130 > [ 162.500621] arch_cpu_idle+0x18/0x28 > [ 162.504729] default_idle_call+0x1c/0x34 > [ 162.508005] do_idle+0x17c/0x1f0 > [ 162.510184] cpu_startup_entry+0x20/0x28 > [ 162.515050] rest_init+0x250/0x260 > [ 162.518228] start_kernel+0x3f0/0x41c > [ 162.522987] BUG: sleeping function called from invalid context at mm/mempool.c:320 > [ 162.533762] in_atomic(): 1, irqs_disabled(): 128,...

...tch_current(); > > > > > > > > I suggest to use the following intead: > > > > > > > > if (unlikely(klp_patch_pending(current))) > > > > klp_update_patch_state(current); > > > > > > > > We already use this in do_idle(). The reason is basically the same. > > > > It is almost impossible to livepatch the idle task when a CPU is > > > > very idle. > > > > > > > > klp_update_patch_state(current) does not check the stack. > > > > It switches the task immed...

...0180000000 000000000000000c 000001bf6f331c58 ffffffffffffffff 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000001 000000007ff70200 0000000000a8b2f0 00000000001034f6 000003e000317e00 #0 [3e000317e28] arch_cpu_idle at 103842 #1 [3e000317e48] do_idle at 17ad18 #2 [3e000317e80] cpu_startup_entry at 17af16 #3 [3e000317ea8] arch_call_rest_init at eac934 > > Wei Wang (2): > virtio_pci: use queue idx instead of array idx to set up the vq > virtio: don't allocate vqs when names[i] = NULL > > drivers/misc/mic/vop/vop_...

...dn't make it, but I simply haven't had time :( :( :( However, given several bugs fixed in 3.08, this seemed important... Changes in 3.08: * SYSLINUX: Fix performance regression (-s mode always enabled.) * Add API function for idle loop. * libutil: Add do_idle() function for idle loop, make get_key() use it. * libutil: Add SHA-1 and base64 functions. * Simple menu system: add password support. * EXTLINUX: Sparse files now handled correctly. * EXTLINUX: Large directories now handled correctly. * ALL...

...uidle cpu_idle_poll(void) } /* Weak implementations for optional arch specific functions */ +void __weak arch_cpu_idle_poll(void) { } void __weak arch_cpu_idle_prepare(void) { } void __weak arch_cpu_idle_enter(void) { } void __weak arch_cpu_idle_exit(void) { } @@ -219,6 +220,7 @@ static void do_idle(void) */ __current_set_polling(); + arch_cpu_idle_poll(); quiet_vmstat(); tick_nohz_idle_enter(); -- 1.7.1

...arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] > default_idle+0xc7/0x450 arch/x86/kernel/process.c:500 > arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491 > default_idle_call+0x6d/0x90 kernel/sched/idle.c:93 > cpuidle_idle_call kernel/sched/idle.c:153 [inline] > do_idle+0x3aa/0x570 kernel/sched/idle.c:262 > cpu_startup_entry+0x10c/0x120 kernel/sched/idle.c:368 > rest_init+0xe1/0xe4 init/main.c:442 > start_kernel+0x90e/0x949 init/main.c:738 > x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452 > x86_64_start_kernel+0x76/0x79 arch/x...

Tim Legge has passed the following message on to me: hpa wrote: > Quinn wrote: > > Now it seems I have found a bug in PXELINUX with regards to etherboot. > > Up until 2.07 pxelinux was responsive to the keyboard. From 2.08 and > > up the keyboard is locked at the boot prompt when pxelinux is loaded > > via etherboot 5.3.14. > > That would not be a PXELINUX bug,

...1a10500 R14: 0000000000000000 R15: 0000000000000000 Apr 02 14:20:59 helium kernel: </IRQ> Apr 02 14:20:59 helium kernel: default_idle+0x20/0x110 Apr 02 14:20:59 helium kernel: arch_cpu_idle+0xf/0x20 Apr 02 14:20:59 helium kernel: default_idle_call+0x23/0x30 Apr 02 14:20:59 helium kernel: do_idle+0x16f/0x200 Apr 02 14:20:59 helium kernel: cpu_startup_entry+0x71/0x80 Apr 02 14:20:59 helium kernel: rest_init+0x84/0x90 Apr 02 14:20:59 helium kernel: start_kernel+0x44d/0x46e Apr 02 14:20:59 helium kernel: ? early_idt_handler_array+0x120/0x120 Apr 02 14:20:59 helium kernel: x86_64_start_re...

...0 </IRQ> ? set_cpu_sd_state_idle+0x145/0x230 (kernel/sched/fair.c:8557) cpuidle_enter+0x17/0x20 (drivers/cpuidle/cpuidle.c:282) call_cpuidle+0x47/0xc0 (kernel/sched/idle.c:103) ? cpuidle_select+0x59/0x80 (drivers/cpuidle/cpuidle.c:266) ? rcu_idle_enter+0x7e/0xa0 (kernel/rcu/tree.c:749) do_idle+0x22c/0x2e0 (kernel/sched/idle.c:209) cpu_startup_entry+0x1d/0x20 (kernel/sched/idle.c:326) start_secondary+0x298/0x360 (arch/x86/kernel/smpboot.c:224) ? set_cpu_sibling_map+0x1a40/0x1a40 (arch/x86/kernel/smpboot.c:525) start_cpu+0x14/0x14 (arch/x86/kernel/head_64.S:301) Object at ffff880739ec...

...c_timer_interrupt+0x64/0xa0 [18830.392746] nouveau_gem_object_open+0x109/0x130 [nouveau] [18830.400421] apic_timer_interrupt+0xf/0x20 [18830.404788] drm_gem_handle_create_tail+0xd3/0x160 [18830.411969] </IRQ> [18830.419146] ? nouveau_gem_new+0x120/0x120 [nouveau] [18830.424088] RIP: 0010:do_idle+0x15a/0x1c0 [18830.431277] nouveau_gem_ioctl_new+0x83/0xd0 [nouveau] [18830.431282] drm_ioctl_kernel+0x6b/0xd0 [18830.438630] RSP: 0018:ffffc90000ccbf20 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff12 [18830.442389] drm_ioctl+0x301/0x3a0 [18830.449643] RAX: 0000000000000000 RBX: 0000000000000001 RC...

From: Yang Zhang <yang.zhang.wz at gmail.com> Some latency-intensive workload have seen obviously performance drop when running inside VM. The main reason is that the overhead is amplified when running inside VM. The most cost I have seen is inside idle path. This patch introduces a new mechanism to poll for a while before entering idle state. If schedule is needed during poll, then we

From: Yang Zhang <yang.zhang.wz at gmail.com> Some latency-intensive workload have seen obviously performance drop when running inside VM. The main reason is that the overhead is amplified when running inside VM. The most cost I have seen is inside idle path. This patch introduces a new mechanism to poll for a while before entering idle state. If schedule is needed during poll, then we

Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. Wei Wang (2): virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL

Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. Wei Wang (2): virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL

From: Matt Fleming <matt.fleming at intel.com> The following patch series is available at, git://git.zytor.com/users/mfleming/syslinux.git elflink All patches are against the 'elflink' branch. This series fixes a few serious bugs and some behavioural incompatibilities with the 4.x series. Matt Fleming (19): ldlinux: Initialise 'p' before using it. ldlinux: Parse

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and