Bug 242526 - ow_temp(4) device on RPi2 disappeared for 13-CURRENT after r354076
Summary: ow_temp(4) device on RPi2 disappeared for 13-CURRENT after r354076
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Only Me
Assignee: Ian Lepore
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-12-09 19:01 UTC by Marek Zarychta
Modified: 2019-12-22 19:30 UTC (History)
2 users (show)

See Also:


Attachments
dmesg output (6.24 KB, text/plain)
2019-12-09 20:49 UTC, Marek Zarychta
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Zarychta 2019-12-09 19:01:33 UTC
I was still running a snapshot of 13.0-CURRENT from August on my RPi2 so on the weekend I performed the update. I found that after update my dev.ow_temp device is no longer visible on 1 Wire Bus. This regression is still valid for fresh r355563 13.0-CURRENT.
While bisectioninig and performing subsequent build I disclosed that this breakage was caused by r354076
Comment 1 Andriy Gapon freebsd_committer 2019-12-09 20:28:52 UTC
Do you have any messages from owc driver?
Comment 2 Marek Zarychta 2019-12-09 20:49:14 UTC
Created attachment 209813 [details]
dmesg output
Comment 3 Marek Zarychta 2019-12-09 21:35:05 UTC
Comment on attachment 209813 [details]
dmesg output

Multipe "oops, starting over" message replaced prevoiusly visible :
ow_temp0: <Advanced One Wire Temperature> romid 28:13:34:c3:03:00:00:d2 on ow0
Comment 4 Andriy Gapon freebsd_committer 2019-12-10 07:56:04 UTC
What specific device do you have on the bus?

