; panic: condition vp->v_holdcnt > 0 not met at
>> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
>> cpuid = 7
>> time = 1744203937
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38
>> vpanic() at vpanic+0x1a0
>> panic() at panic+0x48
>> vget_finish_ref() at vget_finish_ref+0x1a4
>> null_hashget() at null_hashget+0xe4
>> null_nodeget() at null_nodeget+0x34
>> null_lookup() at null_lookup+0x118
>> vfs_lookup() at vfs_lookup+0x3e0
>> namei() at namei+0x298
>> kern_statat() at kern_statat+0xf4
>> sys_fstatat() at sys_fstatat+0x2c
>> do_el0_sync() at do_el0_sync+0x608
>> handle_el0_sync() at handle_el0_sync+0x4c
>> --- exception, esr 0x5600
>> KDB: enter: panic
>>
>> Here:
>> namei() at namei+0x298
>> kern_statat() at kern_statat+0xf4
>> sys_fstatat() at sys_fstatat+0x2c
>> do_el0_sync() at do_el0_sync+0x608
>>
>> The *statat() are distinct from the prior examples.
>>
>> Again the common part is:
>>
>> vget_finish_ref() at vget_finish_ref+0x1a4
>> null_hashget() at null_hashget+0xe4
>> null_nodeget() at null_nodeget+0x34
>> null_lookup() at null_lookup+0x118
>> vfs_lookup() at vfs_lookup+0x3e0
>> namei() at namei+0x298
>
>
> The 4th one is another one with:
>
> Here:
> namei() at namei+0x298
> kern_statat() at kern_statat+0xf4
> sys_fstatat() at sys_fstatat+0x2c
> do_el0_sync() at do_el0_sync+0x608
>
> like the prior one.
I mostly stopped using the debug kernel in contexts were
I'd also be doing non-trivial poudriere-devel bulk builds.
However, when I did try such I eventually ran into the
panic again. I've not bothered with adding more dumps.
I've no known way to, on demand, reproduce such quickly
in a simple context.
===
Mark Millard
marklmi at yahoo.com
On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote:
>
> So: 2 min 31 sec or so difference for overall somewhat over an
> hour, i.e., 151 sec or so. That is under 1 sec per package
> built.
If the slowdown comes from handling shlib provides/requires, then this
obviously depends on the amount of dep
[For the most part the prior history of my notes is not
important so they are mostly omitted this time.]
It looks like my notes about official bulk package builds
taking longer may be from observations of more than one
distinct issue, one leading to a very rough factor of 2
and the other not
ger may be from observations of more than one
> distinct issue, one leading to a very rough factor of 2
> and the other not leading to anything like such.
>
> I'd reported that main-arm64-default was taking very roughly
> 2x as long to do its official bulk -a -c (from scratch)
> style
[Note: The new main-amd64 (beefy18) example reported is
still building but has taken over 72 hrs longer than any
other prior example. There is a major performance change
involved compared to builds started before April. Slower
hardware makes that more obvious than the fastest
hardware does.]
On
> >>> may have the same issue.
>> >>>
>> >>>
>> >>> ) At least for how the local systems were installed, there
>> >>> is no such place predefined as /sys/ , not even as a
>> >>> symbolic link. "man 7 hie
> >>> So it seems /sys -> /usr/src/sys is intended. (But
> >>> /usr/src/ need not have been populated, leaving a
> >>> lack of any GENERIC.hints in such a case.)
> >>>
> >>> Best to not to depend on /sys in the notation shown?
>
7 hier" does not list such.
>>>
>>> So it seems /sys -> /usr/src/sys is intended. (But
>>> /usr/src/ need not have been populated, leaving a
>>> lack of any GENERIC.hints in such a case.)
>>>
>>> Best to not to depend on /sys in the notati
e notation shown?
>>
>>
>> ) The /ARCH/ reference is unclear vs. MACHINE,
>> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths
>> existing for GENERIC.hints do not help because they
>> all allow MACHINE == MACHINE_CPUARCH ,
>> MACHINE == MACHINE_AR
on /sys in the notation shown?
>
>
> ) The /ARCH/ reference is unclear vs. MACHINE,
> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths
> existing for GENERIC.hints do not help because they
> all allow MACHINE == MACHINE_CPUARCH ,
> MACHINE == MACHINE_ARCH , and
> MACH
ased on the
NOTE paths:
# find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | more
/usr/src/sys/amd64/conf/NOTES
/usr/src/sys/arm/conf/NOTES
/usr/src/sys/arm64/conf/NOTES
/usr/src/sys/conf/NOTES
/usr/src/sys/i386/conf/NOTES
/usr/src/sys/powerpc/conf/NOTES
/usr/src/sys/riscv/con
On 5/5/23 6:38 AM, Ed Maste wrote:
FreeBSD supports up to 256 CPU cores in the default kernel configuration
(on Tier-1 architectures). Systems with more than 256 cores are
available now, and will become increasingly common over FreeBSD 14’s
lifetime. The FreeBSD Foundation is supporting the
On Sun, May 7, 2023, 3:51 PM Moin Rahman wrote:
>
>
> > On May 5, 2023, at 3:38 PM, Ed Maste wrote:
> >
> > FreeBSD supports up to 256 CPU cores in the default kernel configuration
> > (on Tier-1 architectures). Systems with more than 256 cores are
>
On 5/5/23 17:23, Tomek CEDRO wrote:
On Fri, May 5, 2023 at 3:38 PM Ed Maste wrote:
FreeBSD supports up to 256 CPU cores in the default kernel configuration
(on Tier-1 architectures). Systems with more than 256 cores are
available now, and will become increasingly common over FreeBSD 14’s
On Fri, May 5, 2023 at 3:38 PM Ed Maste wrote:
> FreeBSD supports up to 256 CPU cores in the default kernel configuration
> (on Tier-1 architectures). Systems with more than 256 cores are
> available now, and will become increasingly common over FreeBSD 14’s
> lifetime. (..)
Con
FreeBSD supports up to 256 CPU cores in the default kernel configuration
(on Tier-1 architectures). Systems with more than 256 cores are
available now, and will become increasingly common over FreeBSD 14’s
lifetime. The FreeBSD Foundation is supporting the effort to increase
MAXCPU, and PR269572
oh, just timekeeping && tell me that uniqueid is oracled with /dev/random
Well it's not that there are Great many things depending on
synchronizing Jit, wit,NTP cloudcovered Just in case, anything can happen
to stratum0 and however unlikely it seems, there is a future imagined for
it, that has a pr
On Fri, Mar 17, 2023 at 9:53 PM Mark Millard wrote:
> This may all be fine. But it still leaves me expecting
> that there should be man page(s) covering these hostid
> and machine-id files and how they should be handled to
> match the usages to which they are put, such as the nfs
> use that was r
On Mar 17, 2023, at 19:04, Mark Millard wrote:
> On Mar 17, 2023, at 18:24, Mark Millard wrote:
>
>> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
>> upgrade sequence did not go well relative to my being
>> prompted to do the right thing to establish /etc/machine-id .
>> After the la
On Mar 17, 2023, at 18:24, Mark Millard wrote:
> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
> upgrade sequence did not go well relative to my being
> prompted to do the right thing to establish /etc/machine-id .
> After the last reboot (kernel upgrade, presumably) it had me
> contin
The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
upgrade sequence did not go well relative to my being
prompted to do the right thing to establish /etc/machine-id .
After the last reboot (kernel upgrade, presumably) it had me
continue with. . .
# /usr/sbin/freebsd-update install
src compon
ing to the latest
>> code -- CCing bapt and tijl just in case since they're more familiar with
>> this
>> than I am.
>>
>> Colin Percival
>>
>> On 3/16/23 15:55, Mark Millard wrote:
>>> # cat /etc/hostid /etc/machine-id /var/d
e latest
>> code -- CCing bapt and tijl just in case since they're more familiar with
>> this
>> than I am.
>
> A question may be if past dbus port related activity might
> have established a /var/db/machine-id independent of the
> recent FreeBSD activity. That mi
On Mar 16, 2023, at 16:48, Colin Percival wrote:
> I think the current situation should be sorted out aside from potential issues
> for people who upgraded to a "broken" version before updating to the latest
> code -- CCing bapt and tijl just in case since they're more f
I think the current situation should be sorted out aside from potential issues
for people who upgraded to a "broken" version before updating to the latest
code -- CCing bapt and tijl just in case since they're more familiar with this
than I am.
Colin Percival
On 3/16/23 15:5
On Mar 16, 2023, at 15:55, Mark Millard wrote:
> # cat /etc/hostid /etc/machine-id /var/db/machine-id
> a4f7fbeb-f668-11de-b280-ebb65474e619
> a4f7fbebf66811deb280ebb65474e619
> 7227cd89727a462186e3ba680d0ee142
>
> (I'll not be keeping these values for the example system.)
>
> # ls -Tld /etc/ho
# cat /etc/hostid /etc/machine-id /var/db/machine-id
a4f7fbeb-f668-11de-b280-ebb65474e619
a4f7fbebf66811deb280ebb65474e619
7227cd89727a462186e3ba680d0ee142
(I'll not be keeping these values for the example system.)
# ls -Tld /etc/hostid /etc/machine-id /var/db/machine-id
-rw-r--r-- 1 root whe
lassified as "out of swap space"? Would either
>>> one show the swap space as (nearly?) all used in, say, top?
>>> Or might one of them still end up looking like a misnomer
>>> from just a top (or whatever) display?
>>
>> Hmm, those cases should lik
t; from just a top (or whatever) display?
>
> Hmm, those cases should likely be changed from "out of swap space" to
> "failed to allocate swap metadata" or something like that.
The above does not seem to have happened yet in main [so: 14].
Will 13.1 get an MFC of 4a864f624a70 in time, possibly with the
above change also in place to fully avoid misnomer reporting
that misleads folks?
4a864f624a70 listed:
MFC after: 2 weeks
but it has been more than a month.
> . . .
>
===
Mark Millard
marklmi at yahoo.com
p_init() pre-allocates
> these structures during boot, and the size of the reserves is based on
> the amount of physical memory. In particular, each VM object maintains
> a trie of "swap blocks", each of which maps a run of SWAP_META_PAGES
> pages contiguous within an object to i
On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote:
> Thanks. This will allow me to remove part of my personal additions
> in this area --and my having to explain the misnomer when trying
> to help someone analyze why they end up with OOM activity so they
> can figure out what to do about
Thanks. This will allow me to remove part of my personal additions
in this area --and my having to explain the misnomer when trying
to help someone analyze why they end up with OOM activity so they
can figure out what to do about it.
There seem to be two separate sources of VM_OOM_SWAPZ. Showing
m
nd have
>> "kyua test -k /usr/tests/Kyuafile" running.
>>
>> I see evidence of one AddressSanitizer report. (kyua is still
>> running.) The context is:
>>
>> # more
>> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt
>>
> I see evidence of one AddressSanitizer report. (kyua is still
> running.) The context is:
>
> # more
> /usr/obj/DESTDIRs/main-amd64-xSAN-chroot/tmp/kyua.FKD2vh/434/stdout.txt
> Executing command [ mkdir /tmp/kyua.FKD2vh/434/work/mntpt ]
> mount -t tmpfs -o size=10M tmp
On Fri, Dec 3, 2021 at 3:52 AM Yetoo Happy wrote:
>
> In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see that at
> 24.5.6.1 Merging Configuration Files are instructions to bootstrap etcupdate
> if switching from mergemaster. This is really convenient and really useful,
> EXCE
and time-consuming challenge. How would one for example find
old sources to perform "etcupdate extract" ?
From my experience etcupdate(8) is only useful for updating RELEASEs or
frequently updated CURRENT. The power of sdiff(1) way merge giving full
control over the update process is th
On Wed, 8 Dec 2021 09:11:05 -0800
John Baldwin wrote:
> On 12/3/21 6:09 PM, Tomoaki AOKI wrote:
> > On Fri, 03 Dec 2021 05:54:37 -0800 (PST)
> > "Jeffrey Bouquet" wrote:
> >
> >>
> >>
> >> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz>
> >> wrote:
> >>
> >>> On 03/12/20
If it was in a temporary directory, even if I manaually resolved the file
and merge, I was expecting that file marked as resolve to stay in that
temporary directory until I was done with all my files. Maybe I'm confusing
mergemaster -Ui behavior with something else, but it seems like only
merging a
Am 08.12.21 um 18:11 schrieb John Baldwin:
> So the new changes always build a temporary tree (vs trying to build
> /var/db/etupdate/current in place). For -n it should be that it just
> doesn't change /var/db/etcupdate/current at the end, but if it did the
> move anyway that would explain the bug
On 12/3/21 6:09 PM, Tomoaki AOKI wrote:
On Fri, 03 Dec 2021 05:54:37 -0800 (PST)
"Jeffrey Bouquet" wrote:
On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote:
On 03/12/2021 12:52, Yetoo Happy wrote:
[...]
Quick Start* and follow the instructions and get to ste
On 12/3/21 4:58 AM, Miroslav Lachman wrote:
So beside the update of documentation I really would like to see some
changes to etcupdate workflow where files are modified in temporary
location and moved to destination only if they do not contain any syntax
breaking changes like , , .
On Fri, 03 Dec 2021 05:54:37 -0800 (PST)
"Jeffrey Bouquet" wrote:
>
>
> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> > On 03/12/2021 12:52, Yetoo Happy wrote:
> >
> > [...]
> >
> > > Quick Start* and follow the instructions and get to step
> > > 7 and ma
On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote:
> On 03/12/2021 12:52, Yetoo Happy wrote:
>
> [...]
>
> > Quick Start* and follow the instructions and get to step
> > 7 and may think that even though etcupdate is different from mergemaster
> > from the last time
On 03/12/2021 12:52, Yetoo Happy wrote:
[...]
Quick Start* and follow the instructions and get to step
7 and may think that even though etcupdate is different from mergemaster
from the last time they used the handbook they have faith that following
the instructions won't brick their system. Th
In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see that
at* 24.5.6.1 Merging Configuration Files* are instructions to bootstrap
etcupdate if switching from mergemaster. This is really convenient and
really useful, *EXCEPT* for that fact that it is placed in a part of the
handbook
> On 5/13/21 9:00 PM, Rodney W. Grimes wrote:
> >> On 12.05.2021 21:01, Marc Veldman wrote:
> >>
> >>> I?m not sure if this is an interesting data point or not,
> >>> but a warm boot without the card inserted succeeds after
> >>> a cold boot with the card inserted.
> >>
> >>It could explain, wh
On 5/13/21 9:00 PM, Rodney W. Grimes wrote:
On 12.05.2021 21:01, Marc Veldman wrote:
I?m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path" g
> On 12.05.2021 21:01, Marc Veldman wrote:
>
> > I?m not sure if this is an interesting data point or not,
> > but a warm boot without the card inserted succeeds after
> > a cold boot with the card inserted.
>
> It could explain, why my tests with "same code path" gave different results!
I am
On 2020-Dec-19, at 03:09, Hans Petter Selasky wrote:
> Please test:
>
> https://svnweb.freebsd.org/changeset/base/368799
> https://svnweb.freebsd.org/changeset/base/368801
>
> --HPS
I grabbed a debug -r368803 kernel from artifacts (first arm64
snapshot available containing the above 2 updat
Please test:
https://svnweb.freebsd.org/changeset/base/368799
https://svnweb.freebsd.org/changeset/base/368801
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail t
[I managed to not cc the primary person that I intended but to cc the secondary
person.
So this resend just adds jmg and removes hps.]
On 2020-Dec-18, at 22:27, Mark Millard wrote:
> The following is from head -r368500's artifact kernel from:
>
> https://artifact.ci.freebsd.org/snapshot/13.0-
The following is from head -r368500's artifact kernel from:
https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz
but the same sort of material showed for -r368000 .
(I was attempting a bisect for a different issue but
the debug kernels did not fail for what I w
The following 2 references to GCC or gcc may not be intended
any more:
The
CCACHE_CPP2 option is used for Clang but not GCC.
To be able to build the system, either gcc
or clang bootstrap must be enabled unless an alternate compiler
is provided via XCC
On 01/26/2019 01:24, Hans Petter Selasky wrote:
On 1/26/19 1:41 AM, Mel Pilgrim wrote:
A quirk for a USB flashdrive was added to head (r342657), but the
modification was too narrow. The quirk affects all of the devices
in the Chipfancier SLC family, not just the one specific device for
which t
On 1/26/19 1:41 AM, Mel Pilgrim wrote:
A quirk for a USB flashdrive was added to head (r342657), but the
modification was too narrow. The quirk affects all of the devices in
the Chipfancier SLC family, not just the one specific device for which
the quirk was added.
I replied to usb/234503 ab
A quirk for a USB flashdrive was added to head (r342657), but the
modification was too narrow. The quirk affects all of the devices in
the Chipfancier SLC family, not just the one specific device for which
the quirk was added.
I replied to usb/234503 about this, but as this is already in head
aarch64 build rather than presume
>> that my personal build is good enough. But I expect that its results
>> should be strongly suggestive, even if an official tests uses a more
>> normal-for-FreeBSD configuration of an aarch64 system.
>>
>> The e.MMC is V5.1 is operating
On Wed, 2018-09-05 at 00:07 +0300, Lev Serebryakov wrote:
> Hello FreeBSD,
>
> When I use serial console (configured as console + "getty std.115200
> xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever.
> If I hit
> ^T system show
Hello FreeBSD,
When I use serial console (configured as console + "getty std.115200
xterm"), csh works perfectly Ok, but "sh" and "more" lockss forever. If I hit
^T system shows that locked process is in "[ttydcd]" state. ^C kills locked
process.
What do
On 07/12/2018 21:15, Yuri wrote:
On 07/12/18 13:38, Pete Wright wrote:
sorry if i missed something (don't see details in the bug report) -
is the issue that the run(4) kernel module is not being loaded? is
there an error when the system attempts to load the kernel module in
the dmesg buffe
On 13.07.2018 14:10, Lev Serebryakov wrote:
> when system is unresponsive I see this in `top -SH`
>
> 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
> 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
>
> And it is new to me.
Oh, this MoBo has
I have "SOHO" router on Atom D2500 with FreeBSD CURRENT. It runs
CURRENT for very long time (from 11-CURRENT times), and recently it
start to consume much more CPU on same traffic — to the point when it
becomes unresponsive in shell (via ssh, not local console).
I have rather co
Yuri Pankov wrote:
Yuri wrote:
On 07/03/18 12:45, Yuri wrote:
I updated the laptop to r335884 last night, and 'service
wpa_supplicant start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. Th
Yuri wrote:
On 07/03/18 12:45, Yuri wrote:
I updated the laptop to r335884 last night, and 'service
wpa_supplicant start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. This is the immediate reason why
On 07/12/18 13:38, Pete Wright wrote:
sorry if i missed something (don't see details in the bug report) - is
the issue that the run(4) kernel module is not being loaded? is there
an error when the system attempts to load the kernel module in the
dmesg buffer? if it is not being loaded automa
On 07/12/2018 12:25, Yuri wrote:
On 07/03/18 12:45, Yuri wrote:
I updated the laptop to r335884 last night, and 'service
wpa_supplicant start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. Th
On 07/03/18 12:45, Yuri wrote:
I updated the laptop to r335884 last night, and 'service
wpa_supplicant start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. This is the immediate reason why wpa_supplican
On Wed, Jul 4, 2018 at 12:17 PM, Warner Losh wrote:
>
>
> On Wed, Jul 4, 2018, 2:13 PM Kevin Oberman wrote:
>
>> On Wed, Jul 4, 2018 at 11:49 AM, Yuri wrote:
>>
>> > On 07/04/18 07:27, Rodney W. Grimes wrote:
>> >
>> >> Devd/devmatch is one of the largest changes recently,
>> >> it could be som
On Wed, Jul 4, 2018 at 12:06 PM, Yuri wrote:
> On 07/04/18 12:00, Rodney W. Grimes wrote:
>
>> Just for fun to see if this can clear up your issue add
>> if_run_load="YES"
>> to /boot/loader.conf
>>
>
>
> This doesn't help. In the presence of preloaded if_run.ko wpa_supplicant
> still can
On Wed, Jul 4, 2018, 2:13 PM Kevin Oberman wrote:
> On Wed, Jul 4, 2018 at 11:49 AM, Yuri wrote:
>
> > On 07/04/18 07:27, Rodney W. Grimes wrote:
> >
> >> Devd/devmatch is one of the largest changes recently,
> >> it could be something in that code path.
> >>
> >> Do you get the if_run.ko module
On Wed, Jul 4, 2018 at 11:49 AM, Yuri wrote:
> On 07/04/18 07:27, Rodney W. Grimes wrote:
>
>> Devd/devmatch is one of the largest changes recently,
>> it could be something in that code path.
>>
>> Do you get the if_run.ko module loaded? What does kldstat show
>> immediately after boot and befo
On 07/04/18 12:00, Rodney W. Grimes wrote:
Just for fun to see if this can clear up your issue add
if_run_load="YES"
to /boot/loader.conf
This doesn't help. In the presence of preloaded if_run.ko wpa_supplicant
still can't initialize wlan0.
Yuri
__
> On 07/04/18 07:27, Rodney W. Grimes wrote:
> > Devd/devmatch is one of the largest changes recently,
> > it could be something in that code path.
> >
> > Do you get the if_run.ko module loaded? What does kldstat show
> > immediately after boot and before you try to "fix" anything with
> > ifconf
On 07/04/18 07:27, Rodney W. Grimes wrote:
Devd/devmatch is one of the largest changes recently,
it could be something in that code path.
Do you get the if_run.ko module loaded? What does kldstat show
immediately after boot and before you try to "fix" anything with
ifconfig.
It definitely di
[ Charset UTF-8 unsupported, converting... ]
> On 07/03/18 18:13, Rodney W. Grimes wrote:
> > Do you get the same failure condition if you use the
> > wpa_supplicant from the base system?
>
>
> Same failure with the base wpa_supplicant.
>
> Creating wlan0 by hand helps, but this should happen au
On 07/03/18 18:13, Rodney W. Grimes wrote:
Do you get the same failure condition if you use the
wpa_supplicant from the base system?
Same failure with the base wpa_supplicant.
Creating wlan0 by hand helps, but this should happen automatically.
restarting devd service also helps.
I think w
[ Charset UTF-8 unsupported, converting... ]
> On 07/03/18 15:29, Rodney W. Grimes wrote:
> >>> wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
> > ^^
> >
> > What wpa_supplicant is this?
> > The normal system one lives in /sbin.
>
> It's installed by t
On 07/03/18 15:29, Rodney W. Grimes wrote:
wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
^^
What wpa_supplicant is this?
The normal system one lives in /sbin.
It's installed by the package wpa_supplicant-2.6_2 from
security/wpa_supplicant.
It is
> On 07/03/18 14:32, Yuri wrote:
> >
> >
> > rc.conf has:
> >
> > wlans_iwn0="wlan0"
> >
> > ifconfig_wlan0="WPA DHCP"
> >
> > wpa_supplicant_enable="YES"
> >
> > wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
^^
What wpa_supplicant is this?
The normal
On 07/03/18 14:32, Yuri wrote:
rc.conf has:
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
wpa_supplicant_enable="YES"
wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
This got mixed up.
rc.conf has:
wlans_run0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"
wpa_supplicant_enable="YES"
wpa_
On 07/03/18 13:54, Sean Bruno wrote:
Yuri:
If you're still having trouble, dump your rc.conf entries for your
wireless. Mine looks like this at the moment with iwn(4):
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
seam
Thank you, Sean!
rc.conf has:
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA
DATING:-(
>
>
> I may be mistaken about the interface creation.
>
> But regardless of the cause, WiFi doesn't work any more. :-(
>
>
> Yuri
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lis
esn't work any more. :-(
Yuri
___
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"
On 03.07.2018 22:45, Yuri wrote:
> I updated the laptop to r335884 last night, and 'service wpa_supplicant
> start wlan0' doesn't succeed any more.
>
> kernel is supposed to create the network interface 'run0', but it
> doesn't. This is the immediate
I updated the laptop to r335884 last night, and 'service wpa_supplicant
start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. This is the immediate reason why wpa_supplicant fails.
The non-creation of &
I finally caught this happening while I had "lockstat sleep 1" running
in a loop, the output looks like:
https://gist.github.com/swills/a2a20c2a4296a4c596ec7f329fb945ab
And top looks like this:
https://gist.github.com/swills/6e749313e52679224adec91d4841ad83
Also noticed that there are actuall
On Wed, Apr 25, 2018 at 2:30 AM, Steve Wills wrote:
Hi,
Recently on multiple systems running CURRENT, I've been seeing the
system become unresponsive. Leaving top(1) running has lead me to
notice that when this happens, the system is still responding to ping
and top over ssh is still worki
Hi,
Recently on multiple systems running CURRENT, I've been seeing the
system become unresponsive. Leaving top(1) running has lead me to notice
that when this happens, the system is still responding to ping and top
over ssh is still working, but no new processes can start and switching
to oth
[I need to be more careful about identifying
the context I'm referring to.]
On 2018-Jan-4, at 7:13 PM, Mark Millard wrote:
> Mark Heily mark at heily.com wrote on
> Thu Jan 4 14:06:18 UTC 2018 :
>
>> the build system for CURRENT can be changed in
>> ways that make it
Mark Heily mark at heily.com wrote on
Thu Jan 4 14:06:18 UTC 2018 :
> the build system for CURRENT can be changed in
> ways that make it incompatible with building STABLE. This is normal and
> expected behavior for a development branch. It has never been a *supported*
> option to mix and match sou
On Thu, Jan 4, 2018 at 6:17 AM, O. Hartmann wrote:
> On Tue, 2 Jan 2018 09:33:08 -0500
> Shawn Webb wrote:
>
> > On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
> > > Since lint was removed from 12.0-CURRENT, it is not possible to build
> > > 11.1-STABLE on a 12.0-CURRENT host
>
Ther
On Tue, 2 Jan 2018 09:33:08 -0500
Shawn Webb wrote:
> On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
> > Since lint was removed from 12.0-CURRENT, it is not possible to build
> > 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that
> > by copying /usr/bin/true to /us
On Mon, Jan 01, 2018 at 05:14:00PM -0800, Don Lewis wrote:
> Since lint was removed from 12.0-CURRENT, it is not possible to build
> 11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that
> by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick
> doesn't work when upd
Since lint was removed from 12.0-CURRENT, it is not possible to build
11.1-STABLE on a 12.0-CURRENT host, but I was able to work around that
by copying /usr/bin/true to /usr/bin/lint. Unfortunately, that trick
doesn't work when updating a 11.1-STABLE poudriere jail on a
12.0-CURRENT host.
===> us
ocl-icd is installed and more than
one OpenCL
ICD is installed with lang/pocl, any client (compiled with lang/pocl) or
port/package
utilising OpenCL in any way (see graphics/blender PR23879 or devel/clinfo,
bails out with:
: CommandLine Error: Option 'enable-value-profiling' registered
With devel/llvm40 and lang/clang40 installed on recent CURRENT (as well as
11-STABLE),
graphics/blender (with option for OpenCL) and software compiled with lang/pocl
fail/crash
with something similar like
[...]
: CommandLine Error: Option 'enable-value-profiling' registered more than
On 27 Jun 2017, at 13:20, Kurt Jaeger wrote:
>
> Hi!
>
>>> Compiling devel/lfcbase, it fails while including sys/socketvar.h with
>>> this error:
>>>
>>> In file included from Net.cc:36:
>>> /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an
>>> anonymous struct
>>>
Hi!
> > Compiling devel/lfcbase, it fails while including sys/socketvar.h with
> > this error:
> >
> > In file included from Net.cc:36:
> > /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an
> > anonymous struct
> >enum {
> >
> On Jun 26, 2017, at 23:31, Kurt Jaeger wrote:
>
> Hi!
>
> Compiling devel/lfcbase, it fails while including sys/socketvar.h with
> this error:
>
> In file included from Net.cc:36:
> /usr/include/sys/socketvar.h:117:4: error: types cannot be declared in an
> anonymous struct
>
so is fairly recent. So if that is more recent than
the most recent compile that worked for you then it may
not be a compiler change at all.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailm
1 - 100 of 1076 matches
Mail list logo
