Date: Fri, 17 Jan 2003 18:19:59 +0100 (CET) From: Harti Brandt <brandt@fokus.gmd.de> To: Thomas Moestl <tmm@freebsd.org> Cc: sparc@freebsd.org Subject: Re: Problem with iommu_dvmamap_create Message-ID: <20030117181111.R45050@beagle.fokus.gmd.de> In-Reply-To: <20030117171111.GC304@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Jan 2003, Thomas Moestl wrote: TM>On Fri, 2003/01/17 at 17:30:13 +0100, Harti Brandt wrote: TM>> On Fri, 17 Jan 2003, Thomas Moestl wrote: TM>> TM>Hmmm, allocating with a size of 0 would of course be a bug, but I fail to TM>> TM>see what would cause presz to be 0 in the first place in your example - TM>> TM>maxpre will be IOMMU_MAX_PRE_SEG = 3 then, so (64k-1) / 3 = 21845. TM>> TM>It will always be > 0 if maxsize > min(maxseg, IOMMU_PRE_SEG), and all TM>> TM>else would be a bogus tag. TM>> TM>> Oh well, I see, I got it wrong. I was confused by all these MAX_PRE and TM>> maxpres. TM>> TM>> On a related topic. I just got a panic when actually using the map. There TM>> are two problems: the first is the definition of BUS_DMAMAP_NSEGS. These TM>> seems to be 128k/8k = 16. On the other hand MCLBYTES is 2048 so that a 64k TM>> PDU is segmented into 32 or more mbufs. I think, that NSEGS should be TM>> large enough to handle 64k PDUs so it should probably be 40 or so. TM> TM>BUS_DMAMAP_NSEGS (and BUS_SPACE_MAXSIZE) is pretty arbitrary, the only TM>thing to limit is the stack space used by the segment array. In the TM>current setting, 272 bytes are used at most, which is less than 1.5 TM>minimal function frames. Values such as 64 should still be OK. Would it be possible if you change it just there? TM>Thanks. Looking at the code you pasted above, I'm afraid that they TM>won't help though. The only possibility for a simple map creation to TM>break things in that way is that it changes the available DVMA space TM>and may cause this or other maps to be pruned. In both cases, another TM>driver must be using DMA already or do load or unload operations for TM>this to take any effect. So, can you please tell me which other TM>DMA-using devices you have in that box, so that I can try to figure TM>out the possible interactions? I have an ATA controller from which I boot, a hme card and an adaptec 29160, but I don't use the SCSI disk at the moment. What I did to trigger the error was: 1) compile the code with the '3 * HE_....' changed to 1. 2) install, kldload, ifconfig up -> ok 3) compile the original code 3) kldunload, install, kldload, ifconfig up -> baaaah 'baaaah' means, that a lot of strange things happen: the driver gets a lot of interrupts, but the interrupt status words (these are written per DMA) are invalid. when kldunloading sometimes I get a repeated loop of 'fast data mmu ... miss' and ddb prompts. After booting (I need to switch the machine off to do this!) the nvram checksum is usually bad and the machine ofw status is reset. I tried to find the problem for 3 days now.... With your patch applied things seem better, but I still fail to see why :-) 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?20030117181111.R45050>