大澤です やや原因がわかってきました。 必ずというわけではありませんが、autofsを使ってFAT32ドライブにアクセスする のがいけないようです。
dosdisk -fstype=msdosfs,rw,-L=ja_JP.eucJP,-D=CP932,-l,-m=0777 :/dev/nvd0p5 としておいて、たとえば、 > cp abc.txt /mnt/dosdisk/<フォルダ名>/^D といった具合に ^D や TAB で補完を行うとかなり高い確率で panic します。 じゃあ対象となっている FAT32 ドライブに不整合があるのかというと、 Windowsを起動してCheckdiskを行ってもエラー無しで修了するので、 そういうわけでもなさそうです。 backtrace を見ると、iconv_convchr_case で trap が呼び出されているので、 このあたりですかね。 だとすると autofs を使わずに、mount_msdosfs で直に mount しても 同じことになりそうなので、 いわゆる2バイト文字を使わないのがさしあたりの回避方法ということに なってしまいますが。 KDB: stack backtrace: #0 0xffffffff80c4ee95 at kdb_backtrace+0x65 #1 0xffffffff80c02822 at vpanic+0x152 #2 0xffffffff80c026c3 at panic+0x43 #3 0xffffffff810bc079 at trap_fatal+0x389 #4 0xffffffff810bc0cf at trap_pfault+0x4f #5 0xffffffff81093618 at calltrap+0x8 #6 0xffffffff83019455 at iconv_convchr_case+0x75 #7 0xffffffff8301a714 at iconv_ucs_conv+0x124 #8 0xffffffff83019455 at iconv_convchr_case+0x75 #9 0xffffffff80a98078 at unix2doschr+0xf8 #10 0xffffffff80a97a0f at unix2dosfn+0xdf #11 0xffffffff80a9be16 at msdosfs_lookup_ino+0x176 #12 0xffffffff80cc366e at vfs_cache_lookup+0xae #13 0xffffffff80cd154d at lookup+0x44d #14 0xffffffff80cd078a at namei+0x24a #15 0xffffffff80cf60d4 at vn_open_cred+0x504 #16 0xffffffff80cec09f at kern_openat+0x26f #17 0xffffffff810bc950 at amd64_syscall+0x110 大澤 On Sat, 25 Nov 2023 11:39:14 +0900, Hisao Osawa <osawa.hi...@tbd.t-com.ne.jp> wrote: > > 大澤です > > ありがとうございます。 > シングルユーザーモードで fsck をかけてみたのでしばらく様子を見てみます。 > 今週月曜日はひどかったのですが、だんだん頻度が下がってきているようなので、 > panic のたびに実行される fsck が効いてきているのかもしれません。 > > > > On Fri, 24 Nov 2023 08:54:58 +0900, > moto kawasaki <m...@kawasaki3.org> wrote: > > > > > > 川崎と申します。 > > > > > Nov 22 11:18:28 Mintaka kernel: panic: ffs_freefile: freeing free inode > > > > freeing free inode でパニックしたと言っているようなので、ファイルシス > > テム(ufsをお使いですよね)内に矛盾が起きているということではないでしょ > > うか。もしそうなら、シングルユーザモードに落としてfsckをかけてみると良 > > いと思います。 > > > > 外していたらごめんなさい。 > > > > -- > > moto kawasaki <m...@kawasaki3.org> +81-90-2464-8454 > > > > > > > > >