After doing an iozone test run with some basic monitoring
( top use, ls -lodTt /tmp/iozone.* ), I later noticed that
the console was displaying message(s). dmesg -a dispalyed
them as well:
fsync: giving up on dirty (error = 35) 0xa00087390a50: type VCHR state
VSTATE_CONSTRUCTED op 0x0
On Dec 25, 2022, at 15:55, Warner Losh wrote:
> Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a bogus if
> MACHINE_ARCH == "amd64" somewhere.
Well, seems more is missing for aarch64 if devd hyperv is to be enabled:
# grep -r MK_HYPERV /usr/main-src/ | more
/usr/main-src
Most likely MK_HYPERV is defaulting to no for aarch64? Or there is a bogus
if MACHINE_ARCH == "amd64" somewhere.
Warner
On Sun, Dec 25, 2022, 4:28 PM Mark Millard wrote:
> From the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
> system:
>
> . . .
> Starting devd.
> genet0: link state changed
From the Dec 24 main [so: 14] snaphot for an aarch64 RPi*
system:
. . .
Starting devd.
genet0: link state changed to UP
sh: /usr/libexec/hyperv/hyperv_vfattach: not found
Starting dhclient.
. . .
This seems to be from /etc/devd/hyperv.conf :
notify 10 {
match "system" "ETHERNET"
On 2021-May-5, at 05:28, Mark Millard wrote:
> On 2021-May-5, at 02:47, Andriy Gapon wrote:
>
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME USED AVAIL REFER MOUNTPOINT
>>> . . .
>>> zroot/DE
On 2021-May-5, at 02:47, Andriy Gapon wrote:
> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME USED AVAIL REFER MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 1
On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G -
line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
Not exactly an obvious erro
In FreeBSD 13.0 when I update the kernel and world I receive the following
error message during mergemaster:
ka-freebsd:/usr/src# mergemaster
*** Creating the temporary root environment in /var/tmp/temproot
*** /var/tmp/temproot ready for use
*** Creating and populating directory structure
On Mon, Jan 13, 2014 at 8:22 PM, Glen Barber wrote:
> On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
> > So, now when I run pkg I get the following:
> > pkg: Ignoring bad configuration entry in
> /usr/local/etc/pkg/repos/FreeBSD.conf: "URL:
> http://pkg.freebsd.org/${ABI}/lates
Glen Barber wrote this message on Mon, Jan 13, 2014 at 23:22 -0500:
> On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
> > So, now when I run pkg I get the following:
> > pkg: Ignoring bad configuration entry in
> > /usr/local/etc/pkg/repos/FreeBSD.conf: "URL:
> > http://pkg.free
On Mon, Jan 13, 2014 at 08:15:34PM -0800, John-Mark Gurney wrote:
> So, now when I run pkg I get the following:
> pkg: Ignoring bad configuration entry in
> /usr/local/etc/pkg/repos/FreeBSD.conf: "URL:
> http://pkg.freebsd.org/${ABI}/latest";
> pkg: Ignoring bad configuration entry in
> /usr/loc
So, now when I run pkg I get the following:
pkg: Ignoring bad configuration entry in /usr/local/etc/pkg/repos/FreeBSD.conf:
"URL: http://pkg.freebsd.org/${ABI}/latest";
pkg: Ignoring bad configuration entry in /usr/local/etc/pkg/repos/FreeBSD.conf:
true
pkg: Ignoring bad configuration entry in /u
Hi!
In the thread
http://lists.freebsd.org/pipermail/freebsd-current/2013-August/043926.html
someone stumbled upon a not very helpful error message from:
# route get
The error message is strange/misleading:
route: writing to routing socket: Invalid argument
The patch in
http
Thanks for all the helpful suggestions.
csup worked like a charm and solved the problem. I will be rebuilding my
ports gradually, starting with the development ports like Perl, gcc,
clang etc.
I am also experimenting with a custom kernel where I am eliminating
drivers and modules for isa, wireles
buildworld and buildkernel. I was able to one general ports, src
and doc
update by cvsup but now I am getting the following error message
when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to
was able to one general ports, src
and doc
update by cvsup but now I am getting the following error message
when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to the mailing list. Is this
W dniu 2010-09-23 14:02, Bartosz Stec pisze:
I am using cvsup. I had recompiled my VirtualBox port but I had not
finished recompiling the other major ports. Thanks for the suggestion.
My make.conf is deliberately very plain jane with no special conditions
or comments.
Thanks
Ralph Ellis
ralphell
doc
update by cvsup but now I am getting the following error message
when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to the mailing list. Is this a known error?
Is this an error to
following error message when I
do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction
I am new to the mailing list. Is this a known error?
Is this an error to do with the source tree or an issue on my end
Niclas Zeising wrote:
On 2010-09-23 04:29, Ralph Ellis wrote:
Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and doc
update by cvsup but now I am getting the following error message when I
do a src
On 2010-09-23 04:29, Ralph Ellis wrote:
Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and doc
update by cvsup but now I am getting the following error message when I
do a src update.
cvsup
Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and
doc update by cvsup but now I am getting the following error message
when I do a src update.
cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
u need to let it rest... there are so many people testing
it that it's getting tired!
8-).
Actually, you need to look at where the error message is
generated, which will tell you that it's running out of
the things returned by "witness_get". Then increase the
compile time constant
is the following message serious ?
Mar 10 21:49:17 multi kernel: witness_get: witness exhausted
is there anything special to do ?
this is on a newly cvsuped, very lightly loaded, -Current (4 minutes
after booting the machine)
TfH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "uns
> Date: Tue, 21 Mar 2000 18:00:46 -0500 (EST)
> From: Bill Pechter <[EMAIL PROTECTED]>
> Subject: pstat -s error message
>
> I've done two make worlds and can't seem to get rid of the following
> error... I had it on my home system, but didn't log wh
I've done two make worlds and can't seem to get rid of the following
error... I had it on my home system, but didn't log what I did to
correct it...
I just upgraded a 4.0-CURRENT (from around Jan 26) to the 4.0-STABLE
from yesterday.
when running pstat -s I get the following:
pstat: undefined s
On 2 Feb, Kenneth D. Merry wrote:
>> I'm using this hardware since 2 years now and it's the first time I see
>> this (the computercase isn't opened for 2 months now, so nothing changed
>> recently). Is this something I should worry about?
>
> This is likely a cabling or termination problem. It
On Wed, Feb 02, 2000 at 13:06:36 +0100, Alexander Leidinger wrote:
> Hi,
>
> today I've got
>
> (da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 44,
>SEQADDR == 0x113
> (da0:ahc0:0:0:0): BDR message in message buffer
> (da0:ahc0:0:0:0): SCB 0xb - timed out in Data-
Hi,
today I've got
(da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 44,
SEQADDR == 0x113
(da0:ahc0:0:0:0): BDR message in message buffer
(da0:ahc0:0:0:0): SCB 0xb - timed out in Data-in phase really in Data-in phase 54,
SEQADDR == 0x113
(da0:ahc0:0:0:0): no longer
As Bruce Evans wrote ...
> >May 27 23:39:23 p100 /kernel: vnode_pager: *** WARNING *** stale FS getpages
> >May 27 23:39:23 p100 /kernel: No strategy for buffer at 0xc13637e0
> >May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4,
> >writecount 0,
> > refcount 0, flags (VOBJBUF)
> >M
As Matthew Dillon wrote ...
> :etc
> :
> :This was during a cp -R /* /mnt where /mnt is a SCSI disk I'm testing.
> :Both disks are on seperate SCSI buses. Is this because the cp -R
> :tries to copy /proc ??
> :
> :| / o / / _Arnhem, The Netherlands- Powered by FreeBSD -
> :|/|/
>May 27 23:39:23 p100 /kernel: vnode_pager: *** WARNING *** stale FS getpages
>May 27 23:39:23 p100 /kernel: No strategy for buffer at 0xc13637e0
>May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4,
>writecount 0,
> refcount 0, flags (VOBJBUF)
>May 27 23:39:23 p100 /kernel: tag VT_P
:etc
:
:This was during a cp -R /* /mnt where /mnt is a SCSI disk I'm testing.
:Both disks are on seperate SCSI buses. Is this because the cp -R
:tries to copy /proc ??
:
:| / o / / _ Arnhem, The Netherlands- Powered by FreeBSD -
:|/|/ / / /( (_) Bulte WWW : http://www.tcja.
Hi
My P100 testbox running a fairly recent current just said:
May 27 23:39:23 p100 /kernel: vnode_pager: *** WARNING *** stale FS getpages
May 27 23:39:23 p100 /kernel: No strategy for buffer at 0xc13637e0
May 27 23:39:23 p100 /kernel: : 0xc35ffd80: type VREG, usecount 4,
writecount 0,
refcoun
36 matches
Mail list logo