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
Do you have any messages from owc driver?
Created attachment 209813 [details] dmesg output
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
What specific device do you have on the bus? Could you please also show output of sysctl hw.ow.regular?
(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
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
(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
Is it still a bug or should I close it ?
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.
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.
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
(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!
(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!
The bug is no more valid for the hardware it was initially disclosed on. Thanks for resolving.
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