Thanx man, it would have been impossible without your magic scripts !
I haven't run long tests yet, i just got this (it's 9am here and i
started the whole thing yesterday at 5pm, i can't wait to sleep :P). I
hope it's stable and it'll work for other implementations too. I can't
be sure until i fix
2007/12/12, Grant Williamson <[EMAIL PROTECTED]>:
> Nick,
> I might be the kernel I am using, this is on a t60
>
> 03:00.0 0200: 168c:1014 (rev 01)
> Subsystem: 1014:058a
> Flags: fast devsel, IRQ 82
> Memory at edf0 (64-bit, non-prefetchable) [disabled] [size=64K]
>
nick!
that is GREAT! :)
thanks for your amazing work!
bruno
On Wednesday 12 December 2007 16:09:31 Nick Kossifidis wrote:
> I was working again on the initial register settings, i'm almost done
> with 5414 and 5213 + 5112, next is 5213 + 5111, 5211 and finally 5210
> (which had a terrible bug i
I was working again on the initial register settings, i'm almost done
with 5414 and 5213 + 5112, next is 5213 + 5111, 5211 and finally 5210
(which had a terrible bug in nic_wakeup -the whole system crashed-
that also gave me a better idea of nic_wakeup).
Before my fixes, with the same setup (my la
Nick,
I might be the kernel I am using, this is on a t60
03:00.0 0200: 168c:1014 (rev 01)
Subsystem: 1014:058a
Flags: fast devsel, IRQ 82
Memory at edf0 (64-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Ca
On Dec 11, 2007 8:46 PM, bruno randolf <[EMAIL PROTECTED]> wrote:
> On Tuesday 11 December 2007 21:38:25 Jiri Slaby wrote:
> > > + if (unlikely(tx_tries0 == 0)) {
> > > + ATH5K_ERR(ah->ah_sc, "zero retries\n");
> > > + WARN_ON(1);
> > > return -EINV
On Tuesday 11 December 2007 21:38:25 Jiri Slaby wrote:
> > + if (unlikely(tx_tries0 == 0)) {
> > + ATH5K_ERR(ah->ah_sc, "zero retries\n");
> > + WARN_ON(1);
> > return -EINVAL;
> > + }
>
> I would just do
> if (WARN_ON(tx_tries0 == 0))
>
By checking it's pci id this seems to be an IBM minipci. It should
work. Did you have any problems with it ?
2007/12/11, Grant Williamson <[EMAIL PROTECTED]>:
> Hi,
> would I be correct in saying that a PCI Express AR5212 168c:1014
> card is not yet supported by ath5k?
>
> Thanks in advance.
>
Hi,
would I be correct in saying that a PCI Express AR5212 168c:1014
card is not yet supported by ath5k?
Thanks in advance.
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Original-Nachricht
> Datum: Tue, 11 Dec 2007 16:22:18 +0530
> Von: Jagadish <[EMAIL PROTECTED]>
> An: ath5k-devel@lists.ath5k.org
> Betreff: [ath5k-devel] athinfo for my atheros card using ath5k driver in
> which "scan is not working"
> Hi,
>
> Thanks for your help on my proble
On Dec 11, 2007 9:07 AM, Bruno Randolf <[EMAIL PROTECTED]> wrote:
> setting up tx descriptors with a rate of zero will put the HW into a mode
> where
> it continously sends noise on the channel, thus blocking the whole channel.
> since it is important to avoid this situation, add a WARN_ON in thes
Hi.
> this is why i created the branch madwifi-trace-0.9.3.
Please add a short description of the new branch to
http://madwifi.org/wiki/DevDocs/Branches
Thanks.
Bye, Mike
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org
hi!
as has been discussed on madwifi lists and tickets, the current HAL version
0.9.30.13 from madwifi-trunk has some performance problems compared to
0.9.18.0 in madwifi-0.9.3 (stable). especially the OFDM sensitivity bug
described at http://madwifi.org/ticket/705 and the fact that we can't sw
Hi,
Thanks for your help on my problem "scan is not working in ath5k driver".
Few days back I posted a mail regarding "scan is not working in ath5k
driver". Now I am sending the ath_info output of my wireless card. I am
also sending lspci -vv output of my card. Please tell me if anybody with
th
hi!
i sent this for review here, before i bother the people at linux-wireless with
it, also since my patches usually seem to need two or three rounds of minor
fix ups ;)
this addresses the issue mentioned on the madwifi lists for ath5k.
bruno
On Tuesday 11 December 2007 17:07:41 Bruno Randolf
setting up tx descriptors with a rate of zero will put the HW into a mode where
it continously sends noise on the channel, thus blocking the whole channel.
since it is important to avoid this situation, add a WARN_ON in these cases,
even if we hope to never get bad rates from the rate control modul
16 matches
Mail list logo
