[00:29] <LLStarks> yo.
[00:44] <LLStarks> yo. i need help with a patch.
[05:54] <pwnguin> heh, should i be concerned that 2.6.29 doubles rsa performance?
[10:36] <apw> sounds like you shoud be happy
[11:26] <mdz> apw: any luck quashing the false positive suspend/resume failure reports?
[11:27] <apw> no luck in finding the source, i have a  branch for apprt which i am about to test to paper over it
[11:28] <IntuitiveNipple> apw: is that unrelated to TEST_SUSPEND_SECONDS?
[11:29] <dandel> i got a suspend/resume failure on my laptop which is triggered each time ( but first i need the acpi to stop ignoring irq 9 (
[11:29] <apw> IntuitiveNipple, my answer is about completely false failures which are being reported by apport, not your 5 second timeout thingy
[11:30] <IntuitiveNipple> apw: OK, sounds harder to fix :)
[11:30] <apw> heh, not really
[11:40] <Kamping_Kaiser> sigh. 
[13:00] <IntuitiveNipple> apw: smb_tp: Could one of you guys clue me in on how you build the ~lpXXXX test kernels so I can use it on my build servers to create test kernel packages too?
[13:01] <apw> IntuitiveNipple, as in how we add that
[13:01] <apw> literally just before the build you edit the debian/changelog
[13:01] <apw> if its UNRELEASED you can add ~lpNNNtj1
[13:01] <apw> it its like jaunty you should leave out the ~
[13:01] <IntuitiveNipple> Is that it? so it is just a plain fakeroot debian/rules binary-generic  (or whatever) ?
[13:02] <apw> yep
[13:02] <smb_tp> too easy :)
[13:02] <IntuitiveNipple> doh! and there was me thinking it was something clever!
[13:02] <IntuitiveNipple> yeah, far too easy. these things are supposed to be brain-strainers :)
[13:02] <IntuitiveNipple> OK, that means I don't need to ask you guys to build/publish the kernels.. I can punt them into my PPA I guess, too.
[13:03] <smb_tp> The only special thing would be for me, that I usually base the checkout on the last updates version
[13:03] <IntuitiveNipple> The only thing I can think - for non-PPA builds - is my lack of a kernel.ubuntu.com address (would people be concerned at pulling test kernels from my own domain?)
[13:04] <smb_tp> The thing for me against ppa builds is, that it only has one version there
[13:04] <IntuitiveNipple> Yeah. I've got several builds in the queue for testing core kernel bug-fixes which I have high hopes for
[13:06] <smb_tp> btw apw I installed the test kernel for the i915 performance issue on the aa1 and it still works the same as before 
[13:06] <apw> oh nice
[13:07] <smb_tp> which was meant as a positive "no side effects" here, but  I realize it could be interpreted as nag, which it isn't :)
[13:08] <apw> smb_tp, i interpreted it as a helpful test on real hardware
[13:08] <smb_tp> good, such it should be 
[13:10] <apw> mdz you will be pleased to hear i just found a way in which you can get a normal looking suspend/resume in concert with it reporting a failure at next reboot.  in concert with my symptom of not wanting to suspend any more
[13:11] <mdz> apw: nice! bug#?
[13:11] <apw> it seems that there is a window after we wake up enough to see working, before the offial wakeup is complete and if we get stuck here (and video post has done that in the past for me) then we seem up to the user
[13:11] <apw> but really really the suspend/resume is broken
[13:11] <apw> i'll put the details in your bug as i am working the issue there
[13:12] <apw> it really is broken, it just seems ok to the user.   we need to tell those two appart so we can inform the user better and get more information when it occurs
[13:16] <mdz> apw: ok, please update the title of the bug to something more meaningful if you would
[13:16] <apw> mdz will do
[15:52] <zilleplus_> hey anny one know a lot of ubuntu server??
[15:52] <zilleplus_> can't get internet on myn
[15:52] <zilleplus_> my dhcp server on route does not shows anny connection from my server
[15:58] <manjo> zilleplus_, #ubuntu-server 
[16:02] <zilleplus_> can't get internet on new ubuntu server 8.10 can aanyone help (sudo route -nee shows not IP ore gateway)
[16:05] <manjo> zilleplus_, your interface is up ? 
[16:09] <zilleplus_> manjo are you still there??
[16:09] <manjo> yes
[16:10] <zilleplus_> okey this is my problem
[16:10] <zilleplus_> i installed my server angain
[16:10] <zilleplus_> ubuntu 8.10
[16:10] <zilleplus_> and cant get inthernet on it
[16:11] <zilleplus_> but config -a gives tath my eth divice is there
[16:11] <zilleplus_> wath do i do
[16:11] <mjg59> zilleplus_: This is the kernel development channel. Support is best found in #ubuntu.
[16:12] <zilleplus_> ooh sorry
[16:12] <mjg59> no problem
[17:08] <IntuitiveNipple> apw: That 'easy' kernel build failed with "Previous or current ABI file missing!" - looks like the changelog version caused debian/abi/2.6.28-11.38lp284377v1 instead of the expected "debian/abi/2.6.28-11.38/". Does that mean I *do* need ~ in the version or do I create an ABI?
[17:10] <apw> was the top of the thing 'jaunty' ?
[17:10] <apw> IntuitiveNipple, 
[17:10] <apw> if so its possible the upload has not yet had the abi files pulled down into it
[17:10] <apw> so it really will fail for all of us
[17:10] <apw> which abi files _do_ you have
[17:10] <IntuitiveNipple> you mean head? yeah, I did a git fetch; git rebase --hard origin/master then checked out the wip branch, applied the patch, and built
[17:11] <IntuitiveNipple> apw: 2.6.28-11.37  2.6.28-11.38lp284377v1
[17:11] <apw> and what are the first two versions in your changelog
[17:11] <apw> fdr printenv will show you what versions its really using
[17:11] <IntuitiveNipple> apw: 2.6.28-11.38lp284377v1 2.6.28-11.38
[17:12] <apw> ok what did you do
[17:12] <apw> did you add a whole new version in the top
[17:12] <apw> i was trying to suggest you simply _edit_ the existing top most version
[17:13] <IntuitiveNipple> apw: Yes, added a new changelog entry with the details of the change... as always :)
[17:13] <IntuitiveNipple> apw: ahhh!
[17:13] <apw> heh no no no don't do that for the kernel
[17:13] <apw> the changelog gets made by the automation on relase
[17:13] <IntuitiveNipple> If I don't I'll forget what the changes are :D
[17:13] <apw> then commit them using git
[17:13] <apw> and put the changelog on there
[17:13] <apw> thats where it should be
[17:14] <IntuitiveNipple> oh, as in the commit message flag? I included my new changelog entry in the patch commit as I do with other packages
[17:14] <apw> the kernel is odd as we cherry pick a lot
[17:15] <apw> so you never update debian/changelog, it just makes life hard when you rebase
[17:15] <apw> (as i just found rebaseing just three commits in bzr)
[17:15] <IntuitiveNipple> I knew that for 'regular' kernels but didn't realise it'd be so drastic for a test build :)
[17:15] <apw> when the release is done we do a fdr insertchanges which makes a debian changelog for us
[17:15] <apw> well the abi checks are very strict
[17:15] <IntuitiveNipple> yeah... I've done that myself in the past
[17:16] <IntuitiveNipple> I guess I'm too used to doing skipabi on out-of-tree builds
[17:23] <IntuitiveNipple> apw: thanks for that... trying again now
[17:24] <apw> luck
[17:28] <manjo> lieb, why does rmmod crasher just hang ? 
[17:29] <lieb> hang?  I tested and it unloaded fine.
[17:29] <lieb> it did hang w/ an earlier version
[17:29] <manjo> after an oops
[17:30] <lieb> ok, you did an oops and then unloading hung?
[17:30] <manjo> the one that is on your people page is the lastest ? 
[17:30] <manjo> yes I did an oops and then the unload hangs
[17:31] <lieb> hmm.  l'll look at it.  yes, the people page one is the latest (or should be)
[17:32] <manjo> also, if I wanted to make the oops appear at a function XXXXX() do I just move the *page0 = tmp; to a function XXXXX() and call it in its place ? 
[17:33] <lieb> I'm not sure what you mean
[17:33] <manjo> instead of EIP: [<f7f60271>] oops_store+0x61/0x70
[17:34] <manjo> I wouild like to see EIP: [< .....>] XXXX+0x../0x..
[17:34] <lieb> just a sec, let me pull up the code...
[17:35] <manjo> so if I call a function in oops_store() to do the same thing it should appear that the eip is now in that new function correct ? 
[17:36] <lieb> yes it would.
[17:36] <manjo> k
[17:37] <manjo> but after  *page0 = tmp; I need to have another instruction like return X;
[17:37] <lieb> also note the extra bit there w/ tmp.  I had to add that to fool the optimizer into doing the store at *page0 = tmp
[17:38] <lieb> and looking at it, I can see why the unload might hang
[17:38] <manjo> we can compile it unoptimized ? 
[17:38] <lieb> this is the sysfs write callback so that chunk of sysfs is left hanging.  I'll have to figure out a way to
[17:39] <lieb> delay the actual oops...
[17:39] <lieb> optimize, yes.  I forget exactly but it gets optimized out.  actually, if I remember, I wanted the DEADBEEF
[17:40] <lieb> to be in a register so we could recognize it.  the optimizer turned the store into a store immediate which
[17:40] <lieb> would not show up in the reg dump
[17:41] <lieb> do you really need this to be unloadable here?  the other opts (panic etc.) whack the kernel so there is nothing to unload from.
[17:43] <manjo> yeah not in the case of panic ... but unload after bug and oops will be nice but not critical I think
[17:44] <lieb> I'd have to look but I think there are some locks held when we get down here in sysfs.  since we never
[17:45] <lieb> return via the normal path, they would not get released.  If that is true, the unload wouldn't work because
[17:45] <lieb> the module exit would hang on the sysfs attr destructor(s)
[17:45] <manjo> right agree
[17:46] <lieb> that might be hard to do
[17:46] <lieb> some other poor sot of a task would have to take the sharp stick in the eye in order to let this task ret to userland
[17:47] <lieb> we can't use a tasklet/workq cuz that would kill a kernel thread and really bring it down.
[17:48] <lieb> yup, the source is the latest.
[17:51] <lieb> I have an idea.  as soon as my jaunty beta downloads complete, I'll try it out.
[19:06] <calc> mjg59: loving your posts to lkml :-)
[19:35] <lool> Hi folks
[19:35] <lool> CONFIG_BLK_DEV_RAM_SIZE was bumped for imx51 from 4MB to 8MB
[19:35] <lool> It turns out this is the uncompressed size, and we didn't bump it enough
[19:35] <lool>     gunzip -c </boot/initrd.img-2.6.28-11-imx51 | wc -c
[19:35] <lool>     8460800
[19:36] <lool> This results in ENOSPC:
[19:36] <lool> [42949379.640000] RAMDISK: Compressed image found at block 0
[19:36] <lool> [42949380.210000] RAMDISK: incomplete write (-28 != 32768) 8388608
[19:36] <lool> Could someone please bump it again to the same value as amd64/i386: 65535?
[19:40] <lool> Bug #349842
[19:40] <ubot3> Malone bug 349842 in linux "Please bump CONFIG_BLK_DEV_RAM_SIZE to 64MB" [Undecided,New] https://launchpad.net/bugs/349842
[19:46] <vadi2> hi, in regards to the suspend/resume testing, are you interested in machines with nvidia cards and the proprietary driver?
[20:00] <IntuitiveNipple> vadi2: Yes, any. I've got nvidia here (7600) and suspend/resume has been fine... so far :)
[20:00] <vadi2> ok. I haven't had any issues on mt 8600 either before but might as well test to be sure
[20:01] <vadi2> (if someone is willing to look at results and not say "oh, proprietary, your reports are useless")
[20:22] <manjo> lieb, note submitted patch to kernel-crasher
[20:24] <lieb> where?
[20:24] <manjo> ukml
[20:24] <lieb> ????
[20:25] <manjo> :)
[20:25] <manjo> ubuntu -kernel -mailing list
[20:26] <manjo> if someone has apport setup to report to kerneloops they will get a lot of false positives from this module... this patch takes care of that
[20:27] <lieb> manjo, you realize that this is boardering on loony, right?
[20:28] <manjo> the reporting part ? 
[20:29] <lieb> What was a testing tool is turning into a metastisizing code cancer.  I do not want to be responsible for the next re-incarnation of emacs! ;)
[20:30] <lieb> or gnome
[20:30] <lieb> or perl
[20:30] <manjo> heh
[20:31] <lieb> not a bad idea though... the function signature as a filter...
[20:31] <lieb> next thing I suppose is a .deb or whatever
[20:31] <manjo> haha
[20:31] <manjo> yeah I am sure there will be a request foir that soon
[20:32] <manjo> atually we can also add another case for loops ... for(;;);
[20:32] <lieb> I'll take the patch and update what I have.  We can talk next week on where to put this thing. right now it is on my local server
[20:32] <manjo> i know its on ur ppl page 
[20:32] <manjo> that might have to move if this is going to be useful 
[20:33] <lieb> and that is only a tarball
[20:33] <manjo> probably should be builnt in as a test module under misc or something 
[20:33] <manjo> with config options
[20:33] <lieb> yea.  to be discussed, probably in the kerneloops session.
[20:34] <manjo> its pretty cool tool ... was very useful in my kerneloops testing 
[20:35] <manjo> I think the arm part can be omitted ... who care if someone wants to shoot themselfs in the foot ? 
[20:36] <manjo> just have /sys/kernel/crash/test and have it take oops, bug, warn, etc as values
[20:37] <lieb> that part is quesionable.  what I thought of doing is spawning a kernel thread to take the bullet.
[20:37] <manjo> so if you cat /sys/kernel/crash/test it will show all the values that you can echo to it 
[20:37] <lieb> the arm part should remain for that reason.  that is why I was questioning the propagation of this beyond a small testing group
[20:38] <manjo> heh its beyond that now 
[20:38] <manjo> something to talk abt the next time we have this discussion with team
[20:39] <lieb> given that kerneloops+kexec/kdump has turned into "something else" it should probably be part of the test infrastructure
[20:39] <manjo> that is a good idea too
[20:40] <manjo> btw kerneloops on 32bit is still broken I think coz of kexec tools
[20:40] <manjo> kdump I mean
[20:40]  * manjo breaks for coffee
[20:40] <lieb> one of the things that I fell into with this pre-in-post berlin was discovering all these disjoint packages
[20:41] <lieb> that, in reality, are really bits of one single "package" intimately tied to the kernel.  Imagine my surprise ;)
[20:56] <cody-somerville> When I attempt to mount a squashfs, I get: mount: mounting /dev/loop0 on /mnt failed: No such device
[20:58] <IntuitiveNipple> cody-somerville: what's the command you're using?
[20:58] <cody-somerville> mount -t squashfs -oloop /cdrom/casper/filesystem.squashfs /mnt/
[20:59] <IntuitiveNipple> not sure about this, but shouldn't there be a space between -o and loop ?
[20:59] <IntuitiveNipple> I know I use that form and I've not had a problem
[21:01] <IntuitiveNipple> I've just used this: sudo mount -t squashfs -o loop casper/filesystem.squashfs /mnt/usb
[21:01] <IntuitiveNipple> And without the space... and it works... so not a missing space issue
[21:02] <IntuitiveNipple> Is the loop device operational?
[21:03] <cody-somerville> How can I tell?
[21:03] <IntuitiveNipple> which kernel version are you using?
[21:04] <IntuitiveNipple> obvious thing first is to look for the loop devices: ls /dev/loop*
[21:04] <cody-somerville> 2.6.28-11-generic
[21:04] <cody-somerville> they're all there
[21:04] <IntuitiveNipple> okay, module is built-in
[21:04] <IntuitiveNipple> does losetup report anything? sudo losetup -a
[21:04] <cody-somerville> losetup -a doesn't work
[21:04] <cody-somerville> I'm using busybox version
[21:05] <IntuitiveNipple> ahhhh
[21:06] <IntuitiveNipple> I don't believe busybox supports -t auto or -t squashfs
[21:07] <cody-somerville> It must
[21:07] <cody-somerville> how would d-i mount a squashfs?
[21:10] <cody-somerville> Maybe I should try doing this two step?
[21:11] <IntuitiveNipple> check what file-systems are available.
[21:12] <IntuitiveNipple> I'll boot a PXE image here and break into init and see if it is the same 
[21:13] <cody-somerville> Maybe I need to use unionfs?
[21:14] <IntuitiveNipple> no there's no squashfs: grep squash /proc/filesystems
[21:15] <cody-somerville> How do I get that?
[21:15] <cody-somerville> squashfs-modules doesn't seem to exist in ubuntu
[21:16] <IntuitiveNipple> The module isn't loaded at that point, presumably not in the initrd. (CONFIG_SQUASHFS=m)
[21:17] <cody-somerville> If I try to load the module, it says the module doesn't exist
[21:18] <IntuitiveNipple> from busybox/initrd? that might be correct. The module is ubuntu/squashfs/
[21:18] <cody-somerville> So do I need to get cjwatson to recompile d-i's initrd to include the squashfs module?
[21:19] <ogasawara> smb_tp: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/349655
[21:19] <ubot3> Malone bug 349655 in linux "[hardy][sparc]: new kernel in security doesn't boot" [High,Triaged] 
[21:19] <IntuitiveNipple> No
[21:20] <IntuitiveNipple> cody-somerville: the module is in /lib/modules/`uname -r`/kernel/ubuntu/squashfs/
[21:21] <cody-somerville> It isn't there
[21:22] <cody-somerville> /lib/modules/2.6.8-11-generic/kernel/ubuntu/ only has dm-loop, dm-raid4-5 and misc
[21:24] <IntuitiveNipple> I got it here ... let me check which version of the CD this is
[21:25] <IntuitiveNipple> 2.6.28-9-generic... let me try 2.6.28-11
[21:29] <IntuitiveNipple> cody-somerville: 2.6.28-11-generic live-CD i386 ISO does have squashfs here
[21:30] <IntuitiveNipple> cody-somerville: (in the initrd) I modprobed it and it shows in /proc/filesystems
[21:30] <cody-somerville> I wonder why it isn't showing up in my custom build for OEM Services
[21:31] <IntuitiveNipple> different config for the initrd possibly? 
[21:32] <cody-somerville> I use the same initrd from archive.ubuntu.com
[21:32] <IntuitiveNipple> is that the casper initrd?
[21:33] <cody-somerville> no, d-i's
[21:34] <IntuitiveNipple> what's the path to the one you use?
[21:34] <cody-somerville> http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/
[21:36] <IntuitiveNipple> which do you use? the cdrom/ ?
[21:37] <cody-somerville> yup
[21:39] <IntuitiveNipple> The initrd from there  doesn't have the ubuntu/ modules path in it
[21:39] <cody-somerville> So what do I have to do to fix that?
[21:43] <IntuitiveNipple> I'm not sure. I've not touched those before.
[21:43] <cody-somerville> Does the kernel provide subsets of modules in udebs or anything like that?
[21:44] <IntuitiveNipple> yes, in http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
[21:44] <cody-somerville> Whats the name of the udeb I need for squashfs support?
[21:45] <IntuitiveNipple> fs-secondary-modules....
[21:45] <cody-somerville> I figured as much...
[21:45] <cody-somerville> I have that in the pool
[21:46] <IntuitiveNipple> But, that doesn't contain squashfs... need to dig deeper :)
[21:48] <cody-somerville> yea, I was just going to say
[21:55] <cody-somerville> IntuitiveNipple, could any of these be it? http://pastebin.ubuntu.com/139208/
[21:55] <IntuitiveNipple> I've opened several to find it but not seen it so far
[21:58] <cody-somerville> squashfs-source claims to have the source for the kernel modules
[22:00] <smb_tp> ogasawara, thanks
[22:08] <cody-somerville> IntuitiveNipple, is there no lum for 2.6.28?
[22:15] <IntuitiveNipple> cody-somerville: that's correct. L-U-M was dropped for Intrepid and merged into the main kernel source, in the ubuntu/ directory