Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Pintér Tibor]

[-- Attachment #1: Type: text/plain, Size: 2915 bytes --]

Reemerge all xf86* packages
Quite obvious as the log clearly gives the clue (new xorg server version, driver version mismatch)

t

"G.Wolfe Woodbury" <redwolfe@gmail.com> wrote:

I did:
    emerge -va --update --deep --newuse @world
on a stable gentoo amd64 (multilib) system after switching the profile
from "desktop/gnome" to "desktop" and adding
qt4 and kde flags to make.conf.  [I wan to add a few kde apps to the
mix, but not everything.]

Since then, I get a keyboard and mouse lockup when gdm starts. and can't
login graphically or switch to a text console.

I'd rather not do a complete re-install on that instance, so some clue
as to where to look for problems beyond the obvious dmesg
and boot info.

I do get a "dmeventd" failure to start, so lvm-monitoring fails to start
(even after a re-emerge of lvm2) but don't think that as anything to do
with the X lockup.  Startx from single user mode also causes a kbd/mouse
lockup.

I've verified that the kernel has the proper event configuration.
Perusing the Xorg.0.log reveals evdev failing to load:

> [   410.507] (II) LoadModule: "evdev"
> [   410.507] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
> [   410.513] (II) Module evdev: vendor="X.Org Foundation"
> [   410.513]    compiled for 1.10.4, module version = 2.6.0
> [   410.513]    Module class: X.Org XInput Driver
> [   410.513]    ABI class: X.Org XInput driver, version 12.2
> [   410.513] (EE) module ABI major version (12) doesn't match the
> server's version (13)
> [   410.513] (II) UnloadModule: "evdev"
> [   410.513] (II) Unloading evdev
> [   410.513] (EE) Failed to load module "evdev" (module requirement
> mismatch, 0)
> [   410.513] (EE) No input driver matching `evdev'
> [   410.513] (II) config/udev: Adding input device Power Button
> (/dev/input/event1)
> [   410.513] (**) Power Button: Applying InputClass "evdev keyboard
> catchall"
> [   410.513] (II) LoadModule: "evdev"
> [   410.513] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
> [   410.513] (II) Module evdev: vendor="X.Org Foundation"
> [   410.513]    compiled for 1.10.4, module version = 2.6.0
> [   410.513]    Module class: X.Org XInput Driver
> [   410.513]    ABI class: X.Org XInput driver, version 12.2
> [   410.513] (EE) module ABI major version (12) doesn't match the
> server's version (13)
> [   410.513] (II) UnloadModule: "evdev"
> [   410.513] (II) Unloading evdev
> [   410.513] (EE) Failed to load module "evdev" (module requirement
> mismatch, 0)
> [   410.513] (EE) No input driver matching `evdev'
> [   410.514] (II) config/udev: Adding input device Sleep Button
> (/dev/input/event0)
which tell me something went wrong in the re-emerge of xorg something,
but I'd like to get a clue as to just what to do to fix it.

Thanks in advance for any help.

-- 
G.Wolfe Woodbury
aka redwolfe@gmail.com




[-- Attachment #2: Type: text/html, Size: 3660 bytes --]

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[G.Wolfe Woodbury]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On 12/22/2011 02:00 AM, Pintér Tibor wrote:
> Reemerge all xf86* packages
> Quite obvious as the log clearly gives the clue (new xorg server 
> version, driver version mismatch)
>
> t

I looked right at it and missed the obvious!  Thanks for the clue-by-four.

-- 
GWW


[-- Attachment #2: Type: text/html, Size: 779 bytes --]

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Alex Schuster]

G.Wolfe Woodbury writes:

> On 12/22/2011 02:00 AM, Pintér Tibor wrote:
> > Reemerge all xf86* packages
> > Quite obvious as the log clearly gives the clue (new xorg server 
> > version, driver version mismatch)

> I looked right at it and missed the obvious!  Thanks for the
> clue-by-four.

BTW, emerge -a @x11-module-rebuild will do this.

	Wonko

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Michael Mol]

On Thu, Dec 22, 2011 at 7:58 AM, Alex Schuster <wonko@wonkology.org> wrote:
> G.Wolfe Woodbury writes:
>
>> On 12/22/2011 02:00 AM, Pintér Tibor wrote:
>> > Reemerge all xf86* packages
>> > Quite obvious as the log clearly gives the clue (new xorg server
>> > version, driver version mismatch)
>
>> I looked right at it and missed the obvious!  Thanks for the
>> clue-by-four.
>
> BTW, emerge -a @x11-module-rebuild will do this.
>
>        Wonko
>

emerge: There are no sets to satisfy 'x11-module-rebuild'. The
following sets exist:

    selected
    system
    world

-- 
:wq

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Dale]

