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

Kernels >= 3.10: w1_gpio destroys i2c bus 0 (raspicam doesn't work anymore) #435

Closed
crashmaster1 opened this issue Nov 18, 2013 · 38 comments
Assignees

Comments

@crashmaster1
Copy link

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:

  • boot without loading the w1_gpio module
  • check i2c bus 0 ("i2cdetect -y 0"), you see lots of dashes, that's fine
  • now load w1_gpio (modprobe w1_gpio)
  • check i2c bus 0 again: all dashes have gone and you get a lot of numbers in ascending order :(
  • f.e. your raspicam will hang now (it uses i2c bus 0)

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).

@ghost ghost assigned popcornmix Nov 18, 2013
@JamesH65
Copy link
Contributor

I think this is a dupe of #434

@crashmaster1
Copy link
Author

I didn't think so because it also affects the official kernel 3.10.x.

@popcornmix
Copy link
Collaborator

I've had a quick look and can reproduce the problem.
The problem is that the 1-wire module overwrite the gpio function selection for the I2C pins.
Before 1-wire is loaded *0x20200000 = 0x48024 and I2C works (GPIO0 and GPIO in I2C alt function)
After 1-wire is loaded *0x20200000 = 0x48921 and I2C fails (GPIO0 is set to an output)

No idea yet why that happens yet, but that explains why I2C (and camera) stops working.

@crashmaster1
Copy link
Author

Thanks popcornmix.

A workaround is to load first the 1wire modules and afterwards the i2c modules.
I2c initialization overwrites the 1wire quirks for bus 0, cam and w1 sensors work fine now.

@popcornmix
Copy link
Collaborator

@crashmaster1
Are you aware of where in the code register 0x20200000 gets written when 1-wire is loaded?
I noticed that the 3.10 1-wire driver does some pin-muxing calls that 3.6 didn't do, but I assumed we have no pin muxing driver, so that would be a no-op.

@crashmaster1
Copy link
Author

Sorry, i'm not aware of that.

N8Fear pushed a commit to N8Fear/linux that referenced this issue Nov 26, 2013
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]>
@chtitux
Copy link

chtitux commented Dec 19, 2013

The workaround of @crashmaster1 DOES work (thank you !), at least on 3.10.24+ kernel.
If if does not work, verify that :

  1. The i2c-bcm2708 is blacklisted in your /etc/modprobe.d/raspi-blacklist.conf

    # blacklist spi and i2c by default (many users don't need them)
    blacklist spi-bcm2708
    blacklist i2c-bcm2708
  2. The modules are in this order in your /etc/modules

    w1-gpio
    w1-therm
    i2c-bcm2078
    i2c-dev
    

@dkossman
Copy link

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
w1_therm
snd-bcm2835
spi-bcm2708
i2c-bcm2708
i2c-dev

and raspi-blacklist.conf:

#blacklist spi-bcm2708
#blacklist i2c-bcm2708

thanks

@crashmaster1
Copy link
Author

You should not change your blacklist but in etc/modules try this order:

w1-therm
w1-gpio pullup=1
i2c-dev
i2c-bcm2708
spi-bcm2708
snd-bcm2835

@dkossman
Copy link

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
Time delay 0, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35
Link to latest frame enabled no
Full resolution preview No
Capture method : Run forever

Preview Yes, Full screen Yes
Preview window 0,0,1024,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'backlit', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

@crashmaster1
Copy link
Author

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.

@dkossman
Copy link

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
gpu_mem=128

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:

  "The i2c-bcm2708 *is* blacklisted in your /etc/modprobe.d/raspi-blacklist.conf"

can anyone explain? or did i misunderstand?

thanks
Don

@dkossman
Copy link

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
blacklist i2c-bcm2708

@smillerk2
Copy link

@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
Linux raspberrypi 3.10.24+ #614 PREEMPT Thu Dec 19 20:38:42 GMT 2013 armv6l GNU/Linux

pi@raspberrypi ~ $ cat /etc/modprobe.d/raspi-blacklist.conf
#blacklist spi-bcm2708
blacklist i2c-bcm2708

