Bug 479860
Summary: | Toshiba Satellite L300-1AF RTL8187B wireless chipset establishes connection, but no traffic can pass. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dave Russell <drussell> |
Component: | kernel | Assignee: | John W. Linville <linville> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | drussell, kernel-maint, quintela |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 2.6.27.12-170.2.5.fc10 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 477086 | Environment: | |
Last Closed: | 2009-01-29 14:23:43 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dave Russell
2009-01-13 16:59:03 UTC
Just a note, I have cloned the previous bug and slightly altered this new one to better reflect the issues (but not loose all the uploaded attachments). Also, I have tried the latest F10 kernel available in koji 2.6.28-1.fc10.i686 Still the same symptoms, NetworkManager establishes a connection but it won't pass any traffic. BTW This machine was a fresh install yesterday. Altered subject to better identify bug. This device is notorious for not playing nice with the mac80211 rate control algorithms. You might want to try forcing a lower rate: iwconfig eth0 rate 5.5M fixed Does that allow some semblance of connectivity? Yes, that does indeed work: iwconfig wlan0 rate 5.5M fixed This is on the 2.6.28-1.fc10.i686 kernel from koji. So that's identified the problem... is there anything that can be done to limit to make these kinds of changes transparent to the user? I'm going to pull down the latest rawhide kernel now and give that a shot too. Now this is interesting, the rawhide kernel seems to work out of the box, no rate limiting required. 2.6.29-0.35.rc1.git4.fc11.i686 pulled straight from koji. Ideas/Suggestions? Nothing that isn't obvious (i.e. either use the fc11 kernel or add the iwconfig command to rc.local). We probably need another rate control algorithm upstream for devices that don't properly report transmit status (i.e. devices like this one). Let me know if you can think of a good algorithm... :-) Ok, for now I'm going to go with the F11 kernel. One thing though, if there's no updated algorithm, I'm confused as to why the F11 one works, and the F10 one doesn't, I assume it's just the updated driver between the versions, but if that's the case, couldn't it be updated/fixed in the F10 kernel? I'm curious if nothing else :o) There were some rtl8187b-related patches that might effect rate scaling. I'll try to dig them out to see if we can improve F10. However ATM I can't be sure how readily they apply to F10 and therefore can't commit to taking them if they are too disruptive or simply don't apply. Ahh ok. Well if you can, and you want a willing vict... test subject, just let me know and I'll give them a try. Many thanks. I pushed a patch into 2.6.28.1-18.fc10 -- not sure when a build will have it... Should also be fixed in 2.6.27.12-170.2.5 which is submitted for updates-testing. Great news, will try the 2.6.27.12-170.2.5 kernel this evening. Will let you know. Bingo! [jane@cobwebs ~]$ uname -a Linux cobwebs.darkglobe.int 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST 2009 i686 i686 i386 GNU/Linux [jane@cobwebs ~]$ ping www.google.co.uk PING www.l.google.com (66.249.91.147) 56(84) bytes of data. 64 bytes from .google.com (66.249.91.147): icmp_seq=1 ttl=243 time=33.5 ms 64 bytes from .google.com (66.249.91.147): icmp_seq=2 ttl=243 time=31.0 ms 64 bytes from .google.com (66.249.91.147): icmp_seq=3 ttl=243 time=38.8 ms ^C --- www.l.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2489ms rtt min/avg/max/mdev = 31.037/34.455/38.820/3.254 ms Great work, all seems to be fine to me, please feel free to push this from testing into released... Thanks for the effort that's gone into this. |