Yasuoka's hack log (2019年)

[ 2024 | 2023 | 2022 | 2021 | 2020 | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 ]

コメントはこちらまで or send a mail to yasuoka at yasuoka dot net.
とくに記載がない場合、OpenBSD の話をしています

2019-12

2019-12-28: https://marc.info/?l=openbsd-bugs&m=157748541912568&w=2 よかったよかった
2019-12-25: pledge(2): prof promise
2019-12-21: 先日 core がとれるようになり、次は gdb を修正。https://marc.info/?l=openbsd-tech&m=157691229529782&w=2
2019-12-20: Chrome まわりで日本語入力した時に、候補 Window が出ない。uim の issue にも見当たらず google っても同じ問題にハマっている人はいないっぽい。地味にいたい

2019-12-19: ACPI が怪しいと思い、デバッグ用の仕組みを組み込んだ。ACPI は 16 バイトの malloc bucket は使わなくなっている。デバッグするには ddb に入る必要があるがその前に、以下の panic。panic のパターン変わったかも

uvm_fault(0xfffffd819f986d18, 0x30, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at      linux_root_RB_REMOVE+0x82:      movq    %rsi,0x10(%rdx)
Running script...
ddb{2}> linux_root_RB_REMOVE(ffff800001bee198,ffff8000012f0f00) at linux_root_RB_REMOVE+0x82
drm_vma_node_revoke(ffff800001bee0d8,ffff8000335f7938) at drm_vma_node_revoke+0x56
drm_gem_object_release_handle(bf,ffff800001bee0c0,ffff80000221fc00) at drm_gem_object_release_handle+0x8a
drm_gem_handle_delete(ffff80000221fc00,bf) at drm_gem_handle_delete+0x7a
drmioctl(75700,80086409,ffff80003482aac0,3,ffff8000fffe4fa8) at drmioctl+0xd8
VOP_IOCTL(fffffd819e081430,80086409,ffff80003482aac0,3,fffffd822c348848,ffff8000fffe4fa8) at VOP_IOCTL+0x55
vn_ioctl(fffffd819e082690,80086409,ffff80003482aac0,ffff8000fffe4fa8) at vn_ioctl+0x64
sys_ioctl(ffff8000fffe4fa8,ffff80003482abd0,ffff80003482ac30) at sys_ioctl+0x3c2
syscall(ffff80003482aca0) at syscall+0x389
Xsyscall(0,36,138ecd465568,36,80086409,7f7ffffe6b38) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7ffffe6b20, count: -10
ddb{2}>
dumping to dev 4,1 offset 465820

2019-12-18: Data modified on freelist の件。
```
0xffff800000b9f7c0:     0xdeaf4152      0xdeaf0002      0x471926d4      0xc211106f
0xffff800000b9f7d0:     0xdeaf4152      0xdeaf0002      0x47192614      0xc211106f
0xffff800000b9f7e0:     0xdeaf4152      0xdeaf0000      0x471926f4      0xc2111020 <-- 壊れてる
0xffff800000b9f7f0:     0xdeaf4152      0xdeaf0000      0x47192904      0xc211006f <-- 壊れてる
0xffff800000b9f800:     0xdeaf4152      0xdeaf0000      0x47192914      0xc211106f
0xffff800000b9f810:     0xdeaf4152      0xdeaf0000      0x47192924      0xc211106f
0xffff800000b9f820:     0xdeaf4152      0xdeaf0000      0x47192934      0xc211106f
0xffff800000b9f830:     0xdeaf4152      0xdeaf0000      0x47192944      0xc211106f
```
1 行 1 freelist のエントリになっている。
```
poison(32bit)  poison(16bit) type(16bit) next(64bit)
```
で、第 3, 4 ワードは次の要素へのポインタで第 4 ワードは上位 32bit になるので、 0xc2111106f になるのが正しいが 3、4 番めのエントリは壊れている。 (OpenBSD は XSIMPLEQ を使っているので、ポインタは coookie = 0x3dee906f47a0d104 と XOR された値) 5 番目以降のエントリの next には +1 番目のエントリが入っていて、しかも FREE なので、未使用のエントリと推測される。これは、3,4 番目のエントリにたいしても、壊れている部分を 0xc2111106f だったとすれば、同じことが言える。つまり、壊れているのは未使用のエントリであるので、use-after-free ではない。

となると...

2019-12-18: 別の core から

0xffff800000b9f640:     0xdeaf4152      0xdeaf007f      0x2f657265      0x384a209c
0xffff800000b9f650:     0xdeaf4152      0xdeaf007f      0x2f657285      0x38002a9c
0xffff800000b9f660:     0xdeaf4152      0xdeaf007f      0x2f657275      0x384a2a9c
0xffff800000b9f670:     0xdeaf4152      0xdeaf007f      0x2f657255      0x384a2a9c

1,2 番めが壊れてる。ページは 0xffff800000b9f000 で同じ

2019-12-18: 別の core から

0xffff8000014cb120:     0xdeaf4152      0xdeaf0091      0xef7cdde7      0xbdd80bc3
0xffff8000014cb130:     0xdeaf4152      0xdeaf0091      0xee6365d7      0x42278bc3
0xffff8000014cb140:     0x9e193850      0xfffffd81      0x9e1934c0      0xfffffd81
0xffff8000014cb150:     0x00000008      0x00000000      0x42204a56      0x32355350
0xffff8000014cb160:     0xfffffffe      0x00000003      0x00000000      0xdeaf4152
0xffff8000014cb170:     0xdeaf4152      0xdeaf0091      0xef2fdc57      0xbdd80bc3
0xffff8000014cb180:     0xdeaf4152      0xdeaf0091      0xef2fdd07      0xbdd80bc3
0xffff8000014cb190:     0xdeaf4152      0xdeaf0091      0xef2fd457      0xbdd80bc3

2 番めが壊れてる。ページは異なる

2019-12-17: OpenBSD 6.6 amd64 用の chromium 79.0.3945.79p1 (野良ビルド) (2020-01-09 消した)
- LINE がクラッシュする問題が治った。これは助かる
2019-12-13: 残っている問題は use after free。サイズは 16 バイト以下。 kern_mallo.c:
```
323         /* Fill the fields that we've used with poison */
324         poison_mem(freep, sizeof(*freep));
325
326         /* and check that the data hasn't been modified. */
327         if (freshalloc == 0) {
328                 size_t pidx;
329                 uint32_t pval;
330                 if (poison_check(va, allocsize, &pidx, &pval)) {
331                         panic("%s %zd of object %p size 0x%lx %s %s"
332                             " (0x%x != 0x%x)\n",
333                             "Data modified on freelist: word",
```
#330 でのチェックの事前準備として #324 で書き換えちゃったポイズンを書き戻している。そのサイズは 16 バイト。これにより 16 バイトのメモリを use after free しても検出しない。 struct kmem_freelist 全部を書き換えるわけじゃないので、書き換わってないところ、とくに先頭の kf_spare0 フィールドが書き換わってないことを追加で確認してみることにした。現在検出している Data modified on freelist は、これとは別の検査で、フリーリストの次の要素が uvm 的に valid かどうかの検査するのだが、そのチェックで検出したものである。次の要素を示すポインタを書き換えちゃって変なところを示しているのだろうから、 #330 のチェックでも検出するようになるはずである。検出すれば、書き換えられちゃった領域の正確なタイプがわかるはず

2019-12-12: まだ頻繁に落ちる

[drm] *ERROR* Potential atomic update failure on pipe A
sd3 at scsibus4 targ 2 lun 0: <OPENBSD, SR CRYPTO, 006>
sd3: 20481MB, 512 bytes/sector, 41945199 sectors
kernel: protection fault trap, code=0
Stopped at      i915_gem_object_put_pages_gtt+0x63:     movl    0x8(%r15),%r13d
Running script...
ddb{0}> i915_gem_object_put_pages_gtt(ffff800001d5a6f8,ffff800001d25cd0) at i915_gem_object_put_pages_gtt+0x63
__i915_gem_object_put_pages(ffff800001d5a6f8,10000) at __i915_gem_object_put_pages+0x86
__i915_gem_free_objects(ffff8000002ab000,ffff800001d60520) at __i915_gem_free_objects+0x1d8
__i915_gem_free_work(ffff8000002af4f0) at __i915_gem_free_work+0x5b
taskq_thread(ffff800000596d00) at taskq_thread+0x67
end trace frame: 0x0, count: -5
ddb{0}>

2019-12-10: yasuoka.net のメールサーバも web サーバも、また落ちてた。監視の warning までは見ていて自然復帰したと勘違いして寝てしまった..

2019-12-09: emacs でメールを読んでいたら

Data modified on freelist: word -35183627864230 of object 0xffff80000138ffc0 size 0x10 previous type DRM (invalid addr 0xffff80000166ff10)
panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) vmmaplk
Stopped at   db_enter+0x10:  popq    %rbp
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
 404276  72707   5063    0x100000       0x80    3  xconsole
  72639   1468   5063         0x2          0    2  xfwm4
