=== mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-kernel === ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-21.31 uploaded (Hello ipw3945) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/ === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === JaneW [n=JaneW@196.36.161.235] has joined #ubuntu-kernel === allee [n=ach@dialin-212-144-131-162.pools.arcor-ip.net] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === Keybuk [n=scott@syndicate.netsplit.com] has joined #ubuntu-kernel === doko [n=doko@dslb-088-073-092-155.pools.arcor-ip.net] has joined #ubuntu-kernel === johnm [n=johnm@gentoo/developer/johnm] has left #ubuntu-kernel [] === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === Keybuk [n=scott@syndicate.netsplit.com] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [02:49] heylo === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === johnm [n=johnm@gentoo/developer/johnm] has joined #ubuntu-kernel [03:40] Hi guys [03:40] BenC: do you publish your ubuntu git repo somewhere by chance? [03:41] http://kernel.org/git [03:42] johnm: only on kenrel.org [03:43] hi fabbione [03:43] hey zul [03:43] that'll work for me, thanks === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === mxpxpod [n=BryanFor@unaffiliated/mxpxpod] has joined #ubuntu-kernel [04:45] bah, stupid docbook failure caused i386 to fail to build === ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-21.32 uploaded (Hello ipw3945, Goodbye build failure) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/ === ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-21.32 uploaded (Hello ipw3945, Goodbye build failure) [05:05] BenC: Hah, I was *just* about to bug you about the build failure, too. === infinity waits for the sources to hit soyuz and build. [05:06] maybe I should be doing a full build on my i386 box to catch this sort of thing [05:06] first time it's happened though, so probably not worth the effort [05:06] Probably. :) [05:06] You know how much I love people using my buildds as testing infrastructure. :P [05:07] hehe [05:27] BenC: Do we know that putting shell expansion like $(uname -r) in modprobe.d files actually works? [05:27] BenC: Or is that completely untested? :) [05:27] No, I tested it [05:27] Spiffy. [05:27] Put "test install echo $(uname -r)" in a modprobe.d file [05:28] and do "sudo modprobe test" [05:28] it should echo it [05:28] Oh, and for the record, not sure what your comment was all about, but modprobe.d filenames don't have to relate to the module name in any way. [05:28] (Usually, they follow the package name, though in this case I agree that it makes sense to use the module name anyway) [05:29] yeah yeah [05:29] I meant to say that the module name in the file cannot be duplicated in other files without bad effects :) [05:29] Ahh, yeah, I ran into that. [05:30] I can't recall if it picks the last or the first, or does all of them or what, but I remember testing this when I used an 'install' hack for the nvidia kernel modules. [05:36] I tend to use package name, or blacklist-$class [05:36] infinity: first, iirc [05:37] Well, packagename is a bit awkward in this case, because it's lrm-common, which could grow more of these files. [05:37] And blacklist-foo is clearly wrong, since it's not a blacklist. :) [05:37] what's going in it? [05:37] install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; \ [05:37] /sbin/ipw3945d-$(uname -r) --quiet [05:37] remove ipw3945 /sbin/ipw3945d-$(uname -r) --kill ; \ [05:37] /sbin/modprobe -r --ignore-remove ipw3945 [05:37] uhhh [05:37] Was just going to name it "ipw3945", which seems sane. :) [05:37] why not do that as a udev rule instead/ [05:38] slightly more elegant [05:38] Does udev trigger on removal of the module? [05:38] yes [05:38] SUBSYSTEM=="module", ACTION=="remove" [05:38] Then give me the udev rules to replace the above, and I'll do that. [05:38] I don't much care, I (and apparently BenC also) just happen to know how to do it this way. [05:39] SUBSYSTEM=="module", NAME=="ipw3945", ACTION=="add", RUN+="sh -c '/sbin/ipw3945-$(uname -r) --quiet'" [05:39] SUBSYSTEM=="module", NAME=="ipw3945", ACTION=="remove", RUN+="sh -c '/sbin/ipw3945-$(uname -r) --kill'" [05:39] I fail to see how that's much more elegant than doing it from modprobe, mind you. [05:40] It also adds a hard dependency on udev, which isn't necessarily true otherwise. [05:40] I tend to cry at install/remove rules :) [05:40] udev rule is triggered by insmod/rmmod too [05:41] But requires udev. [05:41] yes, there is that [05:41] So, in one case, we have modprobe-specific, in the other case, udev-specific. [05:42] Note that the kernel image depends on modprobe, but doesn't depend on udev. === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel [05:42] we don't start any daemons from modprobe rules at the moment [05:42] No time like the present to start. :) [05:42] This is a somewhat special daemon. We don't start any other "module helpers" at all, from udev or modprobe. [05:42] Keybuk: does the udev rule trigger when someone does "modprobe -r ipw3945"? [05:43] because that's what we need [05:43] BenC: yes, it triggers because the kernel's module handler is sysfs-ified [05:43] so it will call the udev rule before it actuallt removes the module? [05:43] because the module cannot be removed until the daemon is killed [05:43] "while it's removing" is probably the best description [05:43] I don't know exactly where [05:44] then it wont work, because "while it is removing" can't happen with the ref-count > 0 [05:44] ok [05:44] then do it your way [05:44] it's not my way, it's the "Intel Way" :) [05:44] It's a stopgap anyway, until someone reverse engineers the daemon and shoves the code in the driver. :) === infinity coughs. [05:45] BenC: What are you doing this weekend? :) [05:45] why's it a userspace daemon and not a kernel thread, anyway? [05:45] Keybuk: because it is binary only [05:45] To avoid license issues. [05:45] regulatory restrictions [05:45] yeah, keeps the driver "free" [05:45] heh, someone can soon port that into the kernel [05:45] infinity: you'll have to do it; BenC's a USian [05:46] they probably will, but then Intel will still not be held liable :) [05:47] Yeah, Intel just wants to be able to waive liabilty. So they release the binary daemon, let some other hacker reverse engineer it, everyone wins. [05:47] and then we can control tx power, and other neat stuff on the chipset [05:47] A double-edged sword that one. === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel [05:48] Let the user control Tx power, and three days later, half of them complain that they blew up their transmitters. [05:48] I'd worry about tx power bumps, but where I live, I'm not likely to interfere with too many others [05:48] (You have no idea how many people I've seem blow up their wlan cards and APs with firmware hacks..) [05:48] doubtful the hillbillies have any serious 80211 networks around [05:48] If I bump the Tx on my AP, the thing starts overheating in a matter of minutes. [05:49] I have my linksys AP's bumped in power so I can reach the barn [05:50] I can't seem to much improve things in my house anyway. The place is a faraday cage. [05:50] Plaster on wire mesh in the walls, it looks like. Can't get reliable transmission between the living room and my bedroom with any two 802.11b/g devices I've tried. === infinity shrugs. [05:51] A repeater in the hallway would fix it, I guess, but it just doesn't seem worth the effort. [05:51] hehe [05:51] I had a repeater for awhile, in the well house, didn't really help much [05:51] your house was definitely not designed by a geek [05:52] Well, a repeater in the hall would allow me to bounce a line-of-sight triangle around the two offending walls between here and the bed. [05:53] But I think I'd rather just move to something that was built in the last century. (In the last decade would be smashing, too) === lamont [n=lamont@mib.fc.hp.com] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === JaneW [n=JaneW@dsl-165-202-111.telkomadsl.co.za] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-kernel === dilinger [n=dilinger@207.210.101.209] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === _human_blip_ [n=mike@220.157.65.181] has joined #ubuntu-kernel === pdr [n=pdr@pogo.pdr.me.uk] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.181] has joined #ubuntu-kernel === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.181] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.181] has joined #ubuntu-kernel [08:21] infinity: 21.32 built successfully [08:22] BenC: I've been watching. :) [08:22] LRM is on its way up already. [08:22] ok, I'll do linux-meta in a few hours [08:22] Well, the orig is on its way to chinstrap, the diff and dsc are getting some final love from me. [08:23] does lrm create any udeb's? [08:23] Yup. [08:23] anyway to get the ipw3945 daemon in the installer? [08:23] nic-restricted-modules and nic-restricted-firmware. [08:23] if so, I'll add it to the nic-udeb [08:23] And I already put the ipw3945d stuff in the nic-r-m udeb. [08:23] Way ahead of you. :) [08:23] sweet, I'll get the driver done too, thanks! [08:26] BenC: May as well pop out a 21.33 with that change ASAP, the buildds can take it. :) [08:26] And it'd be nice to see this in the next d-i build, so the next daily CDs are something we can point people at to test if it works. === infinity uploads LRM and heads off to bed... === JaneW [n=JaneW@dsl-146-167-245.telkomadsl.co.za] has joined #ubuntu-kernel === human_blip [n=mike@220.157.65.181] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has left #ubuntu-kernel [] === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel