大澤です

やや原因がわかってきました。
必ずというわけではありませんが、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
> > 
> > 
> > 
> > 
> 

Reply via email to