[06:27] <TheMuso> c
[06:27] <TheMuso> ugh
[08:57] <kraut> moin
[10:31] <defcon> how do I free my cache memory
[10:38] <mjg59> Why do you want to?
[10:47] <infinity> mjg59: Because it's full, and he wants to cache new things!
[02:53] <zul> is there a way to strace a nfsd process?
[02:54] <mjg59> You can't strace kernel threads
[02:54] <mrec> how about nfs userspace daemon?
[02:54] <zul> thats what i thought
[02:55] <mrec> you can use kdb set breakpoints etc in kernelspace
[02:55] <zul> er not an option
[02:56] <mrec> strace the nfs userspace daemon
[03:14] <BenC> mjg59: hey
[03:15] <mjg59> BenC: Hi
[03:15] <BenC> mjg59: anything you know of that's real urgent in gutsy kernel, e.g. acpi stuff?
[03:16] <mjg59> How urgent is real urgent?
[03:16] <BenC> like, we should have it fixed even before next tribe
[03:16] <mjg59> -5 rather than -4, right?
[03:16] <BenC> right
[03:16] <mjg59> Hang on a sec
[03:17] <mrec> BenC: is the current kernelversion already closed or still open for external drivers?
[03:17] <BenC> mrec: 2.6.22 is it, if that's what you mean
[03:18] <mrec> 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] <mrec> http://mcentral.de/wiki/index.php/Em2880#Devices
[03:18] <mrec> it's about these devices
[03:19] <mrec> the drivers do not require any changes at the existing framework they are just additionally
[03:20] <BenC> mrec: they would go into linux-ubuntu-modules
[03:21] <mjg59> BenC: http://marc.info/?l=linux-acpi&m=118587857102639&w=2
[03:21] <mjg59> The patch from there would be helpful
[03:21] <mrec> who should I talk to regarding that package?
[03:23] <BenC> mjg59: is there some place we can cherry pick?
[03:23] <BenC> mrec: http://kernel.ubuntu.com/git  and find ubuntu/ubuntu-lum-gutsy
[03:24] <mjg59> BenC: Not currently
[03:25] <mrec> BenC: ok I'll mirror that git tree and add the driver
[04:53] <BenC> kylem: are you checking into alsa merge from 2.6.23-rc?
[04:54] <kylem> yes
[04:56] <IntuitiveNipple> 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] <BenC> IntuitiveNipple: perhaps the ACK is corrupt/invalid?
[04:59] <BenC> kylem: ok, then please revert my hda-intel hackage :)
[04:59] <kylem> well, i'll do whatevers easiest. might be that it's simpler to just pull out multi-series patches and cherrypick them
[05:00] <IntuitiveNipple> 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] <IntuitiveNipple> 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] <BenC> 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] <BenC> 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] <kylem> BenC, oh, right, sorry, i hadn't pulled.
[05:03] <kylem> BenC, what do you want to do about -stable?
[05:03] <BenC> kylem: alsa? Nothing for now
[05:03] <kylem> no, i mean 2.6.22.y
[05:04] <BenC> Oh, right, definitely keep that synced up until kernel freeze
[05:04] <BenC> will lower kees work load post gutsy release :)
[05:04] <kylem> ok, i have a tree where i merged .y
[05:04] <IntuitiveNipple> thats what i was wondering... could that occur in two different drivers by co-incidence would you think (tg3/e1000) ?
[05:05] <zul> kylem: did you get my patch?
[05:05] <kylem> yes.
[05:05] <zul> coolio
[05:05] <BenC> IntuitiveNipple: netdev might be a better place to ask this
[05:05] <IntuitiveNipple> didn't realise there was a channel for it... thanks!
[05:06] <BenC> at least for me, it's been a few years since I dug into eth/ip interaction
[05:06] <zul> cool there is a patch for x86_64 paravirt support 
[05:07] <BenC> IntuitiveNipple: not sure if there's a channel, but there is a mailing list
[05:08] <IntuitiveNipple> oh i see... that explains alot :D
[05:25] <bdmurray> ipw3945 is in linux-ubuntu-modules now is that right?
[05:29] <mrec> BenC: is there any preference where I should put the userspace shared libraries which are used by the drivers?
[05:42] <BenC> mrec: in some other package :)
[05:43] <BenC> 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] <mrec> BenC: hmm the firmware is compiled into it
[05:47] <mrec> (although everything beside the firmware binary is OSS)
[05:51] <mrec> BenC: http://mcentral.de/hg/~mrec/userspace-tuner
[05:51] <mrec> this is currently the most important component of the driver
[05:52] <mrec> it should build against every kernel
[06:01] <BenC> mrec: firmware can go iun lum too
[06:01] <mrec> http://mcentral.de/hg/~mrec/userspace-tuner/
[06:01] <mrec> the firmware doesn't get loaded by udev
[06:01] <mrec> it gets passed to kernelspace through the userspace daemon
[06:06] <BenC> mrec: not using standard kernel APIs...tsk tsk
[06:07] <mrec> 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] <mrec> I should push that patch immediatelly anyway
[06:08] <mrec> 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] <mrec> http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages
[06:51] <mjg59> BenC: http://lkml.org/lkml/2007/8/8/251
[06:51] <mjg59> Should be the proper fix for the Turion issue
[07:34] <rtg> mjg59: I picked up the patch and am building. I have a Dell E1501 that exhibits the problem quite nicely.
[08:01] <ThrobbingBrain66> 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] <ThrobbingBrain66> I now realize I may have given you some misleading info
[08:04] <ThrobbingBrain66> 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] <ThrobbingBrain66> 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] <ThrobbingBrain66> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/126140
[08:18] <rtg> mjg59: http://lkml.org/lkml/2007/8/8/251 fixes the E1501 boot problem. Thanks for the notice.
[08:26] <mjg59> rtg: Excellent
[08:33] <BenC> rtg: sweet, can you get that into gutsy git soonish?
[08:33] <rtg> BenC: working on it.
[08:35] <BenC> I can test it on my 1521 too
[08:38] <ThrobbingBrain66> 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] <BenC> ThrobbingBrain66: I saw, not sure what to tell you
[08:38] <ThrobbingBrain66> oh, sorry
[08:39] <ThrobbingBrain66> wouldnt that then make it a kernel bug again?
[08:39] <BenC> I'm not sure what you mean by snd-hda-intel
[08:39] <BenC> most of my systems use that driver and they all shut down fine
[08:40] <ThrobbingBrain66> i understand that, but when i run a script at shut down, everything goes smoothly
[08:41] <ThrobbingBrain66> 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] <rtg> 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
[09:02] <ThrobbingBrain66> must just be a weird bug with my particular laptop, thanks for the help
[09:03] <BenC> ThrobbingBrain66: could be something in your bios
[09:03] <BenC> ThrobbingBrain66: check if there is a BIOS upgrade?
[11:05] (BenC/#ubuntu-kernel) mjg59: can we update the init scripts so we don't have to keep the ugly patch?
[11:06] <mjg59> 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] <BenC> mjg59: actually, part of the reason I dropped it was because the code did change, and it wasn't trivial to merge
[11:11] <BenC> and the description of the changes led me to believe we could do with out it
[11:13] <mjg59> BenC: vesafb.c hasn't been touched since last year?
[11:14] <BenC> maybe I'm thinking of vgafb
[11:14] <BenC> vga16fb I mean
[11:14] <BenC> I wish one of those could die
[11:14] <mjg59> vga16fb *needs* to be modular
[11:14] <mjg59> Or alternatively just not built at all now
[11:15] <mjg59> Though it's only had a few bugfixes this year
[11:15] <mjg59> Nothing major
[11:15] <BenC> Ok, vga16fb is modular
[11:15] <BenC> vesafb isn't
[11:15] <mjg59> vesafb should be
[11:16] <BenC> Why isn't the modular vesafb patch upstream?
[11:16] <mjg59> Because it's a (basically unnecessary) hack
[11:16] <mjg59> But the framebuffer init stuff we have is not straightforward
[11:16] <BenC> if it's unnecessary, then why do we need it? :)
[11:16] <mjg59> So I'd rather not have to rewrite that
[11:17] <BenC> gotcha
[12:15] <bdmurray> Does bug 129812 need any more information other than the specific kernel version?
[12:18] <mjg59> bdmurray: The hardware description