-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Kernels >= 3.10: w1_gpio destroys i2c bus 0 (raspicam doesn't work anymore) #435
Comments
I think this is a dupe of #434 |
I didn't think so because it also affects the official kernel 3.10.x. |
I've had a quick look and can reproduce the problem. No idea yet why that happens yet, but that explains why I2C (and camera) stops working. |
Thanks popcornmix. A workaround is to load first the 1wire modules and afterwards the i2c modules. |
@crashmaster1 |
Sorry, i'm not aware of that. |
Since commit 0c37550 (serial: imx: enable the clocks for console), the imx_startup() function calls clk_prepare_enable conditionally, so we need to call clk_disable_unprepare inside imx_shutdown() under the same condition to avoid unbalanced clock calls. This avoids the following warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 70 at drivers/clk/clk.c:780 __clk_disable+0x68/0x84() Modules linked in: CPU: 0 PID: 70 Comm: mountall Not tainted 3.10.0-rc4-next-20130607+ raspberrypi#435 Backtrace: [<800116a4>] (dump_backtrace+0x0/0x10c) from [<80011844>] (show_stack+0x18/0x1c) r6:8069f4e8 r5:0000030c r4:00000000 r3:00000000 [<8001182c>] (show_stack+0x0/0x1c) from [<8053bce0>] (dump_stack+0x78/0x94) [<8053bc68>] (dump_stack+0x0/0x94) from [<80023df8>] (warn_slowpath_common+0x6c/0x8c) r4:00000000 r3:00000000 [<80023d8c>] (warn_slowpath_common+0x0/0x8c) from [<80023e3c>] (warn_slowpath_null+0x24/0x2c) r8:bf2ed008 r7:bfaa9810 r6:000f0013 r5:bf824b80 r4:bf824b80 [<80023e18>] (warn_slowpath_null+0x0/0x2c) from [<8041af84>] (__clk_disable+0x68/0x84) [<8041af1c>] (__clk_disable+0x0/0x84) from [<8041b098>] (clk_disable+0x20/0x2c) r4:600f0013 r3:00000001 [<8041b078>] (clk_disable+0x0/0x2c) from [<802c93e8>] (imx_shutdown+0xbc/0xec) r5:bf824b80 r4:bfaa9810 [<802c932c>] (imx_shutdown+0x0/0xec) from [<802c63a0>] (uart_port_shutdown+0x34/0x40) r5:bf86f860 r4:bfaa9810 [<802c636c>] (uart_port_shutdown+0x0/0x40) from [<802c68c0>] (uart_shutdown+0x98/0xc4) r4:bf86f800 r3:00000000 [<802c6828>] (uart_shutdown+0x0/0xc4) from [<802c7514>] (uart_close+0x5c/0x198) r7:bfaa9810 r6:bf274400 r5:bf86f86c r4:bf86f800 [<802c74b8>] (uart_close+0x0/0x198) from [<802ac648>] (tty_release+0xf8/0x500) [<802ac550>] (tty_release+0x0/0x500) from [<800c5a30>] (__fput+0x9c/0x208) [<800c5994>] (__fput+0x0/0x208) from [<800c5bac>] (____fput+0x10/0x14) [<800c5b9c>] (____fput+0x0/0x14) from [<80040234>] (task_work_run+0xb4/0xec) [<80040180>] (task_work_run+0x0/0xec) from [<80029238>] (do_exit+0x2b0/0x920) r8:8000e144 r7:000000f8 r6:bf306300 r5:00000000 r4:bfac1180 [<80028f88>] (do_exit+0x0/0x920) from [<80029a4c>] (do_group_exit+0x50/0xd4) r7:000000f8 [<800299fc>] (do_group_exit+0x0/0xd4) from [<80029ae8>] (__wake_up_parent+0x0/0x28) r7:000000f8 r6:00000001 r5:0006f7ae r4:0006f79a [<80029ad0>] (SyS_exit_group+0x0/0x18) from [<8000dfc0>] (ret_fast_syscall+0x0/0x30) ---[ end trace 16d080eb7efea4e9 ]--- Reported-by: Shawn Guo <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Tested-by: Shawn Guo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
The workaround of @crashmaster1 DOES work (thank you !), at least on
|
sorry if this is a dumb question - trying to work around this issue - i'm using the rpi camera, 1-wire temp probes, and i2c (for running an lcd display, AD converter, etc.). I assume that if i blacklist spi and i2c that they'll stop working? my /etc/modules currently looks like this: w1-gpio pullup=1 and raspi-blacklist.conf: #blacklist spi-bcm2708 thanks |
You should not change your blacklist but in etc/modules try this order: w1-therm |
thanks - made that change and restarted, but unhappily I'm still getting the same error. I've updated to the latest using apt-get update, apt-get upgrade, and rpi-update. Any suggestions? pi@raspberrypi ~ $ /usr/bin/raspistill -v -ex auto -mm backlit -w 1024 -h 768 -t 0 -o test.jpg raspistill Camera App v1.3.5 Width 1024, Height 768, quality 85, filename test.jpg Preview Yes, Full screen Yes |
At first I've also got the ENOSPC failure. In my case I commented all "cma_" params i had made in "config.txt" and it helped. Probably you don't have them, but in my opinion you should look there to find out proper values for memory usage and you should have the latest firmware installed. |
Thanks, I don't have any "cms_" params in config.txt - i am pretty sure that i've never edited that file. the only uncommented lines are: start_x=1 when i run "i2cdetect -y 0" the output shows increasing numbers instead of dashes. By the way, if the camera uses i2c bus 0, i'm a bit confused about how we can use the suggested workaround above, when changing the order in /etc/modules doesn't work:
can anyone explain? or did i misunderstand? thanks |
OK. i uncommented "blacklist i2c-bcm2708" in /etc/modprobe.d/raspi-blacklist.conf and now it appears that everything works (i2c, the 1-wire temperature probes, and the pi camera). I assume I misunderstood your suggestion above, and I'm going to leave well enough alone :-). Thanks for your help! pi@raspberrypi ~ $ cat /etc/modprobe.d/raspi-blacklist.conf blacklist spi and i2c by default (many users don't need them)#blacklist spi-bcm2708 |
@dkossman I'm experiencing the same issue as you and have the same settings but am still getting the "mmal: mmal_vc_component_enable: failed to enable component: ENOSPC" error when calling raspistill. Any ideas? pi@raspberrypi ~ $ uname -a pi@raspberrypi ~ $ cat /etc/modprobe.d/raspi-blacklist.conf pi@raspberrypi ~ $ cat /boot/config.txt pi@raspberrypi ~ $ cat /etc/modules |
not sure. I'm on the same kernel as you. I'm using a couple of 1-wire temperature probes and i2c (for an A/D converter and LCD display, as well as the rpi camera). for what its worth, my /etc/modules looks like this: w1-therm Also, I don't have the "disable_camera_led" or smsc95xx" lines in config.txt Don |
Same here, for some reason the workaround (loading w1 modules first) doesn't help for me, it only works if I never load them at all (which means no 1-wire devices can be used). This is on kernel 3.10.25+ by the way (I saw the default raspbian image still comes with 3.10.24+). Maybe that's the difference? I just updated today with apt-get. I did check that i2c-bcm2708 is indeed blacklisted so it doesn't autoload. Very strange. |
Relational to the last comments it's really strange but a bug is a bug and my workaround not a guarantee for success for everybody ;) Anyways i'm wondering because i use this workaround on 4 RPi's needing 1wire and cam (i2c) together - not less but also not more. For me it works. |
I don't know if this will help anyone, but I have found that this bug is only prevalent in 2nd revision Pi's. 1st Revision Model B's aren't affected. |
(Success Update below) Rpi version B, firmware #622 (most recent update as of 5:44 AM 1/8/2014) /etc/modules
Alternate configs tried:
and same with watchdog at the head. blacklist.conf
Also tried with spi-bcm2708 commented out, no luck. I have the camera, a 1wire DS18B20 temp sensor, and a i2c humidity/temp sensor hooked up.to the rpi. Update (Next Day) /etc/modules
/etc/modprobe.d/raspi-blacklist.conf
|
commit 66fadea upstream. Since commit c5340bd ("usb: musb: cancel work on removal") the workqueue is cancelled but then if we bail out before the workqueue is setup we get this: |INFO: trying to register non-static key. |the code is fine but needs lockdep annotation. |turning off the locking correctness validator. |CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435 |[<c00867bc>] (lock_acquire+0xf0/0x108) from [<c00529d0>] (flush_work+0x38/0x2ec) |[<c00529d0>] (flush_work+0x38/0x2ec) from [<c0052d24>] (__cancel_work_timer+0xa0/0x134) |[<c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) |[<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) |[<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24) |[<c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<c0293970>] (driver_probe_device+0x90/0x224) |[<c0293970>] (driver_probe_device+0x90/0x224) from [<c0291ef0>] (bus_for_each_drv+0x60/0x8c) |[<c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<c02938bc>] (device_attach+0x80/0xa4) |[<c02938bc>] (device_attach+0x80/0xa4) from [<c0292b24>] (bus_probe_device+0x88/0xac) |[<c0292b24>] (bus_probe_device+0x88/0xac) from [<c0291490>] (device_add+0x388/0x6c8) |[<c0291490>] (device_add+0x388/0x6c8) from [<c02952a0>] (platform_device_add+0x188/0x22c) |[<c02952a0>] (platform_device_add+0x188/0x22c) from [<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) |[<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24) |platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral |musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 This patch moves the init part to earlier part so it can be cleaned as part of the fail3 label because now it is surrounded by the fail4 label. Step two is to remove it from musb_free() and add it to the two cleanup paths (error path and device removal) separately. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
@dkossman - I was able to finally figure out the ENOSPC issue on 3.10.27. I've been using Motion as a local service with my camera and this was configured to call raspistill every second. My cgi-bin script was calling raspistill with -t 0 and this was causing the camera to hang and return the dreaded ENOSPC error (reboot required to clear). At some point between 3.6 and 3.10, raspistill must have changed the use of -t. On 3.6 with -t 0 the camera would take a picture and then release resources, on 3.10 it waits indefinitely and subsequent calls generate the error. Changing the raspistill call to pass in a small value for the time out (e.g -t 10) fixed the issue for me. |
@smillerk2 - thanks for following up. I'd noticed the same issue with -t in my raspistill calls (from a php web script) and corrected it at around the same time i made some other changes, but didn't connect the dots... |
The change to -t 0 running indefinitely was some months ago. Note that values of -t of less than about 500ms are likely to result in images with bad exposure values. The system needs 500ms or more to get started and receive enough frames in to work out the required exposure. -t 10 will often result in badly exposed images. Note also that the 'reboot required' issue has also been recently fixed. Now, any second instantiation of the camera whilst it is already running will simply drop out, and not lock up the firmware. |
I changed the /etc/modules and /etc/modprobe.d/raspi-blacklist.conf as described before, but pi camera still doesn't works with the error "mmal: Received unexpected camera control callback event, 0x4f525245" Follow the command line uname -a raspistill -v -ex auto -mm backlit -w 1024 -h 768 -t 0 -o test.jpg raspistill Camera App v1.3.6 Width 1024, Height 768, quality 85, filename test.jpg Preview Yes, Full screen Yes |
I have the same problem. pi@raspberrypi ~ $ raspistill -o a1.png -v raspistill Camera App v1.3.7 Width 2592, Height 1944, quality 85, filename a1.png Capture method : Single capture Camera component done Opening output file a1.png mmal: Received unexpected camera control callback event, 0x4f525245 |
So this seems to have just started happening on my camera as well. Same mmal: Received .... error at the bottom of running a raspistill -v my i2c-0 table only has the address 36 populated. Everything else is dashes. I am using a grid-eye i2c on i2c-1 and that seems to work. @myusernamejeep did you get anywhere with your camera? |
Hi there! pi@raspberrypi ~ $ raspistill -v -o test.jpg sometimes I have an error: ENOSPC. pi@raspberrypi ~ $ sudo i2cdetect -y 1 I can see all ports free except one where the pressure sensor is used. But pi@raspberrypi ~ $ sudo i2cdetect -y 0 shows me all ports busy... pi@raspberrypi ~ $ sudo hipi-i2c e 0 0 After that pi@raspberrypi ~ $ sudo i2cdetect -y 0 shows all free ports and I can use my raspicam... |
How is it now? is it solved yet? i have tried new rpi and new camera with following the instruction, but still rpi camera not working. |
@crashmaster1 Please can you explain the steps required in order to fix my raspberry pi camera in a more simple way as i have just started programming and using the pi. Thanks for your help - much appreciated! |
@gecko: Sorry, i can't because i'm using Arch on my RPi's (not Raspbian). I think, it's better you ask for this in the Raspberry forum. |
Indeed, please use the forums to get advice and help for this sort of
|
Solution~ Open /etc/modules -> sudo nano /etc/modules and below add two # snd-bcm2835 and reboot. then GPIO Collision deleted. |
... and 1-wire will stop working... |
@bootor
You can also code it in /etc/modules Problem is by default w1 modules uses GPIO4 which is needed by camera. |
I had the same problem and I found probably the cause because I was able to reproduce it. |
@crashmaster1 has this issue been resolved? If yes, then please close this issue. |
I am still encounter this issue. how should i do to solve this issue? raspistill Camera App v1.3.11 Width 3280, Height 2464, quality 85, filename 1.jpg Preview Yes, Full screen Yes pi@raspberrypi:~$ cat /etc/modprobe.d/raspi-blacklist.conf blacklist spi and i2c by default (many users don't need them)#blacklist spi-bcm2708 /etc/modules: kernel modules to load at boot time.This file contains the names of kernel modules that should be loadedat boot time, one per line. Lines beginning with "#" are ignored.w1-therm |
You've got the latest firmware but your configuration was obsoleted 2 years ago with the switch to Device Tree. Try this:
This will add
substituting your own pin number. Note that if your wiring to the onewire device includes a 3.3V line (which I recommend if you can), i.e. if it isn't using the phantom powering feature, then you just need:
|
smc_lgr_cleanup_early() meant to delete the link group from the link group list, but it deleted the list head by mistake. This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350 Fixes: a0a62ee ("net/smc: separate locks for SMCD and SMCR link group lists") Signed-off-by: Dust Li <[email protected]> Acked-by: Karsten Graul <[email protected]> Reviewed-by: Tony Lu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
commit 789b6cc upstream. smc_lgr_cleanup_early() meant to delete the link group from the link group list, but it deleted the list head by mistake. This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350 Fixes: a0a62ee ("net/smc: separate locks for SMCD and SMCR link group lists") Signed-off-by: Dust Li <[email protected]> Acked-by: Karsten Graul <[email protected]> Reviewed-by: Tony Lu <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 789b6cc upstream. smc_lgr_cleanup_early() meant to delete the link group from the link group list, but it deleted the list head by mistake. This may cause memory corruption since we didn't remove the real link group from the list and later memseted the link group structure. We got a list corruption panic when testing: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350 Fixes: a0a62ee ("net/smc: separate locks for SMCD and SMCR link group lists") Signed-off-by: Dust Li <[email protected]> Acked-by: Karsten Graul <[email protected]> Reviewed-by: Tony Lu <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Since kernel versions >=3.10 "w1_gpio" became a showstopper for i2c bus 0 users, f.e. raspicam needs that!
It can be simply checked:
This happens with the latest official kernel for RPi (= 3.10.19-1) and newer versions.
Switching back to the previous version 3.6.11-18 works fine (without destroying i2c bus 0).
The text was updated successfully, but these errors were encountered: