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