Could you please also show output of sysctl hw.ow.regular?
Comment 5 Marek Zarychta 2019-12-10 11:20:38 UTC
(In reply to Andriy Gapon from comment #4)

At the moment I have only one DS18B20 sensor connected to 1-wire bus. It was measuring temperature fine on 13.0-CURRENT up to revison 354075

% sysctl  hw.ow.regular
hw.ow.regular.t_lowr: 1
hw.ow.regular.t_pdh: 60
hw.ow.regular.t_pdl: 60
hw.ow.regular.t_rsth: 480
hw.ow.regular.t_rstl: 480
hw.ow.regular.t_rdv: 15
hw.ow.regular.t_rec: 15
hw.ow.regular.t_release: 45
hw.ow.regular.t_low1: 1
hw.ow.regular.t_low0: 60
hw.ow.regular.t_slot: 60
Comment 6 Andriy Gapon freebsd_committer 2019-12-10 12:27:14 UTC
Do you have one-wire drivers compiled into kernel or do you load them as modules?
Can you try to manually (re-)load them after the system is booted up?
E.g.:
kldunload ow_temp owc
kldload owc ow_temp
Comment 7 Marek Zarychta 2019-12-10 12:43:59 UTC
(In reply to Andriy Gapon from comment #6)

Thanks for the clue. I can confirm, that loading these modules after bootup resolves the issue. I was loading them from loader.conf
Comment 8 Marek Zarychta 2019-12-10 12:56:00 UTC
Is it still a bug or should I close it ?
Comment 9 Andriy Gapon freebsd_committer 2019-12-10 12:58:23 UTC
I think that it is a bug.
It's good that there is a workaround.
I will try to figure out what can cause the problem during the boot.
Seems like it can be an issue with either measuring of time or running the DELAY loop.
Comment 10 Marek Zarychta 2019-12-10 20:51:22 UTC
It doesn't look like a device specific flaw. Testing D22710 on Pine64-LTS board I was able to get ow_temp(4) working there, but get the same results. So the modules have to be loaded after boot otherwise only a few "oops, starting over" messages appear.
Comment 11 commit-hook freebsd_committer 2019-12-10 21:49:00 UTC
A commit references this bug:

Author: ian
Date: Tue Dec 10 21:48:22 UTC 2019
New revision: 355598
URL: https://svnweb.freebsd.org/changeset/base/355598

Log:
  Do not attach children of owc_gpiobus until interrupts are working.

  The children of the bus need to do IO on the bus to probe for hardware
  presence.  Doing IO means timing the bus states using sbinuptime(), and
  that requires working timecounters, which are not initialized until after
  device attachment has completed.

  PR:		242526

Changes:
  head/sys/dev/ow/owc_gpiobus.c
Comment 12 Andriy Gapon freebsd_committer 2019-12-11 15:01:42 UTC
(In reply to Marek Zarychta from comment #10)
Yes, it was not specific to any end device, it was an issue with the 1-wire driver.
Could you please test if after Ian's change you can again use the drivers as you did before?
Thanks!
Comment 13 Marek Zarychta 2019-12-11 15:30:14 UTC
(In reply to Andriy Gapon from comment #12)
I was able to test it on Pine64 so far and can confirm that Ian's fix solves the issue. If Raspberry Pi 2 will be also fine with this patch, I will close the bug.
Thank you for sorting this out in such a fast track!
Comment 14 Marek Zarychta 2019-12-11 19:23:38 UTC
The bug is no more valid for the hardware it was initially disclosed on. Thanks for resolving.
Comment 15 commit-hook freebsd_committer 2019-12-22 19:30:54 UTC
A commit references this bug:

Author: ian
Date: Sun Dec 22 19:30:15 UTC 2019
New revision: 356022
URL: https://svnweb.freebsd.org/changeset/base/356022

Log:
  MFC r355598, r355727, r355735, r355858

  r355598:
  Do not attach children of owc_gpiobus until interrupts are working.

  The children of the bus need to do IO on the bus to probe for hardware
  presence.  Doing IO means timing the bus states using sbinuptime(), and
  that requires working timecounters, which are not initialized until after
  device attachment has completed.

  PR:		242526

  r355727 (by imp):
  Create new wrapper function: bus_delayed_attach_children()

  Delay the attachment of children, when requested, until after interrutps are
  running. This is often needed to allow children to run transactions on i2c or
  spi busses. It's a common enough idiom that it will be useful to have its own
  wrapper.

  Reviewed by: ian
  Differential Revision: https://reviews.freebsd.org/D21465

  r355735 (by imp):
  Be consistent about checking return value from bus_delayed_attach_children.

  Most places checked, but a couple last minute changes didn't. Make them all use
  the return value.

  Noticed by: rpokala@

  r355858:
  Update owc_gpiobus (one-wire over gpio) to the modern gpio_pin interface.

  It used to be required that a device be a child of gpiobus(4) to manipulate
  gpio pins. That requirement didn't work well for FDT-based systems with many
  cross-hierarchy users of gpio, so a more modern framework was created that
  removed the old hierarchy requirement.

  These changes adapt the owc_gpiobus driver to use the newer gpio_pin_*
  functions to acquire, release, and manipulate gpio pins. This allows a
  single driver to work for both hinted-attachment and fdt-based systems, and
  removes the requirement that any one-wire fdt nodes must appear at the root
  of the devicetree.

  Differential Revision:	https://reviews.freebsd.org/D22710

Changes:
_U  stable/12/
  stable/12/share/man/man9/Makefile
  stable/12/share/man/man9/bus_delayed_attach_children.9
  stable/12/sys/arm/broadcom/bcm2835/bcm2835_bsc.c
  stable/12/sys/arm/freescale/imx/imx_i2c.c
  stable/12/sys/arm/freescale/imx/imx_spi.c
  stable/12/sys/arm/ti/ti_i2c.c
  stable/12/sys/dev/glxiic/glxiic.c
  stable/12/sys/dev/ichsmb/ichsmb.c
  stable/12/sys/dev/ow/owc_gpiobus.c
  stable/12/sys/kern/subr_bus.c
  stable/12/sys/sys/bus.h