rsalvetibjf: cool, thanks00:38
=== 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
* apw yawns08:23
* smb looks whether apw looks a bit sweaty08:23
apwhuh ?08:23
smbHow does it feel being dragged into mumble hell08:24
=== artnay_ is now known as artnay
tseliotsmb, 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:36
apwtseliot, 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
apwbut i suspect its the rules themseleves which fail08:37
apwthe key think is they look for the Ubuntu-<version> messages in the commits to find them08:38
apws/them/the start commit/08:38
apwtseliot, ^^08:38
tseliotapw: ok, thanks08:39
smbMy 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 editor08:39
apwtseliot, you can find the version number it is looking for using the fdr printenv08:39
tseliotapw: this looks correct (at least to my sleep deprived eyes) http://pastebin.ubuntu.com/533394/08:42
apwtseliot, so this is the first version on the branch as it is looking for 2.6.37-0.008:43
apwprev_revision     = 0.008:43
tseliotapw: yes, that's correct08:43
apwso unless you have an UBUNTU: Ubuntu-2.6.37-0.0  commit somewhere it will not woerk08:44
apwi generally just hand make the commit log for the firrst time there, must as smb suggested08:44
apwit will work the next time08:44
tseliotapw: I have this though: "UBUNTU: (release) Ubuntu-2.6.37-0.0 for $MYPROJECT"08:45
tseliotmaybe "(release)" broke the regular expression or whatever it's using08:46
apwno its the for $MYPROJECT that broke it08:46
tseliotapw: oh, really? Where is it in the code?08:47
apwtseliot, look for printchanges08:48
tseliotapw: I can only see insert-changes.pl in misc08: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:49
apwtseliot, it is that way because we generally prefix the taging on branches08:50
tseliotapw: what file is that? I mean the one with printchanges08:50
apwUBUNTU: NBK-Ubuntu-2.6.37-1.208:51
apwnormally they are like that ...08:51
apwtseliot, that is debian/rules/1*08:51
apwbut grep is your friend08:51
tseliotapw: right, I should have used a combination of find and grep08:51
apwgit grep is even better08:52
smbtseliot, There is grep -r ;-)08:52
tseliotapw, smb: adding a simple .* to the regular expression did it :)08:53
apwyeah thats fine for your bracnch, a bit risky for main08:53
tseliotlazyness FTW :)08:53
tseliotapw: yes, it's just for my branch08:54
tseliotapw: BTW this doesn't seem to change insertchanges, only printchanges08:55
apwtseliot, insertchangs directly uses printchanges08:55
tseliotthis saved me a lot of time08:55
apwhave you lost the markers08:56
tseliotapw: I know that it should use printchanges but maybe it aborts the operation08:57
tseliotit = insertchanges08:57
apwtseliot, insertchanges needs the markers in the changelog, which get lost as soon as the first insertchanges fails to find anything08:57
apwyou often need to get them back, git diff will show you what went away08:58
tseliotapw: markers? Aren't they in printchanges?08:59
apwthere are three lines of markers in the changelog, added by startnewrelease09:00
apwwhich are removed and replaced by insertchanges09:00
apwis they are not there, it cannot find the right place to put the output09:00
tseliotapw: oh, I didn't use startnewrelease for the changelog09:01
apwtheres your problem09:01
tseliotapw: http://kernel.ubuntu.com is public, isn't it? Does it support private branches?09:24
apwtseliot, define private, as in secret and must be kept hidden?09:31
tseliotapw: as in accessible only to canonical employees09:31
tseliotapw: and hidden09:32
apwthen zinc is not an appropriate venue09:32
apwthere are non-canonical people who can login for example09:32
apwthere is an oem repo somewhere09:32
apwwhihc you should ask about on #hwe09:33
tseliotapw: ok, thanks09:33
smbcking, apw https://wiki.canonical.com/UbuntuPlatform/Rally/Natty09:36
ckingsmb, ta09:40
=== doko__ is now known as doko
akheronjust stumbled upon bug #15427113:31
ubot2Launchpad 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/15427113:31
akherondoes anyone have a clue of what could cause this?13:31
akheronthe 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 again13:33
akheronsmb: no, I have this with a lucid domU13:33
apwwell if it is a kernel issue then it should really be files against the kernel ?!?13:34
akherondomU is 2.6.32-22-generic-pae, dom0 is lenny's 2.6.26 something13:34
akheronxen 3.313:35
akheronapw: I don't really know where the bug is but seems kernel to me13:35
smbHm, in Hardy there has been some F-RTO issues. Though I thought 2.6.26 should have those fixed. 13:35
apwsmb, the tcpdump seems to show packats being sent >MSS13:36
akheronI can send more tcpdumps if someone wants to13:36
akheronjust figured out today why my domUs have been sending data VERY slowly13:36
apwakheron, i assume the ethtool -K tx  off works for you ?13:37
akheronapw: yes, fixes it completely13:37
akheronbut I don't understand why some tx checksumming would matter13:37
apwakheron, well you are handing off processing to the 'hardware' which presumably is the xen virtualised driver ... and perhaps its utterly broken13:39
akheronah, ok13:39
apwi've documented the work-around prominently in the description and added a task for the kernel13:39
akheronso you think the bug is in the dom0 kernel then?13:40
akheronwe're using debian kernels there are ubuntu doesn't ship them, afaik13:40
akheronI'm not the system admin :)13:40
apwakheron, no i suspect it is in the domU kernel as its only there that switching it13:41
apwmakes a difference13:41
smbWell dom0 would be the one supplying the "hw"13:41
smbLast dom0 we did was hardy13:41
akheronsmb: yes, that's what I thought also13:41
apwsmb, not necessarily, as this is logically bridged13:42
apwintermediate hops do not normally change the package they just ship it along13:42
apwand as the change of config is on the domU, and that change should be a no-op from the view of outside the domU13:42
apwit seems likely it should be the domU which is breaking things13:42
smbBut as you say you change the tx offloading13:43
apwbut that is tx offloading in the domU kernel, i can only offload it to the driver, and that is still in my domU13:43
apwit is possible that the offloading means that the dom0 does the summing instead, but that does seeem odd to me13:44
tgardnerapw, wouldn't that imply para-virt ops? I'm pretty sure a DomU of that vintage wasn't that smart.13:45
apwakheron, what sort of fake ethernet is being used in the domU13:45
akheronI'm just looking13:45
apwtgardner, it is a lucid domU13:46
tgardneroh, I thought I saw Hardy mentioned13:46
akherontgardner: the bug is very old13:46
smbwell ii read correctly this is since gutsy13:46
apwsmb, yep i mean new kernels are still broke, or its dom0 yes13:49
smbYeah. Quite odd13:49
akheronit seems to me that xen has some weird checksum offloading system13:56
akheronnow that I'm looking, I can find many pages with google that suggest to disable tx offloading13:58
apw        /* We need checksum offload to enable scatter/gather and TSO. */13:59
=== zul is now known as ep
=== ep is now known as zul
apwit seems once we turn off the tx sum offload, we stop using scatter gather and TSO whatever the latter is13:59
apw                dev->mtu = ETH_DATA_LEN;14:00
apwheh but what it does do ... is immediatly do that14:00
apwoh ignore me14:00
tgardnerapw, isn't there a sysfs way to cap mtu ?14:00
smbapw, Where the heck are you looking? Latest code?14:00
apwtgardner, yep and that is set as far as i can see, and when it starts SG mode it ignores it and breaks everything14:01
tgardnerapw, hmm, bad news14:01
apwsmb,  lucid domU support14:02
apwstatic int xennet_change_mtu(struct net_device *dev, int mtu)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
apwthat seems to allow MTU to clamp close to 64k in scatter-gather mode, turning off tx csum also turns that off14:02
apwi suspect that when csum is turned on the dom0 is meant to do something meaningful with the packets before pushing them out onto the wire14:03
apwand i suspect it is not14:03
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
apwdoes 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:04
akheronif scanf fails, val = 0 and if val == 0, return -ENOSYS14:05
akheronlooks correct to me14:05
apwdoh just my eyes, thanks14:05
apwfrom what i can see i think xennet assumes we can pass large packets to the host and let it fragment and sum them14:06
apwand it looks like the host is not14:06
akheronso it's dom0 problem after all?14:07
apwi would lean to debugging there first yes14:07
akheronat least the fragmentation needed packets arrive at domU14:07
smbI dunno, max is not used. Its mtu in the code above14:07
smbAnd that is set to the right value14:07
tgardnerapw, we could test your theory by fixing the mtu CAP on the domU client.14:08
akheronthe mtu on eth0 is 150014:08
apwwell 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 it14:08
akheronbut it still sends >2900 byte packets14:08
akheronI can see that using tcpdump clearly14:08
apwright, and the MTU seems to be ignored at the domU when when DG and CSUM offloading is enabled14:09
apwSG even14:09
apwand we pass all the bits as one packet even if it was multiple skb's14:09
akherondoest it try to optimize domU - domU traffic inside dom0 by ignoring mtu?14:09
akheronbecause that traffic seems to work14:09
apwakheron, yes i think its meant to optimise by ignoring MTU during the cross domU/domH transition14:10
apwassuming that the dom0 will fit the result into the MTU before shoving it into the bridge at the other side14:10
akheronbut it doesn't14:11
apwindeed it seems not14:11
apwbut that seems like a dom0 issue14:11
apwits not clear from the interface how you would avoid having to handle that at the other end of the link14:11
apwakheron, one interesting test would be to disable tx offloading then turn it back on and confirm that the issue reasserts itself14:16
apwsmb, with luck xen dom0 will be upstream by the next LTS, ie by the time hardy goes away14:20
smbapw, and maybe fixed. Though (and unfortunately I have not time to learn enough) lots of the interaction is done by a user-space part14:21
apwyeah i bet it is14:22
apwwe have qemu for the same purpose in kvm14:22
smbI believe they use qemu too14:22
=== yofel_ is now known as yofel
smbapw, 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))14:34
=== bjf[afk] is now known as bjf
tgardnerbjf, did mumble die on us?16:01
ckingdied on me16:01
smbSeems to have for me16:01
JFodiead for everyone it seems16:01
smbAnd it looks like canonical irc as well16:01
tgardnerjust came back16:01
ckingme too16:01
ckingand my email16:01
=== diwic is now known as diwic_afk
ubuntuuserI have run into some issues between my SATA-controller  (VT6420) and my new Western Digital Green Power disk (WD10EARS)16:21
ubuntuuserThere seems to be a fix for it16:21
ubuntuuserwhat can I do to help get the patch in ubuntu's kernel as soon as possible?16:22
tgardnerubuntuuser, this seems like a stable updates sort of patch. 16:26
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:27
ogasawarabcurtiswx_: http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch16:28
bcurtiswx_ogasawara, :) muchas gracias16:28
manjohave you guys looked at https://status.canonical.com/doc/faq ?16:34
apwmanjo, how does microblogging help us?  i have enough of that in my life already16:38
* apw pokes manjo16:46
manjoapw, on a call16:47
apwso multi-task :)16:47
JFowhy must headaches all act differently? This one refuses to let my eyes focus for very long :-/16:51
JFothat is my QOTD16:51
ubuntuuserthanks tgardner, I am new to bug reporting/patching etc, can I do something/do I have to file a bug report?17:00
manjoubuntuuser, you could file a bug and add a comment pointing to that patch17:04
=== jdstrand is now known as jdstrand_
apwJFo, different causes, that one is likely eye strain related17:26
JFocould be17:27
JFoI think it is still lack of sleep related17:27
JFoeither way, it sucks17:27
apwgenerally being awake is signalled by eyes not closed and not resting17:28
ogra_actgardner, hmm, Bug 673509 is no duplicate of bug 67350417:29
ubot2Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/67350917:29
ubot2Launchpad 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/67350417:29
ogra_ac*of Bug 67350917:29
tgardnerogra_ac, its already been pointed out to me17:29
ogra_actgardner, but now we have verification tags on both 17:29
ogra_acafter the disaster yesterday i'd like to avoid that uploads get wiped from -proposed unconditionally through wrong tagging17:30
tgardnerogra_ac, ti-omap4 is building.17:30
ogra_acyes, and the beagleboard bug has a verification-needed tag now17:30
tgardnerogra_ac, that wasn't a disaster, merely a minor hiccup17:30
ogra_acwell, tell that to tobin who moans about having to spend a week to find community testers17:31
apwheh well we do want to know we arn't bricking boards right ?17:38
ogra_acapw, well, hard to brick a board if you apply the patch to the wrong kernel :P17:42
ogra_aci set the bug back to proper status so we can track verification as soon as the next linux package goes up17:43
jewsucanusewhat rc is the scheduler patch er... scheduled for?18:12
tgardnerjewsucanuse, http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch18:14
jewsucanusethx tim18:14
Sarvattjewsucanuse: 2.6.38-rc1 most likely unless some magic happens18:14
tgardnerapw, 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
jewsucanusenatty is still scheduled for .38 right?18:14
apwtgardner, 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 when18:18
tgardnerapw, ah! Its .profile that sources .bashrc18:22
=== zul_ is now known as zul
ubuntuuserok i will file a bug, thanks tgardner, manjo18:50
JanCapw: it's documented in 'man bash' and 'info bash', you know...  ;)18:53
apwJanC, yeah it is, but it uses words that make it much easier to just try it and see :)18:53
JanCeh, it seems like it's plain English to me, but I'm not a native speaker18:56
=== xfaf is now known as zul
ubuntuuserok I have reported the bug (676644) sorry if it is not quite up to the usual standards, I am new to this ;)19:25
* tgardner lunches19:29
hallynto 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:29
* hallyn wants to get resume on his netbook working!19:30
tgardnerhallyn, why not try the kernel in https://launchpad.net/~kernel-ppa/+archive ?19:31
tgardnerits based on 2.6.37-rc2 (and is still cooking)19:32
=== tgardner is now known as tgardner-afk
JanCubuntuuser: if you mention LP bugs on IRC, use something like: bug 67664419:44
ubot2Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/67664419:44
JanCsee why?  ;)19:44
ubuntuuserk thanks JanC19:45
hallyntgardner-afk: that kernel doesn't work for me :)19:51
hallyntgardner-afk: so i wanna tweak it to try and make it work again19:52
JanCubuntuuser: 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:53
ubuntuuserJanC: 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.19:55
=== tgardner-afk is now known as tgardner
tgardnerhallyn, whats missing frmo that kernel that _is_ in the mainline build? Or were you planning to patch the mainline?20:00
ubuntuusergoodbye to all, thank you20:03
hallyntgardner: well, i want to debug it. 20:05
hallyntgardner: in the lucid kernel, resume worked20:05
hallynin maverick kernel AND In upstream, it fails20:05
hallyni'm kinda hoping i can find an easy fix20:05
tgardnerhallyn, bummer. there are a lot of commits between lucid and maverick.20:06
hallyni did open bug 674075, but am figuring since it's broken upstream, there's not much hope :)20:07
ubot2Launchpad 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/67407520:07
tgardnerhallyn, which Broadcom driver are you using? The hybrid driver?20:11
hallyn'wl' i guess20:15
hallyn(accoding to lspci -v)20:16
* jjohansen -> lunch20:17
tgardnerhallyn, since its a binary blob, try 'modprobe -r wl' before suspending.20:17
tgardneryou might also try 'rfkill bluetooth'20:17
hallynno bluetooth on this thing it seems (i found out the hard way yesterday when i was expecting to use headset to mumble :)20:18
hallyni'll try the modprobe -r in a few mins, thanks20:18
dany_hi all20:32
dany_hi guys20:48
tgardnerogasawara, shall I reset Lucid master-next back to its original HEAD ?20:48
ogasawaratgardner: nah, just about to push.  want to do a quick test build first.20:49
tgardnerogasawara, but you're gonna clobber HEAD, right?20:49
ogasawaratgardner: I'm just gonna force the push over the existing master-next20:49
ogasawaratgardner: right20:49
tgardnerogasawara, ack. lemme know when cause I've a couple patches to drop in20:49
ogasawaratgardner: I just pushed.  if there's a build failure, I'll fix it up in a subsequent commit.20:52
ogasawaratgardner: I was also gonna drop in your patch for bug 628776, unless you beat me to it20:54
ubot2Launchpad 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/62877620:54
tgardnerogasawara, there are 2 patches for 628776. I'm just gonna do a test build then mark the bug verification-done20:55
tgardnersince its verifiable by inspection20:55
ogasawaratgardner: cool20:55
hallyntgardner: wl is apparently not the culprit.  at least not the only one21:03
tgardnerhallyn, well, if the bug is still upstream then you're likely gonna have bisect it21:05
hallyntgardner: right21:09
hallyntgardner: hence my original question.  i recon' i'll just try it21:10
=== tgardner is now known as tgardner-afk
* jjohansen running an errand22:06
dany_no one?22:13
=== ogra_ac_ is now known as ogra_ac
apwdany_, if you have a question ask it ...22:56
dany_apw: I said before, I'll copy again :=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.so22:57
dany_../libdc1394/.libs/libdc1394_control.so: undefined reference to `raw1394_set_iso_handler'22:57
dany_I'm installing an old version of libdc139422:57
dany_the 1.2 one22:57
dany_I think that it doesn't see the raw library that is installed in my system22: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 one22:57
=== johanbr_ is now known as johanbr
=== bjf is now known as bjf[afk]

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!