Michael Mol wrote:
> On Thu, Dec 22, 2011 at 7:58 AM, Alex Schuster<wonko@wonkology.org>  wrote:
>> G.Wolfe Woodbury writes:
>>
>>> On 12/22/2011 02:00 AM, Pintér Tibor wrote:
>>>> Reemerge all xf86* packages
>>>> Quite obvious as the log clearly gives the clue (new xorg server
>>>> version, driver version mismatch)
>>> I looked right at it and missed the obvious!  Thanks for the
>>> clue-by-four.
>> BTW, emerge -a @x11-module-rebuild will do this.
>>
>>         Wonko
>>
> emerge: There are no sets to satisfy 'x11-module-rebuild'. The
> following sets exist:
>
>      selected
>      system
>      world
>

Someone posted this one liner a while back:

emerge -1a $(qlist -I -C x11-drivers/)

That takes care of the video driver, mouse, keyboard and such.  Mine is 
these packages:

root@fireball / # qlist -I -C x11-drivers/
x11-drivers/nvidia-drivers
x11-drivers/xf86-input-evdev
x11-drivers/xf86-video-nv
x11-drivers/xf86-video-vesa
root@fireball / #

I try to remember to run that when I upgrade the kernel or xorg.  I 
usually forget and have to do the SysReq keystroke magic.  After I slap 
my forehead of course.

There are quite a few of these commands that gets posted from time to 
time.  As a hint, I have a text file in my /root directory that contains 
the commands and a description.  I just cat and grep the file when I 
need to.  I wouldn't recommend a user directory tho.  If for someone 
reason only root is mounted, then you can get to /root but not /home if 
it is a separate partition.  You, and other Gentooers, may want to think 
about doing something like this.

Hope this helps in some small way.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Michael Mol]

On Fri, Dec 23, 2011 at 12:46 AM, Dale <rdalek1967@gmail.com> wrote:
> Michael Mol wrote:
>> On Thu, Dec 22, 2011 at 7:58 AM, Alex Schuster<wonko@wonkology.org>
>>  wrote:
>>> G.Wolfe Woodbury writes:
>>>> On 12/22/2011 02:00 AM, Pintér Tibor wrote:
>>>>> Reemerge all xf86* packages
>>>>> Quite obvious as the log clearly gives the clue (new xorg server
>>>>> version, driver version mismatch)
>>>>
>>>> I looked right at it and missed the obvious!  Thanks for the
>>>> clue-by-four.
>>>
>>> BTW, emerge -a @x11-module-rebuild will do this.
>>>
>>>        Wonko
>>>
>> emerge: There are no sets to satisfy 'x11-module-rebuild'. The
>> following sets exist:
>>
>>     selected
>>     system
>>     world
>>
>
> Someone posted this one liner a while back:
>
> emerge -1a $(qlist -I -C x11-drivers/)
>
> That takes care of the video driver, mouse, keyboard and such.  Mine is
> these packages:
>
> root@fireball / # qlist -I -C x11-drivers/
> x11-drivers/nvidia-drivers
> x11-drivers/xf86-input-evdev
> x11-drivers/xf86-video-nv
> x11-drivers/xf86-video-vesa
> root@fireball / #

I wound up doing something similar, involving a mix of eix, grep and sed.

>
> I try to remember to run that when I upgrade the kernel or xorg.  I usually
> forget and have to do the SysReq keystroke magic.  After I slap my forehead
> of course.

I still don't know the SysReq magic. I've just ssh'd in. If I can't do
that, it usually means something hardlocked.

>
> There are quite a few of these commands that gets posted from time to time.
>  As a hint, I have a text file in my /root directory that contains the
> commands and a description.  I just cat and grep the file when I need to.  I
> wouldn't recommend a user directory tho.  If for someone reason only root is
> mounted, then you can get to /root but not /home if it is a separate
> partition.  You, and other Gentooers, may want to think about doing
> something like this.
>
> Hope this helps in some small way.

Funny thing is, I thought I'd taken care of it. It didn't crop up for
me until xscreensaver kicked in, which crashed X due to differeing ABI
versions between what was already running and what xscreensaver tried
to get linked in. Guess I should remember to restart X. :)

-- 
:wq

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Dale]

