[12:34] <TheMuso> c
[11:22] <IceTox> brb.. reboot of network...
[03:02] <zul> heylo
[05:14] <zul> BenC: i remember seeing a patch on lkml which tells users what to do if they get an oops or something maybe we should grab it or something
[05:15] <zul> for example if there is an oops we can tell them to submit a bug report and go to the wiki for hardware debug..
[05:17] <cjb> How many lines of the tty do the instructions take up?  :)
[05:17] <BenC> Good idea...if it's not invasive, we can include it
[05:18] <zul> i just hvae to find it again
[05:21] <zul> http://marc.theaimsgroup.com/?l=linux-kernel&m=113890842725548&w=2 is an example
[05:46] <infinity> BenC: So, are we trying for ipw3945 in this next kernel/lrm batch, or will that be the one after?
[05:47] <mjg59> It's in git now
[05:55] <BenC> yeah, the kernel is ready
[05:58] <zul> BenC: was it a bitch?
[05:59] <BenC> nah, it was easy once I munged ieee80211
[05:59] <BenC> hmm...this would be a lot easier if we could get some modprobe.conf entries
[05:59] <BenC> that would start the ipw3945d process automatically when ipw3945 is loaded
[06:00] <BenC> ah, easy enough, we just add a /etc/modprobe.d/ipw3945 file in lrm
[06:00] <BenC> sweet, this will be cake
[06:06] <infinity> Yeah, "install" entries in modprobe.d are very flexible that way.
[06:06] <infinity> The killer is that we also need to drop the daemon when the module is unloaded.
[06:06] <infinity> (And it needs to be unloaded on sleep, according to anecdotal evidence)
[06:07] <BenC> supposedly the modprobe rules will do that
[06:07] <BenC> atleast according to their INSTALL
[06:07] <BenC> oh, you mean like hibernate/sleep it needs to unload
[06:07] <infinity> Yeah.
[06:08] <BenC> hmm, is there a .d file we can for that?
[06:08] <infinity> No, but that's easy to add to the list of stuff that needs to unload.
[06:08] <infinity> I didn't realise a modprobe rule could operate on remove as well.
[06:08] <infinity> If so, this is cake.
[06:08] <mjg59> infinity: There's a remove option for modprobe
[06:08] <infinity> mjg59: Sweet.
[06:08] <infinity> It's all lovely and simple then.
[06:08] <mjg59> I had a bug that acpi-support was using rmmod rather than modprobe -r
[06:09] <infinity> You've fixed it, I hope?
[06:09] <mjg59> Yeah
[06:09] <BenC> yeah, the modprobe will handle it, just that we need to tell the acpi scripts to remove it un sleep
[06:09] <infinity> And you'll add ipw3945 to the list of stuff to remove on sleep? :)
[06:10] <infinity> BenC: Well, since this mangling required another orig.tar.gz bump, and so does the new fglrx I want to get in, do you want to do your mangling, then hand it off to me for further breakage?
[06:10] <infinity> BenC: Or you could just leave the whole mess to me tomorrow.  I'm not picky.
[06:10] <BenC> I can just send you the tarball and the modprobe.d file
[06:11] <BenC> it's fairly simple, just copy x86/ipw3945d or x86_64/ipw3945d to /sbin, and place the modprobe.d file
[06:11] <infinity> Right, that's more or less what I was going to do, but with a twist.
[06:12] <infinity> (I need to make the daemon versioned, to allow different versions of the daemon to be installed with different kernels, since there's evidence that the daemon is tightly tied to the kernel driver version)
[06:12] <infinity> But that's simple enough, since lrm/debian/* is teeming with substvars for that sort of thing already.
[06:12] <BenC> nice
[06:12] <infinity> So, yeah, just leave it to me and I'll make it happen.
[06:13] <BenC> ok, I'll get that email out in about 10 minutes
[06:13] <infinity> I assume the driver doesn't actually care what the process name is?  It's just looking for a socket to talk to or something?>
[06:14] <infinity> Oh well.
[06:14] <infinity> Doing drivers blind is FUN.
[06:22] <infinity> Anyhow, I'm off to the sweet caress of my pillow.  New LRM tomorrow.  Yay.
[09:35] <kimo> Hi, I noticed a bug 'kernel does NOT poweroff my laptop' and I reported it. Unfortunately dapper beta is out & it's not yet fixed! Suse10 powers off correctly ... Any help?
[09:38] <zul> kimo: open a bug and attach output of dmidecode, dmesg, and lspci
[09:39] <zul> and try adding reboot=h to your boot parameters
[09:40] <kimo> zul: thnx for that ..
[09:40] <kimo> is there any command I do do to force a 'poweroff' (to at least see error message ?)
[09:43] <zul> try reboot=h on the grub boot parameters
[09:45] <mjg59> kimo: What hardware?
[09:45] <kimo> ok
[09:49] <kimo> mjg59: Toshiba A105 Satellite laptop
[09:55] <mjg59> kimo: Yeah, it's Toshiba specific. I'm looking into it.
[09:56] <kimo> mjg59: do u mean u re looking into it right now ? (sorry not native)
[09:57] <mjg59> Not this very second, but probably this week
[09:57] <kimo> please let me know if I can help in anyway.....
[09:57] <kimo> I can test patches & such
[09:57] <kimo> or if u update dapper pkgs, I usually dist-upgrade daily
[10:00] <kimo> thnx a lot ... for all the effort ... ciao :)
[11:38] <jkakar> Hello
[11:38] <jkakar> Is BSD process accounting turned on by default in dapper kernels?
[11:39] <jkakar> I'm interested in capture information abuot process creation and termination... my search has so far ended at BSD process accounting being the simplest (and least invasive) way of accomplish this goal.
[11:57] <crimsun> /boot/config-2.6.15-20-686:33:CONFIG_BSD_PROCESS_ACCT=y
[11:57] <crimsun> /boot/config-2.6.15-20-686:34:CONFIG_BSD_PROCESS_ACCT_V3=y
[11:58] <jkakar> crimsun: Thanks!  I didn't know the config-* files were there. :)