[01:48] hi all, i have a camera supporting the Mjpeg and H264 format. Now i can play the mjpeg format streaming, but i have no idea to play the h264 format. the linux do not support the h264 format. [01:49] Could you give me some advices? [01:56] I think that it's highly unlikely this is a kernel problem; looking further up the stack is probably what you need to do. [02:10] Hi RAOF , thanks for your reply. I want to add MPEG format to the V4L2 Driver. Do you have any ideas? [02:21] brucezhang: Is the V4L2 layer currently incapable of forwarding mpeg streams on? It's not a problem further up? [02:30] In linux driver layer, V4l2 does not support the H264 format. [02:32] It surely can't be too hard to add that :) [02:33] You're basically just passing on data from the card, right? All that's needed is an extension of the content negotiation, and possibly some metadata? [02:34] i get data from usb dev. [02:35] by the command usb-devices, the MJPEG interface can mount the dirver, but the MPEG interface can not mount the driver. === smb` is now known as smb === amitk is now known as amitk-afk === amitk-afk is now known as amitk === jjohansen is now known as jj-afk [09:42] apw - guess what is happening again - but now it's not all the time - and I am trying to narrow down what triggers the temp increase reliably [09:43] akgraner, bah i hate that machine [09:43] me too [09:43] just want to give you a heads up [09:44] as soon as I figure the trigger part - I'll file a bug :-) === yofel_ is now known as yofel [15:07] sconklin: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/654590 [15:07] Launchpad bug 654590 in linux-linaro (Ubuntu Maverick) (and 1 other project) "WLAN-BT GPIOs need proper initialization (affects: 1) (heat: 12)" [Undecided,Fix released] [15:17] apw: did you port this patch of yours to 2.6.37? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=985f7e2eabee43c30fd3f4d44c8c291c143615f3 [15:20] tseliot i believe this is patch is currently missing as it failed to apply [15:20] its on my list to fix [15:20] tseliot, seeing issues ? [15:21] apw: ok, I was asking as, after porting some new radeon code to Maverick's kernel, the kernel works well but the ddx driver can't open the drm device [15:22] could easily be the issue, i have a crap load of patches on the floor at the moment [15:23] apw: I'll work on it as otherwise I really wouldn't know what could be causing the issue [15:23] want me to have a peek ? [15:24] tseliot, ^^ [15:24] apw: yes, please, help would be welcome :) [15:33] apw: BTW here's what I get in the X log (i.e. it fails to open /dev/dri/card0): http://pastebin.ubuntu.com/530053/ === jjohansen is now known as jj-afk [17:10] jj-afk, smb if you're both about (i realize jj-afk is afk) then we can chat a bit whenever [17:10] smoser: i'm here [17:10] smb, ? [17:10] Got here [17:11] Is it 6pm utc ? [17:11] cool [17:11] no. not for another 50 minutes, but if we're here and available we can get it out of the way [17:11] sounds good [17:11] just got another cup of tea [17:12] ok. you want to just do it here ? [17:12] i see no reason not to, unless others are annoyed by it [17:12] Nah, they are mostly on holiday anyway. :) [17:12] ok [17:12] walking through http://paste.ubuntu.com/530110/ [17:13] bug 614853 [17:13] Launchpad bug 614853 in linux-ec2 (Ubuntu) (and 1 other project) "kernel panic divide error: 0000 [#1] SMP (affects: 2) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/614853 [17:13] jj-afk, it looks like we've got a functional patch there ? [17:13] right I think we have this one [17:13] ok. so you are who supplied the kernel, that wasn't apparent to me [17:14] but the question is whether the patch is SRUable [17:14] really ? [17:14] yeah sorry, I built that at UDS [17:14] http://launchpadlibrarian.net/58956370/lp614853.patch ? [17:14] kind of looks SRUable to me :) [17:14] hehe [17:14] we can try [17:14] Main question about sru ability is whether upstream takes it [17:14] upstream will not take it [17:15] have you asked? [17:15] well, this is quite common, so we need to get a fix in for it. [17:15] who do we/I have to beg ? [17:15] smb: no but there hasn't been any desire to pickup the 2.6.35 fix that its backported from [17:15] I think what jj-afk means is that it only covers things, but does not fix the main issue [17:16] smoser: we can send it to gregkh for the stable tree [17:16] but with it not going into newer kernels I doubt he will take it [17:16] jj-afk, Though he usually wil reject it when there is no upstream [17:16] right [17:16] yeah [17:16] i've not seen this on maverick (ie, newer kernels) [17:16] we can try to push it as an UBUNTU: SAUCE: [17:16] possibly still there, but we dont see it. only on linux-ec2. [17:17] We will probably need to see who is upstream for that bit and see whether it is acceptable as temp solution [17:17] until they find the real fix [17:17] smoser: the schedule is significantly different on newer but it still exists [17:17] well, ok. so will one of you push on that (and put these comments in the bug) ? [17:17] push on that == SRU [17:18] smoser: speaking of which can you bundle and upload the test kernel for me, I haven't been able to get my credentials to work [17:18] smoser: yes [17:19] jj-afk, where is that kernel ? [17:19] smb, and /me will coordinate [17:20] ok. jj-afk get me a link to your kernel builds for that and i'll get them uploaded [17:20] next bug [17:20] bug 651370 [17:20] Launchpad bug 651370 in linux (Ubuntu Maverick) (and 1 other project) "ec2 kernel crash invalid opcode 0000 [#1] (affects: 7) (dups: 1) (heat: 54)" [Medium,In progress] https://launchpad.net/bugs/651370 [17:20] I think were only waiting for it to be applied to maverick [17:20] i think we have that ready to go. [17:20] (disabling intel_idle for virtual) [17:20] so its in kernel teams tree ? [17:21] yes [17:21] not yet I believe [17:21] mostly due to uds and plumbers [17:21] hrmm, I got a merged mail [17:21] maybe it was only natty [17:21] and when would the next sru kernel come ? [17:21] I think it was for natty [17:21] yeah [17:21] ie, when can we have this in ? [17:21] but sent for both natty and maverick [17:21] for maverick, when can we have it in. [17:22] I ll chat with ogasawara about it [17:22] ok. thanks. [17:22] next bug [17:22] basically I could as well as the acks are there but I don't wan to mess [17:22] bug 567334 [17:22] Launchpad bug 567334 in linux (Ubuntu) (and 1 other project) "blocked tasks delay cloud-init for 240 seconds (affects: 2) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/567334 [17:23] looking around the wiki, but not finding: if I want a valid kernel version for a custom natty tree, how can i name it? 2.6.37-2.10userns1 doesn't work. [17:23] do either of you feel like that might actually be bug 666211 ? [17:23] Launchpad bug 666211 in linux (Ubuntu) "maverick on ec2 64bit ext4 deadlock (affects: 3) (heat: 28)" [High,Confirmed] https://launchpad.net/bugs/666211 [17:23] or that they're the same issue [17:23] hallyn, tried +userns1? [17:23] smoser, It could be [17:23] Not really sure about that, yet [17:24] ok, and we think we have that understood ? [17:24] smoser, Though while you said it woul dbe both I only saw lucid feedback i think [17:25] smb: no, i'd tried '-'. (but i think that actually failed for a different reason). '+' works - thanks! [17:25] yeah.. .i'm not sure , i'd have to look at logs again if i've seen it on maverick. [17:25] smoser: I'm actually don't think it is 666211 but that they are related [17:25] ok. and do we think we're moving towards a fix for them ? [17:26] something io related seems to be at least very slow [17:26] or deadlocked [17:26] well, yeah, i think deadlocked. nothing goes that slow. [17:26] but this is not so easy to understeand [17:26] smoser, why doesn't 2.6.37-2.10userns1 work, that fits a pattern i use comonly [17:27] hallyn, ^ apw, i think that was to him [17:27] jj-afk, i cirtainly did merge that patch for natty, i did not merge it anywhere [17:27] smoser, we got similar messages when lucid ext4 had writeback problems. Things would go away eventually but very very slowish [17:27] hallyn, yep i meant you [17:27] smb, ok. [17:27] ok. so well, i'll let you move on that one, primarily looking at bug 666211 [17:27] Launchpad bug 666211 in linux (Ubuntu) "maverick on ec2 64bit ext4 deadlock (affects: 3) (heat: 28)" [High,Confirmed] https://launchpad.net/bugs/666211 [17:28] and hoping that 651370 is related [17:28] I am looking at that but as said progress is slow [17:28] hallyn, can you tell me what goes wrong with that version number [17:28] smb, well, jay seems to be responding there, and it seems easily reproducible for him, so maybe we can get to a easy recreate scenario [17:29] hrmm, this one is going to be hard [17:29] dpepends on how complex the backend with the sql-db is [17:29] apw: sure, one sec [17:29] smb, right. [17:29] but hoepfully closer at least. [17:29] bug 613273 [17:29] Launchpad bug 613273 in linux (Ubuntu) "kernel panic on ec2 in system_call_fastpath (affects: 1) (heat: 37)" [Medium,Confirmed] https://launchpad.net/bugs/613273 [17:30] hallyn, i use lpNNNN commonly as a postfix without issues [17:30] the subject on that is bad, and i'm not sure all my occurences of that should have been considered to be it. [17:30] apw: solar flares, crack, or hasty mis-parsing of errors. in any case, it does work now [17:30] but we see panics. you have either of you have any thoughts on that ? [17:31] hallyn, good, it was hurting my head that it might not work [17:31] it must have all come down to my malformed email address in the trailer [17:31] but i was sure it first complained about version #... [17:31] smoser, I was thinking whether this is still true. cause the last comment was at least a bit older [17:31] (guess not) [17:32] smb, i think i've seen it recently... i'll check logs 2010-09-16 was last comment, so that wasn't to long ago [17:33] jj-afk, knowing the xen code a bit better, would this give some clue to you? [17:33] Sort of all I would see it some interrupt handler failing which is the quite obvious [17:33] i'll try to attach more console logs for refernece. [17:33] their was something about irqs, I am trying to remember [17:34] I remember futzing with panics on fastpaths before [17:34] jj-afk, The lost irq problem? [17:34] no, I don't think so [17:34] I think it was machine specific [17:35] ie it would happen on some machines and not others, kind of like the intel_idle [17:35] I need to spend some time digging, and trying to recall [17:35] i'll try to get all logs i have on that, that will give more info for you to look at. [17:35] and then will ping jj-afk for some help (follow the bug) [17:36] jj-afk, Agreed, hm. This at least seems to be related with some notify call [17:36] bug 634487 [17:36] Launchpad bug 634487 in sun-java6 (Ubuntu) (and 3 other projects) "t1.micro instance hangs when installing sun java (affects: 20) (dups: 1) (heat: 154)" [Undecided,New] https://launchpad.net/bugs/634487 [17:36] I think there were at least some useful comments in the bug [17:36] smb, jj-afk you're more than welcome (encouraged) to keep thinking about this, i'm just trying to get jj-afk back to afk and smb to his evening quicker. [17:37] smb, right. for the java b ug, there is some help from the amazon engineers. [17:37] also, the fedora and amazon linux AMIs do not have this issue [17:37] By someone who apparently understands a bit more of the xen memory management than /me [17:37] right this one is weird, we just need to understand it more [17:37] you think looking at amazon kernel source would be helpful ? [17:38] yes [17:38] or you think its just likely too different to add much value [17:38] ok [17:38] configs too [17:38] well, please try that... [17:38] hehe, yes we will [17:38] jj-afk, you need to show me next week how to do that [17:38] smb: okay [17:39] jj-afk, launch an ec2 ami from http://aws.amazon.com/amazon-linux-ami/ [17:39] right [17:39] then, there is some command you can run to get source... it will give you a source rpm [17:40] i forget hwat command , but its in their docs [17:40] yep its just remembering the command :) [17:40] bug 614853 [17:40] Launchpad bug 614853 in linux-ec2 (Ubuntu) (and 1 other project) "kernel panic divide error: 0000 [#1] SMP (affects: 2) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/614853 [17:40] deja vu? [17:40] http://aws.amazon.com/ec2/faqs/#Can_I_view_the_source_code_to_the_Amazon_Linux_AMI [17:40] deja vu indeed [17:41] bug 586530 [17:41] Launchpad bug 586530 in linux-ec2 (Ubuntu) "kernel BUG at /build/buildd/linux-ec2-2.6.32/fs/ext4/inode.c:1852! (affects: 1) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/586530 [17:41] That seems so old that it could already be resolved [17:42] The upstream bug was never really closed due to the reporter there vanishing [17:42] But since then a huge pile of ext4 updates went into lucid [17:42] yea... that is what concerned me, is that there seemed a legit upstream bug [17:42] ok. [17:42] i think we close that one as incomplete for now [17:42] So we probably should close it with a omment [17:43] yeah, I would do that [17:43] well, 2.6.32-305-ec2 is kernel version shown [17:43] This was roughly 2.6.32.11 level [17:43] were at .25 nowish [17:43] ok. i'll trust you know more on this. i've never seen this one... so, incomplete and move on [17:44] bug 660163 [17:44] Launchpad bug 660163 in linux (Ubuntu) "ec2 kernel hang on XENBUS: Waiting for devices to initialize (affects: 1) (heat: 152)" [Low,New] https://launchpad.net/bugs/660163 [17:44] right this one is I believe a lost interrupt [17:45] I am not sure what to say on this one other than strange. ah ok [17:45] might be an explanateion [17:45] and do we have fix for that? [17:45] i thought jj-afk had patches or ideas. [17:45] I was wondering whether the dom0 xenbus process could be at fault [17:45] hrmm, there was a patch that went into stable that I thought would help [17:46] smb: possible [17:46] the xen devices are split into front and backend and communicate over the xen bus [17:47] and iirc that correctly that was some user-space process in dom0? [17:47] smoser, how often did you see this? [17:47] hrmm, no I think its kernel [17:47] i've never seen this one [17:47] but i do not hit network io hard [17:47] so can one of you at least try to freshen your memory on that one (reading the links posted) and see if you think it might be reasonable to close at this point as "maybe fixed" [17:47] that is the problem its rare [17:48] i think maybe i did see it once [17:48] smoser, Oh, I assumed as you reported it [17:48] smoser: yeah, I'll look again since I was chasing it and thought the patch would come in from stable [17:48] no, if i had reported it it would have kernel version info :) [17:48] jj-afk, thanks. [17:48] the big problem again is verifying [17:49] * smb wonders whether he looks at the right bug [17:49] smb: XENBUS: ... [17:49] seeing a reported by scott moser and not any links [17:49] oops [17:50] i was confusing with https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/648721 [17:50] Launchpad bug 648721 in linux-ec2 (Ubuntu) "page allocation failure on machines under heavy network load (affects: 1) (heat: 77)" [Undecided,New] [17:50] Oh that one I would say is not a bug [17:50] more of a mis-configuration for much network traffic [17:50] sort of [17:51] i've only seen the XENBUS once, maybe twice ever , and i think once. [17:51] right that is how I was leaning too [17:51] hm.. [17:51] so what does that mean ? [17:51] jj-afk, I wonder whether the min_free_pages should be modified for instances a bit [17:52] user error ? [17:52] basically allocating order 5 is guarenteed to fail at some point [17:52] smb: min free pages can be tweaked but that won't help an order 5 allocation when there isn't 32 contiguous pages [17:53] That is true. [17:53] Question is why a network thing needs such a huge area [17:53] relatively [17:53] is that for firmware ? [17:53] apw: no, its a nf hook [17:53] apw, no maybe nf [17:53] netfilter [17:54] ? [17:54] yep [17:54] ok. so one or both of you update that bug please [17:54] bug 669496 [17:54] Launchpad bug 669496 in linux (Ubuntu) "natty kernel fails to mount root on ec2 (affects: 1) (heat: 437)" [Critical,Confirmed] https://launchpad.net/bugs/669496 [17:55] works [17:55] ? [17:55] really ? [17:55] jj-afk, i try to understand it better and then update tomorry (previous bug) [17:55] yep [17:55] for me too [17:55] ami ? [17:55] at least as described by installing current natty in maverick [17:56] used the first one of the dailies showing up... [17:56] oh actually I wrote it in the bug I think? [17:56] right, and i tried to reproduce that and it failed for me [17:56] or not? [17:56] smoser: I used the natty kernel on maverick daily last week and smb booted it today [17:56] i dont come back up at all (using t1.micro though) [17:56] and its not user space in natty [17:56] see my most recent comments in that bug [17:56] I used a m1.large [17:57] ami-00877069 [17:57] right. so i did that with t1.micro 3 times this moring and it never came back up. [17:57] (and no console messages either... our lovely friend for that) [17:58] smoser: okay we will give it another round of testing [17:58] We can trie again with a t1.micro I guess [17:58] yep [17:58] but look at the console logs [17:58] the volume gets mounte dread-write [17:58] and cloud-init even does some work [17:58] but then bad things happen [17:58] and kernel remounts ro [17:58] because of io error [17:58] that much is understandable [17:59] but not really why those io errors happen [17:59] right... so i dont understand how you could suggest that that is user space or plubming [17:59] nothing should cause that [17:59] because it booted for me [17:59] booted once [17:59] and I was tinking of something (like udev) in userspace needing to adapt the size of the blkdev [17:59] maybe check that natty isn't runing ureadahead. [18:00] as it seems to change from 0 to its actual size somewhere [18:00] ... [18:00] but the poitn at which it goes bad is *so* far up in the boot process [18:00] cloud-init runs at mounted=/ and network up [18:00] so much is already functional at that point [18:01] i just would have thought that any udev issues related to the above would have been past [18:02] Lacking the exact details if the init i sort of assumed things went wrong roughly where we pivot over to the real root device [18:02] yeah... i had thought htat too [18:02] but its much further up , now seeing the cloud-init messages there. [18:03] the root device was functional, and lots of things happened before it goes bad [18:03] hmm... [18:03] but then i see [18:04] "An error occurred while mounting / [18:04] Press S to skip mounting or M for manual recovery [18:04] " [18:04] which i would htink is coming from mountall [18:04] Hm, ok. Sadly we only see half of the picture [18:04] i'll poke ther e abit also [18:04] i'll try turning on mountall debug [18:04] It could be also from remounting / rw [18:04] after the fs ckeck step [18:04] and note, this occurs both on instance store and on ebs [18:05] But press s sounds like mountall [18:05] which are different devices in the back [18:05] ok. [18:06] well, smb jj-afk thanks for your help. [18:06] Ok, so I'll poke around ext4 deadlock, the order 5 allocation and the natty kernel on ec2 more tomoorow [18:06] i'll poke at the natty early next week from the user sapce side. [18:06] i'll send you all my notes too. [18:07] alright I'm out of here for the weekend [18:07] if there is anything pressing send me a mail it will be checked a few times [18:07] jj-afk, You should formulate that more like tim [18:07] ;-) [18:07] lol [18:23] ogasawara, are you around [18:23] smb: yep [18:24] ogasawara, Just wanted to ask about one sru for maverick (Disable intel_idle). I think we got enough acks for it and it only affects the virtual config. [18:24] I believe Brad and Steve are not around today and tomorrow [18:25] smb: cool. yah, bjf has been handling Maverick SRU's and tree maintenance [18:25] So just wanted to check with you whether i just can slip it into the tree tomorrow [18:25] smb: I'd be cool with that [18:25] smb: and I'm sure bjf[afk] wouldn't mind [18:25] And hopefully I won't get into the way of the new process [18:26] smb: ahhh right I forgot about the mew process and possibly reverting patches [18:26] smb: I think sconklin was planning on reverting any unverified patches on Monday [18:27] yes, and we don't know the new process enough ourselves to know how that exactly goes. [18:27] probably I should wait then till monday [18:27] smb: so he actually might not want new patches applied. I recall him mentioning having a type of merge window for new SRU patches. [18:27] and write myself an email to make me remember [18:27] smb: probably a good idea if it can wait till Monday [18:28] Depends on whom you ask as always ;) But I would say yes, it is not super urgent [18:29] smb: yah, I've got some Lucid patches I want to apply but am waiting for the green light to push. [18:30] ogasawara, yup, feels safer that way [18:30] ogasawara, I'll be writing reminder mail to all of us. So we all not forget. :) [18:31] smb: sounds good [18:31] * apw suspects that this new process is going to exacerbate the need for a next branch for stuff thats ready for the next sru cycle [18:31] apw, could as well be done by modifying a proposed branch and merge it back [18:31] But that is highly depending on personal taste [18:31] iow, not mine to decide. :-O [18:32] err meant :-P [18:32] bloody o being too close to p [18:32] yeah i suspect a next branch is easier process wise. as we can automate the 'commited' state on rebasing it ... but hey [18:33] * smb shudders a bit when hearing rebasing [18:34] I really started to like rebasing in Maverick actually, but I think that was more because I was lazy and liked how I could easily edit/drop patches [18:35] smb, only next never master, so ust the pending stuff === bjf[afk] is now known as bjf [18:35] so next is only a parking place for things with acks [18:36] I guess it is really nice when you are the only one mangling the tree. It feels (just a feeling) a bit dirty for a released tree as it looses the info about what happened [18:36] apw, Oh, ok. Sounds much better [18:36] * smb relaxes [18:37] ogasawara, rebasing is a bit like teleporting trees. You are there now but you have no idea how you get there. [18:38] smb, it's still not clear to me how the process will work (i have a batch of upstream stable sitting in my personal repo ready to push), i think after monday's revert run we should be able to get your intel idle in [18:38] apw, Reminds me, you see any potter fans queuing up to your place? :) I beleive it was today [18:38] right, and only the pending patches which are currently not even seen as they are not anywhere [18:38] smb heh not as yet [18:38] smb, I can add the idle patch to my tree as well if that would help [18:39] bjf, Sounds cool. If you don't mind i just send that nag mail anyway. Given the state of post-uds memory of mine I forget what I was thinking till then === bjf is now known as bjf[afk] [18:45] Anyone have a recommendation for how to isolate this problem? VV [18:45] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422 [18:45] Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New] [18:45] gober idid you get that reproducible again ? [18:46] absolutely [18:46] I went back and made sure I started fresh on 10.04.1 [18:46] (I had accidentally started with an old lucid alpha iso) [18:47] booting off the latest generic kernel fails [18:47] generic-pae does not [18:48] as I noted udevadm segfaults about half the time I run it when in the initramfs console [18:49] fwiw, I did a i386 generic install just yesterday and got a booted 2.6.32-25-generic [18:49] I compared the initramfses between the two versions and they match ... all but the kmodules of course [18:49] on VMware ESX 4.1? [18:49] no native [18:49] works fine native [18:49] AFAIK [18:50] hm, something stepping on the toes of vmware...? [18:51] _shrug_ I guess [18:51] it also does not happen on VMware ESX 4.0 [18:52] I had thought of two possible ways for me to narrow it down [18:52] I had considered either rebuilding the kernel eliminating the new patches one by one [18:52] or, comparing the configuration differences between the generic and generic-pae kernels [18:53] gober that'd be a bisect [18:53] apw, thanks, I am somewhat new at this level [18:54] is there a handy way to do that? [18:55] git bisect does the trick [18:55] ok, thanks [19:16] is there like a candidate kernel for the next release in a PPA somewhere I can try? [19:17] * cking yawns [19:21] ts [19:22] godber, There is http://launchpad.net/~kernel.ppa [19:22] err kernel-ppa [19:22] but that is the same release. There is also the mainline kernels [19:23] http://kernel.ubuntu.com/~kernel-ppa/mainline/ [19:48] If I get this isolated down to a specific patch, whats the odds of getting the attention of someone who knows how to fix it? [21:00] * ogasawara lunch === ivoks is now known as ivoks-afk [22:43] Any help on getting a panic backtrace out of Ubuntu please? I've tried CrashdumpRecipe but can't seem to get the machine to reboot after panic. I've tried sysctl -w kernel.panic=15 but that didn't seem to work [23:32]