-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Comments
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. |
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 & when plugged into B directly: video device: /dev/video0 control type: 0x00000006 not supported |
Can you give |
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. |
Can you link to the firmware commit that has the black screen? |
I abbreviated the string to avoid any transposition errors from the other machine I was posting from. It's the contents of Here's the full string: "94e1b8014dfa69701d0432088acb11ae01130d38" 94e1b8014dfa69701d0432088acb11ae01130d38 |
The .firmware_revision refers to: |
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. |
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]>
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
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]>
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]>
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.
The text was updated successfully, but these errors were encountered: