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