Re: Undeletable files after kyua test runs

t; g...@freebsd.org> wrote: > > > > > I recently stumbled across undeletable files that are > > > > > generated by kyua > > > > > test runs, > > > > > for example > > > > > > > > > > -rwxr-xr-x 1

Re: Undeletable files after kyua test runs

On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote: > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > > > I recently stumbled across undeletable files that are generate

Re: Undeletable files after kyua test runs

> Hi Kevin, > Hi David, > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > > I recently stumbled across undeletable files that are generated by kyua > > > test runs, > > &g

Re: Undeletable files after kyua test runs

Hi Kevin, Hi David, On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > I recently stumbled across undeletable files that are generated by kyua > > test runs, > > for example > > > > -rwxr

Re: Undeletable files after kyua test runs

On Mon, 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 > > I h

Undeletable files after kyua test runs

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 I haven't yet identified the test that generate those files, but it is impossible to delete them. I have

Re: kyua test

On 31 Jan 2020, at 7:34, Clay Daniels wrote: I've started running kyua test when I load the weekly current snapshot, and I'm a little confused about if I should run kyua test as user or root. In order to make the /usr/ports/devel/kyua port you need to be root and I have just been doing

kyua test

I've started running kyua test when I load the weekly current snapshot, and I'm a little confused about if I should run kyua test as user or root. In order to make the /usr/ports/devel/kyua port you need to be root and I have just been doing the test as root, but I notice in the instructions I'm

Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure

Thanks and all tests are good now: https://ci.freebsd.org/job/FreeBSD-head-i386-test/8056/ https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13917/ On Mon, Jan 13, 2020 at 10:36 PM Mateusz Guzik wrote: > > Fixed in r356683. > > On 1/13/20, Mateusz Guzik wrote: > > On 1

Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure

Fixed in r356683. On 1/13/20, Mateusz Guzik wrote: > On 1/13/20, Li-Wen Hsu wrote: >> On Mon, Jan 13, 2020 at 1:10 PM wrote: >>> >>> FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure >>> >>> Build information: >>> https://ci.f

Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure

On 1/13/20, Li-Wen Hsu wrote: > On Mon, Jan 13, 2020 at 1:10 PM wrote: >> >> FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure >> >> Build information: >> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/ >> Full change log: >> https

Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure

On Mon, Jan 13, 2020 at 1:10 PM wrote: > > FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure > > Build information: https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/ > Full change log: > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/changes > Ful

Re: test program for copy_file_range(2)

s of 0 bytes.) >> >> >> >> My question is.. >> >> What needs to be done to include this in FreeBSD? >> >> I see some stuff under head/tests. I could probably figure out >> >> what the macros in those files are, but I can only see tests to see

Re: test program for copy_file_range(2)

done to include this in FreeBSD? > >> I see some stuff under head/tests. I could probably figure out > >> what the macros in those files are, but I can only see tests to see if > >> arguments are valid and similar. As such, I'm not sure if this is the > >> correct &

Re: test program for copy_file_range(2)

sts to see if >> arguments are valid and similar. As such, I'm not sure if this is the correct >> place for a test like this? >> >> Thanks for any help with this, rick > >head/tests is for complete automated tests, mostly in ATF format. >Your program sounds more like t

Re: test program for copy_file_range(2)

> My question is.. > What needs to be done to include this in FreeBSD? > I see some stuff under head/tests. I could probably figure out > what the macros in those files are, but I can only see tests to see if > arguments are valid and similar. As such, I'm not sure if this is the cor

test program for copy_file_range(2)

s. I could probably figure out what the macros in those files are, but I can only see tests to see if arguments are valid and similar. As such, I'm not sure if this is the correct place for a test like this? Thanks for any help with this, rick #include #include #include #include #include #include

test

Just testing mailing lists. Delete. sean signature.asc Description: OpenPGP digital signature

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

0, rsp = 0, rbp = 0 --- > db> > > > Li-Wen > > On Mon, Aug 6, 2018 at 9:53 AM Alan Somers wrote: > > > > I can't reproduce the failure. On my VM, with a kernel from Aug-2, the > test passes. But it sure seems to be consistent in Jenkins. > > > >

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

0121589b0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db> Li-Wen On Mon, Aug 6, 2018 at 9:53 AM Alan Somers wrote: > > I can't reproduce the failure. On my VM, with a kernel from Aug-2, the test > passes. But it sure seems to be consistent in Jenkins. > > On Sun, Aug 5, 2018 at 6

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

I can't reproduce the failure. On my VM, with a kernel from Aug-2, the test passes. But it sure seems to be consistent in Jenkins. On Sun, Aug 5, 2018 at 6:59 PM, Matthew Macy wrote: > That looks like it is tied to changes I made 3 months ago. I won't be at > my desk until the end of th

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

changes matches up > > with the below example (from the log for amd64). It might not? > > > > For example (i386 is similar): > > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8493/consoleText > > > > sys/netinet/fibs_test:subnet_route_with_multiple_fibs

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

; are from Brad Davis. It is unclear to me how the changes matches up > with the below example (from the log for amd64). It might not? > > For example (i386 is similar): > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8493/consoleText > > sys/netinet/fibs_test:subn

ci.freebsd.org 's FreeBSD-head-{amd64,i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

example (from the log for amd64). It might not? For example (i386 is similar): https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8493/consoleText sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet -> Fatal trap 9: general protection fault while in kernel mode cpuid = 0; a

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On 21 June 2018 at 09:09, Ed Maste wrote: > > We'll also need a man page. I took a quick look at this, and in doing so found that the output from "llvm-objdump --help" appears to be missing a large number of single-letter options, so one more thing to sort out. As it happens there are LLVM bugs

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On 20 June 2018 at 17:26, Alexander Richardson wrote: > > When I made the change to use llvm-objdump in CheriBSD I had to change the > objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. Ah yes, I recall discussing this now. Per GNU objdump's man page, -x is equivalent to -a -f -h -p -r -t.

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On Wed, 20 Jun 2018 at 16:50 Brooks Davis wrote: > On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > > Work is in progress to migrate fully to modern and permissively > > licensed components for the tool chain. This includes moving away from > > the three obsolete binutils components

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On Wed, Jun 20, 2018 at 07:31:21PM -0400, Ed Maste wrote: > On 20 June 2018 at 18:25, Shawn Webb wrote: > > > > Would you like me to quantify the compilation breakages due to the > > full llvm toolchain switch? If so, I can do that after July 12th. > > Thanks Shawn, right now I'm interested

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On 20 June 2018 at 18:25, Shawn Webb wrote: > > Would you like me to quantify the compilation breakages due to the > full llvm toolchain switch? If so, I can do that after July 12th. Thanks Shawn, right now I'm interested specifically in llvm-objdump, with the goal of sorting it out in advance

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > Work is in progress to migrate fully to modern and permissively > licensed components for the tool chain. This includes moving away from > the three obsolete binutils components that are still in the base > system (as, ld, objdump).

Re: Tool Chain Migration: objdump users, please test llvm-objdump

On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote: > Work is in progress to migrate fully to modern and permissively > licensed components for the tool chain. This includes moving away from > the three obsolete binutils components that are still in the base > system (as, ld, objdump).

Tool Chain Migration: objdump users, please test llvm-objdump

Work is in progress to migrate fully to modern and permissively licensed components for the tool chain. This includes moving away from the three obsolete binutils components that are still in the base system (as, ld, objdump). objdump is a tool to report information about binary objects (such as

Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]

In message , Li-Wen Hsu writes: > --79b474056de4bc0b > Content-Type: text/plain; charset="UTF-8" > > On Tue, Jun 5, 2018 at 08:10 Cy Schubert wrote: > > > In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark > > Millard write > > s: > > > >From ci.freebsd.org for a

Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]

On Tue, Jun 5, 2018 at 08:10 Cy Schubert wrote: > In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark > Millard write > s: > > >From ci.freebsd.org for a -r334626 + builds: > > > > --- brk_test.full --- > > cc -target aarch64-unknown-freebsd12.0 >

Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]

On 2018-Jun-5, at 5:09 AM, Cy Schubert wrote: > In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark > Millard write > s: >>> From ci.freebsd.org for a -r334626 + builds: >> >> --- brk_test.full --- >> cc -target aarch64-unknown-freebsd12.0

Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]

In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark Millard write s: > >From ci.freebsd.org for a -r334626 + builds: > > --- brk_test.full --- > cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch > 64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2

Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]

>From ci.freebsd.org for a -r334626 + builds: --- brk_test.full --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -g -std=iso9899:1999 -fstack-protector-strong -Wsystem-headers -Werror -Wall

[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 --- Comment #6 from Charlie Li --- Also could someone remove current@ again? I accidentally used a cached page to comment and didn't pay attention to the CC list. -- You are receiving this mail because: You are

[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 w.schwarzenf...@utanet.at changed: What|Removed |Added CC|freebsd-current@FreeBSD.org

[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Charlie Li changed: What|Removed |Added CC|

[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Conrad Meyer changed: What|Removed |Added CC|freebsd-current@FreeBSD.org |c...@freebsd.org

[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Charlie Li changed: What|Removed |Added CC|

Re: Run binary from test suite

Den 2017-07-11 kl. 20:05, skrev Ngie Cooper: On Tue, Jul 11, 2017 at 10:38 AM, Panagiotes Mousikides <pagg...@yandex.com> wrote: (Resending due to moderation.) Hello! I'm a Google Summer of Code student, writing some tests for the FreeBSD test suite, and putting them under src/tests.

Re: Run binary from test suite

Den 2017-07-11 kl. 18:51, skrev Alan Somers: Are you using pfctl at build time or does your ATF test script need it? I'm assuming the latter. In that case, it's fine to call it directly. Your PATH will be correctly configured. Don't use /usr/obj, because that may no longer exist by the time

Re: Run binary from test suite

On Tue, Jul 11, 2017 at 10:38 AM, Panagiotes Mousikides <pagg...@yandex.com> wrote: > (Resending due to moderation.) > > Hello! > > I'm a Google Summer of Code student, writing some tests for the FreeBSD test > suite, and putting them under src/tests. I need to run some

Run binary from test suite

Hello! I'm a Google Summer of Code student, writing some tests for the FreeBSD test suite, and putting them under src/tests. I need to run some binaries, specifically pfctl. How should I call pfctl from my test scripts? Should I call it directly and let the shell find the binary

Run binary from test suite

(Resending due to moderation.) Hello! I'm a Google Summer of Code student, writing some tests for the FreeBSD test suite, and putting them under src/tests. I need to run some binaries, specifically pfctl. How should I call pfctl from my test scripts? Should I call it directly and let

Re: Run binary from test suite

Are you using pfctl at build time or does your ATF test script need it? I'm assuming the latter. In that case, it's fine to call it directly. Your PATH will be correctly configured. Don't use /usr/obj, because that may no longer exist by the time somebody is running the ATF test. -Alan On Tue

Re: List test, please ignore.

Never! On Tue, Apr 11, 2017 at 3:18 PM Sean Bruno wrote: > ignore > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to

List test, please ignore.

ignore signature.asc Description: OpenPGP digital signature

Re: Laptop very sluggish diring smoke-test @r314036

; Mateusz Guzik Well I "cloned" my head slice (4) to slice 3, updating source on slice 3 to r313995, rebooted to slice 3... and noticed that it didn't seem slugglish at all (unlike the earlier "smoke-test"). So before I did anything else, I rebooted it... and the countdown afte

Re: Laptop very sluggish diring smoke-test @r314036

On Tue, Feb 21, 2017 at 06:39:08AM -0800, David Wolfskill wrote: > This morning's daily "head" update & smoke-test was from: > > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263 > r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017 > r...@

Laptop very sluggish diring smoke-test @r314036

This morning's daily "head" update & smoke-test was from: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263 r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 to FreeBSD g1-252.catwh

Re: Please test EARLY_AP_STARTUP

On Fri, Dec 2, 2016 at 12:53 PM, Sepherosa Ziehau wrote: > On Fri, Dec 2, 2016 at 1:49 AM, John Baldwin wrote: >> On Thursday, December 01, 2016 01:53:29 PM Sepherosa Ziehau wrote: >>> On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau

Re: Please test EARLY_AP_STARTUP

On Fri, Dec 2, 2016 at 1:49 AM, John Baldwin wrote: > On Thursday, December 01, 2016 01:53:29 PM Sepherosa Ziehau wrote: >> On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau >> wrote: >> >>> After fdc is disabled and hyperv/storvsc is fixed, it seems to

Re: Please test EARLY_AP_STARTUP

On Thursday, December 01, 2016 01:53:29 PM Sepherosa Ziehau wrote: > On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau wrote: > >>> After fdc is disabled and hyperv/storvsc is fixed, it seems to boot > >>> fine, except a long delay (28~30seconds) here: > >>> > >>>

Re: Please test EARLY_AP_STARTUP

On Wed, Nov 30, 2016 at 9:59 AM, Sepherosa Ziehau wrote: > On Tue, Nov 29, 2016 at 2:27 AM, John Baldwin wrote: >> On Monday, November 28, 2016 02:35:07 PM Sepherosa Ziehau wrote: >>> Hi John, >>> >>> fdc seems to cause panic on Hyper-V: >>>

Re: Please test EARLY_AP_STARTUP

On Tue, Nov 29, 2016 at 2:27 AM, John Baldwin wrote: > On Monday, November 28, 2016 02:35:07 PM Sepherosa Ziehau wrote: >> Hi John, >> >> fdc seems to cause panic on Hyper-V: >> https://people.freebsd.org/~sephe/fdc_panic.png > > You shouldn't get this panic in latest HEAD

Re: Please test EARLY_AP_STARTUP

On 11/25/16, John Baldwin wrote: > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks > have been testing it for the last week or so which has exposed some > additional things to fix. I think I've resolved most of those in one > way or another, but it will

Re: Please test EARLY_AP_STARTUP

On Monday, November 28, 2016 02:35:07 PM Sepherosa Ziehau wrote: > Hi John, > > fdc seems to cause panic on Hyper-V: > https://people.freebsd.org/~sephe/fdc_panic.png You shouldn't get this panic in latest HEAD (post-r309148). > I then commented out device fdc, and I fixed one panic on Hyper-V

Re: Please test EARLY_AP_STARTUP

Hi John, fdc seems to cause panic on Hyper-V: https://people.freebsd.org/~sephe/fdc_panic.png I then commented out device fdc, and I fixed one panic on Hyper-V here: https://reviews.freebsd.org/D8656 After fdc is disabled and hyperv/storvsc is fixed, it seems to boot fine, except a long delay

Re: Please test EARLY_AP_STARTUP

On Sunday, November 27, 2016 12:46:31 PM O. Hartmann wrote: > Am Fri, 25 Nov 2016 10:20:36 -0800 > John Baldwin schrieb: > > > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks > > have been testing it for the last week or so which has exposed some > >

Re: Please test EARLY_AP_STARTUP

Am Fri, 25 Nov 2016 10:20:36 -0800 John Baldwin schrieb: > I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks > have been testing it for the last week or so which has exposed some > additional things to fix. I think I've resolved most of those in one >

Please test EARLY_AP_STARTUP

I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks have been testing it for the last week or so which has exposed some additional things to fix. I think I've resolved most of those in one way or another, but it will make things smoother if other folks can start testing this

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

tests should all be fixed. I opened PR 210329 for the >>> usr.bin/lastcomm test. I haven't investigated the others. > > ... > >> This time the totals were 15 broken (down from 24) and 41 failed (down >> from 59). >> >> My results this time were. . .

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

29 for the >> usr.bin/lastcomm test. I haven't investigated the others. ... > This time the totals were 15 broken (down from 24) and 41 failed (down > from 59). > > My results this time were. . . Hi Mark, Please file bugs for all of the individual component failures, e.g

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

On 2016-Jun-24, at 2:50 PM, Alan Somers <asom...@freebsd.org> wrote: > As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring > tests should all be fixed. I opened PR 210329 for the > usr.bin/lastcomm test. I haven't investigated the others. > > -Alan

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

>> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net >> > > wrote: >> > > With the newly less strict alignment requirements "kyua test -k >> > > /usr/tests/Kyuafile" runs to completion, unlike before. >> > &

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

> bit_alloc(int _nbits) > { > - return ((bitstr_t *)calloc(bitstr_size(_nbits), 1)); > + return (calloc(howmany(bitstr_size(_nbits), > sizeof(bitstr_t)), > + sizeof(bitstr_t))); > } > #endif > > > > > > > On Mon, J

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

(bitstr_t))); } #endif On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote: > Please open a bug for the bitstring test failures and assign it to me. > Also, since I don't have any arm hardware, please provide instructions > on how to run this code in a VM,

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

r_t * >> bit_alloc(int _nbits) >> { >> - return ((bitstr_t *)calloc(bitstr_size(_nbits), 1)); >> + return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)), >> + sizeof(bitstr_t))); >> } >> #endif >> >> >> >>

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[I've added a list of core files generated and a few other notes.] On 2016-Jun-13, at 10:29 AM, Mark Millard wrote: > With the newly less strict alignment requirements "kyua test -k > /usr/tests/Kyuafile" runs to completion, unlike before. > >> ===> Summary &g

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

On 2016-Jun-13, at 10:49 AM, Alan Somers wrote: > Please open a bug for the bitstring test failures and assign it to me. > Also, since I don't have any arm hardware, please provide instructions > on how to run this code in a VM, or where I can get access to the > hardware. >

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

nbits), sizeof(bitstr_t)), > + sizeof(bitstr_t))); > } > #endif > > > > > > > On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote: >> Please open a bug for the bitstring test failures and assign it to me. >> Also, since I don't have any

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

