|
maemo.org Bugzilla – Full Text Bug Listing |
- Home
- | New
- | Search
- |
- | Reports
- | Help
- | New Account
- | Log In
- | Forgot Password
|
maemo.org Bugzilla – Full Text Bug Listing |
| Summary: | 770 will not see any networks (or connect to those it sees) over 90% of time | ||
|---|---|---|---|
| Product: | [Maemo Official Platform] Connectivity | Reporter: | Scott <human.path> |
| Component: | WiFi | Assignee: | unassigned <nobody> |
| Status: | RESOLVED WONTFIX | QA Contact: | wifi-bugs |
| Severity: | major | ||
| Priority: | Medium | CC: | adam, andre_klapper, anidel, bfhowell, dagreene, henry, hidave.darkstar, human.path, linuxvinh, networklabor, nicolas.vieville, steve_maemobugs, v.pomerol, wangxiaopeng |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | 770 | ||
| OS: | Maemo | ||
| URL: | http://www.internettablettalk.com/forums/showthread.php?t=21797 | ||
| Attachments: |
syslog
strace of iwlist scanning syslog with cx3110x module debug turned on non-crashy debug module syslog |
||
When flashing to Diablo (or Hacker Edition in this case), did you restore backup on first boot, or later? also see https://bugs.maemo.org/show_bug.cgi?id=2926#c10Created an attachment (id=991) [details] syslog Burgess: Thanks for the for the great syslog!! Quoting some parts here: 770 running 2007HE 4.2008.7-1 19:13:17 interesting stuff starts 19:13:26 Scanning the user's home ssid 'default' that I want to connect to 19:14:31, I was partially shielding the 770 by clasping it flat between my palms. At that point, you can see that it picked up a few APs. When I selected my local AP ("default"), I removed the shield and the connection failed. 19:15:05, I again shielded the 770, but this time, I "hugged" it with the face flat against my body and wrapped both hands over the back, covering it completely. 19:15:12, it recognized ONLY my local AP -- no others showed up in the list. I selected my local AP from the list and immediately shielded the 770 in the same hugging manner as before. 19:15:23 Successful connection I am certain now that this is related to some sort of local interference, possibly from nearby n networks. I repeated the "hugging" experiment 5 times, and it worked every time. Leaving the tablet unshielded resulted in the failure to see APs and/or failure to connect to found APs. I conducted these experiments within 6 feet of my own WAP. BTW, I have taken the tablet to work where we have less networks and have not experienced the same sort of failures -- the tablet sees APs and connects every time on the first attempt.heh, iwlist.c contains code which looks mighty familiar (almost identical to the dbus handler for wlancond): /* Try to read the results */ wrq.u.data.pointer = buffer; wrq.u.data.flags = 0; wrq.u.data.length = buflen; if(iw_get_ext(skfd, ifname, SIOCGIWSCAN, &wrq) < 0) { /* Check if buffer was too small (WE-17 only) */ if((errno == E2BIG) && (range.we_version_compiled > 16)) { /* Some driver may return very large scan results, either * because there are many cells, or because they have many * large elements in cells (like IWEVCUSTOM). Most will * only need the regular sized buffer. We now use a dynamic * allocation of the buffer to satisfy everybody. Of course, * as we don't know in advance the size of the array, we try * various increasing sizes. Jean II */ /* Check if the driver gave us any hints. */ if(wrq.u.data.length > buflen) buflen = wrq.u.data.length; else buflen *= 2; /* Try again */ goto realloc; } /* Check if results not available yet */ if(errno == EAGAIN) { /* Restart timer for only 100ms*/ tv.tv_sec = 0; tv.tv_usec = 100000; timeout -= tv.tv_usec; if(timeout > 0) continue; /* Try again later */ } /* Bad error */ free(buffer); fprintf(stderr, "%-8.16s Failed to read scan data : %s\n\n", ifname, strerror(errno)); return(-2); This has to do with buffer limits, but I don't know whether they are in the driver or we can use some other workaround.Created an attachment (id=3187) [details] strace of iwlist scanning iwlist uses a nearly identical codepath to scan for access points. It appears the IO call does indeed return -1 EINVAL (Invalid argument). This could be because of buffer issues, but could also be an issue with the lower level driver.Created an attachment (id=3201) [details] non-crashy debug module syslog Looks like if I don't touch (reload) the umac.ko, then the kernel stays happy. This is the syslog with all debugging turned on in cx3110x from a location which does *not* have N network around.} else if(callb_mask < 0) { DEBUG(DBG_IOCTL, "sm_drv_ioctl (Get OID 0x%x): sm_conf error %d\n", smconf.oid, callb_mask); return -EINVAL; }