pi@raspberrypi ~ $ cat /boot/config.txt
...
start_x=1
gpu_mem=128
disable_camera_led=1
smsc95xx.turbo_mode=N

pi@raspberrypi ~ $ cat /etc/modules
snd-bcm2835

@dkossman
Copy link

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
w1-gpio pullup=1
i2c-dev
i2c-bcm2708
spi-bcm2708
snd-bcm2835

Also, I don't have the "disable_camera_led" or smsc95xx" lines in config.txt

Don

@ghost
Copy link

ghost commented Dec 24, 2013

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.

@crashmaster1
Copy link
Author

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.
Why blacklist a module which is really needed? I'm also just wondering about that but indeed a bug is a bug. ;)

@martinohanlon
Copy link

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.

@Elucidation
Copy link

(Success Update below)
Sadly workaround isn't working for me either. I have the watchdog daemon running if that affects anything.

Rpi version B, firmware #622 (most recent update as of 5:44 AM 1/8/2014)

/etc/modules

w1-gpio
w1-therm

bcm2708_wdog

snd-bcm2835

i2c-bcm2078
i2c-dev

Alternate configs tried:

w1-therm
w1-gpio pullup=1
i2c-bcm2078
i2c-dev
snd-bcm2835
bcm2708_wdog

and same with watchdog at the head.

blacklist.conf

# blacklist spi and i2c by default (many users don't need them)
blacklist spi-bcm2708
blacklist i2c-bcm2708

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)
Successfully got the workaround to work. Looks like I needed to add the spi-bcm2708 (sorry if that was a dumb revelation, I didn't realize)

/etc/modules

w1-therm
w1-gpio pullup=1
i2c-dev
i2c-bcm2708
spi-bcm2708
snd-bcm2835
bcm2708_wdog

/etc/modprobe.d/raspi-blacklist.conf

# blacklist spi and i2c by default (many users don't need them)
#blacklist spi-bcm2708
blacklist i2c-bcm2708

popcornmix pushed a commit that referenced this issue Jan 10, 2014
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]>
@smillerk2
Copy link

@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.

@dkossman
Copy link

@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...

@JamesH65
Copy link
Contributor

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.

@ttresanti
Copy link

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
Linux raspberrypi 3.10.32+ #646 PREEMPT Wed Feb 26 16:47:04 GMT 2014 armv6l GNU/Linux

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
Time delay 0, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35
Link to latest frame enabled no
Full resolution preview No
Capture method : Run forever

Preview Yes, Full screen Yes
Preview window 0,0,1024,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'backlit', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to video render.
Connecting camera stills port to encoder input port
Opening output file test.jpg
Enabling encoder output port
Starting capture 1
mmal: Received unexpected camera control callback event, 0x4f525245

@myusernamejeep
Copy link

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
Time delay 5000, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35
Link to latest frame enabled no
Full resolution preview No

Capture method : Single capture
Preview Yes, Full screen Yes
Preview window 0,0,1024,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000

Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to video render.
Connecting camera stills port to encoder input port

Opening output file a1.png
Enabling encoder output port
Starting capture 0

mmal: Received unexpected camera control callback event, 0x4f525245

@keendog
Copy link

keendog commented Apr 23, 2014

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?

@LabinskiyKN
Copy link

Hi there!
Seems to me, I found interesting way to fix the problem. I don't know, is this way correct, but... it works :)
So, I have RPi rev. B 2.0 with 1-wire DS18B20, i2c BMP085 pressure sensor and raspicam.
when I try to use

pi@raspberrypi ~ $ raspistill -v -o test.jpg

sometimes I have an error: ENOSPC.
In this moment when I run

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...
Seems to me, the problem is in port P5 on RPi rev. B 2.0 - this is a second i2c: i2c-0 which is used with the raspicam and we have our problem.
Because of not using i2c-0 on P5 port I can turn off that port with the help of hipi-i2c utility:

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...

@ajlennon
Copy link

If this relates to w1-gpio and particularly the I2C bus on GPIO0 then it may relate to the issue I believe I discovered with the RPi BSP providing GPIO0 as a pullup pin to w1-gpio #601. I believe I have a fix in #602

