Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-18 Thread netfab
Le 17/08/15 à 21:13, Michel Catudal a tapoté :
 drivers/char/sunxi_mem/sunxi_physmem.c:22:27: erreur fatale:
 mach/includes.h : Aucun fichier ou dossier de ce type

I guess you should disable CONFIG_SUNXI_PHYS_MEM_ALLOCATOR since
anyway, this option is not available into official linux-sunxi-3.4.103,
it has been added by one armbian patch, and this driver seems broken
for your platform.



Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-18 Thread Heiko Baums
Am 18.08.2015 um 04:04 schrieb walt:
 I see the keyboard problem in mate and xfce4 (the only ones I use
 now).  I've wondered about the same things but I don't know how to
 debug those possible scenarios.

And which terminal emulator are you using?

 At the moment I'm waiting for my new keyboard to arrive from amazon,
 hoping to pin the blame on flakey hardware instead of flakey software.

Somehow I doubt that it's the keyboard. I rather guess it's either a
wrong configuration of or a bug in the desktop environment, the terminal
emulator and/or systemd/udev.



Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-17 Thread Michel Catudal

Le 2015-08-17 03:17, netfab a écrit :

Le 16/08/15 à 19:27, Michel Catudal a tapoté :

the latest kernel from sunxi that supports the mali GPU (3.4.103) for
my old Mele A2000G

[offtopic]

Latest up to date (3.4.108) can be found here [1].
It also embeds patchs and fixs from armbian [2].

¹. https://github.com/dan-and/linux-sunxi
². http://forum.armbian.com/

[/offtopic]



michel linux-sunxi # make
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
make[1]: « include/generated/mach-types.h » est à jour.
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC  drivers/char/sunxi_mem/sunxi_physmem.o
drivers/char/sunxi_mem/sunxi_physmem.c:22:27: erreur fatale: mach/includes.h : 
Aucun fichier ou dossier de ce type
 #include mach/includes.h
   ^
compilation terminée.
scripts/Makefile.build:307 : la recette pour la cible « 
drivers/char/sunxi_mem/sunxi_physmem.o » a échouée
make[3]: *** [drivers/char/sunxi_mem/sunxi_physmem.o] Erreur 1
scripts/Makefile.build:443 : la recette pour la cible « drivers/char/sunxi_mem 
» a échouée
make[2]: *** [drivers/char/sunxi_mem] Erreur 2
scripts/Makefile.build:443 : la recette pour la cible « drivers/char » a échouée
make[1]: *** [drivers/char] Erreur 2
Makefile:947 : la recette pour la cible « drivers » a échouée
make: *** [drivers] Erreur 2


--
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/




Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-17 Thread mcatudal


- Mail original -

Le 16/08/15 à 19:27, Michel Catudal a tapoté : 
 the latest kernel from sunxi that supports the mali GPU (3.4.103) for 
 my old Mele A2000G 

[offtopic] 

Latest up to date (3.4.108) can be found here [1]. 
It also embeds patchs and fixs from armbian [2]. 

¹. https://github.com/dan-and/linux-sunxi 
². http://forum.armbian.com/ 

[/offtopic] 

 

resp: 

I don't think it would be off topic since the message is about keyboard that 
stops working, which happened with that kernel as well. 

[offtopic] 

How do you bottom post with comcast webmail? I only see the Microsoft exploder 
way which is only top post. 

[/offtopic] 




Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-17 Thread netfab
Le 16/08/15 à 19:27, Michel Catudal a tapoté :
 the latest kernel from sunxi that supports the mali GPU (3.4.103) for
 my old Mele A2000G

[offtopic]

Latest up to date (3.4.108) can be found here [1].
It also embeds patchs and fixs from armbian [2].

¹. https://github.com/dan-and/linux-sunxi
². http://forum.armbian.com/

[/offtopic]



Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-16 Thread Michel Catudal

Le 2015-08-16 17:07, walt a écrit :

On Sun, 16 Aug 2015 21:48:04 +0200
Alan McKinnon alan.mckin...@gmail.com wrote:


On 16/08/2015 21:42, walt wrote:

On Sun, 16 Aug 2015 18:58:27 +0200
Alan McKinnon alan.mckin...@gmail.com wrote:
   

On 16/08/2015 18:45, walt wrote:

