Alejandro Riveira Fern?ndez wrote:
> I for one stopped booting into -rc kernels.
> The fact that still have to patch my kernels with a *one* liner
> since 2.6.29 kernel [1] does not give me confidence on the "test
> report/bisect and it will be fixed" promise some have made in this
> threath
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=13362
There were promises made in this thread? Then I must have read a
different mailinglist or so.
I do not know why your WLAN regression has not been fixed yet, but at
least it seems rather plausible why commit
7e0986c17f695952ce5d61ed793ce048ba90a661 is not going to be reverted (if
such a revert is the one-liner that you are referring to).
Why is one reporter's rt2500 OK now though but not yours? Are there
different card revisions or firmwares out there that require quirk handling?
--
Stefan Richter
-=====-==-=- -=== -==-=
http://arcgraph.de/sr/
El Tue, 13 Jul 2010 14:38:52 -0400
"John W. Linville" <[email protected]> escribió:
>
> > > isn't using the basic_rates map properly. But after reviewing the
> > > code and the data I have, I can't see what would be causing that.
> > > It is at least possible that your AP is sending bad rate information.
> > > Have you tried this device with other APs?
I do no know; i captured some debug data for Ivo back in the day and from
what he said all the info passed to the card was correct...
See http://lkml.org/lkml/2009/5/25/163 ( link is in bugzilla) in case
you missed it
> >
> > No; this is a desktop pc that connects to my home router/AP. A new wifi
> > card is cheaper than a new AP ...
>
> Perhaps you could capture some beacons from that AP?
f you explain how; I can try.
>
El Tue, 13 Jul 2010 11:35:31 -0400
"John W. Linville" <[email protected]> escribió:
>
> The patch (7e0986c1) corrects an obvious error. Reverting it might
> improve your (i.e. Alejandro) performance, but it seems likely to
> cause connectivity problems for others.
>
> The fact that reverting 7e098c1 helps you suggests that rt2500usb
my card is pci so it would be rt2500pci
> isn't using the basic_rates map properly. But after reviewing the
> code and the data I have, I can't see what would be causing that.
> It is at least possible that your AP is sending bad rate information.
> Have you tried this device with other APs?
No; this is a desktop pc that connects to my home router/AP. A new wifi
card is cheaper than a new AP ...
>
> John
On Tue, Jul 13, 2010 at 08:19:27PM +0200, Alejandro Riveira Fern?ndez wrote:
> El Tue, 13 Jul 2010 11:35:31 -0400
> "John W. Linville" <[email protected]> escribi?:
>
>
> >
> > The patch (7e0986c1) corrects an obvious error. Reverting it might
> > improve your (i.e. Alejandro) performance, but it seems likely to
> > cause connectivity problems for others.
> >
> > The fact that reverting 7e098c1 helps you suggests that rt2500usb
>
> my card is pci so it would be rt2500pci
Sorry, typo...
> > isn't using the basic_rates map properly. But after reviewing the
> > code and the data I have, I can't see what would be causing that.
> > It is at least possible that your AP is sending bad rate information.
> > Have you tried this device with other APs?
>
> No; this is a desktop pc that connects to my home router/AP. A new wifi
> card is cheaper than a new AP ...
Perhaps you could capture some beacons from that AP?
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Alejandro Riveira Fern?ndez wrote:
> El Tue, 13 Jul 2010 14:50:14 +0200
> Stefan Richter <[email protected]> escribi?:
>> There were promises made in this thread? Then I must have read a
>> different mailinglist or so.
>
> Ok no promises.
> Maybe I read to much in to Mr Tso previous mail. My apologies
> [quote]
> > So I tend to use -rc3, -rc4, and -rc5 kernels on my laptops, and when
> > I find bugs, I report them and I help fix them. If more people did
> > that, then the 2.6.X.0 releases would be more stable. But kernel
> > development is a volunteer effort, so it's up to the volunteers to
> > test and fix bugs during the rc4, -rc5 and -rc6 time frame.
>
> [...]
> > [...] Linux may be a very good bargain (look
> > at how much Oracle has increased its support contracts for Solaris!),
> > but it's still not a free lunch. At the end of the day, you get what
> > you put into it.
>
> I tested the kernels i reported the bugs and helped (to the best of my
> knowledge; I'm not a programmer)
> I got no result.
"You get what you put into it" probably did not mean "report a bug, get
it fixed, every time". Often enough, kernel bugs or hardware quirks are
very hard to fix without direct access to affected hardware.
Here is how my involvement with Linux started: I reported a bug but
nobody reacted. I collected some more information, reported the bug
again, and it was immediately fixed by the driver authors. From then on
I kept following driver development as a tester and answered user
questions. A few years later, the driver authors all had left for other
projects but there were still bugs to tackle. So I started to write and
submit bug fixes myself. (I'm not a programmer either but by then I
already knew a lot about the subsystem.)
--
Stefan Richter
-=====-==-=- -=== -==-=
http://arcgraph.de/sr/
El Tue, 13 Jul 2010 14:50:14 +0200
Stefan Richter <[email protected]> escribió:
> Alejandro Riveira Fernández wrote:
> > I for one stopped booting into -rc kernels.
> > The fact that still have to patch my kernels with a *one* liner
> > since 2.6.29 kernel [1] does not give me confidence on the "test
> > report/bisect and it will be fixed" promise some have made in this
> > threath
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=13362
>
> There were promises made in this thread? Then I must have read a
> different mailinglist or so.
Ok no promises.
Maybe I read to much in to Mr Tso previous mail. My apologies
[quote]
> So I tend to use -rc3, -rc4, and -rc5 kernels on my laptops, and when
> I find bugs, I report them and I help fix them. If more people did
> that, then the 2.6.X.0 releases would be more stable. But kernel
> development is a volunteer effort, so it's up to the volunteers to
> test and fix bugs during the rc4, -rc5 and -rc6 time frame.
[...]
> [...] Linux may be a very good bargain (look
> at how much Oracle has increased its support contracts for Solaris!),
> but it's still not a free lunch. At the end of the day, you get what
> you put into it.
I tested the kernels i reported the bugs and helped (to the best of my
knowledge; I'm not a programmer)
I got no result.
On Tue, Jul 13, 2010 at 02:50:14PM +0200, Stefan Richter wrote:
> Alejandro Riveira Fern?ndez wrote:
> > I for one stopped booting into -rc kernels.
> > The fact that still have to patch my kernels with a *one* liner
> > since 2.6.29 kernel [1] does not give me confidence on the "test
> > report/bisect and it will be fixed" promise some have made in this
> > threath
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=13362
>
> There were promises made in this thread? Then I must have read a
> different mailinglist or so.
>
> I do not know why your WLAN regression has not been fixed yet, but at
> least it seems rather plausible why commit
> 7e0986c17f695952ce5d61ed793ce048ba90a661 is not going to be reverted (if
> such a revert is the one-liner that you are referring to).
>
> Why is one reporter's rt2500 OK now though but not yours? Are there
> different card revisions or firmwares out there that require quirk handling?
The patch (7e0986c1) corrects an obvious error. Reverting it might
improve your (i.e. Alejandro) performance, but it seems likely to
cause connectivity problems for others.
The fact that reverting 7e098c1 helps you suggests that rt2500usb
isn't using the basic_rates map properly. But after reviewing the
code and the data I have, I can't see what would be causing that.
It is at least possible that your AP is sending bad rate information.
Have you tried this device with other APs?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.