[12:20] <defendguin> st3: is fstab still used or is there a better way to make sure that a partition is always mounted at a certain place?
[12:37] <TheMuso> c
[12:37] <TheMuso> ugh
[01:31] <st3> defendguin, well, i don't see any reason for not using fstab
[01:32] <defendguin> for some reason i kept thinking there were more high level ways i could manage that procedure
[01:33] <defendguin> i thought it could be handled by the gnome partition editor but i was mistaken
[01:40] <st3> don't choose high level when low level is human readable and just works :)
[01:41] <defendguin> st3: well i could add a new user manually but it is better not to because if i do he won't appear in the user picker in gdm and i can't manage his rights with any high level tool
[02:02] <st3> well, that's a gdm fault
[02:02] <defendguin> yeah
[02:03] <st3> i usually don't use X, so no idea :)
[02:03] <defendguin> you would think gdm and the gdm config tool would know better
[02:03] <defendguin> must stink to browse the web without x
[02:04] <defendguin> and your missing out on all the wobbly windows
[02:07] <st3> i didn't say i never use X, i usually don't
[02:07] <st3> well, my graphics card isn't as powerful as needed for displaying wobbly windows :)
[02:48] <holycow> hey guys
[02:48] <holycow> i'm looking at buying this device and puttinhg ubuntu on it:
[02:48] <holycow> http://www.dynamism.com/u8240/main.shtml
[02:49] <holycow> it has a Intel Pentium A110 800MHz
[02:49] <holycow> can anyone comment on kernel support for the cpu in any regard?
[02:49] <holycow> i'm willing to be a guinea pig if any kernel devs need that as a testing platform
[02:50] <holycow> the chipset is right tho so it should be allright
[02:54] <mjg59> Should be nothing special about the kernel at all
[02:54] <holycow> just reading more on that cpu as i've never heard about it, just looks like lower clocked pentium m cpus
[02:54] <holycow> so indeed
[03:00] <holycow> mjg59, thanks for the heads up, i'll do a writeup when i get the device on the installation process
[03:06] <defendguin> hey mjg59   this person found a work around for this bug but what needs to be done to fix this for gutsy?   https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86820
[03:57] <mjg59> defendguin: Should already be fixed in gutsy, I believe
[04:01] <defendguin> would it work to test that with a liveCD?
[04:02] <mjg59> Once they exist, yeah
[04:02] <defendguin> fair enough.  Thanks
[06:04] <pwnguin> strange question: what's the "right" way to bring a newer kernel into a feisty install?
[06:05] <crimsun> #ubuntu question.  I'll address it there.
[06:05] <pwnguin> i already asked it twice in there, but okay
[08:58] <koresko> I'm looking for a kernel that can see 1 GB of RAM on x86.  Generic sees about 750M.
[08:59] <koresko> Is it necessary to recompile the kernel? Hopefully not - 1 GB is the memory size of about half the laptops I saw when shopping for this one a few days ago.
[08:59] <Mithrandir> -generic sees 1.5GB for me on i386
[08:59] <crimsun> what Mithrandir said.
[09:00] <Mithrandir> at least the kernel from 7.04
[09:00] <Mithrandir> I am fairly sure at least 6.10 and 6.06 did the same.
[09:00] <crimsun> I just verified on 2.6.20-16-generic and 2.6.22-5-generic
[09:01] <koresko> Hm, I wonder if I have a bad BIOS setting or something.  Should I try mem=1024M on the commandline?
[09:01] <koresko> This is with the very latest Feisty kernel, running on a Turion64 laptop (Acer Aspire 5100).
[09:02] <Mithrandir> sounds weird.  Check that the machine sees all the memory in the bios?
[09:02] <koresko> Hm, good point.  I will have to reboot but will do that.
[09:04] <koresko> Hang on, rebooting... should be back in 5 minutes.
[09:11] <koresko> Ah, OK, I made a bonehead mistake!
[09:12] <koresko> The problem was that the BIOS had allocated 256 MB to the onboard video card.  I reduced it to 64 MB, and now the kernel sees 969 MB.
[09:12] <koresko> I was confused because when I upgraded my desktop box from 0.5 to 1.0 GB I needed to rebuild the kernel with the high memory option enabled, else it only saw about 750 MB of memory. 
[09:13] <koresko> That was under Gentoo.
[09:13] <Mithrandir> makes sense, then
[09:14] <koresko> I was afraid I was going to have to maintain my own kernel... the reason I'm running Ubuntu instead of Gentoo on this machine is mostly to do with the fact that it doesn't need as much effort to maintain it.
[09:16] <koresko> Anyway, thanks for confirming that it was *supposed* to work - else I'd probably have built my own kernel and still been stuck.
[09:17] <koresko> But now I realize that I don't get any benefit from having 3.5 GB of swap, since the virtual is limited to 4 GB, right?
[09:37] <cbx33> hi guys....
[09:37] <cbx33> I'm getting this error
[09:37] <cbx33> runaway loop modprobe binfmt-464c
[09:37] <cbx33> but not all the time
[09:37] <cbx33> just occasionally
[09:38] <cbx33> i saw on some threads it could be because I'm running 32 bit on 64 arch?
[09:38] <cbx33> but this machine has happily ran through dapper and edgy and normally feisty
[09:38] <cbx33> I sometimes get an error about pnpbios failing
[09:39] <cbx33> and that's usually the start of the problems
[09:39] <cbx33> anyone got any ideaS?
[09:52] <cbx33> hmmm
[09:52] <cbx33> could have been a dodgy ram chip
[11:03] <st3> koresko, no, it's not limited to 4G
[11:03] <koresko> st3: Really? Even on x86?  
[11:04] <st3> my kernel configuration:
[11:04] <st3> CONFIG_HIGHMEM4G=y
[11:04] <st3> # CONFIG_HIGHMEM64G is not set
[11:04] <st3> Mem:   1018228k total,   776696k used,   241532k free,        0k buffers
[11:04] <st3> Swap:  4882724k total,   273164k used,  4609560k free,   280560k cached
[11:05] <koresko> Hm, interesting point.  But 32 bits can only address 4G, right?
[11:05] <koresko> Or are you running a 64-bit kernel?
[11:05] <st3> i'm running a 32 bit kernel on an old 32 bit processor
[11:05] <crimsun> Pentium Pros and newer support PAE.
[11:06] <st3> right
[11:06] <koresko> I see.
[11:06] <koresko> Can you actually use more than 4G of virtual?
[11:06] <st3> (no need for PAE to have large swap, though)
[11:06] <st3> sure
[11:07] <koresko> I don't understand how it is addressed... Oh, maybe there is a 4G limit per process and the kernel swaps things around to make that work.
[11:07] <st3> no, that's entirely kernel managed of course
[11:08] <koresko> OK, but then what is the point of 64 bits?
[11:08] <mjg59> You can't have more than 4GB of virtual on x86, no
[11:09] <koresko> mjg59: Hm, so how is is that st3's machine is showing nearly 5G?
[11:09] <koresko> I am completely confused now.
[11:10] <st3> bahaha, do you want me to allocate them all?
[11:11] <koresko> st3: I was wondering what would happen if you tried that.
[11:11] <st3> wait
[11:11] <mjg59> PAE lets you have more than 4GB of physical space
[11:12] <mjg59> But per-process, you're still limited to 4GB
[11:12] <mjg59> (Well, 3 really)
[11:12] <koresko> Ah, I thought it might be something like that.
[11:13] <koresko> Well, the biggest program I run routinely uses about 900M, so I'm covered!
[11:19] <st3> ok, i'm almost done...
[11:20] <koresko> I'm going to bed.  Pretty late here.
[11:20] <st3> i'm allocating 4294967297 bytes (note the final 7)
[11:20] <koresko> Thanks for your help!
[11:20] <koresko> Hm, why that specific number of bytes?
[11:21] <st3> it's 2^32+1
[11:21] <koresko> Ah, I see!
[11:21] <koresko> So... any smoke?
[11:22] <st3> no
[11:22] <st3> it works ok
[11:22] <koresko> And you did this in one process?
[11:22] <st3> no, two ones
[11:22] <koresko> Ah, OK.
[11:22] <st3> (a process is limited to 2^30*3-1 or something like that)
[11:23] <koresko> That makes sense.
[11:23] <koresko> Some of the address space (1G) is reserved for the kernel, right?
[11:23] <koresko> There used to be a config option to control where the split went.  I think the default was 2G/2G kernel/user.
[11:24] <st3> iirc, the default was 1G/3G
[11:24] <mjg59> Yes, 1:3
[11:24] <mjg59> Some of the address space is used to refer to the physical address space
[11:24] <koresko> Hm, I vaguely remember that being the optional setting.
[11:24] <mjg59> Moving it lets you use more RAM without needing HIGHMEM
[11:26] <koresko> OK, I think I see.
[11:32] <koresko> Bedtime!  Thanks again for the info.  It's hard to find this even via Google (I tried).  The kernel docs themselves are a bit terse.
[11:56] <tepsipakki> hum, I merged ndiswrapper before checking out the version in kernel..
[01:20] <lifeless> what would cause a drive to flip-flop between sda and hda on boots ? (not every time, but its not consistent)
[01:39] <shawarma> Didn't there used to be a restricted-modules package that corresponds to the server images?
[02:00] <Cheka> hey folks... if i wanted to profile the linux networking stack how would i go about it ?
[02:17] <BenC> Cheka: netperf?
[02:18] <Cheka> netperf will tell me the throughput, but i'm more interested in the length of packet processing at each stage
[02:18] <Cheka> i.e. hardware interrupt, ip processing, tcp processing etc
[02:22] <BenC> that's more like normal kernel perf stuff
[02:22] <BenC> oprofile I think is what you want
[02:22] <BenC> I also don't know if you can get the granularity you're expecting, in regards to ip vs. tcp processing time
[02:23] <Cheka> i've used another profiler and it shows the amount of time spent in the kernel, but as you said not to the granularity that i want :(
[02:43] <zul> BenC: is there still a meeting today?
[02:43] <BenC> zul: yep
[02:44] <zul> okies
[02:44] <zul> whats on the agenda?
[02:45] <zul> er never mind
[02:57] <Mithrandir> hm, the 3ware 9550SX-12MI should be well supported, shouldn't it?
[02:57] <Mithrandir> and is a decent controller?
[03:00] <thom> Mithrandir: yeah, works pretty well for us
[03:00] <thom> just make sure you get BBUs! :-)
[03:01] <Mithrandir> battery backups, yeah.
[03:01] <Mithrandir>  do you have any experience with the Areca ARC-1130?
[03:01] <thom> (the 9550 disables write cache utterly and irrevocably with no BBU)
[03:01] <thom> we had a couple of arecas and they were dreadful
[03:02] <Mithrandir> ok, good to know.
[03:02] <thom> but that was on oldish RHEL
[03:02] <Mithrandir> the 3wares are cheaper, so it's not a hard choice to make.
[03:02] <Mithrandir> by about the price of the battery
[03:03] <thom> heh
[03:16] <kylem> Mithrandir, all 3ware controllers are pretty good.
[03:16] <kylem> if you can live with their custom ODF.
[03:17] <Mithrandir> I'm pondering using them as a JBOD and use the swraid layer
[03:31] <maswan> Mithrandir: we had rather bad experiences with areca too, 3wares are stable for us.
[03:31] <kylem> Mithrandir, are you sure they don't use their own ODF with JBOD too?
[03:31] <Mithrandir> kylem: no, but I'd think it less likely
[03:31] <kylem> hmm.
[03:31] <Mithrandir> maswan: ok, thanks.  That settles it.
[03:32] <kylem> Mithrandir, i don't trust areca... their driver people are... perhaps we should talk in private. ;-)
[03:32] <Mithrandir> that bad?
[03:33] <kylem> no comment.
[03:33] <maswan> I _think_ I've moved between !3ware and 3ware for md raid5 devices
[03:33] <maswan> yeah, started out a raidset on sata_sil, then changed to 3ware for stability
[03:34] <kylem> yeah, 3ware are top notch in the prosumer. raid controller business.
[03:34] <Mithrandir> ok, coolie
[03:58] <st3> Cheka, iperf?
[03:59] <Cheka> does that give me detailed statics of the network code or just the network throughput?
[04:02] <st3> "Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss."
[04:04] <Cheka> yeh, that's what i thought, i'm more interested in how long the the packet is in each layer, say the ip processing (i.e. the ip_output.c functions or whatever)
[04:23] <zul> whoops...I brought down the network at work
[08:16] <fdoving> did anything special change from 2.6.20 to 2.6.22 that would make my trackpoint die? (latitude d620)
[10:57] <keturn> fdoving: maybe it's the season for trackpoint death?  the thing on my inspirion 4000 died, but booting older software doesn't bring it back, so I'm assuming it was hardware gremlins.
[11:01] <fdoving> keturn: well, this machine is pretty new. and it works with the feisty kernels :)
[12:08] <victory747> Hi, I just upgraded feisty to 2.6.20-16.  Previously (2.6.20-15 and earlier) my IDE hard drive always showed up as /dev/sda.  Now, suddenly with this new kernel it shows up as /dev/hda.  Is this a known problem?