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

PS2 Eyetoy camera is not working after commit 44dc4f093c9ec075e6704965665311a94f6371aa #454

Closed
SonnyJim opened this issue Dec 3, 2013 · 8 comments
Assignees

Comments

@SonnyJim
Copy link

SonnyJim commented Dec 3, 2013

Hexxeh/rpi-firmware@44dc4f0

This commit causes the Playstation 2 Eyetoy camera to not work. I have no idea if it affects any other USB cameras, but the error I am receiving from motion is attached to the bottom. Any commit before this works fine.

[1] cap.driver: "ov519"
[1] cap.card: "Logitech EyeToy USB Camera"
[1] cap.bus_info: "usb-bcm2708_usb-1.3"
[1] cap.capabilities=0x85000001
[1] - VIDEO_CAPTURE
[1] - READWRITE
[1] - STREAMING
[1] Test palette JPEG (320x240)
[1] Using palette JPEG (320x240) bytesperlines 320 sizeimage 29390 colorspace 00000007
[1] found control 0x00980900, "Brightness", range 0,255
[1] "Brightness", default 127, current 127
[1] found control 0x00980902, "Saturation", range 0,255
[1] "Saturation", default 127, current 127
[1] mmap information:
[1] frames=4
[1] 0 length=32768
[1] 1 length=32768
[1] 2 length=32768
[1] 3 length=32768
[1] Using V4L2
Unsupported marker type 0xf5
[1] Video device fatal error - Closing video device
[1] Closing video device /dev/video0
@ghost ghost assigned P33M Dec 3, 2013
@P33M
Copy link
Contributor

P33M commented Dec 3, 2013

This is a known issue with fiq_split. The device is a USB1.1 camera which requires isochronous split transactions with multiple split-completes. The current implementation does not allow for more than 1 split-complete in a USB frame therefore only max 188 bytes are transferred per 1ms.

Refer to this comment: raspberrypi/firmware#197 (comment)

The same principle applies for a video stream instead of audio recording stream, but the much greater bandwidth of a video stream (even if JPEG-encoded) produces an unreadable output.

A possible workaround is to disable fiq_split with dwc_otg.fiq_split_enable=0 in /boot/cmdline.txt but the transfer will still be unreliable as generic interrupt latency will mess up the transaction.

@tvjon
Copy link

tvjon commented Jan 13, 2014

I'm currently trying 1d78a22d866b69454c062443db9d4b42f00f0215

mainly to see how high speed isoch' transfers are progressing, but as I have an Eye Toy in my bits box, I thought I'd try it.

If you can put up with a random frame glitch now & then, it does actually produce a fair picture (640*480) using guvcviewer (already in Raspbian distribution), so long as it's plugged directly into a USB port on model B. I'm currently using a 7 port hub which works fine at 2.0 speeds, but has only a single TT. ET's frames just break up if I send through that:

