[02:15] <mfilipe> how do I do to get .config of oneiric kernel?
[02:16] <mfilipe> my kernel is 32bits-pae 
[02:17] <Sarvatt> mfilipe: /boot/config-3.0.0-whatever-generic
[02:17] <mfilipe> Sarvatt, thanks a lot! :)
[02:17] <Sarvatt> replace whatever with a number of course, dont know what kernel you're using :)
[02:23] <mfilipe> Sarvatt, default... 3.0.0. I found the config
[02:23] <mfilipe> ;)
[07:38]  * smb yawns
[08:30] <TeTeT> a customer reports random freezes on x220 (sandybridge) with 10.04 and lowell and natty-backports-lts kernel. Is there any magic sysreq thing I can ask them to run to gather useful info from the crashed systems?
[08:34] <smb> TeTeT, Depends a bit on what really happens. Is it freezing (desktop only or whole system) or a crash. First may show not much and if the whole system is frozen, the sysrq keys don't work either.
[08:35] <TeTeT> smb: ok, seems system is completely frozen, e.g. ssh doesn't work any longer. Only at times the mouse pointer remains moveable
[08:36] <smb> TeTeT, So one thing to try could be to ssh in before and do a tail -f on the syslog and hope to catch something there.
[08:36] <TeTeT> smb: ok, good thing to monitor in real time, I'll suggest that, maybe using the remote option of rsyslog as well
[09:11] <ppisati> morning
[09:13] <cking> morning
[09:14] <smb> morning
[09:15] <smb> cking, You know what, I fixed the jumbled characters in my battery readout that caused udev to go wild...
[09:21] <cking> smb, how?
[09:22] <cking> smb, was this a user space fix or in the kernel?
[09:22] <smb> cking, Removing the battery for a while... Now the strange characters are gone... :/
[09:22] <cking> oh
[09:23] <cking> that's kinda amusing
[09:23] <smb> So it was a hardware fix... :-P
[09:24] <cking> still, the udev issue still needs to be fixed IMHO
[09:24] <smb> Wished I had thought of that last week. Would have saved me the annoying stop/start cycles on udev
[09:24] <smb> I tend to agree, there must be a way to stop a call that has a permanent issue instead of repeating it 
[09:31] <apw> jjohansen, hello
[09:32] <smb> morning apw
[09:32] <apw> morning
[10:47] <Kano> hi apw , could you take a look in pata_of_platform.c ?
[10:48] <Kano> apw: it seems there must be a 32 bit error?
[11:32] <ppisati> herton: hold on for the omap4 kernel, i'm respinning it
[11:35] <herton> ppisati: ok, it's ok to respin it, that problem in the changelog should be fixed
[11:36] <ppisati> herton: yep, but Tim pushed the Linaro revert on top of the previous version, let inclue that patch too
[11:36] <ppisati> *let me include
[11:37] <herton> ppisati: ok, see if there is an abi change needed also because of the change, may be not, I'm not sure but I think abi check is enabled for this one (only disabled for armhf from what I saw yesterday)
[11:38] <ppisati> no abi changes
[11:38] <herton> ok cool
[11:57] <ppisati> herton: ok, all done
[11:58] <herton> ppisati: ack, thanks
[11:58] <ppisati> herton: and it passed the verify-release-ready test
[12:19] <herton> ppisati: tim pushed the patch to you? it misses the signed-off (may be I'm being too pedantic now)
[12:32] <ppisati> herton: nope, it's alreadi in ubuntu-oneiric/ti-omap4
[12:33] <ppisati> (why kernel.ubuntu.com is always so slow????)
[12:34] <herton> ppisati: indeed, I forgot to fetch
[12:34] <ppisati> git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git ti-omap4
[12:35]  * ppisati goes to find something for lunch...
[13:02] <apw> cking, about ?  wondering about resurecting the kernel power consumption blueprint, as a bucket for your workitems
[13:02] <apw> seems the logical thing to od
[13:56] <tgardner> ogasawara, given Rick's test policy, do you suppose we should delay uploading precise until about -rc2 ?
[14:02] <ogasawara> tgardner: that sounds safer
[14:02] <tgardner> ogasawara, shall I rebase against -rc1 ? I'd like to get some master-next testing under way
[14:02] <smb> Though potentially that policy does not apply to us as I think they say Ubuntu developed sw
[14:03] <ogasawara> tgardner: go for it
[14:03] <tgardner> smb, folks will howl anyways if we break their kernel
[14:04] <ogasawara> tgardner: gimme 5min to push the reverted ntrig patches
[14:04] <tgardner> ogasawara, ack
[14:04] <smb> tgardner, That is true. Even more if it stops booting... So to wait an rc sounds like a save play
[14:07] <smb> tgardner, Btw, not sure whether you would still look at it but 2.6.32.47 feels like soon being followed by a fixup .48. Some patches seem to break builds...
[14:08] <tgardner> smb, yep, saw that. armel failure, right ?
[14:08] <smb> tgardner, Well that and an allmodconfig explodes on my amd64 build in some soc module
[14:09] <tgardner> smb, if it builds for our configs, and doesn't break omap3, then its likely still worth applying.
[14:10] <ogasawara> tgardner: pushed
[14:11] <tgardner> ogasawara, ack
[14:12] <smb> tgardner, Not sure whether we would hit those (well the first one likely). I have not yet tried any builds on our side. I'd probably delay until it is fixed, then I can push a fixed up drm33 and we could use that one.
[14:13] <tgardner> smb, do you have some drm patches for this next stable update ?
[14:13] <smb> There is two drm fixes from Debian that I would add as well. And then it might just be one run on the formal (tracking side)
[14:13] <tgardner> ok
[14:14] <ogasawara> tgardner: fwd'd you a patch from apw to fix a 3.2-rc1 build failure
[14:14]  * smb finds it scary to start answering tgardner questions before he asks them...
[14:14] <tgardner> smb, she's just that good
[14:15] <smb> tgardner, I do not count me as a she... ;-P
[14:15] <tgardner> smb, thought you were talking about ogasawara
[14:15]  * apw looks vague
[14:16] <smb> Nah, I was typing the answer to the drm question when you asked it
[14:16] <smb> Of course I am not that fast of a typist so I did not beat you on pressing enter
[14:16]  * smb wonders whether he needs to slap apw...
[14:16]  * apw sends smb a typing tutor
[14:17] <apw> smb, always
[14:17] <tgardner> apw, how's the custom binary maintenance prototype coming? this epoll patch continues to clog my folder.
[14:17] <apw> tgardner, heh i was just checking that branch out ...
[14:49] <ppisati> tgardner: can you install u-boot-tools on tangerine inside the oneiric-amd64 chroot? need it to create the uImage kernels for arm (when i'm building from vanilla)
[14:52] <tgardner> ppisati, done
[15:05]  * ogasawara back in 20
[15:59] <apw> tgardner, ok so i have a prototype basically working.  i am a little concerned about the semantics
[16:00] <apw> tgardner, essentially we have two options, either clean creates the patches, or we have a 'refresh' option you use for this function
[16:00] <apw> in the first instance things are automatic, but local test builds you need to know you need to push the dependant branches also
[16:01] <apw> in the latter you need to know to refresh them when changing things, which can be inforced at insertchanges time
[16:01] <apw> but testing is much more 'as it is now'
[16:02] <smb> I'd tend towards the refresh option...
[16:03] <ogasawara> are we having a meeting today?
[16:03] <apw> ug i hope not :)
[16:03] <smb> It would be in one hour, or?
[16:03] <apw> bjf, is the master of all things meeting
[16:03] <bjf> ogasawara, who would run it?
[16:04] <ogasawara> bjf: I don't know if we actually decided who's running the meetings now
[16:04]  * jussi waves to ogasawara
[16:04] <apw> oh did bjf abdicate ?
[16:04] <ogasawara> apw: he did
[16:04]  * ogasawara waves to jussi 
[16:04]  * smb missed that, too
[16:05] <ogasawara> I don't think it was widely circulated that he stepped down from being the chair
[16:05] <apw> well i am pretty sure noone wants to do it, so perhaps we need to return to a rotating chair
[16:05] <ogasawara> I vote that we postpone till next week.  I'll chair.
[16:06] <bjf> ogasawara, smb and apw were at the same table with me at plumbers when i made the statement :-)
[16:06] <apw> ok, works for me.  we need to make sure its nice and documented to the untrained eye so we can rotate it
[16:06] <smb> bjf, probably too drunk then... :-P
[16:06] <apw> plmbers, plumbers, you expect me to remember that far back ?
[16:07] <bjf> smb, could be though it was in the a.m. at the hotel
[16:08] <cking> I recall bjf saying it
[16:08] <smb> bjf, Oh, morning bah... 
[16:09] <jussi> DO you peoples use the meeting bot for your meetings?  (meetingology) 
[16:09] <apw> cking, heh then you should have reminded us :)
[16:09] <apw> jussi, yep
[16:09] <bjf> jussi, the new bot sucks
[16:09] <cking> ...and I thought "if it I join the kernel team it means somebody as disorganised as me running the meeting == fail"
[16:09] <jussi> bjf: how so?
[16:09] <bjf> jussi, the output is ignored
[16:09] <jussi> bjf: more specific pleasE? 
[16:10] <apw> it does tend to stomp all over what you are trying to read by repeating everything and chainging the topic all the time
[16:10] <bjf> jussi, we developed our own scripts for deailing with the meeting output, the bot doesn't come close to producing the same, so I/we just ignore it
[16:10] <apw> quite why it does that i am unsure
[16:10] <jussi> bjf: and if there are specific issues, bugs would be super. 
[16:11] <apw> for me the issue it about once a year we get a new format out of it
[16:11] <jussi> bjf: so you dont like the wiki output the bot makes? 
[16:11] <jussi> AlanBell: ping
[16:11] <apw> which is just a pain.  we already had to make something make what we wanted to cope with the old
[16:11] <bjf> jussi, no, it's not helpful
[16:11] <jussi> (AlanBell is the author fyi)
[16:12] <bjf> jussi, i explained this to AlanBell
[16:12] <apw> bot, so ... we just continue to do the same and we are bot agnostic
[16:12] <jussi> strange. I find it most helpful. 
[16:12] <apw> do you push many tables through it ?
[16:13] <jussi> No...
[16:13] <jussi> I guess IRC team meetings are very different to kernel meetings ;)
[16:13] <bjf> jussi, the bot grabs the topic changes but then just adds the raw irc log at the end, i don't find that usefull
[16:17] <jussi> bjf: As I said, Im sure bugs would be helpful - perhaps in the future we can create modes in it so theres a mode that puts the output to a style that works better for teams with this kind of meeting. 
[16:17] <bjf> jussi, as i said, i discussed it with AlanBell, he didn't see it as bugs, i'm more than happy to keep doing what i'm doing
[16:19] <apw> often trying to make something do everything is a recipe for disaster
[16:20] <apw> bjf, does the new bot at least give us the beginning and end so we can find the poo to process mroe easily ?
[16:21] <bjf> apw, i just use the raw log, it's easy enough to find the beginning and end
[16:21] <bjf> apw, there is a startmeeting/endmeeting
[16:22] <apw> fair enough, was thinking if there was a url it gave you at the end and you could use that to process against that it might have value
[16:23] <bjf> apw, maybe, but i'd have to make changes to the script, and the next time they change the bot output i'd have to make more, and so on, and so on, ...
[16:23] <apw> fair enough
[16:24] <bjf> apw, the next person to run the meeting can decide if they want to do it differently
[16:25] <ogasawara> I doubt anyone is really reading our meeting minutes that closely to even care
[16:25] <bjf> jussi, "our way" is completely documented: https://wiki.ubuntu.com/KernelTeam/RunningTheIRCMeeting
[16:26] <bjf> ogasawara: that is very true
[16:29] <joaopinto> Hi
[16:30] <joaopinto> after apt-get sourcing the kernel where can I find the list of Ubuntu specific patches ?
[16:30] <jjohansen> apw: morning, so what I was pinging you about was CVE-2011-4081, it is marked as needed for hardy but at least on a first glance it looks like the code wasn't introduced until 2.6.32
[16:30] <ubot2> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4081)
[16:30] <apw> ogasawara, that RunningTheIRCMeeting page doesn't seem to have the kteam-tools magic in it, perhaps you could slam it in when you work it out
[16:31] <ogasawara> apw: yep, will do
[16:31] <apw> joaopinto, the ubuntu specific patches are all directly applied in the version you get from apt-get source
[16:31] <joaopinto> ah ok :\
[16:31] <jjohansen> have you managed to fully script the meeting now :)
[16:31] <apw> joaopinto, if you want the raw patches they are in the our public git trees
[16:32] <apw> joaopinto, every upload has a corresponding tag in those repositories to allow you to find the exact source
[16:32] <joaopinto> I have checked the source, just wanted to be sure the patch was not applied somehow during the build process
[16:32] <apw> other than on hardy there are no patches applied at build time
[16:33] <apw> jjohansen, you should be able to mark hardy 'not-affected' then and my bot will trust you
[16:33] <apw> jjohansen, in theory if the other end was working changing it to Invalid in the bug would be sufficient
[16:33] <joaopinto> there is no patch included for bug 843431 yet :\
[16:33] <ubot2> Launchpad bug 843431 in linux "Logitech camera microphone does not work / makes "chipmunk" sound" [Medium,Triaged] https://launchpad.net/bugs/843431
[16:33] <apw> jjohansen, propogating to UCT as not-affected and triggering my ignoreing it
[16:34] <apw> joaopinto, is it marked Fix Released ?
[16:34] <joaopinto> no, actually there are many bugs related to this issue, with different status and progresses
[16:34] <jjohansen> apw: okay, so just fix it in uct, or do I need to mark invalid in the bug too
[16:34] <apw> joaopinto, indeed from the bug it is not clear that anyone has a fix for it even
[16:35] <joaopinto> http://pkgbuild.com/~heftig/linux-zen/usb-add-reset-resume-quirk-for-several-webcams.patch
[16:35] <joaopinto> https://build.opensuse.org/package/view_file?file=usb-add-quirk-for-logitech-webcams.patch&package=linux&project=home%3Agrayden&srcmd5=ac65d19a58e7dbdcd8a328e124aac0b5
[16:35] <joaopinto> well, someone is applying patches for it :)
[16:36] <joaopinto> I have one affected webcam, whose device id is not listed on that specific patch, I am testing it now
[16:37] <bjf> joaopinto, it helps to know which version you are talking about
[16:37] <joaopinto> bjf, version for ?
[16:37] <apw> joaopinto, ok that patch seem to have _just_ hit mainline in v3.2-rc1
[16:37] <bjf> joaopinto, also, we get most of these cinds of patches from upstream stable releases
[16:37] <joaopinto> yeah, was checking http://www.spinics.net/lists/stable-commits/msg13878.html
[16:38] <apw> joaopinto, and it is marked for stable so we should see it for older releases soon enough via there
[16:38] <bjf> joaopinto, kernel version or hardy/lucid/maverick/natty/oneiric
[16:38] <joaopinto> I don't remember when the problem was introduced, it's present on oneiric
[16:39] <bjf> joaopinto, that's all i wanted to know, what kernel you were trying to build (didn't see it in the scroll back)
[16:40] <apw> joaopinto, ok added the useful bits of that to the bottom of the bug
[16:40] <joaopinto> apw, where can I check the v3.2-rc1 quirk patch ? (want to to check for my device id)
[16:41] <apw> it is 2394d67e446bf616a0885167d5f0d397bdacfdfc in linus' tree
[16:42] <apw> joaopinto, ok that patch is sitting in gregs queue for 3.0 and 3.1
[16:43] <apw> so we should get it in oneiric in the next weeks
[16:43] <joaopinto> ok, QuickCam E 3500 not there, I am going to test for a few more days to be sure that it fixed, once I am sure, how should I proceed to ask for a device id to be added to the list ?
[16:43] <apw> the most direct way is to send a patch up to mainline and mark it for stable handling
[16:43] <joaopinto> (the issue is random, I can't reliably determine that the fix is working)
[16:44] <apw> if that too scarey you can send a patch to the ubuntu kernel list and we can help
[16:44] <joaopinto> well, I am an end-user, whatever is easier for me :)
[16:45] <joaopinto> I will email the ubuntu kernel list with the bug report link
[16:45] <AlanBell> bjf: if it doesn't work for a team then that is a bug
[16:46] <joaopinto> tks for your time
[16:49] <joaopinto> this bug is present since the last LTS http://www.techytalk.info/logitech-e3500-webcam-and-cannot-set-freq-16000-to-ep-0x86/ :\
[16:59]  * ppisati bails out for a bit...
[17:26] <bjf> ogasawara, we have a "bugs with patches" report somewhere don't we? or do we just do a lp advanced search ?
[17:26] <ogasawara> bjf: lp advanced search
[17:26] <bjf> ogasawara: ack
[17:26] <smb> https://bugs.launchpad.net/ubuntu/+source/linux/+patches
[17:26] <ogasawara> bjf: although I had a pretty graph of it somewhere
[17:27] <bjf> smb: thanks
[17:29]  * bjf wonders if "patch attached" should be displayed on our custom reports
[18:00] <htorque_> hi all! is bugzilla.kernel.org down for you (or still not up after the security breach)? i'm wondering if it's known that intel wireless (ultimate-n 6300) is not working with 3.2-rc1 (just tried the mainline ppa yet).
[18:20] <bjf> htorque_: bugzilla.kernel.org is still down
[18:22] <htorque_> bjf: thanks!
[19:01]  * tgardner -> lunch
[19:50] <cwillu_at_work> 32bit mainline ppa builds?
[19:51] <cwillu_at_work> (broken until the build tools are updated for precise?  something else?)
[21:48] <undriedsea> Hey Everyone,
[21:48] <undriedsea> I am having a problem accessing /proc/<pid>/mem range after mprotect has made it readable. It almost seems the procfs driver is not aware of the updated permissions. Any ideas or hints would be great!
[21:48] <undriedsea>     1. Process A ptrace ATTACHs to process B
[21:48] <undriedsea>     2. Process A cannot access of a given range in process Bs /proc/<pid>/mem due to the associated mapping in /proc/<pid>/maps being non-readable
[21:48] <undriedsea>     3. Process A requests process B use mprotect to mark given mapping as readable (mprotect returns success)
[21:48] <undriedsea>     4. Process A now should be able to read the range in /proc/<pid>/mem but can only read part of the range...
[21:48] <undriedsea> Details: http://codepad.org/DMItNdYa
[22:23] <undriedsea> Does anyone know who is the maintainer of the part of the kernel that container the mprotect systemcall?
[23:26] <Somedude> I get this when trying to turn on VT-d. (Intel VT-d tech enabled), intel_iommu=on(!): Your BIOS is broken; DMAR reported at address fed90000 returns all ones
[23:26] <Somedude> The BIOS is up to date, so what can exactly cause this error/warning?
[23:37] <Kano> hi, is there a reason why the generic target is dropped for 32 bit?
[23:37] <Kano> older pentium m do not boot with pae enabled
[23:37] <Kano> and some other older cpus
[23:41] <Sarvatt> http://www.linux-archive.org/ubuntu-kernel-team/596063-3-2-rc1-rebase-review.html
[23:41] <Sarvatt> geode and pentium-m yeah
[23:42] <Somedude> Sarvatt: any ideas on my one?
[23:42] <Sarvatt> Somedude: you literally have a buggy bios, its not exactly uncommon or anything, VT-d is all kinds of pain
[23:42] <Kano> there are lots of pple with that hardware out there
[23:42] <Sarvatt> does it fall back to swiotlb gracefully?
[23:43] <Sarvatt> if not you can boot with intel_iommu=off to work around it
[23:43] <Somedude> how do I check?
[23:43] <Sarvatt> dmesg | grep SWIOTLB will tell you
[23:43] <Somedude> I need it for directed I/O, that's a bit of the pain
[23:44] <Somedude> yes
[23:44] <Somedude> it does
[23:44] <Somedude> what to do to work around this problem?
[23:45] <Somedude> Sarvatt: can I get Directed I/O with swiotlb too?
[23:46] <Somedude> I need to put an PCI card to an KVM VM
[23:46] <Sarvatt> Somedude: honestly I have no clue, I imagine you can though
[23:47] <Sarvatt> there was a bug awhile back where it would completely turn off iommu support if you got that error but thats fixed now apparently
[23:48] <Somedude> Sarvatt: this one you mean? http://freecode.com/articles/red-hat-updated-kernel-packages-fix-multiple-security-issues-16
[23:48] <Somedude> 588638 - [abrt] crash in kernel: Your BIOS is broken; DMAR reported at address fed90000 returns all ones!
[23:49] <Somedude> I need to contact the supplier of the motherboard and ask them for a fixed BIOS, I guess?
[23:49] <Sarvatt> yeah sounds like what google pulled up when I searched for it, you might be able to get more info there :) https://bugzilla.redhat.com/show_bug.cgi?id=524808
[23:50] <ubot2> bugzilla.redhat.com bug 524808 in kernel "swiotlb should be enabled when VT-d setup fails" [High,Closed: errata]
[23:51] <Sarvatt> yeah but honestly don't expect that would happen unless its really new (then theres probably still no chance..), OEMs usually just ship crap out the door and give up on it :)
[23:53] <bjf> Kano, it was discussed at uds and the decision was made there, feel free to post a question to the ubuntu kernel team mailing list
[23:53] <Sarvatt> Kano: maybe send a mail to kernel-team@lists.ubuntu.com discussing it
[23:53] <Sarvatt> bjf beat me to it
[23:53] <bjf> heh
[23:53] <Kano> Sarvatt: ?
[23:53] <Sarvatt> regarding the dropping support for pentium m
[23:55] <Somedude> Sarvatt: I have a contact by ASUS Holland, I will tickle him until he provides me a new BIOS
[23:55] <Somedude> *A working one, that is
[23:58]  * Somedude yawns
[23:59]  * Somedude -> bed
[23:59] <Somedude> 'night all