* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Inaky Perez-Gonzalez @ 2009-08-31 20:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311225r3b0d80bcqcb3e3e11d81a255e@mail.gmail.com>
On Mon, 2009-08-31 at 13:25 -0600, Luis R. Rodriguez wrote:
> OK not so bad except for:
>
> > kernel/net/wimax/wimax.ko
>
> That's touching another subsystem but we could technically merge wimax
> into compat-wireless if Inaky thinks that's a good idea. the point
> here is to unify anything that uses rfkill for backport usage.
Oh boy, can of worms
I have my own compat-wimax already, which already handles things for
backwards compat (many #ifdef hacks to simplify life) and which is
heavily used internally.
I don't really know how much worth it might be and I know I don't have
resources to support both.
> > If everything that depends on rkill is bundled with
> > compat-wireless, there is probablt no need for the symbol and sysfs
> > renaming hacks.
>
> Right which is why I think this may be reasonable to do. Any thoughts Inaky?
> Luis
--
-- Inaky
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Marcel Holtmann @ 2009-08-31 20:40 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Luis R. Rodriguez, Hin-Tak Leung, linux-wireless
In-Reply-To: <1251749600.5165.1.camel@localhost.localdomain>
Hi Luis,
> > OK not so bad except for:
> >
> > > kernel/net/wimax/wimax.ko
> >
> > That's touching another subsystem but we could technically merge wimax
> > into compat-wireless if Inaky thinks that's a good idea. the point
> > here is to unify anything that uses rfkill for backport usage.
>
> Oh boy, can of worms
>
> I have my own compat-wimax already, which already handles things for
> backwards compat (many #ifdef hacks to simplify life) and which is
> heavily used internally.
>
> I don't really know how much worth it might be and I know I don't have
> resources to support both.
for the wireless-compat tree, I would just remove the RFKILL support for
WiMAX. It is really not worth to support it.
Regards
Marcel
^ permalink raw reply
* Test message, please ignore.
From: Gábor Stefanik @ 2009-08-31 21:01 UTC (permalink / raw)
To: linux-wireless, Broadcom Wireless, linux-kernel
I suspect that this will trigger a response from a spambot.
reset
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Larry Finger @ 2009-08-31 21:10 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, Tobias Schlemmer, linux-wireless
In-Reply-To: <3ace41890908311157v4fbc9829j6db9c91ef6fff3c7@mail.gmail.com>
Hin-Tak Leung wrote:
>
> I just took a look at the history - there aren't obvious bug fixes, a
> bunch of work queue-related changes from you & Johannes; feature-wise,
> Larry added LED blinking after 2.6.30, and Herton added rfkill support
> quite recently after 2.6.31-rc7 . But no, there isn't any change that
> would affect tx level beyond 2.6.31-rc7, I think.
Your analysis matches my recollection.
Apparently RealTek is supplying a closed-source driver for RTL8187B
these days. There are no sources for the B on their web site. In
addition, the one that Tobias loaded tainted his kernel.
Larry
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Gábor Stefanik @ 2009-08-31 21:18 UTC (permalink / raw)
To: Larry Finger
Cc: Hin-Tak Leung, Luis R. Rodriguez, Tobias Schlemmer,
linux-wireless
In-Reply-To: <4A9C3C59.5010305@lwfinger.net>
On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
>>
>> I just took a look at the history - there aren't obvious bug fixes, a
>> bunch of work queue-related changes from you & Johannes; feature-wise,
>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>> would affect tx level beyond 2.6.31-rc7, I think.
>
> Your analysis matches my recollection.
>
> Apparently RealTek is supplying a closed-source driver for RTL8187B
> these days. There are no sources for the B on their web site. In
> addition, the one that Tobias loaded tainted his kernel.
>
> Larry
The driver is not actually closed-source; they just don't provide any
drivers on their site anymore, instead they send their reference
drivers to OEMs, expecting the OEMs to release their own versions
(with sources - most vendors who do release Linux drivers in fact only
release sources, without binaries). The reason for this appears to be
that Realtek now encourages vendors to sell RTL81xx wireless chips
with modified USB IDs. (Or are you seeing a binary-only driver on
realtek.com.tw? That would definitely be a GPL violation, given that
they use a modified version of the GPLed libipw stack.)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] ar9170: added phy register initialisation from eeprom values
From: Christian Lamparter @ 2009-08-31 21:37 UTC (permalink / raw)
To: Joerg Albert
Cc: John W. Linville, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <4A9C25AE.9020109@gmx.de>
(changed cc', web.de finally pissed me off with a 500 mail quota)
2009/8/31 Joerg Albert <jal2@gmx.de>:
> On 08/31/2009 11:53 AM, Chunkeey@web.de wrote:
>> ...
>> 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.
>> */
>> ...
>
> Thanks for the comments. I agree with all of them and will re-spin a patch.
Great!
>> It's amazing how much **** you can _cut_ from the vendor driver.
>
> Yes, at first sight it looks really complex but it isn't.
well, there's still a thing... we can only copy what's there in driver,
But since the two-stage fw is capable of reinitializing
the rf/phy we could do all sorts of stuff without breaking it.
>> BTW: does this patch help the 1-stage fw stability, or is it still broken?
>
> Turned out I had a corrupt firmware file. After downloading from Luis' URL it works fine
> with my WNDA3100. Guess I had an earlier version from before 2009/05/28 or firefox
> corrupted it during download.
>
> What's your setup to get 80+ MBit/s throughput with the two-stage firmware?
simply another 11n card a few meters away (but in the same room of course,
since the 5GHz band doesn't like to go through concrete)
I tested a few configurations and only with a rt2860pci was able to get a
satisfying result over a small distance (7 m, but still in the same room ;) )
Other cards: like the ar5416 also worked, but not that well (tx rates halved)
and iwl4965, iwl5300 didn't work at all in n. (but they're flying with 11a)
> I've used an 802.11g AP so far, but have access to an 802.11n dual-band AP now.
> Guess I should use 5GHz as 2.4 is rather crowded here.
> How can I put ar9170 into 802.11n/40MHz mode?
well you need a patch which lets you use the MCS rates and
kicks off BlockAck sessions. I posted a version some time
ago, (AFAIK initial RFC?). However due to fact that the code belongs
into the rc-algorithm and the lack of "out-house testing" feedback,
I had to drop it. I can send you an _updated_ (well, it should apply without
fuzz... but you still have to select the MCS by hand) version if you want,
however not until Friday. Of course, If you have free time on your hand,
you could do the fix-ups by yourself and start the madNess right on! ;-)
(Note: Felix is looking into minstrel/HT. I expect once the code is
available, that we only have to patch ar9170 just a _little_ bit to get
it _sort of_ working.
(it might never probably work with the current available firmwares,
since the BA tx_status is totally bogus)
Regards,
Chr
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Larry Finger @ 2009-08-31 21:38 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Hin-Tak Leung, Luis R. Rodriguez, Tobias Schlemmer,
linux-wireless
In-Reply-To: <69e28c910908311418l7f033b5bp7a9b443cd253304@mail.gmail.com>
Gábor Stefanik wrote:
>
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)
No driver at all. I looked at the Toshiba site, but found only Windows
drivers. Which OEM has the driver available?
Larry
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 21:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Inaky Perez-Gonzalez, Hin-Tak Leung, linux-wireless
In-Reply-To: <1251751251.1266.16.camel@localhost.localdomain>
On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> Hi Luis,
>
>> > OK not so bad except for:
>> >
>> > > kernel/net/wimax/wimax.ko
>> >
>> > That's touching another subsystem but we could technically merge wimax
>> > into compat-wireless if Inaky thinks that's a good idea. the point
>> > here is to unify anything that uses rfkill for backport usage.
>>
>> Oh boy, can of worms
>>
>> I have my own compat-wimax already, which already handles things for
>> backwards compat (many #ifdef hacks to simplify life) and which is
>> heavily used internally.
>>
>> I don't really know how much worth it might be and I know I don't have
>> resources to support both.
>
> for the wireless-compat tree, I would just remove the RFKILL support for
> WiMAX. It is really not worth to support it.
Works for me, we then still need to address (if we really care) the
platform stuff. If someone is interested feel free to send patches to
add those, I figure as long we get down to the latest supported stable
kernel it should be good. The latest supported stable kernel is always
on display on kernel,org, today being 2.6.27.
Luis
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 23:05 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Inaky Perez-Gonzalez, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311445q60c703a3ha8ef8e599e3e712@mail.gmail.com>
On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
>> Hi Luis,
>>
>>> > OK not so bad except for:
>>> >
>>> > > kernel/net/wimax/wimax.ko
>>> >
>>> > That's touching another subsystem but we could technically merge wimax
>>> > into compat-wireless if Inaky thinks that's a good idea. the point
>>> > here is to unify anything that uses rfkill for backport usage.
>>>
>>> Oh boy, can of worms
>>>
>>> I have my own compat-wimax already, which already handles things for
>>> backwards compat (many #ifdef hacks to simplify life) and which is
>>> heavily used internally.
>>>
>>> I don't really know how much worth it might be and I know I don't have
>>> resources to support both.
>>
>> for the wireless-compat tree, I would just remove the RFKILL support for
>> WiMAX. It is really not worth to support it.
>
> Works for me, we then still need to address (if we really care) the
> platform stuff. If someone is interested feel free to send patches to
> add those, I figure as long we get down to the latest supported stable
> kernel it should be good. The latest supported stable kernel is always
> on display on kernel,org, today being 2.6.27.
BTW inaky -- this is actually up to you, are you wiling to live with
no rfkill for compat?
Luis
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Inaky Perez-Gonzalez @ 2009-08-31 23:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Marcel Holtmann, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311605m368f3703vfd8a25694e69072e@mail.gmail.com>
On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> >> Hi Luis,
> >>
> >>> > OK not so bad except for:
> >>> >
> >>> > > kernel/net/wimax/wimax.ko
> >>> >
> >>> > That's touching another subsystem but we could technically merge wimax
> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >>> > here is to unify anything that uses rfkill for backport usage.
> >>>
> >>> Oh boy, can of worms
> >>>
> >>> I have my own compat-wimax already, which already handles things for
> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >>> heavily used internally.
> >>>
> >>> I don't really know how much worth it might be and I know I don't have
> >>> resources to support both.
> >>
> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> WiMAX. It is really not worth to support it.
> >
> > Works for me, we then still need to address (if we really care) the
> > platform stuff. If someone is interested feel free to send patches to
> > add those, I figure as long we get down to the latest supported stable
> > kernel it should be good. The latest supported stable kernel is always
> > on display on kernel,org, today being 2.6.27.
>
> BTW inaky -- this is actually up to you, are you wiling to live with
> no rfkill for compat?
I don't really mind -- but it could be a problem for anyone trying to
use it. Not that I recommend not being able to switch the radio off :)
however, the WiMAX stack has APIs for it too, so at least there is a
workaround.
But remember, I won't be able to support it at all.
--
-- Inaky
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4)
From: Gábor Stefanik @ 2009-08-31 23:11 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Michael Buesch, Leonardo H. Souza Hamada, linux-wireless
In-Reply-To: <3ace41890908311602g4a976ec5k4f1f5145662cf183@mail.gmail.com>
(Restoring CCs from original message.)
2009/9/1 Hin-Tak Leung <hintak.leung@gmail.com>:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Mon, Aug 31, 2009 at 9:35 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Mon, Aug 31, 2009 at 8:27 PM, Michael Buesch<mb@bu3sch.de> wrote:
>>>> On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
>>>>> It would appear that the rw driver's ieee80211->mac80211 conversion
>>>>> has broken big- endian platforms, at a first guess.
>>>>
>>>> Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
>>>> But that's maybe two or three release cycles in the past.
>>>>
>>>> --
>>>> Greetings, Michael.
>>>>
>>>
>>> The rw ieee80211->mac80211 conversion happens in 2.6.27->26.28 ...
>>> Iguess the question is whether it was 2.6.28 or 2.6.27 you had success
>>> with? That's unfortunately two *and* three cycles in the past,
>>> respectively :-).
>>
>> I seem to remember that the conversion happened between 2.6.24 and
>> 2.6.25 - the 2.6.26 injection patch on patches.aircrack-ng.org is also
>> clearly for the mac80211 version.
>
> Some part persists till 2.6.28 - I was running git diff between
> different tags like this:
>
> git diff v2.6.27:drivers/net/wireless/zd1211rw/
> v2.6.28:drivers/net/wireless/zd1211rw/
> diff --git a/Makefile b/Makefile
> index cc36126..1907eaf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,6 @@
> obj-$(CONFIG_ZD1211RW) += zd1211rw.o
>
> -zd1211rw-objs := zd_chip.o zd_ieee80211.o zd_mac.o \
> +zd1211rw-objs := zd_chip.o zd_mac.o \
> zd_rf_al2230.o zd_rf_rf2959.o \
> zd_rf_al7230b.o zd_rf_uw2453.o \
> zd_rf.o zd_usb.o
> diff --git a/zd_chip.c b/zd_chip.c
> index 0acb5c3..e0ac58b 100644
> --- a/zd_chip.c
> +++ b/zd_chip.c
> @@ -28,7 +28,6 @@
>
> #include "zd_def.h"
> #include "zd_chip.h"
> -#include "zd_ieee80211.h"
> #include "zd_mac.h"
> #include "zd_rf.h"
>
AFAIK that was a cleanup from the changeover to mac80211 - originally,
zd_ieee80211 housed the bindings to ieee80211softmac. After the
conversion to mac80211, some mac80211 bindings ended up in zd_mac, the
others in zd_ieee80211. In 2.6.28, the two files were merged.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Hin-Tak Leung @ 2009-08-31 23:16 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, Luis R. Rodriguez, Tobias Schlemmer,
linux-wireless
In-Reply-To: <4A9C42C5.6050400@lwfinger.net>
2009/8/31 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
>
> No driver at all. I looked at the Toshiba site, but found only Windows
> drivers. Which OEM has the driver available?
>
> Larry
The r8187 is distributed from OEMs - stand to reason, as realtek don't
really sell their own brand on high-street shops? We got one release
e-mailed to us, and there are a few floating around on the internet
under some laptop or usb hardware vendors. It is available under this,
for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
r8187mesh is the one in the mesh directory.
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 23:34 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Marcel Holtmann, Hin-Tak Leung, linux-wireless
In-Reply-To: <1251760232.5165.28.camel@localhost.localdomain>
On Mon, Aug 31, 2009 at 4:10 PM, Inaky
Perez-Gonzalez<inaky.perez-gonzalez@intel.com> wrote:
> On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
>> >> Hi Luis,
>> >>
>> >>> > OK not so bad except for:
>> >>> >
>> >>> > > kernel/net/wimax/wimax.ko
>> >>> >
>> >>> > That's touching another subsystem but we could technically merge wimax
>> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
>> >>> > here is to unify anything that uses rfkill for backport usage.
>> >>>
>> >>> Oh boy, can of worms
>> >>>
>> >>> I have my own compat-wimax already, which already handles things for
>> >>> backwards compat (many #ifdef hacks to simplify life) and which is
>> >>> heavily used internally.
>> >>>
>> >>> I don't really know how much worth it might be and I know I don't have
>> >>> resources to support both.
>> >>
>> >> for the wireless-compat tree, I would just remove the RFKILL support for
>> >> WiMAX. It is really not worth to support it.
>> >
>> > Works for me, we then still need to address (if we really care) the
>> > platform stuff. If someone is interested feel free to send patches to
>> > add those, I figure as long we get down to the latest supported stable
>> > kernel it should be good. The latest supported stable kernel is always
>> > on display on kernel,org, today being 2.6.27.
>>
>> BTW inaky -- this is actually up to you, are you wiling to live with
>> no rfkill for compat?
>
> I don't really mind -- but it could be a problem for anyone trying to
> use it.
Hm sure and there is still also the issue of users of wimax enabled on
older kernels and using rfkill there. That is, users not using
compat-wimax but using just compat-wireless and expecting rfkill to
work smoothly between wimax and compat-wireless.
I am not sure of the details of the platform rfkill drivers or how
wimax or wireless drivers use these.. Perhaps there are no issues, I
haven't really cared to look into it.
> Not that I recommend not being able to switch the radio off :)
> however, the WiMAX stack has APIs for it too, so at least there is a
> workaround.
You mean a way to rfkill without rfkill?
> But remember, I won't be able to support it at all.
To support what specifically?
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 23:37 UTC (permalink / raw)
To: Gábor Stefanik, John W. Linville, Greg KH
Cc: Larry Finger, Hin-Tak Leung, Tobias Schlemmer, linux-wireless
In-Reply-To: <69e28c910908311418l7f033b5bp7a9b443cd253304@mail.gmail.com>
2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>> Hin-Tak Leung wrote:
>>>
>>> I just took a look at the history - there aren't obvious bug fixes, a
>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>> would affect tx level beyond 2.6.31-rc7, I think.
>>
>> Your analysis matches my recollection.
>>
>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>> these days. There are no sources for the B on their web site. In
>> addition, the one that Tobias loaded tainted his kernel.
>>
>> Larry
>
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)
Gabor, do you speak to RealkTek folks? It seems what may be best for
OEMs and RealTek themselves is to post drivers for inclusion into
staging first and then for interested parties to port them properly.
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Gábor Stefanik @ 2009-08-31 23:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Greg KH, Larry Finger, Hin-Tak Leung,
Tobias Schlemmer, linux-wireless
In-Reply-To: <43e72e890908311637r7b079e9fj2ac6b77f2b59eb79@mail.gmail.com>
On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>> Hin-Tak Leung wrote:
>>>>
>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>
>>> Your analysis matches my recollection.
>>>
>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>> these days. There are no sources for the B on their web site. In
>>> addition, the one that Tobias loaded tainted his kernel.
>>>
>>> Larry
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
> Gabor, do you speak to RealkTek folks? It seems what may be best for
> OEMs and RealTek themselves is to post drivers for inclusion into
> staging first and then for interested parties to port them properly.
>
> Luis
Not yet, I haven't tried contacting them. I simply based my comments
on the fact that OEMs are releasing sources. However, contacting them
about work to include their drivers in the kernel is a good idea -
apparently there is nothing keeping Realtek from taking community
contributions (unlike e.g. Zydas - the vendor driver is based on
Andrea Merello's old r8180-sa2400 driver, and was not developed
in-house by Realtek).
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 23:54 UTC (permalink / raw)
To: John W. Linville, Eric Paris
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311302s58743978wd8950f167a871cfb@mail.gmail.com>
On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 12:47 PM, John W.
> Linville<linville@tuxdriver.com> wrote:
>> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
>>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
>>> Linville<linville@tuxdriver.com> wrote:
>>
>>> > My guess is that the culprit is between
>>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>>>
>>> But the issue is *not* in linux-2.6-allstable, it is only present on
>>> wireless-testing, and I went as far back as merge-2009-08-28. I was
>>> using whatever tag was available prior to you moving to rc8, and that
>>> worked.
>>
>> OK, then I can only guess that something went wrong in your bisection
>> (e.g. dirty build, something not marked properly, etc).
>
> Well so remember I did a clean git clone of wireless-testing and the
> issue was still there, but I determined just now it seems rc8 from
> Linus does indeed also have the issue. For some reason the issue was
> not present on hpa's rc8 on linux-2.6-allstable. Will double check on
> that again.
OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
for me.. I tested just one patch and it fixed my bootup lag:
http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
FWIW for that patch:
Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
So -- you if you're like me and had issues with bootup lag on
wireless-testing, you can probably fix your wireless-testing by
pulling his patches:
git pull git://git.infradead.org/users/eparis/notify.git for-linus
I saw Linus had some other fixes but I'll wait for rc9 for that as my
box seems reasonably stable right now.
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 23:56 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John W. Linville, Greg KH, Larry Finger, Hin-Tak Leung,
Tobias Schlemmer, linux-wireless
In-Reply-To: <69e28c910908311646w315bef9eo43d3342c13e38fca@mail.gmail.com>
2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>>> Hin-Tak Leung wrote:
>>>>>
>>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>>
>>>> Your analysis matches my recollection.
>>>>
>>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>>> these days. There are no sources for the B on their web site. In
>>>> addition, the one that Tobias loaded tainted his kernel.
>>>>
>>>> Larry
>>>
>>> The driver is not actually closed-source; they just don't provide any
>>> drivers on their site anymore, instead they send their reference
>>> drivers to OEMs, expecting the OEMs to release their own versions
>>> (with sources - most vendors who do release Linux drivers in fact only
>>> release sources, without binaries). The reason for this appears to be
>>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>>> with modified USB IDs. (Or are you seeing a binary-only driver on
>>> realtek.com.tw? That would definitely be a GPL violation, given that
>>> they use a modified version of the GPLed libipw stack.)
>>
>> Gabor, do you speak to RealkTek folks? It seems what may be best for
>> OEMs and RealTek themselves is to post drivers for inclusion into
>> staging first and then for interested parties to port them properly.
>>
>> Luis
>
> Not yet, I haven't tried contacting them. I simply based my comments
> on the fact that OEMs are releasing sources. However, contacting them
> about work to include their drivers in the kernel is a good idea -
> apparently there is nothing keeping Realtek from taking community
> contributions (unlike e.g. Zydas - the vendor driver is based on
> Andrea Merello's old r8180-sa2400 driver, and was not developed
> in-house by Realtek).
If anyone has contacts that does indeed seem reasonable to do, seems
like it could help them and their customers.
Luis
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Inaky Perez-Gonzalez @ 2009-09-01 0:09 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Marcel Holtmann, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311634y5643818ate9d1b28cbbefa2b2@mail.gmail.com>
On Mon, 2009-08-31 at 17:34 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 4:10 PM, Inaky
> Perez-Gonzalez<inaky.perez-gonzalez@intel.com> wrote:
> > On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> >> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> >> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> >> >> Hi Luis,
> >> >>
> >> >>> > OK not so bad except for:
> >> >>> >
> >> >>> > > kernel/net/wimax/wimax.ko
> >> >>> >
> >> >>> > That's touching another subsystem but we could technically merge wimax
> >> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >> >>> > here is to unify anything that uses rfkill for backport usage.
> >> >>>
> >> >>> Oh boy, can of worms
> >> >>>
> >> >>> I have my own compat-wimax already, which already handles things for
> >> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >> >>> heavily used internally.
> >> >>>
> >> >>> I don't really know how much worth it might be and I know I don't have
> >> >>> resources to support both.
> >> >>
> >> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> >> WiMAX. It is really not worth to support it.
> >> >
> >> > Works for me, we then still need to address (if we really care) the
> >> > platform stuff. If someone is interested feel free to send patches to
> >> > add those, I figure as long we get down to the latest supported stable
> >> > kernel it should be good. The latest supported stable kernel is always
> >> > on display on kernel,org, today being 2.6.27.
> >>
> >> BTW inaky -- this is actually up to you, are you wiling to live with
> >> no rfkill for compat?
> >
> > I don't really mind -- but it could be a problem for anyone trying to
> > use it.
>
> Hm sure and there is still also the issue of users of wimax enabled on
> older kernels and using rfkill there. That is, users not using
> compat-wimax but using just compat-wireless and expecting rfkill to
> work smoothly between wimax and compat-wireless.
>
> I am not sure of the details of the platform rfkill drivers or how
> wimax or wireless drivers use these.. Perhaps there are no issues, I
> haven't really cared to look into it.
>
> > Not that I recommend not being able to switch the radio off :)
> > however, the WiMAX stack has APIs for it too, so at least there is a
> > workaround.
>
> You mean a way to rfkill without rfkill?
the wimax_rfkill() call at the end gets at the same point as the rfkill
call to toggle the radio.
> > But remember, I won't be able to support it at all.
>
> To support what specifically?
non-trivial bug reports. I always love to hear them, but I am really up
to my neck. I just don't want to create the wrong expectations from
users.
--
-- Inaky
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Greg KH @ 2009-09-01 0:21 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Gábor Stefanik, John W. Linville, Larry Finger,
Hin-Tak Leung, Tobias Schlemmer, linux-wireless
In-Reply-To: <43e72e890908311656o6f4a4157k6f967dc4934e6dd0@mail.gmail.com>
On Mon, Aug 31, 2009 at 04:56:11PM -0700, Luis R. Rodriguez wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> > On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> >> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> >>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> >>>> Hin-Tak Leung wrote:
> >>>>>
> >>>>> I just took a look at the history - there aren't obvious bug fixes, a
> >>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
> >>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
> >>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
> >>>>> would affect tx level beyond 2.6.31-rc7, I think.
> >>>>
> >>>> Your analysis matches my recollection.
> >>>>
> >>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
> >>>> these days. There are no sources for the B on their web site. In
> >>>> addition, the one that Tobias loaded tainted his kernel.
> >>>>
> >>>> Larry
> >>>
> >>> The driver is not actually closed-source; they just don't provide any
> >>> drivers on their site anymore, instead they send their reference
> >>> drivers to OEMs, expecting the OEMs to release their own versions
> >>> (with sources - most vendors who do release Linux drivers in fact only
> >>> release sources, without binaries). The reason for this appears to be
> >>> that Realtek now encourages vendors to sell RTL81xx wireless chips
> >>> with modified USB IDs. (Or are you seeing a binary-only driver on
> >>> realtek.com.tw? That would definitely be a GPL violation, given that
> >>> they use a modified version of the GPLed libipw stack.)
> >>
> >> Gabor, do you speak to RealkTek folks? It seems what may be best for
> >> OEMs and RealTek themselves is to post drivers for inclusion into
> >> staging first and then for interested parties to port them properly.
> >>
> >> Luis
> >
> > Not yet, I haven't tried contacting them. I simply based my comments
> > on the fact that OEMs are releasing sources. However, contacting them
> > about work to include their drivers in the kernel is a good idea -
> > apparently there is nothing keeping Realtek from taking community
> > contributions (unlike e.g. Zydas - the vendor driver is based on
> > Andrea Merello's old r8180-sa2400 driver, and was not developed
> > in-house by Realtek).
>
> If anyone has contacts that does indeed seem reasonable to do, seems
> like it could help them and their customers.
I do have a few contacts there, and have been trying to work with them
to do this, but it is slow going :(
thanks,
greg k-h
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Eric Paris @ 2009-09-01 0:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Eric Paris, Catalin Marinas, H. Peter Anvin,
linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <43e72e890908311654t5d9489d3w9a817cffab5cb8f8@mail.gmail.com>
On Mon, 2009-08-31 at 16:54 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> > On Mon, Aug 31, 2009 at 12:47 PM, John W.
> > Linville<linville@tuxdriver.com> wrote:
> >> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
> >>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
> >>> Linville<linville@tuxdriver.com> wrote:
> >>
> >>> > My guess is that the culprit is between
> >>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
> >>>
> >>> But the issue is *not* in linux-2.6-allstable, it is only present on
> >>> wireless-testing, and I went as far back as merge-2009-08-28. I was
> >>> using whatever tag was available prior to you moving to rc8, and that
> >>> worked.
> >>
> >> OK, then I can only guess that something went wrong in your bisection
> >> (e.g. dirty build, something not marked properly, etc).
> >
> > Well so remember I did a clean git clone of wireless-testing and the
> > issue was still there, but I determined just now it seems rc8 from
> > Linus does indeed also have the issue. For some reason the issue was
> > not present on hpa's rc8 on linux-2.6-allstable. Will double check on
> > that again.
>
> OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
> turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
> for me.. I tested just one patch and it fixed my bootup lag:
>
> http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
>
> FWIW for that patch:
>
> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> So -- you if you're like me and had issues with bootup lag on
> wireless-testing, you can probably fix your wireless-testing by
> pulling his patches:
>
> git pull git://git.infradead.org/users/eparis/notify.git for-linus
>
> I saw Linus had some other fixes but I'll wait for rc9 for that as my
> box seems reasonably stable right now.
Yes, -rc8 broke pretty badly for a number of people. Linus did pull all
of the fixes that I know of. I wouldn't suggest pulling just that one
commit. All 3 of the post -rc8 patches in my tree fix -rc8
regressions :(
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-09-01 0:31 UTC (permalink / raw)
To: Eric Paris
Cc: John W. Linville, Eric Paris, Catalin Marinas, H. Peter Anvin,
linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <1251764791.2158.7.camel@dhcp231-106.rdu.redhat.com>
On Mon, Aug 31, 2009 at 5:26 PM, Eric Paris<eparis@redhat.com> wrote:
> On Mon, 2009-08-31 at 16:54 -0700, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> > On Mon, Aug 31, 2009 at 12:47 PM, John W.
>> > Linville<linville@tuxdriver.com> wrote:
>> >> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
>> >>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
>> >>> Linville<linville@tuxdriver.com> wrote:
>> >>
>> >>> > My guess is that the culprit is between
>> >>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>> >>>
>> >>> But the issue is *not* in linux-2.6-allstable, it is only present on
>> >>> wireless-testing, and I went as far back as merge-2009-08-28. I was
>> >>> using whatever tag was available prior to you moving to rc8, and that
>> >>> worked.
>> >>
>> >> OK, then I can only guess that something went wrong in your bisection
>> >> (e.g. dirty build, something not marked properly, etc).
>> >
>> > Well so remember I did a clean git clone of wireless-testing and the
>> > issue was still there, but I determined just now it seems rc8 from
>> > Linus does indeed also have the issue. For some reason the issue was
>> > not present on hpa's rc8 on linux-2.6-allstable. Will double check on
>> > that again.
>>
>> OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
>> turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
>> for me.. I tested just one patch and it fixed my bootup lag:
>>
>> http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
>>
>> FWIW for that patch:
>>
>> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>>
>> So -- you if you're like me and had issues with bootup lag on
>> wireless-testing, you can probably fix your wireless-testing by
>> pulling his patches:
>>
>> git pull git://git.infradead.org/users/eparis/notify.git for-linus
>>
>> I saw Linus had some other fixes but I'll wait for rc9 for that as my
>> box seems reasonably stable right now.
>
> Yes, -rc8 broke pretty badly for a number of people. Linus did pull all
> of the fixes that I know of. I wouldn't suggest pulling just that one
> commit. All 3 of the post -rc8 patches in my tree fix -rc8
> regressions :(
Thanks, the note -- so I guess best is to just pull from Linus ontop
of wireless-testing.
Luis
^ permalink raw reply
* Re: [PATCH v2] mac80211: Fix output of minstrels rc_stats
From: Julian Calaby @ 2009-09-01 0:54 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-wireless, joe, proski
In-Reply-To: <1251139906-31813-1-git-send-email-hannemann@nets.rwth-aachen.de>
On Tue, Aug 25, 2009 at 04:51, Arnd
Hannemann<hannemann@nets.rwth-aachen.de> wrote:
> An integer overflow in the minstrel debug code prevented the
> throughput to be displayed correctly. This patch fixes that,
> by permutating operations like proposed by Pavel Roskin.
>
> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
> index 98f4807..3d72ec5 100644
> --- a/net/mac80211/rc80211_minstrel_debugfs.c
> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
> p += sprintf(p, "%3u%s", mr->bitrate / 2,
> (mr->bitrate & 1 ? ".5" : " "));
>
> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
> + tp = mr->cur_tp / ((18000 << 10) / 96);
Sorry about being so late, but wouldn't:
tp = ((mr->cur_tp * 2) / 375) >> 10;
also work? (Assuming that the numbers in the constant aren't important)
or even:
tp = (mr->cur_tp / 375) >> 9;
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Jaswinder Singh Rajput @ 2009-09-01 3:49 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Alan Jenkins,
Henrique de Moraes Holschuh, Iñaky Pérez-González,
Ivo van Doorn, Michael Buesch, Tomas Winkler
In-Reply-To: <20090831174542.GA5631@tuxdriver.com>
On Mon, 2009-08-31 at 13:45 -0400, John W. Linville wrote:
> 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?
>
No Problem, sorry for delay.
Thanks,
--
JSR
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Jaswinder Singh Rajput @ 2009-09-01 3:57 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Alan Jenkins,
Henrique de Moraes Holschuh, Iñaky Pérez-González,
Ivo van Doorn, Michael Buesch, Tomas Winkler
In-Reply-To: <20090831174542.GA5631@tuxdriver.com>
On Mon, 2009-08-31 at 13:45 -0400, John W. Linville wrote:
> 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?
>
Acked-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
--
JSR
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Zhu Yi @ 2009-09-01 6:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Eric Paris, John W. Linville, Eric Paris, Catalin Marinas,
H. Peter Anvin, linux-kernel@vger.kernel.org, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311731h626a5b9bu486653c755cda2fa@mail.gmail.com>
On Tue, 2009-09-01 at 08:31 +0800, Luis R. Rodriguez wrote:
> >>
> http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
> >>
> >> FWIW for that patch:
> >>
> >> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >>
> >> So -- you if you're like me and had issues with bootup lag on
> >> wireless-testing, you can probably fix your wireless-testing by
> >> pulling his patches:
> >>
> >> git pull git://git.infradead.org/users/eparis/notify.git for-linus
> >>
> >> I saw Linus had some other fixes but I'll wait for rc9 for that as
> my
> >> box seems reasonably stable right now.
> >
> > Yes, -rc8 broke pretty badly for a number of people. Linus did pull
> all
> > of the fixes that I know of. I wouldn't suggest pulling just that
> one
> > commit. All 3 of the post -rc8 patches in my tree fix -rc8
> > regressions :(
>
> Thanks, the note -- so I guess best is to just pull from Linus ontop
> of wireless-testing.
I confirm I'm also suffered with the problem on today's wireless-testing
tip (udevadm --settle hangs on boot) and the above patch does fix the
issue for me. Thanks both for identify and fix the problem.
Thanks,
-yi
^ 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