[01:12] <shtylman> anyone able to look into bug #398059 yet? ... major problem imho
[01:12] <ubot3> Malone bug 398059 in linux "system does not boot due to device-mapper error" [Undecided,Confirmed] https://launchpad.net/bugs/398059
[08:15] <cafetiere> squeak
[09:49] <dholbach> hola!
[09:49] <dholbach> who'd be interested in talking a bit about kernel development at Ubuntu Developer Week?
[09:50] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some open slots
[10:25] <cjwatson> I gather reintegrating iscsitarget is assigned to manjo; anyone know how far he's got with it?
[10:26] <cjwatson> the iscsi userspace stuff is on my list for karmic and I'd quite like to have a target to test with :)
[10:31] <smb> cjwatson, I believe he said the projects page code was rather unchanged and the server team had shown a general tendency/interest of getting this module done a dkms package. But I cannot remember any final status...
[10:31] <smb> cafetiere, you? ^
[10:32] <cafetiere> smb that is my memory also
[10:32]  * cafetiere is unsure if its enabled or not as is
[10:33] <cafetiere> cjwatson, will hastle him today to find out status for you
[10:37] <cjwatson> thanks
[10:37] <cjwatson> I tried the existing iscsitarget-source with module-assistant, but it failed to compile so apparently needs some update work
[10:39] <smb> likely the removal of direct access to structs did not help. Yeah, we try to pry it of manjo later
[11:38] <lool> Hey folks
[11:38] <lool> Is there a tree from which I can build a mx51 .31 kernel?   :-)
[11:38] <lool> Or even a binary kernel would probably be good enough for testing
[11:47] <stewart> so, i don't know if this is actually a ubuntu kernel specific issue, but have only seen it on ubuntu. process listening to tcp port restarts (as part of that closes sockets). client program is trying to connect. listener has restarted and is in a loop trying to bind to the server port again, but client application has an open socket to the server port (even though the previous server has gone away) and netstat -t tcp -l -p shows
[11:47] <stewart> : 
[11:47] <stewart> tcp 0 0 *:12500 *:* LISTEN -
[11:47] <stewart> tcp6 0 0 [::]:12500 [::]:* LISTEN -
[11:47] <stewart> i.e. no process
[11:47] <stewart> and client is stuck in poll()
[11:47] <stewart> no idea what is going on. does anybody have an idea what could cause the above?
[11:55] <hyperair> huh i've never seen anything of that sort before
[11:56] <hyperair> you'd think that web servers would have an issue like this when restarting in ubuntu if this was reproducible, wouldn't you?
[12:41] <stewart> hyperair: it's a pretty specialised case...
[12:41] <stewart> after a bit more research....
[12:41] <stewart> has been linux behaviour/bug since at least 2001
[12:42] <stewart> not on solaris amazingly enough
[12:42] <stewart> but also on osx
[12:42] <stewart> but buggy poll/select on osx is nothing new
[13:33] <rtg_> amitk, are those MX51 patches going into a Karmic topic branch? or master ?
[13:44] <amitk> rtg_: they could be in a branch. It needs to be discussed.
[13:45] <rtg_> amitk, why don't you start by creating a branch and pushing the MX51 patches there so they don't get lost or forgotten? We can always merger them back later.
[13:46] <amitk> rtg_: I'm working on that. We just got it booting yesterday evening...
[14:01] <apw> Keybuk, fyi i've done some testing on the latest karmic kernel, on aufs2 and it seems to work for me, updates and kernel compiles
[14:02] <Keybuk> cool
[14:03] <Keybuk> rtg_: you're having that "runlevel" bug yourself/
[14:06]  * apw goes for a systems ... i may be a while
[14:08] <apw> or not long at all!
[14:19] <rtg_> Keybuk, yeah, whats the story on that?
[14:19] <Keybuk> rtg_: I posted to the bug, I think it's apparmor looping over runlevel forever
[14:19] <Keybuk> if you could fiddle with the script like I suggested, I'd like the strace output
[14:20] <Keybuk> I just realised you'll need 2>&1 on that strace as well
[14:20] <rtg_> Keybuk, ok, gimme a bit
[14:25] <apw> Keybuk, would app armour not have to be enabled for that?
[14:26] <apw> rtg_, did you enable apparmor ?
[14:26] <Keybuk> apw: this looks like it's before it checks for that, it's in an infinite loop examining "runlevel" output
[14:26] <Keybuk> I suspect I know what's wrong
[14:26] <rtg_> apw, stock Karmic (upgrade from Jaunty)
[14:26] <Keybuk> I just need strace output to prove it
[14:28] <rtg_> Keybuk, would it run dhclient3-apparmor if I have a static IP address assignment?
[14:28] <apw> anyone found a suspend or hibernate button on their karmic installs?
[14:30] <Keybuk> rtg_: yes
[14:30] <rtg_> apw, sudo grep "1" /sys/module/apparmor/parameters/enabled return 1. How did AA get enabled yet?
[14:31] <apw> rtg i have that, and i also have this
[14:31] <apw> [    0.004000] AppArmor: AppArmor disabled by boot time parameter
[14:31] <apw> in dmesg, someone is lying
[14:31] <rtg_> jjohansen, ^^^
[14:32] <apw> ahh one hits shutdown from the system menu... and that offers you suspend
[14:32] <rtg_> apw, one hits the power button and it just shuts down, no questions asked
[14:33] <apw> nn mine i hit power and i get the same menu
[14:33] <smb> which would be my expectation
[14:33] <apw> though mine has reboot and shutdown greyed out
[14:34] <apw> its probabally trigged by the power management preferences which have 'ask me' under 'when the power button is pressed'
[14:35] <rtg_> apw, which is what I was futzing with.
[14:36] <rtg_> Keybuk, I'm off to the server room to get your strace info. biab
[14:36] <apw> rtg_, on my T30 the only message i see between grub and usplash is 'Loading please wait ...' which i believe is line 1 of the initramfs
[14:36] <apw> so we may be off the hook :)
[14:39] <rtg_> apw, yeah, I didn't think there were many boot time messages
[14:40] <apw> i _think_ i saw one acpi one on my dell, will try and see if can capture those
[14:43] <rtg_> Keybuk, it looks like it went through the loop at least once, but this appears to be exquisitely timing sensitive. I'll attach the updated dhclient3-apparmor as well as the strace output.
[14:44] <Keybuk> great
[14:44] <Keybuk> I suspect it is very timing sensitive
[14:44] <rtg_> I wonder if AA has anything to do with my sshd issues?
[14:45] <Keybuk> if you want to force the timing, add a "sleep 20" to the top of the start() function /etc/init.d/bootmisc.shg
[14:45] <Keybuk> basically
[14:45] <Keybuk> that apparmor script is calling runlevel to figure out the runlevel
[14:45] <Keybuk> before /var/run/utmp is created
[14:45] <Keybuk> so you get "File not found" :-)
[14:46] <rtg_> it clearly doesn't take much. just adding '-v' to /sbin/ifup alters it enough that it boots
[14:46] <Keybuk> if you make it a liiiitle big slower, you'll be lucky and /var/run/utmp will exist
[14:47] <Keybuk> and whoever wrote that grep clearly doesn't understand runlevels anyway
[14:47] <rtg_> well, this is a dual Nehalem, so theres a lot of shit going on at once
[14:47] <Keybuk> yeah
[14:49] <rtg_> Keybuk, bug updated
[14:50] <Keybuk> thanks
[14:50] <Keybuk> odd that the kernel affects it though
[14:50] <Keybuk> maybe one of the kernels is just faster? :P
[14:56] <rtg_> Keybuk, the previous kernel that this machines was using is 2.6.30 based, so did not have the AA patches.
[14:56] <Keybuk> ahh
[14:56] <Keybuk> so the script never ran? :)
[14:57] <rtg_> Keybuk, likely not since 'grep -q "1" /sys/module/apparmor/parameters/enabled 2>/dev/null || exit 0' would have bailed
[14:58] <Keybuk> ok
[14:58] <Keybuk> and the reason this script worked in jaunty was because runlevel output random garbage when it couldn't read from utmp, rather than existing with an error like it was supposed to ;)
[15:00] <Keybuk> though I can't see why that loop would ever work
[15:00] <rtg_> so, fixing runlevel causes second order effects
[15:00] <Keybuk> well, calling runlevel in rcS.d at all is utterly nonsense
[15:00] <Keybuk> rcS.d is the sysinit phase
[15:00] <Keybuk> there is *no* runlevel
[15:00] <Keybuk> not even "S"
[15:01] <rtg_> I'll have to take your word for that :)
[15:01] <Keybuk> so any values returned by runlevel are generally nonsense
[15:01] <Keybuk> iirc, runlevel will return "unknown"
[15:02] <Keybuk> once /var/run/utmp exists, that is
[15:02] <rtg_> Keybuk, what package should this bug be against? upstart doesn't seem appropriate.
[15:04] <Keybuk> rtg_: I'll fix that up presently with a description
[15:04] <Keybuk> open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[15:04] <Keybuk> write(2, "runlevel: No such file or direct"..., 36runlevel: No such file or directory
[15:04] <Keybuk> yeah
[15:04] <Keybuk> the strace proves it quite nicely ;)
[15:05] <rtg_> Keybuk, yep, saw that.
[15:05] <Keybuk> though I should include a filename in that error, shouldn't I
[15:09] <rtg_> Keybuk, next I'm gonna have to attack /sbin/ifup. It doesn't always get the route statements in /etc/network/interfaces 
[15:27] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has some open slots - how about something Kernel related? :-)
[16:06] <rtg_> jjohansen, why does 'grep -q "1" /sys/module/apparmor/parameters/enabled' succeed on a 2.6.31-3 kernel? 
[16:07] <jjohansen> rtg_: hrmm, was the machine booted with security=apparmor?
[16:07] <rtg_> jjohansen, nope
[16:07] <jjohansen> rtg_: it shouldn't be, I'll take a look
[16:08] <rtg_> jjohansen, its part of the reason that we discovered https://bugs.edge.launchpad.net/ubuntu/+source/dhcp3/+bug/399954
[16:08] <ubot3> Malone bug 399954 in dhcp3 "Karmic Boot hangs at "Configuring network interfaces"" [Medium,Triaged] 
[16:11] <Dinh_FSL> manjo: good morning...
[16:11] <manjo> Dinh_FSL, good morning sir 
[16:11] <amitk> Dinh_FSL: manjo: morning!
[16:13] <Dinh_FSL> amitk,manjo: still more debugging to do with the port, I am seeing after some period of time, it's hanging in synchronize_irq
[16:13] <manjo> yep also usb support needs work right 
[16:13] <manjo> are you planning on bringing that jtag home again on fri ? 
[16:14] <manjo> I bet its the same kinda fix for sync_irq like the timer 
[16:14] <manjo> probably missing mx51 bits
[16:14] <amitk> great stuff last evening guys. Thanks.
[16:14] <manjo> amitk, u not on the call ? 
[16:14] <manjo> amitk, yeah lots of beer & wine helped 
[16:15] <amitk> heheh
[16:15] <amitk> umm... call?
[16:15] <manjo> vnc
[16:15] <amitk> oooh. skype
[16:15] <Dinh_FSL> manjo: sure, i can bring jtag home tomorrow...keep going on this...
[16:15] <manjo> yeah
[16:15] <amitk> forgot all about it
[16:15] <manjo> cool I can be there... I had too much fun yesterday
[16:16] <manjo> amitk, so chiming in  ? 
[16:16] <amitk> hold on.
[16:27] <bjf> Dinh_FSL, do you know if the kernel you and manjo are working on right now will boot on a babbage 2.5 board?
[16:27] <bjf> Dinh_FSL, or will there be additional kernel changes required?
[16:28] <manjo> bjf, it boots on the board you gave me 
[16:28] <bjf> manjo, that is a babbage 2 board, we will be getting babbage 2.5 next
[16:29] <manjo> Dinh_FSL, did u have a 2.5 yesterday ? 
[16:29] <manjo> I think he had the same board as me 
[16:29] <Dinh_FSL> bjf: I tried the kernel on the 2.5 and wow!! It boots!!
[16:29] <Dinh_FSL> hehe
[16:29] <manjo> Dinh_FSL, dont forget to copy ubunt u install on my sd
[16:29] <bjf> Dinh_FSL, that's sweet! good to know
[16:30] <Dinh_FSL> manjo: yes sir, but you gave only gave me a 2GB card...it won't fit...i'll put it on 1 of my 4GB card for you
[16:30] <manjo> sweet!
[17:09] <dholbach> ok... only one slot left
[17:09] <dholbach> who would like to talk about something Kernel related?
[17:10] <dholbach> maybe "Becoming a Kernel hacker" where you show people what they can do to help you (or do your work for you :-))
[17:10] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[19:13] <cjwatson> manjo: what's the story on iscsitarget in karmic at the moment? I'll be one of your users if you get it working, since I have a userspace spec for which that's the ideal test harness ...
[19:13] <cjwatson> (just reading off some wiki page that said it was assigned to you and in progress)
[19:13] <manjo> cjwatson, got pulled into doing some arm stuff so will look at it next 
[19:13]  * cjwatson nods
[19:14] <cjwatson> my deadline is alpha 4 so not super-urgent
[19:14] <manjo> cjwatson, was planning on making it dkms
[19:14] <cjwatson> fine by me, I don't much care exactly how it's done :)
[19:14] <manjo> yeah the arm stuff need attention  for alpha3
[19:36] <rtg_> cjwatson, wrt iscsitarget, the last discussion I had with the server folks is that we'll pull it out of the kernel. It'll be a DKMS package that is kept in sync with user space.
[19:37] <cjwatson> that's fine, I just wanted to know if anyone had made progress on actually producing the package yet (e.g. PPA or whatever even if not in the distro)
[19:38] <rtg_> I'll bug Dustinm
[19:38] <rtg_> Dustin, even
[19:40] <cjwatson> ok, cool
[19:53] <cdowns> hello ?
[21:20] <dinh_fsl> manjo, amitk: hi...
[21:20] <manjo> dinh_fsl, hey
[21:20] <manjo> you fixed it already ? 
[21:20] <dinh_fsl> what is the plan with the current ubunt-fsl-2.6.31 tree?
[21:21] <dinh_fsl> no, i haven't gotten a chance to fully debug it yet
[21:21] <manjo> dinh_fsl, dont want to put words in amitk_ 's mouth ... but I think we need to massage it more and make it ready for upstream ... 
[21:22] <manjo> dinh_fsl, same time tomorrow then ? 
[21:22] <dinh_fsl> manjo: that's my thought too, just wanted to make sure...
[21:22] <manjo> yep but we need it booting & running 1st 
[21:22] <manjo> dinh_fsl, I could get you an official ans if you need it 
[21:23] <dinh_fsl> manjo: that's what my manager and I are trying to figure out...
[21:23] <manjo> dinh_fsl, let me see... 
[21:23] <dinh_fsl> manjo: perhaps it may make more sense for you guys to massage it more, and if you hit another hurdle I can help again
[21:25] <manjo> dinh_fsl, but we will need the jtag to see what is going on with the hang ... 
[21:25] <manjo> can I get a loaner ? 
[21:26] <dinh_fsl> a lauterbach?
[21:26] <manjo> dinh_fsl, if you can spend one more day (tomorrow) to figure out that might just do it ... 
[21:26] <manjo> yeah lauterbach + cables
[21:27] <dinh_fsl> manjo: my answer is sure...i was planning to work from home tomorrow anyways...either on this or some other thing
[21:27] <manjo> ok
[21:27] <manjo> going fwd I think we wil see how to massage this code so that it looks better 
[21:28] <manjo> clearly needs more work
[21:45] <dinh_fsl> manjo: when's sushi?
[21:45] <dinh_fsl> ;)
[21:46] <manjo> dinh_fsl, let me call to find out 
[21:46] <manjo> want to do it tonight ? 
[21:46] <dinh_fsl> sure...
[21:46] <dinh_fsl> let me know so that I can hold off the cooks at home
[21:46] <manjo> ok in 10mts
[21:50] <manjo> dinh_fsl, the chief is out of town this week .. so its going to be next week 
[21:51] <dinh_fsl> manjo: ok...the cooks are back online
[21:51] <manjo> :) 
[21:52] <manjo> dinh_fsl, jack said the cheif had to go out of town... the other guys over there are junior 
[21:53] <manjo> dinh_fsl, we want the sushi chief senior to prepare for us :) 
[21:53] <dinh_fsl> manjo: ah I c...
[21:54] <manjo> shit now I am hungry... all that salad for lunch is gone 
[22:01] <dinh_fsl> manjo: outta here...see ya tomorrow morning...
[22:01] <manjo> dinh_fsl, ok sir see you tomorrow