I've been seeing this keyboard problem for the past few weeks:
after running some command from a bash prompt (haven't tried zsh
yet) the keyboard stops working.  Almost like somebody unplugged
the keyboard from its usb port (except that the LED on the
keyboard stays lit so I know the power is still on).

There are no error messages in journalctl or
in /var/log/Xorg.0.log

I don't know how to change to a console without using a
ctrl-alt-Fn keystroke from the keyboard (anyone know if it's
possible?).

When I unplug the keyboard from the usb port I can see the kernel
recognize the unplug event, which makes me think that it's not a
kernel/usb bug or a broken wire in the keyboard cable.

When I re-plug the keyboard into a usb port the keyboard
immediately starts working normally again until the next time I
happen to trigger the problem by running some black-magical
command from a command prompt.  There is no particular command
that causes it--it can be any arbitrary command AFAICT.

Just one weird example:  I can be typing a URL in a web browser
window when a bash command finishes running in a terminal window
and the keyboard stops working in the middle of my typing :(

Any debugging suggestions would be most welcome.


First step (more to half the problem space than anything else):

Does the same happen if you use another keyboard?

I agree with your assessment -- and I will buy another usb keyboard
tomorrow because I'm using the only one I have and this machine has
no ps/2 ports.  Never thought I'd miss the ps/2 ports til now :)

I kind of assumed you'd have lots of spare keyboards lying around and
had already done the test :-)

I do have spares, all ps/2 :-(


I recall something similar happening to me,
perhaps a year ago or longer. I tried to debug it and gave up, then
one day it was no longer happening. I assumed it was a fixed kernel
bug then promptly forgot all about it.

While you are waiting on a new keyboard, do you have the same bug on
different kernels?

Affirmative, and thereby hangs yet another woeful tale.  I've been
running the gentoo-sources-3.14.xx series forever because I wearied of
spending so many hours debugging unstable kernels.

This morning I decided to take a giant leap forward all the way to
3.18.19 (BTW 3.18.20 is already on kernel.org) because, surely, I
wouldn't need to debug a kernel as old as that, right?

Wrong.  Linus and friends have been marking lots of existing kernel
symbols with the SYMBOL_EXPORT_GNU macro, which was designed to block
the loading of any kernel module not explicitly licensed as GNU
software.  (see output of modinfo)

x11-drivers/ati-drivers installs a proprietary binary blob (as does
nvidia-drivers) so the linker refused even to link the kernel module
into a .ko file, nevermind the kernel actually loading the module at
runtime.

The remedy for ati-drivers is well-hidden in a comment in a gentoo bug
report that I found at oh-dark-hundred hours this morning.  Only two
hours later I got the module installed and loaded :)

But yes, kernel 3.18.19 still has my same keyboard halting problem, so
I'm back to 3.14.50 until the ati-drivers package is patched.  I'm sure
gentoo-sources-3.18.20 will be available almost immediately and I'm not
going through that hell again.



I am running Kernel 4.0.5 with no problem with the keyboards. I did encounter one issue, I purchased a French Canadian keyboard off ebay, turned out that the computer box had to be close to the mouse/keyboard otherwise I either lost signal or it was very 
slow. It seemed that when I would connect and reconnect it would work correctly again. That mouse/keyboard combo was from HP.


Is your issue with Logitech remote mouse/keyboard? If so you may want to read 
about my experience on the subject.

I had an issue with Debian on an Olimex A20 Arm board, no issue with ArchLinux on the same board with the same kernel. I found out that the difference was some special options for HID support for Logitech that were disabled by default. Archlinux noticed 
but not debian, in the debian world they must think that nobody uses logitech devices.


This morning I downloaded the latest kernel from sunxi that supports the mali GPU (3.4.103) for my old Mele A2000G, I wanted to upgrade it to Gentoo from SuSE. Someone seemed to have backport the debian bug into it as my logitech keyboard didn't work. 
After I enabled the HID special support for Logitech, both mouse and keyboard now work perfectly.



Michel

--
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/




Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-16 Thread Michel Catudal

Le 2015-08-16 21:43, walt a écrit :

On Sun, 16 Aug 2015 19:27:41 -0400
Michel Catudal mcatu...@comcast.net wrote:


But yes, kernel 3.18.19 still has my same keyboard halting problem,
so I'm back to 3.14.50 until the ati-drivers package is patched.
I'm sure gentoo-sources-3.18.20 will be available almost
immediately and I'm not going through that hell again.


  

