[01:55] <smoser> hey all.
[01:55] <smoser> looking at bug 937352
[01:55] <ubot2`> Launchpad bug 937352 in cloud-initramfs-tools "root partition in may not be grown" [Undecided,New] https://launchpad.net/bugs/937352
[01:55] <smoser> it *appears* to me that after a umount, a subsequent sfdisk (with call to BLKRRPART) returns device or resource busy.
[01:56] <smoser> i'm wondering if there is some thing that is actually necessary to do to wait until the kernel would not any longer consider that resource busy.
[07:34] <reisei> hi! How can I mesure the temperature of the core?
[07:35] <jk-> of the earth? that's a bit tricky.
[07:35] <jk-> reisei: intel CPU?
[07:35] <reisei> jk-: omap cpu
[07:36] <jk-> reisei: eep, that's a little more tricky; is there anything in /sys/class/thermal ?
[07:37] <reisei> jk-: I'll check 
[07:52] <reisei> jk-: there is nothing there
=== smb` is now known as smb
[08:08] <smb> morning
[08:08] <reisei> jk-: What will you suggest?
[08:11] <RAOF> Is there actually a thermal sensor on that thing? :)
[08:14] <reisei> RAOF: yep
[08:16] <smb> RAOF, that at least is step 1 :)
[08:29] <reisei> RAOF: may be you tell me how can I check the temperature?
[08:32] <ohsix> if it's that hard to figure out it might be more prudent to check the datasheet and see if it even has one you can read
[08:32]  * smb struggles very hard and fails... how about putting ones finger on the heat sink...?
[08:33] <reisei> smb: thermak framework is better, I guess
[08:35] <smb> reisei, Here goes the irone. But ok, yes, though that requires either a sensor on the board or the chip, the specs how to read it and someone who writes a driver for it. 
[08:35] <smb> And I don't know any, ohsix, I guess you do not either?
[08:38] <reisei> smb: if there are all this parts, if I got temperature in dmesg, but in some strange format, what should I do to fix it?
=== mthaddon` is now known as mthaddon
[08:41] <ohsix> smb: i'd have to hit up the datasheets too, there's probably a diode somewhere that gets the temperature; but that doesn't always mean you can read it
[08:42] <smb> reisei, I'd probably try to find the function in the kernel source that prints that message, and then try to find out whether that has enough info (which I usually doubt). If you have a datasheet you may find where it looks and maybe what things mean. If not maybe finding who usually commits to that file and try to get into contact with them
[08:43] <smb> ohsix, Totally agree. Was just wondering whether someone may have done something there. Though it did not sound like there is a driver.
[08:43] <reisei> smb: I found hwmon data. But what's the value it get? Something like 51600.
[08:47] <smb> reisei, Have you checked Documentation/hwmon/sysfs-interface in the kernel tree... Seems millidegree C  is what it is. So 51.6°C ? If that is a reasonable value.
[08:47] <smb> would be for x86 but no clue about arm
[08:50] <reisei> smb: ok, but that seems to be wrong value. in the start of the system it show ~38°, but it should room temperature.
[08:54] <smb> reisei, It could be wrong but may also be somewhere inside the chip that gets warm pretty quick. This is where you have to look into the datasheet and the driver. Since you read it from somewhere you should know which driver
=== lool- is now known as lool
=== yofel_ is now known as yofel
[10:35] <ryao> Is grub being compiled with GCC 4.6.2 in Ubuntu 12.04?
[10:37] <ryao> lamont: I hope you don't mind me pinging you, but the official Ubuntu wiki shows you as the contact person for the #ubuntu-kernel channel. I am not sure if that is for things that the Ubuntu kernel team is responsible for maintaining or just this channel.
[10:38] <cking> ryao, I suspect you probably need to ask that question in ubuntu-devel
[10:38] <ryao> cking: I did, but then I noticed on the website that the Ubuntu kernel team is repsonsiblef or it.
[10:41] <smb> Seems the ubuntu kernel team is stated as maintainer in the package... Not that we really do much to it
[10:43] <ryao> smb: Who is responsible for compiling it?
[10:45] <smb> ryao, well from the changelog the uploads have been done either by mvo or cjwatson. Maybe try to get mvo's attention. I'd say though, whatever the default compiler for precise is is used for compiling grub in precise.
[10:48] <ryao> smb: Thanks. I will try to verify that with one of them.
[10:49] <smb> ryao, cjwatson is not around for a while
[10:49] <ryao> smb: cjwatson is in #ubuntu-devel while mvo is not. :/
[10:51] <smb> ryao, Not sure whether he is really there or just his proxy. I think I saw some mail from him announcing to be on leave. Not sure it is already now or later
[10:51] <ryao> Okay, thanks.
[10:51] <smb> Though I see somebody else stepped up
[10:53] <ryao> Thanks for your help. :)
[11:05] <ericm|ubuntu> ppisati, ping
[11:06] <ppisati> ericm|ubuntu: pong
[11:14] <cnd> apw, tim cherry-picked a patch directly last week after a very brief conversation here on irc
[11:15] <cnd> actually, before I go further, I realized the patch hasn't made it to linus yet
[11:15] <cnd> nm for now
[11:15] <cnd> and if you read the above as one normally would, it would seem very odd, but it's best to just assume I never said anything :)
[11:16] <lamont> ryao: you want the team, not me, for that question
[11:16] <ryao> lamont: Thanks.
[11:16] <lamont> ryao: likewise, the buildlog for grub should tell  you what it's using for the build
[11:17] <ryao> Thanks. ajmitch in #ubuntu-devel pointed that out. :)
[11:17] <lamont> or more to the point, what it used for the build
[11:17] <lamont> heh
[11:40]  * ppisati -> back in a bit
[12:02] <smoser> smb, around ?
=== ericm|ubuntu is now known as ericm-dead
[12:29] <apw> smb, hey your maint-update-patch, if i ask it to sign off something, and there are no signoffs already, will it work correctly its looking like it does not
[13:05] <smb> smoser, now and no I don't know what keeps the partition or drive busy
[13:06] <smb> apw, PRobably not as that was rather not the case for anything coming down. Actually I would have asked people to at least have their sob when they want something included. :)
[13:08] <smb> apw, You are not doing it the way it should be done... oops... wrong channel... :-P
[13:08] <apw> :-p
[13:11]  * ppisati -> lunch
[13:12] <smb> smoser, Just a guess, but changing the partition sizes should likely generate change events for the drive/partitions, which then triggers things run by udev, and those again may open the disk/partitions. So maybe it helps to shed light into the issue when you log udev events/debugging in parallel
[13:17] <smoser> smb, hm.. 
[13:17] <smoser> i dont think that makes sense.
[13:17] <smoser> the core issue is:
[13:17] <smoser>  umount
[13:17] <smoser>  sfdisk (with blkpart)
[13:17] <smoser>  mount
[13:17] <smoser> but it is the sfdisk that is failing
[13:17] <smoser> oh...
[13:17] <smoser> if what you're saying is true, then there is a race any time sfdisk is run
[13:18] <smoser> udev really shouldn't be involved until *after* sfdisk has called BLKRRPART
[13:19] <smoser> i have to run. will poke some more later, but please think some.
[13:19] <smb> Actually I mentally ignored the --dry-run part in the sfdisk on the bug report. But thinking of it, it would be interesting to see how things are committed. I guess the events only should happen when doing a rereadpt ioctl
[13:20] <smb> smoser, But I'll think a bit more
=== yofel_ is now known as yofel
=== bladernr_afk is now known as bladernr_
[14:28] <apw> smb, yeah presumably as sfdisk exits
[14:30] <smb> apw, Would be expected. Right now trying to re-create it locallly... and wondering whether this is just a different mode of getting it to fail. since there does not seem to be a settle wait between the growing and resetting the partition (in the test script)
[14:31] <smb> anyway
[14:51] <smoser> smb, yeah, the script i do see lots of failures on the re-start/reset of the script
[14:51] <smoser> but i also see failures after umount
[14:53] <smb> smoser, still waiting to see it happen on my local xen guest... maybe too slow... Just a 2GHz 8-core... :-P
[14:56] <smoser> smb, 
[14:56] <smoser> sudo sh -c 'd=/dev/vdb; p=${d}1; mp=/mnt; trap "umount $mp" EXIT; while : ; do mount $p $mp && umount $mp && sfdisk --re-read $d|| exit 1; echo -n .; done'
[14:56] <smoser> simplify it and try it like that.
[14:56] <smoser> i just saw that fail here.
[14:56] <smoser> in a canonistack instance.
[14:57] <smoser> i can give you access if you need.
[14:58] <smoser> smb, ubuntu@10.55.60.111 if you want. i've imported your launchpad keys.
[14:59] <smb> smoser, hm, that may change some assumptions. Ok, then I can check also a few other general setup questions
[15:00] <smoser> smb, change some assumptions?
[15:00] <smoser> i'm assuming that sfdisk --re-read is just sending the BLKRRPART call without doing anything
[15:00] <smoser> and in this case when it fails, its getting a resource busy
[15:01] <smb> smoser, Well assuming it is Xen or KVM based. Should not really make that difference but could yield different timings
[15:01] <smoser> right.
[15:01] <smoser> timings
[15:01] <smoser> note, i'd never seen this before they upgraded canonistack to precise
[15:01] <smoser> which brought a new kvm
[15:02] <smoser> now we're seeing it quite often (maybe 1/2 boots)
[15:02] <smoser> so yeah, there is obviously race involved.
[15:02] <smoser> smb, 
[15:02] <smoser> sudo sh -c 'd=/dev/vdb; p=${d}1; mp=/mnt; cleanup() { umount $mp >/dev/null 2>&1; } ; trap cleanup EXIT; umount $p >/dev/null 2>&1; while : ; do mount $p $mp && umount $mp && sfdisk --re-read $d|| exit 1; echo -n .; done'
[15:03] <smoser> thats maybe a bit prettier, just cleans up after itself better.
[15:03] <smoser> but i can run that and it will go for quite a while, and the ctrl-c it, and have it fail after 3 tries.
[15:03] <smb> smoser, Could still be both. New kvm or slightly different behaviour in the kernel in general or userspace... Except if it now appears on all kinds of guests too
[15:03] <smoser> right.
[15:04] <smb> smb, I'll try the smaller version 
[15:05] <smoser> smb, i got to run again. sorry to bother you and then run off, but i'm supposed to be on vacation. :)
[15:05] <smb> smoser, Heh ok. no worries
[15:06] <smoser> smb, thanks. later. and you can update that bug with anything you find or post back here.
[15:06] <smb> smoser, will do in the bug
[15:06] <apw> smb, whats that command which is grep foo /etc/passwd with ldap ?
[15:07] <smb> apw, gentent?
[15:07] <apw> that sounds likely
[15:07] <smb> apw, I mean getent
[15:08] <smb> apw, should be getent passwd <id>
=== bjf[afk] is now known as bjf
=== albrigha is now known as Guest79155
=== Guest79155 is now known as albrigha
=== bladernr_ is now known as bladernr_afk
=== bladernr_afk is now known as bladernr_
[15:40]  * ogasawara back in 20
[15:47] <jsalisbury> **
[15:47] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:47] <jsalisbury> **
[15:58] <jsalisbury> apw, Can any kernel config option be changed at boot time, or just a certain set of them?  For example, I'd like to boot a kernel with CONFIG_USB_XHCI_HCD disabled to save time by not having to build a test kernel.
[15:58] <apw> jsalisbury, nope, they have to be specifically exposed either in sysfs or syscontrol
[15:59] <apw> many require different code generated, so can only have effect at build time
[15:59] <jsalisbury> apw, ahh, ok.  thanks!
[16:01] <apw> jsalisbury, i've not got a headset here today, doh so won't be about for the 4:30
[16:01] <apw> (now+29)
[16:02] <jsalisbury> apw, ok.  Tim's out today as well, so it will probably be a quick one this week.
[16:03] <apw> i know lets simply assign smb to them all :)
[16:03]  * smb tries to mentally slap apw
[16:04] <jsalisbury> :-D
[16:04] <apw> jsalisbury, and call for the white coats as smb is going mental too :)
[16:05] <jsalisbury> apw, heh
[16:06] <smb> apw, what do you mean? going?
[16:06]  * smb assumed he was there already
[16:38] <apw> smb, thats not a prizon its your flat
[16:39] <smb> apw, now I am completely lost :) I mean I thought I was already mental ;)
[16:41] <smoser> smb, why would sync do anything other than change timing?
[16:41] <smoser> oops. sorry to interupt meeting.
[16:41] <brendand> bjf - did i just see a new Oneiric -proposed kernel pop up? the current one isn't finished verification yet
[16:42] <smb> smoser, not ours but not being on yours :)
[16:43] <bjf> brendand: i created the wrong tracking bug
[16:43] <bjf> brendand: it's already marked invalid
[16:44] <smb> ogasawara, Do we know about items assigned to the canonical-kernel-team here https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-ceph
[16:45]  * ogasawara looks
[16:45] <jsalisbury> ogasawara, possibly related to the rc6 patch: bug 937378
[16:45] <ubot2`> Launchpad bug 937378 in linux "Patched kernel with rc6 enabled shutdowns" [High,Confirmed] https://launchpad.net/bugs/937378
[16:46] <ogasawara> smb: I'm unaware of anyone actively looking into that
[16:46] <ogasawara> smb: I'm not even sure what patch is being referenced there
[16:49] <ogasawara> jsalisbury: ack thanks
[16:49] <jsalisbury> ogasawara, could be one more too: bug 935965
[16:49] <ubot2`> Launchpad bug 935965 in linux "RC6 enabled causes severe graphics corruption" [High,Confirmed] https://launchpad.net/bugs/935965
[16:49] <smb> ogasawara, Right, probably as aware as I was before being asked in the server team meeting :)
[16:49] <ogasawara> jsalisbury: yep thanks, was aware of that one already
[16:49] <jsalisbury> ogasawara, ok thanks.  I'll add them to the hot list for tracking
[16:50] <ogasawara> jsalisbury: I'm keeping an eye on https://wiki.ubuntu.com/Kernel/PowerManagementRC6 which is where most of the RC6 related bugs should be getting noted
[16:50] <ogasawara> smb: yep, completely unaware
[16:50] <smb> :) yep
[16:50] <jsalisbury> ogasawara, I'll keep an eye on that as well.  Thanks
[16:50] <ogasawara> smb: do you need me to follow up with anyone to get that postponed?
[16:51] <ogasawara> smb: as I'm guessing it's not actually going to get done
[16:52] <smb> ogasawara, We need to talk at least to them to let them know that assinging things to canonical-kernel-team without talking to us is as good as giving the task to john doe
[16:52] <ogasawara> smb: indeed
[16:54] <ogasawara> smb: I'm crafting an email, I'll CC you on it.
[16:55] <smb> ogasawara, ACK, though I am pointing it out on irc as well right now. 
[16:55] <smb> Daviey, and <SpamapS>. 
[16:57] <Daviey> I don't know, without looking at my mail archive, who assigned it.
[16:57] <ogasawara> smb: [08:44:00] <SpamapS> Daviey: I don't think there's anything for the kernel team to do for CEPH .. its more about QA and testing.
[16:58] <smb> ogasawara, Right, the patches there seem to be optimizations
[16:58] <smb> Which we probably want to put on q's list of todos to look at and get assigned to something we know of
[16:59] <ogasawara> smb: so I'm guessing that means the work items could be postponed and are not blocking any others.  but I'll email clint and make sure.
[16:59] <ogasawara> Daviey: ^^ I can CC you on that as well if you like?
[16:59] <smb> ogasawara, Yes, thats is how I undestood clints comments on -server
[17:06] <manjo> For launchpad bug table view install  https://chinstrap.canonical.com/~jamesf/lptables/lptables.crx
[17:07] <manjo> oops
[17:08] <manjo> bad mouse
[17:15] <smb> apw, If you are not yet afflicted by the fridge contents: seems the umount not completely off the blkdev seems to be there at least back to natty... have not made it farther back yet
[17:16] <apw> manjo, quality
[17:16] <manjo> :)
[17:16] <apw> smb, hmm, interesting, yet sd_revlaidate is newish ... odd
[17:17] <smb> apw, Well can be completely unrelated oddness
[17:17] <apw> yeah must be unrelated i guess
[17:37] <jsalisbury> Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Feb 28th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:42] <smb> jsalisbury, not sure that worked as expected
[17:47] <ppisati> EOD
[18:18] <jsalisbury> smb, the topic change?
[18:19] <jsalisbury> smb, ahh, right
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Feb 28th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[18:20] <jsalisbury> smb, thanks ;)
[20:34] <prashs> Hello. My ubuntu is unable to find the bluetooth device connected to it. In kernel 2.6.32 i was able to do that. But once i upgraded to 3.0 i am right now unable to do it. Ubuntu is not recognizing my Bluetooth dongle connected :( What to do??
[22:08] <jsalisbury> ogasawara, regression between 3.2.0-16 and 3.2.0-17: bug 938195
[22:08] <ubot2`> Launchpad bug 938195 in linux "kernel 3.2.0-17-generic crashes constantly" [High,Confirmed] https://launchpad.net/bugs/938195
[22:12] <ogasawara> jsalisbury: thanks
[22:12] <jsalisbury> ogasawara, np.  I requested that the bug report test 3.3-rc4 just to see if the bug is fixed there.
[22:13] <jsalisbury> ogasawara, I wasn't sure if it was rc6 related or not.
[22:13] <ogasawara> jsalisbury: it might be, and it's a quicker test for them to try and disable it to see.
[22:13] <jsalisbury> ogasawara, ahh, right.  I can request that test.  
[22:14] <ogasawara> jsalisbury: cool, thanks.
[22:16] <jsalisbury> ogasawara, I'll request that bug reports disable RC6 for any new bugs that come in that appear to be RC6 related.
[22:16] <ogasawara> jsalisbury: great, that'd be good.  thanks.
[22:24] <jsalisbury> ogasawara, Should these bugs only affect Sandy Bridge systems, or any system using the i915 driver and running the  3.2.0-17.26 kernel? 
[22:24] <ogasawara> jsalisbury: should only affect sandy bridge
[22:25] <jsalisbury> ogasawara, what's the best way to confirm a system is a Sandy Bridge?  With lspci -nn | grep "VGA"
[22:26] <jsalisbury> ogasawara, then look for "Intel Corporation 2nd Generation Core Processor"
[22:28] <ogasawara> jsalisbury: shoot, I thought we had a message thrown to dmesg that it was being enabled, but I'm wrong.
[22:30] <jsalisbury> ogasawara, I see the following in the boot dmesg: agpgart-intel 0000:00:00.0: Intel Sandybridge Chipset
[22:30] <jsalisbury> ogasawara, that should at least help me identify if a system is sandy bridge or not.
[22:31] <ogasawara> jsalisbury: lspci VGA info would also likely include vendor:device id's of one of the following 8086:0102, 8086:0112, 8086:0122, 8086:0106, 8086:0116, 8086:0126, 8086:010A
[22:31] <jsalisbury> ogasawara, cool, thanks.  
[23:08] <jwi> jsalisbury: /proc/cpuinfo - client SNB is family 6, model 42.
[23:18] <ohsix> sforshee: heh re: touchpad, after setting both keys to "toggle", i noticed if i press it fast enough the key events are not sent, but the light does change
[23:19] <ohsix> since they originally were on/off events, it'd get out of sync either way
[23:23] <sforshee> ohsix, both keys? there's more than one?
[23:23] <ohsix> there's one key, but 2 events, one for enabled -> disabled (the light changes from white to orange) and vice versa
[23:24] <sforshee> oh, so two scan codes
[23:24] <ohsix> they didn't work as separate events since g-s-d doesn't trap XF86TouchpadOff (and on) or whatever, but only toggle
[23:24] <sforshee> huh, that's not ideal
[23:25] <ohsix> yea i didn't check and see if it did in the past, but i suspect that's why it stopped working
[23:25] <sforshee> you really want the on/off since that's really what your machine is reporting
[23:25] <ohsix> right, but the light can still get out of sync if it's pressed fast enough; so it sucks either way
[23:25] <ohsix> if it didn't have a light whether it was toggle or separate on/off would be moot, and since the light can change without sending an event it's moot anyways
[23:26] <ohsix> at least on my laptop
[23:26] <ohsix> there are a lot of keymaps for other models that look out of date too
[23:26] <sforshee> odd that it toggles the light without sending the event
[23:27] <sforshee> what kind of machine was it again? HP?
[23:27] <ohsix> yea, HP Compaq Presario CQ60-420US
[23:28] <ohsix> (though it's had a mobo swap, dunno if it's exactly a 420us anymore :)
[23:30] <sforshee> ohsix, which keymap is getting used?
[23:31] <ohsix> it didn't match any of the ones that come with udev on natty, i had to make my own; i mimic'd the other touchpadon/off keysyms in the other ones and it still didn't work, but toggle did; after i found out g-s-d traps toggle
[23:31] <ohsix> i filed a bug, let me find it
[23:33] <ohsix> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/935804
[23:33] <ubot2`> Launchpad bug 935804 in udev "hewlett-packard keymaps mostly wrong or obsolete" [Undecided,New]
[23:34] <ohsix> i haven't really figured out what i can do to usefully get it fixed yet, but i did know that all those keymaps were wrong after my investigation so that's the bug i filed :]
[23:35] <ohsix> the thread didn't have any references so i wasn't able to see what actually happened because of it, so i haven't added anything more yet
[23:37] <sforshee> yeah, keymaps are the only way to really support those since it looks like they come from the AT keyboard
[23:37] <sforshee> so pursuing it in udev seems like the right approach
[23:38] <ohsix> well supposedly you're able to report it to one of the linux mailing lists and they make the kernel send those events directly instead of adjusting the keymap
[23:39] <ohsix> so if i were to do as suggested in README.keymap, i wouldn't even need a keymap file in the end
[23:39] <sforshee> it depends on where the key events come from. The udev rule seems to apply those keymaps for the AT keyboard, and for that one you won't get them added at the kernel level.
[23:39] <ohsix> except for the time window between it landing in a kernel release i can use and before then
[23:39] <ohsix> ah, really?
[23:39] <ohsix> i wasn't aware of any special rules or whatever regarding that
[23:40] <sforshee> yes, if they're coming from a platform driver you can get them added in the kernel
[23:40] <sforshee> the AT keyboard driver is completely generic though, and so it can't have a bunch of model-specific key codes added to it
[23:40] <ohsix> would, say if that's already occuring, the keys come from the AT keyboard in the end? there is a wmi driver in play but i don't know what it's doing
[23:41] <ohsix> eg, platform driver traps whatever and delivers D8 to the at driver, is that what happens or would there be a separate event device?
[23:41] <sforshee> I'm judging based on how the hp keymaps are applied by udev. If you want to know for sure, use lsinput to identify the actual input devices and then use input-events to see which one is reporting the keys.
[23:42] <sforshee> platform drivers have separate event devices
[23:42] <ohsix> ya i've done that before, it used to be on a separate device
[23:42] <sforshee> what device? hp-wmi?
[23:42] <sforshee> hp-wmi doesn't even seem to recognize those scancodes
[23:43] <ohsix> hm wait, it still may be on a separate device, do you mean exclusively or in addition to coming from the AT keyboard? i'm still a bit fuzzy on how everything fits together
[23:43] <sforshee> i don't understand the question
[23:44] <ohsix> not important, i think i'm confusing this whole event/keypress thing with another problem i had with my brightness keys (g-s-d sees 3 brightness changes for one keypress, never found out how)
[23:45] <ohsix> and now my touchpad disable key isn't even working and it decided to do that while it was off, brb
[23:45] <ohsix> rdesktop blows
[23:46] <ohsix> heh i disabled it for the input-test test, since i took the focus back to rdesktop and it does an exclusive grab when it's in the foreground i couldn't reenable it
[23:46] <ohsix> ok so, udev keymaps aren't irrelevant, g-s-d not trapping on/off is, good to know
[23:47] <ohsix> maybe you can help me sort the multiple brightness adjustment thing too, but that will have to wait; overdue for something
[23:48] <sforshee> yeah, it's time for me to get off of here anyway
[23:48] <ohsix> thanks again
[23:48]  * sforshee -> EOD