| mjg59 | Where's the LPIA LUM tree for hardy? | 01:12 |
|---|---|---|
| mjg59 | Ah, got it | 01:21 |
| Kano | hi, could somebody add aufs to 2.6.29 branch? | 02:41 |
| Kano | would be nice to have as squashfs is integrated to build a live image with it | 02:41 |
| Chenkai1 | 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:48 |
| TheMuso | 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:51 |
| Kano | i did not read a mail,but i see the git log | 02:53 |
| maco | 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 |
| TheMuso | Kano: I think the final version is undecided | 03:06 |
| * maco assumes that was at me | 03:07 | |
| maco | ok | 03:07 |
| TheMuso | Kano: oops sorry | 03:07 |
| TheMuso | maco: yeah misread | 03:07 |
| dtchen | last sentence in "Kernel Version" at http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html | 03:11 |
| Kano | bye | 03:12 |
| cooloney | smb_tp, i switch here for a question about git clone | 08:53 |
| smb_tp | sure | 08:54 |
| cooloney | how can i git clone all the branches of a remote git tree | 08:54 |
| cooloney | not just one master branch | 08:54 |
| smb_tp | You normally do somewhat | 08:55 |
| smb_tp | if you do a "git branch -a" you would see them | 08:55 |
| smb_tp | you then can create one with "git branch <localname> origin/<name>" | 08:55 |
| cooloney | ok | 08:56 |
| cooloney | then git pull origin name | 08:56 |
| cooloney | right | 08:56 |
| smb_tp | then "git checkout <localname>" or probably "git checkout -b <localname> origin/<originname>" | 08:56 |
| smb_tp | which would save you one step | 08:56 |
| smb_tp | you don't need to pull. When you clone you get all the objects | 08:57 |
| smb_tp | It just does not create the local branchnames | 08:57 |
| cooloney | ok, i fully understand | 08:57 |
| cooloney | ikepanhc, you may try on you side | 08:58 |
| ikepanhc | oh, got it | 08:59 |
| cooloney | i will try it on my side. actually, this problem frustrate me a lot | 09:00 |
| cooloney | smb_tp, actually this is a little bit difficult to understand, we assume _clone_ means copy everything | 09:13 |
| cooloney | and git branch, git checkout should be ok default | 09:14 |
| smb_tp | 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 |
| smb_tp | and makes a local branch for it as well | 09:16 |
| smb_tp | apw, Can you describe that better? | 09:16 |
| apw | thats pretty accurate | 09:18 |
| cooloney | git just does not do create a local branch from origin/<branch>, only master | 09:18 |
| smb_tp | AFAIK, yes | 09:19 |
| cooloney | ok, i see | 09:19 |
| apw | the master thing is a convienience | 09:20 |
| apw | you can and do checkout other branches from a remote | 09:20 |
| apw | clone checks out the HEAD branch from the remote, which is normally master | 09:21 |
| apw | and it does that because a repo with no branch checked out is confusing | 09:21 |
| smb_tp | 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:22 |
| apw | right | 09:25 |
| apw | git clone is equivalent to | 09:25 |
| apw | mkdir foo; cd foo; git init; git remote add origin <url>; git fetch origin; git checkout -b master origin | 09:25 |
| IntuitiveNipple | 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:47 |
| IntuitiveNipple | Ha, thank-you Mr Invisible Man, that worked... found it... bug #254668 | 09:49 |
| ubot3 | Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] https://launchpad.net/bugs/254668 | 09:49 |
| smb_tp | IntuitiveNipple, yeah that was one of them | 09:50 |
| IntuitiveNipple | I've got another bug that might be the same one, but it's been trailing on an Nvidia MCP67 issue | 09:51 |
| smb_tp | I see you found bug 272247 as well | 09:51 |
| ubot3 | Malone bug 272247 in linux "System freezes during boot, unless I hold a key down" [High,Fix released] https://launchpad.net/bugs/272247 | 09:51 |
| IntuitiveNipple | Yes, I'm seeing quite a few issues with MCP67 so thought it might be good to disambiguate them | 09:52 |
| IntuitiveNipple | 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:52 |
| smb_tp | Yes, there seemed to be a few on HP / amd machines. But also a few between the lines with intel cpu's | 09:53 |
| smb_tp | there is also bug 217849 | 09:53 |
| ubot3 | Malone bug 217849 in linux "Hardy 64-bit beta and nightly alternate installation stalls" [Critical,Incomplete] https://launchpad.net/bugs/217849 | 09:53 |
| smb_tp | which is slightly different | 09:53 |
| smb_tp | For some it helped only to go for clocksource=jiffies | 09:53 |
| smb_tp | Other needed to get around acpi irq routing | 09:54 |
| IntuitiveNipple | Yeah, I remember that one. I was wondering out loud if it had to do with the bounce-buffering | 09:54 |
| smb_tp | right. i remember now | 09:55 |
| IntuitiveNipple | The upstream commentary on the RCU scheduled idle during boot patch looks like it covers a lot of bug reports | 09:55 |
| smb_tp | Generally it seemed like loosing irqs or going into a sleep state without a correct trigger to wake | 09:55 |
| IntuitiveNipple | do you know if anyone here has tried backporting the RCU patch? If not, I'll give it a go? | 09:55 |
| smb_tp | Not to my knowledge | 09:55 |
| IntuitiveNipple | OK. I'll see what it takes | 09:55 |
| smb_tp | Ok, cool | 09:56 |
| IntuitiveNipple | Seeing as it could wipe a fair few niggles out | 09:56 |
| smb_tp | Fixing that would sure make a lot difference | 09:56 |
| IntuitiveNipple | It'll need some munging to make it apply... I'll do some poking | 10:01 |
| === mdz_ is now known as mdz | ||
| IntuitiveNipple | 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:02 |
| smb_tp | 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:06 |
| smb_tp | Otherwise we probably just want the inline... | 11:07 |
| IntuitiveNipple | 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:07 |
| IntuitiveNipple | 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 |
| smb_tp | Ok, thanks. | 11:09 |
| === `6og is now known as Kamping_Kaiser | ||
| apw | maco, hey ... how is your asus acpi driver going | 12:01 |
| maco | apw: backburnered. trying not to fail my compilers class. | 12:01 |
| apw | heheh, always the way | 12:01 |
| rtg | always a good plan | 12:01 |
| maco | which...er...right...i should probably get back to yacc | 12:02 |
| apw | did that use to work on intrepid | 12:02 |
| maco | no, those keys never worked | 12:02 |
| apw | ok cool. so its not a regression at least | 12:02 |
| maco | well i never ran intrepid on here. but they didnt work in hardy | 12:02 |
| _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:04 |
| rtg | _ruben: do you have that kernel installed (I assume you do), e.g., lib/modules/2.6.27-11 ? | 12:06 |
| _ruben | rtg: yes | 12:07 |
| _ruben | (its within a pbuilder chroot btw) | 12:07 |
| _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:08 |
| rtg | _ruben: right, these are benign warning because no modules.dep exists for these symbols at MODPOST time (Ithink() | 12:09 |
| _ruben | rtg: i get similar errors when i modprobe iscsi-scst.ko | 12:10 |
| rtg | _ruben: so, you're saying its not working and the warnings are not benign? | 12:10 |
| _ruben | http://paste.ubuntu.com/132991/ .. thats when i modprobe them | 12:12 |
| rtg | _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:12 |
| IntuitiveNipple | 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:17 |
| rtg | _ruben: make sure its in an EXPORT_SYMBOL macro in the source | 12:18 |
| _ruben | rtg: let me check that | 12:18 |
| _ruben | src/scst_proc.c:EXPORT_SYMBOL(scst_single_seq_open); | 12:19 |
| rtg | _ruben: hmm, can you build it by hand using " make -C /lib/modules/2.6.27-11/build M=`pwd` " ? | 12:20 |
| IntuitiveNipple | Does this show them? grep -in scst_register /lib/modules/2.6.27-1/modules.symbols | 12:20 |
| IntuitiveNipple | oops typo! | 12:20 |
| IntuitiveNipple | Does this show them? grep -in scst_register /lib/modules/2.6.27-11/modules.symbols | 12:20 |
| rtg | 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 |
| IntuitiveNipple | No, it's part of scst not isci-scst | 12:21 |
| rtg | IntuitiveNipple: ah, missed that | 12:22 |
| IntuitiveNipple | 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:23 |
| IntuitiveNipple | Is there a custom Makefile for that module? | 12:26 |
| _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 |
| IntuitiveNipple | ha! | 12:28 |
| rtg | that would definitely explain it | 12:28 |
| _ruben | so i gotta convince DKMS to take care of the symvers file i guess? | 12:28 |
| IntuitiveNipple | we knew the what but not the why | 12:28 |
| IntuitiveNipple | 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:32 |
| rtg | apw: are you done with checkbox then? | 12:33 |
| apw | checkbox is done as far as i can tell | 12:34 |
| apw | i am waiting for the publisher to download it | 12:34 |
| rtg | apw: ah, that reminds me to check on our new ABI kernel | 12:34 |
| rtg | kewl, someone has already NEWed it | 12:35 |
| rtg | apw: when you build checkbox on your PPA, do you only get i386 ? | 12:36 |
| IntuitiveNipple | 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:36 |
| smb_tp | Sounds cool. If you drop the patch to the mailing list I'll see to get a kernel build | 12:37 |
| _ruben | hmm .. perhaps a POST_BUILD= entry in DKMS can be used | 12:38 |
| apw | rtg yeah, its all 'all' code, all python | 12:38 |
| IntuitiveNipple | smb_tp: Will do. I'm doing a build and install test on it first | 12:39 |
| rtg | apw: hmm, I'm just not used to seeing packages only appearing in one ARCH | 12:39 |
| smb_tp | IntuitiveNipple, Ok | 12:39 |
| apw | yeah when its an all it does that | 12:39 |
| apw | its that mad all == any one and any means all of them | 12:40 |
| rtg | doesn't seem ortogonal | 12:40 |
| rtg | orthogonal, even | 12:40 |
| apw | its completely mind bending | 12:47 |
| apw | in better news the script is in the package and seems to work | 12:47 |
| rtg | apw: good, that was really my only goal. | 12:48 |
| apw | indeed, just running a real life test | 12:49 |
| soren | rtg: "archictecture: all" packages only get built on i386, but are published in all architectures. | 12:49 |
| rtg | soren: just one of those funny inconsistencies in the archive | 12:50 |
| soren | Ah, apw already pointed that out. | 12:50 |
| apw | really it should have been all -> indep and any -> all | 12:50 |
| IntuitiveNipple | 16-core Itanium 2 system for £999 ... is it worth it as a build server? | 13:11 |
| elmo | 16 cores for 1K? | 13:13 |
| elmo | that sounds like it's off the back of a lorry | 13:13 |
| elmo | and not in a good way :-P | 13:13 |
| rtg | IntuitiveNipple: and what do you do with ia64 anyway? | 13:14 |
| IntuitiveNipple | elmo: Yeah, I was wondering the same thing myself! I'd just looked at another for £24.5k :) | 13:14 |
| IntuitiveNipple | rtg: To play with, of course! | 13:14 |
| rtg | expensive toy | 13:14 |
| elmo | itanium's are only 2 cores per socket, right now, AFAICR? | 13:15 |
| IntuitiveNipple | all the best toys are :) | 13:15 |
| elmo | if so, that's an 8-socket machine. which would make it *very* expensive to run, and likely *very* noisy too | 13:15 |
| IntuitiveNipple | 2 cores, 2 hyperthreads | 13:15 |
| IntuitiveNipple | elmo: It'd be banished to the garage like the PowerEdges | 13:15 |
| elmo | ah, well, if you have somewhere for it. I dunno, my experience with Itanium's is with older machines | 13:16 |
| elmo | 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 |
| IntuitiveNipple | I was looking for one with VT support | 13:16 |
| elmo | s/unlessimproved/unless they've improved/ (woo, typing on a loaded box) | 13:17 |
| IntuitiveNipple | Yeah... same here... It'd make a great buildd for the kernels | 13:19 |
| IntuitiveNipple | But, that price... and 'cash only' makes me think... oh well *sigh* too good to be true | 13:19 |
| _ruben | grr .. gotta love being pulled into a meeting unexpectedly .. back to my scst/dkms endeavour :p | 14:13 |
| IntuitiveNipple | is there a make rule to easily build/install the /boot/vmcoreinfo* files from a quick-build ? | 14:13 |
| maco | rtg: around? | 14:15 |
| rtg | maco: in 20 mins or so. on conf call right now | 14:15 |
| maco | ok | 14:16 |
| rtg | saw you k-t list email | 14:16 |
| rtg | your* | 14:16 |
| maco | ah ok then nvm | 14:16 |
| IntuitiveNipple | ok, got it: KVER=2.6.28.8; sudo makedumpfile -g /boot/vmcoreinfo-$KVER -x ../builds/vmlinux | 14:24 |
| ernstp | IntuitiveNipple: still haven't seen the bug with an ext3 filesystem.. will leave it running overnight today | 14:41 |
| ernstp | IntuitiveNipple: if you remember, the MCP67/achi bug | 14:42 |
| IntuitiveNipple | which bug is that? I loose track :) | 14:42 |
| IntuitiveNipple | oh, yeah.... I'm actually looking at some patches for that issue atm | 14:42 |
| ernstp | IntuitiveNipple: cool | 14:46 |
| ernstp | IntuitiveNipple: had dpkg running on Intrepid userland on ext with 2.6.28 from the mainline archive for an hour, nothing happened | 14:47 |
| ernstp | IntuitiveNipple: ext3 that is | 14:47 |
| ernstp | IntuitiveNipple: Jaunty userland, 2.6.28-10 and ex4: 5 minutes dpkg and boom | 14:48 |
| ernstp | IntuitiveNipple: if you want some info from the system after it's happened I can probably recreate it pretty quickly | 14:49 |
| IntuitiveNipple | 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:53 |
| rtg | ernstp: cat /proc/version_signature, some ext4 patches were applied in -10.32 | 14:54 |
| ernstp | IntuitiveNipple: well ext4 has much better performance I guess, bigger writes with delayed allocation, so maybe something... ? :-) | 14:56 |
| ernstp | rtg: got 10.32 | 14:56 |
| IntuitiveNipple | rtg: bug #343919 | 14:56 |
| ubot3 | Malone bug 343919 in linux "Nvidia MCP67 AHCI ata timeout exception with data loss" [Medium,In progress] https://launchpad.net/bugs/343919 | 14:56 |
| ernstp | rtg: but it should really be an "ahci" driver issue and not ext4 related | 14:57 |
| rtg | ernstp: ah, I just saw ext4 in the recent scroll-back | 14:57 |
| IntuitiveNipple | what bothers me is each error on whichever kernel is during ext4 journal work: "ext4_journal_start_sb: Detected aborted journal" | 14:59 |
| ernstp | but I've only ever seen it on ext4 so far | 15:01 |
| IntuitiveNipple | I've noted it on the bug... another avenue to examine | 15:01 |
| ernstp | but as I said, I'll leave dpkg running on an ext3 filesystem during the night today | 15:03 |
| ernstp | while true; do dpkg -i wesnoth*; done | 15:03 |
| ernstp | IntuitiveNipple: Ted Ts'o can take a look at it :-) | 15:13 |
| Kano | hi rtg , could you fix the aufs module first? thats needed to try the 2.6.29 kernel in live mode | 15:16 |
| rtg | Kano: Karmic is a background task, so I'll get to it eventually. I've still got to get Jaunty released. | 15:17 |
| Kano | well, there are systems which do not like 2.6.28 | 15:17 |
| Kano | one asrock x58 board has some issues | 15:18 |
| Kano | therefore i want to check with 2.6.29 | 15:18 |
| rtg | Kano: use the mainline build on http://kernel.ubuntu.com/~kernel-ppa | 15:19 |
| Kano | rtg: i need aufs! | 15:19 |
| rtg | then you're gonna have to do it yourself | 15:19 |
| Kano | squashfs is in the kernel now | 15:19 |
| mjg59 | cking: Wow. That hpmini driver is special. | 17:21 |
| * cking nods | 17:21 | |
| cking | ..ultimately a generic solution for ICH7 chipsets should be looked at for saving power on the wake alarm | 17:22 |
| mjg59 | cking: Why not just have the kernel call acpi_disable_event(ACPI_EVENT_RTC) if there's no alarm set? | 17:22 |
| Keybuk | kees: if we move over here, we can say rtg a lot and he'll fix it | 17:23 |
| cking | 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 | |
| Keybuk | rtg | 17:23 |
| Keybuk | rtg | 17:23 |
| Keybuk | rtg | 17:23 |
| Keybuk | :p | 17:23 |
| cking | and ping too | 17:23 |
| mjg59 | cking: It looks like it's just writing to the PM registers, which is what acpi_disable_event does | 17:24 |
| cking | ..is this dependant on the BIOS doing things right? | 17:24 |
| mjg59 | No | 17:25 |
| kees | 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:25 | |
| rtg | you guys quite hassling me. I'm packing boxes. | 17:26 |
| maco | wow, the combination of Keybuk highlighting, cking adding ping, and mjg59 saying 'PM' made mjg59's sentence confusing | 17:26 |
| Keybuk | rtg: are you going somewhere? :p | 17:26 |
| rtg | no, sending computers to germany and Mississippi | 17:26 |
| kees | Keybuk: oh the irony: config SECURITY_DEFAULT_MMAP_MIN_ADDR ... default 0 | 17:27 |
| Keybuk | kees: well, yes | 17:27 |
| rtg | Keybuk: why are you bugging me? is SECURITY_DEFAULT_MMAP_MIN_ADDR the reason? | 17:27 |
| Keybuk | rtg: for your scrollback pleasure | 17:27 |
| Keybuk | it is | 17:27 |
| Keybuk | arch/x86/configs/i386_defconfig:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536 | 17:27 |
| Keybuk | vs. | 17:27 |
| Keybuk | debian/config/i386/config:CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 | 17:27 |
| rtg | Keybuk: ok, gimme 10 minutes or so, I've got a pickup deadline | 17:27 |
| Keybuk | vs. | 17:27 |
| Keybuk | /etc/sysctl.d/10-process-security.conf:vm.mmap_min_addr = 65536 | 17:28 |
| Keybuk | 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 |
| kees | rtg: however, it seems that ARM needs to be 32768. | 17:28 |
| kees | according to the Kconfig help text, anyway | 17:29 |
| kees | ia64, ppc64, x86: 65536, all others: 32768 | 17:29 |
| kees | where x86 means x86 and x86_64 | 17:29 |
| rtg | kees: I though that used to be 0. it certainly was in Intrepid | 17:30 |
| rtg | thought* | 17:30 |
| kees | rtg: right, upstream changed the defaults. | 17:31 |
| rtg | oh, you want it set to 64k? | 17:31 |
| rtg | ok, can do. | 17:31 |
| kees | rtg: yeah. it looks like it isn't set as a default for other archs in the kernel. | 17:31 |
| Keybuk | rtg: just left at whatever the arch default is I guess | 17:31 |
| Keybuk | do we not inherit from arch/*/configs/*_defconfig ? | 17:31 |
| rtg | Keybuk: not really, unless we start from scratch | 17:32 |
| kees | rtg: so, flipping it to 64k (x86, ppc, ia64) and 32k (others) is the way to go | 17:32 |
| rtg | is there an LP? | 17:32 |
| kees | Keybuk: it seems that some archs don't have a default yet upstream | 17:32 |
| ogra | rtg, can you please set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=32768 for ARM (higher values dont work on arm) | 17:34 |
| rtg | ogra: can do :) | 17:35 |
| ogra | thanks a lot :) | 17:35 |
| rtg | ogra: why is it that not all of the ARM flavours have this option? | 17:35 |
| ogra | up to now we have set it from /etc/sysctl.d/10-process-security.conf so it sisnt matter at all | 17:36 |
| ogra | *sisnt | 17:36 |
| ogra | gah | 17:36 |
| ogra | didnt | 17:36 |
| ogra | upstream now uses CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536 ... | 17:37 |
| ogra | but that breaks on arm | 17:37 |
| ogra | the help of SECURITY_DEFAULT_MMAP_MIN_ADDR says "On arm and other archs it should not be higher than 32768." | 17:38 |
| rtg | kees: did you say you had started an LP bug on CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR ? | 17:38 |
| ogra | and i just verified that setting vm.mmap_min_addr = 32768 works fine (while 65536 breaks in intresting ways) | 17:38 |
| kees | rtg: I will open one. | 17:39 |
| rtg | kkesits not really necessary, just wanted to be sure to get the LP# in the commit if it existed | 17:39 |
| kees | ogra: yeah, I was discussing the fixes here with rtg before you joined | 17:39 |
| ogra | ah, k | 17:39 |
| rtg | kees: ^^ (can't type today) | 17:39 |
| kees | rtg: right, I'd like it so I can follow it with procps changes to address it. | 17:40 |
| rtg | np | 17:40 |
| ernstp | IntuitiveNipple: 1 hour no problem with 2.6.29-020629rc8-generic, ext4, jaunty. don't think 1 hour is enough though | 17:44 |
| Kano | rtg: you can remove the squashfs part in ubuntu dir on 2.6.29 | 17:45 |
| Kano | it is inside the kernel | 17:45 |
| kees | rtg: bug #344955 | 17:45 |
| ubot3 | 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 |
| IntuitiveNipple | ernstp: If it doesn't fail then we'll have to hunt the commit(s) that fix it | 17:45 |
| ernstp | IntuitiveNipple: lol, just because I wrote that it failed! | 17:46 |
| kees | rtg: once that's in a published kernel, I will fix procps. :) | 17:46 |
| ernstp | IntuitiveNipple: same message as usual | 17:46 |
| ernstp | reboot :-) | 17:47 |
| ogra | kees, i would call it "high" or even critical for procps ... it breaks ARM completely atm | 17:48 |
| ogra | (i.e. prevents us from building functional images) | 17:50 |
| kees | ogra: right, though it will be fixed very soon in the right place. | 17:55 |
| * ogra hopes so, i need to start building images for imx51 asap | 17:56 | |
| ogra | *before* the beta freeze | 17:56 |
| kees | 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:56 |
| ogra | sadly there arent ... | 17:57 |
| ogra | but i'll try to hack around it in an image build script | 17:57 |
| kees | 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 |
| ogra | yeah | 17:58 |
| ogra | well, since i'm about to write the build script ther *will* be :) | 17:58 |
| ogra | if i want it | 17:58 |
| ogra | we dont have the script i'm talking about yet (i wanted to write it today, but the bug was in my way) | 17:59 |
| amitk | rtg: are you on the SECURITY fix for the day? | 18:09 |
| amitk | or do you want me to look at it? | 18:10 |
| ogra | wow, he's fast | 18:10 |
| ogra | 16min from reported to fix committed status for 344955 :) | 18:11 |
| amitk | hehe... | 18:11 |
| rtg | ogra: I have this amazing hoover that builds _really_ fast | 18:11 |
| kees | rtg: is that the one you were replacing the mainboard in last week? | 18:12 |
| ogra | heh | 18:12 |
| amitk | ogra: I'll push the rest of the changes to imx51 before I got to bed. Then badger rtg for an upload ;) | 18:12 |
| cking | 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 |
| ogra | yay | 18:12 |
| rtg | kees: yep, then I added 4 spindles for raid0 | 18:12 |
| * kees drools | 18:12 | |
| ogra | amitk, btw, my USB NIC works fine now ... | 18:12 |
| ogra | makes the babbage a breeze | 18:12 |
| amitk | ogra: it better! The imx51 is a bloated beast right now | 18:13 |
| ogra | but works fine :) | 18:13 |
| ogra | i shall try my ton of different USB devices the next days | 18:13 |
| mjg59 | cking: Yes, that sounds sensible | 18:14 |
| mjg59 | cking: Probably for S3 as well as S4 | 18:14 |
| * cking nods. It will save several mAh in hibernate that's for sure | 18:14 | |
| * cking investigates cmos_suspend() et al | 18:16 | |
| mjg59 | cking: I think you mean several mA :) | 18:17 |
| cking | yep. | 18:17 |
| * cking wonders why this is not done already | 18:28 | |
| rtg | amitk: so, you're gonna drop some ARM patches on me? | 18:47 |
| amitk | rtg: where are you uploading? | 18:50 |
| amitk | rtg: *when | 18:50 |
| rtg | amitk: anytime you're ready. end of my day is in about 90 mins, but I can do it later tonight as well | 18:51 |
| amitk | 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:52 |
| rtg | amitk: in that event I'll upload anyway so kees can get his procps security fix out of the way | 18:54 |
| amitk | rtg: then let me just push the imx51 config changes. I'll fix d-i later | 18:56 |
| amitk | gimme 30mins | 18:56 |
| rtg | k | 18:56 |
| lime_ | hi | 19:15 |
| lime_ | how i can let ubuntu 32 bit see 4G ram? | 19:18 |
| ubot3 | lime_: Error: Could not parse XML returned by Ubuntu: not well-formed (invalid token): line 338, column 84 | 19:18 |
| rtg | lime_: install the -server kernel | 19:18 |
| lime_ | i did that but still not seen ! | 19:19 |
| rtg | lime_: depending on your chipset, you may only see a bit more then 3Gb | 19:19 |
| lime_ | in the Bios it show 4G , it is dell laptop xps m1210 | 19:20 |
| rtg | 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:20 |
| apw | hrm | 19:21 |
| rtg | apw: also, I have to admit I didn't read you original email correctly. | 19:21 |
| rtg | lime_: the other alternative is to run the 64 bit kernel and user space. | 19:22 |
| apw | rtg that commit should be on the jaunty repo, its the third commit against my origin/master -- baad507a2aca0f997f01f964e03f79c4ec622cf4 | 19:22 |
| rtg | huh, sure is. I searched for the log message in the email and didn't see it. | 19:23 |
| rtg | apw: sorry for the noise. go back to your beers. | 19:24 |
| amitk | rtg: cross compile for entire armel will take ~1hr45m. Are you going to do it in any case? | 19:28 |
| rtg | amitk: yep | 19:28 |
| rtg | takes about 10 mins | 19:28 |
| amitk | 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 |
| rtg | amitk: np | 19:29 |
| apw | rtg beers i wish | 19:30 |
| rtg | apw: what, you run out? | 19:30 |
| apw | yeah have to go buy some before i can start, how fair is that | 19:30 |
| rtg | apw: so, what should I do with the EC2 pile from Chuck? | 19:31 |
| apw | there are some integration issues i believe just in terms of whether we need a branch or not for this thing | 19:31 |
| apw | i was going to review them properly tommorrow am and report back | 19:31 |
| apw | overall the look reasonable, just these niggles on how we get them into our tree without breaking it | 19:32 |
| amitk | rtg: patch pushed. | 19:32 |
| amitk | bradF: yes. How can I help you? | 19:32 |
| bradF | i have aufs building now (that's the good news) | 19:34 |
| bradF | amitk: i have aufs building now (that's the good news) | 19:35 |
| bradF | amitk: will need to do some fencing in unionfs to support the old api | 19:35 |
| bradF | amitk: ixp4xx doesn't enable AA but does use NFS so there would need to be fencing done there (the bad news) | 19:36 |
| bradF | amitk: still want to proceed? | 19:36 |
| bradF | amitk: larger issue is that any fs which is enabled for either ixp4xx or imx51 will probably need fencing done | 19:38 |
| lime_ | from here I can enable HIGH_MEM option? | 19:40 |
| rtg | lime_: which will force PAE | 19:40 |
| amitk | bradF: that sounds like a much larger project | 19:41 |
| amitk | 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 |
| bradF | amitk: yes | 19:42 |
| amitk | rtg: ^ perhaps something to keep in mind if you haven't already applied AA for Karmic | 19:43 |
| rtg | amitk: AA was one of the first commits that I dropped | 19:43 |
| lime_ | rtg, yes how ? | 19:43 |
| amitk | \o/ | 19:44 |
| amitk | we really should not be this tightly coupled to AA. Who knows if we want to move to SELinux someday | 19:44 |
| sbeattie | Eh? you're only tightly coupled to the vfs hook changes. selinux (kernel portion) works now. | 19:45 |
| amitk | rtg: its your call for Jaunty. Should bradF continue decoupling it? It seems the AA _might_ work after all | 19:45 |
| amitk | sbeattie: not being able to compile the kernel without AA is very tight coupling IMO | 19:45 |
| sbeattie | amitk: with AA disabled or without the AA patches? | 19:46 |
| amitk | sbeattie: not necessarily a problem of AA perse, but the way the patches are applied | 19:46 |
| rtg | amitk: well, I never was in favor of disabling AA. Have you found the source of your AA crash? | 19:46 |
| bradF | 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:46 |
| amitk | 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 |
| rtg | that would be nice if it really is the case. | 19:47 |
| bradF | amitk: interesting! | 19:47 |
| sbeattie | 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:48 |
| amitk | bradF: fixing the oops is still a worthwile goal. That will allow us to enable AA for all arm flavours | 19:49 |
| bradF | amitk: so, I should stop further work on the AA changes and concentrate on the oops? | 19:50 |
| rtg | bradF: I suggest you put everything you've done to date on a branch in case we have to come back. | 19:50 |
| bradF | rtg: can do | 19:50 |
| amitk | bradF: yes | 19:50 |
| bradF | amitk: works for me | 19:50 |
| amitk | 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:52 |
| rtg | bradF: do you get serial console? It may be one of those printk until you find it bugs. | 19:54 |
| amitk | amitk & | 19:55 |
| bradF | rtg: yes to serial console | 19:59 |
| rtg | bradF: ok, rinse and repeat :) | 19:59 |
| ernstp | IntuitiveNipple: 5 hours constant dpkg on ext3 with a 2.6.28 kernel, nothing | 21:21 |
| IntuitiveNipple | 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:22 |
| ernstp | IntuitiveNipple: yeah, it's really wierd... | 21:23 |
| ernstp | IntuitiveNipple: userland shouldn't matter right? | 21:23 |
| IntuitiveNipple | if it's an indirect linkage, anything could cause it | 21:24 |
| rtg | I'm pounding my ext4 file system. | 21:24 |
| ernstp | 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 |
| IntuitiveNipple | maybe the way ext4 tries to line up accesses in your case is significant. | 21:24 |
| ernstp | IntuitiveNipple: the very same kernel. nothing on ext3, happens on ext4 | 21:24 |
| ernstp | sounds fun to debug | 21:25 |
| ernstp | one difference is more /etc/sysfs.conf | 21:26 |
| ernstp | devices/system/cpu/cpu0/cpufreq/scaling_governor=performance | 21:26 |
| IntuitiveNipple | rtg: off hand do you know who's responsible for the nvidia DKMS package scripts? Is it 'kernel-team' or someone else? | 21:26 |
| ernstp | I'll enable that on the other and leave it running tonight | 21:26 |
| rtg | Alberto Milone, can't think of his nick | 21:26 |
| IntuitiveNipple | OK, thanks | 21:26 |
| IntuitiveNipple | 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:27 |
| rtg | IntuitiveNipple: gimme a sec to track him down. | 21:28 |
| rtg | IntuitiveNipple: alberto.milone@canonical.com, tseliot is his nick | 21:29 |
| IntuitiveNipple | It's okay, I'll email him | 21:29 |
| IntuitiveNipple | yeah, that's the one :) | 21:29 |
| Kano | IntuitiveNipple: usally it does when you boot a new kernel | 21:30 |
| IntuitiveNipple | Kano: It can't in this case, that's the thing, since one of the include files it uses in a build-test app isn't where it is expected | 21:31 |
| IntuitiveNipple | with a manual install the out-of-tree build dir is linked from ./build and the source is ./source | 21:31 |
| IntuitiveNipple | I had to play with reversing SYSSRC and adding SYSOUT to dkms.conf to figure it out | 21:32 |
| Kano | well they are expected at the standard postition | 21:32 |
| IntuitiveNipple | The Linux kernel modules_install and the Ubuntu linux-headers do different things... it would be nice if the DKMS package can cope with both | 21:33 |
| Kano | was this link /lib/modules/$(uname -r)/build correctly set? | 21:34 |
| IntuitiveNipple | ./build/ links to the out-of-tree build directory, which doesn't contain linux/utsname.h (that's in ./source/include/) | 21:35 |
| IntuitiveNipple | I'll figure out a munge tomorrow, now I have it working | 21:36 |
| Kano | here it is in include/linux/utsname.h | 21:36 |
| Kano | not in your linux version? | 21:36 |
| Kano | well it is in the ubuntu packages at that place at least ;) | 21:39 |
| Kano | even in 2.6.29 | 21:39 |
| IntuitiveNipple | For packaged headers it's in ./build/include/linux/ but for out-of-tree kernel builds installed using the kernel's own make modules_install it's in ./source/include/linux/ | 21:39 |
| Kano | so will test my aufs hack | 21:39 |
| marijus | will there be 2.6.29-rc kernels with kms support build for the mainline kernel ppa? | 23:05 |
| erle- | are the virtualbox kernel modules packaged with the "restricted modules"? | 23:23 |
| TheMuso | erle-: no. What version of Ubuntu are you using? | 23:25 |
| erle- | 8.10 | 23:25 |
| TheMuso | I think for 8.10 the virtualbox modules are built using dkms, but don't hold me to that. | 23:25 |
| erle- | i removed the restricted modules a few days ago | 23:27 |
| erle- | and now i see that there is no more vbox module | 23:27 |
| erle- | i think it is packaged there | 23:27 |
| erle- | and i think that has to be fixed! | 23:27 |
| TheMuso | Well I could be wrong, but I didn't think it was. | 23:27 |
| erle- | TheMuso, can you please look up? | 23:27 |
| erle- | i cannot because the package is not installed | 23:27 |
| TheMuso | Alright, one second. | 23:27 |
| === pgraner` is now known as pgraner | ||
| TheMuso | erle-: you want virtualbox-ose-source | 23:31 |
| erle- | TheMuso, i don't think so | 23:31 |
| erle- | there is a precompiled kernel module shipped | 23:32 |
| erle- | why should i build my own? | 23:32 |
| erle- | the source is nice for people with custom kernels | 23:32 |
| IntuitiveNipple | erle: "This package provides the binaries for the Open Source Edition of | 23:33 |
| IntuitiveNipple | VirtualBox. The virtualbox-ose-source package is also required in order to | 23:33 |
| IntuitiveNipple | compile the kernel modules needed for virtualbox-ose" | 23:33 |
| TheMuso | erle- In that case, I don't know. I suggest you ask in #ubuntu-motu since there you will find the people who maintain it. | 23:33 |
| erle- | hm | 23:34 |
| erle- | i know that it worked before without custom module building | 23:35 |
| erle- | now i am confused | 23:35 |
| erle- | i will investigate and inform you | 23:35 |
| erle- | sorry, my fault, everything fine again | 23:40 |
| erle- | he seems to compile the modules from source on demand | 23:40 |
| erle- | thank you for your support and sorry :) | 23:41 |
| TheMuso | erle-: thats ok, it can be confusing if you don't know where the modules come from. | 23:42 |
| erle- | yeah, its just because i removed the one module package and thought that's the reason | 23:43 |
| TheMuso | yep | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!