2010/5/23 Weedy <[email protected]>:
> 2010/5/17 G?bor Stefanik <[email protected]>:
>> What about cutting down the kernel to the absolute minimum required by
>> your machine?
>>
>> Also, Kbuild supports incremental builds as long as you do not "make
>> clean" before builds.
>>
> I just finished the cycle (told you it would take forever on this
> crapbook) and this ?is what I got. To be sure I have done multiple
> boots with vmlinuz-2.6.31-rc5fffffffff-01634-geadac6b and
> vmlinuz-2.6.31-rc5fffffffff-01635-g56d1de0 and confirmed it broken.
> Patching todays compat-wireless tar with the output of "git diff
> 56d1de0a21db28e41741cfa0a66e18bc8d920554
> 56d1de0a21db28e41741cfa0a66e18bc8d920554^ >fffffffff.diff " restores
> expected functionality (Does this mean I get my name in the kernel
> log? :D ).
>
> $ git bisect bad
> 56d1de0a21db28e41741cfa0a66e18bc8d920554 is the first bad commit
> commit 56d1de0a21db28e41741cfa0a66e18bc8d920554
> Author: Bob Copeland <[email protected]>
> Date: ? Mon Aug 24 23:00:30 2009 -0400
>
> ? ?ath5k: clean up filter flags setting
>
> ? ?The maze of if() statements in configure_filter is confusing.
> ? ?Reorganizing it as a switch statement makes it more apparent what
> ? ?is going on and reveals several suspicious settings. ?This has no
> ? ?functional changes, though it does remove some redundant flags
> ? ?that are set earlier.
>
> ? ?Also now that we can sleep, protect sc->filter_flags with the
> ? ?sc lock.
>
> ? ?Signed-off-by: Bob Copeland <[email protected]>
> ? ?Signed-off-by: John W. Linville <[email protected]>
>
> :040000 040000 1ca00241b99b379f192c1ade63c082955c7dda69
> 1a19187e11210e3c66c224dba62a1896c46d0114 M ? ? ?drivers
>
Certainly a possible cause. Chances are some of the "redundant" flags
weren't so redundant at all...
However, the original code was wrong too - I highly doubt we can rely
on sc->opmode to set monitor mode filter flags. I will look into this
when I get to my Linux box again.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
2010/5/23 G?bor Stefanik <[email protected]>:
> 2010/5/23 Weedy <[email protected]>:
>> 2010/5/17 G?bor Stefanik <[email protected]>:
>>> What about cutting down the kernel to the absolute minimum required by
>>> your machine?
>>>
>>> Also, Kbuild supports incremental builds as long as you do not "make
>>> clean" before builds.
>>>
>> I just finished the cycle (told you it would take forever on this
>> crapbook) and this ?is what I got. To be sure I have done multiple
>> boots with vmlinuz-2.6.31-rc5fffffffff-01634-geadac6b and
>> vmlinuz-2.6.31-rc5fffffffff-01635-g56d1de0 and confirmed it broken.
>> Patching todays compat-wireless tar with the output of "git diff
>> 56d1de0a21db28e41741cfa0a66e18bc8d920554
>> 56d1de0a21db28e41741cfa0a66e18bc8d920554^ >fffffffff.diff " restores
>> expected functionality (Does this mean I get my name in the kernel
>> log? :D ).
>>
>> $ git bisect bad
>> 56d1de0a21db28e41741cfa0a66e18bc8d920554 is the first bad commit
>> commit 56d1de0a21db28e41741cfa0a66e18bc8d920554
>> Author: Bob Copeland <[email protected]>
>> Date: ? Mon Aug 24 23:00:30 2009 -0400
>>
>> ? ?ath5k: clean up filter flags setting
>>
>> ? ?The maze of if() statements in configure_filter is confusing.
>> ? ?Reorganizing it as a switch statement makes it more apparent what
>> ? ?is going on and reveals several suspicious settings. ?This has no
>> ? ?functional changes, though it does remove some redundant flags
>> ? ?that are set earlier.
>>
>> ? ?Also now that we can sleep, protect sc->filter_flags with the
>> ? ?sc lock.
>>
>> ? ?Signed-off-by: Bob Copeland <[email protected]>
>> ? ?Signed-off-by: John W. Linville <[email protected]>
>>
>> :040000 040000 1ca00241b99b379f192c1ade63c082955c7dda69
>> 1a19187e11210e3c66c224dba62a1896c46d0114 M ? ? ?drivers
>>
>
> Certainly a possible cause. Chances are some of the "redundant" flags
> weren't so redundant at all...
>
> However, the original code was wrong too - I highly doubt we can rely
> on sc->opmode to set monitor mode filter flags. I will look into this
> when I get to my Linux box again.
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
In the meantime, one thing to test: Add a printk of sc->opmode. If I
am right, this will never be set to NL80211_IFTYPE_MONITOR... That
would mean the promisc flag would never be set. Prior to the patch,
this was taken care by the following code:
if (sc->opmode != NL80211_IFTYPE_AP &&
sc->opmode != NL80211_IFTYPE_MESH_POINT &&
test_bit(ATH_STAT_PROMISC, sc->status))
rfilt |= AR5K_RX_FILTER_PROM;
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)