Re: 5.0 NFS-related panic

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Dec 29, 2008 at 01:20:31PM +0100, Manuel Bouyer wrote:
> > So a 64bit NFS client doesn't work but 32bit ones do.
> 
> There's another factor I think: alpha is AFAIK the only platform using
> the 64bit cpu_in_cksum() (amd64 and sparc64 have both their assembly version).
> I couln't find anything wrong with the MI cpu_in_cksum() though; I'll try
> to get more infos today.

Another crash, this time with a -g kernel:
CPU 0: fatal kernel trap:

CPU 0    trap entry = 0x2 (memory management fault)
CPU 0    a0         = 0xfffffe010824a000
CPU 0    a1         = 0x1
CPU 0    a2         = 0x0
CPU 0    pc         = 0xfffffc00007ea1e8
CPU 0    ra         = 0xfffffc00007ee5b0
CPU 0    pv         = 0x0
CPU 0    curlwp     = 0xfffffc003e579c00
CPU 0        pid = 0, comm = system
panic: trap
Stopped in pid 0.33 (system) at netbsd:cpu_Debugger+0x4:        ret     zero,(ra
)
db> tr                                                                          
cpu_Debugger() at netbsd:cpu_Debugger+0x4                                       
panic() at netbsd:panic+0x250                                                   
trap() at netbsd:trap+0xdc                                                      
XentMM() at netbsd:XentMM+0x20                                                  
--- memory management fault (from ipl 1) ---                                    
cpu_in_cksum() at netbsd:cpu_in_cksum+0x178                                     
in4_cksum() at netbsd:in4_cksum+0xc0
in_delayed_cksum() at netbsd:in_delayed_cksum+0x74
ip_output() at netbsd:ip_output+0xffc
tcp_output() at netbsd:tcp_output+0x1950
tcp_usrreq() at netbsd:tcp_usrreq+0x67c
tcp_usrreq_wrapper() at netbsd:tcp_usrreq_wrapper+0x18
sosend() at netbsd:sosend+0x5b8
nfs_send() at netbsd:nfs_send+0x100
nfs_request() at netbsd:nfs_request+0x358
nfs_writerpc() at netbsd:nfs_writerpc+0x518
nfs_doio() at netbsd:nfs_doio+0x58c
nfssvc_iod() at netbsd:nfssvc_iod+0x20c
exception_return() at netbsd:exception_return
--- root of call graph ---

(gdb) l *(cpu_in_cksum+0x178)
0xfffffc00007ea1e8 is in cpu_in_cksum 
(/dsk/l1/misc/bouyer/netbsd-5/src/sys/netinet/cpu_in_cksum.c:292).
287                             mlen -= 2;
288                     }
289                     while (mlen >= 64) {
290                             __builtin_prefetch(data + 32);
291                             __builtin_prefetch(data + 64);
292                             partial += *(uint32_t *)data;
293                             partial += *(uint32_t *)(data + 4);
294                             partial += *(uint32_t *)(data + 8);
295                             partial += *(uint32_t *)(data + 12);
296                             partial += *(uint32_t *)(data + 16);

0xfffffc00007ea1d8 <cpu_in_cksum+360>:  lda     t0,-1
0xfffffc00007ea1dc <cpu_in_cksum+364>:  sll     t0,0x3e,a1
0xfffffc00007ea1e0 <cpu_in_cksum+368>:  lda     a2,64(a2)
0xfffffc00007ea1e4 <cpu_in_cksum+372>:  subl    a4,0x40,a4
0xfffffc00007ea1e8 <cpu_in_cksum+376>:  ldl     t1,-64(a2)
0xfffffc00007ea1ec <cpu_in_cksum+380>:  ldl     t0,-60(a2)
0xfffffc00007ea1f0 <cpu_in_cksum+384>:  ldl     t2,-56(a2)
0xfffffc00007ea1f4 <cpu_in_cksum+388>:  ldl     t3,-52(a2)
0xfffffc00007ea1f8 <cpu_in_cksum+392>:  ldl     t6,-48(a2)

It traps on
ldl     t1,-64(a2)
indeed a2 is 0 at this point. This would mean one of the mtod(m, uint8_t *)
returned 0, while m and m->m_len was not 0. unless the compiler is doing
something wrong I can't see how this can happen ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--