[ 277.432873] gspca_main: ISOC data error: [14] len=0, status=-71
[ 277.432885] gspca_main: ISOC data error: [15] len=0, status=-71
[ 277.432897] gspca_main: ISOC data error: [16] len=0, status=-71
[ 277.432909] gspca_main: ISOC data error: [17] len=0, status=-71
[ 277.432921] gspca_main: ISOC data error: [18] len=0, status=-71
[ 277.432933] gspca_main: ISOC data error: [19] len=0, status=-71
[ 277.432945] gspca_main: ISOC data error: [20] len=0, status=-71
[ 277.432967] gspca_main: ISOC data error: [21] len=0, status=-71
[ 277.432981] gspca_main: ISOC data error: [22] len=0, status=-71
[ 277.432993] gspca_main: ISOC data error: [23] len=0, status=-71
[ 277.433005] gspca_main: ISOC data error: [24] len=0, status=-71
[ 277.433017] gspca_main: ISOC data error: [25] len=0, status=-71
[ 277.433030] gspca_main: ISOC data error: [26] len=0, status=-71
[ 277.433042] gspca_main: ISOC data error: [27] len=0, status=-71
[ 277.433054] gspca_main: ISOC data error: [28] len=0, status=-71
[ 277.433066] gspca_main: ISOC data error: [29] len=0, status=-71
[ 277.433088] gspca_main: ISOC data error: [30] len=0, status=-71
ad nauseum....
[ 277.433102] gspca_main: ISOC data error: [31] len=0, status=-71
[ 277.440855] usb 1-1.3.4.3: USB disconnect, device number 8
[ 376.274359] usb 1-1.3.4.3: new full-speed USB device number 10 using dwc_otg
[ 376.397815] usb 1-1.3.4.3: New USB device found, idVendor=054c, idProduct=0155
[ 376.397839] usb 1-1.3.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 376.397852] usb 1-1.3.4.3: Product: EyeToy USB camera Namtai
[ 376.397863] usb 1-1.3.4.3: Manufacturer: Sony corporation
[ 376.401250] gspca_main: ov519-2.14.0 probing 054c:0155
[ 376.624827] input: ov519 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4.3/input/input3
[ 405.202024] usb 1-1.3.4.3: USB disconnect, device number 10
[ 445.995172] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet
[ 445.995243] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 456.406475] usb 1-1.3.4.3: new full-speed USB device number 11 using dwc_otg

& when plugged into B directly:

video device: /dev/video0
Init. EyeToy USB camera Namtai (location: usb-bcm2708_usb-1.2)
{ pixelformat = 'JPEG', description = 'JPEG' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
{ discrete: width = 640, height = 480 }
Time interval between frame:
{ pixelformat = 'RGB3', description = 'RGB3' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
{ discrete: width = 640, height = 480 }
Time interval between frame:
{ pixelformat = 'BGR3', description = 'BGR3' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
{ discrete: width = 640, height = 480 }
Time interval between frame:
{ pixelformat = 'YU12', description = 'YU12' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
{ discrete: width = 640, height = 480 }
Time interval between frame:
{ pixelformat = 'YV12', description = 'YV12' }
{ discrete: width = 320, height = 240 }
Time interval between frame:
{ discrete: width = 640, height = 480 }
Time interval between frame:
vid:054c
pid:0155
driver:ov519
checking format: 1195724874
VIDIOC_G_COMP:: Inappropriate ioctl for device
fps is set to 0/0
drawing controls

control type: 0x00000006 not supported
fps is set to 1/1
Checking video mode 640x480@32bpp : OK

etimage

@P33M
Copy link
Contributor

P33M commented Feb 26, 2014

Can you give sudo BRANCH=next rpi-update a go? My eyetoy works at 640x480 / 7fps with fiq_fsm.

@tvjon
Copy link

tvjon commented Feb 27, 2014

Certainly.

I had tried this again recently, but there was still some bottom-half picture tearing every few seconds.

Happily no tearing now, & between 5 & 7 fps, very good! I generally test using "guvcview", invoked from cli so I can see errors, normally hundreds, but now none!

Also 7 fps on fw 94e1.......30d38, but black screen only. With both firmwares, I left the 3 new cmdline FIQ options in, with a mask of 3.

I have a few more older webcams to check, so I'll update the wiki if any now work that previously didn't.

I was hoping to see just how the new FIQ handler copes with my hd 290e tuner, but I still haven't tracked down why in the last 3 or 4 kernels, it's demodulator won't initialise because of a gpio error. I've just checked kernel's bugzilla & strangely there's no reports, yet there were several for the previous initialisation error which other kernel users noticed after I reported it, so I'm beginning to wonder if it's RPi specific.

Anyway, very good results so far with the new handler. Next to test some USB audio devices.

@P33M
Copy link
Contributor

P33M commented Feb 27, 2014

Can you link to the firmware commit that has the black screen?

@tvjon
Copy link

tvjon commented Feb 27, 2014

I abbreviated the string to avoid any transposition errors from the other machine I was posting from. It's the contents of
.firmware_revision in the /boot folder, but I can't find it here on Github, so what's its relationship?

Here's the full string: "94e1b8014dfa69701d0432088acb11ae01130d38"

94e1b8014dfa69701d0432088acb11ae01130d38

@popcornmix
Copy link
Collaborator

The .firmware_revision refers to:
Hexxeh/rpi-firmware@94e1b80

@P33M
Copy link
Contributor

P33M commented Mar 6, 2014

Eyetoy works fine on my desk with BRANCH=next firmware.

@tvjon the commit producing the black screen does not include the fiq_fsm rewrite. This behaviour is typical of gspca when it gets no data - it just reports a black frame.

@P33M P33M closed this as completed Mar 6, 2014
popcornmix pushed a commit that referenced this issue Oct 8, 2014
Soothes the following checkpatch warnings:

    WARNING: line over 80 characters
    #151: FILE: drivers/mfd/ab8500-core.c:151:
    +	0, 1, 2, 3, 4, -1, -1, -1, -1, 11, 18, 19, 20, 21, 12, 13, 24, 5, 22, 23,

    ERROR: spaces required around that '=' (ctx:VxW)
    #325: FILE: drivers/mfd/ab8500-core.c:325:
    +	ret= mask_and_set_register_interruptible(ab8500, bank, reg,
     	   ^

    WARNING: line over 80 characters
    #418: FILE: drivers/mfd/ab8500-core.c:418:
    +		else if (offset >= AB9540_INT_GPIO50R && offset <= AB9540_INT_GPIO54R)

    WARNING: line over 80 characters
    #420: FILE: drivers/mfd/ab8500-core.c:420:
    +		else if (offset == AB8540_INT_GPIO43R || offset == AB8540_INT_GPIO44R)

    ERROR: spaces required around that '==' (ctx:VxV)
    #454: FILE: drivers/mfd/ab8500-core.c:454:
    +	if ((i==3) && (*offset >= 24))
     	      ^

    ERROR: code indent should use tabs where possible
    #576: FILE: drivers/mfd/ab8500-core.c:576:
    +        .map    = ab8500_irq_map,$

    WARNING: please, no spaces at the start of a line
    #576: FILE: drivers/mfd/ab8500-core.c:576:
    +        .map    = ab8500_irq_map,$

    ERROR: code indent should use tabs where possible
    #577: FILE: drivers/mfd/ab8500-core.c:577:
    +        .xlate  = irq_domain_xlate_twocell,$

    WARNING: please, no spaces at the start of a line
    #577: FILE: drivers/mfd/ab8500-core.c:577:
    +        .xlate  = irq_domain_xlate_twocell,$

    WARNING: char * array declaration might be better as static const
    #1554: FILE: drivers/mfd/ab8500-core.c:1554:
    +	static char *switch_off_status[] = {

    WARNING: char * array declaration might be better as static const
    #1563: FILE: drivers/mfd/ab8500-core.c:1563:
    +	static char *turn_on_status[] = {

    WARNING: sizeof *ab8500 should be sizeof(*ab8500)
    #1582: FILE: drivers/mfd/ab8500-core.c:1582:
    +	ab8500 = devm_kzalloc(&pdev->dev, sizeof *ab8500, GFP_KERNEL);

    ERROR: space required after that close brace '}'
    #1639: FILE: drivers/mfd/ab8500-core.c:1639:
    +	}/* Configure AB8500 or AB9540 IRQ */

    WARNING: line over 80 characters
    #1652: FILE: drivers/mfd/ab8500-core.c:1652:
    +	ab8500->oldmask = devm_kzalloc(&pdev->dev, ab8500->mask_size, GFP_KERNEL);

    WARNING: Prefer [subsystem eg: netdev]_cont([subsystem]dev, ... then dev_cont(dev, ... then pr_cont(...  to printk(KERN_CONT ...
    #1677: FILE: drivers/mfd/ab8500-core.c:1677:
    +				printk(KERN_CONT " \"%s\"",

    WARNING: Prefer [subsystem eg: netdev]_cont([subsystem]dev, ... then dev_cont(dev, ... then pr_cont(...  to printk(KERN_CONT ...
    #1682: FILE: drivers/mfd/ab8500-core.c:1682:
    +		printk(KERN_CONT "\n");

    WARNING: Prefer [subsystem eg: netdev]_cont([subsystem]dev, ... then dev_cont(dev, ... then pr_cont(...  to printk(KERN_CONT ...
    #1684: FILE: drivers/mfd/ab8500-core.c:1684:
    +		printk(KERN_CONT " None\n");

    WARNING: printk() should include KERN_ facility level
    #1695: FILE: drivers/mfd/ab8500-core.c:1695:
    +				printk("\"%s\" ", turn_on_status[i]);

    WARNING: printk() should include KERN_ facility level
    #1700: FILE: drivers/mfd/ab8500-core.c:1700:
    +		printk("None\n");

    total: 5 errors, 14 warnings, 1869 lines checked

Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 1, 2020
The bucket->lock is not needed in the sock_hash_free and sock_map_free
calls, in fact it is causing a splat due to being inside rcu block.

| BUG: sleeping function called from invalid context at net/core/sock.c:2935
| in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 62, name: kworker/0:1
| 3 locks held by kworker/0:1/62:
|  #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0
|  #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0
|  #2: ffff8881381f6df8 (&stab->lock){+...}, at: sock_map_free+0x26/0x180
| CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04008-g7b083332376e #454
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
| Workqueue: events bpf_map_free_deferred
| Call Trace:
|  dump_stack+0x71/0xa0
|  ___might_sleep.cold+0xa6/0xb6
|  lock_sock_nested+0x28/0x90
|  sock_map_free+0x5f/0x180
|  bpf_map_free_deferred+0x58/0x80
|  process_one_work+0x260/0x5e0
|  worker_thread+0x4d/0x3e0
|  kthread+0x108/0x140
|  ? process_one_work+0x5e0/0x5e0
|  ? kthread_park+0x90/0x90
|  ret_from_fork+0x3a/0x50

The reason we have stab->lock and bucket->locks in sockmap code is to
handle checking EEXIST in update/delete cases. We need to be careful during
an update operation that we check for EEXIST and we need to ensure that the
psock object is not in some partial state of removal/insertion while we do
this. So both map_update_common and sock_map_delete need to guard from being
run together potentially deleting an entry we are checking, etc. But by the
time we get to the tear-down code in sock_{ma[|hash}_free we have already
disconnected the map and we just did synchronize_rcu() in the line above so
no updates/deletes should be in flight. Because of this we can drop the
bucket locks from the map free'ing code, noting no update/deletes can be
in-flight.

Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface")
Reported-by: Jakub Sitnicki <[email protected]>
Suggested-by: Jakub Sitnicki <[email protected]>
Signed-off-by: John Fastabend <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/158385850787.30597.8346421465837046618.stgit@john-Precision-5820-Tower
popcornmix pushed a commit that referenced this issue Apr 1, 2020
commit 90db6d7 upstream.

The bucket->lock is not needed in the sock_hash_free and sock_map_free
calls, in fact it is causing a splat due to being inside rcu block.

| BUG: sleeping function called from invalid context at net/core/sock.c:2935
| in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 62, name: kworker/0:1
| 3 locks held by kworker/0:1/62:
|  #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0
|  #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0
|  #2: ffff8881381f6df8 (&stab->lock){+...}, at: sock_map_free+0x26/0x180
| CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04008-g7b083332376e #454
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
| Workqueue: events bpf_map_free_deferred
| Call Trace:
|  dump_stack+0x71/0xa0
|  ___might_sleep.cold+0xa6/0xb6
|  lock_sock_nested+0x28/0x90
|  sock_map_free+0x5f/0x180
|  bpf_map_free_deferred+0x58/0x80
|  process_one_work+0x260/0x5e0
|  worker_thread+0x4d/0x3e0
|  kthread+0x108/0x140
|  ? process_one_work+0x5e0/0x5e0
|  ? kthread_park+0x90/0x90
|  ret_from_fork+0x3a/0x50

The reason we have stab->lock and bucket->locks in sockmap code is to
handle checking EEXIST in update/delete cases. We need to be careful during
an update operation that we check for EEXIST and we need to ensure that the
psock object is not in some partial state of removal/insertion while we do
this. So both map_update_common and sock_map_delete need to guard from being
run together potentially deleting an entry we are checking, etc. But by the
time we get to the tear-down code in sock_{ma[|hash}_free we have already
disconnected the map and we just did synchronize_rcu() in the line above so
no updates/deletes should be in flight. Because of this we can drop the
bucket locks from the map free'ing code, noting no update/deletes can be
in-flight.

Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface")
Reported-by: Jakub Sitnicki <[email protected]>
Suggested-by: Jakub Sitnicki <[email protected]>
Signed-off-by: John Fastabend <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/158385850787.30597.8346421465837046618.stgit@john-Precision-5820-Tower
Signed-off-by: Greg Kroah-Hartman <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 1, 2020
commit 90db6d7 upstream.

The bucket->lock is not needed in the sock_hash_free and sock_map_free
calls, in fact it is causing a splat due to being inside rcu block.

| BUG: sleeping function called from invalid context at net/core/sock.c:2935
| in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 62, name: kworker/0:1
| 3 locks held by kworker/0:1/62:
|  #0: ffff88813b019748 ((wq_completion)events){+.+.}, at: process_one_work+0x1d7/0x5e0
|  #1: ffffc900000abe50 ((work_completion)(&map->work)){+.+.}, at: process_one_work+0x1d7/0x5e0
|  #2: ffff8881381f6df8 (&stab->lock){+...}, at: sock_map_free+0x26/0x180
| CPU: 0 PID: 62 Comm: kworker/0:1 Not tainted 5.5.0-04008-g7b083332376e #454
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
| Workqueue: events bpf_map_free_deferred
| Call Trace:
|  dump_stack+0x71/0xa0
|  ___might_sleep.cold+0xa6/0xb6
|  lock_sock_nested+0x28/0x90
|  sock_map_free+0x5f/0x180
|  bpf_map_free_deferred+0x58/0x80
|  process_one_work+0x260/0x5e0
|  worker_thread+0x4d/0x3e0
|  kthread+0x108/0x140
|  ? process_one_work+0x5e0/0x5e0
|  ? kthread_park+0x90/0x90
|  ret_from_fork+0x3a/0x50

The reason we have stab->lock and bucket->locks in sockmap code is to
handle checking EEXIST in update/delete cases. We need to be careful during
an update operation that we check for EEXIST and we need to ensure that the
psock object is not in some partial state of removal/insertion while we do
this. So both map_update_common and sock_map_delete need to guard from being
run together potentially deleting an entry we are checking, etc. But by the
time we get to the tear-down code in sock_{ma[|hash}_free we have already
disconnected the map and we just did synchronize_rcu() in the line above so
no updates/deletes should be in flight. Because of this we can drop the
bucket locks from the map free'ing code, noting no update/deletes can be
in-flight.

Fixes: 604326b ("bpf, sockmap: convert to generic sk_msg interface")
Reported-by: Jakub Sitnicki <[email protected]>
Suggested-by: Jakub Sitnicki <[email protected]>
Signed-off-by: John Fastabend <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/158385850787.30597.8346421465837046618.stgit@john-Precision-5820-Tower
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants