daily CVS update output
Updating src tree: P src/sys/arch/arm/fdt/pmu_fdt.c P src/sys/kern/kern_auth.c P src/sys/kern/kern_mutex_obj.c P src/sys/kern/kern_rwlock_obj.c P src/sys/kern/vfs_cache.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 39185745 Oct 3 03:03 ls-lRA.gz
Re: urndis and tethering on a Google Pixel 6 phone (or not)
On October 3, 2023 2:49:54 AM GMT+09:00, David Brownlee wrote: >Has anyone been able to tether using urndis on a Google Pixel 6? > >It's not picked up automatically, and just as a test I added it(*) to >urndis_devs in sys/dev/usb/if_urndis.c, but it doesn't complete >autoconfig - I suspect it might need to be poked in some special way >to actually be an urndis, or else is now a new-new-linux-urndis2 thing > >ugen2: Google (0x18d1) Pixel 6 (0x4ee1), rev 2.10/5.10, addr 5 >acpibat0: normal capacity on 'charge state' >ugen2: detached >ugen2: at uhub4 port 1 (addr 5) disconnected >urndis0 at uhub4 port 1 configuration 1 interface 0 >urndis0: Google (0x18d1) Pixel 6 (0x4eeb), rev 2.10/5.10, addr 5 >urndis0: STALLED >urndis0: init failed >autoconfiguration error: urndis0: unable to initialize hardware > >(*) The phone attaches as multiple devices based on whether it's >trying to offer USB tether, combined with whether USB debug is >enabled. > >David Hi, I have Google Pixel 7a and it does not offer urndis(4) device anymore. It provides USB NCM device for USB tethering. It seems that FreeBSD's cdce(4) device driver has NCM support. However I have not tested it yet. I suspect that Pixel 6a also offers NCM device. Thank you. -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: panic: assertion "!cpu_softintr_p()" failed
Hi, On Sun, Oct 01, 2023 at 10:12:47AM +0200, Thomas Klausner wrote: > panic: kernel diagnostic assertion "!cpu_softintr_p()" failed: file > "/usr/src/sys/kern/subr_kmem.c", line 451 Sorry about that. Should be fixed by: /cvsroot/src/sys/kern/kern_mutex_obj.c,v <-- kern_mutex_obj.c new revision: 1.15; previous revision: 1.14 /cvsroot/src/sys/kern/kern_rwlock_obj.c,v <-- kern_rwlock_obj.c new revision: 1.13; previous revision: 1.12 Cheers, Andrew
urndis and tethering on a Google Pixel 6 phone (or not)
Has anyone been able to tether using urndis on a Google Pixel 6? It's not picked up automatically, and just as a test I added it(*) to urndis_devs in sys/dev/usb/if_urndis.c, but it doesn't complete autoconfig - I suspect it might need to be poked in some special way to actually be an urndis, or else is now a new-new-linux-urndis2 thing ugen2: Google (0x18d1) Pixel 6 (0x4ee1), rev 2.10/5.10, addr 5 acpibat0: normal capacity on 'charge state' ugen2: detached ugen2: at uhub4 port 1 (addr 5) disconnected urndis0 at uhub4 port 1 configuration 1 interface 0 urndis0: Google (0x18d1) Pixel 6 (0x4eeb), rev 2.10/5.10, addr 5 urndis0: STALLED urndis0: init failed autoconfiguration error: urndis0: unable to initialize hardware (*) The phone attaches as multiple devices based on whether it's trying to offer USB tether, combined with whether USB debug is enabled. David
re: 10.99.9 amd64 panic
Martin Husemann writes:
> On Fri, Sep 29, 2023 at 09:52:42AM +, Chavdar Ivanov wrote:
> > Sep 29 01:53:13 ymir /netbsd: [ 228407.9443196] panic: kernel diagnostic
> > assertion "offset < map->dm_mapsize" failed: file
> > "/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset 0x0 >=
> > 0x0
> [..]
> > Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] bus_dmamap_sync() at
> > netbsd:bus_dmamap_sync+0x326
> > Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] rge_rxeof() at
> > netbsd:rge_rxeof+0x179
>
> This is a bug in the rge(4) driver (unrelated to userland resource usage
> by the build), maybe a race triggered more easily when the system is
> under heavey load.
hmm, this seems like corruption to me.
> bus_dma.c", line 826 bad offset 0x0 >= 0x0
says that offset == 0 (which is right, this seem to this call):
1241 /* Invalidate the RX mbuf and unload its map. */
1242 bus_dmamap_sync(sc->sc_dmat, rxq->rxq_dmamap, 0,
1243 rxq->rxq_dmamap->dm_mapsize, BUS_DMASYNC_POSTREAD);
offset is the 0 / 3rd arg here, but the *second* 0x0 value here
seems to be corrupted, and shouldn't be zero. ie, there's no
case where it will create a zero-length dma map, it should always
be either RGE_TX_LIST_SZ, RGE_RX_LIST_SZ, or RGE_JUMBO_FRAMELEN,
so for this assert to trigger saying the passed offset is beyond
the mapping, because the mapping is zero length, seems to be
pretty clear that the bus_dmamap_t has been corrupted.
the timing does seem to indicate that a problem with out of
memory may be relevant here..oh, i think i may see a problem.
1110 rge_newbuf(struct rge_softc *sc, int idx)
...
1126 if (bus_dmamap_load_mbuf(sc->sc_dmat, rxmap, m, BUS_DMA_NOWAIT))
1127 goto out;
...
1151 out:
1152 if (m != NULL)
1153 m_freem(m);
1154 return (ENOMEM);
so, if bus_dmamap_load_mbuf() fails, we return ENOMEM, not
ENOBUFS. however, the callers only consider ENOBUFS as an
error case:
1176 rge_rx_list_init(struct rge_softc *sc)
...
1184 if (rge_newbuf(sc, i) == ENOBUFS)
1185 return (ENOBUFS);
and
1212 rge_rxeof(struct rge_softc *sc)
...
1271 if (rge_newbuf(sc, i) == ENOBUFS) {
so in this case, the code thinks a buffer was allocated, but it
wasn't... i haven't gone deeping into what this may cause the
code to do wrong yet, but it seems problematic.
certainly, both callers should check for != 0, not == ENOBUFS,
to avoid this problem.
.mrg.
Re: cgd questions
w...@netbsd.org (Thomas Klausner) writes: >Follow up question because it just happened to me: >I have a USB Disk with ffs-on-cgd. I unmounted the ffs but forgot >unconfiguring the cgd before unplugging the disk. >Can this cause problems? What kinds? Shouldn't do any harm, there is no state on the disk but the data itself and FFS has already flushed everything and waited for completion. The cgd device probably doesn't detach immediately and an attempt to use it may crash the system. But unconfiguring it immediately after should be safe.
Re: panic: assertion "!cpu_softintr_p()" failed
On Mon, Oct 02, 2023 at 09:23:59AM +1100, Matthew Green wrote: > Thomas Klausner writes: > > panic: kernel diagnostic assertion "!cpu_softintr_p()" failed: file > > "/usr/src/sys/kern/subr_kmem.c", line 451 > > > > gdb says: > > > > #10 0x80e3551e in vpanic (fmt=0x813a1880 "kernel > > %sassertion \"%s\" failed: file \"%s\", line %d ", > > ap=ap@entry=0xae2110a93e08) > > at /usr/src/sys/kern/subr_prf.c:286 > > #11 0x80ffab6f in kern_assert (fmt=fmt@entry=0x813a1880 > > "kernel %sassertion \"%s\" failed: file \"%s\", line %d ") > > at /usr/src/sys/lib/libkern/kern_assert.c:51 > > #12 0x80e27e15 in kmem_free (p=0x9afa82af5b80, size=64) at > > /usr/src/sys/kern/subr_kmem.c:451 > > #13 0x80df5960 in rw_obj_free (lock=0x9afa82af5b80) at > > /usr/src/sys/kern/kern_rwlock_obj.c:127 > > #14 0x80d825d3 in uvm_anon_release (anon=) at > > /usr/src/sys/uvm/uvm_anon.c:385 > > i think this is a new bug. this line changed from: > > 1.11 (ad 12-Sep-23): pool_cache_put(rw_obj_cache, ro); > > to > > 1.12 (ad 23-Sep-23): kmem_free(ro, sizeof(*ro)); > > i guess it just should be kmem_free_intr(), as pool_cache > is intr-safe as well. Thanks, I'll try a kernel with the attached diff. Thomas Index: kern_rwlock_obj.c === RCS file: /cvsroot/src/sys/kern/kern_rwlock_obj.c,v retrieving revision 1.12 diff -u -r1.12 kern_rwlock_obj.c --- kern_rwlock_obj.c 23 Sep 2023 18:21:11 - 1.12 +++ kern_rwlock_obj.c 2 Oct 2023 07:51:31 - @@ -124,7 +124,7 @@ } membar_acquire(); rw_destroy(>ro_lock); - kmem_free(ro, sizeof(*ro)); + kmem_intr_free(ro, sizeof(*ro)); return true; }
Re: cgd questions
Follow up question because it just happened to me: I have a USB Disk with ffs-on-cgd. I unmounted the ffs but forgot unconfiguring the cgd before unplugging the disk. Can this cause problems? What kinds? Thomas
