[00:28] <lifeless> nice, it uses all cpu's by default.
[00:30] <lifeless> should I worry about things lik WARNING: drivers/char/ipmi/ipmi_si.o(.devinit.text+0xe12): Section mismatch in reference from the function init_module() to the function .exit.text:cleanup_ipmi_si()
[00:30] <lifeless> The function __devinit init_module() references
[00:30] <lifeless> a function __exit cleanup_ipmi_si().
[00:30] <lifeless> This is often seen when error handling in the init function
[00:30] <lifeless> ...
[00:39] <lifeless> herton: hi, if you're still around -
[00:40] <lifeless> II: Done
[00:40] <lifeless> install -d /home/robertc/source/linux/ubuntu-natty/debian.master/abi/2.6.38-10.46/amd64
[00:40] <lifeless> find /home/robertc/source/linux/ubuntu-natty/debian/build/build-generic/ -name \*.ko | \
[00:40] <lifeless>                 sed -e 's/.*\/\([^\/]*\)\.ko/\1/' | sort > /home/robertc/source/linux/ubuntu-natty/debian.master/abi/2.6.38-10.46/amd64/generic.modules
[00:40] <lifeless> II: Checking modules for generic...explicitly ignoring modules
[00:40] <lifeless> dh_testdir
[00:40] <lifeless> dh_testdir: cannot read debian/control: No such file or directory
[00:40] <lifeless> that was from fakeroot debian/rules binary-generic
[00:40] <herton> lifeless: ah, you must run fdr clean before building
[00:41] <lifeless> ah well, at least this box can build it in 15 minutes :)
[00:41] <lifeless> herton: /bin/bash: kernel-wedge: command not found
[00:41] <lifeless> make: *** [debian/control] Error 127
[00:42] <herton> lifeless: install the kernel-wedge package
[00:42] <lifeless> herton: sure; why isn't it in the build-deps from linux-meta ?
[00:43] <herton> lifeless: no reason that I know, file a bug for it
[00:45] <herton> the fdr clean is just needed if you are building the first time or changed something in debian.master which affects debian dir
[00:46] <herton> it just populates debian/* directory properly for the building
[00:46] <lifeless> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/805737
[00:46] <ubot2> Ubuntu bug 805737 in linux-meta "kernel-wedge not in build-dep for linux-meta" [Undecided,New]
[00:46] <lifeless> and its off building again, 34MB/s writes... wheee
[00:56] <lifeless> herton: now it wants makedumpfile :)
[00:57] <lifeless> herton: I presume I keep following the bouncing ball ?
[00:58] <herton> lifeless: hmm just report it on the same bug should be ok, one more dep to add
[00:58] <lifeless> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/805737
[00:58] <ubot2> Ubuntu bug 805737 in linux-meta "kernel-wedge not in build-dep for linux-meta" [Undecided,New]
[01:03] <herton> lifeless: this errors are on ubuntu-natty tree? I see here kernel-wedge and makedump
[01:03] <lifeless> herton: I did 'apt-get build-dep linux'
[01:03] <lifeless> herton: and it installed neither of them
[01:04] <lifeless> y$ uname -a
[01:04] <lifeless> Linux lifelessdesktop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[01:04] <lifeless> robertc@lifelessdesktop:~/source/linux/ubuntu-natty$ lsb_release -a
[01:04] <lifeless> No LSB modules are available.
[01:04] <lifeless> Distributor ID: Ubuntu
[01:04] <lifeless> Description:    Ubuntu 11.04
[01:06] <herton> debian.master/control.stub.in:Build-Depends: debhelper (>= 5), cpio, module-init-tools, kernel-wedge (>= 2.24ubuntu1), makedumpfile [amd64 i386], device-tree-compiler [powerpc], libelf-dev, binutils-dev, rsync, libdw-dev, dpkg (>= 1.16.0~ubuntu4)
[01:06] <herton> so probably else is going on, may be related to the first build
[01:06] <herton> *something else
[01:09] <herton> hmm now I see, apt-get build-deb chooses linux-meta
[01:10] <herton> *build-dep
[01:14] <herton> lifeless: I don't know if the apt behaviour, not used to all the debian related packaging stuff, just put on the bug report this detail about the apt-get build-dep
[01:15] <herton> *don't know about, damn how hard can it be typing properly...
[01:15] <herton> "apt-get build-dep linux-source-2.6.38" gets things right here
[01:16] <lifeless> herton: yeah
[01:19] <herton> the thing is, linux-meta creates a linux package, while the source name of main package is linux too, so may be apt is looking at built packages, not source names of control file
[01:23] <lifeless> yeah
[01:23] <lifeless> so I realise this is just teething issues for a new person
[01:24] <lifeless> I don't mind if yo uclose the bug won'tfix if its too hard to get a sensible glue-together of all the bits
[01:24] <lifeless> but I suspect other folk will run into traps too
[01:29] <herton> well I don't know enough to say if apt behaviour is ok, it seems to be if it doesn't look to source names, but only built package names. But the naming indeed induces to this confusion
[01:32] <herton> lifeless: oh, I think you wanted "apt-get build-dep --only-source linux" in your case
[01:33] <herton> apt is trying to be smart and does the wrong thing...
[01:34] <lifeless> herton: ahha!
[01:34] <lifeless> OTOH 500MB of deps. wtf?!
[01:39] <herton> docbook-utils seems to be pulling all the bloat (texlive and friends)
[01:39] <herton> I think if you're not going to build linux-doc, don't need to install that
[01:40] <lifeless> cool
[01:40] <lifeless> herton: any particular advice on maintaining the patch - can I just run it in a git branch and sort it out later ?
[01:41] <herton> yes, you can keep in a branch and rebasing when needed
[02:30] <lifeless> is there someway to do incremental builds with the fdr binary-generic approach ?
[02:39] <RAOF> lifeless: It should do incremental builds already?
[02:40] <lifeless> RAOF: I edited drivers/dm/dm-raid1.c
[02:40] <lifeless> RAOF: and ran fdr binary-generic again
[02:40] <lifeless> RAOF: and it did not recompile that file
[02:44] <RAOF> Hm.
[02:45] <lifeless> OTOH it builds crazy fast, so I can deal.
[02:45] <lifeless> (it just finished)
[02:48] <RAOF> Hm.  Is there a staging tree that things get copied to?  It's entirely possible; then you'd need to edit debian/builds/whateveritis/drivers/dm/dm-raid1.c
[02:48] <lifeless> no
[02:48] <lifeless> y$ find . -name "dm-raid1*"
[02:48] <lifeless> ./drivers/md/dm-raid1.c
[02:48] <lifeless> ./debian/build/build-generic/drivers/md/dm-raid1.o
[02:48] <lifeless> its probably a stamp file of some sort
[02:49] <RAOF> Oh, yeah.  That thing.
[06:52] <apw> lifeless, to do an incremental build you need to remove the debian/stamps/ file with build in its name, then fdr binary-generic should just build the changed files and repackage
[07:32]  * smb mornings
[07:40]  * apw waves to smb
[09:21] <lifeless> apw: thanks!
[10:11]  * abogani waves all
[10:12] <abogani> Anyone have tested Oneiric with closed video drivers? 
[10:12] <apw> i have heard rumours, but nothing concrete
[10:12] <apw> i would be supprised if they even compile
[10:14]  * abogani is trying to know if thirdy-part modules still working with 3.0
[10:14] <abogani> apw: Thanks anyway! :)
[10:26] <apw> tseliot, ^^ any idea if prop drivers are working on oneiric ?
[10:28] <tseliot> apw, abogani: nvidia and fglrx work fine
[10:28] <tseliot> I had to patch fglrx though
[10:28] <apw> tseliot, cool, and unexpected
[10:28] <apw> tseliot, lock kernel ?
[10:28] <tseliot> apw: yep
[10:29] <apw> tseliot, did you make it its own private mutex ?
[10:29] <tseliot> apw: yes, and it seems to work well
[10:30] <apw> tseliot, nice
[10:30] <tseliot> :)
[10:31] <abogani> tseliot: Thank you very much!
[10:31] <tseliot> np
[10:32] <apw> tseliot, the design team owe you some beer me thinks
[10:32] <tseliot> hehe
[11:13] <seif> hey guys
[11:13] <lifeless> success:
[11:13] <lifeless> sda              88.60  1025.40   54.80   20.80   578.40  3812.00   116.15     1.10   15.79    5.80   42.12   4.50  34.00
[11:13] <lifeless> sdb              45.40  1024.80   28.60   21.40   300.00  3876.00   167.04     1.41   31.32    3.99   67.85   3.56  17.80
[11:13] <lifeless> sdc              52.80  1018.60   36.80   27.80   363.20  3382.40   115.96     1.02   14.43    8.75   21.94   5.33  34.40
[11:13] <lifeless> sdd              37.20  1014.60   29.40   33.80   268.00  4194.40   141.22     0.78   14.15    2.93   23.91   1.84  11.60
[11:13] <seif> hey guys
[11:13] <lifeless> (load balanced dm-raid raid 1+0 config)
[11:13] <lifeless> seif: hi
[11:13] <seif> for some reason my volume buttons on the thinkpad dont work anymore on oneirick
[11:13] <seif> hwoever i can capture their events being pressed in the keyboard configuration
[11:14] <apw> seif, it is always best to just ask what you want to ask, as then the people who know things know whether to pay attention
[11:14] <seif> but they dont really lower or raise the volume
[11:14] <seif> is this a kernel issue
[11:14] <apw> seif, which thinkpad model
[11:14] <seif> or a de issue
[11:14] <seif> x201
[11:15] <apw> hmm, well if you can see the key presses in input-events somewhere and they are marked as volume up down events then its not the kernel
[11:15] <apw> https://wiki.ubuntu.com/Hotkeys/Troubleshooting
[11:16] <apw> seems to be the place for how to figure this out
[11:16] <seif> yeah
[11:16] <seif> apw, thanks
[11:17] <lifeless> apw: how much overhead is a printk(KERN_DEBUG
[11:17] <apw> lifeless, all depends on whether loglevel is high enough to emit it
[11:17] <lifeless> apw: so nearly-free when loglevel is low ?
[11:17] <apw> if its not then pretty low, though you still have a subroutine jump and an if
[11:18] <apw> so it depends if those are large compared to your code or not
[11:19]  * apw looks smugly at the open cve bugs which are now closed correctly against invalid releases
[11:19] <lifeless> ok, well I think I'll leave them in my patch and the reviewer can tear em out if needed
[11:20] <apw> lifeless, i guess they are still being recorded in the dmesg, and potentially in syslog as a result
[11:20] <apw> just not polled out to the real console.  so it depends really on how much they produce
[11:21] <lifeless> apw: presumably not if the level is disabled ?
[11:21] <apw> are they just making dmesg lose meaning by their quantity
[11:21] <apw> lifeless, i am pretty sure they are in dmesg now i think abou tit
[11:21] <lifeless> I'll double check
[11:22] <lifeless> apw: I've implemented a load balance routine for dm-raid1 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733
[11:22] <ubot2> Ubuntu bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,New]
[11:23] <lifeless> apw: I have the printks in the mapping logic, which is called once per unmerged I/O
[11:24] <lifeless> my first version caused no IO merging to go on
[11:24] <lifeless> which is why I did a more complex version and started printking
[11:25] <apw> i suspect they are going to be recorded, i also suspect you can confirm they are merged using blktrace
[11:25] <lifeless> iostat shows merging happening :)
[11:25] <lifeless> what I was doing in the first version was round-robin
[11:26] <lifeless> on sequential IO this lead to a small read (e.g. 8 sectors) from target 1, then from target 2, then target 1
[11:26] <apw> heh ouch and thats going to hurt indeed
[11:26] <lifeless> it performed terribly :)
[11:27] <lifeless> now I keep track of the last sector a read was dispatched to from the mirror set per target, and prefer the closest 
[11:27] <lifeless> I get pretty good balancing doing the incremental kernel build on each reboot
[11:27] <lifeless> and sequential IO is unaffected - 100M sustained comes from just one target
[11:36] <lifeless> apw: patch attached FWIW; whats the normal process to get them looked at ?
[11:37] <apw> well normally you'd be asked to send them to the driver maintainer, but if you want a review before then we can help
[11:37] <apw> (unless its for an ubuntu only driver)
[11:37] <lifeless> AIUI upstream fakeraid list is totally dead
[11:37] <lifeless> this may have changed
[11:38] <apw> someone must know who is owning it now, even if maintainers is out of date
[11:38] <apw> and if its not it likely falls back to the io maintainer etc
[11:39] <lifeless> ok
[11:39] <lifeless> well, I'm happy to do a modicum
[11:39] <lifeless> my primary itch scratching is now complete however
[11:41] <lifeless> hmm, that came out wrong
[11:41] <lifeless> what I mean is, if the upstream want lots of changes, I can't commit to doing that in a short term time frame
[11:41] <apw> yep
[11:42] <apw> well if you are unsure of quality and want some instant feedback you could send it to the ubuntu kernel-team list saying you are planning to upstream this and would people review it 
[11:45] <ohsix> fakeraid or "ataraid" ?
[11:45] <lifeless> ohsix: dm-raid1 specifically
[11:45] <ohsix> since the userspace tools assemble them with plain dm methods
[11:45] <lifeless> ohsix: which is 'fakeraid' for the folk that don't like it :)
[11:46] <lifeless> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361733/+attachment/2192144/+files/raid1-loadbalance.patch
[11:46] <ubot2> Ubuntu bug 361733 in linux "dmraid(fakeRAID) raid1 driver doesn't loadbalance reads" [Undecided,New]
[11:46] <ohsix> i missed the rest of the chat, but the stuff still works
[11:46] <lifeless> apw: whats the list address to send to?
[11:47] <ohsix> you can do that with lvm and i don't see the utility in not just doing that, unless you want the volumes acessible on windows or something
[11:54] <lifeless> ohsix: thats an entirely different discussion
[11:54] <smb> lifeless, dm-devel@redhat.com might be a generic ujpstream for that. Not sure how much they do atm as the last thing I heard was them wanting to have dm-raid replace dm-raid45 and not much had happened
[12:00] <lifeless> apw: mail sent; I'm sure it will go into moderation.
[12:00] <lifeless> smb: looks like they are, yes.
[12:01] <apw> herton, do you know how to produce the summary for the weekly meeting for stable ?
[12:02] <herton> apw: nope
[12:02] <apw> ok
[12:02] <smb> one less topic on the meeting which is maybe ( not) happing
[12:14] <apw> smb, interestingly i may have worked out how to make it
[12:14] <apw> though hardy is missing
[12:14] <apw> oh no, it is there, so perhaps
[12:14] <smb> hm, if its only pending ones maybe there is just nothing there atm
[12:15] <apw> i _think_ i have it generated, so i will document it very badly and let bjf et al fix it
[12:16] <herton> apw: I was looking here, may be sru-report + generate-meeting-status ?
[12:17] <apw> herton, i am suspicious that that is the incantation myself
[12:17] <apw> herton, the output of the second one seems right ish
[12:19] <smb> apw, herton http://reports.qa.ubuntu.com/reports/ogasawara/kt-meeting.txt may be the thing
[12:19] <smb> though http://kernel.ubuntu.com/~kernel-ppa/reports/kt-meeting.html is the documented link
[12:20] <apw> smb, good spot
[12:21] <smb> apw, Was in the README in kteam-tools/irc-meeting
[12:22] <apw> herton, perhaps you could update that README to include how to generate the stable update
[12:23] <herton> apw: ok, will take a look here, also I have to write a status update I think
[12:23] <herton> the "[12:23] <apw> herton, well do what you can and don't sweat it if you don't know something
[12:24] <apw> herton, the key thing is to know we don't know this time and then you can ask bjf/sconklin for next time
[12:24] <herton> ok
[12:24] <apw> ie. don't worry if you only have 'no update' for any section
[12:24] <apw> it seems like we have the bug stats and the overall stats
[12:24] <apw> smb, shall we decide we'll muddle the meeting and learn from the missing bits 
[12:25] <apw> herton, so if all you have is the output that we've just found for the stable team thats fine, we'll live
[12:25] <smb> apw, Its probably a oportunity to find out what we do not know
[12:25] <apw> smb, if we go for the meeting can i let you paste in the bugs info 
[12:26] <smb> apw, ok, sure
[12:26] <apw> right i'll send out the late annoucnement it is still on
[12:26] <apw> **
[12:26] <apw> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[12:26] <apw> **
[12:36] <ogra_> rtg_, yo !
[12:38] <tgardner> ogra_, yo
[12:38] <ogra_> could we get an omap4 meta upload ? 
[12:38] <apw> bouncy tgardner 
[12:38] <ogra_> you uploaded a new image but no meta apparently
[12:38] <tgardner> ogra_, for natty or oneiric ?
[12:38] <ogra_> oneiric
[12:38] <tgardner> ogasawara, ok, gimme a bit
[12:38] <apw> ogra_, you should have mentioned it yesterday 
[12:39] <ogra_> apw, i didnrt notice it yesterday
[12:39] <ogra_> sorry for that, there was another build failure hiding it
[12:40] <ppisati> it's still based on natty kernel, isn't it?
[12:40] <ogra_> sure, still, the image builder uses the meta pacdkage to roll images
[12:40] <ppisati> ok
[12:41] <ogra_> that currently depends on an older version
[12:41] <ogra_> so image builds fail
[12:41] <tgardner> apw, there isn't a branch for ti-omap4 in ubuntu-oneiric-meta. have I just not had enough coffee yet ?
[12:41] <apw> tgardner, that is very likely, my bad i suspect as it was me who updated oneiric ti-omap4
[12:42] <tgardner> apw, maybe you can fix that ?
[12:42] <apw> tgardner, sure 
[12:54] <apw> ogra_, tgardner pushed and uploaded
[12:55] <ogra_> awesome, thanks !
[12:57] <tgardner> apw, thanks
[13:11] <herton> apw, smb: I think this summarizes everything on the stable side for the meeting: http://pastebin.ubuntu.com/638415/
[13:12] <apw> herton, that looks very good, are you good to paste that in for the team status and the table in for the 'Security and bugfix kernels' sections of the meeting
[13:12] <herton> apw: yep, can do that
[13:13] <smb> +1 (and /me is looking at the hardy srus right now)
[13:13] <apw> awsome, sounds like we are covered then ...
[13:16] <herton> apw: the statistics, I think you already got the same as this: http://pastebin.ubuntu.com/638418/
[13:16] <herton> should I care about it or you will handle it?
[13:16] <herton> *will you
[13:19] <apw> herton, as i will be running things its easier to get you to shove that it in if thats ok, prevents me getting rate limited by floodbot
[13:20] <herton> ok, will paste that as well then
[13:20] <apw> herton, excellent thanks
[13:20]  * apw lunches
[13:20] <tgardner> oneiric unity seems to be ill this AM. lots of notifiers crashing
[13:27] <herton> apw: when you're back, if you happy with this:  http://pastebin.ubuntu.com/638419/ then I send the patch to you to apply on kteam-tools (for the irc-meeting readme)
[13:32] <tgardner> ogasawara, updating tangerine chroots with new binutils and gcc. 
[14:04] <smb> tgardner, Are you talking to ogasawara or just suffer from nick-completion rot and want ogra_ ?
[14:05] <tgardner> smb, no, I just forgot she was on vacation this week
[14:05] <smb> ah :)
[14:17] <apw> tgardner, heh
[14:18] <apw> herton, looks like a good start indeed, zap it over
[14:36] <bjf> apw, so you've decided to have the meeting?
[14:36] <apw> bjf, yep, seems we have foudn the stable data we need so seemed fine to continue
[14:37] <bjf> apw, i'm sending you my runes
[14:37] <apw> bjf, we decided that we'd work out what was missing, find what we need, and leave anything we don't know out with an action to document how its gotten for next time
[14:37] <apw> bjf, though i think we found everything in the end
[14:37] <apw> bjf, thanks
[14:38] <apw> bjf, i may have to leave pushing the output to the blog until you gtet back as when i login to WP it dies in a heap, #is is on the case but i am not hopeful
[14:38] <herton> apw: ok
[14:38] <bjf> apw, not a problem
[14:39] <apw> but that i couldn't do it was highlighted by wanting to for this (well and the onieirc upload announcement)
[14:40] <bjf> apw, when you logged in did you happen to end up and an "Array" page?
[14:41] <bjf> apw, http://voices.canonical.com/kernelteam/Array  ?
[14:42] <apw> bjf, no i get a whole different "Internal Server Error" explosion, which seems to be triggered by some script exploding at the other end
[14:42] <bjf> apw, sweet!
[14:42] <apw> had them rather dazed and confused at the other end, smb i think is also affected
[14:42] <smb> Though I get a blank page (or got)
[14:43] <apw> different fun for everyone, though no way to do anything here.  seemed that they could see it breaking at the server
[14:44] <tgardner> apw, I think its time to extend the oneiric version to 3 digits prior to the next upload, and before the first beta.
[14:44] <smb> apw, Oh today I seem to be at the 404 error too
[14:45] <smb> apw, bah no. just mistyped the login page
[14:46] <apw> tgardner, its likely the time to do it if one is going to i agree.  and i can't really think of a good reason not to, i do wonder if we should be using the full stable version when we get to having those
[14:46] <apw> though we have an alpha-3 right ?
[14:46] <tgardner> apw, can't remember if we have an A3
[14:47] <tgardner> I'm just noticing what carnage oneiric is causing on older user spaces.
[14:48] <apw> tgardner, yeah, can't fault the logic there, and i think debian already did it wrong and committed themselves to 3.0.0
[14:48] <tgardner> apw, I expect the full stable version will be 3.0.1, 3.0.2, etc.
[14:49] <apw> tgardner, right thats what he implied, i mean should we be 3.0.0-1 and then 3.0.1-2 when we have stable, or is that still 3.0.0-2
[14:50] <tgardner> apw, I think we can wait to see what greg k-h does 'cause either case will work for us.
[14:50] <apw> i mean in the case that greg does use 3.0.1 do we change our prefix to that or remain at 3.0.0 regardless
[14:51] <apw> in the past we have not changed the prefix for stable, but that mattered not as we were not saying anything about the stable version number
[14:51] <apw> but now we will be, we'll be implying its 0 if we don't bump our prefix
[14:51] <apw> but it implies an abi bump when there may not be one
[14:52] <tgardner> apw, I guess we should stick with 3.0.0 since we don't always adopt _all_ of the stable patch set.
[14:52] <apw> tgardner, that at least may save some of the tools from death
[14:54] <tgardner> apw, plus its more aligned with our usual version processing
[14:55] <apw> tgardner, i cannot fault the logic of using 3.0.0 and i suspect even if we might want to use 3.0 its probabally better to switch for PP rather than oneiric
[14:56] <tgardner> apw, hmm, whatever we do for oneiric is going to establish the precedent. I don't see us changing the version scheme for an LTS.
[14:57] <tgardner> e.g., lets just adopt the 3 digit version scheme and be done with it.
[14:57] <apw> tgardner, ok ... i'll put that together then shall i
[14:58] <tgardner> apw, wfm
[15:01] <herton> bjf: I sent apw some notes, I think apw can replace that with your notes then. Here is what I sent: http://pastebin.ubuntu.com/638415/
[15:02] <Lekensteyn> Hi all, how do I debug a defunct Fn key? I've already tried https://wiki.ubuntu.com/Hotkeys/Troubleshooting but it seems that the kernel does not recognise the shortcut. I've a Clevo B7130 laptop
[15:03] <bjf> herton, looks good to me, he should use yours
[15:03] <herton> ok, I'll paste that in the meeting
[15:05] <herton> the statistics we saw that sru-report + generate-meeting-status created them, irc-meeting/README has some notes about it now (kteam-tools)
[15:11] <apw> it all sounds sorted, and bjf should go back to being on vacaction and let us fail :)
[15:22] <apw> Lekensteyn, so you've confirmed its not producing any events under input-events and nothign in acpi ?
[15:24] <Lekensteyn> @apw: I used `acpi_listen`, `xev` and `/lib/udev/keymap` and `udevadm monitor`, but none of them generates output from Fn+F8 or Fn+F9 (change brightness) Fn+F5 (change volume) works however
[15:25] <apw> Lekensteyn, i think the one thing left to try is input-events, run that on each of the channels listed in ls-inputs and see if any producs anything for those keys
[15:25] <apw> sometimes they are on the most illogical channel, like on the graphics card or somewhere stupid
[15:30] <Lekensteyn> @apw: I tried all of them, (0-8), but none of them responded to the fn+f8/9 shortcut
[15:31] <apw> Lekensteyn, then its a kernel driver thats needed to make them work probabally, though without someone who knows the h/w telling us how they work we are in the dark.
[15:31] <apw> Lekensteyn, thats assuming they haven't worked in the past
[15:33] <Lekensteyn> @apw: I'm willing to help getting it to work, what information do you need? Fn F[89] has never worked here
[15:34] <Lekensteyn> Should I file a new bug report about it?
[15:34] <apw> Lekensteyn, well thats the problem if they have never worked and nothing is obviously coming out of anywhere its very hard to know where we should be looking for an indication they have been pressed
[15:34] <apw> Lekensteyn, sure, its not obvious if anyone can fix it who doesn't work for the manufacturer though
[15:37] <Lekensteyn> @apw: would a keylogger described at http://www.phrack.com/issues.html?issue=59&id=14#article help to get the required information? If I contact the manufacturer, what should I ask from them?
[15:38] <apw> Lekensteyn, its not obvious how that keylogger would help
[15:38] <apw> Lekensteyn, how their hot keys are exposed
[15:38] <apw> Lekensteyn, do any hotkeys work on this thing?
[15:40] <Lekensteyn> Yes, the fn hotkeys for LCD/touchpad/screen/wifi/webcam/bluetooth toggle, volume adjustment, sleep and mute all work, it's just the brightness thing that is broken
[15:41] <apw> Lekensteyn, then there is some hope, put all that in the bug, also try and find one of the working keys and report where that comes through
[15:41] <smb> tgardner, Hm, contrary to my belief I do not seem to have any hardware with Intel e1000e other than 82574L in my place. Would you happen to have something on your side?
[15:43] <tgardner> smb, not any more.
[15:43] <smb> herton, all hardy srus are verified, though I left one in needed state to give the original reporters a chance
[15:43] <herton> smb: nice, thanks
[15:44] <tgardner> smb, I think the regression risk is likely pretty low.
[15:45] <smb> tgardner, I would guess so as well as it directly comes from Intel as their supported driver.
[15:45] <smb> plus LBM is opt-in / best-effort...
[15:46] <tgardner> smb, applying...
[16:08] <apw> **
[16:08] <apw> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:08] <apw> **
[16:08] <apw> ** that is in approximatly 50 minutes
[16:08] <apw> **
[16:08] <Lekensteyn> @apw: I've reported the bug at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/806032
[16:08] <ubot2> Ubuntu bug 806032 in linux "Fn + F[89] does not work for controlling brightness" [Undecided,New]
[16:10]  * herton --> lunch, back in 30min
[16:19] <smb> jjohansen, Hi just since there is another alpha coming up. Is there anything new in seccomp patch world?
[16:22] <jjohansen> smb: its progressing but hasn't made it to a point that upstream has accepted it
[16:22] <smb> jjohansen, Hm, though that sounds as if we could set the work-item at least to inprogress...
[16:23] <jjohansen> smb: so we are watching it but its getting to the point that for natty we may do nothing
[16:23] <jjohansen> smb: yeah
[16:23] <smb> jjohansen, done. :)
[16:24] <jjohansen> smb: thanks
[16:25] <smb> apw, Actually, do you remember what we decided about using only links for some of the longer lists in the irc meeting?
[16:25] <apw> i think we decided we didn't care if it was long people wanted to see something in it
[16:26] <smb> Ok, just cannot remember. There past is somewhat hazy before last Saturday... 
[16:28] <apw> ok i have managed to fix editmoin (with some help from james_w) and have pushed a fixed version here: http://people.canonical.com/~apw/misc/editmoin
[16:29] <apw> you will still need to update your cookies as they have changed, and the names of those cookies are different from before and different for wiki.ubuntu.com and wiki.canonical.com
[16:29] <apw> smb, ^^
[16:30] <smb> apw, not sure I got any as I never had a successful login
[16:30] <apw> smb, you can no longer login to the wiki ?
[16:30] <smb> err forget it I confused it with voices
[16:30] <smb> Not using editmoin though
[16:30] <apw> ahh yes that heap is broken
[16:30] <apw> oh then you don't care :)
[16:31] <smb> only little. :)
[16:58] <apw> ** team meeting starting over on #ubuntu-meeting
[16:58] <smb> -2
[17:05] <skaet> ogasawara, https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview has been restored.
[17:08] <skaet> apw, ^
[17:32] <apw> does anyone have the Ireport which is needed for irc2moin ??
[17:34] <apw> in which case .... bjf gets to handle it
[17:35] <cking> you'd think it would be documented somewhere..
[17:37] <apw> cking, it is, it says run irc2moin, which dies in a heap as Ireport is missing
[17:37] <apw> cking, fail ... i've punted the input data to him hopefully it'll get checked in
[17:44] <cking> doh
[17:47]  * cking crunches another several thousand LP bugs in fwts and watches his CPU catch fire
[17:53] <apw> cking, that sounds like fun
[17:54] <cking> apw, did you see my email today concerning the automagically generated output from all those bugs?
[17:54] <apw> cking, which bugs ?
[17:55] <cking> apw, the kernel related bugs in LP
[17:55] <apw> i see something about BIOS bugs ?  that or something else ?
[17:56] <cking> yep that one
[17:56] <cking> ~7K of bugs analysed by fwts
[17:57] <apw> it looks horriffic for some bios makers
[17:57] <cking> a lot of it is stupid low-level mistakes
[17:58] <apw> stupid mistakes makes stupid explosions
[18:00] <cking> more like subtle weirdnesses
[18:00] <cking> I think I can summarise: a lot of BIOS vendors produce crack
[18:02]  * tgardner --> lunch
[19:20] <jjohansen1> ->lunch
[19:24] <cking> tgardner, ping
[19:25] <tgardner> cking, dude
[19:25] <cking> tgardner, I'm being a bit dense today, I cannot find the committed patches for bug 755066
[19:25] <ubot2> Launchpad bug 755066 in oem-priority "Heavy I/O on Sandybridge systems with small memory footprints causes system hangs" [Critical,Fix committed] https://launchpad.net/bugs/755066
[19:26] <cking> ..they are marked 'fix committed' by you - where are they in the repo?
[19:26] <tgardner> cking, was that natty?
[19:26] <cking> yep
[19:27] <tgardner> cking, 2e5b4f6c66b664844dde76534dfc5078acab4e12 and a8ead4fb194c86fac770c706dcf5b8a8fd3b2939
[19:27]  * cking double checks - thanks
[19:28] <tgardner> cking, I searched for the BugLink number
[19:31] <cking> that's a darn easy way of finding it. doh
[19:36]  * cking forgot it's in master-next
[19:36] <cking> double doh
[19:36] <tgardner> cking, yep, those haven't been built for -proposed yet
[19:36] <cking> I'm ahead of myself 
[19:45] <sforshee> tgardner, will you accept nominations on bug 771758 ?
[19:45] <ubot2> Launchpad bug 771758 in linux "acer-wmi prevents wifi (bcmwl/brcm80211) from working" [Medium,In progress] https://launchpad.net/bugs/771758
[19:46] <tgardner> sforshee, done
[19:46] <sforshee> thanks tgardner 
[20:03] <cking> yawn
[20:04] <apw> cking-afk: go home
[20:04] <cking-afk> i am home
[20:04] <apw> go further away from the keyboard
[20:04] <cking-afk> ..and I was having so much fun too
[21:47] <neuro_sys> it is not possible to read/write 0xa0000 by mmap'ing /dev/mem right?
[21:47] <neuro_sys> unless it's CONFIG_STRICT_DEVMEM=n for kernel config?
[21:47] <ohsix> yep
[21:48] <neuro_sys> I just couldn't find what range of memory is exactly forbidden in /dev/mem.
[21:49] <neuro_sys> other than my dmesg reporting: [100842.511642] Program cat tried to access /dev/mem between 100000->108000.
[21:49] <ohsix> it's all of it but pci or something, been a while since i looked
[21:50] <mjg59> neuro_sys: Depends on the architecture
[21:50] <mjg59> On X86 you can read anything that is either the first 1MB or that isn't RAM
[21:50] <neuro_sys> on x86, speaking of 0xa0000 for video ram.
[21:50] <mjg59> neuro_sys: arch/x86/mm/init.c
[21:51] <mjg59> devmem_is_allowed()
[21:51] <mjg59> You have to be able to read/write video RAM there because X
[21:51] <ohsix> yar the help text says it only allows access to memory mapped peripherals
[21:51] <ohsix> mjg59: thanks
[21:53] <ohsix> http://lxr.linux.no/linux+*/arch/x86/Kconfig.debug#L8
[21:55] <neuro_sys> the part that says "If this option is switched on, the /dev/mem file only allows userspace access to PCI space and the BIOS code and data regions." makes me still wonder 0xa0000 is permitted.
[21:55] <neuro_sys> apparently not, anyway.
[21:55] <neuro_sys> because the option is yes here, and I still get segfault when trying to write there.
[21:56] <neuro_sys> gotta siwtch it off. not worth recompiling the kernel though :P
[21:57] <mjg59> That's mmap_min
[21:57] <ohsix> that's not assigned to my video card here, i used to know the relationship with those legacy addresses D: it should be accessible as a bios area though
[21:57] <mjg59> Put something smaller in /proc/sys/vm/mmap_min_addr
[21:58] <ohsix> wasn't the 0xa address for a hercules addin card ;]
[21:59] <ohsix> what are you trying to do anyways
[22:00] <neuro_sys> it's the video ram for vga mode (mode 13h).
[22:00] <neuro_sys> http://en.wikipedia.org/wiki/Mode_13h
[22:00] <neuro_sys> :D
[22:00] <neuro_sys> actually was playing around with libx86 
[22:00] <neuro_sys> it switches to vga mode using bios interrupts, but you just can't write pixels to 0xa0000 
[22:01] <ohsix> you've got an extra 0 too
[22:02] <neuro_sys> umm, that I guess has to do with real mode segmentation? it's 0:a000 normally if I'm not mistaken.
[22:02] <neuro_sys> hence the extra 0.
[22:02] <ohsix> maybe with libx86, i dunno
[22:02] <neuro_sys> yeah better check that as well
[22:03] <ohsix> or you could ask mjg59
[22:03] <ohsix> since http://www.codon.org.uk/~mjg59/libx86/
[22:04] <neuro_sys> LOL
[22:04] <neuro_sys> geez
[22:05] <xiackok1> aahha mjg59 is online
[22:05] <mjg59> Oh yeah sorry about libx86
[22:06] <mjg59> That one's my fault
[22:06] <mjg59> I really ought to fix it so it doesn't try to map the zero page
[22:06] <mjg59> There's no reason for it to
[22:06] <neuro_sys> :D heh it's okay, lol didn't know you were the author
[22:06] <xiackok1> ahah its very nice
[22:06] <mjg59> But if you just clear mmap_min_addr things should work for you for now
[22:08] <xiackok1> ok its done
[22:08] <xiackok1> but i didnt anything about
[22:08] <xiackok1> mmap_min
[22:08] <xiackok1> its just writes on 0xa0000
[22:08] <xiackok1> its my mistake i just write wrong mem address
[22:09] <neuro_sys> oh cool then