ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 9:09 am

Those files look OK to me.

How about the output of sudo /opt/vc/bin/vcdbg log msg ?

Tips -
1.) You shouldn't need to have the i2c-bcm2708 (or i2c-bcm2835) and rtc-ds1307 modules listed in /etc/modules.
2.) You also shouldn't need to add the RTC device (echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device) in /etc/rc.local.

Something like the following should work in config.txt:

Code: Select all

# Uncomment this to enable the UPS PIco IR receiver
#dtoverlay=lirc-rpi:gpio_in_pin=18,gpio_in_pull=down

# Uncomment this to enable the UPS PIco RTC
#dtoverlay=i2c-rtc,ds1307

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 9:36 am

ktb wrote:Those files look OK to me.

How about the output of sudo /opt/vc/bin/vcdbg log msg ?

Tips -
1.) You shouldn't need to have the i2c-bcm2708 (or i2c-bcm2835) and rtc-ds1307 modules listed in /etc/modules.
2.) You also shouldn't need to add the RTC device (echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device) in /etc/rc.local.

Something like the following should work in config.txt:

Code: Select all

# Uncomment this to enable the UPS PIco IR receiver
#dtoverlay=lirc-rpi:gpio_in_pin=18,gpio_in_pull=down

# Uncomment this to enable the UPS PIco RTC
#dtoverlay=i2c-rtc,ds1307
I commented out those lines you mentioned in /etc/modules and /etc/rc.local
Added dtoverlay as mentioned but didn't do the trick.
Deamon is running but can't connect the UPS while the the i2cdetect is correct.

as for sudo /opt/vc/bin/vcdbg log msg:

Code: Select all

Unable to determine the value of __LOG_START
Unable to read logging_header from 0x00000000
At the moment flashing a fresh copy of Jessie lite
And will start from scratch to see if the above thoughts has some effect.
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 9:47 am

Please comment out "gpu_mem=8" in your config.txt or logging won't work.

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 9:52 am

ktb wrote:Please comment out "gpu_mem=8" in your config.txt or logging won't work.
Thx for the tip.
Will do in a moment, don't have a spare pi3 while the one i have is doing a full upgrade from scratch,
When done i will put the original sdcard back in and give you the output.
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 11:35 am

Hereby the output for sudo /opt/vc/bin/vcdbg log msg for the working kernel and non working kernel.

4.4.50-v7+ armv7l

Code: Select all

001065.655: HDMI:EDID error reading EDID block 0 attempt 0
001066.918: HDMI:EDID error reading EDID block 0 attempt 1
001068.176: HDMI:EDID error reading EDID block 0 attempt 2
001069.434: HDMI:EDID error reading EDID block 0 attempt 3
001070.693: HDMI:EDID error reading EDID block 0 attempt 4
001071.951: HDMI:EDID error reading EDID block 0 attempt 5
001073.208: HDMI:EDID error reading EDID block 0 attempt 6
001074.465: HDMI:EDID error reading EDID block 0 attempt 7
001075.723: HDMI:EDID error reading EDID block 0 attempt 8
001076.980: HDMI:EDID error reading EDID block 0 attempt 9
001078.002: HDMI:EDID giving up on reading EDID block 0
001092.658: HDMI:Setting property pixel encoding to Default
001092.678: HDMI:Setting property pixel clock type to PAL
001092.697: HDMI:Setting property content type flag to No data
001092.717: HDMI:Setting property fuzzy format match to enabled
001336.494: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001336.530: hdmi: Setting state machine clock to 163682864 Hz
001337.583: hdmi: requested state machine clock @ 163682864 Hz, measured as 163683000 Hz
001337.599: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading EDID<<<<<<<<<<<<<
001337.896: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001339.156: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001340.417: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001341.678: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001342.939: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001344.200: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001345.461: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001346.722: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001347.983: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001349.244: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001350.268: hdmi: HDMI:EDID giving up on reading EDID block 0
001350.299: hdmi: HDMI: No lookup table for resolution group 0
001350.318: hdmi: HDMI: hotplug attached with DVI support
001350.348: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001350.639: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001351.901: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001353.165: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001354.428: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001355.691: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001356.954: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001358.217: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001359.480: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001360.743: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001362.006: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001363.032: hdmi: HDMI:EDID giving up on reading EDID block 0
001365.378: hdmi: HDMI: hotplug deassert
001365.391: hdmi: HDMI: HDMI is currently off
001365.403: hdmi: HDMI: changing mode to unplugged
001365.427: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001368.476: *** Restart logging
001370.341: Read command line from file 'cmdline.txt'
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=c0ac452a-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootdelay=20 rootwait
001628.563: Loading 'kernel7.img' to 0x8000 size 0x409fd8
001629.523: No kernel trailer (run mkknlimg to fix) - assuming DT-capable
001637.487: Loading 'bcm2710-rpi-3-b.dtb' to 0x411fd8 size 0x3e78
001737.854: dtparam: i2c_arm=on
002834.314: Device tree loaded to 0x2effbc00 (size 0x4377)
002839.836: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
003598.516: vchiq_core: vchiq_init_state: slot_zero = 0xfac80000, is_master = 1
003602.780: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
003604.043: cec: setting callback (0x3DCA9D08)

