19:57 -!- Irssi: Starting query in freenode with mjg59
19:59 <shining^> hey. afaik you are familiar with both kms and acpi, did you ever look at this bug : https://bugzilla.kernel.org/show_bug.cgi?id=15322 ? :)
20:00 <shining^> seems to be a big mystery that no one has the slightest clue on . or just doesn't care, not sure
20:01 <mjg59> Yeah, that one I have *no idea* about
20:02 <shining^> we just got a third r50e user in the fdo report :)
20:02 <mjg59> I can take a look
20:02 <mjg59> But I suspect some SMI that pokes the video hardware and makes assumptions
20:02 <mjg59> The "e" in R50e stands for "suck"
20:03 <shining^> eheh. well maybe it's not as good as other thinkpads, but I was quite happy with it when I had it
20:03 <shining^> it had nothing to be ashamed of compared to the other laptops I had (non ibm)
20:04 <shining^> I was wondering if this was one case where we would need a dev to have direct access to the hardware
20:04 <mjg59> It may be, but if it involves system management mode it's not going to be easy
20:07 <mjg59>                 \SWA1 ()
20:07 <mjg59>                 \VVPD (0x03)
20:07 <mjg59>                 \TRAP ()
20:07 <mjg59> I'd bet it's that chunk
20:07 <shining^> uhm where does that come from ? :)
20:07 <mjg59> Basically, we have no way of knowing what that code does
20:07 <mjg59> The ACPI tables
20:08 <shining^> ah
20:08 <mjg59> Part of the _PTS method
20:08 <mjg59> Those are all SMI functions
20:08 <mjg59> Which trigger the CPU to run some code that's hidden from the OS
20:08 <mjg59> We don't know what that code does
20:08 <mjg59> But it's presumably making an incorrect assumption about the video state
20:08 <mjg59> So we're programming something differently to Windows
20:08 <mjg59> But we don't know what, and we can't see what that code's doing
20:08 <mjg59> Which makes fixing it... difficult
20:09 <shining^> its not possible to spy what windows is doing either ?
20:10 <mjg59> There's likely to be a lot of state difference
20:10 <shining^> and for stuff like this, hardware vendors never ever help / answer ?
20:10 <mjg59> I guess we could try bisecting through the differences between text mode and KMS
20:10 <mjg59> But that's likely to result in a pile of other hangs...
20:26 <shining^> I am trying to read the acpidump of the other guy, I think I find the \_PTS section, I see the \VVPD 0x03 \TRAP inside. But I dont see \SWA1 before that
20:30 <mjg59> Probably a version difference
20:31 <shining^> which acpidump did you look at ?
20:31 <mjg59> Oh, wait. I'm looking at r51e
20:32 <mjg59> Unless it's failing on the backlight saving. Hrm.
20:33 <shining^> I actually didnt post acpidump, but I made two : one with original bios version I was still using, one with latest one. I tried to compare to the one Ferenc did and they all looked very different
20:33 <mjg59> Arg0 will be 3 (for S3), so the only lines that run are:
20:33 <mjg59>             Store (Arg0, \SPS)
20:33 <mjg59>             \_SB.PCI0.LPC.EC.HKEY.MHKE (0x00)
20:33 <mjg59>             If (\_SB.PCI0.LPC.EC.KBLT)
20:33 <mjg59>             {
20:33 <mjg59>                 \UCMS (0x0D)
20:33 <mjg59>             }
20:33 <mjg59>             If (LEqual (Arg0, 0x03))
20:33 <mjg59>             {
20:33 <mjg59>                 \VVPD (0x03)
20:33 <mjg59>                 \TRAP ()
20:33 <mjg59>             }
20:33 <mjg59>             If (LNotEqual (Arg0, 0x05))
20:34 <mjg59>             {
20:34 <mjg59>                 Store (0x01, \_SB.PCI0.LPC.EC.HCMU)
20:34 <shining^> oooh how do you get a nice output like that ? :)
20:34 <mjg59> One thing you can do is add a modified DSDT to your kernel
20:34 <mjg59> iasl
20:34 <mjg59> Then you could figure out which line causes it
20:34 <mjg59> I suspect it's either VVPD or TRAP
20:35 <mjg59> But if it's any of the others, that makes life much easier
20:35 <mjg59> http://www.lesswatts.org/projects/acpi/overridingDSDT.php has instructions
21:11 <shining^> oh I love you, you're the best ! :)
21:12 <shining^> wait its supposed to be a bad news
21:13 <shining^> anyway its cool to have gone one level deeper. now lets see which line of the two it is
21:15 <shining^> well not only that, its also awesome to have a workaround. its quite easy to do. there wasnt any workaround to that problem before besides staying on outdated stack/distrib
21:21 <shining^> so just removing \VVPD (0x03) fixes the problem