Date: Mon, 20 Aug 2012 02:11:30 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Gary Aitken <freebsd@dreamchaser.org> Cc: Matthew Seaman <matthew@freebsd.org>, freebsd-questions@freebsd.org Subject: Re: 9.0 release hang in quiescent X Message-ID: <20120820005007.T33776@sola.nimnet.asn.au> In-Reply-To: <20120818120030.D526210657A8@hub.freebsd.org> References: <20120818120030.D526210657A8@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 428, Issue 7, Message: 4 On Fri, 17 Aug 2012 13:51:07 -0600 Gary Aitken <freebsd@dreamchaser.org> wrote: > On 08/16/12 00:04, Matthew Seaman wrote: > > On 16/08/2012 05:45, Gary Aitken wrote: > ... > >> Running 9.0 release on an amd 64 box, standard kernel, 16GB, SSD (/, > >> /usr, /var, /tmp) + HDDs, visiontek 900331 graphics card (ati radeon > >> hd5550). > >> > >> As long as I am using the system, things seem to be fine. However, > >> when I leave the system idle for an extended period of time (e.g. > >> overnight, out for the day, etc.), it often refuses to return from > >> whatever state it is in. The screen is blank and in standby for > >> power saving, and <ctl><alt> Fn won't get me a console prompt. The > >> only way I know to recover is to power off and reboot. > ... > >> Can someone suggest a good way to proceed to figure out what's going > >> on? > > > > Can you get network access to the machine when it gets into this state? > > I enabled remote logins and when the system hangs, I can neither log > in nor ping it. I can do both of those prior to a hang. Hi Gary. Please wrap text less than 80 columns on freebsd lists; I was going to reply to a later message but it had got too messy. Turned out this one is more useful anyway, so I've taken the liberty .. > > If you can't, that suggests the OS is hanging or crashing, possibly in > > response to going into some sort of power-saving mode. Now we know that you can't, what Matthew says is pretty likely the case. > > As to working out what the underlying cause of the problem is: that's > > harder. I'd try experimenting with the power saving settings for your > > graphics display. If you can turn them off as a test, and the machine > > then survives for an extended period of idleness, you'll have gone a > > long way towards isolating the problem. Have you yet tried turning off any and all power saving settings, until your monitor quits blanking/suspending, and the machine keeps running? The monitor isn't blanking by itself, BIOS suspend & power off settings for screen, disk etc shouldn't affect a running FreeBSD system (but turn them off anyway!) - so we're left with something you've set yourself, presumably via your (which?) window manager, which then has Xorg, using your hardware's particular driver, do the dirty work on the hardware. Just that it's not clear you've yet isolated the main suspect. There's buggy hardware, buggy ACPI/BIOS implementations, buggy video drivers; it makes sense to rule out another hardware problem by leaving video on. > My display, a NEC multisync LCD 1970NX, has a menu item for "Off > Timer" but it is set to "off" As far as I can tell there are no > other power saving options on the display itself. Even if the display failed completely, it won't make FreeBSD crash. > Could this be related to the sync rates? I'm using whatever X.org > and the drivers decided to come up with, which is 63.9kHz H, 59.9Hz > V. Again, that could only mess up the display, FreeBSD wouldn't care, but you've said you can't ping or login so it seems more likely software. > I have the following in rc.conf: > powerd_enable="YES" # Run powerd to lower our power usage. > powerd_flags="-a hiadaptive -n hiadaptive -p 250" Sure. No relation to video; despite people regularly wanting to add such features, it sticks to its one job like a good little unix tool. > I presume screen blanking is independent of cpu frequency rates, but > it's not clear to me how the screen blanking is controlled. How does > screen blanking interact with BIOS? My screen blanks, but it's not > clear to me if it's BIOS or the os that's doing it. Something you set is doing it :) If running say KDE, suspects would include screen'savers' (as many have mentioned), window manager power settings (setting/peripherals/display/powercontrol on kde3), and lastly as Warren mentioned, settings for Xorg itself, in xorg.conf (if any). As for BIOS, well make sure any video messing with is turned off, but except BIOS settings expressed as AML code to ACPI, the OS ignores it. > man acpi indicates acpi should not be disabled: > "Disabling all or part of ACPI on non-i386 platforms (i.e., > platforms where ACPI support is mandatory) may result in a > non-functional system." That's correct. Systems with more than one CPU rely on ACPI, period. Anyway, in the other thread Polytropon has boldly taken on, we see ACPI enabled. [BTW don't worry about those 'reservation failed' messages if not followed by indications of some failed subsystem; they really should only be shown on verbose dmesg IMO, as they tend to alarm people - QED] > On 08/16/12 00:06, Steve O'Hara-Smith wrote: > > Are you running any kind of screensaver ? > > Sometimes the OpenGL screen saver modules crash without proper > > hardware support. If you're running a screensaver try disabling it and just > > using display blanking. > > I'm not running a screensaver, just blanking the screen. Yes but how, where, using what software? It's still the main suspect .. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120820005007.T33776>