On 14 Sep 2023, at 15:34, Mark Millard wrote:
> [I've cc'd a couple of folks that have dealt with fixing
> breakage in the past.]
>
I’ve submitted a fix for libdnet in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273899 because it blocks
net/scapy, which we rely on for tests.
I do not plan
[I've cc'd a couple of folks that have dealt with fixing
breakage in the past.]
From: Kristof Provost
Subject: Re: git: 8d49fd7331bc - main - pf: remove DIOCGETRULE and
DIOCGETSTATUS : net/py-libdnet and net/scapy now broken, kyua test suite damaged
Date: September 14, 2023 at 02:02:38 PDT
Hi Mark,
On 14 Sep 2023, at 7:37, Mark Millard wrote:
> This change leads the port net/py-libdnet to be broken:
>
> --- fw-pf.lo ---
> fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
> if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
> ^
> fw-pf.c:252:22: error: use of undeclared
This change leads the port net/py-libdnet to be broken:
--- fw-pf.lo ---
fw-pf.c:212:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
^
fw-pf.c:252:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, ) == 0 &&
^
---
Just FYI:
For the specific machine/storage media combination
used for the openzfs import testing, the following
combination seemed to work well relative to the
subject of the "odd result":
A) /etc/sysctl.conf having "vfs.zfs.per_txg_dirty_frees_percent=30"
B) autotrim off but use of "zpool trim
On Sep 5, 2023, at 00:00, Mark Millard wrote:
> On Sep 4, 2023, at 22:06, Mark Millard wrote:
>
>> . . .
>
> So I tried 30 for per_txg_dirty_frees_percent for 2 contexts:
> autotrim on
> vs.
> autotrim off
>
> where there was 100 GiByte+ to delete after a poudriere
> bulk run.
>
> autotrim
can't promise
>>> I'll take it right now, so anybody else is welcome.
>>
>> As I understand, there are contexts were 5 is inappropriate
>> and 30 works fairly well: no good single answer as to what
>> value range will avoid problems.
>>
>>>> An
FS
>> upstream to be visible to a wider public. Unfortunately I have several
>> other project I must work on, so if it is not a regression I can't promise
>> I'll take it right now, so anybody else is welcome.
>
> As I understand, there are contexts were 5 is inappropriate
>
so if it is not a regression I can't promise I'll take it right
> now, so anybody else is welcome.
As I understand, there are contexts were 5 is inappropriate
and 30 works fairly well: no good single answer as to what
value range will avoid problems.
>> An overall point for the goal of my activity i
. Unfortunately I have
several other project I must work on, so if it is not a regression I
can't promise I'll take it right now, so anybody else is welcome.
An overall point for the goal of my activity is: what makes a
good test context for checking if ZFS is again safe to use?
May be other
kpointed before doing the
>>>> git fetch to start to set up the experiment.
>
> OK. And I see no scrub or async destroy, that could delay sync thread.
> Though I don't see them in the above procstat either.
>
>>>> /etc/sysctl.conf does have:
>>>>
On 04.09.2023 05:56, Mark Millard wrote:
On Sep 4, 2023, at 02:00, Mark Millard wrote:
On Sep 3, 2023, at 23:35, Mark Millard wrote:
On Sep 3, 2023, at 22:06, Alexander Motin wrote:
On 03.09.2023 22:54, Mark Millard wrote:
After that ^t produced the likes of:
load: 6.39 cmd: sh 4849
On Sep 4, 2023, at 02:00, Mark Millard wrote:
> On Sep 3, 2023, at 23:35, Mark Millard wrote:
>
>> On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>>
>>>
>>> On 03.09.2023 22:54, Mark Millard wrote:
After that ^t produced the likes of:
load: 6.39 cmd: sh 4849
On Sep 3, 2023, at 23:35, Mark Millard wrote:
> On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>
>>
>> On 03.09.2023 22:54, Mark Millard wrote:
>>> After that ^t produced the likes of:
>>> load: 6.39 cmd: sh 4849 [tx->tx_quiesce_done_cv] 10047.33r 0.51u 121.32s
>>> 1% 13004k
>>
>> So the
ibdaemon-0.14_1
[00:21:49] [29] [00:15:17] Builder started
[00:21:49] [20] [00:15:18] Builder started
[00:21:49] [41] [00:15:17] Builder started
[00:21:49] [29] [00:00:00] Building textproc/libunibreak | libunibreak-5.1,1
[00:21:49] [20] [00:00:00] Building graphics/poppler-data | poppler-data-0.
On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>
> On 03.09.2023 22:54, Mark Millard wrote:
>> After that ^t produced the likes of:
>> load: 6.39 cmd: sh 4849 [tx->tx_quiesce_done_cv] 10047.33r 0.51u 121.32s 1%
>> 13004k
>
> So the full state is not "tx->tx", but is actually a
>
Mark,
On 03.09.2023 22:54, Mark Millard wrote:
After that ^t produced the likes of:
load: 6.39 cmd: sh 4849 [tx->tx_quiesce_done_cv] 10047.33r 0.51u 121.32s 1%
13004k
So the full state is not "tx->tx", but is actually a
"tx->tx_quiesce_done_cv", which means the thread is waiting for new
ThreadRipper 1950X (32 hardware threads) doing bulk -J128
with USE_TMPFS=no , no ALLOW_MAKE_JOBS , no
ALLOW_MAKE_JOBS_PACKAGES , USB3 NVMe SSD storage/ZFS-boot-media,
debug system build in use :
[00:03:44] Building 34214 packages using up to 128 builders
[00:03:44] Hit CTRL+t at any time to see
See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965
and:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966
All involve 'Alignment Fault' on read at some point
but the 272966 ones first involve: Kernel page fault with
the following non-sleepable locks held during
-chroot/bin\
:/usr/obj/DESTDIRs/main-CA7-chroot/usr/sbin\
:/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin\
:/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\
:/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\
:/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \
/usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test
r/obj/DESTDIRs/main-CA7-chroot/usr/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/sbin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/bin\
> :/usr/obj/DESTDIRs/main-CA7-chroot/root/bin \
> /usr/obj/DESTDIRs/main-CA7-chroot/usr/bin/kyua test \
> -k /usr/obj/DESTDIRs/main-C
ops the reference on the current
>>>>>> address space an extra time, probably freeing it).
>>>>>>
>>>>>> Mike
>>>>
>>>> The fix is in
>>>> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a69
gt;>>>>
>>>>> Mike
>>>
>>> The fix is in
>>> https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
>>>
>>>> The bug was introduced in January, 2022. It allows 32 bit binaries to
>>>>
https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
>>
>>> The bug was introduced in January, 2022. It allows 32 bit binaries to
>>> crash a 64 bit system when COMPAT_FREEBSD32 is on. Test coverage of the
>>> buggy function (sysctl_kern_p
as introduced in January, 2022. It allows 32 bit binaries to
>> crash a 64 bit system when COMPAT_FREEBSD32 is on. Test coverage of the
>> buggy function (sysctl_kern_proc_vm_layout) was added at the same time.
>>
>> There should be routine runs of 32 bit test suites
e an extra time, probably freeing it).
>>
>> Mike
The fix is in
https://cgit.freebsd.org/src/commit/?id=be30fd3ab2e8418a696e69f54a91a7e2db5962de.
> The bug was introduced in January, 2022. It allows 32 bit binaries to crash
> a 64 bit system when COMPAT_FREEB
introduced in January, 2022. It allows 32 bit binaries to crash a
64 bit system when COMPAT_FREEBSD32 is on. Test coverage of the buggy function
(sysctl_kern_proc_vm_layout) was added at the same time.
There should be routine runs of 32 bit test suites on 64 bit systems. Although
i386 and arm
On 6 Jul 2023, at 18:53, John F Carr wrote:
> The hang is caused by the sysctl call in tests/sys/kern/kern_copyin.c. The
> function below hangs when called in a 32 bit ARM process running in a chroot
> environment on a 64 bit ARM system. I will write up a bug report.
>
> static int
>
On Jul 6, 2023, at 16:53, John F Carr wrote:
> On Jun 25, 2023, at 20:16, Mark Millard wrote:
>>
>> . . .
>>
>
> The hang is caused by the sysctl call in tests/sys/kern/kern_copyin.c. The
> function below hangs when called in a 32 bit ARM process running in a chroot
> environment on a 64
g behavior after setting up storage
> media based on them. (This was a test that my builds were not
> odd for the issue.)
>
> Boot the aarch64 media and log in. (Note: I logged in
> as root.)
>
> mount the armv7 media (-noatime is just my habit)
> and then put it to use:
&g
vior after setting up storage
> media based on them. (This was a test that my builds were not
> odd for the issue.)
>
> Boot the aarch64 media and log in. (Note: I logged in
> as root.)
>
> mount the armv7 media (-noatime is just my habit)
> and then put it to use:
>
> #
Using the likes of:
FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230622-b95d2237af40-263748.img
and:
FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230622-b95d2237af40-263748.img
I have shown the following behavior after setting up storage
media based on them. (This was a test that my builds were
On 1/18/23 12:45, Gary Jennejohn wrote:
It's not clear from the content of README.md whether Hans has added
thunderbolt to the files under /sys/conf.
Currently not so much has changed there, except from regularly rebasing
the repository on top of FreeBSD-main.
I currently have my hands
xHCI Host Controller'
> class = serial bus
> subclass = USB
>
>
> maybe this tiger lake support is the problem?
>
>
> I have checked your git repository above, how could i test it here ? what
> dirs am i supposed to copy to my /usr/src ?
>
> thank you
= 'Intel Corporation'
device = 'Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller'
class = serial bus
subclass = USB
maybe this tiger lake support is the problem?
I have checked your git repository above, how could i test it here ? what dirs
am i supposed to copy to my
On 1/17/23 14:13, Ivan Quitschal wrote:
not THAT fine of course, since its limited to around 300mbps. when in
USB 3 it reaches 600mbps just fine.
but besides that limitation from the version 2.0, it really works. ive
tried a whole day of heavy traffic here and nothing happened at all.
rings
On Wed, 28 Sep 2022, Ivan Quitschal wrote:
FYI: There is some experimental thunderbolt support at:
ssages, 64 bit enabled with 1
message
cap 09[90] = vendor (length 20) Intel cap 15 version 0
cap 09[b0] = vendor (length 0) Intel cap 0 version 1
Does the system you also has Thunderbolt chip, or you use native Intel
chipet's XHCI?
Also, when running the stress test and you see t
On 9/28/22 11:47, Tomoaki AOKI wrote:
As I stated on Bug 237666 [1], I have Titan Ridge TB3 bridge on my
ThinkPad P52. The relevant part of HW probe is at comment 206 [2].
Are there any other info I can provide for Titan Ridge support?
(Not yet tried the codes.)
On Tue, 27 Sep 2022 20:17:54 +0200
Hans Petter Selasky wrote:
> On 9/27/22 15:22, Hans Petter Selasky wrote:
(snip)
> FYI: There is some experimental thunderbolt support at:
>
> https://github.com/hselasky/usb4
>
> But I'm not sure if it supports the hardware you've got.
>
> --HPS
cap 09[90] = vendor (length 20) Intel cap 15 version 0
cap 09[b0] = vendor (length 0) Intel cap 0 version 1
Does the system you also has Thunderbolt chip, or you use native
Intel chipet's XHCI?
Also, when running the stress test and you see the traffic stops,
what happens if you run this comma
>
> FYI: There is some experimental thunderbolt support at:
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Fhselasky%2Fusb4data=05%7C01%7C%7C14c86eee9f5d492c41d50
> 8daa0b49bdb%7C84df9e7fe9f640afb435%7C1%7C0%7C6379989
>
0 version 1
Does the system you also has Thunderbolt chip, or you use native
Intel chipet's XHCI?
Also, when running the stress test and you see the traffic stops,
what happens if you run this command as root on the ugen which the
if_ure belongs to:
usbconfig -d ugenX.Y dump_stri
rbolt chip, or you use native
Intel chipet's XHCI?
Also, when running the stress test and you see the traffic stops,
what happens if you run this command as root on the ugen which the
if_ure belongs to:
usbconfig -d ugenX.Y dump_string 0
Does the traffic resume?
Nope. Out of 4 times wh
pet's XHCI?
Also, when running the stress test and you see the traffic stops, what
happens if you run this command as root on the ugen which the if_ure
belongs to:
usbconfig -d ugenX.Y dump_string 0
Does the traffic resume?
Nope. Out of 4 times when traffic stopped 2 times it reported
a
I supports 8 messages, 64 bit enabled with 1 message
cap 09[90] = vendor (length 20) Intel cap 15 version 0
cap 09[b0] = vendor (length 0) Intel cap 0 version 1
Does the system you also has Thunderbolt chip, or you use native Intel
chipet's XHCI?
Also, when running the stress test a
On 9/27/22 00:25, Ivan Quitschal wrote:
Hi Hans,
how do you want me to do those tests for you ? with or without any of your
patches? With the actual code on git ?
Without any patches.
--HPS
] = vendor (length 20) Intel cap 15 version 0
cap 09[b0] = vendor (length 0) Intel cap 0 version 1
Does the system you also has Thunderbolt chip, or you use native Intel
chipet's XHCI?
Also, when running the stress test and you see the traffic stops, what
happens if you run this comma
to be something about it obviously
On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually help
a lot more without so dramatic performance decrease. Though it is likely
only a workaround and does not explain the cause, so I hope Hans more ideas
for us to test. ;)
Hi,
I've got
> -Mensagem original-
> De: Hans Petter Selasky
> Enviada em: segunda-feira, 26 de setembro de 2022 18:29
> Para: Alexander Motin ; Ivan Quitschal
>
> Cc: freebsd-current@freebsd.org; freebsd-...@freebsd.org
> Assunto: Re: RES: TP-LINK USB no carrier after speed te
that reduction of URE_MAX_TX from 4 to 1 actually
help a lot more without so dramatic performance decrease. Though it is
likely only a workaround and does not explain the cause, so I hope Hans
more ideas for us to test. ;)
Hi,
I've got a supposedly "broken" if_ure dongle from
actually
help a lot more without so dramatic performance decrease. Though it is
likely only a workaround and does not explain the cause, so I hope Hans
more ideas for us to test. ;)
--
Alexander Motin
On Mon, 26 Sep 2022, Hans Petter Selasky wrote:
Hi Ivan,
Can you revert all if_ure patches, and try this one instead.
--HPS
hi Hans
bad news im afraid, problem occurred at the first attempt on speedtest.net.
and I'm really trying to help you analizying this code here myself, but
Hi Ivan,
Can you revert all if_ure patches, and try this one instead.
--HPSdiff --git a/sys/dev/usb/controller/xhci.c b/sys/dev/usb/controller/xhci.c
index 045be9a40b99..09aefb02687d 100644
--- a/sys/dev/usb/controller/xhci.c
+++ b/sys/dev/usb/controller/xhci.c
@@ -2848,8 +2848,16 @@
On Mon, 19 Sep 2022, Ivan Quitschal wrote:
On Mon, 19 Sep 2022, Hans Petter Selasky wrote:
Hi Ivan,
Can you also test this USB kernel patch? And revert your if_ure.c patch?
--HPS
hi Hans,
it *almost* worked ... everything was perfect , full speed 600/300 on the
first 5 tests
On Mon, 19 Sep 2022, Hans Petter Selasky wrote:
Hi Ivan,
Can you also test this USB kernel patch? And revert your if_ure.c patch?
--HPS
hi Hans,
it *almost* worked ... everything was perfect , full speed 600/300 on the first
5 tests (on sppedtest.net), on the 6th test, the same
Hi Ivan,
Can you also test this USB kernel patch? And revert your if_ure.c patch?
--HPSdiff --git a/sys/dev/usb/usb_transfer.c b/sys/dev/usb/usb_transfer.c
index 20ed2c897aac..757697926106 100644
--- a/sys/dev/usb/usb_transfer.c
+++ b/sys/dev/usb/usb_transfer.c
@@ -419,6 +419,7
fine, way better now.
should this bug be in bugzilla for this ure driver as well wehave for axge?
thanks
--tzk
Hi Ivan,
I got one of those if_ure adapters at my hand, and will test it a bit
before concluding. Stay tuned and thanks for your testing efforts!
--HPS
@freebsd.org
Assunto: Re: TP-LINK USB no carrier after speed test
On 9/16/22 14:18, Ivan Quitschal wrote:
On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
On 9/16/22 08:34, Hans Petter Selasky wrote:
On 9/16/22 08:20, Hans Petter Selasky wrote:
On 9/15/22 17:36, Ivan Quitschal wrote:
On Thu, 15
after speed test
On 9/16/22 14:18, Ivan Quitschal wrote:
On Fri, 16 Sep 2022, Hans Petter Selasky wrote:
On 9/16/22 08:34, Hans Petter Selasky wrote:
On 9/16/22 08:20, Hans Petter Selasky wrote:
On 9/15/22 17:36, Ivan Quitschal wrote:
On Thu, 15 Sep 2022, Ivan Quitschal wrote:
On Thu, 15
On 9/16/22 16:31, Ivan Quitschal wrote:
-Mensagem original-
De: Hans Petter Selasky
Enviada em: sexta-feira, 16 de setembro de 2022 10:40
Para: Ivan Quitschal
Cc: freebsd-current@freebsd.org
Assunto: Re: TP-LINK USB no carrier after speed test
On 9/16/22 14:18, Ivan Quitschal wrote
> -Mensagem original-
> De: Hans Petter Selasky
> Enviada em: sexta-feira, 16 de setembro de 2022 10:40
> Para: Ivan Quitschal
> Cc: freebsd-current@freebsd.org
> Assunto: Re: TP-LINK USB no carrier after speed test
>
> On 9/16/22 14:18, Ivan Quitschal wrote
Hi,
I compared the Linux code and the FreeBSD code, and the Linux code has
firmware upload support for this device. Maybe implementing that will
fix some issues. Will come back to this after EuroBSDcon :-)
--HPS
net or any
other) , at the end of the test the eth interface dies .. it
changes from full-duplex to half-duplex/no carrier and the only
way to get the internet back thru ue0 is by rebooting the whole
thing.
not even a "service netif restart" does anything
if anyone has any ideas
the wireless but a
TP-LINK USB ethernet connected on "ue0"
ugen0.6: at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (200mA)
but something really strange is happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) , at
the end of the te
on "ue0"
ugen0.6: at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (200mA)
but something really strange is happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) ,
at the end of the test the eth interface dies .. it changes from
f
=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (200mA)
but something really strange is happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) ,
at the end of the test the eth interface dies .. it changes from
full-duplex to half-duplex/no carrier and the only
=ON (200mA)
but something really strange is happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) ,
at the end of the test the eth interface dies .. it changes from
full-duplex to half-duplex/no carrier and the only way to get the
internet back thru ue0 is by
On Thu, Sep 15, 2022 at 01:45:11PM -0300, Ivan Quitschal wrote:
capabilities=68009b
ether 54:af:97:86:be:2c
inet 192.168.0.35 netmask 0xff00 broadcast 192.168.0.255
media: Ethernet 1000baseT
status: active
supported media:
media
=ON (200mA)
but something really strange is happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) , at the
end of the test the eth interface dies .. it changes from full-duplex to
half-duplex/no carrier and the only way to get the internet back
happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) , at the
end of the test the eth interface dies .. it changes from full-duplex to
half-duplex/no carrier and the only way to get the internet back thru ue0
is by rebooting the whole thing.
not even a &quo
speedtest (could be speedtest.net or any other) , at the end of the
test the eth interface dies .. it changes from full-duplex to
half-duplex/no carrier and the only way to get the internet back thru ue0
is by rebooting the whole thing.
not even a "service netif restart" does anythin
t
the end of the test the eth interface dies .. it changes from
full-duplex to half-duplex/no carrier and the only way to get the
internet back thru ue0 is by rebooting the whole thing.
not even a "service netif restart" does anything
if anyone has any ideas why is that , would be appreci
USB ethernet connected on "ue0"
ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (200mA)
but something really strange is happening .. everytime i open the
chromium e do a speedtest (could be speedtest.net or any other) , at the
end of the test the eth interface dies ..
ugen0.6: at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (200mA)
but something really strange is happening .. everytime i open the chromium e do
a speedtest (could be speedtest.net or any other) , at the end of the test the
eth interface dies .. it changes from full-duplex to h
On Wed, 09 Feb 2022 11:08:44 +0100
Kristof Provost wrote:
> On 9 Feb 2022, at 10:57, Gary Jennejohn wrote:
> > test-includes uses pf.h when checking usage of pfvar.h.
> >
> > But, these lines in include/Makefile remove pf.h when WITHOUT_PF is
> > set in sr
On 9 Feb 2022, at 10:57, Gary Jennejohn wrote:
> test-includes uses pf.h when checking usage of pfvar.h.
>
> But, these lines in include/Makefile remove pf.h when WITHOUT_PF is
> set in src.conf:
>
> .if ${MK_PF} != "no"
> INCSGROUPS+= PF
> .endif
>
> Th
test-includes uses pf.h when checking usage of pfvar.h.
But, these lines in include/Makefile remove pf.h when WITHOUT_PF is
set in src.conf:
.if ${MK_PF} != "no"
INCSGROUPS+= PF
.endif
This breaks buildworld. The error message:
In file included from net_pfvar.c:1:
/usr/obj/usr
0x010753ca thread T0
>#0 0x1139bd9 in hexdump
> /usr/main-src/contrib/libarchive/test_utils/test_main.c:875:35
>#1 0x113b73c in assertion_text_file_contents
> /usr/main-src/contrib/libarchive/test_utils/test_main.c:1182:3
>#2 0x1125d46 in basic_cpio
> /usr/main
/contrib/libarchive/test_utils/test_main.c:875:35
#1 0x113b73c in assertion_text_file_contents
/usr/main-src/contrib/libarchive/test_utils/test_main.c:1182:3
#2 0x1125d46 in basic_cpio
/usr/main-src/contrib/libarchive/cpio/test/test_basic.c:84:2
#3 0x11259dc in test_basic
/usr/main-src
On 2022-Jan-9, at 13:47, Mark Millard wrote:
> On 2022-Jan-7, at 03:39, Mark Millard wrote:
>
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use a
On 2022-Jan-7, at 03:39, Mark Millard wrote:
> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
>
On 2022-Jan-7, at 04:31, Stefan Esser wrote:
> Am 07.01.22 um 12:49 schrieb Mark Millard:
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use and have
On 2022-Jan-7, at 05:08, Mark Millard wrote:
> On 2022-Jan-7, at 03:49, Mark Millard wrote:
>
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use a
On 2022-Jan-7, at 03:49, Mark Millard wrote:
> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" runnin
Am 07.01.22 um 12:49 schrieb Mark Millard:
> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
>
&g
Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
after finding what to control to allow the build, I installed
it in a directory tree for chroot use and have
"kyua test -k /usr/tests/Kyuafile" running.
I see evidence of various examples of one type of undefined
behavior:
Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
after finding what to control to allow the build, I installed
it in a directory tree for chroot use and have
"kyua test -k /usr/tests/Kyuafile" running.
I see evidence of one AddressSanitizer report. (kyua is sti
ration.
>>>
>>> WITH_REPRODUCIBLE_BUILD= makes a distinction between these
>>> if I remember right: (partially?) disabling itself for
>>> -dirty style.
>>>
>>> To reproduce the original style of test I need to create
>>> a branch wi
remember right: (partially?) disabling itself for
>> -dirty style.
>>
>> To reproduce the original style of test I need to create
>> a branch with my few patches checked in and do the
>> buildworlds from that branch.
>>
>> This will, of course, take a w
y experimenting. This time it was in a -dirty form (not
> checked in), again as part of my experimental exploration.
>
> WITH_REPRODUCIBLE_BUILD= makes a distinction between these
> if I remember right: (partially?) disabling itself for
> -dirty style.
>
> To reproduce the ori
= makes a distinction between these
if I remember right: (partially?) disabling itself for
-dirty style.
To reproduce the original style of test I need to create
a branch with my few patches checked in and do the
buildworlds from that branch.
This will, of course, take a while.
Sorry for the noise
Hi!
> Has anyone compiled a script/test suite for testing various NIC
> features to make sure they work/function properly?
>
> That is, being able to run a couple interfaces back to back, and turn
> off the features off on one, and make sure things like checksum offload
>
Has anyone compiled a script/test suite for testing various NIC
features to make sure they work/function properly?
That is, being able to run a couple interfaces back to back, and turn
off the features off on one, and make sure things like checksum offload
and the like work properly?
--
John
ling >>> <mailto:g...@freebsd.org>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I recently stumbled across undeletable files that are generated by kyua
> >>> test runs,
> >>> for example
> >>>
> >>>
; wrote:
>>>
>>> Hi,
>>>
>>> I recently stumbled across undeletable files that are generated by kyua
>>> test runs,
>>> for example
>>>
>>> -rwxr-xr-x 1 root wheel 0 May 9 13:10
>>> /tmp/kyua.aB
> On Jul 2, 2020, at 7:57 PM, Enji Cooper wrote:
>
>>
>> On Jun 29, 2020, at 10:26 AM, Gordon Bergling wrote:
>>
>> Hi,
>>
>> I recently stumbled across undeletable files that are generated by kyua test
>> runs,
>> for example
>
> On Jun 29, 2020, at 10:26 AM, Gordon Bergling wrote:
>
> Hi,
>
> I recently stumbled across undeletable files that are generated by kyua test
> runs,
> for example
>
> -rwxr-xr-x 1 root wheel 0 May 9 13:10
> /tmp/kyua.aB4q62/8676/work/fileforaudit
> > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
> > > > > g...@freebsd.org> wrote:
> > > > > > I recently stumbled across undeletable files that are
> > > > > > generated by kyua
> > > > > > test runs,
> >
t; On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling <
>>>>> g...@freebsd.org> wrote:
>>>>>> I recently stumbled across undeletable files that are
>>>>>> generated by kyua
>>>>>> test runs,
>>>>>> for examp
1 - 100 of 885 matches
Mail list logo
