[ 2024 | 2023 | 2022 | 2021 | 2020 | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 ]
2021-12-30: どや https://marc.info/?l=openbsd-tech&m=164085298703800&w=2
2021-12-28: RFC 2409 あたりを原文で読むのって、昔から難易度高すぎたのだ けど、日本語版 https://www.ipa.go.jp/security/rfc/RFC2409JA.html なら、 だいぶわかりやすい。日本語にすると、漢字、ひらがな、カタカナ、アルファ ベットが使われて表現力が増して、意味をとりやすくなるような気がする。 逆にいうと、日本語に慣れてしまうと、原文苦手になっちゃうんだろうな。
2021-12-23: やはり mailest の update 激おそになってる
2021-12-23: カモーン https://marc.info/?t=163824796500003&r=1&w=2
2021-12-22: OpenBSD 7.0 の package から入れた mailest-0.9.24 で mailestctl update したら free() での abort
(gdb) bt
#0 thrkill () at /tmp/-:3
#1 0x000008e934a1ad6e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2 0x000008e934a30116 in wrterror (d=Variable "d" is not available.
)
at /usr/src/lib/libc/stdlib/malloc.c:307
#3 0x000008e934a30e9a in ofree (argpool=0x7f7ffffdb2c0, p=0x8e9559b0640,
clear=0, check=-424333232, argsz=9797703261496) at include/machine/tcb.h:43
#4 0x000008e934a3035b in free (ptr=0x8e9559b0640)
at /usr/src/lib/libc/stdlib/malloc.c:1470
#5 0x000008e86df6f79d in cbmimebreak () from /usr/local/lib/libqdbm.so.14.14
#6 0x000008e65f66aae9 in ?? () from /usr/local/bin/mailestctl
#7 0x000008e65f660ad7 in ?? () from /usr/local/bin/mailestctl
#8 0x000008e65f660233 in ?? () from /usr/local/bin/mailestctl
#9 0x000008e9178d089f in event_base_loop (base=0x8e93fb76c00, flags=0)
at /usr/src/lib/libevent/event.c:333
#10 0x000008e65f65e7d7 in ?? () from /usr/local/bin/mailestctl
#11 0x000008e65f65d758 in ?? () from /usr/local/bin/mailestctl
#12 0x0000000000000000 in ?? ()
(gdb)
これは、もう直したやつだ。0.9.25 リリースせねば
2021-12-21: ワクチン接種証明アプリが NFC 必須だったり、旧姓併記に未対 応だったりする件 これ や これ 。
制限事項ありでリリースするのはよいと思うけど、旧姓併記のほうは、オレが 政府なら政治的な配慮でリリース不可な気がする。岸田さんは知ってたのだ ろうか。
いっぽう NFC は制限事項じゃないので、マイナカード持ってないのと同じ扱い になるのだと思う。こちらのほうが、エンジニアリングな判断での切り捨てな ので、さらにもやもやする。NFC は現在 85% ぐらいの普及率らしい 。 PKI やスマートカードを基礎技術にするのは良いと思うけど、まだ 85% ではあ るので、普及まで、救済手段を用意できなかったのだろうか。85% の現時点で 無いってことは、これから用意するかは微妙だけど。つうか、この日を予想し てなかったのかな
2021-11-23: これ python - "Least Astonishment" and the Mutable Default Argument - Stack Overflow 、 Python 書くときに絶対知っとくべき。自分で書くときはたぶん避けてた けど、人のコードはスルーしてたわ。あぶねー。
関数はオブジェクトであると考えれば誤解しない、という説明があり、 関数型言語圏では誤解はないのかもしれない
2021-11-20: consider LibreSSL as default OpenSSL provider again (#28) · Issues · alpine / TSC · GitLab alpine のデフォルト ssl を libressl に戻そうと。 参考: LibreSSL languishes on Linux [LWN.net]
2021-11-20: 'Fix ipsp_spd_lookup() for transport mode (was Re: Fix IPsec NAT-T for L2TP/IPsec)' - MARC
2021-11-18: システムが認識しているバッテリの残量が変で:
Nov 18 10:40:01 yasuoka-ob1 apmd: battery status: low. external power status: not connected. estimated battery life 32% (31 minutes) Nov 18 10:40:03 yasuoka-ob1 apmd: battery status: CRITICAL. external power status: not connected. estimated battery life 0% Nov 18 10:40:32 yasuoka-ob1 apmd: system hibernating
このように 32% の後に突然 0% にジャンプする。本当にバッテリー切れなの か本当は切れていないか現時点では不明だけど、この状態になると upowered(8) が自動でシステムを hibernate してしまって、デバッグなど行 えず、困ってしまう。 upowerd(8) は /etc/UPower/UPower.conf で設定を行 うが、バッテリー枯渇時のアクションとして、なにもしない、という設定は行 えないようである。議論は、 こちら
どうして upower がインストールされているかといえば
evince => nautilus => tracker3-miners => upower
という依存関係で、それぞれで依存する理由はわからなくはないけど、PDF を読みたいという最初のモチベーションからは、だいぶ遠い話になってしまっ ている。しかたがないので:
doas mv /usr/local/share/dbus-1/system-services/org.freedesktop.UPower.service{,-disabled}
で無効化して様子見
2021-11-10: さらに buddyns の設定も間違っていて、更新ができなくなって いた...
2021-11-09: なんと yasuoka.net の spf の設定がミスっていた。2020-03 以 降..... みなさん、よく受信してくれてたな
2021-11-03: 某社のサービス仕様変更 を見落としていて、openbsd からのメールが全然届いてなく焦った
2021-10-14: chrome で caret browsing の on/off の切り替えは F7 だけど、 現在の状態が on なのか off なのかってどこかに表示しているのだろうか
2021-10-09: tpm の問題はきちんとした修正が別途議論中っぽい
2021-10-09: 生活環境は pkg_add も完了して、完全に OpenBSD 7.0 になった
2021-10-08: 使う前に初期化することが重要なのであって、割り当て時に初期 化するのは方法のひとつにすぎない
2021-10-08: OpenBSD 7.0 相当にする suspend できなくなる問題は、tpm(4) が初期化されずに attach されているのが原因だった
diff --git a/sys/dev/acpi/tpm.c b/sys/dev/acpi/tpm.c
index 6907c6a0d4e..85c5f604907 100644
--- a/sys/dev/acpi/tpm.c
+++ b/sys/dev/acpi/tpm.c
@@ -359,7 +359,7 @@ tpm_init(struct tpm_softc *sc)
if ((r & TPM_CAPSREQ) != TPM_CAPSREQ ||
!(r & (TPM_INTF_INT_EDGE_RISING | TPM_INTF_INT_LEVEL_LOW))) {
DPRINTF((": caps too low (caps=%b)\n", r, TPM_CAPBITS));
- return 0;
+ return 1;
}
/* ack and disable all interrupts, we'll be using polling only */
2021-10-08: 一方で、suspend / resume 後も標準のタッチパッドが使えるよ うになっている。これは便利。ちょっぴりリビングに行くにもマウス持参だっ たのが、マウスなしで大丈夫になる
2021-10-07: OpenBSD 7.0 相当にしたところ suspend できなくなっている。8/4 までは ok
2021-10-04: Remmina で Use client mapping を使うと、Windows で日本語入力ができなくなるのか。ということで暫定パッチとしては:
--- src/plugins/rdp/rdp_event.c.orig Tue Mar 30 18:04:57 2021
+++ src/plugins/rdp/rdp_event.c Sun Oct 3 15:33:19 2021
@@ -744,6 +744,12 @@ static gboolean remmina_rdp_event_on_key(GtkWidget *wi
default:
if (!rfi->use_client_keymap) {
hardware_keycode = event->hardware_keycode;
+ #define SCANCODE_Control_L 0x25
+ #define SCANCODE_Caps_Lock 0x42
+ if (hardware_keycode == SCANCODE_Control_L && event->keyval == GDK_KEY_Caps_Lock)
+ hardware_keycode = SCANCODE_Caps_Lock;
+ else if (hardware_keycode == SCANCODE_Caps_Lock && event->keyval == GDK_KEY_Control_L)
+ hardware_keycode = SCANCODE_Control_L;
if (rfi->keymap) {
for (ik = 0; ik < rfi->keymap->len; ik++) {
kep = &g_array_index(rfi->keymap, RemminaPluginRdpKeymapEntry, ik);
を使うことにした。
2021-10-02: Remmina の RDP で ctrl と caps が入れ替わらない問題、OpenBSD 固有ではなく、ubuntu でも同じ動作
Linux で setxkbdmap -option ctrl:swapcaps した場合に GDK の event の hardware_keycode で渡ってくるのは、 オリジナルのキーコードなので、Linux の動作は OpenBSD の wskbd と同じ
remmina は "use client keymap" をしても、制御キーはそのままなので、OS での ctrl caps の入れ替えは、RDP に反映されない
なので、結局 remmina を直すか、諦めるか、ということになる
--- src/plugins/rdp/rdp_event.c.orig Tue Mar 30 18:04:57 2021
+++ src/plugins/rdp/rdp_event.c Sat Oct 2 11:52:21 2021
@@ -742,8 +742,8 @@ static gboolean remmina_rdp_event_on_key(GtkWidget *wi
break;
default:
+ hardware_keycode = event->hardware_keycode;
if (!rfi->use_client_keymap) {
- hardware_keycode = event->hardware_keycode;
if (rfi->keymap) {
for (ik = 0; ik < rfi->keymap->len; ik++) {
kep = &g_array_index(rfi->keymap, RemminaPluginRdpKeymapEntry, ik);
@@ -773,9 +773,16 @@ static gboolean remmina_rdp_event_on_key(GtkWidget *wi
if (event->keyval >= 0xfe00 || // Arrows, Shift, Alt, Fn, num keypad…
event->hardware_keycode == 0x41 || // Spacebar
unicode_keyval == 0 || // Impossible to translate
- (event->state & (GDK_MOD1_MASK | GDK_CONTROL_MASK | GDK_SUPER_MASK)) != 0 // A modifier not recognized by gdk_keyval_to_unicode()
+ (event->state & (GDK_LOCK_MASK | GDK_MOD1_MASK | GDK_CONTROL_MASK | GDK_SUPER_MASK)) != 0 // A modifier not recognized by gdk_keyval_to_unicode()
) {
- scancode = freerdp_keyboard_get_rdp_scancode_from_x11_keycode(event->hardware_keycode);
+ #define SCANCODE_Control_L 0x25
+ #define SCANCODE_Caps_Lock 0x42
+ if (hardware_keycode == SCANCODE_Control_L && event->keyval == GDK_KEY_Caps_Lock)
+ hardware_keycode = SCANCODE_Caps_Lock;
+ else if (hardware_keycode == SCANCODE_Caps_Lock && event->keyval == GDK_KEY_Control_L)
+ hardware_keycode = SCANCODE_Control_L;
+
+ scancode = freerdp_keyboard_get_rdp_scancode_from_x11_keycode(hardware_keycode);
rdp_event.key_event.key_code = scancode & 0xFF;
rdp_event.key_event.extended = scancode & 0x100;
if (rdp_event.key_event.key_code) {
2021-10-02: Remmina に pull request する準備をしていたら 、 https://gitlab.com/Remmina/Remmina/-/merge_requests/2304 という別の pull request を発見。次のバージョンでは設定で mapping できるようになりそう
2021-09-28: Google Keep、そもそもオフラインで編集できないのかよ！と思っ たら、アプリ版があってそっちはもろもろちゃんとしてた... ごめんなさい
2021-09-28: スマホ (ZenFone 4 Max) の android バージョンが古すぎて Slack が使えなくなってしまった。 https://www.asus.com/jp/supportonly/ZenFone4%20Max%20(ZC520KL)/HelpDesk_BIOS/ から 8.1.0 Oreo に upgrade 中
2021-09-23: vaio-z で
Asynchronous wait on fence :Xorg[75929]:3542 timed out (hint:0xffffffff817dffb0s)
Asynchronous wait on fence :Xorg[75929]:356e timed out (hint:0xffffffff817dffb0s)
Asynchronous wait on fence :Xorg[75929]:35ca timed out (hint:0xffffffff817dffb0s)
Asynchronous wait on fence :Xorg[75929]:35f2 timed out (hint:0xffffffff817dffb0s)
Asynchronous wait on fence :Xorg[75929]:36b4 timed out (hint:0xffffffff817dffb0s)
Asynchronous wait on fence :Xorg[75929]:36ec timed out (hint:0xffffffff817dffb0s)
drm:pid93535:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A
__mp_lock_spin: 0xffffffff82304b38 lock spun out
panic: kernel diagnostic assertion "_kernel_lock_held()" failed: file "/source/yasuoka/openbsd/head/git/src/sys/dev/pci/drm/drm_linux.c", line 736
Stopped at db_enter+0x10: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
*283580 87088 5063 0x300003 0x4000000 2 chrome
123311 68852 0 0x14000 0x200 0K pagedaemon
db_enter() at db_enter+0x10
panic(ffffffff81e5fb7c) at panic+0x13a
__assert(ffffffff81ed1f62,ffffffff81ee06cf,2e0,ffffffff81ee0710) at __assert+0x2b
idr_alloc(ffff800000191478,ffff8000035a5300,1,0,5) at idr_alloc+0x196
__drm_mode_object_add(ffff800000191078,ffff8000035a5300,bbbbbbbb,1,ffffffff812740d0) at __drm_mode_object_add+0xac
drm_property_create_blob(ffff800000191078,44,ffff800036648db0) at drm_property_create_blob+0xa7
drm_atomic_set_mode_for_crtc(ffff8000029df000,ffff800001dc3680) at drm_atomic_set_mode_for_crtc+0x87
__drm_atomic_helper_set_config(ffff800001d46800,ffff800002ac3800) at __drm_atomic_helper_set_config+0xda
drm_client_modeset_commit_atomic(ffff800001d2dc00,1,0) at drm_client_modeset_commit_atomic+0x128
drm_client_modeset_commit_locked(ffff800001d2dc00) at drm_client_modeset_commit_locked+0x55
drm_fb_helper_restore_fbdev_mode_unlocked(ffff800001d2dc00) at drm_fb_helper_restore_fbdev_mode_unlocked+0x44
intel_fbdev_restore_mode(ffff800000191078) at intel_fbdev_restore_mode+0x33
db_ktrap(1,0,ffff8000366490c0) at db_ktrap+0x2c
kerntrap(ffff8000366490c0) at kerntrap+0xa2
end trace frame: 0xffff800036649140, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
2021-09-22: luacstruct なんで ffi じゃないのか、ということを作文し ておく必要がありそう
2021-09-22: Google Keep でデータを失うこと２回.. 1. 削除ボタンに勝手に 指が触れてしまう 2. 編集中の自動保存無く、OS ハング (onenote はそういう のゼロだった。さすが MS)
2021-09-21: vaio pro pk は、液晶破損につき 9/17 より入院中。 で、代わりの vaio z を使っているが、pro pk と異なりキーボードとして ctrl caps の入れ替えができないので、wscons の encoding を使って入れ替 えるが、この方法だと remmina 経由で ctrl が caps になってしまう問題 が発生する。当時何も書いてないようだが、 OpenBSD の wscons での mapping との相性だった記憶がある。であれば直し ても良いのかも
2021-09-16: Microsoft is discontinuing its Office apps for Chromebook users in favor of web versions これ気づいてなくて、Chromebook で OneNote が実質使えなくなった... Google Keep に移行中
2021-09-16: PDF の画像化
convert -density 150 -background white -alpha remove -alpha off calendar2022.pdf calendar2022/calendar2022.png
2021-09-15: Lonovo の USI Pen の問題 だが、サポー トから連絡あり、chromebook dual との相性の問題らしく、返品となった。 問題がある P/N は 4X80Z49962。
2021-09-14: ここ１年ぐらい、夜になると、Youtube の調子が悪いと家族か ら苦情。tcpdump で眺めると、TCP 成立後の HTTP Request のメッセージが 載ったパケットが再送している。パケットサイズは MTU でちぎれているので、 Path MTU Blackhole の問題が発生しているかのような状態で、最初は、 Path MTU 関連の問題かと思われた。しかし、MSS でメッセージサイズを削っ ても、現象は直らない。ググってみると、 せっかくのIPoE化もDS-liteの 制限で台無しだったので、代替策を考えた｜しょっさん｜note という記事にあたった、 たしかに無線 LAN セグメントは IPv4 Only なので、1024 ポートの制限に あたる可能性がある
2021-09-14: 細かいデバッグは後日にするとして、とりあえず一旦 PPPoE に route-to することにしたが、それ以降 LINE の通知がこないと苦情。 これは、outgoing の DF で大きなパケットは PPPoE にカプセル化する時に ICMP unreach need fragment となるが、その時に誤って IPoE (gif) の トンネルの MTU (=1500) を通知している模様。コード的には、
sys/netinet/ip_input:
1552 case EMSGSIZE:
1553 type = ICMP_UNREACH;
1554 code = ICMP_UNREACH_NEEDFRAG;
1555
1556 #ifdef IPSEC
1557 if (rt != NULL) {
1558 if (rt->rt_mtu)
1559 destmtu = rt->rt_mtu;
1560 else {
1561 struct ifnet *destifp;
1562
1563 destifp = if_get(rt->rt_ifidx);
1564 if (destifp != NULL)
1565 destmtu = destifp->if_mtu;
この if が、オリジナル の経路になっているが、route-to した場合には route-to した if の if_mtu を使う必要がありそうだ。
経路 MTU を設定して、この問題を回避してみたが、現象は継続したので、 引き続きの問題はあるかもしれない (つづく)
2021-08-31: docker をいろいろと触っているが、alpine linux が人気らしい。 https://github.com/alpinelinux/docker-alpine "Win at minimalism!" glibc じゃなく musl libc、busybox、そして openssl じゃなく libressl。 package システムは OpenBSD よりもシンプルかも。このへんの議論 https://news.ycombinator.com/item?id=10782897
今後コンテナで動かすような仕事をする場合、 Python じゃなく、C + lua ですむようにすれば 5.1MB とかの極小になって、 かっこいいかも
2021-08-25: pylint でいろいろ white space を指摘されていたのに、新しい pylint では出ないなーと思ったら、出なくなったのか...
http://pylint.pycqa.org/en/latest/whatsnew/2.6.html
black or another formatter can help you with this better than Pylint ということだから、black を使えばよいのね。
https://blog.hirokiky.org/entry/2019/06/03/202745 を見ると、わ りと古い議論なのか
2021-08-19: rsync でバックアップをとったら、source の容量よりもはるかに 大きなスペースを用意しても 容量が足りない現象にあたった。source の 中には巨大な qcow がいくつか含まれていて、それを ls -ls などで見ると、 実際にはディスクは割当たっていない。これは https://en.wikipedia.org/wiki/Sparse_file だとわかった。rsync の場合 -S で destination のファイルを sparse 状態 にする
2021-08-17: 画像が張り付いた pdf から画像を取り出すのは pdfimages
2021-08-13: dhcp で割り当てのレンジを変更したのちに Windows が ipconfig /release するまで追従できない。これはバグ?
2021-07-29:
Asynchronous wait on fence :Xorg[15024]:2c10 timed out (hint:0xffffffff819790f0s)
Asynchronous wait on fence :Xorg[15024]:2c16 timed out (hint:0xffffffff819790f0s)
Asynchronous wait on fence :Xorg[15024]:2c1c timed out (hint:0xffffffff819790f0s)
Asynchronous wait on fence :Xorg[15024]:2c2a timed out (hint:0xffffffff819790f0s)
Asynchronous wait on fence :Xorg[15024]:2c32 timed out (hint:0xffffffff819790f0s)
uvm_fault(0xffffffff821c9c60, 0xd, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at drm_mode_rmfb_work_fn+0x30: movq 0(%rax),%rcx
TID PID UID PRFLAGS PFLAGS CPU COMMAND
516815 97112 5063 0x2 0 2 xfwm4
19525 48363 99 0x100010 0 1 sndiod
*191551 19159 0 0x14000 0x200 0K drmwq
96240 11570 0 0x14000 0x200 3 drmwq
drm_mode_rmfb_work_fn(ffff800035b2b910) at drm_mode_rmfb_work_fn+0x30
taskq_thread(ffff8000002a2400) at taskq_thread+0x9f
end trace frame: 0x0, count: 13
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}> drm_mode_rmfb_work_fn(ffff800035b2b910) at drm_mode_rmfb_work_fn+0x30
taskq_thread(ffff8000002a2400) at taskq_thread+0x9f
end trace frame: 0x0, count: -2
ddb{0}>
(gdb) bt
#0 0xffffffff8170f060 in dumpsys () at /source/yasuoka/openbsd/head/git/src/sys/arch/amd64/amd64/machdep.c:1049
#1 0xffffffff812668f3 in db_fncall () at /source/yasuoka/openbsd/head/git/src/sys/ddb/db_command.c:755
#2 0xffffffff8126672e in db_command (last_cmdp=0x0, cmd_table=Variable "cmd_table" is not available.
) at /source/yasuoka/openbsd/head/git/src/sys/ddb/db_command.c:285
#3 0xffffffff81267438 in db_command_loop () at /source/yasuoka/openbsd/head/git/src/sys/ddb/db_command.c:684
#4 0xffffffff8147da5e in db_trap (type=Variable "type" is not available.
) at /source/yasuoka/openbsd/head/git/src/sys/ddb/db_trap.c:102
#5 0xffffffff81531f42 in db_ktrap (type=0, code=-2112306528, regs=0x0) at /source/yasuoka/openbsd/head/git/src/sys/arch/amd64/amd64/db_interface.c:149
#6 0xffffffff81adeb12 in kerntrap (frame=0x0) at /source/yasuoka/openbsd/head/git/src/sys/arch/amd64/amd64/trap.c:309
#7 0xffffffff81e2b1ce in alltraps_kern_meltdown ()
#8 0xffffffff81600e90 in drm_mode_rmfb_work_fn (w=Variable "w" is not available.
) at /source/yasuoka/openbsd/head/git/src/sys/dev/pci/drm/drm_framebuffer.c:406
#9 0xffffffff81c3219f in taskq_thread (xtq=0xffff800035b2b910) at /source/yasuoka/openbsd/head/git/src/sys/kern/kern_task.c:447
#10 0xffffffff8118144c in proc_trampoline ()
#11 0x0000000000000000 in ?? ()
(gdb) frame 8
#8 0xffffffff81600e90 in drm_mode_rmfb_work_fn (w=Variable "w" is not available.
) at /source/yasuoka/openbsd/head/git/src/sys/dev/pci/drm/drm_framebuffer.c:406
406 while (!list_empty(&arg->fbs)) {
(gdb) l
401
402 static void drm_mode_rmfb_work_fn(struct work_struct *w)
403 {
404 struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
405
406 while (!list_empty(&arg->fbs)) {
407 struct drm_framebuffer *fb =
408 list_first_entry(&arg->fbs, typeof(*fb), filp_head);
409
410 list_del_init(&fb->filp_head);
(gdb)
411 drm_framebuffer_remove(fb);
412 }
413 }
414
415 /**
416 * drm_mode_rmfb - remove an FB from the configuration
417 * @dev: drm device
418 * @fb_id: id of framebuffer to remove
419 * @file_priv: drm file
420 *
#406 で 0xd をさわり uvm_fault。
(gdb) frame 9
#9 0xffffffff81c3219f in taskq_thread (xtq=0xffff800035b2b910) at /source/yasuoka/openbsd/head/git/src/sys/kern/kern_task.c:447
447 (*work.t_func)(work.t_arg);
(gdb) p *((struct drm_mode_rmfb_work *)work.t_arg)
$30 = {work = {task = {t_entry = {tqe_next = 0xffffffffffffffff, tqe_prev = 0xffffffffffffffff}, t_func = 0xffffffff81600e60 <drm_mode_rmfb_work_fn>,
t_arg = 0xffff800035b2b910, t_flags = 192, t_process = 0x5ccda1682e4a4ab}, tq = 0xd}, fbs = {next = 0xd, prev = 0xffff800035b2b9b0}}
(gdb)
arg->fbs は、上記のとおり next = 0xd とゴミ状態となっている。 drmwq が並列で実行されている点が 前回 と共通している
intel_atomic_commit_ready 「Asynchronous wait on fence :Xorg[15024]:2c32 timed out (hint:0xffffffff819790f0s)」の "hint:0xffffffff819790f0s" は
(gdb) info symbol 0xffffffff819790f0 intel_atomic_commit_ready in section .text (gdb)
intel_atomic_commit_ready は、前回 lock spun out したところ。
2021-07-29:
> X 使用中にこのように落ちると、X がハングしているように見える。 > ddb に入る前に console に切り替える必要があるが、たしか CPU #0 だったか > kernel lock を持っているなどの条件が整わないと動かない実装になっていた。 > また、この状態で dumpsys を call しても、ddb は cpu #2 で実行されているので、 > cpu #2 は kernel lock 持っていないから失敗する
kernel lock をささってる CPU があったから spun out して panic している ような場合に、同じく「kernel lock をささってる CPU」のせいで display が console に切り替わらないのだと思われる。その CPU が ddb に入ったところ で、console を切り替えてみる。
2021-07-29: git log の committer を author に reset する方法
git filter-branch -f --env-filter 'GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME \ GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL' HEAD~10..HEAD
2021-07-22:
drm:pid88509:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic update failure on pipe A
drm:pid87651:intel_dp_aux_wait_done *ERROR* [drm] *ERROR* AUX A/port A: did not complete or timeout within 10ms (status 0xac1003ff)
uvm_fault(0xffffffff821c9c60, 0xd, 0, 1) -> e
__mp_lock_spin: 0xffffffff82267728 lock spun out
Stopped at db_enter+0x10: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
48242 87651 35 0x12 0x40 0K Xorg
138548 32280 0 0x14000 0x200 1 i915
*246940 62473 0 0x14000 0x200 2 drmwq
445780 97235 0 0x14000 0x200 3 drmwq
db_enter() at db_enter+0x10
__mp_lock(ffffffff82267728) at __mp_lock+0xe2
__mp_acquire_count(ffffffff82267728,2) at __mp_acquire_count+0x38
msleep(ffff800000c45168,ffff800000c45118,20,ffffffff81e363e0,0) at msleep+0x124
taskq_do_barrier(ffff800000c45100) at taskq_do_barrier+0x108
intel_atomic_commit(ffff8000002b5078,ffff8000014dc800,0) at intel_atomic_commit+0x341
drm_client_modeset_commit_atomic(ffff800000c56000,1,0) at drm_client_modeset_commit_atomic+0x178
drm_client_modeset_commit_locked(ffff800000c56000) at drm_client_modeset_commit_locked+0x55
drm_fb_helper_restore_fbdev_mode_unlocked(ffff800000c56000) at drm_fb_helper_restore_fbdev_mode_unlocked+0x44
intel_fbdev_restore_mode(ffff8000002b5078) at intel_fbdev_restore_mode+0x33
db_ktrap(6,0,ffff8000246b5290) at db_ktrap+0x2c
kerntrap(ffff8000246b5290) at kerntrap+0xa2
alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b
drm_mode_rmfb_work_fn(ffff800035ad7630) at drm_mode_rmfb_work_fn+0x30
end trace frame: 0xffff8000246b53f0, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
問題の核心の前に...
X 使用中にこのように落ちると、X がハングしているように見える。 ddb に入る前に console に切り替える必要があるが、たしか CPU #0 だったか kernel lock を持っているなどの条件が整わないと動かない実装になっていた。 また、この状態で dumpsys を call しても、ddb は cpu #2 で実行されているので、 cpu #2 は kernel lock 持っていないから失敗する
で、核心だが...
taskq_barrier(9) からの lock 取得が spun out ということは、待っている タスクが終了しないってことかな。cpu #0 の Xorg が kernel lock を持っている ので、待っているタスクも待っているのかもしれない。いずれにしても、 再現性はあるので、ddb に落とすが良いと思われる。
2021-07-22: このサーバの証明書が期限切れになっていた。"ACMEv1 is deprecated" で、証明書の更新が止まっていたらしい。OpenBSD の upgrade をサボっていたの が敗因...
acme-client: acme-client: /etc/ssl/private/yasuoka.net.key: loaded RSA domain key/etc/ssl/yasuoka.net.crt: certificate renewable: -2 days left
acme-client: /etc/acme/letsencrypt-privkey.pem: loaded RSA account key
acme-client: https://acme-v01.api.letsencrypt.org/directory: directories
acme-client: acme-v01.api.letsencrypt.org: DNS: 172.65.32.248
acme-client: https://acme-v01.api.letsencrypt.org/directory: bad HTTP: 403
acme-client: transfer buffer: [{ "type": "urn:acme:error:serverInternal", "detail": "ACMEv1 is deprecated and you can no longer get certificates from this endpoint. Please use the ACMEv2 endpoint, you may need to update your ACME client software to do so. Visit https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/27 for more information." } ] (333 bytes)
acme-client: bad exit: netproc(21495): 1
2021-07-22: https://github.com/yasuoka/comment.cgi 更新した
2021-07-19: カーネルを -current にしたが、kmem 領域で壊す系の不具合 が入ったっぽくいろいろな場所で panic や uvm_fault する
2021-07-03: lenovo chromebook dual の USI Pen だが、予備の２本めに不具 合があることは ここ に書いた。当初は２本めだけの問 題で回避方法もあったが、数日前から１本目でも発症して、何をやっても改善 しなくなってしまった。問題は下のリンクと同じものだが...
エレコムの USI ペン を取り寄せたが、大変快適。今回 Lenovo の印象は大変悪いけど、USI という 標準規格だからこそ、このようにサードパーティの製品で回避できたわけで、 それは良かった。
2021-06-29: japanese-holidays-calendar 特措法の改正の patch の件 取り込まれた
2021-06-16: "divert-reply"
どうして "This is especially necessary for DGRAM or RAW sockets" かと言えば、 dgram の場合、終了の仕方が明示的ではなく、idle timer に頼らざるをえないので、 PCB を close したと判断した瞬間に消したほうがよいのである。なぜなら、 後続のパケットの処理はステート抜きで考えるべきである。 待受け用のソケットなどに吸い込みたいのかもしれないが、 ステートが残っているとそれを阻害する
relayd の diff に ok がないのは謎。シビアな状況で、transparent に relayd 使っている人っていないのかな?
2021-05-27: mailest on OpenBSD 6.9、劇遅になってる... DB への flush が 時間かかってるっぽいけど、なんだこれ...
2021-05-21: usi pen の問題は、同じ症状が多発してて、lenovo 側で調査を行っ ているみたい。折り返し連絡となった。youtube にも同じ症状の方が苦情を言っ てる動画を見たし。usi pen は２本体制だし、chromebook 側を再起動すると 現象が収まったりするので、しばらくはあきらめ
2021-05-20: chromebook 用の pen、lenovo usi pen をふたつ持っているのだ けど、片方が画面に接地していないのに描画されてしまう、という不具を発症。 修理すべくサポート問い合わせ中
2021-05-12: IPsec NAT-T 動いてない問題、直した https://marc.info/?l=openbsd-tech&m=162081435817072&w=2
2021-05-11: mailest って結局 dbwork スレッドで性能飽和するんだよなー、 HyperEstraier 使う限りは、もう打つ手なしだよなーと持っていたけど、 HyperEstraier は Read ロックと Write ロックがわかれている ので、DB への write access 以外を dbwork thread 以外で行うことができることに気づ いた。なんで、今まで気づかなかったのか、自分でもびっくり...
2021-05-07: vaio pro pk を 6.9 に upgrade
2021-05-07: FreeRDP が 2.3.2 になり、sndio 対応パッチを取り込まれていた sys:sndio を指定すれば、RDP でリモートオーディオが使える。旧バージョン では、遅延が蓄積していくような問題があったが、このバージョンでなおって いたらうれしい
2021-05-02: C の構造体を Lua で操作するための枠組み、luacstruct を作成 してみた。https://github.com/yasuoka/luacstruct
2021-05-06: mailest が異常終了 する問題は 修正した 。 OpenBSD 6.9 で、小さなメモリチャンクについての write after free も検出 するようになったっぽい
2021-04-30: https://github.com/yasuoka/luacstruct 書き始めた
2021-04-23: emacs 27.2 にしたら、mew で、スキャンが、Symbol’s function definition is void: timezone-make-date-arpa-standard とエラー となる。サマリの時刻をローカル時間で表示するようにしている が、その関数でエラーになっていた。これは timezone.el が require されて いないからで、(require 'timezone) で直る。元ページの gist にもコメ ントしておいた
2021-04-22: mailest が異常終了
(gdb) bt #0 thrkill () at /tmp/-:3 #1 0x000002268de1974e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x000002268ddc6926 in wrterror (d=Variable "d" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:307 #3 0x000002268ddc7686 in ofree (argpool=0x22648141b58, p=0x226a51b2001, clear=0, check=-1036203136, argsz=2364612155656) at include/machine/tcb.h:43 #4 0x000002268ddc7c2e in realloc (ptr=Variable "ptr" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:1669 #5 0x00000226b288c9d0 in vlnodeload () from /usr/local/lib/libqdbm.so.14.14 #6 0x00000226b288b448 in vlsearchleaf () from /usr/local/lib/libqdbm.so.14.14 #7 0x00000226b288e4f7 in vlcurjump () from /usr/local/lib/libqdbm.so.14.14 #8 0x000002268ea22184 in est_db_iter_init () from /usr/local/lib/libestraier.so.8.38 #9 0x00000223e3ce4658 in ?? () from /usr/local/bin/mailestctl #10 0x00000223e3ce42f3 in ?? () from /usr/local/bin/mailestctl #11 0x000002264a78e68f in event_base_loop (base=0x226a51c0000, flags=Variable "flags" is not available. ) at /usr/src/lib/libevent/event.c:333 #12 0x00000223e3ce382d in ?? () from /usr/local/bin/mailestctl #13 0x000002269b55e661 in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:96 #14 0x000002268dde00ca in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 #15 0x000002268dde00ca in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 Previous frame identical to this frame (corrupt stack?)
write after free。est_db_iter_init を呼び出しているのは、たぶん mailestd_db_sync() の冒頭。メモリ破壊系のバグ?
2021-04-16: git でこのファイルはどのリビジョンなのかを調べる方法
git hash-object <FILE>
作業ディレクトリで
git rev-list HEAD <FILE> | xargs -I % sh -c "(echo -n % ; git ls-tree % <FILE>)" | grep <HASH>
これを一発で行う方法はなぜないんだろ。
2021-04-13: OpenBSD 6.9 で gnupg 1.x が削除された。このため、Mew からは gnupg 2 を使うことになり、古い暗号化メールが読めなくなり、また、パスフ レーズがうまく入力できない。時間を見つけて対処しなければ...
2021-04-09: 祝退院 (1週間ほど入院していた)
2021-04-09: Intel NUC DN2820FYKH の BIOS のバッテリ交換の件 、バッテリが到着していたので、交換。レビューどおり、 + - が逆だったので、針で爪を持ち上げて線を入れ替える必要があった。交換 直後のブート時には、Battery Failure 的なメッセージが表示された。２回目 は問題なし
2021-04-02: 先日 vaio z が、バッテリ残量を誤認識している問題が、背面の リセットボタンで直ったが、vaio pro-pk でも、バッテリ残量が異様に早く減っ ていく現象があり、これも、なにかのバグを踏んでいるのかもしれない
2021-04-02: 人事が GitHub を参照する時代だけど、自分は過少評価される感 じがする。https://yasuoka.net/~yasuoka/calendar.html (ソースコードじゃ ないけど) は、広く誰でも使えるものは評価されやすいけど、それを生成する プログラム https://github.com/yasuoka/simple-calendar は、評価されづら い。後者のほうが価値はあるのに。直接利用する人が少ない実装が多い人は過 少評価されるのではないか
2021-03-31: Intel NUC DN2820FYKH の BIOS のバッテリが切れたので交換しようと思ったら、 molex コネクタ付きの CR2032 というもの で、amazon.co.jp でも購入できるらしいのだが、 NUC は + - が逆さまらしい 。 そんなことってあるんだ。
2021-03-31: 時刻戻る問題
2021-03-26: chromebook duet の chromeos は OpenBSD on vaio より頻繁に reboot する。意外と完成度低いな
2021-03-26: /dev/null の実装が sys/arch/amd64/amd64/mem.c とかにあるっ ってことを今日知った
2021-03-25: 一つ前の vaio z、teams 用マシンとして活躍しているのだが、バッ テリが常に 2% になってしまう現象に悩まされていた。試しに、背面のリセッ トボタンを長押ししてみたら、なんと治った... どういうこと?
2021-03-22: openssl cms 自分は gpg -c で、記憶できる安全なパスワードで暗号化している。 公開鍵を使う理由ってなんだろうか。公開鍵暗号の秘密鍵はファイルで保管す る必要があって面倒くさくないのかな
2021-03-17: OpenBSD 6.8 amd64 用の chromium-88.0.4324.190 (野良ビルド) 置いた
2021-03-10: ときどき ttypb などの tty 名から、tmux の pane を探したくな る。list-pane (lsp) では tty が表示されないようなので、
set -s command-alias[100] lsp2="list-pane -aF '#{pane_tty} #D (#{session_name}:#{window_index}.#{pane_index})'"
を tmux.conf に設定して、lsp2 でリスト表示できるようにした。pane id に移 動するには switchc。
2021-03-10: chromeos で USB-C 接続の DAC 経由のマイクが認識しない。回 避方法としては、マイクが有効になるアプリを起動させたまま DAC を接続し、 オーディオの設定として、一旦内臓マイクと内臓スピーカーを使う設定に切り 替えた後に、マイク、スピーカーの順に DAC に切り替えると回避することがで きる
2021-03-08: acpi の件 ついに commit。 https://marc.info/?l=openbsd-cvs&m=161515763310196&w=2
2021-03-05: chromium で Teams のビデオが使えるようになっていた。
2021-03-05: FreeRDP での USB 飛ばしは、FreeRDP の port で頑張れば、なん とかなりそうな感じがする
2021-03-05: rcsparse の python 3 対応、pull request した https://github.com/corecode/rcsparse/pull/6
2021-03-05: Mew の転送メールが Gmail で化ける問題 を踏んだ
(setq mew-field-comment "")
を .mew.el に追加すると回避できる。
2021-03-03: cvs2gitdump が使う https://github.com/corecode/rcsparse だが、メンテ状態もよくなさげなので、python にして cvs2gitdump に含められないか rcsparse.c を眺めて妄想。 大変出来がよく、これを Python で再実装しても、同じ速度で動くとは思えない
2021-03-03: 英文法の誤り多すぎて自己嫌悪... 自分以外の言い回しを確認すると、自分のような誤りをしている人がいなかっ たりして、自分の英語は相当頓珍漢なのでは...
2021-03-02: このサーバのファンが死んで、ダイニングに騒音を垂れ流し始め たため、急遽 Owltech OWL-FE1225LS-BK に交換したが、これは最初から微妙にうるさい。 1,400rpm、2ボールベアリン グ、28.1dbA、静音と書いてあるのだけど。交換前は KEEP A12025M12S という ものだったがスペックが不明で比較できない。マザボ (ASRock H410M-ITX/ac) のマニュアル確認したら、ファン速度変更する設定はあったので、Silent にしてみたが、期待したほどには静かにはならなかった
2021-03-02: acpi の件 は反応がないな
2021-03-01: メルカリからのメール filterability 低すぎ。メールはいい加減に作ってるのかな
2021-02-28: OpenBSD の ports にも取り込んだ https://marc.info/?l=openbsd-ports-cvs&m=161450923016894&w=2
2021-02-27: emacs がクラッシュする問題 は修正された https://github.com/emacs-mirror/emacs/commit/2c5f21541957e2420e54ab2a70883140811708f7
2021-02-26: use after free の問題 は、 VAIO の aml の不具合により領域をはみ出してメモリ参照するから ではないようだ。VAIO の aml をよく読むと、バグっぽいけどメモリ参照は はみ出さない。ローカル変数のリファレンスとして与えた場合に、従前の型 の情報をリセットしない実装になっていて、状況証拠的にこれが問題な感じ する。以下の diff をあててテストを開始
--- a/sys/dev/acpi/dsdt.c
+++ b/sys/dev/acpi/dsdt.c
@@ -2961,11 +2961,11 @@ aml_store(struct aml_scope *scope, struct aml_value *lhs , int64_t ival,
aml_rwfield(rhs, 0, rhs->v_field.bitlen, &tmp, ACPI_IOREAD);
rhs = &tmp;
}
+
+ lhs = aml_gettgt(lhs, AMLOP_STORE);
/* Store to LocalX: free value */
if (lhs->stack >= AMLOP_LOCAL0 && lhs->stack <= AMLOP_LOCAL7)
aml_freevalue(lhs);
-
- lhs = aml_gettgt(lhs, AMLOP_STORE);
switch (lhs->type) {
case AML_OBJTYPE_UNINITIALIZED:
aml_copyvalue(lhs, rhs);
tech@ にメールした https://marc.info/?l=openbsd-tech&m=161431463225032&w=2 (げ、"root cause" が "route cause" になっている...)
2021-02-26: emacs の問題も bug-gnu-emacs@gnu.org に送った http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46791 https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-02/
2021-02-24: Mew の draft モードで emacs が SIGSEGV で落ちる問題がかなりの再現性で、実用的に使えない。6.8 から発症。 gtk_label_new() で SEGV するのだが、これは emacs のツールバーにアイコン付きの ボタンを並べようとして、ボタンのラベルをセットしようとしたところ、ラベルのポインタが示す領域が不正になっているために、SEGV になっている。 調べたところ src/gtkutil.c の、update_frame_tool_bar()
5197 ti = xg_make_tool_item (f, w, &wbutton, label, i, horiz, text_image);
この label が腐っている。これは
5006 for (i = j = 0; i < f->n_tool_bar_items; ++i)
5007 {
5008 bool enabled_p = !NILP (PROP (TOOL_BAR_ITEM_ENABLED_P));
5009 bool selected_p = !NILP (PROP (TOOL_BAR_ITEM_SELECTED_P));
5022 const char *label
5023 = (EQ (style, Qimage) || (vert_only && horiz)) ? NULL
5024 : STRINGP (PROP (TOOL_BAR_ITEM_LABEL))
5025 ? SSDATA (PROP (TOOL_BAR_ITEM_LABEL))
5026 : "";
ループの冒頭で label をセットしているが、
5065 specified_file = file_for_image (image); 5066 if (!NILP (specified_file) && !NILP (Ffboundp (Qx_gtk_map_stock))) 5067 stock = call1 (Qx_gtk_map_stock, specified_file); 5068
#5067 の呼び出し後に label は不正なポインタとなる。ループ冒頭でのセットやり直せば、valid なポインタを取得できることから、 以下のように label の取得を、使う直前に移動することで修正できそうだ。
Index: src/gtkutil.c
--- src/gtkutil.c.orig
+++ src/gtkutil.c
@@ -5019,11 +5019,7 @@ update_frame_tool_bar (struct frame *f)
GtkWidget *wbutton = NULL;
Lisp_Object specified_file;
bool vert_only = ! NILP (PROP (TOOL_BAR_ITEM_VERT_ONLY));
- const char *label
- = (EQ (style, Qimage) || (vert_only && horiz)) ? NULL
- : STRINGP (PROP (TOOL_BAR_ITEM_LABEL))
- ? SSDATA (PROP (TOOL_BAR_ITEM_LABEL))
- : "";
+ const char *label;
ti = gtk_toolbar_get_nth_item (GTK_TOOLBAR (wtoolbar), j);
@@ -5133,6 +5129,11 @@ update_frame_tool_bar (struct frame *f)
continue;
}
}
+
+ label = (EQ (style, Qimage) || (vert_only && horiz)) ? NULL
+ : STRINGP (PROP (TOOL_BAR_ITEM_LABEL))
+ ? SSDATA (PROP (TOOL_BAR_ITEM_LABEL))
+ : "";
/* If there is an existing widget, check if it's stale; if so,
remove it and make a new tool item from scratch. */
emacs の開発にバグ報告して伝わるだろうか。少し前に openpty の問題は取 り込んでもらった が、わりと慎重に扱わ れた印象
2021-02-19: Zenfone は電卓アプリで .12345+= するとテストアプリ (SMMI_TEST) が起動するのね。おもしろい
2021-02-18: cvs2gitdump Python3 対応作業は一段落した感じなので、push しておいた
2021-02-18: malloc_conceal(3) ってのがあるのか。 https://undeadly.org/cgi?action=article;sid=20190605110020
2021-02-15: got
2021-02-15: この週末は cvs2gitdump の Python3 対応をゴリゴリとやっていた
2021-02-15: Python 2 => 3 っていろいろと変わる。パフォーマンス落ちてしまい、 いろいろと調べると int が無限長になった影響とかの記事があってビビったが、 結局 https://github.com/yasuoka/cvs2gitdump/commit/9de06c71942ed6fb1c61850c81c9891ea0caab23 で回復。わりとしょぼいところで秘孔をついていた
2021-02-14: https://docs.python.org/3/library/stdtypes.html#common-sequence-operations の s.index(x[, i[, j]]) の説明で、"Not all implementations support passing the additional arguments i and j." とある。 サポートしない実装ではなにがおこるの? 使わないほうがよいの?
2021-02-10: emacs で日本語入力中に SIGSEGV で落ちまくる現象 -g 付きの バイナリ用意して、デバッグ体制に入った
2021-02-09: Chromebook 輸入した時のデポジットとして 666 円が返ってくる 連絡がきた。輸出費用ってデポる仕組みだったのか。知らなかった
2021-02-07: mlvwm が ports に入った morgant さんに頼まれて、原作者への連絡を仲介したので、良かった
2021-02-07: japanese-holidays-calendar 、特措法の改正の patch がマージされない。osamu さんにメールしてみてはいる。 自分のリポから fork し始めちゃってる けど、どうなるんだろ
2021-02-05: "The Great Suspender" はマルウェアを含む可能性ある、ということで、無効になっていた
2021-02-05: たまには Windows Update しておこうと思い、行ってみたところ、 KB4535680 が 0x800f0922 で失敗するという問題にあたり、どはまり。いろん な解決方法試した上に、UEFI まわりということで、boot loader をデフォルト に戻し、secure boot を disable にしてみたりしたが解決しない 同じように ハマって未解決な人がいる ようなので、しばらく様子見...
2021-02-02: Lenovo USI ペン届いた。パーフェクトではないけど、まずまず 使えそうな感じ
2021-01-28: chromebook duet 既に成田で、本日着予定に上方修正されてる。 4 日で納品だし、送料含めても日本で調達するより少し安い。雪により配送遅れ、 1/29 着
2021-01-28: Lenovo USI Pen 発送の連絡来たが、貨物ステータスによると 1/27 に "lenovo 工場" 出荷で、配送は 2/4。これって海外からの配送かな。 (2021-02-02 追記) 2/2 着。香港からの発送だったみたい
2021-01-27: w3m の passwd ファイル。 README.passwd に "You can omit port, path and realm" と書いてあるが、 実際には realm は省略できない。厳密には proxy なら省略できる。 https://github.com/tats/w3m/blob/f1fd7215d2e031679b64f647744bab3da710716c/etc.c#L926
925 if ((ent->host || netrc) /* netrc accept default (host == NULL) */
926 &&(ent->is_proxy || ent->realm || netrc)
927 && ent->uname && ent->pwd) {
#926 より proxy じゃなく netrc じゃない場合 realm は必須になっている。
--- src/etc.c.orig Wed Jan 27 16:27:33 2021
+++ src/etc.c Wed Jan 27 16:56:26 2021
@@ -936,7 +936,7 @@ static void
add_auth_pass_entry(const struct auth_pass *ent, int netrc, int override)
{
if ((ent->host || netrc) /* netrc accept default (host == NULL) */
- &&(ent->is_proxy || ent->realm || netrc)
+ &&(ent->is_proxy || netrc)
&& ent->uname && ent->pwd) {
struct auth_pass *newent = New(struct auth_pass);
memcpy(newent, ent, sizeof(struct auth_pass));
でよいんだろうか。
2021-01-27: 端末の色付けは AlexAkulov/putty-color-themes: PuTTY Color Themes の 2 を使っている
2021-01-24: ペン入力できるタブレットがほしくて、いろいろ物色した結果、 Lenovo Chromebook dual を購入。2/3 2/2 納品予定。国内だと JIS 配列しか入手できないので US amazon から US 版 を輸入することにした。日本だと 128GB 版 4万円が相場だが、 US だと 64GB $235 というモデルがあり、そっちを購入。送料含めるとちょうど 3 万 弱。USI のPen は、世界的には品薄っぽいが、日本の Lenovo に在庫があり、 4,440 JPY で発注。合計 3.5 万円ということになる。自分の用途は、お絵描 きするわけでもなく、たんにメモアプリで手書きしたい、ネットワーク構成図 などの図をサクサク書きたい、だが、この 3.5 万円構成で十分に実現できた らうれしい。(これは OpenBSD で動かすのではなく、ChromeOS として使うつ もり)
しかし、Lenovo Usi Pen | DONT BUY IT によると、壊れてるやつをツモることがあるらしい... 怖い
2021-01-20: 会社の mailest のメモリ使用量が 2GB を越えていてメモリ 枯渇してしまった。当該のプロセスは昨年 9/29 に起動したものらしい。 mailest 部分にリークがあるのか、libestrairer 部分なのか...
2021-01-15: FreeRDP の sndio 対応の議論 に参加。他に人が反応しないのが不思議だし、FreeRDP のバージョンが古いの は不思議。みなさん RDP 使ってないというのか？ 信じられない..
2021-01-15: emacs 27.1 キーボード入力中に異常終了すること時々ある
2021-01-14: OpenBSD 6.8 amd64 用の chromium-87.0.4280.141 (野良ビルド) 置いた 消した
2021-01-01: あけおめ(死語)