FreeBSD current 一握の砂

**名無しさん＠お腹いっぱい。** · NG

はたらけど　はたらけど猶わが生活
楽にならざりぢつと手を見る

>> Shut up and code!!!

前スレは>>2-5あたり

**名無しさん＠お腹いっぱい。** · 2006/01/01(日) 12:03:33

一応、src/sys/pci/agpvar.hの1.3での変更を元に戻して、kernel,nvidia-dirverを作り直せば、今のcurrentででも動くよね。

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/agpvar.h

**名無しさん＠お腹いっぱい。** · 2006/01/01(日) 15:28:28

>>403
ttp://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/agp.c.diff?r1=1.48&r2=1.49
これと同じことをやればコンパイルはできるんじゃないの?

**名無しさん＠お腹いっぱい。** · 2006/01/01(日) 18:41:24

7-currentについて、方向性とか新機能についてまとめている
サイトとかありますか?

**名無しさん＠お腹いっぱい。** · 2006/01/01(日) 23:30:05

基本的に-currentで、デバッグオプションによる速度低下を
防ぐには、以下の２つをコメントアウトするだけで良いのでしょうか?

options WITNESS
options WITNESS_SKIPSPIN

KDBをコメントアウトすると xfs のコンパイルで、KDB関連のオプションを
有効にしろとエラーメッセージが出ます。

**名無しさん＠お腹いっぱい。** · 2006/01/02(月) 04:53:19

>>403
>>404
OS側のAGPではなくNVIdia のAGPドライバを使えばいいのでは?

**名無しさん＠お腹いっぱい。** · 2006/01/02(月) 13:51:55

>>406
ln -sf aj /etc/malloc.conf

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 14:38:59

最近、なんか-current安定しているよね。

MLで奴が怪しげなこと言っているときはいつも警戒していたのに...

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 17:10:24

>>409 「奴」って誰よ?

**名無しさん＠お腹いっぱい。** · 2006/01/03(火) 23:02:22

そういやlinuxpluginwrapperが使えなくなったな
中の人は何か考えているらしいが
ttp://blog.ninth-nine.com/diary/20060101.txt

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 21:56:06

