Skip to content
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

USB/hubs not working properly #13

Open
neagix opened this issue Aug 25, 2017 · 2 comments
Open

USB/hubs not working properly #13

neagix opened this issue Aug 25, 2017 · 2 comments
Labels

Comments

@neagix
Copy link
Owner

neagix commented Aug 25, 2017

Sometimes the USB keyboard gets never detected if I plug it in after the kernel boots.

The workaround is to boot with the keyboard plugged-in, then everything works fine

The kernel messages that document this problem are:

[   50.798734] usb 2-1.2: unable to read config index 0 descriptor/start: -61
[   50.799307] usb 2-1.2: can't read configurations, error -61
[   50.872739] usb 2-1.2: new low-speed USB device number 10 using ohci-hlwd
[   50.899781] usb 2-1.2: device descriptor read/8, error -61
[   51.028733] usb 2-1.2: device descriptor read/8, error -61
[   51.199738] usb 2-1.2: new low-speed USB device number 11 using ohci-hlwd
[   51.242739] usb 2-1.2: unable to read config index 0 descriptor/start: -61
[   51.243275] usb 2-1.2: can't read configurations, error -61
[   51.244742] hub 2-1:1.0: unable to enumerate USB device on port 2
[   59.622371] usb 2-2: new low-speed USB device number 12 using ohci-hlwd
[   59.837736] usb 2-2: unable to read config index 0 descriptor/start: -61
[   59.838271] usb 2-2: can't read configurations, error -61
[   60.002377] usb 2-2: new low-speed USB device number 13 using ohci-hlwd
[   60.208733] usb 2-2: unable to read config index 0 descriptor/start: -61
[   60.209300] usb 2-2: can't read configurations, error -61
[   60.369042] usb 2-2: new low-speed USB device number 14 using ohci-hlwd
[   60.408734] usb 2-2: device descriptor read/all, error -61
[   60.569045] usb 2-2: new low-speed USB device number 15 using ohci-hlwd
[   60.608734] usb 2-2: device descriptor read/all, error -61
[   60.609783] hub 2-0:1.0: unable to enumerate USB device on port 2

It has to be verified if this is a regression from v2.6 kernels; v3.14.x and v3.15.x both have this issue.

Cc @DeltaResero that also experienced this issue.

@neagix neagix added the bug label Aug 25, 2017
@neagix
Copy link
Owner Author

neagix commented Sep 5, 2017

I verified that with v2.6.32 you can plugin USB devices later on (keyboard, mass storage) without issues

@derek57
Copy link

derek57 commented Nov 25, 2020

@neagix

You have different settings on the Wii-Linux Kernel variables (defconfig files) within this repo...

"CONFIG_SLAB=y"
"# CONFIG_SLOB is not set"
"# CONFIG_SLUB is not set"

Setting these in the defconfig files as shown above makes USB work properly ALL the time.

BTW:

The problem with the Gamecube SI driver crashing with a plugged in controller while booting Linux on the Wii is, because the updated version of the driver itself doesn't allocate memory to the controller struct "input_dev" sub-member "absinfo".

Have a look at the function "si_setup_pad":

"absinfo" members of the "idev" variable are tried to be set BEFORE the call to the function "input_set_abs_params" is being made.

The function "input_set_abs_params" itself allocates the memory for "absinfo" but RETURNS if it fails with that. So trying to set variables of "absinfo" while there is no memory allocated, fails horribly...

ThatsItForTheOtherOne pushed a commit to Wii-Linux/wii-linux-ngx that referenced this issue Oct 16, 2023
[ Upstream commit 05bb016 ]

ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e

Before this change we see the following UBSAN stack trace in Fuchsia:

  #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  #1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f
  #1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f
  #1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f
  #2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d
  #3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d
  #4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  #5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369
  neagix#6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac
  neagix#7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2
  neagix#8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052
  neagix#9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8
  neagix#10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98
  neagix#11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac
  neagix#12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d
  neagix#13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603

Add a simple check that avoids incrementing a pointer by zero, but
otherwise behaves as before. Note that our findings are against ACPICA
20221020, but the same code exists on master.

Link: acpica/acpica@770653e3
Signed-off-by: Bob Moore <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Ulrich Hecht <[email protected]>
techflashYT pushed a commit to Wii-Linux/wii-linux-ngx that referenced this issue Jun 29, 2024
It was observed that a process blocked indefintely in
__fscache_read_or_alloc_page(), waiting for FSCACHE_COOKIE_LOOKING_UP
to be cleared via fscache_wait_for_deferred_lookup().

At this time, ->backing_objects was empty, which would normaly prevent
__fscache_read_or_alloc_page() from getting to the point of waiting.
This implies that ->backing_objects was cleared *after*
__fscache_read_or_alloc_page was was entered.

When an object is "killed" and then "dropped",
FSCACHE_COOKIE_LOOKING_UP is cleared in fscache_lookup_failure(), then
KILL_OBJECT and DROP_OBJECT are "called" and only in DROP_OBJECT is
->backing_objects cleared.  This leaves a window where
something else can set FSCACHE_COOKIE_LOOKING_UP and
__fscache_read_or_alloc_page() can start waiting, before
->backing_objects is cleared

There is some uncertainty in this analysis, but it seems to be fit the
observations.  Adding the wake in this patch will be handled correctly
by __fscache_read_or_alloc_page(), as it checks if ->backing_objects
is empty again, after waiting.

Customer which reported the hang, also report that the hang cannot be
reproduced with this fix.

The backtrace for the blocked process looked like:

PID: 29360  TASK: ffff881ff2ac0f80  CPU: 3   COMMAND: "zsh"
 #0 [ffff881ff43efbf8] schedule at ffffffff815e56f1
 #1 [ffff881ff43efc58] bit_wait at ffffffff815e64ed
 #2 [ffff881ff43efc68] __wait_on_bit at ffffffff815e61b8
 #3 [ffff881ff43efca0] out_of_line_wait_on_bit at ffffffff815e625e
 #4 [ffff881ff43efd08] fscache_wait_for_deferred_lookup at ffffffffa04f2e8f [fscache]
 #5 [ffff881ff43efd18] __fscache_read_or_alloc_page at ffffffffa04f2ffe [fscache]
 neagix#6 [ffff881ff43efd58] __nfs_readpage_from_fscache at ffffffffa0679668 [nfs]
 neagix#7 [ffff881ff43efd78] nfs_readpage at ffffffffa067092b [nfs]
 neagix#8 [ffff881ff43efda0] generic_file_read_iter at ffffffff81187a73
 neagix#9 [ffff881ff43efe50] nfs_file_read at ffffffffa066544b [nfs]
neagix#10 [ffff881ff43efe70] __vfs_read at ffffffff811fc756
neagix#11 [ffff881ff43efee8] vfs_read at ffffffff811fccfa
neagix#12 [ffff881ff43eff18] sys_read at ffffffff811fda62
neagix#13 [ffff881ff43eff50] entry_SYSCALL_64_fastpath at ffffffff815e986e

Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: David Howells <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants