Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, It looks like it has Intel graphics: vgapci0@pci0:0:2:0: class=0x03 card=0x201a17aa chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS, 943/940GML Express Integrated Ah, then i915.ko should restore the graphic state on resuming. If your problem still remains, please try the patches: http://people.freebsd.org/~iwasaki/acpi/syscons-vesa-resume-20120529.diff Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[CFT] radeon_suspend/resume patch
Hi, I created the patches for drm/radeon in order to restore the graphic state on resuming (ported from NetBSD code). http://people.freebsd.org/~iwasaki/acpi/drm-radeon_suspend-20120623.diff Unfortunately, I don't have the machine to test the patches. Can anyone test this? Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] radeon_suspend/resume patch
Hi, I have a desktop with Radeon 9550 AS. How can I trigger suspend/resume on that one manually? It's depends on whether the system support S3. Please check it like this; # sysctl hw.acpi.supported_sleep_state If supported, to suspend; # acpiconf -s 3 or # zzz To resume, just press the power button. Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] radeon_suspend/resume patch
Hi, I'll try to build image for booting off flash drive with this patch. Do xorg-server required to test it? If possible, yes. Assuming the screen crashes on resuming, I'm expecting the patches solve this problem (both X and console). Please note that radeon.ko should be loaded before suspending. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] radeon_suspend/resume patch
Thanks for your thrilling report! I rebooted into X with Fluxbox as my window manager. Ran sudo acpiconf -s3 from an xterm. Machine correctly went to sleep. I waiting 30s and then pressed the power button. Machine came back, loaded X up correctly and everything kept working. Amazing! OK, I'll commit the patches against head tomorrow. BTW, is it effective for the console which is set graphic mode by vidconrol(1) as well? Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, FWIW, Xorg suspend/resume via the switch to VTY before suspending hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Your T60 has a Radeon graphic adapter, right? Could you try the radeon suspend/resume patch and kldload radeon.ko before suspending? http://people.freebsd.org/~iwasaki/acpi/drm-radeon_suspend-20120623.diff Thanks Hi, No, I didn't have vesa loaded. I'll load that now and try tomorrow after a reboot. Yes, I tried switching VTYs, each VTY had the same issue. I guess the driver isn't doing a VGA mode change when I switch VTYs unless the screens are in different modes? FWIW, Xorg suspend/resume via the switch to VTY before suspending hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, Loading vesa didn't help. I think 80x25 and 80x30 were fine when resuming, but 80x50/80x60 weren't. I'll try your patch today. If you have problems with screen saver, please try new patches. http://people.freebsd.org/~iwasaki/acpi/syscons-vesa-resume-20120529.diff Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, No, I didn't have vesa loaded. I'll load that now and try tomorrow after a reboot. vesa(4) has video BIOS init hack run in vm86-mode or on x86 emulator. I think it is cool. My X61 still need video BIOS init in acpi_wakecode, because it seems vesa's BIOS init ends incompletely by page fault for now though. yes, I tried switching VTYs, each VTY had the same issue. I guess the driver isn't doing a VGA mode change when I switch VTYs unless the screens are in different modes? If you have a vty with initial video mode, switching vtys will work I think. Oh yes, please try the following patches. http://people.freebsd.org/~iwasaki/acpi/syscons-vesa-resume-20120526.diff This is already done in vesa(4), added support non-vesa mode. FWIW, Xorg suspend/resume via the switch to VTY before suspending hack works on this Thinkpad T60. It's not optimal but hey, it _does_ work. :) Long time ago, I added the hack trying to make it as small as possible for the same effect :) Now we need the true solution... Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, thanks for reporting! However, the video mode isn't restored. I have my console set to VGA_80x60 and the resume seems to set it up wrong. I get half or so of each line displayed. A vidcontrol VGA_80x60 restores things to proper working order. Is there a shortcoming somewhere in syscons/ACPI video restore on -9 that doesn't properly restore the configured mode? Do you have vesa(4) in your kernel? It seems dev/fv/vesa.c:vesa_bios_post() restore the mode when resuming, but it's maybe incomplete in some cases... I think great work was done in this area, and we can improve this more. How about switching vty to other different mode vty and switching back in order to force changing video mode? I think it's better than re-run vidcontrol. Thanks again for all your hard work! Now that you've done that, I'll go off and work on fixing up ath(4) suspend/resume for PCI devices. :) This is my pleasure :) Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FIXED -- Thanks! Re: ep0 eeprom failed to come ready...
Hi,
Grrr, It's too difficult because I can't do anything after the messsage
even etner DDB or pause screen and back scrolling...
Use the serial console.
Sorry, I don't have null-modem cable or 3c5x9cfg.exe or DOS here, but
I did some hacks. By follwing patch made referring to 3-STABLE code,
system was passed ep probe/attach routine with correct mac address and
stopped /etc/rc.network in userland now.
BTW, I found very strange thing, my system stopped at epstop() in
ep_attach()...
Index: if_ep.c
===
RCS file: /home/ncvs/src/sys/dev/ep/if_ep.c,v
retrieving revision 1.99
diff -u -r1.99 if_ep.c
--- if_ep.c 2000/03/13 11:59:21 1.99
+++ if_ep.c 2000/03/22 18:44:55
@@ -270,7 +270,9 @@
sc-gone = 0;
+#if 0
ep_get_macaddr(sc, (u_char *)sc-arpcom.ac_enaddr);
+#endif
/*
* Setup the station address
@@ -278,6 +280,9 @@
p = (u_short *)sc-arpcom.ac_enaddr;
GO_WINDOW(2);
for (i = 0; i 3; i++) {
+#if 1
+ p[i] = htons(sc-epb.eth_addr[i]);
+#endif
outw(BASE + EP_W2_ADDR_0 + (i * 2), ntohs(p[i]));
}
@@ -331,8 +336,9 @@
EP_FSET(sc, F_RX_FIRST);
sc-top = sc-mcur = 0;
+#if 0
epstop(sc);
-
+#endif
return 0;
}
Index: if_ep_isa.c
===
RCS file: /home/ncvs/src/sys/dev/ep/if_ep_isa.c,v
retrieving revision 1.8
diff -u -r1.8 if_ep_isa.c
--- if_ep_isa.c 2000/01/23 08:46:21 1.8
+++ if_ep_isa.c 2000/03/22 18:45:22
@@ -145,6 +145,8 @@
return (NULL);
}
+u_shortep_isa_eth_addr[16][3]; /* irq, addr */
+
static void
ep_isa_identify (driver_t *driver, device_t parent)
{
@@ -158,6 +160,7 @@
u_int32_t ioport;
u_int32_t isa_id;
device_tchild;
+ u_short eth_addr[3];
outb(ELINK_ID_PORT, 0);
outb(ELINK_ID_PORT, 0);
@@ -195,6 +198,10 @@
(void)get_eeprom_data(ELINK_ID_PORT, j);
}
+ for (j = 0; j 3; j++) {
+ eth_addr[j] = get_eeprom_data(ELINK_ID_PORT, j);
+ }
+
/*
* Construct an 'isa_id' in 'EISA'
* format.
@@ -218,6 +225,10 @@
data = get_eeprom_data(ELINK_ID_PORT, EEPROM_RESOURCE_CFG);
irq = (data 12);
+ for (j = 0; j 3; j++) {
+ ep_isa_eth_addr[irq][j] = eth_addr[j];
+ }
+
/* Retreive IOPORT */
data = get_eeprom_data(ELINK_ID_PORT, EEPROM_ADDR_CFG);
#ifdef PC98
@@ -305,6 +316,7 @@
{
struct ep_softc * sc = device_get_softc(dev);
int error = 0;
+ int irq, i;
if ((error = ep_alloc(dev))) {
device_printf(dev, "ep_alloc() failed! (%d)\n", error);
@@ -315,6 +327,11 @@
GO_WINDOW(0);
SET_IRQ(BASE, rman_get_start(sc-irq));
+
+ irq = bus_get_resource_start(dev, SYS_RES_IRQ, 0);
+ for (i= 0; i 3; i++) {
+ sc-epb.eth_addr[i] = ep_isa_eth_addr[irq][i];
+ }
if ((error = ep_attach(sc))) {
device_printf(dev, "ep_attach() failed! (%d)\n", error);
Index: if_epvar.h
===
RCS file: /home/ncvs/src/sys/dev/ep/if_epvar.h,v
retrieving revision 1.4
diff -u -r1.4 if_epvar.h
--- if_epvar.h 2000/01/15 05:21:43 1.4
+++ if_epvar.h 2000/03/22 18:09:32
@@ -27,6 +27,7 @@
int cmd_off;/* command offset (bit shift) */
int mii_trans; /* activate MII transiever */
u_short res_cfg;/* resource configuration */
+ u_short eth_addr[3];/* Ethernet address */
};
/*
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #14: Thu Mar 23 03:45:36 JST 2000
root@celeron:/usr/src/sys/compile/CELERON
Calibrating clock(s) ... TSC clock: 367492994 Hz, i8254 clock: 1193158 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x660 Stepping = 0
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory = 134205440 (131060K bytes)
Physical memory chunk(s):
0x1000 - 0x0009, 651264 bytes (159 pages)
0x0039b000 - 0x07ff2fff, 130383872 bytes (31832 pages)
avail memory = 126472192 (123508K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00f9ce0
bios32: Entry = 0xf0520 (c00f0520) Rev = 0 Len = 1
pcibios: PCI BIOS