*235132  75240     35        0x12          0    1K Xorg
db_enter() at db_enter+0x10
panic() at panic+0x128
witness_checkorder(ffffffff81f63970,1,0) at witness_checkorder+0xaba
rw_enter_read(ffffffff81f63960) at rw_enter_read+0x38
uvmfault_lookup(ffff8000337a4d28,0) at uvmfault_lookup+0x8a
uvm_fault(ffffffff81f63958,ffff80000166f000,0,1) at uvm_fault+0x6a
pageflttrap() at pageflttrap+0x145
kerntrap(ffff8000337a4ea0) at kerntrap+0x91
alltraps_kern_meltdown(6,0,ffffffff820a7200,0,2440,ffff80000166ff10) at alltraps_kern_meltdown+0x7b
malloc(10,91,5) at malloc+0x482
i915_gem_do_execbuffer(ffff8000002ab078,ffff800000ee9800,ffff8000337a54a0,ffff800001062c00,0) at i915_gem_do_execbuffer+0xa52
i915_gem_execbuffer2_ioctl(ffff8000002ab078,ffff8000337a54a0,ffff800000ee9800) at i915_gem_execbuffer2_ioctl+0x144
drmioctl(15700,80406469,ffff8000337a54a0,3,ffff8000336a8798) at drmioctl+0xd8
VOP_IOCTL(fffffd8227c2b4f8,80406469,ffff8000337a54a0,3,fffffd826b158de8,ffff8000336a8798) at VOP_IOCTL+0x55
end trace frame: 0xffff8000337a5490, 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.
Running script...
ddb{1}>

drmioctl から先の malloc で uvm_fault。これは drmioctl からの__i915_spin_request() で spin しっぱなしになるのと関連してしまってるのかも

2019-12-09: 11/12 から DNS サーバが落ちてた...
- 監視メールは gmail のアカウントに届くが、スマホの通知にならず、このあたりに問題があるので、gmail でフィルタを作成し、「重要」にマークするようにし、slack や普段のメールアカウントにも転送するようにした

2019-12-08: 放置してたら panic した

