Hi again,
On 10/11/08 01:20, Shaddy Baddah wrote:
]> So you can see that skb->data is not even 2-byte aligned. And my debug
leads me to believe that the problem is this line in zd_mac_tx_to_dev():
skb_pull(skb, sizeof(struct zd_ctrlset));
A before and after of this line gives me this output:
Nov 10 00:47:17 trad kernel: [ 8239.534065]
drivers/net/wireless/zd1211rw/zd_mac.c:376: skb fffff8003d0d8fc0
skb->data fffff8003d874cd0
Nov 10 00:47:17 trad kernel: [ 8239.534092]
drivers/net/wireless/zd1211rw/zd_mac.c:390: skb fffff8003d0d8fc0
skb->data fffff8003d874cdb
Perhaps there needs to be some padding there?
Ok, after a long hard slog at trying to understand all this, I'm going
to have to pause the effort. I am beginning to understand the mechanisms
in place... however, I am not totally sure about anything. My first
impression though is that before control is even passed to the driver
via zd_op_tx(), alignment issues have already hit. As far as I could
tell, at that stage skb->data can already be on an odd byte boundary.
Now, all this is very confusing to me... largely because I don't fully
understand what an SKB is. However, it would seem to me that the
sunlance driver would use this mechanism as well, and AFAICT, that
driver (even if it isn't a wireless driver) does not suffer from
alignment issues.
I have much digging left... but I would greatly appreciate the offering
of opinions as to whether this problem lies deeper in the kernel than
the zd1211rw driver itself. I get a sense that I'm being a little
disengaged... but that's totally cool. I understand the onus of at least
trying to contribute a fix myself.
> Also, I've just had a look at the git version of zd_mac.c, and I notice
> it is all change there again. I would feel uncomfortable having studied
> the 2.6.26 code to have to start again. Is it expected that I use the
> latest available via git?
Ignore that. I was looking at older code (via web git).
Thanks in advance,
Shaddy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
