[04:34] <VinceN> Good Evening everyone
[04:35] <VinceN> persia : I ran the latest CD.  The fans seemed to work ok so I went ahead and installed it.  Bad idea.  They work but only intermittently it seems.  I'm still trying to see a rhyme or reason too it.  That being said I want to say congrats to you guys.  Lucid is VERY nicely done otherwise from what I can see
[04:37] <VinceN> I also did some more research, There looks like there might be a firmware update to the laptop that might fix the issue but the update is supposed to be run from inside a windows environment.  There is a DOS bootable CD that supposedly works that someone put up but iI'm hesitant to try it as if I bork the firmware update my laptop is pretty much hosed.
[04:51] <persia> I'm sorry to hear your issue isn't perfectly addressed.  Good luck with the firmware update.
[04:55]  * hyperair heard of a windows livecd or other, but it isn't free, or legally free, in any case.
[06:22] <Sarvatt> apw: regarding the multibyte EC problems, look familiar? - https://bugzilla.kernel.org/show_bug.cgi?id=15749 fix is released upstream
[06:22] <ubot3> bugzilla.kernel.org bug 15749 in EC "bisected 2.6.34-rc3+git EC regression - can't boot after fix from bug #14667" [High,Closed: code_fix] 
[08:40] <apw> Sarvatt, that is indeed equivalent to the fix we had homed in on.  and would be in lucid now if the macbook pro tester didn't have other unrelated but simultaneously appearing issues which masked its success
[08:43] <RAOF> apw: Good morning.
[08:43] <apw> mornig
[09:00] <apw> RAOF, anything exciting occuring in your world?
[12:28] <Sleep_Walker> hi
[12:29] <Sleep_Walker> AceLan: please, is kexec broken in 2.6.28-araneo?
[12:55] <Sleep_Walker> what 'araneo' means? it's kernel branch for some set of devices?
[13:40] <AnAnt> Hello, can I build the kernel package (linux) using pbuilder ?
[13:40] <amitk> AnAnt: we only support debuild
[13:41] <AnAnt> good
[13:42] <AnAnt> amitk: that doesn't necessarily mean that the answer to my question is 'no', right ?
[13:43] <amitk> AnAnt: right, I just don't know how and why I would use pbuilder.
[13:43] <AnAnt> ok, thanks
[13:43] <hyperair> amitk: build-depends!
[13:43] <AnAnt> as for why, because I don't want to install -dev packages on my system
[13:43] <AnAnt> hyperair: exactly
[13:43] <hyperair> AnAnt: you do realize how thin the build-depends of a kernel are, right?
[13:44] <hyperair> Build-Depends: dpkg (>= 1.13.19), debhelper (>= 3), gawk
[13:44] <AnAnt> hyperair: no I didn't know actually, I just saw stuff that aren't on my system
[13:44] <hyperair> hmm?
[13:44] <AnAnt> hyperair: binutils-dev, libelf-dev
[13:44] <hyperair> AnAnt: heh? i don't remember needing those..
[13:44] <AnAnt> hyperair: http://packages.ubuntu.com/source/lucid/linux
[13:45] <AnAnt> I look at {a,i}dep: lines
[13:45] <hyperair> AnAnt: maybe something changed. i use make-kpkg. don't need any of those =p
[13:55] <apw> hyperair, they are new for the perf tools
[14:03] <tgardner> apw, hmm, mumble ain't gonna work too well unless I can find a microphone 
[14:05] <apw> tgardner, heh yeah its not the most useful without that
[14:05] <apw> though with push to talk many people use it with a lid mike
[14:06] <apw> one of your dells prolly has one of those
[14:08] <hyperair> apw: perf tools?
[14:08] <hyperair> apw: what perf tools?
[14:09] <apw> the kernel source has started to carry tightly coupled tools like perf
[14:09] <apw> so we now have a new linux-tools package which carries these version locked tools
[14:09] <hyperair> oh interesting
[14:13] <apw> progress progress
[14:14] <achiang> ugh, last night, i suggested a workaround for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374
[14:14] <ubot3> Malone bug 532374 in oem-priority "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,In progress] 
[14:14] <achiang> didn't work though because i was looking at an upstream tree, not the ubuntu tree
[14:14] <achiang> i suspect backporting d7f0eea9 will resolve the issue
[14:16] <apw> achiang, that just adds a command line option for sci something somtthing, doesn't add any blacklists
[14:17] <achiang> apw: well, right -- i wanted to verify it actually helped before adding a quirk
[14:17] <apw> damn these machines are a mess
[14:19] <achiang> apw: let me forward you a mail from jerone that suggests it is the correct workaround ; i guess i'm sniffing about for a way to do a test kernel for these folks to try to see if it helps
[14:26] <apw> achiang, the bug is currently closed against linux, cause lenovo thinks the issue is their bios?
[14:28] <achiang> apw: yes, the issue is a BIOS bug, but windows works because it essentially does that sci_force_enable quirk. it would be nice if our kernel did that too so people wouldn't be forced to upgrade BIOS
[14:29] <apw> windows is such a pain, if only we didn't have to overlap with it
[14:29] <apw> 'it works with windows' makes me want to scream
[14:29] <achiang> be that as it may, that is the de facto standard for Linux/ACPI
[14:30] <apw> nominally you can't have a defacto standard where there is an actual published standard
[14:30] <apw> all you can have is compiant or _broken_ bioses
[14:30] <achiang> well, that is de facto vs de jure. ;)
[14:31] <achiang> apw: on a more practical note, upstream Linux/ACPI including maintainer explicitly state windows bug-for-bug compatibility is the policy. so in that sense, ubuntu shouldn't deviate from upstream
[14:31] <apw> well de facto has "without being officially established in it"
[14:32] <apw> then they really should just turn on that bit no?
[14:32] <apw> if thats what doze does
[14:33] <achiang> well, they do, but as a quirk... i mean -- you're right -- official standard says, "that's BIOS's job, not OSPM" so i think it would be dangerous to categorically turn it on all the time, punishing the BIOSes you point out that *are* compliant
[14:34] <apw> if the definition is "it must be on on return" then its not clear we can get it wrong
[14:35] <apw> seems lucid only has quirks for HP for this issue
[14:36] <achiang> that bit is owned by BIOS, not the OS, so it's dangerous for the kernel to set that bit unconditionally
[14:36] <achiang> unless it's for a known broken platform
[14:37] <achiang> at least that's the impression i got from reading the comment added by the commit i named above
[14:37] <apw> though the description says it _must_ be on on resume, so it not being would mean we should set it to my eye
[14:38] <achiang> hm, i see quirks for mac platforms in lucid
[14:39] <apw> there are other quirks in the table, not all for that one item
[14:39] <achiang>         .callback = init_set_sci_en_on_resume,
[14:39] <achiang>         .ident = "Apple MacBook 1,1",
[14:39] <apw> oh not really old old old macs yes
[14:39] <achiang> am i looking at the wrong tree?
[14:40] <apw> trust macs to be broken, they are more broken than windows boxes mostly
[14:41] <apw> achiang, anyhow if i am reading this right that command line patch is the next one against that file so it should apply triviallu
[14:42] <achiang> apw: nod, i'm trying to convince someone here to make that patch and do a test kernel. i don't want to overstep my bounds since i'm on the OEM team, not platform
[14:43] <apw> overstep your bounds?  slap it on and build it, its a community distro
[14:43] <apw> its not like most of us have anything to test it with
[14:44] <achiang> heh, ok. guess i need to go figure out how to build / release a kernel the ubuntu way. i'm a new hire too and just ramping up on process here. ;)
[14:44] <apw> heh i could do it for you, but its a good learning experience
[14:45] <apw> all my resources are tied up building other things right now, its a busy time
[14:45] <achiang> sure, ok
[14:46] <achiang> apw: do you still consider https://help.ubuntu.com/community/Kernel/Compile to be accurate?
[14:47] <tgardner> achiang, start here: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance
[14:47] <achiang> ah, ok
[14:48] <tgardner> achiang, we also have a meta page with links to lots of topics: https://wiki.ubuntu.com/KernelTeam
[14:48]  * achiang bookmarks
[14:48] <achiang> thanks tgardner 
[14:49]  * apw suspect you will find many inaccuracies that we can no longer see for doing it too much
[14:49] <tgardner> achiang, feel free to correct said inaccuracies
[14:49] <apw> achiang, feel obligated to fix them :)
[14:50] <achiang> project creep! ;)
[14:50] <achiang> but ok, will do. ;)
[16:55] <crazybyte> jjohansen, hello. may i take up a bit of your time?
[16:55] <jjohansen> crazybyte: sure
[16:58] <crazybyte> jjohansen, i read your comment on the oops related issue. what is strange is that those oopses happened sometime before suspend and now i'm on the lucid kernel and i'm running it since yesterday after several suspend/wake up cycles without any issue.
[16:59] <jjohansen> crazybyte: ? Maybe I misinterpreted what you said but I thought the crashes were coming post suspend
[16:59] <crazybyte> jjohansen, mostly
[16:59] <crazybyte> that is what i observed
[17:00] <crazybyte> but when i started having those issues i remember that sometime they happened before suspend
[17:00] <crazybyte> but then i was using the karmic kernel
[17:00] <crazybyte> now they happened after wake ups
[17:00] <crazybyte> until yesterday
[17:00] <crazybyte> nothing since than
[17:01] <jjohansen> hrrmm, that doesn't really make sense, did you run an update?
[17:02] <crazybyte> no. at least not in the case of the kernel because it's the main lucid kernel installed in karmic so i can't update it by usual means
[17:03] <crazybyte> jjohansen, i will keep my eye on this because it's pretty strange
[17:03] <crazybyte> also could you have a suggestion how to find out what resides at that particular address when the oops happens
[17:04] <crazybyte> i'm very curios about what is there when they happen because the addresses repeat themselves sometimes
[17:05] <jjohansen> crazybyte: hrmm, well you can look at /proc/<pid>/maps
[17:06] <jjohansen> and also the boot messages
[17:06] <crazybyte> jjohansen, could ksymoops help me better somehow i didn't thought of?
[17:07] <crazybyte> ok
[17:08] <jjohansen> crazybyte: hrmm I can't see what more you are going to get from ksymoops
[17:09] <crazybyte> i see
[17:09] <crazybyte> ok
[17:09] <crazybyte> thanks
[17:09] <apw> most oops addresses are kernel side and so only vagely categorisable into a few simple categories
[17:10] <jjohansen> crazybyte: well it might if you can hit it right after the oops, and use /proc/kallsyms but since these are freezes I don't see that happening
[17:11] <crazybyte> yeah
[19:10] <lool> hey folks
[19:10] <lool> My kernel is doing stuff but I dont know what
[19:10] <lool> and my machine is dying under background IO load
[19:10] <lool> I tried sudo perf top, iotop, regular top, and can't tell what's happening
[19:10] <lool> see bug #549428
[19:10] <ubot3> Malone bug 549428 in apparmor "Triggers permanent high i/o load after upgrade" [Undecided,Fix committed] https://launchpad.net/bugs/549428
[19:10] <lool> I get this regularly, but not daily
[19:11] <lool> I will have to reboot the system pretty soon given that it's almost unusable now; anything I can do?
[19:12] <lool> I don't know whether that's expected, but cat /sys/kernel/debug/dri/64/vma returns
[19:12] <lool> cat: /sys/kernel/debug/dri/64/vma: Cannot allocate memory
[19:13] <lool> sudo cat i915_ringbuffer_data
[19:13] <lool> cat: i915_ringbuffer_data: Ne peut allouer de la mémoire
[19:13] <lool> that sounds bad
[19:13] <smb> At least like something went crazy requesting memory
[19:14] <lool> oddly, meminfo lists plenty of cached stuff
[19:14] <lool> Oh I know
[19:14] <lool> So I'm using ecryptfs
[19:14] <lool> and I use unison in the background
[19:14] <lool> Every so many days, this starts happening
[19:14] <lool> I bet it's not giving back some memory to the OS
[19:14] <lool> smb: How could I track memory down?
[19:15] <lool> http://paste.ubuntu.com/418779/ < meminfo
[19:15] <lool> Cached:          2492220 kB
[19:15] <smb> Maybe one could keep tracking memory allocation while running
[19:15] <smb> apparently you cannot even look right now
[19:15] <lool> smb: Well my system still runs for some rason
[19:15] <lool> reason
[19:15] <smb> A high cached value is normal
[19:15] <lool> I suspect the background load is swapping
[19:16] <lool> Except I dont have any hmm
[19:16] <lool> smb: Yes, but I mean this should be reclaimable to allocate memory
[19:16] <lool> smb: I would expect that if my kernel used all available mem, this value would be small
[19:16] <lool> VmallocTotal:   34359738367 kB
[19:16] <lool> VmallocChunk:   34359353372 kB
[19:17] <lool> that's.... too much
[19:17] <lool> I don't have 34 TB of vm
[19:17] <lool> Hmm apparently that's normal
[19:17] <lool> it matches another host
[19:18] <lool> probably some addressable range
[19:20] <smb> I would believe so
[19:24] <smb> lool, The thing is that you seem to be unable to start new tasks which sounds like shortage of allocable memory
[19:25] <lool> smb: I can actually start other tasks
[19:25] <lool> Could at least
[19:25] <lool> smb: I could open an xterm for instance
[19:25] <lool> albeit slowly
[19:29] <smb> I wonder whether iotop could help here or whther it only will show that swapper is on  duty
[19:37] <AnAnt> Hello
[19:37] <AnAnt> I am downloading linux source package
[19:38] <AnAnt> I wanted to know which file should I edit if I wanted to change the configuration for the -generic package 
[19:39] <smb> AnAnt, Depends a bit. The linux-source package is not that useful
[19:39] <smb> AnAnt, apt-get source linux-image-... or git is more useful
[19:40] <AnAnt> smb: well the source package for linux-image-... is linux
[19:40] <smb> AnAnt, In that case it is in debian.master/config/(i386|amd64)/config.generic
[19:41] <smb> AnAnt, Unfortunately the is also a package called linux-source
[19:41] <smb> which is only the general parts without the debian directories
[19:41] <AnAnt> linux-source was in dapper
[19:42] <AnAnt> according to:http://packages.ubuntu.com/search?searchon=sourcenames&keywords=linux-source
[19:44] <smb> AnAnt, In Dapper the source package was named linux source. But later linux (as the source package) also creates a binary package called linux-source
[19:44] <AnAnt> aha
[19:46] <smb> Its a bit confusing and often people get tricked into installing the architecture independend binary package because it has source in its name. Thats why I usually try to make sure that you have the real source package
[19:46] <AnAnt> which is 'linux' , right ?
[19:46] <smb> right
[19:47] <smb> Just looked, the flavour package seems to be config.flavour.generic now
[19:47] <smb> err I mean the config file
[19:49] <smb> But its a stacked approach you got a top level config.ubuntu.common a config.i386(or amd64).common
[19:49] <smb> and the flavour specic
[19:49] <AnAnt> where's that ?
[19:50] <smb> AnAnt, You will find everything when you descent into debian.master/config
[20:08] <peterz> apw: can you fix this messed up kernel-list@ubuntu to not send bounces for each msg?
[20:09] <peterz> apw: or educate folks to not cross post to lkml
[20:09] <achiang> anyone have a lenovo x201 and can send me dmidecode | grep Version ?
[20:51] <apw> peterz, bah sorry man ...
[20:51] <apw> i'll get my cluebat out
[20:52] <peterz> apw: thanks mate! :-)
[21:05] <kyanardag_> hi, i'm using Karmic right now and I noticed at http://kernel.ubuntu.com/~kernel-ppa/mainline/  kernel version 2.6.34.rc3 is available. If I download and install .deb file for linux-source will I be good to go with that kernel version? (no compiling, no configuring, no boot-image generating)
[21:14] <kyanardag_> also, i added the kernel-ppa repository by sudo add-apt-repository ppa:kernel-ppa/ppa but i get error "Failed to fetch http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu/dists/karmic/main/binary-amd64/Packages.gz  404  Not Found"
[21:15] <abogani> kyanardag_: No it is generally used to try bugs against the latest linux kernel version so 1) It isn't tested at all by us 2) It don't contains Ubuntu patches 3) We don't provide any type of support on it.
[21:16] <abogani> kyanardag_: AFAIK It isn't available in PPA you should click and install from kernel.ubuntu.com.
[21:17] <kyanardag_> abogani, i see.. it's just vanilla kernel? thanks..
[21:17] <abogani> kyanardag_: Exactly.