From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Kernel Panic in xen-blkfront.c:blkif_queue_request under 2.6.28 Date: Wed, 04 Feb 2009 08:50:00 -0800 Message-ID: <4989C738.7080005@goop.org> References: <18316821.8169281233693449109.JavaMail.root@ouachita> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18316821.8169281233693449109.JavaMail.root@ouachita> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jens Axboe Cc: Greg Harris , xen-devel List-Id: xen-devel@lists.xenproject.org Greg Harris wrote: > After applying the patch we were able to reproduce the panic and the additional debugging output is attached. The driver appears to re-try the request several times before dying: > > Writing inode tables: ------------[ cut here ]------------ > WARNING: at drivers/block/xen-blkfront.c:244 do_blkif_request+0x301/0x440() > Modules linked in: > Pid: 0, comm: swapper Not tainted 2.6.28.2-metacarta-appliance-1 #2 > Call Trace: > [] warn_on_slowpath+0x64/0xa0 > [] enqueue_task+0x13/0x30 > [] _spin_unlock_irqrestore+0x14/0x20 > [] get_free_entries+0xbc/0x2a0 > [] do_blkif_request+0x301/0x440 > [] blk_invoke_request_fn+0xa5/0x110 > [] kick_pending_request_queues+0x18/0x30 > [] blkif_interrupt+0x197/0x1e0 > [] handle_IRQ_event+0x39/0x80 > [] handle_level_irq+0x96/0x120 > [] do_IRQ+0x85/0x110 > [] xen_evtchn_do_upcall+0xe5/0x130 > [] __do_softirq+0xe7/0x180 > [] xen_do_hypervisor_callback+0x1e/0x30 > [] _stext+0x3aa/0x1000 > [] _stext+0x3aa/0x1000 > [] xen_safe_halt+0xc/0x20 > [] xen_idle+0x2a/0x50 > [] cpu_idle+0x41/0x70 > ---[ end trace 107c74ebf2b50a63 ]--- > METACARTA: too many segments for ring (11): req->nr_phys_segments = 11 > METACARTA: 0: bio page ffffe2000c291d00 pfn 379760 off 1536 len 512 > METACARTA: 0: bio page ffffe2000c291d00 pfn 379760 off 2048 len 512 > METACARTA: 0: bio page ffffe2000c291d00 pfn 379760 off 2560 len 512 > METACARTA: 0: bio page ffffe2000c291d00 pfn 379760 off 3072 len 512 > METACARTA: 0: bio page ffffe2000c291d00 pfn 379760 off 3584 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 0 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 512 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 1024 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 1536 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 2048 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 2560 len 512 > METACARTA: 0: bio page ffffe2000c291d38 pfn 379761 off 3072 len 512 > (Wonder why the index didn't increment. Missing ++?) Well, that's interesting. I count 12 bios there. Are we asking for the wrong thing, or is the block layer giving us too many bios? What's the distinction between a bio and a segment? Also, why are there so many pieces. Our main restriction is that a transfer can't cross a page boundary, but we could easily handle this request in two pieces, one for each page. Can we ask the block layer to do that merging? Thanks, J