| === sconklin is now known as sconklin-away | ||
| === SEJeff_ is now known as SEJeff_away | ||
| === SEJeff_away is now known as SEJeff_home | ||
| vi390 | hi, how can I get openVZ kernels with jaunty | 07:01 |
|---|---|---|
| slytherin | Is ATI KMS configured/enabled in karmic kernels? The kernel upstream changelog says it is enabled for non-x86. | 09:22 |
| mdz | slytherin, the config used is in /boot/config-`uname -r` | 09:27 |
| mdz | slytherin, I believe the relevant option is CONFIG_DRM_RADEON_KMS | 09:31 |
| mdz | it doesn't seem to be set at the moment in Karmic | 09:31 |
| mdz | though I believe apw has a kernel build with it enabled | 09:32 |
| apw | that code comes in the 2.6.31-rc1 update, which is the next kernel for karmic. where it is enabled by default | 09:33 |
| slytherin | mdz: I haven't installed karmic yet. I plan to upgrade my ibook (powerpc) once the KMS is enabled. | 09:34 |
| slytherin | apw: thanks for info. | 09:35 |
| apw | there is an older KMS enabled kernel available in one of my PPAs | 09:35 |
| slytherin | apw: my machine is powerpc arch, hence PPAs are not useful to me. | 09:35 |
| apw | the powerpc kernels in karmic are lagging somewhat right now | 09:36 |
| slytherin | apw: by the way, the changelog for linux package in karmic says that it is rebased on 2.6.31-rc1. So I believe once it builds properly it will have KMS. | 09:36 |
| apw | right, it does have the code but the ports architectures don't seem to be building right now | 09:37 |
| slytherin | apw: anyway I can help to fix it? | 09:38 |
| apw | to be honest i've not even looked yet at why they arn't building. the ports maintainers normally sort that out | 09:38 |
| slytherin | which means I have to bug NCommander | 09:39 |
| apw | yeah there are a couple of them i think | 09:53 |
| === lifeless_ is now known as lifeless | ||
| apw | Keybuk, hey ... the moving from 486 to 586 discussion for i386 architecture, where has that gotten to? i am trying to work out if i need to re-integrate the 386 kernel flavour | 10:15 |
| Keybuk | apw: still waiting on a 586 build to test with | 10:19 |
| apw | thanks for the info | 10:22 |
| bullgard4 | Since upgrading from 2.6.24-24-generic to 2.6.28-13-generic the number of loaded kernel modules almost cut in half. Why? | 10:56 |
| smb | bullgard4, because most drivers are built-in | 10:57 |
| bullgard4 | smb: Thank you. | 11:03 |
| vi390 | can somebody tell me if there is any openVZ kernels for jaunty ? | 11:57 |
| * hyperair doesn't think so | 12:27 | |
| hyperair | you could dig around the PPAs and see, though | 12:27 |
| smb | manjo, look at the makefile of dmraid as it is before. you only get one .ko | 14:04 |
| manjo | smb, I did not change the makefile ... and it produced many kos | 14:05 |
| apw | yeah i think he is right, its makeing a .ko per .c there | 14:05 |
| manjo | dm-raid45.ko dm-message.ko dm-region-hash.ko | 14:05 |
| smb | after importing the new version or before? | 14:05 |
| apw | before for sure | 14:05 |
| apw | obj-$(CONFIG_DM_RAID45) += dm-raid4-5.o dm-mem-cache.o dm-region_hash.o dm-message.o | 14:05 |
| smb | obj-$(CONFIG_DM_RAID45) += dm-raid4-5.o dm-mem-cache.o dm-region_hash.o dm-message.o | 14:05 |
| apw | that is adding them raw, so each is a separate module | 14:05 |
| smb | that is one .ko | 14:05 |
| apw | smb, nope | 14:05 |
| apw | you see | 14:05 |
| apw | dmraid-obj = foo.o bar .o | 14:06 |
| apw | if you merge .o's to make a .ko | 14:06 |
| smb | so? | 14:06 |
| apw | obj-$(CONFIG_TLSUP) := tlsup.o | 14:06 |
| apw | tlsup-objs := tlsup_mod.o tlsup_acpi.o tlsup_backlight.o tlsup_hotkeys.o tlsup_radios.o | 14:06 |
| apw | that construction makes one .ko out of a bunch of .o's | 14:07 |
| apw | obj-$(CONFIG_DM_RAID45) += dm-raid4-5.o dm-mem-cache.o dm-region_hash.o dm-message.o | 14:07 |
| apw | that form makes one .ko per .o | 14:07 |
| smb | Hm, ok , you are right here. Not sure we actually wanted that | 14:07 |
| apw | yeah if it worked using the first form, then things seem less worrying | 14:08 |
| manjo | apw, I thought we changed it to be that way... so that was a mistake you say ? | 14:08 |
| apw | i don't know for sure one way or the other right now | 14:09 |
| manjo | ok how about this ? | 14:09 |
| manjo | I use the makefile that came with the patch | 14:09 |
| manjo | and build the ko in ubuntu ? | 14:09 |
| manjo | throw away the old make file | 14:09 |
| apw | what does that one look like | 14:09 |
| manjo | I wanted to do that originally | 14:09 |
| smb | The problem to me seems that drivers/md also produces similar modules. | 14:09 |
| manjo | yes it does | 14:10 |
| smb | I guess the renaming is the critical part here | 14:10 |
| apw | yes they have been renamed there may be some other renames in the code we cannot see | 14:10 |
| smb | But probably it would make much more sense to use the form to produce only the dm-raid module including all the code | 14:10 |
| apw | manjo, can you pastebin the new Makefile | 14:11 |
| manjo | yes | 14:11 |
| apw | so we can see what its like, its likely an external module build job, whjich is not usable without mod in the kernel | 14:11 |
| manjo | apw, heh the new Makefile does the same thing | 14:11 |
| manjo | +obj-$(CONFIG_DM_RAID45) += dm-raid45.o dm-log.o dm-memcache.o \ | 14:12 |
| manjo | + dm-region-hash.o dm-message.o | 14:12 |
| smb | I believe it produced modules differently named | 14:12 |
| smb | dm-region-hash.o in drivers | 14:12 |
| smb | and dm-region_hash.o in ubuntu | 14:12 |
| apw | manjo, can you pint me at the original patch | 14:13 |
| manjo | http://people.redhat.com/~heinzm/sw/dm/dm-raid45/ | 14:13 |
| manjo | smb, when you apply the patch it no longer produces dm-region_hash.c | 14:14 |
| manjo | but produces dm-region-hash.c | 14:14 |
| smb | apw, I guess what happened was exactly that. Take the patch and the files. And to avoid duplicated rename on | 14:14 |
| smb | but that still leaves the risk of duplicate symbols | 14:14 |
| apw | yeah ... is a little worrying | 14:14 |
| smb | So IMO the simples solution is to import it the other way | 14:14 |
| smb | replace the makefile to build one module | 14:15 |
| manjo | also does not produce dm-mem-cache.c but it produces dm-memcache.c | 14:15 |
| apw | which one? the old? | 14:15 |
| manjo | I think this is what we need to do .. throw away the old ones | 14:16 |
| manjo | use the new patch to produce one module | 14:16 |
| smb | Neither dm-mem-cache nor dm-message are in drivers/md, but this might be preparations to get it merged upstream | 14:16 |
| manjo | right ... apw smb are you in agreement with throwing away the old stuff in /ubuntu/ and makeing dmraid as one module ? | 14:17 |
| apw | dmraid4-5 as one module | 14:17 |
| smb | yep | 14:17 |
| apw | if so, thats the thing to try yes | 14:17 |
| manjo | so we will not have many kos under dmraid4-5 | 14:17 |
| apw | apply the patch, copy the changed/new files over | 14:18 |
| apw | and then use the -objs form to make one .ko | 14:18 |
| smb | manjo, one more second, let me check something | 14:18 |
| apw | then see if it will build/boot/load | 14:18 |
| manjo | yeah actually I have done all that ... just need to make one module .. | 14:18 |
| apw | the tlsup module is a good example of how to do that | 14:18 |
| smb | dm-raid45-objs := dm-raid4-5.o dm-log.o dm-mem-cache.o \ | 14:18 |
| smb | dm-region_hash.o dm-message.o | 14:18 |
| smb | obj-m += dm-raid45.o | 14:18 |
| smb | that is the makefile in Hardy lum for it | 14:18 |
| apw | heh | 14:19 |
| apw | so we know that that works then ... good | 14:19 |
| manjo | ok one module it is ... one line change in makefile | 14:19 |
| apw | the second entry should be obj-$(CONFIG_...) += dm-raid45.o | 14:19 |
| smb | I laso renamed it from dm-raid4-5 to dm-raid45 because at that time the module registered itself with that name and | 14:19 |
| smb | there is some dm rules that normally load a module if you request a function's name | 14:20 |
| manjo | yeah I like to call it dm-raid45 instead of 4-5 | 14:20 |
| smb | manjo, check the module code for the name it registers, to be on the safe side | 14:20 |
| smb | static struct target_type raid_target = { | 14:22 |
| smb | .name = "raid45", | 14:22 |
| smb | At least the version in Jaunty did still name itself like this | 14:22 |
| apw | manjo, so you have a plan? | 14:23 |
| manjo | .name = "raid45", | 14:23 |
| manjo | yeah | 14:23 |
| manjo | smb, apw ok now built as one module ... | 14:55 |
| * smb pats manjo on the shoulder | 14:55 | |
| manjo | a simple boot & load module test will be ok ? | 14:55 |
| smb | manjo, I would say for the first step. But be prepared for the Inquisition as soon as apw uploads it. ;-) | 14:56 |
| manjo | heh | 14:56 |
| manjo | yeah I figured that is bound to happen | 14:57 |
| manjo | apw, smb, btw there are no changes to iscsitarget | 14:58 |
| manjo | no new version out there | 14:58 |
| manjo | and looks like the same case with compcache | 14:59 |
| manjo | although in the case of compcache there is some effort going on to get it upstream | 14:59 |
| smb | manjo, Well ok, so there is nothing to do. Except maybe, get in touch with some server guys and ask them whether they would prefer to have it as dkms module | 14:59 |
| manjo | for iscsi ? | 15:00 |
| * smb nods | 15:00 | |
| * manjo nods twice | 15:00 | |
| * smb goes to fill another cup with dark liquid | 15:01 | |
| hyperair | does anyone know why acpi-cpufreq has been built into the kernel rather than as a module since jaunty? | 15:02 |
| hyperair | i mean, does it make much difference in loading time? | 15:02 |
| smb | hyperair, That was the intention then. We are aware of the issues you got and we will think about it. Just cannot tell any outcome. | 15:07 |
| hyperair | smb: the phc-linux issue? okay then, thanks =) | 15:08 |
| hyperair | as long as it is given attention | 15:08 |
| smb | hyperair, Yes, it is. It is correct that this is a different gouvernor/driver which cannot get active as the built-in acpi-cpufreq is always there before. | 15:08 |
| hyperair | smb: in actuality, the phc linux module is just a patch on the acpi-cpufreq module. some implementations of the install turn it into a differently named module, but it's essentially acpi-cpufreq that's patched | 15:09 |
| hyperair | smb: or the amd one, which i can't remember the name of | 15:10 |
| smb | likely powernow-k8 | 15:10 |
| smb | Hm, ok. So it would not help you, just to have an option to prevent acpi-cpufeq from getting active. | 15:11 |
| mjg59 | Use ksplice | 15:11 |
| smb | mjg59, Don't let the security people hear ;-) | 15:11 |
| amitk | hyperair: is this code unlikely to go upstream? | 15:13 |
| smb | But in general I am a bit against this approach of having patched external modules replacing kernel modules... | 15:13 |
| hyperair | amitk: unlikely. it's been rejected before, because "it allows users to shoot themselves in the foot" | 15:13 |
| smb | amitk, It makes use of non-standard voltages and frequencies. What would you think= | 15:13 |
| smb | ? | 15:13 |
| mjg59 | cpufreq upstream have rejected it, yes | 15:14 |
| amitk | fair enough. | 15:14 |
| hyperair | smb: well, if acpi-cpufreq is prevented from getting active, i think it's possible to inject the patched acpi-cpufreq module into the kernel via insmod | 15:14 |
| hyperair | smb: no, only non-standard voltages. | 15:14 |
| mjg59 | It's not so much that it allows users to shoot themselves in the foot, it means that you're operating the kernel outside normal parameters and could cause all kinds of subtle failures which may appear to be kernel or app bugs | 15:15 |
| hyperair | smb: and it doesn't allow you to overvolt, only undervolt | 15:15 |
| mjg59 | So you also get to shoot other people in the foot | 15:15 |
| bjf_afk | NOTICE: There will be a kernel team meeting on #ubuntu-meeting today at 17:00 UTC | 15:15 |
| mjg59 | Tainting would deal with the kernel side, but it's like overclocking - it may be fine for everything except a very specific set of instructions, so it may seem like an application issue | 15:15 |
| smb | Yes, and being a replacement module also add to the maintenance nightmare | 15:15 |
| hyperair | perhaps a nice large warning by the phc guides =p | 15:17 |
| hyperair | or a huge warning in the dmesg log when the phc values are changed | 15:17 |
| amitk | hyperair: not good enough. We don't want to deal with such bugs _at all_ - whether kernel or app space. And app-space reports don't always ask for dmesg | 15:18 |
| smb | hyperair, The second sounds like a minimum. | 15:18 |
| hyperair | smb: what second? | 15:18 |
| smb | hyperair, A big dmesg warning. But as amitk says, that would not help if strange things happen in app space | 15:19 |
| hyperair | amitk: yeah it's true. well either way, it was rejected by upstream, and is probably not going in, so let's not worry about that issue. what i'm more concerned with is the ability to just recompile the module with the headers installed instead of having to recompile the whole kernel. | 15:19 |
| hyperair | in my case, my cpu + fan was going haywire so a kernel compile would cause it to overheat and shutdown | 15:20 |
| hyperair | undervolting the cpu did a great job at reducing the temperature though, and now i can deal with kernel compiles without having to go through a ^Z + fg cycle | 15:21 |
| mjg59 | It's debatable whether it's actually an OS's job to make it easy for you to deal with broken hardware | 15:23 |
| smb | I can understand it to a degree from the user side, but as a distro that sort of thing sounds slightly scary | 15:24 |
| smb | I run one of my laptops with a upper frequency limit due to the fact that the fan cannot cope with it running full speed | 15:25 |
| hyperair | mjg59: a lot of hardware is broken, especially those with particularly stupid BIOSes. are you saying that we shouldn't support those because their hardware is stupid? | 15:31 |
| hyperair | smb: acpi-cpufreq compiled as a module; that's all i'm asking. | 15:32 |
| hyperair | smb: that's all is required to make it that much easier to set up phc-linux | 15:32 |
| hyperair | +that | 15:32 |
| mjg59 | Compiling acpi-cpufreq as a module means compiling all of cpufreq as modules | 15:32 |
| hyperair | is that so? | 15:33 |
| smb | yes | 15:33 |
| hyperair | the tarball only contains a acpi-cpufreq.c | 15:33 |
| hyperair | and it can be compiled on the spot with just the kernel headers installed, if acpi-cpufreq is compiled as a module | 15:33 |
| hyperair | but either way, compiling all of cpufreq can't take more than a few minutes; maybe ~5 minutes or less on some decent hardware | 15:34 |
| hyperair | compare that to taking nearly an hour, or more to compile the kernel | 15:34 |
| smb | The sequence of probing can change the used driver. If you want to have control over that you have to compile them either all as modules or in | 15:34 |
| hyperair | the *entire* kernel, just because you want changes in that tiny part | 15:34 |
| * hyperair fires up menuconfig | 15:35 | |
| hyperair | menuconfig doesn't seem to agree | 15:36 |
| smb | menuconfig does not care about policy | 15:37 |
| smb | If you want to prefer acpi-cpufreq over powernow-k7 for example, you cannot have powernow-k7 built in and acpi-cpufrq as a module | 15:38 |
| hyperair | what about both of them as modules? | 15:38 |
| hyperair | it's one or the other, isn't it? | 15:39 |
| hyperair | if you use acpi-cpufreq, you won't use powernow, and vice versa? | 15:39 |
| mjg59 | No | 15:39 |
| hyperair | don't tell me you use both? | 15:39 |
| mjg59 | No | 15:39 |
| hyperair | then?! | 15:39 |
| mjg59 | But there are other drivers that may bind | 15:39 |
| hyperair | bind? | 15:39 |
| mjg59 | To the processor | 15:39 |
| hyperair | blargh | 15:39 |
| mjg59 | And if they're built into the kernel, you'll end up with that driver instead | 15:40 |
| mjg59 | Hence, all built in or all modular | 15:40 |
| hyperair | let's look at it this way: intrepid and previous versions of ubuntu had acpi-cpufreq/powernowwhatever compiled as a module. why can't we revert the cpu freq scaling part back to that stage? | 15:40 |
| === bjf_afk is now known as bjf | ||
| smb | As the decision was made in favour of boot time (and module loads at least had a bad impact on that), this depends on whether there might be less or no such penalty now. | 15:41 |
| hyperair | okay, so the deciding factor is now basically how much delay there is, am i right? | 15:42 |
| bjf | amitk, the other differences between my tree and yours is that I also rebased to the 2.6.31 karmic changes over the weekend | 15:42 |
| bjf | amitk, but I think those changes are in the same files (fewer of them) | 15:43 |
| bjf | amitk, any additional fixups were done as separate commits (which I was going to squash before submitting) | 15:43 |
| smb | More or less. And probably too how the common feeling is to change a configuration for a, maybe not uncommon, corner case. | 15:44 |
| amitk | bjf: sure, I'm not worried about the state of the patches right now. I have a kernel the compiles from your tree currently. We can rework the patches later. | 15:44 |
| smb | hyperair, But the main part is the boot delay, yes | 15:44 |
| bjf | amitk, was just letting you know my thinking | 15:45 |
| hyperair | smb: so all i have to do is benchmark? | 15:45 |
| amitk | bjf: did you get your pegatron or b2 board booting with anything apart from your kernel? | 15:45 |
| hyperair | smb: in that case, which kernel version would you prefer me benchmark? | 15:45 |
| amitk | bjf: ack. | 15:46 |
| bjf | amitk, I got the b2 board booting with files from Freescale, The "P" board got shipped out and I never tried booting it. | 15:46 |
| bjf | amitk, don't have a "P" board now | 15:46 |
| smb | hyperair, At the moment, let us do a bit of research. There might be changes to user space that improve things too. So it is not only the kernel | 15:46 |
| amitk | bjf: ok, so we have different boards now. | 15:47 |
| bjf | amitk, you don't have a b2? (right, I remember now) | 15:48 |
| amitk | bjf: nope. And it took me all day today to chase down the right redboot image for my board. | 15:48 |
| hyperair | smb: alright, keep me updated then? =) | 15:48 |
| smb | hyperair, sure, I got the bug number and you are usually around ;-) | 15:49 |
| amitk | bjf: I am working towards a SD image where I can change kernels on the fly | 15:49 |
| bjf | amitk, I'd like that as well | 15:50 |
| * smb has them (sd cards) nearly all for i386 series | 15:51 | |
| hyperair | smb: thanks =) | 15:53 |
| manjo | smb, zul from server is ok with dkm on iscsitarget... so I am going to go ahead and do it | 15:55 |
| manjo | currently testing dm-raid45 | 15:56 |
| smb | manjo, I won't hold you back then. :) | 15:56 |
| manjo | smb, as you suspected ... building it as one module wont work... due to duplicate symbols | 17:02 |
| manjo | dm-raid45 wont load | 17:02 |
| manjo | smb, apw revert back to separate kos ? | 17:02 |
| smb | manjo, You might want to look at the hardy-lum | 17:02 |
| manjo | ok | 17:03 |
| smb | You can remove exports from those other modules | 17:03 |
| manjo | yeah that is what I was just thinkig | 17:03 |
| apw | yeah worth a try, we really only want that one loading that code for the raid45 versions | 17:05 |
| smb | And that got it linked, so it won't need the exports | 17:05 |
| Keybuk | apw: around? | 17:16 |
| apw | hello | 17:16 |
| Keybuk | could you cook me up a custom kernel with http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git;a=blob;f=driver-core/driver-core-devtmpfs-driver-core-maintained-dev-tmpfs.patch;h=22e58d1616d256d7fdd6c2c6365eea11de0123be;hb=6fcc499f41d83b8870b74f024aa906b85b700cb4 applied? | 17:16 |
| apw | Keybuk, looks interesting ... will do | 17:18 |
| * hyperair scratches his head regarding inotify issues in the current git kernel | 18:01 | |
| hyperair | inotify_init() = -1 EMFILE (Too many open files) | 18:02 |
| hyperair | damn strange | 18:02 |
| Keybuk | hyperair: checked the available watches? | 19:05 |
| Keybuk | there are per-user limits on such things | 19:05 |
| hyperair | Keybuk: how do i check? | 19:05 |
| hyperair | Keybuk: i noticed it happened after restarting nautilus a few times | 19:05 |
| hyperair | i was testing nautilus-share, see | 19:05 |
| Keybuk | see if inotify_init() returns -EMFILE ;) | 19:05 |
| Keybuk | EMFILE The user limit on the total number of inotify instances has been | 19:06 |
| Keybuk | reached. | 19:06 |
| Keybuk | cat /proc/sys/fs/inotify/max_user_instances | 19:06 |
| Keybuk | then try poking a larger number than 128 into it | 19:06 |
| Keybuk | echo -n 1024 > /proc/sys/fs/inotify/max_user_instances | 19:06 |
| Keybuk | is a good start | 19:06 |
| Keybuk | you may want to increase /proc/sys/fs/inotify/max_user_watches at the same time (number of directories you can watch) | 19:07 |
| hyperair | hmmm | 19:07 |
| hyperair | well i do know that inotify_init definitely returned EMFILE | 19:07 |
| hyperair | strace of conky showed it | 19:07 |
| Keybuk | increase the maximum then | 19:07 |
| hyperair | too late. i already rebooted | 19:08 |
| Keybuk | :p | 19:08 |
| hyperair | logging out and logging back in didnt help for some reason =\ | 19:08 |
| Keybuk | yeah, something was holding onto them | 19:08 |
| Keybuk | usually it's something like tracker, beagle, banshee, etc. | 19:08 |
| hyperair | banshee has no inotify support just yet | 19:08 |
| Keybuk | a session-bus activated service most likely | 19:08 |
| Keybuk | since they won't go necessarily away when you log out | 19:08 |
| hyperair | tracker and beagle don't run on my notebook | 19:08 |
| hyperair | i'm pretty sure banshee goes away though | 19:08 |
| hyperair | i should have done a killall -u hyperair then | 19:09 |
| hyperair | is there any way to check which processes are holding which inotify handles? | 19:09 |
| Keybuk | I tend to do kill -TERM -1 | 19:09 |
| Keybuk | then kill -KILL -1 | 19:09 |
| Keybuk | after logging in as me | 19:09 |
| hyperair | what's -1? | 19:09 |
| Keybuk | lsof will tell you | 19:09 |
| Keybuk | hyperair: "all" | 19:09 |
| hyperair | ah | 19:09 |
| Keybuk | if you don't do it as root, it just kills all yours | 19:09 |
| hyperair | yeah i know | 19:10 |
| hyperair | never thought of doing that | 19:10 |
| apw | Keybuk, the kernel you wanted is uploading to: http://people.ubuntu.com/~apw/tmpfsdev-karmic/ ... should be complete shortly | 19:22 |
| manjo | smb, apw dm-raid45 loads as a module | 19:29 |
| manjo | single module | 19:29 |
| manjo | tested on karmic | 19:29 |
| manjo | 64 bit | 19:29 |
| apw | excellent, is that after removing the exports? | 19:29 |
| manjo | well had to remove the file entirely coz its already building in /drivers/md | 19:30 |
| manjo | and nothing was using it in ubuntu/ | 19:30 |
| smb | which one | 19:30 |
| apw | which file? | 19:30 |
| manjo | dm-region-hash.c | 19:30 |
| smb | sorry I lost my crystal ball | 19:30 |
| smb | but the patch makes changes to region hash | 19:31 |
| apw | manjo, but the only reason thats there is cause it got changed ... what smb said | 19:31 |
| manjo | I left the changes in /drivers/md... are you guys thinking of having 2 copies of the same ? | 19:32 |
| apw | no the changes should have been moved over | 19:32 |
| apw | and the original restored | 19:32 |
| manjo | the changes cannot be moved over coz there are dependcies | 19:33 |
| apw | i mean apply the changes, copy the | 19:33 |
| apw | whole of the changes file | 19:33 |
| apw | changed file | 19:33 |
| apw | and then restore the original? | 19:33 |
| manjo | ah yes then you will have 2 copies of the same file | 19:33 |
| === bjf is now known as bjf_afk | ||
| manjo | coz the patch changes the header file as well | 19:33 |
| apw | yes, we will but at least the original is unchanged, and cannot regress | 19:34 |
| apw | bring the .h file over to the same place too | 19:34 |
| manjo | ok I see what you mean... heh that is hack | 19:34 |
| apw | yes, but it is the safe hack | 19:34 |
| manjo | okies | 19:34 |
| apw | the normal people with the original dm get the original code | 19:34 |
| manjo | will do that now | 19:34 |
| apw | and 0 chance of a regression, the people who opt in to the new driver get the risk | 19:35 |
| apw | we are risk averse | 19:35 |
| manjo | hmm some how its botched way of doing it ... but less risky ofcourse | 19:36 |
| apw | yes it is indeed botched, but that is the risk averse way | 19:36 |
| manjo | k I am on it | 19:36 |
| mahfouz | I had a problem today with 2.6.30-10-generic in jaunty | 20:07 |
| mahfouz | talked to the people in #kernel but they only started a distro flame war | 20:08 |
| mahfouz | starting up with 2.6.30-10-generic, I get the splash screen all the way to the end but then an unresponsive black screen | 20:08 |
| mahfouz | it worked yesterday, but today it didn't anymore, even though there were no updates afaik | 20:08 |
| maxb | mahfouz: Well the obvious response is "If a karmic kernel doesn't work in jaunty, how about trying *Jaunty's* kernel with Jaunty? | 20:32 |
| mahfouz | because it screws up my intel video | 20:32 |
| mahfouz | I downloaded 2.6.30-10-generic from jaunty repo, you know? | 20:33 |
| maxb | No, you didn't. | 20:33 |
| mahfouz | It was in there temporarily, but now seems to be removed | 20:33 |
| mahfouz | I did | 20:33 |
| mahfouz | maybe it was xorg-edgers | 20:33 |
| mahfouz | yes, I downloaded 2.6.30-10-generic from the xorg-edgers ppa | 20:43 |
| mahfouz | but it worked at first and today it didn't boot anymore | 20:43 |
| amitk | bjf_afk: did you solve your xmodem problem? | 21:18 |
| bjf_afk | amitk, yes I did, user error | 21:19 |
| pgraner | dtchen: ping... when your around :-) | 21:43 |
| amitk | bjf_afk: http://pastebin.ubuntu.com/207169/ this is bad right? (size of uploaded kernel vs. size of default kernel partition in redboot) | 22:05 |
| === bjf_afk is now known as bjf | ||
| bjf | amitk, yes, that looks wrong | 22:11 |
| bjf | amitk, got to look at my notes | 22:11 |
| bjf | amitk, no | 22:12 |
| * amitk is not too familiar with redboot | 22:13 | |
| bjf | amitk, the size you uploaded is 0x1C5463 which fits | 22:17 |
| amitk | bjf: duh, I was forgetting the '1' in the start address | 22:19 |
| bjf | amitk, :-) | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!