daily CVS update output
Updating src tree: U src/crypto/external/bsd/openssl/lib/libcrypto/crypto.expsym P src/distrib/amd64/ramdisks/common/Makefile.ramdisk P src/distrib/i386/ramdisks/common/Makefile.ramdisk P src/distrib/sets/lists/debug/module.md.amd64 P src/distrib/sets/lists/debug/module.md.i386 P src/distrib/sets/lists/modules/md.amd64 P src/distrib/sets/lists/modules/md.i386 P src/etc/etc.amd64/Makefile.inc P src/etc/etc.i386/Makefile.inc P src/lib/libc/arch/sparc64/gen/fpsetround.c U src/share/man/man4/acpihed.4 U src/share/man/man4/apei.4 P src/share/mk/bsd.lib.mk P src/sys/arch/amd64/conf/ALL P src/sys/arch/i386/conf/ALL P src/sys/dev/acpi/acpi.c U src/sys/dev/acpi/acpi_hed.c P src/sys/dev/acpi/acpivar.h U src/sys/dev/acpi/apei.c U src/sys/dev/acpi/apei_bert.c U src/sys/dev/acpi/apei_bertvar.h U src/sys/dev/acpi/apei_cper.h U src/sys/dev/acpi/apei_einj.c U src/sys/dev/acpi/apei_einjvar.h U src/sys/dev/acpi/apei_erst.c U src/sys/dev/acpi/apei_erstvar.h U src/sys/dev/acpi/apei_hed.h U src/sys/dev/acpi/apei_hest.c U src/sys/dev/acpi/apei_hestvar.h U src/sys/dev/acpi/apei_interp.c U src/sys/dev/acpi/apei_interp.h U src/sys/dev/acpi/apei_mapreg.c U src/sys/dev/acpi/apei_mapreg.h U src/sys/dev/acpi/apei_reg.c U src/sys/dev/acpi/apei_reg.h U src/sys/dev/acpi/apeivar.h P src/sys/dev/acpi/files.acpi P src/sys/dev/vmt/vmt_subr.c P src/sys/modules/Makefile U src/sys/modules/acpihed/Makefile U src/sys/modules/acpihed/acpihed.ioconf U src/sys/modules/apei/Makefile U src/sys/modules/apei/apei.ioconf P src/usr.bin/audio/common/wav.c P src/usr.bin/audio/record/record.c P src/usr.sbin/sysinst/msg.mi.en Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 45691128 Mar 21 03:03 ls-lRA.gz
Re: glitches in framebuffer console - NL/CR
Date:Wed, 20 Mar 2024 20:37:09 +0100 From:Riccardo Mottola Message-ID: | Certain programs however print out the text by making only a NL and no | CR, All programs (well, almost all) do that. Normally the tty driver adds a \r after (or before) each \n on output and converts \r into \n on input. But those translations can be disabled - it all depends what is running on the terminal when the output is produced, and what modes that program wants the terminal to be in. This is all "normal". | Sometimes in this situation also keyboard input stops to work, e.g. | pkgin asks Y/n and typing does nothing. The usual reason for that kind of thing is two programs reading from the terminal at the same time. When that happens, where the input is sent is anyone's guess. uwe@'s suggestion to check /etc/ttys and make sure that two different names for the same console aren't both enabled is a good one. I'd use fstat /dev/ttyE0 /dev/console /dev/constty rather than ps to check for users though. In that you can ignore any process (fd) where the r/w field is just "w" (write only processes won't be the ones affecting things in general). kre
Re: gdb crashes on current
On Wed, Mar 20, 2024 at 11:33:30PM +0500, Vitaly Shevtsov wrote: > Hello! > > It seems that gdb from base NetBSD image doesn't work with netbsd's > libcurses in tui mode: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 > [Current thread is 1 (process 12621)] > (gdb) bt > #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 > #1 0x0101ef97 in handle_fatal_signal(int) () > #2 0x0101f152 in handle_sigsegv(int) () > #3 > #4 0x756547e679e1 in prefresh () from /usr/lib/libcurses.so.9 > #5 0x00eec1a0 in tui_source_window_base::refresh_window() () > #6 0x00eedf18 in tui_unhighlight_win(tui_win_info*) () > #7 0x00eec5f8 in > tui_source_window_base::do_erase_source_content(char const*) () > #8 0x00ef60e5 in tui_layout_split::apply(int, int, int, int, bool) () > #9 0x00ef4aa8 in tui_apply_current_layout(bool) () > #10 0x00ef4ddb in tui_set_layout(tui_layout_split*) () > #11 0x00ee4f2f in tui_enable() () > #12 0x00ee5487 in tui_rl_switch_mode(int, int) () > #13 0x01379fa8 in _rl_dispatch_subseq () > #14 0x0137aa27 in _rl_dispatch_callback () > #15 0x0135a1f1 in rl_callback_read_char () > #16 0x0101f40e in gdb_rl_callback_read_char_wrapper_noexcept() () > #17 0x0102020d in gdb_rl_callback_read_char_wrapper(void*) () > #18 0x0101eeb1 in stdin_event_handler(int, void*) () > #19 0x01300eba in gdb_wait_for_event(int) [clone .part.0] () > #20 0x0130155a in gdb_do_one_event(int) () > #21 0x00fa0576 in captured_command_loop() () > #22 0x00fa2113 in gdb_main(captured_main_args*) () > #23 0x013c66fb in main () Just had a go, and "tui enable" doesn't get as far as libcurses (gdb) bt #0 0x7f7ff78dfffa in ?? () #1 0x00222b45 in gdb_rl_callback_handler () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:262 #2 0x00222cfa in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count () at /usr/export/amd64/usr/include/g++/bits/shared_ptr_base.h:1070 #3 std::__shared_ptr, std::allocator >, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr () at /usr/export/amd64/usr/include/g++/bits/shared_ptr_base.h:1524 #4 std::shared_ptr, std::allocator > >::~shared_ptr () at /usr/export/amd64/usr/include/g++/bits/shared_ptr.h:175 #5 gdb_exception::~gdb_exception () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdbsupport/common-exceptions.h:114 #6 gdb_rl_callback_read_char_wrapper_noexcept () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:212 #7 0x7f7ff78e00b0 in ?? () #8 0x0001000b in ?? () #9 0x in ?? () but "gdb -tui" does: Thread 1 "" received signal SIGSEGV, Segmentation faultprefresh (pad=0x0, pbegy=0, pbegx=0, sbegy=1, sbegx=5, smaxy=0, smaxx=78) at /usr/src/lib/libcurses/refresh.c:511 511 pad->pbegy = pbegy; (gdb) bt #0 prefresh (pad=0x0, pbegy=0, pbegx=0, sbegy=1, sbegx=5, smaxy=0, smaxx=78) at /usr/src/lib/libcurses/refresh.c:511 #1 0x000f60ff in tui_source_window_base::refresh_window () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-winsource.c:267 #2 0x000f7e68 in tui_unhighlight_win () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-wingeneral.c:138 #3 tui_unhighlight_win () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-wingeneral.c:131 #4 0x000f6552 in tui_source_window_base::do_erase_source_content () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-winsource.c:219 #5 0x0010008b in tui_layout_split::apply () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-layout.c:1019 #6 0x000fe927 in tui_apply_current_layout () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-layout.c:81 #7 0x000fec65 in tui_set_layout () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-layout.c:150 #8 0x000f1f2f in tui_enable () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui.c:452 #9 0x001c319c in interp_set () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/interps.c:191 #10 0x001a7c55 in captured_main_1 () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:1145 #11 0x001a8b0f in captured_main () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:1320 #12 gdb_main () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:1345 #13 0x005be5cf in main () at /usr/src/external/gpl3/gdb/bin/gdb/../../dist/gdb/gdb.c:32 (gdb) print pad $1 = (WINDOW *) 0x0 (gdb) frame 1 #1 0x000f60ff in tui_source_window_base::refresh_window () at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/tui/tui-winsource.c:267 267
Re: glitches in framebuffer console - NL/CR
On Wed, Mar 20, 2024 at 20:37:09 +0100, Riccardo Mottola wrote: > Boot, dmesg, login come up fine, no issue. > > Certain programs however print out the text by making only a NL and no > CR, making a staircase effect. > E.g. pkgin or dhcpcd do that. > Sometimes in this situation also keyboard input stops to work, e.g. > pkgin asks Y/n and typing does nothing. > dhcpcd completes without issues. May be something weird in your /etc/ttys? Like getty on both cons* and ttyE0 and the like? The input either works and just not echo'ed and needs explicit ^J instead or to get read by the program. Or it may be stolen by the other program reading from the terminal. Switch to another console and check "ps auxww" output for processes that use ttyE0. > Using bash however seems fine. readline explicitly manipulates tty state, so it can dodge a lot of weird terminal conditions. -uwe
Re: gdb crashes on current
On Thu 21 Mar 2024 at 00:29:40 +0500, Vitaly Shevtsov wrote: > Hello! > > It's when you run it with the `-tui` option - text user interface. > Also you can toggle it with C-x C-a or with "tui enable" and "tui disable", too... It can be kind of nice, when it works. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: gdb crashes on current
cli is the main mode in gdb but it also has a built-in pseudo graphic mode :) On Thu, Mar 21, 2024 at 12:48 AM Justin Parrott wrote: > > The last I checked gdb it was a command line interfaced system. > > On Wed, Mar 20, 2024 at 3:47 PM Vitaly Shevtsov wrote: >> >> Sorry, what do you mean? :) >> It's native pseudo graphic interface >> >> On Thu, Mar 21, 2024 at 12:34 AM Justin Parrott >> wrote: >> > >> > Is that not the Default? >> > >> > On Wed, Mar 20, 2024 at 3:30 PM Vitaly Shevtsov >> > wrote: >> >> >> >> Hello! >> >> >> >> It's when you run it with the `-tui` option - text user interface. >> >> Also you can toggle it with C-x C-a >> >> >> >> https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.html >> >> >> >> On Thu, Mar 21, 2024 at 12:21 AM Justin Parrott >> >> wrote: >> >> > >> >> > What is TUI mode? >> >> > >> >> > On Wed, Mar 20, 2024 at 2:34 PM Vitaly Shevtsov >> >> > wrote: >> >> >> >> >> >> Hello! >> >> >> >> >> >> It seems that gdb from base NetBSD image doesn't work with netbsd's >> >> >> libcurses in tui mode: >> >> >> >> >> >> Program terminated with signal SIGSEGV, Segmentation fault. >> >> >> #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 >> >> >> [Current thread is 1 (process 12621)] >> >> >> (gdb) bt >> >> >> #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 >> >> >> #1 0x0101ef97 in handle_fatal_signal(int) () >> >> >> #2 0x0101f152 in handle_sigsegv(int) () >> >> >> #3 >> >> >> #4 0x756547e679e1 in prefresh () from /usr/lib/libcurses.so.9 >> >> >> #5 0x00eec1a0 in tui_source_window_base::refresh_window() () >> >> >> #6 0x00eedf18 in tui_unhighlight_win(tui_win_info*) () >> >> >> #7 0x00eec5f8 in >> >> >> tui_source_window_base::do_erase_source_content(char const*) () >> >> >> #8 0x00ef60e5 in tui_layout_split::apply(int, int, int, int, >> >> >> bool) () >> >> >> #9 0x00ef4aa8 in tui_apply_current_layout(bool) () >> >> >> #10 0x00ef4ddb in tui_set_layout(tui_layout_split*) () >> >> >> #11 0x00ee4f2f in tui_enable() () >> >> >> #12 0x00ee5487 in tui_rl_switch_mode(int, int) () >> >> >> #13 0x01379fa8 in _rl_dispatch_subseq () >> >> >> #14 0x0137aa27 in _rl_dispatch_callback () >> >> >> #15 0x0135a1f1 in rl_callback_read_char () >> >> >> #16 0x0101f40e in gdb_rl_callback_read_char_wrapper_noexcept() >> >> >> () >> >> >> #17 0x0102020d in gdb_rl_callback_read_char_wrapper(void*) () >> >> >> #18 0x0101eeb1 in stdin_event_handler(int, void*) () >> >> >> #19 0x01300eba in gdb_wait_for_event(int) [clone .part.0] () >> >> >> #20 0x0130155a in gdb_do_one_event(int) () >> >> >> #21 0x00fa0576 in captured_command_loop() () >> >> >> #22 0x00fa2113 in gdb_main(captured_main_args*) () >> >> >> #23 0x013c66fb in main () >> >> > >> >> > >> >> > >> >> > -- >> >> > Justin Allen Parrott >> >> > The Renegade of Fairfax, Va. >> >> > The Sun of the Mourning >> >> > >> > >> > >> > >> > -- >> > Justin Allen Parrott >> > The Renegade of Fairfax, Va. >> > The Sun of the Mourning >> > > > > > -- > Justin Allen Parrott > The Renegade of Fairfax, Va. > The Sun of the Mourning >
Re: gdb crashes on current
Sorry, what do you mean? :) It's native pseudo graphic interface On Thu, Mar 21, 2024 at 12:34 AM Justin Parrott wrote: > > Is that not the Default? > > On Wed, Mar 20, 2024 at 3:30 PM Vitaly Shevtsov wrote: >> >> Hello! >> >> It's when you run it with the `-tui` option - text user interface. >> Also you can toggle it with C-x C-a >> >> https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.html >> >> On Thu, Mar 21, 2024 at 12:21 AM Justin Parrott >> wrote: >> > >> > What is TUI mode? >> > >> > On Wed, Mar 20, 2024 at 2:34 PM Vitaly Shevtsov >> > wrote: >> >> >> >> Hello! >> >> >> >> It seems that gdb from base NetBSD image doesn't work with netbsd's >> >> libcurses in tui mode: >> >> >> >> Program terminated with signal SIGSEGV, Segmentation fault. >> >> #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 >> >> [Current thread is 1 (process 12621)] >> >> (gdb) bt >> >> #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 >> >> #1 0x0101ef97 in handle_fatal_signal(int) () >> >> #2 0x0101f152 in handle_sigsegv(int) () >> >> #3 >> >> #4 0x756547e679e1 in prefresh () from /usr/lib/libcurses.so.9 >> >> #5 0x00eec1a0 in tui_source_window_base::refresh_window() () >> >> #6 0x00eedf18 in tui_unhighlight_win(tui_win_info*) () >> >> #7 0x00eec5f8 in >> >> tui_source_window_base::do_erase_source_content(char const*) () >> >> #8 0x00ef60e5 in tui_layout_split::apply(int, int, int, int, >> >> bool) () >> >> #9 0x00ef4aa8 in tui_apply_current_layout(bool) () >> >> #10 0x00ef4ddb in tui_set_layout(tui_layout_split*) () >> >> #11 0x00ee4f2f in tui_enable() () >> >> #12 0x00ee5487 in tui_rl_switch_mode(int, int) () >> >> #13 0x01379fa8 in _rl_dispatch_subseq () >> >> #14 0x0137aa27 in _rl_dispatch_callback () >> >> #15 0x0135a1f1 in rl_callback_read_char () >> >> #16 0x0101f40e in gdb_rl_callback_read_char_wrapper_noexcept() () >> >> #17 0x0102020d in gdb_rl_callback_read_char_wrapper(void*) () >> >> #18 0x0101eeb1 in stdin_event_handler(int, void*) () >> >> #19 0x01300eba in gdb_wait_for_event(int) [clone .part.0] () >> >> #20 0x0130155a in gdb_do_one_event(int) () >> >> #21 0x00fa0576 in captured_command_loop() () >> >> #22 0x00fa2113 in gdb_main(captured_main_args*) () >> >> #23 0x013c66fb in main () >> > >> > >> > >> > -- >> > Justin Allen Parrott >> > The Renegade of Fairfax, Va. >> > The Sun of the Mourning >> > > > > > -- > Justin Allen Parrott > The Renegade of Fairfax, Va. > The Sun of the Mourning >
glitches in framebuffer console - NL/CR
Hi, I noticed that the first console (the standard one) in case of framebuffer enabled cards has strange issues. I noticed this on 9.3 as well as on 10RC on different systems and AMD vs. Intel video card I report it on this ML because t Boot, dmesg, login come up fine, no issue. Certain programs however print out the text by making only a NL and no CR, making a staircase effect. E.g. pkgin or dhcpcd do that. Sometimes in this situation also keyboard input stops to work, e.g. pkgin asks Y/n and typing does nothing. dhcpcd completes without issues. Using bash however seems fine. Switching to console N. 2... and all works fine, both commands. Did someone noticed this too? I'll try to test more systems and see. It does not happen on ALL systems I have and that is strange! Riccardo
Re: gdb crashes on current
Hello! It's when you run it with the `-tui` option - text user interface. Also you can toggle it with C-x C-a https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI.html On Thu, Mar 21, 2024 at 12:21 AM Justin Parrott wrote: > > What is TUI mode? > > On Wed, Mar 20, 2024 at 2:34 PM Vitaly Shevtsov wrote: >> >> Hello! >> >> It seems that gdb from base NetBSD image doesn't work with netbsd's >> libcurses in tui mode: >> >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 >> [Current thread is 1 (process 12621)] >> (gdb) bt >> #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 >> #1 0x0101ef97 in handle_fatal_signal(int) () >> #2 0x0101f152 in handle_sigsegv(int) () >> #3 >> #4 0x756547e679e1 in prefresh () from /usr/lib/libcurses.so.9 >> #5 0x00eec1a0 in tui_source_window_base::refresh_window() () >> #6 0x00eedf18 in tui_unhighlight_win(tui_win_info*) () >> #7 0x00eec5f8 in >> tui_source_window_base::do_erase_source_content(char const*) () >> #8 0x00ef60e5 in tui_layout_split::apply(int, int, int, int, bool) >> () >> #9 0x00ef4aa8 in tui_apply_current_layout(bool) () >> #10 0x00ef4ddb in tui_set_layout(tui_layout_split*) () >> #11 0x00ee4f2f in tui_enable() () >> #12 0x00ee5487 in tui_rl_switch_mode(int, int) () >> #13 0x01379fa8 in _rl_dispatch_subseq () >> #14 0x0137aa27 in _rl_dispatch_callback () >> #15 0x0135a1f1 in rl_callback_read_char () >> #16 0x0101f40e in gdb_rl_callback_read_char_wrapper_noexcept() () >> #17 0x0102020d in gdb_rl_callback_read_char_wrapper(void*) () >> #18 0x0101eeb1 in stdin_event_handler(int, void*) () >> #19 0x01300eba in gdb_wait_for_event(int) [clone .part.0] () >> #20 0x0130155a in gdb_do_one_event(int) () >> #21 0x00fa0576 in captured_command_loop() () >> #22 0x00fa2113 in gdb_main(captured_main_args*) () >> #23 0x013c66fb in main () > > > > -- > Justin Allen Parrott > The Renegade of Fairfax, Va. > The Sun of the Mourning >
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the first successful build: 2024.03.20.18.47.59 riastradh src/sys/dev/acpi/apei_hest.c 1.2 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2024.03.html#2024.03.20.18.47.59
gdb crashes on current
Hello! It seems that gdb from base NetBSD image doesn't work with netbsd's libcurses in tui mode: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 [Current thread is 1 (process 12621)] (gdb) bt #0 0x756547929fba in _lwp_kill () from /usr/lib/libc.so.12 #1 0x0101ef97 in handle_fatal_signal(int) () #2 0x0101f152 in handle_sigsegv(int) () #3 #4 0x756547e679e1 in prefresh () from /usr/lib/libcurses.so.9 #5 0x00eec1a0 in tui_source_window_base::refresh_window() () #6 0x00eedf18 in tui_unhighlight_win(tui_win_info*) () #7 0x00eec5f8 in tui_source_window_base::do_erase_source_content(char const*) () #8 0x00ef60e5 in tui_layout_split::apply(int, int, int, int, bool) () #9 0x00ef4aa8 in tui_apply_current_layout(bool) () #10 0x00ef4ddb in tui_set_layout(tui_layout_split*) () #11 0x00ee4f2f in tui_enable() () #12 0x00ee5487 in tui_rl_switch_mode(int, int) () #13 0x01379fa8 in _rl_dispatch_subseq () #14 0x0137aa27 in _rl_dispatch_callback () #15 0x0135a1f1 in rl_callback_read_char () #16 0x0101f40e in gdb_rl_callback_read_char_wrapper_noexcept() () #17 0x0102020d in gdb_rl_callback_read_char_wrapper(void*) () #18 0x0101eeb1 in stdin_event_handler(int, void*) () #19 0x01300eba in gdb_wait_for_event(int) [clone .part.0] () #20 0x0130155a in gdb_do_one_event(int) () #21 0x00fa0576 in captured_command_loop() () #22 0x00fa2113 in gdb_main(captured_main_args*) () #23 0x013c66fb in main ()
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon4.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2024.03.20.17.11.44.
An extract from the build.sh output follows:
# link fujhk/fujhk.kmod
/tmp/build/2024.03.20.17.11.44-i386/tools/bin/i486--netbsdelf-gcc
--sysroot=/tmp/build/2024.03.20.17.11.44-i386/destdir -Wl,--warn-shared-textrel
-Wl,-z,relro -nostdlib -r
-Wl,-T,/tmp/build/2024.03.20.17.11.44-i386/src/sys/../sys/modules/xldscripts/kmodule,-d
-Wl,-Map=fujhk.kmod.map -o fujhk.kmod fujhk_acpi.o
--- dependall-apei ---
In file included from
/tmp/build/2024.03.20.17.11.44-i386/src/sys/dev/acpi/apei_hest.c:48:
/tmp/build/2024.03.20.17.11.44-i386/src/sys/dev/acpi/apei_hest.c: In
function 'apei_hest_attach':
/tmp/build/2024.03.20.17.11.44-i386/src/sys/dev/acpi/apei_hest.c:920:53:
error: comparison of integer expressions of different signedness: 'int' and
'size_t' {aka 'unsigned int'} [-Werror=sign-compare]
920 | KASSERT((const char *)next - (const char *)header <= resid);
| ^~
--- dependall-fujhk ---
/tmp/build/2024.03.20.17.11.44-i386/tools/bin/nbctfmerge -t -L VERSION -o
fujhk.kmod fujhk_acpi.o
--- dependall-external ---
The following commits were made between the last successful build and
the first failed build:
2024.03.20.17.11.42 riastradh src/distrib/sets/lists/debug/module.md.amd64
1.15
2024.03.20.17.11.42 riastradh src/distrib/sets/lists/debug/module.md.i386
1.9
2024.03.20.17.11.42 riastradh src/distrib/sets/lists/modules/md.amd64 1.101
2024.03.20.17.11.42 riastradh src/distrib/sets/lists/modules/md.i386 1.98
2024.03.20.17.11.42 riastradh src/share/man/man4/apei.4 1.1
2024.03.20.17.11.42 riastradh src/sys/arch/amd64/conf/ALL 1.185
2024.03.20.17.11.42 riastradh src/sys/arch/i386/conf/ALL 1.516
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei.c 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_bert.c 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_bertvar.h 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_cper.h 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_einj.c 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_einjvar.h 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_erst.c 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_erstvar.h 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_hed.h 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_hest.c 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_hestvar.h 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_interp.c 1.1
2024.03.20.17.11.43 riastradh src/sys/dev/acpi/apei_interp.h 1.1
2024.03.20.17.11.44 riastradh src/sys/dev/acpi/apei_mapreg.c 1.1
2024.03.20.17.11.44 riastradh src/sys/dev/acpi/apei_mapreg.h 1.1
2024.03.20.17.11.44 riastradh src/sys/dev/acpi/apei_reg.c 1.1
2024.03.20.17.11.44 riastradh src/sys/dev/acpi/apei_reg.h 1.1
2024.03.20.17.11.44 riastradh src/sys/dev/acpi/apeivar.h 1.1
2024.03.20.17.11.44 riastradh src/sys/dev/acpi/files.acpi 1.131
2024.03.20.17.11.44 riastradh src/sys/modules/Makefile 1.283
2024.03.20.17.11.44 riastradh src/sys/modules/apei/Makefile 1.1
2024.03.20.17.11.44 riastradh src/sys/modules/apei/apei.ioconf 1.1
Logs can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2024.03.html#2024.03.20.17.11.44
live-USB on SanDisk Cruzer Glide (was: Re: USB hubs/controllers detached before umass devices)
On Sat, 16 Mar 2024, John D. Baker wrote: > On Sat, 16 Mar 2024, John D. Baker wrote: > > > The only difference is that the USB devices with netbsd-10 are > > branded SanDisk and the ones with -current are branded PNY. I've just completed a dump/restore to swap the i386 live images so that 10.0_RC6 is on the PNY flash drive and -current (10.99.10) is on the SanDisk flash drive. The problem follows the SanDisk drive. Anything that causes the filesystem to be altered provokes the "Generic HBA error" (and if the disk was actually mounted, further "error writing fsbn " messages). Hitting reset to skip the 40-minute wait for all the retries to time out, rebooting the live image single-user and running 'fsck' to repair the filesystem, then immediately issuing 'halt', the system again reports the "Generic HBA error" but continues with the remaining steps to halt the system. Has anyone else had issues using a SanDisk USB flash drive for a NetBSD live image for NetBSD 9.99.*, -10, -current? These exact same SanDisk USB flash drives (Cruzer Glide 16GB) have been used with netbsd-8 and netbsd-9 in the past and did not exhibit this problem. (By "used", I mean installed/updated/tested. They've never seen any active use beyond that.) When used as a non-boot disk, it doesn't seem to have any problem even if left mounted at system halt/reboot. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Strange sensor names for amdzentemp(4)
On Wed, 20 Mar 2024, J. Hannken-Illjes wrote: # envstat -d amdzentemp0 Current CritMax WarnMax WarnMin CritMin Unit cpu0 temperature:55.125 degC cpu0 ccd0 temperature:36.375 degC cpu0 ccd1 temperature:37.500 degc # The string originates from sys/arch/x86/pci/amdzentemp.c line 471. In this context CCD is a synonym for Core Complex Die. Ah! That makes more sense! Thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Strange sensor names for amdzentemp(4)
> On Mar 20, 2024, at 4:27 PM, Paul Goyette wrote: > > Oddly, I am seeing the following sensor info. Note that the config > doesn't even contain ``ccd''. (Previous incarnations of this config > _did_ have ccd, but it's been completely removed when I changed to > use raidframe...) > > # envstat -d amdzentemp0 > Current CritMax WarnMax WarnMin CritMin Unit > cpu0 temperature:55.125 degC > cpu0 ccd0 temperature:36.375 degC > cpu0 ccd1 temperature:37.500 degc > # The string originates from sys/arch/x86/pci/amdzentemp.c line 471. In this context CCD is a synonym for Core Complex Die. -- J. Hannken-Illjes - hann...@mailbox.org
Strange sensor names for amdzentemp(4)
Oddly, I am seeing the following sensor info. Note that the config doesn't even contain ``ccd''. (Previous incarnations of this config _did_ have ccd, but it's been completely removed when I changed to use raidframe...) # envstat -d amdzentemp0 Current CritMax WarnMax WarnMin CritMin Unit cpu0 temperature:55.125 degC cpu0 ccd0 temperature:36.375 degC cpu0 ccd1 temperature:37.500 degc # +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
