hibernate and suspend broken on F17 i686 desktop
by Greg Woods
I have an i686 desktop (dual core 2GHZ Pentium 4), on which suspend and
hibernate have not worked properly since sometime in the 3.1 kernel
series. This system has 4GB RAM and uses the PAE kernel.
Under F16, I kept updating the kernel and finding each time that suspend
and hibernate did not work, and so kept running the older kernel.
Eventually I had to move to F17. What happens with the newer kernels is,
if I suspend, the machine appears to suspend (last line on the screen is
the one about "suspending console, set no_console_suspend to debug" and
then it hangs (never powers off). Of course if I power it off manually,
the suspended image is lost and it reboots from scratch. If I hibernate
it, it does write the hibernate image to disk, prints the "suspending
console, set no_console_suspend to debug" line, and again hangs without
powering off. If I power off the machine with the power button, on
reboot it does resume properly from the hibernate image, so I think the
problem is just that it's no longer powering the machine off after
suspend/hibernate is complete. The BIOS settings have not been changed
from when it was working.
This is similar to some other threads I've seen here, but ironically, in
my case, the F17 kernels hibernate and suspend just fine on a pair of
x86_64 laptops I have (one Dell and one Sony VAIO). It's only the
desktop where they don't work.
I'm hoping, of course, that somebody will have a magic boot time kernel
parameter recipe I can try that might work, or failing that, a pointer
to some documentation on how to debug suspend/hibernate problems.
TIA,
--Greg
11 years, 9 months
powerdown restarts
by Geoffrey Leach
This problem has been submitted to Bugzilla (836657), but I thought I'd
ask here to see if there are any fixes lurking.
System is running 3.4.3-1.fc17.x86_64. When I systemctl poweroff the
kernel reboots instead of powering off. Under Windows 7, power off
works as expected. All packages are up-to-date.
Any ideas?
11 years, 9 months
Re: F17 XDMCP
by Ken Smith
>
>
>
>
> Gordon Messmer wrote:
>> On 07/02/2012 07:08 AM, Ken Smith wrote:
>>>
>>> I would suggest deprecated as the settings for the function have been
>>> buried. It suppose it depends on how you define deprecated.
>>
>> No, they haven't. They're still in custom.conf, where they've been
>> for some time. The buried settings discussed earlier apply to GDM,
>> which has not itself been deprecated.
>>
>>> If I try the access the FC17 VM with "X -query ..." from the FC13 host
>>> or the C6 VM, the machine switches desktop as expected and then
>>> displays
>>> the circular mouse icon on a black screen and then the desktop freezes.
>>> Cntl-Alt F1 or 2 etc then do nothing.
>>
>> It sounds like the X server is crashing or locking up. Try this:
>> Reset the machine running the X server. Possibly reset the F17 host
>> as well, since it's complaining about too many sessions from your X
>> server host. When you run X -query, capture data using strace:
>>
>> strace -f -s 256 X -query ... > /var/tmp/xtrace.txt 2>&1
>>
>> After the X server locks, cancel the trace with Ctrl+C. Don't send
>> the file to the list, because it'll be large. I don't think it has
>> any sensitive data in it, so maybe compress it and post it somewhere
>> it can be retrieved (http://ge.tt ?) or send it to me. What we're
>> looking for is output from glibc similar to what I included
>> previously. It'll be on lines near the end which indicate calls to
>> writev().
I have just sent the below to Gordon off list with an attached file with
the traces.
Hi Gordon,
I attach a tar.gz file with the traces. It only 500k so e-mail should cope.
These were done with the FC13 machine, that acts as the VM host, as an X
server and the FC17 VM acting as an X client. The FC17 was freshly
booted. I had a ssh session logged in to the FC13 from another machine
as I was expecting to lose control of the desktop of the FC13 machine
during these tests.
The file xtrace.txt is a trace using Xnest from a normal user account on
the FC13 X server.
The file xtrace2.txt is a trace of a repeat of the last Xnest command
but this time a login desktop appeared and allowed me to start entering
logon details before it vanished off the screen
The file xtrace3.txt is a trace of a "X -query ..." command from a
normal user account on the FC13 X server
The file xtrace4.txt is a trace of a "X -query ..." command from the
root account on the FC13 X server. As previously the desktop switched to
the new X display and it showed a small round icon that was movable with
the mouse.
The file xtrace4-copy.txt is a copy of xtrace4.txt made after running
the "X -query ..." command but before rebooting that machine to regain
control of the desktop.
There's some interesting things in that xtrace4.txt file about malloc
and memory corruption.
Hope this helps
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11 years, 9 months
Can DHCP deamon expire leases "lazily"?
by Tom Horsley
I've got some virtual machines with old kernels that know nothing
about virt clocks. They keep time so horribly when loaded up with
testbed runs that they forget to renew their DHCP lease, which
results in their name being removed from the DNS server, which
results in testbed failure :-(.
Does anyone know if it is possible to configure the DHCP daemon
to just leave expired leases active until it actually needs
to reuse the IP address for a new request?
Lacking that, I suppose I can identify the handful of machines
that exhibit this problem and give them static IPs...
11 years, 9 months
F17 XDMCP
by Ken Smith
Hi, I in danger of making this a rant, but is XDMCP no longer something
that Fedora supports?
I have just installed F17 x64 in a VM to tinker with it and systemd and
I'd like to enable XDMCP. Or what is the favoured remote access method
these days.
I've put DisallowTCP=0 in the [security] section and Enable=1 in the
[xdmcp] section of custom.conf in /etc/gdm/ and opened port 177 UDP in
the firewall on the F17 machine.
Oddly, on my remote X server when I run "X -query machinename :1" the
desktop of the remote X server freezes when connecting to this rogue F17
install. As I would expect I can see an open UDP session on UDP 177 but
I don't see any traffic on TCP 6000 or 6001 that I would expect. The
same remote X server connects to FC6, Centos5.6 etc etc without any issue.
What gives?
Thanks for any hints and guidance.
Ken
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11 years, 9 months
socket files in /tmp/at-spi2
by Alexander Volovics
When starting up Fed17 a number of 'sockets' get created in
/tmp/at-spi2. The same when starting apps.
However these sockets are not removed when closing the apps
or shutting down Fed17.
So the number of these sockets keeps increasing.
Is this normal behaviour or should I file a bug?
Alexander
11 years, 9 months
mobile broadband
by mulkesh sharma
sir i am just start using linex i don't know how it works. but it seems
quit interesting. sir i try to use my mobile broadband to run internet in
fedora, but don't know how .
sir please help me
11 years, 9 months
Re: Fedora 17 sound issues- NOT solved !
by linux guy
I spoke too soon.
Everything works fine as long as I keep pavucontrol running. As soon
as I close it sound stops.
I'm running pavucontrol as root. What gives ?
I ran authconfig --updateall as a regular user and have rebooted several times.
Any ideas ?
11 years, 9 months
Re: Fedora 17 sound issues (Solved)
by linux guy
Great tip.
I installed pavucontrol and found out that ALSA playback was set to
Digital Stereo out. I changed it to Analog Stereo Out and it works
great.
Thanks !
11 years, 9 months