On Fri, Aug 12, 2005 at 08:43:26PM -0400, Kris Kennaway wrote: > I have an SMP amd64 package machine that has deadlocked, apparently > here: > > --- trap 0x13, rip = 0xffffffff8034b2a1, rsp = 0xffffffffbe6f2a10, rbp = 0xffffffffbe6f2a40 --- > devfs_create() at devfs_create+0x41 > make_dev_credv() at make_dev_credv+0x148 > make_dev() at make_dev+0x97 > g_dev_taste() at g_dev_taste+0x130 > g_new_provider_event() at g_new_provider_event+0x8a > one_event() at one_event+0x19b > g_run_events() at g_run_events+0x9 > g_event_procbody() at g_event_procbody+0x7d > fork_exit() at fork_exit+0xdf > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffbe6f2d00, rbp = 0 --- > > If I break/continue and examine devfs_nextino, it appears to be > looping infinitely in devfs_create: > > db> x/d devfs_nextino > devfs_nextino: 746 > [...] > db> x/d devfs_nextino > devfs_nextino: 339 > > This machine has a number of md mounts active (they are created and > destroyed dynamically and tend to get up to high unit numbers, around > ~600 at the time of deadlock). Also devfs mounts come and go, but I > don't think anything else unusual is going on on the system. This could explain some mysterious deadlocks I've been getting on sparc machines too, which also cycle through md devices in a similar way. I bet something is not being cleaned up properly when the devices are unconfigured, and eventually devfs is filling up all available inodes (1024) and failing gracelessly. Kris
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:41 UTC