[01:12] <mjg59> Where's the LPIA LUM tree for hardy?
[01:21] <mjg59> Ah, got it
[02:41] <Kano> hi, could somebody add aufs to 2.6.29 branch?
[02:41] <Kano> would be nice to have as squashfs is integrated to build a live image with it
[02:48] <Chenkai1> Hi, i am new to Linux module programming and my first hello_world.ko under Ubuntu 8.04 didn't seem to work.  Following the guide at http://ubuntuforums.org/showthread.php?t=800251, the compilation seems fine but no output from console nor /var/log/messages.  Any one could help me?  thanks:)
[02:51] <TheMuso> Kano: If you read Tim's email from the kernel team list, you will note that some ubuntu drivers have been disabled, aufs is likely one of those. I suggest if you want it ASAP, you help in getting it fixed/updated.
[02:53] <Kano> i did not read a mail,but i see the git log
[03:06] <maco> TheMuso: the git repo Tim's mail pointed to has 2.6.29-rc8. does that mean karmic = 2.6.29? or is 29/30 undecided at the moment?
[03:06] <TheMuso> Kano: I think the final version is undecided
[03:07]  * maco assumes that was at me
[03:07] <maco> ok
[03:07] <TheMuso> Kano: oops sorry
[03:07] <TheMuso> maco: yeah misread
[03:11] <dtchen> last sentence in "Kernel Version" at http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html
[03:12] <Kano> bye
[08:53] <cooloney> smb_tp, i switch here for a question about git clone
[08:54] <smb_tp> sure
[08:54] <cooloney> how can i git clone all the branches of a remote git tree
[08:54] <cooloney> not just one master branch
[08:55] <smb_tp> You normally do somewhat
[08:55] <smb_tp> if you do a "git branch -a" you would see them
[08:55] <smb_tp> you then can create one with "git branch <localname> origin/<name>"
[08:56] <cooloney> ok
[08:56] <cooloney> then git pull origin name
[08:56] <cooloney> right
[08:56] <smb_tp> then "git checkout <localname>" or probably "git checkout -b <localname> origin/<originname>"
[08:56] <smb_tp> which would save you one step
[08:57] <smb_tp> you don't need to pull. When you clone you get all the objects
[08:57] <smb_tp> It just does not create the local branchnames
[08:57] <cooloney> ok, i fully understand
[08:58] <cooloney> ikepanhc, you may try on you side 
[08:59] <ikepanhc> oh, got it
[09:00] <cooloney> i will try it on my side. actually, this problem frustrate me a lot
[09:13] <cooloney> smb_tp, actually this is a little bit difficult to understand, we assume _clone_ means copy everything
[09:14] <cooloney> and git branch, git checkout should be ok default
[09:16] <smb_tp> well, I think of it as git clone makes a complete copy of the repository objects, plus it conveniently checks out the origin/master as master
[09:16] <smb_tp> and makes a local branch for it as well
[09:16] <smb_tp> apw, Can you describe that better?
[09:18] <apw> thats pretty accurate
[09:18] <cooloney> git just does not do create a local branch from origin/<branch>, only master
[09:19] <smb_tp> AFAIK, yes
[09:19] <cooloney> ok, i see
[09:20] <apw> the master thing is a convienience
[09:20] <apw> you can and do checkout other branches from a remote
[09:21] <apw> clone checks out the HEAD branch from the remote, which is normally master
[09:21] <apw> and it does that because a repo with no branch checked out is confusing
[09:22] <smb_tp> iirc, you run into that situation when you create an empty remote and then push things over. before you checkout anything it looks just empty
[09:25] <apw> right
[09:25] <apw> git clone is equivalent to
[09:25] <apw> mkdir foo; cd foo; git init; git remote add origin <url>;  git fetch origin; git checkout -b master origin
[09:47] <IntuitiveNipple> brain-boost-needed: I'm *sure* we recently had a bug where there are random delays during boot for which I found/saw a new upstream patch that reworked the RCU 'idle' scheduling during boot. Trying to find it now I've drawn a blank. Does it ring a bell with anyone else?
[09:49] <IntuitiveNipple> Ha, thank-you Mr Invisible Man, that worked... found it... bug #254668
[09:49] <ubot3> Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] https://launchpad.net/bugs/254668
[09:50] <smb_tp> IntuitiveNipple, yeah that was one of them
[09:51] <IntuitiveNipple> I've got another bug that might be the same one, but it's been trailing on an Nvidia MCP67 issue
[09:51] <smb_tp> I see you found bug 272247 as well
[09:51] <ubot3> Malone bug 272247 in linux "System freezes during boot, unless I hold a key down" [High,Fix released] https://launchpad.net/bugs/272247
[09:52] <IntuitiveNipple> Yes, I'm seeing quite a few issues with MCP67 so thought it might be good to disambiguate them
[09:52] <IntuitiveNipple> There's some sign of AHCI data-loss with the MCP67 but only on Ubuntu... haven't found any noise upstream along the same lines so far.
[09:53] <smb_tp> Yes, there seemed to be a few on HP / amd machines. But also a few between the lines with intel cpu's
[09:53] <smb_tp> there is also bug 217849
[09:53] <ubot3> Malone bug 217849 in linux "Hardy 64-bit beta and nightly alternate installation stalls" [Critical,Incomplete] https://launchpad.net/bugs/217849
[09:53] <smb_tp> which is slightly different
[09:53] <smb_tp> For some it helped only to go for clocksource=jiffies
[09:54] <smb_tp> Other needed to get around acpi irq routing
[09:54] <IntuitiveNipple> Yeah, I remember that one. I was wondering out loud if it had to do with the bounce-buffering
[09:55] <smb_tp> right. i remember now
[09:55] <IntuitiveNipple> The upstream commentary on the RCU scheduled idle during boot patch looks like it covers a lot of bug reports
[09:55] <smb_tp> Generally it seemed like loosing irqs or going into a sleep state without a correct trigger to wake
[09:55] <IntuitiveNipple> do you know if anyone here has tried backporting the RCU patch? If not, I'll give it a go?
[09:55] <smb_tp> Not to my knowledge
[09:55] <IntuitiveNipple> OK. I'll see what it takes
[09:56] <smb_tp> Ok, cool
[09:56] <IntuitiveNipple> Seeing as it could wipe a fair few niggles out
[09:56] <smb_tp> Fixing that would sure make a lot difference
[10:01] <IntuitiveNipple> It'll need some munging to make it apply... I'll do some poking
[11:02] <IntuitiveNipple> Hmmm... this RCU patch. One of the conflicts is a file that doesn't yet exist in Jaunty but does in linux-2.6, and is amended It adds an inline function declaration. What would be the procedure for including its contents? 
[11:06] <smb_tp> IntuitiveNipple, if the change introducing the file/inline is just a moving around of files mostly, then probably pull the patch that created it
[11:07] <smb_tp> Otherwise we probably just want the inline...
[11:07] <IntuitiveNipple> Unfortunately, it's based ona major rework of the entire RCU code... since Jaunty RCU moved to a tree-based system. I'm carrying on but not sure the back-port will be possible in the end
[11:09] <IntuitiveNipple> I'll let that one stand for now and sort out all the content-conflicts... if those can be done, then I'll have to revisit this
[11:09] <smb_tp> Ok, thanks.
[12:01] <apw> maco, hey ... how is your asus acpi driver going
[12:01] <maco> apw: backburnered. trying not to fail my compilers class.
[12:01] <apw> heheh, always the way
[12:01] <rtg> always a good plan
[12:02] <maco> which...er...right...i should probably get back to yacc
[12:02] <apw> did that use to work on intrepid
[12:02] <maco> no, those keys never worked
[12:02] <apw> ok cool.  so its not a regression at least
[12:02] <maco> well i never ran intrepid on here. but they didnt work in hardy
[12:04] <_ruben> probably offtopic .. but does anyone have any clue wrt to the WARNINGS shown here: http://paste.ubuntu.com/132986/ .. those symbols are part of another (same 3rd party) kmod
[12:06] <rtg> _ruben: do you have that kernel installed (I assume you do), e.g., lib/modules/2.6.27-11 ?
[12:07] <_ruben> rtg: yes
[12:07] <_ruben> (its within a pbuilder chroot btw)
[12:08] <_ruben> i think on an earlier attempt i "fixed" it taking the Module.symvers file from the scst.ko along with its header files, but DKMS doesnt give me such a file (at first sight atleast)
[12:09] <rtg> _ruben: right, these are benign warning because no modules.dep exists for these symbols at MODPOST time (Ithink()
[12:10] <_ruben> rtg: i get similar errors when i modprobe iscsi-scst.ko
[12:10] <rtg> _ruben: so, you're saying its not working and the warnings are not benign?
[12:12] <_ruben> http://paste.ubuntu.com/132991/ .. thats when i modprobe them 
[12:12] <rtg> _ruben: you must be missing  one of the files in the link or compile. find out where scst_single_seq_open exists and make sure its getting compiled.
[12:12] <_ruben> toghether with: 
[12:12] <_ruben> # modprobe iscsi-scst
[12:12] <_ruben> FATAL: Error inserting iscsi_scst (/lib/modules/2.6.27-11-server/updates/dkms/iscsi-scst.ko): Unknown symbol in module, or unknown parameter (see dmesg)
[12:12] <_ruben> rtg: its within scst.ko iirc .. let me double-check
[12:17] <IntuitiveNipple> Has "scst" been built and installed against the same kernel version? It looks as if its symbols aren't present.
[12:17] <_ruben> rtg: strings shows scst_single_seq_open is present within scst.ko .. is there some tool to show whats being exported from a certain kmod
[12:17] <_ruben> IntuitiveNipple: yes .. both built using dkms against 2.6.27-11-server
[12:18] <rtg> _ruben: make sure its in an EXPORT_SYMBOL macro in the source
[12:18] <_ruben> rtg: let me check that
[12:19] <_ruben> src/scst_proc.c:EXPORT_SYMBOL(scst_single_seq_open);
[12:20] <rtg> _ruben: hmm, can you build it by hand using " make -C /lib/modules/2.6.27-11/build M=`pwd` " ?
[12:20] <IntuitiveNipple> Does this show them? grep -in scst_register /lib/modules/2.6.27-1/modules.symbols 
[12:20] <IntuitiveNipple> oops typo!
[12:20] <IntuitiveNipple> Does this show them? grep -in scst_register /lib/modules/2.6.27-11/modules.symbols 
[12:21] <rtg> IntuitiveNipple: I think that symbol is part of the module that he's building.
[12:21] <_ruben> # grep -in scst_register /lib/modules/2.6.27-11-server/modules.symbols 
[12:21] <_ruben> 621:alias symbol:__scst_register_virtual_dev_driver scst
[12:21] <_ruben> 1423:alias symbol:__scst_register_target_template scst
[12:21] <_ruben> 2298:alias symbol:__scst_register_dev_driver scst
[12:21] <_ruben> 2673:alias symbol:scst_register_session scst
[12:21] <_ruben> 3297:alias symbol:scst_register scst
[12:21] <_ruben> 4694:alias symbol:scst_register_virtual_device scst
[12:21] <IntuitiveNipple> No, it's part of scst not isci-scst
[12:22] <rtg> IntuitiveNipple: ah, missed that
[12:23] <IntuitiveNipple> OK, so, the build process isn't 'seeing' them via DKMS
[12:23] <_ruben> IntuitiveNipple: sounds about right, yeah
[12:23] <_ruben> it isnt dkms specific though, m-a has the same
[12:26] <IntuitiveNipple> Is there a custom Makefile for that module?
[12:28] <_ruben> just got a reply from upstream:
[12:28] <_ruben> 1. If you don't have SCST core's Module.symvers, you will see complains 
[12:28] <_ruben> on the MODPOST build stage. As you can notice, the Module.symvers is 
[12:28] <_ruben> installed during SCST core installation in /usr/local/include/scst 
[12:28] <_ruben> together with other SCST headers.
[12:28] <_ruben> 2. Since iscsi-scst.ko depends on scst.ko, you must have the correct 
[12:28] <_ruben> version of scst.ko installed, when you trying to load iscsi-scst.ko. 
[12:28] <_ruben> "Correct" means built with the same SCST headers for the same kernel as 
[12:28] <_ruben> iscsi-scst.ko.
[12:28] <IntuitiveNipple> ha!
[12:28] <rtg> that would definitely explain it
[12:28] <_ruben> so i gotta convince DKMS to take care of the symvers file i guess?
[12:28] <IntuitiveNipple> we knew the what but not the why
[12:32] <IntuitiveNipple> In src/scst/Makefile the install: target does "install -m 644 Modules.symvers $(INSTALL_DIR_H)"
[12:32] <_ruben> correct, but dkms doesnt call make install i think?
[12:33] <rtg> apw: are you done with checkbox then?
[12:34] <apw> checkbox is done as far as i can tell
[12:34] <apw> i am waiting for the publisher to download it
[12:34] <rtg> apw: ah, that reminds me to check on our new ABI kernel
[12:35] <rtg> kewl, someone has already NEWed it
[12:36] <rtg> apw: when you build checkbox on your PPA, do you only get i386 ?
[12:36] <IntuitiveNipple> smb_tp: Good news. The RCU back-port looks to be good. The Tree RCU fragments aren't required since there is no Tree RCU until 2.6.29.
[12:37] <smb_tp> Sounds cool. If you drop the patch to the mailing list I'll see to get a kernel build
[12:38] <_ruben> hmm .. perhaps a POST_BUILD= entry in DKMS can be used
[12:38] <apw> rtg yeah, its all 'all' code, all python
[12:39] <IntuitiveNipple> smb_tp: Will do. I'm doing a build and install test on it first
[12:39] <rtg> apw: hmm, I'm just not used to seeing packages only appearing in one ARCH
[12:39] <smb_tp> IntuitiveNipple, Ok
[12:39] <apw> yeah when its an all it does that
[12:40] <apw> its that mad all == any one and any means all of them
[12:40] <rtg> doesn't seem ortogonal
[12:40] <rtg> orthogonal, even
[12:47] <apw> its completely mind bending
[12:47] <apw> in better news the script is in the package and seems to work
[12:48] <rtg> apw: good, that was really my only goal.
[12:49] <apw> indeed, just running a real life test
[12:49] <soren> rtg: "archictecture: all" packages only get built on i386, but are published in all architectures.
[12:50] <rtg> soren: just one of those funny inconsistencies in the archive
[12:50] <soren> Ah, apw already pointed that out.
[12:50] <apw> really it should have been all -> indep and any -> all
[13:11] <IntuitiveNipple> 16-core Itanium 2 system for £999 ... is it worth it as a build server?
[13:13] <elmo> 16 cores for 1K?
[13:13] <elmo> that sounds like it's off the back of a lorry
[13:13] <elmo> and not in a good way :-P
[13:14] <rtg> IntuitiveNipple: and what do you do with ia64 anyway?
[13:14] <IntuitiveNipple> elmo: Yeah, I was wondering the same thing myself! I'd just looked at another for £24.5k :)
[13:14] <IntuitiveNipple> rtg: To play with, of course!
[13:14] <rtg> expensive toy
[13:15] <elmo> itanium's are only 2 cores per socket, right now, AFAICR?
[13:15] <IntuitiveNipple> all the best toys are :)
[13:15] <elmo> if so, that's an 8-socket machine.  which would make it *very* expensive to run, and likely *very* noisy too
[13:15] <IntuitiveNipple> 2 cores, 2 hyperthreads
[13:15] <IntuitiveNipple> elmo: It'd be banished to the garage like the PowerEdges
[13:16] <elmo> ah, well, if you have somewhere for it.  I dunno, my experience with Itanium's is with older machines
[13:16] <elmo> but unlessimproved vastly, the only thing going for that box would be the 16-wayness.  because core to core, a decent Xeon or even Opteron will outclass an Itanium like nobody's business
[13:16] <IntuitiveNipple> I was looking for one with VT support
[13:17] <elmo> s/unlessimproved/unless they've improved/ (woo, typing on a loaded box)
[13:19] <IntuitiveNipple> Yeah... same here... It'd make a great buildd for the kernels
[13:19] <IntuitiveNipple> But, that price... and 'cash only' makes me think... oh well *sigh* too good to be true
[14:13] <_ruben> grr .. gotta love being pulled into a meeting unexpectedly .. back to my scst/dkms endeavour :p
[14:13] <IntuitiveNipple> is there a make rule to easily build/install the /boot/vmcoreinfo* files from a quick-build ?
[14:15] <maco> rtg: around?
[14:15] <rtg> maco: in 20 mins or so. on conf call right now
[14:16] <maco> ok
[14:16] <rtg> saw you k-t list email
[14:16] <rtg> your*
[14:16] <maco> ah ok then nvm
[14:24] <IntuitiveNipple> ok, got it: KVER=2.6.28.8; sudo makedumpfile -g /boot/vmcoreinfo-$KVER -x ../builds/vmlinux
[14:41] <ernstp> IntuitiveNipple: still haven't seen the bug with an ext3 filesystem.. will leave it running overnight today
[14:42] <ernstp> IntuitiveNipple: if you remember, the MCP67/achi bug
[14:42] <IntuitiveNipple> which bug is that? I loose track :)
[14:42] <IntuitiveNipple> oh, yeah.... I'm actually looking at some patches for that issue atm
[14:46] <ernstp> IntuitiveNipple: cool
[14:47] <ernstp> IntuitiveNipple: had dpkg running on Intrepid userland on ext with 2.6.28 from the mainline archive for an hour, nothing happened
[14:47] <ernstp> IntuitiveNipple: ext3 that is
[14:48] <ernstp> IntuitiveNipple: Jaunty userland, 2.6.28-10 and ex4: 5 minutes dpkg and boom
[14:49] <ernstp> IntuitiveNipple: if you want some info from the system after it's happened I can probably recreate it pretty quickly
[14:53] <IntuitiveNipple> Could it really be an ext4 issue? I can't think how the file-system could cause that in the controller... but anything's possible
[14:54] <rtg> ernstp: cat /proc/version_signature, some ext4 patches were applied in -10.32
[14:56] <ernstp> IntuitiveNipple: well ext4 has much better performance I guess, bigger writes with delayed allocation, so maybe something... ? :-)
[14:56] <ernstp> rtg: got 10.32
[14:56] <IntuitiveNipple> rtg: bug #343919
[14:56] <ubot3> Malone bug 343919 in linux "Nvidia MCP67 AHCI ata timeout exception with data loss" [Medium,In progress] https://launchpad.net/bugs/343919
[14:57] <ernstp> rtg: but it should really be an "ahci" driver issue and not ext4 related
[14:57] <rtg> ernstp: ah, I just saw ext4 in the recent scroll-back
[14:59] <IntuitiveNipple> what bothers me is each error on whichever kernel is during ext4 journal work: "ext4_journal_start_sb: Detected aborted journal"
[15:01] <ernstp> but I've only ever seen it on ext4 so far
[15:01] <IntuitiveNipple> I've noted it on the bug... another avenue to examine
[15:03] <ernstp> but as I said, I'll leave dpkg running on an ext3 filesystem during the night today
[15:03] <ernstp> while true; do dpkg -i wesnoth*; done
[15:13] <ernstp> IntuitiveNipple: Ted Ts'o can take a look at it :-)
[15:16] <Kano> hi rtg , could you fix the aufs module first? thats needed to try the 2.6.29 kernel in live mode
[15:17] <rtg> Kano: Karmic is a background task, so I'll get to it eventually. I've still got to get Jaunty released.
[15:17] <Kano> well, there are systems which do not like 2.6.28
[15:18] <Kano> one asrock x58 board has some issues
[15:18] <Kano> therefore i want to check with 2.6.29
[15:19] <rtg> Kano: use the mainline build on http://kernel.ubuntu.com/~kernel-ppa
[15:19] <Kano> rtg: i need aufs!
[15:19] <rtg> then you're gonna have to do it yourself
[15:19] <Kano> squashfs is in the kernel now
[17:21] <mjg59> cking: Wow. That hpmini driver is special.
[17:21]  * cking nods
[17:22] <cking> ..ultimately a generic solution for ICH7 chipsets should be looked at for saving power on the wake alarm
[17:22] <mjg59> cking: Why not just have the kernel call acpi_disable_event(ACPI_EVENT_RTC) if there's no alarm set?
[17:23] <Keybuk> kees: if we move over here, we can say rtg a lot and he'll fix it
[17:23] <cking> mjg59: the driver turns off the power to the wake alarm mechanism - it's more of a low level ICH7 tweak to save power.
[17:23]  * Keybuk wonders what happens if you say it three times
[17:23] <Keybuk> rtg
[17:23] <Keybuk> rtg
[17:23] <Keybuk> rtg
[17:23] <Keybuk> :p
[17:23] <cking> and ping too
[17:24] <mjg59> cking: It looks like it's just writing to the PM registers, which is what acpi_disable_event does
[17:24] <cking> ..is this dependant on the BIOS doing things right?
[17:25] <mjg59> No
[17:25] <kees> Keybuk: you weren't standing in front of a mirror when you said it
[17:25]  * cking goes to look at acpi_disable_event more deeply
[17:26] <rtg> you guys quite hassling me. I'm packing boxes.
[17:26] <maco> wow, the combination of Keybuk highlighting, cking adding ping, and mjg59 saying 'PM' made mjg59's sentence confusing
[17:26] <Keybuk> rtg: are you going somewhere? :p
[17:26] <rtg> no, sending computers to germany and Mississippi
[17:27] <kees> Keybuk: oh the irony: config SECURITY_DEFAULT_MMAP_MIN_ADDR ... default 0
[17:27] <Keybuk> kees: well, yes
[17:27] <rtg> Keybuk: why are you bugging me? is SECURITY_DEFAULT_MMAP_MIN_ADDR the reason?
[17:27] <Keybuk> rtg: for your scrollback pleasure
[17:27] <Keybuk> it is
[17:27] <Keybuk> arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
[17:27] <Keybuk> vs.
[17:27] <Keybuk> debian/config/i386/config:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
[17:27] <rtg> Keybuk: ok, gimme 10 minutes or so, I've got a pickup deadline
[17:27] <Keybuk> vs.
[17:28] <Keybuk> /etc/sysctl.d/10-process-security.conf:vm.mmap_min_addr = 65536
[17:28] <Keybuk> ie. if we didn't override the config option back to zero in our kernel config, and used the x86 arch default, we wouldn't have to override it back to 64k in userspace via sysctl
[17:28] <kees> rtg: however, it seems that ARM needs to be 32768.
[17:29] <kees> according to the Kconfig help text, anyway
[17:29] <kees> ia64, ppc64, x86: 65536, all others: 32768
[17:29] <kees> where x86 means x86 and x86_64
[17:30] <rtg> kees: I though that used to be 0. it certainly was in Intrepid
[17:30] <rtg> thought*
[17:31] <kees> rtg: right, upstream changed the defaults.
[17:31] <rtg> oh, you want it set to 64k?
[17:31] <rtg> ok, can do.
[17:31] <kees> rtg: yeah.  it looks like it isn't set as a default for other archs in the kernel.
[17:31] <Keybuk> rtg: just left at whatever the arch default is I guess
[17:31] <Keybuk> do we not inherit from arch/*/configs/*_defconfig ?
[17:32] <rtg> Keybuk: not really, unless we start from scratch
[17:32] <kees> rtg: so, flipping it to 64k (x86, ppc, ia64) and 32k (others) is the way to go
[17:32] <rtg> is there an LP?
[17:32] <kees> Keybuk: it seems that some archs don't have a default yet upstream
[17:34] <ogra> rtg, can you please set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=32768 for ARM (higher values dont work on arm)
[17:35] <rtg> ogra: can do :)
[17:35] <ogra> thanks a lot :)
[17:35] <rtg> ogra: why is it that not all of the ARM flavours have this option?
[17:36] <ogra> up to now we have set it from /etc/sysctl.d/10-process-security.conf so it sisnt matter at all
[17:36] <ogra> *sisnt
[17:36] <ogra> gah
[17:36] <ogra> didnt
[17:37] <ogra> upstream now uses CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536 ...
[17:37] <ogra> but that breaks on arm
[17:38] <ogra> the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768."
[17:38] <rtg> kees: did you say you had started an LP bug on CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR ?
[17:38] <ogra> and i just verified that setting vm.mmap_min_addr = 32768 works fine (while 65536 breaks in intresting ways)
[17:39] <kees> rtg: I will open one.
[17:39] <rtg> kkesits not really necessary, just wanted to be sure to get the LP# in the commit if it existed
[17:39] <kees> ogra: yeah, I was discussing the fixes here with rtg before you joined
[17:39] <ogra> ah, k
[17:39] <rtg> kees: ^^ (can't type today)
[17:40] <kees> rtg: right, I'd like it so I can follow it with procps changes to address it.
[17:40] <rtg> np
[17:44] <ernstp> IntuitiveNipple: 1 hour no problem with 2.6.29-020629rc8-generic, ext4, jaunty. don't think 1 hour is enough though
[17:45] <Kano> rtg: you can remove the squashfs part in ubuntu dir on 2.6.29
[17:45] <Kano> it is inside the kernel
[17:45] <kees> rtg: bug #344955
[17:45] <ubot3> Malone bug 344955 in linux "CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR needs to be set" [High,In progress] https://launchpad.net/bugs/344955
[17:45] <IntuitiveNipple> ernstp: If it doesn't fail then we'll have to hunt the commit(s) that fix it
[17:46] <ernstp> IntuitiveNipple: lol, just because I wrote that it failed!
[17:46] <kees> rtg: once that's in a published kernel, I will fix procps.  :)
[17:46] <ernstp> IntuitiveNipple: same message as usual
[17:47] <ernstp> reboot :-)
[17:48] <ogra> kees, i would call it "high" or even critical for procps ... it breaks ARM completely atm
[17:50] <ogra> (i.e. prevents us from building functional images)
[17:55] <kees> ogra: right, though it will be fixed very soon in the right place.
[17:56]  * ogra hopes so, i need to start building images for imx51 asap
[17:56] <ogra> *before* the beta freeze
[17:56] <kees> ogra: are there any arm-specific packages?  You could put a 12-arm-mmap-min.conf into /etc/sysctl.d/ that sets it to 32k until the kernel is fixed?
[17:57] <ogra> sadly there arent ... 
[17:57] <ogra> but i'll try to hack around it in an image build script 
[17:58] <kees> ogra: there isn't anything easy in the build script, I can try to teach procps about the arm-specific stuff.  I'd rather wait just to avoid needing to clean up conf files, etc.
[17:58] <ogra> yeah
[17:58] <ogra> well, since i'm about to write the build script ther *will* be :)
[17:58] <ogra> if i want it 
[17:59] <ogra> we dont have the script i'm talking about yet (i wanted to write it today, but the bug was in my way)
[18:09] <amitk> rtg: are you on the SECURITY fix for the day?
[18:10] <amitk> or do you want me to look at it?
[18:10] <ogra> wow, he's fast
[18:11] <ogra> 16min from reported to fix committed status for 344955 :)
[18:11] <amitk> hehe...
[18:11] <rtg> ogra: I have this amazing hoover that builds _really_ fast
[18:12] <kees> rtg: is that the one you were replacing the mainboard in last week?
[18:12] <ogra> heh
[18:12] <amitk> ogra: I'll push the rest of the changes to imx51 before I got to bed. Then badger rtg for an upload ;)
[18:12] <cking> mjg59: yep - I've familiarised myself with the ACPI code now.  A generic solution is that acpi_disable_event(ACPI_EVENT_RTC) before hibernate if the wake alarm is not set
[18:12] <ogra> yay
[18:12] <rtg> kees: yep, then I added 4 spindles for raid0
[18:12]  * kees drools
[18:12] <ogra> amitk, btw, my USB NIC works fine now ... 
[18:12] <ogra> makes the babbage a breeze
[18:13] <amitk> ogra: it better! The imx51 is a bloated beast right now 
[18:13] <ogra> but works fine :)
[18:13] <ogra> i shall try my ton of different USB devices the next days 
[18:14] <mjg59> cking: Yes, that sounds sensible
[18:14] <mjg59> cking: Probably for S3 as well as S4
[18:14]  * cking nods. It will save several mAh in hibernate that's for sure
[18:16]  * cking investigates cmos_suspend() et al
[18:17] <mjg59> cking: I think you mean several mA :)
[18:17] <cking> yep. 
[18:28]  * cking wonders why this is not done already
[18:47] <rtg> amitk: so, you're gonna drop some ARM patches on me?
[18:50] <amitk> rtg: where are you uploading?
[18:50] <amitk> rtg: *when
[18:51] <rtg> amitk: anytime you're ready. end of my day is in about 90 mins, but I can do it later tonight as well
[18:52] <amitk> rtg: then let's not rush it. I've had a long few days. I'll finish up the configs _and_ look at d-i tomorrow morning ready for you to upload when you start.
[18:54] <rtg> amitk: in that event I'll upload anyway so kees can get his procps security fix out of the way
[18:56] <amitk> rtg: then let me just push the imx51 config changes. I'll fix d-i later
[18:56] <amitk> gimme 30mins
[18:56] <rtg> k
[19:15] <lime_> hi
[19:18] <lime_> how i can let ubuntu 32 bit see 4G ram?
[19:18] <ubot3> lime_: Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 338, column 84
[19:18] <rtg> lime_: install the -server kernel
[19:19] <lime_> i did that but still not seen !
[19:19] <rtg> lime_: depending on your chipset, you may only see a bit more then 3Gb
[19:20] <lime_> in the Bios it show 4G , it is dell laptop xps m1210 
[19:20] <rtg> apw: your 'hotkey quirks for various Zepto Znote and Fujitsu' would be easier to cherry pick into Karmic if you pushed it to Jaunty
[19:21] <apw> hrm
[19:21] <rtg> apw: also, I have to admit I didn't read you original email correctly.
[19:22] <rtg> lime_: the other alternative is to run the 64 bit kernel and user space.
[19:22] <apw> rtg that commit should be on the jaunty repo, its the third commit against my origin/master -- baad507a2aca0f997f01f964e03f79c4ec622cf4
[19:23] <rtg> huh, sure is. I searched for the log message in the email and didn't see it.
[19:24] <rtg> apw: sorry for the noise. go back to your beers.
[19:28] <amitk> rtg: cross compile for entire armel will take ~1hr45m. Are you going to do it in any case?
[19:28] <rtg> amitk: yep
[19:28] <rtg> takes about 10 mins
[19:29] <amitk> rtg: then I won't. You'll have to fix abi issues if any for the other flavours. I am marking imx51 as ignore
[19:29] <rtg> amitk: np
[19:30] <apw> rtg beers i wish
[19:30] <rtg> apw: what, you run out?
[19:30] <apw> yeah have to go buy some before i can start, how fair is that
[19:31] <rtg> apw: so, what should I do with the EC2 pile from Chuck?
[19:31] <apw> there are some integration issues i believe just in terms of whether we need a branch or not for this thing
[19:31] <apw> i was going to review them properly tommorrow am and report back
[19:32] <apw> overall the look reasonable, just these niggles on how we get them into our tree without breaking it
[19:32] <amitk> rtg: patch pushed.
[19:32] <amitk> bradF: yes. How can I help you?
[19:34] <bradF> i have aufs building now (that's the good news)
[19:35] <bradF> amitk: i have aufs building now (that's the good news)
[19:35] <bradF> amitk: will need to do some fencing in unionfs to support the old api
[19:36] <bradF> amitk: ixp4xx doesn't enable AA but does use NFS so there would need to be fencing done there (the bad news)
[19:36] <bradF> amitk: still want to proceed?
[19:38] <bradF> amitk: larger issue is that any fs which is enabled for either ixp4xx or imx51 will probably need fencing done
[19:40] <lime_> from here I can enable HIGH_MEM option?
[19:40] <rtg> lime_: which will force PAE
[19:41] <amitk> bradF: that sounds like a much larger project
[19:42] <amitk> bradF: do you mean to say that we've applied apparmor patches to our kernel in such a way that it is very hard to turn off AA now?
[19:42] <bradF> amitk: yes
[19:43] <amitk> rtg: ^ perhaps something to keep in mind if you haven't already applied AA for Karmic
[19:43] <rtg> amitk: AA was one of the first commits that I dropped
[19:43] <lime_> rtg, yes how ?
[19:44] <amitk> \o/
[19:44] <amitk> we really should not be this tightly coupled to AA. Who knows if we want to move to SELinux someday
[19:45] <sbeattie> Eh? you're only tightly coupled to the vfs hook changes. selinux (kernel portion) works now.
[19:45] <amitk> rtg: its your call for Jaunty. Should bradF continue decoupling it? It seems the AA _might_ work after all
[19:45] <amitk> sbeattie: not being able to compile the kernel without AA is very tight coupling IMO
[19:46] <sbeattie> amitk: with AA disabled or without the AA patches?
[19:46] <amitk> sbeattie: not necessarily a problem of AA perse, but the way the patches are applied
[19:46] <rtg> amitk: well, I never was in favor of disabling AA. Have you found the source of your AA crash?
[19:46] <bradF> amitk: should I start looking at that the oops that started this? don't know what progress I'll make but I can start.
[19:47] <amitk> rtg: no, we haven't found the reason for the oops. But I think the MMAP_MIN_ADDR might have something to do with it
[19:47] <rtg> that would be nice if it really is the case.
[19:47] <bradF> amitk: interesting!
[19:48] <sbeattie> hrm, the oops backtrace I saw was on the kernel trying to execve /sbin/init, long before the MMAP_MIN_ADDR stuff gets applied.
[19:49] <amitk> bradF: fixing the oops is still a worthwile goal. That will allow us to enable AA for all arm flavours
[19:50] <bradF> amitk: so, I should stop further work on the AA changes and concentrate on the oops?
[19:50] <rtg> bradF: I suggest you put everything you've done to date on  a branch in case we have to come back.
[19:50] <bradF> rtg: can do
[19:50] <amitk> bradF: yes
[19:50] <bradF> amitk: works for me
[19:52] <amitk> AA upstream would still be interested in that problem being fixed. It seems like it is the first time someone's run AA on ARM arch
[19:54] <rtg> bradF: do you get serial console? It may be one of those printk until you find it bugs.
[19:55] <amitk> amitk &
[19:59] <bradF> rtg: yes to serial console
[19:59] <rtg> bradF: ok, rinse and repeat :)
[21:21] <ernstp> IntuitiveNipple: 5 hours constant dpkg on ext3 with a 2.6.28 kernel, nothing
[21:22] <IntuitiveNipple> ernstp: poor ext4 :( looks like the finger is pointed its way although I still don't see how the file-system can be implicated, unless it provokes some sequence of events that the particular controller/disk combination doesn't like
[21:23] <ernstp> IntuitiveNipple: yeah, it's really wierd...
[21:23] <ernstp> IntuitiveNipple: userland shouldn't matter right?
[21:24] <IntuitiveNipple> if it's an indirect linkage, anything could cause it
[21:24] <rtg> I'm pounding my ext4 file system.
[21:24] <ernstp> IntuitiveNipple: so I've got the exact same mainline kernel build of 2.6.28.7 installed on a Jaunty partition with ext4 and an Intrepid partition with ext3
[21:24] <IntuitiveNipple> maybe the way ext4 tries to line up accesses in your case is significant.
[21:24] <ernstp> IntuitiveNipple: the very same kernel. nothing on ext3, happens on ext4
[21:25] <ernstp> sounds fun to debug
[21:26] <ernstp> one difference is more /etc/sysfs.conf
[21:26] <ernstp> devices/system/cpu/cpu0/cpufreq/scaling_governor=performance
[21:26] <IntuitiveNipple> rtg: off hand do you know who's responsible for the nvidia DKMS package scripts? Is it 'kernel-team' or someone else?
[21:26] <ernstp> I'll enable that on the other and leave it running tonight
[21:26] <rtg> Alberto Milone, can't think of his nick
[21:26] <IntuitiveNipple> OK, thanks
[21:27] <IntuitiveNipple> I just found the default DKMS doesn't work against a manually installed kernel, took me a while to figure out how to sort it out, would be nice if it could work for both packaged and manual installs
[21:28] <rtg> IntuitiveNipple: gimme a sec to track him down.
[21:29] <rtg> IntuitiveNipple: alberto.milone@canonical.com, tseliot is his nick
[21:29] <IntuitiveNipple> It's okay, I'll email him
[21:29] <IntuitiveNipple> yeah, that's the one :)
[21:30] <Kano> IntuitiveNipple: usally it does when you boot a new kernel
[21:31] <IntuitiveNipple> Kano: It can't in this case, that's the thing, since one of the include files it uses in a build-test app isn't where it is expected
[21:31] <IntuitiveNipple> with a manual install the out-of-tree build dir is linked from ./build and the source is ./source
[21:32] <IntuitiveNipple> I had to play with reversing SYSSRC and adding SYSOUT to dkms.conf to figure it out
[21:32] <Kano> well they are expected at the standard postition
[21:33] <IntuitiveNipple> The Linux kernel modules_install and the Ubuntu linux-headers do different things... it would be nice if the DKMS package can cope with both
[21:34] <Kano> was this link /lib/modules/$(uname -r)/build correctly set?
[21:35] <IntuitiveNipple> ./build/ links to the out-of-tree build directory, which doesn't contain linux/utsname.h (that's in ./source/include/)
[21:36] <IntuitiveNipple> I'll figure out a munge tomorrow, now I have it working 
[21:36] <Kano> here it is in include/linux/utsname.h
[21:36] <Kano> not in your linux version?
[21:39] <Kano> well it is in the ubuntu packages at that place at least ;)
[21:39] <Kano> even in 2.6.29
[21:39] <IntuitiveNipple> For packaged headers it's in ./build/include/linux/ but for out-of-tree kernel builds installed using the kernel's own make modules_install it's in ./source/include/linux/
[21:39] <Kano> so will test my aufs hack
[23:05] <marijus> will there be 2.6.29-rc kernels with kms support build for the mainline kernel ppa? 
[23:23] <erle-> are the virtualbox kernel modules packaged with the "restricted modules"?
[23:25] <TheMuso> erle-: no. What version of Ubuntu are you using?
[23:25] <erle-> 8.10
[23:25] <TheMuso> I think for 8.10 the virtualbox modules are built using dkms, but don't hold me to that.
[23:27] <erle-> i removed the restricted modules a few days ago
[23:27] <erle-> and now i see that there is no more vbox module
[23:27] <erle-> i think it is packaged there
[23:27] <erle-> and i think that has to be fixed!
[23:27] <TheMuso> Well I could be wrong, but I didn't think it was.
[23:27] <erle-> TheMuso, can you please look up?
[23:27] <erle-> i cannot because the package is not installed
[23:27] <TheMuso> Alright, one second.
[23:31] <TheMuso> erle-: you want virtualbox-ose-source
[23:31] <erle-> TheMuso, i don't think so
[23:32] <erle-> there is a precompiled kernel module shipped
[23:32] <erle-> why should i build my own?
[23:32] <erle-> the source is nice for people with custom kernels
[23:33] <IntuitiveNipple> erle: "This package provides the binaries for the Open Source Edition of
[23:33] <IntuitiveNipple>  VirtualBox. The virtualbox-ose-source package is also required in order to
[23:33] <IntuitiveNipple>  compile the kernel modules needed for virtualbox-ose"
[23:33] <TheMuso> erle- In that case, I don't know. I suggest you ask in #ubuntu-motu since there you will find the people who maintain it.
[23:34] <erle-> hm
[23:35] <erle-> i know that it worked before without custom module building
[23:35] <erle-> now i am confused
[23:35] <erle-> i will investigate and inform you
[23:40] <erle-> sorry, my fault, everything fine again
[23:40] <erle-> he seems to compile the modules from source on demand
[23:41] <erle-> thank you for your support and sorry :)
[23:42] <TheMuso> erle-: thats ok, it can be confusing if you don't know where the modules come from.
[23:43] <erle-> yeah, its just because i removed the one module package and thought that's the reason
[23:45] <TheMuso> yep