* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 18:02 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Tobias Schlemmer, linux-wireless
In-Reply-To: <3ace41890908311055s5c49a25fjf69ca48024579d44@mail.gmail.com>
On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
> Schlemmer<keinstein_junior@gmx.net> wrote:
>> Hi,
>>
>> I have some problem with my rtl8187b device. It is included in my laptop
>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>> including 2.6.30 and 2.6.31-rc7.
>
> Hmm, are compat-wireless versioned against kernels?
The stable ones are:
http://wireless.kernel.org/en/users/Download/stable/
Luis
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: John W. Linville @ 2009-08-31 17:45 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Alan Jenkins, Henrique de Moraes Holschuh,
Iñaky Pérez-González, Ivo van Doorn,
Jaswinder Singh Rajput, Michael Buesch, Tomas Winkler
In-Reply-To: <1251303197.15619.29.camel@johannes.local>
On Wed, Aug 26, 2009 at 06:13:17PM +0200, Johannes Berg wrote:
> This header file is copied into userspace tools that
> need not be GPLv2 licensed, make that easier.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Iñaky Pérez-González <inaky.perez-gonzalez@intel.com>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: Michael Buesch <mb@bu3sch.de>
> Cc: Tomas Winkler <tomas.winkler@intel.com>
> ---
> Need ACK from everybody listed who ever touched this
> file according to git. Please?
Michael? Jaswinder?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v2] b43: LP-PHY: Begin implementing calibration & software RFKILL support
From: John W. Linville @ 2009-08-31 17:53 UTC (permalink / raw)
To: Michael Buesch
Cc: Larry Finger, Gábor Stefanik, Mark Huijgen,
Broadcom Wireless, linux-wireless
In-Reply-To: <200908301755.40557.mb@bu3sch.de>
On Sun, Aug 30, 2009 at 05:55:40PM +0200, Michael Buesch wrote:
> On Sunday 30 August 2009 17:10:23 Larry Finger wrote:
> > Michael Buesch wrote:
> > > On Sunday 30 August 2009 02:15:55 Gábor Stefanik wrote:
> > >> static void lpphy_pr41573_workaround(struct b43_wldev *dev)
> > >> {
> > >> struct b43_phy_lp *lpphy = dev->phy.lp;
> > >> @@ -1357,28 +1488,440 @@ static void lpphy_pr41573_workaround(struct b43_wldev *dev)
> > >> b43_lptab_read_bulk(dev, B43_LPTAB32(7, 0x140),
> > >> saved_tab_size, saved_tab);
> > >> }
> > >> + b43_put_phy_into_reset(dev);
> > >
> > > Are you sure you really want this?
> > > This function completely disables the PHY on the backplane and keeps the physical
> > > PHY reset pin asserted (even after return from the function).
> > > So the PHY will physically be powered down from this point on. The following
> > > PHY accesses could even hang the machine, because the PHY won't respond to
> > > register accesses anymore.
> > >
> > > We currently only use this function on A/G Multi-PHY devices to permanently
> > > hard-disable the PHY that's not used.
> >
> > The PHY reset routine in
> > http://bcm-v4.sipsolutions.net/802.11/PHY/Reset, which I just updated
> > for the latest N PHY changes, appears to be a different routine than
> > b43_put_phy_into_reset(). The names are confusing.
>
> b43_put_phy_into_reset() is opencoded in the specifications in various init
> routines. There's no separate specs page for that function.
> But I think the code is straightforward and easy to understand.
So is this patch right or not? Should I hold onto it for 2.6.33
(i.e. after the 2.6.32 merge window)?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [RFC v2 0/5] orinoco: use cfg80211 for key manipulation
From: John W. Linville @ 2009-08-31 17:59 UTC (permalink / raw)
To: David Kilroy; +Cc: linux-wireless, orinoco-devel
In-Reply-To: <1250640253-18434-1-git-send-email-kilroyd@googlemail.com>
On Wed, Aug 19, 2009 at 01:04:08AM +0100, David Kilroy wrote:
> This series basically works (at least after the last patch is applied)
> with wpa_supplicant in wext mode.
>
> I had tested with wpa_supplicant in nl80211 mode, but hadn't realised
> it wasn't using connect - I'll need to pick up Zhu Yis' patch and redo
> some testing.
>
> Anyway, the nl80211 interface has a small hole which patch 5 partially
> papers over. I'm not that happy with the way it hijacks the AUTH/ASSOC
> state machine, but it works.
>
> Other outstanding issues:
> - It looks like I haven't quite got the connect_roamed callback right:
> I've got a WARNING I need to investigate in my logs
> - On disconnecting and reconnecting the card I have to restart
> wpa_supplicant for things to work. I'm guessing I have to look at
> driver shutdown, and ensure we send a disconnected event.
>
> Dave.
Any word on this series? Time is short for 2.6.32...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 17:50 UTC (permalink / raw)
To: Catalin Marinas, John W. Linville, H. Peter Anvin
Cc: linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <43e72e890908310123w5d361ed5tff58a7663044bdcd@mail.gmail.com>
On Mon, Aug 31, 2009 at 1:23 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 3:09 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Fri, Aug 28, 2009 at 2:50 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> On Fri, Aug 28, 2009 at 9:52 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>>> On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas<catalin.marinas@arm.com> wrote:
>>>>> "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>>>>>> I have an assorted collection of kmemleak reports for acpi, ext4 and
>>>>>> tty, not sure how to read these yet to fix so figure I'd at least post
>>>>>> them. To reproduce I can just dd=/dev/zero to some big file and played
>>>>>> some video.
>>>>>
>>>>> If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
>>>>> disappear (i.e. transient false positives)?
>>>>
>>>> Sure, I will once on rc8.
>>>>
>>>>> Which kernel version is this?
>>>>
>>>> v2.6.31-rc7-33172-gf4a9f9a
>>>>
>>>> This is from wireless-testing, which has wireless patches on top of
>>>> rc7. John just rebased to rc8 so will give that a shot at work.
>>>>
>>>>>> unreferenced object 0xffff88003e0015c0 (size 64):
>>>>>> comm "swapper", pid 1, jiffies 4294892352
>>>>>> backtrace:
>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>> [<ffffffff81118a03>] kmem_cache_alloc_node+0x193/0x200
>>>>>> [<ffffffff8152509e>] process_zones+0x70/0x1cd
>>>>>> [<ffffffff81525230>] pageset_cpuup_callback+0x35/0x92
>>>>>> [<ffffffff8152c9b7>] notifier_call_chain+0x47/0x90
>>>>>> [<ffffffff81078549>] __raw_notifier_call_chain+0x9/0x10
>>>>>> [<ffffffff81523f25>] _cpu_up+0x75/0x130
>>>>>> [<ffffffff8152403a>] cpu_up+0x5a/0x6a
>>>>>> [<ffffffff8181969e>] kernel_init+0xcc/0x1ba
>>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>
>>>>> Can't really tell. Maybe a false positive caused by kmemleak not
>>>>> scanning the pgdata node_zones. Can you post your .config file?
>>>>
>>>> Sure, attached.
>>>>
>>>>>> unreferenced object 0xffff88003cb5f700 (size 64):
>>>>>> comm "swapper", pid 1, jiffies 4294892459
>>>>>> backtrace:
>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>>> [<ffffffff812bb549>] kzalloc+0xf/0x11
>>>>>> [<ffffffff812bbb53>] acpi_add_single_object+0x58e/0xd3c
>>>>>> [<ffffffff812bc51c>] acpi_bus_scan+0x125/0x1af
>>>>>> [<ffffffff81842361>] acpi_scan_init+0xc8/0xe9
>>>>>> [<ffffffff8184211c>] acpi_init+0x21f/0x265
>>>>>> [<ffffffff8100a05b>] do_one_initcall+0x4b/0x1b0
>>>>>> [<ffffffff81819736>] kernel_init+0x164/0x1ba
>>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>
>>>>> I get ACPI reports as well and they may be real leaks. However, I
>>>>> didn't have time to analyse the code (pretty complicated reference
>>>>> counting).
>>>>
>>>> Heh OK thanks for reviewing them though.
>>>>
>>>>>> unreferenced object 0xffff880039571800 (size 1024):
>>>>>> comm "exe", pid 1168, jiffies 4294893410
>>>>>> backtrace:
>>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>>> [<ffffffff811e1d71>] ext4_mb_init+0x1a1/0x590
>>>>>> [<ffffffff811d2da3>] ext4_fill_super+0x1df3/0x26c0
>>>>>> [<ffffffff8112774f>] get_sb_bdev+0x16f/0x1b0
>>>>>> [<ffffffff811c8fd3>] ext4_get_sb+0x13/0x20
>>>>>> [<ffffffff81127216>] vfs_kern_mount+0x76/0x180
>>>>>> [<ffffffff8112738d>] do_kern_mount+0x4d/0x130
>>>>>> [<ffffffff8113fc57>] do_mount+0x307/0x8b0
>>>>>> [<ffffffff8114028f>] sys_mount+0x8f/0xe0
>>>>>> [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
>>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>>
>>>>> The ext4 reports are real leaks and patch was posted here -
>>>>> http://lkml.org/lkml/2009/7/15/62. However, it hasn't been merged into
>>>>> mainline yet (I cc'ed Aneesh).
>>>>>
>>>>> The patch is merged in my "kmemleak-fixes" branch on
>>>>> git://linux-arm.org/linux-2.6.git.
>>>>
>>>> Will try to suck them out and try them.
>>>
>>> OK -- tested rc8 + a pull of your tree into mine. The bootup was
>>> really slow and something was just not going right. After a while
>>> memleak complained it had 8 kmemleak logs but I was not able to get my
>>> system usable enough to cat the file.
>>>
>>> In cases like these I wish I would hookup my ctrl-alt-del to kexec() a
>>> safe kernel.
>>>
>>> After a long period of time it seems X wished it would start, it tried
>>> and then flashed back to the tty. This kept repeating in a loop.
>>>
>>> I am not sure if the culprit was rc8 or the kmemleak branch merge --
>>> I'll find out after I boot into rc8 in a few.
>>
>> rc8 busted my bootup, the issues are present with just
>> wireless-testing. I highly doubt the issues are wireless-testing
>> related so I will not bisect there. Since I am unable to get anything
>> useful from the kernel to determine what may have gone sour, any
>> suggestions on a path to bisect, or should I just do the whole tree?
>
> I tried 2.6.31-rc8 from hpa's linux-2.6-allstable.git tree instead of
> Linus [1] as I already had that tree, git describe says:
>
> v2.6.31-rc8-15-gadda766
>
> Testing this would be the same as testing Linus' blessed rc8 --
> correct me I'm wrong. Contrary to what I expected this tree with the
> same config works well!
>
> I have compiled a fresh checkout of wireless-testing origin/master to
> double check the issue and it is indeed only present on
> wireless-testing. A diff stat between John's merge of 2.6.31-rc8 and
> current master branch on wireless-testing [2] doesn't reveal much
> other than wireless specific stuff, as expected, so it seems this may
> after all be introduced in a recent patches in wireless-testing. I
> still find this a bit odd given I see no others reporting major
> issues. My boot doesn't go very far, it stalls for a while after input
> devices are being detected, then it spits out a kmemleak warning about
> 13 kmemleaks. Here's a picture [3]. I didn't bother waiting as I did
> last time for X to try to come up, something is really wrong. I'll
> bisect wireless-testing in the morning, starting with a good marker at
> merge-2009-08-28 as that is when John pulled 2.6.31-rc8 (and I confirm
> a diff stat between that and v2.6.31-rc8 yields nothing as it should)
> and current master as the bad marker. I have 9 steps to go, will leave
> first step compiling overnight.
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
> [2] git diff --stat merge-2009-08-28..HEAD
> [3] http://bombadil.infradead.org/~mcgrof/images/2009/08/lag-wl-2009-08-31.jpg
> [4] git diff --stat merge-2009-08-28..v2.6.31-rc8
Hah, well this makes no sense:
mcgrof@tux ~/wireless-testing (git::(no branch))$ git bisect bad
a4e774ca75e5f2d8347b4d9746a2e0a9a4fc521b is first bad commit
commit a4e774ca75e5f2d8347b4d9746a2e0a9a4fc521b
Author: John W. Linville <linville@tuxdriver.com>
Date: Wed Feb 27 16:04:18 2008 -0500
Add localversion-wireless to identify builds from this tree.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
:000000 100644 0000000000000000000000000000000000000000
6a05d60db3b21d9c0a0b93b831c6ea453dc98785 A localversion-wireless
I'll try a fresh branch on merge-2009-08-28 ..
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Hin-Tak Leung @ 2009-08-31 17:55 UTC (permalink / raw)
To: Tobias Schlemmer; +Cc: linux-wireless
In-Reply-To: <h7eo7q$7ks$1@ger.gmane.org>
On Sun, Aug 30, 2009 at 9:44 PM, Tobias
Schlemmer<keinstein_junior@gmx.net> wrote:
> Hi,
>
> I have some problem with my rtl8187b device. It is included in my laptop
> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
> including 2.6.30 and 2.6.31-rc7.
Hmm, are compat-wireless versioned against kernels? I thought they
just have dates and git describe tags. Could you try the
latest-and-greatest? (the latest and greatest is ahead of 2.6.31-rc7
by a few months)
http://linuxwireless.org/en/users/Download
> The problem is that the network adapter looses the connection to the access
> point at very low distances. It seems to be as if the driver is too
> optimistic about tx power. I monitored the singnal strength on the access
> point (Buffalo running DD-WRT). When I associate the laptop with it the
> recieved signal strength starts full and drops rapidly in the first seconds.
> At the end it is about 0 at a distance of 4m. At this moment no ping will
> arrive the destination. Tests with other access points show similar results.
>
> After several attempts to get different drivers working I used an Ubuntu
> 8.04 boot CD this morning which seems to work out of the box. It has kernel
> 2.6.24 using a module called r8187. I compared these two drivers and got
> much better signal strengths, at least more stable connections. Maybe it's
> interesting that the two drivers report different signal strength
> (compat-wireless reports about 10dBm higher values than the old driver) also
> in signal quality the compat wireless driver seems to be more optimistic.
We are familiar with the r8187 module - what version did Ubuntu ship?
(the module headers are not updated so modinfo is useless). I see you
have the mesh code so that's quite recent.
I have compat-wireless from a few days ago, and iwconfig says - Bit
Rate=11 Mb/s Tx-Power=20 dBm - and I am in a different room from AP,
probably 4m through wall & furniture.
^ permalink raw reply
* Re: Inter 5300 AGN with unsupported EEPROM
From: Larry Finger @ 2009-08-31 17:33 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless
In-Reply-To: <1251737294.13180.4.camel@rc-desk>
Hi Reinette,
reinette chatre wrote:
>
> All production cards are supported by the driver. I thus do not know how
> an unsupported card can be obtained from a reputable dealer. Would it be
> possible to obtain images of both sides of this card showing all numbers
> clearly? You can send this to me off list and I can see if it is
> possible to determine what type of card we are dealing with here.
The info I posted was in error. The computer came from Best Buy, but
he got the card on E-Bay. I'll see what I can do about getting the
pictures.
Thanks for your attention,
Larry
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4)
From: Hin-Tak Leung @ 2009-08-31 17:25 UTC (permalink / raw)
To: Leonardo H. Souza Hamada; +Cc: linux-wireless
In-Reply-To: <4A9BFCCB.6040808@ufra.edu.br>
On Mon, Aug 31, 2009 at 5:39 PM, Leonardo H. Souza
Hamada<leonardo.hamada@ufra.edu.br> wrote:
> Hi list,
>
> On linux-2.6.24-gentoo-r3, the zd1211rw driver was working as eth1.
>
> This is a big-endian machine.
>
> On 2.6.30-gentoo-r5, 'ifconfig -a' shows the relevant entries below:
> Likely is a issue similar reported previously:
> http://marc.info/?l=linux-wireless&m=124906700820860&w=2
>
> Quick peek at the source diffs between previous version reveals some
> changes.
Are you talking about a regression - i.e. it used to work *on the same
architecture*, but not any more? If that's the case you can probably
start with 2.6.24 and various compat-wireless on to narrow down which
changes break. The post you referred to is different - vendor driver
vs rw driver.
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: initialize rate control after station inserted
From: reinette chatre @ 2009-08-31 17:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1251538470.19422.23.camel@johannes.local>
Hi Johannes,
On Sat, 2009-08-29 at 02:34 -0700, Johannes Berg wrote:
> I'd say we do the following: At startup, we program the broadcast STA
> into the device so we always have that, and do that synchronously so if
> that fails for some stupid reason. I think we already do that.
The station management in the driver is not entirely synchronous. That
is, adding a station and removing a station are not the only two
commands affecting the device's station knowledge. The often used "rxon"
command, when used without the association flag, always clears the
station table. This command is used frequently while not associated. So,
knowing when to add the broadcast station is not exact and is the reason
why it is currently done as part of the sending of the rxon command.
What I have been doing as part of testing here was to have a new
"restore stations" call which is called after sending the rxon command
to get device and driver in sync again wrt station management. If we
include something like this in the driver then it will be possible to
implement your proposal to add the broadcast station at the beginning.
> Then, we use a station private area that mac80211 can allocate for us to
> store the STA_ID for each station. Set this to the broadcast STA ID,
> which is always valid in some sense, at sta_notify(add) time. Then,
> asynchronously, tell the device about the station. Once that command
> finishes, look up the sta struct again and set the STA_ID to the new ID
> that we used in the device. This way, a sta struct will always have a
> valid sta ID in it.
>
> Now, when we need to set a key for a station, we actually get the
> station struct. Thus, we can keep two separate flag in the station
> struct that tells us whether the STA_ADD was successful. If this flag is
> unset, then we reject the add_key with -ENOSPC. Or when we detect that
> the key command was too fast after the sta_notify we can wait for the
> ADD_STA to finish in the key notification since that can sleep.
>
> And then rate stuff we can just also do as part of the async sta add
> command, so that the sta ID is only set after we have the sta programmed
> into the device and also initialised rate control properly for it.
> Ultimately the rate control algorithm could do nothing at all, and then
> we can remove it completely.
Thank you very much for these great suggestions. I'll look into this
implementation.
Reinette
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Tobias Schlemmer @ 2009-08-31 16:51 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A9BF11D.1060205@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
Larry Finger schrieb:
> There may be additional info following this.
>
> In looking at my copy of the r8187 driver code, I see some branches
> that may not be in our driver, but I need to see what ID info their
> driver sees.
Hm… the output is attached. It seems not to be very informative to me.
But maybe you can read more.
> Have a good vacation.
Thank you very much.
Tobias
[-- Attachment #2: kernel-log-r8187.txt --]
[-- Type: text/plain, Size: 3503 bytes --]
[ 168.274893] usb 3-1: new high speed USB device using ehci_hcd and address 4
[ 168.414599] usb 3-1: configuration #1 chosen from 1 choice
[ 168.475975] ieee80211_crypt: registered algorithm 'NULL'
[ 168.483909] ieee80211_crypt: registered algorithm 'CCMP'
[ 168.491680] ieee80211_crypt: registered algorithm 'WEP'
[ 168.495562] ieee80211_crypt: registered algorithm 'TKIP'
[ 168.535959] r8187msh: module license 'Proprietary' taints kernel.
[ 168.536038] r8187msh: no version for "notify_wx_assoc_event" found: kernel tainted.
[ 168.558140]
[ 168.558142] Linux kernel driver for RTL8187/RTL8187B based WLAN cards
[ 168.558146] Copyright (c) 2004-2005, Andrea Merello
[ 168.558148] rtl8187: Initializing module
[ 168.558149] rtl8187: Wireless extensions version 22
[ 168.558150] rtl8187: Initializing proc filesystem
[ 168.635246] rtl8187: Reported EEPROM chip is a 93c46 (1Kbit)
[ 168.860244] rtl8187: Card MAC address is 00:16:44:fb:52:6d
[ 169.198241] rtl8187: PAPE from CONFIG2: 0
[ 169.235989] rtl8187: EEPROM Customer ID: 00
[ 169.235990]
[ 169.236472] rtl8187: Driver probe completed
[ 169.236473]
[ 169.236490] usbcore: registered new interface driver rtl8187
[ 286.804391] NET: Registered protocol family 17
[ 287.149124] rtl8187: Card successfully reset
[ 295.619702] WIRELESS_MODE_G
[ 295.690942] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 360.727206] rtl8180_close process
[ 360.727219] rtl8180_down process
[ 360.740307] rtl8187: Mangement RX process aborted due to explicit shutdown
[ 361.191136] rtl8187: Card successfully reset
[ 369.966180] WIRELESS_MODE_G
[ 370.061948] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 370.479245] Linking with deleted
[ 370.636366] Linking with deleted
[ 370.735865] Linking with deleted
[ 373.286377] Linking with deleted
[ 373.345154] Associated successfully
[ 373.345161] Using G rates
[ 373.406594] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 374.169721] alg name:CCMP
[ 376.210329] padlock: VIA PadLock not detected.
[ 376.959471] alg name:TKIP
[ 383.529746] wlan0: no IPv6 routers present
[ 383.817734] rtl8180_close process
[ 383.817741] rtl8180_down process
[ 383.830149] rtl8187: Mangement RX process aborted due to explicit shutdown
[ 384.727525] rtl8187: Card successfully reset
[ 393.528271] WIRELESS_MODE_G
[ 393.598464] Linking with deleted
[ 393.599752] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 393.821712] Linking with deleted
[ 394.014709] Linking with deleted
[ 394.070779] Associated successfully
[ 394.070785] Using G rates
[ 394.128104] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 394.495577] Linking with deleted
[ 394.553274] Associated successfully
[ 394.553280] Using G rates
[ 394.561075] rtl8180_close process
[ 394.561077] rtl8180_down process
[ 394.576644] rtl8187: Mangement RX process aborted due to explicit shutdown
[ 394.992566] rtl8187: Card successfully reset
[ 403.365152] WIRELESS_MODE_G
[ 403.451719] Linking with deleted
[ 403.613717] Linking with deleted
[ 403.675288] Associated successfully
[ 403.675294] Using G rates
[ 403.827342] Linking with deleted
[ 403.983464] Linking with deleted
[ 404.039909] Associated successfully
[ 404.039915] Using G rates
[ 413.531913] wlan0: no IPv6 routers present
[ 419.261156] Linking with deleted
[ 419.409459] Linking with deleted
[ 419.470723] Associated successfully
[ 419.470729] Using G rates
[ 420.238284] alg name:CCMP
[ 420.238308] alg name:TKIP
^ permalink raw reply
* Re: Inter 5300 AGN with unsupported EEPROM
From: reinette chatre @ 2009-08-31 16:48 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4A9B0BF8.3040505@lwfinger.net>
Hi Larry,
On Sun, 2009-08-30 at 16:32 -0700, Larry Finger wrote:
> Most of the thread is useless as the OP wouldn't supply critical data
> and persisted in various rants, but on the 3rd page, he finally
> provided the output of 'dmesg | grep iwl', which was
>
> iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
> iwlagn: Copyright(c) 2003-2008 Intel Corporation
> iwlagn 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> iwlagn 0000:07:00.0: setting latency timer to 64
> iwlagn: Detected Intel Wireless WiFi Link 5300AGN REV=0x24
> iwlagn: Unsuported EEPROM VER=0x114 < 0x11a CALIB=0x3 < 0x4
> iwlagn 0000:07:00.0: PCI INT A disabled
> iwlagn: probe of 0000:07:00.0 failed with error -22
>
> The OP states that this device came from Best Buy. What is the current
> scoop on this EEPROM version?
All production cards are supported by the driver. I thus do not know how
an unsupported card can be obtained from a reputable dealer. Would it be
possible to obtain images of both sides of this card showing all numbers
clearly? You can send this to me off list and I can see if it is
possible to determine what type of card we are dealing with here.
Thank you
Reinette
^ permalink raw reply
* zd1211rw on ppc (iBook G4)
From: Leonardo H. Souza Hamada @ 2009-08-31 16:39 UTC (permalink / raw)
To: linux-wireless
Hi list,
On linux-2.6.24-gentoo-r3, the zd1211rw driver was working as eth1.
This is a big-endian machine.
On 2.6.30-gentoo-r5, 'ifconfig -a' shows the relevant entries below:
wlan0 Link encap:Ethernet HWaddr 00:16:01:D0:11:7D
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wmaster0 Link encap:UNSPEC HWaddr
00-16-01-D0-11-7D-10-00-00-00-00-00-00-00-00-00
[NO FLAGS] MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
dmesg command shows:
usb 1-2: new high speed USB device using ehci_hcd and address 3
usb 1-2: New USB device found, idVendor=0411, idProduct=00da
usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=0
usb 1-2: Product: USB2.0 WLAN
usb 1-2: Manufacturer: Buffalo
usb 1-2: configuration #1 chosen from 1 choice
usb 1-2: reset high speed USB device using ehci_hcd and address 3
phy1: Selected rate control algorithm 'minstrel'
zd1211rw 1-2:1.0: phy1
usb 1-2: firmware: requesting zd1211/zd1211b_ub
usb 1-2: firmware: requesting zd1211/zd1211b_uphr
zd1211rw 1-2:1.0: firmware version 4725
zd1211rw 1-2:1.0: zd1211b chip 0411:00da v4810 high 00-16-01 AL2230S_RF
pa0 g--N-
usb 1-2: firmware: requesting zd1211/zd1211b_ub
usb 1-2: firmware: requesting zd1211/zd1211b_uphr
usb 1-2: firmware: requesting zd1211/zd1211b_ub
usb 1-2: firmware: requesting zd1211/zd1211b_uphr
usb 1-2: USB control request for firmware upload failed. Error number -110
usb 1-2: Could not upload firmware code uph. Error number -110
zd1211rw 1-2:1.0: couldn't load firmware. Error number -110
lsusb shows:
Bus 001 Device 003: ID 0411:00da MelCo., Inc. WLI-U2-KG54L
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bringing it up:
ifconfig wlan0 up
SIOCSIFFLAGS: Connection timed out
DHCP command:
dhcpcd wlan0
dhcpcd: version 5.0.6 starting
dhcpcd: wlan0: interface not found or invalid
Likely is a issue similar reported previously:
http://marc.info/?l=linux-wireless&m=124906700820860&w=2
Quick peek at the source diffs between previous version reveals some
changes.
Regards,
Leonardo
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Jon Loeliger @ 2009-08-31 15:49 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, Bob Copeland, Pavel Roskin, ath5k-devel,
linux-wireless, John W. Linville
In-Reply-To: <43e72e890908272221s39df68abq8e146c2d3566b415@mail.gmail.com>
On Thu, 2009-08-27 at 22:21 -0700, Luis R. Rodriguez wrote:
> > Having multiple drivers won't help users, i thought that MadWiFi was "dead"
> > and we were working on a complete alternative.
>
> MadWifi is dead.
>
> Luis
An interesting pronouncement. Do you mean "Dead to Linux"?
Or "Dead to the world, including FreeBSD"?
jdl
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Larry Finger @ 2009-08-31 15:49 UTC (permalink / raw)
To: Tobias Schlemmer; +Cc: linux-wireless
In-Reply-To: <h7g6rd$dvb$1@ger.gmane.org>
Tobias Schlemmer wrote:
> Hi,
>
> thank you for your quick answer.
>
> Larry Finger schrieb:
>> Tobias Schlemmer wrote:
>>> Interestingly iwconfig always reports TX power of 20dBm, regardless of
>>> the actual tx power, but always a TX rate of 1M. Setting the latter to a
>>> higher value results in packet loss.
>>
>> Where are you located? Your log says you are using the EU regulatory
>> domain; however, that is no longer valid. You should add a line like
>>
>> options cfg80211 ieee80211_regdom=XX
>>
>> to /etc/modprobe.conf.local. From your name, I would guess the XX
>> should be DE.
>
> I guess, too. For some reason it is not corrected in some tutorials.
>
>> It is likely that the 20 dBm is set by mac80211 as the maximum allowed
>> by your local regulations. That value is in fact correct for most
>> locations in the EU.
>
> As far as I know, Germany has a maximum of 100mW, which should be 20dBm,
> if I'm right. This means the driver reports full power though the device
> actually seems to send with much less power. The power gets lost
> somewhere between this display and the antenna. Since there exists a
> working driver, I can hardly expect it on the hardware side.
>
> I've attached the output of iwconfig for the two drivers. The
> proprietary works, the compat-wireless one even failed to authenticate
> (auth timeout) today. I don't know which tx power the proprietary driver
> uses. If you can tell me how to find out, I'll try that.
>
> Some additional information: The automatic rate setting seems to work
> somehow. Last night it grow to 11M for a short time (reporting signal
> stregth of -3dBm).
>
> Maybe, the tx power gets only reduced, but never increased. That's what
> the AP sees.
>
>> My rtl8187b runs at a full 54 Mbs and operates at at least 15 m from
>> my AP. I don't run AP firmware that lets me see the signal strength
>> from the STA.
>
> That dosn't surprise me. The archives don't talk about similar problems.
While you are still available, please provide the dmesg output for the
r8187 (vendor) driver beginning at the point that the USB device is
recognized. With rtl8187, it looks like:
[ 346.940054] usb 1-1: new high speed USB device using ehci_hcd and
address 4
[ 347.086851] usb 1-1: configuration #1 chosen from 1 choice
[ 347.418280] cfg80211: Calling CRDA for country: EU
[ 348.348579] phy0: Selected rate control algorithm 'minstrel'
[ 348.349108] phy0: hwaddr e3c7a080, RTL8187BvE V0 + rtl8225z2
[ 348.349131] usbcore: registered new interface driver rtl8187
There may be additional info following this.
In looking at my copy of the r8187 driver code, I see some branches
that may not be in our driver, but I need to see what ID info their
driver sees.
Have a good vacation.
Larry
^ permalink raw reply
* Re: Ath5k and proprietary extensions
From: Bob Copeland @ 2009-08-31 12:53 UTC (permalink / raw)
To: Nick Kossifidis
Cc: John W. Linville, Luis R. Rodriguez, proski, ath5k-devel,
linux-wireless, ic.felix, Felix Fietkau
In-Reply-To: <40f31dec0908282151t245912f0ye79684d4a519f3c9@mail.gmail.com>
On Sat, Aug 29, 2009 at 07:51:29AM +0300, Nick Kossifidis wrote:
> Most code is there for half/quarter and (static) turbo operation, we
> just have to deal with pll programming, clock settings etc. Question
> is how do we use it, NL80211_CMD_TESTMODE is an option i guess and in
> case no one else thinks that we could use a channel width API (or
> extend what we have) for setting 5/10/40MHz width through cfg80211, we
> can just stick to NL80211_CMD_TESTMODE.
Well, we will have a channel width API, I think; several people
have expresed an interest in doing so.
Your summary is useful, and I really don't have any qualms about
keeping the non-standard stuff as long as someone has plans to
write the code to support it. I personally have no interest
in using those features, but of course I only speak for me.
If we do remove turbo code for now, we can leave the initvals, as
they are such a pain to verify. But I'm not sure half a page of
text is worth the churn.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] ath9k: Do an AHB reset before doing RTC reset
From: Vasanthakumar Thiagarajan @ 2009-08-31 12:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
Doing an RTC reset when DMA is active may corrupt memory,
make sure no DMA is active at this moment by doing an
AHB reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index e340dac..71f27f3 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1712,8 +1712,15 @@ static bool ath9k_hw_set_reset_power_on(struct ath_hw *ah)
REG_WRITE(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_EN |
AR_RTC_FORCE_WAKE_ON_INT);
+ if (!AR_SREV_9100(ah))
+ REG_WRITE(ah, AR_RC, AR_RC_AHB);
+
REG_WRITE(ah, AR_RTC_RESET, 0);
udelay(2);
+
+ if (!AR_SREV_9100(ah))
+ REG_WRITE(ah, AR_RC, 0);
+
REG_WRITE(ah, AR_RTC_RESET, 1);
if (!ath9k_hw_wait(ah,
--
1.5.5.1
^ permalink raw reply related
* Re: rtl8187b Problem with tx level
From: Tobias Schlemmer @ 2009-08-31 9:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A9B0479.209@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
Hi,
thank you for your quick answer.
Larry Finger schrieb:
> Tobias Schlemmer wrote:
>> Interestingly iwconfig always reports TX power of 20dBm, regardless of
>> the actual tx power, but always a TX rate of 1M. Setting the latter to a
>> higher value results in packet loss.
>
> Where are you located? Your log says you are using the EU regulatory
> domain; however, that is no longer valid. You should add a line like
>
> options cfg80211 ieee80211_regdom=XX
>
> to /etc/modprobe.conf.local. From your name, I would guess the XX
> should be DE.
I guess, too. For some reason it is not corrected in some tutorials.
> It is likely that the 20 dBm is set by mac80211 as the maximum allowed
> by your local regulations. That value is in fact correct for most
> locations in the EU.
As far as I know, Germany has a maximum of 100mW, which should be 20dBm,
if I'm right. This means the driver reports full power though the device
actually seems to send with much less power. The power gets lost
somewhere between this display and the antenna. Since there exists a
working driver, I can hardly expect it on the hardware side.
I've attached the output of iwconfig for the two drivers. The
proprietary works, the compat-wireless one even failed to authenticate
(auth timeout) today. I don't know which tx power the proprietary driver
uses. If you can tell me how to find out, I'll try that.
Some additional information: The automatic rate setting seems to work
somehow. Last night it grow to 11M for a short time (reporting signal
stregth of -3dBm).
Maybe, the tx power gets only reduced, but never increased. That's what
the AP sees.
> My rtl8187b runs at a full 54 Mbs and operates at at least 15 m from
> my AP. I don't run AP firmware that lets me see the signal strength
> from the STA.
That dosn't surprise me. The archives don't talk about similar problems.
Tobias
[-- Attachment #2: iwconfig1 --]
[-- Type: text/plain, Size: 1483 bytes --]
wlan0 802.11b/g linked ESSID:"Malter"
Mode:Managed Channel=8 Access Point: 00:17:3F:7E:AB:08
Bit Rate=48 Mb/s
Retry:on Fragment thr:off
Link Quality=72/100 Signal level=-45 dBm Noise level=-102 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
filename: /lib/modules/2.6.24-19-generic/kernel/drivers/nb/r8187.ko
description: Linux driver for Realtek RTL8187 WiFi cards
author: Andrea Merello <andreamrl@tiscali.it>
version: V 1.1
license: GPL
srcversion: CE57E03B376EA9ED408E23E
alias: usb:v0846p6A00d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0846p6100d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp8189d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp8187d*dc*dsc*dp*ic*isc*ip*
depends: usbcore
vermagic: 2.6.24-19-generic SMP mod_unload 586
parm: ifname:charp
parm: devname: Net interface name, wlan%d=default
parm: channels: Channel bitmask for specific locales. NYI (int)
filename: /lib/modules/2.6.24-19-generic/kernel/drivers/nb/r8187msh.ko
description: Linux extension module for Realtek RTL8187 WiFi cards
author: Stanley Chang <changsl@cs.nctu.edu.tw>
version: V 11sD1.0
license: Proprietary
srcversion: 4F5B438A81B73DDF03155C5
depends:
vermagic: 2.6.24-19-generic SMP mod_unload 586
[-- Attachment #3: iwconfig2 --]
[-- Type: text/plain, Size: 2123 bytes --]
wlan0 IEEE 802.11bg ESSID:"Malter"
Mode:Managed Frequency:2.447 GHz Access Point: 00:17:3F:7E:AB:08
Bit Rate=1 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=69/70 Signal level=-41 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
filename: /lib/modules/2.6.28-15-generic/updates/drivers/net/wireless/rtl818x/rtl8187.ko
license: GPL
description: RTL8187/RTL8187B USB wireless driver
author: Larry Finger <Larry.Finger@lwfinger.net>
author: Hin-Tak Leung <htl10@users.sourceforge.net>
author: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
author: Andrea Merello <andreamrl@tiscali.it>
author: Michael Wu <flamingice@sourmilk.net>
srcversion: ACC7FDA7EFE2500D0DC1B50
alias: usb:v1737p0073d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1B75p8187d*dc*dsc*dp*ic*isc*ip*
alias: usb:v18E8p6232d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D1pABE6d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1371p9401d*dc*dsc*dp*ic*isc*ip*
alias: usb:v114Bp0150d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p0028d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p000Dd*dc*dsc*dp*ic*isc*ip*
alias: usb:v03F0pCA02d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0846p4260d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0846p6A00d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0846p6100d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0789p010Cd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0769p11F2d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp8198d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp8197d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp8189d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDAp8187d*dc*dsc*dp*ic*isc*ip*
alias: usb:v050Dp705Ed*dc*dsc*dp*ic*isc*ip*
alias: usb:v0B05p171Dd*dc*dsc*dp*ic*isc*ip*
depends: mac80211,eeprom_93cx6,cfg80211
vermagic: 2.6.28-15-generic SMP mod_unload modversions 586
^ permalink raw reply
* Re: [PATCH] ar9170: added phy register initialisation from eeprom values
From: Chunkeey @ 2009-08-31 9:53 UTC (permalink / raw)
To: Joerg Albert, John W. Linville
Cc: Johannes Berg, linux-wireless@vger.kernel.org
> "Joerg Albert" <jal2@gmx.de> wrote:
>
> This patch adds the initialisation of some PHY registers
> from the modal_header[] values in the EEPROM (see otus/hal/hpmain.c, line 333 ff.)
>
> Signed-off-by: Joerg Albert <jal2@gmx.de>
meh, no hardware... and only a shitty kiosk with web-interface here.
testing has to wait until the weekend.
> diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
> index cb8b5cd..47a5e5c 100644
> --- a/drivers/net/wireless/ath/ar9170/phy.c
> +++ b/drivers/net/wireless/ath/ar9170/phy.c
> @@ -396,6 +396,131 @@ static struct ar9170_phy_init ar5416_phy_init[] = {
> { 0x1c9384, 0xf3307ff0, 0xf3307ff0, 0xf3307ff0, 0xf3307ff0, }
> };
>
> +/* look up a certain register in ar5416_phy_init[] and return the init. value
> + for the band and bandwidth given. Return 0 if register address not found. */
See Documentation/CodingStyle - Chapter 8
The preferred style for long (multi-line) comments is:
/*
* look up a certain register in ar5416_phy_init[] and return the init. value
* for the band and bandwidth given. Return 0 if register address not found.
*/
> +u32 ar9170_get_default_phy_reg_val(int reg, bool is_2ghz, bool is_40mhz)
please consider this instead:
static u32 ar9170_get_default_phy_reg_val(u32 reg, [...])
(static function, and reg is a u32)
> +{
> + struct ar9170_phy_init *p;
> + struct ar9170_phy_init *endp =
> + ar5416_phy_init+ARRAY_SIZE(ar5416_phy_init);
(see Codingstyle: 3.1: Spaces
=> Use one space around (on each side of) most binary [...] operators)
> +
> + for (p = ar5416_phy_init; p < endp; p++)
a extra { } wouldn't hurt. The following statements also has multiple lines.
> + if (p->reg == reg) {
> + if (is_2ghz)
> + return is_40mhz ? p->_2ghz_40 : p->_2ghz_20;
> + else
> + return is_40mhz ? p->_5ghz_40 : p->_5ghz_20;
> + }
> + return 0;
> +}
hmm, it's a bit odd to use pointers over a fixed array,
what about (unfortunately space and line damaged... and untested):
{
unsigned int i;
for (i = 0; i < ARRAY_SIZE(ar5416_phy_init); i++) {
if (ar5416_phy_init[i].reg != reg)
continue;
if (is_2ghz) {
if (is_40mhz)
return ar5416_phy_init[i]._2ghz_40;
else
return ar5416_phy_init[i]._2ghz_20;
} else {
if (is_40mhz)
return ar5416_phy_init[i]._5ghz_40;
else
return ar5416_phy_init[i]._5ghz_20;
}
}
return 0;
}
this follows the looks of the rest of the code. (e.g ar9170_init_phy)
(of course, either version should be fine.
so stay with yours if you have doubts.)
> +/* initialize some phy regs from eeprom values in modal_header[]
> + acc. to band and bandwith */
(multi-line comment, but I guess you know what do here now...)
> +static int ar9170_init_phy_from_eeprom(struct ar9170 *ar,
> + bool is_2ghz, bool is_40mhz)
> +{
> + const u8 xpd2pd[16] = {
> + 0x2, 0x2, 0x2, 0x1, 0x2, 0x2, 0x6, 0x2,
> + 0x2, 0x3, 0x7, 0x2, 0xB, 0x2, 0x2, 0x2
> + };
static const u8 xpd2pd ?
> + u32 defval, newval; /* two separate for debugging the changes */
> + /* pointer to the modal_header acc. to band */
> + struct ar9170_eeprom_modal *m = ar->eeprom.modal_header +
> + (is_2ghz ? 1 : 0);
what about:
struct ar9170_eeprom_modal *m = &ar->eeprom.modal_header[is_2ghz]; ?
> + ar9170_regwrite_begin(ar);
> +
> + /* ant common control (index 0) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5964, is_2ghz, is_40mhz);
> + newval = le32_to_cpu(m->antCtrlCommon);
> + ar9170_regwrite(0x1c5964, newval);
> +
> + /* ant control chain 0 (index 1) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5960, is_2ghz, is_40mhz);
> + newval = le32_to_cpu(m->antCtrlChain[0]);
> + ar9170_regwrite(0x1c5960, newval);
> +
> + /* ant control chain 2 (index 2) */
> + defval = ar9170_get_default_phy_reg_val(0x1c7960, is_2ghz, is_40mhz);
> + newval = le32_to_cpu(m->antCtrlChain[1]);
> + ar9170_regwrite(0x1c7960, newval);
> +
> + /* SwSettle (index 3) */
> + if (!is_40mhz) {
> + defval = ar9170_get_default_phy_reg_val(0x1c5844,
> + is_2ghz, is_40mhz);
> + newval = (defval & ~0x3f80) | ((m->switchSettling & 0x7f)<<7);
(well )<<7 is a bit tight, but it looks like you ran out of space in this line?)
> + ar9170_regwrite(0x1c5844, newval);
> + }
> +
> + /* adcDesired, pdaDesired (index 4) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5850, is_2ghz, is_40mhz);
> + newval = (defval & ~0xffff) | ((u8)m->pgaDesiredSize << 8) |
> + ((u8)m->adcDesiredSize);
> + ar9170_regwrite(0x1c5850, newval);
> +
> + /* TxEndToXpaOff, TxFrameToXpaOn (index 5) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5834, is_2ghz, is_40mhz);
> + newval = (m->txEndToXpaOff << 24) | (m->txEndToXpaOff << 16) |
> + (m->txFrameToXpaOn << 8) | m->txFrameToXpaOn;
> + ar9170_regwrite(0x1c5834, newval);
> +
> + /* TxEndToRxOn (index 6) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5828, is_2ghz, is_40mhz);
> + newval = (defval & ~0xff0000) | (m->txEndToRxOn << 16);
> + ar9170_regwrite(0x1c5828, newval);
> +
> + /* thresh62 (index 7) */
> + defval = ar9170_get_default_phy_reg_val(0x1c8864, is_2ghz, is_40mhz);
> + newval = (defval & ~0x7f000) | (m->thresh62 << 12);
> + ar9170_regwrite(0x1c8864, newval);
> +
> + /* tx/rx attenuation chain 0 (index 8) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5848, is_2ghz, is_40mhz);
> + newval = (defval & ~0x3f000) | ((m->txRxAttenCh[0] & 0x3f) << 12);
> + ar9170_regwrite(0x1c5848, newval);
> +
> + /* tx/rx attenuation chain 2 (index 9) */
> + defval = ar9170_get_default_phy_reg_val(0x1c7848, is_2ghz, is_40mhz);
> + newval = (defval & ~0x3f000) | ((m->txRxAttenCh[1] & 0x3f) << 12);
> + ar9170_regwrite(0x1c7848, newval);
> +
> + /* tx/rx margin chain 0 (index 10) */
> + defval = ar9170_get_default_phy_reg_val(0x1c620c, is_2ghz, is_40mhz);
> + newval = (defval & ~0xfc0000) | ((m->rxTxMarginCh[0] & 0x3f) << 18);
> + /* bsw margin chain 0 for 5GHz only */
> + if (!is_2ghz)
> + newval = (newval & ~0x3c00) | ((m->bswMargin[0] & 0xf) << 10);
> + ar9170_regwrite(0x1c620c, newval);
> +
> + /* tx/rx margin chain 2 (index 11) */
> + defval = ar9170_get_default_phy_reg_val(0x1c820c, is_2ghz, is_40mhz);
> + newval = (defval & ~0xfc0000) | ((m->rxTxMarginCh[1] & 0x3f) << 18);
> + ar9170_regwrite(0x1c820c, newval);
> +
> + /* iqCall, iqCallq chain 0 (index 12) */
> + defval = ar9170_get_default_phy_reg_val(0x1c5920, is_2ghz, is_40mhz);
> + newval = (defval & ~0x7ff) | (((u8)m->iqCalICh[0] & 0x3f) << 5) |
> + ((u8)m->iqCalQCh[0] & 0x1f);
> + ar9170_regwrite(0x1c5920, newval);
> +
> + /* iqCall, iqCallq chain 2 (index 13) */
> + defval = ar9170_get_default_phy_reg_val(0x1c7920, is_2ghz, is_40mhz);
> + newval = (defval & ~0x7ff) | (((u8)m->iqCalICh[1] & 0x3f) << 5) |
> + ((u8)m->iqCalQCh[1] & 0x1f);
> + ar9170_regwrite(0x1c7920, newval);
> +
> + /* xpd gain mask (index 14) */
> + defval = ar9170_get_default_phy_reg_val(0x1c6258, is_2ghz, is_40mhz);
> + newval = (defval & ~0xf0000) | (xpd2pd[m->xpdGain & 0xf] << 16);
> + ar9170_regwrite(0x1c6258, newval);
(cannot test this now. it looks good, though.)
It's amazing how much **** you can _cut_ from the vendor driver.
BTW: does this patch help the 1-stage fw stability, or is it still broken?
Regards,
Chr
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 8:23 UTC (permalink / raw)
To: Catalin Marinas, John W. Linville, H. Peter Anvin
Cc: linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <43e72e890908281509o44930348w581b865107ea3e98@mail.gmail.com>
On Fri, Aug 28, 2009 at 3:09 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 2:50 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Fri, Aug 28, 2009 at 9:52 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> On Fri, Aug 28, 2009 at 9:32 AM, Catalin Marinas<catalin.marinas@arm.com> wrote:
>>>> "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>>>>> I have an assorted collection of kmemleak reports for acpi, ext4 and
>>>>> tty, not sure how to read these yet to fix so figure I'd at least post
>>>>> them. To reproduce I can just dd=/dev/zero to some big file and played
>>>>> some video.
>>>>
>>>> If you do a few echo scan > /sys/kernel/debug/kmemleak, do they
>>>> disappear (i.e. transient false positives)?
>>>
>>> Sure, I will once on rc8.
>>>
>>>> Which kernel version is this?
>>>
>>> v2.6.31-rc7-33172-gf4a9f9a
>>>
>>> This is from wireless-testing, which has wireless patches on top of
>>> rc7. John just rebased to rc8 so will give that a shot at work.
>>>
>>>>> unreferenced object 0xffff88003e0015c0 (size 64):
>>>>> comm "swapper", pid 1, jiffies 4294892352
>>>>> backtrace:
>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>> [<ffffffff81118a03>] kmem_cache_alloc_node+0x193/0x200
>>>>> [<ffffffff8152509e>] process_zones+0x70/0x1cd
>>>>> [<ffffffff81525230>] pageset_cpuup_callback+0x35/0x92
>>>>> [<ffffffff8152c9b7>] notifier_call_chain+0x47/0x90
>>>>> [<ffffffff81078549>] __raw_notifier_call_chain+0x9/0x10
>>>>> [<ffffffff81523f25>] _cpu_up+0x75/0x130
>>>>> [<ffffffff8152403a>] cpu_up+0x5a/0x6a
>>>>> [<ffffffff8181969e>] kernel_init+0xcc/0x1ba
>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>
>>>> Can't really tell. Maybe a false positive caused by kmemleak not
>>>> scanning the pgdata node_zones. Can you post your .config file?
>>>
>>> Sure, attached.
>>>
>>>>> unreferenced object 0xffff88003cb5f700 (size 64):
>>>>> comm "swapper", pid 1, jiffies 4294892459
>>>>> backtrace:
>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>> [<ffffffff812bb549>] kzalloc+0xf/0x11
>>>>> [<ffffffff812bbb53>] acpi_add_single_object+0x58e/0xd3c
>>>>> [<ffffffff812bc51c>] acpi_bus_scan+0x125/0x1af
>>>>> [<ffffffff81842361>] acpi_scan_init+0xc8/0xe9
>>>>> [<ffffffff8184211c>] acpi_init+0x21f/0x265
>>>>> [<ffffffff8100a05b>] do_one_initcall+0x4b/0x1b0
>>>>> [<ffffffff81819736>] kernel_init+0x164/0x1ba
>>>>> [<ffffffff810130ca>] child_rip+0xa/0x20
>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>
>>>> I get ACPI reports as well and they may be real leaks. However, I
>>>> didn't have time to analyse the code (pretty complicated reference
>>>> counting).
>>>
>>> Heh OK thanks for reviewing them though.
>>>
>>>>> unreferenced object 0xffff880039571800 (size 1024):
>>>>> comm "exe", pid 1168, jiffies 4294893410
>>>>> backtrace:
>>>>> [<ffffffff81121fad>] create_object+0x13d/0x2d0
>>>>> [<ffffffff81122265>] kmemleak_alloc+0x25/0x60
>>>>> [<ffffffff81119f3b>] __kmalloc+0x16b/0x250
>>>>> [<ffffffff811e1d71>] ext4_mb_init+0x1a1/0x590
>>>>> [<ffffffff811d2da3>] ext4_fill_super+0x1df3/0x26c0
>>>>> [<ffffffff8112774f>] get_sb_bdev+0x16f/0x1b0
>>>>> [<ffffffff811c8fd3>] ext4_get_sb+0x13/0x20
>>>>> [<ffffffff81127216>] vfs_kern_mount+0x76/0x180
>>>>> [<ffffffff8112738d>] do_kern_mount+0x4d/0x130
>>>>> [<ffffffff8113fc57>] do_mount+0x307/0x8b0
>>>>> [<ffffffff8114028f>] sys_mount+0x8f/0xe0
>>>>> [<ffffffff81011f02>] system_call_fastpath+0x16/0x1b
>>>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>>
>>>> The ext4 reports are real leaks and patch was posted here -
>>>> http://lkml.org/lkml/2009/7/15/62. However, it hasn't been merged into
>>>> mainline yet (I cc'ed Aneesh).
>>>>
>>>> The patch is merged in my "kmemleak-fixes" branch on
>>>> git://linux-arm.org/linux-2.6.git.
>>>
>>> Will try to suck them out and try them.
>>
>> OK -- tested rc8 + a pull of your tree into mine. The bootup was
>> really slow and something was just not going right. After a while
>> memleak complained it had 8 kmemleak logs but I was not able to get my
>> system usable enough to cat the file.
>>
>> In cases like these I wish I would hookup my ctrl-alt-del to kexec() a
>> safe kernel.
>>
>> After a long period of time it seems X wished it would start, it tried
>> and then flashed back to the tty. This kept repeating in a loop.
>>
>> I am not sure if the culprit was rc8 or the kmemleak branch merge --
>> I'll find out after I boot into rc8 in a few.
>
> rc8 busted my bootup, the issues are present with just
> wireless-testing. I highly doubt the issues are wireless-testing
> related so I will not bisect there. Since I am unable to get anything
> useful from the kernel to determine what may have gone sour, any
> suggestions on a path to bisect, or should I just do the whole tree?
I tried 2.6.31-rc8 from hpa's linux-2.6-allstable.git tree instead of
Linus [1] as I already had that tree, git describe says:
v2.6.31-rc8-15-gadda766
Testing this would be the same as testing Linus' blessed rc8 --
correct me I'm wrong. Contrary to what I expected this tree with the
same config works well!
I have compiled a fresh checkout of wireless-testing origin/master to
double check the issue and it is indeed only present on
wireless-testing. A diff stat between John's merge of 2.6.31-rc8 and
current master branch on wireless-testing [2] doesn't reveal much
other than wireless specific stuff, as expected, so it seems this may
after all be introduced in a recent patches in wireless-testing. I
still find this a bit odd given I see no others reporting major
issues. My boot doesn't go very far, it stalls for a while after input
devices are being detected, then it spits out a kmemleak warning about
13 kmemleaks. Here's a picture [3]. I didn't bother waiting as I did
last time for X to try to come up, something is really wrong. I'll
bisect wireless-testing in the morning, starting with a good marker at
merge-2009-08-28 as that is when John pulled 2.6.31-rc8 (and I confirm
a diff stat between that and v2.6.31-rc8 yields nothing as it should)
and current master as the bad marker. I have 9 steps to go, will leave
first step compiling overnight.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
[2] git diff --stat merge-2009-08-28..HEAD
[3] http://bombadil.infradead.org/~mcgrof/images/2009/08/lag-wl-2009-08-31.jpg
[4] git diff --stat merge-2009-08-28..v2.6.31-rc8
Luis
^ permalink raw reply
* [PATCH] wireless: hostap, fix oops due to early probing interrupt
From: Tim Gardner @ 2009-08-31 2:18 UTC (permalink / raw)
To: j; +Cc: linux-wireless
Jouni,
Did this ever get sent to you?
rtg
---------------------------------
>From a72eaafae9186632add4ed01a340b4f1b39cc672 Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king@canonical.com>
Date: Wed, 19 Aug 2009 15:39:21 +0100
Subject: [PATCH] wireless: hostap, fix oops due to early probing interrupt
BugLink: https://bugs.launchpad.net/ubuntu/+bug/254837
Spurious shared interrupts or early probing interrupts can cause the
hostap interrupt handler to oops before the driver has fully configured
the IO base port addresses. In some cases the oops can be because
the hardware shares an interrupt line, on other cases it is due to a
race condition between probing for the hardware and configuring
the IO base port. The latter occurs because the probing is required to
determin the hardware port address which is only determined when the probe
can interrupt the hardware (catch 22).
This patch catches this pre-configured condition to avoid the oops.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
---
drivers/net/wireless/hostap/hostap_hw.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_hw.c b/drivers/net/wireless/hostap/hostap_hw.c
index d4d857e..0212ee3 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -2628,6 +2628,15 @@ static irqreturn_t prism2_interrupt(int irq, void *dev_id)
int events = 0;
u16 ev;
+ /* Detect early interrupt before driver is fully configued */
+ if (!dev->base_addr) {
+ if (net_ratelimit()) {
+ printk(KERN_DEBUG "%s: Interrupt, but dev not configured\n",
+ dev->name);
+ }
+ return IRQ_HANDLED;
+ }
+
iface = netdev_priv(dev);
local = iface->local;
--
1.6.2.4
^ permalink raw reply related
* Inter 5300 AGN with unsupported EEPROM
From: Larry Finger @ 2009-08-30 23:32 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless
Reinette,
While helping on the openSUSE wireless forum, I ran across another
unit with the same unsupported EEPROM as in the thread at
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1997.
The thread at openSUSE is at
http://forums.opensuse.org/network-internet/wireless/420589-intel-5300-wifi-minipci-card-asus-g71gx-rx05-bestbuy-3.html
Most of the thread is useless as the OP wouldn't supply critical data
and persisted in various rants, but on the 3rd page, he finally
provided the output of 'dmesg | grep iwl', which was
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
iwlagn: Copyright(c) 2003-2008 Intel Corporation
iwlagn 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:07:00.0: setting latency timer to 64
iwlagn: Detected Intel Wireless WiFi Link 5300AGN REV=0x24
iwlagn: Unsuported EEPROM VER=0x114 < 0x11a CALIB=0x3 < 0x4
iwlagn 0000:07:00.0: PCI INT A disabled
iwlagn: probe of 0000:07:00.0 failed with error -22
The OP states that this device came from Best Buy. What is the current
scoop on this EEPROM version?
Thanks,
Larry
^ permalink raw reply
* [PATCH] ar9170: added phy register initialisation from eeprom values
From: Joerg Albert @ 2009-08-30 23:15 UTC (permalink / raw)
To: Christian Lamparter, John W. Linville
Cc: Johannes Berg, linux-wireless@vger.kernel.org
This patch adds the initialisation of some PHY registers
from the modal_header[] values in the EEPROM (see otus/hal/hpmain.c, line 333 ff.)
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
drivers/net/wireless/ath/ar9170/phy.c | 129 ++++++++++++++++++++++++++++++++-
1 files changed, 128 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
index cb8b5cd..47a5e5c 100644
--- a/drivers/net/wireless/ath/ar9170/phy.c
+++ b/drivers/net/wireless/ath/ar9170/phy.c
@@ -396,6 +396,131 @@ static struct ar9170_phy_init ar5416_phy_init[] = {
{ 0x1c9384, 0xf3307ff0, 0xf3307ff0, 0xf3307ff0, 0xf3307ff0, }
};
+/* look up a certain register in ar5416_phy_init[] and return the init. value
+ for the band and bandwidth given. Return 0 if register address not found. */
+u32 ar9170_get_default_phy_reg_val(int reg, bool is_2ghz, bool is_40mhz)
+{
+ struct ar9170_phy_init *p;
+ struct ar9170_phy_init *endp =
+ ar5416_phy_init+ARRAY_SIZE(ar5416_phy_init);
+
+ for (p = ar5416_phy_init; p < endp; p++)
+ if (p->reg == reg) {
+ if (is_2ghz)
+ return is_40mhz ? p->_2ghz_40 : p->_2ghz_20;
+ else
+ return is_40mhz ? p->_5ghz_40 : p->_5ghz_20;
+ }
+ return 0;
+}
+
+/* initialize some phy regs from eeprom values in modal_header[]
+ acc. to band and bandwith */
+static int ar9170_init_phy_from_eeprom(struct ar9170 *ar,
+ bool is_2ghz, bool is_40mhz)
+{
+ const u8 xpd2pd[16] = {
+ 0x2, 0x2, 0x2, 0x1, 0x2, 0x2, 0x6, 0x2,
+ 0x2, 0x3, 0x7, 0x2, 0xB, 0x2, 0x2, 0x2
+ };
+ u32 defval, newval; /* two separate for debugging the changes */
+ /* pointer to the modal_header acc. to band */
+ struct ar9170_eeprom_modal *m = ar->eeprom.modal_header +
+ (is_2ghz ? 1 : 0);
+
+ ar9170_regwrite_begin(ar);
+
+ /* ant common control (index 0) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5964, is_2ghz, is_40mhz);
+ newval = le32_to_cpu(m->antCtrlCommon);
+ ar9170_regwrite(0x1c5964, newval);
+
+ /* ant control chain 0 (index 1) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5960, is_2ghz, is_40mhz);
+ newval = le32_to_cpu(m->antCtrlChain[0]);
+ ar9170_regwrite(0x1c5960, newval);
+
+ /* ant control chain 2 (index 2) */
+ defval = ar9170_get_default_phy_reg_val(0x1c7960, is_2ghz, is_40mhz);
+ newval = le32_to_cpu(m->antCtrlChain[1]);
+ ar9170_regwrite(0x1c7960, newval);
+
+ /* SwSettle (index 3) */
+ if (!is_40mhz) {
+ defval = ar9170_get_default_phy_reg_val(0x1c5844,
+ is_2ghz, is_40mhz);
+ newval = (defval & ~0x3f80) | ((m->switchSettling & 0x7f)<<7);
+ ar9170_regwrite(0x1c5844, newval);
+ }
+
+ /* adcDesired, pdaDesired (index 4) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5850, is_2ghz, is_40mhz);
+ newval = (defval & ~0xffff) | ((u8)m->pgaDesiredSize << 8) |
+ ((u8)m->adcDesiredSize);
+ ar9170_regwrite(0x1c5850, newval);
+
+ /* TxEndToXpaOff, TxFrameToXpaOn (index 5) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5834, is_2ghz, is_40mhz);
+ newval = (m->txEndToXpaOff << 24) | (m->txEndToXpaOff << 16) |
+ (m->txFrameToXpaOn << 8) | m->txFrameToXpaOn;
+ ar9170_regwrite(0x1c5834, newval);
+
+ /* TxEndToRxOn (index 6) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5828, is_2ghz, is_40mhz);
+ newval = (defval & ~0xff0000) | (m->txEndToRxOn << 16);
+ ar9170_regwrite(0x1c5828, newval);
+
+ /* thresh62 (index 7) */
+ defval = ar9170_get_default_phy_reg_val(0x1c8864, is_2ghz, is_40mhz);
+ newval = (defval & ~0x7f000) | (m->thresh62 << 12);
+ ar9170_regwrite(0x1c8864, newval);
+
+ /* tx/rx attenuation chain 0 (index 8) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5848, is_2ghz, is_40mhz);
+ newval = (defval & ~0x3f000) | ((m->txRxAttenCh[0] & 0x3f) << 12);
+ ar9170_regwrite(0x1c5848, newval);
+
+ /* tx/rx attenuation chain 2 (index 9) */
+ defval = ar9170_get_default_phy_reg_val(0x1c7848, is_2ghz, is_40mhz);
+ newval = (defval & ~0x3f000) | ((m->txRxAttenCh[1] & 0x3f) << 12);
+ ar9170_regwrite(0x1c7848, newval);
+
+ /* tx/rx margin chain 0 (index 10) */
+ defval = ar9170_get_default_phy_reg_val(0x1c620c, is_2ghz, is_40mhz);
+ newval = (defval & ~0xfc0000) | ((m->rxTxMarginCh[0] & 0x3f) << 18);
+ /* bsw margin chain 0 for 5GHz only */
+ if (!is_2ghz)
+ newval = (newval & ~0x3c00) | ((m->bswMargin[0] & 0xf) << 10);
+ ar9170_regwrite(0x1c620c, newval);
+
+ /* tx/rx margin chain 2 (index 11) */
+ defval = ar9170_get_default_phy_reg_val(0x1c820c, is_2ghz, is_40mhz);
+ newval = (defval & ~0xfc0000) | ((m->rxTxMarginCh[1] & 0x3f) << 18);
+ ar9170_regwrite(0x1c820c, newval);
+
+ /* iqCall, iqCallq chain 0 (index 12) */
+ defval = ar9170_get_default_phy_reg_val(0x1c5920, is_2ghz, is_40mhz);
+ newval = (defval & ~0x7ff) | (((u8)m->iqCalICh[0] & 0x3f) << 5) |
+ ((u8)m->iqCalQCh[0] & 0x1f);
+ ar9170_regwrite(0x1c5920, newval);
+
+ /* iqCall, iqCallq chain 2 (index 13) */
+ defval = ar9170_get_default_phy_reg_val(0x1c7920, is_2ghz, is_40mhz);
+ newval = (defval & ~0x7ff) | (((u8)m->iqCalICh[1] & 0x3f) << 5) |
+ ((u8)m->iqCalQCh[1] & 0x1f);
+ ar9170_regwrite(0x1c7920, newval);
+
+ /* xpd gain mask (index 14) */
+ defval = ar9170_get_default_phy_reg_val(0x1c6258, is_2ghz, is_40mhz);
+ newval = (defval & ~0xf0000) | (xpd2pd[m->xpdGain & 0xf] << 16);
+ ar9170_regwrite(0x1c6258, newval);
+
+
+ ar9170_regwrite_finish();
+
+ return ar9170_regwrite_result();
+}
+
int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
{
int i, err;
@@ -426,7 +551,9 @@ int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
if (err)
return err;
- /* XXX: use EEPROM data here! */
+ err = ar9170_init_phy_from_eeprom(ar, is_2ghz, is_40mhz);
+ if (err)
+ return err;
err = ar9170_init_power_cal(ar);
if (err)
--
1.6.0.4
^ permalink raw reply related
* Re: rtl8187b Problem with tx level
From: Larry Finger @ 2009-08-30 23:00 UTC (permalink / raw)
To: Tobias Schlemmer; +Cc: linux-wireless
In-Reply-To: <h7eo7q$7ks$1@ger.gmane.org>
Tobias Schlemmer wrote:
>
> Interestingly iwconfig always reports TX power of 20dBm, regardless of
> the actual tx power, but always a TX rate of 1M. Setting the latter to a
> higher value results in packet loss.
Where are you located? Your log says you are using the EU regulatory
domain; however, that is no longer valid. You should add a line like
options cfg80211 ieee80211_regdom=XX
to /etc/modprobe.conf.local. From your name, I would guess the XX
should be DE.
It is likely that the 20 dBm is set by mac80211 as the maximum allowed
by your local regulations. That value is in fact correct for most
locations in the EU.
My rtl8187b runs at a full 54 Mbs and operates at at least 15 m from
my AP. I don't run AP firmware that lets me see the signal strength
from the STA.
^ permalink raw reply
* Re: [PATCH -next] ipw2200: fix kconfig dependencies
From: John W. Linville @ 2009-08-30 22:35 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-wireless, ipw2100-devel, akpm
In-Reply-To: <4A9ADFA1.5030706@oracle.com>
On Sun, Aug 30, 2009 at 01:22:57PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix kconfig dependencies for ipw2x00 drivers, fixes build errors:
>
> ERROR: "wiphy_free" [drivers/net/wireless/ipw2x00/libipw.ko] undefined!
> ERROR: "wiphy_unregister" [drivers/net/wireless/ipw2x00/libipw.ko] undefined!
> ERROR: "wiphy_new" [drivers/net/wireless/ipw2x00/libipw.ko] undefined!
> ERROR: "cfg80211_wext_giwname" [drivers/net/wireless/ipw2x00/ipw2200.ko] undefined!
> ERROR: "wiphy_register" [drivers/net/wireless/ipw2x00/ipw2200.ko] undefined!
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Oops! My bad...thanks, Randy!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* rtl8187b Problem with tx level
From: Tobias Schlemmer @ 2009-08-30 20:44 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
Hi,
I have some problem with my rtl8187b device. It is included in my laptop
running Ubuntu linux 2.6.28. I've tested several compat-wireless
releases including 2.6.30 and 2.6.31-rc7.
The problem is that the network adapter looses the connection to the
access point at very low distances. It seems to be as if the driver is
too optimistic about tx power. I monitored the singnal strength on the
access point (Buffalo running DD-WRT). When I associate the laptop with
it the recieved signal strength starts full and drops rapidly in the
first seconds. At the end it is about 0 at a distance of 4m. At this
moment no ping will arrive the destination. Tests with other access
points show similar results.
After several attempts to get different drivers working I used an Ubuntu
8.04 boot CD this morning which seems to work out of the box. It has
kernel 2.6.24 using a module called r8187. I compared these two drivers
and got much better signal strengths, at least more stable connections.
Maybe it's interesting that the two drivers report different signal
strength (compat-wireless reports about 10dBm higher values than the old
driver) also in signal quality the compat wireless driver seems to be
more optimistic.
Interestingly iwconfig always reports TX power of 20dBm, regardless of
the actual tx power, but always a TX rate of 1M. Setting the latter to a
higher value results in packet loss.
As I leave for holidays on Tuesday I can give further information only
tomorrow and in two weeks.
Tobias
[-- Attachment #2: eventlog --]
[-- Type: text/plain, Size: 3844 bytes --]
Log of iw event -t
Sun Aug 30 21:26:57 2009
iwdied with signal 2
Sun Aug 30 21:27:22 2009
----------------
1251660460.087134: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660481.753561: wlan0 (phy #0): disassoc 00:16:44:fb:52:6c -> 00:17:3f:7e:ab:08 reason 1: Unspecified
1251660486.831135: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660487.041865: wlan0 (phy #0): auth 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
1251660487.050600: wlan0 (phy #0): assoc 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
1251660588.213505: wlan0 (phy #0): deauth 00:16:44:fb:52:6c -> 00:17:3f:7e:ab:08 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS
1251660600.900453: wlan0 (phy #0): scan aborted: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660607.237699: wlan0 (phy #0): disassoc 00:16:44:fb:52:6c -> 00:17:3f:7e:ab:08 reason 1: Unspecified
1251660613.427166: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660614.348485: wlan0 (phy #0): auth: timed out
1251660620.263160: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660621.152487: wlan0 (phy #0): auth: timed out
1251660626.311193: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660627.200489: wlan0 (phy #0): auth: timed out
1251660632.359167: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660633.248491: wlan0 (phy #0): auth: timed out
1251660638.415165: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660639.304490: wlan0 (phy #0): auth: timed out
1251660644.467730: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660645.356493: wlan0 (phy #0): auth: timed out
1251660650.519172: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660651.419254: wlan0 (phy #0): auth: timed out
1251660656.587182: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660657.512517: wlan0 (phy #0): auth: timed out
1251660662.655181: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660663.532509: wlan0 (phy #0): auth: timed out
1251660668.711181: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660669.588513: wlan0 (phy #0): auth: timed out
1251660674.779164: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660675.656519: wlan0 (phy #0): auth: timed out
1251660680.943163: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660681.836528: wlan0 (phy #0): auth: timed out
1251660686.879163: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660687.768520: wlan0 (phy #0): auth: timed out
1251660692.927168: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660693.816525: wlan0 (phy #0): auth: timed out
1251660698.975165: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660699.400865: wlan0 (phy #0): auth 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
1251660699.412964: wlan0 (phy #0): assoc 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
[-- Attachment #3: kernel-short.log --]
[-- Type: text/x-log, Size: 3813 bytes --]
[ 346.940054] usb 1-1: new high speed USB device using ehci_hcd and address 4
[ 347.086851] usb 1-1: configuration #1 chosen from 1 choice
[ 347.418280] cfg80211: Calling CRDA for country: EU
[ 348.348579] phy0: Selected rate control algorithm 'minstrel'
[ 348.349108] phy0: hwaddr e3c7a080, RTL8187BvE V0 + rtl8225z2
[ 348.349131] usbcore: registered new interface driver rtl8187
[ 361.807409] phy0: device now idle
[ 361.878423] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 361.893826] phy0: device no longer idle - scanning
[ 364.225226] phy0: device now idle
[ 364.806379] phy0: device no longer idle - scanning
[ 366.893227] phy0: device now idle
[ 390.835706] phy0: device no longer idle - scanning
[ 392.917362] phy0: device now idle
[ 412.002426] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 412.371061] phy0: device no longer idle - scanning
[ 414.498373] wlan0: authenticate with AP e3c7b708
[ 414.498397] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
[ 414.499742] phy0: device now idle
[ 417.572157] phy0: device no longer idle - scanning
[ 419.649259] phy0: device now idle
[ 419.718250] phy0: device no longer idle - in use
[ 419.785249] wlan0: authenticate with AP e3c7b708
[ 419.786755] wlan0: authenticated
[ 419.786756] wlan0: associate with AP e3c7b708
[ 419.789134] wlan0: RX AssocResp from e3f8201a (capab=0x411 status=0 aid=3)
[ 419.789138] wlan0: associated
[ 419.789142] phy0: Allocated STA e3c00a08
[ 419.789403] phy0: Inserted STA e3c00a08
[ 419.790372] wlan0: switched to short barker preamble (BSSID=e3c7b708)
[ 419.790374] wlan0: switched to short slot time (BSSID=e3c7b708)
[ 419.795862] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 420.664625] padlock: VIA PadLock not detected.
[ 426.992527] wlan0: setting MTU 1492
[ 429.796020] wlan0: no IPv6 routers present
[ 465.032820] usb 2-2: USB disconnect, address 2
[ 520.958259] wlan0: deauthenticating by local choice (reason=3)
[ 520.959293] phy0: device now idle
[ 521.037304] phy0: Removed STA e3c00a08
[ 521.037411] phy0: Destroyed STA e3c00a08
[ 524.902800] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 533.450798] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 533.452844] phy0: device no longer idle - scanning
[ 533.645340] phy0: device now idle
[ 537.890760] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 537.890876] phy0: device no longer idle - scanning
[ 539.982438] wlan0: direct probe to AP e3c7b708 try 1
[ 539.982476] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
[ 539.983926] phy0: device now idle
[ 543.973724] phy0: device no longer idle - scanning
[ 546.270791] phy0: device now idle
[ 546.358314] phy0: device no longer idle - in use
[ 546.425311] wlan0: direct probe to AP e3c7b708 try 1
[ 546.624050] wlan0: direct probe to AP e3c7b708 try 2
[ 546.824039] wlan0: direct probe to AP e3c7b708 try 3
[ 547.024037] wlan0: direct probe to AP e3c7b708 timed out
[ 547.024044] phy0: device now idle
[ 551.030732] phy0: device no longer idle - scanning
[ 553.093323] phy0: device now idle
[ 553.162315] phy0: device no longer idle - in use
[ 553.229316] wlan0: direct probe to AP e3c7b708 try 1
[ 553.428042] wlan0: direct probe to AP e3c7b708 try 2
[ 553.628037] wlan0: direct probe to AP e3c7b708 try 3
[ 553.828036] wlan0: direct probe to AP e3c7b708 timed out
[ 553.828043] phy0: device now idle
[ 557.082433] phy0: device no longer idle - scanning
[ 559.141327] phy0: device now idle
[ 559.210312] phy0: device no longer idle - in use
[ 559.277319] wlan0: direct probe to AP e3c7b708 try 1
[ 559.476045] wlan0: direct probe to AP e3c7b708 try 2
[ 559.676044] wlan0: direct probe to AP e3c7b708 try 3
[ 559.876044] wlan0: direct probe to AP e3c7b708 timed out
[-- Attachment #4: lsusb --]
[-- Type: text/plain, Size: 5080 bytes --]
Bus 001 Device 004: ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x8189 RTL8187B Wireless 802.11g 54Mbps Network Adapter
bcdDevice 2.00
iManufacturer 1 Manufacturer_Realtek
iProduct 2
iSerial 3 00e04c000001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 81
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 Wireless Network Card
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 9
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07 EP 7 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0a EP 10 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0b EP 11 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0c EP 12 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox