After several hours usage kybrd & mouse input fail?

No I don't want to just fix it. I want to *KNOW* the reason.

The USB-mouse and PS2-kybrd lose action. It seemed to happen often when I plugged a 1.5M USB-cable to my WiFi.

I use mostly X86:Linux:Slakware13 but some comp.sys.raspberry-pi readers are hardware knowledgable.

Probably related, is that Debian wheezy [which I seldom run] became relatedly bad: I think that was installed to boot into X; where it now gives no kybrd/mouse response. Booting via GRUB2 via goes to single-user, where keybrd & mouse DO respond [but perhaps not for extended use], but `startx` == no kybrd & mouse.

So far today Slakware13 is OK, since I use only a short USB-cable to the WIFI.

If the USB drivers fail/reset-interrupt-adr, why does the ps2-keybrd also fail?

Reply to
noSpam
Loading thread data ...

Prolly on the same interrupt controller

--
New Socialism consists essentially in being seen to have your heart in  
the right place whilst your head is in the clouds and your hand is in  
 Click to see the full signature
Reply to
The Natural Philosopher

To debug a computer that is (mostly) non-communicative, use a serial port.

My 2015 purchased desktop, has a serial port (RS232) header on the motherboard, and it is connected to the SuperI/O. I didn't even realize it had one, because there was no connector on the I/O plate. It shows up as a 2x5 connector that "looks different" than all the USB2 2x5 headers. I made an adapter cable, to be able to use it. It's a ribbon cable, and I soldered a DB-9 to one end of it.

You can define a serial console in Linux, and for the SuperI/O ones, they stay at a fixed location. Whereas, if you purchase a USB serial port, the device can end up at a different address when it is plugged in. Making configuration in advance, more difficult.

As long as a computer answers a "ping" (and you didn't turn off ICMP on purpose of course), then there is a good chance you can debug it with a serial port.

As for the path that HID input travels, you can see it's at the bottom of the diagram, and the tortured path it takes might not be documented nicely for you. So good luck with that :-) Notice that the serial console port doesn't even appear as an "item" on the diagram. I correlate kdb/mouse failure here, with "DBUS messages", but can never be sure exactly how that works, or what actually broke. But as long as your serial console continues to run, and you debug the affected box from a second working computer, you'll have much better odds of figuring it out.

formatting link

E8400 ------- RS232 @ 38.4K --------- Test Machine machine (null modem cable) (ping-able) (Debug from Kbd not working... here...)

You have to set up the serial port on the right hand machine in the diagram in advance, as the path is not enabled for you by default.

Serial ports come in two flavors. Buffered with RS232 levels. Or raw TTL. Raw TTL is used on the serial port inside a hard drive, or on the serial port inside a home router. You'd be surprised just how many serial ports are sitting there in the stuff you own. At least one famous hard drive bug, a guy figured out how to re-initialize the hard drive data structures, using a TTL level serial port connection into the drive. The language hard drives use, is obscure and not documented. So I have to assume the author of the technique, happened to have absconded with the necessary technical documents from work.

With serial port in hand, you want to check the logs, look at "dmesg" or examine whatever passes for a syslog or, whatever. Once you're in there, it's then up to your computer skillz to figure it out.

At one time, I might have advocated for inetd and telnetd, but they don't make that as easy as you might hope. That would have been my preferred (less secure) method for home debug purposes. On my crusty old Macintosh G4, enabling telnetd is a single tick box, if I want it :-) You'll not find that level of convenience, all that often...

Have fun, Paul

Reply to
Paul

The RPi default for recent SD card images is to start sshd at boot time, so if you can ping it, you can also login over SSH and debug it using command line tools.

If the computer you're sitting at runs Linux, start a terminal session and use it the login to the RPi. If its running Windows, install PuTTY, an SSH terminal for Windows, and use that to login to the RPi.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Right; so it's not about a Raspberry Pi, so please don't cross post here.

Follow-ups set.

---druck

Reply to
druck

Can't be sure about 'nix but under Windows the USB drivers sometimes have settings which allow the ports to power down after a set time. Do you have anything like that? Otherwise, if it only happens with one cable, why do you keep on using it?

Reply to
John McGaw

....

Can this have anything to do with all the RPi USB sockets being attached to a single internal hub?

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

From: The Natural Philosopher ]> If the USB drivers fail/reset-interrupt-adr, why does the ps2-keybrd ]> also fail?

]Prolly on the same interrupt controller ============= From: Paul

]To debug a computer that is (mostly) non-communicative, ]use a serial port. .... ]

formatting link
!! This is just a banner of adverts ?! ] ] E8400 ------- RS232 @ 38.4K --------- Test Machine ] machine (null modem cable) (ping-able) ] (Debug from Kbd not working... ] here...) ============= From: Martin Gregorie

] If the computer you're sitting at runs Linux, start a terminal session ] and use it the login to the RPi. ........... Linux:mc connected to: sh:pi@192.168.0.2/home/pi where I can navigate the dir-tree and read files but NOT write nor execute.

How would I use the already installed/confirmed software of RPi, to connect the X86:Linux to the WiFi via RPi, to avoid the suspected X86-USB-to-WiFi connection? Or ..... Which of these is correct? X86->-eth0->-RPi->-pppd->-WiFi- X86->-pppd->-eth0->-RPi->-WiFi-

Would this do it: set up RPi to ssh: view the problematic X86:linux's files [mc is convenient]; and when X86's kybrd & mouse freeze, read & save X86's & /var/log/messages?

