search for: softirq

Hi, Keir, Thanks for checking in cpu online/offline support. Another thought inspired by Kevin, due to the time sequence that different cpus enter the stop machine context, there is a small window that some kind of softirqs (say softirq_A) are issued to the dying cpu right after the dying cpu has already handled softirq_A in do_softirq before entering stop_machine softirq. So this softirq_A should be handled by the dying cpu after exiting from stop_machine context. However, scheduling to idle leaves no change for sof...

In "Understanding the Linux Kernel" 3rd edition, section 4.7 "Softirqs and Tasklets" it states: "Activation and execution [of defferable functions] are bound together: a deferrable function that has been activated by a given CPU must be executed on the same CPU. There is no self-evident reason suggesting that this rule is beneficial for system performance...

...ntroller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) 06:02.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) The mainboard is with Intel 5000 series chipset Asus board. When I use 2.6.9 kernel with the same location and traffic I have had no softirq usage. Also in 2.4 Centos 3 machine I have had no softirq usage. With the same location and traffic I have softirq usage %25: Cpu0 : 2.0%us, 2.0%sy, 0.0%ni, 71.3%id, 0.0%wa, 2.7%hi, 22.0%si, 0.0%st Cpu1 : 1.0%us, 1.3%sy, 0.0%ni, 79.7%id, 0.0%wa, 1.3%hi, 16.6%si, 0.0%st I have no extra...

...h 2.6 dom0 and 2.4 domU on a P4 HT 3.2Ghz. Perhaps this helps to track the problem down. Greetings, Martin ---------- The messages : (dom0 hostname is zen, domU hostname is ftp, directory is /xen/mount/ftp) Output from umount: Jun 2 12:13:16 zen kernel: Badness in local_bh_enable at kernel/softirq.c:140 Jun 2 12:13:16 zen kernel: [local_bh_enable+130/144] local_bh_enable+0x82/0x90 Jun 2 12:13:16 zen kernel: [skb_checksum+317/704] skb_checksum+0x13d/0x2c0 Jun 2 12:13:16 zen kernel: [udp_poll+154/352] udp_poll+0x9a/0x160 Jun 2 12:13:16 zen kernel: [sock_poll+41/64] sock_poll+0x29/0x40...

...many interrupts and one of the cpus is overloaded. Example: i have 4 cpus and i have configured irqbalance= off, so there is no irqbalancing done by xen. Now if i have affintized all my physical interrutps to one cpu say cpu1 all the interrutps shpuld be handled by the cpu1 and so should all the softirqs generated. Now what happens if one of the other cpus is lightly loaded, will some of the softirqs be queued against the other cpus or will cpu1 handle all interrupts and softirqs. Looks to me like there are two levels of interrupt redirection, one done by the hardware where each physical device i...

...//www.ussg.iu.edu/hypermail/linux/kernel/0503.1/1622.html http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/1621.html Not sure if it is xen or linux-iscsi related bug. Any ideas how to cure it will be very appreciated. -- Jul 6 15:20:32 iscsi-test1 kernel: Badness in local_bh_enable at kernel/softirq.c:140 Jul 6 15:20:32 iscsi-test1 kernel: [<c01205a4>] local_bh_enable+0x68/0x83 Jul 6 15:20:32 iscsi-test1 kernel: [<c8973742>] iscsi_queuecommand+0x173/0x1e3 [iscsi_sfnet] Jul 6 15:20:32 iscsi-test1 kernel: [<c02c9e7f>] scsi_dispatch_cmd+0x149/0x264 Jul 6 15:20:32 iscsi-t...

...out, on a 32 bit kernel that uses a seqcount. sequence counts are "lock" constructs where you need to make sure that writers are serialized. In turn, this means that we mustn't run two try_fill_recv concurrently. Which of course we don't. We do run try_fill_recv sometimes from a softirq napi context, and sometimes from a fully preemptible context, but the later always runs with napi disabled. However, when it comes to the seqcount, lockdep is trying to enforce the rule that the same lock isn't accessed from preemptible and softirq context - it doesn't know about napi bein...

Add self pause ability, which is required by vcpu0/dom0 when running on a AP. This can''t be satisfied by existing interface, since the new flag also serves as a sync point. Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r d5315422dbc8 xen/common/domain.c --- a/xen/common/domain.c Mon May 14 18:35:31 2007 -0400 +++ b/xen/common/domain.c Mon May 14 20:21:04 2007 -0400 @@

...sequence counts are "lock" constructs where you need to make sure that writers are serialized. In turn, this means that we mustn't run two try_fill_recv concurrently. Which of course we don't. We do run try_fill_recv sometimes from a fully preemptible context and sometimes from a softirq (napi) context. However, when it comes to the seqcount, lockdep is trying to enforce the rule that the same lock isn't accessed from preemptible and softirq context. This causes a false-positive warning: WARNING: inconsistent lock state ... inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usa...

__napi_schedule might raise softirq but nothing causes do_softirq to trigger, so it does not in fact run. As a result, the error message "NOHZ: local_softirq_pending 08" sometimes occurs during boot of a KVM guest when the network service is started and we are oom: ... Bringing up loopback interface: [ OK ] Bringi...

__napi_schedule might raise softirq but nothing causes do_softirq to trigger, so it does not in fact run. As a result, the error message "NOHZ: local_softirq_pending 08" sometimes occurs during boot of a KVM guest when the network service is started and we are oom: ... Bringing up loopback interface: [ OK ] Bringi...

