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.

Sign up for GitHub

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

Jump to bottom

xpad module not being compiled #187

Closed
adrianmoisey opened this issue Jan 5, 2013 · 11 comments
Closed

xpad module not being compiled #187

adrianmoisey opened this issue Jan 5, 2013 · 11 comments

Comments

@adrianmoisey
Copy link

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=14450&p=149173

Some people need the xpad module so that various gamepads can be used on the Raspberry Pi. Can this be included?
@licaon-kter
Copy link

isn't this better anyway: https://github.com/Grumbel/xboxdrv/ ?

@adrianmoisey
Copy link
Author

I tried it on my Logitech F310, and it doesn't work. The only way I know how to get it working is the xpad module.

@adrianmoisey
Copy link
Author

Will this happen?

@adrianmoisey
Copy link
Author

I've compiled this module myself for now, but it would be nice if it was included in the main package.

@usul294
Copy link

usul294 commented Apr 29, 2013

Any help on doing that? I downloaded xpad.c and xpad.h but I'm having trouble compiling it with any makefile I can find. Trying to use an f310 as well

@Silent-Hunter
Copy link

Yes please! I have a Razer Sabertooth, and even though it works on an actual XBOX 360, it will not work with xboxdrv no matter what I do. However it works perfectly on xpad. Come to think of it, I can't get a standard XBOX 360 controller to work on xboxdrv either.

@adrianmoisey
Copy link
Author

@popcornmix how do we get this to happen?

@popcornmix
Copy link
Collaborator

It's included in the next (3.10) kernel tree.
sudo BRANCH=next rpi-update
will get it.

@adrianmoisey
Copy link
Author

Awesome! Looks like it worked! Thanks :)

[    3.760363] input: Generic X-Box pad as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3:1.0/input/input0

@Silent-Hunter
Copy link

I'm getting "sudo: rpi-update: command not found".

@popcornmix
Copy link
Collaborator

You can get it from here:
https://github.com/Hexxeh/rpi-update

popcornmix pushed a commit that referenced this issue Jun 8, 2014
@torvalds
modules: use raw_cpu_write for initialization of per cpu refcount.
08f141d 
The initialization of a structure is not subject to synchronization.
The use of __this_cpu would trigger a false positive with the additional
preemption checks for __this_cpu ops.

So simply disable the check through the use of raw_cpu ops.

Trace:

  __this_cpu_write operation in preemptible [00000000] code: modprobe/286
  caller is __this_cpu_preempt_check+0x38/0x60
  CPU: 3 PID: 286 Comm: modprobe Tainted: GF            3.12.0-rc4+ #187
  Call Trace:
    dump_stack+0x4e/0x82
    check_preemption_disabled+0xec/0x110
    __this_cpu_preempt_check+0x38/0x60
    load_module+0xcfd/0x2650
    SyS_init_module+0xa6/0xd0
    tracesys+0xe1/0xe6

Signed-off-by: Christoph Lameter <cl@linux.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
popcornmix pushed a commit that referenced this issue Jun 8, 2014
@torvalds
net: replace __this_cpu_inc in route.c with raw_cpu_inc
3ed66e9 
The RT_CACHE_STAT_INC macro triggers the new preemption checks
for __this_cpu ops.

I do not see any other synchronization that would allow the use of a
__this_cpu operation here however in commit dbd2915 ("[IPV4]:
RT_CACHE_STAT_INC() warning fix") Andrew justifies the use of
raw_smp_processor_id() here because "we do not care" about races.  In
the past we agreed that the price of disabling interrupts here to get
consistent counters would be too high.  These counters may be inaccurate
due to race conditions.

The use of __this_cpu op improves the situation already from what commit
dbd2915 did since the single instruction emitted on x86 does not
allow the race to occur anymore.  However, non x86 platforms could still
experience a race here.

Trace:

  __this_cpu_add operation in preemptible [00000000] code: avahi-daemon/1193
  caller is __this_cpu_preempt_check+0x38/0x60
  CPU: 1 PID: 1193 Comm: avahi-daemon Tainted: GF            3.12.0-rc4+ #187
  Call Trace:
    check_preemption_disabled+0xec/0x110
    __this_cpu_preempt_check+0x38/0x60
    __ip_route_output_key+0x575/0x8c0
    ip_route_output_flow+0x27/0x70
    udp_sendmsg+0x825/0xa20
    inet_sendmsg+0x85/0xc0
    sock_sendmsg+0x9c/0xd0
    ___sys_sendmsg+0x37c/0x390
    __sys_sendmsg+0x49/0x90
    SyS_sendmsg+0x12/0x20
    tracesys+0xe1/0xe6

Signed-off-by: Christoph Lameter <cl@linux.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@adrianmoisey @popcornmix @licaon-kter @Silent-Hunter @usul294