I have written a small program which generates 4 Audio Streams (sine waves) and sends them to 4 sound cards (each one connected to a USB port of the raspberry pi 3).
After a few seconds the pi completely freezes/crashes. I have to reboot the Raspberry Pi.
With just 3 Audio Streams (and 3 USB sound cards), everything works as expected.
The CPU load is actually ok (monitored with htop). The 4 CPUs are at about 30%.
However before crashing I can find the following entries in syslog:
Oct 11 18:48:13 pi kernel: [ 51.983775] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=6 fsm=8 on transfer to device 4 ep 0x4
Oct 11 18:48:14 pi kernel: [ 52.415833] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=2 fsm=9 on transfer to device 7 ep 0x1
Oct 11 18:48:14 pi kernel: [ 52.991916] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=3 fsm=9 on transfer to device 4 ep 0x4
Oct 11 18:48:14 pi kernel: [ 53.135930] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=2 fsm=9 on transfer to device 4 ep 0x4
Oct 11 18:48:15 pi kernel: [ 53.268195] Transfer to device 4 endpoint 0x4 frame 1995 failed - FIQ reported NYET. Data may have been lost.
Oct 11 18:48:15 pi kernel: [ 53.423974] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=3 fsm=9 on transfer to device 7 ep 0x1
Oct 11 18:48:15 pi kernel: [ 53.567994] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=3 fsm=9 on transfer to device 4 ep 0x4
Oct 11 18:48:15 pi kernel: [ 53.712005] WARN::dwc_otg_hcd_handle_hc_fsm:2619: Unexpected state received on hc=3 fsm=9 on transfer to device 7 ep 0x1
I suspect that there is some problem with the USB.
Are there any tools which could help me to monitor the USB ports? e.g. Buffers, Lost packets,...etc
What's the meaning of the syslog messages?
Any hints appreciated!
Related
I bought a RFlink Gateway from Nodo-shop.nl, the the RFLink 433.42 Somfy RTS version, to use with Domoticz on a RPI. I had Nodo to solder the components of my Rflink, so there should not be any problem on this end :)
I connected it to my MacbookAir, and followed the instructions on Domoticz wiki to upload the firmware into the RFlink. It apparently uploaded the firmware successfully.
Then I updated and upgraded my RPI (Linux raspberrypi 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux) and hooked it up to my Raspberry Pi 3 .
I tried to identify the port with Dmesg. If the Arduino Mega is detected, I cannot see the ttyAMCO or ttyUSB everyone is referring to in various posts.
Here is the output of the dmesg command:
[3902580.423329] usb 1-1.1.2: new full-speed USB device number 9 using dwc_otg [3902580.568650] usb 1-1.1.2: New USB device found, idVendor=2341, idProduct=0042, bcdDevice= 0.01 [3902580.568671] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=220 [3902580.568685] usb 1-1.1.2: Manufacturer: Arduino (www.arduino.cc) [3902580.568699] usb 1-1.1.2: SerialNumber: 55037313237351714260
I also tried to look for the port using this command ls /dev | grep tty*. I can only see these ports : ttyXX, ttyAMA0 and ttyprintk. But no sign of the port of my RFlink Gateway.
When I use this command lsusb, it shows it recognizes the Arduino:
Bus 001 Device 009: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM).
I read tons of posts on the internet but I did not find any answer to my problem.
I even bought a power supply for my Arduino Mega as some wrote that it may not get enough power from the RPI's USB. But I still have the same problem...
What I'm not doing right ? Or what am I not looking at ?
Thank you for your help
Sorry, bit late but it might be useful to someone else...
It might well be the /dev/ttyAMA0 you found - it depends what else you've got on there.
listing by id should identify it definitively though:
$ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Mar 18 2021 usb-0658_0200_12345678-9012-3456-7890-123456789012-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Mar 18 2021 usb-Arduino__www.arduino.cc__0042_55639313533351509150-if00 -> ../../ttyACM0
So, in my case it's on /dev/ttyACM0.
If you've got multiple USB serial adapters, reboot the pi with them all plugged in to get the default mapping (I've seen hotplugged AMA0 and AMA1 swap after a reboot).
The connection to a Bluetooth device via RFCOMM fails on Linux/Bluez with Connection refused at the call of
connect(s, (struct sockaddr *)&addr, sizeof(addr));.
The device was successfully paired. An RFCOMM connection to that device from Android or Windows can be successfully established, so the problem seems to be locaed with Bluez diver and/or blueotoothd.
With Linux/Bluez the bluetoothctl and Wireshark traces show that it fist connects and then after about 2 seconds a disconnection is done. The reason for the disconnection is not clear.
The same problem happens with different Linux releases, on PC with USB Bluetooth (Linux ubuntu 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux) or Raspberry Pi 3 (Jessie, Stretch).
I have checked numerous other thread having the same/similar problem. Most have no or no clear answer.
The Wireshark trace screenshot shows the disconnect after 2.2 seconds.
The corresponding bluetoothd syslog output:
Aug 31 16:43:54 ubuntu bluetoothd[926]: src/adapter.c:connected_callback() hci0 device F6:65:0A:E5:DE:E1 connected eir_len 22
Aug 31 16:43:54 ubuntu bluetoothd[926]: src/device.c:device_create() dst F6:65:0A:E5:DE:E1
Aug 31 16:43:54 ubuntu bluetoothd[926]: src/device.c:device_new() address F6:65:0A:E5:DE:E1
Aug 31 16:43:55 ubuntu bluetoothd[926]: src/device.c:device_new() Creating device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:dev_disconnected() Device F6:65:0A:E5:DE:E1 disconnected, reason 3
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:adapter_remove_connection()
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:adapter_remove_connection() Removing temporary device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/device.c:device_remove() Removing device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/device.c:btd_device_unref() Freeing device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/device.c:device_free() 0x563aa2a270a0
Aug 31 16:43:57 ubuntu bluetoothd[926]: plugins/policy.c:disconnect_cb() reason 3
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr F6:65:0A:E5:DE:E1 type 0 status 0xe
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:resume_discovery()
reason 3 points to MGMT_DEV_DISCONN_REMOTE in include/net/bluetooth/mgmt.h of the kernel sources. This would mean that it is the device who initiates the disconnect. But the highlighted line in the Wireshark trace shows that it is the host that initiates the disconnection.
Many thanks for any help in advance.
The incorrect RFCOMM channel was used. It instantly works when the correct RFCOMM channel is used.
sdptool records F6:65:0A:E5:DE:E1 shows on which channel the RFCOMM is:
Service Name: Serial Port
Service RecHandle: 0x10000
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 5
when i run yum command：
> yum
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/usr/lib64/python2.6/lib-dynload/arraymodule.so: cannot read file data: Input/output error
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.6 (r266:84292, Jul 23 2015, 15:22:56)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)]
Current version of Python is 2.6.6，not other。
system logs:
Oct 16 09:56:50 localhost kernel: mptbase: ioc0: LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Oct 16 09:56:50 localhost kernel: LSI Debug log info 31080000 for channel 0 id 0
Oct 16 09:56:50 localhost kernel: mptbase: ioc0: LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Oct 16 09:56:50 localhost kernel: LSI Debug log info 31080000 for channel 0 id 0
Oct 16 09:56:50 localhost kernel: sd 6:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 16 09:56:50 localhost kernel: sd 6:0:0:0: [sda] Sense Key : Medium Error [current]
Oct 16 09:56:50 localhost kernel: Info fld=0x4d59fc8
Oct 16 09:56:50 localhost kernel: sd 6:0:0:0: [sda] Add. Sense: Unrecovered read error
Oct 16 09:56:50 localhost kernel: sd 6:0:0:0: [sda] CDB: Read(10): 28 00 04 d5 9f c8 00 00 08 00
Oct 16 09:56:50 localhost kernel: end_request: critical medium error, dev sda, sector 81108936
Who know how to fix? Thank you!
Input/output error indicates that you system cannot read the file. Your log indicates that the hard drive is failing. Reinstall yum through RPM if you must, but ultimately backup your critical data and salvage the storage array.
I have an embedded computer that is running Linux 3.4, and there is not a way for me to upgrade to 4.x.y at the moment unfortunately.
I have compiled g_ether as a kernel module using the following configuration options:
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
The module compiles fine and I can load it once the system has booted with no issues:
[ 7.160000] DWC_otg: dwc_udc_start: g_ether
[ 7.168000] DWC_otg: bind to driver g_ether
[ 7.176000] DWC_otg: dwc_otg_pcd_alloc_request(e30171a4,208)
[ 7.184000] g_ether gadget: using random self ethernet address
[ 7.196000] usb0: MAC 52:e9:07:c2:0f:23
[ 7.204000] usb0: HOST MAC 82:cf:ce:fa:44:18
[ 7.212000] rndis_bind
[ 7.224000] DWC_otg: dwc_otg_pcd_alloc_request(e30171ec,208)
[ 7.232000] rndis_register: configNr = 0
[ 7.236000] rndis_set_param_medium: 0 0
[ 7.244000] DWC_otg: dwc_otg_pcd_alloc_request(e30171ec,208)
[ 7.252000] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[ 7.264000] g_ether gadget: g_ether ready
[ 7.268000] DWC_otg: dwc_udc_start: registered gadget driver 'g_ether'
My goal is to connect this embedded computer to a Windows computer. When I connect the embedded computer, Windows initially shows the "device" in the Device Manager as working properly and then updates to show that it is not working with the error:
This device cannot start. (Code 10)
FWIW I have tried several different drivers on the Windows side, including the linux.inf referenced in the Linux USG Gadget documentation, several of the built-in drivers, and one driver I found on a forum.
From the Linux side, when I plug in the USB cord, I see the following output:
Aug 29 05:13:54 dot-8f2wktlxah kernel: [ 31.840000] g_ether gadget: init rndis
Aug 29 05:13:54 dot-8f2wktlxah kernel: [ 31.840000] g_ether gadget: RNDIS RX/TX early activation ...
Aug 29 05:13:54 dot-8f2wktlxah kernel: [ 32.116000] usb0: qlen 10
Aug 29 05:13:56 dot-8f2wktlxah kernel: [ 34.128000] g_ether gadget: rndis req21.00 v0000 i0000 l24
Aug 29 05:13:56 dot-8f2wktlxah kernel: [ 34.540000] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096
This corresponds on the Windows side (via USBPcap):
1226 29734.081932 host 2.1.0 USBCOM 36 SEND ENCAPSULATED COMMAND Request
1227 29735.362932 2.1.0 host USBCOM 52 SEND ENCAPSULATED COMMAND Response
1228 29735.362932 2.1.0 host USB 28 GET STATUS Status
1229 29735.810932 2.1.2 host USBCOM 35 NETWORK CONNECTION
1230 29735.810932 host 2.1.0 USBCOM 36 GET ENCAPSULATED RESPONSE Request
The rndis req21 on the Linux side corresponds to the SEND ENCAPSULATED COMMAND on the Windows side, and the same is true for the rndis reqa1 and GET ENCAPSULATED RESPONSE.
There is no other output on either after those last response/requests.
I understand that Linux 3.4 is very out of date, but I don't have the option to upgrade since this is an embedded computer and thus I am beholden to the chip-maker to provide an update.
Has anyone successfully used the g_ether kernel module with Windows 7/8 and Linux 3.4, or know why these request/responses seem to just stop after that last GET ENCAPSULATED RESPONSE?
I am trying to embed tslib on an ARM system, in order to use a touchscreen device ; I already installed it successfully but unfortunately I can't retrieve all my notes to do it again. x)
I cross-compiled the libraries files, and I put them into /usr/lib ; I have created the conf file /etc/ts.conf and I have exported the good environment variables :
export TSLIB_TSDEVICE="/dev/event2"
export TSLIB_CONFFILE="/etc/ts.conf"
Here is my problem : tslib doesn't seem to create the event device when I plug the device in. And here is the result of *ts_calibrate* : ts_open: No such file or directory
I think it tries to open /dev/event2 which doesn't exist because it has not been created by tslib.
Any ideas ?
Thanks
What kind of kernel + userspace do you have ? device file creation is usually
the job of kernel hotplug + udev or mdev.
In any case, tslib is not supposed to create device file. You have two options :
creating the device manually, provided your busybox contains the mknod utility :
mknod event2 c 13 66
where 66 is the minor number, it should be one more than the minor number for event1.
launching mdev -s and see if the content of your /dev directory change
find out why the vent device is not detected / created : please post the output of uname -a, and dmesg after boot.
Do you need to mknod the /dev/event2 yourself? Are you positive your library makes the device node?
Actually mknod is not available on our busybox. Nothing changed when launching mdev -s, I already tryed that. :/
Here is the result of uname : Linux MYNAME 2.6.24.4 #3 Fri Dec 2 16:54:41 CET 2011 armv4l unknown (MYNAME is just the system name, I replaced it for privacy reason ;) )
And dmesg :
<6>usb 1-1.3: new high speed USB device using str8100-ehci and address 23
<6>usb 1-1.3: configuration #1 chosen from 1 choice
<6>hub 1-1.3:1.0: USB hub found
<6>hub 1-1.3:1.0: 4 ports detected
<6>usb 1-1.3.2: new high speed USB device using str8100-ehci and address 24
<6>usb 1-1.3.2: configuration #1 chosen from 1 choice
<6>udlfb: DisplayLink AT-7 - serial #200694
<6>udlfb: vid_17e9&pid_02fc&rev_0104 driver's dlfb_data struct at c1031000
<6>udlfb: console enable=0
<6>udlfb: fb_defio enable=0
<6>udlfb: vendor descriptor length:23 data:23 5f 01 0021 00 04 04 07 00 01
<4>udlfb: DL chip limited to 1500000 pixel modes
<4>dlfb_alloc_urb_list
<4>dlfb_release_urb_work : INIT_DELAYED_WORK dlfb_release_urb_work
<4>dlfb_release_urb_work : after INIT_DELAYED_WORK
<4>usb_fill_bulk_urb
<4>usb_fill_bulk_urb end
<4>dlfb_release_urb_work : INIT_DELAYED_WORK dlfb_release_urb_work
<4>dlfb_release_urb_work : after INIT_DELAYED_WORK
<4>usb_fill_bulk_urb
<4>usb_fill_bulk_urb end
<4>dlfb_release_urb_work : INIT_DELAYED_WORK dlfb_release_urb_work
<4>dlfb_release_urb_work : after INIT_DELAYED_WORK
<4>usb_fill_bulk_urb
<4>usb_fill_bulk_urb end
<4>dlfb_release_urb_work : INIT_DELAYED_WORK dlfb_release_urb_work
<4>dlfb_release_urb_work : after INIT_DELAYED_WORK
<4>usb_fill_bulk_urb
<4>usb_fill_bulk_urb end
<4>dlb_alloc_urb_list : before sema_init
<4>dlb_alloc_urb_list : after sema_init
<5>udlfb: allocated 4 65024 byte urbs
<4>dlfb_setup_modes
<4>dlfb_get_edid
<4>dlfb_is_valid_mode
<6>udlfb: 800x480 valid mode
<4>udlfb: Reallocating framebuffer. Addresses will change!
<4>dlfb_ops_check_var
<4>dlfb_is_valid_mode
<6>udlfb: 800x480 valid mode
<5>udlfb: set_par mode 800x480
<4>dlfb_set_video_mode
<4>dlfb_get_urb end
<4>dlfb_set_vid_cmds
<4>dlfb_submit_urb
<4>dlfb_submit_urb : after usb_submit_urb ret=0
<4>dlfb_set_video_mode end
<4>dlfb_urb_completion
<4>up release_urb_work !!!
<4>dlfb_urb_completion end
<4>dlfb_handle_damage
<4>dlfb_get_urb end
<4>dlfb_submit_urb
<4>dlfb_submit_urb : after usb_submit_urb ret=0
<6>udlfb: DisplayLink USB device /dev/fb1 attached. 800x480 resolution. Using 1504K framebuffer memory
<4>dlfb_urb_completion
<4>up release_urb_work !!!
<4>dlfb_urb_completion end
<6>usb 1-1.3.3: new full speed USB device using str8100-ehci and address 25
<3>usb 1-1.3.3: device descriptor read/64, error -32
<3>usb 1-1.3.3: device descriptor read/64, error -32
<6>usb 1-1.3.3: new full speed USB device using str8100-ehci and address 26
<3>usb 1-1.3.3: device descriptor read/64, error -32
<3>usb 1-1.3.3: device descriptor read/64, error -32
<6>usb 1-1.3.3: new full speed USB device using str8100-ehci and address 27
<3>usb 1-1.3.3: device not accepting address 27, error -32
<6>usb 1-1.3.3: new full speed USB device using str8100-ehci and address 28
<3>usb 1-1.3.3: device not accepting address 28, error -32
<6>usb 1-1.3: USB disconnect, address 23
<6>usb 1-1.3.2: USB disconnect, address 24
<6>udlfb: USB disconnect starting
<4>dlfb_free_framebuffer_work
<4>udlfb: fb_info for /dev/fb1 has been freed
<4>dlfb_free
<5>udlfb: Waiting for completes and freeing all render urbs
<4>udlfb: freeing dlfb_data c1031000
<6>usb 1-1: USB disconnect, address 12
<6>usb 1-1: new high speed USB device using str8100-ehci and address 29
<6>usb 1-1: configuration #1 chosen from 1 choice
<6>hub 1-1:1.0: USB hub found
<6>hub 1-1:1.0: 4 ports detected
tslib doesn't create an input device; your touchscreen's device driver does. tslib uses it and you can call ts_read() to get filtered samples. There are X11 and Qt5 wrappers that do this. That's the way it always was.
As of version 1.3 of tslib, there is tslib/tools/ts_uinput that you can use to create an input device to point your environment to, see tslib's project page.
As of now, there is tslib-1.3-rc1 if you want to test this.