[05:04] <bullgard4> I obtained a message "panic occurred, switching back to text console". What Natty log file should reflect that?
[05:12] <ohsix> that's a panic; it wouldn't have made it to a log file, you need to take a screenshot of it or otherwise read it to start investigating what it is
[05:14] <ohsix> er screenshot -> photo
[05:27] <bullgard4> ohsix: When having made a photo, is the proper way to report to Launchpad using the command '~$ ubuntu-bug linux-image-2.6.38-8-generic' and attaching there the photo as a file?
[05:28] <ohsix> thats what i did last time i reported a panic
[05:28] <bullgard4> Thank you.
[08:28]  * apw yanws
[08:34]  * apw waves to cking 
[08:35] <jjohansen> morning apw, cking
[08:35] <apw> jjohansen, not again!  morning
[08:36]  * apw wonders if mumble is broke, or if its just none of us is in CC
[08:36] <cking> morning one and all, here we go again
[08:36] <jjohansen> apw: nope I'm not here, you are still groggy got get some coffee
[08:37] <jjohansen> s/got/go/
[08:45] <jjohansen> apw: so for aufs in the oneiric kernel we have commit dc7c488aeee4e3a50d6e76c5a6eba01d4ecfe432, and then b105abf699ff68fe0960a2568c14da8f82cfe4eb which is the merge from upstream which should have contained the patch in first commit mentioned, but that commit never got dropped
[08:47] <apw> jjohansen, looking
[08:48] <apw> jjohansen, ok the 'merge' from upstream is just a physical copy over of the aufs code
[08:48] <apw> so we'd never know to remove the old commit, does t
[08:48] <jjohansen> apw: ah, right
[08:48] <apw> that matter ?
[08:49] <jjohansen> apw: nope, except it shows up as a sauce patch to check status on
[08:50] <apw> jjohansen, ahh just mark it 'merged upstream already' and i'll try and figure out how to lose it :)
[08:50] <jjohansen> apw: will do :)
[09:58] <apw> 7467571 cpuidle: menu: fixed wrapping timers at 4.294 seconds
[10:12] <ppisati> lucid/fsl-imx51 have already 3 new commits but no start release since the last UBUNTU: Ubuntu-xxx closure
[10:13] <ppisati> shall i start a new release or do i keep committing on top of these?
[10:14] <apw> ppisati, generally we expect whoever notices the startnewrelease is missing to add it, thoguh it doesn't matter when it occurs, so feel free to add it
[10:14] <ppisati> apw: do i pop off the 3 commits and add a new release there or do i add it now?
[10:14] <apw> ppisati, it totally doesn't matter the order, so just stick it next
[10:14] <ppisati> ok
[14:31]  * ogasawara back in 20
[15:15] <sconklin> moin
[15:18] <lool> I've started an ubuntu-devel@ thread to discuss removal of the armel versatile flavor; I didn't Cc: ubuntu-kernel@, but will pass the result of the discussion in case it's favorable (nobody objects to the removal)
[15:19] <tgardner> lool, isn't the versatile flavor required for qemu ?
[15:23] <tgardner> lool, nm, just saw your email
[15:31] <ppisati> who decides which patch-es close a CVE? because i'm skeptical about CVE-2010-4251
[15:31] <ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
[15:31] <ppisati> since the mentioned patches are not enought to close the DDOS scenario
[15:31] <ppisati> and in fact, later, there's another patch related to it but the CVE doesn't mention it as necessary
[15:39] <apw> ppisati, i would say in large part the security team who read the background, but should you find an apparent discrepancy do feel free to refer it back to them, better to waste a bit of their time checking than to miss it
[15:39] <ppisati> apw: ok
[16:03] <stat> Anyone here able to let me know a bit about the PAE kernel?
[16:06] <stat> (I'm just going to talk anyways. Ignore me if I'm irrelevant)
[16:07] <stat> It seems that the "big memory" flag for the PAE kernel is disabled by default now. That means you only get a maximum of 3.5GB. If you only get an extra 512MB, why even bother with PAE?
[16:09] <apw> stat, big memory flage?  which one are you referring to ?
[16:12] <stat> I'm not entirely sure to be honest. From what I understand though, is that there is a flag that you must enable to get up to 64GB, and you need to recompile the current PAE kernel to get that flag enabled. I'll see if I can find the link where I was reading this.
[16:13] <stat> Ok, my mistake. It's called "High Memory Support (64GB)" not "Big Memory"
[16:13] <apw> stat, the PAE kernel doubled the number of bits available to store the location of physical page, which allows you to have more physical memory
[16:13] <stat> I know what PAE is for. I've just installed it, but now it seems 3.5GB instead of the 4GB that it should, which apparently is due to this flag.
[16:14] <stat> http://www.larmeir.com/2009/07/enabling-pae-on-a-32-bit-ubuntu-desktop-supporting-up-to-64-gb/
[16:14] <apw> stat, not necessarilly, physical layout of your ram may preclude seeing all 4GB
[16:14] <apw> can you pastebin yout e820 information from your dmesg
[16:15] <smb> I think the issue is that you get 3.5G per process because kernel has to be mapped there too. but with PAE you can address all mem so the virtual 4G could be spread over different physical memory
[16:15] <stat> http://pastebin.com/evE63C7P
[16:21] <apw> stat, ok and how do you know you only have 3.5gb, ie. where is that being expressed
[16:22] <stat> /proc/meminfo
[16:23] <apw> can you paste the overall number pls
[16:23] <stat> MemTotal:        3600576 kB
[16:29] <apw> stat, none of this makes any sense.  the point of the generic-pae kernel is that that it does set HIGHMEM64G
[16:29] <apw> can you paste the whole dmesg please from this boot
[16:30] <apw> that blog post is simply not applicable, as the kernle you have should have the flag you are aski
[16:30] <apw> asking to be on
[16:31] <stat> http://pastebin.com/zLLZZLim
[16:43] <apw> stat, how much memory did you have on the -generic kernel ?
[16:43] <apw> i am suspectin
[16:44] <apw> i am suspecting from the physical layout that it as much less than 3GB
[16:44] <stat> Ummm, I can't remember. I'm pretty sure it was 3GB. It was definitely more than 2.5 if that's what your suspecting.
[16:44] <smb> or probably asked the other way round: how much ram is there for real
[16:45] <stat> 4GB. 2 2GB sticks.
[16:45] <apw> i am suspecting its 2.6 as you have a full G over 4 GB
[16:45] <stat> That... might be.
[16:46] <apw> or do you ... argle stupid hex numbers
[16:46] <stat> Hang on, I'll reboot it without PAE and double-check.
[16:46] <apw> stat, ok
[16:46] <apw> cking, this is 512MB right?
[16:47] <apw> [    0.000000]  modified: 0000000100000000 - 0000000120000000 (usable)
[16:47]  * apw needs a sanity check
[16:47] <smb> apw, But for that (4G) it sounds reasonable to have 3.6G left after taking away kernel, page tables and other reservations, doesn't it?
[16:47] <apw> cking, and this is a smidge less than 3 right ?
[16:47] <apw> [    0.000000]  modified: 0000000000100000 - 00000000bffc6b00 (usable)
[16:48] <apw> so if i am reading this e820 right its is only advertising 3.5GB
[16:48] <cking> apw, you got access to the machine?
[16:49] <apw> cking, nope,but i do have the whole e820
[16:49] <apw> http://pastebin.com/evE63C7P
[16:50] <apw> but i think thats saying the bios is not advertising all the ram
[16:53] <stat> (Sorry that took so long. I suck at Grub2)
[16:53] <apw> stat, ok it looks like your bios is simply lying
[16:53] <stat> MemTotal:        3096612 kB <-- Non PAE kernel.
[16:54] <stat> Mmk. So my motherboard is just crazy then?
[16:54] <apw> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[16:54] <apw> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffc6b00 (usable)
[16:54] <apw> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
[16:54] <apw> are the 'usable' memory
[16:54] <apw> the first two are basically the whole first 3GB, then you have .5GB from 4GB physical
[16:54] <apw> so 3.5 in total
[16:55] <apw> sometimes there is a layout option in your bios to say where the ram will be placed
[16:55] <cking> 3583M useable IMHO
[16:55] <apw> but given the information the machine is offering the kernel is doing the right things
[16:55] <smb>  /me thinks there is also acpi tables placed 
[16:55] <apw> smb, but those would be shown cut from the ram ... but its still not even there
[16:56] <apw> i suspect the ram is actually being placed under the io space and masked
[16:56] <apw> which is stupid
[16:56] <cking> if e820 tables are wrong, that's all you get
[16:56] <apw> [    0.000000] e820 update range: 00000000d0000000 - 0000000100000000 (usable) ==> (reserved)
[16:56] <apw> i think that is the other bit being lost, i think that means its under the AGP apature
[16:57] <smb> hmm, maybe stolen graphics memory (on cheap cards)
[16:57] <apw> stat, what machine is this, we might find some help on if there is a bios wiggle
[16:58] <apw> cause you want different layouts for windows 32 bit and windows 64 bit ... so often there is a way
[16:58] <herton> apw: yes, a bios option like "Remap memory above 4GB"
[16:58] <apw> herton, right
[16:58] <stat> Uhh an hp machine of sorts. 
[16:59] <stat> Do you jsut want a device list?
[16:59] <apw> worth rooting about in the bios then, or searching for "remap memory above 4GB" and "machine name"
[16:59] <apw> on google
[16:59] <apw> heh ... really its the bios infor thats intreesting
[17:00] <stat> So do you want biosdecode info?
[17:01] <cking> I have code to dump out the e820 from user space directly using the e820 BIOS call
[17:01] <cking> http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=blob;f=e820/e820.c;h=fc4721eb80e50a7491dac4a059f746019f36d49e;hb=6cb227ece5ef420af9b341025b6a5e49e2d0e232
[17:01] <stat> Will that be more useful if I reboot back into PAE?
[17:01] <cking> but I expect it will give you identical results as the kernel gives
[17:04] <stat> cking: I am confused by your code. I tried that makefile that came with it, but it doesn't seem o have an actual target for building it.
[17:05] <stat> http://pastebin.com/X0fVehMJ <-- biosdecode if you're interested. I'm going to fiddle with my BIOS settings as you've suggested.
[17:05] <stat> Thanks everyone for your help so far. :)
[17:06] <ppisati> lp#799805
[17:06] <ppisati> please accept my nomination
[17:07] <tgardner> bug #799805
[17:07] <ubot2> Launchpad bug 799805 in linux-ti-omap4 "CVE-2010-4256" [Undecided,New] https://launchpad.net/bugs/799805
[17:07] <tgardner> ppisati, done
[17:07] <ppisati> 10x
[17:13] <stat> Well, I couldn't find anything in my BIOS about memory settings or remapping. I guess my BIOS is just lame. :P
[17:15] <sforshee> tgardner, one of the testers that had reported that the new rt2800 firmware made his rt3072 work is now saying it's causing problems (poor performance, machine won't shutdown/reboot). Is that justification to revert back to the old firmware, given that rt3072 didn't work at all previously?
[17:17] <apw> stat, did you see an option for the size of the AGP apature ?  and if so do you know how much video ram you have ?
[17:17] <tgardner> sforshee, yeah, I think so. I should just get the archive admon to reject it.
[17:17] <tgardner> admin*
[17:18] <stat> Uhh, I did see a setting for video memory. It was set to auto, but could also be between 32-256.
[17:19] <tgardner> sforshee, perhaps you should send an email to the SRU mailing list requesting rejection of the Lucid/Maverick packages that are currently in the unapproved queue
[17:20] <tgardner> sforshee, after that I'll just reset HEAD~2 on those 2 repos
[17:22] <stat> apw: It looks like it's 256MB.
[17:24] <sforshee> tgardner, what's the address for the SRU mailing list? I'm not familiar with it.
[17:24] <tgardner> sforshee, uh, I forget. bjf, sconklin ?
[17:26] <sconklin> ubuntu-kernel-sru@lists.ubuntu.com
[17:27] <stat> Ok, definitely 256MB according the memory range from lshw.
[19:00]  * tgardner --> lunch