Messages in this thread | | | Date | Sun, 26 May 2002 19:35:29 +0200 | From | Wolfgang Wegner <> | Subject | Re: sk_buff modification problem -> (almost) solved |
| |
Hi,
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] skb->rcvtime.is_valid=1; printk("orinoco.c: skb=%p, is_valid=%d\n",skb,skb->rcvtime.is_valid); netif_rx(skb);
[linux/net/core/dev.c] 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) do_gettimeofday(&skb->stamp);
printk("netif_rx: skb=%p, is_valid=%d\n",skb,skb->rcvtime.is_valid);
dmesg: 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... ;-)
Wolfgang
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |