| bizhanMona | HI I like to use a Jtag to debug a kernel driver for a PCIe board we build in house, does anyone knows how to use Jtag with ubuntu? thx | 03:28 |
|---|---|---|
| brendand | henrix_, ping | 07:32 |
| === smb` is now known as smb | ||
| === henrix_ is now known as henrix | ||
| * apw yawns | 08:00 | |
| henrix | brendand: pong | 08:03 |
| brendand | henrix, i decided this is a transient issue | 08:05 |
| * smb gets more coffee | 08:05 | |
| brendand | henrix, we can't reproduce it | 08:05 |
| henrix | brendand: ok, great. thanks for the update | 08:06 |
| henrix | brendand: so, you're closing the bug, right? | 08:06 |
| brendand | henrix, yeah. i guess to invalid | 08:07 |
| henrix | ack | 08:08 |
| hrw | hi | 08:58 |
| hrw | can someone remind me why deadline scheduler is used in quantal instead of cfq? | 08:59 |
| === ante_ is now known as ivoks | ||
| alexbligh | hrw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1008400 | 09:22 |
| ubot2 | Ubuntu bug 1008400 in linux "Ubuntu server uses CFQ scheduler instead of deadline" [Medium,In progress] | 09:22 |
| alexbligh | inter alia | 09:22 |
| hrw | thx | 09:31 |
| * henrix -> brb | 10:19 | |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === doko_ is now known as doko | ||
| rtg | any thoughts on why this doesn't always work ? 'schroot --list --all|grep ^session|sed 's/^session://'|while read s;do sudo schroot -f -e --chroot=$s; done' | 13:00 |
| rtg | seems that session teardown is racy. udev is just too quick. | 13:01 |
| Daviey | is cking around? | 13:20 |
| rtg | Daviey, he's out for the week | 13:25 |
| Daviey | Sounds very unbritish, but ok | 13:25 |
| Daviey | (thanks) | 13:25 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| doko | apw, rtg: I see that the x32 support was reverted for quantal. will it be re-enabled for r? | 13:39 |
| apw | doko, should be, it may even already be | 13:39 |
| apw | doko, it was causing graphics regressions of all things | 13:40 |
| doko | apw, generally, or just on certain hardware? | 13:40 |
| apw | i belive it was a specific subset, jsalisbury which h/w wsa affected by X32 | 13:41 |
| rtg | apw, doko: an asus platform IIRC | 13:42 |
| doko | thanks, so I can probably just re-enable it locally | 13:44 |
| rtg | apw, I've disabled CONFIG_X86_X32 for R on the theory that it enables functionality that we are not actually using (except for doko) | 13:44 |
| doko | rtg: we still have the x32 spec. I'll see how far the debian guys are with it | 13:45 |
| rtg | apw, so there is a bug on this schroot thing. at least I'm not the only one seeing it: bug #917339 | 13:46 |
| ubot2 | Launchpad bug 917339 in schroot "10mount: umount: /<<CHROOT>>/dev: device is busy" [Undecided,Confirmed] https://launchpad.net/bugs/917339 | 13:46 |
| smoser | apw, https://groups.google.com/forum/#!msg/linux.kernel/QYDb9t1Bs1c/1ob8Ev9k4PUJ ("overlayfs and inotify") got no responses? | 13:53 |
| apw | smoser, nope, they are not the most responsive of upstreams are they | 13:56 |
| smoser | i just would have thought that it would be a larger sticking point. | 13:56 |
| apw | smoser, indeed | 13:56 |
| smoser | i just lost the better part of an hour wondering why upstart didn't recognize my new job in /etc/ | 13:57 |
| smoser | er.. /etc/init/ | 13:57 |
| apw | i detect a significant amount of fingers in ears in response | 13:57 |
| apw | i have mostly working patches for one possible approach, which closes most of the holes in inotify | 13:57 |
| apw | but we're never going to be able to make tail -f work in its current form | 13:58 |
| smoser | now that i think about this, i'm really surprised that overlayroot (http://blog.dustinkirkland.com/2012/08/introducing-overlayroot-overlayfs.html) works as well as it does. | 13:58 |
| apw | indeed | 13:58 |
| * rtg reboots tangerine in frustration | 14:04 | |
| rtg | back in a bit | 14:04 |
| jsalisbury | apw, looking for which h/w | 14:10 |
| utlemming | kernel team....for 12.10 it looks like hv_storesc was removed from the linux-image-extra package's initrd modules. Was this an intentions change? Before it was in the linux-image-virtual-extra package for 12.04. | 14:15 |
| jsalisbury | apw, this was the bug regarding CONFIG_X86_X32: bug 1041883 | 14:16 |
| ubot2 | Launchpad bug 1041883 in linux "Recent patch to asus-wmi module makes system unbootable" [High,Fix released] https://launchpad.net/bugs/1041883 | 14:16 |
| apw | utlemming, cirtainly nothing recently was deliberatly changed | 14:16 |
| utlemming | apw: k, isn't kernel freeze tomorrow? | 14:16 |
| apw | no it was last week | 14:17 |
| apw | final freeze is tommorrow | 14:17 |
| utlemming | and what about getting this in as a emergency? Azure is busted with out this. MS finally got us logs that shows that the initrd lacks the drivers. | 14:19 |
| apw | how long have we known there was an issue? | 14:19 |
| utlemming | we have know there was an issue since beta-1, but were unable to get any logs to prove the issue. | 14:20 |
| apw | and we are hearing about it today for the first time ? | 14:20 |
| utlemming | to be frank, there was nothing to prove until we got the logs back. | 14:22 |
| apw | well the code in the kernel to include that module is the same in both p and q | 14:23 |
| apw | whats the bug number | 14:23 |
| apw | utlemming, ok this module is in the normal packages | 14:25 |
| apw | -rw-r--r-- root/root 25008 2012-10-08 15:19 ./lib/modules/3.5.0-18-generic/kernel/drivers/scsi/hv_storvsc.ko | 14:25 |
| apw | not in -extras, but in the main linux-image package as you need it for virtual hosts | 14:25 |
| rtg | therefore in -virtual | 14:25 |
| apw | indeed | 14:26 |
| utlemming | apw, rtg: sorry, I mispoke | 14:26 |
| utlemming | bug 1065070 | 14:26 |
| ubot2 | Launchpad bug 1065070 in linux-meta "hv_storesc driver has been removed from the linux-image-virtual-extra initird module list" [Critical,Confirmed] https://launchpad.net/bugs/1065070 | 14:26 |
| apw | so if this is a bug in anything then this is perhaps initramfs-tools | 14:26 |
| apw | rtg am looking at it | 14:27 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === amitk_ is now known as amitk | ||
| === ikonia_ is now known as ikonia | ||
| alexbligh | apw, can I pick your brains on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1064521 please? | 15:36 |
| ubot2 | Ubuntu bug 1064521 in linux "Kernel I/O scheduling writes starving reads, local DoS" [Undecided,Confirmed] | 15:36 |
| apw | alexbligh, you can ask, i am running round like a headless chicken on release things so may be vague | 15:39 |
| alexbligh | apw, ok we've given you a script to test this. Switching to deadline scheduler makes mysql updates take 11 seconds per update (average) rather than hanging indefinitely. Any ideas on how to advance on that? Worth trying ionice? Switching to qunatal kernel? Where should we go from here? | 15:40 |
| apw | alexbligh, the logical next step is to make a test rig and go on a bisect hunt for where it was introduced, between o and p | 15:42 |
| apw | alexbligh, probabally using the mainline builds if one is lucky enough to be able to boot them | 15:42 |
| alexbligh | apw, if you had to guess, would you guess this was a mainline kernel regression rather than a difference in the way (say) the Ubuntu kernel is compiled? (different options etc.) - I am wondering whether there are other things other than change of elevator between O and P. | 15:43 |
| apw | i am not aware of anything, but you could switch to a mainline kernel at the same base patch level as your P kernel (see /proc/version_signature) to tell if it is an ubuntu patch issue | 15:44 |
| alexbligh | apw, I meant more a different config option (brought about by the demise of -server) | 15:44 |
| apw | there really was only the elevator in difference which is why we collapsed them, as that is configuraable at run time | 15:45 |
| alexbligh | apw, do you know off hand whether there is any ionice type thing we can use to work around this? We are in control of the zcat. | 15:46 |
| apw | it would be worth trying making it 'idle' priority to see if this helps any | 15:46 |
| alexbligh | apw, so (a) retest mainline kernels, (b) try ionice (workaround for me, but not for everyone), (c) try quantal and see if already fixed (from mainline) there? Is there enough info in the bug? | 15:48 |
| apw | alexbligh, i would yes test O level mainlnie and P level mainline kernels, if they show the same bracket good bad, then you can use the inbeween releeases to manually bisect for the regression | 15:49 |
| apw | the mainline archive should have builds for any tag linus produces | 15:50 |
| apw | and for all the stable updates too | 15:50 |
| apw | and also i would confirm if the O kernel works as expected on the P userspace | 15:50 |
| apw | so confirm its kernel triggered not mysql level or something | 15:50 |
| alexbligh | apw, good plan. In case you were wondering, we have an end-of-month release too :-) | 15:51 |
| alexbligh | apw, doubt it's mysql, as it affects postgres too :-) | 15:51 |
| apw | indeed, but one has to be methodical | 15:51 |
| * ppisati -> gym | 15:56 | |
| alexbligh | apw, ok, thanks, that's helpful. | 15:56 |
| alexbligh | apw, so is 3.2.0-31-generic 3.2.28 (per /proc/versioninfo) the same as 3.2.28-precise (in the mainline build archive) or the same as 3.2.31? I think it's the latter. | 16:01 |
| alexbligh | s/versioninfo/version_signature/ | 16:02 |
| apw | its the same as 3.2.28 in mainline | 16:02 |
| apw | -31 is the abi number | 16:02 |
| * smb -> errand | 16:02 | |
| alexbligh | apw, thx | 16:02 |
| jsalisbury | apw, rtg, it seems the amd64 mainline kernel is not building: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.6-quantal/ | 16:51 |
| jsalisbury | apw, rtg, it also fails to build with the mainline-build-one script. I'm looking into that now for clues. | 16:51 |
| apw | jsalisbury, fails how, with an error, or does nothing | 16:51 |
| rtg | make: *** No rule to make target `build-generic-pae'. Stop | 16:52 |
| jsalisbury | apw, nothing is posted for v3.5.6 on our mainline builds page. | 16:52 |
| apw | rtg, that is normal, as we do not have pae any more | 16:53 |
| jsalisbury | rtg, that one is ok I beleive. I've seen it for a while | 16:53 |
| apw | but we do in older releases | 16:53 |
| apw | we do it last for safety | 16:53 |
| jsalisbury | apw, I'm capturing the output from a mainline-build-one run right now. I'll be able to review it shortly for errors. | 16:54 |
| apw | jsalisbury, ok this is something i have done to the main kernel build | 16:55 |
| jsalisbury | apw, ok | 16:56 |
| apw | give me a bit | 16:56 |
| jsalisbury | apw, ok, thanks! | 16:58 |
| apw | jsalisbury, i have pushed a commit to quantal master-next, could you update your quantal head | 17:02 |
| apw | and see if that builds for you | 17:02 |
| jsalisbury | apw, will do | 17:03 |
| apw | (as the mainline builds publl the build engine from quantal in this case) | 17:03 |
| jsalisbury | Did that update this repository on tangerine: git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git | 17:04 |
| herton | apw, jsalisbury: | 17:04 |
| herton | handoff=`dd if="/home/apw/COD/linux/debian/linux-image-3.5.6-030506-generic/boot/vmlinuz-3.5.6-030506-generic" bs=1 skip=514 count=6 2>/dev/null | od -s | awk '($1 == 0 && $2 == 25672 && $3 == 21362 && $4 >= 523) { print "GOOD" }'`; \ | 17:04 |
| herton | [ "$handoff" = "GOOD" ] && \ | 17:04 |
| herton | cp -p /home/apw/COD/linux/debian/linux-image-3.5.6-030506-generic/boot/vmlinuz-3.5.6-030506-generic \ | 17:04 |
| herton | /home/apw/COD/linux/debian/linux-image-3.5.6-030506-signed/3.5.6-030506.201210071308/vmlinuz-3.5.6-030506-generic.efi | 17:04 |
| herton | make: *** [install-generic] Error 1 | 17:05 |
| jsalisbury | apw, if not, I can add a git remote somewhere else | 17:05 |
| herton | I had this same problems on my builds | 17:05 |
| apw | herton, yes i've fixed that | 17:05 |
| apw | i hope :) | 17:05 |
| herton | apw, yep, I used your fix :) | 17:05 |
| apw | jsalisbury, it updates like every hour i think | 17:05 |
| jsalisbury | apw, is there a link to the master.next repo ? I can point there | 17:06 |
| apw | its on zinc | 17:06 |
| jsalisbury | apw, cool, thanks | 17:06 |
| === henrix is now known as henrix_ | ||
| * herton -> errand | 17:07 | |
| === henrix_ is now known as henrix | ||
| * rtg -> lunch | 17:32 | |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === tjaalton_ is now known as tjaalton | ||
| * rtg -> EOD | 20:28 | |
| slangasek | apw, jsalisbury: hi, bug #1065263 for your UEFI enjoyment | 21:30 |
| ubot2 | Launchpad bug 1065263 in linux "wrong stride for efifb on some systems" [Undecided,Incomplete] https://launchpad.net/bugs/1065263 | 21:30 |
| mjg59 | That patch will only help if you're using the kernel EFI stub | 21:34 |
| mjg59 | Otherwise you'll need equivalent code in grub | 21:34 |
| slangasek | yeah, cjwatson and I were just working through that :) | 21:34 |
| slangasek | mjg59: so you guys haven't pushed a patch for grub for this? | 21:35 |
| mjg59 | And also the equivalent of the other patch for the kernel whose title I can't remember | 21:35 |
| mjg59 | slangasek: No, we're using the kernel stub | 21:35 |
| slangasek | mjg59: hmm, I think I've lost track of y'all's implementation. shim->grub2->kernel stub? or shim->kernel stub? | 21:36 |
| * slangasek gets everyone on the same channel :) | 21:38 | |
| slangasek | mjg59: so we do have signed kernels bopping about now, precisely due to your advice about the quirking | 21:38 |
| slangasek | mjg59: but we need both the signed kernel (w/ efi kernel stub) and the above patch to get to efifb playing nice, correct? | 21:39 |
| mjg59 | shim->grub2->kernel | 21:39 |
| mjg59 | Yeah | 21:39 |
| mjg59 | There may be one other patch as well | 21:39 |
| slangasek | ok | 21:39 |
| mjg59 | "X86: Improve GOP detection in the EFI boot stub" | 21:39 |
| slangasek | thanks | 21:40 |
| === jgriffit2 is now known as jgriffith | ||
| slangasek | mjg59: so stgraber has just tested our boot path with Lenovo's SB implementation; turns out that when LoadImage fails there, it doesn't fail silently, but pops an error message that requires the user to acknowledge (press return) | 21:50 |
| slangasek | mjg59: have you guys run into this? | 21:50 |
| mjg59 | slangasek: Oh for the love of christ | 21:50 |
| stgraber | mjg59: http://www.stgraber.org/download/DSC02669.JPG | 21:50 |
| mjg59 | slangasek: No we hadn't | 21:50 |
| cjwatson | As usual there's nothing especially useful in the UEFI spec to forbid this stupid behaviour | 21:50 |
| cjwatson | (Although this behaviour is to some extent inference on our part) | 21:51 |
| mjg59 | Yeah ok so the easiest thing to do there is to flip the order in shim | 21:51 |
| cjwatson | I wonder if we need the LoadImage path at all | 21:51 |
| slangasek | well, I guess the shim isn't currently checking db only dbx? | 21:51 |
| slangasek | but yeah, I wonder if it should just skip LoadImage entirely | 21:52 |
| mjg59 | slangasek: Yeah | 21:52 |
| mjg59 | slangasek: Checking db as well as dbx would avoid it | 21:52 |
| mjg59 | Meanwhile the LF have just done something stupid and dumb and stupid | 21:53 |
| slangasek | cjwatson: so, should I make elmo cry by revving shim, or do we have other priorities I should be worrying about at the moment? | 21:53 |
| cjwatson | well | 21:53 |
| cjwatson | this is in principle release-notable, since you can still boot | 21:54 |
| cjwatson | even though the release note would be horrible | 21:54 |
| slangasek | you can still boot a signed kernel, anyway | 21:54 |
| slangasek | from what stgraber saw, you couldn't boot an unsigned kernel | 21:54 |
| stgraber | yeah, the part where I can't boot an unsigned kernel from grub is still kinda weird, not sure if it's related to the first problem at all :) | 21:54 |
| slangasek | possibly because the firmware has lost its mind by that point and can't display the confirmation message | 21:54 |
| slangasek | stgraber: I expect it is the same issue, because we try to call LoadImage for the kernel too | 21:55 |
| slangasek | which obviously fails for an unsigned kernel | 21:55 |
| cjwatson | uh | 21:55 |
| cjwatson | it should call shim_verify first | 21:56 |
| slangasek | oh, does it? | 21:56 |
| cjwatson | the LoadImage bit is only in init_grub | 21:56 |
| cjwatson | it's not in shim's verify protocol handler | 21:56 |
| slangasek | ah, ok then | 21:57 |
| slangasek | cjwatson: well, it's easy enough to reverse the order of the check in shim; I could do that and aim it at quantal-proposed? | 22:02 |
| cjwatson | if you're comfortable doing that, sure | 22:03 |
| cjwatson | and make elmo's day a little bit worse | 22:04 |
| mjg59 | Yeah can't say I'm unhappy that we've ended up slipping by a month | 22:05 |
| jsalisbury | slangasek, thanks :-) | 22:11 |
| slangasek | mjg59: proposed patch for shim sent your way; would appreciate it if you could spare the time to eyeball it before we go pushing an MS signature on it | 22:36 |
| mjg59 | slangasek: Thanks | 22:37 |
| mjg59 | slangasek: It'll be tomorrow before I check, if that's ok? | 22:37 |
| slangasek | mjg59: yeah; I think we can hold off on pushing this to MS until then | 22:38 |
| slangasek | I'll get the package uploaded in any case | 22:38 |
| === rsalveti_ is now known as rsalveti | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
