Paul Mackerras wrote : > Philippe De Muyter writes: > > > Actually, that's probably the case I had, but my fix gets the ip adresses > > 4byte aligned in my case : I had verified the address of the saddr field, > > and I needed to shift the buffer by 3, not 1, to get it 4byte aligned. > > Please outline the code flow that leads to that situation. AFAICS we > would only need to shift the buffer by 3 if we had a compressed > (1-byte) protocol number at the original skb->data, implying that the > protocol byte was first. But if the protocol byte was first, then > this code: > > if (buf[0] != PPP_ALLSTATIONS) > skb_reserve(skb, 2 + (buf[0] & 1)); > > at line 893 should have moved skb->data up by 3 bytes already, since a > 1-byte protocol number is always odd. > > If that is not the case then there is something else going on beyond > the data getting misaligned, and I would like to know what it is.
I just noticed something at the end of process_input_packet : /* queue the frame to be processed */ skb->cb[0] = ap->state; skb_queue_tail(&ap->rqueue, skb); ap->rpkt = 0; ap->state = 0; return; err: /* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */ ap->state = SC_PREV_ERROR; if (skb) skb_trim(skb, 0); } In the normal case, skb is given to the next stage and ap->rpkt is reset, but in the error case, skb is kept, ap->rpkt is not reset, so we keep the skb with skb->data aligned for one message and we put another one into it :) Could that not be the culprit ? Philippe > > Paul. > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html