/srv/irclogs.ubuntu.com/2011/02/09/#ubuntu-kernel.txt

ohsixneat01:11
ohsixor some other parallel try-out type thing01:13
cjwatsonohsix: you're leaking across channels, FYI01:18
ohsixi sure am, argh; still getting used to them being in the same window01:18
=== emma is now known as em
=== smb` is now known as smb
* apw yawns08:48
smbapw, Morning, I'd send you some coffee but it would be cold on arrival08:49
jk-hey smb & apw08:50
smbjk-, Man, long time no read. :)08:51
apwjk-, lives08:51
jk-he does08:51
apwjk-, not drowing or burning then?08:51
jk-not that I'm aware of08:51
jk-apw: mind if I parameterise baseCommit in the printchanges target?08:58
apwjk-, in principle no, but where you going to get the parameter08:58
jk-make basecommit=deadbeef printchanges08:59
jk-^apw09:00
jk-hm, wonder if that'll still work with insertchanges09:00
smbI beleive insertchanges was just reading in output from calling printchanges. You know that you can get that relatively simple using git-ubuntu-log itself?09:02
jk-smb: yeah, but insert-changes.pl may not pass the parameter to the newly-invoked make09:02
* jk- looks at git-ubuntu-log09:03
smbjk-, Not sure what use case you have in mind. It could be a bit tedious to do it manually more often09:03
jk-ah, yep, but that still needs the list of changes on STDIN09:04
smbBut I sort of often used git log <range> | .../git-ubuntu.log09:04
jk-smb: for custom builds, where we can't always rely on 'Ubuntu-$(release)-$(prev_revision)' being the base of the new changes09:05
smb(Hm, though in that case you probably really want a version in the topic branch that matches with your start commit messages...09:06
jk-yeah, that would be a good plan.09:07
jk-I should get a template sorted for starting a new topic branch09:08
smbapw, (who apparently dropped into a not-enough-coffee coma :-P) probably has more ideas. Though it feels like it may be possible to externalize (as a config file) the search tag09:09
jk-woot :)09:10
apwjk-, you'd need to make insertchanges pass it through i suspect, though a as its a $(MAKE) printchanges job, i think you can just $(MAKE) basecommit=$(basecommit) and be compatible09:11
apwperhaps the thing to do is allow the Ubuntu- pattern be a definable09:11
jk-yeah, i like that idea09:11
jk-will put something together to do that09:11
apwif that was in the 0- file as a default, then your *.mk in th branch could override it09:11
jk-yup :)09:12
psurbhismb, ping10:32
smbpsurbhi, hey, whats up10:33
psurbhismb, hey! just the nfs bug again :)10:33
psurbhismb, for the lucid code, did you see a COMMIT as a part of the vfs_write() ? Like, does vfs_write wait till COMMIT is over? I thought it did not wait for a COMMIT.10:33
psurbhiWhereas I thought that with upstream code, COMMIT is a part of vfs_write() and it waits till the COMMIT is over.10:34
smbpsurbhi, Frankly I did not look at the code but the tcpdump created by the dd. And there every write is followed by a commit. And the strace of the dd does not show any sync calls10:35
psurbhiok, then i think in Lucid, vfs_write does  not wait for COMMIT10:35
psurbhiso the write is not synchronous in that sense10:35
psurbhiatleast this is what it seems from the code10:35
psurbhiwhereas in upstream vfs_write() ultimately waits for COMMIT to complete10:35
smbpsurbhi, But fact is the next write did not happen before the commit was complete10:35
psurbhiok10:36
psurbhimaybe, i missed something.. :)10:36
psurbhiif not, then its a bug in Lucid and not upstream.. and so needs fixing in Lucid10:36
psurbhiright10:36
smbIt is complicated enough and I did not want to understand all of the details when the practical test seemed to be ok at least. :)10:36
psurbhibut the dump could possibly be a co-incidence10:37
psurbhiin which case we will end up invalidating the bug10:38
psurbhiwhen it actually really is a bug10:38
psurbhidid you see a COMMIT for every write when oflag=sync or even without it?10:39
smbI 100 times coincidence? I would rather believe that we missed the way this is done. I did see a commit for every write (at least looking at it) and I did not try without sync10:40
psurbhiok, great10:41
psurbhismb, thanks10:42
smbpsurbhi, Sure. If you think we miss something, feel free to bring it up. I was more interested in seeing the tcpdump apparently doing the same thing.10:44
psurbhismb, ok! 10:45
psurbhilooking at the code, i just got a feeling that lucid would not synchronously wait for the COMMIT to occur10:45
psurbhiso i thought i will just bring it up once..10:45
psurbhiand as you said it is complicated... maybe i did just miss something10:45
psurbhiits not apparent that it waits on the COMMIT10:46
psurbhiwhereas with upstream, its very apparent that it does wait for the COMMIT10:46
psurbhibut i am glad you have it verified :)10:46
psurbhiif i find something else, i will bring it up10:46
smbThings seemed to have changed around quite a bit. So it could be just better hidden. Ok, sure. :)10:47
=== artir is now known as Artir
ckingapw, you around?12:19
ckingapparently not12:26
* apw_ is still out and about ... back soon13:28
=== yofel_ is now known as yofel
apwcking, hiya14:19
apwcking, had a suit fitting14:19
smbapw, sounds terrible. ;-)14:21
apwyeah terrible :)14:22
apwsmb have i missed anything14:26
smbapw, Not that I am aware of (beside of cking) 14:26
* apw pokes cking for fun14:27
* smb does not think apw would miss the lovely crackling sound broken natty mumble does14:27
apwno not that either14:27
ckingapw, just wondered if you were alive..14:30
apwyeah had to go out and pick out my suit14:31
komputesHi JFo 14:31
JFohi komputes 14:31
komputesJFo: would there be any chance that we could edit the "Mainline kernel" auto-response or the wiki page to simplify the process for new users. I have gotten many responses from people that they don't know what to do to install a mainline kernel. I was just wondering if we could simplify the process.14:33
JFoI'm already working on something for that14:34
JFoit is in my blueprint for n-bug handling14:34
JFoactually there are 2 items there relating to that14:34
JFoso the short answer is 'yes, we are doing something about that' :)14:35
=== sconklin-gone is now known as sconklin
=== Quintasan_ is now known as Quintasan
apwi suspect komputes is offering to help with wording14:39
apwkomputes, do you have some specific suggestions on how we could improve it based on their feedback14:39
komputesI could if needed. I would first suggest step by step instructions, not too much copy. Then I would specify which kernel needs to be tested.14:40
komputesJFo: A lot of people don't understand which packages they need to install or where to install them from. I would guess http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ is what you want tested?14:43
JFoyep14:43
JFothe wording is something I have been doing testing on14:44
JFothe idea being that the comment points them to the mainline testing page of the wiki14:44
JFothat would then have some information on how to determine what kernel they would need to test14:44
komputesJFo: for example For example for 2.6.27.15 we have the following files, for i386 you would need those marked with B and C, amd64 take those marked A & C:  <- too complicated for most14:44
komputesJFo: except for the fact that many people do not understand the wiki instructions and give up there or come back to us asking for clarification, common issue.14:45
bjfJFo, what's the url for the mailine testing page in the wiki ?14:46
* JFo digs it up14:46
komputesbjf: https://wiki.ubuntu.com/Kernel/MainlineBuilds14:46
bjfkomputes, thanks14:46
komputesJFo: what I would suggest is that you link top the correct files (2 or 3 debs) directly from the command. Based on the Arch of the reported and the kernel you want tested.14:47
komputess/top/to/14:47
komputess/reported/reporter/14:48
komputesneed coffee, BRB14:48
tgardnerapw: did you make any progress on your lapic issue?14:58
sforsheedoes anyone know if the state of the hpet/lapic timers would affect the ability of a machine to resume from S3?15:01
sforsheei've got an Atom machine that usually takes about 5 min to resume, but with nohz=off highres=off it comes up immediately15:01
sforsheethe big difference I see is how these timers are used15:01
sforsheeand interestingly, 5 min is exactly how long it takes the hpet to wrap 32 bits on this machine15:01
apwtgardner, not as yet no ... am going to try the -rc4 kernel shortly15:06
=== herton is now known as herton_lunch
tgardnerapw: check for a BIOS upgrade15:09
apwtgardner, yeah will do, i'll get the puppy registered today15:10
JFokomputes, sorry, I got strangled on my breakfast and have been dealing with that for the last bit15:12
* JFo goes to look at the mainline page15:12
komputesJFo: sounds bad, was the heimlich maneuver involved?15:16
JFonope, no one else here but me15:17
JFoit was dicey for a bit there15:17
tgardnerapw, https://launchpad.net/~doctormo/+archive/wacom-plus15:35
komputestgardner: for a sec there I thought there was a graphical wacom settings utility... got all excited :(15:38
tgardnerkomputes, nah, pgraner was asking me about including the device driver.15:39
* JFo goes for more water15:41
* cking wonders if JFo is going to drink it or swim in it15:44
JForight now try to drink it, but I did try to breathe my food earlier :-/15:44
bjfJFo, how often are you regenerating your kernel-buglist-by-team report ?15:51
JFoshould be hourly15:51
JFobjf, ^15:52
bjfJFo, ack15:52
bjfJFo, on the top of the hour ? 15:53
JFoshould be, yes15:53
Sarvattkomputes: you mean like http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9863ccf9d99fdd712778b31197365723b9caa0be :)15:53
* JFo checks the cron job15:53
JFobjf, yep, top of the hour15:54
komputesSarvatt: I'm so happy15:54
Sarvattkomputes: natty+1, it's part of the gnome 3.0 stuff :(15:54
komputesSarvatt: this does mean wacom settings will be in mouse prefs right?15:54
Sarvattthere will be a new wacom one, yeah15:54
=== herton_lunch is now known as herton
komputesSarvatt: makes me giddy like a light-headed teenager at a Beatles concert15:56
* komputes screams15:56
Sarvattit could be easily backported to our g-s-d if someone felt adventurous enough, was originally written for 2.3x15:57
=== tgardner is now known as tgardner-afk
hertonsforshee: may be in your atom machine you hit the same bug as here: https://lkml.org/lkml/2011/1/19/49115:59
bjfJFo, IMHO bugs with a status of "Incomplete" should not be on the report16:03
sforsheeherton, afraid not, this isn't a recent regression16:03
sforsheeit hasn't worked for a long time, maybe not ever16:03
hertonah ok16:03
sforsheeherton, although I may be hitting it, as resuming devices does take 3+ seconds, but the majority of the delay is before that16:04
JFobjf, I can understand the argument16:06
JFoit is a relatively simple thing to ignore them, but I thought we would want to see them since they are technically an open state16:06
JFoand due to the ability of the masses to set Incomplete, I didn't want us to miss something16:06
bjfi like to think of it as a "task" list and as I work one and ask for more testing and mark it incomplete, i'd like it to fall off the list until the status changes back (but that's just me)16:07
JFowell, I am open to that if that is the generally accepted method :)16:09
bjfJFo, what is the "staging" tag about ?16:56
JFobjf, not sure16:56
JFoI think that is the first I have heard of it16:56
bjfi'm seeing it on a number of the bugs i'm looking at 16:57
bjflooks like apport probably put it on16:57
JFomind dropping me a bug number?16:57
bjfjfo bug #68997416:58
ubot2Launchpad bug 689974 in linux "frequent failure to boot with 2.6.37-9-generic #22-Ubuntu" [Undecided,New] https://launchpad.net/bugs/68997416:58
JFothanks16:58
JFohuh16:58
JFoI'm not sure16:58
JFolooks like there are only 100 of them16:59
JFolet me grab something to eat and look at these a bit17:01
JFobbiab17:01
bjfJFo, it's trying to indicate that it's related to a driver that is in "staging"17:02
JFoah 17:05
bjfJFo, but it does it in a fairly brain-dead way17:05
=== cmagina is now known as cmagina-lunch
bjfJFo, that change has been in there for quiet a while, interesting that we / i just started noticing it17:07
JFoI was just wondering about that as the bug numbers seem to indicate it is a recent thing17:08
bjfJFo, the patch went into apport 2010-02-2217:08
JFohuh17:08
JFowonder why we are only just beginning to see them17:13
JFowell, now/recently17:13
JFohmmm, I just found a bug from Sept 09 tagged staging17:17
bjfJFo, if the string "module is from the staging directory" is in one of the Dmesg logs, that tag is applied17:17
bjfJFo, even if the bug has nothing to do with the driver17:17
bjfJFo, i can understand wanting to flag it, that just seems like overkill, but maybe that's just me17:19
JFoI think it is overkill as well17:24
apwhttp://people.canonical.com/~apw/XXX.html17:30
brycehapw, ooh porn!17:37
brycehoh wait17:37
JFoof a sort, I suppose17:37
JFoIf you are into that sort of thing17:37
hertonbug porn17:37
JFoheh17:38
=== cmagina-lunch is now known as cmagina
apwJFo, ok i've pushed up a branch containing some fixes to the kernel key bugs page, the main changes are to split the tags into their own column to aid sorting by regression and by team, it also splits out Incomplete into their own table17:49
apwJFo, branch is here lp:~apw/canonical-qa-tracking/cleanup and produces a page as at http://people.canonical.com/~apw/XXX.html ... if you concur with the changes you can merge it into the live version17:50
* JFo looks17:50
JFoI like the report :)17:51
* JFo pulls the branch.17:51
ckingsnap17:51
apwthats what would happen if he _stood_ on it17:52
JFoheh17:52
* JFo chews on the branch. Great source of fiber17:53
=== tgardner-afk is now known as tgardner
=== sforshee is now known as sforshee-lunch
apwJFo, so the report just updated and looks the same18:09
apwi guess the cranberry version needs updating18:10
JFoyeah, I am looking over the changes18:10
JFoI haven't yet updated the branch18:10
apwok18:10
JFoapw, what file did you change?18:21
JFowait, think I found it18:23
JFoyep, I found it18:23
apwbzr log -p will show you the commits and file actual chane18:28
sconklinhttp://electronicdesign.com/article/digital/Bad-Transistor-May-Not-Cost-A-Billion-Dollars.aspx?cid=ed_newsletter&amp;NL=1&amp;YM_RID=`email`18:38
JFok, apw, it is up and the first one has been generated18:44
apwJFo, excellent thanks18:50
bjfJFo, minor nit, might change the title from "Upstream Bug Report"18:51
JFoyeah18:53
=== sforshee-lunch is now known as sforshee
JFobjf, fixed it18:58
JFoit will take a bit to trickle up to cranberry18:58
* tgardner --> lunch19:05
tgardnerapw, Natty master-next is working pretty well on my Emerald Ridge. 19:56
tgardnerbjf, can you review the CVE-2010-3880 patches so I can get it off my list?19:59
ubot2tgardner: net/ipv4/inet_diag.c in the Linux kernel before 2.6.37-rc2 does not properly audit INET_DIAG bytecode, which allows local users to cause a denial of service (kernel infinite loop) via crafted INET_DIAG_REQ_BYTECODE instructions in a netlink message that contains multiple attribute elements, as demonstrated by INET_DIAG_BC_JMP instructions. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3880)19:59
bjftgardner, looking20:00
bjftgardner, done20:08
tgardnerbjf, and the patches for Dapper/Karmic/Lucid/Maverick ?20:11
bjftgardner, acking them as we speak20:11
tgardnerbjf, ah, sorry. got ahead of yourself20:11
* jjohansen -> lunch20:23
tgardnerbjf, I'm not seeing dapper. 20:31
bjftgardner, looking, don't remember reviewing it20:32
tgardnerthat would explain it20:33
bjftgardner, i see a minor issue with that patch, email sent20:44
tgardnerbjf, responded20:55
bjftgardner, you dropped const, however the struct was chaged from "rtattr" to "nlattr" in other patches20:56
tgardnerbjf, huh, good point. better check that out.20:57
tgardnerbjf, corrected21:07
bjftgardner, that was my only issue, other than that it looked good21:08
bjftgardner, ack sent21:09
tgardnerbjf, thanks. good eye.21:09
=== bjf is now known as bjf[afk]
vanhoofsconklin: is dannf's update to bug 698883 sufficient for verification?23:14
ubot2Launchpad bug 698883 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/net/tun.c:725! - tun_chr_aio_read+0x428/0x430" [Undecided,Fix committed] https://launchpad.net/bugs/69888323:14
sconklinvanhoof: looking23:15
vanhoofsconklin: making the -proposed rounds :)23:15
sconklinvanhoof: you know we're rolling a new release of almost everything and anything verified will be carried over, right?23:16
vanhoofsconklin: correct, but might as well get these knocked out sooner than later23:16
vanhoofsconklin: unless you'd prefer i wait until the next upload23:17
sconklinright, just wanted to make sure we had no misunderstandings about when these would pulish23:17
sconklinpublish23:17
* vanhoof knows23:17
sconklinNo, please verify as early as possible23:17
vanhoofsconklin: I am in constant close contact with bjf[afk] :D23:17
sconklinand as far as I'm concerned, that's as good as we can get for that one.23:17
vanhoofsconklin: awesome, thanks23:18
sconklinSince there were no regressions from someone who actually uses that driver23:18
sconklinyou expecting me to set the tag or will you do it once LP comes back23:18
sconklin?23:18
vanhoofsconklin: happy to set it once its back23:18
sconklinok. I'm outta here, I'm blocked until LP comes back write-enabled23:19
=== sconklin is now known as sconklin-gone
vanhoofsconklin-gone: see ya23:20

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