[00:38] <rsalveti> bjf: cool, thanks
[08:23]  * apw yawns
[08:23]  * smb looks whether apw looks a bit sweaty
[08:23] <apw> huh ?
[08:24] <smb> How does it feel being dragged into mumble hell
[08:36] <tseliot> smb, apw: do you know where's the script that's called by "debian/rules insertchanges"? I'm asking as it's not working correctly for me (I'm using a customised flavour)
[08:37] <apw> tseliot, in part some of it is in the rules (the bit which works out the start point) and the second debian/scripts/misc/git-*log*
[08:37] <apw> but i suspect its the rules themseleves which fail
[08:38] <apw> the key think is they look for the Ubuntu-<version> messages in the commits to find them
[08:38] <apw> s/them/the start commit/
[08:38] <apw> tseliot, ^^
[08:39] <tseliot> apw: ok, thanks
[08:39] <smb> My workaround for that is sometimes "git log <whatever range>|./devian/scripts/misc/git-ubuntu.log > bla" and then include the output in the changelog with my favorite editor
[08:39] <apw> tseliot, you can find the version number it is looking for using the fdr printenv
[08:42] <tseliot> apw: this looks correct (at least to my sleep deprived eyes) http://pastebin.ubuntu.com/533394/
[08:43] <apw> tseliot, so this is the first version on the branch as it is looking for 2.6.37-0.0
[08:43] <apw> prev_revision     = 0.0
[08:43] <tseliot> apw: yes, that's correct
[08:44] <apw> so unless you have an UBUNTU: Ubuntu-2.6.37-0.0  commit somewhere it will not woerk
[08:44] <apw> i generally just hand make the commit log for the firrst time there, must as smb suggested
[08:44] <apw> it will work the next time
[08:45] <tseliot> apw: I have this though: "UBUNTU: (release) Ubuntu-2.6.37-0.0 for $MYPROJECT"
[08:46] <tseliot> maybe "(release)" broke the regular expression or whatever it's using
[08:46] <apw> no its the for $MYPROJECT that broke it
[08:47] <tseliot> apw: oh, really? Where is it in the code?
[08:48] <apw> tseliot, look for printchanges
[08:49] <tseliot> apw: I can only see insert-changes.pl in misc
[08:49] <apw> rintchanges:
[08:49] <apw>         @baseCommit=$$(git log --pretty=format:'%H %s' | \
[08:49] <apw>                 awk '/UBUNTU: '".*Ubuntu-$(release)-$(prev_revision)"'$$/ { print $$1; exit }'); \
[08:49] <apw>                 git log "$$baseCommit"..HEAD | \
[08:49] <apw>                 perl -w -f $(DROOT)/scripts/misc/git-ubuntu-log $(ubuntu_log_opts)
[08:50] <apw> tseliot, it is that way because we generally prefix the taging on branches
[08:50] <tseliot> apw: what file is that? I mean the one with printchanges
[08:51] <apw> UBUNTU: NBK-Ubuntu-2.6.37-1.2
[08:51] <apw> normally they are like that ...
[08:51] <apw> tseliot, that is debian/rules/1*
[08:51] <apw> but grep is your friend
[08:51] <tseliot> apw: right, I should have used a combination of find and grep
[08:51] <tseliot> thanks
[08:52] <apw> git grep is even better
[08:52] <smb> tseliot, There is grep -r ;-)
[08:52] <tseliot> ah
[08:53] <tseliot> apw, smb: adding a simple .* to the regular expression did it :)
[08:53] <apw> yeah thats fine for your bracnch, a bit risky for main
[08:53] <tseliot> lazyness FTW :)
[08:54] <tseliot> apw: yes, it's just for my branch
[08:55] <tseliot> apw: BTW this doesn't seem to change insertchanges, only printchanges
[08:55] <apw> tseliot, insertchangs directly uses printchanges
[08:55] <tseliot> this saved me a lot of time
[08:56] <apw> have you lost the markers
[08:57] <tseliot> apw: I know that it should use printchanges but maybe it aborts the operation
[08:57] <tseliot> it = insertchanges
[08:57] <apw> tseliot, insertchanges needs the markers in the changelog, which get lost as soon as the first insertchanges fails to find anything
[08:58] <apw> you often need to get them back, git diff will show you what went away
[08:59] <tseliot> apw: markers? Aren't they in printchanges?
[09:00] <apw> there are three lines of markers in the changelog, added by startnewrelease
[09:00] <apw> which are removed and replaced by insertchanges
[09:00] <apw> is they are not there, it cannot find the right place to put the output
[09:01] <tseliot> apw: oh, I didn't use startnewrelease for the changelog
[09:01] <apw> theres your problem
[09:02] <tseliot> right
[09:24] <tseliot> apw: http://kernel.ubuntu.com is public, isn't it? Does it support private branches?
[09:31] <apw> tseliot, define private, as in secret and must be kept hidden?
[09:31] <tseliot> apw: as in accessible only to canonical employees
[09:32] <tseliot> apw: and hidden
[09:32] <apw> then zinc is not an appropriate venue
[09:32] <apw> there are non-canonical people who can login for example
[09:32] <tseliot> s/to/by/
[09:32] <apw> there is an oem repo somewhere
[09:33] <apw> whihc you should ask about on #hwe
[09:33] <tseliot> apw: ok, thanks
[09:36] <smb> cking, apw https://wiki.canonical.com/UbuntuPlatform/Rally/Natty
[09:40] <cking> smb, ta
[09:50] <kraut> moin
[09:52] <apw> https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[13:31] <akheron> just stumbled upon bug #154271
[13:31] <ubot2> Launchpad bug 154271 in xen-3.3 (Ubuntu) (and 2 other projects) "xenU sending too big packets (affects: 2) (heat: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/154271
[13:31] <akheron> does anyone have a clue of what could cause this?
[13:33] <smb> gutsy???
[13:33] <akheron> the kernel in xen domU sends too big IP packet, router asks to fragment, kernel sends a smaller one, the other end of the connection acks, and then the kernel sends too big packet again
[13:33] <akheron> smb: no, I have this with a lucid domU
[13:34] <apw> well if it is a kernel issue then it should really be files against the kernel ?!?
[13:34] <akheron> domU is 2.6.32-22-generic-pae, dom0 is lenny's 2.6.26 something
[13:35] <akheron> xen 3.3
[13:35] <akheron> apw: I don't really know where the bug is but seems kernel to me
[13:35] <smb> Hm, in Hardy there has been some F-RTO issues. Though I thought 2.6.26 should have those fixed. 
[13:36] <apw> smb, the tcpdump seems to show packats being sent >MSS
[13:36] <akheron> I can send more tcpdumps if someone wants to
[13:36] <akheron> just figured out today why my domUs have been sending data VERY slowly
[13:37] <apw> akheron, i assume the ethtool -K tx  off works for you ?
[13:37] <akheron> apw: yes, fixes it completely
[13:37] <akheron> but I don't understand why some tx checksumming would matter
[13:39] <apw> akheron, well you are handing off processing to the 'hardware' which presumably is the xen virtualised driver ... and perhaps its utterly broken
[13:39] <akheron> ah, ok
[13:39] <apw> i've documented the work-around prominently in the description and added a task for the kernel
[13:40] <akheron> so you think the bug is in the dom0 kernel then?
[13:40] <akheron> we're using debian kernels there are ubuntu doesn't ship them, afaik
[13:40] <akheron> I'm not the system admin :)
[13:41] <apw> akheron, no i suspect it is in the domU kernel as its only there that switching it
[13:41] <apw> makes a difference
[13:41] <smb> Well dom0 would be the one supplying the "hw"
[13:41] <smb> Last dom0 we did was hardy
[13:41] <akheron> smb: yes, that's what I thought also
[13:42] <apw> smb, not necessarily, as this is logically bridged
[13:42] <apw> intermediate hops do not normally change the package they just ship it along
[13:42] <apw> and as the change of config is on the domU, and that change should be a no-op from the view of outside the domU
[13:42] <apw> it seems likely it should be the domU which is breaking things
[13:43] <smb> But as you say you change the tx offloading
[13:43] <apw> but that is tx offloading in the domU kernel, i can only offload it to the driver, and that is still in my domU
[13:43] <smb> hm
[13:44] <apw> it is possible that the offloading means that the dom0 does the summing instead, but that does seeem odd to me
[13:45] <tgardner> apw, wouldn't that imply para-virt ops? I'm pretty sure a DomU of that vintage wasn't that smart.
[13:45] <apw> akheron, what sort of fake ethernet is being used in the domU
[13:45] <akheron> I'm just looking
[13:46] <apw> tgardner, it is a lucid domU
[13:46] <akheron> xen_netfront
[13:46] <tgardner> oh, I thought I saw Hardy mentioned
[13:46] <akheron> tgardner: the bug is very old
[13:46] <smb> well ii read correctly this is since gutsy
[13:49] <apw> smb, yep i mean new kernels are still broke, or its dom0 yes
[13:49] <smb> Yeah. Quite odd
[13:56] <akheron> it seems to me that xen has some weird checksum offloading system
[13:58] <akheron> now that I'm looking, I can find many pages with google that suggest to disable tx offloading
[13:59] <apw>         /* We need checksum offload to enable scatter/gather and TSO. */
[13:59] <apw> it seems once we turn off the tx sum offload, we stop using scatter gather and TSO whatever the latter is
[14:00] <apw>                 dev->mtu = ETH_DATA_LEN;
[14:00] <apw> heh but what it does do ... is immediatly do that
[14:00] <apw> oh ignore me
[14:00] <tgardner> apw, isn't there a sysfs way to cap mtu ?
[14:00] <smb> apw, Where the heck are you looking? Latest code?
[14:01] <apw> tgardner, yep and that is set as far as i can see, and when it starts SG mode it ignores it and breaks everything
[14:01] <tgardner> apw, hmm, bad news
[14:02] <apw> smb,  lucid domU support
[14:02] <apw> static int xennet_change_mtu(struct net_device *dev, int mtu)
[14:02] <apw> {
[14:02] <apw>         int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN;
[14:02] <apw>         if (mtu > max)
[14:02] <apw>                 return -EINVAL;
[14:02] <apw>         dev->mtu = mtu;
[14:02] <apw>         return 0;
[14:02] <apw> }
[14:02] <apw> that seems to allow MTU to clamp close to 64k in scatter-gather mode, turning off tx csum also turns that off
[14:03] <apw> i suspect that when csum is turned on the dom0 is meant to do something meaningful with the packets before pushing them out onto the wire
[14:03] <apw> and i suspect it is not
[14:04] <apw>                 if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-sg",
[14:04] <apw>                                  "%d", &val) < 0)
[14:04] <apw>                         val = 0;
[14:04] <apw>                 if (!val)
[14:04] <apw>                         return -ENOSYS;
[14:04] <apw> does that error condition seem inverted to anyone?  if we are unable to lookup feature-sg surly we should assume we have not got it, not assume we have ?
[14:05] <akheron> if scanf fails, val = 0 and if val == 0, return -ENOSYS
[14:05] <akheron> looks correct to me
[14:05] <apw> doh just my eyes, thanks
[14:05] <akheron> :)
[14:06] <apw> from what i can see i think xennet assumes we can pass large packets to the host and let it fragment and sum them
[14:06] <apw> and it looks like the host is not
[14:07] <akheron> so it's dom0 problem after all?
[14:07] <apw> i would lean to debugging there first yes
[14:07] <akheron> at least the fragmentation needed packets arrive at domU
[14:07] <smb> I dunno, max is not used. Its mtu in the code above
[14:07] <smb> And that is set to the right value
[14:08] <tgardner> apw, we could test your theory by fixing the mtu CAP on the domU client.
[14:08] <akheron> the mtu on eth0 is 1500
[14:08] <apw> well i would expect that if we shove a bad packet out without fragmenting it and get a reply from an external router, i would expect us to pass that back to the domU thinking its for it
[14:08] <akheron> but it still sends >2900 byte packets
[14:08] <akheron> I can see that using tcpdump clearly
[14:09] <apw> right, and the MTU seems to be ignored at the domU when when DG and CSUM offloading is enabled
[14:09] <apw> SG even
[14:09] <apw> and we pass all the bits as one packet even if it was multiple skb's
[14:09] <akheron> doest it try to optimize domU - domU traffic inside dom0 by ignoring mtu?
[14:09] <akheron> because that traffic seems to work
[14:10] <apw> akheron, yes i think its meant to optimise by ignoring MTU during the cross domU/domH transition
[14:10] <apw> assuming that the dom0 will fit the result into the MTU before shoving it into the bridge at the other side
[14:11] <akheron> but it doesn't
[14:11] <apw> indeed it seems not
[14:11] <apw> but that seems like a dom0 issue
[14:11] <apw> its not clear from the interface how you would avoid having to handle that at the other end of the link
[14:16] <apw> akheron, one interesting test would be to disable tx offloading then turn it back on and confirm that the issue reasserts itself
[14:20] <apw> smb, with luck xen dom0 will be upstream by the next LTS, ie by the time hardy goes away
[14:21] <smb> apw, and maybe fixed. Though (and unfortunately I have not time to learn enough) lots of the interaction is done by a user-space part
[14:22] <apw> yeah i bet it is
[14:22] <apw> we have qemu for the same purpose in kvm
[14:22] <smb> I believe they use qemu too
[14:34] <smb> apw, Hm, just reading that qemu is more likely used for HVM domUs not for the PV domUs (which use a xennet-backend (which is maybe in the hypervisor code))
[15:55] <bjf> https://kernel-tools.canonical.com/srus.html
[15:56] <bjf> https://kernel-tools.canonical.com/queues.html
[16:01] <tgardner> bjf, did mumble die on us?
[16:01] <cking> died on me
[16:01] <JFo> yep
[16:01] <smb> Seems to have for me
[16:01] <bjf> yup
[16:01] <JFo> diead for everyone it seems
[16:01] <smb> And it looks like canonical irc as well
[16:01] <JFo> yep
[16:01] <tgardner> just came back
[16:01] <cking> me too
[16:01] <cking> and my email
[16:20] <ubuntuuser> Hi
[16:21] <ubuntuuser> I have run into some issues between my SATA-controller  (VT6420) and my new Western Digital Green Power disk (WD10EARS)
[16:21] <ubuntuuser> There seems to be a fix for it
[16:21] <ubuntuuser> http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/02db8575ded42ab1
[16:22] <ubuntuuser> what can I do to help get the patch in ubuntu's kernel as soon as possible?
[16:26] <tgardner> ubuntuuser, this seems like a stable updates sort of patch. 
[16:27] <bcurtiswx_> im going to assume you've gotten this question a lot recently and apologize if its overkill.  Does Ubuntu plan on grabbing the ~200 line kernel patch that sig improves things for Natty?
[16:28] <ogasawara> bcurtiswx_: http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch
[16:28] <bcurtiswx_> ogasawara, :) muchas gracias
[16:34] <manjo> have you guys looked at https://status.canonical.com/doc/faq ?
[16:38] <apw> manjo, how does microblogging help us?  i have enough of that in my life already
[16:46]  * apw pokes manjo
[16:47] <manjo> apw, on a call
[16:47] <apw> so multi-task :)
[16:51] <JFo> why must headaches all act differently? This one refuses to let my eyes focus for very long :-/
[16:51] <JFo> that is my QOTD
[17:00] <ubuntuuser> thanks tgardner, I am new to bug reporting/patching etc, can I do something/do I have to file a bug report?
[17:04] <manjo> ubuntuuser, you could file a bug and add a comment pointing to that patch
[17:26] <apw> JFo, different causes, that one is likely eye strain related
[17:27] <JFo> could be
[17:27] <JFo> I think it is still lack of sleep related
[17:27] <JFo> either way, it sucks
[17:28] <apw> generally being awake is signalled by eyes not closed and not resting
[17:29] <ogra_ac> tgardner, hmm, Bug 673509 is no duplicate of bug 673504
[17:29] <ubot2> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/673509
[17:29] <ubot2> Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (dups: 1) (heat: 26)" [High,Fix committed] https://launchpad.net/bugs/673504
[17:29] <ogra_ac> *of Bug 673509
[17:29] <tgardner> ogra_ac, its already been pointed out to me
[17:29] <ogra_ac> tgardner, but now we have verification tags on both 
[17:30] <ogra_ac> after the disaster yesterday i'd like to avoid that uploads get wiped from -proposed unconditionally through wrong tagging
[17:30] <tgardner> ogra_ac, ti-omap4 is building.
[17:30] <ogra_ac> yes, and the beagleboard bug has a verification-needed tag now
[17:30] <tgardner> ogra_ac, that wasn't a disaster, merely a minor hiccup
[17:31] <ogra_ac> well, tell that to tobin who moans about having to spend a week to find community testers
[17:38] <apw> heh well we do want to know we arn't bricking boards right ?
[17:42] <ogra_ac> apw, well, hard to brick a board if you apply the patch to the wrong kernel :P
[17:43] <ogra_ac> i set the bug back to proper status so we can track verification as soon as the next linux package goes up
[18:12] <jewsucanuse> what rc is the scheduler patch er... scheduled for?
[18:14] <tgardner> jewsucanuse, http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch
[18:14] <jewsucanuse> thx tim
[18:14] <Sarvatt> jewsucanuse: 2.6.38-rc1 most likely unless some magic happens
[18:14] <tgardner> apw, how do I get .bashrc to execute on login? Since trashing /home on tangerine I can't seem to automatically get it sourced.
[18:14] <jewsucanuse> natty is still scheduled for .38 right?
[18:18] <apw> tgardner, i believe different ones get souced depending if the connection is interactive or not, i always have to add an echo NAME to .bashrc .bash_login and .profile in my home and try it out to figure out which ones get loaded when
[18:22] <tgardner> apw, ah! Its .profile that sources .bashrc
[18:50] <ubuntuuser> ok i will file a bug, thanks tgardner, manjo
[18:53] <JanC> apw: it's documented in 'man bash' and 'info bash', you know...  ;)
[18:53] <apw> JanC, yeah it is, but it uses words that make it much easier to just try it and see :)
[18:56] <JanC> eh, it seems like it's plain English to me, but I'm not a native speaker
[19:25] <ubuntuuser> ok I have reported the bug (676644) sorry if it is not quite up to the usual standards, I am new to this ;)
[19:29]  * tgardner lunches
[19:29] <hallyn> to replicate a kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/, do i just apply the 3 patches there and hit 'go'?
[19:30]  * hallyn wants to get resume on his netbook working!
[19:31] <tgardner> hallyn, why not try the kernel in https://launchpad.net/~kernel-ppa/+archive ?
[19:32] <tgardner> its based on 2.6.37-rc2 (and is still cooking)
[19:44] <JanC> ubuntuuser: if you mention LP bugs on IRC, use something like: bug 676644
[19:44] <ubot2> Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/676644
[19:44] <JanC> see why?  ;)
[19:45] <ubuntuuser> k thanks JanC
[19:51] <hallyn> tgardner-afk: that kernel doesn't work for me :)
[19:52] <hallyn> tgardner-afk: so i wanna tweak it to try and make it work again
[19:53] <JanC> ubuntuuser: and you can add useful info for the developers to your bug with the command "apport-collect 676644" (not sure if that's still needed if there is a patch available already though)
[19:55] <ubuntuuser> JanC: I'll look into it, I've just looked for some more information about the patch&bug, now I am not so sure it is what I am experiencing... A hardware issue is very unlinkely however, as I have switched out every part of the chain.
[20:00] <tgardner> hallyn, whats missing frmo that kernel that _is_ in the mainline build? Or were you planning to patch the mainline?
[20:03] <ubuntuuser> goodbye to all, thank you
[20:05] <hallyn> tgardner: well, i want to debug it. 
[20:05] <hallyn> tgardner: in the lucid kernel, resume worked
[20:05] <hallyn> in maverick kernel AND In upstream, it fails
[20:05] <hallyn> i'm kinda hoping i can find an easy fix
[20:06] <tgardner> hallyn, bummer. there are a lot of commits between lucid and maverick.
[20:06] <hallyn> yeah
[20:07] <hallyn> i did open bug 674075, but am figuring since it's broken upstream, there's not much hope :)
[20:07] <ubot2> Launchpad bug 674075 in linux (Ubuntu) "Maverick won't resume (lucid will) on Lenovo S10-3 (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/674075
[20:11] <tgardner> hallyn, which Broadcom driver are you using? The hybrid driver?
[20:15] <hallyn> 'wl' i guess
[20:16] <hallyn> (accoding to lspci -v)
[20:17]  * jjohansen -> lunch
[20:17] <tgardner> hallyn, since its a binary blob, try 'modprobe -r wl' before suspending.
[20:17] <tgardner> you might also try 'rfkill bluetooth'
[20:18] <hallyn> no bluetooth on this thing it seems (i found out the hard way yesterday when i was expecting to use headset to mumble :)
[20:18] <hallyn> i'll try the modprobe -r in a few mins, thanks
[20:32] <dany_> hi all
[20:48] <dany_> hi guys
[20:48] <tgardner> ogasawara, shall I reset Lucid master-next back to its original HEAD ?
[20:49] <ogasawara> tgardner: nah, just about to push.  want to do a quick test build first.
[20:49] <tgardner> ogasawara, but you're gonna clobber HEAD, right?
[20:49] <ogasawara> tgardner: I'm just gonna force the push over the existing master-next
[20:49] <ogasawara> tgardner: right
[20:49] <tgardner> ogasawara, ack. lemme know when cause I've a couple patches to drop in
[20:52] <ogasawara> tgardner: I just pushed.  if there's a build failure, I'll fix it up in a subsequent commit.
[20:54] <ogasawara> tgardner: I was also gonna drop in your patch for bug 628776, unless you beat me to it
[20:54] <ubot2> Launchpad bug 628776 in linux (Ubuntu Maverick) (and 2 other projects) "HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs (affects: 2) (heat: 54)" [Low,Fix released] https://launchpad.net/bugs/628776
[20:55] <tgardner> ogasawara, there are 2 patches for 628776. I'm just gonna do a test build then mark the bug verification-done
[20:55] <tgardner> since its verifiable by inspection
[20:55] <ogasawara> tgardner: cool
[21:03] <hallyn> tgardner: wl is apparently not the culprit.  at least not the only one
[21:05] <tgardner> hallyn, well, if the bug is still upstream then you're likely gonna have bisect it
[21:09] <hallyn> tgardner: right
[21:10] <hallyn> tgardner: hence my original question.  i recon' i'll just try it
[22:06]  * jjohansen running an errand
[22:13] <dany_> no one?
[22:56] <apw> dany_, if you have a question ask it ...
[22:57] <dany_> apw: I said before, I'll copy again :=
[22:57] <dany_> :)
[22:57] <dany_> I get this error: gcc -g -O2 -Wall -Wunused -o .libs/dc1394_vloopback dc1394_vloopback.o affine.o  -lm ../libdc1394/.libs/libdc1394_control.so /usr/lib/libraw1394.so
[22:57] <dany_> ../libdc1394/.libs/libdc1394_control.so: undefined reference to `raw1394_set_iso_handler'
[22:57] <dany_> I'm installing an old version of libdc1394
[22:57] <dany_> the 1.2 one
[22:57] <dany_> I think that it doesn't see the raw library that is installed in my system
[22:57] <dany_> Can you tell me how can I say to libdc1394 (there is a configure file)
[22:57] <dany_> to see the libraw?
[22:57] <dany_> tgardner: wl is apparently not the culprit.  at least not the only one