4.9.11-v7+ armv7l

Code: Select all

001065.631: HDMI:EDID error reading EDID block 0 attempt 0
001066.894: HDMI:EDID error reading EDID block 0 attempt 1
001068.152: HDMI:EDID error reading EDID block 0 attempt 2
001069.410: HDMI:EDID error reading EDID block 0 attempt 3
001070.668: HDMI:EDID error reading EDID block 0 attempt 4
001071.926: HDMI:EDID error reading EDID block 0 attempt 5
001073.184: HDMI:EDID error reading EDID block 0 attempt 6
001074.442: HDMI:EDID error reading EDID block 0 attempt 7
001075.699: HDMI:EDID error reading EDID block 0 attempt 8
001076.957: HDMI:EDID error reading EDID block 0 attempt 9
001077.978: HDMI:EDID giving up on reading EDID block 0
001092.632: HDMI:Setting property pixel encoding to Default
001092.652: HDMI:Setting property pixel clock type to PAL
001092.671: HDMI:Setting property content type flag to No data
001092.691: HDMI:Setting property fuzzy format match to enabled
001336.472: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001336.508: hdmi: Setting state machine clock to 163682864 Hz
001337.561: hdmi: requested state machine clock @ 163682864 Hz, measured as 163683000 Hz
001337.577: hdmi: HDMI:>>>>>>>>>>>>>Rx sensed, reading EDID<<<<<<<<<<<<<
001337.874: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001339.134: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001340.395: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001341.656: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001342.917: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001344.178: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001345.439: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001346.700: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001347.961: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001349.222: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001350.246: hdmi: HDMI:EDID giving up on reading EDID block 0
001350.278: hdmi: HDMI: No lookup table for resolution group 0
001350.296: hdmi: HDMI: hotplug attached with DVI support
001350.327: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001350.617: hdmi: HDMI:EDID error reading EDID block 0 attempt 0
001351.879: hdmi: HDMI:EDID error reading EDID block 0 attempt 1
001353.143: hdmi: HDMI:EDID error reading EDID block 0 attempt 2
001354.406: hdmi: HDMI:EDID error reading EDID block 0 attempt 3
001355.669: hdmi: HDMI:EDID error reading EDID block 0 attempt 4
001356.932: hdmi: HDMI:EDID error reading EDID block 0 attempt 5
001358.195: hdmi: HDMI:EDID error reading EDID block 0 attempt 6
001359.458: hdmi: HDMI:EDID error reading EDID block 0 attempt 7
001360.721: hdmi: HDMI:EDID error reading EDID block 0 attempt 8
001361.984: hdmi: HDMI:EDID error reading EDID block 0 attempt 9
001363.010: hdmi: HDMI:EDID giving up on reading EDID block 0
001365.356: hdmi: HDMI: hotplug deassert
001365.369: hdmi: HDMI: HDMI is currently off
001365.381: hdmi: HDMI: changing mode to unplugged
001365.405: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
001368.453: *** Restart logging
001370.270: Read command line from file 'cmdline.txt'
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=c0ac452a-01 rootfstype=ext4 elevator=deadline fsck.repair=yes rootdelay=20 rootwait
001653.010: Loading 'kernel7.img' to 0x8000 size 0x45cec8
001653.970: No kernel trailer (run mkknlimg to fix) - assuming DT-capable
001660.617: Loading 'bcm2710-rpi-3-b.dtb' to 0x464ec8 size 0x4262
001771.147: dtparam: i2c_arm=on
002884.691: Device tree loaded to 0x2effb800 (size 0x4769)
002890.198: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
004402.257: vchiq_core: vchiq_init_state: slot_zero = 0xfa980000, is_master = 1
004406.402: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
004407.652: cec: setting callback (0x3DCA9D08)

Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 9:18 pm

Hmmm. I don't see anything that is clearly wrong there. The Device Tree stuff gets loaded to different locations, but I don't think that's necessarily a problem? I suppose you could dig into the picofssd code to see if there is a problem there or if it's producing any errors, but why bother if i2cget/i2cset aren't working.

If it will help, I could take out my UPS PIco HV 1.0 and set it up on my Pi2B to see if that still works with the 4.9.x kernel. I haven't used the UPS PIco or Pi2B in a long time and I'm not sure what all the differences might be between our different hardware versions.

Perhaps the RP engineers have some ideas.

notro
Posts: 692
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 10:01 pm

There's a fallback option:
config.txt

Code: Select all

dtoverlay=i2c-bcm2708
The i2c-bcm2835 driver has some debugging support to aid in tracking down issues. See this commit: i2c: bcm2835: Add debug support

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Tue Feb 21, 2017 10:07 pm

ktb wrote:Hmmm. I don't see anything that is clearly wrong there. The Device Tree stuff gets loaded to different locations, but I don't think that's necessarily a problem? I suppose you could dig into the picofssd code to see if there is a problem there or if it's producing any errors, but why bother if i2cget/i2cset aren't working.

If it will help, I could take out my UPS PIco HV 1.0 and set it up on my Pi2B to see if that still works with the 4.9.x kernel. I haven't used the UPS PIco or Pi2B in a long time and I'm not sure what all the differences might be between our different hardware versions.

Perhaps the RP engineers have some ideas.
My thought also, been flashing, trail and error entire day.
i2c is open as i can see the tables and call ports and deamon is running acording the led on the UPS which should be blinking fast and it doesn't without the deamon.
Clean install with only the necessary packages as per install manual is the closest i can get.
My best guess but can't find any evidence something has changed in the kernel which doesn't correspond with the ups firmware and there for those weird 0xff readings instead of normal byte reading.
The dev of the pico is going to look into it and hope to have a answer soon.

Feel free to try, but don't think it will help or maybe a little.
pcb and firmware are different and miles apart.
notro wrote:There's a fallback option:
config.txt

Code: Select all

dtoverlay=i2c-bcm2708
The i2c-bcm2835 driver has some debugging support to aid in tracking down issues. See this commit: i2c: bcm2835: Add debug support
Doesn't work, if i use it then rebooting hangs at eth in the booting process
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

cjan
Posts: 544
Joined: Sun May 06, 2012 12:00 am

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 10:20 am

cjan wrote:wifi dongle 8192cu module did not blinking.
indicator led light did not blinking.
and, after hours become drop & reconnect repeatedly.

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 10:36 am

Update:

I setup the UPS PIco HV 1.0 on my Pi2B -- updated UPS PIco firmware and all. I've run into the same if not similar issue.

One thing that may be of interest is that when I use

Code: Select all

dtparam=i2c_arm=on
dtoverlay=i2c-bcm2708
I do get the i2c-bcm2708 module to load instead of i2c-bcm2835, but things still don't work correctly/well. If I wait until everything loads (Pixel desktop in my case) and then press the UPSR (reset) button, things begin to work at least briefly (sudo i2cdetect -y 1 outputs quickly and the output looks good, hwclock -r and sudo python pico_status.py also work). Now, If I wait long enough those same commands begin to fail again (sudo i2cdetect -y 1 output crawls very slowly through each address, hwclock -r and sudo python pico_status.py both fail) at which point another UPSR (reset) press gets things working again.

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 10:41 am

ktb wrote:Update:

I setup the UPS PIco HV 1.0 on my Pi2B -- updated UPS PIco firmware and all. I've run into the same if not similar issue.

One thing that may be of interest is that when I use

Code: Select all

dtparam=i2c_arm=on
dtoverlay=i2c-bcm2708
I do get the i2c-bcm2708 module to load instead of i2c-bcm2835, but things still don't work correctly/well. If I wait till everything loads (Pixel desktop in my case) and then press the UPSR (reset) button, things begin to work at least briefly (sudo i2cdetect -y 1 outputs quickly and the output looks good, hwclock -r and sudo python pico_status.py also work). Now, If I wait long enough those same commands begin to fail again (sudo i2cdetect -y 1 output crawls very slowly through each address, hwclock -r and sudo python pico_status.py both fail) at which point another UPSR (reset) press gets things working again.
Thx for the feedback and reproducing.
It's indeed almost the same issue but the main difference is your i2cdetect is starting to fail while mine continues to work.
And reading i2c with i2cget 0x69 xxx only give 0xff readings while it should be a byte reading.
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 10:57 am

Siewert308SW wrote:
ktb wrote:Update:

I setup the UPS PIco HV 1.0 on my Pi2B -- updated UPS PIco firmware and all. I've run into the same if not similar issue.

One thing that may be of interest is that when I use

Code: Select all

dtparam=i2c_arm=on
dtoverlay=i2c-bcm2708
I do get the i2c-bcm2708 module to load instead of i2c-bcm2835, but things still don't work correctly/well. If I wait till everything loads (Pixel desktop in my case) and then press the UPSR (reset) button, things begin to work at least briefly (sudo i2cdetect -y 1 outputs quickly and the output looks good, hwclock -r and sudo python pico_status.py also work). Now, If I wait long enough those same commands begin to fail again (sudo i2cdetect -y 1 output crawls very slowly through each address, hwclock -r and sudo python pico_status.py both fail) at which point another UPSR (reset) press gets things working again.
Thx for the feedback and reproducing.
It's indeed almost the same issue but the main difference is your i2cdetect is starting to fail while mine continues to work.
And reading i2c with i2cget 0x69 xxx only give 0xff readings while it should be a byte reading.
Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget and UPSR resets make no difference whatsoever.

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 11:01 am

ktb wrote:
Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget too and UPSR resets make no difference whatsoever.
I understand, but now the million dollar question ;-)
Is it kernel or UPS related, thats something i couldn't figure out.
I can imagine something in the kernel has changed causing to fail on reading i2c or firmware of the ups isn't compatible in the difference on how it reads the i2c or vice versa?
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 11:13 am

Siewert308SW wrote:
ktb wrote:
Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget too and UPSR resets make no difference whatsoever.
I understand, but now the million dollar question ;-)
Is it kernel or UPS related, thats something i couldn't figure out.
I can imagine something in the kernel has changed causing to fail on reading i2c or firmware of the ups isn't compatible in the difference on how it reads the i2c or vice versa?
Well, there have been I2C changes in the kernel and it makes sense that the problems are caused by the combination of kernel and UPS firmware. It's difficult for me to pin blame solely on either one. The UPS firmware has always been a black box as far as I know. I also don't have any other I2C devices I can test against the kernel, so that makes it tougher to test that angle. EDIT: IIRC, the official touch display actually works over I2C because Eric had problems with using DSI.

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 11:19 am

