うへえ><
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
SJ3 2.0.1.20はポインタをintにキャストする箇所があった(pkgsrc由来のパッチで修正済み)ので、希少なILP64をNEWS-OSが採用していたのでもない限り、Sonyが公開しなかった64ビット版の差分があると思われる。
https://github.com/FUJIMI-IM/sj3/commit/89151996c6a8936d7db0f9a2da504a248e8f0684
でもお皿洗って考えてたけど、寝た子を起こす…ではないが問題が無ければ放置というのも一案なのかも。32bit, 64bit環境でwarningが出なければヨシ!なアプローチ。
EFI領域をどんだけ取るかっていうのはまた難しい問題ではあるよね…自分は512MBくらいとってる感じなんだけど多分。
(IDEの1024シリンダ制限回避のため、8.4GB以内に色々置けるよう/bootを用意するって理解してる)
一区画に全部放り込むので/bootのみ割り当てるとかやらないんですが…やっぱダメですか…
このアカウントは、notestockで公開設定になっていません。
…ってふと思うんだけど、何故ここまでコードの整理に熱くなってるんだろう自分。別に良いんだけど。
sj3、int, long, longlongの混在があるのでこの辺の整理も多分要る。
ILP32/I32LP64であればint, longlongはそれぞれ32bit, 64bitなのははっきりしてるんだけど…longの解釈が32bit/64bitで変わるし。
32bit環境もそれなりにパワフルだし、ってことを考えるとlong, long longをint64_tに置き換えちゃうのが一番手っ取り早いのかも。
NEWS-OSの64bit版ってあるのかなっておもったら、NWS-7000が64bit機なのであるっていう理解で良い? https://goodoldbits.wordpress.com/2016/08/18/news-11-nws-7000/
なるほど先人たちがメンテナンスをぶん投げる気持ち、ほんっとーによく分かったわ💢ということがよく分かった。
ちょっともんにゃりした内容のPR投げちゃってます。問題があったらそのままcloseしておいてください…
DOSBox-XでPC-9801のDOSエミュレーションをやらせて、DOS時代のFEPをというのは気になるところだけどこれもこれで荷の重い話なんだよなというか…ああそーいやportsまとめないといけないんだった(DESCRを書き直せって言われて放置してた)
Linux版ATOKガアアアアッって話が流れていたけど、VJE-Deltaとかどうなんだろう。こっちも厳しいのかな。
今みたいにコーディングスタイル(ルール)がそれほど厳しくない時代で、複数人でつくったとかそんな感じの印象がありますな。u_char/unsigned char/Ucharの混在とか見てると。
単にEmacsで各ファイルに対してreplace-string "register "→""をしただけなので阿呆なことにはなってないはずなんだけど…とにかく量が多いのでチェックが面倒かも。ビルドは通ってるし、ヘンなところまではいじっていないと思います…
土曜のお昼に仕事上がって、帰り道に飲むかーってなるとあんまり飲めるお店って無いんだよね。ファミレス飲みが一番手っ取り早いかな?
fuzoku.cのsrchszk()に付いてる(ほんと、K&Rスタイルは滅ぼしたくなりますね…)
sj_typedef.h、RECURSなる宣言あるけどこれって「この関数は再帰してます」を示すための物か…?
なんか辞書周りはu_char, u_shortを、辞書とか下回りがunsigned char, unsigned short使ってる感じ。
@omasanori unsigned charとu_charの混在はまだ良いんですが、わざわざコード内でUcharとか指定するのは流石に意味無くないっすかと思いまして…
読みにくい名前なぞ滅んでしまえ…💢、という気分になることは割と多いですね。どういう場面でそうなるかはすみません伏せさせてくだしあ…
(メーカー公式の読み方があり決着が付いているとはいえ)ASUSは未だに「あすーす」とか「えいさす」と読んでしまうことが…
最近はi18nとかl10nとかを前ほどあんまし言わなくなった気がする(k8sのtootを見て思い出した)
SFINAEって、すふぃねーなのか。すふぃなえって読むもんだと(埋まってきます
dancyu、自分の感覚では「だんきゅー」以外ありえないんだが。
dancyuが読めないんだよ。だんちゅー、だったと思うけど…cyuをちゅー読みするのはマジあり得ない。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Z80は「ぜっとはちまる」(「ぜっぱち」だとZ8があるので、自分は避けてる)…海外だと「zi eitee」みたいな発音だっけ?
x86って、「えっくすはちろく」ないし「ぺけはちろく」じゃないのか…?
このアカウントは、notestockで公開設定になっていません。
なんでもかんでも発音しづらいと思う。というか「それ読めないの?だっさwww」するために難読化してるんじゃないか疑惑。
IT用語知らないと発音できないランキング不動の1位はnginxだと思うけど、知ってても発音しにくいランキングだと何でしょうね
register潰しはこれで良いはずで(もう一回確認したら上げます)…って、sj_typedef.h見てるとVoidだのUcharだのも潰したくなるな。大体何故同じコードの中でu_charとUcharが混在すんだよ💢ってなる。その辺の整理がつけば、extern func()でなんかやってるプロトタイプ宣言周りのwarning潰せて、K&R→ANSI化への道筋が付くと思うんだよなあ。
@omasanori warning潰しもきになるんですが、そこ行きましょうか…
こっちで聞いちゃった方が早いから聞いちゃうけど(でもissue立てた方が良い?)、イマドキの環境で動かすならregister宣言とかざっくり削った方が良い?
なんせ、Debianでもコードのビルドに困る時とかあるんだもん。Archならイケる時があるとか…そういうのを経験すると、自分の使い方にはLTSは向いてないなーって。
@hadsn 使うアプリが決まり切っていて、あんまり頻繁にアップデートしたくないって向きにはLTSはお勧めなんでしょうけど…触ったことのないアプリを色々を試したいとか、ライブラリも最新のが無いと困るとか開発用に使いたいといったケースだとむしろLTS避けろって感じな気がします。
LTSって昔某untuのLTSでソフト旧すぎ動かなすぎっていうのを経験したのであんまり信用してない。OS自体は対応してても取り巻き(アプリ)のアップデートがいまいちなんだもん…って、今のLTSはそれなりにちゃんとしてると思いたいんだけど。
一度ダークモードに目が慣れてしまうと、なんかライトモードに戻した途端眩しくてたまらない…(と書いておきながら、OpenBSD側はライトモードのままでも違和感なく使えているのは何故)
@omasanori 個人的には-Wallだけで十分な気がしますが、-Wextraは当面付けておいた方が良いかもしれません。64bit環境の無い頃のコードでlongを素で使っているため、それに絡む問題を炙り出せるようにしておきたいです。
ごめん、自分の頭だとこのオプションを外す以外に選択肢見当たらない…
なんかを内包してる訳じゃないけど、「const宣言を注意深く使っているコードならともかく、そうでなければ面倒なだけ…なので-Wallにはこれを入れてない(意訳)」らしい。
一旦-Wwrite-stringsを切ってビルドを試してみるよ。
-Wwrite-strings
When compiling C, give string constants the type const char[length] so that copying the address of one into a non-const char * pointer produces a warning. These warnings help you find at compile time code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it is just a nuisance. This is why we did not make -Wall request these warnings.
ソースの整理とかデバッグのために現状は警告オプションを厳しくしているところがあると理解していて、-Wwrite-stringsを切れば-Wincompatible-pointer-types-discards-qualifiersに関しては静かになってくれる。とはいえ、-Wwrite-stringsが他にどんなオプションを内包してるかを調べないといかん…
-Wincompatible-pointer-types-discards-qualifiers潰し、大抵はconst追加するケースになるんだろうけど…不用意にconst追加するとあっちもこっちも追加でconstってケースになって収拾つかなくなるし、意図しないトラブルの原因になるのでちょっと厄介かも。
一晩考えてみたけど、さっきやった作業は一旦破棄して(参考にはする)、やり直しで。
execute.cのrmemcpy()の引数が曲者だな。memcpy(dst, src, len)をわざわざrmemcpy(src, dst, len)にしてる(これのおかげで今までの作業が…)
-Wincompatible-pointer-types-discards-qualifiers
こういう作業は始めると止まんなくなっちゃう(そして眠れなくなる)ので今日はちょっとここで止めちゃいますね。流石に色々やりすぎてテンションが…
level1.c:52:7: warning: initializing 'char *' with an expression of type 'const
char [13]' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers
]
char *sj3_socket_name = SocketName;
これどう直したもんだろう。領域の書き換えがあるならchar sj3_socket_name[]になるし、無いならconst char *sj3_socket_nameだし。const突っ込んで、ダメなら[]の方でという方針でいく?
手っ取り早く治せる、brace周りの修正は早速やって…他の問題どうしよう…(悩
sj3_getkan_eucの
while (*src) {
bun->srclen = *src++;
memcpy(&(bun->dcid), src, stysiz);
src += stysiz;
bun->destlen = strlen(src);
bun->srcstr = yp;
bun->deststr = kp;
while (*src)
*kp++ = *src++;
knjsiz -= bun->destlen;
src++;
yp += bun->srclen;
bun++;
buncnt++;
}
ここでknjsizが負になる可能性はあり得るんだろうなあ…であれば、intによるキャストも「アリ」か?
sj3lib.c:460:14: warning: comparison of integers of different signs: 'int' and '
unsigned long' [-Wsign-compare]
if (knjsiz > sizeof(kbuf)) {
は結構直すのがヤな感じですよねえ。安直にsizeof()をintでキャストするしかないのかなあ。
https://github.com/FUJIMI-IM/sj3
./configure; make; sudo make install できるようになった。 #SJ3 #InputMethod
@hadsn 丸亀最近行ってない…うどん+おにぎりとか、ちょっとしたプラスアルファが嬉しいお店。
自分とこのweb日記はISO-2022-JPだったけど、ある時期を境に全部UTF-8化してます。grepで検索するのが楽になった反面、「当時物の記録」の正当性は失われてますね…
このアカウントは、notestockで公開設定になっていません。
(あっちの舞台裏をこっち(Mastodon/Nostr)で書くのは、こっちにとって無礼を働いてるっていう自覚はあるんだけど…あっちで書いてもねーというのは、あるし。某氏のように今でもPC-9801のドライバについて淡々と語るだけという境地にたどり着いていないので、自分もまだまだだなーとは思います。)
あの話はあっち側に書きたくないのが本音なんだけど、パフォーマンスを打っておかないとそれはそれで面倒なことになるというのもあって。
もはや滅ぶか滅ぼすかという戦いをやるしか無いってことですね…
このアカウントは、notestockで公開設定になっていません。
商売は信用第一、払った分に見合うものが手に入るという信用があるから取引が成立すると理解してるんだけど…
結局採用された人間が信用できないから安く使い潰すとか、そもそも採らないとか、そういう方向になるんだろうね。使える人材として採ったつもりが使えない→それを選んだ人間が叩かれるのは嫌だから採られた人間を(安く)叩くとか。
相互不信の行きつく果ては貧困とモラルハザードという結論を出したくなるんだけど、もうそれでいいよね?(ちなみにそれに対する処方箋なんて、無いからね?落ちるところまで落ちるから)
このアカウントは、notestockで公開設定になっていません。
こーゆうののデバッグって、やっぱりリモートデバッグが主体になるんですかね?入力部分(fcitx)を動かすマシンと、リモートでその動きを監視するマシンで。
このアカウントは、notestockで公開設定になっていません。
vlanceのテスト用フロッピーディスクイメージ、ブートセクタ以外を0x40で埋めるか0xe5で埋めるかは悩んだんですが0xe5にしました。松下系MSXだと0x40、SONY系MSXだと0xe5というのはよく知られている話ですよね?
TBSラジオを聞いてるけど、あんまり季節感のあるコマーシャルが無いような。10~20年くらい前だと年末感がそれなりにあったと記憶してるんだけど。
アマチュア無線局の再免許申請なるものをさっき片づけたけど、免許番号と他数項目、あとは「はい」「いいえ」形式でほぼ済んだのでとっても楽だった。ほんと、こういう感じで片付く申請書じゃないものは滅ぼした方が良いよね。
このアカウントは、notestockで公開設定になっていません。
さてと、vlanceの件は然るべき人に投げよう。これ以上はこちらの領分じゃない。
…へぇ、pastebinは地味にダークモード対応してるじゃん。
VMware Player 17.5のvlanceをクラッシュさせる手順、こういうコード書けば多分誰もが理解してくれるよね…?ブートセクタ上に再現手順をアセンブラで突っ込んでるけど、これ以上簡単な再現手順は思い付かない。 https://pastebin.com/nakTrnCx
久々にMMDVMHostのビルドを試してみたけど、何故またlibsamplerateなんてものを使うことになってるんだか…? https://github.com/g4klx/MMDVMHost/pull/786
結局LuckFoxはPico Plus M(RAM 64MB, pre-soldered header)を注文してみた。流石にPro(128MB)/Max(256MB)は高いし、その辺りは必要になった時で良いのかなーって。 https://www.luckfox.com/Mini-PC/Luckfox-Pico/EN-Luckfox-Pico-Plus
まさか令和の時代にbcc(Bruce Evans' C compiler)を使う必要が出るとはな…!
BMS> ih 0x2014
Port 2014:H --> 0000
BMS> iw 0x2018
Port 2018:W --> ffffffff
BMS> ow 0x2010,0
Port 2010:W <-- 00000000
BMS> ow 0x2014,0x14
Port 2014:W <-- 00000014
BMS> iw 0x201c
Port 201c:W --> 00000200
BMS>
BMS> iw 0x2018
Port 2018:W --> 00000000
BMS> ow 0x2010,0
Port 2010:W <-- 00000000
BMS> ow 0x2014,0x14
Port 2014:W <-- 00000014
BMS> iw 0x201c
おっけ、再現手順分かった。二度リセットすると死ぬ。こんなの実機じゃあり得ない。
2023-12-07T01:07:19.565Z In(05) vcpu-0 VLANCE: Switching to 32bit I/O
2023-12-07T01:07:58.830Z In(05) vcpu-0 VLANCE: OUT on LANCE_CHIPID0: word: 0x0
2023-12-07T01:08:33.150Z Wa(03) vcpu-0 VLANCE: Wild write to CSR20. Assuming broken linux pcnet32 driver
2023-12-07T01:08:33.150Z In(05) vcpu-0 VLANCE: OUT on LANCE_CXBAL while not stopped: 0x4, word: 0x0. Write ignored.
broken linux32 driver…余計なお世話だ💢というのはともかく、linuxでしか動作確認してないってことかい。
それあくまでもVMwareの問題であって実機側じゃ問題無いんだし、知らんがなという話だったりするのでは…?もうちょい突っついてみないと何とも言えないけど。
二度目のリセット以降に再度CSR0の書き込みを行うと二重登録か何かで死ぬ、ってパターンかなあ。WIO/DWIOという問題ではないのかも。
iw 0x2018による二度目のリセット以降、動作がおかしくなってる。実機だと多分起こらないはずなんだけど。
あと、BCR20の設定値については突っ込まないでください。
ih 0x2014
iw 0x2018
ow 0x2010,0
ow 0x2014,0x58
iw 0x2010
iw 0x2000
iw 0x2004
ih 0x2014
iw 0x2018
ow 0x2010,0
ow 0x2014,0x14
ow 0x201c,0x103 ←ここで死ぬ
ow 0x2014,0x50
iw 0x2010
qemu-system-i386 --trace help|less
(ry
pcnet_s_reset
pcnet_user_int
pcnet_isr_change
pcnet_init
pcnet_rlen_tlen
pcnet_ss32_rdra_tdra
pcnet_aprom_writeb
pcnet_aprom_readb
pcnet_ioport_read
pcnet_ioport_write
(ry
…なぜ今までこれに気づかなかった>自分
Allwinner H618周りはなんか色々動き出してるみたいだし、こちらでそれ関連の(baiduとかから落とした)ファイルを持っておく必要はもう無いかな…消そう。
VMware Player 17.5になってからなんかトラブル多い気がするのは自分だけかなあ。Linux仮想マシン、ネットワークからリモートでログインする分には問題ないんだけど…ホスト(Windows)上に表示させたデスクトップ、キー入力のレスポンスが悪いとかキー入力に反応しないといったことがよく起こっていて。
SSH接続が通るからといって裏でsshが動いている保証はない(dropbearとか他のソフトウェアかもしれないし)というのは良い教訓になったけど…この問題で相当な時間使ってたんだよなあ。
「なんかいつの間にかssh -YでX11 Forwardingが効かなくなってるんですけど?」ってなって全然解決方法が分からなくって。で、先ほどのに戻る訳で。
dropbear…お前だったのか💢
dropbearの名誉のために書いておくと、きちんと設定すればdropbearでもX11 Forwardingはできるみたいなんですよね(その設定をしていないのでできていなかっただけなんですが) https://qiita.com/z80oolong/items/7bdfc322fa586f5d4a30#%E6%8E%A5%E7%B6%9A%E5%85%83%E3%81%AE-homesshconfig-%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B
dropbear…お前だったのか💢
ssh -Y remotehostでXセッションが繋がらず、リモートホストの/etc/ssh/sshd_configをいくら見直しても解決しない原因を作り出していたのは💢💢
でも壁紙暗くすると今度はアイコンが眩しくなるのでやっぱりある程度明るい壁紙じゃないと鬱陶しいのかも(デスクトップ整理しろ、なのかもだけど)。
ダークモードが好きなんじゃなく明るい画面が好きじゃないだけ(color 15,4,7の民が何を言う)
Windows11の背景色、過去にblackbox使ってた頃にxsetroot -solid "#2c2c2c "を設定していたのでこれを持って来てみたけど、引き締まった感じが良くてもダークモードなウィンドウの色と壁紙との区別を付けにくいのがなんとも。
とはいえWindowMakerと同じ#505075にしてみたんだけど …良くも悪くもない感じ。日頃mltermで設定している#000060との相性は凄く良いんだけどね 。
という訳で、壁紙は#000060にしてみました (何故)
前々から、なんか自分のデスクトップがちぐはぐだなーと思っていたんだけど…アプリとOSをダークモードにしても、壁紙がこうも明るいとそりゃあ眩しいよねって。
X6って色々機種出てくるけど、今だとOPPO Find X6なのかなあ。
@reasonset スマホは落とす物・壊すものという認識なのでハイエンド機を買う度胸が無いんですよね(その辺がアガらない原因なのかも)
新しいスマホは気分がアガ…らないんですよね、あんまり。PCだと結構アガるんですけど。スマホの場合は必要だから筆記具を買いましたみたいな感覚になるのに対して、PCの場合だと新しいオモチャを買いましたという感覚になっているんだと思います…自分の中では。
Fedilabいいですね。有償ですが有償なだけの勝手の良さはあると思う。
スマホ(サブ機)の移行はおしまい。電源ボタンがヘタったせいで電源が入りにくいしオクトラ大陸の覇者が異様に重くなった→壊れる前に対策しておくか、という理由で買い替えたんですが…折角壊れたスマホが手に入ったので、捨てる前に分解・修理の練習台にしてみましょうかね?なんてことを考えています。
TwidereをMastodonクライアントとして使ってるけど、Android13での動作実績ってあるのかな(なんか不安定な感じがあって)。
Fedilabへ移行しようか検討中。
そもそも、オタクが自分の活動のことをいちいち「オタ活」とか言うんだろうか…
UV-K5なる(ファームウェアの解像が流行っている)無線機も気になるところだが…あれこれ手を広げるのもどうなんだか。
なるほど?RV1103は512Mbit(64MB)のメモリを載せていて
https://www.aliexpress.com/item/1005006040593450.html
RV1106は128MB/256MBのモデルがあると。
https://www.aliexpress.com/item/1005006083739388.html
どうしたもんかな。
「空気を読め」で手を汚さずに言論封殺できますよね。その手を積極的に使ってきた人達が幅を利かせたおかげでこのご時世が成り立っていると理解しています。※個人の感想です
2023-12-05T12:05:08.315Z Wa(03) vcpu-0 IOSPACE: unreg. non-registered port 0x2016
2023-12-05T12:05:08.315Z In(05) vcpu-0 IOSPACE: 2nd registration for port 0x2018 (Lance reset), old 0x7ff68ca1b100 user, new 0x7ff68ca1b100 user
2023-12-05T12:05:08.315Z In(05) vcpu-0 IOSPACE: 2nd registration for port 0x201c (Lance BCR), old 0x7ff68ca19bd0 user, new 0x7ff68ca19bd0 user
…ん?
2023-12-05T12:04:29.254Z In(05) vcpu-0 VLANCE: Switching to 32bit I/O
2023-12-05T12:04:30.034Z In(05) vcpu-0 VIDE: Already in check condition 02 3a 00
(ry
2023-12-05T12:05:08.314Z In(05) vcpu-0 VLANCE: Switching to 32bit I/O
2023-12-05T12:05:08.314Z Wa(03) vcpu-0 IOSPACE: unreg. non-registered port 0x2012
でもこれ自分のお仕事じゃないし、とぶん投げても良いのかもしれない。不便なのは確かだし何とかしてほしいのも事実なんだけど…興味ドリブンで動ける範囲にも限界があるからね。
とりあえずWIO/DWIOモード周りの問題ってことは分かっているはず…多分そうなんだと思う…として、vlanceが何をしてほしくないのかというのはもう少し洗ってみる必要があるのかなあ。
0x108e76~0x1098dbの範囲に、in (%dx),%axは二か所あったとして…out %ax,(%dx)は全くないんだよね。単に16bit I/Oを潰せば良いって問題にはならない?
0x66, 0xed→0xeb, 0xfeで引っかけてみた感じでは
109831: 66 ed in (%dx),%ax
109026: 66 ed in (%dx),%ax
この二か所はどちらとも引っかかる。つまり実行パスに入ってる(そしてVMware Playerがゴネることもない)。
0xeb 0xfeが 0: jmp 0b…無限ループになるので、こいつで引っかけてみるか
一番目、二番目共に潰してもダメ…そこのロジックを通ってるか、なんかチェックする方法があればそれで見てみる必要があるかな
二番目はoffset 0x905bを0xed→0x90にして、2byte NOPにすれば良いかな。
0x00108e00~0x108e75に違うコントローラのエントリポイントがあって、0x001098dcにこのコントローラのエントリポイントがあるみたいだから…なんとなく、この間が怪しいと見てる。んでもって、in (%dx), %axがあるのは2か所か…最初に見つけた場所(0x109831)が間違いなら、二番目に見つけた場所(0x109026)を潰したらどうなるかなあ
この辺も怪しい?
109020: 8b 55 fc mov 0xfffffffc(%ebp),%edx
109023: 83 c2 14 add $0x14,%edx
109026: 66 ed in (%dx),%ax
109028: 8b 55 fc mov 0xfffffffc(%ebp),%edx
10902b: 83 c2 18 add $0x18,%edx
10902e: ed in (%dx),%eax
とりあえずシステムファイルの圧縮を解いて、バイナリパッチを当てることができる状態までは確立できたか。パッチを用意できるかどうかはまた別の話ってことで。
元のファイルは圧縮がかかっているからこれをどうにか解いて、得られたファイルのoffset 0x9861を14→10, 0x9865の66, edをef, 90か。objdumpでも
10982b: 8d 56 10 lea 0x10(%esi),%edx
10982e: 83 c4 08 add $0x8,%esp
109831: ef out %eax,(%dx)
109832: 90 nop
うん、意図した通りになってる。
10982b 8d 56 14 lea 0x14(%esi), %edx
↓
10982b 8d 56 10 lea 0x10(%esi), %edx
109831 66 ed in (%dx), %ax
↓
109831 ef out %eax, (%dx)
109832 90 nop
これ試してみようか?
109826: e8 fc ff ff ff call 109827 <_init-0xf67d9>
10982b: 8d 56 14 lea 0x14(%esi),%edx
10982e: 83 c4 08 add $0x8,%esp
109831: 66 ed in (%dx),%ax
109833: 8d 56 18 lea 0x18(%esi),%edx
109836: ed in (%dx),%eax
109837: 68 e8 03 00 00 push $0x3e8
この辺か?
もしかするとあれかな、VMware Player上のvlanceが何かの拍子にDWIO modeが解除されるバグか何かがあって、それに対処したが故に問題が起こったのかなあ。
Linux最古のpcnet32.cを見るに、チップのプローブで8bitアクセスは使っているけど16bitアクセスは未使用… https://elixir.bootlin.com/linux/2.0.34/source/drivers/net/pcnet32.c#L271
詳細はAm79C973/Am79C975データシートのSoftware Access→Word I/O mode, Double Word I/O modeの項を参照。
16bit modeでなんかやって、RDPに32bit幅で書き込むと自動的に32bit modeになるんだけどその後のアクセスは32bit単位でやらないとダメとかそういう対処法が必要になるのかも。
これすっごくやらしくて、最初に16bit accessせずに0x2010に0(32bit)書いた後16bit readするだけでは再現しないという…
[/SYS/WORK]% iodump h 2000 201f
2000: 0c00 4729 fc2b 0000 1100 0000 0262 5757
2010: 0004 ffff 0000 ffff 0000 ffff 0005 ffff
[/SYS/WORK]% #ow 0x2010,0
Port 2010:W <-- 00000000
[/SYS/WORK]% iodump h 2000 201f
2000: 0c00 4729 fc2b 0000 1100 0000 0262 5757
2010: 0004 ffff 0000 ffff
vlanceの16bit/32bitモードに絡む問題っぽいな
2023-12-03T13:32:46.188Z In(05) vcpu-0 IOSPACE: 2nd registration for port 0x2018 (Lance reset), old 0x7ff7d662b100 user, new 0x7ff7d662b100 user
2023-12-03T13:32:46.188Z In(05) vcpu-0 IOSPACE: 2nd registration for port 0x201c (Lance BCR), old 0x7ff7d6629bd0 user, new 0x7ff7d6629bd0 user
2023-12-03T13:32:46.188Z In(05) vcpu-0 MsgHint: msg.monitorEvent.14552
2023-12-03T13:32:46.188Z In(05)+ vcpu-0 *** Access to misconfigured virtual devices ***
…ん?
2023-12-03T13:32:46.185Z In(05) vcpu-0 VLANCE: Switching to 32bit I/O
2023-12-03T13:32:46.188Z In(05) vcpu-0 VLANCE: Switching to 32bit I/O
2023-12-03T13:32:46.188Z Wa(03) vcpu-0 IOSPACE: unreg. non-registered port 0x2012
2023-12-03T13:32:46.188Z Wa(03) vcpu-0 IOSPACE: unreg. non-registered port 0x2016
@hadsn 多分jiskan16辺りを強引に縮小してたんだと思う、WindowMakerのアレ。
このアカウントは、notestockで公開設定になっていません。
@hadsn あの時代、日本語が出るだけでもありがたいとかそういう時代だったので…(震え声
WindowMakerなら一応動いてる感じ。書体が汚いのはまあこんなもんか…
VMware SVGA-IIの機能というよりはXFree86ドライバの作りとして多分なんかあるんだと思います(拙作のvmxscreenだとホストの色数≠ゲストの色数はできてます)。
@whtapple ちょっと古い環境を調べてみたくなったもので…
@hadsn ありがとうございます!これで当時の環境を色々探ることができそうです。
XFree86のvmwareドライバ、ホストの色数とゲストの色数が揃っていないと動かないようです(エラー発生時にそうメッセージが出てる)。
Vine Linux 2.5 on VMware Player 17.5…どうにかここまで来ました。
日本の大手メーカー製のPCって(自分が前職で相手にしてた時は)あんまりBIOSに期待できない、っていう認識だったんだけど…今でもそうだとしたらやっぱり日本の大手メーカー製のPCは買うもんじゃないねーということになりそう。
このアカウントは、notestockで公開設定になっていません。
open-vm-toolsでのFreeBSD向けif_vxn(4)、10.2.xまでの対応か。10.3以降ではなくなってる。 https://github.com/vmware/open-vm-tools/blob/10.2.x/open-vm-tools/modules/freebsd/vmxnet/if_vxn.c
Linuxのvmxnetについては、10.1.xまで。 https://github.com/vmware/open-vm-tools/tree/stable-10.1.x/open-vm-tools/modules/linux/vmxnet
VMwareのサポートへ問い合わせようにも、なんかメールアドレス無効化したから違うサポートへ聞いとくれとか言われてるんだけど…どうすれば良いんだこれ。
いやそもそもこういう調査って今やるタスクじゃない気がする。これは他の人がやっているはずのタスクだし…?
ってことは、vlanceの作りからすると…index→dataレジスタのアクセスなので意図しないindexを指定したアクセスでもやってるのか。
if_vic(4)のソースを見るに、vlanceでもBAR0+0x20にあるレジスタ(vlanceの場合は0x2934になってる)に0x4392を書くとvmxnetモードになるんだけど…意図せずにvmxnetモードになってる訳じゃない、ということは確かそう。 https://github.com/openbsd/src/blob/master/sys/dev/pci/if_vic.c#L56
[/SYS/WORK]% iodump w 2000 207f
2000: 47290c00 0000fc2b 00001100 57570262
2010: 00000004 00000000 00000000 00000005
2020: 00002934 ffffffff ffffffff ffffffff
2030: ffffffff ffffffff ffffffff ffffffff
2040: ffffffff ffffffff ffffffff ffffffff
2050: ffffffff ffffffff ffffffff ffffffff
2060: ffffffff ffffffff ffffffff ffffffff
2070: ffffffff ffffffff ffffffff ffffffff
[/SYS/WORK]%
[/SYS/WORK]% iodump h 2000 207f
2000: 0c00 4729 fc2b 0000 1100 0000 0262 5757
2010: 0004 ffff 0000 ffff 0000 ffff 0005 ffff
2020: 2934 ffff ffff ffff ffff ffff ffff ffff
2030: ffff ffff ffff ffff ffff ffff ffff ffff
2040: ffff ffff ffff ffff ffff ffff ffff ffff
2050: ffff ffff ffff ffff ffff ffff ffff ffff
2060: ffff ffff ffff ffff ffff ffff ffff ffff
2070: ffff ffff ffff ffff ffff ffff ffff ffff
[/SYS/WORK]%
[/SYS/WORK]% iodump b 2000 207f
2000: 00 0c 29 47 2b fc 00 00 00 11 00 00 62 02 57 57
2010: 73 ff ff ff 00 ff ff ff 00 ff ff ff 05 ff ff ff
2020: 34 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[/SYS/WORK]%
そもそもvlanceが死んでる状態のレジスタダンプを取ってないな…
[/SYS/WORK]% iodump w 2000 203f
2000: ffffffff 00000000 ffffffff 00000000
2010: ffffffff ffffffff babe864f babe864f
2020: 00000001 ffffffff ffffffff ffffffff
2030: 00000020 ffffffff ffffffff ffffffff
[/SYS/WORK]%
アクセスするレジスタ幅で全然違うもの読みだしてくるんですけど…
vmxnetのレジスタダンプ…
[/SYS/WORK]% iodump b 2000 203f
2000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2010: 00 0c 29 47 2b fc ff ff ff ff ff ff ff ff ff ff
2020: ff ff ff ff ff ff ff ff 00 0c 29 47 2b fc ff ff
2030: 20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[/SYS/WORK]% iodump h 2000 203f
2000: ffff ffff ffff ffff ffff ffff ffff ffff
2010: ffff ffff ffff ffff ffff ffff ffff ffff
2020: ffff ffff ffff ffff ffff ffff ffff ffff
2030: 0020 ffff ffff ffff ffff ffff ffff ffff
[/SYS/WORK]%
vmxnet
[ 208] Vend:15ad Dev:0720 Rev:10 Class:0200:00 [ Network:Ethernet ]
Cmd:0003 Sts:0280 Ht:00 Cs:00 Lt:40 Bt:00
sVen:15ad sDev:0720 Int:01:05 Mg:06 Mt:ff
BA#0: I/O: 00002000 [00000040]
(これは書いた通り)
どうも.vmxの書き換えがちゃんとできてなかったようだ。
vmxnet3
[ 300] Vend:15ad Dev:07b0 Rev:01 Class:0200:00 [ Network:Ethernet ]
Cmd:0003 Sts:0010 Ht:00 Cs:08 Lt:00 Bt:00
sVen:15ad sDev:07b0 Int:01:0a Mg:00 Mt:00
BA#0: MEM: ef5fc000 P:0 T:32 [00001000]
BA#1: MEM: ef5fd000 P:0 T:32 [00001000]
BA#2: MEM: ef5fe000 P:0 T:32 [00002000]
BA#3: I/O: 00004000 [00000010]
>>
vmxnet2
(これはエラーとなって起動しない)
vmxnet3
[ 208] Vend:15ad Dev:0720 Rev:10 Class:0200:00 [ Network:Ethernet ]
Cmd:0003 Sts:0280 Ht:00 Cs:00 Lt:40 Bt:00
sVen:15ad sDev:0720 Int:01:05 Mg:06 Mt:ff
BA#0: I/O: 00002000 [00000040]
あれー?15ad:07b0のはずなのに?(virtualHW.version=7だからか?)
https://kb.vmware.com/s/article/2050364?lang=ja
vmxnet
[ 208] Vend:15ad Dev:0720 Rev:10 Class:0200:00 [ Network:Ethernet ]
Cmd:0003 Sts:0280 Ht:00 Cs:00 Lt:40 Bt:00
sVen:15ad sDev:0720 Int:01:05 Mg:06 Mt:ff
BA#0: I/O: 00002000 [00000040]
vmxnet2
[ 208] Vend:15ad Dev:0720 Rev:10 Class:0200:00 [ Network:Ethernet ]
Cmd:0003 Sts:0280 Ht:00 Cs:00 Lt:40 Bt:00
sVen:15ad sDev:0720 Int:01:05 Mg:06 Mt:ff
BA#0: I/O: 00002000 [00000040]
…同じ?
久々にPCnet-Homeのデータシート見たけど、確かアクセスするレジスタ幅を32bit/16bit切り替えできたり、動作モードがいくつかあったりするのでその辺のエミュレーションを「このモード使ってないから削除するんで」とかされちゃうと動かなくはなりますよね。今まで動いていたものを削除する可能性はあんまり無いと思うので、この推測はたぶん外れてると思いますが。
netdrv(だよね、ネットワークドライバって)がおそらくLANCEなら問題にならないがvlanceのレジスタを叩いた際に、おそらく何か嫌なところを踏んでVMware Playerが機嫌を損ねている…というところかなあ?
おそらく機嫌のいい時は、こう。
[/SYS]% #
BMS> oh 0x2012,0x12
Port 2012:H <-- 0012
BMS> ih 0x2010
Port 2010:H --> ffff
BMS> oh 0x2012,0x1a
Port 2012:H <-- 001a
BMS> ih 0x2010
Port 2010:H --> ffff
BMS> oh 0x2012,0x3a
Port 2012:H <-- 003a
BMS> ih 0x2010
Port 2010:H --> 0200
BMS>
VMware Playerが機嫌を損ねた後は何をやっても無駄らしい
[/SYS/WORK]% #
BMS> oh 0x2012,0x12
Port 2012:H <-- 0012
BMS> ih 0x2010
Port 2010:H --> 0073
BMS> oh 0x2012,0x1a
Port 2012:H <-- 001a
BMS> ih 0x2010
Port 2010:H --> 0073
BMS> oh 0x2012,0x3a
Port 2012:H <-- 003a
BMS> ih 0x2010
Port 2010:H --> 0073
BMS>
単にvlanceのレジスタを舐めるだけで機嫌が悪くなる、という状況ではないみたい。
[/SYS/WORK]% iodump w 2000 207f
2000: 47290c00 0000fc2b 00001100 57570262
2010: 00000004 00000000 ffffffff ffffffff
2020: 00002934 ffffffff ffffffff ffffffff
2030: ffffffff ffffffff ffffffff ffffffff
2040: ffffffff ffffffff ffffffff ffffffff
2050: ffffffff ffffffff ffffffff ffffffff
2060: ffffffff ffffffff ffffffff ffffffff
2070: ffffffff ffffffff ffffffff ffffffff
[/SYS/WORK]%
[/SYS/WORK]% iodump h 2000 207f
2000: 0c00 4729 fc2b 0000 1100 0000 0262 5757
2010: 0004 0000 0000 0005 ffff ffff ffff ffff
2020: 2934 ffff ffff ffff ffff ffff ffff ffff
2030: ffff ffff ffff ffff ffff ffff ffff ffff
2040: ffff ffff ffff ffff ffff ffff ffff ffff
2050: ffff ffff ffff ffff ffff ffff ffff ffff
2060: ffff ffff ffff ffff ffff ffff ffff ffff
2070: ffff ffff ffff ffff ffff ffff ffff ffff
[/SYS/WORK]%
[/SYS/WORK]% iodump b 2000 207f
2000: 00 0c 29 47 2b fc 00 00 00 11 00 00 62 02 57 57
2010: 04 ff 00 ff 00 ff 05 ff ff ff ff ff ff ff ff ff
2020: 34 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[/SYS/WORK]%
[/SYS/WORK]% hwtool/pciinf
** PCI Device test **
Total 16 PCI Devices/Func [ConfM:1]
>> d 208
[ 208] Vend:1022 Dev:2000 Rev:10 Class:0200:00 [ Network:Ethernet ]
Cmd:0003 Sts:0280 Ht:00 Cs:00 Lt:40 Bt:00
sVen:1022 sDev:2000 Int:01:05 Mg:06 Mt:ff
BA#0: I/O: 00002000 [00000080]
>> q
[/SYS/WORK]%