Re: [ath5k-devel] ath5k_pci: gain calibration timeout / unable to reset hardware -11

2008-12-22 Thread Nick Kossifidis
2008/12/22 Bob Copeland : > On Mon, Dec 22, 2008 at 4:39 PM, Jiri Slaby wrote: >>> >>> Does the _HW lockup_ happen even with 2.6.28? The lockup should be gone >>> there >>> (with the messages still present). >> >> I see Bob already replied, ignore me, he knows better. > > I thought Felix's patch

Re: [ath5k-devel] ath5k_pci: gain calibration timeout / unable to reset hardware -11

2008-12-22 Thread Maxim Levitsky
On Mon, 2008-12-22 at 16:48 -0500, Bob Copeland wrote: > On Mon, Dec 22, 2008 at 4:39 PM, Jiri Slaby wrote: > >> > >> Does the _HW lockup_ happen even with 2.6.28? The lockup should be gone > >> there > >> (with the messages still present). > > > > I see Bob already replied, ignore me, he knows b

Re: [ath5k-devel] reset hangs

2008-12-22 Thread Nick Kossifidis
2008/12/22 Bob Copeland : > While looking into http://bugzilla.kernel.org/show_bug.cgi?id=12080 > I noticed that we call reset() from a lot of places without locking: > > - at probe time > - whenever we change channels > - whenever we miss 3 beacons > - whenever a 'bad' interrupt occurs > - wh

Re: [ath5k-devel] reset hangs

2008-12-22 Thread Bob Copeland
On Mon, Dec 22, 2008 at 4:54 PM, Nick Kossifidis wrote: > remains). Can someone work on these locking issues inside base.c to be > safe on the driver side ? Ok, I'll leave the hardware stuff to you and take a look at the driver interface. I think most things can just schedule restq and be done w

Re: [ath5k-devel] reset hangs

2008-12-22 Thread Maxim Levitsky
On Mon, 2008-12-22 at 16:16 -0500, Bob Copeland wrote: > While looking into http://bugzilla.kernel.org/show_bug.cgi?id=12080 > I noticed that we call reset() from a lot of places without locking: > > - at probe time > - whenever we change channels > - whenever we miss 3 beacons > - whenever a

Re: [ath5k-devel] ath5k_pci: gain calibration timeout / unable to reset hardware -11

2008-12-22 Thread Bob Copeland
On Mon, Dec 22, 2008 at 4:39 PM, Jiri Slaby wrote: >> >> Does the _HW lockup_ happen even with 2.6.28? The lockup should be gone there >> (with the messages still present). > > I see Bob already replied, ignore me, he knows better. I thought Felix's patch had gone into .28, but in fact it hasn't.

Re: [ath5k-devel] ath5k_pci: gain calibration timeout / unable to reset hardware -11

2008-12-22 Thread Jiri Slaby
On 12/22/2008 10:37 PM, Jiri Slaby wrote: > On 12/22/2008 09:58 PM, Andrew Morton wrote: >> (cc linux-wireless) >> >> On Mon, 22 Dec 2008 06:31:53 +0100 >> Soeren Sonnenburg wrote: >> >>> Hi, >>> >>> I was using the ath5k_pci driver on a macbook pro 1,1 and it is working >>> for some time but then

Re: [ath5k-devel] ath5k_pci: gain calibration timeout / unable to reset hardware -11

2008-12-22 Thread Jiri Slaby
On 12/22/2008 09:58 PM, Andrew Morton wrote: > (cc linux-wireless) > > On Mon, 22 Dec 2008 06:31:53 +0100 > Soeren Sonnenburg wrote: > >> Hi, >> >> I was using the ath5k_pci driver on a macbook pro 1,1 and it is working >> for some time but then suddenly messages like the ones below appear and >

[ath5k-devel] reset hangs

2008-12-22 Thread Bob Copeland
While looking into http://bugzilla.kernel.org/show_bug.cgi?id=12080 I noticed that we call reset() from a lot of places without locking: - at probe time - whenever we change channels - whenever we miss 3 beacons - whenever a 'bad' interrupt occurs - whenever the calibration timer runs and we

Re: [ath5k-devel] ath5k_pci: gain calibration timeout / unable to reset hardware -11

2008-12-22 Thread Bob Copeland
On Mon, Dec 22, 2008 at 12:31 AM, Soeren Sonnenburg wrote: > Hi, > > I was using the ath5k_pci driver on a macbook pro 1,1 and it is working > for some time but then suddenly messages like the ones below appear and > I have to *turn off* the machine to get it back working (even booting to > osx is

[ath5k-devel] [PATCH] ath5k: More EEPROM code updates

2008-12-22 Thread Nick Kossifidis
* Don't scale power values on RF5111 EEPROMs because they get out of bounds (power is u8, so multiplying power by 50 is too much and there is no reason to do so -we don't do it on other chips anyway-). HAL does it as a technique to handle 0.5 dbm steps but i believe it's not the right thing to