=== bjf is now known as bjf[afk]
smbcking, \o09:05
* cking waves o/09:05
cooloneysmb and cking moring *.eu09:06
smbHi cooloney 09:06
ikepanhcgood morning .eu \o/09:09
smbikepanhc, morning .asia :)09:09
abogani2morning all!09:15
lagcooloney: Has anyone managed to get HDMI on the Panda working yet?09:15
cooloneylag: oh, i don't think so.09:15
lagDespite placing vram=8M omapfb.vram=0:8M on the Kernel cmdline I still get "omapfb omapfb: failed to allocate framebuffer"09:15
cooloneysebjan told me he has no HDMI device. 09:16
lagWho were we speaking to the other day?09:17
lagWas it Rob?09:17
lagAnd someone else?09:17
cooloneyi think Nicolas?09:17
cooloneyi didn't meet Rob before09:17
lagWhat time do they normally turn up?09:17
lifelessrob who ? :)09:18
cooloneyi think they should be on line soon, but not sure about that09:18
lifeless<- a Rob09:18
cooloneylag: why not mail out, please cc me, hehe09:18
lagcooloney: I don't know anyone's addresses09:18
lagCan you mail me them?09:19
cooloneylag: oh, forget that. no problem,09:19
TeTeTsmb: I'll visit our customer this week, hope we get some testing done with your lbm for x201 wwan09:19
cooloneylag: just wanna confirm, is this bug #592295?09:20
ubot2Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/59229509:20
smbTeTeT, That would be good. To see whether it is working or not. hard to tell without the hw. :)09:20
lagcooloney: It was RobClark and prpplague09:21
lagChatting with ogra and I09:21
TeTeTsmb: agreed :)09:21
cooloneylag: ok, i don't have robclark's email. i will mail to sebjan and nico09:23
lagIs prpplague == nico?09:24
cooloneylag: no09:25
cooloneylag: it should be nedc or sth.09:26
cooloneylag: and how do you think sebjan's solution in the LP of this bug?09:27
cooloneylag: it looks like a workaround to me09:28
lagcooloney: All it does it stops the message from printing out and swapping the console09:31
lagcooloney: I already did that with a 'static int'09:31
lagcooloney: Hence, I haven't used sebjan's 'solution'09:32
cooloneylag: right, and you still don't get anything on you HDMI display. 09:32
cooloneylag: yeah, understand09:32
lagcooloney: I am currently building the very latest ti-omap4 branch09:38
lagI'll let you know if anything changes regarding this bug09:38
cooloneylag: thanks man. hehe09:39
lagNo worries 09:41
ogralag, it needs to be vram=32M and dont set omapfb.vram at all10:37
ogracooloney, prpplague's nick is prpplague ;)10:39
lagogra: How did you find that out?10:40
ogralag, trial and error :)10:40
ograi know we have three output devices enabled in omap4, and i know each needs at least 8M10:40
lagWell done10:41
cooloneyyeah, so for the HDMI issue, we maybe can fix it in videoram code10:41
lagWhat console is it?10:44
lagogra: -^10:45
ogralag, ??10:47
lagHDMI still doesn't work for me10:47
ogralag, you mean the kernel cmdline ? 10:47
ograroot=/dev/mmcblk0p2 rootwait ro mem=463M console=ttyO2,115200n8 console=tty0 vram=32M10:47
lagAre you using a full desktop?10:47
ograthats what i used to get screen output10:47
lagI'll try it10:48
ograno, just tty atm and the rootfs is screwed 10:48
lagThat's completely different to mine10:48
lagI have a working rootfs if you'd like it?10:48
ograit should even work without setting conole options10:48
ogranaj, i'm working on the images anyway 10:48
ograi have plenty of rootfses around just not on that SD10:48
lagogra: http://paste.ubuntu.com/456301/10:50
ograare you using a plain HDMI monitor (no DVI or adapters)10:51
lagHDMI -> HDMI10:52
jk-smb: could you take a look at comment 28 on https://bugs.launchpad.net/oem-priority/+bug/557742 ? looks like a symbol versioning issue between kernel modules & l-b-m12:05
ubot2Launchpad bug 557742 in linux-backports-modules-2.6.32 (Ubuntu) (and 2 other projects) "Lenovo Thinkpad X201 & T410 & W510 not autoswitching to input mic jack in 10.04 (affects: 9) (dups: 1) (heat: 70)" [Undecided,New]12:05
jk-the symbol version magic in l-b-m shouldn12:07
jk-'t be different, right?12:08
=== rsalveti_ is now known as rsalveti
smbjk-, Let me check. They should not be different12:55
smbjk-, But with thinkpad's and alsa there is an unsolved problem with thinkpad-acpi providing a mixer and alsa from lbm having different alsa versions12:56
=== cnd` is now known as cnd
tgardnerccheney, http://kernel.ubuntu.com/~rtg/mainline/94b8f28fa6ffd56ba13b88b6e8d98c7b540b61de-maverick/linux-image-2.6.35-6-server_2.6.35-6.7_amd64.deb14:07
ccheneytgardner, ok will take a look in a min14:11
tgardnerccheney, this is the upstream response. I updated the bug14:12
ccheneybooting into it now14:15
ccheneytgardner, its looking good so far14:18
=== lifeless_ is now known as lifeless
tgardnerccheney, done yet?14:49
ccheneytgardner, it passed the register image test, so i think its fixed14:49
ccheneywhen i tried to run an image it didn't work but i'm still looking into that14:50
tgardnerccheney, k14:50
ccheneyit passed the full 10 loop test14:50
ccheneytgardner, works14:57
ccheneytgardner, just needed to reboot my node apparently14:57
tgardnerccheney, cool. I'll bug ttx about whether he wants a new kernel image. it'll completely piss off ogasawara.14:58
ccheneyheh ok14:58
ccheneyttx, ^ :-)14:58
* ttx doesn't want to piss off ogasawara :)14:58
tgardnerttx, can you live with a day-1 kernel update if she uploads right after A2 freeze islifted?14:59
tgardneris lifted*14:59
ttxtgardner: we would need to have a PPA with a kernel to allow some testing of eucalyptus during ISO testing14:59
tgardnerttx, thas easy enough15:00
ttxtgardner: I just don't want UEC untested on A2, if the test is: "you will hit that one, just do this to workaround it, then continue your testing" I'm ok with it15:00
tgardnerttx, ok, then lemme get you a PPA kernel building.15:00
ttx(also allows to validate the kernel upgrade, fwiw)15:00
ttxkirkland: does that work for you  ? ^^15:01
cndapw, ogasawara: it looks like amd64 ddebs aren't getting published: http://ddebs.ubuntu.com/pool/main/l/linux/15:10
=== sconklin-gone is now known as sconklin
Keybukapw: thanks for the init cmdline patch; it works perfectly15:19
Keybuktgardner: you remember the iwl3945 problems I was having?15:20
* tgardner notes that apw is on vacation this week15:20
tgardnerKeybuk, sort of15:20
Keybuktgardner: seems it's definitely an upstream kernel issue, there's traffic on LKML about others experiencing it15:21
tgardnerKeybuk, 'iwlwifi: cancel scan watchdog in iwl_bg_abort_scan' just went into Linus' tree15:21
tgardneras well as 'iwlwifi: serialize station management actions'15:22
tgardnerKeybuk, actually, there are a couple of i3945 specific fixes.15:23
Keybukyeah the updates pulled in seem to be the ones people have tested and say fixes it for them15:24
tgardnerKeybuk, so, we''ll get 'em as soon as Linus declares -rc415:24
tgardnerKeybuk, you could always apply just the iwlwifi updates to an -rc3 Maverick kernel to see if it fixes your problems.15:26
Keybukyeah will try that15:28
Keybukthe workaround suggested works for me too (ifconfig wlan0 promisc)15:28
ograso with the init comdline patch, do i need to use the vars in a literal way or are they capitalized by default ? 15:32
ograi.e. do i have root= as root= available in initramfs scripts ? or do i need to check for ROOT ?15:32
ogra(i'm assuming the initramfs init has the vars globally available as well as upstart does)15:33
=== manjo` is now known as manjo
Keybukogra: the patch does not affect such things15:35
Keybukall the patch changes is that, previously, the kernel would only pass unknown arguments to init (splash, frobmybar, etc.)15:35
ograwhat does it affect then ? i thought the vars get exported to the init environment15:36
Keybukwith the patch, the kernel now passes all arguments to init, including those it knew what to do with15:36
Keybukbasically, in the default install, it means that instead of just getting "splash" on its command-line, init now gets "ro quiet splash"15:36
ograah, so i still need to parse the cmdline if i want to look for root= in an initramfs script ? 15:36
Keybukjust look at $root15:36
ograah, sweet 15:36
ograthats what i'm looking for 15:36
Keybukanything with an = in has always, and is still, placed as an envvar in init's environment15:37
Keybukthat is unchanged15:37
Keybuk(indeed, much of the /proc/cmdline parsing in initramfs is entirely pointless for this reason)15:37
ograhmm, i thought that depended on an export in the /init script 15:37
ograok, great15:37
Keybukthe initramfs /init script is largely wrong, it makes a $ROOT by parsing /proc/cmdline15:37
Keybukwhen $root was always there all along15:37
ograright, i mistook it and used the same parsing routine in my initramfs scripts15:38
ograwhich apparently is a waste :)15:38
ogragood to know15:38
ograi guess there are a lot of scripts that can drop such routines now ... the framebuffer handling parses /proc/cmdline too iirc15:39
ograogra@osiris:~/Devel/branches/livecd-rootfs/livecd-rootfs-1.125$ grep -r cmdline /usr/share/initramfs-tools/scripts/*|wc -l15:40
Keybuk"now" is irrelevant, as I said15:41
Keybukthe patch doesn't change whether or not you need those routiens15:41
Keybukyou've *never* really needed them for the = ones15:41
Keybukbut you do currently need them to parse out keywords15:41
ograyeah, but there are a bunch that still parse the = ones 15:42
=== bjf[afk] is now known as bjf
ograbrltty, bootchart, blacklist and framebuffer definately do15:44
ogracnd, its pointelss to aks for imx51 or dove bugs to be confirmed fixed in maverick ... we should rather drop these packages from the archive 15:47
amitkogra: cnd: I don't see any imx51/dove branches. What packages are being created?15:49
cndamitk: ogra is talking about bug 42376715:49
ubot2Launchpad bug 423767 in linux-fsl-imx51 (Ubuntu Karmic) (and 3 other projects) "please enable rt2800usb and disable rt3070sta in the imx51 kernel (affects: 1) (heat: 26)" [Low,Fix released] https://launchpad.net/bugs/42376715:49
ograamitk, no packages, i just got bugmail for an ancient bug where cnd asked to check if its fixed in maverick15:49
cndso I'll just close it up as won't fix15:50
ograamitk, we dont remove binaries from the archive without someone asking for it, they still idle around in the archive atm15:50
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - June-29 - 17:00 UTC
ogracnd, well, might be an SRU thing, not sure15:50
ogracnd, though for that specific one its likely something to just close, i doubt anyone will actually put time into it15:51
cndI'm just trying to clear out crufty linux-firmware bugs :)15:51
ograyeah, i got that watching -devel :)15:52
ogasawaratgardner: for the UEC bug, you're already handling pushing the fix to a PPA correct?16:06
ogasawaratgardner: I'll get the kernel ready for upload and coordinate with the release team for the 0-day upload16:06
tgardnerogasawara, yep, I'll feed you a pull request presently as well.16:07
ogasawaratgardner: sweet16:07
tgardnerogasawara, Changli says Jens Axobe hasn't acked it yet, so I think we'll carry it as an Upstream patch until it gets resolved.16:08
ogasawaratgardner: ack16:08
ogasawaracnd: not sure why the amd64 ddebs aren't getting published.  I'm not familiar with what magic is involved but I'm guessing pitti might?16:11
tgardnerogasawara, its an archive admin issue16:18
ogasawaratgardner: so pitti would be a good person to nudge16:19
tgardnerogasawara, indeed, he is always a good person to nudge16:19
ogasawaracnd: I'll ping him about it in #ubuntu-devel16:21
cndogasawara: thanks!16:22
ogasawaraRAOF: just saw your common bug tag email for X and kernel.  I definitely agree we should converge on a common set of tags.16:25
ogasawaraRAOF: But ideally I'd like to wait to have this conversation when JFo and apw are around (both are on holiday this week).16:25
ckinganother day, another BIOS check16:34
* cking reboots16:41
=== kamal-away is now known as kamal
ogasawaracnd: pitti will check on the ddeb issue tomorrow morning17:23
ogasawaraok dudes, we've got 3 remaining Alpha2 work items.  I just want to get a status check if they'll be done by thurs or if I should bump them to Alaph3.17:27
ogasawarajjohansen: "Refresh Xen patchset and get xen version of EC2 kernel working in Maverick".  I assume you're still working that.  Should I bump to A3?17:28
ogasawaramanjo: "blacklist old firewire stack & enable new stack", seems that's still in progress?  Should I bump it to A3?17:28
jjohansenogasawara: yeah, I thought I had done that already17:28
ogasawarajjohansen: oh, if it's done, I can just close it17:28
jjohansenogasawara: no, I meant moved to alpha317:29
jjohansenwhen I talked to tim and andy last week17:29
jjohansenhrmm, must not have saved17:29
ogasawarajjohansen: hrm, I'll double check it and if it's not moved to A3 I'll move it17:29
ogasawaracking: "Investigate situation with Intel graphics drivers on EFI".  Think you'll squeeze this in by Thurs or should I bump this to Alpha3?17:31
ckingogasawara, I'm discussing this with Intel. Still open - I got a response today, I need to follow it up though. Maybe A3 is better17:34
ogasawaracking: ok cool, I'll move it17:34
jjohansenogasawara: oh, I have to thursday for kernel alpha2 items?  I should have it done by then, if so should I mark it DONE and move it back17:34
ogasawarajjohansen: yah, if you get it done by Thurs, just move it back and mark it DONE.17:35
jjohansenokay will do17:35
tgardnerttx, https://bugs.edge.launchpad.net/eucalyptus/+bug/588861/comments/38 (when its done building)17:47
ubot2Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress]17:47
ogasawaratgardner, ttx:  I'm just waiting for armel to finish building so I can get the abi and start the next release.  Will apply the patch and have a kernel ready for the 0-day upload after that.17:48
manjoogasawara, I submitted the patch to ubuntu kenel mailing list 17:55
manjoogasawara, tgardner supposed to pick it up, and pgraner was going to submit more test results 17:56
ogasawaramanjo: right, but it doesn't look to be packaged and uploaded.  And since we're on the verge of the A2 freeze I assume it'll have to wait till A3.17:56
manjoogasawara, ok. tgardner any chance you will pick this one up for A3 ? 17:57
pgranermanjo: I can't get it working17:58
tgardnermanjo, I've sent Keybuk a review request. Lemme find it.17:58
pgranermanjo: none of the fw cards I have are detected under maverick, they are on lucidc17:58
Keybuktgardner: ah, well nagged17:59
Keybukfwiw, I'm maintaining module-init-tools using the new standard bzr model17:59
Keybukbzr branch lp:ubuntu/module-init-tools17:59
Keybukwe don't use Vcs-Bzr for those17:59
pgranermanjo: I just got a lap top (StinkPad X410) that maverick does see the fw card so I'll test today17:59
tgardnerKeybuk, I use bzr so seldom that its a half day learning curve each time17:59
manjopgraner, ok 18:00
Keybuktgardner: I would tend to NAK that patch18:00
Keybukcan you not make acct=1 the default in the nf_conntrack module?18:00
pgranermanjo: whats the link to the fw testing page again?18:01
tgardnerKeybuk, upstream is gonna make it 018:01
Keybukyes, so we should patch that to be 1 in our kernel if we want that to be the default18:01
tgardnerKeybuk, well, I don't know that we do, but how is that related to firewire ?18:02
Keybuktgardner: ? firewire?18:02
KeybukI'm looking at your NF_CT_ACCT mail18:02
Keybukwhich is the most recent thing you mailed me to review18:02
tgardnerthats the review request I was referring to18:02
manjopgraner, just a sec 18:02
tgardnerKeybuk, hmm, lemme get my shit sorted out18:02
KeybukI don't have anything about firewire18:03
tgardnerkeybugok, I remember now. I haven't written the firewire stack blacklist patch yet. I was waiting on results from pgraner. the  NF_CT_ACCT patch is a different issue, and may well be moot at this point.18:04
manjopgraner, https://wiki.ubuntu.com/Kernel/SwitchFirewireStack18:04
Keybukfirewire is just a matter of switching stacks, no?18:04
tgardnerKeybuk, yes18:05
Keybukunblacklist the new one, blacklist the old one18:05
Keybukand pick a date that we stop building the old one18:05
manjotgardner, won't the patch I sent to ubuntu kernel list work ? it was a bzr patch?18:06
manjoKeybuk, we will build both ... just black list the old modules 18:06
Keybukright, and we should pick a day where we stop building the old one and drop support for it18:07
Keybuke.g. after 12.0418:07
manjoif we don't see problems in maverick we could drop it altogether in M+1 18:08
Keybuknot sure whether or not we need udev rules for it18:09
maks_lol on Ubuntu for having old firwire :P18:09
maks_Keybuk: you had the tradition to hire the wrong linux-2.6 hackers :)18:10
Keybukmaks_: I didn't hire any hackers18:10
maks_well i remeber the big press release when BenC got hired18:11
maks_and the Ubutntu kernel put on kernel.org18:11
manjoKeybuk, https://ieee1394.wiki.kernel.org/index.php/Juju_Migration18:11
KeybukBen left before the new firewire stack was even written18:11
maks_no i had been in the channel when he loled on us switching18:11
maks_and leaving his rotten code.18:11
Keybukmanjo: what I mean is that the rules already seem to be in upstream udev18:12
manjoKeybuk, ack18:12
pgranermanjo: ok, video works with both dvgrab & kino, will check the sbp2 stuff in a bit18:12
manjopgraner, ack... thanks18:13
maks_the security implications of the old dma stack is fun18:13
maks_makes it easy to poke anywhere.18:13
Keybukwhich is why we always locked it down to root-only18:14
manjomaks_, and your point is ? 18:15
maks_manjo: fun to see that you have an LTS with the old stack18:16
maks_although your userspace back then already supported juju.18:16
Keybukit's always easier to support an older known stack for a long time than a shiny new one18:17
Keybukthe new one was always there and was a simple config change for anyone to switch for it18:17
manjomaks_, next LTS will have the new stack ... if that makes you happy18:17
manjomaks_, like Keybuk said 18:18
ckingmanjo, you're back from your travels?!18:44
manjocking, yes 18:45
manjocking, back and pretty tired 18:45
ckingmuch appreciate you going on the trip.  I'd like to catch up and get some feedback sometime, but when you're ready18:46
manjocking, yep we can mumble tomorrow ? 18:47
ckingmanjo, yeah, good plan. I need to go in a mo, so tomorrow is good for me.18:48
=== maco2 is now known as maco
=== emma_ is now known as emma
jcastroI bought a new laptop and the nic only works in maverick kernels, I suspect at some point the driver goes into lbm, when we do LTS point releases do those drivers end up updated on the media?19:14
tgardnerjcastro, compat-wireless in LBM shod be the solution. Those drivers will not show up i a point release19:15
jcastrook so I suppose that means this laptop won't be kickstartable for me with lucid19:16
jcastroare normal NIC drivers in compat-wireless too?19:16
tgardnerjcastro, there are a few, but its mostly wireless drivers19:16
* tgardner lunches19:22
jjohansen-> Lunch19:42
=== mjg59` is now known as mjg59
* ogasawara lunch20:51
=== soren_ is now known as soren
Frode_Haugsgjerdhey, i have an issue with xchi on my brand new hp 8540p, when i connect my nokia n900, syslog quicly grows with messages like this: "WARN urb submitted to disabled ep" 22:16
Frode_Haugsgjerdi have of course searched the fine web, but only found the kernel code that emits this message22:17
Frode_Haugsgjerdok so i guess my question is, has anyone heard of this before?22:26
keesogasawara: will you be able to revert f1befe71fa7a79ab733011b045639d8d809924ad for the next kernel (bug 597075)?22:41
ubot2Launchpad bug 597075 in linux (Ubuntu) (and 1 other project) "2.6.35 hangs at boot due to regression in i915 or intel_agp (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/59707522:41
ogasawarakees: the only fear I have with reverting is it could then cause regressions for others22:45
ogasawarakees: has there been any progress with upstream?22:46
ogasawarakees: I saw the comments to the upstream bug report, but didn't seemed to present a solution, just more questions22:46
keesogasawara: they have no solution.22:46
keesogasawara: and reverting it would be the same as lucid's behavior.22:46
ogasawarakees: I'm still debating :)  your point is valid that it does bring us back to lucid's behavior and you can at least boot.23:04
ogasawarakees: I've got a 0-day Alpha2 kernel upload that's gonna take precedent and won't contain the reverted patch23:05
ogasawarakees: so at best I'd like to maybe wait till we rebase to -rc4 and then revert if there's no better solution by then23:05
=== sconklin is now known as sconklin-gone

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