ktb wrote:
Siewert308SW wrote:
ktb wrote:
Well, I get the same behavior as you if I don't use dtoverlay=i2c-bcm2708. Without dtoverlay=i2c-bcm2708, i2cdetect -y 1 always "works" (air quotes). However, it doesn't show 68 as in-use (UU). In this case I also always get 0xff readings from i2cget too and UPSR resets make no difference whatsoever.
I understand, but now the million dollar question ;-)
Is it kernel or UPS related, thats something i couldn't figure out.
I can imagine something in the kernel has changed causing to fail on reading i2c or firmware of the ups isn't compatible in the difference on how it reads the i2c or vice versa?
Well, there have been I2C changes in the kernel and it makes sense that the problems are caused by the combination of kernel and UPS firmware. It's difficult for me to pin blame solely on either one. The UPS firmware has always been a black box as far as I know. I also don't have any other I2C devices I can test against the kernel, so that makes it tougher to test that angle.
I see and no worries, appreciate your effort and confirming.
I can't test other i2c devices and don't have the knowledge to debug the ups and kernel combination.
Lets hope someone else can fix it or until the ups dev ran into the same issue as it will happen in the near future.
Until then i'll have to stick to 4.4.50 #bummer

thx in advanced
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1677
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 1:33 pm

I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 6:36 pm

PhilE wrote:I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.
Will do, hope tomorrow if i'm home early otherwise it will be friday
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 7:59 pm

PhilE wrote:I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.
Hi PhilE,

Here you go -- http://pastebin.com/AJjsJ82h

Thank you.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1677
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 8:24 pm

Thanks. It's interesting how the RTC driver (or the I2C subsystem on its behalf) keeps on repeating the same transaction, even though there's no obvious error. I've no idea yet why that is, but your trace takes us much closer to an answer.

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 11:23 pm

PhilE wrote:I know this doesn't help you, but I2C isn't completely dead. The Sense HAT seems to work as normal - display, compass, joystick etc. - as does an I2C RTC.

1) Make sure you don't load the i2c-bcm2708 driver - no overlay, not in /etc/modules.
2) Add " i2c_bcm2835.debug=3" to /boot/cmdline.txt.
3) Reboot.
4) Try to access the UPS devices via i2cget etc., then dump the output of dmesg into a text file and upload it where we can see it.
Just a little bit earlier then expected.
But here are my findings.

Information on 4.4.50 PI3 in working condition:
Some screenshots while running 4.4.50 kernel on my Pi3.
On which everything is working as it should be.
When doing i2cget -y 1 0x69 0x26 i get a output of 0x24, in this case i read the current firmware version

System Info:
Image
https://dl.dropboxusercontent.com/u/232 ... ebug_1.png


UPS HV3.0A Stack Plus:
Image
https://dl.dropboxusercontent.com/u/232 ... ebug_2.png

i2cdetect -y 1 output

Code: Select all

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU 69 6a 6b 6c 6d 6e 6f
70: -- -- -- -- -- -- -- --

Next i went into /etc/modules and comment out all driver loads.
Only let i2c-dev untouched and added i2c_bcm2835.debug=3 to the cmdline.txt
Connected to the UPS by i2cget -y 1 0x69 0x26.
Output : http://pastebin.com/bJjGzBev

Information on 4.9.11 PI3 in non working condition:
Next i ran rpi-update and upgraded to 4.9.11-v7+ armv7l
Rebooted and and connected to the UPS by i2cget -y 1 0x69 0x26 i got a output of 0xff which should output 0x24
Output : http://pastebin.com/f9vXqqhn

i2cdetect -y 1 output on 4.9.11

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 69 6a 6b 6c 6d 6e 6f
70: -- -- -- -- -- -- -- --
edit: Just notice that after doing i2cget -y 1 0x69 0x26 it also wrote instead of reading.
After returning to 4.4.50 a saw it wrote 0xde to the ups, weird...
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Wed Feb 22, 2017 11:56 pm

