artifact.ci's head -r357545 kernel for 32-bit powerpc FreeBSD vs. 64-bit PowerMac: panic: lock tfo_ccache_bucket . . . already initialized
On a 32-bit PowerMac 2 socket machine, it booted
just fine. This is a 64-bit capable 2 socket,
2 cores each, PowerMac context for the example
failure.
There is also an odd "kern.ipc.nmbclusters limit
reached" message before the powerpc64 panic.
Typed from a picture of the screen:
(I omit stack addresses and routine offsets
in the backtrace.)
. . .
firewire0: bus manager 1
bge0: link state changed to UP
[zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
panic: lock "tfo_ccache_bucket" 0xdd533f24 already initialized
cpuid = 0
time = 1
KDB: stack backtrace
. . .
panic
lock_init
_mtx_init
tcp_fastopen_init
tcp_init
protosw_init
vnet_domain_init
vnet_register_sysinit
mi_startup
btext
KDB: enter: panic
[ thread pid 0 tid 10 ]
. . .
This is too early for user input to the
db> prompt on PowerMacs.
The loop in tcp_fastopen_init(void) seems to
be:
for (i = 0; i < V_tcp_fastopen_ccache.buckets; i++) {
TAILQ_INIT(_tcp_fastopen_ccache.base[i].ccb_entries);
mtx_init(_tcp_fastopen_ccache.base[i].ccb_mtx,
"tfo_ccache_bucket",
NULL, MTX_DEF);
if (V_tcp_fastopen_client_enable) {
/* enable bucket */
V_tcp_fastopen_ccache.base[i].ccb_num_entries = 0;
} else {
/* disable bucket */
V_tcp_fastopen_ccache.base[i].ccb_num_entries = -1;
}
V_tcp_fastopen_ccache.base[i].ccb_ccache =
_tcp_fastopen_ccache;
}
Separately, the warning:
[zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
also seems odd. The powerpc64 FreeBSD variant does not
get this message.
It leaves me wondering if the 32-bit FreeBSD
atomic_fetchadd_64 and smp_started
cross-socket/cross-core value synchronization
are working fully-correctly on 64-bit PowerMacs.
However, I'm outside of my area, so take the
below on such a basis.
It does appear to me that the SMP case for the
!smp__started yet context does not have code for
s=intr_disable() and intr_restore(s) . (Not
limited to atomic_fetchadd_64.) Such disable/restore
code is only present for the !SMP case.
How strongly is the !smp_started temporary-context
like the !SMP case as far as what it requires for
correctness?
FYI:
008fc99c mflrr0
008fc9a0 stw r0,4(r1)
008fc9a4 stwur1,-32(r1)
008fc9a8 stw r31,28(r1)
008fc9ac stw r30,24(r1)
008fc9b0 mr r31,r1
008fc9b4 stw r26,8(r31)
008fc9b8 stw r27,12(r31)
008fc9bc stw r28,16(r31)
008fc9c0 stw r29,20(r31)
008fc9c4 bl 008fc9c8
008fc9c8 mr r27,r3
008fc9cc mflrr30
008fc9d0 addis r30,r30,80
008fc9d4 addir30,r30,8180
008fc9d8 mr r28,r6
008fc9dc mr r3,r27
008fc9e0 mr r29,r5
008fc9e4 bl 0093e668
008fc9e8 lwz r4,-32768(r30)
008fc9ec rlwinm r3,r3,25,24,31
008fc9f0 mulli r26,r3,20
008fc9f4 lwz r4,0(r4)
008fc9f8 cmplwi r4,0
008fc9fc beq-008fca1c
008fca00 lwz r3,-32764(r30)
008fca04 lwz r5,-32760(r30)
008fca08 li r4,0
008fca0c li r6,101
008fca10 add r3,r3,r26
008fca14 addir3,r3,16
008fca18 bl 0051b0b0 <__mtx_lock_flags>
008fca1c lwz r3,4(r27)
008fca20 lwz r4,0(r27)
008fca24 addcr3,r3,r28
008fca28 stw r3,4(r27)
008fca2c adder3,r4,r29
008fca30 stw r3,0(r27)
008fca34 lwz r3,-32768(r30)
008fca38 lwz r4,4(r27)
008fca3c lwz r5,0(r27)
008fca40 lwz r3,0(r3)
008fca44 subfc r28,r28,r4
008fca48 subfe r29,r29,r5
008fca4c cmplwi r3,0
008fca50 beq-008fca70
008fca54 lwz r3,-32764(r30)
008fca58 lwz r5,-32760(r30)
008fca5c li r4,0
008fca60 li r6,101
008fca64 add r3,r3,r26
008fca68 addir3,r3,16
008fca6c bl 0051b780 <__mtx_unlock_flags>
008fca70 mr r3,r29
008fca74 mr r4,r28
008fca78 lwz r29,20(r31)
008fca7c lwz r28,16(r31)
008fca80 lwz r27,12(r31)
008fca84 lwz r26,8(r31)
008fca88 lwz r0,36(r1)
008fca8c lwz r31,28(r1)
008fca90 lwz r30,24(r1)
008fca94 addir1,r1,32
008fca98 mtlrr0
008fca9c blr
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r357529 for 32-bit powerpc on 64-bit PowerMac: boot fails for getnewbuf_empty: locked buf 0xd2800000 on freequeue
On 2020-Feb-4, at 15:25, Mark Millard wrote: > The old PowerMac happens to be a 64-bit capable one > but the FreeBSD is the 32-bit variant. It boots on the 32-bit PowerMac example. It panics on the two examples of 64-bit types of PowerMac, both types dual socket but 1 core each vs. 2 cores each. The kernel and world were non-debug builds (with symbols). > The backtrace goes like: > (typed from a screen picture) > > . . . > panic > getnewbug Typo above, should have been: getnewbuf > getblkx > breadn_flags > ffs_use_bread > readsuper > ffs_sbget > ffs_mount > vfs_domount > vfs_donmount > kernel_mount > parse_mount > vfs_mountroot > start_init > fork_exit > fork_trampoline So I installed the artifact.ci.freebsd.org -r357545 kernel and kernel-dbg (-r357529 was not available). But is failed earlier for the example 64-bit PowerMac tried. 32-bit booted okay. But I'll report details for this one in a separate submittal for the earlier problem. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
head -r357529 for 32-bit powerpc: boot fails for getnewbuf_empty: locked buf 0xd2800000 on freequeue
The old PowerMac happens to be a 64-bit capable one but the FreeBSD is the 32-bit variant. The backtrace goes like: (typed from a screen picture) . . . panic getnewbug getblkx breadn_flags ffs_use_bread readsuper ffs_sbget ffs_mount vfs_domount vfs_donmount kernel_mount parse_mount vfs_mountroot start_init fork_exit fork_trampoline === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187)
Hi Mark, Thanks for the heads up. r357201:has been reverted by 357522. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message , Mark Millard write s: > > > On 2020-Feb-4, at 00:15, Francis Little wrote: > > > I have the same issue on my PowerMac G5 running HEAD, svnlite segfaults. > > > > I have installed subversion from ports for now as a workaround. > > I will note that svnlite has not changed in head for some time > but sql3lite (which svnlite uses as I understand) changed at -r357201 > to 3.31.0 . > > In ports sql3lite 3.31.0 has been reverted for segmentation > fault problems with firefox's use of it. (More than firerfox > might have been noticed if sql3lite 3.31.0 had lasted more than > 24 hours.) > > > Regards > > > > On Tue, 4 Feb 2020 at 03:47, Mark Millard via freebsd-ppc bsd.org> wrote: > > Given various issues that have been going on, > > I offer the following as a possible evidence > > for a problem still existing for powerpc64 > > as of head -r357419. Unfortunately, I do not > > have the time or context to do much for > > tracking it down. (I've already spent time > > on other unexpected failures in recent times.) > > > > The report does have a backtrace towards the > > end of this note. > > > > I have reverted to booting an emergency SSD that is > > at head -r356187 in order to have the following work > > instead of getting a segmentation fault on the old > > PowerMac: > > > > # svnlite update -r357473 /mnt/usr/src/ > > Updating '/mnt/usr/src': > > At revision 357473. > > > > (/mnt is a mount of the normal SSD that when booted > > would be at head -r357419 and was intended for a > > update to -r357473 .) > > > > Under head -r357419 on the G5 PowerMac, such a > > command ( then /usr/src/ ) gets a segmentation > > fault instead. (svnlite cleanup then leaves > > things corrupted as well.) > > > > This started by an attempt to update /usr/src/ > > from -r357419 or -r357473 . The -r357419 had > > been established via snvlite update under > > -r356426 and that had no problems. But this > > update under -r357419 just segmentation faulted. > > > > After discovering that I could not update the > > source tree natively, I copied over a -r357473 > > /usr/src/ from elsewhere and checked it with > > diff -r and rsync. I then tried to see if it > > would do like the above but it again > > segmentation faulted instead. (No actual source > > update needed, so a simpler case.) > > > > I did various retries by re-establishing the > > copy with no differences found. Each time > > the result was the same. > > > > So for the above working command, I again > > established the copy before switching boot > > media to the head -r356187 emergency SSD. > > > > Booted from -r356187, svnlite update > > -r357473 on the tree ( now /mnt/usr/src/ ) > > works fine. > > > > As another experiment, before switching to -r356187 , > > I swapped to a head -r356426 kernel copy and got > > the same sort of failing result. But that was mixing > > a 1300075 kernel with a 1300076 world, if I remember > > the numbers right. Still, since -r356426 for both > > kernel and world together updated to -r357419 okay, > > it may suggest that the more recent world contributes > > to or causes the failure instead of it being (just?) > > a kernel problem. > > > > > > FYI: I recorded a backtrace from a core that > > was produced in one of the example failures > > ( under head -r357419 ): > > > > Program terminated with signal SIGSEGV, Segmentation fault. > > . . . > > (gdb) bt > > #0 sqlite3VdbeRecordUnpack (pKeyInfo=0x810df84b8, nKey=0, pKey=0x0, p=0x81 > 16ea448) at /usr/src/contrib/sqlite3/sqlite3.c:81283 > > #1 0x0008104eec6c in sqlite3VdbeExec (p=0x8116ea308) at /usr/src/contr > ib/sqlite3/sqlite3.c:89367 > > #2 0x0008104b2f84 in sqlite3Step (p=0x8116ea308) at /usr/src/contrib/s > qlite3/sqlite3.c:83195 > > #3 sqlite3_step (pStmt=0x8116ea308) at /usr/src/contrib/sqlite3/sqlite3.c: > 17724 > > #4 0x10315e6c in svn_sqlite__step (got_row=0x3fffc484, stm > t=0x811a19420) at /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c > :347 > > #5 0x10315fa4 in svn_sqlite__insert (row_id=0x0, stmt=0x811a19420) > at /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c:371 > > #6 0x10195bd4 in insert_base_node (pibb=0x3fffc630, wcroot > =0x810dfd980, local_relpath=0x8119d2191 "sys/kern/sched_ule.c", scratch_pool= > 0x8119d2028) > > at /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:812 > > #7 0x10196688 in svn_wc__db_base_add_file (db=, loc > al_abspath=0x8119d2188 "/usr/src/sys/kern/sched_ule.c", wri_abspath= d out>, > > repos_relpath=0x8119d2228 "head/sys/kern/sched_ule.c", repos_root_url=0 > x8116b64f8 "svn://svn0.us-west.freebsd.org/base", repos_uuid=0x8116b6520 "ccf > 9f872-aa2e-dd11-9fc8-001c23d0bc1f", > > revision=357473, props=,
Re: OFWBUS: How does autoconfiguration work?
On Tue, 2020-02-04 at 19:09 +0530, Niteesh wrote: > I am working on an operating systems project at my university, which > currently > uses lazy driver initialization i.e. that is the drivers initialize the > hardware only > during the first invocation, for example, the UART hardware is initialized > only during the first call to output_char. > > Currently, we have multiple BSP's to support different variants even though > they are quite similar. For example, we have two BSPs to support BeagleBone > Black > and white. We are trying to avoid this by using device tree files. Our goal > is to parse the > DTB at boot time and call all the registered drivers to initialize the > hardware. By registered > drivers, I mean drivers which are statically linked to executable. > > I am trying to add a system, which will parse the DTB files and initialize > them by calling > the appropriate drivers. I want a system similar to FreeBSD or Linux > a probe and attach method for device drivers. It doesn't have to be as > complex as FreeBSD > but a simple one will do. > > If you have any other questions please let me know :) > > Thanks, > Niteesh > I don't think there is anything much in the freebsd code that will help you with that. The book "The Design and Implementation of the FreeBSD Operating System 2nd ed." describes the freebsd autoconfiguration mechanisms. Those mechanisms are designed to solve problems a lot more complex than parsing a simple hierarchical dtb to find active devices, it supports a mix of buses that can identify the devices on the bus (USB, PCI), buses that are described with metadata (ACPI, fdt simplebus, ISA bus with PNP data), and drivers that can just force a bus to adopt them by using an identify() method. Resource management (interrupts and mmio ranges, mostly) are also part of the scheme. FDT data adds another wrinkle by creating cross-hierarchy links between devices using phandles, and there are sideband subsystems in freebsd to handle that stuff separately from the normal hiearchical parent/child bus relationships. There just isn't much that can reasonably be separated out and used in another project, I think. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is amd automount still supported in 13.0 or not?
On Tue, Feb 04, 2020 at 08:15:05AM -0800, David Wolfskill wrote:
> On Tue, Feb 04, 2020 at 09:46:50AM -0600, Bob Willcox wrote:
> > ...
> > > Amd is not build by default now and will be removed from base. But you
> > > can continue using it by installing sysutils/am-utils from port.
> >
> > Thanks for the tip. I will likely go ahead and install the am-utils port as
> > from looking
> > at the setup and features of autofs it is way more complex and does more
> > than I need or
> > want. I've been using amd for decades now and it does exactly what I need
> > w/o any special
> > setup or configuration required. :)
> >
>
> I had also used amd from back when I still used a SPARCStation 5 as my
> home NFS (& yp) server, but switched with little fuss to autofs --
> primarily by using symlinks into /net/${host}/..., which works (for my
> purposes) just as well with either (amd or autofs).
I will likely look into autofs again at some point when I get a bit more time.
Right now
my goal was to get this system up and running so using something I'm familiar
with
expidites that.
Bob
>
> Peace,
> david
> --
> David H. Wolfskillda...@catwhisker.org
> "The Senate has abdicated its constitutional duty during the impeachment
> trial of President Donald Trump." -- Alan S. Frumin, parliamentarian
> emeritus of the US Senate
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
--
Bob Willcox| It's possible that the whole purpose of your life is to
b...@immure.com | serve as a warning to others.
Austin, TX |
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r357419 vs. svnlite update -rdddddd on PowerMac with 2 sockets, 2 cores each: segmentation fault (not under -r356187)
On 2020-Feb-4, at 00:15, Francis Little wrote: > I have the same issue on my PowerMac G5 running HEAD, svnlite segfaults. > > I have installed subversion from ports for now as a workaround. I will note that svnlite has not changed in head for some time but sql3lite (which svnlite uses as I understand) changed at -r357201 to 3.31.0 . In ports sql3lite 3.31.0 has been reverted for segmentation fault problems with firefox's use of it. (More than firerfox might have been noticed if sql3lite 3.31.0 had lasted more than 24 hours.) > Regards > > On Tue, 4 Feb 2020 at 03:47, Mark Millard via freebsd-ppc > wrote: > Given various issues that have been going on, > I offer the following as a possible evidence > for a problem still existing for powerpc64 > as of head -r357419. Unfortunately, I do not > have the time or context to do much for > tracking it down. (I've already spent time > on other unexpected failures in recent times.) > > The report does have a backtrace towards the > end of this note. > > I have reverted to booting an emergency SSD that is > at head -r356187 in order to have the following work > instead of getting a segmentation fault on the old > PowerMac: > > # svnlite update -r357473 /mnt/usr/src/ > Updating '/mnt/usr/src': > At revision 357473. > > (/mnt is a mount of the normal SSD that when booted > would be at head -r357419 and was intended for a > update to -r357473 .) > > Under head -r357419 on the G5 PowerMac, such a > command ( then /usr/src/ ) gets a segmentation > fault instead. (svnlite cleanup then leaves > things corrupted as well.) > > This started by an attempt to update /usr/src/ > from -r357419 or -r357473 . The -r357419 had > been established via snvlite update under > -r356426 and that had no problems. But this > update under -r357419 just segmentation faulted. > > After discovering that I could not update the > source tree natively, I copied over a -r357473 > /usr/src/ from elsewhere and checked it with > diff -r and rsync. I then tried to see if it > would do like the above but it again > segmentation faulted instead. (No actual source > update needed, so a simpler case.) > > I did various retries by re-establishing the > copy with no differences found. Each time > the result was the same. > > So for the above working command, I again > established the copy before switching boot > media to the head -r356187 emergency SSD. > > Booted from -r356187, svnlite update > -r357473 on the tree ( now /mnt/usr/src/ ) > works fine. > > As another experiment, before switching to -r356187 , > I swapped to a head -r356426 kernel copy and got > the same sort of failing result. But that was mixing > a 1300075 kernel with a 1300076 world, if I remember > the numbers right. Still, since -r356426 for both > kernel and world together updated to -r357419 okay, > it may suggest that the more recent world contributes > to or causes the failure instead of it being (just?) > a kernel problem. > > > FYI: I recorded a backtrace from a core that > was produced in one of the example failures > ( under head -r357419 ): > > Program terminated with signal SIGSEGV, Segmentation fault. > . . . > (gdb) bt > #0 sqlite3VdbeRecordUnpack (pKeyInfo=0x810df84b8, nKey=0, pKey=0x0, > p=0x8116ea448) at /usr/src/contrib/sqlite3/sqlite3.c:81283 > #1 0x0008104eec6c in sqlite3VdbeExec (p=0x8116ea308) at > /usr/src/contrib/sqlite3/sqlite3.c:89367 > #2 0x0008104b2f84 in sqlite3Step (p=0x8116ea308) at > /usr/src/contrib/sqlite3/sqlite3.c:83195 > #3 sqlite3_step (pStmt=0x8116ea308) at > /usr/src/contrib/sqlite3/sqlite3.c:17724 > #4 0x10315e6c in svn_sqlite__step (got_row=0x3fffc484, > stmt=0x811a19420) at > /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c:347 > #5 0x10315fa4 in svn_sqlite__insert (row_id=0x0, stmt=0x811a19420) > at /usr/src/contrib/subversion/subversion/libsvn_subr/sqlite.c:371 > #6 0x10195bd4 in insert_base_node (pibb=0x3fffc630, > wcroot=0x810dfd980, local_relpath=0x8119d2191 "sys/kern/sched_ule.c", > scratch_pool=0x8119d2028) > at /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:812 > #7 0x10196688 in svn_wc__db_base_add_file (db=, > local_abspath=0x8119d2188 "/usr/src/sys/kern/sched_ule.c", > wri_abspath=, > repos_relpath=0x8119d2228 "head/sys/kern/sched_ule.c", > repos_root_url=0x8116b64f8 "svn://svn0.us-west.freebsd.org/base", > repos_uuid=0x8116b6520 "ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f", > revision=357473, props=, changed_rev=, > changed_date=, changed_author=, > checksum=, dav_cache=, > delete_working=, update_actual_props=, > new_actual_props=, new_iprops=, > keep_recorded_info=, > insert_base_deleted=, conflict=, > work_items=, scratch_pool=) at > /usr/src/contrib/subversion/subversion/libsvn_wc/wc_db.c:1831 > #8 0x101ceaf0 in close_file (file_baton=0x8119d20a0, > expected_md5_digest=, pool=) at >
Looks like head -r357201 (Update sqlite3-3.30.1 (3300100) --> sqlite3-3.31.0 (3310000)) leads to svnlite segfaults on powerpc64
See: https://lists.freebsd.org/pipermail/freebsd-ppc/2020-February/011416.html for reports of svnlite segfaults and corrupted svn content after svnlite cleanup on powerpc64 (old PowerMacs). But there is also . . . databases/sqlite3: revert upgrade to 3.31.0 Firefox relied on internals. They changed, which leads to segfaults. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1607902 [2] https://hg.mozilla.org/try/rev/8d7104bac33729b4da67954b07fb08371df39bd8 PR: 243602 Reported by:Michael Butler , David Wolfskill I might suggest reverting the sqllite3 update in head for now. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is amd automount still supported in 13.0 or not?
On Tue, Feb 04, 2020 at 09:46:50AM -0600, Bob Willcox wrote:
> ...
> > Amd is not build by default now and will be removed from base. But you
> > can continue using it by installing sysutils/am-utils from port.
>
> Thanks for the tip. I will likely go ahead and install the am-utils port as
> from looking
> at the setup and features of autofs it is way more complex and does more than
> I need or
> want. I've been using amd for decades now and it does exactly what I need w/o
> any special
> setup or configuration required. :)
>
I had also used amd from back when I still used a SPARCStation 5 as my
home NFS (& yp) server, but switched with little fuss to autofs --
primarily by using symlinks into /net/${host}/..., which works (for my
purposes) just as well with either (amd or autofs).
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
"The Senate has abdicated its constitutional duty during the impeachment
trial of President Donald Trump." -- Alan S. Frumin, parliamentarian
emeritus of the US Senate
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Is amd automount still supported in 13.0 or not?
On Tue, Feb 04, 2020 at 08:54:35AM +0900, Yasuhiro KIMURA wrote: > From: Bob Willcox > Subject: Is amd automount still supported in 13.0 or not? > Date: Mon, 3 Feb 2020 17:23:33 -0600 > > > I've recently installed a 13.0 snapshot on one of my system to get some > > experience with it > > and am having trouble trying to setup the amd automount program. In fact, I > > can't find amd > > on this system. Has amd been removed and all we have for automatically > > mounting > > filesystems autofs? > > Amd is not build by default now and will be removed from base. But you > can continue using it by installing sysutils/am-utils from port. Thanks for the tip. I will likely go ahead and install the am-utils port as from looking at the setup and features of autofs it is way more complex and does more than I need or want. I've been using amd for decades now and it does exactly what I need w/o any special setup or configuration required. :) I do wonder though, are there plans to remove it from ports? I hope not. I find autofs to be way overkill for my needs. Bob > > --- > Yasuhiro KIMURA > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OFWBUS: How does autoconfiguration work?
I am working on an operating systems project at my university, which currently uses lazy driver initialization i.e. that is the drivers initialize the hardware only during the first invocation, for example, the UART hardware is initialized only during the first call to output_char. Currently, we have multiple BSP's to support different variants even though they are quite similar. For example, we have two BSPs to support BeagleBone Black and white. We are trying to avoid this by using device tree files. Our goal is to parse the DTB at boot time and call all the registered drivers to initialize the hardware. By registered drivers, I mean drivers which are statically linked to executable. I am trying to add a system, which will parse the DTB files and initialize them by calling the appropriate drivers. I want a system similar to FreeBSD or Linux a probe and attach method for device drivers. It doesn't have to be as complex as FreeBSD but a simple one will do. If you have any other questions please let me know :) Thanks, Niteesh On Sun, Feb 2, 2020 at 9:07 PM Ian Lepore wrote: > On Sun, 2020-02-02 at 10:02 +0530, Niteesh wrote: > > I couldn't find anything useful for me, I need information about how the > > hardware autoconfiguration works, not autoconf. > > > > Then maybe you need to provide more details about what you're doing, > what you've tried that isn't working, or something. I couldn't make > any sense out of your original question. > > -- Ian > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
