neuro_sysmjg59: when using this bios call, r.flags should contain the correct values? http://www.ctyme.com/intr/rb-1755.htm00:35
neuro_syswith libx86.00:35
mjg59neuro_sys: No00:35
mjg59neuro_sys: libx86 is in no way guaranteed to actually let you make arbitrary BISO calls00:36
mjg59The only things you should expect to work are graphics calls00:36
neuro_sysdoes it emulate or something? Actually I need to have a look at vm86 first I guess.00:36
mjg59The rest of the BIOS isn't hooked up at all00:36
xiackokok there is kernel system calls00:39
lifelessapw: I mailed the kernel list; I presume it went to moderation05:34
lifelessapw: I also forgot to say that I'm not subscribed ... so I won't see replies05:34
smblifeless, I forwarded you my reply which only went to the list accidentally06:59
lifelesssmb: thanks!07:00
smblifeless, Actually a request based mapping might be more desirable than a merge function for bios. Cause for the latter you would have to find out the common max of all mirrors if I understood correctly. Which sounds much more complicated. While for rq mapping the elevators just should be able to merge.07:11
smbAfter all multipath had the same problem there.07:11
lifelesssmb: common max?07:14
lifelesssmb: is request a larger unit of work ?07:14
smbI mean the maximum size of a bio all the mirror paths/drives can handle. Yes, request is a set of bios07:15
smbNormally for a request queue the elevators can merge bios into an existing request if it is adjacent. But for the bio based mapping there is no such thing07:17
lifelesssmb: I've replied; I appreciate the feedback; I guess I think further fiddling isn't likely to have much impact - the kernel is merging the bios on the targets post mapping07:17
lifelesssmb: hmm, they are definitely being merged07:17
lifelessDevice:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util07:18
lifelesssda            3854.60     0.80  270.00    5.40 16498.40    21.60   119.97     0.14    0.50    0.43    4.07   0.43  11.8007:18
lifeless3854 -> 27007:18
smbDid you see that? Cause iirc going through the device-mapper bio mapping was past the queues and so no merging was done07:18
lifelessdm-1              0.00     0.00 4124.60    6.20 16498.40    21.60     8.00     1.34    0.33    0.32    3.23   0.03  11.8007:19
lifelessis the raid1 device07:19
lifelessso it got 4K reads, which all got mapped, then 3.8K were merged into the other 27007:20
lifelessbbiab, cooking dinner07:22
smbHm seems like. Yeah. 07:22
smbAt least dm does no queue here, so merging is not done before sending it down a path07:23
lifelesssmb: its pretty efficient on sequential IO:07:34
lifelesssda           25616.80     0.00 1816.60    1.80 109734.40     6.40   120.70     1.06    0.59    0.57   17.78   0.41  74.2007:34
lifelessdm-1              0.00     0.00 27368.00    1.80 109472.00     6.40     8.00    14.99    0.55    0.55   17.78   0.03  74.0007:34
lifeless100MB/sec out of the drive07:34
smbWell yes, just thought in the past the bios would just get passed on behind a dm device. But it could have changed. Your sda is also only used for that raid, right?07:35
lifelessdd from the drive gets:07:35
lifeless131072000 bytes (131 MB) copied, 1.07633 s, 122 MB/s07:35
lifelessyeah, its a raid 1+0 ICH10R07:36
lifelessso sda and sdb are raid1 together07:36
lifelesssdc and sdd are raid1 together07:36
lifelessand dm1 and dm3 are striped together into dm507:36
lifelessdm5 is what gets partitioned etc07:36
lifelessso without the patch, sequential IO + interactive IO is a bit poor07:38
smbOk, so merging at least happens on the backing devices. Just not for the mirror target which then can pass bios to both sides without caring whether they are mergeable07:38
lifelesswith it deals better07:38
lifelesssmb: yeah, thats my observation07:38
smbIsn't the current code doing no read balance at all?07:38
smbOk, so I read the old one correctly. :)07:39
lifelesswhich is why sequential IO + interactive IO is bad :)07:39
lifelessbecause you die from seeks07:39
smbRight, it works around not merging but misses the oportunity of using a second source07:39
lifelessmy patch avoids that some of the time - when the IO distance is reasonable07:40
lifelesssmb: I did try two sources for sequential IO07:40
lifelesssmb: if you get it wrong, its way worse ;)07:40
smbI can believe that07:40
smbWould basically break up the chance for merging07:40
lifelessso I think the heuristic I'm add is valuable even if we add a merge method07:41
lifelessor request handling07:41
lifelessIMBW :)07:41
smbJust my gut feeling is that, when asking upstream, they will point at how multipath went to request based mapping and that avoids the need for heuristics07:42
smbIn the simplest form (before having the rq_map) they just used the same path x times and then switched in a round-robin balancer07:44
smbWas not bad but had exactly the same issue of being dumb about possible merges07:44
smblifeless, But that is my personal feeling. You certainly can get more accurate feedback from dm-devel. My knowledge there has become a bit rusty from not looking all the time07:48
lifelesssmb: ok, thats good to know07:57
lifelesssmb: I think I'll wait for them to say that; if multipath knew that writes had to go to all devices, we could just have multipath layered in the mix07:58
smblifeless, Yeah, though for multipath it is actually the other way. Writes do go to all devices as it is really only one. Just there are multiple way to reach. The problem there is more that on the other end there may be a stupid handler or transport is more efficient in bulk08:01
lifelessright, I meant 'transmit on all paths08:02
lifelessbecause raid1 is 'write to all read from one + a bitmap for region synchronisation'08:02
smbRight, different use cases. For mpath transmit to all paths is futile or stupid so it is not intended for that. But there is one patch in the past which introduces the rq_map stuff in the past and it did not look too terrible. It might be a source to look at.08:04
apwppisati: have you created bugs for the two new CVEs yet?  i would like to test some scripting on them if not08:57
apw(ie. i want to make them)08:57
apwbut i don't trust launchpad to find them08:57
ppisatiapw: which one?09:03
apwand 2011-248409:04
apwcool, i'll sort them out then thanks09:04
ppisatidin't notiche them (yet)09:04
apwppisati: has anyone pointed you at the new page with the open CVEs on it, the bug view: http://people.canonical.com/~kernel/reports/kernel-cves.html09:59
apwthis is the first proto-type of an incoming queue for us, once kees starts making the bugs10:01
smbYet another one... But I guess that one goes with the bugs and will get us rid of supertracker10:02
apwsmb, yeah its about getting rid of the tracker, and about the fack stupid launchpad searches do NOT work10:02
apwppisati, you must teach me how you find a CVE bug in launchpad.  even when i have just opened one and i know its number i cannot find it using traditional searches ... it makes NO sense10:03
apwsmb, can you find the bug for CVE-2011-1070 ?10:10
ubot2apw: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1070)10:10
apwbug #80637510:10
ubot2Launchpad bug 806375 in linux-ti-omap4 "CVE-2011-1770" [Undecided,Invalid] https://launchpad.net/bugs/80637510:11
apwthat bug is New in linux but i cannot get a search on linux bugs to find it10:11
apwi am being told its "the hyphens"10:14
smbSo you are trying to search the number and they fail ... bah10:15
smbhow useful is that...10:16
smbNo don't know how to do it. Stripping of the CVE part and only using numbers gives you completely unrelated bugs10:18
arothhi, i found the following kernel bug: http://paste.ubuntu.com/638832/11:10
arothhow should i proceed?11:10
blissthat's a fairly short list of CVE bugs11:22
blissnot complete, i suppose?11:23
blissi'd expect CVE-2011-2497 and CVE-2011-2213 to be unfixed so far11:23
ubot2bliss: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2497)11:23
ubot2bliss: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2213)11:23
blissvery helpful ubot2, thanks :p11:24
apwbliss, nope its likely incomplete currently12:32
blissi'll have to give you guys some more to work on ;-)12:33
blisscan't have the ubuntu kernel team getting bored12:33
blissoff to work, later12:35
neuro_sysjeroen tel vs. piper fawn13:08
* apw wanders out for a bit, some fresh air is required13:34
=== _LibertyZero is now known as LibertyZero
* apw notes it is windy out14:31
* tgardner steps out for an appt. back in a couple hours14:32
=== tgardner is now known as tgardner-afk
brendandbjf - is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/802554 really still being verified? i thought i saw an email from sconklin last week saying it could be tested?14:44
ubot2Ubuntu bug 802554 in linux "linux: 2.6.32-33.69 -proposed tracker" [Medium,In progress]14:44
bjfherton, ^14:49
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - July-12 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
hertonbrendand: yes, everything on lucid seems verified, I'll check and set it to fix released14:50
brendandherton - thanks,14:52
bjfapw, irc meeting scripts updated and pushed14:52
apwbjf were we missing a bit ?14:52
bjfapw, yup, fixed14:53
apwother than the little hickup everything else went well, we found all the reports in the end and added to the README14:53
hertonbrendand: done, you can assign yourself on the bug and start working etc.14:54
bjfapw, all pages have been updated and email sent, i think it's a wrap14:55
apwbjf, thanks for that14:55
apweverytime you are away we get closer to it working :)14:55
bjfapw, as "punishment" for getting my upload rights, it looks like I now get to do "patch pilot", i've been assigned dates14:58
apwbjf, indeed so :/14:58
apwbjf, we ussually use that to review the incomng bugs in linux with patches14:58
bjfapw, ack, that was my plan14:59
bjfapw, i believe that is what we agreed to in dallas14:59
apwbjf, indeed so, and its actually been pretty good at finding real patches to apply14:59
=== tgardner-afk is now known as tgardner
hertonbjf: do you know/remember if someone from kernel team must verify tracking bugs, or can we set verification -> fix released for bug 79515317:35
ubot2Launchpad bug 795153 in linux-mvl-dove "linux-mvl-dove: 2.6.32-417.34 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/79515317:35
hertonI mean, verify *arm* tracking bugs17:36
* tgardner --> lunch18:06
ckingwhen tgardner goes to lunch it reminds me I should be finishing up for the day18:07
apwbjf, could you remind me where the documentaiton on how to upload one of these puppies is?  i need the switch to make it use lucid18:08
bjfapw, ^ bottom of the page18:09
=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel

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