panic doesn't get invoked on oops when panic_on_oops is set

Hi, An oops doesn't result in panic() call even when panic_on_oops is set (if we've a crash kernel loaded). The reason seems to be that from oops codepath before calling panic(), we call crash_kexec() if panic_on_oops is set: void __kprobes oops_end(unsigned long flags, struct pt_regs *regs, int

inconsistency in dev->hard_header() arguments?

The function is called like this- dev->hard_header(skb, dev, ptype, dest_hw, src_hw, skb->len); where "skb->protocol" is same as "ptype", but the former is expected to be in network byte order before calling hard_header, while latter in host byte order (eth_header internally does its own conversio

wake_up() takes long time to return

Hi there, We've a kernel (n/w) module, which sits over ethernet. Whenever a pkt is received (in softirq), after doing some minimal processing, wake_up() is called to wake up another kernel thread which does rest (bulk) of the processing. We notice that this wake_up() call is sometimes taking as

Re: wake_up() takes long time to return

On 1/20/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Sat, 2007-01-20 at 15:54 +0530, kalash nainwal wrote: > Hi there, > > We've a kernel (n/w) module, which sits over ethernet. Whenever a pkt > is received (in softirq), after doing some minimal processing, > wake

Re: select-like implementation for kernel sockets

On 5/6/07, Robert Hancock <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > Hi, > > I'm using kernel sockets to Tx and Rx UDP packets between my hardware > device (DSP) to the external network (this is part of a VoIP > implementation). The motivation for using kernel sockets rather than > use

[PATCH] (re)register_binfmt returns with -EBUSY

t to NULL after unregistering, but that is kind of unclean (one should better be using only the interfaces, and not the interal members, isn't it?) Attached one-liner can fix it (for 2.6.20). Regards, -Kalash Signed-off-by: Kalash Nainwal <[EMAIL PROTECTED]> lnx_binfmt.patch Description: Binary data

Re: irq load balancing

On 9/12/07, Venkat Subbiah <[EMAIL PROTECTED]> wrote: > Most of the load in my system is triggered by a single ethernet IRQ. > Essentially the IRQ schedules a tasklet and most of the work is done in the > taskelet which is scheduled in the IRQ. From what I read looks like the > tasklet would be

[PATCH] Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255

Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255 to keep legacy software happy. This is similar to what was done for ipv4 in commit 709772e6e065 ("net: Fix routing tables with id > 255 for legacy software"). Signed-off-by: Kalash Nainwal --- net/ipv6/route.c | 2 +- 1

Re: [PATCH] Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255

On Fri, Feb 22, 2019 at 3:22 PM David Miller wrote: > > From: Kalash Nainwal > Date: Wed, 20 Feb 2019 16:23:04 -0800 > > > Set rtm_table to RT_TABLE_COMPAT for ipv6 for tables > 255 to > > keep legacy software happy. This is similar to what was done for > > ipv4