Siewert308SW wrote:edit: Just notice that after doing i2cget -y 1 0x69 0x26 it also wrote instead of reading.
After returning to 4.4.50 a saw it wrote 0xde to the ups, weird...
Hmm... Very interesting.

It's also good to hear that the Sense HAT is working properly. I don't think the touch display uses the same i2c bus, but the display has been working well enough for me in general on 4.9.x.

notro
Posts: 692
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Moving Linux kernel to 4.9

Thu Feb 23, 2017 12:10 am

Trace events/points can also be used to debug i2c. One benefit is that it displays the content of the buffer.
I have nothing connected here, just showing what it looks like:

Code: Select all

$ echo 1 | sudo tee /sys/kernel/debug/tracing/events/i2c/enable

$ i2cget -y 1 0x69 0x26
Error: Read failed

$ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 6/6   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          i2cget-792   [002] ....    64.249432: smbus_read: i2c-1 a=069 f=0000 c=26 BYTE_DATA
          i2cget-792   [002] ....    64.249445: i2c_write: i2c-1 #0 a=069 f=0000 l=1 [26]
          i2cget-792   [002] ....    64.249448: i2c_read: i2c-1 #1 a=069 f=0001 l=1
          i2cget-792   [002] ....    64.249707: i2c_result: i2c-1 n=0 ret=-121
          i2cget-792   [002] ....    64.249711: smbus_reply: i2c-1 a=069 f=0000 c=26 BYTE_DATA l=1 [0a]
          i2cget-792   [002] ....    64.249714: smbus_result: i2c-1 a=069 f=0000 c=26 BYTE_DATA rd res=-121

# clear trace buffer
$ echo | sudo tee /sys/kernel/debug/tracing/trace
Refs:
https://linuxtv.org/wiki/index.php/Bus_ ... iffing#i2c
https://www.kernel.org/doc/Documentatio ... events.txt

ktb
Posts: 1380
Joined: Fri Dec 26, 2014 7:53 pm

Re: Moving Linux kernel to 4.9

Thu Feb 23, 2017 2:56 am

Thank you very much, notro. I don't think it provides any further explanation of what's going wrong in this case, but that seems like a valuable feature. I was not aware of it.

Code: Select all

