[11:57] <kraut> moin
[02:00] <ogra> BenC, hey, could it be that linuc-ubuntu-modules is a bit out of sync ? seems people using ltsp with unionfs/squashfs/nbd setup are seeing a lot of unionfs noise in the dmesg outputs since the swithc from 2.6.22-10 to -11
[02:05] <mjg59> ogra: unionfs is currently broken
[02:05] <ogra> yeah, ltsp users are moaning :)
[02:05] <ogra> mjg59, thanks for the info 
[02:20] <soren> AFAIUI the netconsole stuff in the kernel is only one-way. It's only good for spewing kernel output and such to a remote host.. Is there a more full featured mechanism for setting up a "real" networked console (if the hardware doesn't have it built in, obviously)?
[02:24] <BenC> ogra: everyone is moaning :)
[02:26] <ogra> heh
[02:26] <ogra> well, it seems to do any harm on thin clients at least apart from filling the logs with oopses :)
[02:26] <ogra> s/seems/seems not/
[02:27] <ogra> but then a thin client doesnt do any more with it but booting :)
[02:40] <\sh> BenC, btw...are you enabled hugetbl fs by default as module in the next kernel release?
[02:40] <\sh> s/enabled/enabling/
[02:41] <BenC> \sh: it's not modular
[02:43] <\sh> BenC, right ;) so it's enabled by default?
[02:44] <BenC> no, not on i386
[02:44] <\sh> BenC, but on amd64...that's whats more important ;)
[02:44] <BenC> only on sparc and powerpc
[02:45] <\sh> BenC, I filed a but about it on amd64...this is important for java devs on x86_64 ...
[02:45] <\sh> BenC, it enabled ibm java etc. to use largepages support
[02:45] <\sh> s/enabled/enables/
[02:46] <\sh> BenC, bug 122800 :)
[02:46] <ubotu> Launchpad bug 122800 in linux-source-2.6.22 "Please consider enabling HugeTBLFS for Gutsy " [Wishlist,Triaged]  https://launchpad.net/bugs/122800
[02:47] <BenC> \sh: we'll do our best
[02:47] <\sh> BenC, it was reported 2007-06-28 :)
[02:48] <\sh> when I tested feisty with our java backend on amd64
[02:48] <BenC> \sh: point taken, but it's still 3 days till beta :)
[02:48] <BenC> beta freeze I mean
[02:50] <\sh> BenC, using my self made 2.6.22.2 it's working perfectly...and when it's enabled via kernel paramenters (sysctl.conf) it works more perfectly..but it's not needed by default, only when you use this feature
[03:20] <BenC> rtg: rebooting in a sec to test the new iwlwifi
[03:21] <rtg> Big fire yesterday afternoon, my mirror isn't up to date. No power until this morning.
[03:21] <BenC> rtg: fire at your place?
[03:22] <rtg> No, downwind a few hundred yards.
[03:22] <rtg> Burnt up some power lines.
[03:22] <rtg> (and a bunch of houses)
[03:22] <BenC> rtg: nasty
[03:23] <ogra> rtg, hey, mn works fine with WEP and the rt73 driver in gutsy (have no WPA networks here so i only can test WEP and unencrypted)
[03:23] <ogra> s/mn/nm/
[03:23] <rtg> So, lum and kernel et al are in the archive?
[03:23] <BenC> rtg: kernel is, I'm giving pkl some time to fix unionfs before we do lum
[03:24] <rtg> ogra: rt73 works? I'm amazed.
[03:24] <BenC> so am I
[03:24] <BenC> ogra: works with n-m too?
[03:24] <ogra> yep
[03:25] <mjg59> acx100 seems to have broken again for some reason
[03:25] <mjg59> I managed to lose my hardware for that, which is a pain
[03:25] <ogra> on a minimally local install on the classmate ... tested on the weekend 
[03:26] <rtg> ogra: I have a CMPC. Do you have directions and/or an image somewhere? I can test WPA.
[03:26] <JanC> aren't all those rt* bugs concurrency issues, so not always reproducable ?   ;)
[03:27] <ogra> rtg, i dont have any gutsy image yet ... mdz moaned about my decision to take a squashfs image for that thing, i'm waiting on a meeting for a proper decision
[03:28] <rtg> ogra: np. 
[03:31] <BenC> rtg: iwlwifi seems to be working ok for me
[03:32] <BenC> $ lsmod | grep mac
[03:32] <BenC> iwlwifi_mac80211      174856  1 iwl4965
[03:32] <BenC> cfg80211                7304  1 iwlwifi_mac80211
[03:32] <rtg> BenC: have you tried WPA, suspend/resime hibernate, etc.
[03:32] <BenC> only thing I've done is connect via WEP
[03:32] <rtg> If it compiles, ship it :)
[03:36] <rtg> BenC: you won't forget debian/control-scripts/* will you?
[03:37] <rtg> Seeing activity on the DKMS bug reminded me.
[03:37] <BenC> rtg: err, I did forget
[03:37] <BenC> I'll work on that today and get an upload out tomorrow for it
[03:37] <rtg> Its important.
[03:37] <BenC> yeah, critical in fact
[03:38] <zul> how is the dkms revu coming in universe coming?
[03:38] <rtg> zul: https://bugs.edge.launchpad.net/ubuntu/+bug/121676. He is banging away at it.
[03:38] <ubotu> Launchpad bug 121676 in ubuntu "add DKMS to Ubuntu" [Wishlist,Incomplete]  
[03:39] <zul> well if it needs a uvf for universe let me know since im on the uvf team i can get it rammed through
[03:40] <BenC> rtg: interestingly enough, I seem to be getting 85% signal now instead of ~75% like I was before
[03:41] <rtg> BenC: The real indicator is 'at what bit rate does it run?' and  'with how many retries?'. Ultimately throughput is the goal. Signal level can be quite misleading.
[03:42] <BenC> rtg: 2.2M/sec transfer over scp
[03:42] <rtg> Mbit/sec?
[03:43] <BenC> Megabytes
[03:43] <BenC> scp doesn't report mbits :)
[03:44] <rtg> BenC: Thats not too bad. Is it better then before?
[03:44] <BenC> connected at 54g
[03:44] <BenC> rtg: before was about 1.8M/sec
[03:45] <BenC> rtg: so far, no invalid packets reported in iwconfig
[03:45] <rtg> BenC: You should set up a loop and run some sustained bulk transfers. Maybe we can close the hiccup bug.
[03:45] <rtg> BenC: I'll do the same.
[03:45] <BenC> rtg: and more importantly, my dmesg isn't being flooded with operational messages :)
[03:46] <rtg> BenC: sounds like 2 steps forward. 
[03:47] <BenC> rtg: only problem so far is the lack of wifi led
[03:47] <BenC> I need to see what I can do to make ieee80211_led.c compile in this new mac80211
[03:48] <BenC> it was expecting some new led interfaces in the kernel I think
[03:48] <rtg> I think it was a config option. I might not have turned it on.
[03:48] <BenC> I tried enabling it, but the compile failed
[03:49] <rtg> BenC: The iwlwifi pile is  backport from 2.6.23-rc*, so it might not compile.
[04:33] <zul> anyone got an opinon on bug 139881
[04:33] <ubotu> Launchpad bug 139881 in linux-source-2.6.22 "hdaps_protect patch to enable disk head parking on thinkpads" [Undecided,New]  https://launchpad.net/bugs/139881
[04:34] <mjg59> It would be nice if someone would actually get it into a state where it'll be accepted upstream
[04:35] <BenC> zul: Yeah, the patch is useless without userspace to support it
[04:36] <mjg59> BenC: There's userspace in the archive
[04:36] <BenC> mjg59: ah, last I heard it wasn't there
[04:36] <BenC> mjg59: but I also remember that the patch is pretty intrusive
[04:37] <mjg59> Yes, it's pretty nasty looking
[05:18] <zul> Ill just leave it then
[05:19] <afs> hi! I'm trying to compile qemu but it can't find /usr/include/linux/compiler.h. This include file belongs to package linux-headers-2.6.20-16-generic, but ends up in /usr/src/linux-headers-2.6.20-16-generic/include/linux/compiler.h. Is this normal behaviour?
[05:21] <soren> afs: It's an empty file, IIRC? Could you check that?
[05:22] <BenC> afs: add -I/usr/src/linux-headers-`uname -r` to your CFLAGS in qemu
[05:22] <afs> tried that, didn't work (suspect that's a qemu bug)
[05:24] <afs> /usr/include/linuxcompiler.h is not an empty file on debian
[05:28] <rtg> BenC: have a look at the changelog for iwlwifi 0.1.16. I'm testing his updates. It might fix an iwl3945 RF kill issue.
[05:33] <soren> do any of our kernel flavours have HZ=1000? 
[05:35] <abogani> soren: Rt kernel have it
[05:35] <soren> abogani: Sure? It's not at 250?
[05:36] <abogani> soren: yes i'm sure.
[05:40] <soren> abogani: Ok. Thanks.
[05:40] <abogani> soren: :-)
[06:07] <BenC> soren: HZ= doesn't make sens with our stock kernel, because it has dynticks
[06:08] <JanC> hm, on all architectures?
[06:08] <mjg59> BenC: My understanding is that it still affects the base timer granularity
[06:09] <mjg59> HZ=1000 on i386 would make sense
[06:09] <BenC> we got too many complaints about battery usage when we did that
[06:09] <BenC> and we have quite a few laptop models that fall into the AMD broken ioapic timer category
[06:09] <mjg59> Yes, but dynticks avoids that being an issue
[06:10] <mjg59> When the system is idle, you still get the power savings
[06:10] <Nafallo> mjg59: my acer died ;-)
[06:10] <mjg59> And when it's active, it's no worse
[06:10] <Nafallo> mjg59: just thought you might want to know ;-)
[06:10] <mjg59> Nafallo: I'm shocked
[06:10] <Nafallo> hehe
[06:11] <BenC> mjg59: but the broken ioapic timer's don't get nohz, so they'll suffer
[06:11] <Nafallo> I've ordered a Dell D630 again :-P
[06:11] <mjg59> BenC: Uh. That shouldn't be the case.
[06:11] <mjg59> BenC: Lacking the apic timer isn't a blocker to nohz
[06:12] <BenC> mjg59: on the amd laptop I have, I had to add nolapic_timer nohz=on to get it to boot
[06:12] <BenC> I meant lapic timer
[06:12] <mjg59> Then there's a bug somewhere
[06:12] <BenC> nohz doesn't like not having lapic timer
[06:14] <mjg59> BenC: I think limiting functionality in the name of providing a small increase in battery life on broken hardware is less than ideal
[06:15] <mjg59> But I was also under the impression that the turion issue had been fixed without the need to disable the lapic timer (the issue was that the code was incorrectly thinking that the timer continued in C2, which it didn't)
[06:16] <BenC> maybe I misunderstood the patch then
[06:16] <BenC> I can't tell if dynticks is enabled or not...is there a file in sysfs that will show that?
[06:17] <mjg59> Not sure
[06:17] <mjg59> You can work it out from /proc/timer_list, I think
[06:18] <BenC> there's a nohz_mode...guess I can check the expected values for that
[06:19] <BenC> running on intel now
[07:04] <verwilst> hi!
[07:08] <verwilst> oh, they're in universe!
[07:08] <verwilst> carry on people ;)
[09:48] <rtg> mjg59: Do you only need the first 2 bytes of a hotkey to map it? For example, the windows media key on an XPS M1330 emits e0 5b e0 db.
[09:51] <superm1_> is this commit toward unionfs supposed to be resolving the issue on the currently daily builds, or is that coming in a later build? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=commit;h=2289191572cbb20dc4db387cc079e79f003a3bf2
[09:52] <rtg> superm1_:  Phillip is still working on it.
[09:53] <superm1_> rtg, okay cool thanks :)
[10:08] <mjg59> rtg: e0 means it's an extended scancode, 5b is the mapping, db is the release
[10:08] <mjg59> We need e05b for the mapping
[10:09] <rtg> mjg59: thanks.
[10:09] <mjg59> Does it not already generate a keycode under X?
[10:09] <rtg> mjg59: It does, I was juts trying to figure out the mapping using 'showkey -s'
[10:10] <mjg59> Ah, ok