Please open a bug for the bitstring test failures and assign it to me. Also, since I don't have any arm hardware, please provide instructions on how to run this code in a VM, or where I can get access to the hardware. -Alan On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.

11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

With the newly less strict alignment requirements "kyua test -k /usr/tests/Kyuafile" runs to completion, unlike before. > ===> Summary > Results read from > /root/.kyua/store/results.usr_tests.20160613-080302-120731.db > Test cases: 5694 total, 54 skipped, 21 expecte

Re: please test your commits

sorry, big pointyhat here. I only did a kernel test. I'll have to figure out a cleaner way to fix this. (this is all so we don't have collisions with the linux "struct device" for linuxkpi updates, fwiw.) -a On 4 May 2016 at 18:53, Ngie Cooper (yaneurabeya) <yaneurab...@gma

Re: please test your commits

> On May 4, 2016, at 17:56, Steve Kargl > wrote: > > % make -j7 buildworld |& tee sgk.log > > --- lib/libkvm__L --- > In file included from /usr/src/lib/libkvm/kvm_pcpu.c:43: > /usr/obj/usr/src/tmp/usr/include/sys/pcpu.h:163:2: error: unknown type name >

please test your commits

% make -j7 buildworld |& tee sgk.log --- lib/libkvm__L --- In file included from /usr/src/lib/libkvm/kvm_pcpu.c:43: /usr/obj/usr/src/tmp/usr/include/sys/pcpu.h:163:2: error: unknown type name 'device_t' device_tpc_device; ^ -- Steve

Re: Missing locales causing test failures

; en_AU.ISO8859-15 > en_CA.ISO8859-15 > en_NZ.ISO8859-15 > en_US.ISO8859-15 > fr_CA.ISO8859-15 > lt_LT.ISO8859-4 > sr_YU.ISO8859-2 > sr_YU.ISO8859-5 > sr_YU.UTF-8 > > Can we bring these back? Their absence is causing test failures. > I would be surprised they do caus

Re: Missing locales causing test failures

e latest build. The latest build still has some > > missing locales, > > > > > > af_ZA.ISO8859-15 > > en_AU.ISO8859-15 > > en_CA.ISO8859-15 > > en_NZ.ISO8859-15 > > en_US.ISO8859-15 > > fr_CA.ISO8859-15 > > lt_LT.ISO8859-4 > > sr_YU.

Missing locales causing test failures

.ISO8859-2 sr_YU.ISO8859-5 sr_YU.UTF-8 Can we bring these back? Their absence is causing test failures. -- Craig ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "

Re: Quick test building a module cross all targets and architectures

On 10/27/15 17:16, Hans Petter Selasky wrote: On 10/27/15 16:49, John Baldwin wrote: With MAKE_JUST_WORLDS you would only build a "generic" module once per architecture. That savings is likely far more than the cost of the additional tools. I will try it out. Thanks for your hints and

Re: Quick test building a module cross all targets and architectures

On Tue, 2015-11-03 at 13:24 +0100, Hans Petter Selasky wrote: > On 10/27/15 17:16, Hans Petter Selasky wrote: > > On 10/27/15 16:49, John Baldwin wrote: > > > With MAKE_JUST_WORLDS you would only build > > > a "generic" module once per architecture. That savings is likely > > > far > > > more >

Re: Quick test building a module cross all targets and architectures

On 10/26/15 19:03, John Baldwin wrote: On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: Hi, We have NO_MODULES for building kernel without modules, but no NO_KERNEL to only build the modules. What do you think about the following patch: diff --git a/sys/conf/kern.post.mk

Re: Quick test building a module cross all targets and architectures

ifferrent. Hi, I understand that the compilation environments are different. How would you suggest to build-test a handful of C-files under a single device keyword and associated kernel module cross all kernels we have in a 10-minutes time-frame? MODULES_OVERRIDE can be defined from within

Re: Quick test building a module cross all targets and architectures

On 10/27/15 13:16, Konstantin Belousov wrote: On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky wrote: I understand that the compilation environments are different. How would you suggest to build-test a handful of C-files under a single device keyword and associated kernel module

Re: Quick test building a module cross all targets and architectures

On 10/27/15 13:16, Konstantin Belousov wrote: On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky wrote: I understand that the compilation environments are different. How would you suggest to build-test a handful of C-files under a single device keyword and associated kernel module

Re: Quick test building a module cross all targets and architectures

On Tue, Oct 27, 2015 at 10:31:26AM +0100, Hans Petter Selasky wrote: > I understand that the compilation environments are different. > > How would you suggest to build-test a handful of C-files under a single > device keyword and associated kernel module cross all kernels we hav

Re: Quick test building a module cross all targets and architectures

; > > How would you suggest to build-test a handful of C-files under a > > > single > > > device keyword and associated kernel module cross all kernels we > > > have in > > > a 10-minutes time-frame? MODULES_OVERRIDE can be defined from > > > with

Re: Quick test building a module cross all targets and architectures

On Tuesday, October 27, 2015 10:06:41 AM Hans Petter Selasky wrote: > On 10/26/15 19:03, John Baldwin wrote: > > On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: > >> Hi, > >> > >> We have NO_MODULES for building kernel without modules, but no NO_KERNEL > >> to only build the

Re: Quick test building a module cross all targets and architectures

On 10/27/15 16:49, John Baldwin wrote: With MAKE_JUST_WORLDS you would only build a "generic" module once per architecture. That savings is likely far more than the cost of the additional tools. I will try it out. Thanks for your hints and tips. --HPS

Re: Quick test building a module cross all targets and architectures

+1 to this thankyou! -adrian On 26 October 2015 at 02:11, Hans Petter Selasky wrote: > Hi, > > We have NO_MODULES for building kernel without modules, but no NO_KERNEL to > only build the modules. > > What do you think about the following patch: > >> diff --git

Quick test building a module cross all targets and architectures

Hi, We have NO_MODULES for building kernel without modules, but no NO_KERNEL to only build the modules. What do you think about the following patch: diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk index ddf828e..f0920df 100644 --- a/sys/conf/kern.post.mk +++

Re: Quick test building a module cross all targets and architectures

for modules. I am only aware of > exceptions for i915kms, which was done for a reason which is no longer > valid. In other words, if your goal is to check that the change does not > break compilation of some kernel code, then it is wrong to not compile > kernels. > > Note tha

Re: Quick test building a module cross all targets and architectures

On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: > Hi, > > We have NO_MODULES for building kernel without modules, but no NO_KERNEL > to only build the modules. > > What do you think about the following patch: > > > diff --git a/sys/conf/kern.post.mk b/sys/conf/kern.post.mk >

Re: Quick test building a module cross all targets and architectures

On Mon, Oct 26, 2015 at 11:03:07AM -0700, John Baldwin wrote: > On Monday, October 26, 2015 10:11:43 AM Hans Petter Selasky wrote: > > Hi, > > > > We have NO_MODULES for building kernel without modules, but no NO_KERNEL > > to only build the modules. > > > > What do you think about the

Re: sa(4) driver changes available for test

-byte tape record bigger than supplied buffer Is this just informational? If so, I'll ignore it. Yes, it's informational. It tells you that your tape blocks are 64512 bytes long. Or at least the first one is. The initial tape mount inside the sa(4) driver does a test read with an 8K buffer

Re: sa(4) driver changes available for test

On Mar 2, 2015, at 12:26 PM, Kenneth D. Merry k...@freebsd.org wrote: On Mon, Mar 02, 2015 at 11:43:15 -0500, Dan Langille wrote: On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry k...@freebsd.org wrote: On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: On Mar 1, 2015, at 7:36

Re: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting

On 8 June 2015 at 11:29, Adrian Chadd adr...@freebsd.org wrote: Sigh. This patch: https://people.freebsd.org/~adrian/net80211/20150524-iwn-delay-xmit-passive-1.diff along with the latest net80211 tree in -HEAD will buffer frames until the first beacon is received after association. It

<    1   2   3   4   5   6   7   8   9   >