I am running Kernel 4.0.5 with no problem with the keyboards.

Okay, thanks, that's good to know.

I'm aware that I'm mixing posts about video drivers in the same thread
(that I started) about keyboard problems, but that's no accident:  both
topics involve kernel device drivers *and* differences between kernel
versions.  I think the two apparently different problems are related.

snipped for brevity


Someone seemed to have backport the debian bug
into it as my logitech keyboard didn't work.

Yes, I wonder if some of the problems I'm having are caused by the
patches to gentoo-sources and/or ati-drivers that were committed by our
gentoo devs, or are my problems coming from upstream?  I have no idea.


A patch for bugs should be checked so it doesn't create other bugs. When they 
tried to fix a problem with some keyboards they destroyed the support for 
Logitech keyboards.
I have several remote keyboards and I find them to be the ones that works the 
best.

This may not be the only part that is problematic right now in the latest 
updates in Gentoo.
Handbrake for instance no longer works. To get it to work I had to install the 
latest x264 (not the latest one from gentoo which doesn't work either)
In the process I also upgraded Handbrake to 0.10.2 which works on ArchLinux, I 
think that x264 might probably have been good enough. The  version didn't 
even compile, likely due to some gentoo patches.


After I enabled the HID
special support for Logitech, both mouse and keyboard now work
perfectly.

Heh.  I just ordered a replacement Logitech USB keyboard from
amazon.com.  I picked the Logitech because it was from a company
(Logitech) whose name I recognize, as opposed to the other keyboards
that amazon offers under its own brand.

If my new Logitech keyboard fails to work correctly I will try enabling
the special HID support in whatever kernel(s) I'm using at the moment.
(Three days from now...who knows?)






--
For Linux Software visit
http://home.comcast.net/~mcatudal
http://sourceforge.net/projects/suzielinux/




Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-16 Thread Dale
walt wrote:
 Affirmative, and thereby hangs yet another woeful tale. I've been
 running the gentoo-sources-3.14.xx series forever because I wearied of
 spending so many hours debugging unstable kernels. This morning I
 decided to take a giant leap forward all the way to 3.18.19 (BTW
 3.18.20 is already on kernel.org) because, surely, I wouldn't need to
 debug a kernel as old as that, right? Wrong. Linus and friends have
 been marking lots of existing kernel symbols with the
 SYMBOL_EXPORT_GNU macro, which was designed to block the loading of
 any kernel module not explicitly licensed as GNU software. (see output
 of modinfo) x11-drivers/ati-drivers installs a proprietary binary blob
 (as does nvidia-drivers) so the linker refused even to link the kernel
 module into a .ko file, nevermind the kernel actually loading the
 module at runtime. The remedy for ati-drivers is well-hidden in a
 comment in a gentoo bug report that I found at oh-dark-hundred hours
 this morning. Only two hours later I got the module installed and
 loaded :) But yes, kernel 3.18.19 still has my same keyboard halting
 problem, so I'm back to 3.14.50 until the ati-drivers package is
 patched. I'm sure gentoo-sources-3.18.20 will be available almost
 immediately and I'm not going through that hell again. 


Interesting info.  I haven't been able to get new kernels to work
either.  I wonder if this is why.  o_O

Dale