Michael Mol wrote:
> I still don't know the SysReq magic. I've just ssh'd in. If I can't do 
> that, it usually means something hardlocked. 

This is from a post Neil made many ages ago.  Notice the random sig too.

"Hold down Atl, hold down SysRq, press each of the keys in turn. The 
usual full sequence is R-E-I-S-U-B Reboot Even If System Utterly Broken

By ${DEITY} - this tagline picker is spooky at times :-O

-- Neil Bothwick System halted - Press all keys at once to continue." Me 
again, don't forget to include the options in the kernel config too. 
Should look like this: root@fireball / # zcat /proc/config.gz | grep -i 
sysrq CONFIG_MAGIC_SYSRQ=y root@fireball / # When it locks up to the 
point that those keys don't work, grip the plug firmly and pull. I 
usually get to about the E and sometimes the I before I find myself at a 
console. Another thing, it is best if you use that to go all the way 
down to single user mode, make sure no processes are running that 
shouldn't with top or something then go back to regular default mode. I 
say that because sometimes there is plenty of cruft left hanging around. 
It stops services but the services still have run and lock files and it 
leads to errors. You could also just reboot too.

>> There are quite a few of these commands that gets posted from time to time.
>>   As a hint, I have a text file in my /root directory that contains the
>> commands and a description.  I just cat and grep the file when I need to.  I
>> wouldn't recommend a user directory tho.  If for someone reason only root is
>> mounted, then you can get to /root but not /home if it is a separate
>> partition.  You, and other Gentooers, may want to think about doing
>> something like this.
>>
>> Hope this helps in some small way.
> Funny thing is, I thought I'd taken care of it. It didn't crop up for
> me until xscreensaver kicked in, which crashed X due to differeing ABI
> versions between what was already running and what xscreensaver tried
> to get linked in. Guess I should remember to restart X. :)
>

Yea, some updates are tricky.  A good while back, I could upgrade all of 
KDE and not logout until it is done.  Now I have to logout at least a 
couple times or things get buggy.  I guess things are pretty tight 
between programs nowadays.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 751 bytes --]

On Friday 23 Dec 2011 05:12:47 Michael Mol wrote:
> On Thu, Dec 22, 2011 at 7:58 AM, Alex Schuster <wonko@wonkology.org> wrote:
> > G.Wolfe Woodbury writes:
> >> On 12/22/2011 02:00 AM, Pintér Tibor wrote:
> >> > Reemerge all xf86* packages
> >> > Quite obvious as the log clearly gives the clue (new xorg server
> >> > version, driver version mismatch)
> >> 
> >> I looked right at it and missed the obvious!  Thanks for the
> >> clue-by-four.
> > 
> > BTW, emerge -a @x11-module-rebuild will do this.
> > 
> >        Wonko
> 
> emerge: There are no sets to satisfy 'x11-module-rebuild'. The
> following sets exist:
> 
>     selected
>     system
>     world

You need portage-2.2 to be able to use sets.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Michael Mol]

On Fri, Dec 23, 2011 at 5:38 AM, Mick <michaelkintzios@gmail.com> wrote:
> On Friday 23 Dec 2011 05:12:47 Michael Mol wrote:
>> On Thu, Dec 22, 2011 at 7:58 AM, Alex Schuster <wonko@wonkology.org> wrote:
>> > G.Wolfe Woodbury writes:
>> >> On 12/22/2011 02:00 AM, Pintér Tibor wrote:
>> >> > Reemerge all xf86* packages
>> >> > Quite obvious as the log clearly gives the clue (new xorg server
>> >> > version, driver version mismatch)
>> >>
>> >> I looked right at it and missed the obvious!  Thanks for the
>> >> clue-by-four.
>> >
>> > BTW, emerge -a @x11-module-rebuild will do this.
>> >
>> >        Wonko
>>
>> emerge: There are no sets to satisfy 'x11-module-rebuild'. The
>> following sets exist:
>>
>>     selected
>>     system
>>     world
>
> You need portage-2.2 to be able to use sets.

Sadly, 2.1.10.11 is the latest marked stable for ~amd64. (Or was, last
time I synced.)

It'll be nice when it's available, though.

-- 
:wq

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Dale]

Michael Mol wrote:
> On Fri, Dec 23, 2011 at 5:38 AM, Mick<michaelkintzios@gmail.com>  wrote:
>> You need portage-2.2 to be able to use sets.
> Sadly, 2.1.10.11 is the latest marked stable for ~amd64. (Or was, last
> time I synced.)
>
> It'll be nice when it's available, though.
>

I been using the unstable portage for a long time.  Since I built this 
rig if I recall correctly.  It works fine but it does get updated pretty 
regular.  Zac is always adding some new frills and shiney things.  ;-)  
I wouldn't blame you for staying stable but it works fine here on my 
amd64 and old x86 rig.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Michael Mol]

Dale wrote:
> Michael Mol wrote:
>> On Fri, Dec 23, 2011 at 5:38 AM, Mick<michaelkintzios@gmail.com> wrote:
>>> You need portage-2.2 to be able to use sets.
>> Sadly, 2.1.10.11 is the latest marked stable for ~amd64. (Or was, last
>> time I synced.)
>>
>> It'll be nice when it's available, though.
>>
>
> I been using the unstable portage for a long time. Since I built this
> rig if I recall correctly. It works fine but it does get updated pretty
> regular. Zac is always adding some new frills and shiney things. ;-) I
> wouldn't blame you for staying stable but it works fine here on my amd64
> and old x86 rig.

Devs don't seem to like bug reports involving mixes of stable and 
unstable. I was mildly scolded for filing a bug report against xemacs' 
failing to build with libpng15, when xemacs was stable, and libpng15 
wasn't, yet. I'm trying to being slightly more conservative about what I 
unmask.

Between autounmask and specific desires to be on top of some packages, 
it's not easy. For example, stable WINE hasn't built since February 
2011... ( https://bugs.gentoo.org/show_bug.cgi?id=354745 ) Anyone who 
needs WINE for any reason needs to use their unstable 1.3.x tree. This 
isn't expected to be fixed until this coming *March*, when ICU 49 goes 
generally available.

/rant

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Dale]

