=== Guest77821 is now known as NCommander | ||
=== NCommander is now known as Guest33254 | ||
=== Guest33254 is now known as NCommander | ||
=== NCommander is now known as Guest82317 | ||
=== Guest82317 is now known as NCommander | ||
=== yofel_ is now known as yofel | ||
Keybuk | apw: when's your next upstream-tree-of-the-day-build due? | 12:42 |
---|---|---|
apw | they build about 10am | 12:42 |
Keybuk | 23-Jul was the last? | 12:43 |
Keybuk | oh, no, daily | 12:43 |
Keybuk | sorry, mis-understood your directory structure | 12:43 |
apw | heh :) | 12:43 |
Keybuk | any way to know what the git log/revno of a given build was? | 12:43 |
apw | the last -rc was 23rd | 12:44 |
apw | at the top of the build log | 12:44 |
Keybuk | why the -g ? | 12:44 |
apw | long<v2.6.31-rc4-198-g7d3e91b> | 12:44 |
apw | thats the form git uses for describing a commit | 12:44 |
apw | the short form of the sha1 follows the -g | 12:45 |
Keybuk | ah | 12:45 |
Keybuk | got it | 12:45 |
Keybuk | that has the patches I need to ack | 12:45 |
* Keybuk downloads to test | 12:45 | |
apw | though i also report the full commit after the checkout there | 12:45 |
apw | vvv - build head | 12:45 |
Timmy2Tall | Home is where the heart is | 13:03 |
Timmy2Tall | would you agree? | 13:03 |
=== akgraner_ is now known as akgraner | ||
maks_ | hello Keybuk | 13:57 |
maks_ | thanks for your write down, will release current state of i-t to have that out of the way and then soonest pick up. | 13:57 |
Keybuk | maks_: busy atm, will get back to you in a bit | 13:57 |
maks_ | no rush needed. Keybuk | 13:57 |
Keybuk | great! :) | 13:57 |
dk_ | hi | 14:52 |
dk_ | i have questions | 14:52 |
dk_ | i have a Netbook acer aspire one, and i want compile the kernel for the best performace | 14:55 |
rtg | dk_, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance | 14:58 |
rtg | apw, we don't have a single example of request-pull in any of the git recipe pages. | 14:59 |
apw | rtg, thats poor, i can fix that | 14:59 |
rtg | apw, the reason I was looking is the I cannot get one of my request-pull examples to work, so I was just making sure i didn't have brain damage | 15:00 |
apw | whats it doing wrong reporting lots and lots of patches? | 15:00 |
rtg | apw, it can't find the repo on zinc. | 15:01 |
apw | wanna paste the line here or in /query that you are using | 15:01 |
rtg | apw, actually, there is an example: https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide?highlight=(request\-pull) | 15:01 |
rtg | apw, here is my example: git request-pull HEAD~1 git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git | 15:02 |
apw | your branch won't be in the ubuntu karmic repo though will it | 15:02 |
apw | ? | 15:02 |
rtg | apw, I tried my repo as well | 15:03 |
apw | normally its in your personal one | 15:03 |
rtg | git request-pull f493e5ae7f0799a45f25e6f0595e32e95990c67d git://kernel.ubuntu.com/rtg/ubuntu-karmic | 15:03 |
apw | ok so its definatly yours as the last param | 15:03 |
apw | and you have pushded the commit as which branch in your repo? | 15:03 |
rtg | apw, this is just master, and I'm synced. | 15:04 |
rtg | it should be a no-brainer | 15:04 |
* apw looks | 15:04 | |
rtg | apw, how about you, can you get a request-pull to work correctly? | 15:04 |
apw | just testing with your repo | 15:05 |
apw | rtg ok a request pull can only be for a commit which is the head of a branch | 15:07 |
apw | so you'd have to have pushed HEAD~1 as a branch tip | 15:07 |
apw | so the one you are trying there f493e5ae7f0799a45f25e6f0595e32e95990c67d is master~2 | 15:09 |
apw | so if you want to send a request pull for that you need to do like | 15:09 |
dk_ | rtg: i was compiling my kernel for acer aspire one, but i need more help::) | 15:09 |
apw | git push zincremote master~2:pullme | 15:09 |
apw | and then the request-pull will work | 15:09 |
rtg | apw, I don't think thats correct. I just updated against the core repo (I guess I wasn't synched). This works fine (notice I can specify a commit prior to HEAD) : git request-pull HEAD~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic | 15:10 |
rtg | dk_, do it the long way first. install devscripts, then 'debuild -b' and follow the bouncing ball. | 15:11 |
apw | rtg ok we are both using it wrong | 15:12 |
apw | or i am understanding you wrong | 15:12 |
apw | git request-pull HEAD~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic | 15:12 |
rtg | apw, my understanding of the SHA1 in request-pull is that is where you'd like the pull to start from. | 15:13 |
apw | does not ask for HEAD~1 to be the thing to pull, that says list from after HEAD~1..HEAD on the page, and find HEAD in the repo | 15:13 |
apw | ie the HEAD~1 there is the commit before the first one you want mentioned, but it is trying to find your current branch in there | 15:13 |
apw | you can add a commit tip as param 3 | 15:14 |
apw | but either way that needs to be in the pushed repo as a head | 15:14 |
apw | git request-pull f493e5ae7f0799a45f25e6f0595e32e95990c67d git://kernel.ubuntu.com/rtg/ubuntu-karmic | 15:14 |
apw | arrg | 15:14 |
apw | git request-pull rtg/master~1 git://kernel.ubuntu.com/rtg/ubuntu-karmic rtg/master | 15:15 |
apw | so that says ... generate a request to pull the commits from rtg/master~1 to rtg/master | 15:15 |
apw | the final param must be a the sha1 of a tip in the repo in param 2 | 15:15 |
rtg | apw, I think I grok it. I just wasn't properly synced. Its just like forgetting to see if your mixer is plugged in when it won't turn on. | 15:16 |
apw | i happen to be using your branches there | 15:16 |
* apw notes he got its use wrong again and once again had to read the manual. its not an obvious interface to me | 15:17 | |
rtg | apw, true, but at least request-pull tells you when its confused. | 15:18 |
dk_ | rtg: speak spanish? | 15:18 |
rtg | dk_, nope. | 15:18 |
dk_ | ok | 15:18 |
apw | rtg it should just say, "look read the manual, trust me its quicker" | 15:18 |
rtg | :) | 15:19 |
=== lamont` is now known as lamont | ||
apw | Keybuk, how common across distros is the modprobe blacklist stuff? is it ubuntu specific? | 15:34 |
Keybuk | apw: the blacklist files, or the contents of them? | 15:36 |
apw | the format and support for the functionality | 15:36 |
Keybuk | oh, totally upstream | 15:37 |
Keybuk | we have no patches to module-init-tools | 15:37 |
apw | so if you can find the right place, then a blacklist config can be added, cool | 15:37 |
apw | Keybuk, are we still looking to remove graphics drivers from initramfs? i was supprised to find i915 in mine | 15:39 |
Keybuk | in the common case, yes | 15:40 |
apw | whats the uncommon case? | 15:41 |
Keybuk | see my mail today ;) | 15:41 |
ogra | phew | 15:46 |
* ogra is relived that Keybuk agrees we *do need it* :) | 15:46 | |
apw | Keybuk, thanks ... thats exactly what i needed to know at the moment i needed to know; most fortuitious | 15:48 |
ogra | did anyone ever chack how much ot bloats the kernel if we compile all FB drivers in ? | 15:48 |
Keybuk | ogra: FB drivers are quite closely linked to the X driver | 15:49 |
ogra | or is that breakins | 15:49 |
Keybuk | I don't think we want to compile them in | 15:49 |
ogra | *g | 15:49 |
Keybuk | in fact, in general, I say we should never compile a _driver_ in | 15:49 |
ogra | well, we do so for filesystems | 15:49 |
ogra | and that was actually a noticeable speedup | 15:49 |
Keybuk | only ext4 | 15:49 |
Keybuk | ext* sorry | 15:50 |
Keybuk | and those aren't really drivers | 15:50 |
ogra | fuse too | 15:50 |
apw | we tend to compile in commonly used filesystems yes | 15:50 |
apw | drivers we tend to make modules | 15:50 |
ogra | and nfs i think | 15:50 |
Keybuk | again, not a driver | 15:50 |
apw | Keybuk, have you tried switching the initramfs to lzma ? | 15:50 |
Keybuk | driver sits on a bus | 15:50 |
ogra | indeed | 15:51 |
maks_ | -rw-r--r-- 1 root root 6314398 2009-07-29 16:48 /boot/initrd.img-2.6.31-rc4-amd64 | 15:51 |
maks_ | contrast too | 15:51 |
maks_ | -rw-r--r-- 1 root root 10655820 2009-07-29 10:10 /boot/initrd.img-2.6.31-rc4-amd64.bak | 15:51 |
rtg | Keybuk, so you are arguing that we should only be compiling in drivers that are essential to mount the rootfs. udev can do the rest (for the common case). | 15:52 |
ogra | apw, please make that optional, we have massive probs on ARM with lzma | 15:52 |
Keybuk | apw: I'd like to see the benchmarks of decompress time first | 15:52 |
Keybuk | rtg: that's what we do | 15:52 |
Keybuk | rtg: I think the only driver we compile in, in practice, is the Intel PIIX driver no? | 15:52 |
rtg | Keybuk, thats what I though we were doing, just wanted to confirm. | 15:52 |
Keybuk | things that it makes sense to compile in | 15:53 |
Keybuk | - modules that we force load for everybody unconditionally | 15:53 |
apw | Keybuk, its slower to decompress, but a lot smaller to load | 15:53 |
Keybuk | - core kernel functionality that it makes no sense to be an option (unix.ko, printk.ko, etc. :p) | 15:53 |
rtg | Keybuk, actually, we compile in _all_ of the block level drivers that are required for a root fs | 15:53 |
apw | so its a trade off between the two | 15:53 |
Keybuk | apw: I'd like to see the timings for that | 15:53 |
Keybuk | decompress should show up as the populate_rootfs() time | 15:54 |
apw | yeah ... and you should just be able to make the initrd which ever way you prefer | 15:54 |
apw | the kernel should understand both | 15:55 |
ogra | on ARM its like 10x slower to compress/decompress | 15:55 |
apw | i would think on netbooks gzip is faster, on faster boxes i would think lzma probabally is | 15:55 |
apw | ogra, yep, but as the kernel understands both you can choose the faster one | 15:56 |
ogra | in fact we have massive build failures on arm for all packages using lzma because the ddeb compressing times out after 3h | 15:56 |
apw | if your initrd is in flash you may decide not to compress it | 15:56 |
ogra | its on SD | 15:56 |
ogra | or various forms of disks depending on the HW | 15:56 |
ogra | we dont use flash on any of the supported SoCs | 15:57 |
apw | all i am saying is it is an option ... not trying to make one or the other the right one | 15:58 |
apw | was just interested if Keybuk had poked that pile of ants in his review of boot speed | 15:58 |
maks_ | smaller initramfs also builds faster, as added bonus :) | 16:00 |
apw | cking, that kernel i was tlaking about is here: http://people.canonical.com/~apw/lp318942-jaunty/ | 17:00 |
cking | apw, cheers, will test. | 17:02 |
cking | apw, yep some audio, and crackly reboot sound too | 17:13 |
apw | so the audio is 'working' but the thingy you said was bust is | 17:14 |
cking | apw, yep. Let me do some other tests (headphone, suspend/resume etc) to make sure it's all fine. | 17:14 |
apw | Keybuk, sorry to ask yet again, but where might i find info on the vt7->vt1 switch | 17:15 |
cking | apw, speakers work, headphones plug in works, headphones unplugged => no sound out of speakers. | 17:24 |
apw | crap | 17:24 |
cking | lemme have a poke around. | 17:24 |
cking | apw, you're 95% the way there. It's just that weird hda pin stuff that needs some massaging | 17:32 |
rtg | cking, you mean that 128 bit magic array of bits? | 17:33 |
cking | something that way. It's not too difficult when one has the data sheet. However, I don't have the data sheet :-) | 17:33 |
rtg | cking, thats what makes it magic. how often can you procure the data sheet for a motherboard? | 17:37 |
cking | ..rarely. But there are ways and means... | 17:37 |
apw | cking, it is meant to work in karmic if that helps | 18:02 |
cking | really? I will give that a try and make sure. | 18:02 |
cking | I will pick this up tomorrow. I've got some family deadlines tonight | 18:03 |
apw | just the kernel should be sufficient | 18:03 |
apw | and thanks for that | 18:03 |
cking | I could not apply your 3rd patch onto jaunty, I got: | 18:04 |
cking | Applying: UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family | 18:04 |
cking | error: sound/pci/hda/Makefile: does not match index | 18:04 |
cking | error: sound/pci/hda/hda_codec.c: does not match index | 18:04 |
cking | error: sound/pci/hda/hda_patch.h: does not match index | 18:04 |
cking | Patch failed at 0001 UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family | 18:04 |
cking | ?? | 18:05 |
cking | rats, my left hand has gone numb, must be my neck pressing on the nerves | 18:06 |
apw | cking, third patch would be 0003? | 18:07 |
apw | cking, what base you applying them to? | 18:09 |
cking | top of the jaunty repo. | 18:09 |
apw | thats where they are in my tree | 18:09 |
cking | lemme retry. could be a typo, my left hand is out of action | 18:10 |
apw | d2d686f4ff11f7cde54e30ddab3886936f4101d8 is the tip i am on | 18:10 |
apw | and remember they apply in numeric order | 18:11 |
cking | 0001, 0002, then 0003 -> probs | 18:11 |
cking | d2d686f4ff11f7cde54e30ddab3886936f4101d8 is the tip too | 18:12 |
apw | cking, sum those patches | 18:13 |
apw | as i just applied them from my rookery copy | 18:13 |
apw | apw@dm$ git am ~/rookery/lp318942-jaunty/????-* | 18:13 |
apw | Applying: UBUNTU: SAUCE: copy the hda sigmatel codec driver for the HP mini family | 18:13 |
cking | 5a65225dec284daf299a8d6711e99595 0001-UBUNTU-SAUCE-copy-the-hda-sigmatel-codec-driver-for-.patch | 18:13 |
cking | 0a54f072f5a75c199cd866e5be4971f9 0002-ALSA-hda-Rework-on-STAC-IDT-auto-configuration-code.patch | 18:13 |
cking | 0195e12abb7b4ff2d5f2a73a2b86baf2 0003-UBUNTU-SAUCE-select-the-patched-sigmatel-codec-for-H.patch | 18:13 |
apw | Applying: ALSA: hda - Rework on STAC/IDT auto-configuration code | 18:13 |
apw | Applying: UBUNTU: SAUCE: select the patched sigmatel codec for HP mini family | 18:13 |
apw | sums match | 18:13 |
cking | apw, see my email - got a script of what happens. Most curious. | 18:19 |
apw | cking, oddness, could you ensure you are reset to head correctly | 18:23 |
* apw will push up my branch too ... | 18:28 | |
cking_ | apw, that fixed it. sorry about that | 18:30 |
apw | cking_, np was confused | 18:30 |
* cking_ is surprised he missed that one. doh | 18:32 | |
cking_ | I need to go. Family + left hand issues. | 18:32 |
apw | np | 18:33 |
apw | go | 18:33 |
Alaric` | localtime(time()), folks .... anyone here running 9.04 on an Inspiron 4100? I have a fan problem I'm seeking a solution for. | 18:50 |
Alaric` | capsule summary: the fans on the laptop never run, causing it to overheat, unless I load the i8k module. i8k.ko + i8kmon runs the cooling fans properly, BUT i8k.ko disables the keyboard as soon as it loads, and I can't get the keyboard back except by rebooting without i8k. | 18:50 |
Alaric` | is there a known solution for this? | 18:51 |
* apw hasn't heard of that specific issue | 18:52 | |
Alaric` | (right now I'm compiling a new kernel with a modified i8k.c patched to never try to touch fn-key status, to see whether that's where it's blowing away the keyboard) | 18:53 |
Alaric` | also speculating that it may be an ACPI issue | 18:53 |
apw | have you tried later mainline kernels to see if they work? | 18:53 |
Alaric` | last time my wife (it's her laptop) checked for updates, it wasn't showing a newer kernel available as a package | 18:54 |
apw | no i mean a later mainline build, from the mainline builds archive | 18:55 |
Alaric` | mainline builds archive? | 18:55 |
apw | https://wiki.ubuntu.com/KernelTeam/MainlineBuilds | 18:55 |
apw | those contain builds of later upstream kernels which can be used to see if the issue is fixed later on | 18:55 |
Alaric` | but yeah, once I get the build-kernel-on-ubuntu procedure down, I was thinking of building a 2.6.30.3 | 18:55 |
apw | which can help find it | 18:55 |
Alaric` | hm, lemme check that out | 18:56 |
apw | there are prepackaged 2.6.30 kernels on there | 18:56 |
Alaric` | hm. in this situation, would you go with 1.6.30.3, or 2.6.31.rc3? | 18:57 |
Alaric` | er, s/1.6/2.6/ | 18:58 |
Alaric` | oh, there's an rc4 | 18:58 |
Alaric` | missed it at first | 18:58 |
apw | i would tend to pick the latest first if that works pick one between the distro and that one and try that | 18:58 |
apw | yeah so i'd try -rc4 | 18:58 |
apw | its not intended as a fix, more as a barometer of that feature being fixed | 18:58 |
Alaric` | the linux-source package is equal to the corresponding linux-image plus linux-headers? | 18:59 |
apw | i am suspicious it will not fix things as there does not seem to be much | 18:59 |
apw | nope thats a source package no use generally | 18:59 |
apw | you want the binary and headers and generic headers | 19:00 |
Alaric` | so http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-image-2.6.31-020631rc4-generic_2.6.31-020631rc4_i386.deb, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-headers-2.6.31-020631rc4_2.6.31-020631rc4_all.deb, http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31-rc4/linux-headers-2.6.31-020631rc4-generic_2.6.31-020631rc4_i386.deb? | 19:00 |
Alaric` | oops. forgot those'd get expanded. :p sorry. | 19:01 |
apw | looks about right | 19:01 |
apw | is there a bug for this on launchpad? | 19:01 |
Alaric` | haven't found any reference to it except in way old threads dating from 2.6.8 | 19:03 |
apw | you should file one then, so it can get tracked | 19:03 |
Alaric` | roger that. soon as I get this kernel-with-patched-i8k built and tested. | 19:05 |
Alaric` | if it works, I'll have at least a workaround to attach to the report. | 19:07 |
rtg | apw, whats the script you use to rebase master onto a topic branch, e.h., master --> lpia ? | 19:09 |
apw | you mean to rebase the netbook branches onto a tag ... rebase-branch in the branch | 19:10 |
apw | that reminds me i have a netbook push to do for jaunty | 19:10 |
rtg | apw, I guess. where is it located? | 19:10 |
apw | ./debian/scripts/misc/rebase-branch | 19:11 |
apw | normally you rebase to a tag | 19:11 |
rtg | apw, ah, that script only lives on the netbook branch | 19:12 |
apw | yes, its branch specific right now, am working on removing the last couple of branch specific items | 19:12 |
apw | then we cna commit it to the master | 19:12 |
apw | that reminds me, i have a proposed update to the karmic config system | 19:13 |
apw | which makes it a completely overrides based system | 19:13 |
apw | ie. each level contains only the options which are changed | 19:13 |
rtg | apw, I'd like to use it for the LTS branch, i.e., the hardy branch in the Jaunty tree. | 19:13 |
apw | so you can have a default at the top and only mask it with another value on one flavour or arch | 19:14 |
apw | rtg makes sense for that use for sure | 19:14 |
apw | i will get an email together for this config thing and send it out, prolly in the morning now | 19:14 |
rtg | apw, yeah, isn't it time you were off quaffing beers? | 19:15 |
apw | heh something like that | 19:15 |
]Oscar | does the usb driver send a reset signal to all peripherial while shutting down the pc? | 20:08 |
AnAnt | Hello, I got a directory that has a kernel module how can I avoid a binary blob (.o) file from being deleted by clean target ? | 20:09 |
AnAnt | when I run make -C $KERNELSRC -M $(CURDIR) clean, the blob gets deleted that is | 20:09 |
AnAnt | isn't there an override that I can add to the makefile ? | 20:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!