Lots of "FIQ reported NYET. Data may have been lost." when using APC UPSD with apcupsd software. #624
Assignees
Comments
|
I confirm the same problem: lsusb -t lsusb -v for device is With dwc_otg.fiq_fsm_mask = 0x5 the problem go away so seems linked to the implementation of periodic split transaction within the FIQ FSM acceleration |
|
@xittos sorry I am not a linux expert, where do I have to configure Anyway, I confirm this error, happening with my USB bluetooth device. After a lot of those
|
|
Ok @xittos nevermind a bit of research on google and I found out where to put this setting. Now I can confirm that I don't have any error anymore, and that I can successfully use my USB bluetooth device without it being disconnected by the kernel. I forgot to mention one maybe useful information to help fixing the bug if it's a bug: UPDATE: Hope this information will be useful. |
|
Other reports are that dwc_otg.fiq_fsm_mask=0xF with recent firmware makes this sort of problem disappear. Reopen if this is still an issue. |
|
I get this too, for my e-on current cost usb device. (I was worried at first that it was my usb memory stick I use for back-ups, but it wasn't that after all.) dmesg reports: [1992998.546945] Transfer to device 9 endpoint 0x1 frame 505 failed - FIQ reported NYET. Data may have been lost. $ lsusb dwc_otg.fiq_fsm_mask=0xF fixed it for me after a reboot. :) |
|
I recently updated my kernel GIT tree and saw a bunch of fixes in this vein. I tried removing my dwc_otg.fiq_fsm_mask=0xF workaround from the cmdline.txt, but the warning messages did come back. Is this indeed a fix, or a workaround? |
|
Why has this issue been closed? Still see some of those errors on a Raspberry Pi 2 on a regular basis: dmesg -T | grep dev lsusb I´ve got no idea what´s going on here and therefore I´m not brave enough to just try the above mentioned "workaround" (what does ist do???). |
|
I'm in the same boat a bcutter. [Wed Mar 2 00:20:19 2016] Transfer to device 4 endpoint 0x3 frame 1600 failed - FIQ reported NYET. Data may have been lost. RasPi2 running Linux RasPi 4.1.18-v7+ #845 SMP Thu Feb 18 19:45:28 GMT 2016 armv7l GNU/Linux I am a bit reluctant to add dwc_otg.fiq_fsm_mask=0xF fix without knowing what it does. Anyone care to explain? Also, further up in this thread someone mentioned that dwc_otg.fiq_fsm_mask=0x5 fixes it. What is the difference between the two? Which one is the actual fix? |
|
Recent kernels default to 0xf. But seems it's causing problems for me. Using fiq_fsm_mask=0x5 removed the issue on my case. |
fabled
added a commit
to rameplayerorg/rameplayer-alpine
that referenced
this issue
May 19, 2016
raspberrypi/linux#624 recent kernels default to 0xf, and the problem appears. using 0x5 for now to workaround the issue.
|
@fabled can you provide more details of what fails with: |
|
Did the default change in the 4.4 series? For me at least, adding fiq_mask=0xf fixed my APC UPS issue, so I can take the line out of config.txt if 0xf is now the default? |
|
@popcornmix the USB device I have problems is a Behringer Xenyx Q502 USB analog audio mixer with USB audio interface. It uses snd-usb-audio kernel module. The problem happens when using grabbing audio (line-in) from the device using ffmpeg/alsa. See below for more technical dump. I can test the 0xd mask some time next week. |
|
I can confirm that for my device in the description of this issue, the problem goes away with default settings in 4.4-y sources. |
|
@popcornmix So I did additional testing, and my device seems to work with dwc_otg.fiq_fsm_mask=0x5 and 0xd. I see errors with 0x7 and 0xf. The errors happen every 5-20 seconds, and in dmesg are: Additionally to ffmpeg grabbing audio, I have omxplayer streaming live video from rtmp server. The video is h264/aac and about 2mbps. So the (USB) NIC is doing quite a bit of work too. When just grabbing audio without omxplayer streaming, the errors happen less (or not at all). |
popcornmix
pushed a commit
that referenced
this issue
Dec 31, 2020
[ Upstream commit 4ea0bf2 ] In commit "phy: tegra: xusb: Add usb-phy support", an OTG capable PHY device, such as phy-usb2.0 device of Jetson-TX1 platform, will be bound to the tegra-xusb-padctl driver by the following line in tegra_xusb_setup_usb_role_switch(). port->usb_phy.dev->driver = port->padctl->dev->driver; With this, dev_pm_ops set of tegra-xusb-padctl driver will be invoked for the OTG capable PHY incorrectly as below logs show. This commit fixes the issue by assigning an empty driver to it. [ 153.451108] tegra-xusb-padctl phy-usb2.0: > tegra_xusb_padctl_suspend_noirq(dev=ffff000080917000) [ 153.460353] tegra-xusb-padctl phy-usb2.0: driver: ffff8000114453e0 (tegra_xusb_padctl_driver) [ 153.469245] tegra-xusb-padctl phy-usb2.0: padctl: ffff0000829f6480 [ 153.475772] tegra-xusb-padctl phy-usb2.0: soc: ef7bdd7fffffffff (0xef7bdd7fffffffff) [ 153.484061] Unable to handle kernel paging request at virtual address 007bdd800000004f [ 153.492132] Mem abort info: [ 153.495083] ESR = 0x96000004 [ 153.498308] EC = 0x25: DABT (current EL), IL = 32 bits [ 153.503771] SET = 0, FnV = 0 [ 153.506979] EA = 0, S1PTW = 0 [ 153.510260] Data abort info: [ 153.513200] ISV = 0, ISS = 0x00000004 [ 153.517181] CM = 0, WnR = 0 [ 153.520302] [007bdd800000004f] address between user and kernel address ranges [ 153.527600] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 153.533231] Modules linked in: nouveau panel_simple tegra_video(C) tegra_drm drm_ttm_helper videobuf2_dma_contig ttm videobuf2_memops cec videobuf2_v4l2 videobuf2_common drm_kms_helper v4l2_fwnode videodev drm mc snd_hda_codec_hdmi cdc_ether usbnet snd_hda_tegra r8152 crct10dif_ce snd_hda_codec snd_hda_core tegra_xudc host1x lp855x_bl at24 ip_tables x_tables ipv6 [ 153.566417] CPU: 0 PID: 300 Comm: systemd-sleep Tainted: G C 5.10.0-rc3-next-20201113-00019-g5c064d5372b0-dirty #624 [ 153.578283] Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) [ 153.584281] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 153.590381] pc : tegra_xusb_padctl_suspend_noirq+0x88/0x100 [ 153.596016] lr : tegra_xusb_padctl_suspend_noirq+0x80/0x100 [ 153.601632] sp : ffff8000120dbb60 [ 153.604999] x29: ffff8000120dbb60 x28: ffff000080a1df00 [ 153.610430] x27: 0000000000000002 x26: ffff8000106f8540 [ 153.615858] x25: ffff8000113ac4a4 x24: ffff80001148c198 [ 153.621277] x23: ffff800010c4538c x22: 0000000000000002 [ 153.626692] x21: ffff800010ccde80 x20: ffff0000829f6480 [ 153.632107] x19: ffff000080917000 x18: 0000000000000030 [ 153.637521] x17: 0000000000000000 x16: 0000000000000000 [ 153.642933] x15: ffff000080a1e380 x14: 74636461702d6273 [ 153.648346] x13: ffff8000113ad058 x12: 0000000000000f39 [ 153.653759] x11: 0000000000000513 x10: ffff800011405058 [ 153.659176] x9 : 00000000fffff000 x8 : ffff8000113ad058 [ 153.664590] x7 : ffff800011405058 x6 : 0000000000000000 [ 153.670002] x5 : 0000000000000000 x4 : ffff0000fe908bc0 [ 153.675414] x3 : ffff0000fe910228 x2 : 162ef67e0581e700 [ 153.680826] x1 : 162ef67e0581e700 x0 : ef7bdd7fffffffff [ 153.686241] Call trace: [ 153.688769] tegra_xusb_padctl_suspend_noirq+0x88/0x100 [ 153.694077] __device_suspend_noirq+0x68/0x1cc [ 153.698594] dpm_noirq_suspend_devices+0x10c/0x1d0 [ 153.703456] dpm_suspend_noirq+0x28/0xa0 [ 153.707461] suspend_devices_and_enter+0x234/0x4bc [ 153.712314] pm_suspend+0x1e4/0x270 [ 153.715868] state_store+0x8c/0x110 [ 153.719440] kobj_attr_store+0x1c/0x30 [ 153.723259] sysfs_kf_write+0x4c/0x7c [ 153.726981] kernfs_fop_write+0x124/0x240 [ 153.731065] vfs_write+0xe4/0x204 [ 153.734449] ksys_write+0x6c/0x100 [ 153.737925] __arm64_sys_write+0x20/0x30 [ 153.741931] el0_svc_common.constprop.0+0x78/0x1a0 [ 153.746789] do_el0_svc+0x24/0x90 [ 153.750181] el0_sync_handler+0x254/0x260 [ 153.754251] el0_sync+0x174/0x180 [ 153.757663] Code: aa0303e2 94000f64 f9405680 b40000e0 (f9402803) [ 153.763826] ---[ end trace 81543a3394cb409d ]--- Fixes: e8f7d2f ("phy: tegra: xusb: Add usb-phy support") Signed-off-by: JC Kuo <[email protected]> Acked-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
pfpacket
pushed a commit
to pfpacket/linux-rpi-rust
that referenced
this issue
Apr 7, 2023
rust: add `dev_*` print macros.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Seeing many messages in dmesg like:
lsusb -v for device is:
The text was updated successfully, but these errors were encountered: