[01:23] <kseise> Is this the right channel to ask about creating a custom kernel for a noobie?
[01:59] <xaashi> hi where would be a good place to get help with tcpdum
[01:59] <xaashi> tcpdump :)
[01:59] <xaashi> oops wrong channel., sorry
[10:32] <Kano> hi apw , did you see 2.6.30 final?
[10:33] <apw> Kano, yep saw it.  but the repos are down at the moment
[10:33] <Kano> well kernel.org only has got the tar it seems
[10:34] <apw> the rebase will appear when i can get the tree
[10:34] <Kano> good to know
[10:47] <Kano> git seems to be back
[11:56] <JarekMk> Hi
[11:56] <JarekMk> I'm useing Ubuntu 9.04 and have a question, if I install kernel 2.6.30 - it's safety?
[11:57] <JarekMk> someone use it?
[11:59] <apw> JarekMk, cirtinaly members of the kernel team are running both mainline 2.6.30 and Karmic 2.6.30 based kernels on their Jaunty userspace
[12:02] <JarekMk> so it's safe to use it?
[12:11] <Kano> well when you use fglrx then the u kernel will not help you
[12:49] <amitk_> JarekMk: since the kernel is so HW-dependent(!), it is hard to say. But you can always boot up with the old kernel if the new ones causes regressions.
[12:51] <JarekMk> you have right, I've be a men and do this :)
[12:51] <Kano> which gfx card?
[13:14] <apw> JarekMk, there is always risk ... all we can definatly safe is those who have tried here have had no issues, as kano indicates binary drivers are an issue as they do not exist for these updated kernels
[13:18] <smb> The graphics drivers are dkms'ed. Though there is always a chance that upstream has changed in a way, that lets them fail to re-compile.
[13:18] <Kano> they dont exist for u, but they do for my system ;)
[13:20] <Kano> i gave you several times the patches which would allow fglrx (with patches of course) to work
[13:22] <Kano> new nv drivers work with 2.6.30 directly, old ones need a simple patch
[13:24] <CarlFK1> http://kernel.ubuntu.com/~kernel-ppa/  does that work with apt-get, or do i have to use wget/dpkg ?
[13:27] <smb> CarlFK1, Those you neew to wget/dpkg
[13:27] <CarlFK1> thought so, the ppa thing made me wonder 
[13:27] <CarlFK1> thanks
[13:27] <smb> s/neew/need&
[13:27] <smb> Arg, fingers... 
[13:28] <CarlFK1> is ok... I think I understand :)
[13:28] <smb> CarlFK1, The name is slightly misleading but a real PPA would not allow to keep the older kernels
[13:30] <smb> CarlFK1, BTW, you had the problem with pauses during boot, too. iirc
[13:30] <CarlFK1> yeah, still pausing 
[13:30] <smb> You could try acpi_skip_timer_override
[13:31] <smb> Finally got a system with the same symptoms with c1e enabled
[13:31] <smb> And it turned out the problem is an incorrect timer interrupt override. Unfortunately I currently see no way to automatically fix that
[13:33] <CarlFK1> I have a new laptop, so unless it will help you test it, there isn't much value for me to fix 
[13:33] <CarlFK1> would it help you?
[13:34] <smb> Not much further. I think I understand the problem. Though for the solution one would need the documentation of various chipsets, which isn't likely to happen so soon
[13:34] <smb> Just thought, if you still have the problem with that laptop it can help you
[13:34] <CarlFK1> thanks
[13:38] <CarlFK1> what Is a problem with that laptop, and I have a hunch others, will test 'soon') is a panic: http://bugzilla.kernel.org/show_bug.cgi?id=13075
[13:38] <ubot3> bugzilla.kernel.org bug 13075 in Other "kernel BUG at /build/buildd/linux-2.6.27/net/core/skbuff.c:128!" [Normal,New] 
[13:38] <CarlFK1> which is why I am trying daily vanilla kernel 
[13:39] <CarlFK1> there is no way to script "get latest kernel" is there?
[13:40] <CarlFK1> make that 'easy' way...
[13:42] <CarlFK1> VER=2.6.30-999-generic_2.6.30-999.1244629645 makes me grumpy :)
[13:42] <smb> CarlFK1, apw should know more of the details. But there is a daily dir with <date> subdirs... Might be a way to do a script
[13:42] <CarlFK1> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-06-10/  
[13:43] <apw> CarlFK1, i can't think of a way to make that work with the web based stuff we have there
[13:43] <smb> The version had to be sufficiently away from "real" ones, so the 999 abi
[13:43] <CarlFK1> I could probably construct that date, no clue where 1244629645  comes from
[13:43] <apw> thats the time it was built
[13:44] <apw> used to make the 999.NNNN uniquue
[13:44]  * smb wonders whether wget can work with wildcards...
[13:44] <apw> you can likely just wget the directory -R
[13:44] <CarlFK1> apw: "with the web based stuff we have there"  is there some other source that would be easier to script?
[13:45] <apw> CarlFK1, nope there is no other source right now ... you want a PPA for upgrades
[13:45] <CarlFK1> hmm... and then dpkg -i xxx*yyy.deb 
[13:45] <apw> but as smb says thast doens't do 'keep the last N' functionality we require
[13:45] <CarlFK1> I think your -R thing will do the trick
[13:46] <apw> we are always looking to improve things.  will put something on my todo to see if we can make it easier
[13:46] <CarlFK1> I was just trying to avoid having to look at the dir listing and cut/paste the 1244629645 timestamp into a script.
[13:47] <apw> would recording that information separatly help in some way?
[13:47] <CarlFK1> a 'current' symlink near the top of the tree would be handy 
[13:47] <apw> like a current file with the numbers, or a ... current symlink ...
[13:47] <apw> will see what we can do there
[13:49] <CarlFK1> groovy.  I can spend more time crashing my kernel :)
[13:49] <apw> that does sound somewhat massocistic for sure
[13:52] <CarlFK1> the panic seems to be related to using both firewire and nic, currently I need to run dvgrab to work the firewire. any idea how I can move data over firewire using a more generic command? like I am using nc to create network traffic 
[13:55] <CarlFK1> networking over firewire is better than "get a dv camera, run an app" ... really trying to avoid having anything plugged in, but I don't think that;s going to happen
[13:55] <smb> Hm, not really. Not even owning something that does firewire... 
[13:55]  * apw neither
[14:04] <CarlFK1> i think a firewire kernel module dev is on the dvgrab mail list... maybe he can help
[14:06] <smb> Fair. Just remembered I actually _have_ something with a firewire connector. Just no cables. Some USB/firewire harddisk housing. That probably could do traffic simpler...
[14:10] <CarlFK1> http://www.monoprice.com/products/product.asp?c_id=103&cp_id=10301&cs_id=1030102&p_id=1991&seq=1&format=2  $1.44 plus  $1.73 shipping
[14:10] <CarlFK1> feel free to send me a bill, which I will pass on to the PSF :)
[14:14] <smb> heh, yeah. looking which machines have the other end it looks like I need a 6-6 pin. Anyhow it was rather a matter of "why". Maybe now... ;-)
[14:55] <cjwatson> smb: wget and wildcards> try lftp
[14:56] <cjwatson> it can talk HTTP and you can do 'mget <wildcard>'
[14:56] <smb> CarlFK1, that might be interesting to you ^^^
[14:56] <smb> cjwatson, thanks
[14:56] <CarlFK1> thanks, thanks
[15:04] <mr_claus_> hi, where i can find the diff.tar.gz of the compiles mainline kernels?
[15:04] <mr_claus_> on http://kernel.ubuntu.com/~kernel-ppa/mainline/ are only the binaries
[15:05] <CarlFK1> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-06-10/linux-source-2.6.30_2.6.30-999.1244629645_all.deb ?
[15:06] <CarlFK1> duh no if the diff is there...
[15:10] <apw> mr_claus_, there is only the full source tarball
[15:13] <apw> that said it would likely not be so hard to produce a raw delta from the base release and we could then get rid of the source tarball which is huge
[15:21] <mr_claus_> apw: ok, thx, i didn't look in the source deb
[15:21] <CarlFK1> smb: "is this mainline?"  yes if this is that: http://kernel.ubuntu.com/~kernel-ppa/mainline
[15:21] <apw> its not necesarily ideal
[15:22] <smb> CarlFK1, You got me slightly confused
[15:23] <CarlFK1> smb: oh wait... you are not: Stefan Richter 2.6.29-02062901-generic  Is this mainline?
[15:24] <smb> CarlFK1, No, just another Stefan
[15:29] <mr_claus_> apw: so the huge tarball is just an copy of kernel.org?
[15:29] <apw> that tarball is a copy of the source from which the binaries were made
[15:33] <mr_claus_> apw: and the binaries are made from the kernel.org sources withtout any changes right?
[15:33] <apw> right.  the source is basically pointless in my view as we are building from mainline
[15:34] <apw> so you can get the same source from linus' tree via the tag we built
[15:34] <apw> but we had complaints without it so i included them for completeness
[15:34] <apw> the only changes we make are to add the build machinary so we can make .deb no changes to the actual mainline sources are applied
[15:36] <mr_claus_> apw: the build machinery is the most important part :)
[15:36] <apw> that is available in our ubuntu trees which are also public
[15:37] <Loc_Vyler> Hello everybody. I'm trying to go in kernel development and using vanilla kernel with my ubuntu. So, I take config of ubuntu stock kernel and apply it to vanilla kernel. I noticed big difference in HDV performance, ubuntu stock kernel performs much better (everything but kernel is the same). Are there any secret in stock kernel? :-)
[15:37] <Loc_Vyler> I mean I looked through ububtu specific patches and found nothing special about that. I use the same config with the same Timer frequency and Preemption Model.
[15:37] <mr_claus_> so the ./debian is the same like the ubuntu release packages?
[15:37] <Loc_Vyler> Just disabled Kernel hacking and CONFIG_DEBUG_INFO=y and CONFIG_DEBUG_KERNEL=y that was in stock config (that is strange thing to be enabled).
[15:45] <Loc_Vyler> Sorry for dummy question, but I can't find answer anywhere else. I hoped you guys can send me to the right direction
[15:46] <mr_claus_> probably there are patches in the stock kernel, you can download it and check out if there is something which depends on HDV
[15:55] <Loc_Vyler> I don't think there are _special_ HDV patches :-), but some ordinary performance tuning that indirectly influenced on that
[16:03] <mr_claus_> as you used the stock config with the vanilla kernel there is no difference, only the patches on kernel and drivers i think
[16:09] <Loc_Vyler> sure, you right.
[16:10] <CarlFK1> cat /etc/rc.local = screen -S ckdvs /home/carl/vga2usb/dvs/ckdvs1.sh
[16:10] <CarlFK1> I see on the console "pick a screen profile 1...2...3..."
[16:10] <CarlFK1> how do I get rid of that?
[16:12] <CarlFK1> ckdvs1.sh is the scrip that causes the kernel panic... trying to get some stats on how long it takes
[16:12] <CarlFK1> why I am asking here.
[16:14] <CarlFK1> nm... I gotta run for the day
[16:30] <Kano> apw: where is your rebase
[16:30] <apw> test building before i push it
[16:31] <Kano> slow cpu?
[16:32] <apw> i was held up by the git outage on kernel.org
[16:32] <apw> and i am somewhat careful so i like to be sure the whole stack builds first
[16:33] <apw> it'll be there today when i am happy
[16:34] <Kano> ok
[16:34] <Kano> will watch a movie then instead of waiting all the time ;)
[16:34] <apw> heh a good plan.  i am eyeing up a cold beer
[16:35] <smb-topper> Heh, I am eying a whole pub of beer
[16:39] <cking> it's not beer time? surely?
[16:40] <mr_claus_> it's beer time :)
[16:43] <cking> in a 24x7 world, it's always beertime somewhere
[16:54] <mr_claus_> apw: the mainline packages are built with http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.28-11.42.diff.gz except patches, the build system is the same and can copied?
[16:55] <apw> mr_claus_, thats basically it yes.  we get the latest tree from the nearest distro kernel, replace the source tree and then build it
[16:59] <Sarvatt> apw: might want to use drm-next-merge instead of drm-next-radeon next time you build one of those :D
[16:59] <apw> Sarvatt, whats that got in it?
[17:00] <Sarvatt> looks more up to date getting ready for the merge -- http://cgit.freedesktop.org/~glisse/drm-next/log/?h=drm-next-merge
[17:01] <apw> Sarvatt, thanks for the headds up will go look at it
[17:03] <mr_claus_> apw: ok, thx, anyway it would be nice to get a delta with the mainline build, even if it's not much work to get it from the distro kernel
[17:04] <apw> i've put an item to investigate what we can produce a diff from
[17:04] <apw> onto my todo list
[17:07] <mr_claus_> ty
[18:19] <apw> Keybuk, 1) did you see my pointer to the unionfs kernel, 2) would it be fair to say you understand LSB headers for init scripts?
[18:19] <Keybuk> apw: yes, yes
[18:19] <Keybuk> haven't tested it though yet ;)
[18:20] <apw> would you be able to cast an eye over the proposed change for linux-restricted-modules on bug #305587 for me
[18:20] <ubot3> Malone bug 305587 in linux-restricted-modules "[Jaunty] warning: missing LSB information " [Medium,In progress] https://launchpad.net/bugs/305587
[18:24] <Keybuk> do you mean start in 0 and 6?
[18:24] <Keybuk> i guess you do ;)
[18:24] <Keybuk> so yeah that looks right
[18:24] <apw>     dh_installinit -p linux-restricted-modules-common --no-start -- start 7 S . start 1 0 6 .
[18:24] <apw> we install it thusly at the moment
[18:24] <apw> Keybuk, excellent ... will push that to our list for acks etc and get it in...
[18:34]  * Keybuk battles with Automake
[18:34] <Keybuk> Automake strikes
[18:34]  * Keybuk dies
[18:53]  * apw lobs Keybuk a ring of regeneration
[18:55] <Keybuk> an ironic choice of item, given that it's source regeneration I'm having issues with ;)
[19:34] <Kano> apw: i enabled lzma compression for kernel
[19:35] <Kano> gives 3.1 mb instead of 3.8 mb kernel size
[19:35] <Kano> 64 bit
[19:35] <Kano> 3,8M 29. Mai 19:20 vmlinuz-2.6.30-8-generic
[19:35] <Kano> 3,1M 10. Jun 20:21 vmlinuz-2.6.30-9-generic
[19:35] <Kano> absolutely uncritical to use
[19:36] <Kano> CONFIG_KERNEL_LZMA=y
[19:36] <Kano> now
[19:37] <Kano> also the initramfs could be compressed with lzma
[19:39] <Keybuk> we don't really need to do that though
[19:39] <Kano> you save lots of space in live mode, as you have the kernel+initrd twice on live media
[19:40] <Keybuk> at the cost of slower decompression
[19:40] <Keybuk> also 700KB is not "lots of space"
[19:40] <Kano> DEcompression is really fast
[19:40] <Keybuk> it's less really fast than gzip
[19:41] <Kano> the compression for the initrd takes a while thats correct,but i see no problem for the kernel image, as you precompile it
[19:44] <Kano> also 700kb * 2 usually
[19:44] <Kano> thats only for the kernel
[19:44] <Kano> the initrd could be even better compressed
[19:57] <apw> Keybuk, the trade off is how long grub takes to load the poo as against how long it takes to decompress.  that compression advantage doesn't seem vry big
[20:06] <Kano> initrd with lzma -9 compared to gzip: 6.7M vs. 10M
[20:06] <Kano> so you save combined 8mb for live images
[20:09] <apw> hrm, that might be measurable on load via grub ... dunno
[21:07] <dhendrix> whoa, sweet! I didn't even know this channel existed. So has anyone tried building linux-source-2.6.30 lately? I'm getting an error about linux-2.6.30/ubuntu/gfs missing a Makefile.
[22:07] <soren>   /win 40
[22:07] <soren> Whoops