Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Fri 2008-02-08 22:56:08, Rafael J. Wysocki wrote: > On Friday, 8 of February 2008, Pavel Machek wrote: > > On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: > > > Pavel Machek wrote: > > >> > > >> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent > > >> to the list). No problem there, but table stored at nonzero > > >> offset. Short jump at the beggining of table would fix it (ugly). > > >> > > > > > > Ugly, but it's the standard way to deal. We have it in the bzImage > > > format, > > > too. > > > > I'd prefer to keep it as it is, there are no problems. > > > > This way, we can put debugging instructions at the first byte of > > wakeup code, which is somehow important. > > > > Plus, with right #defines, it should be clean enough. > > Well, I don't know how to evaluate #defines in *.ld files ... See a patch in your inbox :-). Sam told me how to do it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Friday, 8 of February 2008, Pavel Machek wrote: > On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: > > Pavel Machek wrote: > >> > >> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent > >> to the list). No problem there, but table stored at nonzero > >> offset. Short jump at the beggining of table would fix it (ugly). > >> > > > > Ugly, but it's the standard way to deal. We have it in the bzImage format, > > too. > > I'd prefer to keep it as it is, there are no problems. > > This way, we can put debugging instructions at the first byte of > wakeup code, which is somehow important. > > Plus, with right #defines, it should be clean enough. Well, I don't know how to evaluate #defines in *.ld files ... Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: > Pavel Machek wrote: >> >> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent >> to the list). No problem there, but table stored at nonzero >> offset. Short jump at the beggining of table would fix it (ugly). >> > > Ugly, but it's the standard way to deal. We have it in the bzImage format, > too. I'd prefer to keep it as it is, there are no problems. This way, we can put debugging instructions at the first byte of wakeup code, which is somehow important. Plus, with right #defines, it should be clean enough. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
Pavel Machek wrote: See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Ugly, but it's the standard way to deal. We have it in the bzImage format, too. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
Hi! > > > > segments:offsets rear its ugly head here. I need %ds to point to my > > > > data, and the way to do it is copy it from %cs; that needs start to be > > > > at 0. > > > > > > Hm, why exactly is that necessay? > > > > It is not _neccessary_. Try to come up with another method that gets > > relocations right. I could not :-(. > > > > (Actually, putting table at the offset 0 and short jump at beggining > > of the table would probably do the trick. But that still keeps code at > > offset 0 :-). > > Pavel, can you explain in greater detail exactly what you need? I do not think I need anything. I'm just explaining why data need to go at nonzero offset. Nothing to see here, move on ;-). > It sounds like you are running in real mode with code stored at some > (unknown?) location in memory. The BIOS calls this code with IP=0 and > CS=, which apparently doesn't fit your requirements. > So just what are your requirements? The only possibilities I can think > of are: > > Code stored at a particular location in memory; > > CS, IP, etc. initialized to some particular values. > > What am I missing? See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Fri, 8 Feb 2008, Pavel Machek wrote: > > > segments:offsets rear its ugly head here. I need %ds to point to my > > > data, and the way to do it is copy it from %cs; that needs start to be > > > at 0. > > > > Hm, why exactly is that necessay? > > It is not _neccessary_. Try to come up with another method that gets > relocations right. I could not :-(. > > (Actually, putting table at the offset 0 and short jump at beggining > of the table would probably do the trick. But that still keeps code at > offset 0 :-). Pavel, can you explain in greater detail exactly what you need? It sounds like you are running in real mode with code stored at some (unknown?) location in memory. The BIOS calls this code with IP=0 and CS=, which apparently doesn't fit your requirements. So just what are your requirements? The only possibilities I can think of are: Code stored at a particular location in memory; CS, IP, etc. initialized to some particular values. What am I missing? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Friday, 8 of February 2008, Pavel Machek wrote: On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: Pavel Machek wrote: See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Ugly, but it's the standard way to deal. We have it in the bzImage format, too. I'd prefer to keep it as it is, there are no problems. This way, we can put debugging instructions at the first byte of wakeup code, which is somehow important. Plus, with right #defines, it should be clean enough. Well, I don't know how to evaluate #defines in *.ld files ... Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Fri 2008-02-08 22:56:08, Rafael J. Wysocki wrote: On Friday, 8 of February 2008, Pavel Machek wrote: On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: Pavel Machek wrote: See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Ugly, but it's the standard way to deal. We have it in the bzImage format, too. I'd prefer to keep it as it is, there are no problems. This way, we can put debugging instructions at the first byte of wakeup code, which is somehow important. Plus, with right #defines, it should be clean enough. Well, I don't know how to evaluate #defines in *.ld files ... See a patch in your inbox :-). Sam told me how to do it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: Pavel Machek wrote: See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Ugly, but it's the standard way to deal. We have it in the bzImage format, too. I'd prefer to keep it as it is, there are no problems. This way, we can put debugging instructions at the first byte of wakeup code, which is somehow important. Plus, with right #defines, it should be clean enough. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
On Fri, 8 Feb 2008, Pavel Machek wrote: segments:offsets rear its ugly head here. I need %ds to point to my data, and the way to do it is copy it from %cs; that needs start to be at 0. Hm, why exactly is that necessay? It is not _neccessary_. Try to come up with another method that gets relocations right. I could not :-(. (Actually, putting table at the offset 0 and short jump at beggining of the table would probably do the trick. But that still keeps code at offset 0 :-). Pavel, can you explain in greater detail exactly what you need? It sounds like you are running in real mode with code stored at some (unknown?) location in memory. The BIOS calls this code with IP=0 and CS=something, which apparently doesn't fit your requirements. So just what are your requirements? The only possibilities I can think of are: Code stored at a particular location in memory; CS, IP, etc. initialized to some particular values. What am I missing? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines
Pavel Machek wrote: See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent to the list). No problem there, but table stored at nonzero offset. Short jump at the beggining of table would fix it (ugly). Ugly, but it's the standard way to deal. We have it in the bzImage format, too. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
