-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Ethernet drops: smsc95xx 1-1.1:1.0 eth0: Failed to write reg index 0x00000014: -71 #746
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Please post a |
Output from
|
@davidjb has this issue been resolved? If yes, please close this issue. Thanks. |
Closing USB issues as OP has not updated the thread. Further comments by the OP stating that the issue is still present on latest rpi-update kernel will lead to a review. |
Mesa has been issuing a single bind operation per ioctl since xe.ko changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to issue every single bind operation it can in the same ioctl, it hits the MAX_BINDS assertion when running Vulkan conformance tests. Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 issues 960 bind operations in a single ioctl, it's the most I could find in the conformance suite. I don't see a reason to keep the MAX_BINDS restriction: it doesn't seem to be preventing any specific issue. If the number is too big for the memory allocations, then those will fail. Nothing related to num_binds seems to be using the stack. Let's just get rid of it. Fixes: dd08ebf ("drm/xe: Introduce a new DRM driver for Intel GPUs") Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746 Cc: Matthew Brost <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ba6bbdc) Signed-off-by: Thomas Hellström <[email protected]>
My Pi (model B) runs fine, headless, for several days, and then eventually stops responding to network requests on Ethernet, requiring a hard reboot. This issue looks to be similar to others reported (eg raspberrypi/firmware#268, #552), but I'm currently using the
next
rpi firmware, and this issue is still present.My syslog extract (some repeated lines removed, I've denoted in brackets):
Currently using the next firmware:
The text was updated successfully, but these errors were encountered: