Suspend vs Network Traffic - blockers

[Deepak Saxena]

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 <dwmw2 at infradead.org>
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 <dwmw2 at infradead.org>

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 - dsaxena at laptop.org