[01:12] Where's the LPIA LUM tree for hardy? [01:21] Ah, got it [02:41] hi, could somebody add aufs to 2.6.29 branch? [02:41] would be nice to have as squashfs is integrated to build a live image with it [02:48] Hi, i am new to Linux module programming and my first hello_world.ko under Ubuntu 8.04 didn't seem to work. Following the guide at http://ubuntuforums.org/showthread.php?t=800251, the compilation seems fine but no output from console nor /var/log/messages. Any one could help me? thanks:) [02:51] Kano: If you read Tim's email from the kernel team list, you will note that some ubuntu drivers have been disabled, aufs is likely one of those. I suggest if you want it ASAP, you help in getting it fixed/updated. [02:53] i did not read a mail,but i see the git log [03:06] TheMuso: the git repo Tim's mail pointed to has 2.6.29-rc8. does that mean karmic = 2.6.29? or is 29/30 undecided at the moment? [03:06] Kano: I think the final version is undecided [03:07] * maco assumes that was at me [03:07] ok [03:07] Kano: oops sorry [03:07] maco: yeah misread [03:11] last sentence in "Kernel Version" at http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html [03:12] bye [08:53] smb_tp, i switch here for a question about git clone [08:54] sure [08:54] how can i git clone all the branches of a remote git tree [08:54] not just one master branch [08:55] You normally do somewhat [08:55] if you do a "git branch -a" you would see them [08:55] you then can create one with "git branch origin/" [08:56] ok [08:56] then git pull origin name [08:56] right [08:56] then "git checkout " or probably "git checkout -b origin/" [08:56] which would save you one step [08:57] you don't need to pull. When you clone you get all the objects [08:57] It just does not create the local branchnames [08:57] ok, i fully understand [08:58] ikepanhc, you may try on you side [08:59] oh, got it [09:00] i will try it on my side. actually, this problem frustrate me a lot [09:13] smb_tp, actually this is a little bit difficult to understand, we assume _clone_ means copy everything [09:14] and git branch, git checkout should be ok default [09:16] well, I think of it as git clone makes a complete copy of the repository objects, plus it conveniently checks out the origin/master as master [09:16] and makes a local branch for it as well [09:16] apw, Can you describe that better? [09:18] thats pretty accurate [09:18] git just does not do create a local branch from origin/, only master [09:19] AFAIK, yes [09:19] ok, i see [09:20] the master thing is a convienience [09:20] you can and do checkout other branches from a remote [09:21] clone checks out the HEAD branch from the remote, which is normally master [09:21] and it does that because a repo with no branch checked out is confusing [09:22] iirc, you run into that situation when you create an empty remote and then push things over. before you checkout anything it looks just empty [09:25] right [09:25] git clone is equivalent to [09:25] mkdir foo; cd foo; git init; git remote add origin ; git fetch origin; git checkout -b master origin [09:47] brain-boost-needed: I'm *sure* we recently had a bug where there are random delays during boot for which I found/saw a new upstream patch that reworked the RCU 'idle' scheduling during boot. Trying to find it now I've drawn a blank. Does it ring a bell with anyone else? [09:49] Ha, thank-you Mr Invisible Man, that worked... found it... bug #254668 [09:49] Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] https://launchpad.net/bugs/254668 [09:50] IntuitiveNipple, yeah that was one of them [09:51] I've got another bug that might be the same one, but it's been trailing on an Nvidia MCP67 issue [09:51] I see you found bug 272247 as well [09:51] Malone bug 272247 in linux "System freezes during boot, unless I hold a key down" [High,Fix released] https://launchpad.net/bugs/272247 [09:52] Yes, I'm seeing quite a few issues with MCP67 so thought it might be good to disambiguate them [09:52] There's some sign of AHCI data-loss with the MCP67 but only on Ubuntu... haven't found any noise upstream along the same lines so far. [09:53] Yes, there seemed to be a few on HP / amd machines. But also a few between the lines with intel cpu's [09:53] there is also bug 217849 [09:53] Malone bug 217849 in linux "Hardy 64-bit beta and nightly alternate installation stalls" [Critical,Incomplete] https://launchpad.net/bugs/217849 [09:53] which is slightly different [09:53] For some it helped only to go for clocksource=jiffies [09:54] Other needed to get around acpi irq routing [09:54] Yeah, I remember that one. I was wondering out loud if it had to do with the bounce-buffering [09:55] right. i remember now [09:55] The upstream commentary on the RCU scheduled idle during boot patch looks like it covers a lot of bug reports [09:55] Generally it seemed like loosing irqs or going into a sleep state without a correct trigger to wake [09:55] do you know if anyone here has tried backporting the RCU patch? If not, I'll give it a go? [09:55] Not to my knowledge [09:55] OK. I'll see what it takes [09:56] Ok, cool [09:56] Seeing as it could wipe a fair few niggles out [09:56] Fixing that would sure make a lot difference [10:01] It'll need some munging to make it apply... I'll do some poking === mdz_ is now known as mdz [11:02] Hmmm... this RCU patch. One of the conflicts is a file that doesn't yet exist in Jaunty but does in linux-2.6, and is amended It adds an inline function declaration. What would be the procedure for including its contents? [11:06] IntuitiveNipple, if the change introducing the file/inline is just a moving around of files mostly, then probably pull the patch that created it [11:07] Otherwise we probably just want the inline... [11:07] Unfortunately, it's based ona major rework of the entire RCU code... since Jaunty RCU moved to a tree-based system. I'm carrying on but not sure the back-port will be possible in the end [11:09] I'll let that one stand for now and sort out all the content-conflicts... if those can be done, then I'll have to revisit this [11:09] Ok, thanks. === `6og is now known as Kamping_Kaiser [12:01] maco, hey ... how is your asus acpi driver going [12:01] apw: backburnered. trying not to fail my compilers class. [12:01] heheh, always the way [12:01] always a good plan [12:02] which...er...right...i should probably get back to yacc [12:02] did that use to work on intrepid [12:02] no, those keys never worked [12:02] ok cool. so its not a regression at least [12:02] well i never ran intrepid on here. but they didnt work in hardy [12:04] <_ruben> probably offtopic .. but does anyone have any clue wrt to the WARNINGS shown here: http://paste.ubuntu.com/132986/ .. those symbols are part of another (same 3rd party) kmod [12:06] _ruben: do you have that kernel installed (I assume you do), e.g., lib/modules/2.6.27-11 ? [12:07] <_ruben> rtg: yes [12:07] <_ruben> (its within a pbuilder chroot btw) [12:08] <_ruben> i think on an earlier attempt i "fixed" it taking the Module.symvers file from the scst.ko along with its header files, but DKMS doesnt give me such a file (at first sight atleast) [12:09] _ruben: right, these are benign warning because no modules.dep exists for these symbols at MODPOST time (Ithink() [12:10] <_ruben> rtg: i get similar errors when i modprobe iscsi-scst.ko [12:10] _ruben: so, you're saying its not working and the warnings are not benign? [12:12] <_ruben> http://paste.ubuntu.com/132991/ .. thats when i modprobe them [12:12] _ruben: you must be missing one of the files in the link or compile. find out where scst_single_seq_open exists and make sure its getting compiled. [12:12] <_ruben> toghether with: [12:12] <_ruben> # modprobe iscsi-scst [12:12] <_ruben> FATAL: Error inserting iscsi_scst (/lib/modules/2.6.27-11-server/updates/dkms/iscsi-scst.ko): Unknown symbol in module, or unknown parameter (see dmesg) [12:12] <_ruben> rtg: its within scst.ko iirc .. let me double-check [12:17] Has "scst" been built and installed against the same kernel version? It looks as if its symbols aren't present. [12:17] <_ruben> rtg: strings shows scst_single_seq_open is present within scst.ko .. is there some tool to show whats being exported from a certain kmod [12:17] <_ruben> IntuitiveNipple: yes .. both built using dkms against 2.6.27-11-server [12:18] _ruben: make sure its in an EXPORT_SYMBOL macro in the source [12:18] <_ruben> rtg: let me check that [12:19] <_ruben> src/scst_proc.c:EXPORT_SYMBOL(scst_single_seq_open); [12:20] _ruben: hmm, can you build it by hand using " make -C /lib/modules/2.6.27-11/build M=`pwd` " ? [12:20] Does this show them? grep -in scst_register /lib/modules/2.6.27-1/modules.symbols [12:20] oops typo! [12:20] Does this show them? grep -in scst_register /lib/modules/2.6.27-11/modules.symbols [12:21] IntuitiveNipple: I think that symbol is part of the module that he's building. [12:21] <_ruben> # grep -in scst_register /lib/modules/2.6.27-11-server/modules.symbols [12:21] <_ruben> 621:alias symbol:__scst_register_virtual_dev_driver scst [12:21] <_ruben> 1423:alias symbol:__scst_register_target_template scst [12:21] <_ruben> 2298:alias symbol:__scst_register_dev_driver scst [12:21] <_ruben> 2673:alias symbol:scst_register_session scst [12:21] <_ruben> 3297:alias symbol:scst_register scst [12:21] <_ruben> 4694:alias symbol:scst_register_virtual_device scst [12:21] No, it's part of scst not isci-scst [12:22] IntuitiveNipple: ah, missed that [12:23] OK, so, the build process isn't 'seeing' them via DKMS [12:23] <_ruben> IntuitiveNipple: sounds about right, yeah [12:23] <_ruben> it isnt dkms specific though, m-a has the same [12:26] Is there a custom Makefile for that module? [12:28] <_ruben> just got a reply from upstream: [12:28] <_ruben> 1. If you don't have SCST core's Module.symvers, you will see complains [12:28] <_ruben> on the MODPOST build stage. As you can notice, the Module.symvers is [12:28] <_ruben> installed during SCST core installation in /usr/local/include/scst [12:28] <_ruben> together with other SCST headers. [12:28] <_ruben> 2. Since iscsi-scst.ko depends on scst.ko, you must have the correct [12:28] <_ruben> version of scst.ko installed, when you trying to load iscsi-scst.ko. [12:28] <_ruben> "Correct" means built with the same SCST headers for the same kernel as [12:28] <_ruben> iscsi-scst.ko. [12:28] ha! [12:28] that would definitely explain it [12:28] <_ruben> so i gotta convince DKMS to take care of the symvers file i guess? [12:28] we knew the what but not the why [12:32] In src/scst/Makefile the install: target does "install -m 644 Modules.symvers $(INSTALL_DIR_H)" [12:32] <_ruben> correct, but dkms doesnt call make install i think? [12:33] apw: are you done with checkbox then? [12:34] checkbox is done as far as i can tell [12:34] i am waiting for the publisher to download it [12:34] apw: ah, that reminds me to check on our new ABI kernel [12:35] kewl, someone has already NEWed it [12:36] apw: when you build checkbox on your PPA, do you only get i386 ? [12:36] smb_tp: Good news. The RCU back-port looks to be good. The Tree RCU fragments aren't required since there is no Tree RCU until 2.6.29. [12:37] Sounds cool. If you drop the patch to the mailing list I'll see to get a kernel build [12:38] <_ruben> hmm .. perhaps a POST_BUILD= entry in DKMS can be used [12:38] rtg yeah, its all 'all' code, all python [12:39] smb_tp: Will do. I'm doing a build and install test on it first [12:39] apw: hmm, I'm just not used to seeing packages only appearing in one ARCH [12:39] IntuitiveNipple, Ok [12:39] yeah when its an all it does that [12:40] its that mad all == any one and any means all of them [12:40] doesn't seem ortogonal [12:40] orthogonal, even [12:47] its completely mind bending [12:47] in better news the script is in the package and seems to work [12:48] apw: good, that was really my only goal. [12:49] indeed, just running a real life test [12:49] rtg: "archictecture: all" packages only get built on i386, but are published in all architectures. [12:50] soren: just one of those funny inconsistencies in the archive [12:50] Ah, apw already pointed that out. [12:50] really it should have been all -> indep and any -> all [13:11] 16-core Itanium 2 system for £999 ... is it worth it as a build server? [13:13] 16 cores for 1K? [13:13] that sounds like it's off the back of a lorry [13:13] and not in a good way :-P [13:14] IntuitiveNipple: and what do you do with ia64 anyway? [13:14] elmo: Yeah, I was wondering the same thing myself! I'd just looked at another for £24.5k :) [13:14] rtg: To play with, of course! [13:14] expensive toy [13:15] itanium's are only 2 cores per socket, right now, AFAICR? [13:15] all the best toys are :) [13:15] if so, that's an 8-socket machine. which would make it *very* expensive to run, and likely *very* noisy too [13:15] 2 cores, 2 hyperthreads [13:15] elmo: It'd be banished to the garage like the PowerEdges [13:16] ah, well, if you have somewhere for it. I dunno, my experience with Itanium's is with older machines [13:16] but unlessimproved vastly, the only thing going for that box would be the 16-wayness. because core to core, a decent Xeon or even Opteron will outclass an Itanium like nobody's business [13:16] I was looking for one with VT support [13:17] s/unlessimproved/unless they've improved/ (woo, typing on a loaded box) [13:19] Yeah... same here... It'd make a great buildd for the kernels [13:19] But, that price... and 'cash only' makes me think... oh well *sigh* too good to be true [14:13] <_ruben> grr .. gotta love being pulled into a meeting unexpectedly .. back to my scst/dkms endeavour :p [14:13] is there a make rule to easily build/install the /boot/vmcoreinfo* files from a quick-build ? [14:15] rtg: around? [14:15] maco: in 20 mins or so. on conf call right now [14:16] ok [14:16] saw you k-t list email [14:16] your* [14:16] ah ok then nvm [14:24] ok, got it: KVER=2.6.28.8; sudo makedumpfile -g /boot/vmcoreinfo-$KVER -x ../builds/vmlinux [14:41] IntuitiveNipple: still haven't seen the bug with an ext3 filesystem.. will leave it running overnight today [14:42] IntuitiveNipple: if you remember, the MCP67/achi bug [14:42] which bug is that? I loose track :) [14:42] oh, yeah.... I'm actually looking at some patches for that issue atm [14:46] IntuitiveNipple: cool [14:47] IntuitiveNipple: had dpkg running on Intrepid userland on ext with 2.6.28 from the mainline archive for an hour, nothing happened [14:47] IntuitiveNipple: ext3 that is [14:48] IntuitiveNipple: Jaunty userland, 2.6.28-10 and ex4: 5 minutes dpkg and boom [14:49] IntuitiveNipple: if you want some info from the system after it's happened I can probably recreate it pretty quickly [14:53] Could it really be an ext4 issue? I can't think how the file-system could cause that in the controller... but anything's possible [14:54] ernstp: cat /proc/version_signature, some ext4 patches were applied in -10.32 [14:56] IntuitiveNipple: well ext4 has much better performance I guess, bigger writes with delayed allocation, so maybe something... ? :-) [14:56] rtg: got 10.32 [14:56] rtg: bug #343919 [14:56] Malone bug 343919 in linux "Nvidia MCP67 AHCI ata timeout exception with data loss" [Medium,In progress] https://launchpad.net/bugs/343919 [14:57] rtg: but it should really be an "ahci" driver issue and not ext4 related [14:57] ernstp: ah, I just saw ext4 in the recent scroll-back [14:59] what bothers me is each error on whichever kernel is during ext4 journal work: "ext4_journal_start_sb: Detected aborted journal" [15:01] but I've only ever seen it on ext4 so far [15:01] I've noted it on the bug... another avenue to examine [15:03] but as I said, I'll leave dpkg running on an ext3 filesystem during the night today [15:03] while true; do dpkg -i wesnoth*; done [15:13] IntuitiveNipple: Ted Ts'o can take a look at it :-) [15:16] hi rtg , could you fix the aufs module first? thats needed to try the 2.6.29 kernel in live mode [15:17] Kano: Karmic is a background task, so I'll get to it eventually. I've still got to get Jaunty released. [15:17] well, there are systems which do not like 2.6.28 [15:18] one asrock x58 board has some issues [15:18] therefore i want to check with 2.6.29 [15:19] Kano: use the mainline build on http://kernel.ubuntu.com/~kernel-ppa [15:19] rtg: i need aufs! [15:19] then you're gonna have to do it yourself [15:19] squashfs is in the kernel now [17:21] cking: Wow. That hpmini driver is special. [17:21] * cking nods [17:22] ..ultimately a generic solution for ICH7 chipsets should be looked at for saving power on the wake alarm [17:22] cking: Why not just have the kernel call acpi_disable_event(ACPI_EVENT_RTC) if there's no alarm set? [17:23] kees: if we move over here, we can say rtg a lot and he'll fix it [17:23] mjg59: the driver turns off the power to the wake alarm mechanism - it's more of a low level ICH7 tweak to save power. [17:23] * Keybuk wonders what happens if you say it three times [17:23] rtg [17:23] rtg [17:23] rtg [17:23] :p [17:23] and ping too [17:24] cking: It looks like it's just writing to the PM registers, which is what acpi_disable_event does [17:24] ..is this dependant on the BIOS doing things right? [17:25] No [17:25] Keybuk: you weren't standing in front of a mirror when you said it [17:25] * cking goes to look at acpi_disable_event more deeply [17:26] you guys quite hassling me. I'm packing boxes. [17:26] wow, the combination of Keybuk highlighting, cking adding ping, and mjg59 saying 'PM' made mjg59's sentence confusing [17:26] rtg: are you going somewhere? :p [17:26] no, sending computers to germany and Mississippi [17:27] Keybuk: oh the irony: config SECURITY_DEFAULT_MMAP_MIN_ADDR ... default 0 [17:27] kees: well, yes [17:27] Keybuk: why are you bugging me? is SECURITY_DEFAULT_MMAP_MIN_ADDR the reason? [17:27] rtg: for your scrollback pleasure [17:27] it is [17:27] arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536 [17:27] vs. [17:27] debian/config/i386/config:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 [17:27] Keybuk: ok, gimme 10 minutes or so, I've got a pickup deadline [17:27] vs. [17:28] /etc/sysctl.d/10-process-security.conf:vm.mmap_min_addr = 65536 [17:28] ie. if we didn't override the config option back to zero in our kernel config, and used the x86 arch default, we wouldn't have to override it back to 64k in userspace via sysctl [17:28] rtg: however, it seems that ARM needs to be 32768. [17:29] according to the Kconfig help text, anyway [17:29] ia64, ppc64, x86: 65536, all others: 32768 [17:29] where x86 means x86 and x86_64 [17:30] kees: I though that used to be 0. it certainly was in Intrepid [17:30] thought* [17:31] rtg: right, upstream changed the defaults. [17:31] oh, you want it set to 64k? [17:31] ok, can do. [17:31] rtg: yeah. it looks like it isn't set as a default for other archs in the kernel. [17:31] rtg: just left at whatever the arch default is I guess [17:31] do we not inherit from arch/*/configs/*_defconfig ? [17:32] Keybuk: not really, unless we start from scratch [17:32] rtg: so, flipping it to 64k (x86, ppc, ia64) and 32k (others) is the way to go [17:32] is there an LP? [17:32] Keybuk: it seems that some archs don't have a default yet upstream [17:34] rtg, can you please set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=32768 for ARM (higher values dont work on arm) [17:35] ogra: can do :) [17:35] thanks a lot :) [17:35] ogra: why is it that not all of the ARM flavours have this option? [17:36] up to now we have set it from /etc/sysctl.d/10-process-security.conf so it sisnt matter at all [17:36] *sisnt [17:36] gah [17:36] didnt [17:37] upstream now uses CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536 ... [17:37] but that breaks on arm [17:38] the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768." [17:38] kees: did you say you had started an LP bug on CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR ? [17:38] and i just verified that setting vm.mmap_min_addr = 32768 works fine (while 65536 breaks in intresting ways) [17:39] rtg: I will open one. [17:39] kkesits not really necessary, just wanted to be sure to get the LP# in the commit if it existed [17:39] ogra: yeah, I was discussing the fixes here with rtg before you joined [17:39] ah, k [17:39] kees: ^^ (can't type today) [17:40] rtg: right, I'd like it so I can follow it with procps changes to address it. [17:40] np [17:44] IntuitiveNipple: 1 hour no problem with 2.6.29-020629rc8-generic, ext4, jaunty. don't think 1 hour is enough though [17:45] rtg: you can remove the squashfs part in ubuntu dir on 2.6.29 [17:45] it is inside the kernel [17:45] rtg: bug #344955 [17:45] Malone bug 344955 in linux "CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR needs to be set" [High,In progress] https://launchpad.net/bugs/344955 [17:45] ernstp: If it doesn't fail then we'll have to hunt the commit(s) that fix it [17:46] IntuitiveNipple: lol, just because I wrote that it failed! [17:46] rtg: once that's in a published kernel, I will fix procps. :) [17:46] IntuitiveNipple: same message as usual [17:47] reboot :-) [17:48] kees, i would call it "high" or even critical for procps ... it breaks ARM completely atm [17:50] (i.e. prevents us from building functional images) [17:55] ogra: right, though it will be fixed very soon in the right place. [17:56] * ogra hopes so, i need to start building images for imx51 asap [17:56] *before* the beta freeze [17:56] ogra: are there any arm-specific packages? You could put a 12-arm-mmap-min.conf into /etc/sysctl.d/ that sets it to 32k until the kernel is fixed? [17:57] sadly there arent ... [17:57] but i'll try to hack around it in an image build script [17:58] ogra: there isn't anything easy in the build script, I can try to teach procps about the arm-specific stuff. I'd rather wait just to avoid needing to clean up conf files, etc. [17:58] yeah [17:58] well, since i'm about to write the build script ther *will* be :) [17:58] if i want it [17:59] we dont have the script i'm talking about yet (i wanted to write it today, but the bug was in my way) [18:09] rtg: are you on the SECURITY fix for the day? [18:10] or do you want me to look at it? [18:10] wow, he's fast [18:11] 16min from reported to fix committed status for 344955 :) [18:11] hehe... [18:11] ogra: I have this amazing hoover that builds _really_ fast [18:12] rtg: is that the one you were replacing the mainboard in last week? [18:12] heh [18:12] ogra: I'll push the rest of the changes to imx51 before I got to bed. Then badger rtg for an upload ;) [18:12] mjg59: yep - I've familiarised myself with the ACPI code now. A generic solution is that acpi_disable_event(ACPI_EVENT_RTC) before hibernate if the wake alarm is not set [18:12] yay [18:12] kees: yep, then I added 4 spindles for raid0 [18:12] * kees drools [18:12] amitk, btw, my USB NIC works fine now ... [18:12] makes the babbage a breeze [18:13] ogra: it better! The imx51 is a bloated beast right now [18:13] but works fine :) [18:13] i shall try my ton of different USB devices the next days [18:14] cking: Yes, that sounds sensible [18:14] cking: Probably for S3 as well as S4 [18:14] * cking nods. It will save several mAh in hibernate that's for sure [18:16] * cking investigates cmos_suspend() et al [18:17] cking: I think you mean several mA :) [18:17] yep. [18:28] * cking wonders why this is not done already [18:47] amitk: so, you're gonna drop some ARM patches on me? [18:50] rtg: where are you uploading? [18:50] rtg: *when [18:51] amitk: anytime you're ready. end of my day is in about 90 mins, but I can do it later tonight as well [18:52] rtg: then let's not rush it. I've had a long few days. I'll finish up the configs _and_ look at d-i tomorrow morning ready for you to upload when you start. [18:54] amitk: in that event I'll upload anyway so kees can get his procps security fix out of the way [18:56] rtg: then let me just push the imx51 config changes. I'll fix d-i later [18:56] gimme 30mins [18:56] k [19:15] hi [19:18] how i can let ubuntu 32 bit see 4G ram? [19:18] lime_: Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 338, column 84 [19:18] lime_: install the -server kernel [19:19] i did that but still not seen ! [19:19] lime_: depending on your chipset, you may only see a bit more then 3Gb [19:20] in the Bios it show 4G , it is dell laptop xps m1210 [19:20] apw: your 'hotkey quirks for various Zepto Znote and Fujitsu' would be easier to cherry pick into Karmic if you pushed it to Jaunty [19:21] hrm [19:21] apw: also, I have to admit I didn't read you original email correctly. [19:22] lime_: the other alternative is to run the 64 bit kernel and user space. [19:22] rtg that commit should be on the jaunty repo, its the third commit against my origin/master -- baad507a2aca0f997f01f964e03f79c4ec622cf4 [19:23] huh, sure is. I searched for the log message in the email and didn't see it. [19:24] apw: sorry for the noise. go back to your beers. [19:28] rtg: cross compile for entire armel will take ~1hr45m. Are you going to do it in any case? [19:28] amitk: yep [19:28] takes about 10 mins [19:29] rtg: then I won't. You'll have to fix abi issues if any for the other flavours. I am marking imx51 as ignore [19:29] amitk: np [19:30] rtg beers i wish [19:30] apw: what, you run out? [19:30] yeah have to go buy some before i can start, how fair is that [19:31] apw: so, what should I do with the EC2 pile from Chuck? [19:31] there are some integration issues i believe just in terms of whether we need a branch or not for this thing [19:31] i was going to review them properly tommorrow am and report back [19:32] overall the look reasonable, just these niggles on how we get them into our tree without breaking it [19:32] rtg: patch pushed. [19:32] bradF: yes. How can I help you? [19:34] i have aufs building now (that's the good news) [19:35] amitk: i have aufs building now (that's the good news) [19:35] amitk: will need to do some fencing in unionfs to support the old api [19:36] amitk: ixp4xx doesn't enable AA but does use NFS so there would need to be fencing done there (the bad news) [19:36] amitk: still want to proceed? [19:38] amitk: larger issue is that any fs which is enabled for either ixp4xx or imx51 will probably need fencing done [19:40] from here I can enable HIGH_MEM option? [19:40] lime_: which will force PAE [19:41] bradF: that sounds like a much larger project [19:42] bradF: do you mean to say that we've applied apparmor patches to our kernel in such a way that it is very hard to turn off AA now? [19:42] amitk: yes [19:43] rtg: ^ perhaps something to keep in mind if you haven't already applied AA for Karmic [19:43] amitk: AA was one of the first commits that I dropped [19:43] rtg, yes how ? [19:44] \o/ [19:44] we really should not be this tightly coupled to AA. Who knows if we want to move to SELinux someday [19:45] Eh? you're only tightly coupled to the vfs hook changes. selinux (kernel portion) works now. [19:45] rtg: its your call for Jaunty. Should bradF continue decoupling it? It seems the AA _might_ work after all [19:45] sbeattie: not being able to compile the kernel without AA is very tight coupling IMO [19:46] amitk: with AA disabled or without the AA patches? [19:46] sbeattie: not necessarily a problem of AA perse, but the way the patches are applied [19:46] amitk: well, I never was in favor of disabling AA. Have you found the source of your AA crash? [19:46] amitk: should I start looking at that the oops that started this? don't know what progress I'll make but I can start. [19:47] rtg: no, we haven't found the reason for the oops. But I think the MMAP_MIN_ADDR might have something to do with it [19:47] that would be nice if it really is the case. [19:47] amitk: interesting! [19:48] hrm, the oops backtrace I saw was on the kernel trying to execve /sbin/init, long before the MMAP_MIN_ADDR stuff gets applied. [19:49] bradF: fixing the oops is still a worthwile goal. That will allow us to enable AA for all arm flavours [19:50] amitk: so, I should stop further work on the AA changes and concentrate on the oops? [19:50] bradF: I suggest you put everything you've done to date on a branch in case we have to come back. [19:50] rtg: can do [19:50] bradF: yes [19:50] amitk: works for me [19:52] AA upstream would still be interested in that problem being fixed. It seems like it is the first time someone's run AA on ARM arch [19:54] bradF: do you get serial console? It may be one of those printk until you find it bugs. [19:55] amitk & [19:59] rtg: yes to serial console [19:59] bradF: ok, rinse and repeat :) [21:21] IntuitiveNipple: 5 hours constant dpkg on ext3 with a 2.6.28 kernel, nothing [21:22] ernstp: poor ext4 :( looks like the finger is pointed its way although I still don't see how the file-system can be implicated, unless it provokes some sequence of events that the particular controller/disk combination doesn't like [21:23] IntuitiveNipple: yeah, it's really wierd... [21:23] IntuitiveNipple: userland shouldn't matter right? [21:24] if it's an indirect linkage, anything could cause it [21:24] I'm pounding my ext4 file system. [21:24] IntuitiveNipple: so I've got the exact same mainline kernel build of 2.6.28.7 installed on a Jaunty partition with ext4 and an Intrepid partition with ext3 [21:24] maybe the way ext4 tries to line up accesses in your case is significant. [21:24] IntuitiveNipple: the very same kernel. nothing on ext3, happens on ext4 [21:25] sounds fun to debug [21:26] one difference is more /etc/sysfs.conf [21:26] devices/system/cpu/cpu0/cpufreq/scaling_governor=performance [21:26] rtg: off hand do you know who's responsible for the nvidia DKMS package scripts? Is it 'kernel-team' or someone else? [21:26] I'll enable that on the other and leave it running tonight [21:26] Alberto Milone, can't think of his nick [21:26] OK, thanks [21:27] I just found the default DKMS doesn't work against a manually installed kernel, took me a while to figure out how to sort it out, would be nice if it could work for both packaged and manual installs [21:28]