Data modified on freelist: word -35183627074926 of object 0xffff8000024a3060 size 0x10 previous type temp (invalid addr 0xffff8027023e55f0)
uvm_fault(0xffffffff81f63958, 0xffff8027023e55f8, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      malloc+0x482:   movq    0x8(%r14),%rcx
Running script...
ddb{0}> malloc(10,91,5) at malloc+0x482
i915_gem_do_execbuffer(ffff8000002ab078,ffff800000ee0c00,ffff8000337a7970,ffff8000020ca000,0) at i915_gem_do_execbuffer+0xa52
i915_gem_execbuffer2_ioctl(ffff8000002ab078,ffff8000337a7970,ffff800000ee0c00) at i915_gem_execbuffer2_ioctl+0x144
drmioctl(15700,80406469,ffff8000337a7970,3,ffff8000336a8798) at drmioctl+0xd8
VOP_IOCTL(fffffd8227abbeb0,80406469,ffff8000337a7970,3,fffffd826bd1dd88,ffff8000336a8798) at VOP_IOCTL+0x55
vn_ioctl(fffffd82282ee8e8,80406469,ffff8000337a7970,ffff8000336a8798) at vn_ioctl+0x64
sys_ioctl(ffff8000336a8798,ffff8000337a7a80,ffff8000337a7ae0) at sys_ioctl+0x3c2
syscall(ffff8000337a7b50) at syscall+0x389
Xsyscall(6,36,0,36,80406469,7f7fffff5c00) at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7fffff5bd0, count: -9
ddb{0}>

2019-12-07: dumpsys() が途中で止まる原因はコレ。コマンドを完了を示すビットが、リングバッファが一巡するとビットの意味が反転するのだが、それだと扱いづらいので、nvme_poll_done() で、コマンド完了時を常に true とする実装をしている。この時に手元の値だけを書き換えるのなら問題がないが、デバイス上のビットも書き換えてしまっていた。

Index: sys/dev/ic/nvme.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/nvme.c,v
retrieving revision 1.63
diff -u -p -r1.63 nvme.c
--- sys/dev/ic/nvme.c       27 Jul 2019 13:20:12 -0000      1.63
+++ sys/dev/ic/nvme.c       7 Dec 2019 05:51:22 -0000
@@ -957,8 +957,8 @@ nvme_poll_done(struct nvme_softc *sc, st
 {
    struct nvme_poll_state *state = ccb->ccb_cookie;

-   SET(cqe->flags, htole16(NVME_CQE_PHASE));
    state->c = *cqe;
+   SET(state->c.flags, htole16(NVME_CQE_PHASE));
 }

 void

これで core がとれるようになったので、作業が捗るはず

2019-12-07: X 上で負荷をかけるとハングする問題の回避方法がわかった

diff --git a/sys/dev/pci/drm/i915/i915_request.c b/sys/dev/pci/drm/i915/i915_request.c
index 6d9cf0d4b12..0e600deeb66 100644
--- a/sys/dev/pci/drm/i915/i915_request.c
+++ b/sys/dev/pci/drm/i915/i915_request.c
@@ -1226,6 +1226,7 @@ static bool __i915_spin_request(const struct i915_request *rq,
 {
     struct intel_engine_cs *engine = rq->engine;
     unsigned int irq, cpu;
+    int spunout = 20000000;

     GEM_BUG_ON(!seqno);

@@ -1276,7 +1277,9 @@ static bool __i915_spin_request(const struct i915_request *rq,
                     break;

             cpu_relax();
-    } while (!drm_need_resched());
+    } while (!drm_need_resched() && spunout-- > 0);
+    if (spunout <= 0)
+            printf("%s: spunout %lu %lu\n", __func__, timeout_us, local_clock_us(&cpu));

     return false;
 }

kernel lock したままスピンする問題はすべてコレが原因だった。

本日 2 つ問題が解決して、残りは、”Data modified on freelist” などで検出している問題だけか。

2019-12-05: switching tabs on web browser

kernel: protection fault trap, code=0
Stopped at      i915_gem_object_put_pages_gtt+0x63:     movl    0x8(%r15),%r13d
Running script...
ddb{3}> sleep_finish(ffffffff8235bea8,1) at sleep_finish+0x84
tsleep(ffffffff820aaae8,4,ffffffff81c9bf0e,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-05: switching tabs on web browser

__mp_lock_spin: cpu=2 lock spun out
__mp_loStopped at       x86_ipi_db+0x12:        leave
Running script...
ddb{1}> sleep_finish(ffffffff8235bea8,1) at sleep_finish+0x84
tsleep(ffffffff820aaae8,4,ffffffff81c9bf0e,0) at tsleep+0xcb

Data modified on freelist: word -35183627862710 of object 0xffff800001887544 size 0x10 previous type ??? (invalid addr 0x5c7da1676eab4751)
kernel: protection fault trap, code=0
Stopped at      malloc+0x482:   movq    0x8(%r14),%rcx
Running script...
ddb{2}> sleep_finish(ffffffff8235bea8,1) at sleep_finish+0x84
tsleep(ffffffff820aaae8,4,ffffffff81c9bf0e,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-04: When rebooting

urtwn0: device timeout
syncing disks...panic: pr_find_pagehead: dirhash: page header missing
Stopped at      db_enter+0x10:  popq    %rbp
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
*216863  96362      0         0x2          0    0K reboot
db_enter() at db_enter+0x10
panic() at panic+0x128
pool_do_put(ffffffff820ad068,ff208000348e7400) at pool_do_put+0x29b
pool_put(ffffffff820ad068,ff208000348e7400) at pool_put+0x5a
ufsdirhash_free(fffffd81e0d50cd0) at ufsdirhash_free+0xf0
ufs_reclaim(fffffd82094bdc38,ffff800033b571c8) at ufs_reclaim+0x9a
ffs_reclaim(ffff800033a9f710) at ffs_reclaim+0x2f
VOP_RECLAIM(fffffd82094bdc38,ffff800033b571c8) at VOP_RECLAIM+0x46
vclean(fffffd82094bdc38,8,ffff800033b571c8) at vclean+0xda
vgonel(fffffd82094bdc38,ffff800033b571c8) at vgonel+0x3c
vflush_vnode(fffffd82094bdc38,ffff800033a9f810) at vflush_vnode+0xc0
vflush(ffff800000e34000,0,2) at vflush+0x57
ffs_flushfiles(ffff800000e34000,2,ffff800033b571c8) at ffs_flushfiles+0x86
ffs_unmount(ffff800000e34000,80000,ffff800033b571c8) at ffs_unmount+0x46
end trace frame: 0xffff800033a9f990, 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.
Running script...
ddb{0}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-04: http://www.wikihouse.com/mew/index.php?Mew4FAQ#c46d68e8 を参考に、 Openpgp ヘッダ (Thunderbird などが使っているらしい) を非表示にする設定を入れた
```
(mew-insert-after mew-field-spec '("^Autocrypt:" nil) "^Status:$")
(mew-insert-after mew-field-spec '("^Openpgp:" nil) "^Status:$")
```

2019-12-04: Unknown timing

panic: free: size too large 24 > 1 (0xffff800001200c20) type DRM
Stopped at      db_enter+0x10:  popq    %rbp
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
  86549  53152   5063    0x300003          0    3  chrome
 363084  53152   5063    0x300003  0x4000000    2  chrome
 243356  84735   5063    0x300003          0    1  chrome
*252522  88001      0     0x14000      0x200    0K i915
db_enter() at db_enter+0x10
panic() at panic+0x128
free(ffff800001200c20,91,18) at free+0x3d2
i915_gem_object_put_pages_gtt(ffff800001569148,ffff80000179a9e0) at i915_gem_object_put_pages_gtt+0x117
__i915_gem_object_put_pages(ffff800001569148,10000) at __i915_gem_object_put_pages+0x86
__i915_gem_free_objects(ffff8000002ab000,ffff8000015692b8) at __i915_gem_free_objects+0x1d8
__i915_gem_free_work(ffff8000002af4f0) at __i915_gem_free_work+0x5b
taskq_thread(ffff800000596380) at taskq_thread+0x67
end trace frame: 0x0, count: 7
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
Running script...
ddb{0}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-04: mem address conflict 0xfe010000/0x1000 の件は、UEFI で reserved とした領域と重なっていると判明。どうするか考え中

2019-12-03: 朝起きたら panic reboot してた

Data modified on freelist: word -35183625861134 of object 0xffff8000017f6ae0 size 0x10 previous type DRM (invalid addr 0xffffb600017f6aa0)
uvm_fault(0xffffffff81f63c18, 0xffffb600017f6aa8, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      malloc+0x482:   movq    0x8(%r14),%rcx
Running script...
ddb{2}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-03:

Data modified on freelist: word -35183627829358 of object 0xffff80000193a64d size 0x10 previous type ??? (invalid addr 0xe0993221430b8d6d)
kernel: protection fault trap, code=0
Stopped at      malloc+0x482:   movq    0x8(%r14),%rcx
Running script...
ddb{0}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-02: Idle 時に panic するやつ (その 2)

uvm_fault(0xffffffff820aaea0, 0x58, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      i915_gem_object_put_pages_gtt+0x73:     movq    0x58(%rax),%r14
ddb{3}> ddb{3}> ddb{3}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-02: 負荷をかけるとハング、放置すると uvm_fault で、かなりつらい状況..

2019-12-02: suspend から復帰後

Data modified on freelist: word -35183627864770 of object 0xffff800002786a40 size 0x10 previous type DRM (invalid addr 0xff3d8000035df160)
kernel: protection fault trap, code=0
Stopped at      malloc+0x482:   movq    0x8(%r14),%rcx
Running script...
ddb{3}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-02: 作業中断してご飯食べてたら panic

xhci0: NULL xfer pointer
sd3 at scsibus4 targ 2 lun 0: <OPENBSD, SR CRYPTO, 006>
sd3: 20481MB, 512 bytes/sector, 41945199 sectors
Data modified on freelist: word -35183625486786 of object 0xffff800001a11459 size 0x4 previous type free (invalid addr 0x3b9d18dc97b772f9)
panic: free: unaligned addr 0xffff800001a11459, size 16, type temp, mask 15
Stopped at      db_enter+0x10:  popq    %rbp
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
 249585  26480   5063    0x300003  0x4000000    1  chrome
 500937  99076   5063    0x300003          0    0  chrome
*434420  99076   5063    0x300003  0x4000000    2K chrome
 313448   9571   5063    0x100000       0x80    3  xconsole
db_enter() at db_enter+0x10
panic() at panic+0x128
free(ffff800001a11459,7f,4) at free+0x3ef
unp_externalize(fffffd807547eb00,210,80) at unp_externalize+0x406
soreceive(fffffd824c0f7670,ffff8000340b7078,ffff8000340b7038,0,ffff8000340b7070,ffff8000340b71dc) at soreceive+0x612
recvit(ffff8000337b8538,36,ffff8000340b71b0,0,ffff8000340b72a0) at recvit+0x1ed
sys_recvmsg(ffff8000337b8538,ffff8000340b7240,ffff8000340b72a0) at sys_recvmsg+0xe0
syscall(ffff8000340b7310) at syscall+0x389
Xsyscall(0,1b,b28db2baa20,1b,b299c9faf88,b2947287c00) at Xsyscall+0x128
end of kernel
end trace frame: 0xb28db2ba7f0, count: 6
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
Running script...
ddb{2}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-12-01: Idle 時に panic するやつ

Data modified on freelist: word -35183623670806 of object 0xffff80000271dba0 size 0x4 previous type DRM (invalid addr 0xffff8000313541d0)
Data modified on freelist: word -35183627864634 of object 0xffff8000313541d0 size 0x10 previous type ??? (invalid addr 0x61fd62c6ce8af52d)
panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) vmmaplk
Stopped at      db_enter+0x10:  popq    %rbp
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
 403289  63427   5063    0x100000       0x80    3  xconsole
 275257  22498   5063         0x2          0    1  xfwm4
*203385  59215     35        0x12          0    2K Xorg
db_enter() at db_enter+0x10
panic() at panic+0x128
witness_checkorder(ffffffff81f63c30,1,0) at witness_checkorder+0xaba
rw_enter_read(ffffffff81f63c20) at rw_enter_read+0x38
uvmfault_lookup(ffff8000337a4998,0) at uvmfault_lookup+0x8a
uvm_fault(ffffffff81f63c18,ffff8000080df000,0,1) at uvm_fault+0x6a
pageflttrap() at pageflttrap+0x145
kerntrap(ffff8000337a4b10) at kerntrap+0x91
alltraps_kern_meltdown(6,31339,61fd62c6ce8af52d,0,2440,ffff8000313541d0) at alltraps_kern_meltdown+0x7b
malloc(10,91,5) at malloc+0x5c9
i915_gem_object_get_pages_gtt(ffff8000027f8b90) at i915_gem_object_get_pages_gtt+0x58
__i915_gem_object_get_pages(ffff8000027f8b90) at __i915_gem_object_get_pages+0xbb
i915_gem_set_domain_ioctl(ffff8000002ab078,ffff8000337a4fb0,ffff800000ea0c00) at i915_gem_set_domain_ioctl+0xda
drmioctl(15700,800c645f,ffff8000337a4fb0,3,ffff8000336a8798) at drmioctl+0xd8
end trace frame: 0xffff8000337a4ea0, 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.
Running script...
ddb{2}> sleep_finish(ffffffff8235aea8,1) at sleep_finish+0x84
tsleep(ffffffff820aa668,4,ffffffff81c9c160,0) at tsleep+0xcb
main() at main+0x7a0
end trace frame: 0x0, count: 254

2019-11

2019-11-30: X 上の termininal で find / などとするとハングは再現する。 kernel lock をつかんだままループしているっぽいスレッドは drmtskl なのだが、これ以上デバッグが進まない。dumpsys が成功しないので、gdb は使えない。ループしているのが video ドライバなので、ddb も使えない。どうやったらループしているスレッドの trace をとれるんだろうか。当該スレッドを ipi で ddb に入れることはできるのだが、そこから trap 元の frame をどう読んだらよいのだろう。

2019-11-27: dmesg をよく見ると

0:31:5: mem address conflict 0xfe010000/0x1000

というのがあった。pcidump -v より:

0:31:5: Intel 300 Series SPI
       0x0000: Vendor ID: 8086, Product ID: 9da4
       0x0004: Command: 0402, Status: 0000
       0x0008: Class: 0c Serial Bus, Subclass: 80 (unknown),
               Interface: 00, Revision: 30
       0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
               Cache Line Size: 00
       0x0010: BAR mem 32bit addr: 0xfe010000/0x00001000
       0x0014: BAR empty (00000000)
       0x0018: BAR empty (00000000)
       0x001c: BAR empty (00000000)
       0x0020: BAR empty (00000000)
       0x0024: BAR empty (00000000)
       0x0028: Cardbus CIS: 00000000
       0x002c: Subsystem Vendor ID: 1d19 Product ID: 000f
       0x0030: Expansion ROM Base Address: 00000000
       0x0038: 00000000
       0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00

実際にはこの出力は以下の diff を適用した後のもので、適用前は BAR mem 32bit addr: が 0x0/0x1000 となっている。これは diff を当てた箇所の下で、そのように書き込んだ結果そうなっていると思われる。:

diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c
index 1ca2b943df9..b92a7d70d01 100644
--- a/sys/dev/pci/pci.c
+++ b/sys/dev/pci/pci.c
@@ -895,6 +895,8 @@ pci_reserve_resources(struct pci_attach_args *pa)
                        base, size, EX_NOWAIT)) {
                            printf("%d:%d:%d: mem address conflict 0x%lx/0x%lx\n",
                                bus, dev, func, base, size);
+                           if (base == 0xfe010000)
+                                   break;
                            pci_conf_write(pc, tag, reg, 0);
                            if (type & PCI_MAPREG_MEM_TYPE_64BIT)
                                    pci_conf_write(pc, tag, reg + 4, 0);

とりあえず、この diff で症状が変わるかを試してみる。

2019-11-27: ふと。昔 movable type とかでコメント機能を有効にすると、SEO 狙いか、リンク付きのコメントスパムが殺到する問題があって、captcha で対策した時代もあったけど、captcha の実装のメンテがなかなか面倒くさかった。 5 年ぐらい熟考した結果「URL は自動ではリンクにせず、captcha っぽい何かがあれば、費用対効果が低いから spam 来ないのでは?」と思い、ためしに、「日本の首都を漢字で」という質問に「東京」と入れてもらう実装にしてみたら、本当にスパムはまったくこない。世の中そんなもんなんだな。実装は https://github.com/yasuoka/comment.cgi
2019-11-27: hexdump in bootloader、 https://github.com/yasuoka/hd/blob/master/hd2.c というのもあったけど、別実装になってしまった

2019-11-27: xterm 上で find / とすると MP_LOCKDEBUG が lock spun out を検出する

__mp_lock_spin: 0xffffffff8209eb48 lock spun out__mp_lock_spin: 0xffffffff8209eb48 lock spun outpanic: kernel diagnostic assertion "_kernel_lock_held()" failed:
file "/source/yasuoka/openbsd/head/git/src/sys/dev/pci/drm/drm_linux.c", line 652
Stopped at      db_enter+0x10:  popq    %rbp
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
   3063  80015   5063    0x100032          0    3  xterm
 275821  57743     35        0x12          0    0  Xorg
* 61603  95073   5063           0  0x4000000    2  mailestctl
db_enter() at db_enter+0x10
panic() at panic+0x128
__assert(ffffffff81cae26b,ffffffff81cba0ff,28c,ffffffff81cb9723) at __assert+0x2b
idr_alloc(ffff8000002ab378,ffff8000011ccb00,1,0,5) at idr_alloc+0x186
__drm_mode_object_add(ffff8000002ab078,ffff8000011ccb00,bbbbbbbb,1,ffffffff817697d0) at __drm_mode_object_add+0x6c
drm_property_create_blob(ffff8000002ab078,44,ffff800033731640) at drm_property_create_blob+0xa5
drm_atomic_set_mode_for_crtc(ffff800001071000,ffff80000056fe00) at drm_atomic_set_mode_for_crtc+0x87
__drm_atomic_helper_set_config(ffff800000b7bd00,ffff800001071800) at __drm_atomic_helper_set_config+0xda
restore_fbdev_mode_atomic(ffff800000b6ce00,1) at restore_fbdev_mode_atomic+0x14a
drm_fb_helper_restore_fbdev_mode_unlocked(ffff800000b6ce00) at drm_fb_helper_restore_fbdev_mode_unlocked+0x76
intel_fbdev_restore_mode(ffff8000002ab078) at intel_fbdev_restore_mode+0x33
db_ktrap(1,0,ffff800033731900) at db_ktrap+0x2c
kerntrap(ffff800033731900) at kerntrap+0xa2
alltraps_kern_meltdown(1,30,0,0,ffff80002200aff0,ffffffff8209eb48) at alltraps_kern_meltdown+0x7b
end trace frame: 0xffff8000337319b0, 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.
ddb{2}> rebooting...

これはどうしたものか...

stack trace 自体は、 lock spun out により ddb に入ろうとして X から wsdisplay に切り替わろうとしたところ KERNEL_ASSERT_LOCKED() が失敗して panic したということ。肝心の lock spun out の情報がない...

2019-11-22: OpenBSD 6.6 errata 007
- "A local user could cause the system to hang by reading specific registers when Intel Gen8/Gen9 graphics hardware is in a low power state." 現象としてこれも起こっているけど、これは efifb でも起こっていたので drm 関係ないと思っていたのだが...
- とにかく一部かもしれないけど問題はなおるので大変良かった
2019-11-22: OpenBSD 6.6 amd64 用の chromium 78.0.3904.106 (野良ビルド) (2019-12-17 消した)
2019-11-21: efifb でもハングすること 2 回。アイドル状態の時と、suspend から復帰した時
2019-11-20: しょっちゅうハングしたり panic する問題は inteldrm(4) の問題っぽい。数時間に一度作業が中断するのは、つらくなってきたので、平日昼間は efifb で生活することにする

2019-11-19: mailest で検索の問題は解決したが、大量に受信することに伴う問題は、がまんの限界

こんな lua スクリプトで制御できるようにするプログラムを書いて、おおよそ動くところまできた

mailserver = mailfilter.pop3("pop3s://mailserver", "username")
mailserver:getpass()

inbox = mailfilter.mh_folder("inbox")
spam  = mailfilter.mh_folder("spam")

for _,msg in pairs(mailserver:list()) do
  spam = false
  msg:top({
    on_header = function(key, val)
      if key == "subject" and val:find("未承諾広告") then
        spam = true
      end
    end
  })
  if not spam then
    inbox:save(msg, {"X-Spam-Check", "passed")
  else
    spam:save(msg)
  end
end

問題意識と実装の方向性に共感できる人いないかな

2019-11-11: OpenBSD 6.6 amd64 用の chromium 78.0.3904.97 (野良ビルド) (2019-12-17 消した)
2019-11-11: しょっちゅうハングしたり panic する問題のデバッグ
- panic しても dumpsys が必ず途中で刺さるので、まずはそれを回避したい
- この diff を revert
- efifb が PMAP_DIRECT の範囲からはみ出している場合には、 efifb を attach しないようにしてしばらく生活してみる
2019-11-08: タップ tap to click は xfce の設定で on にすれば使える。しかし、タイプ中にタッチパッドを無効にする機能が動いてないっぽく、それではまともに文章入力できないので、結局は無効にしたままになった
2019-11-08: VAIO Pro PK。malloc() や free() で panic したり uvm fault で落ちたりする問題が、9/11 以降 40 回以上発生している。それ以外にも X11 操作中にハングして、暫くして復帰するケースと、復帰しないケースがある
2019-11-07: VAIO Pro PK で、マウスのボタンが効かない問題があったが、imt(4) をいじって、ボタンは動くようになった。タップはまだ。
2019-11-06: 78 がきた https://github.com/openbsd/ports/commit/8a23431bd47e0626e7ab93aabd619200912c933a
2019-11-06: syn/ack リフレクションというのか https://sect.iij.ad.jp/d/2019/11/051516.html
2019-11-05: OpenBSD 6.6 amd64 用の chromium 77.0.3865.120 (野良ビルド) (2019-11-11 消した)
- LINE がクラッシュする問題は治っていない

2019-10

2019-10-24: RFC 3676 sig-dashes 知らなかった... https://www.kanzaki.com/memo/2006/03/03-1 直そ

2019-10-21: 文書のムキがちぐはぐになった PDF を直す

pdftk input.pdf shuffle 1-endoddeast 1-endevenwest output output.pdf

2019-10-09: またフィッシング iijad.jp にひっかかった

2019-10-09: ヘッダが大きすぎて mew の refile で処理されない時の回避設定の例

(setq mew-header-reasonable-size 20000)
(setq mew-header-max-length 4096)
(setq mew-header-max-depth 100)

2019-10-02: http://www.inctel.com.cn/ かっこいいやついっぱいある
2019-10-01: 「DNSフィルタリングによるマルウェア対策機能」オプトアウトした

2019-09

2019-09-30: OpenBSD 6.5 amd64 用の chromium 77.0.3865.90p1 (野良ビルド) (2019-11-05 消した)
2019-09-29: chromium が速攻で落ちる問題の修正が来てた。OpenBSD 6.5 amd64 用の chromium 77.0.3865.90p0 (野良ビルド) (2019-09-30 消した)

2019-09-26: mailest mew の refile 後に暴走

% ps Hup 25175
USER       PID %CPU %MEM   VSZ   RSS TT  STAT   STARTED       TIME COMMAND
yasuoka  25175 98.9  4.1 326864 335228 ??  R/3    10:04PM  403:50.81 mailestd (mailestctl)
yasuoka  25175  0.0  4.1 326864 335228 ??  I      10:04PM    0:00.56 mailestd (mailestctl)
yasuoka  25175  0.0  4.1 326864 335228 ??  I      10:04PM    0:00.06 mailestd (mailestctl)
%
% tail  ~/Mail/mailestd.log
2019-09-25 22:05:16:INFO: Database cache updated
2019-09-26 00:29:30:INFO: Gathering +inbox by monitor
2019-09-26 00:29:30:INFO: Opened DB for writing
2019-09-26 00:29:30:INFO: Updated +inbox (Folders: 1 Remove: 39 Update: 81)
2019-09-26 00:29:38:INFO: Gathering +openbsd-hackers by monitor
2019-09-26 00:30:12:INFO: Updated +openbsd-hackers (Folders: 1 Remove: 0 Update: 2)
2019-09-26 00:30:53:INFO: Gathering +openbsd-ports by monitor
2019-09-26 00:30:56:INFO: Updated +openbsd-ports (Folders: 1 Remove: 0 Update: 27)
2019-09-26 00:34:00:INFO: Gathering +openbsd-ports-changes by monitor
2019-09-26 00:34:01:INFO: Updated +openbsd-ports-changes (Folders: 1 Remove: 0 Update: 14)
%
% doas gdb mailestd/obj/mailestd 25175
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
(snip)
[Switching to thread 577355]
0x0000164f200dc3f7 in cbmapopenex () from /usr/local/lib/libqdbm.so.14.14
(gdb) bt
#0  0x0000164f200dc3f7 in cbmapopenex () from /usr/local/lib/libqdbm.so.14.14
#1  0x0000164ea93fd2eb in est_db_flush ()
   from /usr/local/lib/libestraier.so.8.38
#2  0x0000164c8a0116e4 in task_worker_on_proc_db (_this=0x7f7ffffec348,
    ctx=0x164f45173e00, task=0x0)
    at /home/yasuoka/Work/2018/mailest/mailestd/../mailestd.c:2267
#3  0x0000164c8a010cb9 in task_worker_on_proc (_this=0x7f7ffffec348)
    at /home/yasuoka/Work/2018/mailest/mailestd/../mailestd.c:2060
#4  0x0000164c8a0108a8 in task_worker_on_itc_event (fd=13, evmask=2,
    ctx=0x7f7ffffec348)
    at /home/yasuoka/Work/2018/mailest/mailestd/../mailestd.c:2022
#5  0x0000164f77f0087f in event_base_loop (base=0x164f7c40b000, flags=0)
    at /usr/src/lib/libevent/event.c:333
#6  0x0000164c8a00ec87 in task_worker_start0 (ctx=0x7f7ffffec348)
    at /home/yasuoka/Work/2018/mailest/mailestd/../mailestd.c:1927
#7  0x0000164f65fe0e21 in _rthread_start (v=Variable "v" is not available.
)
    at /usr/src/lib/librthread/rthread.c:96
#8  0x0000164ef6af043b in __tfork_thread ()
    at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#9  0x0000000000000000 in ?? ()
(gdb) finish
Run till exit from #0  0x0000164f200dc3f7 in cbmapopenex ()
   from /usr/local/lib/libqdbm.so.14.14

Program received signal SIGSTOP, Stopped (signal).
[Switching to thread 192857]
kevent () at -:3
3       -: No such file or directory.
        in -
Current language:  auto; currently asm
(gdb) continue
Continuing.

Program received signal SIGSTOP, Stopped (signal).
[Switching to thread 504376]
kevent () at -:3
3       in -
(gdb) continue
^C

cbmapopenex で無限 loop していたものと思われる。 continue から抜けるために Ctrl-C したらその signal で

2019-09-26 07:19:15:INFO: Received SIGINT
2019-09-26 07:19:45:INFO: Closing DB
2019-09-26 07:19:47:ERR: Closing DB: database problem
2019-09-26 07:19:47:INFO: Closed DB (put=124 delete=39)
2019-09-26 07:19:47:INFO: Stopped mailestd

正常終了してしまった。正常終了といっても database のエラーは検出している。 mailest を再起動したところ database は読めてる。

2019-09-26: https://opensource.srad.jp/story/16/06/10/2256213/ まつもとゆきひろ氏のこの OSS についての話
2019-09-26: OpenBSD 6.5 amd64 用の chromium 77.0.3865.90 (野良ビルド) 置いた。けど、動かない! (2019-09-29 消した)
2019-09-25: ubuntu を USB に入れて vaio pro で起動してみた。それはそれとして、強制的に hardware clock を UTC にされてしまう。https://askubuntu.com/questions/169376/clock-time-is-off-on-dual-boot ubuntu 8.10 から UTC=yes はデフォルトらしい
2019-09-25: vaio pro pk は、ほぼ完璧。
- vaio z に比べ、自分はノングレア液晶のほうがよいし、USB ポートやイーサネットポートが増えてよい。さらに、レガシーなスタンバイをサポートするので、ハイバネじゃなくサスペンドできる、やはり便利。液晶がタッチパネルじゃないけど別に困ってない。キーボードやスピーカーの品質は維持しているっぽくてよかった。十分満足だけど、あえて改善してほしい点をあげると、カメラは自分ではなくモノをとるのがほとんどなので、インカメラじゃなくアウトカメラがほしい。 VGA しか用意してない所では、ブツブツいいながら変換をかますことにしているので、VGA コネクタは要らない

2019-09-22: 動画撮影

doas sysctl kern.audio.record=1
doas env HOME=$HOME ffmpeg -i /dev/video0 -f sndio -i default -c:v copy output.avi -pix_fmt yuv420p -f xv -

2019-09-22: 写真撮影

doas env HOME=$HOME video -s 1280x780
# p で画面を停止し、import (ImageMagick) で画像ファイル化
import -window video out.png

2019-09-20: vaio pro の diff。efifb の問題と keyboard の問題が治る
- OpenBSD では directmap は 2GB までは、locore0.S で初期化するが、それ以降は、pmap_bootstrap() で初期化される。また cninit() で EFI Frame Buffer の directmap に触るのは pmap_bootstrap の前なので、 EFI Frame Buffer が 2GB より高位にある場合に対応できていなかった。修正としては、まず、cninit() を pmap_bootstrap() 後に呼び出すように変更する必要がある。さらに pmap_bootstrap 呼び出し時に、物理メモリの最高位として使用可能メモリの最高位を与えているが、 vaio pro の EFI Frame Buffer はこれに含まれないため引き続き問題であり、 EFI Frame Buffer の領域を含むように修正する必要がある
- この diff で vaio pro は生活に困らないレベルまで動くので、現在メインの vaio-z から引越しを始める
2019-09-20: WiFi が Qualcomm Athros QCA6174 というもので、まだドライバがないらしい。Linux の場合 ath10k というドライバ
2019-09-20: HDD の EFIBootBOOTX64.EFI に efiboot を置いても起動しない。UEFI Shell を起動して、エントリを追加する必要があった。方法は https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Obtaining_UEFI_Shell が参考になる
2019-09-15: OpenBSD 6.5 amd64 用の chromium 76.0.3809.132 (野良ビルド) 置いた (2019-09-25 消した)
2019-09-14: VAIO Pro とりあえず起動 dmesg
2019-09-11: VAIO Pro PK VJPK11C11N が納品
- VAIO の設定 -> 入力デバイス -> キーの設定で Ctrl <-> Caps の入れ替えができて便利
- OpenBSD 6.5 も 8/19 の snap も起動しない。efiboot => kernel あたりで止まる
2019-09-07: PPPoE のテスト手順を書いた https://gist.github.com/yasuoka/7a9ae7218a91b3544bae0ae9f2e594e1
2019-09-05: OneMix3 https://www.one-netbook.jp/landing/onemix3/ OpenBSD はどこまで動くかな
2019-09-04: https://github.com/osamutake/japanese-holidays-js/issues/7 直してもらった

2019-08

2019-08-30: https://github.com/osamutake/japanese-holidays-js/issues/7
2019-08-24: ports の grive2 (Google drive と同期するもの) を使い始めたけど、CPU 回りつつ 408 で失敗する不具合 https://github.com/vitalif/grive2/issues/254 を踏んでいる.. (2020-03-21 追記) grive2 の利用は要注意です
2019-08-15: OpenBSD 6.5 amd64 用の chromium 76.0.3809.100 (野良ビルド) 置いた (2019-09-17 消した)
- LINE アプリ直らず
2019-08-15: "/.well-known/" は RFC 8615 で定義されていて、登録制
2019-08-09: "config -e" timezone の問題、議論が始まった https://marc.info/?t=156523215100002&r=1&w=2
2019-08-08: Chrome の LINE アプリがクラッシュする問題が再発。前回、リソースリミットを変更して直ったのは偶然だったのか?
2019-08-03: OpenBSD 6.5 amd64 用の chromium 76.0.3809.87 (野良ビルド) 置いた (2019-08-15 消した)
2019-08-02: https://marc.info/?l=openbsd-tech&m=156463894328592&w=2 なかなかおもしろいスレッドになった

2019-07

2019-07-31: OpenBSD 6.5 amd64 用の chromium 75.0.3770.142p1 (野良ビルド) 置いた (2019-08-03 削除しました)
2019-07-31: https://marc.info/?l=openbsd-misc&m=156438579905691&w=2 果たして返事はくるかな。
2019-07-27: OpenBSD 6.5 amd64 用の chromium 75.0.3770.142p0 (野良ビルド) (2019-07-31 削除しました)
2019-07-27: Slack の問題は、https://github.com/openbsd/ports/commit/4a42641e814314adf7f267cf5d5d81330f9cd40d で回避できるようで、上記バージョンで直った https://yasuoka.net/~yasuoka/images/42f147b7f4a0d2dc1a1d85b63feb8ffe.png
2019-07-24: Strava のアンケートに回答してみた。アンケートは https://jp.surveymonkey.com/ を使ってた
2019-07-24: その後の slack support チームから、あれ調べろこれ調べろとやりとりしている。簡潔なメッセージのやりとり、スピーディで無駄がない。ツールは https://www.zendesk.com/ を使っているっぽい
2019-07-24: slack の問題は "a known issue we're currently looking into" らしい。自分だけじゃないから、迅速に対応してもらえそうだ
2019-07-23: slack つながらない。webpack でエラーになっているので、最近の変更によるものか? https://twitter.com/yasuoka_m/status/1153449767864692736
2019-07-21: Wikimedia かお布施のお願いメールが来ていたので、お布施した
2019-07-04: JEP 254: Compact Strings、Java9 でも String クラスがリファクタリングされていました（JEP 254: Compact Strings 編） US-ASCII や Latin-1 で収まる場合は、UTF-16 だとスペース効率が悪くて不満だった、この実装なら、US-ASCII や Latin-1 で収まる人はぎっしり情報が詰め込める、というのはわかる。しかし、英文に続いて漢字を追加すると、英文部分に文字間の隙間を空けるためのコピーが発生する。これは、漢字などを使っている場合は従来より遅くなる、ペナルティを課されるようになった。つまり、CJK にはペナルティを与え、US(-ASCII) と Latin(-1) の効率を改善してるという印象を受けた。だったら最初から UTF-8 や EUC のほうが平和だった感じがする (自国第一主義的な時代背景と関係していなければいいけど)

2019-06

2019-06-30: OpenBSD 6.5 amd64 用の chromium 75.0.3770.100p0 (野良ビルド) 置いた (2019-07-27 消しました)

2019-06-30: Chrome の LINE アプリを便利に使っていたのだが、1 ヶ月ぐらい前から起動後やログイン中にクラッシュするようになってしまった

<--- Last few GCs --->

[13123:0xa034b844000]      153 ms: Mark-sweep 1.7 (3.3) -> 1.6 (3.5) MB, 3.7 / 0.1 ms  (average mu = 0.071, current mu = 0.071) memory pressure GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0xa0098a74539]
    1: StubFrame [pc: 0xa00989e9fce]
Security context: 0x13ac30ee43d9 <DedicatedWorkerGlobalScope map = 0x20fadfc86c19>
    2: /* anonymous */(aka /* anonymous */) [0x9df4ddee4b1] [chrome-extension://ophjlpahpchlmihnnnihgmmeilfjmjjc/src/TjxcO.js:1] [bytecode=0xfa58933a109 offset=2270](this=0x279394c404d1 <undefined>,0x09df4ddee9f9 <Object map = 0x20fadfc8ed79>,0x0faf73d94dc9 <JSGlobal Object>)
    3: /...

[13123:-1677910976:0630/152931.477318:FATAL:v8_initializer.cc(648)]

v8_initializer.cc:648 は、

644 static void ReportFatalErrorInWorker(const char* location,
645                                      const char* message) {
646   // FIXME: We temporarily deal with V8 internal error situations such as
647   // out-of-memory by crashing the worker.
648   LOG(FATAL);
649 }

このような感じ。これで out-of-memory だと思うのは早計だなと思いつつも data と memory のリソースリミットを解除して起動したら、無事起動。結果オーライ。

2019-06-30: chrome の更新が効いたのか、unlimit が効いたのかわからないが、facebook のとあるグループのページを閲覧してもクラッシュしなくなり、facebook のドキュメント編集も可能になった。これはよい！これで久しぶりに facebook twitter line slack すべて chrome に収容できる
2019-06-13: VAIO VJPK111 https://www.sony.jp/vaio-biz/products/PK11/spec/vjpk111.html
- Graphic は "Intel UHD 620" で、https://en.wikipedia.org/wiki/Intel_Graphics_Technology によれば、Kaby Lake, Kaby Lake Refresh と呼ばれる世代っぽい
- https://marc.info/?l=openbsd-cvs&m=155523690813457&w=2 対応済 or 非常に近いとこまで来てるかんじか
- 黒の 4K モデルは在庫切れ... シルバーも英字キーボードが在庫切れ..
2019-06-06: だんだん本格的になってきてしまった https://github.com/yasuoka/mleakdetect

2019-05

2019-05-17: 次のノートPC 選考中。VAIO を継続するかどうか。
2019-05-17: 古いやつが revert されてしまったけど、新しい ftp(1) https://github.com/openbsd/src/tree/6bc63e8c7a983d88fe87962098dc04877077b923/usr.bin/ftp libcurl の代わりに使えないかな
2019-05-06: 昔 iTune で買った楽曲を mplayer (smplayer) で再生すると、CPU100% となる。m4a で video 部分にジャケが入ってたりするので、それを削除すれば回避できる気がするけど、再エンコなしにいけるのかな... mplayer を直すってのもあるが、これはApple の呪いかもしれないので、iTune 時代のデータは全部削除して CD or Amazon MP3 で買い直すべきかもしれない
2019-05-04: lua でプログラム書くとテンションあがる
2019-05-04: fluent-bit も jsmn 使ってた https://github.com/fluent/fluent-bit/tree/master/lib/jsmn
2019-05-02: https://marc.info/?l=openbsd-cvs&m=155678582227264&w=2 は Android もバグってる

2019-05-02: PPPoE が 1 本だけ切れた。あやしい

May  2 18:46:06 stm0 /bsd: pppoe0: LCP keepalive timeout

2019-05-01: 令和初日
2019-05-01: ソフトウェアについての基本的な考えを、チームで共有して統一しておくのは非常に重要

2019-04

2019-04-30: 自宅無線 LAN 、少しひきこもった場所だと使い物にならなくなっていたたので、TPLINK Archer A2600 を購入。いまのところ快適
2019-04-27: https://github.com/zserge/jsmn が再び動き出した
- https://github.com/zserge/jsmn/pull/102 master では JSMN_STRICT じゃなくても問題ではじめたので、他からも苦情くると思われる

2019-04-27: PNG => PDF。余白をつけてまんなかあたりにレイアウトしたい

(サイズを調べ、上下左右に余白を作る)
% file hoge.png
hoge.png: PNG image data, 1225 x 639, 8-bit grayscale, non-interlaced
% convert -extent 1425x839 -gravity center hoge.png hoge_extent.png
%

(PDF に変換、+400 で縦方向のオフセットを指定)
% convert -page a4+0+400 hoge_extent.{png,pdf}
%

2019-04-24: VirtualBox で UUID {00000000-0000-0000-0000-000000000000} of the medium ‘/xxx/xxx.vmdk’ does not match the value {deadbeaf-0123-3210-1234-deadebaedead} stored in the media registry (‘/xxx/xxx/.config/VirtualBox/VirtualBox.xml’) で起動しなくなる問題が時々発生する。VBoxManage showhdinfo でステータスなどを確認できる。UUID にズレが生じているので、VBoxManage closemedium disk /xxx/xxx.vmdk としてあげればよい
2019-04-06: 6.4 用の chromium 73 はビルドできず、6.5 のリリースの間近なのであきらめる
2019-04-05: スラドの記事 NetBSD、メンテナンスの負担を理由にOpenBSD由来のファイアーウォールを廃止から引用されてた

2019-03

2019-03-30: pf 消すとか頭おかしい。むしろ他のやつ消してちゃんとメンテすべき。 http://mail-index.netbsd.org/tech-kern/2019/03/29/msg024883.html
2019-03-25: 台北のハッカソン t2k19 参加します
2019-03-22: asiabsdcon2019 3/23, 3/24 参加します！
2019-03-16: github で特定ディレクトリだけで通知を発生させる方法 https://stackoverflow.com/questions/7353538/setting-up-an-github-commit-rss-feed#comment85910414_7353586 個人 slack の RSS と組み合わせると、よい感じ
2019-03-15: OpenBSD 6.4 amd64 用の chromium 72.0.3626.121p0 (野良ビルド) 置いた (2019-06-30 消しました)
2019-03-13: 現在 CPU キャッシュとかそういうところ問題を調査中だが、Software optimization resources は素晴らしい
2019-03-13: さよなら、愛しのFreeBSD コメントいただいて気づいた
2019-03-09: Initial Benchmarks Of OpenBSD 6.4, DragonFlyBSD 5.3, FreeBSD vs. Linux
2019-03-09: amazon affiliate 2 回申し込んで 2 回落ちた
2019-03-09: ここに昔あった wiki.cgi へのアクセスが、最近も続いていて、もれなく ELF バイナリを 200 で返却していた... ソースコードは wiki.c
2019-03-07: unzip-*-iconv の件、sjis なファイルを展開するには unzip -O sjis じゃなく unzip -I sjis なの? どっかで仕様変わったんだろうか

2019-02

2019-02-23: もう半年ぐらい、そうなんだけど、chromium で Facebook をみると tab が crash するので、それを回避するためだけに firefox を使っている。crash するからには何らかの問題があるに違いないと思うけど、Facebook にも google にも報告するモチベーションはないので、スルーして直るの待ち
2019-02-23: USB イーサ購入。イーサは ure(4) として認識された
2019-02-16: mew の master-password は最初は使えるけど、なにかのタイミングから正しいパスワードを入れてもダメと言われるようになる。ソースコードを読んでみるのだけど、直せないのがつらい
2019-02-15: OpenBSD 6.4 amd64 用の chromium 72.0.3626.96 (野良ビルド) 置いた (2019-03-15 消しました)
2019-02-07: https://github.com/yasuoka/unescape

2019-01

2019-01-17: axen(4) を使うとハングする件で、pkt_count == 0 なら panic させてみる件は、
```
axen_rxeof(f004bcce3aed9acd,ffffff024d66a780,ffff8000022da000) at axen_rxeof+0x393
usb_transfer_complete(5219cf678302cae1) at usb_transfer_complete+0x1ed
xhci_event_dequeue(1) at xhci_event_dequeue+0xf7
xhci_softintr(a5543a73ce00a24e) at xhci_softintr+0x30
```
というスタックトレースとなる。xhci_event_dequeue => usb_transfer_complete なのは XHCI_EVT_PORT_CHANGE というイベントが発生したからだが、このイベントが、 axen の xfer 上で発生するのはおかしい。axen_rxeof が call されても buffer には uhub 用のデータが載っているようなので、pkt_count == 0 となっているようだ。axen_rxeof ならば、callback しないようにしてみた。 (2019-01-21 追記) XHCI_EVT_PORT_CHANGE じゃなく XHCI_EVT_XFER からの usb_transfer_complete() だった...
2019-01-10: メモるのを忘れていたが、どこかのタイミングから X 起動直後に固まる状態に陥る (キーボードは効かないが、電源ボタンは効く) ようになった。ims(4) を無効にすれば回避できる。(この問題がなくても ims(4) が有効だとタッチパッドに手があたってポインタが動いてしまって使いづらいので ims(4) は無効にしている)
2019-01-10: シングルユーザモードで savecore をバックグラウンドで動かしたのちマルチユーザモードに切り替えると、savecore の kernel の copy が unveil により失敗する。unveil の状態がマルチユーザモードに切り替えたことでリセットされてしまうのだと推測
2019-01-10: https://github.com/yasuoka/ubootenv 書いた (2019-01-12 追記) 最近の uboot は fat 上の uboot.env というファイルを読むっぽいので、uboot.env を作成するコマンドを作れば、 -boot を動かす前 (起動ディスクのイメージを作成する時など) に環境変数を設定できれば便利だと思ったが、
- uboot.env には環境変数全体を格納する必要があり、デフォルトを変更したいものを書けば良いという話ではない
- uboot.env のサイズは u-boot 内部の ENV_SIZE にしておく必要がある (CRC にも影響するので、正確なサイズを知る必要がある)
ということで、やりたいことはできないと判明した。ので撤退

2019-01-09: axen(4) を使うとハングする件は、pkt_count == 0 となるようような callback 連続で発生し、その後ハング。pkt_count == 0 の時に処理をスキップするだけでは治らないので、panic させてみることにした

diff --git a/sys/dev/usb/if_axen.c b/sys/dev/usb/if_axen.c
index 190bf2ecbc5..e3089a4900c 100644
--- a/sys/dev/usb/if_axen.c
+++ b/sys/dev/usb/if_axen.c
@@ -928,6 +928,8 @@ axen_rxeof(struct usbd_xfer *xfer, void *priv, usbd_status status)
        hdr_offset = (u_int16_t)(rx_hdr >> 16);
        pkt_count  = (u_int16_t)(rx_hdr & 0xffff);

+       KASSERT(pkt_count != 0);
+
        if (total_len > sc->axen_bufsz) {
                printf("%s: rxeof: too large transfer\n",
                    sc->axen_dev.dv_xname);
@

2019-01-09: 会社のネットワークはルーティングドメインをわけて接続することにした
2019-01-08: 生活用の vaio は -current と同期。Spleen フォント化してみた
2019-01-04: https://note.mu/yasuoka を作っておいた。使い途未定だけど
2019-01-04: 8 月下旬から ports@ の配送が止まっていたので、subscribe し直し & archive から復元
2019-01-03: 今年もよろしくお願い致します

トップページへ