Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
> On Mar 29, 2017, at 01:26, Bruce Evans wrote: > > On Tue, 28 Mar 2017, Ngie Cooper wrote: > >>> On Mar 28, 2017, at 21:40, Bruce Evans wrote: >>> On Wed, 29 Mar 2017, Bruce Evans wrote: > On Wed, 29 Mar 2017, Andrey Chernov wrote: > ... > Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode > anymore - nothing happens. In the vt mode I can, but can't exit via "c" > properly, all chars typed after "c" produce beep unless I switch to > another screen and back. > All it means that syscons becomes very broken now by itself and even > damages the kernel operations. > > I found a bug in screen resizing (the console context doesn't get resized). > This doesn't cause any keyboard problems. > ... But I suspect it is a usb keyboard problem. Syscons now does almost correct locking for the screen, but not for the keyboard, and the usb keyboard is especially fragile, especially in ddb mode. Console input is not used in normal operation except for checking for characters on reboot. Try using vt with syscons unconfigured. Syscons shouldn't be used when vt is selected, but unconfigure it to be sure. vt has different bugs using the usb keyboard. I haven't tested usb keyboards recently. >>> >>> ... >>> I tested usb keyboards again. They sometimes work, much the same as >>> a few months ago after some fixes: >>> ... >>> >>> The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux. >>> Other combinations and dynamic switching move the bugs around, and a >>> serial console is needed to recover in cases where the bugs prevent any >>> keyboard input. >> >> I filed a bug a few years ago about USB keyboards and usability in ddb. If >> you increase the timeout so the USB hubs have enough time to probe/attach, >> they will work. > > Is that for user mode or earlier? ukb has some other fixes for ddb now, but > of course it can't work before it finds the device. > > I recently found that usb boot drives sometimes don't have enough time to > probe/attach before they are used in mountroot, and the mount -a prompt > does locking that doesn't allow them enough time if they are not ready > before it. The usb maintainers already know about this. Ah, I misremembered my filing the bug — someone else did it: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133989 (it happens at mountroot, for example, because of probing order being what it is). -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
On Wed, 29 Mar 2017, Andrey Chernov wrote: On 29.03.2017 0:46, Ngie Cooper (yaneurabeya) wrote: On Mar 28, 2017, at 14:27, Andrey Chernov wrote: ??? Using rc_debug=yes I see that it is the kernel problem, not rc problem. Sometimes rc backward sequence executed even fully, sometimes only partly, but in unpredictable moment inside rc sequence the kernel decide to reboot quickly (or even deadly hang in rare cases). Always without any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal UFS, no EFI, no GPT. I change GELI swap to normal one, but it does not help. The same untouched config works for years, I see this bug for the first time in FreeBSD. I forget to mention that typescript and dmesg does not survive after this reboot (or rare hang). Good to note. The simple explanation to the problem might be r307755, depending on when you last synced/built ^/head. I have a few more questions (if reverting that doesn't pan out): I just found the cause, it is new syscons bug (bde@ cc'ed). I never compile vt driver into kernel, i.e. I don't have this lines in the kernel config: device vt device vt_vga device vt_efifb When I add them, the bug described is gone. It seems syscons goes off to early, provoking reboot. Bah, I only have vt and vt_vga to check that I didn't break them. Unfortunately, syscons still works right when I remove these lines. I also find some lines of the kernel messages strange colored instead of white in the syscons only mode. Even in vt mode vidcontrol errors have invisible escapes prepended (although visible through /var/log/messages). Kernel messages in syscons are now supposed to be colorized by CPU. The boot messages should show all the colors. Shutdown and ddb are normally done by a single random CPU, so are shown in a single random color. The colors are bright (light) 8-15 foreground, except bright black (8) is not so bright. Configure with a non-default KERNEL_SC_CONS_ATTR (maybe yellow on black instead of lightwhite on black) to turn of the colorization. I haven't tested this recently. There is also a sysctl for setting all the colors. Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode anymore - nothing happens. In the vt mode I can, but can't exit via "c" properly, all chars typed after "c" produce beep unless I switch to another screen and back. All it means that syscons becomes very broken now by itself and even damages the kernel operations. Try backing out r315984 only. This is supposed to fix parsing of output. It switches to a state indexed by the CPU for every character, and switches back. Screen switching does a different switch and would fix any bug in switching back. But I suspect it is a usb keyboard problem. Syscons now does almost correct locking for the screen, but not for the keyboard, and the usb keyboard is especially fragile, especially in ddb mode. Console input is not used in normal operation except for checking for characters on reboot. Try using vt with syscons unconfigured. Syscons shouldn't be used when vt is selected, but unconfigure it to be sure. vt has different bugs using the usb keyboard. I haven't tested usb keyboards recently. Bruce___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
On Wed, 29 Mar 2017, Bruce Evans wrote: On Wed, 29 Mar 2017, Andrey Chernov wrote: ... Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode anymore - nothing happens. In the vt mode I can, but can't exit via "c" properly, all chars typed after "c" produce beep unless I switch to another screen and back. All it means that syscons becomes very broken now by itself and even damages the kernel operations. ... But I suspect it is a usb keyboard problem. Syscons now does almost correct locking for the screen, but not for the keyboard, and the usb keyboard is especially fragile, especially in ddb mode. Console input is not used in normal operation except for checking for characters on reboot. Try using vt with syscons unconfigured. Syscons shouldn't be used when vt is selected, but unconfigure it to be sure. vt has different bugs using the usb keyboard. I haven't tested usb keyboards recently. I tested usb keyboards again. They sometimes work, much the same as a few months ago after some fixes: - after booting with -d, they never work (give no input) at the ddb prompt with either sc or vt. usb is not initialized then, and no usb keyboard is attached to sc or vt - after booting without loader with -a, sc rarely or never works (gives no input) at the mountroot prompt - after booting with loader with -a, vt works at the mountroot prompt. I don't normally use loader but need to use it to change the configuration. This might be better than before. There used to be a screen refresh bug. - after booting with loader with -a, sc works at the mountroot prompt too. I previously debugged that vt worked better because it attaches the keyboard before this point, while sc attaches it after. Booting with loader apparently fixes the order. - after any booting, sc works for user input (except sometimes after a too-soft hard reset, the keyboard doesn't even work in the BIOS, and it takes unplugging the keyboard to fix this) - after almost any booting, vt doesn't work for user input (gives no input). However, if ddb is entered using a serial console, vt does work! A few months ago, normal input was fixed by configuring kbdmux (the default in GENERIC). It is not fixed by unplugging the keyboard. kbdmux has a known bug of not doing nested switching for the keyboard state. Perhaps this "fixes" ddb mode. But I would have expected it to break ddb mode. - I didn't test sc after entering ddb, except early when it doesn't work. The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux. Other combinations and dynamic switching move the bugs around, and a serial console is needed to recover in cases where the bugs prevent any keyboard input. Bruce ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
On Tue, 28 Mar 2017, Ngie Cooper wrote: On Mar 28, 2017, at 21:40, Bruce Evans wrote: On Wed, 29 Mar 2017, Bruce Evans wrote: On Wed, 29 Mar 2017, Andrey Chernov wrote: ... Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode anymore - nothing happens. In the vt mode I can, but can't exit via "c" properly, all chars typed after "c" produce beep unless I switch to another screen and back. All it means that syscons becomes very broken now by itself and even damages the kernel operations. I found a bug in screen resizing (the console context doesn't get resized). This doesn't cause any keyboard problems. ... But I suspect it is a usb keyboard problem. Syscons now does almost correct locking for the screen, but not for the keyboard, and the usb keyboard is especially fragile, especially in ddb mode. Console input is not used in normal operation except for checking for characters on reboot. Try using vt with syscons unconfigured. Syscons shouldn't be used when vt is selected, but unconfigure it to be sure. vt has different bugs using the usb keyboard. I haven't tested usb keyboards recently. ... I tested usb keyboards again. They sometimes work, much the same as a few months ago after some fixes: ... The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux. Other combinations and dynamic switching move the bugs around, and a serial console is needed to recover in cases where the bugs prevent any keyboard input. I filed a bug a few years ago about USB keyboards and usability in ddb. If you increase the timeout so the USB hubs have enough time to probe/attach, they will work. Is that for user mode or earlier? ukb has some other fixes for ddb now, but of course it can't work before it finds the device. I recently found that usb boot drives sometimes don't have enough time to probe/attach before they are used in mountroot, and the mount -a prompt does locking that doesn't allow them enough time if they are not ready before it. The usb maintainers already know about this. I haven't taken the time to follow up on that and fix the issue, or at least propose a bit more functional workaround. Bruce ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > > > On 26 Mar 2017, at 23:36, Mark Millard wrote: > >> > >> I upgraded from llvm40 r4 to final. An interesting result was > >> its creation of a backup package for llvm40-4.0.0.r4: > >> > >> about 13 cpu-core-hours running pkg create > >> > >> (Remember: I've been building with WITH_DEBUG= ) Its > >> single-threaded status stands out via elapsed time > >> approximately matching. > >> > >> I'll note that it was somewhat under 6 elapsed hours for > >> staging to have been populated (-j4 with 4 cores present > >> helps for this part). > >> > >> (Of course these elapsed-time figures are rather system > >> dependent, although the ratio might be more stable.) > >> > >> > >> > >> Also interesting was: > >> > >> Installed packages to be REMOVED: > >>llvm40-4.0.0.r4 > >> > >> Number of packages to be removed: 1 > >> > >> The operation will free 49 GiB. > > > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. And > > in that case, you are better served by a Subversion checkout or Git > > clone from upstream instead. > > > > -Dimitry > > FYI: > > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. > > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG= . > I'm more concerned with the time it takes than with > the file system space involved. In the case of LLVM, enabling debug builds does a LOT more than adding symbols. It's much more like enabling WITNESS and INVARIANTS in your kernel, except that the performance of the resulting binary is much worse than a WITNESS kernel (more like 10x slowdown). As Dimitry points out, these builds are of questionable value in ports so garbage collecting the knob might be the sensable thing to do. -- Brooks signature.asc Description: PGP signature
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 29 Mar 2017, at 17:53, Brooks Davis wrote: > > On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: ... >> This is extreme enough that next time I synchronize >> /usr/ports and it has a devel/llvm40 update I'll >> likely rebuild devel/llvm40 without using WITH_DEBUG= . >> I'm more concerned with the time it takes than with >> the file system space involved. > > In the case of LLVM, enabling debug builds does a LOT more than adding > symbols. It's much more like enabling WITNESS and INVARIANTS in your > kernel, except that the performance of the resulting binary is much > worse than a WITNESS kernel (more like 10x slowdown). > > As Dimitry points out, these builds are of questionable value in ports > so garbage collecting the knob might be the sensable thing to do. I suggest that for the LLVM ports, the DEBUG option should set the RelWithDebInfo build type for CMake. That will give you binaries which can produce good backtraces, and a fair chance at debugging, in a pinch. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
On 29.03.2017 6:29, Bruce Evans wrote: > Using rc_debug=yes I see that it is the kernel problem, not rc > problem. > Sometimes rc backward sequence executed even fully, sometimes only > partly, but in unpredictable moment inside rc sequence the kernel > decide > to reboot quickly (or even deadly hang in rare cases). Always without > any "Syncing buffers..." leaving FS dirty. No zfs etc. just normal > UFS, > no EFI, no GPT. > I change GELI swap to normal one, but it does not help. The same > untouched config works for years, I see this bug for the first time in > FreeBSD. I forget to mention that typescript and dmesg does not survive after this reboot (or rare hang). >>> >>> Good to note. >>> The simple explanation to the problem might be r307755, depending on >>> when you last synced/built ^/head. >>> >>> I have a few more questions (if reverting that doesn't pan out): >> >> I just found the cause, it is new syscons bug (bde@ cc'ed). I never >> compile vt driver into kernel, i.e. I don't have this lines in the >> kernel config: >> >> devicevt >> devicevt_vga >> devicevt_efifb >> >> When I add them, the bug described is gone. It seems syscons goes off to >> early, provoking reboot. > > Bah, I only have vt and vt_vga to check that I didn't break them. > > Unfortunately, syscons still works right when I remove these lines. Maybe two will be enough too, I don't check. I just don't need _any_ of vt lines. What is matter it is that syscons only mode (without any vt) was recently broken, causing shutdown problems and file system damage each time. Syscons only mode works for years until you break it recently. > Kernel messages in syscons are now supposed to be colorized by CPU. The It looks really crazy on 8-core CPU and should not be default. And I don't see colors in vt mode (which should be parallel at that point, at least), but what about invisible escapes on vidcontrol errors (f.e. invalid argument) in vt mode? >> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode >> anymore - nothing happens. In the vt mode I can, but can't exit via "c" >> properly, all chars typed after "c" produce beep unless I switch to >> another screen and back. > > Try backing out r315984 only. This is supposed to fix parsing of output. I'll try. thanx. But most dangerous new syscons bug is the first one, damaging file system on each reboot. I try to go to KDB to debug it, but seeing that I can't even enter KDB I understand that all that bugs, including nasty one, are introduced by your syscons changes, it was a hint to add completely unneeded and unused vt to my kernel config file. vt is real downgrade. Its default console font is plain ugly, it is impossible to work with it. I can't find proper TERM for it to make function keys and pseudographics works in ncurses apps (not with xterm, a little better with xterm-sco), lynx can't display all things properly, etc. All we need is KMS integration alone and not vt. > But I suspect it is a usb keyboard problem. No, I have PS/2 keyboard. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Was pf(4) removed from periodic daily?
I've depended upon pf for many years, but somewhere between updating my servers from 9 to 11, and 12. I seem to have lost getting the daily statistics from pf. Does anyone know what changed, and what I need to do to get those reports back? Thanks! --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Was pf(4) removed from periodic daily?
On Wed, Mar 29, 2017 at 4:40 PM, Chris H wrote: > I've depended upon pf for many years, but somewhere between > updating my servers from 9 to 11, and 12. I seem to have > lost getting the daily statistics from pf. > > Does anyone know what changed, and what I need to do to > get those reports back? > > Thanks! > > --Chris This change made the report less verbose. That's the only relevant change I can see. https://svnweb.freebsd.org/base?view=revision&revision=290405 As always, the way to enable the reports is to set security_status_pfdenied_enable=YES in periodic.conf (YES is the default) and set the daily_output variable to an email address you check. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Was pf(4) removed from periodic daily?
On Wed, 29 Mar 2017 16:50:41 -0600 Alan Somers wrote > On Wed, Mar 29, 2017 at 4:40 PM, Chris H wrote: > > I've depended upon pf for many years, but somewhere between > > updating my servers from 9 to 11, and 12. I seem to have > > lost getting the daily statistics from pf. > > > > Does anyone know what changed, and what I need to do to > > get those reports back? > > > > Thanks! > > > > --Chris > > This change made the report less verbose. That's the only relevant > change I can see. > https://svnweb.freebsd.org/base?view=revision&revision=290405 > > As always, the way to enable the reports is to set > security_status_pfdenied_enable=YES in periodic.conf (YES is the > default) and set the daily_output variable to an email address you > check. Thanks, Alan! I'll set it, and anxiously await my pf(4) report! :-) --Chris > > -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others
On 30.03.2017 8:53, Bruce Evans wrote: >> Maybe two will be enough too, I don't check. I just don't need _any_ of >> vt lines. What is matter it is that syscons only mode (without any vt) >> was recently broken, causing shutdown problems and file system damage >> each time. Syscons only mode works for years until you break it recently. > > Actually, I fixed it not so recently (over the last few months), partly > with much older local fixes. Please commit your fix as soon as possible. vt is broken as designed in many aspects (I even mention not all of them), but from other hand I can't allow dirty filesystem (or hang) on each reboot using sc only mode as always. It is dangerous, and fsck takes big time. Moreover, using sc while keeping vt bloat compiled in the kernel just as the bug workaround is the best demotivator for perfectionist. > The escape sequences in dmesg are very interesting. You should debug > those. I'll send you them a bit later. Since I don't want vt at all, I don't want to debug or fix it, let it die. >> I'll try. thanx. But most dangerous new syscons bug is the first one, >> damaging file system on each reboot. I try to go to KDB to debug it, but >> seeing that I can't even enter KDB I understand that all that bugs, >> including nasty one, are introduced by your syscons changes, it was a >> hint to add completely unneeded and unused vt to my kernel config file. > > It's normal to have a slightly damaged file system after a panic. In sc only mode I have no kernel panic, i.e panic with trace on console or entering KDB. I have silent reboot in the middle or end of shutdown sequence or rare dead hang on reboot (which absolutely not acceptable for remote machine). > You might have entered ddb in a context which used to race or deadlock. No. I try about 20 times on machine which does nothing and can't enter KDB in sc only mode, but got one dead hang instead, when start to repeat it too fast. In vt mode I can enter each time, but there are exit problems I already mention. I use text mode in sc. > Strings for function keys: > - these are just broken in both sc and vt I have all function keys working in sc only mode with TERM=cons25 and similar ones. > Pseudographics: > - I don't use it enough to see problems in it. Even finding the unicode > glyph for the block character took me some time. Even cp437 have it and dialog library use it for all windows frames, f.e. all ports config windows use pseudographics if it is available and working (replaced by +-| etc poor looking ASCII otherwise). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
