| kees | is there some plan to get people off of the 2.6.36-999 kernels once maverick releases officially? | 01:32 |
|---|---|---|
| ogasawara | kees: not that I'm aware of. the mainline kernels are an elective install so it seems inappropriate for us to then force them back to the Maverick kernel. | 01:34 |
| kees | ogasawara: fair enough. | 01:34 |
| ogasawara | kees: but that's just my initial opinion | 01:35 |
| === bjf is now known as bjf[afk] | ||
| ogasawara | RAOF: if your about, let me know what the final verdict is for the KMS disablement patches as I'll need to get them reverted asap to make the kernel freeze deadline. | 03:00 |
| === bjf[afk] is now known as bjf | ||
| === bjf is now known as bjf[afk] | ||
| jjohansen | rebooting | 07:31 |
| apw | RAOF, morning ... | 08:35 |
| apw | did we bottom out on KMS, i think we need to revert those today to get them in in time | 08:35 |
| * smb has completed the morning scan of email | 08:47 | |
| smb | morning all | 08:47 |
| smb | RAOF, If you are around, are you the radeon guy or is that Sarvatt ? (one day I am hopefully able to remember) | 08:48 |
| cooloney | apw and smb morning | 08:51 |
| smb | cooloney, \o | 08:51 |
| apw | morning alll | 08:51 |
| smb | apw, https://patchwork.kernel.org/patch/120327/ | 09:01 |
| apw | smb, apparently there is a bug in LP for the above patch: bug #563481 | 10:00 |
| ubot2 | Launchpad bug 563481 in linux (Ubuntu) "BUG: Bad page state in process soffice.bin pfn:111e42 (affects: 4) (dups: 1) (heat: 45)" [Undecided,Incomplete] https://launchpad.net/bugs/563481 | 10:00 |
| apw | found it while closing down tabs overload | 10:00 |
| smb | ah right that was it | 10:01 |
| amitk | ikepanhc: did you receive any HW schematics during the lange51 engagement? | 10:10 |
| ikepanhc | amitk: maybe only blocks | 10:10 |
| ikepanhc | amitk: let me check | 10:10 |
| amitk | ikepanhc: could you forward me whatever material you did receive? | 10:11 |
| ikepanhc | amitk: sure | 10:11 |
| amitk | ikepanhc: thanks! | 10:12 |
| smb | apw, enable_mtrr_cleanup | 10:12 |
| ikepanhc | amitk: found three emails, forwarded. | 10:15 |
| === smb is now known as smb-afk | ||
| * apw lunches | 12:56 | |
| apw | bah uk banks SUCK | 13:51 |
| === smb-afk is now known as smb | ||
| smb | apw, Still around or went away to smash the bank | 13:54 |
| apw | smb, am in the damn bank now ... waiting | 13:56 |
| smb | apw, Hope without a gun. :-P What the heck did they (not) do? | 13:57 |
| apw | they need my id to open a savings account (bloody sarbains-oxley) | 13:57 |
| apw | but the woman with nothing to do can't see me i have to see one of the busy ones | 13:57 |
| smb | Not her expertise. Yeah that sucks. But the id stuff if now European | 13:58 |
| apw | its a passport, so its not worth the paper its printed on anyhow | 13:58 |
| smb | heh, not sure whether the uk ones are worse but the german ones likely carry your dna information | 13:59 |
| smb | (I am exaggerating, but either they have started or will soon to put your fingerprints on an id chip there) | 14:01 |
| === ivoks-afk is now known as ivoks | ||
| apw | smb, i have an old one, they will be adding them soon i think prob in my next one | 14:06 |
| smb | apw, Me too. Will be bloody expensive to get one then. With the great added value of having an rfid chip that already had been proven to be easily destroyed if one wants to... | 14:09 |
| apw | hehhe | 14:10 |
| apw | smb, that args testing kernel is http://people.canonical.com/~apw/args-debug-maverick/ | 14:17 |
| apw | smb it has specific debug for the mtrr thingy and alll args debugging turned on | 14:17 |
| smb | apw, A good, was about to ask you. | 14:17 |
| apw | be interested in the dmesg with it on | 14:18 |
| smb | Test with just enable_mtrr_cleanup showed the same result as before with the 2.6.35-21 kernel | 14:18 |
| smb | ok | 14:18 |
| apw | smb, wassit say | 14:35 |
| smb | "smb was preempted away and just now is installing it" | 14:36 |
| * smb feels like having IPI issues :-P | 14:37 | |
| smb | apw, mtrr cleanup deemed enabled but it does not do it. bugger | 14:40 |
| apw | so it says deemed enabled ? but does not say deemed needed ? | 14:41 |
| smb | right, did not see that | 14:41 |
| smb | hmmm... maybe it thinks pat is better? | 14:43 |
| smb | apw, ^ | 14:43 |
| apw | smb, no it means that it decided it would not work or not required, i will check | 14:45 |
| smb | apw, dmesg.aa1.debug1 at the usual place | 14:46 |
| apw | ta | 14:46 |
| === ivoks is now known as ivoks-afk | ||
| apw | smb, could you shove cat /proc/mtrr somewhere (/QUERY or a chin or ...) | 14:50 |
| smb | sure. a sec | 14:51 |
| === xfaf is now known as zul | ||
| smb | apw, mtrr.bad@chin | 14:52 |
| cassidy | hi guys. I have a system freeze which is 100% reproducible. What's the best way to gather info for the bug report? kerneloops doesn't seem to catch it | 15:06 |
| smb | cassidy, "ubuntu-bug linux" to gather generic stuff. And then proceed from there | 15:07 |
| cassidy | yeah I know that, but is there a way to get info from the freeze? | 15:07 |
| apw | smb, do you have an older kernel on that machine you could get an /proc/mtrr off of? | 15:08 |
| apw | cassidy, if its freezeing hard ie its not accessible over the network or console then not really | 15:09 |
| smb | apw, Not very much more, I could boot from a Lucid install | 15:09 |
| cassidy | apw, yeah | 15:09 |
| smb | cassidy, If its possible to cause the freeze after switching to a vt it may show something | 15:09 |
| apw | smb, well i know why it won't clean your mtrrs at the moment ... you have a write-protect in there | 15:09 |
| apw | trying to work out why it might care | 15:09 |
| cassidy | smb, which terminal ? | 15:09 |
| smb | cassidy, vt1 with ctrl-alt-f1 | 15:10 |
| cassidy | ok I'll try that | 15:10 |
| smb | apw, So a dmesg from a lucid disk is ok? Can do that relatively quick | 15:11 |
| apw | smb, s'ok not worth it, just found the change which you are being hit by | 15:12 |
| smb | apw, a ok. more smartness? | 15:12 |
| apw | more safety | 15:13 |
| smb | *sigh* | 15:13 |
| apw | pgraner, looked over latest pres. and it looks much better | 15:22 |
| === BenC___ is now known as BenC | ||
| ogasawara | has anyone seen RAOF about? | 15:37 |
| vanhoof | Sarvatt: ^^ | 15:38 |
| Sarvatt | RAOF is at the X developers summit | 15:38 |
| ogasawara | Sarvatt: maybe you can answer my question then... I need to know if we need to drop those KMS disablement patches from the kernel. | 15:38 |
| Sarvatt | yeah, we've already switched the server to use fbdev | 15:39 |
| ogasawara | Sarvatt: ok cool, I'll drop the patches then. thanks. | 15:39 |
| pgraner | apw: thanks | 15:39 |
| Sarvatt | well, xserver with the change isn't uploaded yet, he didn't find a sponsor before he had to get on the plane | 15:39 |
| Sarvatt | but he does intend for those to go away yeah | 15:40 |
| apw | Sarvatt, if we don't drop them today and upload them they won't make the release ... | 15:40 |
| apw | kernel freeze is tommorrow | 15:40 |
| * Sarvatt nods | 15:40 | |
| Sarvatt | i'll try to find a sponsor for his packages, things are crazy right now because the latest mesa upload broke unity on intel | 15:41 |
| ogasawara | that's not good | 15:41 |
| * ogasawara looks around for diwic and jj as they have outstanding patches we need by today too | 15:41 | |
| === bjf[afk] is now known as bjf | ||
| bjf | ogasawara: diwic is on a walkabout today | 15:42 |
| ogasawara | bjf: hrm, his might have to wait for an SRU then to Maverick | 15:43 |
| apw | ogasawara, ok confirmed the archive goes to freeze mode at midnight tonight (and thats UTC I assume) | 15:44 |
| apw | so even now we are going to have to stroke the arm binaries through | 15:45 |
| ogasawara | apw: yep, which means I want to upload within the next few hours to be safe | 15:45 |
| apw | ogasawara, yep | 15:45 |
| apw | smoser, how much output would you say comes out before the lost information | 15:51 |
| ogasawara | apw, tgardner: what about ti-omap4, is that good to go? | 15:51 |
| apw | not sure that has changed has it? | 15:52 |
| tgardner | ogasawara, I was kind of waiting to see if the cache line bounce fix helped, but it doesn't really seem to be a complete fix. I could upload with lag's timer config patch. | 15:52 |
| ogasawara | apw: I saw tgardner applied lag's high res timers config patch, so I think that's it | 15:52 |
| apw | lag, know of anything else | 15:53 |
| smoser | apw, well, http://paste.ubuntu.com/494225/ . look at line 520 and on. | 15:53 |
| smoser | so we get kernel output to console | 15:53 |
| smoser | then, ramdisk output to console | 15:53 |
| smoser | then early forked command output | 15:53 |
| smoser | then exec upstart | 15:53 |
| smoser | at some point it disappears for 6 seconds or so | 15:54 |
| * lag checks | 15:54 | |
| lag | Nope | 15:54 |
| smoser | so in that pastebin, we're missing lines like "[1]: X, could not write to /handler" | 15:54 |
| smoser | where X is 2-5 | 15:55 |
| tgardner | ogasawara, given lag's lack of patches for now I'll wrap up ti-omap4 and git 'er done | 15:55 |
| ogasawara | tgardner: awesome, thanks. | 15:55 |
| smoser | i wonder how nefarious "mountall: Disconnected from Plymouth | 15:55 |
| smoser | " is | 15:55 |
| smoser | as that is the message that is written to the console when all else is lost | 15:55 |
| apw | smoser, indeed, so the hello world is missing right ? | 16:00 |
| apw | is the first thing missing | 16:00 |
| smoser | no | 16:01 |
| smoser | the initital "hi world" gets there (line 900) | 16:01 |
| smoser | the second hi world goes to a file in the filesystem | 16:01 |
| smoser | (and it gets there, but thats not surprising) | 16:01 |
| apw | smoser, right but the one after the 'wait till / is read-write' loop | 16:02 |
| apw | is the first thing missing | 16:02 |
| smoser | no. that one goes to a file | 16:03 |
| smoser | see the { } >> ${out} | 16:03 |
| smoser | the things missing is "echo "[${SECONDS}]: $i, could not write to ${out}"" | 16:03 |
| apw | you don't know that do you? | 16:03 |
| smoser | for all the failures (there were 4 of them) | 16:04 |
| smoser | i dont know what ? | 16:04 |
| smoser | in /handler, i know that : "[2]: wrote to /handler after 5 | 16:04 |
| smoser | " | 16:04 |
| apw | the first thing to the console after we have transitioned from r/o to r/w is "wrote to ${out} after $i" | 16:04 |
| apw | ahh | 16:04 |
| apw | so we are missing 3,4,5 of that and 1-6 of the second loop plus the 'write to out after $i' | 16:05 |
| apw | all of that is missing | 16:05 |
| smoser | missing 3 and 4, 5 wouldn't be written because the /handler write would succeed. | 16:05 |
| smoser | right. | 16:05 |
| smoser | and then "reports" messages up to i-6 | 16:06 |
| smoser | i=6 | 16:06 |
| apw | smoser, can you disable plymouth i wonder | 16:07 |
| apw | like rename it away and see what happens | 16:07 |
| smoser | i can try | 16:07 |
| smoser | apw, if you want to poke or look at the instance you can get to ubuntu@ec2-67-202-31-38.compute-1.amazonaws.com | 16:08 |
| smoser | i'll try removing plymouth | 16:08 |
| tgardner | ogasawara, ti-omap4 is in the pipeline | 16:20 |
| ogasawara | tgardner: thanks | 16:20 |
| === lag is now known as lksjopfjljfslijg | ||
| === lksjopfjljfslijg is now known as jigijigijigjijig | ||
| === jigijigijigjijig is now known as lag | ||
| cking | having fun with your nick lag? | 16:41 |
| lag | See #ubuntu-arm for details :) | 16:42 |
| lag | ogra: Was using my name in vain, so I changed it | 16:43 |
| === yofel_ is now known as yofel | ||
| ogasawara | jjohansen: just the person I've been waiting for | 16:57 |
| ogasawara | jjohansen: I need your patches asap as the archive freezes at midnight UTC, ie in 8 hrs | 16:58 |
| jjohansen | hey, sorry I am getting the pull request together now | 16:58 |
| ogasawara | jjohansen: perfect | 16:58 |
| apw | jjohansen, fyi the lost output during boot issue is looking like its a plymouth issue; we are off the hook | 17:26 |
| smoser | apw, thanks. | 17:27 |
| jjohansen | apw: yeah I was just talking to smoser | 17:27 |
| apw | ahh ok, i'll shut up then :) | 17:27 |
| smoser | apw, you have a suggestion other than just race as to why i would see it on ec2 but not euca ? | 17:27 |
| tgardner | smoser, just the fact that its a race makes it somewhat random | 17:28 |
| jjohansen | apw: yeah it is strange, as setting the console in upstart was working for me but not smoser | 17:28 |
| apw | smoser, either timing, or the plymouth support for passing on the data works with not-ec2 and not with it | 17:28 |
| jjohansen | so it is definitely a race | 17:28 |
| apw | perhaps its plymouth is unable to open the console before it redirects it or something | 17:28 |
| apw | perhaps its plymouthd which hit the race | 17:29 |
| smoser | well, but we should then have been able to work around that | 17:29 |
| smoser | with our hack of keeping the fd open | 17:29 |
| smoser | so, for the moment, i wont care. | 17:30 |
| smoser | now on to looking at plymouth. thanks apw and jjohansen for your help at redirecting my pointed finger. | 17:30 |
| smoser | :) | 17:30 |
| apw | plymouth may yet point back at us i guess | 17:30 |
| === ivoks-afk is now known as ivoks | ||
| jjohansen | hehe | 17:43 |
| ogasawara | jjohansen: thanks for the patches. I assume that's all of them? | 18:26 |
| jjohansen | ogasawara: one more comming, for EC2 | 18:27 |
| jjohansen | it should be in the mail queue | 18:27 |
| ogasawara | jjohansen: ack, /me looks for it | 18:27 |
| apw | ogasawara, update on the armel issue, looks to be simply the packages being stuck in NEW, i've gotten an AA to sort them but cannot confirm yet its the only issue. but its likely that was it | 18:47 |
| ogasawara | apw: ok cool. Am planning to upload in about 10min. | 18:50 |
| apw | ogasawara, GruMaster is rebooing and will re-test the update then | 18:55 |
| apw | hopefully that will be 'ok' | 18:55 |
| ogasawara | apw: k, lemme know the results. I'll wait to push the button till I hear from you. | 18:56 |
| ogasawara | apw: I want to do a quick test build anyways before uploading | 18:56 |
| apw | ogasawara, best i can tell the arm issue is confirmed ok, ie. was the binary NEW issue only, so from my side you are good to go | 19:00 |
| ogasawara | apw: sweet. my build should finish in a few minutes and then I'll upload. | 19:01 |
| apw | ogasawara, there may be a string issue with linux-meta, but that is very minor and we've got more time on that | 19:02 |
| ogasawara | apw: ack | 19:02 |
| === ivoks is now known as ivoks-afk | ||
| * ogasawara lunch | 20:02 | |
| * ogasawara really goes to lunch | 20:25 | |
| hallyn | regarding bug 639712, i assume there is a particular reason why CONFIG_DMAR=n ? | 21:52 |
| ubot2 | Launchpad bug 639712 in libvirt (Ubuntu) "PCI Pass Through via libvirt cannot remap IRQ's (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/639712 | 21:52 |
| achiang | random question, purely for informational purposes - does ubuntu and/or canonical have a test farm of random hardware for kernel folks to use? | 23:12 |
| nigelb | yes, they are called volunteer testers :p | 23:13 |
| achiang | nigelb: ha. | 23:15 |
| achiang | the case i'm thinking of is, random user reports an issue; instead of kernel developer asking the user to run a test and wait (indefinitely?) for the results, the developer could just try reproducing on the appropriate machine in the farm | 23:17 |
| nigelb | that I don't know | 23:17 |
| achiang | again, i'm not necessarily proposing that we do such a thing -- only asking if such a thing already exists. | 23:17 |
| achiang | lamont: ^^ ?? | 23:17 |
| JanC | achiang: I know there is some test hardware, certainly for the hardware that's "certified" to work with Ubuntu | 23:31 |
| JanC | so, hardware from the companies that pay Canonical | 23:32 |
| JanC | a large farm of random hardware would be rather expensive I think ;) | 23:35 |
| JanC | well, maybe not for older hardware (people could volunteer their old hardware for that) | 23:35 |
| achiang | JanC: nod. | 23:50 |
| achiang | thanks | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!