/srv/irclogs.ubuntu.com/2010/08/24/#ubuntu-kernel.txt

=== simar__mohaar is now known as simar
=== bjf[afk] is now known as bjf
=== kancerman_ is now known as kancerman
=== bjf is now known as bjf[afk]
=== jjohansen is now known as jj-afk
jj-afkback on later01:02
syn-ackjj-afk: Congrats on the inclusion. ;) It's finally about time! good work to you and Pete and the rest of the crew. :)04:41
jj-afkhere's hoping the latest upgrade doesn't break me08:02
jj-afkrebooting08:02
jk-ever the optimist08:03
amitkheh08:03
jk-amitk: http://devicetree.org/PowerDomainBindings : do we expect devices to have multiple power inputs?08:04
amitkjk-: you mean a single device drawing power from multiple regulators?08:05
jk-amitk: exactly, yup08:05
jk-(maybe an ethernet device with a separate line for the phy?)08:06
jk-although, the ethernet and the phy may be considered separate devices...08:06
amitkjk-: yes, there are such devices. I think the MMC driver in OMAP (atleast the rx51 board) is one such example08:06
amitkbrb08:06
jk-amitk: ok, thanks08:06
=== achaemenes is now known as hydarnes
=== ericm_ is now known as ericm|ubuntu
smbjjohansen, Ok, I cannot find the way from split_vma to make_pages_present. Likely too much inlining there so see it on a glance. In the end make_pages-present is called with an addr >= end. Not sure its worth to try to understand that too much. I go ahead and build kernels for the variations we talked about.09:19
=== amitk is now known as amitk-afk
=== amitk-afk is now known as amitk
jjohansensmb: I couldn't find it either11:25
jjohansensmb: that is I didn't find make_pages_present in split_vma11:27
jjohansenbut mlock_fixup calls it directly11:27
* jjohansen wonders if the stack trace is broken11:27
=== jjohansen is now known as jj-afk
jj-afkg'night11:43
lamontsmb: how's things?11:52
dholbachhi guys12:48
dholbachcan something be done about bug 622583?12:48
ubot2Launchpad bug 622583 in linux-meta-rt (Ubuntu) "Remove the linux-meta-rt packages (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/62258312:48
dholbachit says that another kernel was uploaded for review but never received any12:48
smblamont, Got two new variations to try... if you ain't bored of it by now. One (pre4) is on tangerine in hardy-amd64 the other I need move out of nc13:00
smbdholbach, Looks like this is an archive admin question13:01
dholbachsmb: but the kernel that's up for review?13:01
dholbachsmb, the bug I mentioned it also currently stuck at a review-before-archive-admins-do-their-work level and I thought it'd be good to have the kernel team have a look at it13:02
smbhm, yeah. Wonder whether that is the real rt one or moved over to preempt. Someone needs to chech that13:02
smbabogani, are you around?13:02
aboganismb, Yeah13:03
dholbachthanks guys13:03
smbdholbach, was looking at your bug above and I am not sure about the kernel for review thing13:03
smbabogani, Is this the -rt version or something for -preempt that apw was trying to look at?13:04
aboganismb: Lowlatency should be the preempt replace.13:04
aboganilowlatency should be kernel which apw should review.13:04
smbAh ok and -rt will be continued in universe13:05
smbor where ever it is now13:05
aboganismb: No it is died.13:05
smbOk, so I am now well confused. :) What kernel is "An updated version was uploaded on http://kernel.ubuntu.com/git but it never receive a review." referencing in the bug report above13:06
* smb is still trying to get some hardy security wreckage fixed and is a bit out of any other context...13:07
lamontsmb: rebooting into pre4 now13:07
aboganismb: Lowlatency should be replace preempt. Realtime should be replace rt.13:08
aboganismb: There are only two kernels on Zinc owned by me :-)13:08
lamontError: /usr/lib64/xen/bin/xc_restore 23 3 1 2 0 0 0 failed <-- smb13:10
smbabogani, This would still leave a 50:50 chance to know which kernel you mean. Though I guess as it says remove -rt it means -realtime. Did you ask someone to review?13:10
smblamont, So still no joy there.13:11
lamontcorrect13:11
smblamont, Ok, give me a few minutes to move pre513:11
aboganismb: In any case don't bother with the -rt/-realtime, please. I give up to continue that effort.13:12
smblamont, btw have you once tried pre2 from the peoples page (or maybe still on tangerine, too)? To at least see what happens when we do not try to do anything smart13:13
smbabogani, Ok, so basically the request in that bug means: Please remove any -rt kernel and meta package from the maverick archive?13:14
smbabogani, And sad to hear you give up. Did we have too little time to help you there?13:15
lamontsmb: I haven't13:19
lamont http://people.canonical.com/~smb/lp620994/linux-image-2.6.24-28-xen_2.6.24-28.77~pre2_amd64.deb is 40413:19
smblamont, *lalala* try again13:20
aboganismb: No. I would be very happy if I had received the rights to upload these packages after more than 3 years I'm working on it (that is since Feisty/Gusty and I'm the only one).13:21
dholbachabogani, I can't quite remember, did you apply for those upload rights?13:24
aboganidholbach, Of course Sir.13:24
smbabogani, I know the process to get that is a bit long winded. Normally someone has uploaded the packages for you. The problem then is that that someone remains the same one or two people which then can give you their endorsement for upload rights. I did that for one upload but that is not really long enough13:24
dholbachabogani, how did it work out?13:24
smbAnd I am ready to admit that I fail often to review if I am not reminded daily and beaten with sticks. There nearly always seems something urgent going on. :(13:26
aboganidholbach: Sorry?13:28
dholbachabogani, the application process, what was blocking the application there?13:28
aboganidholbach, The lacking of endorsements.13:28
lamontsmb: pre2 only has headers and linux-libc-dev on people.c.c13:29
smblamont, hm, ok. Need to fix that up. No idea where those went. pre5 should be there now and complete13:31
dholbachabogani, that sucks - who's been your main sponsors?13:31
aboganidholbach, Ben Collins and Luke Yelavich13:32
dholbachabogani, I see13:32
lamontsmb: rebooting nao13:34
smblamont, Ok, seems pre2 I have to compile again. :-/ binaries seem have to have vanished13:37
lamontError: /usr/lib64/xen/bin/xc_restore 23 3 1 2 0 0 0 failed <-- pre513:38
smblamont, gah!13:38
smblamont, Is in that version the guest unreachable too or can you ssh in like in pre113:39
lamontI haven't been able to ssh to any guests in anything pre1-513:40
lamontif I rebuild from scratch, I see it come up during that process, then we do a stop & restore and the restore is what fails13:41
smblamont, Hm, maybe I got that wrong then. I thought ssh was possible with pre113:41
lamonthost has booted for all pre1-5, and you asked if I had networking at all: I said I had sshed in (to the host), maybe you took that to mean guest13:42
smbYeah, that was my confusion13:43
lamontand by "up during the rebuild", I mean pingable from off-host13:43
smbHm ok which means we have no information at all from within the guest... I assume the guest process is not running anymore when the error occurs13:45
lamontno it isn't.  we've stopped it and are trying to restore13:50
=== bjf[afk] is now known as bjf
bjf##14:56
bjf## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting14:56
bjf##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting14:56
bjf##14:56
ogasawaradiwic: around?  just had a quick question about two of the patches you sent that you're wanting to land in the Maverick Beta kernel...15:04
ogasawaradiwic: ALSA: HDA: Fix front mic on Dell Precision M650015:04
ogasawaradiwic: ALSA: HDA: Add Sony VAIO quirk for ALC26915:05
ogasawaradiwic: I didn't see them upstream in Linus' tree, just curious if they're in Takashi's sound tree?15:05
ogasawaradiwic: if so, do you have the sha1's you could point me at, just so I can add them to the commits in our Maverick tree when I apply them.15:06
diwicogasawara, I'm around15:07
diwicogasawara, so these were submitted upstream yesterday and Takashi hasn't been around today15:07
ogasawaradiwic: ah ok.  They seem harmless enough so I'll still pull them for Maverick.  Just be sure to also submit all 5 to upstream stable.15:09
diwicogasawara, the happy users are in bug #519066 and bug #61827115:09
ubot2Launchpad bug 519066 in alsa-driver (Ubuntu) "Microphone doesn't work on Dell Precision M6500 (affects: 10) (dups: 1) (heat: 70)" [Medium,In progress] https://launchpad.net/bugs/51906615:09
ubot2Launchpad bug 618271 in alsa-driver (Ubuntu) "[Realtek ALC269] ALSA test tone not correctly played back = no sound at all (affects: 2) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/61827115:09
ogasawaradiwic: that way when we rebase to a stable kernel which contain the patches, we'll just drop the one's we're carrying in favor of the official upstream patch.15:09
diwicogasawara, so to sum up, when I send the patch to upstream, it should have a "Cc: stable@kernel.org" in the commit message, a launchpad buglink and a sign-off?15:11
diwic(assuming it's suitable for stable)15:11
ogasawaradiwic: yep15:12
diwicokay, thanks15:13
ogasawaradiwic: if they went upstream without the "Cc: stable@kernel.org", just send an email to stable@kernel.org once the patch has landed in Linus' tree asking for the patch to be considered for the next stable patch set.15:13
bjfdiwic: this should help some, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat15:14
ogasawaradiwic: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=e213f45cf9d7505c9c9e1fbd088eb91cd83292f4;hb=HEAD15:14
diwicbjf, ogasawara, thanks, I'll have something to read now :-)15:16
diwicbjf, so for upstream I'd use ogasawara's link, and for the email to ubuntu-kernel mailinglist, I'd use bjf's link?15:18
ogasawaradiwic: yep15:19
bjfdiwic: ack15:19
diwicDoes upstream like launchpad BugLink rows?15:20
bjfdiwic: at this point, i don't think they mind them15:21
ogasawaradiwic: probably depends on the maintainer.  I haven't had issues when I've submitted patches upstream which had a BugLink.15:21
ogasawaradiwic: the nice thing about the BugLink is that either the launchpad janitor or our own scripts will close the bug when it gets into our tree.15:23
diwicSomeday when I'm feeling happy I'm going to add a switch to git commit that adds Cc: stable and BugLink lines ;-)15:28
manjotgardner, LTS backports is for servers only ?15:29
tgardnermanjo, that is the supported configuration, but it  seem to work well for many desktops.15:29
JFobut if it doesn't we let you keep the pieces :)15:30
manjotgardner, so there are separate desktop and server kernels that you build? or just one kernel works for both?15:30
tgardnermanjo, the same flavours are built for both Maverick and its backport to Lucid15:31
tgardnersame x86'en flavours that is15:31
manjook thanks15:31
bjf##16:02
bjf## Ubuntu Kernel Team Meeting - in 1 hour - #ubuntu-meeting16:02
bjf##16:02
ogasawarabjf: 1hr or 2hr?16:02
bjfogasawara: you are correct, was looking at london time and not gmt16:03
bjf##16:03
bjf## Ubuntu Kernel Team Meeting - in 2 hours - #ubuntu-meeting16:03
bjf##16:03
JFotgardner, have you seen this? https://bugs.launchpad.net/ecryptfs/+bug/62308716:43
ubot2Launchpad bug 623087 in ecryptfs "ecryptfs file permissions broken with kernel 2.6.36-rc2 (affects: 2) (heat: 12)" [Critical,In progress]16:43
JFoapparently folks testing against RC1 are losing data16:43
tgardnerJFo, hmm, thats bad. why do we have a bug against 2.6.36 already?16:44
JFogood question16:44
JFoapparently some folks are doing some testing with the RC16:44
tgardnerI haven't even officially announced the natty repo16:44
JFoheh, you know how those folks get when they get the maple syrup in them. All antsy in the pantsy16:45
tgardnerJFo, looks like Tyler is already on it16:46
tgardnerJFo, you should change the package from ecryptfs to linux16:47
JFok, will do16:47
JFough, sometimes I really hate LP16:51
=== jj-afk is now known as jjohansen
=== kamalmostafa is now known as kamal
smbjdstrand, lamont, jjohansen, Just some update: I have installed xen on a test system without any guest configuration. .37 seems to boot ok (though network does not work atm), all of the prex kernels seem to crash when booting Dom0 in page_remove_rmap (which has not been looked at yet at all)17:48
jdstrandack17:49
jjohansensmb: ouch, its spreading17:49
jjohansensmb: have you verified whether a stack vma split by the mlock is merged back together correctly, or are we getting into a situation where the stack vma is getting really fragmented17:50
smbjjohansen, Not really spreading. That is probably just the next thing that breaks. I was already somewhat scared of how this guard page might interact17:50
jjohansensmb: yeah I know, it was a "its spreading like the plague" type statement ;)17:51
smbjjohansen, I have not had a system up enough to be able to look at that17:51
jjohansensmb: ack17:51
smbThere is a lot of "in theory" there atm :/17:52
jjohansenyeah17:54
smbouch, page->flags = 7365696666696e does not feel too right17:56
smbbjf, <chiming sound>17:57
bjfsmb: my clock says 3 min17:58
smbmine seem to be undecided. but you are right the majority says 2m17:58
bjf##17:59
bjf## Meeting starting now17:59
bjf##17:59
jjohansenchase: can I get you to look at something quick?18:00
jjohansencnd ^18:00
cndjjohansen, look at what?18:03
cndin #ubuntu-meeting?18:03
jjohansenno just a sec18:03
smbjjohansen, *sigh* maybe I have an idea what else could be wrong18:23
jjohansensmb: oh?18:23
smbjjohansen, There is also the place where the guard page is added. And that also just checks for very basic things. Which could be wrong for splitted stack vmas...18:25
jjohansenhrmm, yeah18:25
smbMight be worth to try. I don't want to try understand why the other thing crashes without really really needing to18:27
smbAnd maybe something I need to understand is whether find_vma would expand any vma if it can...18:28
jjohansenno find_vma shouldn't expand them18:30
jjohansenmy bet is its in the simple tests, that basically assume the stack is a single vma18:31
smbWhich makes the code looking a bit weird as there is this test for find_vma ((addr & PAGE_MASK) - PAGESIZE) != vma. if there is not yet a vma for the address below wouldn't find_vma return NULL?18:33
smbbut yes, the rest assumes that single vma 18:33
smbah now, the semantics is different18:34
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-31 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
* tgardner lunches19:06
* smb dinners19:07
=== gnomefreak76 is now known as gnomefreak
=== bjf is now known as bjf[afk]
=== hydarnes is now known as rasputin
=== yofel_ is now known as yofel
* jjohansen -> lunch20:49
=== ivoks is now known as ivoks_sleeping
smbjjohansen, lamont, jdstrand Yo! Seems pre6 finally boots in xen mode as badly as the .73 kernel did. It comes up claims to have a network but no pings go well (but as said this was before). I got the 64bit versions moved over but now pgraners tyler seems to have vanished21:21
smbHm, no reconnect works... must be network flux21:22
jdstrandsmb: I had networking going here with dhcp, so I can test that21:22
jdstrandsmb: do you have i386 builds?21:22
smbjdstrand, Yes, but not (yet) for you. Those need moving21:23
jdstrandsmb: k, just ping me and I'll test21:23
smbsure21:23
jdstrandsmb: thanks for all your work on this :)21:24
smbjdstrand, Heh, well I broke it, so I have to fix it. :) Though it rather was upstream/Linus.21:26
* smb wonders whether the more recent kernels really work with xen21:26
jdstrandit would be worth testing21:26
smbjjohansen, Did you have time to test the ec2 kernels of security?21:26
jjohansensmb: I haven't yet, I will try it today, but I expect they will fail21:27
smbHrm, we might have been a bit quick with the release here. We really should make sure we await at least feedback on the ec2 kernels before claiming the release is good.21:30
jjohansensmb: sorry, its one of those things, I meant to test, and then it slipped through the cracks21:30
smbBut maybe Lucid or Karmic mm is broken in a way that it handles the badness better. Though the last bug I fixed now would cause asummption of ENOMEM when looking at split vmas of the stack. Well, its not only you having forgotten to do the test. Its also kees and jdstrand to be careful to have all oks.21:32
smbjdstrand, Ok, pre6 i386 versions now on people.c.c/~smb/lp62094421:34
jdstrandsmb: ack21:34
smbjjohansen, If you are interested doing a second glance over the patches of pre6, I put them to chinstrap (0005 + 0006)21:39
jjohansensmb: okay, I'll look at them as soon as I am done testing on EC2 :)21:40
smbjjohansen, wfm :) thanks21:40
jjohansenhrmm, Lucid boot testing passed with the security kernel, I expected problems21:55
jdstrandsmb: .77 i386 generic passed qrt test-kernel*21:55
jdstrandsmb: still testing -xen, but so far so good21:56
smbjjohansen, Well, there is a lot of other things different. Could be even differences in what userspace does21:56
jdstrandsmb: I can say for sure that networking works just fine, and so does xc_restore21:56
smbjdstrand, \o/ :)21:56
smbI'd probably give it to lamont tomorrow and then prepare packages to upload. Question is whether we want to do similar fixes to Dapper even as xen does not exist there.21:58
smbjdstrand, Maybe something to discuss with kees21:58
jdstrandsmb: how similar is the code in dapper?22:01
jjohansenjdstrand: were you doing anything special to tickle xc_restore?22:01
jdstrandjjohansen: I start a vm, then reboot the host. it will trigger a save on shutdown and a restore on boot22:01
smbjdstrand, very similar. I believe between hardy and dapper there was not much change.22:01
jjohansenjdstrand: right22:02
jdstrandjjohansen: an easier way would probably be to look in the initscript22:02
jjohansenjdstrand: nope reboot, and stop for ec222:02
jdstrandsmb: we can discuss with kees when he comes online, but my feeling is we get hardy fixed, see how it goes and then consider backporting hardy's patches to dapper at the next security update22:03
smbjdstrand, I think we probably should do it as this now might leave the loophole of allowing a user-space app which partially locks the stack to crash things. Maybe its worth to make a test case for that22:03
smbjdstrand, But yes, first hardy and see, then look forward22:03
smb11pm... /me thinks its a good time for eod22:04
jdstrandsmb: have a good night. thanks again22:05
smbnp. somebody remind me tomorrow to update the bug. :)22:05
jdstrandsmb: do you want me to point people at pre6 so they can maybe test through the night?22:06
smbyeah that sounds like a good idea22:06
jdstrandk22:06
=== bjf[afk] is now known as bjf
* lamont fetches pre623:07
lamontError: /usr/lib64/xen/bin/xc_restore 23 10 1 2 0 0 0 failed <-- jdstrand, smb, et al.23:26
lamontthat's pre623:26
lamontthere was a known issue with lucid vs xen at one point23:27
lamontsigh.  let's see if ACTUALLY REBOOTING INTO PRE6 works better for me.23:29

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