...ff -r 1539f5a2b3ba xen/arch/x86/acpi/power.c --- a/xen/arch/x86/acpi/power.c Tue Jun 26 18:05:22 2007 -0400 +++ b/xen/arch/x86/acpi/power.c Tue Jun 26 19:44:36 2007 -0400 @@ -25,6 +25,7 @@ #include <xen/sched.h> #include <xen/domain.h> #include <xen/console.h> +#include <xen/softirq.h> u8 sleep_states[ACPI_S_STATE_COUNT]; DEFINE_SPINLOCK(pm_lock); @@ -80,37 +81,77 @@ static void device_power_up(void) console_resume(); } -/* Main interface to do xen specific suspend/resume */ -int enter_state(u32 state) -{ - struct domain *d, *pd = NULL; - unsigned long fla...

...raid5 xor multipath linear ide_generic r8169 uhci_hcd ehci_hcd usbcore thermal processor fan raid0 raid1 md_mod sata_via sd_mod libata scsi_mod via82cxxx ide_core ext3 jbd mbcache EIP: 0060:[<f0872d73>] Not tainted VLI EFLAGS: 00210246 (2.6.17-2-k7 #1) BUG: warning at kernel/softirq.c:141/local_bh_enable() <b0120e27> local_bh_enable+0x25/0x64 <b0218215> lock_sock+0x85/0x8d <b021604b> sock_fasync+0x5c/0x111 <b0216fa1> sock_close+0x1e/0x2a <b0153fcd> __fput+0x87/0x13c <b0151b57> filp_close+0x4e/0x54 <b011e0a1> put_files_st...

...dy discussed here [1], dealing with IOMMU faults in interrupt context may cause nasty things to happen, up to being used as a form of DoS attack, e.g., by generating a "storm" of IOMMU faults that will livelock a pCPU. To avoid this, IOMMU faults handling is being moved from interrupt to softirq context. Basically, the inerrupt handler of the IRQ originated by an IOMMU (page) fault will raise a softirq-tasklet which will then deal with the actual fault records by clearing the logs and re-enabling interrupts from the offending IOMMU(s). A single tasklet is being used even if there are more...

...er has done it's job there's about 15MB of RAM free and swap is hardly used at all (1MB at most) I've increased RAM to 64MB and the OOM killer doesn't kick in.. but I am seeing plenty of such messages in the logs ... Dec 2 16:05:21 noc kernel: Badness in local_bh_enable at kernel/softirq.c:141 Dec 2 16:05:21 noc kernel: [<c0121178>] local_bh_enable+0x47/0x6f Dec 2 16:05:21 noc kernel: [<c02177d5>] skb_checksum+0x133/0x25e Dec 2 16:05:21 noc kernel: [<c0250f06>] udp_poll+0x66/0x113 Dec 2 16:05:21 noc kernel: [<c02135fd>] sock_poll+0x19/0x1d Dec 2 16:...

...irtnet_poll_tx(), we need call free_old_xmit_skbs() > unconditionally. This can also help to reduce the possible of napi > rescheduling in virtnet_poll_tx(). Because of the use of trylock there. Absolutely, thanks! Perhaps I should only use trylock in the opportunistic clean path from the rx softirq and full locking in the tx softirq. I previously observed that cleaning here would, counterintuitively, reduce efficiency. It reverted the improvements of cleaning transmit completions from the receive softirq. Going through my data, I did not observe this regression anymore on the latest patchset...

...irtnet_poll_tx(), we need call free_old_xmit_skbs() > unconditionally. This can also help to reduce the possible of napi > rescheduling in virtnet_poll_tx(). Because of the use of trylock there. Absolutely, thanks! Perhaps I should only use trylock in the opportunistic clean path from the rx softirq and full locking in the tx softirq. I previously observed that cleaning here would, counterintuitively, reduce efficiency. It reverted the improvements of cleaning transmit completions from the receive softirq. Going through my data, I did not observe this regression anymore on the latest patchset...

...ot <schlurp... ahhh> Mmm, box says no banana... a lot. [ 30.456921] ================================ [ 30.456924] WARNING: inconsistent lock state [ 30.456928] 5.9.0.gf11901e-master #2 Tainted: G S E [ 30.456932] -------------------------------- [ 30.456935] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 30.456940] ksoftirqd/4/36 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 30.456944] ffff8e2c8bde9e40 (&mgr->vm_lock){++?+}-{2:2}, at: drm_vma_offset_remove+0x14/0x70 [drm] [ 30.456976] {SOFTIRQ-ON-W} state was registered at: [ 30.456982] lock_acquire+0x1a7/0x3...

> I get the same effect when mounting nfs-exported directories > from dom0 in domU. > Every mount/umount/showmount command in domU produces the > message in the dom0 syslog. > > I run 2.0.6 compiled from source, with 2.6 dom0 and 2.4 domU > on a P4 HT 3.2Ghz. This is a native Linux bug. A patch has been submitted upstream, but is already in our 2.0-testing and unstable

Hi, I''m seeing this in the current linux-next tree: ------------[ cut here ]------------ WARNING: at kernel/softirq.c:143 local_bh_enable+0x40/0x87() Modules linked in: xt_state dm_mirror dm_region_hash dm_log microcode [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted 2.6.35-rc6-next-20100729+ #29 Call Trace: <IRQ> [<ffffffff81030de3>] warn_slowpath_common+0x80/0x98 [<ffffff...