Re: secondary ACPI problems
Kevin Oberman writes: From: Andrew Gallatin [EMAIL PROTECTED] Date: Wed, 19 Mar 2003 17:41:17 -0500 (EST) Sender: [EMAIL PROTECTED] Daniel O'Connor writes: Restart X? :-) I wish. The board seems totally gone after an ACPI suspend. This seems to be a common problem with ATI cards. Work-around for M7 cards (may or may not work for others): Switch to a character display (CTRL-ALT-F2) Turn off the display (Fn-F3 on my ThinkPad) Press any key to turn on display Switch back to X (ALT-F9) This solution seems to be dependant on using a laptop. My box is a desktop. I wish there was something I could do to force a reset like this. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: secondary ACPI problems
On Sat, 14 Dec 2002, Andrew Gallatin wrote: This does not happen if I do not have rp.ko loaded. I suspect that the rocketport card needs some setup when power is restored. It polls all its ports, so it makes sense that a swi would get clogged. I thought it might be sufficent to unload the driver and reload after resume. However, it doens't appear to be unloadable now. Before I get too far into this, will unloading rp and reloading it suffice, or is there a better way which could just allow me to save and restore the card state so I wouldn't have to reload it on resume? See the device_suspend/resume implementations in various drivers (i.e. rl(4)). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: secondary ACPI problems
Nate Lawson writes: On Sat, 14 Dec 2002, Andrew Gallatin wrote: This does not happen if I do not have rp.ko loaded. I suspect that the rocketport card needs some setup when power is restored. It polls all its ports, so it makes sense that a swi would get clogged. I thought it might be sufficent to unload the driver and reload after resume. However, it doens't appear to be unloadable now. Before I get too far into this, will unloading rp and reloading it suffice, or is there a better way which could just allow me to save and restore the card state so I wouldn't have to reload it on resume? See the device_suspend/resume implementations in various drivers (i.e. rl(4)). Wow, what a blast from the past! ;) Shouldn't a driver without a suspend/resume implementation implicitly veto the suspend? That's how OS-X does it. Anyway, I'll worry about this when/if somebody can tell me how to get my video back after suspending to S3: [EMAIL PROTECTED]:0:0: class=0x03 card=0x7106174b chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 128 Pro AGP 4x' class= display Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: secondary ACPI problems
On Wed, 19 Mar 2003, Andrew Gallatin wrote: Nate Lawson writes: On Sat, 14 Dec 2002, Andrew Gallatin wrote: This does not happen if I do not have rp.ko loaded. I suspect that the rocketport card needs some setup when power is restored. It polls all its ports, so it makes sense that a swi would get clogged. I thought it might be sufficent to unload the driver and reload after resume. However, it doens't appear to be unloadable now. Before I get too far into this, will unloading rp and reloading it suffice, or is there a better way which could just allow me to save and restore the card state so I wouldn't have to reload it on resume? See the device_suspend/resume implementations in various drivers (i.e. rl(4)). Wow, what a blast from the past! ;) I am trying to eliminate a backlog of email. I can only manage actually reading cvs-src and developers it seems. Shouldn't a driver without a suspend/resume implementation implicitly veto the suspend? That's how OS-X does it. Currently the default is null_suspend which returns 0 (i.e. ok). You could create a new default, refuse_suspend and then go to all drivers and add an explicit call to null_suspend but I'm not sure this is the best idea. Anyway, I'll worry about this when/if somebody can tell me how to get my video back after suspending to S3: [EMAIL PROTECTED]:0:0: class=0x03 card=0x7106174b chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 128 Pro AGP 4x' class= display Sorry, I have no knowledge of video hw except that it does need to be reset on suspend. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: secondary ACPI problems
On Thu, 2003-03-20 at 08:28, Andrew Gallatin wrote: Shouldn't a driver without a suspend/resume implementation implicitly veto the suspend? That's how OS-X does it. I don't think so - the reason being that when a lot of this stuff was written it was done for APM. Since the OS doesn't _usually_ have to frob the hardware when using APM the default makes sense. Anyway, I'll worry about this when/if somebody can tell me how to get my video back after suspending to S3: [EMAIL PROTECTED]:0:0: class=0x03 card=0x7106174b chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 128 Pro AGP 4x' class= display Restart X? :-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: secondary ACPI problems
Daniel O'Connor writes: Restart X? :-) I wish. The board seems totally gone after an ACPI suspend. This seems to be a common problem with ATI cards. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: secondary ACPI problems
From: Andrew Gallatin [EMAIL PROTECTED] Date: Wed, 19 Mar 2003 17:41:17 -0500 (EST) Sender: [EMAIL PROTECTED] Daniel O'Connor writes: Restart X? :-) I wish. The board seems totally gone after an ACPI suspend. This seems to be a common problem with ATI cards. Work-around for M7 cards (may or may not work for others): Switch to a character display (CTRL-ALT-F2) Turn off the display (Fn-F3 on my ThinkPad) Press any key to turn on display Switch back to X (ALT-F9) R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
secondary ACPI problems
Hi, I've got an Intel D845EBG2. I have 2 ACPI related problems I'm looking for advice on: - ATI Rage 128 Pro TF If I suspend to S3 from text mode on console, the screen remains blank after resume. The system is otherwise functional, and can be logged into remotely. If I start X after resume, the system locks solid. If I suspend from inside X, the system locks solid a few seconds after resume. I'm happy to replace the ATI with something which works. So.. is there a cheap AGP4x video card (to drive analog LCD 1280x1024@60Hz) which is known to work well with ACPI on FreeBSD? - rp.ko If I suspend to S3 and resume, the system becomes nearly unusable because it spends all its time in swi6: tty:sio clock (200%, in fact!:) Ping times go from 3ms to 11000ms from nearby powerbook. Commands take seconds to echo, etc. This does not happen if I do not have rp.ko loaded. I suspect that the rocketport card needs some setup when power is restored. It polls all its ports, so it makes sense that a swi would get clogged. I thought it might be sufficent to unload the driver and reload after resume. However, it doens't appear to be unloadable now. Before I get too far into this, will unloading rp and reloading it suffice, or is there a better way which could just allow me to save and restore the card state so I wouldn't have to reload it on resume? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
