Menu
▾
▴
suspend-devel — Linux Suspend Development List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(75) |
Mar
(232) |
Apr
(182) |
May
(75) |
Jun
(143) |
Jul
(184) |
Aug
(197) |
Sep
(223) |
Oct
(134) |
Nov
(257) |
Dec
(187) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(242) |
Feb
(230) |
Mar
(283) |
Apr
(200) |
May
(252) |
Jun
(117) |
Jul
(368) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alon Bar-L. <alo...@gm...> - 2007-07-31 19:56:13
|
On Tuesday 31 July 2007, Luca wrote: > > http://suspend.sf.net/s2ram-support.html > > I've also updated the link on the documentation page. > > Luca > Thanks for such quick response! Here is a patch for the rest of the files. Alon. --- diff -urNp suspend.org/README suspend/README --- suspend.org/README 2007-06-01 09:55:49.000000000 +0300 +++ suspend/README 2007-07-31 22:48:52.000000000 +0300 @@ -45,8 +45,7 @@ http://www.codon.org.uk/~mjg59/vbetool/) above) you also have to install the zlib development package (zlib-devel on SUSE, zlib1g-dev on Debian). -For debugging, see http://www.opensuse.org/ACPI_Suspend_debugging and -http://en.opensuse.org/S2ram . +For debugging, see http://suspend.sf.net/s2ram-support.html. acpi-support package from Ubuntu has *very* long whitelist of machines: http://packages.ubuntu.org.cn/dapper/admin/acpi-support that are likely to diff -urNp suspend.org/README.s2ram-whitelist suspend/README.s2ram-whitelist --- suspend.org/README.s2ram-whitelist 2007-01-17 14:30:47.000000000 +0200 +++ suspend/README.s2ram-whitelist 2007-07-31 22:49:39.000000000 +0300 @@ -168,7 +168,7 @@ usually provides faster response times a Any additions / corrections to this document are always welcome. There is also a similar document available online (which might even contain -newer information) as http://en.opensuse.org/S2ram +newer information) as http://suspend.sf.net/s2ram-support.html. Have a lot of fun... diff -urNp suspend.org/s2ram-x86.c suspend/s2ram-x86.c --- suspend.org/s2ram-x86.c 2007-07-20 18:48:17.000000000 +0300 +++ suspend/s2ram-x86.c 2007-07-31 22:47:11.000000000 +0300 @@ -62,7 +62,7 @@ void identify_machine(void) " sys_version = \"%s\"\n" " bios_version = \"%s\"\n", sys_vendor, sys_product, sys_version, bios_version); - printf("See http://en.opensuse.org/S2ram for details.\n" + printf("See http://suspend.sf.net/s2ram-support.html for details.\n" "\n" "If you report a problem, please include the complete output " "above.\n"); @@ -139,7 +139,7 @@ int s2ram_check(int id) " but the entry has not been confirmed.\n" "Please try to find the best options and " "report them as explained on\n" - "http://en.opensuse.org/S2ram.\n\n"); + "http://suspend.sf.net/s2ram-support.html.\n\n"); } return ret; |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 19:47:28
|
On Tue 2007-07-31 21:45:14, Luca wrote: > On 7/31/07, Pavel Machek <pa...@uc...> wrote: > > On Tue 2007-07-31 21:35:59, Alon Bar-Lev wrote: > > > On 7/31/07, Pavel Machek <pa...@uc...> wrote: > > > > Hmm, IIRC we _do_ have some webmaster, already. Ok, lets keep pages in > > > > suse wiki, then. > > > > > > Excuse me for not understanding such short messages... > > > Are you doping the idea of link only suspend site and redirect from > > > suspend site to suse wiki? > > > Or you will ask your "some webmaster" to add the new URL? > > > > Luca, could you add redirect from suspend.sf.net to s2ram wiki in > > suse? Alon knows what is required... > > http://suspend.sf.net/s2ram-support.html > > I've also updated the link on the documentation page. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Luca <kro...@gm...> - 2007-07-31 19:45:17
|
On 7/31/07, Pavel Machek <pa...@uc...> wrote: > On Tue 2007-07-31 21:35:59, Alon Bar-Lev wrote: > > On 7/31/07, Pavel Machek <pa...@uc...> wrote: > > > Hmm, IIRC we _do_ have some webmaster, already. Ok, lets keep pages in > > > suse wiki, then. > > > > Excuse me for not understanding such short messages... > > Are you doping the idea of link only suspend site and redirect from > > suspend site to suse wiki? > > Or you will ask your "some webmaster" to add the new URL? > > Luca, could you add redirect from suspend.sf.net to s2ram wiki in > suse? Alon knows what is required... http://suspend.sf.net/s2ram-support.html I've also updated the link on the documentation page. Luca |
|
From: Alon Bar-L. <alo...@gm...> - 2007-07-31 19:39:15
|
On 7/31/07, Pavel Machek <pa...@uc...> wrote: > Luca, could you add redirect from suspend.sf.net to s2ram wiki in > suse? Alon knows what is required... > Pavel Great! Hello Luca, There should be a URL such as http://suspend.sourceforge.net/s2ram-info.shtml that redirects users to http://en.opensuse.org/S2ram. Something like: --- <html> <meta http-equiv="refresh" content="1; URL=http://en.opensuse.org/S2ram"> <head><title>Redirect</title></head> <body> <a href="http://en.opensuse.org/S2ram">Here</a> </body> </html> --- Thanks! Alon. |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 19:22:10
|
On Tue 2007-07-31 21:35:59, Alon Bar-Lev wrote: > On 7/31/07, Pavel Machek <pa...@uc...> wrote: > > Hmm, IIRC we _do_ have some webmaster, already. Ok, lets keep pages in > > suse wiki, then. > > Excuse me for not understanding such short messages... > Are you doping the idea of link only suspend site and redirect from > suspend site to suse wiki? > Or you will ask your "some webmaster" to add the new URL? Luca, could you add redirect from suspend.sf.net to s2ram wiki in suse? Alon knows what is required... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Rafael J. W. <rj...@si...> - 2007-07-31 19:09:21
|
On Tuesday, 31 July 2007 20:30, Pavel Machek wrote: > Hi! > > > > Right... so do you have sourceforge login? I guess we could use you as > > > a webmaster for suspend.sf.net project ;-). > > > > My sf login is alonbl. > > But I am far from being a web master... Or have the time to do this. > > But if you like I can put the suggested html on your site so that you > > can point to this URL from sources. > > Hmm, IIRC we _do_ have some webmaster, already. Ok, lets keep pages in > suse wiki, then. > > > Still waiting for lzo ACK/comments... This is the most important patch > > for my users. > > IIRC noone was strongly against, so replacing lzf with lzo is the way > to go...? Ultimately, I think it is. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth |
|
From: Alon Bar-L. <alo...@gm...> - 2007-07-31 18:36:02
|
On 7/31/07, Pavel Machek <pa...@uc...> wrote: > Hmm, IIRC we _do_ have some webmaster, already. Ok, lets keep pages in > suse wiki, then. Excuse me for not understanding such short messages... Are you doping the idea of link only suspend site and redirect from suspend site to suse wiki? Or you will ask your "some webmaster" to add the new URL? Alon. |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 18:30:50
|
Hi! > > Right... so do you have sourceforge login? I guess we could use you as > > a webmaster for suspend.sf.net project ;-). > > My sf login is alonbl. > But I am far from being a web master... Or have the time to do this. > But if you like I can put the suggested html on your site so that you > can point to this URL from sources. Hmm, IIRC we _do_ have some webmaster, already. Ok, lets keep pages in suse wiki, then. > Still waiting for lzo ACK/comments... This is the most important patch > for my users. IIRC noone was strongly against, so replacing lzf with lzo is the way to go...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Alon Bar-L. <alo...@gm...> - 2007-07-31 18:01:19
|
On 7/31/07, Pavel Machek <pa...@uc...> wrote: > Right... so do you have sourceforge login? I guess we could use you as > a webmaster for suspend.sf.net project ;-). > Pavel My sf login is alonbl. But I am far from being a web master... Or have the time to do this. But if you like I can put the suggested html on your site so that you can point to this URL from sources. Still waiting for lzo ACK/comments... This is the most important patch for my users. Alon. |
|
From: Stefan S. <se...@su...> - 2007-07-31 17:29:32
|
On Tue, Jul 31, 2007 at 01:02:43PM +0530, Arun Raghavan wrote: > Surprise of surprises, resume almost works in 2.6.23-rc1! I didn't get > any beeping (my laptop might not have a beeping thing), but the > machine does resume, except the LCD doesn't come back on. I'm > attaching a file (all-options) with all the flags I've tried. None of > these worked for me. I'm missing the "-p -m" combination. Also, if you are using a framebuffer ... no, you are not. Hm, in this case, "-p" should be mostly the same as "-p -m", so i also don't have an idea what could help you. > Trying 10+ different sets of options is really painful, so I've made a > little script to automate the process. It tries each of a set of > options from a given file in series. I'm attaching both of these (also > mirrored at http://nemesis.accosted.net/downloads/s2ram-test.tar.gz) > in the hope that someone finds them useful, despite the hackiness. > > I just make the default Grub option my 2.6.23-rc1 kernel with > "init=/root/s2ram-test/s2ram-test.sh", and then the only manual > intervention required is hitting a key to wake the machine up after > suspend. > > Feedback on the script is welcome. Also, the list of options used is > pretty much arbitrary. Can someone in the know please review them, > add/remove relevant options and reorder them by priority? I've updated > my BIOS now (F.15 to F.23), and if someone can tell me the right set > of options and the right order, I'll give the whole thing another go. Well, there is a list of option combinations on http://en.opensuse.org/S2ram which also indicate the ordering i usually prefer :-) Maybe your X driver also knows how to reactivate the display, so trying it from X might be worth a try. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-31 17:29:32
|
On Mon, Jul 30, 2007 at 06:36:53PM -0400, a v wrote: > using -a 3 reinitializes the screen/(video adapter) badly, showing white > and then slowly and unevenly fading to black: probably the melting screen you > mentioned Exactly. > It does respond to stuff in that state (no crash), like sysRq commands, or > rebooting with ctrl-alt del (after switching to a vt) > > so I guess there is a pattern :) Yes, thanks for confirming :-) -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 16:45:18
|
Hi! > > > > Hmm, yes, I guess I want to now. So you have thinkpad that is broken > > > > with -a1 -m, in 64-bit mode only? And no other differences? (Like, > > > > same kernel framebuffer driver, both time from console?) > > > > > > I have a thinkpad on my desk (T61 with intel graphics) that is broken with > > > "-a 3" in 64bit mode only (works in 32bit mode). It does, however, work > > > with "-a 1 -m" in both modes. Everything else is pretty much the same. > > > Oh - and "-p -m" does not work in both modes. > > > > Could you try removing "call verify_cpu" from x86-64 wakeup.S? That's > > only significant difference I can see... > > > > ...hmm, and we may need a bigger stack space on x86-64... > > I just verified it, and found out, that only on an old kernel (2.6.16.46) > "-a 1 -m" was necessary on 64bit, newer kernels (2.6.22 and 2.6.23-rc1) > worked fine with "-a 3". > > So recent kernels might have this already fixed. I do not know what fixed it, but 2.6.16 is old, so I guess that's okay. Can anyone see the i386-vs-x86-64 difference in quirks with 2.6.22+? Hmm, question is what to do with the whitelist :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Stefan S. <se...@su...> - 2007-07-31 16:39:17
|
On Tue, Jul 31, 2007 at 01:55:28PM +0200, Pavel Machek wrote: > Hi! > > > > Hmm, yes, I guess I want to now. So you have thinkpad that is broken > > > with -a1 -m, in 64-bit mode only? And no other differences? (Like, > > > same kernel framebuffer driver, both time from console?) > > > > I have a thinkpad on my desk (T61 with intel graphics) that is broken with > > "-a 3" in 64bit mode only (works in 32bit mode). It does, however, work > > with "-a 1 -m" in both modes. Everything else is pretty much the same. > > Oh - and "-p -m" does not work in both modes. > > Could you try removing "call verify_cpu" from x86-64 wakeup.S? That's > only significant difference I can see... > > ...hmm, and we may need a bigger stack space on x86-64... I just verified it, and found out, that only on an old kernel (2.6.16.46) "-a 1 -m" was necessary on 64bit, newer kernels (2.6.22 and 2.6.23-rc1) worked fine with "-a 3". So recent kernels might have this already fixed. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Stefan S. <se...@su...> - 2007-07-31 15:00:05
|
Hi,
next time, i will test on an affected machine :-)
This is already checked in:
Index: s2ram-x86.c
===================================================================
RCS file: /cvsroot/suspend/suspend/s2ram-x86.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -p -U5 -r1.6 -r1.7
--- s2ram-x86.c 19 Jul 2007 13:28:47 -0000 1.6
+++ s2ram-x86.c 31 Jul 2007 12:32:41 -0000 1.7
@@ -69,20 +69,23 @@ void identify_machine(void)
}
static int set_acpi_video_mode(int mode)
{
unsigned long acpi_video_flags;
- FILE *f = fopen("/proc/sys/kernel/acpi_video_flags", "rw");
+ FILE *f = fopen("/proc/sys/kernel/acpi_video_flags", "r");
if (!f) {
printf("/proc/sys/kernel/acpi_video_flags does not exist; you need a kernel >=2.6.16.\n");
return S2RAM_FAIL;
}
/* read the old setting from /proc */
if (fscanf(f, "%ld", &acpi_video_flags) != 1) {
printf("/proc/sys/kernel/acpi_video_flags format is invalid\n");
return S2RAM_FAIL;
}
+ /* rewind() seems not to work on /proc files, so close and reopen it */
+ fclose(f);
+ f = fopen("/proc/sys/kernel/acpi_video_flags", "w");
/* mask out bits 0 and 1 */
acpi_video_flags = acpi_video_flags & (~0UL - S3_BIOS - S3_MODE);
fprintf(f, "%ld", acpi_video_flags | mode);
fflush(f);
fclose(f);
This caused the acpi_video_flags to not get written at all, so if you get
reports about no longer working suspend, make sure these users use the
latest code.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
|
|
From: Pavel M. <pa...@uc...> - 2007-07-31 14:58:14
|
Hi! > > > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S > > > index 1415da1..9cebef7 100644 > > > --- a/arch/i386/kernel/acpi/wakeup.S > > > +++ b/arch/i386/kernel/acpi/wakeup.S > > > @@ -28,21 +28,6 @@ #define BEEP \ > > > movb $15, %al; \ > > > outb %al, $66; > > > > > > -#define BEEP \ > > > - inb $97, %al; \ > > > - outb %al, $0x80; \ > > > - movb $3, %al; \ > > > - outb %al, $97; \ > > > - outb %al, $0x80; \ > > > - movb $-74, %al; \ > > > - outb %al, $67; \ > > > - outb %al, $0x80; \ > > > - movb $-119, %al; \ > > > - outb %al, $66; \ > > > - outb %al, $0x80; \ > > > - movb $15, %al; \ > > > - outb %al, $66; > > > - > > > ALIGN > > > .align 4096 > > > ENTRY(wakeup_start) > > > > This hunk rejected for me (against 2.6.23-rc1), but i'm testing x86_64, so > > it did not matter ;-) > > I think it's gone in favor of the more sophisticated beeping > > > support. No. It was merge problem on my side, I actually had _two_ times the beeping macro. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Rafael J. W. <rj...@si...> - 2007-07-31 14:55:11
|
On Tuesday, 31 July 2007 16:43, Stefan Seyfried wrote: > On Tue, Jul 31, 2007 at 04:01:40PM +0200, Pavel Machek wrote: > > Hi! > > > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > > > - movb $0xa1, %al ; outb %al, $0x80 > > > > > > > > > > Well, what was this for? > > > > > > > > Debugging leds on port 80. I still have that card somewhere > > > > :-). Interesting parties can reinsert it. > > > > > > Ah, I see. > > > > > > Hmm, can you please write about that in the chanelog more explicitly? > > > Or just comment it out with a "uncomment this to get ..." text? > > > > I still need someone with x86-64 to test it for me before I submit it > > properly ;-). Updated patch follows. > > Compiling right now. > > > Pavel > > > > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S > > index 1415da1..9cebef7 100644 > > --- a/arch/i386/kernel/acpi/wakeup.S > > +++ b/arch/i386/kernel/acpi/wakeup.S > > @@ -28,21 +28,6 @@ #define BEEP \ > > movb $15, %al; \ > > outb %al, $66; > > > > -#define BEEP \ > > - inb $97, %al; \ > > - outb %al, $0x80; \ > > - movb $3, %al; \ > > - outb %al, $97; \ > > - outb %al, $0x80; \ > > - movb $-74, %al; \ > > - outb %al, $67; \ > > - outb %al, $0x80; \ > > - movb $-119, %al; \ > > - outb %al, $66; \ > > - outb %al, $0x80; \ > > - movb $15, %al; \ > > - outb %al, $66; > > - > > ALIGN > > .align 4096 > > ENTRY(wakeup_start) > > This hunk rejected for me (against 2.6.23-rc1), but i'm testing x86_64, so > it did not matter ;-) I think it's gone in favor of the more sophisticated beeping support. |
|
From: Stefan S. <se...@su...> - 2007-07-31 14:43:45
|
On Tue, Jul 31, 2007 at 04:01:40PM +0200, Pavel Machek wrote: > Hi! > > > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > > > - movb $0xa1, %al ; outb %al, $0x80 > > > > > > > > Well, what was this for? > > > > > > Debugging leds on port 80. I still have that card somewhere > > > :-). Interesting parties can reinsert it. > > > > Ah, I see. > > > > Hmm, can you please write about that in the chanelog more explicitly? > > Or just comment it out with a "uncomment this to get ..." text? > > I still need someone with x86-64 to test it for me before I submit it > properly ;-). Updated patch follows. Compiling right now. > Pavel > > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S > index 1415da1..9cebef7 100644 > --- a/arch/i386/kernel/acpi/wakeup.S > +++ b/arch/i386/kernel/acpi/wakeup.S > @@ -28,21 +28,6 @@ #define BEEP \ > movb $15, %al; \ > outb %al, $66; > > -#define BEEP \ > - inb $97, %al; \ > - outb %al, $0x80; \ > - movb $3, %al; \ > - outb %al, $97; \ > - outb %al, $0x80; \ > - movb $-74, %al; \ > - outb %al, $67; \ > - outb %al, $0x80; \ > - movb $-119, %al; \ > - outb %al, $66; \ > - outb %al, $0x80; \ > - movb $15, %al; \ > - outb %al, $66; > - > ALIGN > .align 4096 > ENTRY(wakeup_start) This hunk rejected for me (against 2.6.23-rc1), but i'm testing x86_64, so it did not matter ;-) -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 14:01:47
|
Hi! > > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > > > - movb $0xa1, %al ; outb %al, $0x80 > > > > > > Well, what was this for? > > > > Debugging leds on port 80. I still have that card somewhere > > :-). Interesting parties can reinsert it. > > Ah, I see. > > Hmm, can you please write about that in the chanelog more explicitly? > Or just comment it out with a "uncomment this to get ..." text? I still need someone with x86-64 to test it for me before I submit it properly ;-). Updated patch follows. Pavel diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S index 1415da1..9cebef7 100644 --- a/arch/i386/kernel/acpi/wakeup.S +++ b/arch/i386/kernel/acpi/wakeup.S @@ -28,21 +28,6 @@ #define BEEP \ movb $15, %al; \ outb %al, $66; -#define BEEP \ - inb $97, %al; \ - outb %al, $0x80; \ - movb $3, %al; \ - outb %al, $97; \ - outb %al, $0x80; \ - movb $-74, %al; \ - outb %al, $67; \ - outb %al, $0x80; \ - movb $-119, %al; \ - outb %al, $66; \ - outb %al, $0x80; \ - movb $15, %al; \ - outb %al, $66; - ALIGN .align 4096 ENTRY(wakeup_start) @@ -53,9 +38,6 @@ wakeup_code: # Uncomment this to make your computer start producing ugly noise as soon # as BIOS returns to this real-mode entry point. # BEEP - movw $0xb800, %ax - movw %ax,%fs - movw $0x0e00 + 'L', %fs:(0x10) cli cld @@ -70,7 +52,6 @@ # BEEP BEEP 1: mov $(wakeup_stack - wakeup_code), %sp # Private stack is needed for ASUS board - movw $0x0e00 + 'S', %fs:(0x12) pushl $0 # Kill any dangerous flags popfl @@ -108,9 +89,6 @@ # BEEP # make sure %cr4 is set correctly (features, etc) movl real_save_cr4 - wakeup_code, %eax movl %eax, %cr4 - movw $0xb800, %ax - movw %ax,%fs - movw $0x0e00 + 'i', %fs:(0x12) # need a gdt -- use lgdtl to force 32-bit operands, in case # the GDT is located past 16 megabytes. @@ -120,8 +98,6 @@ # BEEP movl %eax, %cr0 jmp 1f 1: - movw $0x0e00 + 'n', %fs:(0x14) - movl real_magic - wakeup_code, %eax cmpl $0x12345678, %eax jne bogus_real_magic @@ -145,7 +121,6 @@ real_save_efer_edx: .long 0 real_save_efer_eax: .long 0 bogus_real_magic: - movw $0x0e00 + 'B', %fs:(0x12) jmp bogus_real_magic /* This code uses an extended set of video mode numbers. These include: @@ -170,29 +145,9 @@ #define VIDEO_FIRST_V7 0x0900 # Setting of user mode (AX=mode ID) => CF=success mode_set: movw %ax, %bx -#if 0 - cmpb $0xff, %ah - jz setalias - - testb $VIDEO_RECALC>>8, %ah - jnz _setrec - - cmpb $VIDEO_FIRST_RESOLUTION>>8, %ah - jnc setres - - cmpb $VIDEO_FIRST_SPECIAL>>8, %ah - jz setspc - - cmpb $VIDEO_FIRST_V7>>8, %ah - jz setv7 -#endif cmpb $VIDEO_FIRST_VESA>>8, %ah jnc check_vesa -#if 0 - orb %ah, %ah - jz setmenu -#endif decb %ah # jz setbios Add bios modes later @@ -232,7 +187,6 @@ wakeup_pmode_return: movw %ax, %es movw %ax, %fs movw %ax, %gs - movw $0x0e00 + 'u', 0xb8016 # reload the gdt, as we need the full 32 bit address lgdt saved_gdt @@ -256,7 +210,6 @@ wakeup_pmode_return: jmp *%eax bogus_magic: - movw $0x0e00 + 'B', 0xb8018 jmp bogus_magic diff --git a/arch/x86_64/kernel/acpi/wakeup.S b/arch/x86_64/kernel/acpi/wakeup.S index 13f1480..fd09434 100644 --- a/arch/x86_64/kernel/acpi/wakeup.S +++ b/arch/x86_64/kernel/acpi/wakeup.S @@ -41,7 +41,6 @@ wakeup_code: # Running in *copy* of this code, somewhere in low 1MB. - movb $0xa1, %al ; outb %al, $0x80 cli cld # setup data segment @@ -65,11 +64,6 @@ # Running in *copy* of this code, somewh cmpl $0x12345678, %eax jne bogus_real_magic - call verify_cpu # Verify the cpu supports long - # mode - testl %eax, %eax - jnz no_longmode - testl $1, realmode_flags - wakeup_code jz 1f lcall $0xc000,$3 @@ -84,12 +78,6 @@ # Running in *copy* of this code, somewh call mode_seta 1: - movw $0xb800, %ax - movw %ax,%fs - movw $0x0e00 + 'L', %fs:(0x10) - - movb $0xa2, %al ; outb %al, $0x80 - mov %ds, %ax # Find 32bit wakeup_code addr movzx %ax, %esi # (Convert %ds:gdt to a liner ptr) shll $4, %esi @@ -117,14 +105,10 @@ wakeup_32_vector: .code32 wakeup_32: # Running in this code, but at low address; paging is not yet turned on. - movb $0xa5, %al ; outb %al, $0x80 movl $__KERNEL_DS, %eax movl %eax, %ds - movw $0x0e00 + 'i', %ds:(0xb8012) - movb $0xa8, %al ; outb %al, $0x80; - /* * Prepare for entering 64bits mode */ @@ -200,16 +184,11 @@ wakeup_long64: */ lgdt cpu_gdt_descr - movw $0x0e00 + 'n', %ds:(0xb8014) - movb $0xa9, %al ; outb %al, $0x80 - movq saved_magic, %rax movq $0x123456789abcdef0, %rdx cmpq %rdx, %rax jne bogus_64_magic - movw $0x0e00 + 'u', %ds:(0xb8016) - nop nop movw $__KERNEL_DS, %ax @@ -220,13 +199,11 @@ wakeup_long64: movw %ax, %gs movq saved_rsp, %rsp - movw $0x0e00 + 'x', %ds:(0xb8018) movq saved_rbx, %rbx movq saved_rdi, %rdi movq saved_rsi, %rsi movq saved_rbp, %rbp - movw $0x0e00 + '!', %ds:(0xb801a) movq saved_rip, %rax jmp *%rax @@ -256,20 +233,12 @@ realmode_flags: .quad 0 .code16 bogus_real_magic: - movb $0xba,%al ; outb %al,$0x80 jmp bogus_real_magic .code64 bogus_64_magic: - movb $0xb3,%al ; outb %al,$0x80 jmp bogus_64_magic -.code16 -no_longmode: - movb $0xbc,%al ; outb %al,$0x80 - jmp no_longmode - -#include "../verify_cpu.S" /* This code uses an extended set of video mode numbers. These include: * Aliases for standard modes @@ -294,29 +263,9 @@ # Setting of user mode (AX=mode ID) => C .code16 mode_seta: movw %ax, %bx -#if 0 - cmpb $0xff, %ah - jz setalias - - testb $VIDEO_RECALC>>8, %ah - jnz _setrec - - cmpb $VIDEO_FIRST_RESOLUTION>>8, %ah - jnc setres - - cmpb $VIDEO_FIRST_SPECIAL>>8, %ah - jz setspc - - cmpb $VIDEO_FIRST_V7>>8, %ah - jz setv7 -#endif cmpb $VIDEO_FIRST_VESA>>8, %ah jnc check_vesaa -#if 0 - orb %ah, %ah - jz setmenu -#endif decb %ah # jz setbios Add bios modes later -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Rafael J. W. <rj...@si...> - 2007-07-31 13:40:55
|
Hi, On Tuesday, 31 July 2007 15:18, Pavel Machek wrote: > Hi! > > > > This removes some stale debugging infrastructure from s2ram > > > paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't > > > change during s2ram, and removed #if 0-ed code. Some testing would be > > > useful, perpahs it will even fix someone's machine :-). (VGA accesses > > > could theoretically hurt if vga is not present / if it is in some > > > strange state). > > > > > > Signed-off-by: Pavel Machek <pa...@su...> > > > > > > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S > > > index 1415da1..9719bd6 100644 > > > --- a/arch/i386/kernel/acpi/wakeup.S > > > +++ b/arch/i386/kernel/acpi/wakeup.S > > > @@ -53,9 +38,6 @@ wakeup_code: > > > # Uncomment this to make your computer start producing ugly noise as soon > > > # as BIOS returns to this real-mode entry point. > > > # BEEP > > > - movw $0xb800, %ax > > > - movw %ax,%fs > > > - movw $0x0e00 + 'L', %fs:(0x10) > > > > Hmm, was this a part of that yellow "Linux" string? > > Yes. But I'm afraid that may cause problems if vga is not ready. I agree. > > > # Running in *copy* of this code, somewhere in low 1MB. > > > > > > - movb $0xa1, %al ; outb %al, $0x80 > > > > Well, what was this for? > > Debugging leds on port 80. I still have that card somewhere > :-). Interesting parties can reinsert it. Ah, I see. Hmm, can you please write about that in the chanelog more explicitly? Or just comment it out with a "uncomment this to get ..." text? > > > @@ -88,8 +82,6 @@ # Running in *copy* of this code, somewh > > > movw %ax,%fs > > > movw $0x0e00 + 'L', %fs:(0x10) > > > > Why aren't you removing this line? > > Mistake, killed. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 13:18:08
|
Hi! > > This removes some stale debugging infrastructure from s2ram > > paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't > > change during s2ram, and removed #if 0-ed code. Some testing would be > > useful, perpahs it will even fix someone's machine :-). (VGA accesses > > could theoretically hurt if vga is not present / if it is in some > > strange state). > > > > Signed-off-by: Pavel Machek <pa...@su...> > > > > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S > > index 1415da1..9719bd6 100644 > > --- a/arch/i386/kernel/acpi/wakeup.S > > +++ b/arch/i386/kernel/acpi/wakeup.S > > @@ -53,9 +38,6 @@ wakeup_code: > > # Uncomment this to make your computer start producing ugly noise as soon > > # as BIOS returns to this real-mode entry point. > > # BEEP > > - movw $0xb800, %ax > > - movw %ax,%fs > > - movw $0x0e00 + 'L', %fs:(0x10) > > Hmm, was this a part of that yellow "Linux" string? Yes. But I'm afraid that may cause problems if vga is not ready. > > # Running in *copy* of this code, somewhere in low 1MB. > > > > - movb $0xa1, %al ; outb %al, $0x80 > > Well, what was this for? Debugging leds on port 80. I still have that card somewhere :-). Interesting parties can reinsert it. > > @@ -88,8 +82,6 @@ # Running in *copy* of this code, somewh > > movw %ax,%fs > > movw $0x0e00 + 'L', %fs:(0x10) > > Why aren't you removing this line? Mistake, killed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Rafael J. W. <rj...@si...> - 2007-07-31 13:12:15
|
Hi, On Tuesday, 31 July 2007 14:12, Pavel Machek wrote: > Hi! > > This removes some stale debugging infrastructure from s2ram > paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't > change during s2ram, and removed #if 0-ed code. Some testing would be > useful, perpahs it will even fix someone's machine :-). (VGA accesses > could theoretically hurt if vga is not present / if it is in some > strange state). > > Signed-off-by: Pavel Machek <pa...@su...> > > diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S > index 1415da1..9719bd6 100644 > --- a/arch/i386/kernel/acpi/wakeup.S > +++ b/arch/i386/kernel/acpi/wakeup.S > @@ -53,9 +38,6 @@ wakeup_code: > # Uncomment this to make your computer start producing ugly noise as soon > # as BIOS returns to this real-mode entry point. > # BEEP > - movw $0xb800, %ax > - movw %ax,%fs > - movw $0x0e00 + 'L', %fs:(0x10) Hmm, was this a part of that yellow "Linux" string? > cli > cld > @@ -70,7 +52,6 @@ # BEEP > BEEP > 1: > mov $(wakeup_stack - wakeup_code), %sp # Private stack is needed for ASUS board > - movw $0x0e00 + 'S', %fs:(0x12) > > pushl $0 # Kill any dangerous flags > popfl > @@ -108,9 +89,6 @@ # BEEP > # make sure %cr4 is set correctly (features, etc) > movl real_save_cr4 - wakeup_code, %eax > movl %eax, %cr4 > - movw $0xb800, %ax > - movw %ax,%fs > - movw $0x0e00 + 'i', %fs:(0x12) And this? > # need a gdt -- use lgdtl to force 32-bit operands, in case > # the GDT is located past 16 megabytes. > @@ -120,8 +98,6 @@ # BEEP > movl %eax, %cr0 > jmp 1f > 1: > - movw $0x0e00 + 'n', %fs:(0x14) > - And this? > movl real_magic - wakeup_code, %eax > cmpl $0x12345678, %eax > jne bogus_real_magic > @@ -145,7 +121,6 @@ real_save_efer_edx: .long 0 > real_save_efer_eax: .long 0 > > bogus_real_magic: > - movw $0x0e00 + 'B', %fs:(0x12) > > jmp bogus_real_magic > > /* This code uses an extended set of video mode numbers. These include: > @@ -170,29 +145,9 @@ #define VIDEO_FIRST_V7 0x0900 > # Setting of user mode (AX=mode ID) => CF=success > mode_set: > movw %ax, %bx > -#if 0 > - cmpb $0xff, %ah > - jz setalias > - > - testb $VIDEO_RECALC>>8, %ah > - jnz _setrec > - > - cmpb $VIDEO_FIRST_RESOLUTION>>8, %ah > - jnc setres > - > - cmpb $VIDEO_FIRST_SPECIAL>>8, %ah > - jz setspc > - > - cmpb $VIDEO_FIRST_V7>>8, %ah > - jz setv7 > -#endif > > cmpb $VIDEO_FIRST_VESA>>8, %ah > jnc check_vesa > -#if 0 > - orb %ah, %ah > - jz setmenu > -#endif > > decb %ah > # jz setbios Add bios modes later > @@ -232,7 +187,6 @@ wakeup_pmode_return: > movw %ax, %es > movw %ax, %fs > movw %ax, %gs > - movw $0x0e00 + 'u', 0xb8016 > > # reload the gdt, as we need the full 32 bit address > lgdt saved_gdt > diff --git a/arch/x86_64/kernel/acpi/wakeup.S b/arch/x86_64/kernel/acpi/wakeup.S > index 13f1480..bc9af5d 100644 > --- a/arch/x86_64/kernel/acpi/wakeup.S > +++ b/arch/x86_64/kernel/acpi/wakeup.S > @@ -41,7 +41,6 @@ wakeup_code: > > # Running in *copy* of this code, somewhere in low 1MB. > > - movb $0xa1, %al ; outb %al, $0x80 Well, what was this for? > cli > cld > # setup data segment > @@ -65,11 +64,6 @@ # Running in *copy* of this code, somewh > cmpl $0x12345678, %eax > jne bogus_real_magic > > - call verify_cpu # Verify the cpu supports long > - # mode > - testl %eax, %eax > - jnz no_longmode > - Yup, good idea. > testl $1, realmode_flags - wakeup_code > jz 1f > lcall $0xc000,$3 > @@ -88,8 +82,6 @@ # Running in *copy* of this code, somewh > movw %ax,%fs > movw $0x0e00 + 'L', %fs:(0x10) Why aren't you removing this line? > - movb $0xa2, %al ; outb %al, $0x80 > - > mov %ds, %ax # Find 32bit wakeup_code addr > movzx %ax, %esi # (Convert %ds:gdt to a liner ptr) > shll $4, %esi > @@ -117,14 +109,10 @@ wakeup_32_vector: > .code32 > wakeup_32: > # Running in this code, but at low address; paging is not yet turned on. > - movb $0xa5, %al ; outb %al, $0x80 > > movl $__KERNEL_DS, %eax > movl %eax, %ds > > - movw $0x0e00 + 'i', %ds:(0xb8012) > - movb $0xa8, %al ; outb %al, $0x80; > - > /* > * Prepare for entering 64bits mode > */ > @@ -200,16 +188,11 @@ wakeup_long64: > */ > lgdt cpu_gdt_descr > > - movw $0x0e00 + 'n', %ds:(0xb8014) > - movb $0xa9, %al ; outb %al, $0x80 > - > movq saved_magic, %rax > movq $0x123456789abcdef0, %rdx > cmpq %rdx, %rax > jne bogus_64_magic > > - movw $0x0e00 + 'u', %ds:(0xb8016) > - > nop > nop > movw $__KERNEL_DS, %ax > @@ -256,20 +239,12 @@ realmode_flags: .quad 0 > > .code16 > bogus_real_magic: > - movb $0xba,%al ; outb %al,$0x80 > jmp bogus_real_magic > > .code64 > bogus_64_magic: > - movb $0xb3,%al ; outb %al,$0x80 > jmp bogus_64_magic > > -.code16 > -no_longmode: > - movb $0xbc,%al ; outb %al,$0x80 > - jmp no_longmode > - > -#include "../verify_cpu.S" > > /* This code uses an extended set of video mode numbers. These include: > * Aliases for standard modes > @@ -294,29 +269,9 @@ # Setting of user mode (AX=mode ID) => C > .code16 > mode_seta: > movw %ax, %bx > -#if 0 > - cmpb $0xff, %ah > - jz setalias > - > - testb $VIDEO_RECALC>>8, %ah > - jnz _setrec > - > - cmpb $VIDEO_FIRST_RESOLUTION>>8, %ah > - jnc setres > - > - cmpb $VIDEO_FIRST_SPECIAL>>8, %ah > - jz setspc > - > - cmpb $VIDEO_FIRST_V7>>8, %ah > - jz setv7 > -#endif > > cmpb $VIDEO_FIRST_VESA>>8, %ah > jnc check_vesaa > -#if 0 > - orb %ah, %ah > - jz setmenu > -#endif > > decb %ah > # jz setbios Add bios modes later > Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 12:12:53
|
Hi! This removes some stale debugging infrastructure from s2ram paths. Also, there's no need to verify_cpu on x86-64 -- cpu can't change during s2ram, and removed #if 0-ed code. Some testing would be useful, perpahs it will even fix someone's machine :-). (VGA accesses could theoretically hurt if vga is not present / if it is in some strange state). Signed-off-by: Pavel Machek <pa...@su...> diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S index 1415da1..9719bd6 100644 --- a/arch/i386/kernel/acpi/wakeup.S +++ b/arch/i386/kernel/acpi/wakeup.S @@ -53,9 +38,6 @@ wakeup_code: # Uncomment this to make your computer start producing ugly noise as soon # as BIOS returns to this real-mode entry point. # BEEP - movw $0xb800, %ax - movw %ax,%fs - movw $0x0e00 + 'L', %fs:(0x10) cli cld @@ -70,7 +52,6 @@ # BEEP BEEP 1: mov $(wakeup_stack - wakeup_code), %sp # Private stack is needed for ASUS board - movw $0x0e00 + 'S', %fs:(0x12) pushl $0 # Kill any dangerous flags popfl @@ -108,9 +89,6 @@ # BEEP # make sure %cr4 is set correctly (features, etc) movl real_save_cr4 - wakeup_code, %eax movl %eax, %cr4 - movw $0xb800, %ax - movw %ax,%fs - movw $0x0e00 + 'i', %fs:(0x12) # need a gdt -- use lgdtl to force 32-bit operands, in case # the GDT is located past 16 megabytes. @@ -120,8 +98,6 @@ # BEEP movl %eax, %cr0 jmp 1f 1: - movw $0x0e00 + 'n', %fs:(0x14) - movl real_magic - wakeup_code, %eax cmpl $0x12345678, %eax jne bogus_real_magic @@ -145,7 +121,6 @@ real_save_efer_edx: .long 0 real_save_efer_eax: .long 0 bogus_real_magic: - movw $0x0e00 + 'B', %fs:(0x12) jmp bogus_real_magic /* This code uses an extended set of video mode numbers. These include: @@ -170,29 +145,9 @@ #define VIDEO_FIRST_V7 0x0900 # Setting of user mode (AX=mode ID) => CF=success mode_set: movw %ax, %bx -#if 0 - cmpb $0xff, %ah - jz setalias - - testb $VIDEO_RECALC>>8, %ah - jnz _setrec - - cmpb $VIDEO_FIRST_RESOLUTION>>8, %ah - jnc setres - - cmpb $VIDEO_FIRST_SPECIAL>>8, %ah - jz setspc - - cmpb $VIDEO_FIRST_V7>>8, %ah - jz setv7 -#endif cmpb $VIDEO_FIRST_VESA>>8, %ah jnc check_vesa -#if 0 - orb %ah, %ah - jz setmenu -#endif decb %ah # jz setbios Add bios modes later @@ -232,7 +187,6 @@ wakeup_pmode_return: movw %ax, %es movw %ax, %fs movw %ax, %gs - movw $0x0e00 + 'u', 0xb8016 # reload the gdt, as we need the full 32 bit address lgdt saved_gdt diff --git a/arch/x86_64/kernel/acpi/wakeup.S b/arch/x86_64/kernel/acpi/wakeup.S index 13f1480..bc9af5d 100644 --- a/arch/x86_64/kernel/acpi/wakeup.S +++ b/arch/x86_64/kernel/acpi/wakeup.S @@ -41,7 +41,6 @@ wakeup_code: # Running in *copy* of this code, somewhere in low 1MB. - movb $0xa1, %al ; outb %al, $0x80 cli cld # setup data segment @@ -65,11 +64,6 @@ # Running in *copy* of this code, somewh cmpl $0x12345678, %eax jne bogus_real_magic - call verify_cpu # Verify the cpu supports long - # mode - testl %eax, %eax - jnz no_longmode - testl $1, realmode_flags - wakeup_code jz 1f lcall $0xc000,$3 @@ -88,8 +82,6 @@ # Running in *copy* of this code, somewh movw %ax,%fs movw $0x0e00 + 'L', %fs:(0x10) - movb $0xa2, %al ; outb %al, $0x80 - mov %ds, %ax # Find 32bit wakeup_code addr movzx %ax, %esi # (Convert %ds:gdt to a liner ptr) shll $4, %esi @@ -117,14 +109,10 @@ wakeup_32_vector: .code32 wakeup_32: # Running in this code, but at low address; paging is not yet turned on. - movb $0xa5, %al ; outb %al, $0x80 movl $__KERNEL_DS, %eax movl %eax, %ds - movw $0x0e00 + 'i', %ds:(0xb8012) - movb $0xa8, %al ; outb %al, $0x80; - /* * Prepare for entering 64bits mode */ @@ -200,16 +188,11 @@ wakeup_long64: */ lgdt cpu_gdt_descr - movw $0x0e00 + 'n', %ds:(0xb8014) - movb $0xa9, %al ; outb %al, $0x80 - movq saved_magic, %rax movq $0x123456789abcdef0, %rdx cmpq %rdx, %rax jne bogus_64_magic - movw $0x0e00 + 'u', %ds:(0xb8016) - nop nop movw $__KERNEL_DS, %ax @@ -256,20 +239,12 @@ realmode_flags: .quad 0 .code16 bogus_real_magic: - movb $0xba,%al ; outb %al,$0x80 jmp bogus_real_magic .code64 bogus_64_magic: - movb $0xb3,%al ; outb %al,$0x80 jmp bogus_64_magic -.code16 -no_longmode: - movb $0xbc,%al ; outb %al,$0x80 - jmp no_longmode - -#include "../verify_cpu.S" /* This code uses an extended set of video mode numbers. These include: * Aliases for standard modes @@ -294,29 +269,9 @@ # Setting of user mode (AX=mode ID) => C .code16 mode_seta: movw %ax, %bx -#if 0 - cmpb $0xff, %ah - jz setalias - - testb $VIDEO_RECALC>>8, %ah - jnz _setrec - - cmpb $VIDEO_FIRST_RESOLUTION>>8, %ah - jnc setres - - cmpb $VIDEO_FIRST_SPECIAL>>8, %ah - jz setspc - - cmpb $VIDEO_FIRST_V7>>8, %ah - jz setv7 -#endif cmpb $VIDEO_FIRST_VESA>>8, %ah jnc check_vesaa -#if 0 - orb %ah, %ah - jz setmenu -#endif decb %ah # jz setbios Add bios modes later -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 11:55:25
|
Hi! > > Hmm, yes, I guess I want to now. So you have thinkpad that is broken > > with -a1 -m, in 64-bit mode only? And no other differences? (Like, > > same kernel framebuffer driver, both time from console?) > > I have a thinkpad on my desk (T61 with intel graphics) that is broken with > "-a 3" in 64bit mode only (works in 32bit mode). It does, however, work > with "-a 1 -m" in both modes. Everything else is pretty much the same. > Oh - and "-p -m" does not work in both modes. Could you try removing "call verify_cpu" from x86-64 wakeup.S? That's only significant difference I can see... ...hmm, and we may need a bigger stack space on x86-64... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Pavel M. <pa...@uc...> - 2007-07-31 11:48:26
|
On Mon 2007-07-30 07:49:07, Stefan Seyfried wrote: > On Fri, Jul 27, 2007 at 07:38:52PM +0200, Pavel Machek wrote: > > > If the needed quirks differ between otherwise identical i386 and > > x86-64 installation, I'd like to know. That means there's serious > > problem somewhere. > > Well, the '-a' quirks not working on x86_64 - that does not surprise > me at all. IIUC, it is somehow surprising that they work on i386 at > all, because of 16bit BIOS code <--> 32bit mode kernel, isn't it? No, we do BIOS calls while still in 16bit mode. It is 16bit entry call bios enter 32-bit or 64-bit mode. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html |
|
From: Stefan S. <se...@su...> - 2007-07-31 09:22:56
|
On Tue, Jul 31, 2007 at 11:28:54AM +0300, Alexander Toncovidov wrote: > 1) It works only under X. On the console I have a blank screen, but I > can still use commands like find or reboot. > 2) Under X, I just run it with the -f option and all goes smooth and shine Then please visit the URL shown by s2ram -i and follow the instructions on how to get it working on the console, too. Thanks :-) Stefan > >> # s2ram -i > >> This machine can be identified by: > >> sys_vendor = "SAMSUNG ELECTRONICS CO., LTD." > >> sys_product = "R19/R20/R21" > >> sys_version = "09SH" > >> bios_version = "10SH" > >> See http://en.opensuse.org/S2ram for details. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) |
16192 messages has been excluded from this view by a project administrator.
