=== jml [n=jml@ppp121-44-210-226.lns1.hba1.internode.on.net] has joined #ubuntu-kernel === doko_ [n=doko@dslb-088-073-072-074.pools.arcor-ip.net] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === rikai_ [n=rikai@unaffiliated/rikai] has joined #ubuntu-kernel === ion [n=ion@71-35-72-43.phnx.qwest.net] has joined #ubuntu-kernel === chrisle [n=chris@e178111116.adsl.alicedsl.de] has joined #ubuntu-kernel === joris_ [i=joris@082-146-097-169.dyn.adsl.xs4all.be] has joined #ubuntu-kernel === m0rg0th [n=m0rg0th@219.64.120.181] has joined #ubuntu-kernel === chrisle [n=chris@e178075067.adsl.alicedsl.de] has joined #ubuntu-kernel === Starting logfile irclogs/ubuntu-kernel.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-9.25 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/ === Topic (#ubuntu-kernel): set by lamont at Fri Aug 3 16:12:28 2007 === retour [n=wolfenst@adsl-70-228-92-219.dsl.akrnoh.ameritech.net] has joined #ubuntu-kernel === retour [n=wolfenst@adsl-70-228-92-219.dsl.akrnoh.ameritech.net] has left #ubuntu-kernel [] === jml_ [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === m0rg0th [n=m0rg0th@220.225.228.97] has joined #ubuntu-kernel === IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel === ICU [n=me@sechzig.dd.ewetel.de] has joined #ubuntu-kernel === ICU [n=me@sechzig.dd.ewetel.de] has joined #ubuntu-kernel === bullgard4 [n=detlef@p54BF3D50.dip0.t-ipconnect.de] has joined #ubuntu-kernel === cobman [n=justinas@212.47.107.11] has joined #ubuntu-kernel === abogani [n=alessio@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === jml_ [n=jml@ppp121-44-210-226.lns1.hba1.internode.on.net] has joined #ubuntu-kernel === ICU [n=me@sechzig.dd.ewetel.de] has joined #ubuntu-kernel [09:57] moin === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === hxu [n=hxu@159.226.21.127] has joined #ubuntu-kernel [10:44] In include/linux/mqueue.h, the space limit of per-uid mqueue is set 819200 bytes, but you always get -1(which means infinity) for both soft and hard limit of mqueue by getrlimit(2) in ubuntu 2.6.20-16.29, any idea? === dorileo [n=dorileo@201.22.196.157.adsl.gvt.net.br] has joined #ubuntu-kernel [11:09] In include/linux/mqueue.h, the space limit of per-uid mqueue is set 819200 bytes, but you always get -1(which means infinity) for both soft and hard limit of mqueue by getrlimit(2) in ubuntu 2.6.20-16.29, any idea? [11:13] hxu: Good thing you asked that twice in 20 minutes, otherwise someone might not have noticed. === joris [i=joris@082-146-097-169.dyn.adsl.xs4all.be] has joined #ubuntu-kernel === bullgard4 [n=detlef@p54BF1257.dip0.t-ipconnect.de] has joined #ubuntu-kernel [11:38] In include/linux/mqueue.h, the space limit of per-uid mqueue is set 819200 bytes, but you always get -1(which means infinity) for both soft and hard limit of mqueue by getrlimit(2) in ubuntu 2.6.20-16.29, any idea? === Yagisan [n=Yagisan@doomsday/developer/Yagisan] has joined #ubuntu-kernel === Yagisan [n=Yagisan@doomsday/developer/Yagisan] has joined #ubuntu-kernel === Traxer [i=traxer@shell6.powershells.de] has joined #ubuntu-kernel === smurf [n=smurf@debian/developer/smurf] has joined #ubuntu-kernel === Riddell [i=jr@kde/jriddell] has joined #ubuntu-kernel === stgraber [n=stgraber@ubuntu/member/stgraber] has joined #ubuntu-kernel === fs [i=fs@213.178.77.100] has joined #ubuntu-kernel === n0u [i=Chaton@unaffiliated/nou] has joined #ubuntu-kernel === kraut [n=kraut@blackhole.packetloss.biz] has joined #ubuntu-kernel === maswan [i=maswan@kennedy.acc.umu.se] has joined #ubuntu-kernel === soren [n=sh@ubuntu/member/shawarma] has joined #ubuntu-kernel === chrisle [n=chris@e178075067.adsl.alicedsl.de] has joined #ubuntu-kernel === rikai_ is now known as rikai === sacater [n=sacater@ubuntu/member/colchester-lug.sacater] has joined #ubuntu-kernel === IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel === AndyP [n=andyp@ubuntu/member/welshbyte] has joined #ubuntu-kernel === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-kernel === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-kernel === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === ICU [n=me@sechzig.dd.ewetel.de] has joined #ubuntu-kernel === abogani [n=alessio@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === m0rg0th [n=m0rg0th@220.225.228.97] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === rikai [n=rikai@unaffiliated/rikai] has joined #ubuntu-kernel === doko [n=doko@dslb-088-073-072-074.pools.arcor-ip.net] has joined #ubuntu-kernel === calc [n=ccheney@conr-adsl-209-169-124-200.consolidated.net] has joined #ubuntu-kernel === paran [n=paran@cust.fiber-lan.snet.lk.212.214.112.112.visit.se] has joined #ubuntu-kernel === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === allee [n=ach@lapex-mcallee.mpe.mpg.de] has joined #ubuntu-kernel === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-kernel === n2diy [n=darryl@wlk-barre-208-103-147-177.dynamic-dialup.coretel.net] has joined #ubuntu-kernel === thom [n=thom@amnesiac.heapspace.net] has joined #ubuntu-kernel === macd [n=d@cl-151.ewr-01.us.sixxs.net] has joined #ubuntu-kernel === maks [n=max@baikonur.stro.at] has joined #ubuntu-kernel === \sh [n=nnsherma@server3.servereyes.de] has joined #ubuntu-kernel === amitk_ [n=amit@a91-154-122-129.elisa-laajakaista.fi] has joined #ubuntu-kernel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel === RemoteViewer [n=555@stan.physik.fu-berlin.de] has joined #ubuntu-kernel === tepsipakki [n=tjaalton@replicant.hut.fi] has joined #ubuntu-kernel === infinity [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #ubuntu-kernel === sevrin [n=sevrin@ns1.clipsalportal.com] has joined #ubuntu-kernel === mhb [n=mhb@ubuntu/member/mhb] has joined #ubuntu-kernel === lamont [n=lamont@mix.mmjgroup.com] has joined #ubuntu-kernel === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #ubuntu-kernel === laga [n=laga@mythwiki.de] has joined #ubuntu-kernel === OldKid [n=oldi@fresno121.webperoni.de] has joined #ubuntu-kernel === ion [n=ion@71-35-72-43.phnx.qwest.net] has joined #ubuntu-kernel === Traxer [i=traxer@shell6.powershells.de] has joined #ubuntu-kernel === smurf [n=smurf@debian/developer/smurf] has joined #ubuntu-kernel === Riddell [i=jr@kde/jriddell] has joined #ubuntu-kernel === stgraber [n=stgraber@ubuntu/member/stgraber] has joined #ubuntu-kernel === fs [i=fs@213.178.77.100] has joined #ubuntu-kernel === n0u [i=Chaton@unaffiliated/nou] has joined #ubuntu-kernel === kraut [n=kraut@blackhole.packetloss.biz] has joined #ubuntu-kernel === maswan [i=maswan@kennedy.acc.umu.se] has joined #ubuntu-kernel === soren [n=sh@ubuntu/member/shawarma] has joined #ubuntu-kernel === kylem [n=kyle@amnesiac.heapspace.net] has joined #ubuntu-kernel === zul__ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === chrisle [n=chris@e178075067.adsl.alicedsl.de] has joined #ubuntu-kernel === dorileo [n=dorileo@201.40.162.47] has joined #ubuntu-kernel [02:21] i/c [02:21] argh === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #ubuntu-kernel === lamont` ponders the best way to not build ov511 in lum on hppa === lamont` tries the other option first === ionstorm [n=ion@70-59-226-160.phnx.qwest.net] has joined #ubuntu-kernel === dieguito [n=diego@201.230.8.15] has joined #ubuntu-kernel [03:14] hello happy hackers, just dropping to ask -at the risk of annoying you- if there's a simple way to disable libata via the kernel parameters given at boot time [03:17] dieguito: you can blacklist drivers, but I don't think you can disable libata as such, no. [03:17] hmmm [03:18] which ones should i blacklist in that case? [03:18] What's the end goal here? === bullgard4 [n=detlef@p54BF322A.dip0.t-ipconnect.de] has joined #ubuntu-kernel [03:19] my stone age pc boots in no less than 5 minutes with newer kernels using libata === m0rg0th [n=m0rg0th@219.64.120.181] has joined #ubuntu-kernel [03:22] (yes, it can boot faster than 5 minutes on non-libata kernels) [03:22] why not rather find out what the problem is and fix that? [03:23] Mithrandir: if you want me to debug it just tell me how and i'll try [03:23] it works using older libata kernels? [03:23] if so, that sounds like a use case for git bisect. [03:23] nope, it works using good old /dev/hd* kernels [03:25] now that everything is /dev/sd* it takes ages to boot [03:25] paste a dmesg from a slow boot somewhere, then? [03:26] let me turn on that machine... [03:26] from a google search the other day I have this line: exception emask 0x0 sact 0x0 serr 0x0 action 0x2 frozen emask 0x4 time out [03:26] i'll give you the full log in a second [03:26] well in 5*60 seconds [03:37] oh great now it doesn't boot === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #ubuntu-kernel [04:01] i can't boot it [04:02] :/, sorry but closest thing is that line above [04:04] https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106512/comments/3 is a close match to my usual output === dorileo [n=dorileo@201.40.162.47] has joined #ubuntu-kernel === mdomsch [n=Matt_Dom@cpe-70-124-62-55.austin.res.rr.com] has joined #ubuntu-kernel [04:41] kylem: are you working on an nvidia refresh for next tribe? If no, I'll get it ready for upload later this week with your kernel upload === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel [04:44] BenC, nope, i haven't done anything about nvidia yet. [04:44] (what's the problem, is there new hw support?) [04:45] yeah, we need the 100 series for -new, and there's new versions of legacy and legacy-new as well [04:45] ok, cool. [04:45] I've got tons of nvidia hw, so I can test it pretty well [04:46] We've always had a pretty open "if it seems to work on a few cards, ship it" attitude to LRM updates all the way up to rc/beta anyway, since there's nothing we can really do about upstream breaking it. [04:46] As long as it kinda works somewhere, we win. Ish. [04:47] BenC: later this week? freeze is tomorrow morning [04:48] Riddell: well I can upload it tomorrow, but then it will get uploaded/built again at the end of the week for the kernel ABI bump === chrisle [n=chris@e178075067.adsl.alicedsl.de] has joined #ubuntu-kernel [04:49] Oh, wait, tribe freeze is tomorrow? [04:49] hmm [04:49] kylem: did we get a kernel upload in? [04:49] yes, if you want new linux stuff in you need to upload before I wake up tomorrow [04:50] I've been on vacation, got a little time skew [04:51] Riddell: very little chance of us getting an upload done today because of the NEW processing and dep-wait for lrm/lum and such [04:51] BenC, no, i have all the src packages built but i'm waiting for a fix for unionfs. if i don't get one by the end of my work day, i upload a second set which have the apparmor things reverted for now. [04:52] not having the apparmor fix blocks mathiaz, so it's kind of important as well, but if it has to be reverted, we're kind of caught by the short & curlies. [04:52] kylem: ok...for future ref, I promised Mith and others we'd get kernels uploaded Fri before freeze to avoid cutting things so close [04:53] BenC, ok. yeah, sorry, this was kind of an exceptional case as i'd not noticed lum ftbfs due to stupidity on my pat. [04:53] part [04:53] so you might want to clue #ubuntu-release in on the this [04:53] np === kylem nods. [04:53] i wonder which tab that is. [04:53] if someone tells me what knob to press, i probably have magic build pinning abilities. [04:54] You don't. [04:54] loss. [04:54] i should. [04:54] ;-) [04:54] Shouldn't matter anyway, unless the queue is backed up. [04:54] Making the only build in the queue a higher priority still makes it... The only build in the queue. :P [04:55] lpia is backlogged, no? [04:55] slightly [04:55] Who cares? [04:55] lpia isn't releasing tribes. [04:55] true. [04:55] The only arches you need to see build your kernel are i386/amd64/powerpc. [04:55] it's only about 7700 builds behind, it'll catch up quickly enough [04:56] actually, I want kernels on lpia quickly too [04:56] Down to 7700 from close to 9000. [04:56] so please tell me ifwhen you have stuff to be bumped [04:56] It's doing well. [04:56] infinity, we release powerpc tribes? [04:57] Anyhow, lpia builds the kernel quickly (fast machines, only one flavour), so if it doesn't get built ASAP, it's not the end of the world. [04:57] Compared to i386, which takes a week. [04:57] kylem: I'm not sure about "release" anymore, but we still build 'em. === cjwatson [n=cjwatson@chiark.greenend.org.uk] has joined #ubuntu-kernel === lamont` [i=lamont@nat/hp/x-5759474b7376fa57] has joined #ubuntu-kernel [05:00] I wonder if I can get nvidia done today [05:01] we're already past UVF, and I don't want to put it off any longer [05:01] kylem: we are on an ABI bump, right? === chrisle [n=chris@e178075067.adsl.alicedsl.de] has joined #ubuntu-kernel === ionstorm [n=ion@70-59-226-160.phnx.qwest.net] has joined #ubuntu-kernel === mhb [n=mhb@64.73.broadband3.iol.cz] has joined #ubuntu-kernel [05:20] BenC, yup. [05:20] sorry, was on a call. [05:23] kylem: ok, I'll work on getting that done [05:23] do you want the .orig.tar.gz with the abibump done? [05:24] then you can just blat the new nvidia stuff and not worry about it [05:24] I've got to make a new .orig.tar.gz for lrm === rtg_ [n=rtg@gn-216-166-171-58.mtwireless.net] has joined #ubuntu-kernel [05:25] kylem: do you have changed to lrm other than the abi bump? [05:25] *changes [05:26] nope === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel [05:26] ok, I'll just apt-get source and go from there [05:27] BenC: Does LRM still have my 3 levels of autogenerated control files? [05:28] (For which I profusely apologise but, hey, it worked) [05:28] infinity: yeah, but then, so does most everything else related to the kernel :) [05:33] Changes: [05:33] linux-restricted-modules-2.6.22 (2.6.22.2-10.9) gutsy; urgency=low [05:33] . [05:33] * ABI bump to -10. [05:33] yeah, that's it === infinity2 [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #ubuntu-kernel === pmjdebruijn [n=pmjdebru@213.84.213.170] has joined #ubuntu-kernel === mjg59 [n=mjg59@78.32.9.130] has joined #ubuntu-kernel === mjg59 [n=mjg59@78.32.9.130] has joined #ubuntu-kernel [06:34] rtg_: last time I updated rt2x00 I used the wireless-dev version for lum, but had to munge things because of api changes in current wireless-dev [06:34] rtg_: if the API has changed too much, then just stick with 2.0.4 that we have now [06:35] BenC: right. [06:35] BenC: The only prism54 I see in wireless-dev is drivers/net/wireless/prism54. Is there some other name? [06:36] kylem: I have lrm with all the nvidia updates, passed built and basic boot test...I'm going to drop it on kernel.ubuntu.com, so you can just upload it from there when you're ready if you want, or ping me and I can [06:36] rtg_: check for p54 [06:36] sure. [06:37] prism54 is hardmac, p54 is softmac [06:38] s/hardmac/fullmac/ [06:38] Any modern p54 hardware is softmac [06:38] mjg59: I just spotted it. [06:39] unfortunately, p54 and prism54 both claim the same PCI ids :/ [06:39] Thanks, Intersil [06:39] The fullmac cards can be run with the softmac firmware and driver [06:39] ah, good, so just get p54 [06:39] mjg59: There has been a lot of churn in wireless-dev of late. Will the Gutsy version of softmac be sufficient for p54? [06:39] But prism54 works, whereas I have no idea if p54 does [06:40] rtg_: When I say softmac, I mean the card doesn't have a hardware mac. I've no idea if the driver uses softmac or mac80211 [06:40] rtg_: do you have any prism54 hw? [06:40] BenC: not that I know of. [06:40] rtg_: you may have to munge things in p54 a bit to compile against 2.6.22, like I did for rt2x00 [06:41] mjg59: do you have any p54 hw? [06:41] BenC: so, do you want both prism54 and p54? [06:41] Nope [06:41] rtg_: For tribe-5, let's just enable prism54 in linux-source...after that, disable prism54 and get p54 into lum for testing [06:42] probably easiest to get the people in the bug report to test p54 for you [06:42] BenC: will do. [06:51] BenC: We might want to let rt2x00 settle for a bit. Ivo submitted 30 patches yesterday. [06:52] rtg_: ok [07:09] 78 [07:09] -ETERMINAL #soory === lamont` fights with lum/hppa === m0rg0th [n=m0rg0th@219.64.120.181] has joined #ubuntu-kernel [07:38] hmm, it just occured to me, if i bounce apparmor back to the old version for tribe5, we'll have another abi event when we readd it. === lamont` ponders _why_ squashfs/inode.c winds up dying with TASK_UNINTERRUPTIBLE undefined on hppa64 (only), and why #include is needed there to fix it. [07:39] lamont`, headers in general are a mess. [07:40] will you forgive a stray #include in squashfs/inode.c? [07:40] i have no idea which include is guarded by __lp64__ or something, i'm kind of confused. [07:40] i'll even testbuild on i386 [07:42] kylem: best to ask pkl, it's his code :) [07:42] lamont: ^^ [07:42] BenC, it's not a squashfs problem persey. [07:43] granted, explictly including sched.h is probably best === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel [07:43] i'm curious why it only breaks on 64-bit. [07:45] doesn't sound like 64-bit, since x86_64, sparc64 and powerpc64 seem to build fine [07:46] BenC, it's a problem in one of the on parisc, hence my interest [07:46] being them maintainer and all [07:47] hppa64 is CONFIG_SMP=n for now [07:47] oh. [07:47] dunno if that's a factor [07:47] that might do it. [07:47] kylem: ah, you meant only breaks on 64-bit hppa, as opposed to 32-bit hppa [07:47] misunderstood [07:48] ah, i bet i see how. [07:48] kylem: if you have a pointer, I've no objection to testing it === dorileo [n=dorileo@201.40.162.47] has joined #ubuntu-kernel [07:49] lamont`, are you building SMP=n hppa32? [07:49] kylem: zinc:~bcollins/ has lrm ready [07:49] BenC, groovy, thanks. [07:49] kylem: no. [07:49] back to my inbox [07:49] ok. [07:50] basically, hppa32 is happy and has what I believe to be final-.config [07:50]