Are there other files which may give debugg>

No the problem is the X86, not the rPi. ================= On 2/3/2016 11:04 AM, snipped-for-privacy@gmail.com wrote: ]Can't be sure about 'nix but under Windows the USB drivers sometimes have ]settings which allow the ports to power down after a set time. Do you have ]anything like that? Otherwise, if it only happens with one cable, why do ]you keep on using it?

I moved the WiFi-thing, to be able to use a short cable; and it *seems* better. I'm starting to suspect some marginal hardware cause, possibly related to the varying . ================= Even if/when I get the absurdly annoying ssh to read the X86 from RPi, what would I look at ? top = needs run pemission, mem / free = also...?

See messages just prior to crash [when plugging Neotel]:-- => /var/log/messages

Feb 14 10:58:45 darkstar -- MARK -- Feb 14 11:18:45 darkstar -- MARK -- Feb 14 11:34:24 darkstar kernel: usbcore: deregistering interface driver usbserial_generic Feb 14 11:34:24 darkstar kernel: USB Serial deregistering driver generic Feb 14 11:34:24 darkstar kernel: usbcore: deregistering interface driver usbserial Feb 14 11:34:35 darkstar kernel: usbcore: registered new interface driver usbserial Feb 14 11:34:35 darkstar kernel: USB Serial support registered for generic Feb 14 11:34:35 darkstar kernel: usbcore: registered new interface driver usbserial_generic Feb 14 11:34:35 darkstar kernel: usbserial: USB Serial Driver core Feb 14 11:35:35 darkstar kernel: usb 2-1: new full speed USB device using ohci_hcd and address 18 Feb 14 11:35:36 darkstar kernel: usb 2-1: new full speed USB device using ohci_hcd and address 19 Feb 14 11:35:36 darkstar kernel: usb 2-1: New USB device found, idVendor=1d09, idProduct=4000 Feb 14 11:35:36 darkstar kernel: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Feb 14 11:35:36 darkstar kernel: usb 2-1: Product: Dupont CDMA Technologies MSM Feb 14 11:35:36 darkstar kernel: usb 2-1: Manufacturer: Dupont, Incorporated Feb 14 11:35:36 darkstar kernel: usb 2-1: configuration #1 chosen from 1 choice Feb 14 11:35:36 darkstar kernel: usbserial_generic 2-1:1.0: generic converter detected Feb 14 11:35:36 darkstar kernel: usb 2-1: generic converter now attached to ttyUSB0 Feb 14 11:35:36 darkstar kernel: usbserial_generic 2-1:1.1: generic converter detected Feb 14 11:35:36 darkstar kernel: usb 2-1: generic converter now attached to ttyUSB1

Reply to
noSpam

It's not a banner of adverts. It's a stick and ball model, without the sticks. Using just four of the acronyms from that useless picture, I can find this in a search engine...

The article on Wayland, provides a portion showing how input bubbles up through the model. So "evdev" is above the keyboard. However, your platform might not be using Wayland, and you'd have to find the equivalent of "libinput" on yours to understand it.

formatting link

In all the years I've been studying this sort of thing, I have *never* seen anyone attempt to write a single article that covers, in scrupulous detail, how input gets all the way to the top. It's one of my pet peeves, that such an article does not exist. I've already wasted a lot of time in the past looking for it. The diagrams above, are about the best I can do for you, in giving some leads.

*******

As for the rest of your post, is is possible the "modprobe -r usbserial" is removing an existing connection ? Like, some other bit of hardware that also happens to be connected via usbserial. Perhaps that script is overly aggressive (didn't do enough conditional checks).

Paul

Reply to
Paul

] If the computer you're sitting at runs Linux, start a terminal session ] and use it the login to the RPi. ...........

The RPi must examine the X86, after the X86 loses Input: Kybrd & mouse.

----------- This is the annoying crap, that rPi shows: as seen by :--

File: RPidebugMOBO Line 1 Col 1 == => /home/pi/MOBO/RPidebugMOBO

2016 Feb ! MOBO hangs with kybrd & Mouse fail; mostly after Neotel is plugged Try Rpi do: top, mem, free ...? ==> MOBO can *read* here

-> $ ssh root@192.168.0.1 ls == @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is b5:90:75:12:d6:0d:5e:cb:76:29:dc:01:d2:a7:6f:89. Please contact your system administrator. Add correct host key in /home/pi/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/pi/.ssh/known_hosts:2 RSA host key for 192.168.0.1 has changed and you have requested strict checking. Host key verification failed.

==> Try repeat previous log OK:

-> ssh root@192.168.0.1 /root/FC1LNO ==

Reply to
noSpam

snipped-for-privacy@gmail.com wrote: - - -

!! Good thinking. I modified that now. It seems more reliable. Shorter USB-cable 'seemed' to be more reliable too. It's as if the hardware is at some threshold, so that slight variations [eg. in mains voltage] cause problems. It's very frustrating to use dumb/substitution debugging, rather than: think, measure, conclude.

Reply to
noSpam

Power distribution is a frequent problem with USB. One reason is that most USB cables do not meet the USB specifications, so their resistance is too high and the voltage delivered to the destination is too low for reliable operation.

Conversely, regulation in the power supplies means that mains voltage variation is very, very unlikely to cause a problem.

Dave

Reply to
Dave Higton

Yes, but perhaps the PSU is not per spec., -- marginal. Since the reliability seems to change from day to day, I'm suspecting a change in the environment. Like or electric mains condition.

Reply to
noSpam

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.