@hilmanshini
Copy link

How is it now? is it solved yet?
me either not works. 2 month struggling this,

i have tried new rpi and new camera with following the instruction, but still rpi camera not working.

@joshhankins
Copy link

@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!

@crashmaster1
Copy link
Author

@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.

@JamesH65
Copy link
Contributor

Indeed, please use the forums to get advice and help for this sort of
thing. The camera is known to work with the latest boards and
firmware/kernel.
On 11 Aug 2014 15:43, "crashmaster1" [email protected] wrote:

@gecko https://github.com/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.


Reply to this email directly or view it on GitHub
#435 (comment).

@kimbongzo
Copy link

Solution~

Open /etc/modules -> sudo nano /etc/modules

and below add two #

snd-bcm2835
i2c-dev
#w1-gpio
#w1-therm
lirc_dev
lirc_rpi gpio_out_pin=7

and reboot. then GPIO Collision deleted.

@bootor
Copy link

bootor commented Sep 21, 2014

... and 1-wire will stop working...

@popcornmix
Copy link
Collaborator

@bootor
If you want to use 1-wire with a camera you need to set the GPIO pin to use. E.g. add to cmdline.txt

bcm2708.w1_gpio_pin=16

You can also code it in /etc/modules
w1-gpio-gpiopin=16

Problem is by default w1 modules uses GPIO4 which is needed by camera.

@GertjanvanhetHof
Copy link

I had the same problem and I found probably the cause because I was able to reproduce it.
For me it was a hardware problem. One of the wires on de flex cable (from raspberry to camera module) was broken.
When I bow the cable the above problem was shown. This was because the connection was broken.
When I put the cable straight, the camera was working correctly.
I think it is the most left wire when camera is pointing to me.

@Ruffio
Copy link

Ruffio commented Aug 10, 2016

@crashmaster1 has this issue been resolved? If yes, then please close this issue.

@kenxausten
Copy link

I am still encounter this issue. how should i do to solve this issue?
pi@raspberrypi:~$ raspistill -o 1.jpg -v

raspistill Camera App v1.3.11

Width 3280, Height 2464, quality 85, filename 1.jpg
Time delay 5000, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35
Link to latest frame enabled no
Full resolution preview No
Capture method : Single capture

Preview Yes, Full screen Yes
Preview window 0,0,1024,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 0, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'auto', AWB Mode 'auto', Image Effect 'none'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates

pi@raspberrypi:~$ cat /etc/modprobe.d/raspi-blacklist.conf

blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
#blacklist i2c-bcm2708
pi@raspberrypi:~$ uname -a
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux
pi@raspberrypi:~$ cat /etc/modules

/etc/modules: kernel modules to load at boot time.

This file contains the names of kernel modules that should be loaded

at boot time, one per line. Lines beginning with "#" are ignored.

w1-therm
w1-gpio pullup=1
w1-gpio-gpiopin=16
bcm2708.w1_gpio_pin=16
i2c-bcm2078
i2c-dev
snd-bcm2835
bcm2708_wdog

@pelwell
Copy link
Contributor

pelwell commented Sep 15, 2017

You've got the latest firmware but your configuration was obsoleted 2 years ago with the switch to Device Tree. Try this:

  1. Remove everything from /etc/modules except this:
i2c-dev
  1. Delete /etc/modprobe.d/raspi-blacklist.conf - you shouldn't need it.
  2. Enable the camera using raspi-config:
sudo raspi-config
# Open Interfacing Options
# Select Camera
# Choose Yes to enable the camera

This will add start_x=1 and gpu_mem=64 to /boot/config.txt.

  1. If you are using a onewire device such as a DS18B20 (you don't say) then edit /boot/config.txt and add this line:
dtoverlay=w1-gpio,gpiopin=16,pullup

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:

dtoverlay=w1-gpio,gpiopin=16
  1. Reboot.

popcornmix pushed a commit that referenced this issue Dec 7, 2021
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]>
popcornmix pushed a commit that referenced this issue Dec 16, 2021
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]>
popcornmix pushed a commit that referenced this issue Dec 16, 2021
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]>
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