2013/3/27 Stuart Henderson
> This patch only helped some quite uncommon cards with rf 6.0,
> the normal ones have rf 10.2 which these diffs didn't help, and made
> worse in some cases (system hangs).
>
Oh... So can I have a little request for someone skilled in patching driver
to help with this
On 2013/03/27 12:27, Hubert Jarosz wrote:
> Hi,
> I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The
> question is: wasn't the patch which I found (
> http://marc.info/?t=12643791922) merged into OpenBSD official
> repository or it's bugged?
> Have maybe anyone tried testi
On 03/27/13 12:27, Hubert Jarosz wrote:
> Hi,
> I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The
> question is: wasn't the patch which I found (
> http://marc.info/?t=12643791922) merged into OpenBSD official
> repository or it's bugged?
>
If I remember well it breaks a
Hi,
I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The
question is: wasn't the patch which I found (
http://marc.info/?t=12643791922) merged into OpenBSD official
repository or it's bugged?
Have maybe anyone tried testing/developing those patches since 2010?
Retards,
Hube
On 21/05/10 18:42, Giovanni Bechis wrote:
> Il 21/05/2010 19.31, Tom Murphy ha scritto:
>>Is there any update on this? Is it possible to get the chipset
>> working?
>>
> At least latest version breaks this chip (found on IBM x40):
> ath0 at pci1 dev 2 function 0 "Atheros AR5212 (IBM MiniPCI)" r
Hi Tom,
On Mon, Jun 28, 2010 at 12:26 PM, Tom Murphy wrote:
> On 21/05/10 18:42, Giovanni Bechis wrote:
>> Il 21/05/2010 19.31, Tom Murphy ha scritto:
>>>Is there any update on this? Is it possible to get the chipset
>>> working?
>>>
>> At least latest version breaks this chip (found on IBM x
On 2010/06/20 15:08, Luis Henriques wrote:
> Hi,
>
> I'm attaching a patch I've been using for a couple of weeks now. Can
> anyone give it a try? As usual, no guarantees -- it may crash your
> system, so be careful.
>
> Just let me know of any successful/unsuccessful story.
this needs a test o
Full patch against latest I assume b/c of the 1.51 version tag of ar5212.c.
I'll need to update before I test, but I'll try to test soon. Thanks.
Hi,
I'm attaching a patch I've been using for a couple of weeks now. Can
anyone give it a try? As usual, no guarantees -- it may crash your
system, so be careful.
Just let me know of any successful/unsuccessful story.
--
Luis Henriques
Index: dev/ic/ar5212.c
===
Il 21/05/2010 19.31, Tom Murphy ha scritto:
Is there any update on this? Is it possible to get the chipset working?
At least latest version breaks this chip (found on IBM x40):
ath0 at pci1 dev 2 function 0 "Atheros AR5212 (IBM MiniPCI)" rev 0x01:
irq 11
ath0: AR5213A 5.9 phy 4.3 rf5112a 3
On Wed, May 05, 2010 at 02:37:54PM +0200, Giovanni Bechis wrote:
> On 05/05/10 13:25, Tom Murphy wrote:
> >My guess is the device isn't supported or WPA/WPA2 isn't working yet
> >for it? Haven't tried with an open/unencrypted access or WEP point yet
> >to see if that makes any difference.
> >
>
On 05/05/10 13:25, Tom Murphy wrote:
My guess is the device isn't supported or WPA/WPA2 isn't working yet
for it? Haven't tried with an open/unencrypted access or WEP point yet
to see if that makes any difference.
I tried the diff and I have no mode device timeout, anyway I receive a
beacon
Hi Luis,
The patch works on my system. ifconfig ath0 up doesn't lock the system
I enabled debug and it does an active scan where it sends probes to
ff:ff:ff:ff:ff:ff on a bunch of channels, gets a beacon from my AP, then
when it tries to send an auth to my AP, I get: "ath0: device timeout".
Hi,
Here's another patch with a couple of changes since the last one. Not
sure how this will make any difference to the cards that were not working
with previous versions, but hopefully there will be some changes.
Please let me know if this works for you.
Alexander: sorry for the delay on sendi
On 04/29/10 13:40, Luis Henriques wrote:
On 2010/04/28 18:41, Luis Henriques wrote:
Anyway, this gave me the chance to find some more differences between
ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
HAL_MODE_XR) were defined with the wrong values. See updated patch
bel
>> On 2010/04/28 18:41, Luis Henriques wrote:
>> > Anyway, this gave me the chance to find some more differences between
>> > ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
>> > HAL_MODE_XR) were defined with the wrong values. See updated patch
>> > bellow.
>>
>> hmm, I'm n
> Date: Thu, 29 Apr 2010 11:20:52 +0100
> From: Stuart Henderson
>
> On 2010/04/28 18:41, Luis Henriques wrote:
> > Anyway, this gave me the chance to find some more differences between
> > ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
> > HAL_MODE_XR) were defined with t
On 2010/04/28 18:41, Luis Henriques wrote:
> Anyway, this gave me the chance to find some more differences between
> ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
> HAL_MODE_XR) were defined with the wrong values. See updated patch
> bellow.
hmm, I'm not sure about this..
Il 29/04/2010 11.59, Giovanni Bechis ha scritto:
With this patch my system does not hang anymore but when I try dhclient
ath0 my wifi status is "no network":
$ sudo dhclient ath0
ath0: no link . sleeping
I am seeing also some "ath0: device timeout" kernel messages.
Cheers
Giovanni
On 04/28/10 19:41, Luis Henriques wrote:
Anyway, this gave me the chance to find some more differences between
ath(4) and linux ath5k device driver. Two constants (HAL_MODE_11G and
HAL_MODE_XR) were defined with the wrong values. See updated patch
bellow.
With this patch my system does not han
On Thu, Apr 29, 2010 at 12:27:41AM +0800, Alexander Vladimirov wrote:
> On Wed, 28 Apr 2010 14:15:27 +0100
> Luis Henriques wrote:
> > Interesting. This is behaviour seems to be different from what
> > Alexander was seeing. Is this correct Alexander? I believe you
> > referred in your last email t
On Wed, 28 Apr 2010 14:15:27 +0100
Luis Henriques wrote:
> Interesting. This is behaviour seems to be different from what
> Alexander was seeing. Is this correct Alexander? I believe you
> referred in your last email that your system is not hanging anymore.
>
> --
> Luis
Your latest patches lack
On Wed, Apr 28, 2010 at 2:07 PM, Giovanni Bechis
wrote:
> On 04/27/10 19:34, Luis Henriques wrote:
>>
>> BTW, with my wifi card, it seems to make no difference whether the value
>> 0x0040 or 0x1000 is used. How the hell my card is working??? :-)
>>
> I tried your latest diff with my card, it is r
On 04/27/10 19:34, Luis Henriques wrote:
> BTW, with my wifi card, it seems to make no difference whether the value
> 0x0040 or 0x1000 is used. How the hell my card is working??? :-)
>
I tried your latest diff with my card, it is recognized well, there are
no more "hal status" messages from the k
On Tue, Apr 27, 2010 at 10:59:21AM +0800, Alexander Vladimirov wrote:
> On Mon, 26 Apr 2010 20:59:45 +0100
> Luis Henriques wrote:
>
> > @@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha
> > /*
> > * Set misc registers
> > */
> > + /* Enable DCU early termination for
On Tue, Apr 27, 2010 at 3:59 AM, Alexander Vladimirov
wrote:
> On Mon, 26 Apr 2010 20:59:45 +0100
> Luis Henriques wrote:
>
>> @@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha
>> /*
>>* Set misc registers
>>*/
>> + /* Enable DCU early termination for this
On Mon, 26 Apr 2010 20:59:45 +0100
Luis Henriques wrote:
> @@ -1150,9 +1179,17 @@ ar5k_ar5212_reset_tx_queue(struct ath_ha
> /*
>* Set misc registers
>*/
> + /* Enable DCU early termination for this queue */
> AR5K_REG_WRITE(AR5K_AR5212_QCU_MISC(queue),
>
On Mon, Apr 26, 2010 at 05:04:49PM +0100, Stuart Henderson wrote:
> AR5424 14.2 phy 7.0 rf 10.2, WOR5_ETSIC
>
> ar5212.c:ar5k_ar5212_reset() resets tx queues.
> I inserted a printf as follows...:
>
> /*
> * Reset queues and start beacon timers at the end of the reset
> routine
>
On Mon, Apr 26, 2010 at 03:38:19PM +0100, Luis Henriques wrote:
> On Mon, Apr 26, 2010 at 7:57 AM, Tom Murphy wrote:
> > Hi Luis,
> >
> > Yes, that is correct. Do you need the rf value from the patched kernel?
> > I basically patched the latest -CURRENT (cvs tree as of yesterday).
>
> Ok, thanks
AR5424 14.2 phy 7.0 rf 10.2, WOR5_ETSIC
ar5212.c:ar5k_ar5212_reset() resets tx queues.
I inserted a printf as follows...:
/*
* Reset queues and start beacon timers at the end of the reset routine
*/
for (i = 0; i < hal->ah_capabilities.cap_queues.q_tx_num; i++) {
On Mon, Apr 26, 2010 at 4:03 PM, Adam M. Dutko wrote:
> The previous patches you sent me off list gave me this:
> ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
> 10)
> ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address XX:XX:XX:XX:XX:XX
> I'm going to evaluate the new
The previous patches you sent me off list gave me this:
ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
10)
ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address XX:XX:XX:XX:XX:XX
I'm going to evaluate the new ones tonight and will let you know.
On Mon, Apr 26, 2010 at 7:57 AM, Tom Murphy wrote:
> Hi Luis,
>
> Yes, that is correct. Do you need the rf value from the patched kernel?
> I basically patched the latest -CURRENT (cvs tree as of yesterday).
Ok, thanks. I just wanted to make sure the patch was identifing
correctly your card. The
On Sun, Apr 25, 2010 at 10:49:26PM +0100, Luis Henriques wrote:
> On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote:
> > Luis,
> >
> > I have an Asus EEE with uses an AR5424 chipset:
> >
> > ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 18 (irq
> > 10)
> > ath0:
On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote:
> Luis,
>
> I have an Asus EEE with uses an AR5424 chipset:
>
> ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 18 (irq
> 10)
> ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f
>
> I tried the
Luis,
I have an Asus EEE with uses an AR5424 chipset:
ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 18 (irq 10)
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f
I tried the latest patch you posted and it locks OpenBSD completely up
when bringing the ne
Hi,
here's another version of the patch. It includes the patch from Alexander.
Again, it has been tested on my hardware only and it is working.
WARNING: previous versions of this patch are known to freeze your system
so... make sure you really want to test it! However, the -current version
of t
Hi Alexander (and others),
I am attaching a new patch which merges your patch with another one
I have never sent to tech@ before. I shared this patch with some other
guys that were testing it, but I believe it's worth trying it again
with your modifications.
Could someone run a quick test? Agai
On Sun, Apr 25, 2010 at 03:25:03AM +0800, Alexander Vladimirov wrote:
> I actually did, your patch was the starting point, but I encountered "ath0:
> device timeout" errors while testing with both patches applied, so it still
> needs deeper research.
Great, thanks. That's valuable information ;-)
I actually did, your patch was the starting point, but I encountered "ath0:
device timeout" errors while testing with both patches applied, so it still
needs deeper research.
2010/4/25 Luis Henriques
> Hi Alexander,
>
> I was wondering whether you tested this code + my original patch. I
> just
Hi Alexander,
I was wondering whether you tested this code + my original patch. I
just merged both patches and I'm still able to use my card.
However, with my card the code you added (function ar5k_ar2425_channel)
is not actually activated -- I follow into the default case where function
ar5k_ar
On Sat, 24 Apr 2010 16:26:01 +0100
"Federico G. Schwindt" wrote:
> > + else if (hal->ah_radio == AR5K_AR2425)
> > + ret = ar5k_ar5111_channel(hal, channel);
> ^^
> shouldn't that be ar_2425?
>
Oh sorry, sure it should. I was cleaning other c
Here are dmesg lines for Atheros wireless in my Acer Aspire One:
ath0 at pci3 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 4 int 18 (irq 11)
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR5_ETSIC, address 00:22:69:4c:f5:20
Its EEPROM reports only 802.11g mode supported which is disabled in current
kern
> Date: Sat, 24 Apr 2010 14:04:35 +0100
> From: Stuart Henderson
>
> On 2010/04/24 13:19, Luis Henriques wrote:
> > > Luis, can you send the latest version of your diff please. There were
> > > at least two and I'm not sure which one people should be testing.
> > > Then I'll test it on AR5213A 5.
On 2010/04/24 13:19, Luis Henriques wrote:
> > Luis, can you send the latest version of your diff please. There were
> > at least two and I'm not sure which one people should be testing.
> > Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works
> > ok with the existing driver.
>
Hi Stuart
On Sat, Apr 24, 2010 at 11:03:21AM +0100, Stuart Henderson wrote:
> Luis, can you send the latest version of your diff please. There were
> at least two and I'm not sure which one people should be testing.
> Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works
> ok wit
Luis, can you send the latest version of your diff please. There were
at least two and I'm not sure which one people should be testing.
Then I'll test it on AR5213A 5.9 phy 4.3 rf2112a 4.6, WOR0W which works
ok with the existing driver.
Other people: if you have ath(4) devices please mail the full
Rod Whitworth wrote:
On Tue, 20 Apr 2010 17:58:17 +0100, Luis Henriques wrote:
On Tue, Apr 20, 2010 at 12:14:51PM -0400, Adam M. Dutko wrote:
Lines identifying the card:
ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
10)
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, ad
On Tue, 20 Apr 2010 17:58:17 +0100, Luis Henriques wrote:
>On Tue, Apr 20, 2010 at 12:14:51PM -0400, Adam M. Dutko wrote:
>> Lines identifying the card:
>>
>> ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
>> 10)
>> ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:
On Tue, Apr 20, 2010 at 12:14:51PM -0400, Adam M. Dutko wrote:
> Lines identifying the card:
>
> ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
> 10)
> ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX
>
> I have the version the other folks had that h
Lines identifying the card:
ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 2 int 17 (irq
10)
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address XX:XX:XX:XX:XX:XX
I have the version the other folks had that had issues with your patch. I
can still attempt to use the patch if you'd lik
On Tue, Apr 20, 2010 at 4:06 PM, Adam M. Dutko wrote:
> I have a card to test with and am trying to solve the problem on my eeepc
> laptop. Luis, are you still around and interested in working on this?
Yep, still around. But not sure how I can help without the actual HW.
Sometime ago I submited
I have a card to test with and am trying to solve the problem on my eeepc
laptop. Luis, are you still around and interested in working on this?
On Thu, Mar 11, 2010 at 1:20 AM, Abel Abraham Camarillo Ojeda
wrote:
>
> Anyone knows what happened to this?
>
> ... or it just got lost in the mist?
I'm currently using a CVS head kernel patched with this. But since the
patch seems to benefit myself only (no one else has reported a
successfull u
"Bret S. Lambert" wrote:
> On Mon, Jan 25, 2010 at 06:18:33PM +, Luis Henriques wrote:
> > On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote:
> > > On 2010/01/25 00:50, Luis Henriques wrote:
> > > > Re-sending with "cvs diff -upRN"
> > >
> > > Wha, you mean I have to dismantle
Luis Henriques wrote:
Anyway, could you please confirm that there are changes on dmesg?
I am expecting that the two lines on dmesg that relate to the ath
attachment should have changed to match your card (you had previously
"rf 0.0", it should now have something different there...).
ath0 at pci3
On Wed, Jan 27, 2010 at 8:48 AM, Giovanni Bechis wrote:
> Luis Henriques wrote:
>>
>> If you're able to test this patch, please let me know if anything changed
>> from previous patch.
>>
> The wireless doesn't work but some error codes have changed, now hal
> statuses are:
> ath0: unable to reset
Luis Henriques wrote:
If you're able to test this patch, please let me know if anything changed
from previous patch.
The wireless doesn't work but some error codes have changed, now hal
statuses are:
ath0: unable to reset hardware; hal status 2160264736
ath0: unable to reset hardware; hal stat
On Mon, Jan 25, 2010 at 03:58:59PM +0100, Giovanni Bechis wrote:
> Giovanni Bechis wrote:
> >Stuart Henderson wrote:
> >>On 2010/01/25 00:50, Luis Henriques wrote:
> >>>Re-sending with "cvs diff -upRN"
> >
> Unfortunately this diff doesn't work with my card, I have "unable to
> reset hardware" erro
On Mon, Jan 25, 2010 at 03:58:59PM +0100, Giovanni Bechis wrote:
> Giovanni Bechis wrote:
> >Stuart Henderson wrote:
> >>On 2010/01/25 00:50, Luis Henriques wrote:
> >>>Re-sending with "cvs diff -upRN"
> >
> Unfortunately this diff doesn't work with my card, I have "unable to
> reset hardware" erro
On Mon, Jan 25, 2010 at 06:18:33PM +, Luis Henriques wrote:
> On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote:
> > On 2010/01/25 00:50, Luis Henriques wrote:
> > > Re-sending with "cvs diff -upRN"
> >
> > Wha, you mean I have to dismantle my AspireOne again and put the
> > min
On Mon, Jan 25, 2010 at 01:52:12PM +, Stuart Henderson wrote:
> On 2010/01/25 00:50, Luis Henriques wrote:
> > Re-sending with "cvs diff -upRN"
>
> Wha, you mean I have to dismantle my AspireOne again and put the
> minipcie back in to test it? But last time I did that I had to drill
> out some
On Mon, Jan 25, 2010 at 2:58 PM, Giovanni Bechis
wrote:
> Giovanni Bechis wrote:
>>
>> Stuart Henderson wrote:
>>>
>>> On 2010/01/25 00:50, Luis Henriques wrote:
Re-sending with "cvs diff -upRN"
>>
> Unfortunately this diff doesn't work with my card, I have "unable to reset
> hardware" e
Giovanni Bechis wrote:
> Stuart Henderson wrote:
>> On 2010/01/25 00:50, Luis Henriques wrote:
>>> Re-sending with "cvs diff -upRN"
>
Unfortunately this diff doesn't work with my card, I have "unable to
reset hardware" errors whenever I try to scan the network or configure
my device.
Cheers
Stuart Henderson wrote:
On 2010/01/25 00:50, Luis Henriques wrote:
Re-sending with "cvs diff -upRN"
Wha, you mean I have to dismantle my AspireOne again and put the
minipcie back in to test it?
Don't worry, I have this wireless card on my laptop too ;-)
Cheers
Giovanni
On 2010/01/25 00:50, Luis Henriques wrote:
> Re-sending with "cvs diff -upRN"
Wha, you mean I have to dismantle my AspireOne again and put the
minipcie back in to test it? But last time I did that I had to drill
out some of the screws :-) (only joking, I can do this on the eee
instead, it's far e
Re-sending with "cvs diff -upRN"
Index: dev/ic/ar5212.c
===
RCS file: /home/miguel/openbsd-cvsroot//src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- dev/ic/ar5212.c 2 Jun 2009 12:39:02 -
My wireless card is recognised as being a AR5424 by OpenBSD. Unfortunately,
it is a non-supported card. After some hacking, I was able to make it work
by using some code both from Linux and NetBSD device drivers.
After some initial doubts about licensing issues (I though the Linux code
was GPL b
68 matches
Mail list logo
