On Tue, 3 Apr 2007, Johnny Billquist wrote:

>>> Also, probably very unrelated. A kernel as built today is not useable. It 
>>> goes up to about 100% system time as soon as I copy anything from an NFS 
>>> mounted disk to a local disk on my VAX.
>>> This is 4.99.16. I have an older build (4.99.15) where this don't happen, 
>>> so something changed recently. But like I said, I don't think that is 
>>> related to GCC.
>>
>>   I think this is related to mutex_spin_{enter,exit), which I am looking 
>> at.  I think it also causes the le0 device to not be detected on my 
>> 4000/VLC, and probably on the 3100 mentioned in an earlier port-vax 
>> message.
>>
>>   A work-around may be to build a kernel with LOCKDEBUG.
>
> Hmm. Might try that later. Anyway. The problem is something that happened 
> after march 15, since my kernel from march 15 works fine.

   It appears that the gcc changes that enabled PIC support may be to 
blame.  I built a kernel using sources from 2007.04.01.06.00.00, but using 
the tools from the day before.  That kernel seemed to run fine.  Then I 
rebuilt the tools and another kernel.  That kernel now exhibits the 
problem of spending a lot of time in the kernel.  It seems to be related 
to writing to the filesystem - that's the only time I've seen the problem.

   I had some trouble getting some information about where it is in the 
kernel, but I finally managed to get some information after stumbling 
around in ddb a bit:


Stopped in pid 650.1 (tar) at   netbsd:cpu_Debugger+0x15:       mfpr    $18, r1
db> t/t
Process 650
          PCB contents:
  KSP = 0x8413fb7c
  ESP = 0x8413e064
  SSP = 0x80338200
  USP = 0x7fffea88
  R[00] = 0x00000001       R[06] = 0x80338200
  R[01] = 0x80338200       R[07] = 0x813feb20
  R[02] = 0x80246084       R[08] = 0x00000000
  R[03] = 0x0000001f       R[09] = 0x00000000
  R[04] = 0x0000001f       R[10] = 0x801aa200
  R[05] = 0x00000000       R[11] = 0x8413fe9c
  AP = 0x8413fbb0
  FP = 0x8413fb88
  PC = 0x8011b27f
  PSL = 0xdf0004
  Trap frame pointer: 0x8413ffb4
Stack traceback :
db> t 0x8413fb88
Stack traceback :
db> c                                                                         ^[Stopped in pid 650.1 (tar) at   netbsd:cpu_Debugger+0x15:       mfpr    $18, r1
db> x/x 0x8413fb88,8
0x8413fb88:     1263000     0           823c9000    1000        1           1
0x8413fba0:     800efe5c    80156aea
db> x/i 80156aea
netbsd:genfs_putpages+0xb18:    addl3   -4294967308(fp), $1, r0
db> t 80156aea
Stack traceback :
0x80156aea: 0xab31ff1e(panic: Segv in kernel mode: pc 801b3b0e addr cd019105
Stopped in pid 650.1 (tar) at    netbsd:trap+0x506:      m
ovl     $1, -4294967360(fp)
db> t
panic: Segv in kernel mode: pc %x addr %x
Stack traceback :
0x80337bb0: trap+0x506(0x80337c78)
0x80337c78: trap type=0x8 code=0xcd019105 pc=0x801b3b0e psl=0x41f0008
0x80337c44: db_dump_stack+0x68(0x80156aea,0,0x80128e58)
0x80337cd0: db_stack_trace_print+0x1f5(0x80156aea,0x1,0xffff,0x80337d78,0x80128e
58)
0x80337d10: db_stack_trace_cmd+0x67(0x80156aea,0x1,0xffffffff,0x80337d78)
0x80337d50: db_command+0x13e(0x80203190,0x801d3e9c)
0x80337dfc: db_command_loop+0xd0(void)
0x80337e54: db_trap+0xf1(0x11,0)
0x80337e78: kdb_trap+0x106(0x80337f40)
0x80337ea4: trap+0x2f4(0x80337f40)
0x80337f40: trap type=0x11 code=0x0 pc=0x801b41e3 psl=0x40e0000
0x80337f0c: cpu_Debugger+0x15(void)
0x80337f90: dzrint+0x14e(0x81fde800)
0x80337fac: start+0x149(0x8413fd28)
0x8413fcf4: VOP_PUTPAGES+0x30(0x811d8558,0x1260000,0,0x1270000,0,0x1)
0x8413fd48: ffs_write+0x350(0x8413fe10)
0x8413fddc: VOP_WRITE+0x2f(0x811d8558,0x8413fe9c,0x10,0x80c8b544)
0x8413fe28: vn_write+0xbc(0x80c967c0,0x80c967ec,0x8413fe9c,0x80c8b544,0x1)
0x8413fe58: dofilewrite+0x6f(0x813feb20,0x5,0x80c967c0,0x89648,0x2800,0x80c967ec
,0x1,0x8413ff74)
0x8413fed0: sys_write+0x4c(0x813feb20,0x8413ff54,0x8413ff74)
0x8413ff24: syscall_plain+0x8f(0x8413ffb4)


--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA