mieki256's diary

Windows10 x64 22H2 をインストールしてあるメインPCが時々ブルースクリーン(BSOD)になるのが気になってる。ひょっとして、2つ積んでいる2.5インチSSDの温度が高くなった時に、SSDにアクセスできなくなってBSODになるのではないかと疑っているところ。

SSDは、製品によるだろうけど、高熱になると基板が熱で反ってしまって、上に半田付けしてあるチップ等が剥がれてしまって壊れる時があるらしい…。以前自分が使ってて突然死した SanDisk製SSDもソレが原因ではないかと疑ってるのだけど…。 *1 それはさておき。

2つのSSDは、3，5インチ内蔵ベイに、隙間が無い状態でみっちり入っているはずなので、冷却がほとんどできていないのではないかと…。PCケースのフロントFAN(12cm FAN)のすぐ後ろに配置できたら多少は冷えてくれるのではないか。しかし、そこに置くためのマウンタのようなものをどう用意するかで悩んでしまった。ガムテープの類でケース内部底面に貼り付けてしまう手もあるだろうけど、後からフロントFANを交換する時に苦労しそうだし、SSDは熱を出すからテープの類もベタベタになってSSDの見た目も汚くなるだろうと…。

ホームセンターでL型金具の類でも買ってきてどうにかできんかと考えたけど、ふと、タミヤ ユニバーサルプレートの余りを持っていることを思い出した。

_タミヤ 楽しい工作シリーズ　ユニバーサルプレート （2枚セット） | タミヤ
_タミヤ 楽しい工作シリーズ　ユニバーサルプレートL（210×160mm） | タミヤ

以前、Raspberry Pi を使って360度撮影ができないか実験していた時に、購入して、何枚か使って、残っているはず…。ソレを使ってどうにかできんか。

ということで、ユニバーサルプレートと、使っていない2.5インチHDDを、部屋の中から発掘して試してみた。


イイ感じかもしれない。ただ、プレート同士を垂直に繋げるためのアングルとやらを4本も使ってしまうのはもったいない気がする。しかも一本だけ長いし。コレが無いと、後でまた何か工作する際、余ってるプレートを垂直に立てたいと思った時に困ってしまうはず。どうにかプレートで作れないか。

そんなわけで、プレートをニッパーでプチプチ切って、Vesion 2.0 を試作。



イイ感じかもしれない。これなら、SSDを2つ入れても上下に隙間ができるだろうから、冷却も多少期待できるのではないか。

これをPCケースの底面に貼り付けたいけど…。マジックテープではどうだろう。それなら脱着可能になるし。それとも、何度も貼って剥がせると謳う魔法のテープ系の両面テープを使ったほうがいいだろうか。でも、それも熱でベタベタになりそうだな…。

---

Windows10 x64 22H2 を動かしてるメインPCが、やたらとブルースクリーン(BSOD)になる。困った。もしかしてBISOその他を更新したら改善されないだろうかと思えてきたので、そのあたりの更新作業をしてみた。

ハードウェアは、AMD Ryzen 5 5600X + GIGABYTE B450M S2H rev. 1.x。OS は Windows10 x64 22H2。

◎ BIOSの更新。 :

◎ チップセット、LANのドライバを更新。 :

◎ オーディオドライバを更新する段階でハマった :

Debian Linux 11 bullseye上で、プリンタ Canon iP4600用の公式ドライバをソースからビルドできそうか、途中まで試してみた。あくまで途中まで。昨日メモした内容と少し被るけど一応メモ。

• Canonのサイトから、cnijfilter-common-3.00-1.tar.gz を入手。
• tar zxvf cnijfilter-common-3.00-1.tar.gz で解凍。
• cd cnijfilter-common-3.00 でディレクトリの中に入る。

中に入ってた Makefile の内容は以下。

$ cat Makefile
#dirs = libs cngpij cngpijmon ppd pstocanonij
dirs = libs cngpij pstocanonij backend

scripts=for dir in $(dirs); do\
                        (cd $$dir; make $$target)|| exit 1;\
                done

all :
        $(scripts)

clean :
        target=clean; $(scripts)

install :
        target=install; $(scripts)

おそらく、以下のディレクトリに入って make を実行する処理になってるのだろう。

libs, cngpij, pstocanonij, backend

しかし、各ディレクトリには Makefile が入ってないので、実行してもエラーになる。代わりに、INSTALL, autogen.sh, configure.in, Makefile.am といったファイルが入ってる。

INSTALL には、各ディレクトリ内でのビルド手順が書いてある。大体は、./autogen.h を実行後、make と make install を実行せよと書かれてる。一部そうではないものもあるけど。おそらく、autogen.h を実行すると Makefile を作ってくれるのではないか。たぶん。

少しコンパイルした感じだと、ビルドには以下が必要になりそう。他に必要なパッケージがあるかもしれないけれど。

sudo apt install build-essential autoconf libtool libtool-bin automake libpopt-dev libppd-dev libppd0
sudo apt install libcups2 libcups2-dev libcupsfilters-dev libcupsimage2-dev
sudo apt install libpng-dev libpng16-16 libtiff-dev libtiff5 libtiff5-dev

各ディレクトリの中に入って試してみた。

./autogen.h
make

libs/, cngpij/, pstocanonij/ の中では autogen.h も実行できたし、Makefile も生成されたので make も実行できたけど…。

backend/ の中では、autogen.h は実行できたものの、make を実行したら cnij_backend_common.c のコンパイルでエラーが出た。ppd_file_t という型が見つからないらしい。

_#838972 - cups-filters: FTBFS: cupsfilters/colord.h:39:44: error: unknown type name 'ppd_file_t' - Debian Bug report logs

#include <cups/ppd.h> を追加すればエラーを回避できるっぽい。cnij_backend_common.c を修正。

$ diff -u src/cnij_backend_common.c.orig src/cnij_backend_common.c
--- src/cnij_backend_common.c.orig      2023-01-31 03:23:08.509470935 +0900
+++ src/cnij_backend_common.c   2023-01-31 03:23:52.809932769 +0900
@@ -39,6 +39,7 @@
// CUPS Header
#include <cups/cups.h>
#include <cups/ipp.h>
+#include <cups/ppd.h>

// Header file for CANON
#include "cnij_backend_common.h"

この状態なら make が通った。

後は、各ディレクトリの中で、sudo make install を実行すれば、生成したファイルが所定のディレクトリにコピーされていくのだろう。しかし、それをやって、システムが壊れたら怖いな…。

仮想PC上の Debian 11 bullseye 上で作業してみることにした。各ディレクトリ内で、前述の作業をして、sudo make install を実行。

想像だけど、前述の Makefile で作れるのは、ドライバの共通部分だけなのかなという気がする。iP4600に特化した部分は、別のディレクトリ内でビルドしないといけないのではなかろうか。それら別ディレクトリの中では、プリンタの型番を指定して autogen.h を実行するようだし…。

cngpijmon/ の中でコンパイルしてみる。

cd cngpijmon
./autogen.sh --program-suffix=ip4600
make

bjcupsmon_cups.c のコンパイル時に、大量にエラーが出てきた。以下、一例。

bjcupsmon_cups.c:224:17: error: invalid use of incomplete typedef ‘ipp_t’ {aka ‘struct _ipp_s’}
  224 |    if (pResponse->request.status.status_code > IPP_OK_CONFLICT) {
      |                 ^

bjcupsmon_cups.c:229:44: error: invalid use of incomplete typedef ‘ipp_attribute_t’ {aka ‘struct _ipp_attribute_s’}
  229 |      printerState = (ipp_state_t)pAttribute->values[0].integer;
      |                                  

ipp_attribute_t とか ipp_t という型がおかしいのだろうか。/usr/include/cups/cups.h の中で、ipp.h を include していて、ipp.h の中で件の型は定義されてるように見えるのだけどな…。

ここで手詰まり。すんなりとはいかないなと。そもそも、どのディレクトリの中身が必要になってくるのか、そこもよく分からない…。

某所のPCが起動しない云々の相談を受けた際、ひょっとして中に入ってるコイン型電池 CR2032 が切れかかっているのかな、だとしたら交換しないといかんなあ、と思ったのだけど。

考えてみたら、PCのM/B(マザーボード)に載ってるコイン型電池の交換って、地味に面倒臭いなと思えてきた。PCのケースを開けて作業するあたりが、まず面倒臭い。フツーの人なら「そんなことやりたくないよ…」と思うわな…。

どうして、PCは、本体ケースを開けずに電池だけ交換できる仕組みにしなかったのだろう。例えば、乾電池を使う電気機器って、本体ケースを分解しなくても、電池の蓋を開ければサクッと交換できるようになってるわけで。PCも同じ仕組みにしておけば良かったのに。

「数年は電池交換しないで済むんだからそのくらいええやん」って言われそうだけど。乾電池で動く時計だって数年は交換しないのに、ちゃんと電池の蓋があるわけで。

そう考えると、電池部分だけケースの外に出しておけるとか、3.5インチベイやPCIスロットに電池が置いてあるからケースを開けずに電池交換できるとか、そういう状態にできるPCパーツがあってもいいような気がする。

もっとも、そのためだけに1,000円〜2,000円を追加で払うかというと…。誰も買わないような気もしてくる…。

そもそも、そういうPCパーツって作れるのだろうか？ M/B上のコイン型電池の部分にアダプタを入れて、そのアダプタからケーブルが伸びていて、みたいな感じになるのだろうか。だとしたら、どういうアダプタを作ればいいのか。

コイン型電池のホルダーはよく見かけるけれど、ホルダーに入れるアダプタなんて目にしたことがないような気もする。そういうパーツを作れば、それはそれで、また違う場所で需要があったりするのだろうか。

いやまあ、普通は、ホルダーを外してピンヘッダをつける設計にしちゃうよな…。例えばノートPCに入ってるコイン型電池は、そんな感じで入ってるわけだし…。まあ、フツーのノートPCは、そのコイン型電池をわざわざM/B上に貼り付けてしまうあたりがおかしいけれど…。ノートPC裏面に電池の蓋をつけて、そこに配置すれば便利になるのに…。

もっとも、スマホやタブレット等、リチウムイオンバッテリーすら本体をバラさないと交換できない設計が増えてきているとも聞くし。コイン型電池の交換なんてますます無視されて当然なのかも。

2022/12/19を最後に日記をアップロードしてなかったのでアップロードしておいた。

炎上しそうな内容をうっかり書いてないか、そのあたり少し寝かしてから眺めてみないと判断がつかないもので、つい溜まってしまう…。