[lkml]   [2002]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sk_buff modification problem -> (almost) solved

I finally found the source of the problem, and was such able to solve
it for me. Unfortunately, I do not really understand, why all this
behaves that way.

In short:
I inserted a new member into struct sk_buff, which was filled in in the
driver (orinoco.c) and should be evaluated "upstairs". However, the contents
of this field was already lost in netif_rx...

(Like this:
[orinoco.c, orinoco_ev_rx]
printk("orinoco.c: skb=%p, is_valid=%d\n",skb,skb->rcvtime.is_valid);

int netif_rx(struct sk_buff *skb)
int this_cpu = smp_processor_id();
struct softnet_data *queue;
unsigned long flags;

if (skb->stamp.tv_sec == 0)

printk("netif_rx: skb=%p, is_valid=%d\n",skb,skb->rcvtime.is_valid);

May 26 14:41:05 licht kernel: orinoco.c: skb=c3d40d80, is_valid=1
May 26 14:41:05 licht kernel: netif_rx: skb=c3d40d80, is_valid=0
May 26 14:41:05 licht kernel: orinoco.c: skb=c3d400c0, is_valid=1
May 26 14:41:05 licht kernel: netif_rx: skb=c3d400c0, is_valid=0
...and so on)

It turned out to be a problem with the pcmcia-cs-3.1.33 package i was using,
now i modified the in-kernel orinoco driver to generate the timestamps i want,
and everything works as expected.

What i do not understand is how such a behaviour can evolve, without any
compiler warning?
Just post it again because i really would be interested which trap i ran
into here... ;-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.068 / U:10.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site