kern/109762: deadlock in g_down -> ahd_action -> contigmalloc

Andrew andrew+pr2 at supernews.net
Fri Mar 2 18:20:05 UTC 2007


>Number:         109762
>Category:       kern
>Synopsis:       deadlock in g_down -> ahd_action -> contigmalloc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 02 18:20:04 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Andrew
>Release:        FreeBSD 6.2-20070202
>Organization:
Critical Path, Inc
>Environment:
FreeBSD volcano.supernews.net 6.2-20070202 FreeBSD 6.2-20070202 #0: Fri Feb  2 16:29:10 UTC 2007     root at supernews.net:/usr/obj/usr/src/sys/SUPERNEWS  i386

>Description:
System hung during heavy file write activity (copying a large file between filesystems). The cause of the hang was g_down being stuck as follows:

Tracing pid 4 tid 100016 td 0xa8303a80
sched_switch(a8303a80,0,1) at sched_switch+0x14b
mi_switch(1,0,a8303a80,ca4249c4,a0515704,...) at mi_switch+0x1ba
sleepq_switch(bc3927f0) at sleepq_switch+0x87
sleepq_wait(bc3927f0,0,a8303a80,44,bc3927f0,...) at sleepq_wait+0x5c
msleep(bc3927f0,a073c7a0,44,a06f43d5,0) at msleep+0x269
bwait(bc3927f0,44,a06f43d5,bc3927f0,0,...) at bwait+0x5f
swap_pager_putpages(ac2d318c,ca424ac4,1,1,ca424a90,...) at swap_pager_putpages+0x48c
default_pager_putpages(ac2d318c,ca424ac4,1,1,ca424a90) at default_pager_putpages+0x18
vm_pageout_flush(ca424ac4,1,1) at vm_pageout_flush+0xcb
vm_contig_launder_page(a49de288) at vm_contig_launder_page+0x2a6
vm_page_alloc_contig(3,0,0,ffffffff,8,0) at vm_page_alloc_contig+0x25c
contigmalloc(3000,a0710ea0,1,0,ffffffff,...) at contigmalloc+0x97
bus_dmamem_alloc(a83d3e80,ab998618,1,ab998610) at bus_dmamem_alloc+0xb4
ahd_alloc_scbs(a8415000) at ahd_alloc_scbs+0x17a
ahd_get_scb(a8415000,8) at ahd_get_scb+0x57
ahd_action(a83f82c0,ab8a4800) at ahd_action+0x103
xpt_run_dev_sendq(a83f8280) at xpt_run_dev_sendq+0x175
xpt_action(ab8a4800) at xpt_action+0x269
dastart(a862c600,ab8a4800,ab8a4800,a86254c0,1) at dastart+0x149
xpt_run_dev_allocq(a83f8280) at xpt_run_dev_allocq+0x82
xpt_schedule(a862c600,1,a9da5bdc,ca424ce8,a04bd420,...) at xpt_schedule+0xef
dastrategy(a9da5bdc) at dastrategy+0x4a
g_disk_start(a9da5528) at g_disk_start+0x18c
g_io_schedule_down(a8303a80) at g_io_schedule_down+0x13b
g_down_procbody(0,ca424d38) at g_down_procbody+0x92
fork_exit(a04bf00c,0,ca424d38) at fork_exit+0x71
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xca424d6c, ebp = 0 ---

Clearly, having g_down waiting for a swap pageout to complete is a deadlock.

The circumstances under which this happens are not particularly clear - at the point of the hang, most of the system memory was in the 'inactive' queue, but the amount of free and/or cached memory was substantial. Machine has 4GB of RAM of which about 3.3GB is usable (i386, no PAE). Inactive memory was about 2.2GB, cache 900M, free 5M.

This has been observed twice so far, though attempts to reproduce it in a consistent fashion have failed and it seems to be relatively rare.


>How-To-Repeat:
Initiate a burst of heavy i/o via the ahd driver, such as copying multi-gigabyte files or using dd to create same. The other conditions needed for it to happen are not known.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list