=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
[12:19] <BenC> successful boot, with nvidia drivers...I think this is ready to upload
[12:45] <Nafallo> BenC: yay!
=== ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-1 (really 2.6.21, but whos counting) | Latest news: -rt and -xen kernels included in build.
[01:03] <ajmitch> BenC: nice, so xen kernel binaries will still fall to universe?
[01:03] <BenC> yes
[01:04] <BenC> xen and rt will be in universe
=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-kernel
[02:17] <BenC> battery life seems pretty good with this tickless kernel
=== jml [n=jml@59.167.203.115]  has joined #ubuntu-kernel
=== pkl_ [n=phillip@lougher.demon.co.uk]  has joined #ubuntu-kernel
=== jml_ [n=jml@59.167.203.115]  has joined #ubuntu-kernel
[03:02] <BenC> awesome, build failures all around
=== reitblatt [n=mark@resnet-50-133.dorm.utexas.edu]  has joined #ubuntu-kernel
=== reitblatt [n=mark@resnet-50-133.dorm.utexas.edu]  has left #ubuntu-kernel [] 
=== MrNOKIA1 [n=user@86.121.178.243]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@0-195.dsl.iskon.hr]  has joined #ubuntu-kernel
=== dade` [n=dade@85-18-201-175.ip.fastwebnet.it]  has joined #ubuntu-kernel
=== dade` [n=dade@85-18-201-175.ip.fastwebnet.it]  has joined #ubuntu-kernel
=== dade` [n=dade@85-18-201-175.ip.fastwebnet.it]  has left #ubuntu-kernel [] 
=== sb73542 [n=Sully@200.107.49.51]  has joined #ubuntu-kernel
=== sb73542 [n=Sully@200.107.49.51]  has left #ubuntu-kernel [] 
=== m0rg0th [n=manugarg@220.225.228.97]  has joined #ubuntu-kernel
=== pulkit [n=root@221.134.114.125]  has joined #ubuntu-kernel
=== pulkit [n=root@221.134.114.125]  has left #ubuntu-kernel [] 
=== bdgraue [n=bdgraue@dyndsl-085-016-027-253.ewe-ip-backbone.de]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@32-36.dsl.iskon.hr]  has joined #ubuntu-kernel
=== qiyong [n=qiyong@fc-cn.com]  has joined #ubuntu-kernel
[08:18] <qiyong> why ntfs is read only? why not rw?
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== abogani [n=alessio@adsl203-157-083.mclink.it]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-145-254-251-234.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== gortiz [n=gortiz@88.87.105.4]  has joined #ubuntu-kernel
=== sky_walkie [i=czzhrd02@xdsl-563.lodz.dialog.net.pl]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@5-14.dsl.iskon.hr]  has joined #ubuntu-kernel
=== cassidy [n=cassidy@host-213-189-171-21.brutele.be]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@21-187.dsl.iskon.hr]  has joined #ubuntu-kernel
=== jml [n=jml@59.167.203.115]  has joined #ubuntu-kernel
=== m0rg0th_ [n=manugarg@220.225.228.97]  has joined #ubuntu-kernel
=== bdgraue [n=bdgraue@dyndsl-085-016-027-253.ewe-ip-backbone.de]  has joined #ubuntu-kernel
=== gicmo [n=gicmo@p5491E2BC.dip.t-dialin.net]  has joined #ubuntu-kernel
=== m0rg0th_ [n=manugarg@220.225.228.97]  has joined #ubuntu-kernel
=== n2diy [n=darryl@66.212.42.141]  has joined #ubuntu-kernel
=== bdgraue_ [n=bdgraue@dyndsl-085-016-169-160.ewe-ip-backbone.de]  has joined #ubuntu-kernel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-kernel
=== smurf [n=smurf@debian/developer/smurf]  has joined #ubuntu-kernel
=== m0rg0th [n=manugarg@220.225.228.97]  has joined #ubuntu-kernel
=== EtienneG [n=etienne@ubuntu/member/EtienneG]  has joined #ubuntu-kernel
=== lifeless [n=robertc@ppp245-86.static.internode.on.net]  has joined #ubuntu-kernel
=== tarnap_ [n=verges@24-151.63-81.stat.fixnetdata.ch]  has joined #ubuntu-kernel
[01:54] <tarnap_> i salute you!
=== tarnap_ [n=verges@24-151.63-81.stat.fixnetdata.ch]  has left #ubuntu-kernel ["Ex-Chat"] 
=== sky_walkie [i=czzhrd02@xdsl-563.lodz.dialog.net.pl]  has joined #ubuntu-kernel
=== gortiz [n=gortiz@88.87.105.4]  has joined #ubuntu-kernel
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
[03:50] <Mithrandir> BenC: I've made sure the new kernel builds on palmer now.  Hopefully it won't take too long.
[03:50] <BenC> Mithrandir: thanks
=== alleeHol [n=ach@dialin-145-254-255-184.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== _allee_ [n=ach@dialin-145-254-253-254.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-kernel
=== Keybuk [n=scott@wing-commander.netsplit.com]  has joined #ubuntu-kernel
[04:46] <Keybuk> ya know
[04:46] <Keybuk> it's just occurred to me that it wouldn't be that hard to put hd[a-z] [0-9]  symlinks in place pointing to the libata equivalents
[04:47] <Keybuk> since we know it's libata, we can find out whether it's PATA, and from there work out which controller it is, etc.
[04:47] <Keybuk> and the hd names are controller-predictable
[04:51] <BenC> Keybuk: can you get enough info, like PATA, master/slave and such out of it?
[04:51] <Keybuk> I think all the info is in the sysfs path alone
[04:52] <Keybuk> if not, it shouldn't be hard to add it?
[04:52] <mjg59_> It's not as easy as you'd think
[04:53] <Keybuk> no? ;-/
[04:53] <mjg59_> You want to expose cable type, really
[04:54] <Keybuk> aren't the resource ranges of PATA devices predictable?
[04:55] <mjg59_> Not if they're in native mode
[04:55] <Keybuk> oh well, it was a good idea :)
=== dade` [n=dade@85-18-201-175.ip.fastwebnet.it]  has joined #ubuntu-kernel
=== pkl_ [n=phillip@lougher.demon.co.uk]  has joined #ubuntu-kernel
=== pkl_ [n=phillip@lougher.demon.co.uk]  has joined #ubuntu-kernel
=== pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl]  has joined #ubuntu-kernel
=== johanbr [n=j@JBrannlund.MathStat.Dal.Ca]  has joined #ubuntu-kernel
=== Codename_PBLP [n=Shoaibi@202.163.65.233]  has joined #UBUNTU-KERNEL
=== bdmurray [n=bdmurray@c-24-21-235-175.hsd1.or.comcast.net]  has joined #ubuntu-kernel
[05:54] <bdmurray> BenC: ping
[05:54] <BenC> bdmurray: hey
[05:54] <bdmurray> I'm looking at bug 110168 where the reporter says only one cpu is showing up
[05:55] <bdmurray> I asked for /proc/cpuinfo and sure enough there is only 1 CPU what else should we look at?
[05:59] <dade`> -386 kernel ?
[06:01] <bdmurray> yes
[06:02] <Nafallo> that flavour isn't SMP, right?
[06:02] <Nafallo> so tell him to try with -generic
[06:02] <bdmurray> ah, wrong answer then
[06:03] <bdmurray> yes he is using generic but it is on i386
[06:03] <Nafallo> that's not -386 kernel then ;-)
[06:04] <bdmurray> indeed
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-kernel
[06:13] <BenC> model name : Intel(R) Celeron(R) CPU 2.80GHz
[06:13] <BenC> I don't think that's a dual core cpu
[06:15] <BenC> hmm...maybe it is
[06:18] <BenC> bdmurray: Could be he has multi-core disabled in BIOS...waiting for dmesg
=== bleinmono [n=toffel@ppp91-76-73-141.pppoe.mtu-net.ru]  has joined #ubuntu-kernel
[06:23] <bdmurray> BenC: okay, thanks.  so dmesg would be definitive then?
[06:24] <BenC> dmesg would at least tell us why it didn't probe, or failed to probe the second core
[06:24] <mjg59> Dual-core Celeron? Really?
[06:25] <mjg59> Everything I can find suggests not
=== Zic [n=Zic@Final-Fantasy.FF-IRC.net]  has joined #ubuntu-kernel
=== mdz [n=mdz@yttrium.canonical.com]  has joined #ubuntu-kernel
[06:31] <mdz> pkl_: do you have any thoughts on bug 96084?
[06:31] <mdz> there may be more than one problem there, but it seems certain that there is at least one genuine bug which should be investigated
[06:38] <pkl_> I seem to recall the original bug was something quite weird and unexplained.  If it is still happening, then it should be looked at again.
[06:39] <pkl_> mdz:  I'll have a look at it again, and see if there's anything possible fixes for the first Feisty kernel SRU.
[06:39] <mdz> pkl_: I read over the comments, and I didn't see any which seemed to point to a cause; everyone is going on about the top level symptom (being  dropped to initramfs)
[06:40] <mdz> pkl_: oh, I see a BUG in one of the screenshots
[06:41] <pkl_> mdz: yes, it looked like the probe was passing a NULL string to printk.
[06:44] <mdz> pkl_: could you follow up to the bug with your analysis?  it's a great help both to other developers (to  benefit from your analysis and follow it further) and the community (to know that someone has looked at the bug)
[06:44] <pkl_> mdz: OK
=== Eruantalon [n=hans@5634185c.rev.stofanet.dk]  has joined #ubuntu-kernel
=== ivoks [n=ivoks@2-37.dsl.iskon.hr]  has joined #ubuntu-kernel
[07:20] <lamont> BenC: did the hppa build-fix get uploaded yet?
[07:20] <lamont> just curious
[07:21] <BenC> lamont: feisty SRU hasn't happened yet
[07:21] <lamont> right
[07:21] <BenC> we're trying to snag a couple more fixes
[07:22] <lamont> ok.  was actually meaning to gutsy
[07:22] <BenC> the gutsy upload is strictly 2.6.21 stock source
[07:22] <lamont> we didn't make the window to have feisty/hppa in launchpad, so the target is now to have enough there to make the bootstrap of gutsy easy.
[07:22] <BenC> so if isn't in linux-2.6, then no
[07:22] <Nafallo> feisty is SO yesterday ;-)
[07:23] <BenC> lamont: unless you mean the debian/* fixes, in which case, yes they did make it :)
[07:23] <lamont> Makefile
[07:23] <BenC> yeah, the strip fixes made it into gutsy
[07:23] <lamont> and it needs an hppa.ignore abi file in the gutsy upload as well, until we finally get the abi file back into the source tree...
[07:23] <mrec__> BenC: do you still accept critical bugfixes?
[07:24] <lamont> that's actually true for any ports arch where we don't have the previous abi file.
[07:32] <BenC> mrec__: of course :)
[07:33] <mrec__> http://mcentral.de/hg/~mrec/v4l-dvb-stable/ the last 3 patches.. they're already included in the repository on linuxtv now
[07:33] <mrec__> but linus didn't pull them for 2.6.21
[07:33] <mrec__> http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg23028.html
[07:34] <mrec__> it doesn't solve that problem, but it solves crashing the whole box if it happens at least
[07:35] <BenC> mrec__: any chance we could get some patches against feisty git?
[07:35] <mrec__> BenC: I can prepare them they aren't difficult..
[07:36] <mrec__> even I think they should apply as they are there
[07:36] <BenC> mrec__: If you could just send the request and link to kernel-team@lists.ubuntu.com (feisty in the subject) so pkl can pick it up, that'd be great
[07:37] <mrec__> ok I'll send it tomorrow
[07:37] <BenC> he can probably grab the patches easily, so I wouldn't worry about getting them just for feisty git
[07:38] <mrec__> many interesting things happen now on the multimedia side, Kworld just sent me an email that they're interested in linux support
[07:38] <mrec__> they even sent me windows code :)
[07:38] <mrec__> (to replace some reverse engineered drivers)
[07:41] <pkl_> mrec_:  yeah, please send the link to kernel-team, and I'll pick up the patches from there.  Thanks.
=== jpon [n=jpon@neu67-3-82-239-80-181.fbx.proxad.net]  has joined #ubuntu-kernel
=== bleinmono [n=toffel@ppp91-76-73-141.pppoe.mtu-net.ru]  has left #ubuntu-kernel [] 
=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
=== m0rg0th [n=manugarg@219.64.120.181]  has joined #ubuntu-kernel
=== Eruantalon [n=hans@5634185c.rev.stofanet.dk]  has joined #ubuntu-kernel
[08:54] <BenC> yay, lum uploading
[08:54] <BenC> pretty much gets us at 98% of functionality for gutsy kernel
[08:55] <BenC> cjwatson: btw, there's a new udeb, ubuntu-modules, which contains some scsi and net controllers that used to be in normal udeb's
=== doko_ [n=doko@dslb-088-073-082-203.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== johanbr [n=j@blk-224-156-151.eastlink.ca]  has joined #ubuntu-kernel
=== ash211 [n=andrew@user-1121k7e.dsl.mindspring.com]  has joined #ubuntu-kernel
=== calavera [n=cal@195.Red-80-26-32.staticIP.rima-tde.net]  has joined #ubuntu-kernel
[10:19] <Nafallo> Linux silverfairy 2.6.22-1-generic #1 SMP Fri Apr 27 14:45:08 GMT 2007 i686 GNU/Linux
[10:19] <Nafallo> :-)
[10:19] <BenC> kewl
[10:20] <BenC> is that from the archive build?
[10:20] <Nafallo> indeed. I grabbed it from LP :-)
[10:20] <BenC> nice
[10:21] <BenC> lrm and lum are uploaded, just waiting for the builds
[10:21] <Nafallo> lum? metapackages?
[10:21] <BenC> lum == linux-ubuntu-modules
[10:22] <Nafallo> aha. kewl.
[10:22] <BenC> like lrm, but it's all the stuff that used to be in ubuntu/ in feisty
[10:22] <Nafallo> so my webcam might work soon ;-)
[10:22] <BenC> ivtv doesn't build right with 2.6.21 v4l2 yet
[10:22] <BenC> I probably just need to snag a newer version
[10:22] <Nafallo> qcusb :-)
[10:23] <BenC> ah, that should be there then
[10:23] <BenC> wont have meta packages till after UDS
[10:23] <Nafallo> hmm. the source is probably in unapproved?
[10:23] <BenC> let this initial upload simmer a bit
[10:24] <Nafallo> I haven't seen lrm and lum on -changes
[10:24] <BenC> probably...archive folks are well into their weekend by now
[10:24] <Nafallo> indeed
[10:24] <BenC> lrm is in need-build on lp
[10:24] <Nafallo> ah :-)
[10:25] <Nafallo> I haven't seen my sponsored uploads to main yet either ;-)
[10:25] <Nafallo> atleast not in the archive
[10:27] <Nafallo> eog was the first one, and it's pending :-P
[10:27] <Nafallo> :-)
=== dade` [n=dade@85-18-201-175.ip.fastwebnet.it]  has joined #ubuntu-kernel
=== zorglu_ [n=zorglub@165.43.102-84.rev.gaoland.net]  has joined #ubuntu-kernel
[10:35] <zorglu_> q. i would like to intercept a given syscall for all the apps (namely the bind() syscall), is there a way to do that? where should i look ?
[10:39] <BenC> zorglu_: I'm not sure you can, but the kernel source is the place to look
[10:39] <zorglu_> hehe :)
[10:40] <BenC> are you attempting to get rid of the port < 1024 restriction on non-root?
[10:40] <zorglu_> thanks but very large :) i would look for something similar to ipfilter but for syscall
[10:40] <zorglu_> i was wondering if the guys doing all the security have soemthing like that
[10:40] <BenC> there's no easy to to hook into syscalls
[10:41] <BenC> basically hacking the code and recompiling, that's about it
[10:41] <zorglu_> arg no cool
[10:41] <zorglu_> ok thanks for your help
[10:42] <mjg59> Well, for dynamically linked applications, you can LD_PRELOAD
=== cjb [n=cjb@pullcord.laptop.org]  has joined #ubuntu-kernel
=== OldKid [n=oldi@fresno121.webperoni.de]  has joined #ubuntu-kernel
[10:42] <zorglu_> yep i was thinking about something like that, but issue with statically linked exe
[10:43] <zorglu_> well a first implementation could use tLD_PRELOAD and maybe doing modif in kernel if the approach is proven 'good'
[10:44] <cjb> Hi.  There's a vm_insert_pfm() namespace clash; the Ubuntu kernel has started defining it for some reason (upstream doesn't), and drm uses it too, so compiling against drm is broken.  I don't see a launchpad bug; does anyone know about this?
[11:07] <BenC> cjb: how is it broken?
[11:07] <cjb> BenC: /home/cjb/git/drm/linux-core/drm_compat.c:190: error: static declaration of vm_insert_pfn follows non-static declaration
[11:07] <cjb> include/linux/mm.h:1126: error: previous declaration of vm_insert_pfn was here
[11:07] <cjb> 
[11:07] <cjb> BenC: http://bugs.freedesktop.org/show_bug.cgi?id=10576 diagnoses it.
[11:07] <BenC> cjb: that's not our bug...your source need to not define it
[11:08] <BenC> obviously it is doing so to be compatible with pre 2.6.21 kernels, which our kernel is
[11:08] <BenC> however we pulled in some changes related to that from 2.6.21 to support newer drivers (like newer drm)
[11:09] <BenC> cjb: edit drm_compat.c, and comment out that function declaration
[11:09] <cjb> BenC: So, you're using code from 2.6.21, but you're not willing to advertise your kernel as 2.6.21, and you don't care that it breaks stuff.  :)
[11:10] <BenC> I'm not going to call our kernel 2.6.21 just because we pulled one API from 2.6.21
[11:10] <cjb> Yeah, I know I can do that.  I was hoping that other people using Ubuntu might be able to compile drm too.  ;-)
[11:10] <BenC> and there's no way for me to "fix" it
=== zaph31 [n=cyril@lns-bzn-22-82-249-94-119.adsl.proxad.net]  has joined #ubuntu-kernel
[11:11] <cjb> Okay, I understand.  It's not usual for something to check the kernel version, then?
[11:11] <BenC> cjb: there's a small matter of whether we want a 2.6.20 compatible API, or better hw support...since we are more interested in the latter, since it helps alleviate the need for the former, we chose to update things
[11:12] <BenC> cjb: it's normal yes, but it only applies to stock kernel code...no distro that I know of has perfect API compatibility with the stock source that the base on
[11:15] <cjb> BenC: Yeah.
=== ash211_ [n=andrew@user-1121k7e.dsl.mindspring.com]  has joined #ubuntu-kernel
=== zaph31 [n=cyril@lns-bzn-22-82-249-94-119.adsl.proxad.net]  has left #ubuntu-kernel ["Konversation] 
[11:30] <cjb> BenC: drm has a policy to only support API changes in official kernel releases, so I guess I can just tell you that if you pull drm early without being willing to fix the API checks, you'll continue to lose.  :)
=== gortiz [n=gortiz@88.87.105.4]  has joined #ubuntu-kernel
[11:30] <BenC> cjb: how can I fix those checks?
[11:30] <BenC> I mean really, what would you have me do?
[11:32] <cjb> BenC: You can make them fail in your kernel source..
[11:32] <cjb> Oh.  No you can't; sorry, being slow.
[11:32] <BenC> besides, I think only a very very very few of our users plan on compiling their own drm, and those people know how to overcome this, and expect to do so, which means it isn't a loss for me or the distro
[11:33] <BenC> or for our users in general
[11:33] <cjb> I'd hope for more collaboration upstream than "haha, we broke compiling drm, it's your problem", but I understand your situation.
[11:35] <mjg59> cjb: I can't think of any clean method to make these things fail. The assumption that checking for a kernel version is equivalent to checking for an API version has never been true.
[11:39] <BenC> cjb: there's no way to collaborate, there's nothing I can do to fix it
[11:39] <BenC> it's simply not possible
[11:40] <BenC> besides, I didn't "break" anything
=== MrNOKIA1 [n=user@86.121.181.146]  has joined #ubuntu-kernel
=== gortiz [n=gortiz@88.87.105.4]  has joined #ubuntu-kernel