[07:37]  * smb yawns
[07:39]  * _ruben copy-cats smb 
[08:27] <hrw> hi
[08:28] <hrw> does someone here work on intel backlight support in laptops
[08:28] <hrw> ?
[11:56] <Kano> hi apw 
[11:56] <Kano> apw: the current symlink is missing, i need that for my script
[11:56] <Kano> apw: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/
[11:56] <Kano> this one
[11:57] <apw> Kano, yes that is correct, right now the revamp of the builds does not generate it
[11:58] <Kano> can you add it again
[11:58] <apw> it'll return at some point yes, it not the worst bug i have in the rewrite yet
[11:59] <Kano> can your create it manually?
[11:59] <Kano> i have got a tiny script that parses that url
[11:59] <Kano> http://kanotix.com/files/fix/mainline/install-daily.sh
[12:00] <Kano> i would love if there would be latest links for each kernel
[12:00] <Kano> for 3.2 you could use ~rc
[12:03] <Kano> btw. i have got several bug reports for realtek gbit nics, do you know of  a working fix?
[12:05] <Kano> some use the "official" realtek driver as fix (outside tree driver, but that is no real solution)
[12:05] <Kano> http://ubuntuforums.org/showthread.php?t=1022411&highlight=rt+8111&page=9
[12:06] <apw> that sounds about right re: rtl drivers
[12:47] <hrw> can someone check how many brightness level has on intel laptop?
[12:47] <Kano> mal den pc wechseln...
[12:48] <hrw> mine thinks about nearly 2mln levels - makes backlight applications useless
[12:48] <apw> hrw in the real work it has many many, last i looked gsd was doing something stoopid and moving 3-4 steps out of the 8 at a time
[12:50] <hrw> apw: with <3.1 kernel I had 15 steps and it was working 
[12:51] <hrw> brb
[12:51] <smb> If that should have meant intel gfx laptop. Mine has 10 or 1 depending whether you look at the acpi or intel subdir
[12:52] <apw> hrw so you are on precise already ... hmmm
[13:00]  * smb thinks the new releases codename will cause a lot of un-precise statements... 
[13:04] <hrw> apw: on this laptop yes
[13:05] <hrw> smb: acpi one reports 15 but do not react to changes, intel one reports ~2000000 levels and reacts to cahnges
[13:06] <smb> hrw, The netbook I was comparing with is on Oneiric only, but behaves the opposite way. So acpi does react intel does not. But it also has an odd value in bl_power
[13:08] <hrw> smb: I do nto use this laptop so often
[13:10] <smb> hrw, So which setting is set to those ~2000000 max_brightness or something else?
[13:10] <hrw> smb: max_brightness yes
[13:11] <hrw> 1992060 to be exact
[13:12] <smb> Hm, ok. Maybe always was an odd value somewhere. If you had a way to quickly boot back into an older kernel, you might check whether its acpi that changes there
[13:12] <smb> Maybe just for some reason the newer kernel switched what it uses for control...
[13:12] <hrw> would have to install older kernel and prefer to not do that now
[13:13] <smb> hrw, Alternatively if you have an old desktop cd/dvd you could boot into trial mode there
[13:13] <hrw> smb: booting to oneiric kernel would take less effort ;D
[13:14] <smb> hrw, At least you would not have to _install_ an older kernel. ;)
[13:14]  * smb tries to remember those backlight runes...
[13:14] <hrw> acpi_backlight=vendor one?
[13:15] <smb> Yes, just the other setting. video..?
[13:15] <hrw> no idea
[13:15] <hrw> I used acpi_backlight=vendor with <3.0 kernel
[13:16] <smb> So that would force it not to use acpi
[13:16] <smb> =video should be the opposite
[13:18] <smb> Though that normally passes control to some vendor driver (like thinkpad_acpi or so...)
[13:18] <hrw> asus_laptop here
[13:18] <hrw> [   26.734876] asus_laptop: Backlight controlled by ACPI video driver
[13:19] <smb> Hmmm
[13:19] <smb> So have you used acpi_backlight=vendor for 3.1?
[13:19] <hrw> nope
[13:19] <hrw> BOOT_IMAGE=/vmlinuz-3.1.0-1-generic root=/dev/mapper/lucek-rootfs ro loop.max_loop=256 loglevel=0 pcie_aspm=force quiet
[13:20] <smb> Then I would try that again...
[13:23] <hrw> worth try cause fn+F6 does not bump backlight but gives acpi kernel errors
[13:23] <hrw> [18360.424842] ACPI Exception: AE_AML_BUFFER_LIMIT, Index (0x0000000000000074) is beyond end of object (20110623/exoparg2-418)
[13:23] <hrw> [18360.424866] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.STBR] (Node ffff880138a40118), AE_AML_BUFFER_LIMIT (20110623/psparse-536)
[13:23] <hrw> [18360.424888] ACPI Error: Method parse/execution failed [\_SB_.PCI0.VGA_.LCDD._BCM] (Node ffff880138a392f8), AE_AML_BUFFER_LIMIT (20110623/psparse-536)
[13:23] <hrw> [18360.424911] ACPI Error: Evaluating _BCM failed (20110623/video-364)
[13:23] <hrw> [18360.424920] ACPI: Failed to switch the brightness
[13:24] <smb> tbh, if you had to use it before it was likely because your acpi bios is broken (which would not be the first one). And that is not expected to be fixed by having a newer kernel...
[13:24] <hrw> yep
[13:27]  * smb forgot what _BCM meant exactly but it definitely was something controlling the backlight. 
[13:27] <cking> the AML buffer limit is not pleasant, and _BCM sets the brightness level
[13:27] <smb> something like backlight control method or so. just cannot remember
[13:27] <smb> but yes
[13:28] <smb> sounds like the value it reads from the ec is out of bounds
[13:28] <cking> _BCM  -> (Set the Brightness Level) section B.6.3 of the ACPI spec
[13:29]  * smb probably foolishly tries to find a meaning behind the acronym
[13:29] <hrw> Backlight Control Method?
[13:29] <cking> Brightness Control Method
[13:29] <smb> that was my guess, yes. :)
[13:30] <smb> Ok brightness then. :)
[13:30] <smb> cking, Ta
[13:31] <cking> I'd extract the acpi tables, disassemble the DSDT and look at it - you could extract the tables and run _BCM inside acpiexec and see what it's doing wrong 
[13:31] <cking> http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html
[13:32] <hrw> thx, will check on tuesday while travelling
[13:56] <brendand> herton - did you get my note on the maverick tracking bug?
[13:57] <herton> brendand: yep, I changed the bot here, next time it should set the task automatically to invalid for maverick bugs
[14:08]  * ogasawara back in 20
[14:41] <jsalisbury> ogasawara, bjf, I've been seeing lots of duplicates and and increase of people affected for bug 843431 
[14:41] <ubot2> Launchpad bug 843431 in linux "Logitech camera microphone does not work / makes "chipmunk" sound" [Medium,Triaged] https://launchpad.net/bugs/843431
[14:42] <jsalisbury> ogasawara, bjf, there is a proposed patch in comment #42
[14:42] <ogasawara> jsalisbury: ack thanks, I'll take a look in a bit
[14:43] <jsalisbury> ogasawara, thanks, some of the duplicate bugs report the mainline kernel fixes the issue as well.
[14:43] <ogasawara> jsalisbury: cool
[14:52] <apw> jsalisbury, perhaps copy the information up into the main bug when you find useful things like that
[14:52] <jsalisbury> apw, OK, I'll do that from now on
[14:53] <apw> or like "duplicates say 'foo' see comment blah" and a link to it
[14:59] <herton> ppisati: your ti-omap4 branch for oneiric doesn't pull clean, it's missing a change which was on main ti-omap4
[15:01] <ppisati> uh?
[15:01] <ppisati> let me check
[15:02] <herton> ppisati: it misses "Make TASKSTATS require root access, CVE-2011-2494" change, probably was not up to date when you closed the release
[15:02] <ubot2> herton: ** 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-2494)
[15:02] <ppisati> ok, let me fix it
[15:03] <tseliot> is tgardner online today?
[15:04] <smb> tseliot, no on vacation till friday (including)
[15:04]  * herton -> lunch
[15:10] <ppisati> herton: the fix was already in master, so we got it for free
[15:18] <apw> tseliot, i assume what you needed tim for we covered ?
[15:19] <tseliot> apw: absolutely. Thanks again guys
[15:22] <apw> cool, good, yay
[15:24] <jsalisbury> Do you happen to know if there is a way to identify if a system has a sandy bridge cpu?  Is there a flag in cpuinfo, or can I tell by the model name?
[15:45] <apw> smb, where is the local version of your .33 tree
[15:45] <apw> (not kernel.org)
[15:46] <smb> apw git://kernel.ubuntu.com/smb/linux-2.6.32.y-drm33.z.git
[15:47] <hggdh> herton: there?
[15:47] <herton> hggdh: yep
[15:48] <hggdh> herton: I had not noted the lucid tracking bug was not yet ready, and tested it -- and marked it done. Will it mess up the scheduler?
[15:48] <hggdh> herton: bug 871899
[15:48] <ubot2> Launchpad bug 871899 in kernel-sru-workflow/verification-testing "linux: 2.6.32-35.78 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/871899
[15:49] <herton> hggdh: no, it's fine. There is still one bug to be verified for lucid, but I think it'll be. About the state is ok, just it would have to be retested if the verification "fails"
[15:50] <hggdh> herton: good to know. And, of course, what I did is valid as long as there is no change to the package
[15:50] <brendand> herton - when do you reckon we go to verification-done then? today or tomorrow?
[15:51] <herton> brendand: It can be done today, I'll see what's pending
[15:51] <smb> herton, would that be bug 614853 	
[15:51] <ubot2> Launchpad bug 614853 in linux "kernel panic divide error: 0000 [#1] SMP" [Undecided,Fix committed] https://launchpad.net/bugs/614853
[15:51] <herton> smb: correct. May be we can mark that as verification-done, since no one will be able to check that in 1 week it seems
[15:52] <smb> herton, that is sadly correct
[15:52] <smb> But I guess we can consider it ok as it has been passed quite a while in the ec2 topic branch
[15:53] <herton> indeed. I'll comment on the bug and tag it, then release the update for the certification team
[15:54] <smb> cool thanks
[16:02] <herton> brendand: verification done, feel free start lucid testing
[16:10] <brendand> herton - thanks!
[16:34] <hallyn> oh fooi - after upgrading netbook from natty to ocelots, ad-hoc is once again not supported.  now i'll need to remember which driver i switched to that did :)
[19:12]  * ogasawara lunch
[23:36] <hggdh> bjf, smb: I have bug 879151 as from the testing on bug 872660, and I am holding my ack pending your review
[23:36] <ubot2> Launchpad bug 879151 in linux-lts-backport-maverick "WARNING: at /build/buildd/linux-lts-backport-maverick-2.6.35/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0xb1/0xf0() " [Undecided,New] https://launchpad.net/bugs/879151
[23:36] <ubot2> Launchpad bug 872660 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.61~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/872660