[12:06] <zul> heylo
[12:09] <zul> brb
[12:42] <ds> is there a simple way to build only a subset of packages from linux-source?
[04:12] <lamont> with an amd64 kernel, and i386 user space, xsane fails to find the scanner - "device busy"
[04:12] <mjg59> Yay 32-bit ioctl emulation
[04:13] <mjg59> That stuff's always broken
[04:13] <lamont> sigh.  any trivial way to find _which_ ioctl is b0rked?
[04:14] <BenC> which is why I am hesitant to provide an amd64 kernel for i386
[04:14] <BenC> lamont: check dmesg
[04:14] <lamont> I suppose I could always use 2.6.15, eh?
[04:14] <BenC> why not just use i386 kernel?
[04:14] <BenC> or 64-bit userspace :)
[04:14] <lamont> oh, yeah. plenty of them.
[04:14] <lamont> i386 kernel --> double time rate
[04:15] <lamont> iz mother board issue that's "fixed" in amd64 kernel, but not in i386
[04:15] <BenC> use noapictimer
[04:15] <lamont> that's only implemented in x86_64
[04:15] <BenC> nah, it worked for my sempron notebook (32-bit k8) with -k7 kernel
[04:15] <lamont> didn't work for  me.
[04:15] <lamont> [  225.362891]  ioctl32(xsane:10063): Unknown cmd fd(8) cmd(c00c5512){00} arg(ffff88c0) on /proc/bus/usb/003/001
[04:15] <BenC> weird, did for me
[04:16] <BenC> well, you know it's a USB ioctl, just parse cmd to find which one (referencing usb ioctl headers)
[04:16] <BenC> gotta run
[04:16] <lamont> kernel          /boot/vmlinuz-2.6.12-9-386 root=/dev/sda1 ro quiet splash noapictimer
[04:16] <lamont> like that, I wonder?
[04:17] <lamont> brb
[04:17] <mjg59> noapic nolapic also ought to work
[04:17] <lamont> mjg59: which should I use?
[04:17] <mjg59> If noapictimer doesn't work, try noapic nolapic
[04:17] <lamont> "noapic nolapic" or each one separately in turn?
[04:18] <mjg59> Both parameters at once
[04:45] <lamont> mjg59: noacpitimer caused the machine to not boot.
[04:45] <lamont> noacpi nolacpi gave me doubletime
[04:46] <lamont> which gets me back to fixing ioctl's in amd64
[04:59] <lamont> interesting... chrooting into an amd64 chroot doesn't fix it either...
[05:38] <infinity> Meh.
[05:39] <cjb> lamont: Wait, you're seeing double-time?  Have you tried acpi_disable_pin_1, or whatever it's called?
[05:40] <cjb> Oh, I see, you're seeing doubletime with noacpi.  I'm not helping, then.
[05:40] <infinity> mjg59: Feel like thinking more about my scaling problem?
[05:42] <infinity> for i in *freq; do echo -n "$i: "; sudo cat $i; done
[05:42] <infinity> cpuinfo_cur_freq: 800000
[05:42] <infinity> cpuinfo_max_freq: 2000000
[05:42] <infinity> cpuinfo_min_freq: 800000
[05:42] <infinity> scaling_cur_freq: 800000
[05:42] <infinity> scaling_max_freq: 800000
[05:42] <infinity> scaling_min_freq: 800000
[05:42] <infinity> That would appear to be problematic...
[05:46] <mjg59> Hm.
[05:46] <mjg59> Wonder what scaling_max_freq means
[05:46] <infinity> And for reference:
[05:46] <infinity> scaling_available_frequencies: 2000000 1600000 1333000 1066000 800000
[05:47] <infinity> So, it sees all the available frequencies, then sets the max to 800000
[05:47] <infinity> AFAICT.
[05:47] <infinity> Benchmarks seem to bear this theory out (it's slow as hell right now)
[05:48] <mjg59> On 2.6.5-11, I've got scaling_max_freq: 1200000
[05:48] <mjg59> Can you echo 2000000 to scaling_max_freq?
[05:49] <infinity> That's on a 1.2GHz X40 though, right?
[05:49] <mjg59> Yeah
[05:49] <infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # echo 2000000 > scaling_max_freq
[05:49] <infinity> (base)root@cthulhu:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_max_freq
[05:49] <infinity> 800000
[05:50] <mjg59> Right
[05:50] <mjg59> Sounds Dothan specific, then
[05:50] <mjg59> What cpufreq module do you have loaded?
[05:50] <infinity> centrino.
[05:50] <infinity> Same as always, afaik.
[05:51] <mjg59> Can you stop powernowd, unload that and load acpi-cupfreq?
[05:52] <infinity> Hrm.  How can I see what processes are using a module?
[05:53] <infinity> (Can't unload speedstep_centrino, in use)
[05:54] <mjg59> Are you still in /sys/devices/system/cpu/cpu0/cpufreq ?
[05:54] <infinity> Oh, I could be that retarded...
[05:55] <mjg59> Yay kernel refcounting
[05:55] <infinity> Err, no.  Leaving did no good.  Still a refcount of 1.
[05:57] <mjg59> You didn't cd there, su and then cd out, did you?
[05:58] <infinity> No, lsof confirms I'm not that dumb.
[05:58] <mjg59> Ok
[05:59] <infinity> (base)root@cthulhu:~ # lsof | grep cpu
[05:59] <infinity> nautilus   5407   adconrad   25r      REG        0,3        0 4026531851 /proc/cpuinfo
[05:59] <mjg59> Hm. No, it seems I can't unload mine either
[05:59] <mjg59> Bloody thing
[05:59] <infinity> Not sure why anything would hold a handle open on /proc/cpuinfo, but that shouldn't matter, I hope.
[06:00] <infinity> Go, git, go.
[06:01] <infinity> (base)adconrad@cthulhu:~/kernel/ubuntu-2.6$ git pull
[06:01] <infinity> [...] 
[06:01] <infinity> rsync: link_stat "/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/refs/heads/for-jgarzik" (in pub) failed: No such file or directory (2)
[06:01] <infinity> rsync error: some files could not be transferred (code 23) at main.c(1173)
[06:02] <infinity> Maybe I should just go back to bed.
[06:23] <fabbione> infinity: no, you need to purge the tree and clone it again
[06:24] <infinity> Yeah, I'm doing that.
[06:24] <infinity> Which is pretty icky, given how much data that is.
[02:51] <zul> heylo
[02:57] <BenC> yo chuck
[03:00] <zul> yo ben
[06:28] <fabbione> BenC: ping?
[06:35] <BenC> fabbione: pong
[06:38] <fabbione> BenC: hey
[06:38] <fabbione> BenC: did you ever try to boot one of the -server kernels on i386?
[06:38] <fabbione> -11- goes foobar on me really badly
[06:38] <BenC> yeah, I have a bug report about that
[06:38] <fabbione> and i need it for the cluster modules
[06:38] <fabbione> ok
[06:38] <BenC> going to test -12 on my i386
[06:39] <fabbione> ok thanks
[06:39] <fabbione> BenC: we might also need to kill cmirror from our kernel tree
[06:39] <fabbione> it's part of redhat-cluster-suite
[06:40] <fabbione> i am talking right now with upstream...
[06:40] <BenC> feel free, you know all the cluster stuff :)
[06:41] <fabbione> yeah sure
[06:43] <fabbione> it would also be nice to get ipv6 working on hppa
[06:43] <BenC> it's not?
[06:43] <BenC> is that a 32-bit userspace, 64-bit kernel issue?
[06:43] <fabbione> module ipv6 relocation of symbol in6_dev_finish_destroy is out of range (0x3ffeff7c in 17 bits)
[06:43] <fabbione> tons of this
[06:43] <fabbione> 32bit kernel
[06:43] <BenC> ah
[06:43] <fabbione> i still need to try to boot a 64bit kernel on that machine
[07:11] <fabbione> BenC: did zachery died again?
[07:12] <fabbione> oh christ
[07:12] <mjg59> "First Mac with Intel processor today."
[07:16] <trappist> fellas I sent an email to the kernel-team list per fabbione's suggestion about building iptables against the source of the running kernel and haven't heard a peep out of the list since then.  is my subscription busted or does that list really not see that much traffic?
[07:20] <cjb`> But it's an iMac.  :(
[07:21] <cjb> I think they might throw in an Intel laptop as the "One more thing.."
[07:56] <fabbione> trappist: the mail is there, do you want to give people sometime to read and think about it?
[07:56] <fabbione> pushing won't help
[08:00] <trappist> fabbione: not trying to push.  I just haven't seen *any* traffic on the list and was beginning to wonder if my subscription had gotten lost.
[08:09] <zul> trappist: its a very very low volume list
[08:11] <trappist> zul: that answers my question, thanks
[08:27] <zul> there is also something about in ubuntu-devel mailing list..
[08:45] <BenC> trapist: I saw it, but I'm no iptables expert
[08:48] <Mithrandir> BenC: did you have a chance to track down any of the unionfs bugs?
[08:48] <Mithrandir> on ppc
[08:53] <BenC> Mith: I was hoping the new unionfs woudl fix it
[08:54] <Mithrandir> BenC: I can enable unionfs for ppc again and we can see
[08:54] <BenC> Mithrandir: is it still broken with latest daily builds?
[08:54] <BenC> I'm willing to test it
[08:54] <Mithrandir> I don't have a working PPC, so it's a bit hard for me to test it. :-)
[08:55] <BenC> I have G4/G5 so I can test if it's enabled
[08:55] <BenC> been meaning to test the new yaboot anyway
[08:56] <Mithrandir> ok, assuming the next live fs build works ok, please grab tomorrow's live image and test it.
[08:58] <BenC> sure thing
[09:03] <cjb> BenC: So, replacing your obsolete PB with a MacBook anytime soon?  :)
[09:18] <zul> BenC: did you have a chance to do a pull yet?
[09:31] <BenC> zul: I tried a pull, but it didn't work
[09:37] <zul> blah...ill look at it
[09:38] <zul> when?
[09:55] <zul> BenC: fixed i just did a pull from my tree..
[09:55] <zul>  http://zulinux.homelinux.net/git/ubuntu-2.6.git
[10:02] <BenC> ok
[10:03] <zul> i dont know what happened apache must have gotten screwed up or something
[10:11] <ds> mdz: there's a new release of swfdec out