=== skaet_ is now known as skaet
=== hughhalf_ is now known as hughhalf
[07:08] <ppisati> moin
=== smb` is now known as smb
[07:14]  * smb tries to get in unseen
=== Guest8994 is now known as tlei
[08:52] <ppisati> brb
[09:33] <dileks> apw: http://marc.info/?l=linux-kernel&m=134519512112692&w=2
[09:48] <apw> heh, that sounds like fun
[10:07] <dileks> apw: s***storm expected
[10:07] <apw> dileks, i expect it will just get ignored actually
[10:07] <apw> though al migh reply and tell us if union-mounts is going in or not
[10:09] <dileks> I repeated consciously the word "finished" and remembered the nvidia-f-u video, so this will ring bells (I hope so). but lets see.
[10:09] <apw> well its not like overlayfs is finished either
[10:10] <apw> its all pretty tricky
[10:15] <dileks> apw: if the code is upstreamed more people will look at it and use it. its more a phychological thingie. /me thinks of enlightenment DR17 (OK, the major libs have now stable versions :-), but ...)
[10:16] <apw> dileks, there is that, overlayfs has semantic issues (due to its attempts to be performant) that i am not sure will ever be acceptable
[10:16] <apw> to the purists
[10:19] <dileks> I remember a faculty meeting where one professor throw into the round, only (software engineering) fundamentalist talk like this... rebellion or kindergarden I dunno. he sould have said "purists", hehe.
[10:19] <dileks> apw: and miklos somehow reminds of IBM and OS/2
[10:20] <dileks> hope he will not throw away his own code
[10:20] <dileks> marketing seems to be a foreign word to him
[10:21] <dileks> I suggested to get overlayfs into linux-next
[10:22] <dileks> out of my own experiences... linux-next is better tested than any rcX (upstream) :-)
[10:22] <dileks> https://lkml.org/lkml/2012/8/16/602
[10:29] <caribou> smb: howdy, just saw your comment about the kdump kernel issue in Quantal
[10:30] <smb> caribou, Hi there. Well, just made it. :)
[10:30] <caribou> smb: just so I understand things correctly : this is not specific to our kernel but is in any mainline kernel above 3.5 ?
[10:31] <smb> caribou, right
[10:31] <caribou> smb: if so, shouldn't it be brought up to the kexec ML ?
[10:32] <smb> caribou, Well it is an issue that ends up making the limited memory even more limited. I don't think it is something that kexec needs to change but the kernel.
[10:33] <caribou> smb: I know, but maybe the kexec people oughta be aware of it (I mean the fact that it doesn't  work)
[10:33] <caribou> smb: afaik, hpa is on the kexec ML
[10:33] <smb> But feel free to take it to the kexec ml 
[10:34] <smb> So maybe that would be another way to make him aware
[10:34] <smb> He was cc'ed on the lkml discussion but I can understand when people miss things there
[10:36] <caribou> smb: it's worth a try. I just don't wanna make a fool out of myself by stating the obvious :-)
[10:37] <caribou> smb: to me, it looks like the full kexec mechanism doesn't kick in, which should have been seen before
[10:37] <smb> caribou, I wonder, did you try with more than 128M of crashkernel memory?
[10:38] <caribou> smb: nope, but I can try, I just prepared a VM for that
[10:38] <smb> (that would be 64bit, on 32bit it would be a different problem)
[10:38] <caribou> smb: yep, x86_65
[10:38] <caribou> euh, 64
[10:38] <smb> heh :)
[10:38]  * smb always needs to refrain from saying 31 bit
[10:40] <smb> caribou, So basically the problem is that on 64bit, due to some mismatch you have about 3 to 6MB (rough estimate) more memory wasted to initial page tables.
[10:41] <smb> Depends of course on the amount of memory you have on the machine
[10:42] <caribou> smb: with a 2G VM, even with 256M reserved it doesn't work
[10:43] <smb> caribou, what kind of vm (xen, kvm, virtualbox,...)? and does a normal (non-crash) kexec work there?
[10:44] <smb> The problem could be a different one just in the VM
[10:48] <caribou> smb: it's a KVM vm. 
[10:48] <caribou> smb: I'll try to test on baremetal when I have a minute
[11:41]  * henrix -> lunch
[12:30] <smb> *sigh* is it just me or is a kvm using cirrus graphics currently broken in quantal (had to blacklist the cirrus kernel module otherwise the X driver went into a corner and sulked)
[12:34] <apw> smb, not tried that i am afraid
[12:38] <smb> Of course I have not looked what modules were loaded and which driver was used before that giant upgrade...
[12:42] <siretart> hi. - I'm currently testing the fai (fully automated installation) package in ubuntu, and am struggling with technicalities in the kernel
[12:43] <siretart> it seems that aufs has been disabled currently in quantal. is this correct, and is the plan for release to leave that disabled in favor of overlayfs?
[12:43] <apw> that is the current plan, though it was the plan for P as well, and it didn't work out
[12:43] <siretart> I've also tried overlayfs, but I got a kernel oops when trying it with an nfsroot
[12:44] <siretart> I didn't find nor file a bug for that yet, I'm still checking the options here.
[12:45] <apw> always interested in overlayfs triggered opses
[12:45] <siretart> let me phrase it as a question: is overlayfs supposed to work with NFS?
[12:46] <apw> there is an indication that NFS is not complete enough to be suitable
[12:47] <apw> (as an UPPER filesystem)
[12:47] <apw> otherwise i suspect it is expected to work
[12:48] <siretart> I'm not sure if I undestand the 'UPPER' part correctly. The setup is to mount the nfsroot read-only from the installation server, and use unionfs to mount a tmpfs ontop of that in early userspace, then continue booting
[12:48] <apw> in that context the NFS is LOWER
[12:48] <siretart> ok
[12:48] <apw> so i think the docs say we might it expect it to work indeed
[12:49] <apw> cirtainly i have never tried that combo
[12:49] <siretart> I'll try to reproduce this in non-initramfs context (i.e., on an properly booted system) first, and see if that's enough to describe a test-case. thanks for explaining the current situation and what to expect.
[12:50] <apw> ok cool.  do ping me with the bug number when you get that far
[12:50] <siretart> willdo
[12:59] <siretart> apw: yep, I managed to reproduce it without early userspace. http://pbot.rmdir.de/ba0ec9f8742a0a0dce7ffcd24db00c12 - filing a bug now
[13:08] <siretart> apw: filed as bug #1038075 - feel free to ping me either here or in #ubuntu-devel if there is any additional information that might be useful here
[13:08] <ubot2`> Launchpad bug 1038075 in linux "[Overlayfs] kernel OOPS with NFS" [Undecided,New] https://launchpad.net/bugs/1038075
[13:22] <rtg_> apw, sbuild wants aufs, doesn't it ?
[13:23] <apw> rtg_, i believe it uses overlayfs as well
[13:23] <siretart> rtg_: sbuild itself doesn't care, but schroot deals with aufs if configured to do so
[13:24] <apw> i thought the default changed recently, i'd have to check
[13:24] <siretart> the mk-sbuild script from the ubuntu-dev-tools package switched the default from aufs to overlayfs in quantal
[13:24] <apw> if only the three upstream groups could talk to each other and sort out the problems
[13:24] <siretart> I did that only a couple of days ago
[13:25] <apw> smb, might that explain why your builds all broke ?
[13:25] <rtg_> apw, siretart: I'm using a quantal setup in a chroot, but a precise host. I guess I should just install a vanilla precise. this is on an ARM system.
[13:26] <siretart> could aufs be provided as out-of-tree add-on kernel module package in quantal?
[13:27] <apw> that doesn't really reduce the maintenance burden which would be the point of not building it
[13:27] <smb> apw, No I am still P. My "error" was to a( have switched from lvm snapshots to overlay and b) have set build_dir which seems to cause the actual build go into /build (which is overlay)
[13:27] <siretart> rtg_: I think the switch to overlayfs by default was already done for precise, if I read the changelog correctly
[13:28] <siretart> version number 0.136, dated Wed, 16 Nov 2011 14:33:04 +0200
[13:28] <rtg_> siretart, right. I know that sbuild works correctly in precise. it sure doesn't seem to in quantal.
[13:29] <apw> really waht issues you seeing, i am pretty sure my builder here is quantal using overlay for sbuild
[13:29] <siretart> rtg_: as said, with the test machine here that I have (amd64, upgraded from precise to quantal) mk-sbuild seems to work just fine for me
[13:29] <rtg_> hmm
[13:30] <apw> that fits with my expectations too
[13:30] <rtg_> dunno. I'm using this hacked up nano image from linaro.
[13:30] <apw> ahhh ... eeep
[13:30] <rtg_> think I'll start over
[13:31] <siretart> too bad that this booting via nfsroot is quite critical for our deployment here :-(
[13:37] <rtg_> apw, turns out this dang Linaro kernel has neither overlayfs or aufs. Guess I'd better fix that first.
[13:37] <apw> qualtity
[14:01] <ppisati> ogasawara: rtg_: after rebasing Q/omap4 on -11.11 i found a regression on boot. so i'll need some time to check what's going on
[14:01] <ogasawara> ppisati: ack
[14:02] <ppisati> but i would really like to upload 3.5 Q/omap4  even if it's still on -9.9
[14:02] <rtg_> ppisati, send a pull request. we can catch up to -11 next week.
[14:02] <ppisati> ack
[14:03] <ppisati> besides, i wanted to warn you that, no matter what we do, beta1 omap4 desktop image is going to be broken due to missing 3d driver
[14:34] <smb> caribou, So I have proof now that kvm crash-kexec works when fixing up the too big page table (4M->16K) and crashkernel=128M but it would not work with crashkernel=256M and the unpatched kernel. 
[14:34] <caribou> smb: good !
[14:35] <caribou> smb: I didn't get to test on realiron
[14:35]  * ogasawara back in 20
[14:36] <smb> caribou, Cannot really explain why. Probably it is not alone the size but also the location or increasing crashkernel= over a certain number is as bad as not being big enough...
[14:46] <akua> Can someone help me. I am trying to compile a kernel ( into a deb so I can copy it to a few systems at my work ). I need to use the linux 3.5.x kernel because of USB3 support, however I am trying to stay on Ubuntu 10.04 for the time being.  Everything is going well, I had a lot of problems finding a .config that worked OK, but before I install the kernel-image.deb, I have to copy initramfs from 
[14:46] <akua> /usr/share/doc/kernel-package/examples/etc/kernel/postinst.d/initramfs into /etc/kernel/initramfs or the kernel panics on reboot.
[14:46] <caribou> smb: might be a good idea to put your findings in the bug; I will refer to it if I post to the kexec ML (maybe monday)
[14:47] <akua> I would rather the deb has all the files and actions necessary, but it seems it doesn't.  I am building the deb with the command: "fake root make-kpkg --initrd --append-to-version=-test1 kernel-image kernel-headers" 
[14:47] <smb> caribou, I should ... and thought I had some but right, I will update it
[14:48] <rtg> akua, have you tried just installing the quantal kernel ? 
[14:48] <akua> I also tried the "AUTOBUILD=1 fake root debian/rules binary-debs" method on a git checkout from quantal, but ended up with debs that had no usb hid_drivers, etc.
[14:49] <akua> ya. I tried that, but it was built with gcc 4.6, and some new version of glibc and then I couldn't compile any kernel modules after the fact, which I must do to run the devices ( capture cards, etc ) required.
[14:50] <rtg> akua, remember that the git checkout method produces _2_ packages that need to be installed. linux-image and linux-image-extra
[14:52] <rtg> you might also need the linux-firmware package from precise or quantal to pair up with kernel drivers that need newer firmware.
[14:53] <akua> rtg: what do you mean about the firmware, is it only if i use the pre-built quantal kernel, or even if i compile my own?
[14:54] <rtg> akua, yes, you should use a newer linux-firmware in either case
[14:55] <akua> rtg, i was hoping to build my own kernel-image.deb so I can use a specific kernel, do I need to compile my own firmware then, or is it 'generic'?
[14:56] <rtg> akua, its largely generic
[14:58]  * rtg reboots gomeisa for kernel update
[15:16] <akua> rtg: and there is no easy/obvious solution as to this initramfs problem? I can probably live with it, but for the firmware should I just install linux-image and linux-firmware ( the one from quantal ) and everything should work?
[15:16] <rtg> akua, yes, but don't forget linux-image-extras
[15:21] <akua> it seems the debian/rules method makes one of those, but the make-kpkg doesn't
[15:32] <akua> rtg: ok, the git method seemed to work, but the headers won't install cleanly because it (linux-headers-3.5.0-10-generic) depends on 'linux-headers-3.5.0-10'. Can I build this?
[15:34] <rtg> akua, build binary-indep (I think)
=== kamal1 is now known as kamal
[16:12]  * smb -> EOW
[16:25] <apw> binary-headers might do it too
[16:52]  * henrix -> EOD
[17:07]  * ppisati -> EOW
[18:07] <cwillu_at_work> quick question: the 32-bit mainline packages seem to have some magic to detect whether the cpu supports pae or not; I'm trying to roll a test image, but I can't install that package on the build server because cpuinfo doesn't reflect the target hardware
[18:07] <cwillu_at_work> is there a way to ignore that check?
[18:08] <cwillu_at_work> "This kernel does not support a non-PAE CPU.
[18:08] <cwillu_at_work> dpkg: error processing /tmp/linux-image-3.5.2-030502-generic_3.5.2-030502.201208151151_i386.deb (--install)"
[18:10] <rtg> cwillu_at_work, unless you've changed the config options, then I don't think the mainline kernel is gonna work.
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest37216
[18:13] <cwillu_at_work> rtg, how do you mean?
[18:13] <rtg> cwillu_at_work, I mean the its not gonna work on a non-PAE capable CPU
[18:13] <cwillu_at_work> rtg, I'm not running a non-pae capable cpu
[18:13] <cwillu_at_work> the cpu supports pae just fine
[18:14] <cwillu_at_work> the problem is the build environment
[18:14] <rtg> cwillu_at_work, well, the check is in the pre-inst. perhaps it is incorrect ?
=== Guest37216 is now known as mfisch
[18:19] <cwillu_at_work> rtg, I don't doubt that the check is correct, it's just that I really do know better than it in this case
[18:20] <rtg> cwillu_at_work, well then, hack on debian/control-scripts/preinst to remove the check and rebuild the kernel.
[18:21] <cwillu_at_work> rtg, I see a grim future of never being able to use the packaged kernels for automated installs though
[18:22] <cwillu_at_work> I'm mainly wondering if there's an existing flag to slap it down (--force-architecture should seem to imply this sort of thing, although that's primarily for dpkg I suppose)
[18:22] <rtg> cwillu_at_work, yeah, I don't see a way around it. preinst is part of the package and it wants to see 'pae' in /proc/cpuinfo
[18:25]  * rtg -> lunch
[18:30] <Eimann> sweet, https://eimann.etherkiller.de/nmz/panic-cisco-dlm-java-applet-in-ff.JPG - happens with 3.6.0-999-generic #201208090423 on x86_64 with 7~u3-2.1.1~pre1-1ubuntu3 openjdk when using the cisco software download manager in firefox 14.0.1+build1-0ubuntu0.12.04.1
[18:31] <cwillu_at_work> rtg, I think I got it faked out by plopping the word into an empty cpuinfo; first attempts didn't work as it's actually looking for " pae ", while I had tried a simple "pae" :p
[18:31] <cwillu_at_work> even so
[18:31]  * cwillu_at_work leaves a postit reminder on his monitor to file a bug
[19:42] <akua> I built my own kernel, and linux-image and linux-headers installs as expected, and boots with everything working. However, I am trying to compile nvidia's drivers ( because I need CUDA ), and it is complaining about not being able to find the headers.
[19:45] <akua> the director "/usr/src/linux-3.5.2-custom1/ exists, but /lib/modules/linux-3.5.2-custom1/build and /lib/modules/linux-3.5.2-custom1/source point to /usr/src/linux-3.5.2
[19:46] <akua> but if i link /usr/src/linux-3.5.2to /usr/src/linux-3.5.2-custom1 it still fails
[20:37]  * rtg -> EOW