Date: Tue, 15 Jul 2008 16:05:56 +0300 From: "Yony Yossef" <yonyossef.lists@gmail.com> To: "Kris Kennaway" <kris@freebsd.org> Cc: freebsd-questions@freebsd.org Subject: Re: options WITNESS and locks Message-ID: <20def4870807150605w6e3de82eq4a999360e9b49b6c@mail.gmail.com> In-Reply-To: <487BE91E.1020202@FreeBSD.org> References: <20def4870807140902y4e5aad69r649d577fb5f5ad84@mail.gmail.com> <487BE91E.1020202@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Kris, Please see below > Hi all. >> >> I'm trying to debug a "spinlock held too long" error. >> Therefore I thought compiling my kernel with "options WITNESS" would be a >> good idea. >> >> Using the WITNESS kernel I cannot load my driver with any MTX_SPIN mutex. >> I had to change it all to MTX_DEF since every MTX_SPIN got me this error: >> >> panic: lock (network driver) spin mutex does not match earlier (sleep >> mutex) >> lock >> > > It means that somewhere you are treating a mutex with that name as a sleep > mutex and in other places as a spin mutex. WITNESS works on the lock name > so this may or may not be a bug. > > However, default mutexes should be used in most cases anyway (bear in mind > that default mutexes will also spin when it makes sense for them to do so). > > So I changed it all to MTX_DEF, just to see if things will work. >> Now I can load my driver, but calling ifconfig shows a new crash: >> >> mtnic0: Activating port:1 >> mtnic0: Ethernet address: 00:00:00:00:08:88 >> mtnic0: Activating port:2 >> mtnic1: Ethernet address: 00:00:00:00:08:89 >> lock order reversal: (sleepable after non-sleepable) >> 1st 0xffffffff81379010 MTNIC state semaphore (MTNIC state semaphore) @ >> mtnic_netdev.c:1855 >> 2nd 0xffffffff809eee00 ACPI root bus (ACPI root bus) @ >> /usr/src/sys/dev/acpica/acpi.c:1022 >> > > You are acquiring a lock that is "sleepable" (i.e. legal for consumers to > sleep while holding it), after first acquiring another lock that is not > sleepable. The danger is that if some code sleeps while holding both the > first and second lock, then other code that tries to acquire the first lock > will deadlock indefinitely. > > This is often due to a programming or design error. > > Kris Something is still unclear. All my locks are MTX_DEF type, which means sleepable, including the one specified in the crash report (MTNIC state semaphore). This crash happens when I try to call bus_resource_alloc_any for a SYS_REQ which is trying to obtain the second lock (ACPI root bus). How come my MTX_DEF lock is being treated as as non-sleepable? > > > KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> witness_checkorder() at witness_checkorder+0x559 >> _sx_xlock() at _sx_xlock+0x32 >> acpi_alloc_resource() at acpi_alloc_resource+0x9a >> pci_alloc_resource() at pci_alloc_resource+0x81 >> resource_list_alloc() at resource_list_alloc+0x17a >> pci_alloc_resource() at pci_alloc_resource+0x81 >> bus_alloc_resource() at bus_alloc_resource+0x89 >> mtnic_start_port() at mtnic_start_port+0x4f1 >> mtnic_open() at mtnic_open+0xb2 >> ether_ioctl() at ether_ioctl+0xb5 >> mtnic_ioctl() at mtnic_ioctl+0x3e >> in_ifinit() at in_ifinit+0x8d >> in_control() at in_control+0xc66 >> ifioctl() at ifioctl+0xea >> kern_ioctl() at kern_ioctl+0xa3 >> ioctl() at ioctl+0xf9 >> syscall() at syscall+0x1b5 >> Xfast_syscall() at Xfast_syscall+0xab >> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800824cfc, rsp = >> 0x7fffffffe3b8, rbp = 0x7fffffffee10 --- >> KDB: enter: witness_checkorder >> [thread pid 1051 tid 100069 ] >> Stopped at kdb_enter+0x31: leave >> db> >> >> >> Can anybody please tell me what is going on here? >> >> -Yony >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to " >> freebsd-questions-unsubscribe@freebsd.org" >> >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20def4870807150605w6e3de82eq4a999360e9b49b6c>