[12:31] <asac> so you actually wait till nothing happens anymore ... then you turn off and on and it associates ? e.g. goes to stage3 et al?
[12:32] <asac> or does it start from stage 1 again, but this time goes through to stage 5?
[12:32] <stgraber> asac: http://paste.stgraber.org/3291
[12:32] <stgraber> I receive an associated event after switch rfkill back on
[12:33] <stgraber> then it continues at stage 2
[12:33] <asac> yes great
[12:33] <asac> i see it
[12:33] <asac> why the hell goes all usb down?
[12:33] <stgraber> my kill switch also kills my bluetooth card which is USB :)
[12:34] <asac> stgraber: apparently it doesn't resent the associated event if you set the same essid again
[12:34] <asac> stgraber: ah ok
[12:35] <asac> stgraber: ok when you hang at stage 2
[12:36] <asac> does setting essid to "" trigger the association even again?
[12:36] <asac> stgraber: or better ... set to a not existing one ... then set the right onw again
[12:36] <asac> maybe it just continues
[12:42] <stgraber> setting to not existing works
[12:43] <stgraber> setting to "" doesn't change the essid (iwconfig still shows the same)
[12:44] <stgraber> when setting to a not existing one, I see a "disassociated event", then a "associated event" and it connects correctly
[12:44] <stgraber> so the main problem is that NM try to deassociate using essid "", which in fact doesn't deassociate :)
[12:48] <asac> stgraber: i look at the driver code now ... i am not really adept in kernel code
[12:48] <asac> but from what i read it skips reassociation when essid is changed :/ in case you are already associated
[12:49] <asac> stgraber: yeah we should probably set to no-existing instead of any/off
[12:50] <asac> stgraber: i don't really understand the logic in this driver code
[12:51] <asac>         IPW_DEBUG_ASSOC("[re] association triggered due to BSSID change.\n");
[12:51] <asac>         if (!ipw_disassociate(priv))
[12:51] <asac>                 ipw_associate(priv);
[12:51] <asac> ipw_disassociate returns 0 iif you are currently not associated/associating
[12:52] <asac> for me it looks like it should just be ipw_disassociate(priv); ipw_associate(priv);
[12:52] <asac> without if
[12:53] <asac> further it treats any in the same way as off ... in both cases it runs ipw_associate
[12:53] <asac> imo it shouldn#t do that for off
[12:54] <asac> only for any
[12:54] <asac> stgraber: wanna try to patch those two places?
[12:54] <stgraber> if you have an easy way to rebuild the driver yes
[12:55] <asac> easy way?
[12:55] <asac> does building modules fail for you?
[12:56] <asac> stgraber: have you tried to build the sources from upstream site?
[12:56] <stgraber> yes
[12:56] <stgraber> and had some problem with the ieee80211 thing
[12:57] <asac> stgraber: why do you need that? don't we have that installed/build already?
[12:59] <stgraber> asac: what cmd do you use to build upstream ipw3945 ?
[01:00] <stgraber> a simple "make" complains about duplicate ieee80211 thing
[01:05] <asac> stgraber: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=bash
[01:05] <asac> that builds for me at least
[01:06] <asac> stgraber: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash
[01:08] <asac> stgraber: maybe try unmodified 1.2.2 first5
[01:08] <asac> if that work we can test things
[01:11] <stgraber> asac: http://paste.stgraber.org/3292
[01:13] <asac> hmm
[01:13] <asac> ok
[01:13] <asac> try to: apt-get install ieee80211-source module-assistant
[01:13] <asac> then
[01:13] <asac> sudo module-assistant prepare
[01:13] <asac> sudo module-assistant unpack ieee80211-source
[01:14] <asac> after that it should ubild
[01:17] <stgraber> asac: looks like the ieee80211-source isn't complete, net/ieee80211_radiotap.h is missing
[01:20] <asac> stgraber: what did you do?
[01:21] <asac> for me it just builds
[01:21] <asac> did you try to tweak the INC variable? i didn't need that
[01:22] <stgraber> I had to as module-assistant extract to /usr/src/module and ipw3945 looks for /usr/src/ieee80211
[01:22] <asac> stgraber: did you run module-assistant prepare?
[01:22] <stgraber> yes
[01:23] <asac> stgraber: for me the headers are found ... they are from the unpacked sources (now that i look at it) ... but are in kernel headers directory
[01:23] <asac> stgraber: but prepare should have installed the headers for you?
[01:24] <asac> stgraber: http://paste.stgraber.org/3293
[01:25] <asac> stgraber: http://paste.stgraber.org/3294
[01:26] <Kopfgeldjaeger> bye
[01:30] <stgraber> asac: I have the same result for the find cmd ...
[01:33] <asac> does the make command print the same?
[01:33] <asac> and you really run: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash
[01:33] <asac> thats strange
[01:34] <stgraber> yes
[01:34] <asac> you must have someelse messed up ... /usr/src/linux link exists?
[01:34] <asac> /usr/src/linux-headers-2.6.22-10-generic as well?
[01:35] <stgraber> linux -> linux-headers-2.6.22-10-generic
[01:37] <asac> stgraber: make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash IEEE80211_INC=/lib/modules/2.6.22-10-generic/build/include/
[01:39] <stgraber> same
[01:40] <asac> then i can't tell ... maybe you are not up-to-date or something
[01:44] <asac> stgraber: maybe you added some links when you tried to do ieee8... stuff manually in the past?
[01:44] <stgraber> asac: I'm downloading the complete source tree, maybe it'll find the required bits here :)
[01:44] <asac> stgraber: i doubt that its the required bits
[01:44] <asac> your system has something wierd :)
[01:45] <stgraber> I reinstalled all 2.6.22-10 packages this morning after trying to manually build ipw3945 so my system should be clean
[01:46] <asac> stgraber: strace -eopen -f make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash &> /tmp/out
[01:46] <asac> please post it
[01:46] <stgraber> http://paste.stgraber.org/3295
[01:46] <asac> stgraber: better: strace -eopen -f make IEEE80211_IGNORE_DUPLICATE=y  SHELL=/bin/bash 2>&1 | grep ieee8 > /tmp/out
[01:47] <asac> ok
[01:47] <asac> ok
[01:47] <stgraber> compiled (using linux-source)
[01:47] <asac> stgraber: does /lib/modules/2.6.22-10-generic/build/include/net/ieee80211.h exist?
[01:48] <asac> stgraber: well please install generic kernel
[01:48] <asac> to test
[01:49] <stgraber> that's -generic, I just did : apt-get source linux-image-2.6.22-10-generic and used that as IEEE80211_INC and worked
[01:49] <stgraber> ieee80211.h doesn't exist
[01:51] <stgraber> anyway, I can now make the module so that should be good (even if I normally wouldn't have had to download the ubuntu kernel source package)
[01:53] <asac> stgraber: ok so wait a sec
[01:54] <asac> stgraber: http://paste.stgraber.org/3296
[01:54] <asac> try that patch
[01:54] <asac> DISCLAIMER: i don't know what i do ;)
[01:55] <stgraber> 2 out of 2 hunks FAILED -- saving rejects to file ipw3945.c.rej
[01:57] <stgraber> on clean upstream ipw3945-1.2.2
[01:58] <asac> can you edit it manualyl that way?
[01:58] <stgraber> yes
[01:58] <asac> stgraber: good
[01:58] <LaserJock> it's all asac and stgraber for 3 hrs
[01:59] <asac> LaserJock: yeah ... apparently everyone else have their issues sorted out already ;)
[01:59] <LaserJock> gutsy is perfect! let's go home
[02:00] <asac> of course its perfect ... but still there are things that can be improved ;)
[02:02] <asac> stgraber: the idea is that you receive an association event in case you set a new essid :) and that you don't try to associate if essid is set to off
[02:02] <stgraber> module compiled, let's try to replace the current one :)
[02:04] <stgraber> asac: result with NM is still the same
[02:05] <stgraber> (and no event received)
[02:06] <asac> stgraber: please set iwconfig essid to off
[02:06] <asac> and see if it still reassociates (e.g. nm stopped)
[02:13] <stgraber> asac: exactly the same behaviour as before, off doesn't seem to make it deassociate at all
[02:15] <asac> stgraber: how did you run iwconfig exactly?
[02:15] <stgraber> iwconfig eth1 essid off
[02:16] <asac> stgraber: in man they say that you should escape if you use the keywords
[02:16] <asac> stgraber: iwconfig eth0 essid -- "ANY"
[02:16] <asac> is one example
[02:20] <stgraber> asac: well, if I do : iwconfig eth1 essid -- "off" it'll be the essid "off", not the action off
[02:20] <stgraber> asac: so -- "off" will work, but "niofnbdiono" would have done the same :)
[02:21] <asac> oh right ;)
[02:22] <stgraber> btw, why does "off" deassociate+associate, shouldn't it only deassociate ?
[02:23] <asac> stgraber: well the patch i gave you should fix that
[02:23] <asac> stgraber: current behaviour is any+off deassociate + associate
[02:23] <asac> so i made this patch :)
[02:23] <asac> did you apply it ;) ?
[02:23] <stgraber> yes :)
[02:24] <stgraber> hmm, right that's the first part of your script (didn't really read the code :))
[02:24] <asac> script :)
[02:24] <asac> thats a .c file patch
[02:24] <stgraber> he, it's 2 o'clock :), yes it's C :)
[02:25] <asac> stgraber: can you please try one more thing for today: build with CONFIG_IPW3945_DEBUG=1
[02:26] <asac> oh its already the default
[02:27] <stgraber> yes, but I'd need the debug value to pass to the kernel module
[02:28] <asac> yes
[02:29] <wasabi> Hmm. Looking for guidelines on what's accepted in -updates
[02:30] <asac> stgraber: try 0xffffffff or something
[02:32] <asac> stgraber: i think its 0x1800
[02:32] <asac> that should be SCAN + ASSOC
[02:32] <stgraber> tried with 0xffffffff and 8 (which is WX) and I have no output :(
[02:33] <asac> how did you load?
[02:34] <asac> stgraber: try echo 6144 > /sys/bus/pci/drivers/ipw3945/debug_level
[02:38] <stgraber> I have some debug info with that, but nothing when doing the essid off
[02:40] <stgraber> asac: when doing the essid off with debug being 6252 I see : Sep  2 02:39:21 laptop kernel: [52117.597673]  ipw3945: U ipw_wx_set_essid Setting ESSID to ANY
[02:40] <asac> wow
[02:40] <asac> you have a bit more log for me?
[02:42] <stgraber> http://paste.stgraber.org/3298
[02:42] <stgraber> ^ a bit :)
[02:43] <stgraber> at least it's clear that NM sets the ESSID to ANY and then the driver try to associate
[02:44] <asac> stgraber: well ... as you see off is any
[02:44] <asac> (somehow)
[02:44] <asac> you tried it manually right?
[02:45] <stgraber> hmm, you are right that could well be OFF too as both shows ANY :)
[02:46] <stgraber> last log line is a manual "iwconfig eth1 essid off"
[02:46] <asac> i see in code that i touched AP code not essid
[02:46] <asac> for essid its just zero length string
[02:46] <asac> which means any
[02:46] <asac> apparently wireless tools already does that
[02:46] <asac> e.g. convert off to empty
[02:47] <asac> stgraber: in that log you get an associated event
[02:47] <asac> what kind of testrun was it?
[02:47] <asac> just setting to off while nm was running?
[02:47] <stgraber> it's what I get when loading the module with NM running
[02:48] <asac> but not the complete log
[02:48] <stgraber> so NM setting the device to OFF (-> ANY), then scanning for network and finally me doing the "iwconfig eth1 essid off"
[02:48] <asac> well
[02:49] <asac> yes ... stgraber this issue is not really my problem here ... my problem is that we don't get an associated event when setting essid explicitly
[02:49] <asac> ok now that i see that we cannot differentiate between off and any we have to do try it the hard way
[02:51] <asac> stgraber: have you tried that explicitly connecting in applet still doesn't work?
[02:51] <asac> (i don't think it will ... but who knows)
[02:53] <asac> stgraber: last try for today: http://paste.stgraber.org/3299
[02:55] <asac> stgraber: its in the ...set_essid method
[02:55] <asac> and bascially reassociates explicitly when you set essid explicitly ... even though both are the same
[03:02] <asac> stgraber: still there?
[03:05] <stgraber> asac: yes
[03:05] <stgraber> asac: I was just testing
[03:05] <asac> ok
[03:06] <asac> have you tried the patch? ... to test just set the essid to the same value like you had before
[03:06] <stgraber> it works better (I can now connect to an open wlan)
[03:07] <asac> with that latest patch?
[03:07] <stgraber> I just have some weird thing while switching from a WLAN to another
[03:07] <stgraber> yes
[03:07] <asac> ok
[03:07] <asac> wait a second lets try something not so brutal
[03:07] <stgraber> as you deassociate+associate, it first associate to the first network it finds, then switch to the right one
[03:08] <stgraber> the other main problem is that it still associate with the first network it finds, even if it now lets you connect to it or to another that still cause a problem
[03:08] <stgraber> ipw3945 seems not to scan networks the same way if it's associated or not
[03:09] <stgraber> for example, if it's associated with FON_BEVAIX which is my public WLAN, it will only find my WPA networks after 5 minutes or so :)
[03:09] <asac> stgraber: http://paste.stgraber.org/3300
[03:09] <asac> e.g. replae the two lines we just had with the one line in that patch
[03:09] <stgraber> I have the same behaviour with iwlist eth1 scan where I need to run it 5-6 times before I see all my networks
[03:09] <stgraber> k
[03:10] <asac> it should just send a assoc event ... without actually reassociating
[03:10] <asac> stgraber: i thought your interface is always associated??
[03:11] <asac> (aeh not for nm of course)
[03:12] <stgraber> asac: remember, it's always associated because NM first send this essid off, without NM it isn't
[03:12] <asac> stgraber: actually i think its not right to call it directly
[03:12] <asac> probably it should be queue_work(priv->workqueue, &priv->link_up);
[03:12] <stgraber> hmm, build fails
[03:13] <stgraber> /home/stgraber/Desktop/ipw3945-1.2.2/ipw3945.c:12249: warning: implicit declaration of function ipw_link_up
[03:13] <asac> oh
[03:13] <asac> yeah try what i said above then
[03:13] <asac> warning makes it fail?
[03:13] <asac> maybe better that way
[03:13] <asac> queue_work(priv->workqueue, &priv->link_up);
[03:17] <stgraber> yeah, I managed to do : Wired -> public -> WPA1 -> WPA2
[03:17] <asac> then it stalled?
[03:17] <stgraber> then wanted to come back to public but NM had the bug I showed you before (got stuck at Stage 1)
[03:17] <asac> e?
[03:18] <asac> which bug do you refer to? ... ah the hang
[03:18] <asac> hmm
[03:18] <asac> yes
[03:18] <asac> that should be something different then
[03:18] <asac> stgraber: so what was the default kernel parameter used for no auto association?
[03:19] <stgraber> parm:           associate:auto associate when scanning (default 0 off) (int)
[03:20] <stgraber> so currently, except that hang (which is more or less random) and the fact that it real slow to have a full list of network when associated, everything works fine :)
[03:20] <asac> stgraber: auto? ... didn't you say its 0 ?
[03:21] <asac> stgraber: i found the thing in code ... if associate there is an extra scan suspend_time
[03:21] <asac> so it might be reasonable that you don't get lots of results ... especially since ipw appears to jump on the first wifi it sees ... and probably forgets about the scan results
[03:24] <stgraber> that's a problem when the first wifi it sees is a public hotspot and your personal wifi is detected only after a couple of minutes :)
[03:24] <asac> yeah we can look into that the next days
[03:24] <asac> its probably driver specific
[03:24] <asac> stgraber: can you try to not set to auto ?
[03:24] <asac> (i wonder why we have that set to auto at all)
[03:25] <stgraber> associate=0 by default so it doesn't auto-associate when scanning
[03:25] <asac> ok
[03:25] <asac> then thats a bug
[03:26] <stgraber> the associate comes from NM doing the essid ANY/OFF
[03:26] <asac> stgraber: we can try to fix that tomorrow
[03:26] <asac> i think i know how to make the driver to obey not to do that.
[03:26] <stgraber> cool :)
[03:27] <asac> well don't hope too much
[03:27] <asac> :)
[03:28] <asac> stgraber: imo when you have associate=0 ... then setting ANY/OFF should not associate
[03:28] <asac> right?
[03:28] <stgraber> yes, but that's not the current behaviour :)
[03:28] <asac> yeah question is if thats the desired behaviour?
[03:28] <asac> if so i see the place to add that
[03:28] <stgraber> I don't see why off should associate at all ...
[03:29] <stgraber> even with associate=1
[03:29] <asac> but i don't see a use case for auto association at all
[03:29] <asac> stgraber: off doesn't exist
[03:29] <stgraber> right :)
[03:30] <asac> the difference is probably already eliminated on user-space in wireless-tools
[03:30] <asac> though not really sure
[03:31] <stgraber> ok, so basically if associate=0 then the driver should only deassociate not deassociate+associate
[03:31] <asac> yes
[03:31] <asac> so with associate=0 it means OFF
[03:31] <asac> while with associate=1 it means ANY :)
[03:31] <asac> no idea what that would break ;)
[03:31] <asac> i think the only thing that wouldn't happen is that user gets initially connected to some random network
[03:32] <asac> which might be nice for noops ... but on the other hand often not the right network anyway
[03:32] <stgraber> which is current behaviour for most other drivers no ?
[03:32] <asac> no idea ... i just got dragged into this driver thing ...
[03:33] <asac> do they all get an assocaite paratmeter?
[03:33] <asac> can you see that?
[03:33] <stgraber> bcm43xx doesn't
[03:34] <stgraber> and same for madwifi
[03:34] <asac> stgraber: what parameters do those get?
[03:36] <stgraber> countrycode (for the channel limit I guess), outdoor (?), xchanmode (extanded channel mode), rfkill (enable rfkill), autocreate (autocreate if), ratectl, ath_debug for madwifi
[03:37] <asac> stgraber: so how is the current behaviour?
[03:37] <stgraber> locale (?), country (same as madwifi), noleds (disable led), fwpostfix (choose what firmware to load)
[03:37] <asac> if you boot ... you still get an associated wifi next to your connected wired?
[03:38] <stgraber> with bcm43xx and madwifi doing : iwconfig if essid off( or any) doesn't make the card to associate
[03:38] <asac> ok so maybe its really just off for them
[03:38] <asac> and ipw implemented just any :)
[03:38] <stgraber> :)
[03:38] <asac> well they tried to implement off ... but failed ;)
[03:39] <asac> because they forget the associate config test when essid is set
[03:39] <asac> and associate always
[03:40] <asac> wow they even overwrite the associate parameter once you configured essid off/any
[03:46] <asac> stgraber: last for real: http://paste.stgraber.org/3303
[03:54] <stgraber> asac: can you paste your .c somewhere so I'm sure mine is clean :)
[03:57] <asac> does it fail?
[03:57] <asac> i mean we were diverged from the beginning :)
[03:58] <asac> stgraber: http://people.ubuntu.com/~asac/ipw3945.c
[03:59] <asac> no idea if i edited something else at some point
[03:59] <asac> (seemed like i did because you couldn't apply the patch)
[04:00] <asac> stgraber: sorry i made a mistake :)
[04:00] <stgraber> FATAL: Error inserting ipw3945 (/lib/modules/2.6.22-10-generic/ubuntu/wireless/ipw3945/ipw3945.ko): Unknown symbol in module, or unknown parameter (see dmesg)
[04:00] <stgraber> oh, saw the mistake :)
[04:01] <stgraber> s/deassociate/disassociate/
[04:01] <asac> yes
[04:01] <asac> stgraber: should work with that imo
[04:02] <asac> stgraber: ok reuploaded the .c file (which compiles) ... but still no idea what else i edited at some point in there
[04:03] <stgraber> good this one doesn't auto-associate, I can also connect to a network without any problem, but switching back to Wired, it associates with my Open wifi in the background
[04:04] <stgraber> so problem is 50% solved :)
[04:04] <stgraber> well, more 80% I'd say :)
[04:04] <asac> hmm
[04:04] <asac> ok
[04:04] <asac> does it harm your ability to go back to wifi?
[04:06] <stgraber> I'll try one more time but I think the only thing it'll cause is that it'll scan less frequently after you did : wired -> wifi -> wired
[04:06] <asac> ok
[04:07] <stgraber> argh, no, I can't go back to wifi :(
[04:10] <asac> stgraber: well i would need a driver debug log then again :)
[04:10] <asac> but maybe tomorrow
[04:10] <stgraber> as usual, as it's already associated with the network it doesn't reassociate
[04:10] <stgraber> so problem is half-solved :)
[04:10] <asac> stgraber: don't you see an associated evnt in log?
[04:11] <asac> (the output we added to network manager)?
[04:11] <asac> when trying to go back?
[04:11] <stgraber> yes :)
[04:11] <stgraber> (which is strange ...)
[04:11] <asac> you see it?
[04:11] <asac> where does it hang?
[04:11] <asac> maybe its again the other hang issue?
[04:12] <asac> and next time you try it works longer?
[04:12] <stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  SUP: sending command 'ENABLE_NETWORK 0'
[04:12] <asac> e.g. you can go to wired/wifie more than once?
[04:12] <stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  SUP: response was 'OK'
[04:12] <stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  Activation (eth1) Stage 2 of 5 (Device Configure) complete.
[04:12] <stgraber> Sep  2 04:09:40 laptop NetworkManager: <info>  wireless_event_helper - associated event
[04:12] <stgraber> no it's not the hang issue as I can go back to wired with having to kill NM
[04:13] <asac> what happens after that?
[04:13] <stgraber> nothing till I switch back to wired
[04:14] <asac> stgraber: but no Activation (eth1) Stage 2 of 5 (Device Configure) successful. ?
[04:14] <asac> before that?
[04:15] <stgraber> asac: http://paste.stgraber.org/3304
[04:19] <asac> stgraber: ok i think the link_up is not enough then
[04:19] <asac> with disassociate/assocaite instead of the queue_work( ... link_up) it should work i hope
[04:20] <asac> but not today :)
[04:20] <asac> night!
[04:20] <stgraber> good night
[04:20] <asac> and thanks for all the testing !
[04:20] <stgraber> no problem
[04:22] <jds663> was Xgl made default in this last batch of updates and how the heck do I stop it from trying to load?!? It's way too slow for my card..
[04:22] <jds663> the cpu load is at 100% xgl... and I have never run that xserver
[04:24] <mjg59> No. It's in universe. We've never shipped it by default
[04:26] <jds663> this is strange after an update it's refusing to boot without it.. and ive even removed the package so now it just "stops" when i login and goes no further.. could this have been the kubuntu team? and where might I look to find out where it is executing this.. ive looked in kdmrc and several Xsession/X11 files...
[05:46] <Maczimus> Love Gutsy, was there a recent update that makes ATI cards work with the effects?

