| lifeless | the machine as a whole doesn't lock up or anything. | 00:00 |
|---|---|---|
| manjo | looks more like a firmware issue to me | 00:01 |
| ogasawara | bjf: let me restart mumble, just a sec | 00:01 |
| bjf | ah | 00:02 |
| manjo | lifeless, what driver is series 6000 use ? | 00:07 |
| lifeless | iwlagn | 00:08 |
| lifeless | manjo: oh, I'm not assuming anything about where the bug is; firmware makes sense to me | 00:08 |
| manjo | does it help if you do sudo rfkill unblock wifi ... just a shot in the dark this one ... | 00:08 |
| manjo | does rfkill list say it is soft blocked or hard blocked ? | 00:09 |
| manjo | lifeless, there is new microcode for this device ... http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-6000-ucode-9.193.4.1.tgz | 00:10 |
| lifeless | manjo: I'll install rfkill and try those commands next time it goes awol | 00:10 |
| manjo | do rfkill list | 00:11 |
| manjo | and that should tell if it is blocked. | 00:11 |
| manjo | but I suspect it is firmware issue | 00:11 |
| lifeless | manjo: I'm quite sure its not, but it is worth checking | 00:11 |
| lifeless | manjo: I says it not, because nm doesn't think its blocked | 00:11 |
| lifeless | it thinks it can't associate | 00:11 |
| manjo | lifeless, ah worth a try | 00:12 |
| manjo | lifeless, I also posted a link to the current firmware | 00:12 |
| lifeless | manjo: indeed, its worth checking | 00:12 |
| lifeless | I've pulled that down | 00:12 |
| lifeless | where does that go these days ? | 00:12 |
| lifeless | ah /lib/firmware | 00:13 |
| manjo | /lib/firmware/ | 00:13 |
| manjo | yes | 00:13 |
| lifeless | lucid has it | 00:13 |
| lifeless | iwlwifi-6000-ucode-9.193.4.1/iwlwifi-6000-4.ucode | 00:13 |
| lifeless | bah | 00:13 |
| lifeless | robertc@lifeless-64:/lib/firmware$ diff iwlwifi-6000-4.ucode ~/source/iwl/iwlwifi-6000-ucode-9.193.4.1/iwlwifi-6000-4.ucode | 00:13 |
| lifeless | robertc@lifeless-64:/lib/firmware$ | 00:13 |
| manjo | lifeless, can you enable power mangement for the card ? | 00:16 |
| manjo | iwconfig wlan0 power on | 00:16 |
| manjo | lifeless, microcode errors might be due to card over heating ... are you running in N mode ? | 00:16 |
| lifeless | manjo: am running in N mode; am in new zealand so its not very warm :) | 00:17 |
| lifeless | have done the power on | 00:17 |
| lifeless | and will do so after firware reloads from here on in | 00:17 |
| manjo | lifeless, it might be also interesting to test the over heating theory ... | 00:18 |
| lifeless | manjo: other than putting it under the hot water tap, do you have any suggestions ? :) | 00:19 |
| manjo | hhaha | 00:20 |
| manjo | lifeless, I see an upstream bug on this ... https://bugzilla.kernel.org/show_bug.cgi?id=15374 | 00:20 |
| ubot2 | bugzilla.kernel.org bug 15374 in network-wireless "iwlagn Microcode SW error detected" [Normal,Resolved: code_fix] | 00:20 |
| lifeless | manjo: the problem is that the restart error is very generic | 00:22 |
| manjo | lifeless, I will pull in the upstream patch for you and build a kernel if you like | 00:22 |
| lifeless | manjo: that would be totally awesome | 00:22 |
| lifeless | I'm running 2.6.32-22-generic x86_64 | 00:23 |
| lifeless | (just the stock lucid 64 bit kernel) | 00:23 |
| manjo | lifeless, it is towards the end of the day for me. I can have it uploaded to my people page by tomorrow AM | 00:23 |
| lifeless | manjo: there is no panic | 00:23 |
| manjo | lifeless, :) cool talk to you tomorrow then | 00:23 |
| lifeless | manjo: let me know in the bug where it is and I'll spin it up asap | 00:23 |
| manjo | ok | 00:23 |
| manjo | will do | 00:23 |
| ogasawara | manjo, lifeless: I wonder if linux-backports-modules might help as I think that contains and updated compat-wireless stack | 00:25 |
| manjo | ogasawara, thanks totally forgot about the backport modules | 00:25 |
| manjo | lifeless, try what ogasawara suggests | 00:25 |
| lifeless | does it contain the patch from the upstream bug report ? | 00:26 |
| ogasawara | manjo: no idea if it'll really help, but for testing it wouldn't hurt and might save you having to build a custom kernel | 00:26 |
| ogasawara | lifeless: not sure on that, would have to dig around | 00:26 |
| ogasawara | lifeless: if the patch in the upstream bug report hasn't been applied to mainline, then lbm won't have it | 00:26 |
| manjo | lifeless, I will have a kernel for you as well & point you to it on the bug ... just in case lbm does not work | 00:27 |
| lifeless | ogasawara: can you tell from https://bugzilla.kernel.org/show_bug.cgi?id=15374 if its applied ? | 00:28 |
| ubot2 | bugzilla.kernel.org bug 15374 in network-wireless "iwlagn Microcode SW error detected" [Normal,Resolved: code_fix] | 00:28 |
| lifeless | ogasawara: to mainline, I mean.. | 00:28 |
| manjo | ogasawara, lifeless, there was commit to mainline | 00:29 |
| manjo | commit 74e2bd1fa3ae9695af566ad5a7a288898787b909 | 00:29 |
| manjo | Author: Wey-Yi Guy <wey-yi.w.guy@intel.com> | 00:29 |
| manjo | Date: Wed Feb 3 09:28:55 2010 -0800 | 00:29 |
| lifeless | cool | 00:29 |
| manjo | ogasawara, so lbm should have them ? | 00:29 |
| manjo | there are a total 4 patches to fix this issue | 00:29 |
| ogasawara | manjo: would have to cross check and see what latest version of compat-wireless was updated to | 00:30 |
| lifeless | don't stress | 00:30 |
| lifeless | I'll run manjos build tomorrowish/whenever | 00:30 |
| ogasawara | manjo: it looks like that patch didn't land till 2.6.34-rc1 | 00:30 |
| lifeless | which as an isolated change will be valuable to confirm/deny the change works. | 00:30 |
| manjo | ogasawara, right... that is what I was just about to say | 00:30 |
| manjo | lifeless, in that case don't bother with lbm, I will have a kernel for you tomorrow AM | 00:31 |
| lifeless | if it doesn't, I'll try lbm and hope; if it does we know whats up and can look at SRU inclusion or whatever. | 00:31 |
| ogasawara | manjo: in that case, might not hurt to give tgardners LTS backport kernel a try | 00:31 |
| manjo | ogasawara, can you please point lifeless to it ? | 00:31 |
| * ogasawara digs for the link, just a sec | 00:32 | |
| lifeless | it has 2.6.34rc1 ? | 00:32 |
| ogasawara | lifeless: it's up to 2.6.35-rc1, it's basically a maverick kernel backport | 00:32 |
| manjo | ogasawara, remember lifeless does not want to try experimental stuff on his production machine | 00:32 |
| ogasawara | make that 2.6.35-rc3 | 00:32 |
| lifeless | manjo: I'm happy to try whats in maverick | 00:32 |
| lifeless | manjo: because we're supporting that :> | 00:33 |
| manjo | sure | 00:33 |
| ogasawara | it would be good to know if it exists in Maverick sooner rather than later | 00:33 |
| manjo | lifeless, ogasawara will point you to the lts backport kernel | 00:33 |
| lifeless | if its good enough for the distro, I think the risk is reasonably assessed ;) | 00:33 |
| lifeless | ogasawara: absolutely. | 00:33 |
| manjo | ogasawara, the microcode failure is not fixed so far, the real problem still exists coz its firmware | 00:33 |
| manjo | ogasawara, fix is to make sure that the link does not go down even if there is a microcode crash | 00:34 |
| manjo | ogasawara, so that the connection is maintianied | 00:34 |
| ogasawara | lifeless: "The LTS backport kernel and meta packages at http://ppa.launchpad.net/kernel-ppa/ppa/ubuntu are up to 2.6.35-3.4" | 00:35 |
| * manjo heading out for dinner ... adios amigos | 00:36 | |
| lifeless | thanks | 00:36 |
| ogasawara | lifeless: I've got an hp mini here which uses the iwlagn driver running up to date maverick and haven't seen any issues, but I haven't been hamming it that hard | 00:36 |
| lifeless | ogasawara: I didn't see any issues at all until I got the N wifi point | 00:36 |
| ogasawara | lifeless: ah | 00:36 |
| lifeless | ogasawara: I don't know if you folloed the details in the bug, but there are two separate issues: | 00:36 |
| manjo | ogasawara, you need a 6000 series, N mode & huge file tranfers | 00:36 |
| lifeless | * the microcode is shit | 00:36 |
| lifeless | * When the microcode fails, the recovery was broken | 00:37 |
| lifeless | so the 'fix' here is to recover and reload the microcode better | 00:37 |
| lifeless | if you're not triggering the underlying microcode problem, you won't have any issues at all. | 00:37 |
| ogasawara | ack | 00:37 |
| lifeless | and the kicker is, that the bug count in the microcode is unknown - there could be 20 different bugs | 00:37 |
| lifeless | or 1 | 00:37 |
| lifeless | and we'll never know | 00:37 |
| === rsalveti_ is now known as rsalveti | ||
| === sconklin-gone is now known as sconklin | ||
| === sconklin is now known as sconklin-gone | ||
| === ericm-Zzz is now known as ericm|ubuntu | ||
| kraut | moin | 08:04 |
| amitk | ericm|ubuntu: what is 'git blog'? An alias? | 08:14 |
| jk- | heh | 08:15 |
| ericm|ubuntu | amitk, heh, my alias - git config alias.blog "--pretty=oneline --abbrev-commit" | 08:15 |
| ericm|ubuntu | very useful | 08:15 |
| jk- | damn, i thought it makes a blog entry for your commit :) | 08:15 |
| ericm|ubuntu | jk-, haha - it's not that smart | 08:16 |
| amitk | yeah, that was the first thing I thought of - how and WHY? | 08:16 |
| amitk | :) | 08:16 |
| ericm|ubuntu | confusing, heh | 08:16 |
| ericm|ubuntu | means brief log, cannot find any other word from my poor vocabulary, you know | 08:16 |
| ericm|ubuntu | jk-, btw, is it convenient to setup patchwork for linux-arm-kernel ML? | 08:18 |
| ericm|ubuntu | jk-, guess will be much useful | 08:18 |
| jk- | yeah, it's easy to do, but someone has to maintain it | 08:19 |
| jk- | and rmk has his own patch system, so I don't think he'll be doing that | 08:19 |
| ericm|ubuntu | jk-, there lot of effort to maintain that? | 08:19 |
| ericm|ubuntu | jk-, nah - just hundreds of patches flooding, and SoC patches are all over | 08:19 |
| jk- | well, it's really to make the maintainer's life easier, and since rmk doesn't need it, I'm not sure it'll be useful | 08:19 |
| ericm|ubuntu | guess will at least make us sub-maintainers life easier | 08:19 |
| apw | jk-, oh can you tell if brad figg has an patchworks account? we need him to be maintainer on the ubuntu pwks thingy | 08:20 |
| amitk | I think omap list already uses it | 08:20 |
| jk- | apw: will check | 08:20 |
| ericm|ubuntu | jk-, indeed rmk is a bit stubborn - and he seems to use his own patch system for things other than kernel, which I have no idea :-X | 08:21 |
| ericm|ubuntu | jk-, another thing - there is patchwork.ozlab.org and patchwork.kernel.org, seems they are not linked and I need to register on both sites | 08:22 |
| jk- | apw: looks like he doesn't. | 08:22 |
| jk- | ericm|ubuntu: yes | 08:22 |
| apw | jk-, ok i'll hastle him to make one then | 08:22 |
| jk- | ericm|ubuntu: I maintain the patchwork.ozlabs.org site, the kernel.org people (ie, warthog9) maintain patchwork.kernel.org | 08:23 |
| jk- | s/maintain/admin/ | 08:23 |
| ericm|ubuntu | jk-, I see | 08:23 |
| jk- | they're separate setups | 08:24 |
| ericm|ubuntu | jk-, mmm... so I guess would make more sense to first setup linux-arm-kernel on ozlab? | 08:25 |
| jk- | ericm|ubuntu: it's just going to fill up with patches if there's no one to update the patches in it | 08:27 |
| ericm|ubuntu | jk-, but with a filter, is it still possible that, let's say, all pxa patches can be picked up there? | 08:28 |
| * smb grumbles at his ThinkPad for "forgetting" to turn on the backlight after suspend | 08:28 | |
| amitk | smb: it was scared at night? | 08:29 |
| ericm|ubuntu | smb, turn on or turn off? | 08:29 |
| smb | Cannot say. But the same seems to happen now every time | 08:29 |
| smb | ericm|ubuntu, It rurns off on suspend which is what I expect | 08:30 |
| jk- | ericm|ubuntu: patchwork doesn't have a filter on incoming patches at the moment | 08:30 |
| smb | It just does not turn on on resume | 08:30 |
| jk- | but interesting idea | 08:30 |
| smb | Which it had been done until recently | 08:30 |
| smb | On the good side, this happens with the previous kernel, too | 08:30 |
| ericm|ubuntu | jk-, mmm I guess it's also useful for the linux-kernel ML, as patches toward different sub-maintainers are all flooding there | 08:31 |
| ericm|ubuntu | smb, that means a fix of a regression is seamlessly merged without our awareness? | 08:32 |
| jk- | ericm|ubuntu: most sub-maintainers have their own lists though, so it's not too bad | 08:32 |
| jk- | and akpm pick up a lot of the generic stuff | 08:32 |
| jk- | *picks | 08:32 |
| smb | ericm|ubuntu, I'd rather hope for the regression not being in the kernel | 08:32 |
| smb | There have been X updates too | 08:33 |
| ericm|ubuntu | smb, I see - now quite a work to find out that regression | 08:33 |
| smb | Even more as I see no error message anywhere, yet | 08:34 |
| smb | Hm another x-org-server-core update... Lets see | 08:34 |
| ikepanhc | smb: good morning. I read your feedback but do not understand. you mean I did not update abi information? | 08:55 |
| smb | ikepanhc, If I looked right, you forgot to update and commit the generated files | 08:55 |
| smb | Oh good morning | 08:56 |
| ikepanhc | or you mean debian/control? | 08:56 |
| smb | control control.stub and kernel-versions | 08:56 |
| ikepanhc | oh. in netbook-lpia delta, no commit update the three files | 08:56 |
| ikepanhc | these three file is the same in master branch and netbook-lpia branch | 08:57 |
| smb | Hm... I thought the rscript might change that. Give me a sec | 08:58 |
| smb | No ok, you are right that the files are ok as they are now | 09:02 |
| ikepanhc | yeah, I check again too. you update them for me :) | 09:02 |
| smb | Yes, I will pull those in | 09:03 |
| ikepanhc | thanks, I will upload now | 09:03 |
| ikepanhc | E: bzrlib must be instyalled to use sftp transport. | 09:06 |
| ikepanhc | eh, anyone know what package I shall install? | 09:06 |
| apw | ikepanhc, wasn't that announced recently, the sftp support ? per | 09:09 |
| apw | perhaps the announce tells us | 09:09 |
| ikepanhc | apw: let me check my email | 09:10 |
| smb | Though I thought that sftp wasoptional | 09:11 |
| apw | smb, it is for the normal archive, not for ikes use | 09:12 |
| smb | apw, Oh right I forgot, they always had sftp | 09:12 |
| ikepanhc | yeah, I try ftp, connection refused | 09:13 |
| apw | ikepanhc, ask on #ubuntu-devel, they'll know | 09:18 |
| ikepanhc | apw: I find the answer | 09:18 |
| ikepanhc | apw: seems because I apt-get remove bzr | 09:19 |
| ikepanhc | so I install it again | 09:19 |
| apw | hrm | 09:19 |
| apw | i wonder why those would be related without a dep | 09:19 |
| ikepanhc | yeah, I wonder too | 09:20 |
| amitk | apw: http://blog.namei.org/?p=258 (why is jj not attending?) | 09:27 |
| apw | amitk, i wasn't aware of it, are you sure he isn't ? but you should ask him when he wakes for sure | 09:28 |
| amitk | jj is sleeping!! (the horrors...) | 09:29 |
| amitk | his name is not on | 09:29 |
| smb | ikepanhc, Ok, your trees have been pushed. Don't forget to make a meta-package, too | 09:32 |
| ikepanhc | smb: eh. because of ABI bump? | 09:33 |
| smb | yep | 09:33 |
| ikepanhc | oh, I did not aware of that, checking | 09:33 |
| smb | ikepanhc, To make it more fun, we don't seem to carry a branch for that on git. I am not sure, maybe OEM did the meta package on their own | 09:35 |
| smb | apw, RAOF On of you got an idea how to kick a radeon based system in the a** to turn on the backlight? | 09:36 |
| apw | smb, which kernel is this on ? | 09:37 |
| apw | smb, i assume xset dpms force on doesn't do anything | 09:37 |
| smb | Lucid, either -22 or -23 | 09:37 |
| smb | Nope | 09:37 |
| ikepanhc | smb: yeah, I can not find it on repo, I guess I need to ping steve magoun for making sure he knows there is an ABI bump | 09:37 |
| smb | And the other backlight controls also think its on | 09:37 |
| apw | smb, hrm, no idea at alll, hopefully RAOF has some ideas | 09:38 |
| apw | smb, did you see the console suspect patch being talked about, how it might cause backlight issues (reported on .35 though) | 09:38 |
| smb | apw, Yeah, it seems to turn on when shutting down to show me plymouth... Not too useful. :-P | 09:38 |
| smb | apw, No not yet | 09:39 |
| apw | UBUNTU: SAUCE: pm: Config option to disable | 09:39 |
| apw | that thread | 09:39 |
| smb | apw, But somehow it worked before erecently | 09:39 |
| apw | yeah very odd, but it may be a stable update perhaps ? | 09:39 |
| apw | smb, did you try switching VTs ? | 09:39 |
| smb | Thats why I loaded the -22 kernel which now behaes the same | 09:39 |
| smb | Seems no reaction | 09:40 |
| amitk | apw: as I mentioned in that thread, that config should be disabled and a test kernel posted to all suspend/resume bugs to see if helps some of them | 09:40 |
| smb | But somehow this would not affect the timeframe from one week ago in Lucid and now... | 09:41 |
| smb | I try to go back one abi version further ... | 09:41 |
| apw | smb, yeah that does seem right ... | 09:41 |
| smb | apw, Doh! From time to time this stupid laptop just sits on the bios screen thinking. Gues thats why its called thinkpad | 09:45 |
| apw | smb, heheh nice | 09:51 |
| smb | apw, Grr, -21 seems to work but -22 not.Which would throw a strong suspicion on a EC patch we know of | 09:51 |
| cking | smb, the thinkpad isn't the one that's thinking, it's making *you* think | 09:57 |
| smb | cking, No, just grumpy | 09:58 |
| apw | smb, i wonder why you didn't notice it before though | 10:06 |
| smb | Yes that is odd like hell. I thought to have updated before that. Well, I try to revert that one patch and test again | 10:06 |
| apw | fingers crossed that does not help you | 10:07 |
| RAOF | smb, apw: I don't have any secret sauce to prod backlights on radeon. Intel have some patches wending their way through, though. | 10:27 |
| apw | RAOF, interesting though not helpful for smb's issue :) | 10:27 |
| smb | RAOF, Ok, thanks. Actually I went on on suspecting some stuff with the embedded controller | 10:28 |
| apw | smb, you are always dissing that poor EC patch, it is so going to get a complex | 10:28 |
| smb | apw, Oh, well. Maybe I find out in a second its not its fault.:) | 10:29 |
| apw | i do hope so | 10:30 |
| smb | I would actually, too | 10:30 |
| tseliot | apw: what's smb's issue with the backlight? | 10:36 |
| smb | tseliot, It does not turn back on after suspend | 10:37 |
| apw | tseliot, stops working on suspend/resume | 10:37 |
| apw | smb, when did it appear | 10:37 |
| tseliot | apw, smb: I have a patch that fixes the issue | 10:37 |
| smb | tseliot, In Lucid? | 10:37 |
| apw | tseliot, oh ? | 10:37 |
| apw | tell all | 10:37 |
| smb | tseliot, right, what does it change? | 10:38 |
| tseliot | apw, smb: it simply turns dpms back on on resume: https://bugzilla.kernel.org/attachment.cgi?id=26733 | 10:38 |
| tseliot | (for radeon) | 10:38 |
| tseliot | and it works well here | 10:38 |
| smb | apw, So good new, it definitely is not the EC patch | 10:39 |
| apw | smb, as in you have tested it, or that you are assuming its tseliots fix ? | 10:39 |
| smb | apw, I tested with the EC patch reverted | 10:39 |
| apw | PHEW good | 10:39 |
| smb | I now can test with tseliot s patch | 10:39 |
| smb | tseliot, I am just a bit surprised that in started to fail between the -21 and -22 kernels | 10:40 |
| tseliot | here's the upstream report: https://bugzilla.kernel.org/show_bug.cgi?id=16180 | 10:40 |
| ubot2 | bugzilla.kernel.org bug 16180 in Video(DRI - non Intel) "radeon regression with 2.6.35-rc2-00001-g386f40c: black screen after resume" [Normal,Resolved: patch_already_available] | 10:40 |
| smb | tseliot, Which are the day0 update with only two patches and the security update which also does not touch drm iirc | 10:40 |
| tseliot | smb: it's not the 1st mysterious regression I've dealth with... | 10:41 |
| tseliot | smb: wait is this in lucid's kernel? | 10:41 |
| smb | tseliot, Yes, thats what I mentioned erlier. :) | 10:42 |
| tseliot | right. I tested the patch in 2.6.35 and I'm not sure about Lucid's kernel | 10:42 |
| tseliot | still the patch should hurt | 10:43 |
| tseliot | shouldn't | 10:43 |
| tseliot | smb: does vtswitching to vt1 and then vt7 restore the backlight? | 10:44 |
| smb | I will surely give it a try after wondering a bit more what changed between .32-21 and .32-22 to make that happen | 10:44 |
| smb | tseliot, no | 10:44 |
| tseliot | hmm.. ok | 10:44 |
| smb | tseliot, Funnily the moment I say shutdown it turns on to give way to plymouth | 10:45 |
| tseliot | smb: maybe switching to graphics mode turns on the backlight | 10:46 |
| tseliot | KD_GRAPHICS mode, that is | 10:46 |
| tseliot | which is what plymouth does to show the splash | 10:47 |
| tseliot | KDSETMODE KD_GRAPHICS | 10:47 |
| smb | tseliot, killing X works too. gdm comes up and backlight is on... | 10:47 |
| smb | though there seems to be something going wrong now | 10:48 |
| smb | no network anymore | 10:49 |
| apw | smb, sounds well broken | 10:49 |
| smb | yeah, magic sysrq worked. But everything else.. | 10:50 |
| tseliot | I have a similar problem with 2.6.35. I can't reconnect (using eth0) on resume | 10:51 |
| smb | tseliot, For me it worked well until I killed the X server | 10:51 |
| tseliot | ok, it must be a different problem then. I don't see how X can block the network | 10:52 |
| smb | apw, Oh crap -21 was not a .32-21 but a .31-21. Now there is enough difference to behave differently. But I am really really sure I did suspends with a Lucid kernel before | 10:56 |
| apw | smb, you got the wrong one ? oops | 10:57 |
| apw | bfore the .33 drm update perhaps | 10:57 |
| apw | ls | 10:57 |
| smb | apw, Yeah, the Karmic kernel worked. But that could be just to different interaction with something else that broke | 10:57 |
| apw | well i say leave tseliot's patch building and try it after lunch | 10:59 |
| smb | That sounds like a good plan | 10:59 |
| tseliot | mjg59: I spoke with Alex about the atif method. Do you know of any code samples or documentation that I could look at to implement this in the radeon driver? | 13:52 |
| tseliot | so that I can see what headers I should include and what function I should call (I already know what arguments I should pass) | 13:54 |
| mjg59 | tseliot: You could look at the acpi calls in nouveau | 13:56 |
| mjg59 | I'm planning on implementing it next week - I'd have got to it this week but it turns out some of our customers can't write firmware | 13:56 |
| tseliot | :-) | 13:57 |
| apw | mjg59, you _must_ be mistaken surely | 14:00 |
| mjg59 | Who'd have thought? | 14:01 |
| mjg59 | So now I need to hack qemu to let me reproduce the behaviour under Windows in order to justify our position | 14:01 |
| apw | mjg59, that sounds _so_ familiar ... sign | 14:02 |
| tseliot | mjg59: does nouveau use atif (isn't it only for ATI?)? | 14:08 |
| mjg59 | tseliot: It uses a different ACPI interface | 14:09 |
| mjg59 | Just grep for acpi_evaluate_method | 14:09 |
| smb | tseliot, apw, Ok, so the backlight issue is the same with the patch of tseliot. But it works if I disable KMS. Why this seems to have changed recently is beyond my understanding. | 14:09 |
| tseliot | mjg59: nothing in drivers/gpu/drm/nouveau | 14:12 |
| apw | smb, thats a bit mental me thinks | 14:12 |
| tseliot | acpi_get_name is the closest thing, I guess | 14:12 |
| mjg59 | tseliot: Sorry, acpi_evaluate_object | 14:12 |
| tseliot | smb: so, it's not dpms. Is it that the backlight is off or just a black screen with the backlight on? | 14:13 |
| smb | apw, It is mental. Especially without knowing the exact state before. Just thinking it worked. | 14:14 |
| smb | tseliot, No backlight. The screen is really block without any ambient | 14:14 |
| smb | I am trying to see what happens to another laptop with ati. But it would be another card. | 14:15 |
| mjg59 | Without knowing the background, on several GPUs the backlight will refuse to turn on if LVDS has been set up incorrectly | 14:18 |
| tseliot | mjg59: what's the acpi_string pathname for atif? | 14:18 |
| tseliot | smb: can you access the laptop via ssh? | 14:19 |
| smb | mjg59, In my special case I believe to have had it working at some point | 14:19 |
| smb | tseliot, Yes | 14:19 |
| smb | tseliot, Until I kill X which seems to take the whole system into a bad state | 14:19 |
| mjg59 | tseliot: You need to get the acpi_handle for the PCI device you're working with | 14:20 |
| tseliot | smb: anything interesting in dmesg and Xorg.0.log? Also maybe you could dump the registers after resume with the driver that works and with the driver that doesn't (with avivotool regs all) | 14:20 |
| tseliot | mjg59: right but that's the 1st argument | 14:21 |
| tseliot | acpi_status | 14:21 |
| tseliot | acpi_evaluate_object(acpi_handle object, | 14:21 |
| tseliot | acpi_string pathname, | 14:21 |
| tseliot | struct acpi_object_list *parameter_objects, | 14:21 |
| tseliot | struct acpi_buffer *return_object_buffer); | 14:21 |
| smb | tseliot, Nothing obvious in the logs (radeon seems happy with things). But I will dod the dump with and without kms enabled | 14:22 |
| mjg59 | tseliot: "ATIF" | 14:23 |
| tseliot | smb: hopefully we'll see the difference in the dumps | 14:23 |
| tseliot | mjg59: "ATIF" or "_ATIF" (sorry to be such a pain) | 14:25 |
| mjg59 | ATIF | 14:25 |
| mjg59 | All ACPI methods are four characters long | 14:25 |
| tseliot | ok | 14:25 |
| tseliot | aah, it makes sense now. So if it's 3 characters long you prepend a "_" or something like that | 14:26 |
| mjg59 | A leading _ indicates that it's a reserved ACPI name | 14:29 |
| * smb like those well written tools, avivotool has two possible outcomes: called non root -> segmentation fault. Called with sudo -> lockup system | 14:30 | |
| tseliot | mjg59: ah, thanks for the info | 14:31 |
| tseliot | mjg59: if it locks up, I have a patch that can help | 14:31 |
| tseliot | a patch for avivotool | 14:32 |
| tseliot | smb: here's the patch: https://bugs.freedesktop.org/attachment.cgi?id=34810 | 14:33 |
| smb | tseliot, Thanks. This gets more and more complicated. One thing I just noticed. The pitch black screen is what I get when I switch to a text console. IOW those do not work, So the problem with resume is more likely that I fail to switch back to graphics. | 14:36 |
| smb | And I cannot do manually | 14:36 |
| === sconklin-gone is now known as sconklin | ||
| tseliot | smb: does anything change if you suspend with "sudo pm-suspend --quirk-vbe-post" ? | 15:01 |
| smb | tseliot, That probably made no difference. But I had the funny idea of removing radeonfb from the backlist-framebuffer.conf. Which caused it to be loaded in parallel with vga16fb which presumably is bad. Though right now this not only seems to make resume work but also give me usable text consoles... | 15:05 |
| smb | Heck, I thought radeonfb will get loaded automatically... | 15:05 |
| tseliot | smb: I don't think you need radeonfb as the KMS driver already provides a framebuffer device. The console driver should work | 15:09 |
| smb | tseliot, I don'T think readeondrmfb showed up on this piece of hw before. But I revert that blacklist change | 15:11 |
| mjg59 | smb: radeonfb is superceded by radeondrmfb | 15:11 |
| mjg59 | Which is automatic if you have kms | 15:11 |
| smb | mjg59, So it is on the other laptop I got | 15:12 |
| tseliot | I've never noticed radeondrmfb | 15:13 |
| smb | mjI see it starting on the Dell | 15:13 |
| smb | But I thought I had not seen in on the T42p | 15:13 |
| smb | tseliot, Hah, it _is_ there, but too late. It becomes fb1 after vga16fb is claiming to be fb0 before. Probably taking too long to initialize | 15:16 |
| tseliot | yes, initialisation could be slow | 15:19 |
| smb | Especially on this reasonable quick but still only single core machine | 15:20 |
| cking | manjo, ping | 15:21 |
| smb | tseliot, Ok, blacklisting vga16fb to give the late radeon driver a chance, results in a corrupted but after switching to an (after suspend black) text console and back give me a working X screen. | 15:29 |
| smb | tseliot, I think I will file my theory that it worked before into the myths drawer. At least the seems to be no regression | 15:29 |
| tseliot | smb: :-) | 15:31 |
| cking | bjf, hey, able to mumble to me? | 15:32 |
| smb | Damn seems mumble lost its marbles for me | 15:36 |
| bjf | cking, getting there | 15:39 |
| bjf | :-) | 15:39 |
| bjf | cking, am mumbling, shall we step out onto the balcony? | 15:50 |
| nealmcb | when I run memtest86+ on my dell 1012, it runs clean for hours, except when I insert or remove the usb connection I use to charge my android phone. Then I get an error at 0x0004c509 where the right-most byte is always "01" rather than what memtest is looking for. Can someone tell me what that address is normally used for? I get corruption of filesystems on this box regularly some time after doing a suspend and an otherwise successful resume | 15:53 |
| nealmcb | i.e. how to check the physical memory map for that addr... | 15:54 |
| === bladernr is now known as bladernr-afk | ||
| === ericm|ubuntu is now known as ericm-Zzz | ||
| ogasawara | apw: I notice you've got work items on the delta-review blueprint and the union-mounts blueprint which accomplish the same thing ie evaluate union-mount as a replacement for AUFS | 16:09 |
| ogasawara | apw: care if I delete one | 16:09 |
| apw | ogasawara, not quite sure how that occurd, but yes kill the one on delta-review i say | 16:10 |
| ogasawara | apw: ack, thanks | 16:10 |
| * ogasawara tries to find two more work items to close and drop us below our alpha2 trend line | 16:10 | |
| * apw added a work item for 'you' onto a foundations-m-686-something blueprint | 16:10 | |
| ogasawara | ok cool | 16:10 |
| * tgardner thought ogasawara was running out of things to do | 16:10 | |
| * apw has closed two already today | 16:10 | |
| * amitk invents two new arm flavours to keep ogasawara busy ;) | 16:13 | |
| ogasawara | yeek | 16:13 |
| tgardner | amitk, I see omap4 coming down the pipe. whats the second flavour? | 16:14 |
| amitk | tgardner: nothing concrete yet, but perhaps we'll take the pain there in npitre's arm tree. We've got all these partners now :) | 16:15 |
| jcastro | tgardner: fs-cache is working as expected on all the maverick machines I've tested it on! | 16:16 |
| tgardner | jcastro, ack. good to know. | 16:16 |
| tgardner | jcastro, is there a notable performance difference? | 16:16 |
| jcastro | tgardner: hard to tell with one person on one NFS share, client side, when gigabit NFS mounting not really, however over wifi on a laptop it feels nearly-local | 16:17 |
| tgardner | jcastro, how does it behave when you lose your wifi link? do things recover OK ? | 16:18 |
| jcastro | tgardner: it /seems/ too but I only ran outside with it once, I will get more testing done this next week | 16:18 |
| jcastro | tgardner: I think it would be interesting to test something like an LTSP client with local storage with an NFS /home | 16:19 |
| tgardner | jcastro, feel free :) I'm off on other tasks.... | 16:20 |
| jcastro | no worries, I'm on it! | 16:20 |
| nealmcb | when I run memtest86+ on my dell 1012, it runs clean for hours, except when I insert or remove the usb connection I use to charge my android phone. Then I get an error at 0x0004c509 where the right-most byte is always "01" rather than what memtest is looking for. Can someone tell me how to check the memory maps to find out what that address is being used for? I get corruption of filesystems on this box regularly some time after doing a suspen | 16:22 |
| nealmcb | (running lucid) | 16:22 |
| apw | nealmcb, the e820 is reported in dmesg and should tell you somthing about whats there | 16:31 |
| nealmcb | apw: thanks - I'll learn about e820's But I also recall that the kernel may change what the bios passes on for memory mapping - is there a way to get up-to-date info? | 16:33 |
| apw | it reports both the bios and the one it goes a head and uses | 16:34 |
| apw | nealmcb, what filesystem are you using which shows the corruption? | 16:34 |
| nealmcb | thanks | 16:34 |
| nealmcb | ext4 | 16:34 |
| apw | could be bios low memory curruption, thats a low page i suspect | 16:36 |
| apw | cnd, whats the low-memory bios corruption detection limit normally ? | 16:36 |
| cnd | uhhh? | 16:37 |
| cnd | apw: I think manjo knew more about that | 16:37 |
| apw | cnd, ahh fair enough thanks | 16:37 |
| nealmcb | fsck reported a few times that "inodes that were part of a corrupted orphan linked list found"... | 16:42 |
| nealmcb | a manual fsck seemed to clean it up, but dpkg was hosed a bit too - haven't finished cleaning that up | 16:43 |
| apw | nealmcb, i think we have other people with that machine and i've not heard it reported | 16:43 |
| apw | cnd, you have a 1012 i think | 16:43 |
| cnd | yes | 16:43 |
| JFo | tgardner, do you think it worthwhile to post an fs-cache CFT? | 16:43 |
| cnd | apw: what's the issue? | 16:44 |
| apw | nealmcb is seeing oddness including fs corruption on lucid ext4, possibly related to plugging in a smart phone | 16:44 |
| tgardner | JFo, I dunno if its really worth the effort. It _is_ mainline (and has been for some time), plus its elective, so I don't expect it'll cause any regressions. | 16:44 |
| JFo | ok, was just catching up on scrollback | 16:45 |
| JFo | :) | 16:45 |
| === bladernr-afk is now known as bladernr | ||
| === bladernr is now known as bladernr_ | ||
| nealmcb | cnd: I saw memtest86+ report memory errors at 4c590 every time I plugged an android phone in or out of usb. very odd - as if something in usb was mapping to that address and yielding a "01" on read access | 16:48 |
| cnd | hrm | 16:49 |
| cnd | I can try that here | 16:49 |
| cnd | I have a nexus 1 | 16:49 |
| nealmcb | I should try it with other usb devices.... mine is a g1 | 16:49 |
| cnd | nealmcb: is there a way to test this without having to boot into memtest86? | 16:49 |
| nealmcb | cnd: that is the most easily reproduced oddness I've seen | 16:50 |
| nealmcb | in memtest | 16:51 |
| nealmcb | beyond that I see regular crashes some time after resuming from suspend | 16:51 |
| nealmcb | I'm wondering if the suspend moves the memory error around and makes it worse | 16:52 |
| nealmcb | bios-e820 in dmesg says that 0 - 9dc00 is "usable" | 16:53 |
| apw | so its meant to be 'ram' there | 16:54 |
| apw | and i would not expect it to change | 16:54 |
| nealmcb | (in karmic usb-boot anyway....) | 16:54 |
| cnd | nealmcb: ok, can you run me through the steps required to recreate the issue in memtest86 | 16:54 |
| cnd | I'm not terribly familiar with it | 16:54 |
| mjg59 | nealmcb: Almost certainly the BIOS scribbling on stuff | 16:54 |
| nealmcb | I guess I can reserve the memory on boot | 16:55 |
| apw | yeah likely, i thought we had bios corrupter detection turned on by default | 16:55 |
| mjg59 | USB insertion is a prime candidate for triggering SMM | 16:55 |
| mjg59 | On the other hand, we disable USB SMIs when the hcd driver bind | 16:55 |
| cwillu_at_work | anyone have any wisdom re: compiling the xfsqa tool from the kernel tree? | 16:57 |
| nealmcb | cnd: I happened regularly yesterday when I was doing this in the car, and I'll post a picture of the screen. this morning I can't reproduce it - wonder if it was hotter then or something. I just ran the normal memtest from the grub menu, and while it was running test 3 or 4 I plugged a usb cable in and out with my android g1 attached. | 17:02 |
| cnd | nealmcb: I just tried running both tests 3 and 4 while continuously plugging in and removing my n1 | 17:10 |
| cnd | no issues here | 17:10 |
| nealmcb | cnd: thanks for checking. my memtest screen is shown here (I'll resize the picture to make it easier to see soon): https://wiki.ubuntu.com/NealMcBurnett/dell1012 | 17:31 |
| nealmcb | that shows the errors in test 6, but I think it happened with most any test | 17:33 |
| cnd | well, the simplest solution is to try new memory :) | 17:33 |
| nealmcb | I'll try to reproduce it some more at this end. I had the filesystem problems with the original 1GB memory card, so I think it is more likely to be some problem with the usb or bus or something. but I'll try to reproduce it more | 17:34 |
| ogasawara | apw: just browsing through the debian commonisation patch for Maverick and notice we had to hard code "series := maverick" in debian/rules.d/0-common-vars.mk | 17:54 |
| ogasawara | apw: so presumably whomever open the M+1 release will have to remember to update that bit | 17:55 |
| apw | ogasawara, yeah there are a couple of places the series is used, and over time i am going to convert them over to that | 17:55 |
| ogasawara | apw: cool | 17:55 |
| JFo | <-lunch | 17:55 |
| apw | ogasawara, the plan is that the update-debian script will use that | 17:55 |
| apw | sorry apply that as its copied in, its @SERIES@ in the orignal | 17:55 |
| apw | right now there are other places which have lucid say in, like control.stub.in, which i want to convert to using that one instance | 17:56 |
| apw | but tis a bigger job than i wanted to bite off at this point | 17:56 |
| ogasawara | apw: ok so still some cleaning up but getting us in the right direction, I'll get it applied | 17:56 |
| apw | yeah, adding one to remove 5 others long term, in this one it adds one and removes one | 17:57 |
| tseliot | mjg59: shall I check the existence of the ATIF method before calling it or is it fine to just call acpi_evaluate_object? | 18:06 |
| mjg59 | tseliot: You can call it, but you should handle the failure appropriately | 18:07 |
| mjg59 | status will be AE_NOT_FOUND if it's not there | 18:07 |
| tseliot | mjg59: ah, but it should suffice to check ACPI_FAILURE(status) | 18:09 |
| mjg59 | Check status | 18:09 |
| mjg59 | if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {printk("Things are broken\m"); return -1}, or something | 18:10 |
| tseliot | ok, thanks again | 18:11 |
| === sconklin is now known as sconklin-lunch | ||
| tseliot | mjg59: do you think we should print something if atif is not there too (without failing)? | 18:17 |
| mjg59 | I don't think so | 18:20 |
| mjg59 | There's no point in printing kernel messages when something valid happens | 18:20 |
| tseliot | ok | 18:24 |
| tgardner | apw, how are you intending to apply debian commonization bits from ubuntu-debian ? are you using initial-rollout/MAKER to splatter the various branches? | 18:37 |
| apw | tgardner, that is the initial-rollout yes, next step for me is distill out just the updater from it | 18:38 |
| apw | and that stuff will get removed and replaced by 'UPDATE' sort of thing | 18:38 |
| apw | and a 'README' of course | 18:38 |
| tgardner | apw, so, I'm working on the maverick ti-omap4 branch. shall I just rsync the debian directory and go from there? | 18:39 |
| apw | tgardner, ahh you need to change the @SERIES@ to the right thing | 18:40 |
| apw | there is a log generator in there as well, but you could just steal the commit message from maverick | 18:41 |
| tgardner | apw, not sure to what you are referring? | 18:41 |
| tgardner | got SERIES fixed | 18:42 |
| === sconklin-lunch is now known as sconklin | ||
| apw | yeah the idea is the updater will do that as it copies it in, and will do the changelog as per mavericks update for example | 18:43 |
| apw | see how the changelog contains the buglinks etc from the ubuntu-debian changelog | 18:43 |
| apw | if you are commiting the tip of u-d as of now, then whats in maverick should be the same, so youc ould cut-n-paste it | 18:43 |
| apw | the updater will know how to do that | 18:43 |
| tgardner | apw, for this first time I probably don't have to worry about that, right? | 18:44 |
| tgardner | its an initial commit | 18:44 |
| apw | tgardner, oh i see, yeah its the initial version of the branch ...# | 18:44 |
| johanbr | this is weird... under 2.6.35-3, /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq always reports maximum frequency | 18:46 |
| johanbr | ondemand governor, negligible load | 18:46 |
| apw | johanbr, its not systemic as my local machine has that on and is at 800MHz mostly | 18:46 |
| apw | johanbr, do you have lots of kslowd's eating CPU? | 18:47 |
| johanbr | no, I don't think so | 18:48 |
| johanbr | I have some other kernels installed, will reboot a few times and see when it started appearing... | 18:48 |
| johanbr | hmm... OTOH, powertop says CPU spends 99.6% of the time at 800 MHz | 18:50 |
| apw | hrm | 18:51 |
| === JanC_ is now known as JanC | ||
| tgardner | apw, wrt to the config checker, why is debian.master/config required? ti-omap4 is currently 2.6.34 based, so it seems a bit odd to require 2.6.35 config options. | 19:04 |
| * tgardner lunches | 19:11 | |
| * cking calls it day | 19:29 | |
| bcurtiswx | with 20 people affected it may be worth looking at bug #548992, with some recent good information for debugging | 19:36 |
| ubot2 | Launchpad bug 548992 in debian (and 1 other project) "Wireless connection frequently drops [deauthenticating by local choice (reason=3)] (affects: 21) (heat: 152)" [Undecided,New] https://launchpad.net/bugs/548992 | 19:36 |
| bcurtiswx | now 21 apparently, lol | 19:36 |
| * JFo looks | 19:37 | |
| JFo | looks like someone changed it to confirmed before it hit my radar | 19:38 |
| JFo | so bcurtiswx am I right in my assumption that this issue now appears to be a result of network-manager and DHCP? | 19:39 |
| JFo | if so, this may need to be looked at by the n-m folks | 19:39 |
| JFo | bcurtiswx, are you affected by it as well? | 19:40 |
| bcurtiswx | JFo: well, i don't know enough to say its not one or the other. I have been affected by it, and actually will look to see if its happening again as i have been disconnected on occasion today without warning | 19:41 |
| JFo | hmmm, if it still seems to be the case, are you willing to try some other network manager? | 19:41 |
| JFo | to see if using that resolves it? | 19:41 |
| JFo | so that we can narrow? | 19:41 |
| bcurtiswx | i'd be happy to help, what should I try | 19:41 |
| JFo | on that I am not completely certain | 19:42 |
| JFo | I have seen other cases reported like this where they tried a different connection manager | 19:42 |
| JFo | let me see what I can find | 19:42 |
| bcurtiswx | Ok | 19:42 |
| bcurtiswx | and I apologize if i get DC.. i'll try to recognize it and get back ASAp | 19:43 |
| JFo | bcurtiswx, I am under the impression that we are looking at connection-manager for maverick, but don't quote me :) | 19:43 |
| JFo | bcurtiswx, no problem | 19:43 |
| bcurtiswx | JFo: OK | 19:44 |
| JFo | looks like WICD is one that has been tested | 19:44 |
| JFo | let me see if there are others | 19:44 |
| bigcx2 | hey all, i kinda have an off the wall question for all you gurus :) | 19:46 |
| bigcx2 | i'm trying to create a custom live cd and i have a custom squashfs image i would like to mount for it | 19:47 |
| bigcx2 | but everytime i boot it up, it says that it can't find a bootable medium | 19:48 |
| bigcx2 | but | 19:48 |
| bigcx2 | i can succesfully mount the squashfs image by hand | 19:48 |
| bigcx2 | from the initramfs prompt i get dropped into | 19:48 |
| bigcx2 | but how do i get past the initramfs shell and into my squashfs image? | 19:48 |
| bigcx2 | i've seen stuff around with mount -o move but i can't quite get it right | 19:49 |
| bcurtiswx | JFo: would it help to say that at home I don't get this problem, but here at work I do (Campus network) | 19:49 |
| JFo | interesting | 19:50 |
| JFo | it would help very much | 19:50 |
| bcurtiswx | lemme know anything you need from my comp and i'll pastebin it | 19:50 |
| JFo | will do | 19:52 |
| jjohansen | Lunch -> | 19:52 |
| ogasawara | apw: CONFIG_INIT_PASS_ALL_PARAMS I'm assuming it's not necessary to have that turned on for ports? ie I can disable it for ports. | 19:53 |
| tgardner | ogasawara, won't they have the same upstart? | 19:54 |
| ogasawara | tgardner: that's true | 19:54 |
| tgardner | I don't think CONFIG_INIT_PASS_ALL_PARAMS is arch dependent | 19:55 |
| JFo | it annoys me to no end that e-mail I send to ubuntu-devel must await moderator approval | 19:58 |
| bcurtiswx | are you a devel member? i think they wanted devel for members only and devel-discuss for anyone.. no sure tho | 20:01 |
| unlex | hi | 20:02 |
| unlex | what is the use of afence register? | 20:02 |
| JFo | bcurtiswx, just griping. I think it is something I could fix if I were so inclined :) | 20:04 |
| JFo | I just like to gripe every so oftn | 20:04 |
| JFo | often* | 20:04 |
| bcurtiswx | nothing wrong with that :) | 20:04 |
| JFo | :-D | 20:04 |
| unlex | anyone understand fence registers here? | 20:04 |
| bcurtiswx | unlex: IDK, but my google search returned http://is.gd/cT98f | 20:08 |
| JFo | manjo, where is the git repo for the kernel-qa bits? /me forgets | 20:09 |
| JFo | could have sworn I had a cloned branch of it, but I can't find it | 20:10 |
| bcurtiswx | JFo: got DC | 20:27 |
| apw | ogasawara, doh yeah, should be on for ports as well yes, sorry | 20:32 |
| ogasawara | apw: no worries, enabled it and it's building nicely now | 20:33 |
| ogasawara | mpoirier: bug 591941 is on the release meeting agenda tomorrow. is there any update there and if so, could you post it as a comment to the bug? | 20:39 |
| ubot2 | Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/591941 | 20:39 |
| mpoirier | ogasawara: hold on a sec, I'll look at it. | 20:39 |
| mpoirier | ogasawara: I am currently working with TI people on it. | 20:40 |
| ogasawara | mpoirier: ok thanks | 20:43 |
| ogasawara | mpoirier: any idea if a resolution will happen before next friday (as that's the cut off date for our Alpha2 kernel)? | 20:44 |
| ogasawara | mpoirier: else I'll bump the milestone on the bug out to alpha3 | 20:45 |
| mpoirier | ogasawara: it is hard to say if we'll have a solution. | 20:45 |
| mpoirier | we are faced with a timing issue introduced by the preemption model. | 20:45 |
| mpoirier | I will bump the milestone to alpha3. | 20:46 |
| mpoirier | That way no one is disapointed. | 20:46 |
| ogasawara | mpoirier: perfect thanks. | 20:46 |
| mpoirier | ogasawara: done with comments and bumped milestone | 20:50 |
| ogasawara | mpoirier: sweet thanks, it makes my life easier for tomorrows meeting | 20:51 |
| Sleep_Walker | amitk: there is even no DMA support for MX5 :/ | 20:54 |
| JFo | -ENOCONTEXT | 21:19 |
| * ogasawara lunch | 21:20 | |
| === kentb is now known as kentb_out | ||
| tseliot | mjg59: I'm getting "Return, Return, Super_L" if I press that key with atif (and acpi_osi="!Windows 2009") | 22:01 |
| tseliot | still no event is listed in acpi_listen | 22:01 |
| mjg59 | Unsure what's wrong then, I'm afraid | 22:02 |
| tseliot | I didn't get anything before calling atif | 22:02 |
| kees | the strangest things appear in kernel builds: | 22:05 |
| kees | II: New modules (you've been busy, wipe the poop off your nose) | 22:05 |
| tseliot | mjg59: is there some acpi spec I can look at with all these methods (including atif)? | 22:05 |
| mjg59 | No, atif is entirely specced by ATI | 22:05 |
| kamal | kees: yeah, when there are no new modules then it calls you a "slacker" | 22:06 |
| kees | kamal: hah! | 22:06 |
| tseliot | mjg59: ok | 22:06 |
| mjg59 | Everything that's standardised is in the ACPI specification, which you can get from www.acpi.info | 22:07 |
| tgardner | kees, thats a BenC original :) | 22:09 |
| tseliot | mjg59: great, thanks for the link | 22:12 |
| tseliot | mjg59: does _DOS have anything to do with this? | 22:19 |
| tseliot | not that it would explain the lack of that acpi event.. | 22:20 |
| mjg59 | tseliot: If _DOS isn't set correctly then you won't get hotkey events | 22:22 |
| tseliot | mjg59: ah, so brightness keys shouldn't work | 22:22 |
| mjg59 | Hm. Brightness typically will | 22:24 |
| mjg59 | But not display switch | 22:24 |
| tseliot | mjg59: ah, so you're saying that I might be on the right track? | 22:25 |
| mjg59 | It's possible | 22:25 |
| tseliot | mjg59: if so, I would just have to implement another function and set the right bits. That would be great (if it worked) | 22:29 |
| mjg59 | tseliot: _DOS should be set at boot time | 22:30 |
| mjg59 | You can alter it through /proc/acpi/video/DOS | 22:30 |
| tseliot | mjg59: ah, how? It says DOS setting: <4> | 22:32 |
| mjg59 | Just write to it | 22:32 |
| mjg59 | Hang on a moment... | 22:32 |
| tseliot | in /proc/acpi/video/VGA2/DOS | 22:32 |
| tseliot | ok | 22:32 |
| mjg59 | 4 should be correct for getting events | 22:33 |
| tseliot | the default should be 1 though | 22:33 |
| tseliot | mjg59: "The system BIOS, when doing switching of the active display, must verify the state of the variable set by the _DOS method. The default value of this variable must be 1" | 22:36 |
| mjg59 | Yeah, which means you don't get events | 22:36 |
| mjg59 | That's why it's changed by the OS | 22:36 |
| tseliot | right | 22:37 |
| tseliot | mjg59: I guess I should set the 1st bit to 3 | 22:38 |
| mjg59 | tseliot: You can try, but 0 or 4 is correct for getting hotkey events | 22:38 |
| tseliot | I see | 22:39 |
| tseliot | right, nothing changes | 22:41 |
| tseliot | mjg59: I guess my only chances are _DCS, _DGS and _DSS | 22:46 |
| tseliot | according to the acpi spec 40a they are all "Required if the system supports display switching (via hotkey)" | 22:48 |
| mjg59 | The spec requires them, but they do nothing useful | 22:50 |
| tseliot | hmm... maybe it's worth bugging AMD about this | 22:52 |
| tseliot | anyway something I can do tomorrow | 22:55 |
| tseliot | good night | 22:55 |
| === bjf is now known as bjf[afk] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!