Re: Where should I put my public_rpms for 10.1.3 ?
On 10/20/2010 07:10 PM, Martin Langhoff wrote: > Hi Simon, > > as in the past, should it be ~/public_rpms/10.1.3 ? Will that work? Yes, using the public_rpms will work. They will end up under the name of dsd then [1]. Mind that you have to use ~martin/public_rpms and not ~martin/public_html/public_rpms but I am sure you know this already :) > Hello list -- did I forget to mention this? Simon is build-master for > 10.1.3 . Release manager. Culprit-in-chief. > > Mbwa-ha-ha-ha-ha. Little does he know the trouble he's in... ;-) Thanks for the introduction :) Regards, Simon [1] http://xs-dev.laptop.org/~dsd/repos/f11/filelist.txt ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, 2010-10-20 at 10:28 -0400, Martin Langhoff wrote: > The hardcoded sleep *is* being removed. IME, that'll first uncover a > variety of bugs and odd interactions/races in various drivers and > hardwares it has been covering for. I'm hitting one of these races even *with* the hard-coded timeout: it's between wpa_supplicant and NetworkManager, on resume from suspend. It causes the list of available access points to remain blank. Dan Williams helped me analyze the issue, but we still have no fix. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Aggressive suspend vs NM/DHCP
On Wed, Oct 20, 2010 at 5:55 PM, Martin Langhoff wrote: > The "right fix" is just what we wanna do for the upstream dev branch, > for the next cycle. Sigh. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Aggressive suspend vs NM/DHCP
On Wed, Oct 20, 2010 at 5:46 PM, John Gilmore wrote: > If the client sent a broadcast DHCP request, any response will > NOT be a broadcast -- it'll be sent directly to the MAC address of > the requester. (I co-designed the BOOTP protocol that DHCP is based on.) Thanks! That means I'm worrying pointlessly. > I guess I have to post this once a month: stop dumping more kludges into Sure, just gimme infinite resources to do everything just perfect on the first try, and crazy upstreams that auto-merge our patches on stable and dev branches. Or get rid of those pesky deployments that are about to distribute a few K laptops to hard-to-reach places w/o internet. So we either fix something for a "handful" of kids, or we don't. We aren't upstream. We're downstream -- and very close to the users. Sit here and feel their pain while we tell them to wait a year or two. The "right fix" is just what we wanna do for the upstream dev branch, for the next cycle. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Aggressive suspend vs NM/DHCP
> (nor for the first time) I spot an XO that goes into suspend in the > middle of the DHCP conversation. In this case, it was with a bad WEP > key so we never heard back from the DHCP server. > > But if you look at /var/log/messages, you see dhclient's DHCPDISCOVER > and 12s later PM: Syncing filesystems... done. Normally you'd get a response from a working DHCP server in much than 12 seconds. > Do we wake up on broadcast DHCP responses properly? (Am I worrying > pointlessly?) If the client sent a broadcast DHCP request, any response will NOT be a broadcast -- it'll be sent directly to the MAC address of the requester. (I co-designed the BOOTP protocol that DHCP is based on.) > Otherwise, is there a way for powerd to wait a bit longer when > NM/dhclient are... active? I guess I have to post this once a month: stop dumping more kludges into the kludged autosuspend implementation. If you fix it properly, once, then you'll never have to kludge anything again. An autosuspended laptop should awaken when it gets a packet addressed to it. Fix all bugs around that and you won't need kludges. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Where should I put my public_rpms for 10.1.3 ?
Hi Simon, as in the past, should it be ~/public_rpms/10.1.3 ? Will that work? Hello list -- did I forget to mention this? Simon is build-master for 10.1.3 . Release manager. Culprit-in-chief. Mbwa-ha-ha-ha-ha. Little does he know the trouble he's in... ;-) We're aiming to roll as many blockers and high bugs as possible from http://dev.laptop.org/1.5 as well as a number of activity improvements being managed by Gonzalo Odiard. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Aggressive suspend vs NM/DHCP
Paul, list, (nor for the first time) I spot an XO that goes into suspend in the middle of the DHCP conversation. In this case, it was with a bad WEP key so we never heard back from the DHCP server. But if you look at /var/log/messages, you see dhclient's DHCPDISCOVER and 12s later PM: Syncing filesystems... done. Do we wake up on broadcast DHCP responses properly? (Am I worrying pointlessly?) Otherwise, is there a way for powerd to wait a bit longer when NM/dhclient are... active? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On 20 October 2010 15:28, Martin Langhoff wrote: > The hardcoded sleep *is* being removed. IME, that'll first uncover a > variety of bugs and odd interactions/races in various drivers and > hardwares it has been covering for. It wasn't a workaround for races or bugs. It was a fundamental part of the NM user vs system split. If you remove it, you'll break things like ethernet connectivity. Not because of bugs, just because having a delay was an inherent part of the "who gets it" design, mostly thanks to limitations of HAL. This has already been solved better in newer versions of NetworkManager, thanks to advancements in udev allowing for nicer NM design/interactions. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, Oct 20, 2010 at 7:28 AM, Martin Langhoff wrote: > On Wed, Oct 20, 2010 at 9:40 AM, Bernie Innocenti wrote: >> On Wed, 2010-10-20 at 08:35 -0500, Mikus Grinbergs wrote: >>> > The question is why does it take so long for the connection to be >>> > established? >>> > >>> > A 10-12 second reconnect time is to be expected: >>> > 1. A 1 second delay for the device to be probed and initialized on resume >>> > 2. NetworkManager has a 7 second delay hardcoded >> >> Really? That sucks! >> >> Finally explained why my simple shell script could connect in just 3 >> seconds whereas NM took a lot longer. > > The hardcoded sleep *is* being removed. IME, that'll first uncover a > variety of bugs and odd interactions/races in various drivers and > hardwares it has been covering for. > There is also the problem where the wireless drivers don't age network scan results over suspend resume. The ipw2200 driver was fixed for this issue but I don't think any other drivers followed suite. I had written a patch for the libertas driver pre XO 1.5 release but never tested it fully enough to say how much of a difference it made. This does sound like it will fix the problem that has been noticed here, where the scan list is populated and then goes away. I think the initial list is the pre-suspend AP list that has not been aged over the suspend cycle, so the entries still look relevant. http://lwn.net/Articles/321102/ http://blogs.gnome.org/dcbw/2009/02/26/suspendresume-vs-networkmanager/ If people are interested in testing I can role a kernel with my patches in it and post it somewhere. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, Oct 20, 2010 at 9:40 AM, Bernie Innocenti wrote: > On Wed, 2010-10-20 at 08:35 -0500, Mikus Grinbergs wrote: >> > The question is why does it take so long for the connection to be >> > established? >> > >> > A 10-12 second reconnect time is to be expected: >> > 1. A 1 second delay for the device to be probed and initialized on resume >> > 2. NetworkManager has a 7 second delay hardcoded > > Really? That sucks! > > Finally explained why my simple shell script could connect in just 3 > seconds whereas NM took a lot longer. The hardcoded sleep *is* being removed. IME, that'll first uncover a variety of bugs and odd interactions/races in various drivers and hardwares it has been covering for. Only once we're past that fallout, with those bugs accounted for and fixed, we might get better behaviour. In the meantime. suckitude in this area is likely to increase :-[ ain't optimism great? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, 2010-10-20 at 08:35 -0500, Mikus Grinbergs wrote: > > The question is why does it take so long for the connection to be > > established? > > > > A 10-12 second reconnect time is to be expected: > > 1. A 1 second delay for the device to be probed and initialized on resume > > 2. NetworkManager has a 7 second delay hardcoded Really? That sucks! Finally explained why my simple shell script could connect in just 3 seconds whereas NM took a lot longer. > [I hope that an XO which is in "I've had my wireless connected for a > whole hour" mode can nevertheless detect whenever a __new__ AP shows up > (whose radio signal was not previously noticed). If that is possible, > then the SAME capability should be applicable even at startup time.] This is called background scanning. Most wifi firmwares do it because it's required to hop to another with the same ESSID and better signal quality. Background scanning may introduce several ms of latency while the radio is switching channels. Gamers know tricks to disable it. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
> The question is why does it take so long for the connection to be established? > > A 10-12 second reconnect time is to be expected: > 1. A 1 second delay for the device to be probed and initialized on resume > 2. NetworkManager has a 7 second delay hardcoded > 3. A 1-2 second delay for scanning to complete > 4. A 1-2 second delay for authentication, association, key exchange > (if applicable) and DHCP. It has looked to me as though icons already in Neighborhood View can disappear as the XO reinitializes a complete scan of its radio spectrum. I still think that in the plurality of wireless startup cases the pupil will expect to make a connection on the SAME frequency that the XO was using the last time his XO system's wireless was in use. [I hope that an XO which is in "I've had my wireless connected for a whole hour" mode can nevertheless detect whenever a __new__ AP shows up (whose radio signal was not previously noticed). If that is possible, then the SAME capability should be applicable even at startup time.] I'm thinking that at startup, Network Manager ought to be *inhibited* while the XO listens on the same frequency as was last used. If the XO hears a strong enough signal, it ought to go into its "I've had my wireless connected for a whole hour" mode -- and depend upon "radio signal discovery" the same way that it does when not starting up.. Only if the XO at startup does NOT hear a strong signal on the last-used frequency should the XO depend upon scanning and Network Manager to determine "what are the radio signals that I am receiving now". Whenever steps 2-3 above can be avoided, wireless startup will be noticeably quicker. [For those cases where the pupil has moved to a different schoolroom while his XO was powered down - once the XO is powered up let the pupil perform whatever manual "tuning" procedure he would have used if he had moved to that different schoolroom while carrying his XO powered up.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On 20 October 2010 09:14, Hal Murray wrote: > On lid open, the WiFi LED blinks a few times, finds a few APs, but doesn't > find my AP. After a long pause (10+ seconds), it blinks again, finds my AP, > turns the LED on, and connects to my AP. > > I just measured the pause at 20 seconds. Is there a reason for that delay? > Why doesn't the WiFi LED turn on sooner? The LED-on isn't the point at which it tries to connect. That's the point at which the association has successfully completed. The LED doesn't turn on sooner because the connection hasn't been established until that point. The question is why does it take so long for the connection to be established? A 10-12 second reconnect time is to be expected: 1. A 1 second delay for the device to be probed and initialized on resume 2. NetworkManager has a 7 second delay hardcoded 3. A 1-2 second delay for scanning to complete 4. A 1-2 second delay for authentication, association, key exchange (if applicable) and DHCP. We can't really do anything about any of these except #2, which will go away as soon as we switch to a newer Fedora base version. It's never gonna be lightning fast. But, this doesn't explain why you can see a 20 second delay, and others have reported 30. I've never been able to reproduce this, so I can't offer a diagnosis. But I once added some diagnostics and confirmed that the basic things do happen: NM fires off a scan really quick after the 7 second delay, and the kernel seems to be scanning on all channels. Next step is for someone who can reproduce this to confirm my findings and add further diagnostics. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
On Wed, Oct 20, 2010 at 01:14:33AM -0700, Hal Murray wrote: > I just measured the pause at 20 seconds. Is there a reason for that delay? > Why doesn't the WiFi LED turn on sooner? When I tested this in the past few months ... avoiding NetworkManager an sticking to shell commands, I could get reconnected after suspend in about three to five seconds. Therefore I think that the problem is related to NetworkManager. > What is a "scan"? # iwlist eth0 scan (effectively this is what is used by NetworkManager when it does a scan ... the results are then passed by NM to Sugar over DBUS.). > Does it check one channel or all 3? It checks all 11, depending on the regulatory domain. > I'd expect most people to be using nearby APs with good signal > strength so they should be easy to find and not require extra scans. A scan can fail to detect an AP because the AP beacon is trodden on by another transmission. Scanning is not a reliable thing; it's not like the APs know they are being scanned and can try harder. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC wireless startup at boot time
> - Preserving "last scan results" may improve user experience. I think that depends on the reason for powering off or closing the lid. If you moved to a new building, you probably need a new AP. If you moved from one tree to another, they are either using the same mesh channel to cooperate (or simplify things), or they are using a different one to avoid interference. If you shut down to save power but didn't move, you probably want to re-connect to the same AP/mesh. > - Waking up the WLAN & scanning ASAP is key -- I think we are reasonably > good there already It doesn't feel that way to me. On lid open, the WiFi LED blinks a few times, finds a few APs, but doesn't find my AP. After a long pause (10+ seconds), it blinks again, finds my AP, turns the LED on, and connects to my AP. I just measured the pause at 20 seconds. Is there a reason for that delay? Why doesn't the WiFi LED turn on sooner? > - Trying to pick quickly which AP to connect to is problematic. The > preferred AP may only appear on the 2nd or 3rd scan. See earlier discussions > about asking NM to wait _longer_ on that task to work on a more complete > list of available networks. What is a "scan"? Does it check one channel or all 3? Assuming that a "scan" checks all 3, I'd expect most people to be using nearby APs with good signal strength so they should be easy to find and not require extra scans. I'm guessing the first set of blinks is only checking one channel. My AP is on channel 6, so that fits if it scans them in the order: 1, 6, 11. Perhaps it should try the last active channel first, or even give the last AP a quick try. (assuming there was a last AP) -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