malloc新しくなったから入れてみたらX起動しなくなった　orz
かなり遅いし、戻すか…( ´・ω・`)

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:24:38

>>412
libcのmalloc(3)を切り替えたよ。今はデバッグ、検査、統計収集用のオプションが
全部有効になってるから、プログラムは遅くなるしメモリも余計に食う。移行期間の
バタバタがおおよそ終わったらここらへんのは切れるから。
パフォーマンスが気になるなら、src/lib/libc/stdlib/malloc.cの中にある下の
いくつかをundefineして。これらのせいでプログラムが遅くなって、メモリも
余計に食ってるんだ。
MALLOC_DEBUG MALLOC_STATS MALLOC_REDZONES
もしmallocがらみの実行時エラーを見つけたら、malloc(3)でチューニング用の
フラグを調べて関係あるのを使いながら、問題の種類をみきわめてほしい。特に
A J Q Zフラグは便利だね。この実装が見つけるアプリケーションのバグは

**名無しさん＠お腹いっぱい。** · 2006/01/14(土) 22:37:52

* バイト境界に対する誤った仮定: このmallocはたとえ非常に大きい領域の割り当て
についても16バイト境界しか保証しない。正当だけど、あまり一般的じゃない。
phkmallocはここらへんがとても寛容だった。もしこういうバグをみつけたら
posix_memalign(3)を見て直してね。
* バッファオーバラン: このmallocはboundary tagを使っているので、割り当て
の外側に書き込むとmalloc内部のデータ構造を壊す可能性がある。小さいオーバ
ランはredzoneで検出できるけど、大きいのは無理だ。

この変更によって沢山の問題の報告が来るだろうと思う。その場合、たいていは
アプリケーションのバグだと思うけど、malloc自身のバグという可能性もある。
みんな、広い心で原因の究明に取りくもう。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 01:31:15

アメリカのドラマの吹き替え口調みたいな文体だな

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 05:59:11

結局、mallocで一番、高速に動作するオプションはどれ?

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 12:04:57

つうか、なんで新しいmallocが入ることになったの？
>>413-414の解説を読むとあまり利点を感じないのだが。

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 13:30:10

>>417
SMP 環境でマルチスレッドのプログラムの性能を向上させるためらしい。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=783829+0+archive/2005/freebsd-current/20051225.freebsd-current

kris が4CPUのamd64マシンでベンチマークをやっているけど、スレッド数3の場合で以前のmallocより107倍早かったそうな。
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=138177+0+archive/2005/freebsd-current/20051218.freebsd-current

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 15:54:41

最後の三行だけ抜き出すと
So libthr is *much* faster than libpthread with both malloc
implementations, but jemalloc is still 1.7 times faster for 1 thread
and 80 times faster for 5 threads than phkmalloc.

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 20:55:47

でもマルチスレッドでmallocしまくるような状況って
それほどあるの?

**名無しさん＠お腹いっぱい。** · 2006/01/15(日) 23:45:42

特にOO系の言語ではメモリアロケータのパフォーマンスが重要だから、
恩恵を受けるプログラムは結構多いんじゃない?

それに、libpthreadやlibthrによるカーネルレベルでのスレッドサポートが
せっかく入ったのに、今までのmalloc()は単一のspinlockによる
原始的な排他しかしてなかったからなあ……

**名無しさん＠お腹いっぱい。** · 2006/01/16(月) 02:54:56

>>412
XについてはXorg-snapを入れるというworkaroundがあるようで。
ぶっちゃけ、dlopen使えってことだな。

**名無しさん＠お腹いっぱい。** · 2006/01/18(水) 08:27:44

これで MySQL と FreeBSD の組み合わせが最強になるとうれしい。
関係ないですか？

**名無しさん＠お腹いっぱい。** · 2006/01/18(水) 09:51:46

mallocの性能の悪さも性能が劣化する原因の一つだろうからこれで少しは変わると思うよ。
つうか、こういう単純なベンチマークじゃなくてもっとリアルなアプリケーションで
ベンチマークをやった人って居ないんだろうか....
マルチスレッドのアプリケーションと言えば、MySQL、BIND、Apacheといろいろ
ありそうなのだけど。

**名無しさん＠お腹いっぱい。** · 2006/01/18(水) 17:13:34

実務や現場を知らない香具師の寝言。

**名無しさん＠お腹いっぱい。** · 2006/01/18(水) 23:21:48

そういう香具師が往々にして決裁権を持っている件について

**名無しさん＠お腹いっぱい。** · 2006/01/19(木) 00:00:45

現場的には今回の変更はどうなの？
新しいもの勝手に入れるなゴルァ！
今動いているのが動かなくなったらコロスケなりよ
なんだろうか。それとも、速くなりそうなので歓迎なんだろうか。

**名無しさん＠お腹いっぱい。** · 2006/01/19(木) 02:11:17

>>427
現場の人はcurrentには興味なしと思われ。

**名無しさん＠お腹いっぱい。** · 2006/01/19(木) 12:40:59

そもそも、性能に影響あるところには極力mallocを使わないようにコード書くしなぁ。

**名無しさん＠お腹いっぱい。** · 2006/01/21(土) 09:26:12

qemuが動かなくなっとる。。

**名無しさん＠お腹いっぱい。** · 2006/01/23(月) 06:46:08

mallocってマロックって読むの？
俺ずっとエムアロックと読んでて不安になった。
メモリ・アロケーションだよね？

**名無しさん＠お腹いっぱい。** · 2006/01/23(月) 08:09:55

どっちでもいいんじゃない？
stdioはスタンダードアイオーと読んで、スタジオと読んだりはしないけど。

**名無しさん＠お腹いっぱい。** · 2006/01/23(月) 09:50:14

俺はエスティーディーアイオーと四㌦

**名無しさん＠お腹いっぱい。** · 2006/01/23(月) 12:36:32

UNIXに関する言葉のひらがな読みスレッド
http://pc8.2ch.net/test/read.cgi/unix/1001358861/

**名無しさん＠お腹いっぱい。** · 2006/01/30(月) 00:29:24

12/31のvm(キャッシュ)の修正で久しぶりに動かなくなった。
オラ、ワクワクして来たぞ。

**名無しさん＠お腹いっぱい。** · 2006/01/30(月) 04:44:13

>>435
12/31?

**名無しさん＠お腹いっぱい。** · 2006/01/30(月) 20:52:35

2005/12/31 14:39の↓のコミット
古いCPUだとのdetection of the cache sizeでストールする。

MI changes:
- provide an interface (macros) to the page coloring part of the VM system,
this allows to try different coloring algorithms without the need to
touch every file [1]
- make the page queue tuning values readable: sysctl vm.stats.pagequeue
- autotuning of the page coloring values based upon the cache size instead
of options in the kernel config (disabling of the page coloring as a
kernel option is still possible)

MD changes:
- detection of the cache size: only IA32 and AMD64 (untested) contains
cache size detection code, every other arch just comes with a dummy
function (this results in the use of default values like it was the
case without the autotuning of the page coloring)
- print some more info on Intel CPU's (like we do on AMD and Transmeta
CPU's)

Note to AMD owners (IA32 and AMD64): please run "sysctl vm.stats.pagequeue"
and report if the cache* values are zero (= bug in the cache detection code)
or not.

**名無しさん＠お腹いっぱい。** · 2006/01/31(火) 08:50:16

仮想端末のデバイス名が /dev/pts/* に変更されつつある件について

**名無しさん＠お腹いっぱい。** · 2006/01/31(火) 09:21:36

デバイス名だけの変更じゃないよ。

**名無しさん＠お腹いっぱい。** · 2006/01/31(火) 11:03:38

そろそろcvsupしても大丈夫かな?

**名無しさん＠お腹いっぱい。** · 2006/02/05(日) 02:49:17

7-currentって、なんかXを立ち上げずコンソールで使うとキー入力に
対する反応が凄く遅い。

Xを立ち上げて使うと全然問題ないんだけど...

**名無しさん＠お腹いっぱい。** · 2006/02/05(日) 06:20:56

しらんがな

**名無しさん＠お腹いっぱい。** · 2006/02/05(日) 06:28:24

そういや、今の-currentちょっと重いね。
漏れのところは X が立ち上がっていても重いよ。
多分Thread周りがこまめにいじられているから、
もうちょっと待てば、ましにはなると思う。
WindowMakerのアニメーションがめちゃくちゃスローだよ。

**名無しさん＠お腹いっぱい。** · 2006/02/05(日) 13:35:29

最近いろいろいじりはじめたみたい。

あー、関係ないけど、7-currentってjdk1.5.0インストール失敗するな。
やっとcurrentらしくなってきた。

**名無しさん＠お腹いっぱい。** · 2006/02/05(日) 16:05:21

>>443
新mallocのデバックオプションのせいじゃね?
NO_MALLOC_EXTRAS 付けてビルドしたら?

**名無しさん＠お腹いっぱい。** · 2006/02/05(日) 23:12:16

たぶん、mallocは関係ないと思うな。
けっこうThread周りが今怪しいことになっている。

powerdでcpu clock を落としていると体感できるぐらい遅くなっているよ。

**名無しさん＠お腹いっぱい。** · 2006/02/06(月) 00:35:33

powerdを有効にしたら確かに重い

**名無しさん＠お腹いっぱい。** · 2006/02/06(月) 00:39:43

描画というか表示関係が遅いのかな?

emacsの起動も遅くないし、buildworldの時間もそれほど変わってないよ。

**名無しさん＠お腹いっぱい。** · 2006/02/06(月) 00:55:45

珍しく currentスレが盛り上がっているが、

linuxpluginwrapperってまだ未対応のままだね。
早く対応してくれないかな。

**名無しさん＠お腹いっぱい。** · 2006/02/06(月) 21:31:14

最近daichiのことが気になってしかたありません。
見るたびになんだか落着かなくなってしまいます。
ときめきとも違った、ふしぎな気分なんです。

**名無しさん＠お腹いっぱい。** · 2006/02/07(火) 04:53:23

そろそろcvsupしようと思ったらcurrentが重いっていう話なのか。
いつごろ解消しそう?

去年の12月の終わりからまだ更新してないんだ。

**名無しさん＠お腹いっぱい。** · 2006/02/07(火) 05:46:27

jdk 1.5 がコンパイルできねぇー

**名無しさん＠お腹いっぱい。** · 2006/02/07(火) 11:01:15

>>452
勘違いだった、普通に入った。

**名無しさん＠お腹いっぱい。** · 2006/02/07(火) 11:20:44

風説の流布罪によりタイーh

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 01:32:03

FreeBSD 7-currentでqemu 0.8.0を使うと、ゲストOSの時間が凄い勢いで
進んでしまう。

これ何で?

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 02:24:45

どこもかしこもqemuネタ多いな・・・

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 03:06:47

unix板でqemuスレ立てた方がいいかも知れんな

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 03:30:12

ちょっとここのスレの流れを読んでて思ったんだけど、
今の7-currentってタイマー関連がおかしくない?

だから、表示が遅かったり qemuの時間がおかしかったりしているんじゃないの?

漏れはcurrent使ってないから何ともいえないけど、詳しいこと知っている香具師が
いたら教えてくれ。

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 09:57:01

>>455
> FreeBSD 7-currentでqemu 0.8.0を使うと、
漠然と 7-current って言われても...
少なくとも, 1 月 20日に buildkernel した奴は無問題だが...

>>458
> 今の7-currentってタイマー関連がおかしくない?
なぜタイマー関連のせいになる?

> だから、表示が遅かったり
表示するときに時間を気にするのはゲームとかビデオの再生くらいのもんだろ
それ以外は通常全力で出力する

**名無しさん＠お腹いっぱい。** · 2006/02/08(水) 15:24:37

>>459
7-currentの日付だけど、
2月5日くらいにcvsupしたkernel、2月7日にcvsupしたものも同じ症状。

**名無しさん＠お腹いっぱい。** · 2006/02/09(木) 02:51:07

まぁ、currentなんだし気楽に待ちましょ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 01:32:48

しっかし、今の-currentって、shutdown に時間がかかるな。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 13:54:19

まぁ、1週間もしたら直るでしょ。

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 14:42:12

shutdown に一週間かかるのかとオモタ

**名無しさん＠お腹いっぱい。** · 2006/02/10(金) 16:50:06

xeon × 4のマシンで何年も前からリブートできないよ。
不思議なことにシングルユーザからだとリブートできる。
それ以上はめんどくさいから調べてないけど。

**名無しさん＠お腹いっぱい。** · 2006/02/17(金) 10:25:49

起動と停止の処理は面倒を避けるためにシングルCPU状態におちると思うのだけど、
そのときのCPUを止める処理が壊れてるんじゃないの？
まあ、壊れてるんだろうなと思ってもどうやって直したらいいか見当がつかんけど。

**名無しさん＠お腹いっぱい。** · 2006/02/23(木) 23:19:09

最近のcurrent で Emacs ビルドできた方います？
firewire の cardbus カード BUFFALO IFC-ILCB3 も認識できなくなってるし。
ついでにゆうと、RELENG_6 でも認識できなくなってたような。

**名無しさん＠お腹いっぱい。** · 2006/02/24(金) 01:35:22

>>467
おれもできない。coredumped.

**名無しさん＠お腹いっぱい。** · 2006/02/24(金) 03:15:33

>>468, 467
preload image 作るときに undump できないだけだと思うが.

**名無しさん＠お腹いっぱい。** · 2006/02/24(金) 13:08:23

nsp ドライバ腐ってる。

**名無しさん＠お腹いっぱい。** · 2006/02/24(金) 13:48:30

>>449
一瞬ペンギンラッパーってなんぞいなと読みまつがえた。

**467** · 2006/02/27(月) 01:05:34

Emacsビルドできた。
でも、後ろ向きな解決方法ですけど。
libc.so.6のmallocが悪さしているみたいです。
手順
misc/compat5xをインストールする。
/etc/libmap.confに以下の内容を追加。
[emacs]
libc.so.6 libc.so.5
configure後、src/config.hでHAVE_POSIX_MEMALIGNが定義されていたら定義しないようにする。
で、いけるんじゃあないかと思う。

**名無しさん＠お腹いっぱい。** · 2006/02/27(月) 01:38:44

>>472
/etc/make.conf に NO_MALLOC_EXTRAS を指定してlibcを作りなおしてみたり、
ln -s ajQ /etc/malloc.conf
(Qは複数回指定可)とかしてみたらどうよ?

**467** · 2006/02/27(月) 01:44:30

ln -s ajQ /etc/malloc.conf して libmap.conf の記述を削除して
さっき作った emacs 起動できた！

**名無しさん＠お腹いっぱい。** · 2006/02/27(月) 08:35:27

>>465
つまり shutdown -r now だとダメだけど、
shutdown now → shutdown -r now だとOKってこと?
それともいっぺんmultiuser modeに入るとアウトてこと?

**名無しさん＠お腹いっぱい。** · 2006/03/02(木) 23:46:51

おっちゃん達が懐かしいネタに喰いついてきましたよ :)
ttp://docs.FreeBSD.org/cgi/mid.cgi?20060301170306.GZ55746

**名無しさん＠お腹いっぱい。** · 2006/03/03(金) 00:03:55

>>475
後者

**名無しさん＠お腹いっぱい。** · 2006/03/04(土) 02:43:06

csupこんにちは
cvsupさようなら

**名無しさん＠お腹いっぱい。** · 2006/03/04(土) 12:56:36

csupサーバーってどこあんの？
csupサーバーを自分で立てるにはどうするの？

cvsupだとcvsup-mirrorを入れると後者の9割り方が終了だけどさ。

**名無しさん＠お腹いっぱい。** · 2006/03/04(土) 13:29:31

互換なんじゃないの?

**名無しさん＠お腹いっぱい。** · 2006/03/04(土) 13:49:21

csup が落ち着いたら csupd も作ってくれるさ

**名無しさん＠お腹いっぱい。** · 2006/03/04(土) 22:59:04

いまのところcheckout modeしかサポートされないから
cvsupさようなら、とはいかないな。

**名無しさん＠お腹いっぱい。** · 2006/03/04(土) 23:14:17

そこで cvsync ですよ。

**名無しさん＠お腹いっぱい。** · 2006/03/05(日) 03:40:21

じゃあ俺bobsup作るかな

**名無しさん＠お腹いっぱい。** · 2006/03/05(日) 10:00:26

出か杉

**名無しさん＠お腹いっぱい。** · 2006/03/06(月) 10:09:08

cvsyncは逆にcheckout modeなかったような

**名無しさん＠お腹いっぱい。** · 2006/03/11(土) 13:34:51

ata-usbがcommitされたけど、CAMに比べてどんないいこと
があるの？

**名無しさん＠お腹いっぱい。** · 2006/03/12(日) 02:58:21

sosの自慰行為を堪能できます

**名無しさん＠お腹いっぱい。** · 2006/03/13(月) 14:09:34

>>476
3年前のじゃねえか
とっくに消えてるの持ってきて釣ったつもりか

**名無しさん＠お腹いっぱい。** · 2006/03/13(月) 15:55:52

消えてるんじゃなくて、Message-ID 検索が壊れてるだけ。これだろ。
http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061224.html

**名無しさん＠お腹いっぱい。** · 2006/03/14(火) 20:11:41

csup、今日の分で十分使えるようになった感じ。
あとは、CVS mode と csupd か。ガンガレむっくす。

**476** · 2006/03/14(火) 22:44:58

>>489 遅ぇーよ、俺が貼った頃にはちゃんと見えてたんだよ。

**名無しさん＠お腹いっぱい。** · 2006/03/14(火) 23:40:12

csup派とportsnap派どっちが多いよ

**名無しさん＠お腹いっぱい。** · 2006/03/15(水) 00:36:12

src tree と ports tree それぞれで併用

**名無しさん＠お腹いっぱい。** · 2006/03/15(水) 10:22:32

っていうかそれが普通で、csup と portsnap は排他なものではないと思うが。

**名無しさん＠お腹いっぱい。** · 2006/03/16(木) 21:42:20

今年は技術評論社から　FreeBSD Expert 2006 は出版されないのかな？

**>495** · 2006/03/16(木) 22:37:09

はあ？portsに関しては排他的じゃん
あんたバカ？

**名無しさん＠お腹いっぱい。** · 2006/03/16(木) 23:01:11

portsnap使うのは素人

**名無しさん＠お腹いっぱい。** · 2006/03/17(金) 01:02:51

もれはアップデートに必要な時間が少ないのでportsnapに切り替えた。
/usr/srcはcvsupで、/usr/portsはportsnap使ってる。

**名無しさん＠お腹いっぱい。** · 2006/03/17(金) 10:49:03

>>497
portsしか使えないバカは引っ込んでください。

**名無しさん＠お腹いっぱい。** · 2006/03/17(金) 11:31:37

一部にて春厨蠢動中に感じるが。

portと、tar-ballの標準的配布形態を利用したいものとか、binのおき場所とか
設定ファイルの保存場所の違いがあると結構面倒草。
PATH変数を汚さなくてすむという利点より、パッケージの管理しやすさからいうとportsの
ポリシーが気に入らない時があるよ。　だから、"portsしか"使えないのじゃなくて、使わないと
不幸になる場合（郷に入っては郷に従え的なもの）がある気が

**名無しさん＠お腹いっぱい。** · 2006/03/17(金) 11:45:22

>496
ギリギリまで6.1Rを待っていたけど、もうムリポ
だから来月でるはず。

**名無しさん＠お腹いっぱい。** · 2006/03/17(金) 13:40:34

>501
なにが言いたいのかわからん。

ports のポリシーが気にくわなければ既存 ports を使わなければいい

自分の独自ポリシーで独自 ports をつくって勝手に管理する自由はあるし
ports システムに一切関係なくいじるのもまた自由。