Date: Tue, 21 Jan 2003 11:46:55 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Thomas Moestl <tmm@freebsd.org> Cc: Harti Brandt <brandt@fokus.gmd.de>, "" <sparc@freebsd.org> Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030121114313.O80603@beagle.fokus.gmd.de> In-Reply-To: <20030120192946.GB240@crow.dom2ip.de> References: <20030117151958.U715@beagle.fokus.gmd.de> <20030117160857.GB304@crow.dom2ip.de> <20030117171317.F44530@beagle.fokus.gmd.de> <20030117171111.GC304@crow.dom2ip.de> <20030117181111.R45050@beagle.fokus.gmd.de> <20030117173303.GD304@crow.dom2ip.de> <20030120103814.X45050@beagle.fokus.gmd.de> <20030120151712.GA240@crow.dom2ip.de> <20030120161832.K45050@beagle.fokus.gmd.de> <20030120192946.GB240@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Jan 2003, Thomas Moestl wrote: TM>On Mon, 2003/01/20 at 16:40:56 +0100, Harti Brandt wrote: TM>> On Mon, 20 Jan 2003, Thomas Moestl wrote: TM>> TM>> seg[15]=tpd[6,0]=c0c6a800/2048 TM>> seg[16]=tpd[6,1]=c0c6c000/2048 TM>> seg[17]=tpd[6,2]=17f02cc0/1077936128 TM>> seg[18]=tpd[7,0]=1/3438465064 TM>> seg[19]=tpd[7,1]=ccf2d010/3438465048 TM>> seg[20]=tpd[7,2]=ccf2c711/3222760340 TM>> seg[21]=tpd[8,0]=f/0 TM>> seg[22]=tpd[8,1]=432a330/324612608 TM>> seg[23]=tpd[8,2]=1390b550/77178368 TM>> seg[24]=tpd[9,0]=16d20570/0 TM>> seg[25]=tpd[9,1]=ccf2da80/3223451912 TM>> seg[26]=tpd[9,2]=7def510/132025856 TM>> seg[27]=tpd[10,0]=0/0 TM>> seg[28]=tpd[10,1]=17f178c0/0 TM>> seg[29]=tpd[10,2]=0/1077936128 TM>> TM>> Starting at seg[17] the segments are simply wrong. The number of segments TM>> in the tag is 39 so this should work. (The numbers are the phys address TM>> and segment length). TM> TM>Hmmmm, looks like the printf() part of the size check is still intact, TM>did you forget to remove the break statement maybe? I don't see TM>anything else that would make it stop exactly at BUS_DMAMAP_NSEGS. With the attached patch it looks better - it removes the check for BUS_DMAMAP_NSEGS and also adds a break for promoting the error from load_buffer back to load_mbuf and exit the loop there in case of an error. (Sorry, the patch contains also the patch that you sent in your last mail). TM>Yes, but I strongly suspect that the bug is only hidden by it, TM>probably because it corrects the semantics of IOMMU_MAX_PRE_SEG, which TM>effectively results in preallocation being reduced by one segment. I TM>finally managed to reproduce similar behaviour, and think I might have TM>a real fix. Can you please revert the previous patch (just to get a TM>clean environment for reproducing the behaviour) and try again with TM>just the attached patch applied? That seems to work. I have reverted both the change to subr_rman.c and iommu.c (1.14) before applying your patch. Thanks, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030121114313.O80603>