Michael Mol wrote:
> Dale wrote:
>> Michael Mol wrote:
>>> On Fri, Dec 23, 2011 at 5:38 AM, Mick<michaelkintzios@gmail.com> wrote:
>>>> You need portage-2.2 to be able to use sets.
>>> Sadly, 2.1.10.11 is the latest marked stable for ~amd64. (Or was, last
>>> time I synced.)
>>>
>>> It'll be nice when it's available, though.
>>>
>>
>> I been using the unstable portage for a long time. Since I built this
>> rig if I recall correctly. It works fine but it does get updated pretty
>> regular. Zac is always adding some new frills and shiney things. ;-) I
>> wouldn't blame you for staying stable but it works fine here on my amd64
>> and old x86 rig.
>
> Devs don't seem to like bug reports involving mixes of stable and 
> unstable. I was mildly scolded for filing a bug report against xemacs' 
> failing to build with libpng15, when xemacs was stable, and libpng15 
> wasn't, yet. I'm trying to being slightly more conservative about what 
> I unmask.
>
> Between autounmask and specific desires to be on top of some packages, 
> it's not easy. For example, stable WINE hasn't built since February 
> 2011... ( https://bugs.gentoo.org/show_bug.cgi?id=354745 ) Anyone who 
> needs WINE for any reason needs to use their unstable 1.3.x tree. This 
> isn't expected to be fixed until this coming *March*, when ICU 49 goes 
> generally available.
>
> /rant
>
>


I file bugs with the unstable portage and I don't think I've ever heard 
them complain about running unstable portage.  That said, sometimes when 
you run some software unstable and some not, then you can run into 
issues.  A while back I was trying to burn home DVDs.  I run the latest 
KDE4 but not all the way up to 9999 but unstable still.  I had to also 
install unstable for the packages that it depended on as well.  Things 
like DeVeDe and Bombono would not work well with them being unstable and 
the things under the hood running stable.  Things like this, you have to 
make choices and just sort of figure out my trial and error.  If in 
doubt, ask here first to see if a bug should be posted or not.  If 
others have ran into the same issue, then maybe it needs to be filed 
possibly upstream.

Thing is, the latest portage seems to fix things more than it breaks.  
It handles updates a lot better.  The downside, docs are not to up to 
date.  Zac manages to stay ahead of the docs at times.  I monitor -dev 
to sort of keep up.

Maybe they will mark it stable soon and you can test out all the new stuff.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Fri, 23 Dec 2011 17:17:31 -0600, Dale wrote:

> > Devs don't seem to like bug reports involving mixes of stable and 
> > unstable.

> I file bugs with the unstable portage and I don't think I've ever heard 
> them complain about running unstable portage.

It's not unstable, it's testing (or non-stable, if you prefer), bug
reports are not only welcome, they are it's purpose. The situation that
Michael referred to was running a mixture to stable and not, that is
bound to cause spurious problems.


-- 
Neil Bothwick

I am Flatulus of Borg.  You will be asphixiated.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[Stroller]

On 23 December 2011, at 14:38, Michael Mol wrote:
> ...
> Devs don't seem to like bug reports involving mixes of stable and unstable. I was mildly scolded for filing a bug report against xemacs' failing to build with libpng15, when xemacs was stable, and libpng15 wasn't, yet. I'm trying to being slightly more conservative about what I unmask.

The devs are just sometimes grumpy and, as a group, inconsistent.

Assuming there isn't already an existing bug report for that issue (just makes sure you check *thoroughly* - duplicate bug submissions is a pet peeve of mine) it's perfectly legitimate to report it. 

If you don't report it, then there'll just be a spate of users doing so when libpng15 is stabilised. 

It may very well be that libpng15 hasn't been stabilised for this very reason, but in that case there should be an existing bug so you don't waste time reporting the problem.

I report bugs all the time saying "please mark this ~x86 package as stable, works for me on an otherwise mostly stable system" and I never get any complaints. 

The sum of your experience and mine is that devs will complain about this only when it suits them. 

Gentoo devs are over-worked volunteers, so we must accept such idiosyncrasies. But please don't stop fling useful bug reports.

Stroller.


(Searching shows that your report *was* found valuable, and that your bug was set as a blocker to bug 354479 until bug 385207 was created. This is *exactly* how it should have been handled, and if you hadn't reported the issue then someone else would have had to find out the hard way. The dev's chiding was a poor choice of words -  please continue filing such useful bug reports.) 

[gentoo-user] GDM kbd/mouse lockup after emerge --update on a stable amd64 platform - need hints to cure

[G.Wolfe Woodbury]

I did:
    emerge -va --update --deep --newuse @world
on a stable gentoo amd64 (multilib) system after switching the profile
from "desktop/gnome" to "desktop" and adding
qt4 and kde flags to make.conf.  [I wan to add a few kde apps to the
mix, but not everything.]

Since then, I get a keyboard and mouse lockup when gdm starts. and can't
login graphically or switch to a text console.

I'd rather not do a complete re-install on that instance, so some clue
as to where to look for problems beyond the obvious dmesg
and boot info.

I do get a "dmeventd" failure to start, so lvm-monitoring fails to start
(even after a re-emerge of lvm2) but don't think that as anything to do
with the X lockup.  Startx from single user mode also causes a kbd/mouse
lockup.

I've verified that the kernel has the proper event configuration.
Perusing the Xorg.0.log reveals evdev failing to load:

> [   410.507] (II) LoadModule: "evdev"
> [   410.507] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
> [   410.513] (II) Module evdev: vendor="X.Org Foundation"
> [   410.513]    compiled for 1.10.4, module version = 2.6.0
> [   410.513]    Module class: X.Org XInput Driver
> [   410.513]    ABI class: X.Org XInput driver, version 12.2
> [   410.513] (EE) module ABI major version (12) doesn't match the
> server's version (13)
> [   410.513] (II) UnloadModule: "evdev"
> [   410.513] (II) Unloading evdev
> [   410.513] (EE) Failed to load module "evdev" (module requirement
> mismatch, 0)
> [   410.513] (EE) No input driver matching `evdev'
> [   410.513] (II) config/udev: Adding input device Power Button
> (/dev/input/event1)
> [   410.513] (**) Power Button: Applying InputClass "evdev keyboard
> catchall"
> [   410.513] (II) LoadModule: "evdev"
> [   410.513] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
> [   410.513] (II) Module evdev: vendor="X.Org Foundation"
> [   410.513]    compiled for 1.10.4, module version = 2.6.0
> [   410.513]    Module class: X.Org XInput Driver
> [   410.513]    ABI class: X.Org XInput driver, version 12.2
> [   410.513] (EE) module ABI major version (12) doesn't match the
> server's version (13)
> [   410.513] (II) UnloadModule: "evdev"
> [   410.513] (II) Unloading evdev
> [   410.513] (EE) Failed to load module "evdev" (module requirement
> mismatch, 0)
> [   410.513] (EE) No input driver matching `evdev'
> [   410.514] (II) config/udev: Adding input device Sleep Button
> (/dev/input/event0)
which tell me something went wrong in the re-emerge of xorg something,
but I'd like to get a clue as to just what to do to fix it.

Thanks in advance for any help.

-- 
G.Wolfe Woodbury
aka redwolfe@gmail.com