|
Namazu for hns による簡易全文検索 詳しくは 詳細指定/ヘルプを参照して下さい |
|||||||||||||||||||||||||||||||||||||||||||||||||
2006年09月23日(土) [n年日記] Last Update: "2006/12/12 23:31:33"#1 [4400] 4.99.1 の CD-R 起動中停止
4.99.1 の CD-R で起動しようとすると、次のところで止ってしまう
ものがある
0 > boot ata/atapi-disk@0:0 >> NetBSD/macppc OpenFirmware Boot, Revision 1.5 >> (root@st4200, Tue Sep 5 04:27:45 JST 2006) open /netbsd: Device not configured open /netbsd.gz: Device not configured 7233932+203968実は、riser card 無 Cache 無 CDROM 無のものなので、何か以前に問題があった ものか ? CPU, PPC 603 Memory, 64+ Disk, Quantum 2G CD-ROM, 電池, 角実は別の機械で試したところ、同じように止ったが、 3.99.21 の CD-R では起動した。ということは ..
0 > setenv real-base EC0000 okこんなことをしてしたら、多分電池外しが必要になってしまった。 3.99.21 の場合は次のような表示がある 6987964+204168=0x6dc198 ttyrc:makoto@mini 10:20:25/060924(~)> bc obase = 16 6987964+204168 6DBE44 ibase = 16 6DBE44-6DC198 -354 obase = 16 7233932+203968 717E4Cこれは real-base F00000としているのが原因だった。設置時だけは、これを -1 とする必要がある。 set-default real-base reset-all
real-base = -1 real-base = F00000
16M +---------+
| |
| | 16M +---------+
| | sysinst 時 | |
| | | |
| | | | sysinst 時
| | | |
8M +---------+ | |
| | | |
| | 8M +---------+
| | | |
4M +---------+ | |
| | 通常起動 | |
1M +---------+ 4M +---------+
| | | | 通常起動
0M +---------+ 1M +---------+
| |
0M +---------+
real-base = F00000 の時には メモリは 15M までしか使えない。
sysinst 時には 80000 から置くが、大きさが 7M を越えると、問題が起きる
2006年09月27日(水) [n年日記] Last Update: "2006/12/12 23:31:47"#1 [4.99.1] やはり ex がささっていると
sysinst の途中で止ってしまう
db> bt at 0x9d4dc8 at 0xa913b8 at 0xa81ce8 at 0xa815c0 at 0xa8b2f8 at 0xadba08 at 0xadf61c db> reboot panic: lockmgr: locking against myself Stopped in pid 94.1 (tar) at 0xadc8c8: addi 1,1,16 db>ところが、これがどこか分らない。sysinst の中 ? ex を抜いても(同じところで)止ってしまう .. 84% |******************************* | 81913 KB 1.63 MB/s 00:09 ETAStopped in pid 90.1 (tar) at 0xa7e040: lwz 0,32(31) db> bt at 0x9d4dc8 at 0xa913b8 at 0xa81ce8 at 0xa815c0 at 0xa8b2f8 at 0xadba08 at 0xadf61c db>これは別の NIC を差して、設置を済ませた。 ＠ もう一度 ex を差して確めると:ex0 at pci1 dev 7 function 0: 3Com 3c905C-TX 10/100 Ethernet with mngmt (rev. 0x6c) ex0: interrupting at irq 27 trap type 200 at 1f42f8 Stopped in pid 0.1 (swapper) at netbsd:ex_reset+0x34: ori 3,3,34464 db> bt at ex_config+5c at ex_pci_attach+300 at config_attach_loc+31c at config_found_sm_loc+60 at pci_probe_device+2f4 at pci_enumerate_bus+1d8 at pcirescan+54 at config_attach_loc+31c at config_found_sm_loc+60 at ppbattach+128 at config_attach_loc+31c at config_found_sm_loc+60 at pci_probe_device+2f4 at pci_enumerate_bus+1d8 at pcirescan+54 at config_attach_loc+31c at config_found_sm_loc+60 at bandit_attach+1d0 at config_attach_loc+31c at config_found_sm_loc+60 at mainbus_attach+14c at config_attach_loc+31c --db_more-- 001f42c4 <ex_reset>: 1f42c4: 7c 08 02 a6 mflr r0 1f42c8: 94 21 ff e0 stwu r1,-32(r1) 1f42cc: 93 a1 00 14 stw r29,20(r1) 1f42d0: 7c 7d 1b 78 mr r29,r3 1f42d4: 90 01 00 24 stw r0,36(r1) 1f42d8: 80 03 20 f0 lwz r0,8432(r3) 1f42dc: 81 23 02 5c lwz r9,604(r3) 1f42e0: 54 00 de f6 rlwinm r0,r0,27,27,27 1f42e4: 39 29 00 0e addi r9,r9,14 1f42e8: 7c 00 4f 2c sthbrx r0,0,r9 1f42ec: 7c 00 06 ac eieio 1f42f0: 7c 00 04 ac sync 1f42f4: 3c 60 00 01 lis r3,1 1f42f8: 60 63 86 a0 ori r3,r3,34464 1f42fc: 48 1f 25 95 bl 3e6890 <delay>sys/dev/ic/elinkxl.c:
1514 ex_reset(sc)
1515 struct ex_softc *sc;
1516 {
1517 u_int16_t val = GLOBAL_RESET;
1518
1519 if (sc->ex_conf & EX_CONF_RESETHACK)
1520 val |= 0x10;
1521 bus_space_write_2(sc->sc_iot, sc->sc_ioh, ELINK_COMMAND, val);
1522 /*
1523 * XXX apparently the command in progress bit can't be trusted
1524 * during a reset, so we just always wait this long. Fortunately
1525 * we normally only reset the chip during autoconfig.
1526 */
1527 delay(100000);
1528 ex_waitcmd(sc);
1529 }
多分、RESET を送って 100,000
待っている間に割込がかかってしまうから machine check になるのだらう。
それと、
何故 100,000 が 34,464 になっているのかな。
この辺は 2001 年に行なわれた変更 だ .. FreeBSD のコード の ex_reset を見ると、ずいぶん違う (これは違う chip 用かな)。 とりあえず delay を長くして見る ? (でも delay の間に割込が来て問題が起きているなら、長くしても意味がない) 上に書いたことは間違っていると思う。100,000(?) をレジスタに設定している時に落ちるのだから、 delay は関係ない。 本来 RESET するだけなら割込は発生しないはずなのに、発生していることが問題、だと思う。＠ patch を作成、これで見かけ上解決:Index: sys/dev/ic/elinkxl.c =================================================================== RCS file: /export/20060822/Repository/src/sys/dev/ic/elinkxl.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 elinkxl.c --- sys/dev/ic/elinkxl.c 4 Sep 2006 11:24:16 -0000 1.1.1.1 +++ sys/dev/ic/elinkxl.c 28 Sep 2006 01:20:00 -0000 @@ -1519,12 +1519,16 @@ if (sc->ex_conf & EX_CONF_RESETHACK) val |= 0x10; bus_space_write_2(sc->sc_iot, sc->sc_ioh, ELINK_COMMAND, val); + /* Above command causes machine check at autoconf, so disable IRQ here */ + bus_space_write_2(sc->sc_iot, sc->sc_ioh, ELINK_COMMAND, SET_INTR_MASK ); /* * XXX apparently the command in progress bit can't be trusted * during a reset, so we just always wait this long. Fortunately * we normally only reset the chip during autoconfig. */ delay(100000); + /* Then enable IRQ again */ + bus_space_write_2(sc->sc_iot, sc->sc_ioh, ELINK_COMMAND, STATS_ENABLE ); ex_waitcmd(sc); } 2006年09月28日(木) [n年日記] Last Update: "2006/12/12 23:31:54"#1 [4.99.1] DSI 割込
trap type 300 とは Data Storage Interrupt らしい
trap type 300 at 37dfac Stopped in pid 3049.1 (pax) at netbsd:cache_lookup+0x8c: lwz 0,32(31) db> bt at ufs_lookup+110 at VOP_LOOKUP+34 at lookup+2f4 at namei+10c at vn_open+90 at sys_open+e0 at syscall_plain+134 at setfault+c54 db>kernel を L2-1M-SHM にしたが、関係なく落ちる。 trap type 300 at 37dfb0 Stopped in pid 703.1 (tar) at netbsd:cache_lookup+0x8c: lwz 0,32(31) db> bt at ufs_lookup+110 at VOP_LOOKUP+34 at lookup+2f4 at namei+10c at vn_open+90 at sys_open+e0 at syscall_plain+134 at setfault+c54 db> 0037df24 <cache_lookup>: 37df24: 7c 08 02 a6 mflr r0 37df28: 94 21 ff d0 stwu r1,-48(r1) 37df2c: 3d 20 00 5e lis r9,94 37df30: 93 61 00 1c stw r27,28(r1) 37df34: 7c 9b 23 78 mr r27,r4 37df38: 93 81 00 20 stw r28,32(r1) 37df3c: 7c bc 2b 78 mr r28,r5 37df40: 93 c1 00 28 stw r30,40(r1) 37df44: 7c 7e 1b 78 mr r30,r3 37df48: 93 41 00 18 stw r26,24(r1) 37df4c: 93 a1 00 24 stw r29,36(r1) 37df50: 93 e1 00 2c stw r31,44(r1) 37df54: 90 01 00 34 stw r0,52(r1) 37df58: 81 29 5b c8 lwz r9,23496(r9) 37df5c: 2f 89 00 00 cmpwi cr7,r9,0 37df60: 41 9e 01 c4 beq- cr7,37e124 <cache_lookup+0x200> 37df64: 83 a5 00 18 lwz r29,24(r5) 37df68: 2f 9d 00 1f cmpwi cr7,r29,31 37df6c: 41 9d 01 94 bgt- cr7,37e100 <cache_lookup+0x1dc> 37df70: 81 45 00 1c lwz r10,28(r5) 37df74: 3d 60 00 5e lis r11,94 37df78: 80 0b 67 70 lwz r0,26480(r11) 37df7c: 54 69 e8 fe rlwinm r9,r3,29,3,31 37df80: 7d 29 52 78 xor r9,r9,r10 37df84: 3d 60 00 5e lis r11,94 37df88: 7d 29 00 38 and r9,r9,r0 37df8c: 81 4b 67 74 lwz r10,26484(r11) 37df90: 55 29 10 3a rlwinm r9,r9,2,0,29 37df94: 7f e9 50 2e lwzx r31,r9,r10 37df98: 2f 9f 00 00 cmpwi cr7,r31,0 37df9c: 40 be 00 14 bne+ cr7,37dfb0 <cache_lookup+0x8c> 37dfa0: 48 00 01 14 b 37e0b4 <cache_lookup+0x190> 37dfa4: 83 ff 00 00 lwz r31,0(r31) 37dfa8: 2f 9f 00 00 cmpwi cr7,r31,0 37dfac: 41 9e 01 08 beq- cr7,37e0b4 <cache_lookup+0x190> 37dfb0: 80 1f 00 20 lwz r0,32(r31) 37dfb4: 7f 9e 00 00 cmpw cr7,r30,r0 37dfb8: 40 9e ff ec bne+ cr7,37dfa4 <cache_lookup+0x80> 37dfbc: 88 1f 00 34 lbz r0,52(r31) 37dfc0: 7f 9d 00 00 cmpw cr7,r29,r0src/sys/kern/vfs_cache.c
176 cache_lookup(struct vnode *dvp, struct vnode **vpp, struct componentname *cnp)
177 {
178 struct namecache *ncp;
179 struct vnode *vp;
180 int error;
181
182 if (!doingcache) {
183 cnp->cn_flags &= ~MAKEENTRY;
184 *vpp = NULL;
185 return (-1);
186 }
187
188 if (cnp->cn_namelen > NCHNAMLEN) {
189 /* XXXSMP - updating stats without lock; do we care? */
190 nchstats.ncs_long++;
191 cnp->cn_flags &= ~MAKEENTRY;
192 goto fail;
193 }
194 simple_lock(&namecache_slock);
195 ncp = cache_lookup_entry(dvp, cnp);
196 if (ncp == NULL) {
197 nchstats.ncs_miss++;
198 goto fail_wlock;
199 }
200 if ((cnp->cn_flags & MAKEENTRY) == 0) {
201 nchstats.ncs_badhits++;
202 goto remove;
203 } else if (ncp->nc_vp == NULL) {
204 /*
205 * Restore the ISWHITEOUT flag saved earlier.
206 */
207 cnp->cn_flags |= ncp->nc_flags;
208 if (cnp->cn_nameiop != CREATE ||
201 行目で落ちている気がする。
|
最近の日記 | ||