[12:53] <valkyr> hi
[12:53] <valkyr> Correct me if Im wrong .. but 32bit Linux systems are also limited to under 4gb of ram right?  To increase limit one has to either upgrade to a 64bit version or update the kernel with a PAE aware kernel.  Would you all agree?
[12:54] <domas> right
[12:54] <valkyr> thanks
[12:54] <domas> (PAE kernel doesn't allow you to address all memory in application though )
[12:56] <valkyr> in which case what do i do?
[12:56] <valkyr> there's no other choice here but to use PAE or just upgrade right
[12:57] <domas> you use 64 bits
[12:57] <domas> ;-)
[12:58] <valkyr> heh alright
[12:58] <domas> windows have AWE, which allows applications to address larger areas, but I have no idea how it works ;-)
[12:58] <valkyr> thanks :))
[12:58] <valkyr> well we won't have no use for windows here
[12:58] <domas> there's specific API 
[12:58] <valkyr> domas: going back to what you said
[12:58] <valkyr> in a single process is what oyu mean right?
[12:58] <domas> yes
[12:59] <valkyr> ok
[12:59] <domas> (I'm working with multiple software pieces that loves memory ;-)
[12:59] <valkyr> s0 same  limitation per process as you have system-wide with a non-PAE kernel?
[13:00] <domas> actually, with non-PAE kernel you can allocate ~100MB more of memory ;-)
[13:00] <domas> or maybe not
[13:00] <domas> 32-bit linux gives you about 2.7G per app
[13:00] <domas> and maximum contiguous allocation can be less (close to 2G)
[13:00] <valkyr> they say that PAE slows the system down somewhat, but I've never heard any XP user complain about it. 
[13:00] <domas> if PAE would slow the system down, ubuntu-server kernels (all with PAE) would not be that usable, right?
[13:01] <domas> maybe using memory via AWE is slower than directly, I don't know ;-)
[13:01] <valkyr> ok you're not a kernel dev?
[13:01] <valkyr> :P
[13:01] <domas> I do some development for myself sometimes ;-) 
[13:01] <valkyr> XP switched to a PAE kernel with SP2. They still limit the memory in order to not confuse drivers. 
[13:01] <valkyr> so I don't know how big the difference in performance can be in practice.
[13:02] <domas> I doubt there is any
[13:03] <valkyr> ok
[13:04] <domas> 1%
[13:04] <domas> ;-)
[13:04] <valkyr> 1%?
[13:04] <valkyr> yu checked?
[13:05]  * domas points at http://people.redhat.com/nmurray/RHEL-2.1-VM-whitepaper.pdf
[13:05] <domas> "The performance impact is highly workload dependent, but on a fairly typical ker- 
[13:05] <domas> nel compile, the PAE penalty works out to be around a 1% performance hit on Red 
[13:05] <domas> Hat?s test boxes. Testing withhits ranging from 0% to 10%"
[13:05] <domas> damn pdf copypaste
[13:05] <domas> mangled the text ;-)
[13:05] <valkyr> ah
[13:05] <valkyr> could get a second opinion on this from one of the devs too 
[13:05] <valkyr> thanks for the link
[13:07] <domas> I prefer x86_64 ;-)
[13:09] <valkyr> so using memory via AWE is slower?
[13:18] <valkyr> domas so with non-PAE you can allocate more than 1--mb
[13:18] <valkyr> 100mb
[13:18] <valkyr> cant see it in the link though
[13:19] <domas> noooo
[13:19] <domas> with PAE kernel you can allocate ~2.7G
[13:19] <domas> with non-PAE it is closer to 2.8G
[13:19] <domas> ;-)
[13:19] <valkyr> /<domas> actually, with non-PAE kernel you can allocate ~100MB more of memory ;-)
[13:19] <domas> 'more'
[13:19] <valkyr> ohh
[13:20] <valkyr> so with a non-PAE kernel you dont have that many limitations to a PAE kernel?
[13:20] <domas> well, it is just small difference
[13:21] <valkyr> but per process, they're both limited equally
[13:21] <valkyr> non-pae and PAE right?
[13:21] <domas> nono, I'm talking exactly about per-process
[13:21] <domas> PAE kernel can allocate much more overall
[13:21] <valkyr> i dont gain anything more from using a non-PAE here do i 
[13:21] <domas> nope
[13:22] <valkyr> ok
[14:15] <valkyr> thx domas
[15:31] <Kano> hi, i just looked at your linux-firmware package, a few files could be added
[15:32] <Kano> you have got only 2 of 3 possible firmware files for ar9170, the correct one for AVM Wlan N sticks is missing
[15:33] <Kano> http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/LICENSE
[15:33] <Kano> http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw
[15:33] <Kano> also for your other non-free package
[15:34] <Kano> there you could add xc3028-v27.fw as dvb firmware
[15:36] <Kano> and dont say there is no bug...
[15:36] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/278656
[15:36] <ubot3> Malone bug 278656 in linux-firmware "Missing firmware for em28xx DVB-T digital tuner" [Wishlist,Triaged] 
[15:39] <Kano> http://linuxwireless.org/en/users/Drivers/ar9170
[15:39] <Kano> the one stage part
[15:41] <tormod> Kano: please add your information to the report if is relevant
[15:41] <Kano> the 2nd bug is definitely clear ot not
[15:41] <Kano> will add the url to the files to another bug
[15:44] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/386403
[15:44] <ubot3> Malone bug 386403 in linux-firmware "ar9170 wireless firmware needed in Karmic" [Undecided,Fix released] 
[18:47] <setuid> How do I ensure that the same initramfs/initrd that is used to successfully boot a 2.6.28-5 kernel on Jaunty, is used to generate a working 2.6.28-15 version? 
[18:48] <setuid> because 2.6.28-15 is unbootable
[19:32] <setuid> What is it that governs what modules/etc. are included in an initramfs? 
[19:32] <setuid> Because I can't seem to generate one for 2.6.28-15-generic that models the same modules/support that is included in the default 2.6.28-5 that I'm using right now. 
[19:32] <jk-> hey setuid
[19:32] <setuid> hola
[19:33] <jk-> setuid: /etc/initramfs-tools/modules ?
[19:34] <setuid> Ok, so when I run: update-initramfs.distrib -c -k 2.6.28-15-generic
[19:35] <setuid> It should generate a working one... but doesn't
[19:35] <setuid> I get a hard-lock, when it tries to mount the root volume, using a UUID (the same construct that works with 2.6.28-5) 
[19:46] <setuid> So any ideas? 
[22:15] <tormod> why are there no daily builds in the mainline kernel-ppa?