[07:50] <ppisati> moin
[08:24] <smb> morning
[09:09]  * apw yawns
[09:48] <melkor> Hello, I am trying to build a driver and I get an implicit function declaration error for __netdev_printk
[09:48] <melkor> I think this function has been removed from the 3.7 kernel and I'm curious if it has been replaced or changed.
[09:58] <melkor> Deleted the function call and the driver compiles fine. It sucks that the driver hasn't found its way into the kernel. It is the ethernet driver for newer atheros cards.
[10:54] <ppisati> brb
[12:39] <dhanasekaran> Hi Guys, How to find one particular  process how many open files are there, any way to identify?
[12:40] <melkor> dhanasekaran: seems like this might not be the correct channel for that question. Did you mean #ubuntu?
[12:42] <dhanasekaran> melkor: it's process related right?  process  guys talk to libc. The kernel must know the list of open files right.
[12:43] <melkor> dhanasekaran: I'm not arguing with you I'm just offering you a suggestion that might improve your chances of getting help.
[12:43] <dhanasekaran> melkor: thnaks.
[13:19] <rtg> smb, rebooting gomeisa for _something_, but can't remember what.
[13:19] <smb> rtg, ok, I am off
[13:21] <dhanasekaran> apw: yesterday I asked one question, How to find particular path, available or not? You said no available in Linux tree. I agree. I want to know how to find it. It's helpful my further searches please guide me, I already download code from github
[13:22] <apw> dhanasekaran, from what i could see that patch was only on the mailing list, i think your link was to patchworks
[13:23] <apw> dhanasekaran, though it was also 3/3, ie the third one of a set and likely no use on its own
[13:23] <dhanasekaran> can i find patch history from gitk
[13:26] <apw> if a patch is only on the mailing list, then it is not in git, therefore not in gitk
[14:06] <smb> rtg, did the something turn out to be a pain?
[14:06] <rtg> smb, gomeisa not back ?
[14:07] <smb> rtg, sort of... just not letting me in
[14:07] <rtg> crud, better go check
[14:21] <rtg> smb, gomeisa is back
[14:21] <smb> rtg, thanks
[15:41] <rtg> this smatch run is taking forever
[16:14] <jsalisbury> **
[16:14] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:14] <jsalisbury> **
[16:35] <jsalisbury> rtg, so you can't hear me, eh?
[16:35] <rtg> jsalisbury, nope
[16:36] <jsalisbury> rtg, whoops, I was wondering why it was so quiet :-)
[16:36] <rtg> jsalisbury, still no sound
[16:36] <jsalisbury> rtg, ok, let me see what broke
[16:40] <rtg> jsalisbury, you are screwed today
[16:41] <jsalisbury> rtg, yup.  I'll try to figure out what happened after the IRC meeting.
[16:42] <tjaalton> 'ubuntu-bug linux' fails on raring, claims -5-generic is 3rd party, known?
[16:45] <ohsix> check aptitude and see if it's in the obsolete or locally created packages section, if it isn't, i dunno :]
[16:47] <tjaalton> ohsix: indeed, -6 is out :)
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
[17:17]  * ppisati goes for some sweating - later...
[17:50] <apw> henrix, ok ... looks right now
[17:50] <henrix> apw: \o/
[17:51] <henrix> apw: any other thing i missed there?
[17:51] <apw> nope, the ' thing was the primary problem, then the raring things were simply sha1s coming available later
[17:52] <henrix> apw: ah, ok. thanks a lot for your help
[18:02] <jsalisbury> bjf, henrix, herton bug 1119809 is a regression in 3.2.0-38.59 that is affecting allot of people.  The issue doesn't happen in 3.2.0-37.58
[18:02] <ubot2> Launchpad bug 1119809 in linux (Ubuntu) "Desktop login freeze with kernel 3.2.0-38.59" [Medium,Confirmed] https://launchpad.net/bugs/1119809
[18:03] <bjf> jsalisbury, ack
[18:03] <jsalisbury> bjf, I haven't started a bisect for it yet, but I can do so
[18:04] <henrix> jsalisbury: looking, thanks
[18:27]  * rtg -> lunch
[18:45] <herton> jsalisbury, it seems I'm able to reproduce here, I'm starting a bisect here
[18:46] <jsalisbury> herton, cool, thanks!
[18:54] <bjf> slangasek, we loaned you a mac. i thought it was so something would be fixed so we didn't have to produce +mac isos. i just noticed we are still producing them so i'm assuming you have not finished that work?
[18:54] <slangasek> bjf: correct, I have not :/
[18:54] <slangasek> you need the macs back?
[18:55] <bjf> slangasek, nope, all good, just making sure we were not building +mac isos unnecessarily
[18:55] <slangasek> sadly no
[19:20]  * henrix -> EOD
[20:13]  * rtg -> EOD
[20:58] <sforshee> stgraber, can you try out the kernel at http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-6.11~lp1098216v201302121943/ on your x230?
[20:59] <sforshee> this is a different approach to the backlight problem
[21:00] <stgraber> sforshee: yep, will do
[21:00] <sforshee> stgraber, thanks. Be sure you don't boot with acpi_osi="!Windows 2012".
[21:05] <stgraber> sforshee: oh, I see, you're doing it the Windows way then ;) set all the values in the array from the current one to the one we actually want
[21:06] <sforshee> stgraber, yep. That's what I was asked to do when I tried to get the quirks upstream.
[21:07] <sforshee> stgraber, what you'll probably see is that it mostly works, but in one or two spots the brightness won't actually change when you adjust it through the desktop
[21:07] <sforshee> g-s-d divides the range up into 20 steps but there are only 16 valid values
[21:08] <stgraber> I rarely use the GUI tool, I usually just use the hotkeys which give you 8 levels IIRC
[21:08] <stgraber> you only get the 20 if you go through the control center I believe
[21:08] <sforshee> hmm, okay. Those must be generating backlight events rather than keypresses then.
[21:09] <sforshee> stgraber, please try it both ways, I'd like to know the results
[21:10] <sforshee> stgraber, also try directly writing the value in /sys/class/backlight/acpi_video0/brightness back into that file. That's an edge case I want to be sure gets tested.
[21:11] <stgraber> ok
[21:11] <stgraber> my laptop should be available for testing in a few minutes, finishing a couple of upstart and network-manager builds now ;)
[21:15] <sforshee> stgraber, at your leisure ;-)
[21:22] <stgraber> sforshee: bad news for you, doesn't work
[21:23] <stgraber> sforshee: using the hotkeys in X (which are caught by g-s-d), I can't change the brightness level, it gets stuck at maximum
[21:24] <stgraber> looking at the value of brightness, I can bring it down to 95 as the lowest value (actual_brightness remains at 100)
[21:24] <sforshee> stgraber, drat
[21:24] <stgraber> sforshee: going through the full gnome-control-center applet works though
[21:25] <sforshee> hmm, okay
[21:25] <sforshee> stgraber, when you say you can bring brightness down to 95, how are you doing that?
[21:26] <sforshee> (note that reading actual_brightness is going to reset brightness to the actual value your firmware thinks the value is, which is the last valid value written)
[21:26] <stgraber> fn+F8 which shows me the notify-osd brightness stuff. The slider appears as slightly less than maximum but there's no actual change in screen brightness
[21:31] <stgraber> sforshee: I've been tracing gnome-settings-daemon a bit here and looking at the dbus calls, when going through gnome-control-center only SetPercentage calls are emited
[21:31] <stgraber> when using the hotkeys, I see a GetPercentage call and a StepDown call instead
[21:32] <stgraber> so depending what file GetPercentage is reading, this may explain why it gets stuck
[21:32] <sforshee> stgraber, run acpi_listen and press your hotkeys and tell me what output you get
[21:33] <stgraber> F8 is: video LCD0 00000087 00000000
[21:33] <stgraber> F9 is: video LCD0 00000086 00000000
[21:33] <sforshee> that's what I thought
[21:34] <sforshee> so acpi_video handles those events internally to adjust the brightness
[21:34] <sforshee> unfortunately when it does that it's calling _BQC to ask the firmware what it thinks the brightness is
[21:34] <sforshee> so it's always getting the last value that actually applied
[21:35] <stgraber> so it that explains why it's trying to set the same value over and over again without any actual result
[21:35] <stgraber> s/it//
[21:35] <sforshee> yeah, it always tries to get the next larger or smaller value, but when it writes that to the firmware the value just gets discarded
[21:36] <sforshee> the next time it asks it just gets the same thing it got the previous time
[21:36] <sforshee> stupid firmware
[21:36] <sforshee> so the question then is does acpi_video really need to ask, or can it just use the cached value it already has
[21:37] <stgraber> do we have firmware that messes with the value by itself? if not, then cached should be safe
[21:38] <stgraber> (thinking of some of those machines with ambient light sensors, not sure whether it's just exposed to the OS or if the actual brightness change is done by the firmware)
[21:38] <sforshee> I don't know, the code is way more careful than I'd think it needs to be
[21:38] <sforshee> it doesn't even assume that the value it got from the firmware is one of the values the firmware said is valid
[22:06] <sforshee> stgraber, even if I fix this bug your hotkeys are going to work terribly. They're going to cycle you through 100 brightness values, most of which do nothing.
[22:06] <stgraber> great...
[22:07] <sforshee> anyway I've got a patch to fix it already, so I'll spin a build to verify that I understand the problem correctly. Then I'll go back to the upstream folks and describe the problems with the solution they're asking for.
[22:18] <PatrikOlsson> Hey guys, I want to add data from a test I did for the PowerManagementALPM. How can I add this to the wiki?
[22:39] <sforshee> stgraber, http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-6.11~lp1098216v201302122215/
[22:39] <sforshee> let me know if that gets the hotkeys working, even if it is suboptimal
[22:40] <stgraber> sforshee: ok. I'll get you some results tomorrow. I'm on 3G for the rest of the day so I'll avoid any massive download :)
[22:41] <sforshee> stgraber, np
[23:47] <stgraber> sforshee: hey, looks like your kernel bricked my machine...
[23:48] <stgraber> sforshee: or rather, it apparently failed to suspend, when I noticed it was rather hot already and had a nice kernel panic on the screen. Since it won't boot at all, not getting anything from the firmware