ahc/ahd locking

Matthew Dillon dillon at apollo.backplane.com
Sun Jan 13 17:43:17 PST 2008


:And I just got a crash:
:
:panic: softdep_deallocate_dependencies: dangling deps
:mp_lock =3D 00000000; cpuid =3D 0
:...
:softdep_deallocate_dependencies(c4050f54) at softdep_deallocate_dependencie=
:s+0x19
:brelse(c4050f54) at brelse+0x1ff
:bqrelse(c4050f54) at bqrelse+0x145
:biodone(c4050ff4,da130818,c4050f54) at biodone+0x463
:dadone(c3c63fb8,e5f33e50,c039d31c,ff800000,d9f4ecb4) at dadone+0x2d8
:camisr(d9f4ed84,c01841a3,0,0,43b1) at camisr+0x29b
:swi_cambio(0,0) at swi_cambio+0xd
:ithread_handler(43,0,0,0,0) at ithread_handler+0x123
:lwkt_exit() at lwkt_exit
:boot() called on cpu#0
:Uptime: 4h48m49s
:
:And so on...
:
:So my question is there something wrong with the locking in ahd that is
:causing cam (da) to have problems, or is this just a coincidence and the
:real problem is in cam (da). Unfortunately, no crash dump available.
:
:--Peter

    That seems more softupdatesish.  I haven't seen that particular panic
    in a long time but it's possible that something got corrupted on-disk
    during your testing.  Softupdates is ultra sensitive to disk corruption.

    If cam/ahc/ahd were losing track of an IO it would most like panic
    with 'biodone: bp %p already done!' or something like that.

						-Matt





More information about the Kernel mailing list