Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 10 Feb 2005, Bill Davidsen wrote: Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. Isn't that what it's there for? In any context other than save/restore I wouldn't think using the BIOS was a good approach. But this is a special case, and if there's a BIOS function which does the right thing, it would seem to be easier to assume that the BIOS works than that the driver can do every operation for a clean restart. Maybe with new cards it is different but a few years ago, most cards that I tested had problems with those functions. -- Matan Ziv-Av. [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
I added Kendall from Scitech to the CC list. He is the expert on getting VBIOS's to post. Maybe he can help. On Thu, 10 Feb 2005 20:29:47 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote: > > On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> > > wrote: > > > It also explicitly states that Windows 2000 and XP don't support this, > > > which leads me to suspect that vendors no longer expect POSTing to be > > > possible after initial system boot. > > > > No, it means that some of my ATI cards don't function as secondary > > adapters on 2K and XP. > > And nor will any other card that requires POSTing (assuming that it > isn't just ATI being less than honest about driver shortcomings). And > we've certainly seen in the past that removing support for functionality > in Windows tends to result in hardware no longer supporting that > functionality. > > I have real, shipping hardware here that fails if you simply try to > execute the video BIOS POST code. If you think this is due to a > shortcoming in existing BIOS emulations, I'm more than happy to dump the > video and system BIOS regions and send them to you. > > -- > Matthew Garrett | [EMAIL PROTECTED] > > -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, Feb 10, 2005 at 03:17:47PM -0500, Jon Smirl wrote: > On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > > It also explicitly states that Windows 2000 and XP don't support this, > > which leads me to suspect that vendors no longer expect POSTing to be > > possible after initial system boot. > > No, it means that some of my ATI cards don't function as secondary > adapters on 2K and XP. So you can suspend with one of these and the card gets resumed properly? If so I wonder why they don't allow POSTing of secondary cards. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote: > On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > > It also explicitly states that Windows 2000 and XP don't support this, > > which leads me to suspect that vendors no longer expect POSTing to be > > possible after initial system boot. > > No, it means that some of my ATI cards don't function as secondary > adapters on 2K and XP. And nor will any other card that requires POSTing (assuming that it isn't just ATI being less than honest about driver shortcomings). And we've certainly seen in the past that removing support for functionality in Windows tends to result in hardware no longer supporting that functionality. I have real, shipping hardware here that fails if you simply try to execute the video BIOS POST code. If you think this is due to a shortcoming in existing BIOS emulations, I'm more than happy to dump the video and system BIOS regions and send them to you. -- Matthew Garrett | [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > It also explicitly states that Windows 2000 and XP don't support this, > which leads me to suspect that vendors no longer expect POSTing to be > possible after initial system boot. No, it means that some of my ATI cards don't function as secondary adapters on 2K and XP. -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 2005-02-10 at 21:25 +0200, Ville SyrjÃlà wrote: > BTW it seems that old ATI cards use the BIOS to initialize secondary > adapters even under Windows. > See http://www.ati.com/support/infobase/3663.html. It also explicitly states that Windows 2000 and XP don't support this, which leads me to suspect that vendors no longer expect POSTing to be possible after initial system boot. -- Matthew Garrett | [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > >>Rumors say that notebooks no longer have video bios at C000h:0; rumors > >>say that video BIOS on notebooks is simply integrated into main system > >>BIOS. I personaly do not know if rumors are true, but PCs are ugly > >>machines > >> > > > > > >A small number of laptop systems are known to pull this trick. There are > >other problems too - the video bios boot may make other assumptions > >about access to PCI space, configuration, interrupts, timers etc. > > > >Some systems (intel notably) appear to expect you to use the bios > >save/restore video state not re-POST. > > Isn't that what it's there for? In any context other than save/restore I > wouldn't think using the BIOS was a good approach. But this is a special > case, and if there's a BIOS function which does the right thing, it > would seem to be easier to assume that the BIOS works than that the > driver can do every operation for a clean restart. > > The problem is that while POST leaves the video in a known state, it may > not the known state you want, nor is it a given that you can get from > there to where you were on suspend. PC hardware isn't always that > dependable. Eh? POST leaves video in 80x25 text mode, and we know how to handle that mode just fine... Historically that's what we ran our consoles at, so X can handle it etc. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
BTW it seems that old ATI cards use the BIOS to initialize secondary adapters even under Windows. See http://www.ati.com/support/infobase/3663.html. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Alan Cox wrote: On Sad, 2005-02-05 at 09:35, Pavel Machek wrote: Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines A small number of laptop systems are known to pull this trick. There are other problems too - the video bios boot may make other assumptions about access to PCI space, configuration, interrupts, timers etc. Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. Isn't that what it's there for? In any context other than save/restore I wouldn't think using the BIOS was a good approach. But this is a special case, and if there's a BIOS function which does the right thing, it would seem to be easier to assume that the BIOS works than that the driver can do every operation for a clean restart. The problem is that while POST leaves the video in a known state, it may not the known state you want, nor is it a given that you can get from there to where you were on suspend. PC hardware isn't always that dependable. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Alan Cox wrote: On Sad, 2005-02-05 at 09:35, Pavel Machek wrote: Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines A small number of laptop systems are known to pull this trick. There are other problems too - the video bios boot may make other assumptions about access to PCI space, configuration, interrupts, timers etc. Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. Isn't that what it's there for? In any context other than save/restore I wouldn't think using the BIOS was a good approach. But this is a special case, and if there's a BIOS function which does the right thing, it would seem to be easier to assume that the BIOS works than that the driver can do every operation for a clean restart. The problem is that while POST leaves the video in a known state, it may not the known state you want, nor is it a given that you can get from there to where you were on suspend. PC hardware isn't always that dependable. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
BTW it seems that old ATI cards use the BIOS to initialize secondary adapters even under Windows. See http://www.ati.com/support/infobase/3663.html. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines A small number of laptop systems are known to pull this trick. There are other problems too - the video bios boot may make other assumptions about access to PCI space, configuration, interrupts, timers etc. Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. Isn't that what it's there for? In any context other than save/restore I wouldn't think using the BIOS was a good approach. But this is a special case, and if there's a BIOS function which does the right thing, it would seem to be easier to assume that the BIOS works than that the driver can do every operation for a clean restart. The problem is that while POST leaves the video in a known state, it may not the known state you want, nor is it a given that you can get from there to where you were on suspend. PC hardware isn't always that dependable. Eh? POST leaves video in 80x25 text mode, and we know how to handle that mode just fine... Historically that's what we ran our consoles at, so X can handle it etc. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 2005-02-10 at 21:25 +0200, Ville Syrjl wrote: BTW it seems that old ATI cards use the BIOS to initialize secondary adapters even under Windows. See http://www.ati.com/support/infobase/3663.html. It also explicitly states that Windows 2000 and XP don't support this, which leads me to suspect that vendors no longer expect POSTing to be possible after initial system boot. -- Matthew Garrett | [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett [EMAIL PROTECTED] wrote: It also explicitly states that Windows 2000 and XP don't support this, which leads me to suspect that vendors no longer expect POSTing to be possible after initial system boot. No, it means that some of my ATI cards don't function as secondary adapters on 2K and XP. -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote: On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett [EMAIL PROTECTED] wrote: It also explicitly states that Windows 2000 and XP don't support this, which leads me to suspect that vendors no longer expect POSTing to be possible after initial system boot. No, it means that some of my ATI cards don't function as secondary adapters on 2K and XP. And nor will any other card that requires POSTing (assuming that it isn't just ATI being less than honest about driver shortcomings). And we've certainly seen in the past that removing support for functionality in Windows tends to result in hardware no longer supporting that functionality. I have real, shipping hardware here that fails if you simply try to execute the video BIOS POST code. If you think this is due to a shortcoming in existing BIOS emulations, I'm more than happy to dump the video and system BIOS regions and send them to you. -- Matthew Garrett | [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, Feb 10, 2005 at 03:17:47PM -0500, Jon Smirl wrote: On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett [EMAIL PROTECTED] wrote: It also explicitly states that Windows 2000 and XP don't support this, which leads me to suspect that vendors no longer expect POSTing to be possible after initial system boot. No, it means that some of my ATI cards don't function as secondary adapters on 2K and XP. So you can suspend with one of these and the card gets resumed properly? If so I wonder why they don't allow POSTing of secondary cards. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
I added Kendall from Scitech to the CC list. He is the expert on getting VBIOS's to post. Maybe he can help. On Thu, 10 Feb 2005 20:29:47 +, Matthew Garrett [EMAIL PROTECTED] wrote: On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote: On Thu, 10 Feb 2005 20:08:15 +, Matthew Garrett [EMAIL PROTECTED] wrote: It also explicitly states that Windows 2000 and XP don't support this, which leads me to suspect that vendors no longer expect POSTing to be possible after initial system boot. No, it means that some of my ATI cards don't function as secondary adapters on 2K and XP. And nor will any other card that requires POSTing (assuming that it isn't just ATI being less than honest about driver shortcomings). And we've certainly seen in the past that removing support for functionality in Windows tends to result in hardware no longer supporting that functionality. I have real, shipping hardware here that fails if you simply try to execute the video BIOS POST code. If you think this is due to a shortcoming in existing BIOS emulations, I'm more than happy to dump the video and system BIOS regions and send them to you. -- Matthew Garrett | [EMAIL PROTECTED] -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Thu, 10 Feb 2005, Bill Davidsen wrote: Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. Isn't that what it's there for? In any context other than save/restore I wouldn't think using the BIOS was a good approach. But this is a special case, and if there's a BIOS function which does the right thing, it would seem to be easier to assume that the BIOS works than that the driver can do every operation for a clean restart. Maybe with new cards it is different but a few years ago, most cards that I tested had problems with those functions. -- Matan Ziv-Av. [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > > > > We already try to do that, but it hangs on 70% of machines. See > > > > Documentation/power/video.txt. > > > > > > We know that all of these ROMs are run at power on so they have to > > > work. This implies that there must be something wrong with the > > > environment the ROM are being run in. Video ROMs make calls into the > > > INT vectors of the system BIOS. If these haven't been set up yet > > > running the VBIOS is sure to hang. Has someone with ROM source and > > > the appropriate debugging tools tried to debug one of these hangs? > > > Alternatively code could be added to wakeup.S to try and set these up > > > or dump the ones that are there and see if they are sane. > > > > Rumors say that notebooks no longer have video bios at C000h:0; rumors > > say that video BIOS on notebooks is simply integrated into main system > > BIOS. I personaly do not know if rumors are true, but PCs are ugly > > machines > > The state of current hardware has already been mentioned but let > me clarify. This is not a laptop problem anytime you have onboard > video you are unlikely to have a separate video ROM. This includes > many recent server boards as well as laptops. When the board boots > up there will be a video option ROM shadowed into the usually location > at C000h:0 but what becomes of it afterwards is a good question. > > For server boards most commonly this seems to be a flavor of the ATI > Rage XL chip. It is a low end part that I doubt getting documentation > for will be very hard. And according to > Documentation/power/video.txt this is one of the cases that actually > works. I do not see Rage XL mentioned in video.txt; can you give me details and/or suggest a patch? > What is happening in those POST routines of a video card is typically > the code to initialize the memory controller on the video card. Plus > a little bit of code to set the video mode. If I read the > documentation correctly in a S3 power state only the RAM is preserved. > So it does look like the video post is needed. On some machines, video state is preserved over S3... Some BIOSes are good enough to POST video for you... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > > > > We already try to do that, but it hangs on 70% of machines. See > > > Documentation/power/video.txt. > > > > We know that all of these ROMs are run at power on so they have to > > work. This implies that there must be something wrong with the > > environment the ROM are being run in. Video ROMs make calls into the > > INT vectors of the system BIOS. If these haven't been set up yet > > running the VBIOS is sure to hang. Has someone with ROM source and > > the appropriate debugging tools tried to debug one of these hangs? > > Alternatively code could be added to wakeup.S to try and set these up > > or dump the ones that are there and see if they are sane. > > Rumors say that notebooks no longer have video bios at C000h:0; rumors > say that video BIOS on notebooks is simply integrated into main system > BIOS. I personaly do not know if rumors are true, but PCs are ugly > machines The state of current hardware has already been mentioned but let me clarify. This is not a laptop problem anytime you have onboard video you are unlikely to have a separate video ROM. This includes many recent server boards as well as laptops. When the board boots up there will be a video option ROM shadowed into the usually location at C000h:0 but what becomes of it afterwards is a good question. For server boards most commonly this seems to be a flavor of the ATI Rage XL chip. It is a low end part that I doubt getting documentation for will be very hard. And according to Documentation/power/video.txt this is one of the cases that actually works. What is happening in those POST routines of a video card is typically the code to initialize the memory controller on the video card. Plus a little bit of code to set the video mode. If I read the documentation correctly in a S3 power state only the RAM is preserved. So it does look like the video post is needed. Hmm. Looking at the ACPI 3.0 spec it appears there is a _ROM method that can be called to get a copy of the ROM image for an onboard video card. Has any one tried that method? Eric - 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: [ACPI] Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > > Some systems (intel notably) appear to expect you to use the bios > > save/restore video state not re-POST. > > This works well in many cases, but there are some machines that freeze > if you attempt to make a VBE state save call. Sadly, I don't have any > access to an affected machine, so it's a bit awkward working out what > the problem is. Where do I find code to do VBE save state? I might get you some testing... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [ACPI] Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Sun, 2005-02-06 at 16:02 +, Alan Cox wrote: > Some systems (intel notably) appear to expect you to use the bios > save/restore video state not re-POST. This works well in many cases, but there are some machines that freeze if you attempt to make a VBE state save call. Sadly, I don't have any access to an affected machine, so it's a bit awkward working out what the problem is. -- Matthew Garrett | [EMAIL PROTECTED] - 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: [ACPI] Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Sun, 2005-02-06 at 16:02 +, Alan Cox wrote: Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. This works well in many cases, but there are some machines that freeze if you attempt to make a VBE state save call. Sadly, I don't have any access to an affected machine, so it's a bit awkward working out what the problem is. -- Matthew Garrett | [EMAIL PROTECTED] - 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: [ACPI] Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. This works well in many cases, but there are some machines that freeze if you attempt to make a VBE state save call. Sadly, I don't have any access to an affected machine, so it's a bit awkward working out what the problem is. Where do I find code to do VBE save state? I might get you some testing... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Pavel Machek [EMAIL PROTECTED] writes: Hi! We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. We know that all of these ROMs are run at power on so they have to work. This implies that there must be something wrong with the environment the ROM are being run in. Video ROMs make calls into the INT vectors of the system BIOS. If these haven't been set up yet running the VBIOS is sure to hang. Has someone with ROM source and the appropriate debugging tools tried to debug one of these hangs? Alternatively code could be added to wakeup.S to try and set these up or dump the ones that are there and see if they are sane. Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines The state of current hardware has already been mentioned but let me clarify. This is not a laptop problem anytime you have onboard video you are unlikely to have a separate video ROM. This includes many recent server boards as well as laptops. When the board boots up there will be a video option ROM shadowed into the usually location at C000h:0 but what becomes of it afterwards is a good question. For server boards most commonly this seems to be a flavor of the ATI Rage XL chip. It is a low end part that I doubt getting documentation for will be very hard. And according to Documentation/power/video.txt this is one of the cases that actually works. What is happening in those POST routines of a video card is typically the code to initialize the memory controller on the video card. Plus a little bit of code to set the video mode. If I read the documentation correctly in a S3 power state only the RAM is preserved. So it does look like the video post is needed. Hmm. Looking at the ACPI 3.0 spec it appears there is a _ROM method that can be called to get a copy of the ROM image for an onboard video card. Has any one tried that method? Eric - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. We know that all of these ROMs are run at power on so they have to work. This implies that there must be something wrong with the environment the ROM are being run in. Video ROMs make calls into the INT vectors of the system BIOS. If these haven't been set up yet running the VBIOS is sure to hang. Has someone with ROM source and the appropriate debugging tools tried to debug one of these hangs? Alternatively code could be added to wakeup.S to try and set these up or dump the ones that are there and see if they are sane. Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines The state of current hardware has already been mentioned but let me clarify. This is not a laptop problem anytime you have onboard video you are unlikely to have a separate video ROM. This includes many recent server boards as well as laptops. When the board boots up there will be a video option ROM shadowed into the usually location at C000h:0 but what becomes of it afterwards is a good question. For server boards most commonly this seems to be a flavor of the ATI Rage XL chip. It is a low end part that I doubt getting documentation for will be very hard. And according to Documentation/power/video.txt this is one of the cases that actually works. I do not see Rage XL mentioned in video.txt; can you give me details and/or suggest a patch? What is happening in those POST routines of a video card is typically the code to initialize the memory controller on the video card. Plus a little bit of code to set the video mode. If I read the documentation correctly in a S3 power state only the RAM is preserved. So it does look like the video post is needed. On some machines, video state is preserved over S3... Some BIOSes are good enough to POST video for you... Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
hi all, I would like point to work done by Li-Ta Lo. It allows you to completely initalize the VGA BIOS w/out using PC BIOS at all. http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html unforunatelly the information the web is somewhat sparse, but you can get more info by following the archive of the thread (which head I listed above) and perhaps by posting to linuxbios mailing list (Ollie, is somewhat buy those days with his new baby). Either way quite amazing feat that should bring LinuxBIOS closer to desktop. - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Sad, 2005-02-05 at 09:35, Pavel Machek wrote: > Rumors say that notebooks no longer have video bios at C000h:0; rumors > say that video BIOS on notebooks is simply integrated into main system > BIOS. I personaly do not know if rumors are true, but PCs are ugly > machines > A small number of laptop systems are known to pull this trick. There are other problems too - the video bios boot may make other assumptions about access to PCI space, configuration, interrupts, timers etc. Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Sad, 2005-02-05 at 09:35, Pavel Machek wrote: Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines A small number of laptop systems are known to pull this trick. There are other problems too - the video bios boot may make other assumptions about access to PCI space, configuration, interrupts, timers etc. Some systems (intel notably) appear to expect you to use the bios save/restore video state not re-POST. - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
hi all, I would like point to work done by Li-Ta Lo. It allows you to completely initalize the VGA BIOS w/out using PC BIOS at all. http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html unforunatelly the information the web is somewhat sparse, but you can get more info by following the archive of the thread (which head I listed above) and perhaps by posting to linuxbios mailing list (Ollie, is somewhat buy those days with his new baby). Either way quite amazing feat that should bring LinuxBIOS closer to desktop. - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > > We already try to do that, but it hangs on 70% of machines. See > > Documentation/power/video.txt. > > We know that all of these ROMs are run at power on so they have to > work. This implies that there must be something wrong with the > environment the ROM are being run in. Video ROMs make calls into the > INT vectors of the system BIOS. If these haven't been set up yet > running the VBIOS is sure to hang. Has someone with ROM source and > the appropriate debugging tools tried to debug one of these hangs? > Alternatively code could be added to wakeup.S to try and set these up > or dump the ones that are there and see if they are sane. Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. We know that all of these ROMs are run at power on so they have to work. This implies that there must be something wrong with the environment the ROM are being run in. Video ROMs make calls into the INT vectors of the system BIOS. If these haven't been set up yet running the VBIOS is sure to hang. Has someone with ROM source and the appropriate debugging tools tried to debug one of these hangs? Alternatively code could be added to wakeup.S to try and set these up or dump the ones that are there and see if they are sane. Rumors say that notebooks no longer have video bios at C000h:0; rumors say that video BIOS on notebooks is simply integrated into main system BIOS. I personaly do not know if rumors are true, but PCs are ugly machines Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote: > We already try to do that, but it hangs on 70% of machines. See > Documentation/power/video.txt. We know that all of these ROMs are run at power on so they have to work. This implies that there must be something wrong with the environment the ROM are being run in. Video ROMs make calls into the INT vectors of the system BIOS. If these haven't been set up yet running the VBIOS is sure to hang. Has someone with ROM source and the appropriate debugging tools tried to debug one of these hangs? Alternatively code could be added to wakeup.S to try and set these up or dump the ones that are there and see if they are sane. -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit : > Doing this in user space lets you have two reset > programs, vm86 and emu86 for non-x86 machines. Perhaps only emu86 should be used, to have a well-debugged codepath on all archs (amd64, ppc, ...) As it's usermode, the code size is less of a problem. Xav - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek: > What about simply blocking all video accesses before disk (etc) is > resumed, so that "normal" (not locked in memory) application can be > used? Very bad for debugging. Genuine serial ports are becoming rarer. Regards Oliver - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi!
> > I'd love to see it too. Pavel, even if you don't want to merge it for a
> > while, we can always incorporate it in the Suspend2 patches so it gets
> > some testing. I know I'd try it on my i830 based Omnibook.
>
> Can we use call_usermodehelper at this early resume stage (before any
> video access)? Calling vm86 directly is probably not going to fly
> because we want to be shielded from any misbehaviour in the bios code
> and it may be necessary to kill the process running the bios code.
>
> Cases in point: My bios will cause the POSTing application to segfault.
> Others have reported the POSTing application just hangs, but the
> important things are done before the hang, so killing it after maybe
> 5 seconds would be ok.
>
> Rough outline how to do that without adding tons of code:
> We need a call_usermodehelper_from_ram_with_timeout for that.
>
> Kernel: Userspace:
> User wants to enter S3
> init_mutex_locked(s3_sem)
> call_usermodehelper("vesaposter")
> vesaposter calls LRMI_init
> vesaposter mlocks all its memory
> vesaposter calls into kernel
> and down(s3_sem)
> suspend vesafb
>
> User has triggered resume
> run wakeup.S
> thaw essential threads
> set a timer of 5 seconds
> up(s3_sem)
> thaw and schedule vesaposter
> wait for timer or vesaposter termination
> vesaposter returns from kernel
> vesaposter posts video card
> vesaposter terminates
> resume vesafb
> continue resume
>
> Problems with that approach:
> - vesaposter has to be locked in memory to avoid disk accesses
> - vesafb has to refrain from touching video until after POST
> - the vesaposter thread has to be the first unfrozen and
> scheduled and completed thread. Only after that we can resume
> vesafb and other threads
> - the locking will be tricky
- it is ugly
What about simply blocking all video accesses before disk (etc) is
resumed, so that "normal" (not locked in memory) application can be
used?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! I'd love to see it too. Pavel, even if you don't want to merge it for a while, we can always incorporate it in the Suspend2 patches so it gets some testing. I know I'd try it on my i830 based Omnibook. Can we use call_usermodehelper at this early resume stage (before any video access)? Calling vm86 directly is probably not going to fly because we want to be shielded from any misbehaviour in the bios code and it may be necessary to kill the process running the bios code. Cases in point: My bios will cause the POSTing application to segfault. Others have reported the POSTing application just hangs, but the important things are done before the hang, so killing it after maybe 5 seconds would be ok. Rough outline how to do that without adding tons of code: We need a call_usermodehelper_from_ram_with_timeout for that. Kernel: Userspace: User wants to enter S3 init_mutex_locked(s3_sem) call_usermodehelper(vesaposter) vesaposter calls LRMI_init vesaposter mlocks all its memory vesaposter calls into kernel and down(s3_sem) suspend vesafb User has triggered resume run wakeup.S thaw essential threads set a timer of 5 seconds up(s3_sem) thaw and schedule vesaposter wait for timer or vesaposter termination vesaposter returns from kernel vesaposter posts video card vesaposter terminates resume vesafb continue resume Problems with that approach: - vesaposter has to be locked in memory to avoid disk accesses - vesafb has to refrain from touching video until after POST - the vesaposter thread has to be the first unfrozen and scheduled and completed thread. Only after that we can resume vesafb and other threads - the locking will be tricky - it is ugly What about simply blocking all video accesses before disk (etc) is resumed, so that normal (not locked in memory) application can be used? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek: What about simply blocking all video accesses before disk (etc) is resumed, so that normal (not locked in memory) application can be used? Very bad for debugging. Genuine serial ports are becoming rarer. Regards Oliver - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Le vendredi 04 fvrier 2005 00:03 -0500, Jon Smirl a crit : Doing this in user space lets you have two reset programs, vm86 and emu86 for non-x86 machines. Perhaps only emu86 should be used, to have a well-debugged codepath on all archs (amd64, ppc, ...) As it's usermode, the code size is less of a problem. Xav - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek [EMAIL PROTECTED] wrote: We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. We know that all of these ROMs are run at power on so they have to work. This implies that there must be something wrong with the environment the ROM are being run in. Video ROMs make calls into the INT vectors of the system BIOS. If these haven't been set up yet running the VBIOS is sure to hang. Has someone with ROM source and the appropriate debugging tools tried to debug one of these hangs? Alternatively code could be added to wakeup.S to try and set these up or dump the ones that are there and see if they are sane. -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > > > User has triggered resume > > > run wakeup.S > > wakeup.S runs in real mode. Why can't it just call the VBIOS at > C000:0003 to reset the hardware before setting the mode? We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! > Reseting a video card from suspend is essentially the same problem as > reseting secondary video cards on boot. The same code can address both > problems. Well, it is made more tricky by the fact that you are running during resume -- hard to debug. Ideally you want to have video so you can debug resume of ethernet, disk, etc... But you don't have video :-(. But I agree, same code should be used. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Fri, 04 Feb 2005 13:51:55 +1100, Nigel Cunningham <[EMAIL PROTECTED]> wrote: > > User has triggered resume > > run wakeup.S wakeup.S runs in real mode. Why can't it just call the VBIOS at C000:0003 to reset the hardware before setting the mode? -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Reseting a video card from suspend is essentially the same problem as reseting secondary video cards on boot. The same code can address both problems. Some things to consider 1) With multiple video cards you have to ensure only a single VGA gets enabled. Running video reset on a card is going to turn on it's VGA emulation. So you have to ensure that VGA emulation on other cards is disabled first. 2) I add the 'rom' parameter in sysfs so that you can get to the rom contents from a user space app. It's there to support running video reset code. "echo 1 >rom" to see the contents, it is not enabled by default. 3) The user space reset programs have to be serialized because of the rule about only a single VGA at a time. Calling vm86 from kernel mode is not a good idea. Doing this in user space lets you have two reset programs, vm86 and emu86 for non-x86 machines. A starting place for a user space reset program: ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz This thread talks about the VGA routing code: http://lkml.org/lkml/2005/1/17/347 -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi.
On Fri, 2005-02-04 at 13:35, Carl-Daniel Hailfinger wrote:
> Can we use call_usermodehelper at this early resume stage (before any
> video access)? Calling vm86 directly is probably not going to fly
> because we want to be shielded from any misbehaviour in the bios code
> and it may be necessary to kill the process running the bios code.
>
> Cases in point: My bios will cause the POSTing application to segfault.
> Others have reported the POSTing application just hangs, but the
> important things are done before the hang, so killing it after maybe
> 5 seconds would be ok.
Yuck!
> Rough outline how to do that without adding tons of code:
> We need a call_usermodehelper_from_ram_with_timeout for that.
>
> Kernel: Userspace:
> User wants to enter S3
> init_mutex_locked(s3_sem)
> call_usermodehelper("vesaposter")
> vesaposter calls LRMI_init
> vesaposter mlocks all its memory
> vesaposter calls into kernel
> and down(s3_sem)
> suspend vesafb
>
> User has triggered resume
> run wakeup.S
> thaw essential threads
> set a timer of 5 seconds
> up(s3_sem)
> thaw and schedule vesaposter
> wait for timer or vesaposter termination
> vesaposter returns from kernel
> vesaposter posts video card
> vesaposter terminates
> resume vesafb
> continue resume
>
> Problems with that approach:
> - vesaposter has to be locked in memory to avoid disk accesses
That's no biggie.
> - vesafb has to refrain from touching video until after POST
Which is why I think we should do the post asap (as you have). What is
counted as an essential thread?
> - the vesaposter thread has to be the first unfrozen and
> scheduled and completed thread. Only after that we can resume
> vesafb and other threads
All other threads will be frozen, and we don't have scheduler hooks that
will hang up our new kiddie, so we should be right there.
> - the locking will be tricky
But also simplified by the fact that everything else is frozen.
> Advantages:
> - the problems all seem to be solvable easily
> - security and stability are similar to the current userspace code
> - we can use vesafb on such machines
> - the kernel code won't be much more than two dozen lines
> - the userspace POSTing code can be upgraded without the need
> for kernel updates (no policy in the kernel)
>
> What do you think?
Show us some code :>
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574
-
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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi. On Fri, 2005-02-04 at 13:35, Carl-Daniel Hailfinger wrote: Can we use call_usermodehelper at this early resume stage (before any video access)? Calling vm86 directly is probably not going to fly because we want to be shielded from any misbehaviour in the bios code and it may be necessary to kill the process running the bios code. Cases in point: My bios will cause the POSTing application to segfault. Others have reported the POSTing application just hangs, but the important things are done before the hang, so killing it after maybe 5 seconds would be ok. Yuck! Rough outline how to do that without adding tons of code: We need a call_usermodehelper_from_ram_with_timeout for that. Kernel: Userspace: User wants to enter S3 init_mutex_locked(s3_sem) call_usermodehelper(vesaposter) vesaposter calls LRMI_init vesaposter mlocks all its memory vesaposter calls into kernel and down(s3_sem) suspend vesafb User has triggered resume run wakeup.S thaw essential threads set a timer of 5 seconds up(s3_sem) thaw and schedule vesaposter wait for timer or vesaposter termination vesaposter returns from kernel vesaposter posts video card vesaposter terminates resume vesafb continue resume Problems with that approach: - vesaposter has to be locked in memory to avoid disk accesses That's no biggie. - vesafb has to refrain from touching video until after POST Which is why I think we should do the post asap (as you have). What is counted as an essential thread? - the vesaposter thread has to be the first unfrozen and scheduled and completed thread. Only after that we can resume vesafb and other threads All other threads will be frozen, and we don't have scheduler hooks that will hang up our new kiddie, so we should be right there. - the locking will be tricky But also simplified by the fact that everything else is frozen. Advantages: - the problems all seem to be solvable easily - security and stability are similar to the current userspace code - we can use vesafb on such machines - the kernel code won't be much more than two dozen lines - the userspace POSTing code can be upgraded without the need for kernel updates (no policy in the kernel) What do you think? Show us some code : Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Reseting a video card from suspend is essentially the same problem as reseting secondary video cards on boot. The same code can address both problems. Some things to consider 1) With multiple video cards you have to ensure only a single VGA gets enabled. Running video reset on a card is going to turn on it's VGA emulation. So you have to ensure that VGA emulation on other cards is disabled first. 2) I add the 'rom' parameter in sysfs so that you can get to the rom contents from a user space app. It's there to support running video reset code. echo 1 rom to see the contents, it is not enabled by default. 3) The user space reset programs have to be serialized because of the rule about only a single VGA at a time. Calling vm86 from kernel mode is not a good idea. Doing this in user space lets you have two reset programs, vm86 and emu86 for non-x86 machines. A starting place for a user space reset program: ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz This thread talks about the VGA routing code: http://lkml.org/lkml/2005/1/17/347 -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
On Fri, 04 Feb 2005 13:51:55 +1100, Nigel Cunningham [EMAIL PROTECTED] wrote: User has triggered resume run wakeup.S wakeup.S runs in real mode. Why can't it just call the VBIOS at C000:0003 to reset the hardware before setting the mode? -- Jon Smirl [EMAIL PROTECTED] - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! Reseting a video card from suspend is essentially the same problem as reseting secondary video cards on boot. The same code can address both problems. Well, it is made more tricky by the fact that you are running during resume -- hard to debug. Ideally you want to have video so you can debug resume of ethernet, disk, etc... But you don't have video :-(. But I agree, same code should be used. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))
Hi! User has triggered resume run wakeup.S wakeup.S runs in real mode. Why can't it just call the VBIOS at C000:0003 to reset the hardware before setting the mode? We already try to do that, but it hangs on 70% of machines. See Documentation/power/video.txt. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
