Control: retitle -1 rt: NAPI softirq not being scheduled properly Control: tag -1 upstream On Mon, 2012-08-20 at 11:06 +0300, Yevgeny Kosarzhevsky wrote: > On Mon, 20 Aug 2012 04:46:53 +0100 > Ben Hutchings <ben@decadent.org.uk> wrote: > > > On Mon, 2012-07-16 at 10:48 +0000, Yevgeny Kosarhevsky wrote: > > > Package: src > > > Version: 3.2.21-3 > > > Severity: critical > > > Justification: causes serious data loss > > > > What data? > > My peers reported packet loss. Switching back to 2.6.32 kernel solved the issue. You must accept the risk of loss of data transmitted using UDP. The phrase 'causes serious data loss' refers only to data in non-volatile storage (or that is reported as having been stored there). > > > Dear Maintainer, > > > I get a heavy load on irq/23-eth0: > > > 1086 root -51 0 0 0 0 S 2.0 0.0 0:31.04 irq/23-eth0 > > > > I don't think 2% CPU time is a 'heavy load'. > > > > > This is only occured after upgrading from 2.6.32 kernel. > > > The LA was 0.00 on previous kernel, now it's 1.44 > > [...] > > > > But you are not comparing like with like. On a real-time kernel, IRQ > > handlers are scheduled as tasks and are accounted in the load average. > > On a standard kernel as you were running before, IRQ handlers are > > accounted separately. > > > > So, is there really a problem here? Did you actually mean to install a > > real-time kernel? > > Since there was a packet loss, I think there is a problem. I don't know if it's > related with > > [ 1966.544292] NOHZ: local_softirq_pending 08 > > [ 2108.848600] NOHZ: local_softirq_pending 08 The number 08 apparently represents the NET_RX softirq, which is usually responsible for receiving packets after a network interrupt (NAPI). And this warning seems to mean that it is marked as pending, but somehow hasn't been scheduled. So this is very likely related. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
Attachment:
signature.asc
Description: This is a digitally signed message part