joel.bertr...@systella.fr (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: > Hello,
> I can see some panics on a server that exports iSCSI volumes (istgt on >a CCB device) to some workstations. dmesg always contains this kind of >backtrace : That would be on the workstation that uses the volumes unless your server would also be a client. >[ 308324,087343] S-1C-1: ccb_timeout: num=1 total=1 disp=0 >[ 308324,087343] uvm_fault(0xffffffff81585e20, 0x0, 2) -> e >[ 308324,087343] fatal page fault in supervisor mode >[ 308324,087343] trap type 6 code 0x2 rip 0xffffffff802280cc cs 0x8 >rflags 0x10246 cr2 0x10 ilevel 0 rsp 0xffff97813fa16f48 A NULL pointer dereference... >[ 308324,087343] curlwp 0xffffc947d4f304c0 pid 0.201 lowest kstack >0xffff97813fa142c0 >[ 308324,087343] panic: trap >[ 308324,087343] cpu1: Begin traceback... >[ 308324,087343] vpanic() at netbsd:vpanic+0x160 >[ 308324,087343] snprintf() at netbsd:snprintf >[ 308324,087343] startlwp() at netbsd:startlwp >[ 308324,087343] alltraps() at netbsd:alltraps+0xbb >[ 308324,087343] ccb_timeout() at iscsi:ccb_timeout+0xf0 >[ 308324,087343] iscsi_cleanup_thread() at iscsi:iscsi_cleanup_thread+0x2b6 in something called by ccb_timeout(). If you have a version of the kernel with debug symbols, you could use addr2line to identify the instruction that caused the uvm_fault at address 0xffffffff802280cc. Without debug symbols it is not that easy.
