From owner-svn-src-head@FreeBSD.ORG Fri Aug 29 17:52:18 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCAED6A5; Fri, 29 Aug 2014 17:52:18 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E10631E5B; Fri, 29 Aug 2014 17:52:17 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id q5so2944453wiv.12 for ; Fri, 29 Aug 2014 10:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eEgoVDpk74fapCMcMXMPZ2ZDYqZynWR1jpwew2RxqYA=; b=JV2dbAZKXq+Ys2ZDNEP7iV+Xh4X3ZcT07IG9G99ztN8GUHLFu8BLiyQ4TrFqQPkurK AiW4pXMzu+SkS92M1mcR0ReRICpun6hRVbPcgxDPpbtGg3wl72VsdK25BJ9NjR1UVSsT hdAxIsi8uugzc1TXjzn08LxGN9ECkMcqz8E1PtSGQ9FucWGsRgRwSXEbLWJbZi+JlELS 59Qvm5to+T3Kfa0Gp/h0S18spGWgwP/8roRcteXiutw0uEuevVAFpx3jNfhUXsDjhUoh ijhtgDxOcBjcnWP8w+cpZsf0VFE9tEtP4vpy8rGEtDjE9jczeOpO3T9GehcyhSSePhPz LO7A== X-Received: by 10.180.37.241 with SMTP id b17mr5447989wik.70.1409334736031; Fri, 29 Aug 2014 10:52:16 -0700 (PDT) Received: from [172.16.1.30] (124.Red-83-33-238.dynamicIP.rima-tde.net. [83.33.238.124]) by mx.google.com with ESMTPSA id ll20sm2055708wic.14.2014.08.29.10.52.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Aug 2014 10:52:15 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <5400BDC7.7020902@FreeBSD.org> Date: Fri, 29 Aug 2014 19:52:07 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alexander Motin , John-Mark Gurney Subject: Re: svn commit: r269814 - head/sys/dev/xen/blkfront References: <53e8e31e.2179.30c1c657@svn.freebsd.org> <53FF7386.3050804@FreeBSD.org> <20140828184515.GV71691@funkthat.com> <53FF7BC4.6050801@FreeBSD.org> In-Reply-To: <53FF7BC4.6050801@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:52:18 -0000 El 28/08/14 a les 20.58, Alexander Motin ha escrit: > On 28.08.2014 21:45, John-Mark Gurney wrote: >> Alexander Motin wrote this message on Thu, Aug 28, 2014 at 21:23 +0300: >>> Hi, Roger. >>> >>> It looks to me like this commit does not work as it should. I got >>> problem when I just tried `newfs /dev/ada0 ; mount /dev/ada0 /mnt`. >>> Somehow newfs does not produce valid filesystem. Problem is reliably >>> repeatable and reverting this commit fixes it. >>> >>> I found at least one possible cause there: If original data buffer is >>> unmapped, misaligned and not physically contiguous, then present x86 >>> bus_dmamap_load_bio() implementation will process each physically >>> contiguous segment separately. Due to the misalignment first and last >>> physical segments may have size not multiple to 512 bytes. Since each >>> segment processed separately, they are not joined together, and >>> xbd_queue_cb() is getting segments not multiple to 512 bytes. Attempt to >>> convert them to exact number of sectors in the driver cause data corruption. >> >> Are you sure this isn't a problem w/ the tag not properly specifying >> the correct alignement? > > I don't know how to specify it stronger then this: > error = bus_dma_tag_create( > bus_get_dma_tag(sc->xbd_dev), /* parent */ > 512, PAGE_SIZE, /* algnmnt, boundary */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > sc->xbd_max_request_size, > sc->xbd_max_request_segments, > PAGE_SIZE, /* maxsegsize */ > BUS_DMA_ALLOCNOW, /* flags */ > busdma_lock_mutex, /* lockfunc */ > &sc->xbd_io_lock, /* lockarg */ > &sc->xbd_io_dmat); > >> Also, I don't think there is a way for busdma >> to say that you MUST have a segment be a multiple of 512, though you >> could use a 512 boundary, but that would force all segments to only be >> 512 bytes... > > As I understand, that is mandatory requirement for this "hardware". > Alike 4K alignment requirement also exist at least for SDHCI, and IIRC > UHCI/OHCI hardware. Even AHCI requires both segment addresses and > lengths to be even. > > I may be wrong, but I think it is quite likely that hardware that > requires segment address alignment quite likely will have the same > requirements for segments length. I've been able to trigger it quite easily by adding the following KASSERTs and got a "panic: Invalid segment size 2080". I will try to look into it tomorrow, or else revert the commit. Thanks for noticing. Roger. --- diff --git a/sys/dev/xen/blkfront/blkfront.c b/sys/dev/xen/blkfront/blkfront.c index 7a1c974..6226534 100644 --- a/sys/dev/xen/blkfront/blkfront.c +++ b/sys/dev/xen/blkfront/blkfront.c @@ -199,6 +199,13 @@ xbd_queue_cb(void *arg, bus_dma_segment_t *segs, int nsegs, int error) while (1) { while (sg < last_block_sg) { + + KASSERT((segs->ds_len % 512) == 0, + ("Invalid segment size %u", segs->ds_len)); + KASSERT((segs->ds_addr % 512) == 0, + ("Invalid segment alignment ds_addr: %jx", + (uintmax_t) segs->ds_addr)); + buffer_ma = segs->ds_addr; fsect = (buffer_ma & PAGE_MASK) >> XBD_SECTOR_SHFT; lsect = fsect + (segs->ds_len >> XBD_SECTOR_SHFT) - 1;