So I've been using the ath5K drivers for my Compaq Presario C751NR for
some time now. I appreciate the connectivity, and figured I should show
my support by a modest donation.
And now the request: LED and kill-switch support for my card would be
excellent.
Here is what I run:
01:00.0 Ethernet
On Thu, Feb 26, 2009 at 07:06:08PM -0800, Bob Copeland wrote:
> On Thu, Feb 26, 2009 at 06:39:12PM -0800, Luis R. Rodriguez wrote:
> > Might be worth adding a note why this is the case. Can't we simply avoid
> > this by checking earlier for the error or simply assigning it an actual
> > default _go
On Thu, Feb 26, 2009 at 06:39:12PM -0800, Luis R. Rodriguez wrote:
> Might be worth adding a note why this is the case. Can't we simply avoid
> this by checking earlier for the error or simply assigning it an actual
> default _good_ hw rate value?
I guess an alternative is to initialize to 0, that
On Thu, Feb 26, 2009 at 06:27:04PM -0800, Bob Copeland wrote:
> On Fri, Feb 27, 2009 at 12:32:55AM +0100, Jiri Slaby wrote:
> > On 27.2.2009 00:28, Bob Copeland wrote:
> >> hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
> >> array is initialized to (u8)-1 for invalid rates. So,
On Fri, Feb 27, 2009 at 12:32:55AM +0100, Jiri Slaby wrote:
> On 27.2.2009 00:28, Bob Copeland wrote:
>> hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
>> array is initialized to (u8)-1 for invalid rates. So, it can
>> return 255 if the hardware rate index (y) is bad, then the c
On 27.2.2009 00:28, Bob Copeland wrote:
> hw_to_driver_rix() returns sc->rate_idx[x][y] as an int, and that
> array is initialized to (u8)-1 for invalid rates. So, it can
> return 255 if the hardware rate index (y) is bad, then the check
> "rxs.rate_idx>= 0" would always be true, right? If it's n
On Thu, Feb 26, 2009 at 6:19 PM, Jiri Slaby wrote:
> On 27.2.2009 00:15, Bob Copeland wrote:
>> Speaking of, I think there's another potential oob array access at:
>>
>> if (rxs.rate_idx>= 0&& rs.rs_rate ==
>> sc->curband->bitrates[rxs.rate_idx].hw_value_short)
>> rxs.flag |= RX_FLA
On 27.2.2009 00:15, Bob Copeland wrote:
> Speaking of, I think there's another potential oob array access at:
>
> if (rxs.rate_idx>= 0&& rs.rs_rate ==
> sc->curband->bitrates[rxs.rate_idx].hw_value_short)
> rxs.flag |= RX_FLAG_SHORTPRE;
>
> because sc->rate_idx is u8 instead of s8.
On Thu, 26 Feb 2009 23:44:31 +0100, Jiri Slaby wrote
> Make sure we print out a warning when the index is out of bounds,
> i.e. even on hw_rix == AR5K_MAX_RATES.
>
> Also change to WARN and print text with the reported hw_rix.
ACK.
Speaking of, I think there's another potential oob array access
Make sure we print out a warning when the index is out of bounds,
i.e. even on hw_rix == AR5K_MAX_RATES.
Also change to WARN and print text with the reported hw_rix.
Signed-off-by: Jiri Slaby
Cc: Nick Kossifidis
Cc: Luis R. Rodriguez
Cc: Bob Copeland
---
drivers/net/wireless/ath5k/base.c |
On Thu, 26 Feb 2009 21:53:08 +0100, Jiri Slaby wrote
> On 26.2.2009 02:06, Bob Copeland wrote:
> > --- a/drivers/net/wireless/ath5k/base.c
> > +++ b/drivers/net/wireless/ath5k/base.c
> > @@ -1140,12 +1140,14 @@ ath5k_rxbuf_setup(struct ath5k_softc *sc, struct
ath5k_buf *bf)
> > struct ath5k_hw
On 26.2.2009 02:06, Bob Copeland wrote:
> --- a/drivers/net/wireless/ath5k/base.c
> +++ b/drivers/net/wireless/ath5k/base.c
> @@ -1140,12 +1140,14 @@ ath5k_rxbuf_setup(struct ath5k_softc *sc, struct
> ath5k_buf *bf)
> struct ath5k_hw *ah = sc->ah;
> struct sk_buff *skb = bf->skb;
>
Bob Copeland writes:
> On Wed, Feb 25, 2009 at 2:37 PM, Adam Di Carlo wrote:
>> Adam Di Carlo writes:
>> I was able to get beyond this problem when i noticed an ath5k module
>> param, nohwcrypt. Setting that module param to 1, and the connection
>> is much better.
>
> Odd, do you see disassoci
On Thu, Feb 26, 2009 at 08:59:39AM -0500, Bob Copeland wrote:
> On Wed, Feb 25, 2009 at 02:01:39PM +, Sitsofe Wheeler wrote:
> > It has been days since the original BUG occurred and further it
> > originally had happened in a -tip kernel with kmemcheck compiled into
> > it. I had been utterly u
[Doh! Let's try that again, this time with the right date in the subject
and the right address for ath[59]k-devel...]
Hi all.
As mentioned earlier this week on the madwifi-project list, I'll do some
maintenance work on our server tomorrow; see [1] for details / background
information.
My plan is
On Wed, Feb 25, 2009 at 02:01:39PM +, Sitsofe Wheeler wrote:
> It has been days since the original BUG occurred and further it
> originally had happened in a -tip kernel with kmemcheck compiled into
> it. I had been utterly unable to reproduce the error on any network with
> a stock 2.6.29-rc6
16 matches
Mail list logo
