[03:27] <eegore> I installed 4 gigs of ram in this box and the os only sees 3
[03:27] <eegore> running dapper
[03:27] <eegore> kernel 2.6.16-27-k7
[03:28] <eegore> kernel 2.6.15-27-k7
[03:28] <BenC> egore: There's some overhead in highmem
[03:28] <BenC> eegore: ^^
[03:29] <eegore> paging?
[03:29] <kylem> i suspect it's because your bios reserves space for mmio.
[03:30] <eegore> ASUS A*n-E
[03:30] <eegore> A8N-E
[03:31] <eegore> 25% overhead?
[03:31] <kylem> well, that really depends how you look at it.
[03:31] <kylem> when you have video cards with 512M addressable...
[03:34] <eegore> so what you are saying is the bios is caching the data in memory as a i gig cache memory
[03:34] <eegore> 1*
[03:34] <mjg59> You have 4GB of address space
[03:34] <mjg59> And some of that's being kept by the BIOS for PCI devices and the like
[03:34] <mjg59> Check whether your BIOS says anything about memory holes
[03:34] <mjg59> If not, you lose
[03:35] <ajmitch> one case where it can be a good idea to run amd64
[03:35] <mjg59> amd64 actually has the same problem
[03:35] <mjg59> Well, with some chipsets
[03:35] <kylem> mmm double address cycle.
[03:35] <eegore> running a 64 bit cpu on 32 bit dapper
[03:35] <ajmitch> it appears to be fine with my system, at least
[03:35] <eegore> not enough app support for 64 bit
[03:36] <mjg59> eegore: It's not an OS issue. Windows will behave identically.
[03:36] <mjg59> I'm afraid it's something you'll have to discuss with your hardware vendor.
[03:37] <eegore> so the system itself is using a gig to cache the I/O?
[03:37] <mjg59> No
[03:37] <kylem> it doesn't cache it.
[03:37] <kylem> it doesn't address it.
[03:37] <mjg59> The system can access 4GB of address space
[03:37] <mjg59> Most of that is RAM
[03:37] <kylem> you could remove one of the dimms, and it would make no difference.
[03:37] <mjg59> But it has to put PCI cards and other mmio devices somewhere
[03:38] <mjg59> The displaced RAM isn't used at all. It's idle.
[03:40] <eegore> so I would need a bios patch if it is availble to access it fully with more options in the setup
[03:40] <mjg59> There may already be one
[03:41] <mjg59> But it'll be called something like "memory hole"
[03:41] <mjg59> Otherwise, yes, you'd need some sort of bios support
[03:41] <eegore> that is setable?
[03:43] <eegore> [17179569.184000]  3200MB HIGHMEM available
[03:43] <eegore> [17179569.184000]  896MB LOWMEM available.
[03:43] <mjg59> Erm.
[03:43] <mjg59> That would seem to suggest that you have 4GB.
[03:44] <eegore> what is the 1 gig being reserved for 
[03:44] <derekS> this probably isn't the right forum for this question, but what is the difference between "HIGHMEM" and "LOWMEM"?
[03:44] <derekS> like why does it have 2 types
[03:45] <derekS> (my comp also has 896MB of lowmem reserved)
[03:45] <mjg59> lowmem isn't reserved
[03:45] <mjg59> The split is because you only have 4GB of address space
[03:46] <mjg59> And that has to be split between physical addresses and process address space
[03:46] <derekS> mjg59: i only have 2 gigs
[03:46] <mjg59> You have 4GB of address space
[03:46] <mjg59> Because you have a 32 bit system
[03:48] <mjg59> http://linux-mm.org/HighMemory
[03:52] <derekS> ahh
[03:52] <derekS> thanks
[03:52] <derekS> reading
[03:53] <derekS> mjg59: but you said that this issue is also present on 64bit os's?
[03:53] <mjg59> The highmem split isn't
[03:53] <mjg59> But that's got nothing to do with eegore's problem
[03:54] <derekS> ohh :)
[03:54] <mjg59> It's normal to have a split between lowmem and highmem on 32 bit systems
[03:54] <derekS> so i am better off wiping the 32bit os, and putting on the 64bit version?
[03:54] <mjg59> If you've only got 2GB, not really
[03:55] <derekS> ok
[03:55] <mjg59> But PCI needs to live below 4GB
[03:55] <mjg59> So unless the system supports remapping the memory above 4GB in order to leave space for PCI, you'll still have the problem even on a 64 bit OS
[03:56] <mjg59> Especially since older Opterons can't remap memory
[03:56] <derekS> i have an older opteron (i think)
[03:56] <mjg59> But you've only got 2GB
[03:56] <mjg59> So it's fine
[03:56] <derekS> yeah, i am not worried
[03:57] <derekS> i don't need more
[03:57] <derekS> i was just interested
[03:57] <ajmitch> mine appears to give me the 4GB, so I'm happy with it
[03:57] <derekS> thanks for explaining
[04:07] <eegore> mjg59: so a bios upgrade may push he pci past the 4gig barrier?
[04:08] <mjg59> Possibly
[04:08] <mjg59> But you'd then need to use the server kernel to access it
[04:08] <mjg59> (Or the 64 bit version of Ubuntu)
[04:08] <eegore> eeeewwwww
[04:09] <eegore> The server kernel has to be comiled right?
[04:09] <eegore> compiled
[04:09] <mjg59> 32-bit kernels in "Not able to access memory about 4GB" shocker
[04:09] <mjg59> No
[04:09] <mjg59> linux-image-server
[04:10] <eegore> will all the other hardware detection work or is that different in the server kernel
[04:10] <mjg59> It should be fine
[04:15] <eegore> I may have to bite the bullet and load up a 64 bit os
[04:35] <derekS> hey, i am about to file a bug, i just want to make sure it *is* a kernel bug, and not an X bug (has to do with my mouse). I initially put it in udev, but fabbione said it wasn't there. can someone take a look at 73425 *just* to make sure it is a kernel bug?
[04:49] <eegore> later all
[02:57] <zul> morning
[03:05] <BenC> hey zul
[03:06] <zul> hey BenC how is it going?
[03:06] <BenC> not too bad
[03:06] <zul> good to hear
[03:06] <zul> redhat is suppose to rlease their 2.6.19-rc1 xen kernel tomorrow
[03:07] <zul> but other than that i have been better
[03:07] <BenC> 2.6.19-rc1, as in based on the pre-release of a released kernel?
[03:07] <BenC> or xen-rc1?
[03:08] <zul> pre-released of a released kernel
[03:08] <zul> yeah i know...:)
[03:11] <zul> good thing the bossman at work is not going to be here tomorrow ;)
[03:43] <\sh> datten:
[03:43] <\sh> grmp
[03:44] <\sh> BenC: in 2.6.20: are we including the PWC driver for logitech usb cams?
[03:44] <BenC> \sh: Yeah, it's one of the modules I still need to forward port
[03:45] <\sh> BenC: cool...
[08:13] <dade`> BenC: on 2.6.20 the FN key of macbooks does not work anymore
[08:14] <fabbione> dade`: confirmed here too
[08:14] <dade`> fabbione: do you have a macbook ?
[08:14] <fabbione> dade`: PB G4
[08:14] <fabbione> same keyboard
[08:14] <dade`> uh ok
[08:15] <fabbione> BenC: ^^ do you want a bug for this?
[08:15] <fabbione> BenC: or should I unleash your wife with the G4 against you? :P
[08:15] <BenC> hehe
[08:15] <BenC> let me check the config options
[08:17] <BenC> debian/config/powerpc/config:CONFIG_USB_HID_POWERBOOK=y
[08:17] <BenC> same for i386
[08:17] <BenC> and amd64
[08:17] <fabbione> BenC: i think it's a code regression
[08:17] <fabbione> it's the only key that's gone foobar
[08:18] <fabbione> from .19
[08:18] <BenC> anyone willing to bisect it?
[08:18] <fabbione> wound't be easier to identify first whatchanged?
[08:18] <BenC> the change was a switch to a generic hid layer
[08:18] <fabbione> actually
[08:18] <fabbione> benh
[08:18] <fabbione> i am sure he knows
[08:18] <BenC> I don't think it's anything ppc specific
[08:19] <fabbione> yeah but i am pretty sure he is hiding the body of who did the change as we speak
[08:45] <jbailey> BenC: What do you need bisected on pc?
[08:45] <jbailey> ppc?
[08:45] <BenC> pc or ppc, just has to be a macbook/powerbook
[08:45] <jbailey> Oh, nope.
[08:46] <BenC> to check the FN key
[08:46] <jbailey> I was vaguely hoping it was my ppc64 booting bug. =)
[08:46] <BenC> you have a ppc64 booting bug on feisty-2.6.20?
[08:48] <jbailey> BenC: Yup, submitted to you last night with a photo of the oops. =)
[08:49] <jbailey> s/you/launchpad/
[08:49] <jbailey> 'sokay, I'm sending this box to Kyle shortly to play with.  I suspect that all the bugs will suddenly melt away. =)
[08:52] <BenC> jbailey: deja vu...sata_svw seems to never get any love till you find out it's broken, and I fix it :/
[08:53] <BenC> I wonder if it's the same damn bug I fixed in edgy
[08:54] <jbailey> BenC: I'm glad I'm an early adopter, then. =)
[08:55] <BenC> I'm betting it is
[09:02] <BenC> jbailey: Can you test a kernel with this little patch to see if it works?
[09:04] <jbailey> BenC: I'm not near the machine, but I can tonight.
[09:05] <BenC> jbailey: I'll build it, put it on rookery and send you an email
[09:05] <jbailey> Thanks, much appreciated!
[09:26] <BenC> hello mdz_sort_of_online
[09:33] <fabbione> mdz: do you want a shell from where you can irc without timeout all the time?
[09:51] <BenC> jbailey: http://people.ubuntu.com/~bcollins/kernels/
[10:17] <jbailey> BenC: Hm,  should I be brave and reboot the box remotely? =)
[10:17] <jbailey> BenC: If it comes up, it worked, it not, I'll reset it when I get home in a couple hours. =)
[10:19] <zul> jbailey: hey how is the new place?
[10:19] <jbailey> zul: Wonderful!  It's so nice to be moved.
[10:24] <zul> good to hear
[10:46] <jbailey> BenC: Can't ssh to it, I think it didn't work.  Ah well. =)
[10:50] <BenC> jbailey: Hopefully it's something else...I'm sure this patch fixed a bug
[10:50] <jbailey> =)
[10:52] <jbailey> Oh!
[10:52] <jbailey> Linux starshine 2.6.20-3-powerpc64-smp #2 SMP Tue Dec 19 20:27:47 UTC 2006 ppc64 GNU/Linux
[10:52] <jbailey> The bloody must've decided it was time to fsck.
[10:53] <kylem> lol.
[10:55] <jbailey> BenC: ^^
[10:55] <jbailey> Was that the same thing as last time? =)
[10:55] <BenC> sweet
[10:55] <BenC> yep
[10:56] <jbailey> I'm surprised other's aren't tripping on it.
[10:58] <jbailey>   CHANGELOG: Do not edit directly. Autogenerated at release.
[10:58] <jbailey>   CHANGELOG: Use the printchanges target to see the curent changes.
[10:58] <jbailey>   CHANGELOG: Use the insertchanges target to create the final log.
[10:58] <jbailey> *lol*
[10:58] <jbailey> When you *know* something was a one-off build ;)