Re: blacklist -> blocklist in current
On Tue, Jun 16, 2020 at 07:43:07AM +0200, Marc Balmer wrote: > Well, obviously anything with the word black in it must be considered > racist these days. Hmm... May be. Out of the 4k+ times the word occurred majority occurrences were for the black as in color (say of the terminal). May be we should invent a better word for that - at least till such newly invented word starts being regarded as racist in a few years time! Then, of course, we'll choose yet another word and so on. May be we should keep a watch on physicists who use the term blackhole and also see if they want to `correct' all the text written by the likes of Einstein to Stephen Hawking on the topic. Mayuresh
Re: RAIDframe question
I don't know what I did to get that volume to recover but ripping it apart and placing the good component first on reconfiguration produced a good volume on a rebuild. As I recall it looked a lot like this: Components: component0: failed /dev/wd1c: optimal Spares: /dev/wd0c: spare component0 status is: failed. skipping label Component label for /dev/wd1c: Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 Version: 2, Serial Number: 1984, Mod Counter: 7232 Clean: No, Status: 0 sectPerSU: 128, SUsPerPU: 4, SUsPerRU: 1 Queue size: 120, blocksize: 512, numBlocks: 976772992 RAID Level: 1 Autoconfig: Yes Root partition: No Last configured as: raid1 /dev/wd0c status is: spare. Skipping label. Reconstruction is 100% complete. Parity Re-write is 100% complete. Copyback is 100% complete. On the other hand, I have the following showing up after a rebuild (different volume, "raid2", mirrored 2TB disks): Components: /dev/dk0: optimal component1: spared Spares: /dev/dk1: used_spare Component label for /dev/dk0: Row: 0, Column: 0, Num Rows: 1, Num Columns: 2 Version: 2, Serial Number: 3337, Mod Counter: 468 Clean: No, Status: 0 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 Queue size: 100, blocksize: 512, numBlocks: 3907028992 RAID Level: 1 Autoconfig: Yes Root partition: No Last configured as: raid2 component1 status is: spared. Skipping label. Component label for /dev/dk1: Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 Version: 2, Serial Number: 3337, Mod Counter: 468 Clean: No, Status: 0 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 Queue size: 100, blocksize: 512, numBlocks: 3907028992 RAID Level: 1 Autoconfig: Yes Root partition: No Last configured as: raid2 Parity status: clean Reconstruction is 100% complete. Parity Re-write is 100% complete. Copyback is 100% complete. I've been thru enough different results it's hard to tell whether that is sane; I would have expected /dev/dk1 to have shifted up to 'optimal' and component1 to have vanished. On Sat, Jun 13, 2020 at 11:48 PM Martin Husemann wrote: > > On Sat, Jun 13, 2020 at 09:44:35PM -0700, Greywolf wrote: > > raidctl -a /dev/wd0c raid1 > > > > raidctl -F component0 raid1 > > I would have expected that to work. What is the raidctl status output > after the -a ? > > Martin -- --*greywolf;
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: fs/vfs/t_full:nfs_fillfs fs/vfs/t_io:nfs_extendfile fs/vfs/t_io:nfs_extendfile_append fs/vfs/t_io:nfs_holywrite fs/vfs/t_io:nfs_overwrite512 fs/vfs/t_io:nfs_overwrite64k fs/vfs/t_io:nfs_overwrite_trunc fs/vfs/t_io:nfs_read_after_unlink fs/vfs/t_io:nfs_read_fault fs/vfs/t_io:nfs_shrinkfile fs/vfs/t_io:nfs_wrrd_after_unlink fs/vfs/t_mtime_otrunc:nfs_otrunc_mtime_update fs/vfs/t_mtime_write:nfs_mtime_update_on_write fs/vfs/t_renamerace:nfs_renamerace_dirs fs/vfs/t_rmdirrace:nfs_race fs/vfs/t_ro:nfs_attrs fs/vfs/t_ro:nfs_create fs/vfs/t_ro:nfs_createdir fs/vfs/t_ro:nfs_createfifo fs/vfs/t_ro:nfs_createlink fs/vfs/t_ro:nfs_createsymlink fs/vfs/t_ro:nfs_fileio fs/vfs/t_ro:nfs_rmfile fs/vfs/t_ro:nfsro_attrs fs/vfs/t_ro:nfsro_create fs/vfs/t_ro:nfsro_createdir fs/vfs/t_ro:nfsro_createfifo fs/vfs/t_ro:nfsro_createlink fs/vfs/t_ro:nfsro_createsymlink fs/vfs/t_ro:nfsro_fileio fs/vfs/t_ro:nfsro_rmfile fs/vfs/t_unpriv:nfs_dirperms fs/vfs/t_vfsops:nfs_tfhinval fs/vfs/t_vfsops:nfs_tfhremove fs/vfs/t_vfsops:nfs_tfilehandle fs/vfs/t_vfsops:nfs_tmount fs/vfs/t_vfsops:nfs_tstatvfs fs/vfs/t_vfsops:nfs_tsync fs/vfs/t_vnops:nfs_access_simple fs/vfs/t_vnops:nfs_attrs fs/vfs/t_vnops:nfs_create_exist fs/vfs/t_vnops:nfs_create_many fs/vfs/t_vnops:nfs_create_nametoolong fs/vfs/t_vnops:nfs_create_nonalphanum fs/vfs/t_vnops:nfs_dir_notempty fs/vfs/t_vnops:nfs_dir_rmdirdotdot fs/vfs/t_vnops:nfs_dir_simple fs/vfs/t_vnops:nfs_fcntl_getlock_pids fs/vfs/t_vnops:nfs_fcntl_lock fs/vfs/t_vnops:nfs_lookup_complex fs/vfs/t_vnops:nfs_lookup_simple fs/vfs/t_vnops:nfs_lstat_symlink fs/vfs/t_vnops:nfs_read_directory fs/vfs/t_vnops:nfs_rename_dir fs/vfs/t_vnops:nfs_rename_dotdot fs/vfs/t_vnops:nfs_rename_nametoolong fs/vfs/t_vnops:nfs_rename_reg_nodir fs/vfs/t_vnops:nfs_symlink_long fs/vfs/t_vnops:nfs_symlink_root fs/vfs/t_vnops:nfs_symlink_zerolen The above tests failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.06.14.22.25.15 ad src/sys/uvm/uvm_extern.h,v 1.230 2020.06.14.22.30.44 rkujawa src/share/man/man4/mcp980x.4,v 1.7 2020.06.14.23.13.21 rillig src/usr.bin/make/str.c,v 1.47 2020.06.14.23.13.21 rillig src/usr.bin/make/unit-tests/modmatch.mk,v 1.5 2020.06.14.23.17.01 ad src/sys/kern/subr_pool.c,v 1.272 2020.06.14.23.19.11 riastradh src/sys/arch/i386/pci/glxsb.c,v 1.15 2020.06.14.23.20.15 riastradh src/sys/arch/x86/x86/via_padlock.c,v 1.29 2020.06.14.23.22.09 riastradh src/sys/dev/pci/ubsec.c,v 1.52 2020.06.14.23.22.09 riastradh src/sys/dev/pci/ubsecvar.h,v 1.11 2020.06.14.23.23.12 riastradh src/sys/dev/pci/qat/qat.c,v 1.6 2020.06.14.23.23.55 riastradh src/sys/opencrypto/cryptosoft.c,v 1.55 2020.06.14.23.24.20 ad src/sys/arch/x86/x86/tsc.c,v 1.50 2020.06.14.23.29.23 riastradh src/sys/dev/marvell/mvcesa.c,v 1.3 2020.06.14.23.38.25 kamil src/sys/rump/include/rump/rump.h,v 1.72 2020.06.15.00.18.47 christos src/external/bsd/file/dist/libmagic.pc.in,v 1.1.1.1 2020.06.15.00.18.47 christos src/external/bsd/file/dist/src/buffer.c,v 1.1.1.4 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/animation,v 1.1.1.17 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/asf,v 1.1.1.1 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/cad,v 1.1.1.11 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/commands,v 1.1.1.14 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/compress,v 1.1.1.14 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/console,v 1.1.1.11 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/database,v 1.1.1.16 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/der,v 1.1.1.3 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/dif,v 1.1.1.1 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/games,v 1.1.1.9 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/gnu,v 1.1.1.10 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/images,v 1.1.1.17 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/intel,v 1.1.1.9 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/kicad,v 1.1.1.2 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/linux,v 1.1.1.15 2020.06.15.00.18.48 christos src/external/bsd/file/dist/magic/magdir/msdos,v 1.1.1.15 2020.06.15.00.18.48 christo
Re: Automated report: NetBSD-current/i386 test failure
> On 16. Jun 2020, at 12:42, NetBSD Test Fixture wrote: > > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > >fs/vfs/t_full:nfs_fillfs [snip] >2020.06.14.23.38.25 kamil src/sys/rump/include/rump/rump.h,v 1.72 This commit seems to be the cause ... -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig signature.asc Description: Message signed with OpenPGP
uvm_amap panic in -current
This happened on aarch64 -current while running a pkgsrc bulk build: [ 346117.3280182] panic: kernel diagnostic assertion "amap->am_nused < amap->am_maxslot" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 1506 [ 346117.3380176] cpu4: Begin traceback... [ 346117.3380176] trace fp c0085a43fa10 [ 346117.3480181] fp c0085a43fa30 vpanic() at c04b2fd4 netbsd:vpanic+0x15c [ 346117.3580180] fp c0085a43faa0 kern_assert() at c07d208c netbsd:kern_assert+0x5c [ 346117.3580180] fp c0085a43fb30 amap_add() at c0412b1c netbsd:amap_add+0x214 [ 346117.3680249] fp c0085a43fb70 uvmfault_promote() at c041833c netbsd:uvmfault_promote+0x174 [ 346117.3780191] fp c0085a43fbd0 uvm_fault_internal() at c0419f70 netbsd:uvm_fault_internal+0xf78 [ 346117.3880182] fp c0085a43fdf0 data_abort_handler() at c008c754 netbsd:data_abort_handler+0x184 [ 346117.3980178] fp c0085a43fe70 trap_el0_sync() at c008bc6c netbsd:trap_el0_sync+0x27c [ 346117.4080236] tf c0085a43fed0 el0_trap() at c0089404 netbsd:el0_trap [ 346117.4180252] trapframe 0xc0085a43fed0 (304 bytes) [ 346117.4180252] pc=000200a4f5bc, spsr=2000 [ 346117.4280366]esr=9207,far=f60326efaf98 [ 346117.4280366] x0=0003, x1=00020114b000 [ 346117.4380257] x2=0003, x3=0008 [ 346117.4480252] x4=, x5= [ 346117.4480252] x6=ffd572d0, x7= [ 346117.4580251] x8=0003, x9= [ 346117.4580251]x10=0001,x11= [ 346117.4680282]x12=00020079,x13= [ 346117.4780348]x14=f60327797c18,x15= [ 346117.4780348]x16=00020107b730,x17=f6032d237100 [ 346117.4880322]x18=0068,x19=ffd57200 [ 346117.4880322]x20=2698,x21=f60326ef8900 [ 346117.4980323]x22=f60326efaf98,x23=000a [ 346117.5080321]x24=f603279ec340,x25=f603276a8b00 [ 346117.5080321]x26=f603279e7930,x27=000200d92438 [ 346117.5180324]x28=, fp=x29=ffd56fb0 [ 346117.5180324] lr=x30=000200a4fdd8, sp=ffd56fb0 [ 346117.5280369] [ 346117.5380361] cpu4: End traceback... Stopped in pid 20064.20064 (cc1plus) at netbsd:cpu_Debugger+0x4: ret
Re: blacklist -> blocklist in current
On 15.06.2020 21:44, Christos Zoulas wrote: > Hi Marc, > > When I wrote this in 2015 I did not consider the terms blacklist/whitelist > offensive, > or associated them with race. Perpetuating this Western-centric stereotype in such renames is abusive to the white East people, that used to be on the black skin side of the human history (Slavic ethnicity has etymology in the word 'slave' - do you want to rename us?). Putting it into throats of the rest of the global East world is offensive. At least the renames won't take away the title of "the White Negroes of Europe" as given with brotherhood and respect by Jean-Jacques Dessalines to so called Polanders (and perpetuated in the Hayti constitution from 1805). The fact that Americans did not follow the Last Will of the founding father of United States Kosciuszko (Polish by origin) of liberating slaves (Jefferson the 3rd president preferred to keep the slaves for better profit) and instead vandalized his memorial in the recent days is just meaningful. signature.asc Description: OpenPGP digital signature
Re: uvm_amap panic in -current
On Tue, Jun 16, 2020 at 08:52:55AM -0300, Jared McNeill wrote: > This happened on aarch64 -current while running a pkgsrc bulk build: > > [ 346117.3280182] panic: kernel diagnostic assertion "amap->am_nused < > amap->am_maxslot" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", > line 1506 Maybe the same as http://gnats.netbsd.org/54421 kern/54421: amap field am_nused becomes negative
Re: RAIDframe question
On Tue, Jun 16, 2020 at 12:18:34AM -0700, Greywolf wrote: ... > Components: > /dev/dk0: optimal > component1: spared > Spares: > /dev/dk1: used_spare ... > I would have expected /dev/dk1 to have shifted up to 'optimal' and component1 > to > have vanished. AFAIR it will after a reboot. Cheers, Patrick
Re: blacklist -> blocklist in current
In article <02813400-41f9-cec9-84d0-ed3ccd2a8...@netbsd.org>, Kamil Rytarowski wrote: >-=-=-=-=-=- >Perpetuating this Western-centric stereotype in such renames is abusive >to the white East people, that used to be on the black skin side of the >human history (Slavic ethnicity has etymology in the word 'slave' - do >you want to rename us?). Putting it into throats of the rest of the >global East world is offensive. At least the renames won't take away the >title of "the White Negroes of Europe" as given with brotherhood and >respect by Jean-Jacques Dessalines to so called Polanders (and >perpetuated in the Hayti constitution from 1805). The fact that >Americans did not follow the Last Will of the founding father of United >States Kosciuszko (Polish by origin) of liberating slaves (Jefferson the >3rd president preferred to keep the slaves for better profit) and >instead vandalized his memorial in the recent days is just meaningful. > I think that you would agree that owners of applications should be allowed to name them as they please. And that me renaming my application causes equal "abuse" (inconvenience) to everyone. christos
Re: blacklist -> blocklist in current
On 16.06.2020 16:27, Christos Zoulas wrote: > In article <02813400-41f9-cec9-84d0-ed3ccd2a8...@netbsd.org>, > Kamil Rytarowski wrote: >> -=-=-=-=-=- >> Perpetuating this Western-centric stereotype in such renames is abusive >> to the white East people, that used to be on the black skin side of the >> human history (Slavic ethnicity has etymology in the word 'slave' - do >> you want to rename us?). Putting it into throats of the rest of the >> global East world is offensive. At least the renames won't take away the >> title of "the White Negroes of Europe" as given with brotherhood and >> respect by Jean-Jacques Dessalines to so called Polanders (and >> perpetuated in the Hayti constitution from 1805). The fact that >> Americans did not follow the Last Will of the founding father of United >> States Kosciuszko (Polish by origin) of liberating slaves (Jefferson the >> 3rd president preferred to keep the slaves for better profit) and >> instead vandalized his memorial in the recent days is just meaningful. >> > > I think that you would agree that owners of applications should be > allowed to name them as they please. And that me renaming my application > causes equal "abuse" (inconvenience) to everyone. > > christos > Quod scripsi, scripsi. signature.asc Description: OpenPGP digital signature
Re: blacklist -> blocklist in current
Christos Zoulas wrote: > I think that you would agree that owners of applications should be > allowed to name them as they please. And that me renaming my application > causes equal "abuse" (inconvenience) to everyone. If my reading of the current commit guideline is correct, a case of renaming already released application doesn't fall into the "obvious" fix because some people can possibly object to breaking backward compatibility. $NetBSD: commit-guidelines,v 1.3 2005/10/11 03:14:08 jschauma Exp $ ... 4. The more intrusive your changes are the higher is the level of required prior approval. - "Obvious" fixes can be committed without any prior discussion or review. (The definition of "obvious" in the GCC Project is: "could not possibly cause anyone to object." We adopt this definition here) - All other (i. e. "non-obvious") fixes *should* have a review. - Implementing (significant) new features requires a prior discussion on an appropriate technical mailing list. - Changing existing interfaces in libraries or in the kernel requires prior approval by Core. -- Alex
Re: cmake hanging
I just had another similar hang, this time in git, while trying to pull pkgsrc/wip: ... [Switching to LWP 2518 of process 2823] 0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 2823 of process 2823): #0 0x72b102a4551a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x72b10320c754 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x00549842 in preload_index () #3 0x00558178 in refresh_index () #4 0x004252f0 in cmd_status () #5 0x004053fe in handle_builtin () #6 0x00406301 in cmd_main () #7 0x005ea9a3 in main () Thread 1 (LWP 2518 of process 2823): #0 0x72b102aa87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x72b103209791 in ?? () from /usr/lib/libpthread.so.1 #2 0x72b102ad6d0a in je_malloc_mutex_lock_slow () from /usr/lib/libc.so.12 #3 0x72b102b0e4f1 in je_arena_choose_hard () from /usr/lib/libc.so.12 #4 0x72b102ab583f in je_tsd_tcache_data_init () from /usr/lib/libc.so.12 #5 0x72b102ab5a89 in je_tsd_tcache_enabled_data_init () from /usr/lib/libc.so.12 #6 0x72b102ab1b09 in je_tsd_fetch_slow () from /usr/lib/libc.so.12 #7 0x72b102b0e82d in malloc () from /usr/lib/libc.so.12 #8 0x005cbed5 in xrealloc () #9 0x005a04d0 in strbuf_grow () #10 0x005aa74b in lstat_cache_matchlen () #11 0x005aa885 in threaded_has_symlink_leading_path () #12 0x005495b8 in preload_thread () #13 0x72b10320bee0 in ?? () from /usr/lib/libpthread.so.1 #14 0x72b102a92370 in ?? () from /usr/lib/libc.so.12 #15 0x0020 in ?? () #16 0x in ?? () The system is from today: $ uname -a NetBSD ymir 9.99.67 NetBSD 9.99.67 (GENERIC) #4: Tue Jun 16 09:10:01 BST 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC am d64 Chavdar On Thu, 11 Jun 2020 at 00:19, Andrew Doran wrote: > > On Mon, Jun 08, 2020 at 03:38:44PM +0100, Chavdar Ivanov wrote: > > On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > > > > > Hi, > > > > > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > > > ... ; quit sorted it out. > > > > > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > > > > > Just to mention that after I quit gdb and detached from the process > > > > > > it > > > > > > continued and completed the build . . . > > > > > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > > > > > The second hung sample - with git - also completed OK after I quit > > > > gdb... > > > > I had another three cmake hangs just like this today, while rebuilding > > bits of kf5. > > > > Just to confirm - the moment one answers 'y' to the question whether > > to leave gdb the process continues and the build succeeds. > > > > This is somewhat annoying; although it does not stop the rebuild > > process, it makes it impossible to complete unattended. > > I just made some more changes to libpthread today that may help. I'll try > building KDE soon. > > Cheers, > Andrew --
Re: blacklist -> blocklist in current
> On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote: > > If my reading of the current commit guideline is correct, a case > of renaming already released application doesn't fall into the > "obvious" fix because some people can possibly object to breaking > backward compatibility. You are correct, and this is why I discussed it with core before doing it. In fact the name "block" instead of "deny" was suggested by a core member: I chose "block" over "deny" because of similarity to the previous name, and because some of the API's start with "bl_" and would not need to be modified. If "deny" was chosen instead, these would probably need to be changed to "dl_" and that prefix is associated with the dynamic linker. Best, christos signature.asc Description: Message signed with OpenPGP
commit-guidelines (was Re: blacklist -> blocklist in current)
Christos Zoulas wrote: > > > > On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote: > > > > If my reading of the current commit guideline is correct, a case > > of renaming already released application doesn't fall into the > > "obvious" fix because some people can possibly object to breaking > > backward compatibility. > > You are correct, and this is why I discussed it with core before doing it. In > fact > the name "block" instead of "deny" was suggested by a core member: I chose > "block" over "deny" because of similarity to the previous name, > and because some of the API's start with "bl_" and would not need to be > modified. If "deny" was chosen instead, these would probably need to be > changed to "dl_" and that prefix is associated with the dynamic linker. Clause 4 (and probably others) needs a serious overhaul to make sure that all cases that needs a review reach everyone who has a voice (and who can potentially object) before involving the Core, if necessary. The current wording isn't inclusive, period. -- Alex
Re: commit-guidelines (was Re: blacklist -> blocklist in current)
+ core. christos > On Jun 16, 2020, at 3:31 PM, Alexander Nasonov wrote: > > Christos Zoulas wrote: >> >> >>> On Jun 16, 2020, at 2:17 PM, Alexander Nasonov wrote: >>> >>> If my reading of the current commit guideline is correct, a case >>> of renaming already released application doesn't fall into the >>> "obvious" fix because some people can possibly object to breaking >>> backward compatibility. >> >> You are correct, and this is why I discussed it with core before doing it. >> In fact >> the name "block" instead of "deny" was suggested by a core member: I chose >> "block" over "deny" because of similarity to the previous name, >> and because some of the API's start with "bl_" and would not need to be >> modified. If "deny" was chosen instead, these would probably need to be >> changed to "dl_" and that prefix is associated with the dynamic linker. > > Clause 4 (and probably others) needs a serious overhaul to make > sure that all cases that needs a review reach everyone who has a > voice (and who can potentially object) before involving the Core, > if necessary. > > The current wording isn't inclusive, period. > > -- > Alex signature.asc Description: Message signed with OpenPGP
Re: RAIDframe question
hello. If you reboot again, the raid2 will probably look as you expect. The general procedure for disk replacement is; 1. raidctl -a /dev/newdisk raidset 2. raidctl -F /dev/baddisk raidset (fails the bad disk, uses the spare and reconstructs to it) 3. Raid is left with a used_spare, but all is wel. 4. Reboot. All components become optimal. It has long been my desire that once a spare is used, it get automatically promoted to optimal without the interveening reboot. I probably could have made this change with Greg's blessing, but I never did the work. Hope that helps. -Brian On Jun 16, 12:18am, Greywolf wrote: } Subject: Re: RAIDframe question } I don't know what I did to get that volume to recover but ripping } it apart and placing the good component first on reconfiguration } produced a good volume on a rebuild. As I recall it looked a lot like this: } } Components: } component0: failed } /dev/wd1c: optimal } Spares: } /dev/wd0c: spare } component0 status is: failed. skipping label } Component label for /dev/wd1c: }Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 }Version: 2, Serial Number: 1984, Mod Counter: 7232 }Clean: No, Status: 0 }sectPerSU: 128, SUsPerPU: 4, SUsPerRU: 1 }Queue size: 120, blocksize: 512, numBlocks: 976772992 }RAID Level: 1 }Autoconfig: Yes }Root partition: No }Last configured as: raid1 } /dev/wd0c status is: spare. Skipping label. } Reconstruction is 100% complete. } Parity Re-write is 100% complete. } Copyback is 100% complete. } } On the other hand, I have the following showing up after } a rebuild (different volume, "raid2", mirrored 2TB disks): } } Components: } /dev/dk0: optimal } component1: spared } Spares: } /dev/dk1: used_spare } Component label for /dev/dk0: }Row: 0, Column: 0, Num Rows: 1, Num Columns: 2 }Version: 2, Serial Number: 3337, Mod Counter: 468 }Clean: No, Status: 0 }sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 }Queue size: 100, blocksize: 512, numBlocks: 3907028992 }RAID Level: 1 }Autoconfig: Yes }Root partition: No }Last configured as: raid2 } component1 status is: spared. Skipping label. } Component label for /dev/dk1: }Row: 0, Column: 1, Num Rows: 1, Num Columns: 2 }Version: 2, Serial Number: 3337, Mod Counter: 468 }Clean: No, Status: 0 }sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1 }Queue size: 100, blocksize: 512, numBlocks: 3907028992 }RAID Level: 1 }Autoconfig: Yes }Root partition: No }Last configured as: raid2 } Parity status: clean } Reconstruction is 100% complete. } Parity Re-write is 100% complete. } Copyback is 100% complete. } } I've been thru enough different results it's hard to tell whether that is sane; } I would have expected /dev/dk1 to have shifted up to 'optimal' and component1 to } have vanished. } } On Sat, Jun 13, 2020 at 11:48 PM Martin Husemann wrote: } > } > On Sat, Jun 13, 2020 at 09:44:35PM -0700, Greywolf wrote: } > > raidctl -a /dev/wd0c raid1 } > > } > > raidctl -F component0 raid1 } > } > I would have expected that to work. What is the raidctl status output } > after the -a ? } > } > Martin } } } } -- } --*greywolf; >-- End of excerpt from Greywolf
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2020.06.15.16.59.05. An extract from the build.sh output follows: /tmp/bracket/build/2020.06.15.16.59.05-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: control.c:(.text+0x87f): undefined reference to `ps_ctl_sendargs' /tmp/bracket/build/2020.06.15.16.59.05-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: privsep.o: in function `ps_start': privsep.c:(.text+0x486): undefined reference to `ps_ctl_start' /tmp/bracket/build/2020.06.15.16.59.05-i386/tools/lib/gcc/i486--netbsdelf/8.4.0/../../../../i486--netbsdelf/bin/ld: privsep.o: in function `ps_stop': privsep.c:(.text+0x587): undefined reference to `ps_ctl_stop' collect2: error: ld returned 1 exit status *** [dhcpcd] Error code 1 nbmake[10]: stopped in /tmp/bracket/build/2020.06.15.16.59.05-i386/src/external/bsd/dhcpcd/sbin/dhcpcd 1 error The following commits were made between the last successful build and the failed build: 2020.06.15.16.58.01 roy src/external/bsd/dhcpcd/dist/src/control.c,v 1.1.1.12 2020.06.15.16.58.01 roy src/external/bsd/dhcpcd/dist/src/defs.h,v 1.1.1.43 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/arp.c,v 1.1.1.17 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/arp.h,v 1.1.1.12 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/control.h,v 1.1.1.9 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/dhcpcd.h,v 1.1.1.16 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/eloop.c,v 1.1.1.12 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/eloop.h,v 1.1.1.9 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/if-options.h,v 1.1.1.17 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/if.c,v 1.1.1.22 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/if.h,v 1.1.1.17 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/ipv4ll.c,v 1.1.1.13 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep-bsd.c,v 1.1.1.4 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep-control.c,v 1.1.1.1 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep-control.h,v 1.1.1.1 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep-inet.c,v 1.1.1.5 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep-root.c,v 1.1.1.5 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep-root.h,v 1.1.1.4 2020.06.15.16.58.02 roy src/external/bsd/dhcpcd/dist/src/privsep.h,v 1.1.1.4 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/bpf.c,v 1.16 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/dhcp6.c,v 1.21 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/dhcpcd.c,v 1.39 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/if-bsd.c,v 1.22 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/if-options.c,v 1.25 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/ipv6nd.c,v 1.21 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/logerr.c,v 1.5 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/privsep.c,v 1.5 2020.06.15.16.59.05 roy src/external/bsd/dhcpcd/dist/src/script.c,v 1.8 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.15.16.59.05
daily CVS update output
Updating src tree: P src/lib/libc/rpc/svc_fdset.h P src/libexec/ld.elf_so/arch/aarch64/mdreloc.c P src/libexec/ld.elf_so/arch/arm/mdreloc.c P src/sbin/fsck_lfs/kernelops.c P src/sys/arch/cobalt/conf/GENERIC P src/sys/conf/Makefile.kern.inc P src/sys/dev/raidframe/rf_netbsdkintf.c P src/sys/dev/usb/usbdi_util.c P src/sys/dev/usb/usbdi_util.h P src/sys/netinet6/in6.c P src/sys/netinet6/in6_var.h P src/sys/netinet6/scope6.c P src/sys/netinet6/scope6_var.h P src/sys/sys/vmem.h P src/tests/fs/common/fstest_ext2fs.c P src/tests/fs/common/fstest_ffs.c P src/tests/fs/common/fstest_lfs.c P src/tests/fs/common/fstest_msdosfs.c P src/tests/fs/common/fstest_nfs.c P src/tests/fs/common/fstest_puffs.c P src/tests/fs/common/fstest_rumpfs.c P src/tests/fs/common/fstest_sysvbfs.c P src/tests/fs/common/fstest_tmpfs.c P src/tests/fs/common/fstest_udf.c P src/tests/fs/common/fstest_v7fs.c P src/tests/fs/common/fstest_zfs.c P src/tests/fs/nfs/nfsservice/getmntinfo.c P src/tests/fs/nfs/nfsservice/rumpnfsd.c P src/tests/lib/libarchive/t_libarchive.sh P src/usr.sbin/mountd/mountd.c P src/usr.sbin/mtree/mtree.8 P src/usr.sbin/nfsd/nfsd.c P src/usr.sbin/rpcbind/check_bound.c P src/usr.sbin/rpcbind/rpcb_svc_com.c P src/usr.sbin/rpcbind/rpcbind.c P src/usr.sbin/rpcbind/util.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P sys/arch/mac68k/dev/ams.c P sys/dev/usb/if_otus.c P sys/dev/usb/if_run.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38981188 Jun 17 03:19 ls-lRA.gz
missing etc/rc.d file? (Was: blacklist -> blocklist in current)
On Sunday 2020-06-14 22:01 -0400, Christos output: :I've renamed blacklist to blocklist, so if you are currently using it, :you should rename things accordingly: : : - rc.conf variable : - /var/db/blacklist.db file : - npf table name : :Apologies for the inconvenience, :christos Hi, I cannot see (in CVS or FTP): src/etc/rc.d/blocklistd Regards, Geoff
