=== mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #ubuntu-kernel [02:34] infinity: ping [02:40] pong [02:41] zul: ^^ [02:41] did the sl-modem driver get into lrm? [02:41] Not that I know of. [02:42] *sigh* ok.. [02:42] Does it build against our kernels okay? [02:42] I can certainly still lok at adding it. [02:42] i dont think so, there is a deb in universe that doesnt work right now [02:42] heh...i had a patch for it a long time ago that might have gotten lost or something [02:43] I vaguely recall a patch in bugzilla, but that was for 2.6.12, no? [02:43] correct [02:43] Also, with sl-modem-daemon in multiverse, we'd need that promoted to make the LRM driver any use anyway, I suspect. [02:43] So, that's committing to supporting code we previously weren't touching with a 20-foot pole. [02:44] i know...im doing some research about it and see if there is a 2.6.15 version [02:44] 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] yeah [02:45] we should remove it from universe me things [02:45] thinks even [02:45] dinner.. === JaneW [n=JaneW@dsl-146-141-13.telkomadsl.co.za] has joined #ubuntu-kernel === [g2] [n=g2@nslu2-linux/g2] has joined #ubuntu-kernel [05:30] <[g2] > Are there any other platforms than the Intel Mac mini using EFI as a BIOS ? [06:16] BenC: pong [06:51] [g2] : Yes, all ia64 machines. === Teo [n=teo@p54BC8566.dip0.t-ipconnect.de] has joined #ubuntu-kernel === Teo [n=teo@p54BC8566.dip0.t-ipconnect.de] has left #ubuntu-kernel [] === chmj [n=chmj@196.44.1.98] has joined #ubuntu-kernel === allee [n=ach@217.19.180.111] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === doko [n=doko@dslb-088-073-081-033.pools.arcor-ip.net] has joined #ubuntu-kernel === allee [n=ach@217.19.180.111] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [12:43] morning [01:49] Mithrandir: can you let me know when I can upload a new kernel? [01:49] BenC: will do. In a few hours, unless the world suddenly breaks. [01:49] I'll keep the duct tape handy just in case :) === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === mxpxpod [n=BryanFor@unaffiliated/mxpxpod] has joined #ubuntu-kernel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel [04:38] BenC: ping (hopeful) [04:39] Keybuk: pong [04:39] so, I have an interesting set of bugs here that Compact Flash card readers don't cause usb_storage to get loaded [04:39] and I found this in modules.alias: [04:39] alias usb:v07C4pA000d001[0-5] dc*dsc*dp*ic*isc*ip* usb_storage [04:39] ^^^^^ [04:40] :p [04:40] what exactly does that 0-5 match cause? [04:41] that's what I'm trying to find out, the modprobe documentation suggests that would only match the literal string "[0-5] " :) [04:41] though I thought it used fnmatch [04:42] (the other possibility right now is that udev escapes [ and ] to just _ :p) [04:42] actually, strike that udev bit [04:42] quest scott% modprobe -n -v --first-time usb:v07C4pA000d0012dcFFdsc00dp00ic05isc00ip00 [04:42] FATAL: Module usb:v07C4pA000d0012dcFFdsc00dp00ic05isc00ip00 not found. [04:46] HAHAHAHAHAHAHAHAHAHAHAHA [04:46] BWAHAHAHAHAHAHAHAH [04:46] Oh lordy [04:46] modprobe converts the "-" to "_" when "canonicalising" the alias as a module name [04:46] "shell-style wildcards" [04:46] ah, yeah, it does that for like usb-storage -> usb_storage [04:47] right [04:47] it also does it to the wildcard aliases :p [04:47] so that's actually seen as usb:v07C4pA000d001[0_5] dc*dsc*dp*ic*isc*ip* [04:47] So use {1..5} and you win? [04:48] probably [04:49] I'll just fix modprobe to not escape "-" if inside [ ... ] [04:49] [ and ] aren't legal in a module name anyway [04:50] quest obj% ./modprobe -n -v --first-time usb:v07C4pA000d0012dcFFdsc00dp00ic05isc00ip00 [04:50] insmod /lib/modules/2.6.15-21-amd64-k8/kernel/drivers/usb/storage/usb-storage.ko [04:50] better [04:50] sweet [04:52] any other occurences of [x-y] in there? [04:53] quite a few [04:54] all usb_storage and ibmcar [04:54] uh, ibmcam [04:58] infinity: btw, do you have a roomy for paris? [04:58] I need a smoker to bunk with [04:58] BenC: Not that I know of. Sign us up. [04:58] good deal [05:18] What's the l-r-m status? [05:21] oh, neat; that bug was already fixed in the newest upstream modprobe anyway === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-22.33 uploaded (Hello (working) ipw3945) | If you have ANYTHING you want in dapper kernel, message BenC here, or email me directly bcollins@ubuntu.com (malone is kind of noisy right now so I might miss things on there) === Topic (#ubuntu-kernel): set by BenC at Tue May 2 20:37:36 2006 [05:49] gnargh, this whole udev device enumeration thing is really annoying me now [05:52] should we sort the device list, or not? === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-22.33 uploaded (Hello (working) ipw3945) | If you have ANYTHING you want in dapper kernel, message BenC here, or email me directly bcollins@ubuntu.com (malone is kind of noisy right now so I might miss things on there) === Topic (#ubuntu-kernel): set by BenC at Tue May 2 20:37:36 2006 [05:54] oh, there's about a dozen different cases now [05:54] so currently we: [05:55] o recurse /sys/devices [05:55] o sort by canonical path [05:55] now, the "proper" way seems to be to just read each /sys/bus/*/devices directory instead [05:56] if we do that, we "lose" a bunch of intermediate nodes that represent things like "the PCI bus", "an IDE bus", etc. [05:56] 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] in fact, those are all those nodes where if you write to the uevent file, NOTHING HAPPENS [05:56] (remember those? :p) [05:56] so it doesn't matter if we ignore them [05:57] this inclines me to believe that we should instead iterate each /sys/bus/*/devices [05:57] but then we have a sorting issue [05:57] 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] 0000:00:1f.0 > 0000:00:09.0/0000:02:00.0, etc. [05:58] so I thought about instead just sorting by logical path [05:58] which amounts to basically sorting the directory before reading from it [05:59] but now there's a third way too [05:59] which is "don't sort at all" [05:59] and then you get the devices out of /sys in whatever order the kernel put them in there [05:59] the curious thing about that is that it appears to be basically backwards [06:00] on my AMD64 I see "PCI/Express devices, forwards"; "PCI devices, backwards"; "Internal PCI, backwards" [06:00] when if I sort logically, I get roughly the opposite order [06:02] *help* [06:02] :p [06:13] did you all die? :p === tuxmaniac [n=aanjhan@60.254.67.17] has joined #ubuntu-kernel [06:54] Keybuk: yes [06:54] damn [06:54] mdz: so, what do you think? [06:54] relying on the order the kernel put them there seems wrong [06:55] if sorting gives us something vaguely like bus order, that would be logical === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel [06:55] yeah, my inclination is that sorting by logical bus id is the right solution [07:12] I suspect the only answer we'll ever get from kernel or upstream is "don't rely on any kind of order" === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [08:02] BenC: ping? === mxpxpod [n=BryanFor@unaffiliated/mxpxpod] has joined #ubuntu-kernel [08:59] wohoo.. [10:05] fabbione: pong [10:06] 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] and i also get a gazzillions duplicate pkts when pinging an host [10:07] yeah, it's a known bug [10:07] fabbione: Yes, the driver is still mildly b0rked [10:07] That's why we default to 11M [10:07] both from/to [10:07] I've never been able to do more than 11 [10:07] i can associate at 36M max [10:07] and I also get the dup pings [10:07] ok [10:07] so it's all known stuff.. [10:07] perfect [10:07] I can get 24M decently, but I keep it at 11M [10:07] then i won't bother you anymore [10:07] :) [10:08] well performance are still 11Mb [10:08] no matter at what speed you associate [10:08] BenC: Any idea when we get new l-r-m? [10:08] thanks guys === fabbione heads offline === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel