Hello,
i think we have few options here:
1) revert back original tapwrite function that was changed in
v. 1.48 and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepend and
m_pullup mbuf after m_uiotombuf
3) change m_uiotombuf to accept one more parameter
On Mon, 2 May 2005, Sten Spans wrote:
On Mon, 2 May 2005, Maksim Yevmenkin wrote:
Hello,
i think we have few options here:
1) revert back original tapwrite function that was changed in v. 1.48
and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepend and
m
On Mon, 2 May 2005, Mike Silbersack wrote:
On Tue, 3 May 2005, Sten Spans wrote:
For the if_tap case fixing the driver ( or rather changing m_uiotombuf )
is definately the correct solution. No sensible person would say otherwise.
Once the if_tap change is properly tested and signed off it should
ma
On Tue, 3 May 2005, Sten Spans wrote:
For the if_tap case fixing the driver ( or rather changing m_uiotombuf )
is definately the correct solution. No sensible person would say otherwise.
Once the if_tap change is properly tested and signed off it should
make it into the tree.
Yes, that makes sense.
On Mon, 2 May 2005, Mike Silbersack wrote:
On Thu, 28 Apr 2005, Bruce M Simpson wrote:
jmg's suggestion of bringing in the NetBSD patches to allow the entire
network stack to be compiled with unaligned accesses (for those platforms
which support it) is interesting because it can simplify or elimina
On Thu, 28 Apr 2005, Bruce M Simpson wrote:
jmg's suggestion of bringing in the NetBSD patches to allow the entire
network stack to be compiled with unaligned accesses (for those platforms
which support it) is interesting because it can simplify or eliminate
some of the acrobatics needed in network
On Mon, 2 May 2005, Maksim Yevmenkin wrote:
Hello,
i think we have few options here:
1) revert back original tapwrite function that was changed in v. 1.48
and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepend and
m_pullup mbuf after m_uiotombuf
3) cha
John-Mark Gurney wrote:
Maksim Yevmenkin wrote this message on Mon, May 02, 2005 at 09:38 -0700:
i think we have few options here:
1) revert back original tapwrite function that was changed in v.
1.48 and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepen
Maksim Yevmenkin wrote this message on Mon, May 02, 2005 at 09:38 -0700:
> >>i think we have few options here:
> >>
> >>1) revert back original tapwrite function that was changed in v.
> >>1.48 and set offset to 2 bytes in top mbuf
> >>
> >>2) change current version of tapw
Hello,
i think we have few options here:
1) revert back original tapwrite function that was changed in v.
1.48 and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepend and
m_pullup mbuf after m_uiotombuf
3) change m_uiotombuf to accept one more parameter
On Fri, 29 Apr 2005, Maksim Yevmenkin wrote:
[...]
I could try to port the changes netbsd made using m_copyup and
send you the resulting patchfile. IPv4 has already been serviced by
John-Mark Gurney in perforce.
having these changes in the tree is a good thing, but it will require more
testing. m
[...]
I could try to port the changes netbsd made using m_copyup and
send you the resulting patchfile. IPv4 has already been serviced by
John-Mark Gurney in perforce.
having these changes in the tree is a good thing, but it will require
more testing. maybe for now we could get away with simpler c
Maksim Yevmenkin wrote this message on Fri, Apr 29, 2005 at 10:51 -0700:
> [...]
>
> i think we have few options here:
>
> 1) revert back original tapwrite function that was changed in v.
> 1.48 and set offset to 2 bytes in top mbuf
>
> 2) change current version of tapwr
[...]
i think we have few options here:
1) revert back original tapwrite function that was changed in v.
1.48 and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepend and
m_pullup mbuf after m_uiotombuf
3) change m_uiotombuf to accept one more parameter
On Thu, 28 Apr 2005, Sam Leffler wrote:
Julian Elischer wrote:
Maksim Yevmenkin wrote:
Hello,
A quick question about if_tap, the tapwrite function
( which copies an ethernet frame into an mbuf using uiotombuf )
is broken on alpha and sparc64.
The 14 byte ethernet header causes the rest of the fram
Julian Elischer wrote:
Maksim Yevmenkin wrote:
Hello,
A quick question about if_tap, the tapwrite function
( which copies an ethernet frame into an mbuf using uiotombuf )
is broken on alpha and sparc64.
The 14 byte ethernet header causes the rest of the frame to
be misaligned on 4 byte boundaries.
On Thu, Apr 28, 2005 at 11:30:02AM -0700, Julian Elischer wrote:
>
>
> Maksim Yevmenkin wrote:
>
> >Hello,
> >
> >>A quick question about if_tap, the tapwrite function
> >>( which copies an ethernet frame into an mbuf using uiotombuf )
> >>is broken on alpha and sparc64.
> >>The 14 byte ethernet
Maksim Yevmenkin wrote:
Hello,
A quick question about if_tap, the tapwrite function
( which copies an ethernet frame into an mbuf using uiotombuf )
is broken on alpha and sparc64.
The 14 byte ethernet header causes the rest of the frame to
be misaligned on 4 byte boundaries. This causes crashes in
On Thu, Apr 28, 2005 at 05:50:26PM +0100, Bruce M Simpson wrote:
...
> jmg's suggestion of bringing in the NetBSD patches to allow the entire
> network stack to be compiled with unaligned accesses (for those platforms
> which support it) is interesting because it can simplify or eliminate
> some of
On Thu, Apr 28, 2005 at 09:39:27AM -0700, Maksim Yevmenkin wrote:
> you probably should file pr. (1) and (2) above are quick fixes. (3) is
> more complicated and, maybe, not desirable.
3) may be good. I have an ATM driver which may need this behaviour. I
haven't had a chance to get test coverage
Hello,
A quick question about if_tap, the tapwrite function
( which copies an ethernet frame into an mbuf using uiotombuf )
is broken on alpha and sparc64.
The 14 byte ethernet header causes the rest of the frame to
be misaligned on 4 byte boundaries. This causes crashes in
various other parts of t
Forward this to expose to wider audience.
- Forwarded message from Sten Spans <[EMAIL PROTECTED]> -
From: Sten Spans <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Julian Elischer <[EMAIL PROTECTED]>
Subject: if_tap unaligned access problem
Date: Wed, 27 Apr 2005 14
22 matches
Mail list logo