pi@raspberrypi:~ $ sudo cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 28/28   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          i2cget-2620  [003] .... 25755.444984: smbus_read: i2c-1 a=069 f=0000 c=0 BYTE_DATA
          i2cget-2620  [003] .... 25755.445006: i2c_write: i2c-1 #0 a=069 f=0000 l=1 [00]
          i2cget-2620  [003] .... 25755.445010: i2c_read: i2c-1 #1 a=069 f=0001 l=1
          i2cget-2620  [003] .... 25755.445681: i2c_reply: i2c-1 #1 a=069 f=0001 l=1 [ff]
          i2cget-2620  [003] .... 25755.445687: i2c_result: i2c-1 n=2 ret=2
          i2cget-2620  [003] .... 25755.445693: smbus_reply: i2c-1 a=069 f=0000 c=0 BYTE_DATA l=1 [ff]
          i2cget-2620  [003] .... 25755.445697: smbus_result: i2c-1 a=069 f=0000 c=0 BYTE_DATA rd res=0
          i2cget-2637  [003] .... 25825.097963: smbus_read: i2c-1 a=069 f=0000 c=0 BYTE_DATA
          i2cget-2637  [003] .... 25825.097984: i2c_write: i2c-1 #0 a=069 f=0000 l=1 [00]
          i2cget-2637  [003] .... 25825.097989: i2c_read: i2c-1 #1 a=069 f=0001 l=1
          i2cget-2637  [003] .... 25825.098620: i2c_reply: i2c-1 #1 a=069 f=0001 l=1 [ff]
          i2cget-2637  [003] .... 25825.098629: i2c_result: i2c-1 n=2 ret=2
          i2cget-2637  [003] .... 25825.098636: smbus_reply: i2c-1 a=069 f=0000 c=0 BYTE_DATA l=1 [ff]
          i2cget-2637  [003] .... 25825.098640: smbus_result: i2c-1 a=069 f=0000 c=0 BYTE_DATA rd res=0
          i2cget-2654  [002] .... 25991.176494: smbus_read: i2c-1 a=06b f=0000 c=0 BYTE_DATA
          i2cget-2654  [002] .... 25991.176515: i2c_write: i2c-1 #0 a=06b f=0000 l=1 [00]
          i2cget-2654  [002] .... 25991.176519: i2c_read: i2c-1 #1 a=06b f=0001 l=1
          i2cget-2654  [002] .... 25991.177173: i2c_reply: i2c-1 #1 a=06b f=0001 l=1 [ff]
          i2cget-2654  [002] .... 25991.177179: i2c_result: i2c-1 n=2 ret=2
          i2cget-2654  [002] .... 25991.177185: smbus_reply: i2c-1 a=06b f=0000 c=0 BYTE_DATA l=1 [ff]
          i2cget-2654  [002] .... 25991.177189: smbus_result: i2c-1 a=06b f=0000 c=0 BYTE_DATA rd res=0
          i2cget-2662  [002] .... 25994.847091: smbus_read: i2c-1 a=06b f=0000 c=1 BYTE_DATA
          i2cget-2662  [002] .... 25994.847111: i2c_write: i2c-1 #0 a=06b f=0000 l=1 [01]
          i2cget-2662  [002] .... 25994.847116: i2c_read: i2c-1 #1 a=06b f=0001 l=1
          i2cget-2662  [002] .... 25994.847750: i2c_reply: i2c-1 #1 a=06b f=0001 l=1 [ff]
          i2cget-2662  [002] .... 25994.847757: i2c_result: i2c-1 n=2 ret=2
          i2cget-2662  [002] .... 25994.847762: smbus_reply: i2c-1 a=06b f=0000 c=1 BYTE_DATA l=1 [ff]
          i2cget-2662  [002] .... 25994.847767: smbus_result: i2c-1 a=06b f=0000 c=1 BYTE_DATA rd res=0

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1677
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux kernel to 4.9

Thu Feb 23, 2017 12:26 pm

The debug logs from the driver don't include enough information to distinguish success from failure, so notro's tracing method looks like a better bet.

Put this in a file called trace:

Code: Select all

echo 1 | sudo tee /sys/kernel/debug/tracing/events/i2c/enable
sudo cat /sys/kernel/debug/tracing/trace
Running ". trace" will then enable tracing and print out the current contents.

@ktb Can you enable tracing then read from the RTC?

Code: Select all

. trace
sudo hwclock -r
. trace > trace.txt

User avatar
Siewert308SW
Posts: 33
Joined: Fri Feb 27, 2015 1:31 pm
Location: The Netherlands
Contact: Website

Re: Moving Linux kernel to 4.9

Thu Feb 23, 2017 12:32 pm

PhilE wrote:The debug logs from the driver don't include enough information to distinguish success from failure, so notro's tracing method looks like a better bet.

Put this in a file called trace:

Code: Select all

echo 1 | sudo tee /sys/kernel/debug/tracing/events/i2c/enable
sudo cat /sys/kernel/debug/tracing/trace
Running ". trace" will then enable tracing and print out the current contents.

@ktb Can you enable tracing then read from the RTC?

Code: Select all

. trace
sudo hwclock -r
. trace > trace.txt
So even my log posted earlier doesn't help?

Should we do the trace without the modules loaded and i2c_bcm2835.debug=3 enabled?
Setup:
- RPi3 - PIco HV3.0A / Domo Beta 3.9XXX / RFXtrx433E / Aeotec Gen5
- RPi3 - PIco HV3.0A / PiHole / PiVPN / NAS / Print Server
- Youless Elec&Gas
- FI9803P Cams
- KD101 detectors
- Zwave & KaKu

https://github.com/Siewert308SW

Return to “Advanced users”

Who is online

Users browsing this forum: No registered users and 4 guests