Re: port-amd64/53155: OS wedges after <12h uptime when >2 bnx network interfaces in use

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR port-amd64/53155; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-amd64/53155: OS wedges after <12h uptime when >2 bnx network interfaces in use
Date: Fri, 6 Apr 2018 05:38:13 -0000 (UTC)

 he%NetBSD.org@localhost (Havard Eidnes) writes:
 
 >I don't even know how to identify which process this is, perhaps
 >other than doing a backtrace of each and every process on the
 >system at the time of the wedge.
 
 The ps output has marked the processes running on a CPU:
 
  >  PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
  >  6110 :   1 7   3         0   fffffe821e439080             expect
  >  855  :   1 7   6         0   fffffe820e54e100             expect
  >  759  :   1 7   1         0   fffffe822962bac0             master
  >  342  :   2 7   0         0   fffffe822d7a1180              dhcpd
  >  0    : 119 7   7       200   fffffe822dce8100            ioflush
  >  0    :  59 7   5       200   fffffe810eb61aa0               ipmi
  >  0    :  35 7   4       201   fffffe810e9739a0             idle/4
  >  0    :   6 7   0       200   fffffe822f6eb440          softser/0
  >  0    :   3 7   0       200   fffffe822f707420          softnet/0
          ^
          |
 
 
  >>  db{0}: machine cpu 1
  >>  using CPU 1
  >>  db{0}: tra
  >>  x86_pause() at netbsd:x86_pause+0x2
  >>  cdev_open() at netbsd:cdev_open+0xaf
  >>  spec_open() at netbsd:spec_open+0x260
  >>  VOP_OPEN() at netbsd:VOP_OPEN+0x33
  >>  vn_open() at netbsd:vn_open+0x28b
  >>  do_open() at netbsd:do_open+0x112
  >>  do_sys_openat() at netbsd:do_sys_openat+0x68
  >>  sys_open() at netbsd:sys_open+0x24
  >>  syscall() at netbsd:syscall+0x1ed
 
 Assuming both outputs are from the same state: CPU 1 is running PID 759 (master).
 From "netbsd:cdev_open+0xaf" I would also think it's waiting on KERNEL_LOCK
 which is held by:
 
  >  current lwp  : 0xfffffe822f6eb440 last held: 0xfffffe822f6eb440
 
  >  0    :   6 7   0       200   fffffe822f6eb440          softser/0
 
 
 Unfortunately there is no backtrace of that LWP.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."