[02:34] <zul> infinity: ping
[02:40] <infinity> pong
[02:41] <infinity> zul: ^^
[02:41] <zul> did the sl-modem driver get into lrm?
[02:41] <infinity> Not that I know of.
[02:42] <zul> *sigh* ok..
[02:42] <infinity> Does it build against our kernels okay?
[02:42] <infinity> I can certainly still lok at adding it.
[02:42] <zul> i dont think so, there is a deb in universe that doesnt work right now
[02:42] <zul> heh...i had a patch for it a long time ago that might have gotten lost or something
[02:43] <infinity> I vaguely recall a patch in bugzilla, but that was for 2.6.12, no?
[02:43] <zul> correct
[02:43] <infinity> Also, with sl-modem-daemon in multiverse, we'd need that promoted to make the LRM driver any use anyway, I suspect.
[02:43] <infinity> So, that's committing to supporting code we previously weren't touching with a 20-foot pole.
[02:44] <zul> i know...im doing some research about it and see if there is a 2.6.15 version
[02:44] <infinity> The description for sl-modem-daemon leads me to believe that the alsa intel8x0m module should be sufficient, and I don't need the sl-modem source...
[02:45] <zul> yeah
[02:45] <zul> we should remove it from universe me things
[02:45] <zul> thinks even
[02:45] <zul> dinner..
[05:30] <[g2] > Are there any other platforms than the Intel Mac mini using EFI as a BIOS ?
[06:16] <Mithrandir> BenC: pong
[06:51] <infinity> [g2] : Yes, all ia64 machines.
[12:43] <zul> morning
[01:49] <BenC> Mithrandir: can you let me know when I can upload a new kernel?
[01:49] <Mithrandir> BenC: will do.  In a few hours, unless the world suddenly breaks.
[01:49] <BenC> I'll keep the duct tape handy just in case :)
[04:38] <Keybuk> BenC: ping (hopeful)
[04:39] <BenC> Keybuk: pong
[04:39] <Keybuk> so, I have an interesting set of bugs here that Compact Flash card readers don't cause usb_storage to get loaded
[04:39] <Keybuk> and I found this in modules.alias:
[04:39] <Keybuk> alias usb:v07C4pA000d001[0-5] dc*dsc*dp*ic*isc*ip* usb_storage
[04:39] <Keybuk>                         ^^^^^
[04:40] <Keybuk> :p
[04:40] <BenC> what exactly does that 0-5 match cause?
[04:41] <Keybuk> that's what I'm trying to find out, the modprobe documentation suggests that would only match the literal string "[0-5] " :)
[04:41] <Keybuk> though I thought it used fnmatch
[04:42] <Keybuk> (the other possibility right now is that udev escapes [ and ]  to just _ :p)
[04:42] <Keybuk> actually, strike that udev bit
[04:42] <Keybuk> quest scott% modprobe -n -v --first-time usb:v07C4pA000d0012dcFFdsc00dp00ic05isc00ip00
[04:42] <Keybuk> FATAL: Module usb:v07C4pA000d0012dcFFdsc00dp00ic05isc00ip00 not found.
[04:46] <Keybuk> HAHAHAHAHAHAHAHAHAHAHAHA
[04:46] <Keybuk> BWAHAHAHAHAHAHAHAH
[04:46] <Keybuk> Oh lordy
[04:46] <Keybuk> modprobe converts the "-" to "_" when "canonicalising" the alias as a module name
[04:46] <BenC> "shell-style wildcards"
[04:46] <BenC> ah, yeah, it does that for like usb-storage -> usb_storage
[04:47] <Keybuk> right
[04:47] <Keybuk> it also does it to the wildcard aliases :p
[04:47] <Keybuk> so that's actually seen as usb:v07C4pA000d001[0_5] dc*dsc*dp*ic*isc*ip*
[04:47] <infinity> So use {1..5} and you win?
[04:48] <Keybuk> probably
[04:49] <Keybuk> I'll just fix modprobe to not escape "-" if inside [ ... ] 
[04:49] <Keybuk> [ and ]  aren't legal in a module name anyway
[04:50] <Keybuk> quest obj% ./modprobe -n -v --first-time usb:v07C4pA000d0012dcFFdsc00dp00ic05isc00ip00
[04:50] <Keybuk> insmod /lib/modules/2.6.15-21-amd64-k8/kernel/drivers/usb/storage/usb-storage.ko
[04:50] <Keybuk> better
[04:50] <BenC> sweet
[04:52] <BenC> any other occurences of [x-y]  in there?
[04:53] <Keybuk> quite a few
[04:54] <Keybuk> all usb_storage and ibmcar
[04:54] <Keybuk> uh, ibmcam
[04:58] <BenC> infinity: btw, do you have a roomy for paris?
[04:58] <BenC> I need a smoker to bunk with
[04:58] <infinity> BenC: Not that I know of.  Sign us up.
[04:58] <BenC> good deal
[05:18] <mjg59> What's the l-r-m status?
[05:21] <Keybuk> oh, neat; that bug was already fixed in the newest upstream modprobe anyway
[05:49] <Keybuk> gnargh, this whole udev device enumeration thing is really annoying me now
[05:52] <Keybuk> should we sort the device list, or not?
[05:54] <Keybuk> oh, there's about a dozen different cases now <g>
[05:54] <Keybuk> so currently we:
[05:55] <Keybuk>  o recurse /sys/devices
[05:55] <Keybuk>  o sort by canonical path
[05:55] <Keybuk> now, the "proper" way seems to be to just read each /sys/bus/*/devices directory instead
[05:56] <Keybuk> if we do that, we "lose" a bunch of intermediate nodes that represent things like "the PCI bus", "an IDE bus", etc.
[05:56] <Keybuk> but those seem to be just there for the kernel's own nafarious purposes anyway, and don't actually represent any useful hardware
[05:56] <Keybuk> in fact, those are all those nodes where if you write to the uevent file, NOTHING HAPPENS
[05:56] <Keybuk> (remember those? :p)
[05:56] <Keybuk> so it doesn't matter if we ignore them
[05:57] <Keybuk> this inclines me to believe that we should instead iterate each /sys/bus/*/devices
[05:57] <Keybuk> but then we have a sorting issue
[05:57] <Keybuk> if we sort by canonical path, we'll still think an IDE controller on a PCI bridge comes before the internal IDE controller, beacuse we'll be sorting by it's physical path
[05:58] <Keybuk> 0000:00:1f.0 > 0000:00:09.0/0000:02:00.0, etc.
[05:58] <Keybuk> so I thought about instead just sorting by logical path
[05:58] <Keybuk> which amounts to basically sorting the directory before reading from it
[05:59] <Keybuk> but now there's a third way too
[05:59] <Keybuk> which is "don't sort at all"
[05:59] <Keybuk> and then you get the devices out of /sys in whatever order the kernel put them in there
[05:59] <Keybuk> the curious thing about that is that it appears to be basically backwards
[06:00] <Keybuk> on my AMD64 I see "PCI/Express devices, forwards"; "PCI devices, backwards"; "Internal PCI, backwards"
[06:00] <Keybuk> when if I sort logically, I get roughly the opposite order
[06:02] <Keybuk> *help*
[06:02] <Keybuk> :p
[06:13] <Keybuk> did you all die? :p
[06:54] <mdz> Keybuk: yes
[06:54] <Keybuk> damn
[06:54] <Keybuk> mdz: so, what do you think?
[06:54] <mdz> relying on the order the kernel put them there seems wrong
[06:55] <mdz> if sorting gives us something vaguely like bus order, that would be logical
[06:55] <Keybuk> yeah, my inclination is that sorting by logical bus id is the right solution
[07:12] <Keybuk> I suspect the only answer we'll ever get from kernel or upstream is "don't rely on any kind of order"
[08:02] <fabbione> BenC: ping?
[08:59] <zul> wohoo..
[10:05] <BenC> fabbione: pong
[10:06] <fabbione> BenC: yo.. did you notice that the airport extreme in the PB can't do more than 11Mb in performance even if associated at 36M?
[10:07] <fabbione> and i also get a gazzillions duplicate pkts when pinging an host
[10:07] <BenC> yeah, it's a known bug
[10:07] <mjg59> fabbione: Yes, the driver is still mildly b0rked
[10:07] <mjg59> That's why we default to 11M
[10:07] <fabbione> both from/to
[10:07] <BenC> I've never been able to do more than 11
[10:07] <fabbione> i can associate at 36M max
[10:07] <BenC> and I also get the dup pings
[10:07] <fabbione> ok
[10:07] <fabbione> so it's all known stuff..
[10:07] <fabbione> perfect
[10:07] <BenC> I can get 24M decently, but I keep it at 11M
[10:07] <fabbione> then i won't bother you anymore
[10:07] <BenC> :)
[10:08] <fabbione> well performance are still 11Mb
[10:08] <fabbione> no matter at what speed you associate
[10:08] <mjg59> BenC: Any idea when we get new l-r-m?
[10:08] <fabbione> thanks guys