Date: Mon, 22 Mar 2010 07:53:15 +0200 From: Alexander Motin <mav@FreeBSD.org> To: jhell <jhell@DataIX.net> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS Message-ID: <4BA705CB.9090705@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.1003212158190.16103@qvfongpu.qngnvk.ybpny> References: <4BA4E7A9.3070502@FreeBSD.org> <201003201753.o2KHrH5x003946@apollo.backplane.com> <891E2580-8DE3-4B82-81C4-F2C07735A854@samsco.org> <4BA52179.9030903@FreeBSD.org> <4BA532FF.6040407@elischer.org> <4BA62757.7090400@FreeBSD.org> <alpine.BSF.2.00.1003212045540.16103@qvfongpu.qngnvk.ybpny> <alpine.BSF.2.00.1003212158190.16103@qvfongpu.qngnvk.ybpny>
next in thread | previous in thread | raw e-mail | index | archive | help
jhell wrote: > On Sun, 21 Mar 2010 20:54, jhell@ wrote: >> I played with it on one re-compile of a kernel and for the sake of it >> DFLTPHYS=128 MAXPHYS=256 and found out that I could not cause a crash >> dump to be performed upon request (reboot -d) due to the boundary >> being hit for DMA which is 65536. Obviously this would have to be >> adjusted in ata-dma.c. >> >> I suppose that there would have to be a better way to get the real >> allowable boundary from the running system instead of setting it >> statically. >> >> Other then the above I do not see a reason why not... It is HEAD and >> this is the type of experimental stuff it was meant for. > > I should have also said that I also repeated the above without setting > DFLTPHYS and setting MAXPHYS to 256. It was bad idea to increase DFLTPHYS. It is not intended to be increased. About DMA boundary, I do not very understand the problem. Yes, legacy ATA has DMA boundary of 64K, but there is no problem to submit S/G list of several segments. How long ago have you tried it, on which controller and which diagnostics do you have? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BA705CB.9090705>