On Aug 12 2008, at 12:22, Ricardo Carrano was caught saying:
> Dear all,
>
> It is very important to correctly approach the interactions between
> suspend/resume and network traffic.
>
> There are at least two mechanisms that need to be in place for both
> things to be able to operate together without causing major issues:
>
> 1 - The multicast address populating on the firmware, that is needed
> for collaboration to work: http://dev.laptop.org/ticket/6818
So it doesn't look like Javier's patch actually went into one of our official
branches (stable/testing/master). I'm also not sure we need it b/c testing
and stable have the following commit that came in 6 days after Javier's patch
on trac and it seems to deal with the same issue:
commit c16eba59c2183f9d4952eca4d720982cfbe8e031
Author: David Woodhouse <[EMAIL PROTECTED]>
Date: Mon May 19 18:47:52 2008 +0100
libertas: fix multicast handling on eth and msh interfaces
We weren't properly handling multicast on the mesh interface. Fix that,
which involves setting up the hardware to use the union of dev->mc_list
for both eth%d and msh%d devices.
This means we can't do it directly from ->set_multicast_list() because
we'd need to lock the other device to read its list, and we can't do
that because it might deadlock. So punt the actual work to keventd.
Also, invoke the same when taking an interface down; for some reason the
core calls ->set_multicast_list while IFF_UP is still set in dev->flags
when we're taking it down, so its addresses don't get removed then.
We also convert MAC_MULTICAST_ADR to a direct command while we're at it,
removing one more entry from the big switch statement in the deprecated
lbs_prepare_and_send_command() function. Change the priority of the
'unknown command' warnings in that switch statement too, because we
really do want to know about it if it happens.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
Ricardo, have you reproduced the issues with the latest kernels?
> 2 - The signature based filter, that is needed for ARP to work
> (keeping in mind that no ARP, no unicast traffic, nothing):
> http://dev.laptop.org/ticket/6993#comment:2
This patch applies cleanly and if we need this for 8.2 mesh to work properly,
I'm OK pushing it in (depending on how our discussion on change control ends
up) but would like to see us vet this upstream for the future. Instead of
iwpriv, we could theoretically extend the ethtool interface to support
this if we think more HW in the future will support this sort of filtering.
Javier, can you work on push to upstream? Have we already tried and been
NACKed?
Thanks for point these out Ricardo!
<rant>
This is not the first set of issues that have come up due to
out-of-tree, non-upstream development that was stuck in one of our
trees or trac and we need to work on reducing our differences
from upstream. Our delta is just going to get bigger and unmaintainble
with regressions constantly popping up as patches get dropped. For
9.1 (9.2 more realistically?) I highly suggest one of our priorities
be that a stock kernel.org kernel just works out of the box on our
lovely little laptop, even if that means rewriting parts of drivers,
firmware, etc.
</rant>
~Deepak
--
Deepak Saxena - Kernel Developer - [EMAIL PROTECTED]
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
