Date: Mon, 20 Jan 2003 20:29:46 +0100 From: Thomas Moestl <tmm@freebsd.org> To: Harti Brandt <brandt@fokus.gmd.de> Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030120192946.GB240@crow.dom2ip.de> In-Reply-To: <20030120161832.K45050@beagle.fokus.gmd.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003/01/20 at 16:40:56 +0100, Harti Brandt wrote: > On Mon, 20 Jan 2003, Thomas Moestl wrote: > > TM>On Mon, 2003/01/20 at 10:52:11 +0100, Harti Brandt wrote: > TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote: > TM>> > TM>> Just while I could not sleep last night, it occured to me, that the code > TM>> should work without even this change when the kernel is compiled with gcc. > TM>> The code in iommu.c and bus_machdep.c use #ifdef __GNUC__ to use dynamic > TM>> arrays on stack that have size ddmat->dt_nsegements size. So if I create a > TM>> tag with a number of segments large enough, the arrays should be large > TM>> enough. The only problem should be, that the size check around line 823 in > TM>> iommu.c should also be conditionalized (for __GCC__ BUS_DMAMAP_NSEGS > TM>> should not be checked.) Well, for some reason, that seems not to work. > TM> > TM>Hmmm, how does it fail? > > Trying to send a 60000 byte PDU gives me the following: > > hatm0: <FORE HE> mem 0x100000-0x1fffff irq 20 at device 2.0 on pci1 > hatm: hw.hatm0.rbps0.size=32 > hatm: hw.hatm0.rbps0.thresh=8 > hatm: hw.hatm0.rbpl0.size=32 > hatm: hw.hatm0.rbpl0.thresh=8 > hatm: hw.hatm0.rbps1.size=32 > hatm: hw.hatm0.rbps1.thresh=8 > hatm0: ForeRunnerHE 155, Rev. B, S/N 5705534, MAC=00:20:48:57:0f:3e > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > iommu_dvmamap_load_buffer: too many segments. > seg[0]=tpd[1,0]=c02d8800/2048 > seg[1]=tpd[1,1]=c02da800/2048 > seg[2]=tpd[1,2]=c02dd000/2048 > seg[3]=tpd[2,0]=c02de800/2048 > seg[4]=tpd[2,1]=c02e0000/2048 > seg[5]=tpd[2,2]=c02e3800/2048 > seg[6]=tpd[3,0]=c02e5000/2048 > seg[7]=tpd[3,1]=c02e6800/2048 > seg[8]=tpd[3,2]=c02e8000/2048 > seg[9]=tpd[4,0]=c02eb800/2048 > seg[10]=tpd[4,1]=c02ed000/2048 > seg[11]=tpd[4,2]=c02ee800/2048 > seg[12]=tpd[5,0]=c02f0000/2048 > seg[13]=tpd[5,1]=c0c67800/2048 > seg[14]=tpd[5,2]=c0c69000/2048 > seg[15]=tpd[6,0]=c0c6a800/2048 > seg[16]=tpd[6,1]=c0c6c000/2048 > seg[17]=tpd[6,2]=17f02cc0/1077936128 > seg[18]=tpd[7,0]=1/3438465064 > seg[19]=tpd[7,1]=ccf2d010/3438465048 > seg[20]=tpd[7,2]=ccf2c711/3222760340 > seg[21]=tpd[8,0]=f/0 > seg[22]=tpd[8,1]=432a330/324612608 > seg[23]=tpd[8,2]=1390b550/77178368 > seg[24]=tpd[9,0]=16d20570/0 > seg[25]=tpd[9,1]=ccf2da80/3223451912 > seg[26]=tpd[9,2]=7def510/132025856 > seg[27]=tpd[10,0]=0/0 > seg[28]=tpd[10,1]=17f178c0/0 > seg[29]=tpd[10,2]=0/1077936128 > > Starting at seg[17] the segments are simply wrong. The number of segments > in the tag is 39 so this should work. (The numbers are the phys address > and segment length). Hmmmm, looks like the printf() part of the size check is still intact, did you forget to remove the break statement maybe? I don't see anything else that would make it stop exactly at BUS_DMAMAP_NSEGS. > TM>>From a quick inspection, I can see one class of problems (which might > TM>or might not be the cause for this specific behaviour, but will cause > TM>trouble in any case): you need to do endiannes conversions for memory > TM>that is accessed by DMA and interpreted or written by the > TM>adapter. Since it is a PCI card, it operates on little-endian > TM>data. While the bus_space_* functions know the access size and will > [...] > > The card is desgined for operation in LE and BE systems. It has a register > where you set bits which tell the card to swap the data during DMA. There > is a function hatm_init_endianess, which sets the right bits. Ahhh, sorry, I didn't notice that. Nifty feature. > This is really not the problem. When I create tx_tag with a maximum of 1 > segment, the receive function of the card works (that means interrupt > status is correctly processed, receive queues and buffers are correctly > red and written). When I create tx_tag with a number of segments > 1 than > only creating a couple of DMA maps with this tag (not using them at all) > entirly confuses operation. > > But as I said already - with your patch applied it seems to work (albeit > not very stable, but this may be my fault). Yes, but I strongly suspect that the bug is only hidden by it, probably because it corrects the semantics of IOMMU_MAX_PRE_SEG, which effectively results in preallocation being reduced by one segment. I finally managed to reproduce similar behaviour, and think I might have a real fix. Can you please revert the previous patch (just to get a clean environment for reproducing the behaviour) and try again with just the attached patch applied? Thanks, - Thomas -- Thomas Moestl <tmoestl@gmx.net> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C 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?20030120192946.GB240>