=== johanbr [n=j@JBrannlund.MathStat.Dal.Ca] has joined #ubuntu-kernel === zul__ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === defcon [n=defcon@71-223-85-147.phnx.qwest.net] has joined #ubuntu-kernel === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === doko [n=doko@dslb-088-073-114-212.pools.arcor-ip.net] has joined #ubuntu-kernel === cobman [n=justinas@194.176.50.7] has joined #ubuntu-kernel === jml [n=jml@ppp121-44-218-164.lns1.hba1.internode.on.net] has joined #ubuntu-kernel === defcon [n=defcon@70-59-227-116.phnx.qwest.net] has joined #ubuntu-kernel === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-kernel === bullgard4 [n=detlef@p54BF1B28.dip0.t-ipconnect.de] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === jml [n=jml@ppp121-44-218-164.lns1.hba1.internode.on.net] has joined #ubuntu-kernel [06:27] c [06:27] ugh === jml [n=jml@ppp121-44-218-164.lns1.hba1.internode.on.net] has joined #ubuntu-kernel === defcon [n=defcon@70-59-227-116.phnx.qwest.net] has joined #ubuntu-kernel === bullgard5 [n=detlef@p54BF1B28.dip0.t-ipconnect.de] has joined #ubuntu-kernel === OGDA [n=thomas@67-150-255-194.oak.mdsg-pacwest.com] has joined #ubuntu-kernel === blenderhead001 [n=blenderh@adsl-068-209-133-121.sip.jax.bellsouth.net] has joined #ubuntu-kernel === OGDA is now known as BFTD === bullgard1 [n=detlef@p54BF1B28.dip0.t-ipconnect.de] has joined #ubuntu-kernel === bullgard1 [n=detlef@p54BF1B28.dip0.t-ipconnect.de] has joined #ubuntu-kernel === n2diy [n=darryl@wlk-barre-208-103-147-19.dynamic-dialup.coretel.net] has joined #ubuntu-kernel === abogani [n=alessio@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === defcon [n=defcon@70-59-227-116.phnx.qwest.net] has joined #ubuntu-kernel === m0rg0th [n=m0rg0th@220.225.228.97] has joined #ubuntu-kernel [08:57] moin === calc [n=ccheney@conr-adsl-209-169-124-200.consolidated.net] has joined #ubuntu-kernel === Lure [n=lure@external-1.hermes.si] has joined #ubuntu-kernel === calc_ [n=ccheney@conr-adsl-209-169-124-200.consolidated.net] has joined #ubuntu-kernel === calc__ [n=ccheney@conr-adsl-209-169-124-200.consolidated.net] has joined #ubuntu-kernel === cwillu [n=cwillu@70.64.74.208] has joined #ubuntu-kernel === cwillu [n=cwillu@70.64.74.208] has left #ubuntu-kernel [] === defcon [n=defcon@70-59-224-3.phnx.qwest.net] has joined #ubuntu-kernel [10:31] how do I free my cache memory [10:38] Why do you want to? [10:47] mjg59: Because it's full, and he wants to cache new things! === cobman [n=justinas@212.47.107.5] has joined #ubuntu-kernel === Keybuk [i=scott@nat/canonical/x-a1815f81a5b95fe2] has joined #ubuntu-kernel === cobman [n=justinas@omega.vic.lt] has joined #ubuntu-kernel === IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === AlinuxOS [n=vsichi@host156-122-dynamic.3-87-r.retail.telecomitalia.it] has joined #ubuntu-kernel === rtg [n=rtg@rtg.theglobal.net] has joined #ubuntu-kernel [02:53] is there a way to strace a nfsd process? [02:54] You can't strace kernel threads [02:54] how about nfs userspace daemon? [02:54] thats what i thought [02:55] you can use kdb set breakpoints etc in kernelspace [02:55] er not an option [02:56] strace the nfs userspace daemon [03:14] mjg59: hey [03:15] BenC: Hi [03:15] mjg59: anything you know of that's real urgent in gutsy kernel, e.g. acpi stuff? [03:16] How urgent is real urgent? [03:16] like, we should have it fixed even before next tribe [03:16] -5 rather than -4, right? [03:16] right [03:16] Hang on a sec [03:17] BenC: is the current kernelversion already closed or still open for external drivers? [03:17] mrec: 2.6.22 is it, if that's what you mean [03:18] do you still agree with pushing in external drivers? I expect them to go in 2.6.24 since I missed the 2.6.23 merge window [03:18] http://mcentral.de/wiki/index.php/Em2880#Devices [03:18] it's about these devices [03:19] the drivers do not require any changes at the existing framework they are just additionally [03:20] mrec: they would go into linux-ubuntu-modules [03:21] BenC: http://marc.info/?l=linux-acpi&m=118587857102639&w=2 [03:21] The patch from there would be helpful [03:21] who should I talk to regarding that package? [03:23] mjg59: is there some place we can cherry pick? [03:23] mrec: http://kernel.ubuntu.com/git and find ubuntu/ubuntu-lum-gutsy [03:24] BenC: Not currently === jamiemcc [n=jamie@82-32-8-26.cable.ubr02.azte.blueyonder.co.uk] has joined #ubuntu-kernel [03:25] BenC: ok I'll mirror that git tree and add the driver === dorileo [n=dorileo@201.40.162.47] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === ion [n=ion@70-59-224-3.phnx.qwest.net] has joined #ubuntu-kernel === pkl_ [n=phillip@unaffiliated/pkl/x-764568] has joined #ubuntu-kernel === elementz [n=elementz@p4FC4C4B9.dip.t-dialin.net] has joined #ubuntu-kernel === abogani [n=alessio@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === mylox [n=kvirc@74-34-195-11.dsl1-pixley.roch.ny.frontiernet.net] has joined #ubuntu-kernel === mylox [n=kvirc@74-34-195-11.dsl1-pixley.roch.ny.frontiernet.net] has left #ubuntu-kernel ["Time] === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel [04:53] kylem: are you checking into alsa merge from 2.6.23-rc? [04:54] yes [04:56] Do we have any kernel network ether/TCP experts about? Got a very weird issue where randomly and without warning the ACK to a SYN ACK is being ignored and the server is repeating the SYN ACKs until finally issuing an RST. Wondered if anyone has an y bright ideas as to why this might occur [04:57] IntuitiveNipple: perhaps the ACK is corrupt/invalid? [04:59] kylem: ok, then please revert my hda-intel hackage :) [04:59] well, i'll do whatevers easiest. might be that it's simpler to just pull out multi-series patches and cherrypick them [05:00] no, thats the strange thing. I'm helping out a big online retailer that have clusters of servers behind Juniper DX load balancers... and in one cluster (Proliants) they see this happen occassionally. We've been analysing the tcpdump - the only explanation for what we see is that the 3rd packet, the ACK to the SYN ACK from the Juniper isn't seen by the Linux TCP layer, but it *is* captured by tcpdump/libpcap at the 'link' layer [05:01] We've ruled out differing configurations by doing diffs, they're all on identical kernels, identical hardware (but the problem persists with an addtional NIC plugged in) [05:01] kylem: right, but I mean I disabled snd-hda-intel in linux-source and put a bleeding edge driver in lum that doesn't really work without some changes in snd core [05:02] IntuitiveNipple: the kernel would have to have some reason to ignore the packet, or perhaps the driver isn't inserting it into the network layer properly [05:02] BenC, oh, right, sorry, i hadn't pulled. [05:03] BenC, what do you want to do about -stable? [05:03] kylem: alsa? Nothing for now [05:03] no, i mean 2.6.22.y [05:04] Oh, right, definitely keep that synced up until kernel freeze [05:04] will lower kees work load post gutsy release :) [05:04] ok, i have a tree where i merged .y [05:04] thats what i was wondering... could that occur in two different drivers by co-incidence would you think (tg3/e1000) ? [05:05] kylem: did you get my patch? [05:05] yes. [05:05] coolio [05:05] IntuitiveNipple: netdev might be a better place to ask this [05:05] didn't realise there was a channel for it... thanks! [05:06] at least for me, it's been a few years since I dug into eth/ip interaction [05:06] cool there is a patch for x86_64 paravirt support [05:07] IntuitiveNipple: not sure if there's a channel, but there is a mailing list [05:08] oh i see... that explains alot :D === IntuitiveNipple slaps self with soggy banana [05:25] ipw3945 is in linux-ubuntu-modules now is that right? === Lure [n=lure@ubuntu/member/lure] has joined #ubuntu-kernel [05:29] BenC: is there any preference where I should put the userspace shared libraries which are used by the drivers? === pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel === _ion [n=ion@70-59-224-3.phnx.qwest.net] has joined #ubuntu-kernel [05:42] mrec: in some other package :) [05:43] mrec: lum isn't really designed to have userspace parts, but I guess that could be added as a linux-ubuntu-modules-support package or something [05:46] BenC: hmm the firmware is compiled into it [05:47] (although everything beside the firmware binary is OSS) [05:51] BenC: http://mcentral.de/hg/~mrec/userspace-tuner [05:51] this is currently the most important component of the driver [05:52] it should build against every kernel === BFTD [n=thomas@67-150-247-63.oak.mdsg-pacwest.com] has joined #ubuntu-kernel === cobman [n=justinas@194.176.50.4] has joined #ubuntu-kernel [06:01] mrec: firmware can go iun lum too [06:01] http://mcentral.de/hg/~mrec/userspace-tuner/ [06:01] the firmware doesn't get loaded by udev [06:01] it gets passed to kernelspace through the userspace daemon [06:06] mrec: not using standard kernel APIs...tsk tsk [06:07] BenC: I had a discussion about the firmware loading class an important patch isn't included yet which can cause problems with using the firmware loading mechanism with 2 frameworks [06:07] I should push that patch immediatelly anyway [06:08] and the windows sample drivers I have include the firmware in the sources .. it takes me around 30 minutes to convert these drivers to linux with that work [06:11] http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages === johanbr [n=j@JBrannlund.MathStat.Dal.Ca] has joined #ubuntu-kernel === _ion [n=ion@70-59-224-3.phnx.qwest.net] has joined #ubuntu-kernel === amitk [n=amit@85-156-15-100.elisa-mobile.fi] has joined #ubuntu-kernel [06:51] BenC: http://lkml.org/lkml/2007/8/8/251 [06:51] Should be the proper fix for the Turion issue === Lure_ [n=lure@89-212-18-142.dynamic.dsl.t-2.net] has joined #ubuntu-kernel === dorileo [n=dorileo@201.40.162.47] has joined #ubuntu-kernel === calc [n=ccheney@conr-adsl-209-169-124-200.consolidated.net] has joined #ubuntu-kernel === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === ThrobbingBrain66 [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel [07:34] mjg59: I picked up the patch and am building. I have a Dell E1501 that exhibits the problem quite nicely. === ThrobbingBrain66 [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel === ThrobbingBrain66 [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel [08:01] Hi BenC and IntutiveNipple, both you were helping me about a week and half ago with my shutdown problem (I was known as bradley at the time) [08:01] I now realize I may have given you some misleading info === n2diy [n=darryl@69.72.85.102] has joined #ubuntu-kernel === ivoks [n=ivoks@vipnet101-165.mobile.CARNet.hr] has joined #ubuntu-kernel [08:04] One of you asked me to access a virtual terminal, shut down gnome with /etc/inti.d/gdm stop. I did that and things shut down smoothly so the conclusion was come to that my bug was infact an xorg bug [08:04] since then, ive tried that a few more times and things done shut down smoothly. i think i forgot to disable my workaround before i attempted your instructions [08:05] https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/126140 === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel [08:18] mjg59: http://lkml.org/lkml/2007/8/8/251 fixes the E1501 boot problem. Thanks for the notice. [08:26] rtg: Excellent [08:33] rtg: sweet, can you get that into gutsy git soonish? [08:33] BenC: working on it. [08:35] I can test it on my 1521 too [08:38] BenC: you and IntutiveNipple were helping me about a week and half ago with my shutdown problem (I was known as bradley at the time) I think I may have given you so misleading info [08:38] ThrobbingBrain66: I saw, not sure what to tell you [08:38] oh, sorry [08:39] wouldnt that then make it a kernel bug again? [08:39] I'm not sure what you mean by snd-hda-intel [08:39] most of my systems use that driver and they all shut down fine [08:40] i understand that, but when i run a script at shut down, everything goes smoothly [08:41] i dont know if modules are implicity uploaded at shut down, or what happens to them, but when I remove it before shut down, everything works great [08:46] BenC: I updated the gutsy repo. You can either build or get zinc.ubuntu.com:/home/rtg/linux-image-2.6.22-9-generic_2.6.22-9.26_i386.deb === bronson [n=bronson@66.237.74.66.ptr.us.xo.net] has joined #ubuntu-kernel === amitk [n=amit@85-156-114-34.elisa-mobile.fi] has joined #ubuntu-kernel [09:02] must just be a weird bug with my particular laptop, thanks for the help [09:03] ThrobbingBrain66: could be something in your bios [09:03] ThrobbingBrain66: check if there is a BIOS upgrade? === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] 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 [11:05] (BenC/#ubuntu-kernel) mjg59: can we update the init scripts so we don't have to keep the ugly patch? [11:06] BenC: In theory, sure. On the other hand, we've carried that patch forever (and Debian have carried it even longer) and the vesafb code doesn't change - is there really any benefit? [11:11] mjg59: actually, part of the reason I dropped it was because the code did change, and it wasn't trivial to merge [11:11] and the description of the changes led me to believe we could do with out it [11:13] BenC: vesafb.c hasn't been touched since last year? [11:14] maybe I'm thinking of vgafb [11:14] vga16fb I mean [11:14] I wish one of those could die [11:14] vga16fb *needs* to be modular [11:14] Or alternatively just not built at all now [11:15] Though it's only had a few bugfixes this year [11:15] Nothing major [11:15] Ok, vga16fb is modular [11:15] vesafb isn't [11:15] vesafb should be [11:16] Why isn't the modular vesafb patch upstream? [11:16] Because it's a (basically unnecessary) hack [11:16] But the framebuffer init stuff we have is not straightforward [11:16] if it's unnecessary, then why do we need it? :) [11:16] So I'd rather not have to rewrite that === ketrox [n=ketrox@Zfc4a.z.pppool.de] has joined #ubuntu-kernel [11:17] gotcha === 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 === macd [n=d@cl-151.ewr-01.us.sixxs.net] has joined #ubuntu-kernel === macd [n=d@cl-151.ewr-01.us.sixxs.net] has joined #ubuntu-kernel === ThrobbingBrain66 [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel [12:15] Does bug 129812 need any more information other than the specific kernel version? [12:18] bdmurray: The hardware description