-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-03 16:47:47 -0400, John Baldwin wrote: > On Tuesday, September 03, 2013 4:12:01 pm Jung-uk Kim wrote: >> On 2013-09-03 12:28:30 -0400, John Baldwin wrote: >>> On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: >>>> (cc jkim) >>>> >>>> Hi! Would you mind taking a look at the -acpi list posts >>>> with this subject? It looks like a lot of the video >>>> suspend/resume issues on these thinkpads boil down to the >>>> VESA driver code. If it's disabled, (at least) x11 resume >>>> works. >>>> >>>> Would you be able to help us track down what's going on? >>>> >>>> Thanks! >>> >>> Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is >>> calling vidd_save_state() and vidd_load_state() which in the >>> VESA case map to the _save_state() and _load_state() methods >>> in sys/dev/fb/vesa.c. >> >> Unfortunately, I don't really know where it actually fails >> because I do not have *any* Intel GPUs to test. If vesa.c is >> really causing trouble, vesa_bios_post() in vesa_load_state() may >> be the culprit, however. > > I can try narrowing it down.
Please do. >>> These methods look fairly sane to me, so it's probably either >>> a BIOS bug, or the fact that KMS is bypassing the BIOS, so when >>> KMS is active we should perhaps disable the VESA BIOS. >> >> AFAIK, KMS does not play nice with syscons(4) ATM, e.g., syscons >> does automatic VT switching and it may need to be turned off. >> Again, it is just my guess. > > Well, I don't have to do that, just having no VESA in the kernel > results in resume working fine in X. It seems that the i915drm > driver is doing something to explicitly enable the backlight on the > LCD btw. Normally, I expect a device tree like this to do properly suspend/resume with *drm1*: nexus0 acpi0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 dpms0 drm0 ... isab0 isa0 sc0 vga0 ... Not sure about i915kms.ko. >>> However, one thing that might help is that this is being called >>> at a "random" time rather than when vgapci0 is being suspended >>> and resumed. Actually, it looks like jkim fixed this via the >>> vgapm driver, except I have no vgapm0 device on my laptop. >> >> If you don't have vgapm0, its BIOS is not setting >> PCIB_BCR_VGA_ENABLE bit to its bridge. Often times, that means >> it is "legacy free" stuff. >> >>> I wonder if it's supposed to be device_get_unit() instead of >>> device_get_flags() in the vgapm identify routine? >> >> No. With multiple GPUs, it is (was?) the only way to find the >> "boot display" because unit number is not always 0. Although >> dumbbell added vga_pci_is_boot_display() in current, this >> interface should be kept for 9.x. > > Hmm, so there is magic to set this I guess? Ah, I see it now in > vga_pci.c. That does seem gross compared to an ivar or some such. > :) And you said the almost exact same thing but okayed at the time. :-) > In my case btw, x86bios_match_device() doesn't work because the > BIOS ROM has a PCI device ID of 0x0106 while the device itself is > 0x0126. It's a bug. > Even with that hacked so I force vgapm0 and dpms0 to attach, I > still can't resume in console mode, and resume in X refuses to > wakeup with VESA in the kernel (hitting the power button doesn't > make it wakeup). Please try to make syscons resume first. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJmgdAAoJECXpabHZMqHOh6kH/RpRVeXz3n8eb72PMfZ1eQDy 2LBn/NCpxbRAHhNkwclLqCorQp6CDAEM1iO4IJMgUG4BrRYcrGUybM7kHDGn5Oy3 7qLkXmu1TmBGwFndHMZ8VaqLsUV2mgKG1DLgCCEp2NG3szOuSgg1KwBaZuT1OUhm TtJIWyuuwWld+DAaBaJJqCTJun6s3rpddXIEKj/2R+f4q99cjLt5I5qel+goArE+ yym4VrkY0S1Fn3Vj5+Nv8WMXlTgknIymsEg7fNJ9RDBGDPZ11l5DLztLjj+UfvIL K6L3+AMNJ58HRA/PibPIGNgI0WXUDJ/KSNN0A44RIItiYwTxJSh482PkghlrLE4= =jHx2 -----END PGP SIGNATURE----- _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"