:-)  :-) 



Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-16 Thread Alan McKinnon
On 16/08/2015 21:42, walt wrote:
 On Sun, 16 Aug 2015 18:58:27 +0200
 Alan McKinnon alan.mckin...@gmail.com wrote:
 
 On 16/08/2015 18:45, walt wrote:
 I've been seeing this keyboard problem for the past few weeks:
 after running some command from a bash prompt (haven't tried zsh
 yet) the keyboard stops working.  Almost like somebody unplugged
 the keyboard from its usb port (except that the LED on the keyboard
 stays lit so I know the power is still on).

 There are no error messages in journalctl or in /var/log/Xorg.0.log

 I don't know how to change to a console without using a ctrl-alt-Fn
 keystroke from the keyboard (anyone know if it's possible?).

 When I unplug the keyboard from the usb port I can see the kernel
 recognize the unplug event, which makes me think that it's not a
 kernel/usb bug or a broken wire in the keyboard cable.

 When I re-plug the keyboard into a usb port the keyboard immediately
 starts working normally again until the next time I happen to
 trigger the problem by running some black-magical command from a
 command prompt.  There is no particular command that causes it--it
 can be any arbitrary command AFAICT.

 Just one weird example:  I can be typing a URL in a web browser
 window when a bash command finishes running in a terminal window
 and the keyboard stops working in the middle of my typing :(

 Any debugging suggestions would be most welcome.  


 First step (more to half the problem space than anything else):

 Does the same happen if you use another keyboard?
 
 I agree with your assessment -- and I will buy another usb keyboard
 tomorrow because I'm using the only one I have and this machine has no
 ps/2 ports.  Never thought I'd miss the ps/2 ports til now :)

I kind of assumed you'd have lots of spare keyboards lying around and
had already done the test :-)

I myself have 4 spares lying around my home study, all functional, and
I'm totally at a loss to explain why so many!

Anyway, back on topic. I recall something similar happening to me,
perhaps a year ago or longer. I tried to debug it and gave up, then one
day it was no longer happening. I assumed it was a fixed kernel bug then
promptly forgot all about it.

While you are waiting on a new keyboard, do you have the same bug on
different kernels?


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Re: [~amd64] Keyboard stops working several times/day

2015-08-16 Thread Dale
walt wrote:
 On Sun, 16 Aug 2015 16:34:08 -0500
 Dale rdalek1...@gmail.com wrote:

 walt wrote:
 Affirmative, and thereby hangs yet another woeful tale. I've been
 running the gentoo-sources-3.14.xx series forever because I wearied
 of spending so many hours debugging unstable kernels. This morning I
 decided to take a giant leap forward all the way to 3.18.19 (BTW
 3.18.20 is already on kernel.org) because, surely, I wouldn't need
 to debug a kernel as old as that, right? Wrong. Linus and friends
 have been marking lots of existing kernel symbols with the
 SYMBOL_EXPORT_GPL macro, which was designed to block the loading of
 any kernel module not explicitly licensed as GPL software. (see
 output of modinfo) x11-drivers/ati-drivers installs a proprietary
 binary blob (as does nvidia-drivers) so the linker refused even to
 link the kernel module into a .ko file, nevermind the kernel
 actually loading the module at runtime. The remedy for ati-drivers
 is well-hidden in a comment in a gentoo bug report that I found at
 oh-dark-hundred hours this morning. Only two hours later I got the
 module installed and loaded :) But yes, kernel 3.18.19 still has my
 same keyboard halting problem, so I'm back to 3.14.50 until the
 ati-drivers package is patched. I'm sure gentoo-sources-3.18.20
 will be available almost immediately and I'm not going through that
 hell again.   

 Interesting info.  I haven't been able to get new kernels to work
 either.  I wonder if this is why.  o_O
 I've skimmed some of your threads involving initrd (maybe raid?) but I
 don't participate in them because I don't use either initrd or raid so
 I have nothing to offer.

 If your problems are caused by non-loading kernel modules, though, it
 should be easy to find out by running modinfo -l on each kernel module.

 Here is the cause of my problem this morning:

 #modinfo -l /lib/modules/3.18.19-gentoo/video/fglrx.ko 
 Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY

 BTW, I post-edited a typo I made in the text you quoted:  I typed
 SYMBOL_EXPORT_GNU when I really meant SYMBOL_EXPORT_GPL.  I could have
 typed SYMBOL_EXPORT_RMS because I conflate the three into one synonym :)






No RAID here, although it would likely be a good idea.  I just have /usr
on a separate partition. 

I build my kernels with everything built in.  The only module I have is
Nvidia but that is one thing that doesn't work at times.  Sometimes, it
doesn't want to boot all the way.  It doesn't even get through the
kernel loading everything up at times. 

I need to work on this some time soon.  Problem is, I rarely reboot. 
Generally, power failure is about all that will get me to
shutdown/reboot.  Recently tho, lightening has done the job.  My
neighbor got hit last week.  Their DSL went out, blew up a outside wall
plug and took out my land line, tho I rarely use it either.   They live
a quarter mile away but it sure was loud.  I'm surprised that side of
the house still had windows.  Anyway, maybe I will get around to it one
of these days.  At least 3.18.7 is working OK. 

Dale

:-)  :-)