-> -> -> $lots [07:50] hppa64 was failing to boot, so I went for a "give me somethign that boots, thanks" [07:50] something was trashing life with SMP [07:50] and I grew tired of looking [07:50] there's another hppa64-pseudo-ABI event coming [07:51] lamont`, if squashfs is using something from that header, the safest thing to do is include it. [07:51] and not rely on it being included acciently. [07:51] squashfs calls wait_event, which expands to use TASK_UNINTERRUPTIBLE [07:51] but wait_event is defined outside of squashfs, so I think it's still a kernel-header issue, no? [07:52] wait.h, to be specific [07:52] so I kinda think wait.h should be including sched.h. Thoughts? [07:53] yes, probably. [07:53] hmm [07:53] unless there's some kind of perverse recursion and instead is relying on include ordering. [07:53] is there still daily test kernels? ;-) [07:53] which, given it's linux, is entirely likely. [07:54] kylem: it shows up as undef, so it never got included.... [07:54] so the question is, do I want to do a lum patch for that, or a kernel patch? [07:54] Nafallo, i was working on something a few weeks ago that was as much of ubuntu patches + daily git, but never got around to wiring up automation. [07:55] kylem: and http://people.ubuntu.com/~bcollins/kernels-daily/ is empty, so I guess no ;-) === Nafallo wants working tickless :-P [07:55] oh right. [07:56] i don't think you can have tickless, but at least you won't hang on bootup. [07:56] :-/ [07:56] I already don't. got some commandline stuff from BenC before :-P [07:57] yeah. [07:57] Nafallo: does "nolapic_timer nohz=off" work for you? [07:57] kylem: on the subject of dead horses... do you want me to commit this as a squashfs/inode.c change, or a linux/wait.h change? [07:57] BenC: yes [07:57] that'll give you the same thing as the patched kernel [07:57] lamont`, the former for now. [07:57] ok. [07:57] wait. [07:57] er, sec. [07:57] BenC: at least until the problem is fixed so I can have tickless ;-) [07:58] kind of hard to fix broken hardware. [07:58] I have a kernel commit and a lum commit so far (config, and debian/control*, respectively) [07:58] possibly a bios update might help you. [07:58] oh. so I will /never/ have tickless then? [07:58] hmm. oki- [07:58] worth trying I guess. [07:58] iirc what i saw from amd was that it was an smm problem. [07:58] that could be fixed by a bios update. [07:58] I just wish it was as easy as putting the firmware on USB :-P === pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel [07:59] lamont`, so the problem is TASK_foo being undefined? [08:00] correct [08:00] and that's the only problem? [08:00] seems to be [08:00] hrm. [08:01] inode.c failed with lots of TASK_UNINTERRUPTIBLE undefined errors. including sched.h in inode.c eliminates all the compile errors [08:02] well, it's a kernel problem. i'll try to track down where i can fix it in [08:02] the other issue (orthogonal) is that the control file still says gcc-3.4 [08:02] ok. fact remains that linux/wait.h assumes that it'll be included, rather than explicitly including it.... [08:03] kylem: and then if you grab my committed tweaks from lamont/hppa-ia64{,-lum}.git, we'll get a kernel and lum. [08:03] want email? [08:04] include/linux/smp_lock.h:#include [08:04] heh, that might have done it. [08:04] sure. [08:04] heh === lamont` composes [08:09] kylem: sent [08:09] and pushing git repos. :-) [08:09] does gcc-4.1 build ocfs2/gfs now? [08:10] we made it through the build completely..... [08:10] already saw it. [08:10] ;-) [08:11] so why doesn't it boot? [08:15] last I left it, it would hang in the midst of releasing processors. [08:15] for my next round of fun, I plan to start with defconfig+SMP, and keep adding stuff back in until it breaks. === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel [08:22] i just love it when /proc/mounts and the output of mount says 2 different things [08:23] zul: but that [08:24] s always the case, since mount drops stuff [08:24] if its reporting 8k and 32k? === johanbr [n=j@blk-224-159-249.eastlink.ca] has joined #ubuntu-kernel === chrisle [n=chris@e178075067.adsl.alicedsl.de] has joined #ubuntu-kernel === joris [i=joris@082-146-097-169.dyn.adsl.xs4all.be] has joined #ubuntu-kernel === xhaker [n=xhaker@83-223-185-184.cpe.netmadeira.com] has joined #ubuntu-kernel [10:02] Hey, I'm having some problems with an ich4-m ide controller [10:03] I'm running with udma2 for some time now [10:03] since the change to ata_piix [10:04] It claims my cable is 40pin only [10:04] blacklisting ata_piix and running with ide_generic i can have udma5 [10:05] so what do you say? any boot options to help me get this sorted? [10:15] xhaker: try booting with "all_generic_ide" [10:16] BenC, that would bring it to use ide_generic? [10:16] xhaker: lspci -vn [10:18] mjg59, http://pastebin.com/meb1bb40 [10:18] With ide_generic? That sounds unlikely [10:18] Are you sure you don't mean generic? [10:19] thanks for looking into this, i've been ignoring the problem, until yesterday when i was building a new package for eclipse, and the disk poor performance was noticeable [10:19] mjg59, I'm running with ata_piix/udma5 now [10:20] xhaker: Erm. I thought you just said you weren't? [10:20] mjg59, ata_piix/udma2 [10:20] ide_generic/udma5 [10:21] xhaker: ide-generic has no DMA support. Are you really sure you don't mean generic? [10:22] hmm, that's why the performance is better with ata_piix [10:23] xhaker: I'm sorry, you're not making a lot of sense here. [10:24] mjg59, I'll try to summarize. I know this laptop can do udma5. By default the kernel loads ata_piix and claims my cables are 40pin so udma2. [10:25] Yes, that bit is fairly clear [10:25] mjg59, /dev/sda: [10:25] Timing cached reads: 876 MB in 2.00 seconds = 437.46 MB/sec [10:25] Timing buffered disk reads: 24 MB in 3.11 seconds = 7.71 MB/sec [10:25] is what i get now [10:25] moving on.. in my quest to enable udma6, i've tried every boot option i could find.. ide0=ata66 idebus=66 [10:25] Try http://www.codon.org.uk/~mjg59/tmp/xhaker.diff [10:26] There's no way ide-generic can give you any DMA, so I don't understand the bit where you say it gives you udma5 [10:27] mjg59, explaining the rest.. I've then proceeded to backlist ata_piix, rootdelay=3 [10:28] mjg59, when the shell came up type in modprobe ide_generic [10:28] Yes, that'll give you pio [10:29] hdparm claimed udma5, even though the performance was tested lower.. 3 MB/sec [10:29] hdparm was lying for some reason [10:29] Can you try that patch, and if it works send it to Ben? === mkrufky [n=mk@unaffiliated/mkrufky] has joined #ubuntu-kernel [10:36] hey, guys... is it safe to assume that if I get a patch into 2.6.22.y, that it will make its way into the Gutsy kernel, or do I have to file a bug report and ask for it? === mdomsch [n=Matt_Dom@cpe-70-124-62-55.austin.res.rr.com] has joined #ubuntu-kernel [10:37] mkrufky: It should do === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel [10:38] mjg59, will try :) [10:38] mjg59: ok, cool.. .thanks [10:38] i searched launchpad and nobody filed yet ... probably just luck :-) === tepsipakki [n=tjaalton@replicant.hut.fi] has joined #ubuntu-kernel [10:50] mkrufky, i think in general we will be pulling 2.6.22.y until freeze, barring any special cases [10:51] ok.. thanks kylem ... i'll be sending this regression-fix to -stable tonight, when i get home... (cant send inline from here) [10:52] its a regression causing certain DVB hardware to not be able to tune... easily fixed [10:55] ok, cool [10:55] bugfixes definitelyw elcome. [11:27] kylem: here's a random question ... it's almost impossible to google this one, but i tried and landed on your name..... im under the impression that __u64 is for userspace and u64 is for internal kernelspace ... what is the difference, really? [11:27] (landed on your name cuz it found you ack a patch of somebody doing a conversion from u64 to __u64) [11:29] there's no fundamental difference [11:29] __x is used instead of x for namespace reasons. [11:29] (only, eg: __u32 is exported, not the u32 typedef) [11:30] ah, ok ... so, if something comes in from userspace as __u32 is can be assigned to a u32 var in kernelspace, no problem ? [11:30] indeed. [11:30] i ask, because v4l2_std_id is typedef'd as __u64 , and I'm doing a large refactoring on the v4l / dvb internal tuner api [11:31] ok, well that makes this easy .. .thanks [11:31] np. === Nafallo_ [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-kernel [12:04] ok, goin home... ttyl === mkrufky [n=mk@unaffiliated/mkrufky] has left #ubuntu-kernel [] === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel