/srv/irclogs.ubuntu.com/2012/07/20/#ubuntu-kernel.txt

ppisatiogasawara: USB_GPIO_VBUS totally clueless, seems ok to =m00:33
jwiogasawara: hm, did you get my reply before you pinged out?00:34
ogasawarajwi: yes thanks00:34
jwik00:34
skaetogasawara, bjf - backscroll is inconclusive, and there are no updates in the incident report.     What is the status with the kernel built yesterday?13:10
ogasawarabjf: https://wiki.ubuntu.com/PrecisePangolin/12.04.115:33
bdmurraysmb: perhaps I should upload kerneloops turning it off until we sort out the crashes?15:58
henrixsmb: can you take a look at my git lucid/lts-backport-oneiric and push it if OK?16:07
derwaffenssLet’s put a stop to the subversive Judaics and any selfish slime allied with them.  WHITE AMERICA: Time for some serious house cleaning! http://incogman.net/16:18
smbbdmurray, Err which realease was that? For Quantal I thought I had it turned it off by default16:27
smbhenrix, maybe16:27
bdmurraysmb: I turned it on when I was down there on Tuesday16:28
bdmurraysmb: after talking to jsalisbury16:28
henrixsmb: ok, if you're busy i can bug herton16:29
smbhenrix, I'll try to squeeze it in :)16:29
smbbdmurray, Ah, missed that16:29
henrixsmb: ok, cool. thanks16:29
jsalisburysmb, yeah, kerneloops is on for Quantal now, it will be on until just before release16:29
smbbdmurray, Yeah, I was not sure it did work, but always got distracted before actually testing16:29
bdmurraysmb: okay, well it doesn't! ;-)16:30
smbIn theory it should pipe itnto apport16:30
bdmurrayright, there is a problem with just running the daemon though16:30
smbbdmurray, Then we may turn it better off... Oh bugger... :-P16:31
jsalisburybdmurray, smb, I saw a kerneloops bug this morning, and it looks like apport had an issue: bug 102693616:31
ubot2Launchpad bug 1026936 in linux "BUG: Bad page map in process Xorg pte:5b840067 pmd:7f4cc067" [Medium,Incomplete] https://launchpad.net/bugs/102693616:31
jsalisburymessage box:16:31
jsalisburyThis problem report is damaged and cannot be processed.16:31
jsalisburyError('Incorrect padding',)16:31
jsalisburythree or four popup messages at once,16:31
bdmurraysmb: okay, I'll just turn it off for now16:32
smbjsalisbury, Ok, so best turn it off... Hm, I wonder whether this is because I was told to drop some of the applet patches because we dont need the applet (which apparently we do do need)16:32
smbbdmurray, Ok, yes. Thanks16:32
smbjsalisbury, Probably you can assign the bug to me, so I will find it again when I try to16:32
jsalisburysmb, ack16:33
bjfutlemming: can you test the oneiric kernel that is in -proposed?17:10
utlemmingbjf: in progress now17:10
bjfutlemming: many thanks17:10
ogasawaraarges: around?  we want to see that testing doc you posted17:11
slangasekrtg, ogasawara: hey, question on this linux-hwe-generic thing17:19
slangasekwhy is the backport release not in the package name?17:19
slangasekwe're going to have more than one of these in the precise archive over time, and they need to remain co-installable17:19
slangasek(bug #1026831)17:20
ubot2Launchpad bug 1026831 in debian-installer "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [Undecided,Invalid] https://launchpad.net/bugs/102683117:20
ogasawaraslangasek: we intend for the hwe meta package to always point to the current point release kernel17:20
ogasawaraslangasek: there is an additional release specific meta package17:20
slangasekthat's problematic17:20
ogasawaraslangasek: the linux-hwe-generic will point to this17:20
ogasawaraslangasek: wiki.ubuntu.com/Kernel/Release/Rolling has our specific details17:20
slangasekbecause if you're installing linux-hwe-generic, at the next point release, you get auto-switched to the next backport kernel17:20
slangasekwhich is not supposed to happen17:21
ogasawaraslangasek: correct, which is what we intend17:21
slangaseker, that's not what had been discussed / approved at UDS17:21
ogasawaraslangasek: hrm, that's not our recollection.  seems we have a disconnect.17:22
ogasawaraslangasek: what was your memory of the discussions, we don't auto roll forward?17:22
ogasawaraslangasek: how else would we roll forward for security for 5 years.  12.10 is only supported for the 18mo.17:23
slangasekogasawara: q, r, s backport kernels would be available under separate metapackage names in precise, and track the security updates for the respective releases17:23
slangasekcorrec17:23
slangasekt17:23
slangasekbut the point is that we were going to *only* roll forward from the q kernel to the t kernel once q itself is EOL for security17:23
bjfhttps://wiki.ubuntu.com/Kernel/Release/Rolling17:23
slangasekso that users who've installed 12.04.2 don't get a separate upstream kernel release every 6 months17:23
slangasekwhich is what happens if you use a single name17:24
ogasawaraslangasek: I assumed this is practice/prototype for 14.04 when we do go for a rolling kernel policy17:25
utlemmingbjf, smb: tested and confirmed to work. 17:25
slangasekogasawara: that was not my understanding at all17:25
bjfutlemming: can you add a comment to bug 1026730 ?17:26
ubot2Launchpad bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/102673017:26
=== jdstrand_ is now known as jdstrand
slangasekthis is the first time I've heard of a rolling kernel upgrade policy for 14.0417:26
ogasawaraslangasek: hrm, so you're view is the upgrade paths are Q->T, R->T, S->T right? and would those transitions happen when T releases or 3mo after T releases?17:29
slangasekogasawara: I don't remember if it was "when T releases" or "3 mo after"; it was discussed in the UDS session17:30
slangasekbut yes, that's what I was expecting to see as the upgrade path17:30
slangasekwhich means keeping separate named metapackages for each backport channel17:30
ogasawaraslangasek: our reasoning for doing the rolling upgrade of Q->R->S->T was to minimize the maintenance burden17:30
slangasekwell17:30
slangasekmy understanding was that it was already agreed that the kernel team would take on that maintenance burden, as the cost of providing a suitable LTS experience :)17:31
slangasekan upstream kernel upgrade every 6 months for anyone who needs any post-12.04 hardware enablement isn't very LTS-y17:31
ogasawaraslangasek: we're digging up our notes from UDS...17:33
slangasekok :)17:33
infinityslangasek: They get "a new one every 6 months" anyway, just with an initial 18-month delay.17:38
infinityslangasek: (With your proposed scheme)17:38
slangasekinfinity: not at all17:38
slangasekinfinity: they get "the one they installed", followed by "the one from the next LTS"17:38
infinityslangasek: Oh, right.  Okay, fair enough.  But.  Well.  How is that better?17:39
slangasekit's better because one kernel switch is better than more than one kernel switch :)17:39
infinity(I'm not convinced on the "12.04.2 should ship with the backport kernel" plan, mind you, but that's unrelated)17:39
infinityslangasek: It's one massive kernel switch, rather than smaller incremental ones.  Both suck, I guess.17:40
infinityI do think that the whole foo-lts-backport-$release thing is madness, though.17:40
slangasekin terms of administration cost, one massive kernel switch is clearly better17:41
slangasekwhich is why the users have chosen the LTS in the first place :)17:41
infinityslangasek: It might be better for upgrade scariness costs, yes.  I'd argue that the quality of support we (or anyone) can provide on a system with multiple shipping kernel versions is probably worse.17:43
infinity(When you do a userspace SRU on lucid that's scary and wonky, do you test on lucid's kernel, plus all the backports?)17:43
infinityAnd while we clearly need to be doing the backport thing to support new hardware, having several of them instead of the One True Backport Kernel does make things a bit of a nightmare.17:45
infinityIt does for end-users too, who find that they have 3 different kernels installed, based on when they installed their machines.17:45
henrixsmb: finally, pkg upload has completed!  it's on zinc17:47
smbhenrix, ok. looking17:47
infinityslangasek: I really have no sense for what the average user finds good, sensible, or maintainable.  But I know I live in a bit of an all-or-nothing state where my ideal is "all my machines have the same kernel and never change, ever", but the next best thing is "they all upgrade together and have the same version at all times".  Having the possibility to have 3 or 4 versions in play based on when in the enablement cycle I jumped on board is awful, IM17:49
slangasekinfinity: well, in that case you still have the option to upgrade them all to the latest enablement kernel for consistency17:50
slangasekbut users shouldn't be forced to be an a 6-month kernel upgrade treadmill just because their hardware enablement missed 12.04 by 3 months17:50
ogasawaraslangasek: we're unable to find notes which definitively document the solution that was discussed but we clearly remember different results.  I think we're at a stand still atm.17:55
ogasawaraslangasek: am contemplating best way to move forward17:56
infinityogasawara: A linux-meta-lts-backport-latest that gave the rolling experience would allow users the choice between option A or B.17:57
infinityogasawara: That doesn't solve the headache that you guys have to support N kernel versions on the LTS, but if that support is effectively just backport-and-forget (has it been vaguely effortless for lucid?), then that may be a non-argument.17:58
apwinfinity, yeah and lts-hwe-falvour is your one there, we are going to have 'this lts backport' and the 'latest lts backport' meta packages17:59
apwinfinity, the argument is about which is default for a .N release17:59
rtginfinity, linux-hwe-generic and linux-image-generic-lts-quantal are the 2 meta package names right now18:00
slangasekogasawara: maybe the X guys can break the tie... since the X stack and kernel need to be doing the same thing :)18:01
apwslangasek, heh yeah18:02
ogasawaraslangasek: they definitely need to be brought into this discussion18:02
rtginfinity, slangasek: this is the description of how meta packages are meant to behave based on my memory of UDS sessions (which I wrote the week after IIRC): https://wiki.ubuntu.com/Kernel/Release/Rolling18:04
slangasekrtg: yes, everyone is pointing me at the wiki page; I'm saying that's not what I understood was being agreed to18:06
slangasekI'm not saying you misremembered, I'm just saying that apparently not everyone in the sessions understood the same thing18:08
rtgslangasek, clearly :)18:08
bjf!vote!18:08
ubot2Factoid 'vote!' not found18:08
* apw votes slangasek gets the first round in18:08
smbhenrix, its signed now18:10
henrixsmb: ack, thanks!18:10
infinityapw: Was there a reason no one felt the proposed 14.04 plan wouldn't be appropriate for 12.04 too?18:16
infinityapw: (If you recall)18:16
apwinfinity, that applied the same to the 'release' kernel as well, and i think people were scared of that18:17
apwinfinity, before people were used to a regular new kernel18:17
infinityI can see how it's scary, but if it's scary now, it's scary in two years too.18:17
infinitySo, this needs to be hashed out sooner or later.18:17
apwi see it as a slightly scarier combination, and 14.04 the same level of scary compared to this18:19
bjfjjohansen: bug 102685318:23
ubot2Launchpad bug 1026853 in qa-regression-testing "test-kernel-security fails on seccomp on Oneiric AWS" [Undecided,New] https://launchpad.net/bugs/102685318:23
jjohansenbjf:  thanks18:23
jjohanseninfinity: because the 12.04 plan was announced before what is currently planned for 14.04, and maybe deals where made based on that18:26
argesogasawara, hi18:26
ogasawaraarges: heya, are you still on holiday?  If so, go away18:27
argesogasawara, no i'm back today! family left a day early18:27
ogasawaraarges: ah, I can see the doc now, thanks!18:27
argesogasawara, yup. no problem18:28
ckingapw, this is a fun elf article: http://timelessname.com/elfbin/18:53
ogasawarartg: https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg19:00
ogasawarartg: look at their Questions section at the end19:01
infinitycking: Haha.  Love the animated gif of jmps.19:08
rtgogasawara, hmm19:10
hggdhsmb: while testing the new oneiric kernel, I got a crash on m1.small: http://pastebin.ubuntu.com/1102330/19:48
hggdhrepeating the test did not result in a crash19:48
smbhggdh, I think I saw this kind of failure somewhere before but I cannot remember exactly where. Does repeating the test involve starting another instance? (which I assume)19:51
smbIt would be good if there are complete dmesgs of fail or not fail (in order to see which xen version this was)19:52
jjohansenyeah19:54
infinityCould be hypervisor versions, or even underlying hardware.  Not all instances are created equal. :/19:54
jjohansensmb, hggdh can't you just reboot the instance, instead of starting a new one so we are guaranteed the same Xen/machine19:54
smbjjohansen, with manual attempts certainly. Though I would think from jenkins its probably always starting a fresh one19:57
smbWith all the "repeatability" 19:57
hggdhsmb, jjohansen19:57
hggdh; the instance was rebootged19:57
smbUnfortunately ec2 is a bit "surprising" there19:57
hggdhthis is being run manually19:58
* jjohansen wasn't sure if this was from a jenkins or manual test19:58
* smb neither19:58
hggdhjjohansen: I will rerun on the previous kernel20:05
hggdhand this may explain the failure I got yesterday runniong the -1720:10
hggdhjjohansen, smb just ran seccomp on -22, no errors20:22
hggdhI am starting to think I am getting different xen versions20:22
smbhggdh, As did I (get no errors) when running it yesterday. That one was something 3.4.3-kaos...20:23
jjohansenhggdh: likely, what we need to do is multiple runs, and get the full boot log20:23
hggdhthe failing one (on -23.39 is [    0.000000] Xen version: 3.0.3-rc5-8.1.14.e20:24
hggdhthe one with no failure (on -22) is [    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)20:25
hggdhsmb: isn't the 3.03 the one we had an issue some time ago?20:25
hggdhhow many bloody different versions does AWS run?20:26
bjfhggdh: are you ready to sign off on the "incident" bug so we can get this oneiric kernel into -proposed? 20:26
smbhggdh, Usually the older the more issues. There was one, and it might have been this one that had issues with installing java on 32bit t1.micro20:27
ogasawarappisati: can you add DRM_OMAP to your investigation list20:27
smbhggdh, bjf Certainly this is not any regression (that much we already were ready to agree yesterday)20:27
smbjjohansen, Note that the crash there is another path of setting cr4 (remember osxsave)?20:28
hggdhI just ran another one under [    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)20:31
jjohansensmb: no, not at all /me sticks fingers in ears and shouts I'm not listening, I'm not listening20:32
smbhggdh, aaaaand?20:33
hggdhhum. Let me repeat, the instance seems to have vanished :-(20:33
jjohansensigh /me really dislikes dealing with all Xen version on ec220:33
smbhggdh, That does not exactly sound like a repeat20:34
hggdhdammit. I have the feeling it was a 3.0.3-whatever, under -17. I will restart20:34
=== yofel_ is now known as yofel
hggdhsmb: no, it does not. I never had an instance simply vanish in thin air20:39
hggdhfound it, it was just lurking. It is indeed a 3.0.3-rc5-8.1.14.f, on -1720:41
smbhggdh, I have the same gp fault on another 3.0.3 I started and I certainly had no problems yesterday which ran on 3.4.320:43
hggdhsmb: the other 3.0.3 above also died on an OOPS20:43
hggdhsmb: I agree this sounds like a bad Xen on AWS20:44
hggdhapart from that, no errors on KVM, and bare-metal (except that all jobs on two specific machines failed, but this is due to a problem with the CDU20:48
hggdhoh, perfect, now I have a thunderstorm over me20:48
hggdhsmb, jjohansen: do you agree this is most probably related to the 3.0.3-crappy Xen on AWS?20:49
jjohansenhggdh: that does seem to be a possibility, but I a haven't seen enough data to be comfortable claiming such.  Basically I have seen one instance that we can definitively make the correlation.  I would like a lot more data than that20:51
smbhggdh, Having seen it pass depending on host Xen version or not and even fail on older releases when not, this really does not sound like any regression20:51
bjfthis is *not* a regression. a bug has been filed, we need to add data to that but do we wan't to hold up on the release of this kernel?20:53
bjfhggdh, jjohansen ^ ?20:55
hggdhbjf: jjohansen is correct -- it seems not a regression, but I would like to try another one20:56
* hggdh is almost convinced20:56
jjohansenhggdh, bjf: I am convinced it is not a regression we have sufficient data to show it happening on older releases.  The only thing I am unsure of is the correlation of all the failures to Xen version 3.0.3-crappy20:57
jjohansenbjf: what is the bug number again20:57
bjfjjohansen: bug 102673020:57
ubot2Launchpad bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/102673020:58
hggdhjjohansen: running on 3.4.3-kaos-whatever20:58
smbjjohansen, I agree that pinning badness to one exact version we will need to repeat the tests more often. There might be versions in between showing the same or different problems (or none)21:00
hggdhso far we have at least 3 different versions involved... who knows how many are there?21:01
smb$DEITY knows...21:02
smbStill this should not let us delay getting rid of the other mess21:03
hggdhOK. ran on 3.4.3-kaos_droplet (preserve-AD), -17 kernel, no issues21:03
hggdhI vote to approve21:03
smb+121:03
jjohansen+121:03
hggdhjjohansen: ?21:03
hggdhheh21:03
bjfhggdh: you can cast your vote by changing the task :-)21:03
* hggdh goes updating the task21:04
hggdhjjohansen: there is a confirmed task there for you also21:05
* hggdh goes terminating all m1.small instances21:07
jjohansenhggdh: yeah, its going to take a few minutes, I am running the scripts now21:07
bjfjjohansen: i believe the bug is waiting on "security signoff'21:11
jjohansenbjf: yes, I am working on it21:11
bjfjjohansen: :-) thanks21:12
infinityOh, hah, I just mentioned that in another channel.21:12
infinityLa la la.21:12
infinityI'd question why Amazon is using xen3 at all instead of xen4, but whatever. :/21:13
hggdhnot only xen3, but a really old on at that21:17
hggdhs/ on/&e/21:17
jjohansenhggdh, bjf, infinity: released21:29
* hggdh goes to cross all fingers and toes, just in case21:29
bjfjjohansen: ack21:30
bjfinfiniti, it is in your hands21:30
bjfinfinity, the bot is not going to set the release tasks due to it being friday :-)21:32
henrixbjf: and will it set the 'promote-to-proposed' task on the lts kernel tracking bug?21:34
hggdhbjf: BTW, have you seen https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/ ? We are now listing the kernel version there; I think it is good enough, care to comment?21:36
bjfhggdh: yes, that is very nice in the description. are these in the "dashboard" yet?21:38
hertonhenrix, yes, nothing was changed related to the promote-to-proposed task21:39
henrixherton: ack, thanks21:39
infinitybjf: Haha, right.  On it.21:41
hggdhbjf: I think so (based on gema's EOD in G+)21:41
infinitybjf: Was the promote-to-security task a mistake there?  The previous -23.38 was only in -updates.21:43
infinitybjf: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020623 <-- No security task.21:44
ubot2Ubuntu bug 1020623 in linux "linux: 3.0.0-23.38 -proposed tracker" [Undecided,Fix released]21:44
infinitybjf: Doesn't seem to make sense for 23.39 to have one.21:44
henrixinfinity: there is a security task there as well, which was marked as invalid i believe.21:45
henrixinfinity: see comment #421:46
hertonyes, the bot would set it to invalid, but as it doesn't run today the task stays as new21:46
infinityhenrix: I meant "there wasn't a valid one". :P21:46
infinityherton: The bot really should be marking security (and signoff) tasks invalid long before it comes up.  Could have saved jjohansen some time too.21:47
infinity(Though I'm not sure how the bot even knows, I would have thought it was a human task)21:47
hertoninfinity, no, the bot doesn't go as far as that, I thought you meant about the task as being in new state21:47
bjfinfinity, jjohansen set the task21:47
infinityherton: No, no.  I meant it should be invalid.21:48
jjohanseninfinity: we have scripts etc, to help determine if its invalid, but in the end it currently a human call21:48
hertoninfinity, the bot sets it to invalid if jjohansen sets the security-signoff to invalid. But it sets this along with the promote-to-updates step21:49
jjohanseninfinity: so I ran my check, it reports it needs to be looked at, and another script reports it doesn't believe there are any CVEs, but I need to do the check and make the final call21:49
infinityherton: Ahh, kay.  So, jjohansen also didn't set signoff to invalid, so I'll blame him. :)21:49
infinityOh, wait.  He did.  I'm blind.21:49
infinityIGNORE ME.21:49
jjohansenherton: I did set the security sign-off to invalid21:50
* infinity plays bot, and releases.21:50
jjohansenherton: oh ignore I read that wrong21:50
henrixinfinity: since you're around... would you care to take a look at oneiric lts kernel? :)21:51
infinityhenrix: Needs a PPA copy?21:51
bjfinfinity: it just went into the upload queue21:52
henrixinfinity: yep. i know its friday, but its the same issue so... i guess we're having an exception here as well21:52
infinitybjf: Alright.  Will accept and fix the override on the one binary if it breaks the same way.21:52
henrixthanks21:52
infinityjjohansen: If you want to pre-emtively security-invalidate https://bugs.launchpad.net/kernel-sru-workflow/promote-to-proposed/+bug/1026884 now, so we don't have to worry about it later? :)21:54
ubot2Ubuntu bug 1026884 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-23.39~lucid1 -proposed tracker" [Medium,In progress]21:54
rtghttp://bytesmedia.co.uk/2012/07/17/richard-stallman-uefi/21:54
infinityrtg: That's a terrifying combination of nouns.21:54
rtginfinity, as you might have guess, he's not all that positive about UEFI21:55
infinityrtg: s/UEFI/SecureBoot/21:55
infinityrtg: And even then, probably only vendor restrictions on SB, I'd bet.21:56
rtginfinity, right21:56
* infinity wishes people would stop conflating (u)efi and SB.21:56
rtgI've conflated UEFI with SB 'cause its all I've thought about lately21:56
infinityWe have a "supporting UEFI" session at DebConf that was entirely dominated by SB prattle, which was useless.21:56
infinitys/have/had/21:57
jjohanseninfinity: unfortunately microsoft is forcing the the conflation of UEFI SB and RB21:58
infinityjjohansen: To be fair, I think it's mostly the free software world that's doing that, especially the people who don't seem to be aware that there have been EFI machines for years that they supported poorly (or failed to support entirely).22:00
infinityjjohansen: So, now that the world is moving to UEFI wholesale, and it happens to coincide with the Win8 SB cutover, people are acting as though "supporting EFI" and "supporting SB" are the same task, when they're two very different beasts.22:01
infinity(And those of us who supported EFI for years know this)22:01
jjohanseninfinity: previous efi did not conform to the SB specification and microsoft wasn't forcing its use for RB nor was it the root key authority22:02
infinityjjohansen: Yes.  But that doesn't make A equal to B.22:03
* infinity shrugs.22:03
infinityIt's a pet peeve.22:03
jjohanseninfinity: agreed that EFI and SB are different but its because microsoft is forcing SB/RB that its a problem22:03
infinityNot made better by, like I said, a one hour session of people talking about secureboot, as if that mattered when Debian doesn't even support EFI properly.22:03
infinityjjohansen: SB/RB goes from annoying to downright hostile, but even without it, modern OSes need to support EFI, and most don't actually do it right.22:04
jjohanseninfinity: true, though /me can wish that EFI was never even conceived22:05
infinityI do rather wish that Intel/HP had gone with OpenFirmware back when they decided to flirt with PC BIOS alternatives.22:07
infinityThe reinvention of the wheel was irksome.22:07
infinityFrom a "firmware addon" developer POV, EFI is much more pleasant, though.  Maybe that was part of the motivation.22:07
jjohanseninfinity: heh if firmware addons are what you want what of coreboot22:12
infinityjjohansen: coreboot is politically distasteful to a lot of people, I suspect.22:14
jjohanseninfinity: well yes :)22:14
jjohanseninfinity: but so is SB22:14
infinityOF would have been a reasonably neutral choice, I thought.22:14
infinityIBM, Sun, Apple, and many others had invested in it.22:14
jjohansenit was the logical choice at the time22:14
infinityBut, too late now.22:14
jjohansenyep22:14
ogasawarappisati: CONFIG_NLS_ISO8859_1 does this need to be =y on omap4 or can we flip it to =m22:39
ogasawarappisati: CONFIG__OMAP_IOVMM=n, should that be =m?22:44
ppisatiogasawara: OMAP_IOVMM should be deprecated in modern kernels, is it =y or =m anywhere?23:20
ogasawarappisati: it's set =m on omap323:21
ogasawarappisati: so we should turn it off yes?23:21

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