From owner-freebsd-arch@FreeBSD.ORG Mon Mar 22 15:13:15 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EABF106566C; Mon, 22 Mar 2010 15:13:15 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 403A88FC0C; Mon, 22 Mar 2010 15:13:14 +0000 (UTC) Received: by fxm24 with SMTP id 24so1747017fxm.3 for ; Mon, 22 Mar 2010 08:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=DsRv+5AHwNnZAxbyt2GiWovNe3F9FVZXx5YY0zZIM3k=; b=cMFUq1MxzJL1ie5YQCMyJKtoccBfrg6XvNvcgOne9/4RllPgIR3Yrn3l+cVk0is0a/ dDcpF6X4W6p9ecQKE44WTPgxGfPQrWVNqGEuyPch1CX1NTem3GJfUnCWHqebvmojicuS A4jlQGYXlBLIrnutF645ShZ7mpeEOatO+ztaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=vfmy+Ly6x0Efvy4ohd+N4UjfdonSCczYib5P6Knfvs6azXETqPnPeJED1YuhOD0OyX +Pco24Lzt0MoTieJahGIyCsSEErWLHpUGgvcwdlcu6Tw16gyCvE5MU/7RkIoM/YinWym PLBTfOHfP6je0B8POWS4APM3s6r2+VoiP+56E= Received: by 10.223.58.83 with SMTP id f19mr2826229fah.88.1269270793405; Mon, 22 Mar 2010 08:13:13 -0700 (PDT) Received: from centel.dataix.local (ppp-21.63.dialinfree.com [209.172.21.63]) by mx.google.com with ESMTPS id 13sm3894781fxm.14.2010.03.22.08.12.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 08:13:12 -0700 (PDT) Sender: "J. Hellenthal" Date: Mon, 22 Mar 2010 11:11:55 -0400 From: jhell To: Alexander Motin In-Reply-To: <4BA705CB.9090705@FreeBSD.org> Message-ID: 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> <4BA705CB.9090705@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: Increasing MAXPHYS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 15:13:15 -0000 On Mon, 22 Mar 2010 01:53, Alexander Motin wrote: In Message-Id: <4BA705CB.9090705@FreeBSD.org> > 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. > I just wanted to see what I could break; when I increased DFLTPHYS it was just for that purpose. It booted and everything was running after. Wasn't long enough to do any damage. > 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? > > atapci0@pci0:0:31:1: class=0x01018a card=0x01271028 chip=0x24cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL (ICH4/ICH4-L) UltraATA/100 EIDE Controller' class = mass storage subclass = ATA I do not have any diagnostics but if any are requested I do have the kernel's that I have tuned to the above values readily available to run again. The first time I tuned MAXPHYS was roughly about 7 weeks ago. That was until I noticed I could not get a crash dump for a problem I was having a week later and had to revert back to its default setting of 128. The problem I had a week later was unrelated. Two days ago when I saw this thread I recalled having modified MAXPHYS but could not remember the problem it caused so I re-enabled it again to reproduce the problem for sureness. Anything else you need please address, Regards, -- jhell