On Wed, Jan 29, 2025 at 05:16:50PM +0200, Konstantin Belousov wrote:
> On Wed, Jan 29, 2025 at 05:29:35AM +, jenkins-ad...@freebsd.org wrote:
> > FreeBSD-main-amd64-test - Build #25976
> > (4da070ce6c015a994ec4ecf3d31ee94810ea19f1) - Still unstable
> >
> &g
On Wed, Jan 29, 2025 at 8:17 AM Konstantin Belousov wrote:
>
> On Wed, Jan 29, 2025 at 05:29:35AM +, jenkins-ad...@freebsd.org wrote:
> > FreeBSD-main-amd64-test - Build #25976
> > (4da070ce6c015a994ec4ecf3d31ee94810ea19f1) - Still unstable
> >
> > Build infor
On Wed, Jan 29, 2025 at 05:29:35AM +, jenkins-ad...@freebsd.org wrote:
> FreeBSD-main-amd64-test - Build #25976
> (4da070ce6c015a994ec4ecf3d31ee94810ea19f1) - Still unstable
>
> Build information: https://ci.FreeBSD.org/job/FreeBSD-main-amd64-test/25976/
> Full chang
hi!
I've pushed a bunch more changes / fixes into rtwn. This includes a bunch
of RTL8192CU fixes and preparation for firmware rate control support.
One of the changes removes an old work-around. I've tested it locally on my
11bg and 11bgn APs in 11b, 11g and 11n modes. It seemed to behave just fi
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
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
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, &pcr) == 0 &&
> ^
> fw-pf.c:252:22: error: use of undeclared ide
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, &pcr) == 0 &&
^
fw-pf.c:252:22: error: use of undeclared identifier 'DIOCGETRULE'
if (ioctl(fw->fd, DIOCGETRULE, &pcr) == 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 o
on 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.
>>
>
nZFS
>> 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 ina
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 o
ublic. 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 us
l content, then checkpointed 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 doe
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 [tx->
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 [tx->tx_quiesce_done
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
l/libdaemon | libdaemon-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 | popp
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
> "tx->tx_qu
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
t
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 bu
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
in6ifa_ifwithaddr
bj/DESTDIRs/main-CA7-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-chro
:/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 \
> -k /usr/obj/DESTDIRs/m
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=be30fd3ab2e8418a696e69f
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
>>>>
//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 on 64
n 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
> get_vm_la
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 b
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 not
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 full!
= '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 sup
vice=0x0ab0
vendor = '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 her
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:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhselasky%2Fusb4&data=05%7C01%7C%7Cc2f534f631fd47afec9908daa135d60b%7C84df9e7fe9f640afb435%7C1%7C0%7C63
s D0 D3 current D0
cap 05[80] = MSI 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
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.)
[1]https://bugs.freebsd.org/bugzi
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
Thanks
pports 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 and you s
>
> FYI: There is some experimental thunderbolt support at:
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Fhselasky%2Fusb4&data=05%7C01%7C%7C14c86eee9f5d492c41d50
> 8daa0b49bdb%7C84df9e7fe9f640afb435%7C1%7C0%7C6379989
> 94857157968%7CUnknown%7CTW
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 command as root on the ugen which
el 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 command as root on the ugen which the
if_ure belongs to:
usbconfig -d ugenX.Y dump_
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_string 0
Does the traffic resume?
Nope. Ou
spec 2 supports D0 D3 current D0
cap 05[80] = MSI 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
ch
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
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 and you see t
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
> -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
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 a supposedly "broken" if_ure dongle
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. ;)
--
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 proble
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 @@ xhci_transf
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
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 wh
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
full
=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
mA)
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 reb
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 autose
=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
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
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 half
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 src.conf:
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" running.
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 still
run
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 origina
= 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
> >>>
> >>>
1 - 100 of 927 matches
Mail list logo