[09:56] <stgraber> asac: I've just built the ipw3945 driver with the latest ipw3945.c you've uploaded and it's almost perfect (deassociation works fine when setting any)
[09:56] <stgraber> asac: the only problem is that if I do the following : wired -> public -> private1 -> private2 -> private1 -> public (failed and fallback to wired)
[09:57] <stgraber> asac: so I can connect to an open network only if it's the first network I try to connect to, otherwise it doesn't even try to associate (iwconfig shows off/any)
[09:57] <stgraber> hi Hobbsee
[10:10] <stgraber> asac: http://paste.stgraber.org/3308 (log of first connect to open network (working))
[10:10] <stgraber> asac: http://paste.stgraber.org/3307 (log of switch from WPA to open network (not working))
[12:01] <StevenK> infinity: Ping, re: libnss-db some more. And I have a question about a promotion.
[01:18] <asac> stgraber: i need the full driver logs
[01:20] <asac> stgraber: and how about wired -> public ->  wired -> public -> wired -> public ... i assume it doesn't work as well?
[01:25] <stgraber> right
[01:34] <stgraber> ok, I've the debug message, now let's try to have some interesting ones :)
[01:36] <stgraber> asac: http://paste.stgraber.org/3311
[01:37] <stgraber> btw, it looks like a wpa_supplicant problem
[01:41] <asac_> stgraber: i was off :/
[01:42] <asac_> 13:33 < stgraber> ok, I've the debug message, now let's try to have some interesting ones :)
[01:42] <asac_> 13:39 < asac> huh?
[01:42] <asac_> stgraber: if you have debug=0xffffffff
[01:42] <asac_> then it should be interesting enough ;)
[01:43] <asac_> stgraber: ok i think i found the log on your paste server
[01:44] <asac_> 3311?
[01:45] <asac_> stgraber: hmmm that run is again a bit strange ... we see:
[01:45] <asac_> #
[01:45] <asac_> Sep  2 13:36:07 laptop NetworkManager: <info>  Error opening supplicant global control interface.
[01:45] <asac_> #
[01:45] <asac_> Sep  2 13:36:07 laptop NetworkManager: <WARN>  real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
[01:45] <asac_> we didn't see that before, right?
[01:54] <jc-denton> how can i check if a box is performing well?
[01:55] <asac> stgraber: you know our workaround we did in nm to unset the essid in stage1? ... probably we don't want that anymore now.
[02:01] <stgraber> asac: right, I tried to disable the patch but after that I wasn't able to apply the wpa_supplicant patch anymore
[02:03] <Hobbsee> jc-denton: #ubuntu for support, please see teh /topic
[02:03] <jc-denton> well
[02:03] <jc-denton> last time i asked there for something specific, nobody had a clue
[02:03] <jc-denton> here people know stuff..
[02:04] <asac> stgraber: ok will do it
[02:04] <Hobbsee> jc-denton: run top, and look at the stuff off that.
[02:04] <jc-denton> heh
[02:04] <Hobbsee> jc-denton: it still doesnt make it the right channel (it's nothing to do with ubuntu development), and it's also a weekend.
[02:04] <jc-denton> well i did that
[02:05] <Hobbsee> "run well" is not very descriptive, either.
[02:05] <jc-denton> well i don't have anything running on the box
[02:05] <Hobbsee> does a low load mean that it's running well?  no runaway processes?
[02:05] <jc-denton> i tested disk io with hdparm
[02:05] <jc-denton> and it seems to work fine
[02:05] <jc-denton> but when i run apt-get install something
[02:05] <jc-denton> for example
[02:05] <jc-denton> "building dependency tree" takes some time
[02:05] <jc-denton> and it's a fresh install
[02:06] <jc-denton> on my laptop it's much faster and i have many things installed
[02:07] <soren> jc-denton: If you want help even though you're asking user questions in a development channel, you could at least have the decency to ask proper questions that we can actually answer.
[02:07] <sits> .o0 ( hmm, I wonder if jc-denton can get answers here then maybe I should try too )
[02:08] <jc-denton> lol
[02:08] <sits> jc-denton: I jest I jest
[02:08] <Hobbsee> sits: that's why we discourage such things
[02:08] <sits> jc-denton: but people do go by convertion
[02:08] <soren> jc-denton: With the information you've given, "you can check if someone has hammered on it with an axe" would be a possible response to "how can i check if a box is performing well?
[02:08] <Hobbsee> sits: because people *do* do that
[02:09] <Hobbsee> soren: *snorts with laughter*
[02:09] <sits> (I really did have a question before you arrived but read the topic and thought.. Hmm better not)
[02:09] <jc-denton> well ok
[02:09] <Hobbsee> soren: good thing i didnt have my water in my hand!
[02:09] <jc-denton> i checked disk io with hdparm
[02:09] <jc-denton> it seems fine
[02:09] <jc-denton> although hdparm says it supports only 16 bit for io
[02:09] <soren> jc-denton: Well, when you run apt-get update on a machine from the early nineties, it takes some time.
[02:09] <Hobbsee> sits: what's the quesiton, out of curiousity?  we'll see if you can phrase yours better than jc-denton can
[02:09] <jc-denton> it's not that old
[02:09] <soren> jc-denton: Oh. I didn't know. You didn't say.
[02:10] <jc-denton>  IO_support   =  0 (default 16-bit)
[02:10] <jc-denton> however if i run hdparm -tT speed seems to be resonable
[02:10] <soren> jc-denton: Building dependency trees is not really an io-bound operation.
[02:10] <sits> Hobbsee: is gnome-power-manager in Gutsy broken with regard to dbus?
[02:11] <jc-denton>  Timing cached reads:   624 MB in  2.00 seconds = 311.73 MB/sec
[02:11] <jc-denton>  Timing buffered disk reads:  172 MB in  3.01 seconds =  57.10 MB/sec
[02:11] <jc-denton> soren: cpu?
[02:11] <sits> I have just tried compiling the python test example, fixing it because the example I had was old and then testing the gnome-inhibit applet while closing my laptop's lid
[02:11] <soren> jc-denton: Yes. Does it have one?
[02:12] <jc-denton> celeron 2.6 ghz or so
[02:12] <sits> jc-denton: those speeds are very high. Now here's a bit of advice before a flee in terror
[02:12] <Hobbsee> sits: ah.  got no idea, ask ogra on monday
[02:12] <soren> jc-denton: It's quite possible that people in #ubuntu could actually answer your "question" if it had any information in it.
[02:12] <Hobbsee> sits: (or wait for an update)
[02:12] <jc-denton> so building dependency tree is a cpu bound operation?
[02:13] <sits> jc-denton: I'd check your CPU usage when you do update. I have used servers with a throughput lower than 311Mbyte/s
[02:13] <jc-denton> that's already a hint
[02:13] <soren> jc-denton: Well, even with a 100 GHz machine it's not an instantaneous operation.
[02:13] <sits> jc-denton: I would have thought so but this is easier for you check than me. Top will help you out.
[02:13] <jc-denton> humm
[02:13] <soren> jc-denton: You may remember that all you've said is "it takes some time".
[02:14] <sits> if I just couldn't stop myself then I would crack out oprofile and start looking at the performance stats that that produced couple with cachegrind runs
[02:14] <jc-denton> well on my laptop its less then a sec
[02:14] <sits> jc-denton: at a more basic level you can go on a syscall hunt by looking at the output produced by strace
[02:14] <soren> jc-denton: That sounds nice. You have still not told us how long it takes on the machine that you think is having problems.
[02:15] <Hobbsee> soren: heh.   with this kind of thing, i'm not surprised that people whine about their questions in #ubuntu not being answered.
[02:15] <soren> Hobbsee: Quite.
[02:15] <jc-denton> soren: how can i mesure that?
[02:15] <sits> jc-denton: but the time it should take will be hard to pin down. You will need to do a lot of serious work to be able to answer that with any accuarcy
[02:16] <soren> jc-denton: How did you measure it on your laptop?
[02:16] <jc-denton> err measure
[02:16] <jc-denton> just by looking
[02:16] <soren> jc-denton: That sounds like a good starting point. Do that.
[02:16] <sits> OK that's enough spam from me.
[02:16] <soren> jc-denton: Dude....
[02:16] <jc-denton> wait
[02:17] <sits> Hobbsee: thanks for the advice - it's a bit busy in here for me so see you round!
[02:17] <soren> jc-denton: I suggest you stop this, take your time to actually formulate a question with actual information in it, and then come back.
[02:17] <Hobbsee> where 'come back' is to #ubuntu
[02:17] <soren> jc-denton: So far, all you've given us is "'apt-get install' takes longer than I expect it to on a machine with a cpu and a harddrive in it. Why is that?"
[02:18] <soren> jc-denton: With that amount of information, I might as well advice you to check if you're running it on 110 V rather than 230 V.
[02:18] <Hobbsee> soren: "because someone smashed it with a hammer out of sheer frustration, due to the user's incompetence at asking questions"
[02:18] <soren> jc-denton: I don't mean to be offensive. I'm just trying to make it very clear that you need to give us something to work with here.
[02:19] <Hobbsee> jc-denton: you'll probably find http://www.sabi.co.uk/Notes/linuxHelpAsk.html helpful
[02:19] <jc-denton> aha
[02:19] <Hobbsee> to stop wasting other people's time, and all...
[02:19] <jc-denton> Mr Blissex
[02:19] <soren> ?
[02:20] <jc-denton> http://rafb.net/p/FSEmmu48.html
[02:20] <jc-denton> so can you have a look at this
[02:21] <jc-denton> soren: heh thx i didn't think about the power
[02:22] <soren> jc-denton: that's a start. Some information about the differences between the two machines might be good, too.
[02:22] <jc-denton> how can i check the temperature of the cpu
[02:22] <Hobbsee> jc-denton: now you're *really* getting back to #ubuntu type questions.
[02:22] <jc-denton> well then thx for first
[02:23] <jc-denton> the hint that building dependency tree is a cpu bound operation already gave me some hint
[02:24] <soren> jc-denton: Ok, here's a list of info to gather so that you can ask again in #ubuntu and probably get an answer: Contents of /proc/cpuinfo, output from "uptime", those timings you already gave, output of "free". That's just about the minimum of information that is needed to even start helping you.
[02:24] <jc-denton> free is ok
[02:25] <soren> No!
[02:25] <Hobbsee> jc-denton: no, no.  you take the list, then you ask #ubuntu.  you dont ask us.
[02:25] <jc-denton> lol sry
[02:25] <soren> You can't just say "free is ok". If you want anyone to give you answers, you have to give them information!
[02:25] <jc-denton> i'll stop asking
[02:26] <soren> Oh, also add the contents of /etc/apt/sources.list to the list of stuff to provide.
[02:26] <soren> The *entire* contents, I might add. Not just the stuff you find interesting.
[02:27] <jc-denton> humm maybe
[02:28] <soren> jc-denton: You need to understand that the answer probably lies in one of those pieces of information, but if *you* look at them individually, they probably will all look fine, but you have a problem don't you. So it might just be that you're misinterpreting stuff, and if there's something that's annoying, it's people asking for help, but refusing to give the information that makes it possible to help them.
[02:28] <jc-denton> i see
[02:28] <soren> jc-denton: More information is *always
[02:28] <soren> * better than less.
[02:29] <jc-denton> not always
[02:29] <jc-denton> if there is too much it's probably not good
[02:29] <jc-denton> but better a bit more then a bit too less
[02:29] <soren> When asking for help, yes.
[02:29] <Hobbsee> jc-denton: then people can sift through it.
[02:29] <jc-denton> i agree
[02:30] <soren> In my 13 years in this business, I have only once or twice had someone give me too much information when I was supposed to help them.
[02:31] <Hobbsee> oh dear.  people, please stop filing crap bugs.
[02:31] <soren> And by "too much" I mean "so much information that it became annoying trying to make sense of it".
[02:32] <soren> Hobbsee: do you have a bug number, or is it just a general observation? :)
[02:32] <Hobbsee> soren: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/136761
[02:32] <ubotu> Launchpad bug 136761 in firefox "Cannot open some website......" [Undecided,New] 
[02:32] <soren> It's not "too much information" when there's information that turns out not to be relevant to the problem.
[02:32] <Hobbsee> soren: there was also one about how windows XP was much more automated and simple, and linux should be fixed to be like it, in this day and age...yada yada yada
[02:32] <soren> Hobbsee: Have you fixed that one yet?
[02:33] <soren> Hobbsee: Otherwise get on it, and make it snappy!
[02:33] <Hobbsee> soren: nope!
[02:33] <soren> Aw, come on.
[02:33] <Hobbsee> vaguely
[02:34] <soren> Oh, I meant the "make linux more like XP" bug.
[02:34] <Hobbsee> soren: ahh.  sure, where fixed is "hit it with the WONTFIX stick"
[02:34] <Hobbsee> oh, and telling him to run the command that he was writing over
[02:37] <Hobbsee> i'd really like to know why it's telling them to report it, though.
[02:41] <zul> Hobbsee: there was also a bug report on why cant i fix my windows dll
[02:41] <Hobbsee> zul: *lovely*
[02:41] <zul> lemme see if can see still find it :)
[02:42] <zul> firefox has like advocacy bugs where they encourage users to write to the webmaster and ask them to fix it
[02:44] <Hobbsee> i'd prefer a stab-over-http for that particular webmaster, though
[02:45] <zul> Hobbsee: yes we know how violent you are ;)
[03:21] <Moniker42> hey, are the Gutsy wallpapers going to be available in 1920x1200?
[03:22] <Moniker42> because some of them look very nice indeed... but the previous wallpapers haven't been available in double-mega-Dell size :)
[04:20] <geser> Mithrandir: please give-back ladcca on lpia. Thanks.
[04:33] <geser> Mithrandir: please give-back sdlgfx on lpia. Thanks.
[04:37] <geser> Mithrandir: please give-back date on lpia. Thanks.
[04:38] <geser> Mithrandir: please give-back quadprog on lpia. Thanks.
[04:39] <geser> Mithrandir: please give-back vr and rgl on lpia. Thanks.
[04:45] <AlinuxOS> https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677
[04:45] <ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
[04:45] <AlinuxOS> tribe 5 is out.
[04:45] <AlinuxOS> asac, hello do you have some news regard this ?
[04:46] <Hobbsee> !weekend | AlinuxOS
[04:46] <ubotu> AlinuxOS: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[04:46] <AlinuxOS> Hobbsee, uh... sorry! :)
[04:47] <AlinuxOS> Hobbsee, + devels, have a nice weekend!
[05:06] <Mark_27> hi all
[05:08] <Hobbsee> AlinuxOS: :)
[05:08] <Hobbsee> AlinuxOS: i wish.  i'll have a nice weekend, if you'll do this rotten physics assignment for me?
[05:11] <Hobbsee> doko: please fix gcc-snapshot maintainer field in debian, if you havent done so already.  motu list doesnt need to hear about it
[05:11] <bddebian> Heya
[05:13] <doko> Hobbsee: you are not the first one ...
[05:14] <Hobbsee> doko: ah cool.  didnt think i would be, i just saw more mail hit the ML
[05:15] <alex-weej> Hobbsee: are you doing a physics degree?
[05:15] <bddebian> doko: Is there any chance I could bug you about a Java package for a minute?
[05:15] <Hobbsee> alex-weej: i was.  it's now a computing degree, but i'm still taking bits of physics
[05:56] <Mithrandir> geser: all given-back
[05:56] <Hobbsee> good morning Mithrandir!
[05:58] <bddebian> Mithrandir: Hi.  jmagick has been in the archive since Dapper at least and was FTBFS.  I got it to build but the binaries are in NEW.  Is that because it has never successfully built before?
[05:59] <Mithrandir> bddebian: probably, yes.
[05:59] <bddebian> OK, thx
[06:01] <ScottK> Mithrandir: would you please give-back taskjuggler on lpia?
[06:06] <bddebian> haha
[06:26] <stgraber> asac: did you manage to disable the patch ?
[06:30] <mike__> deser you around?
[06:31] <mike__> desrt around?
[06:31] <asac> stgraber: wow :) ... i took some rest, was at sport
[06:33] <stgraber> asac: me too :)
[06:36] <asac> stgraber: maybe i can get things up later ... i have to cleanup the ipw3945 code as well ... there is still this OFF/ANY thing in place for the set_bssid case ... which might cause troubles :)
[06:36] <asac> stgraber: i will let you know
[06:37] <asac> stgraber: maybe one thing ... do you always see:
[06:37] <asac> #
[06:37] <asac> ep  2 13:36:07 laptop NetworkManager: <info>  Error opening supplicant global control interface.
[06:38] <asac> #
[06:38] <asac> Sep  2 13:36:07 laptop NetworkManager: <WARN>  real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
[06:38] <asac> or did it just happen the one time you captured the debug output?
[06:38] <asac> (in http://paste.stgraber.org/3311)
[06:40] <stgraber> asac: it always happen when I do : wired -> something -> public
[06:40] <stgraber> asac: so I have it everytime NM fails to connect
[06:42] <asac> stgraber: ok ... what is something?
[06:43] <asac> do you get it as well when you just do wired->public->wired->public ?
[06:43] <stgraber> yes
[08:15] <asac> stgraber: wow the git branch of ipw is a mess
[08:15] <asac> stgraber: it just stopped to receive commits short after 1.2.0
[08:16] <asac> stgraber: http://www.intellinuxwireless.org/repos/?p=ipw3945.git;a=summary
[08:16] <asac> stgraber: on sourceforge there is no cvs ... so this should be the real home
[08:17] <stgraber> asac: that's maybe because intel is developing iwl3945 ?
[08:20] <asac> maybe ... but still they should push their commits to that repo
[08:20] <asac> even if they don't do active development on it :)
[08:20] <asac> that branch is just stuck at 1.2.0 + 5 commits
[08:20] <asac> last commit 6 months ago
[08:21] <asac> while last release was on  Jul 31 2007
[08:23] <asac> email sent to intel devs ... lets see :)
[08:29] <asac> stgraber: can you please apply these two patches (manually) and tell me if they break more things ?
[08:30] <asac> stgraber: http://ipw3945.sourceforge.net/patches/ipw3945-1.1.3-2.6.20-register.patch ([PATCH 1/1]  Change call to the deprecated pci_driver_init to pci_register_driver)
[08:30] <asac> stgraber: http://ipw3945.sourceforge.net/patches/ipw3945-1.2.1-inta-fix.patch (Fix potential driver lockup problem)
[08:30] <asac> oh and:
[08:30] <asac> http://ipw3945.sourceforge.net/patches/ipw3945-1.1.4.essid.patch (bogus character appended to ESSID)
[08:30] <asac> which i already saw in log
[08:31] <asac> to test things like hibernate/suspend would be nice to know as well
[08:32] <stgraber> aren't they already included as we are using 1.2.2 and your patches are 1.1.3, 1.1.4 and 1.2.1 ?
[08:32] <asac> i don't think so ... if you see that they are ... fine :)
[08:33] <alex-weej> is it possible to "burn" ISO files to a flash device?
[08:33] <alex-weej> so i can boot from flash instead of wasting CDs all the time?
[08:33] <asac> you can copy the content to a flash filesystem i guess
[08:34] <asac> but i am the wrong person to ask :)
[08:34] <asac> alex-weej: you can use RW cds :)
[08:34] <alex-weej> of which i have none
[08:34] <alex-weej> :P
[08:35] <stgraber> asac: at least I can't apply any of them
[08:35] <asac> yeah :) ... but get two and be happy for a long time
[08:35] <alex-weej> i'm just thinking it would be cool if we could easily support using flash devices to bootstrap an ubuntu system rather than wasteful (and harmful-to-the-environment!) CDs
[08:35] <stgraber> 1.1.3 and 1.1.4 seems to be already applied (according to patch)
[08:36] <Mithrandir> alex-weej: sure, it's just slightly more fiddly to write an image to a USB device, and in practice I believe it requires a linux machine already present.
[08:36] <stgraber> and it's unable to apply 1.2.1
[08:37] <asac> stgraber: ok fine
[08:37] <asac> they are either in ... or the source-base has drifted away too far to tell from a glance
[08:37] <asac> i think its safe to assume that we have them
[08:37] <stgraber> asac: manually looking at the code I didn't find where I'd manually patch 1.2.1
[08:37] <alex-weej> i'd imagine the installer would be much quicker to copy from USB than CD too, or are the reads from CD generally pretty sequential?
[08:38] <asac> probably
[08:38] <asac> it should work ... wait till someone who knows the details pops-up
[08:38] <broonie> Flash devices aren't usually enormously fast, either.
[08:38] <asac> maybe try tomorrow
[08:39] <asac> broonie: maybe the throughput is bad ... but the access-latency should be better
[08:39] <asac> (just out of my guts)
[08:41] <leip`> " gpgme created no signature for './dists/feisty/Release.new'!
[08:41] <leip`> :-(
[08:42] <leip`> Google offers no help
[08:42] <leip`> this time..
[08:43] <cjwatson> alex-weej: CD seeks do suck, though we sort the files in the ISO9660 image in an attempt to minimise seeks
[08:43] <leip`> I'm trying to add my new package to my new repository
[08:43] <alex-weej> ok
[08:43] <leip`> Packaged and " reprepro includedeb feisty <package-name-and-path>
[08:43] <cjwatson> alex-weej: as far as USB goes, depends on the device and whether it's USB2
[08:43] <cjwatson> (obviously)
[08:43] <alex-weej> i mean i know there are guides and stuff to do this, i just think it would be incredibly cool and edgy if we supported install-from-USB or something
[08:45] <desrt> so... how's the tribe?
[08:46] <leip`> No default secret key... hmm..
[08:48] <asac> stgraber: oh no ... i cannot even clone that git repo ... (while iwlwifi works) ... so i think its completely abandoned
[08:49] <cjwatson> alex-weej: err, we do - it's been documented in the installation guide since hoary or thereabouts
[08:49] <stgraber> uhm, so they really want everyone to switch to iwlwifi ? (it's still marked as devel release on their website)
[08:49] <asac> stgraber: no idea ... hope the devs reply
[08:50] <cjwatson> if you're using that many, RWs would be a better idea anyway
[08:50] <Mithrandir> alex-weej: I wonder why you didn't just get some RWs instead.
[08:50] <alex-weej> hyperbole alert :P
[08:50] <Mithrandir> it's not like they're hard to get.
[08:50] <cjwatson> https://help.ubuntu.com/7.04/installation-guide/i386/boot-usb-files.html
[08:51] <alex-weej> that is awesomely, awesomely cool
[08:52] <alex-weej> bit hopeless for windows users though i guess
[08:52] <asac> stgraber: now that we have ipw3945 improved ... maybe we can do the same for iwlwifi too :) ... wasn't it you who claimed that it works like a charme?
[08:53] <stgraber> asac: no but I heard it does, only problem is that here it creates an interface called wlan0_renamed or something similar that NM doesn't detect
[08:54] <stgraber> asac: so I wasn't really able to test it
[08:54] <leip`> Man, pgp wants me to do random stuff to seed it's random number generator, but I'm in an ssh session!
[08:54] <asac> stgraber: there was a guy in a bug that claimed that it just worked with nm
[08:54] <leip`> And it ran out of random bits and is asking me to do more
[08:55] <asac> stgraber: ok ... he revised his claim
[08:55] <leip`> I tried typing random stuff and sleeping it and doing a find / ... but it's still stuck there
[08:55] <leip`> *gpg
[08:55] <leip`> *whatever...
[08:56] <asac> stgraber: ok he says that he needed remove iwl again ... and then insert it ... finally he had just wlan0
[08:56] <asac> stgraber: http://paste.stgraber.org/3315
[08:57] <asac> stgraber: just look at the bottom of bug 121439 for more info
[08:57] <cjwatson> leip`: I believe disk I/O typically feeds the entropy pool
[08:57] <ubotu> Launchpad bug 121439 in network-manager "[Gutsy] Network Manager Applet can't connect wireless with ipw3945 driver" [High,Confirmed]  https://launchpad.net/bugs/121439
[08:58] <asac> :)
[08:58] <cjwatson> leip`: (may take a while, but it's one approach you can take remotely)
[08:58] <leip`> cjwatson: How can I skim off /dev/random? Perhaps I can create a script
[08:59] <cjwatson> leip`: hm? you shouldn't have to do anything to it directly
[08:59] <cjwatson> leip`: just do stuff on disk, it'll feed in randomness automatically
[08:59] <leip`> cjwatson: I thought you could echo random stuff out of /dev/random?
[08:59] <cjwatson> leip`: oh, sure, but that won't help you fill up /dev/random with more randomness :)
[08:59] <cjwatson> leip`: dd is the traditional shell tool for extracting random bytes
[09:00] <stgraber> asac: it's still wlan0_rename here :(
[09:00] <asac> stgraber: did you try to blacklist as one of the last comments suggests?
[09:00] <cjwatson> (obviously it does lots of other stuff too, but when applied to /dev/random - or more usually /dev/urandom if your application is not cryptographic)
[09:02] <siretart> asac: FYI, I'm noticing bug #124706 even with wpasupplicant 0.5.8. therefore I can say you that I don't see any regression nor improvement regarding NM and ipw3945 :(
[09:02] <ubotu> Launchpad bug 124706 in network-manager "NM sometimes drops connection before associating, logfile says assertion `dev != NULL' failed " [Undecided,Confirmed]  https://launchpad.net/bugs/124706
[09:02] <asac> siretart: yes ... we are currently trying to improve the driver
[09:03] <leip`> cjwatson: Thanks for the info
[09:03] <asac> siretart: however i found in ipw bugtracker that some issues just happen with 0.6.0 ... but in the end those issues should be due to the driver as well.
[09:03] <asac> siretart: so lets first see how far we get with driver fixes
[09:03] <leip`> cjwatson: I'm doubling the result of find over and over again switching between two files
[09:03] <siretart> asac: fixes in the ipw3945 or iwl3945 driver?
[09:04] <leip`> 244M test  336M test1
[09:04] <leip`> haha
[09:04] <cjwatson> leip`: there's probably little point in that since it will only be hitting the cache, not the actual disk
[09:04] <asac> siretart: for us: ipw3945
[09:04] <asac> siretart: as thats most likely what we will ship
[09:04] <cjwatson> leip`: I'd try writing arbitrary (though not actually random) stuff, reading it back, deleting it, repeating
[09:04] <siretart> ok
[09:04] <cjwatson> possibly throw in a sync after each write
[09:05] <leip`> cjwatson: Why aren't my two monsterous files hitting disk?
[09:05] <stgraber> asac: blacklist + reboot doesn't help
[09:05] <asac> siretart: i will bring up our ipw code somewhere ... will let you know :) ... maybe you can help to test ;)
[09:05] <leip`> cjwatson: I "cat test >> test1 && cat test1 >> test"
[09:06] <asac> stgraber: hmm ok
[09:07] <leip`> finished!
[09:07] <siretart> asac: sure
[09:09] <stgraber> asac: ok, managed to have it rename to wlan0 using an udev rule
[09:10] <asac> stgraber: rock
[09:11] <stgraber> asac: this driver works like our patch ipw3945 minus the daemon, which is great
[09:12] <stgraber> It also fails to connect to open network when doing wired -> wpa -> public or wired -> public -> wired -> public
[09:12] <stgraber> which tends to show that this bug isn't driver related but NM related
[09:13] <stgraber> this driver also seems a bit faster to associate than the ipw3945
[09:13] <cjwatson> leip`: you may not have forced a sync, so they could still just be in cache ...
[09:13] <cjwatson> (conceivably. dunno.)
[09:14] <cjwatson> ha! working whatis/apropos for non-English languages
[09:15] <stgraber> asac: same "couldn't connect to the supplicant" thing
[09:15] <cjwatson> only a 45K diff or so ;-)
[09:18] <leip`> hmmm apt-get remove on my package is leaving stuff...
[09:21] <asac> stgraber: i doubt that the above example shows that its not-driver related
[09:21] <asac> but we will see
[09:23] <asac> stgraber: i have pushed an ipw branch that contains our current changes (cleaned-up)
[09:23] <asac> stgraber: https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac
[09:23] <asac> stgraber: can you try to build that and submit a debug log of the wired->public->wired->public testcase?
[09:24] <asac> stgraber: maybe its better now ... as the previous log really ran into the code i placed in the wrong method ;)
[09:27] <asac> stgraber: what happens if you try multiple times when you get that "couldn't connect to the supplicant"  thing?
[09:27] <asac> stgraber: does it work again? or never?
[09:28] <stgraber> argh, it seems that I can't unload iwl3945 ...
[09:28] <asac> stgraber: yeah ... that was pointed out in bug :)
[09:29] <asac> you should reboot i guess
[09:29] <stgraber> argh, brb then :)
[09:35] <stgraber> ok, so I always have that : real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
[09:35] <stgraber> problem is that I can't really force it to try again as it fallback to wired
[09:44] <stgraber> asac: ^
[09:47] <asac> stgraber: opk i updated the nm ... dropped the hack we introduced et al:
[09:47] <asac> https://code.launchpad.net/~asac/network-manager/ubuntu.0.6.x.dev.opennet
[09:47] <asac> stgraber: why not? can't you just click on the wireless network ap again?
[09:48] <stgraber> hmm, yes, doesn't help
[09:48] <asac> stgraber: ok ... please try the branch above
[09:48] <stgraber> pulling
[09:48] <asac> stgraber: maybe it helps here ...
[09:48] <asac> stgraber: otherwise ... have you build the ipw branch?
[09:48] <stgraber> yes, that's the ipw3945 I'm currently using
[09:49] <asac> stgraber: if it works i would ask siretart to see if he can reproduce the "cannot connect" issue and then see if using older wpasupplicant helps
[09:49] <asac> stgraber: can you please post a debug log of wired->public->wired->public as well?
[09:49] <asac> stgraber: i just want to confirm that the driver behaves now as i want it to behave :)
[09:50] <asac> stgraber: but at best test the new network-manager from my branch
[09:51] <Kano> hi, is there a special trick needed to use firmware in /lib/firmware/$(uname -r)?
[09:52] <asac> stgraber: hmm i see that there are still two patches in the dev.opennet branch that i didn't want ... anyway they should do no harm for us
[09:54] <Kano> hmm maybe in hotplug functions
[09:54] <stgraber> asac: I haven't been able to reprodue the wired -> public -> wired -> public problem, it only happens when doing wired -> wpa -> public now
[09:55] <asac> stgraber: ok so bouncing betweek public -> wired works as long as you try?
[09:56] <stgraber> asac: http://paste.stgraber.org/3316
[09:56] <asac> stgraber: what case is that?
[09:56] <asac> the wpa?
[09:56] <stgraber> wired -> wpa -> public
[09:57] <stgraber> I tried 4-5 times switching between wired and public without any problem, so previous problem might have been the "NM got stuck at stage 1" problem :)
[09:57] <stgraber> which seems to appear randomly
[09:57] <asac> stgraber: does it still appear at all?
[09:57] <asac> stgraber: i think yesterday it might have been due to the cruft patch we had
[09:58] <asac> stgraber: is all this with opennet.dev network-manager?
[09:58] <stgraber> no
[09:58] <stgraber> haven't built it yet
[09:58] <asac> stgraber: ok ... the log appears to be incomplete anyway
[09:59] <stgraber> I stopped the log when NM showed the connect to wired icon
[09:59] <asac> he?
[10:00] <asac> i mean i don't see that wpa succeeded
[10:00] <stgraber> strange
[10:00] <asac> i think its imcomplete ... because otherwise you would not have seen the wireless icon in nm-applet
[10:01] <asac> anyway ... try with new network-manager please
[10:01] <asac> the old one is just two aggressive
[10:01] <stgraber> asac: ~line 1437
[10:01] <asac> i only see 500 :)
[10:01] <stgraber> hmm
[10:02] <stgraber> pastebin limitation :)
[10:02] <asac> http://paste.stgraber.org/3316
[10:02] <asac> stgraber: try pastebin.mozilla.org
[10:02] <asac> or just upload :)
[10:03] <stgraber> same limitation, will upload
[10:03] <stgraber> http://www.stgraber.org/download/debug-nm
[10:08] <asac> stgraber: ok we are struck by wpasupplicant cleanup issues as it looks like
[10:08] <asac> stgraber: can you try with new nm ... and if we still get that let me know?
[10:09] <stgraber> ok, just tried new NM
[10:09] <stgraber> results aren't good
[10:09] <stgraber> same problem with switching from wpa to public
[10:09] <stgraber> + had a NM crash
[10:09] <stgraber> + failed to switch from public to wpa
[10:10] <stgraber> the crash happened when connecting to WPA network
[10:11] <asac> stgraber: please comment out the last patch in series (41p_set_enc_key_NULL_in_wireless_real_init.patch)
[10:11] <stgraber> k
[10:12] <asac> stgraber: can you still switch open->wired and back?
[10:13] <stgraber> asac: yes
[10:15] <Bsims_> I want to know what to file a bugreport against
[10:16] <alex-weej> asac: do you know much about rt2x00?
[10:16] <alex-weej> Bsims_: just file it against ubuntu if in doubt, someone will triage it
[10:17] <alex-weej> or "don't know"
[10:17] <asac> alex-weej: don't know the name at all :) ... whats that? realtek? ralink?
[10:17] <alex-weej> asac: yeah
[10:17] <asac> alex-weej: yeah doesn't answer my question :)
[10:18] <alex-weej> ralink
[10:18] <alex-weej> the project took the open source ralink drivers and improved them, then they started the "rt2x00" driver which was supposed to unify them all. but rt2x00 isn't finished, it's still beta, and it doesn't work.
[10:18] <asac> only thing i have heard of ralink is that the drivers are a mess :)
[10:18] <alex-weej> yet we're bundling it.
[10:18] <Bsims_> but that is not the case
[10:18] <alex-weej> the older drivers work better, but they're not distributed anymore :/
[10:19] <asac> alex-weej: i guess the older drivers have their own share of deficiencies as well :)
[10:19] <alex-weej> asac: at least they associate with WAPs
[10:19] <alex-weej> (and FWIW i've had no problems running rt73)
[10:20] <alex-weej> with my linksys usb dongle
[10:20] <Bsims_> Ah it is in the buglist https://bugs.launchpad.net/ubuntu/+source/dhcdbd/+bug/93360 but will someone at least set a importance level for it
[10:20] <ubotu> Launchpad bug 93360 in dhcdbd "Dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason" [Undecided,Confirmed] 
[10:22] <Bsims__> sorry it died again was anything addressed to me
[10:22] <alex-weej> no
[10:24] <stgraber> asac: it seems that the opennet NM also try to associate in background ...
[10:30] <asac> he?
[10:30] <asac> stgraber: it never was ment to fix anything in this regards
[10:31] <stgraber> no, but the driver change fixed that :)
[10:31] <asac> yes ... and now its back?
[10:31] <stgraber> yes
[10:31] <stgraber> doing : iwconfig eth1 essid off
[10:31] <stgraber> disconnect and connect 3s after ..
[10:32] <asac> well ... but with the current gutsy nm that doesn't happen?
[10:32] <stgraber> indeed, with current gutsy NM + patched driver that doesn't happen
[10:32] <asac> stgraber: could you at least connect to WPA now that you dropped the NULL wep key patch?
[10:33] <asac> stgraber: but this auto-associate doesn't affect the overall usability, right? e.g. open network connecting dstill works?
[10:34] <asac> stgraber: maybe its the *NEW* driver that makes this auto-association happen again?
[10:34] <asac> e.g the one from bzr?
[10:36] <stgraber> ok, I've reloaded everything and now auto-association doesn't happen anymore (maybe it was caused by the kill+reload I had to do a minute before), I can switch between WPA network correctly
[10:37] <asac> ok ... and then going back to open doesn't work?
[10:37] <stgraber> WPA -> open still fail
[10:38] <asac> ok ... thats what we need to figure out now ... does iwconfig still show the wpa key for your device?
[10:38] <stgraber> but I didn't have the supplicant error this time, so it might have been the random "got stuck at stage 1" thing
[10:38] <asac> hmm
[10:38] <stgraber> no it doesn't
[10:38] <stgraber> let me try again
[10:38] <asac> so its stuck?
[10:38] <asac> and you cannot switch to wired?
[10:38] <asac> siretart: where did you post your wpa 0.5.8 packages?
[10:39] <asac> siretart: maybe you can push them to a paa?
[10:39] <stgraber> second try, same result got stuck at stage 1
[10:40] <asac> stgraber: without the wpa supplicant "cannot connect" ?
[10:40] <asac> stgraber: is the process still alive? e.g. can you switch to wired now?
[10:40] <stgraber> and finally third try I have the supplicant error ...
[10:41] <asac> so which one is easier to reproduce for you now?
[10:41] <stgraber> no, when I got stuck at Stage 1 I can't select wired I have to kill NM
[10:41] <asac> so we can concentrate on that one for now :)
[10:41] <stgraber> the supplicant one was less random in the past
[10:42] <stgraber> good, I was able to reproduce the supplicant one
[10:43] <stgraber> Sep  2 22:42:27 laptop NetworkManager: <info>  Error opening supplicant global control interface.
[10:43] <stgraber> Sep  2 22:42:27 laptop NetworkManager: <WARN>  real_act_stage2_config(): Activation (eth1/wireless): couldn't connect to the supplicant.
[10:46] <asac> stgraber: yes .... thats really interesting
[10:55] <asac> stgraber: both issues could be related if the device worker is not running
[10:55] <siretart> asac: the 0.5.8 packages are still at http://siretart.tauware.de/upload-queue
[10:56] <siretart> asac: and for the ppa, you still haven't answered me to which ppa we should push it
[10:56] <asac> siretart: ah ... ok i can either upload to mine ... or to yours :)
[10:56] <asac> thanks for the info
[10:57] <asac> stgraber: can you try the wpasupplicant packages from http://siretart.tauware.de/upload-queue ?
[10:59] <stgraber> building
[10:59] <siretart> asac: feel free to upload to yours. beware that the version is currently lower than the package currently in gutsy
[11:00] <asac> siretart: yes thats ok i think
[11:08] <stgraber> asac: same problem with that wpasupplicant
[11:09] <zasf> !weekend
[11:09] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[11:09] <zasf> !weekdays
[11:09] <ubotu> Sorry, I don't know anything about weekdays - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[11:09] <zasf> !weekday
[11:09] <ubotu> Sorry, I don't know anything about weekday - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[11:11] <asac> siretart: do you know how the clean way to shutdown wpa supplicant is?
[11:11] <asac> siretart: e.g. not using kill
[11:12] <asac> e.g. something like EXIT when in wpa_cli
[11:12] <asac> but i didn't find anything
[11:13] <asac> siretart: another question is if we can stop wpasupplicant from doing anything by DISABLE_NETWORK 0 ... and then set AP_SCAN 0
[11:13] <asac> ?
[11:14] <asac> siretart: hmmm we use interface_add ... is there something like interface_RM ?
[11:16] <asac> siretart: ok found interface_remove ... it is
[11:27] <soren> asac: TERMINATE?
[11:29] <soren> asac: Or is that not what you're asking? :)
[11:29] <asac> soren: yes i found
[11:29] <asac> soren: thanks
[11:30] <asac> works great i guess :)
[11:30] <soren> \o/
[11:30] <soren> asac: np
[11:35] <asac> soren: you have ipw3945 as well?
[11:35] <soren> asac: Nope.
[11:36] <asac> good for you ... so you don't need to test for me ;)
[11:36] <asac> soren: does your nm work?
[11:36] <soren> asac: atheros (and access to and ipw2200) if you ever need them for testing.
[11:36] <soren> asac: Yeah, no problems here.
[11:37] <asac> i have an ipw2200 bug as well
[11:37] <asac> wait
[11:38] <asac> stgraber: i pushed a new patch that should shutdown wpa supplicant more gracefully
[11:38] <asac> to .opennet branch
[11:40] <stgraber> ok
[11:42] <asac> stgraber: i think you won't have to test ... i see the wpasupplicant error here as well
[11:42] <soren> asac: Well, "no problems" is not entirely true, actually, but it's not really nm's fault. I've come across a few AP's whose DHCP servers seem to not work with dhclient. I haven't gathered enough debugging info to file a bug yet, though.
[11:45] <asac> soren: when you are sure that its dhclient ... then i am out of that ;)
[11:49] <stgraber> asac: looks like "terminate" isn't the right command
[11:50] <asac> stgraber: yes it needs to be UPPER case
[11:50] <asac> anyway the problem does not really go away
[11:50] <asac> stgraber: but maybe try yourself (as you have 0.5.8 supplicant)
[11:51] <asac> my wpa supplicant often gives me busy results when adding the interface
[11:55] <asac> stgraber: i often get:
[11:55] <asac> asac@hector:~/ubuntu_nm/wpasupplicant.stable.debian$ sudo wpa_cli -g /var/run/wpa-global INTERFACE_ADD wlan0 "" "" /var/run/wpa-run
[11:55] <asac> 'INTERFACE_ADD wlan0                    /var/run/wpa-run                ' command timed out.
[11:55] <asac> on command line
[11:55] <asac> but i can afterwards just go ahead and use it as normal ... and wpa_supplicant actually starts scanning et al after that command
[11:59] <stgraber> asac: http://paste.stgraber.org/3319
[12:06] <stgraber> Have to wake up early, see you
[12:06] <asac> stgraber: ok night!