From owner-freebsd-arch@FreeBSD.ORG Mon Jun 8 09:15:38 2009 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 B2418106566C; Mon, 8 Jun 2009 09:15:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 062C68FC1D; Mon, 8 Jun 2009 09:15:37 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 245158151; Mon, 08 Jun 2009 12:15:34 +0300 Message-ID: <4A2CD6AC.80407@FreeBSD.org> Date: Mon, 08 Jun 2009 12:15:24 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: FreeBSD-Current , freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary="------------010407070706090009080901" Cc: Subject: Multiple MSI on SMP, misrouting or misunderstanding? 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, 08 Jun 2009 09:15:39 -0000 This is a multi-part message in MIME format. --------------010407070706090009080901 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hi. While experimenting with using multiple MSIs support on AHCI controller I have got the problem. When system boots as UP - everything is fine, driver allocates all available 16 MSIs and works. But when system booted as SMP, interrupts begin to behave strange: I didn't receive expected AHCI IRQs, but instead receive IRQ1 interrupts of atkbd0, while I have no PS/2 keyboard/mouse attached. As I have found, problem appears due to IRQ rebalancing between CPUs. As I have got, MSI requires that all vectors from the same group to be allocated sequentially, but IRQ rebalancing breaks correct order, that happed during initial allocation. I was quite surprised by this issue. If multiple MSI vectors of the same device have to be allocated sequentially and bound to the same CPU, then they will be unable to give any SMP scalability benefits. Am I right, or there is some special technique expected to be used to somehow distribute grouped MSI vectors between CPUs which we don't have? I have made small patch that denies rebalancing for grouped MSIs, to make them work at least somehow. It works fine for me, but I am not sure that it is the best solution. -- Alexander Motin --------------010407070706090009080901 Content-Type: text/plain; name="msi.c.reassign.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msi.c.reassign.patch" --- msi.c.prev 2009-06-08 11:30:13.000000000 +0300 +++ msi.c 2009-06-08 11:30:06.000000000 +0300 @@ -210,6 +210,8 @@ msi_assign_cpu(struct intsrc *isrc, u_in old_id = msi->msi_cpu; if (old_vector && old_id == apic_id) return; + if (old_vector && !msi->msi_msix && msi->msi_first->msi_count > 1) + return; /* Allocate IDT vector on this cpu. */ vector = apic_alloc_vector(apic_id, msi->msi_irq); if (vector == 0) --------------010407070706090009080901-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 8 11:06:48 2009 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 E4DD3106564A for ; Mon, 8 Jun 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B83DF8FC13 for ; Mon, 8 Jun 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n58B6muX020554 for ; Mon, 8 Jun 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n58B6mG2020550 for freebsd-arch@FreeBSD.org; Mon, 8 Jun 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jun 2009 11:06:48 GMT Message-Id: <200906081106.n58B6mG2020550@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 08 Jun 2009 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 8 15:33:59 2009 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 3FE151065675; Mon, 8 Jun 2009 15:33:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 11D628FC14; Mon, 8 Jun 2009 15:33:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BB26446B4C; Mon, 8 Jun 2009 11:33:58 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4D0A28A049; Mon, 8 Jun 2009 11:33:57 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 8 Jun 2009 11:16:40 -0400 User-Agent: KMail/1.9.7 References: <4A2CD6AC.80407@FreeBSD.org> In-Reply-To: <4A2CD6AC.80407@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906081116.40462.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 08 Jun 2009 11:33:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Motin , freebsd-arch@freebsd.org Subject: Re: Multiple MSI on SMP, misrouting or misunderstanding? 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, 08 Jun 2009 15:33:59 -0000 On Monday 08 June 2009 5:15:24 am Alexander Motin wrote: > Hi. > > While experimenting with using multiple MSIs support on AHCI controller > I have got the problem. When system boots as UP - everything is fine, > driver allocates all available 16 MSIs and works. But when system booted > as SMP, interrupts begin to behave strange: I didn't receive expected > AHCI IRQs, but instead receive IRQ1 interrupts of atkbd0, while I have > no PS/2 keyboard/mouse attached. > > As I have found, problem appears due to IRQ rebalancing between CPUs. As > I have got, MSI requires that all vectors from the same group to be > allocated sequentially, but IRQ rebalancing breaks correct order, that > happed during initial allocation. > > I was quite surprised by this issue. If multiple MSI vectors of the same > device have to be allocated sequentially and bound to the same CPU, then > they will be unable to give any SMP scalability benefits. Am I right, or > there is some special technique expected to be used to somehow > distribute grouped MSI vectors between CPUs which we don't have? > > I have made small patch that denies rebalancing for grouped MSIs, to > make them work at least somehow. It works fine for me, but I am not sure > that it is the best solution. It is a limitation of MSI. With MSI, you have a single address register for the entire group of messages (the individual messages are just distinguished by toggling the lower N bits in the message data register). On x86 the address register includes the APIC ID. That means that all of the messages get sent to the same CPU. With MSI-X, there is a table with separate address and data registers for each message. This allows a driver to distribute interrupts across CPUs. I had old patches prior to the per-CPU IDT stuff to handle this quirk of MSI groups. The approach I used there was that I would only allow reassigning of the entire group by assigning to the first interrupt in the group. With per-CPU IDTs that gets trickier though as you need to allocate a whole block of aligned, consecutive IDT vectors in the new CPU. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jun 8 19:16:54 2009 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46982106566B; Mon, 8 Jun 2009 19:16:54 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 05F488FC0C; Mon, 8 Jun 2009 19:16:53 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n58IpMKa065821; Mon, 8 Jun 2009 14:51:22 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n58IpM0A065820; Mon, 8 Jun 2009 14:51:22 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 8 Jun 2009 14:51:22 -0400 From: David Schultz To: Brooks Davis Message-ID: <20090608185122.GA65737@zim.MIT.EDU> Mail-Followup-To: Brooks Davis , arch@FreeBSD.ORG, current@FreeBSD.ORG References: <20090605223636.GA24364@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090605223636.GA24364@lor.one-eyed-alien.net> Cc: arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: RFT: Allow large values of NGROUPS_MAX 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, 08 Jun 2009 19:16:54 -0000 On Fri, Jun 05, 2009, Brooks Davis wrote: > - Should we make any attempt to support old binaries when there > are more than 16 groups? The POSIX getgroups/setgroups APIs did not > anticipate this change and thus either will fail outright. We can't > fix setgroups, but we might want to make an optional accommodation for > getgroups to allow for truncated returns to old code. Awesome. I think the ABI breakage is fine as long as it only affects systems where users are actually in more than 16 groups. It's perfectly reasonable to expect people to recompile in order to take advantage of a new feature. As for the value of NGROUPS_MAX, there are systems with more than 32k groups out there, but I doubt there are interesting cases where a single user is a member of more than 32k groups. The permission checking code would not realistically scale to group lists that long anyway. From owner-freebsd-arch@FreeBSD.ORG Mon Jun 8 21:04:28 2009 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 0E192106564A; Mon, 8 Jun 2009 21:04:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE248FC19; Mon, 8 Jun 2009 21:04:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz17 with SMTP id 17so611181bwz.43 for ; Mon, 08 Jun 2009 14:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2l5AbUYISz6IpnY+xCu6wGTQz/vS/2l20wv5ANejyHA=; b=tJg9FO3h9UCD6cICOp8Lwc2tFGXRWT9kZEkQCw6HH60aPHk+d3PDCr7rczHkqrRZtS c/mklGNWksdD/z3Xge0GXZWBK+Z4qta3rLciiHtstVCfIzhgS5MyVaGFbrS16YmaZhsM +RgcHUB4mjRzkYq6nozzk3O2a0ZSCzF9DjPqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=iTBRIk2d1SfH2aG12Q/O7SppOad0LhaP3AcOSbgsE5QsBjxzj27C1aAF4KKfBRuNph rXFf071dm0/qPoMdsk0RPH03WpZtlyEfguae86nfv17WgufvM/tCs3wk57VVUB99rT9j 1MHMCMU1OrjPt388rVkObR4kT6Xjd7uyxNQmc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.112.204 with SMTP id x12mr4735147fap.70.1244493755848; Mon, 08 Jun 2009 13:42:35 -0700 (PDT) Date: Mon, 8 Jun 2009 22:42:35 +0200 X-Google-Sender-Auth: 4ad939ca14ef331c Message-ID: <3bbf2fe10906081342i6ef418e0n75e22d0b9e2543b3@mail.gmail.com> From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-smp@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: [PATCH] Adaptive spinning for lockmgr 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, 08 Jun 2009 21:04:28 -0000 This patch enables adaptive spinning for lockmgr: http://www.freebsd.org/~attilio/adaptive_lockmgr.diff and it should presumably improve performance on disks/vfs/buffer cache based benchmarks, so, if you want to try out and report any benchmarks result, I'd love to see it. Please note that there are some parameters to tune: for example, you would like to not enable adaptive spinning to default while you just want that for a class of locks (and in that case you want to apply the reversed logic for what is living now) or you want to use different values for retries and loops. Interested developers can refer to such 3 variables. Peter Holm alredy tested that patch for about 24hours without any regression to report. Also note that the patch is not 100% yet as long as it needs UPDATES and manpages updates, but they will be added just in time before to commit. The modify is all there. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Jun 9 08:50:25 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E0871065670 for ; Tue, 9 Jun 2009 08:50:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB3A8FC13 for ; Tue, 9 Jun 2009 08:50:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MDwfP-0006QT-Nr; Tue, 09 Jun 2009 11:26:48 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n598Qix6059023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 11:26:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n598Qii0097285; Tue, 9 Jun 2009 11:26:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n598Qhc9097284; Tue, 9 Jun 2009 11:26:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jun 2009 11:26:43 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20090609082643.GB75569@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MDwfP-0006QT-Nr 2083f2f06a6d3db9afba058546a7813f X-Terabit: YES Cc: arch@freebsd.org Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed 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: Tue, 09 Jun 2009 08:50:25 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 04, 2009 at 10:46:42AM +0100, Robert Watson wrote: > On Wed, 3 Jun 2009, Jeff Roberson wrote: >=20 > >I have not tested anything other than amd64. If you have a !amd64=20 > >architecture, in particular any of the embedded architectures, I would= =20 > >really appreciate it. Some of the arm boards postincrement the end=20 > >address to allocate early memory and some pre-decriment. Hopefully I go= t=20 > >it right. >=20 > I appear to get an instant reboot early during the kernel startup on i386= =20 > with this patch applied: >=20 > OK lsmod > 0x400000: /boot/kernel/kernel (elf kernel, 0xcd8920) > modules: elink.1 io.1 hptrr.1 ufs.1 kernel_mac_support.4 krpc.1=20 > nfslockd.1 nfssvc.1 nfsserver.1 nfslock.1 nfs.1 wlan_sta.1 wlan.1=20 > wlan_wep.1 wlan_tkip.1 wlan_ccmp.1 wlan_amrr.1 if_gif.1 if_firewire.1=20 > if_faith.1 ether.1 sysvshm.1 sysvsem.1 sysvmsg.1 firmware.1 kernel.800096= =20 > cd9660.1 isa.1 pseudofs.1 procfs.1 msdosfs.1 usb_quirk.1 ucom.1 uvscom.1= =20 > uslcom.1 uplcom.1 uether.1 cdce.1 usb.1 random.1 ppbus.1 pci.1 pccard.1= =20 > null.1 mpt_user.1 mpt_raid.1 mpt.1 mpt_cam.1 mpt_core.1 miibus.1 mem.1=20 > isp.1 sbp.1 fwip.1 fwe.1 firewire.1 splash.1 exca.1 dcons.2 dcons_crom.1= =20 > cardbus.1 bt.1 ath.1 ast.1 afd.1 acd.1 ataraid.1 ad.1 ata_via.1 ata_sis.1= =20 > ata_sii.1 ata_serverworks.1 ata_promise.1 ata_nvidia.1 ata_netcell.1=20 > ata_national.1 ata_micron.1 ata_marvell.1 ata_jmicron.1 ata_ite.1=20 > ata_intel.1 ata_highpoint.1 ata_cyrix.1 ata_cypress.1 ata_cenatek.1=20 > ata_ati.1 ata_amd.1 ata_adaptec.1 ata_ali.1 ata_acard.1 ata_ahci.1 atapci= .1=20 > ata.1 ahc.1 ahd.1 ahd_pci.1 ahc_pci.1 ahc_isa.1 ahc_eisa.1 agp.1 acpi_pci= .1=20 > acpi.1 scsi_low.1 cam.1 > OK boot -s > The reason for the reboot is the fact that memory after physfree is not mapped, and init386() tries to carve a piece of it for dpcpu for BSP. Since IDT/exceptions are not initialized yet, generated #pf is translated into triple fault. Please, see the patch at http://people.freebsd.org/~kib/misc/dcpu.1.patch that allocates area for dpcpu0 using the same technique as the memory for proc0kstack. Another minor issue is that per-cpu sysmaps were allocated without clearing corresponding ptes, causing panic in pmap_zero_page etc due to changed KVA layout. AMD64 is fine thanks to the direct map. --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkouHMIACgkQC3+MBN1Mb4hr6wCfc9j6LACKxkrRopQjMsYQoNxO upcAnR1JuDIOO4PpTuiidG+8ZxsBtoUJ =CU4h -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 9 20:37:48 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5DA41065670 for ; Tue, 9 Jun 2009 20:37:48 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE0E8FC1E for ; Tue, 9 Jun 2009 20:37:47 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n59KBRoL051163; Tue, 9 Jun 2009 22:11:27 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n59KBR2w051162; Tue, 9 Jun 2009 22:11:27 +0200 (CEST) (envelope-from marius) Date: Tue, 9 Jun 2009 22:11:27 +0200 From: Marius Strobl To: Jeff Roberson Message-ID: <20090609201127.GA50903@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed 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: Tue, 09 Jun 2009 20:37:49 -0000 On Wed, Jun 03, 2009 at 08:55:39PM -1000, Jeff Roberson wrote: > http://people.freebsd.org/~jeff/dpcpu.diff > > This patch implements dynamic per-cpu areas such that kernel code can do > the following in a header: > > DPCPU_DECLARE(uint64_t, foo); > > and this in source: > > DPCPU_DEFINE(uint64_t, foo) = 10; > > local = DPCPU_GET(foo); > DPCPU_SET(foo, 11); > > The dynamic per-cpu area of non-local cpus is accessable via > DPCPU_ID_{GET,SET,PTR}. > > If you provide an initializer as I used above that will be the default > value when all cpus come up. Otherwise it defaults to zero. This is > presently slightly more expensive than PCPU but much more flexible. > Things like id and curthread should stay in PCPU forever. > > I had to change the pcpu_init() call on every architecture to pass in > storage for the dynamic area. I didn't change the following three calls > because it wasn't immediately obvious how to allocate the memory: > > ./powerpc/booke/machdep.c: pcpu_init(pc, 0, sizeof(struct pcpu)); > ./mips/mips/machdep.c: pcpu_init(&__pcpu[0], 0, sizeof(struct pcpu)); > ./mips/mips/machdep.c: pcpu_init(pcpup, 0, sizeof(struct pcpu)); > > > I have not tested anything other than amd64. If you have a !amd64 > architecture, in particular any of the embedded architectures, I would > really appreciate it. Some of the arm boards postincrement the end > address to allocate early memory and some pre-decriment. Hopefully I got > it right. As for sparc64 allocating the storage for the dynamic area from end probably isn't a good idea as the pmap code assumes that the range from KERNBASE to end is covered by the pages allocated by and locked into the TLB for the kernel by the loader, so depending on the actual kernel size the DPCPU storage may be outside that region. The printf() will also blow at the location you moved it in sparc64_init() as the console isn't initialized at that point, yet. I think the best thing to do for the BSP would be to allocate its DPCPU storage via pmap_bootstrap_alloc() and use the direct mapping. This causes a bit of a chicken and egg problem though as MD parts of the per-CPU data are used to get pmap_bootstrap_alloc() working. Could you move the initialization of the DPCPU part to a dpcpu_init()? Marius From owner-freebsd-arch@FreeBSD.ORG Tue Jun 9 23:42:32 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F33EB106568B for ; Tue, 9 Jun 2009 23:42:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B28D78FC16 for ; Tue, 9 Jun 2009 23:42:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n59NgUa1052658 for ; Tue, 9 Jun 2009 17:42:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 09 Jun 2009 17:42:49 -0600 (MDT) Message-Id: <20090609.174249.-1435625969.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: devclass_find_free_unit 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: Tue, 09 Jun 2009 23:42:32 -0000 What purpose does devclass_find_free_unit serve? I think it can safely be eliminated from the tree. The current design is racy. Comments? It is currently used: ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: devclass_find_free_unit(ata_devclass, 0)); # All the above can be replaced with a simple '-1'. ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) == NULL) { These can likely be replaced by '2', but that may result in a warning message being printed that likely can be eliminated... comments? Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 00:03:51 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5ADC106566B for ; Wed, 10 Jun 2009 00:03:51 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 86FC88FC12 for ; Wed, 10 Jun 2009 00:03:51 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id B5FBA11A56; Wed, 10 Jun 2009 09:48:25 +1000 (EST) Received: from peter-grehans-macbook.local (c-76-25-181-67.hsd1.co.comcast.net [76.25.181.67]) by dommail.onthenet.com.au (MOS 3.8.6-GA) with ESMTP id EUR41149 (AUTH peterg@ptree32.com.au); Wed, 10 Jun 2009 09:48:24 +1000 (EST) Message-ID: <4A2EF4C4.408@freebsd.org> Date: Tue, 09 Jun 2009 17:48:20 -0600 From: Peter Grehan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090609.174249.-1435625969.imp@bsdimp.com> In-Reply-To: <20090609.174249.-1435625969.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: devclass_find_free_unit 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: Wed, 10 Jun 2009 00:03:52 -0000 Hi Warner, > What purpose does devclass_find_free_unit serve? I think it can safely be > eliminated from the tree. The current design is racy. ... > ./powerpc/psim/.svn/text-base/ata_iobus.c That would be a cut'n'paste relic from the ATA code that it originated from. Going to -1 is fine. later, Peter. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 01:50:11 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20371106564A for ; Wed, 10 Jun 2009 01:50:11 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id D331E8FC1B for ; Wed, 10 Jun 2009 01:50:10 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id 0A29211932; Wed, 10 Jun 2009 11:50:07 +1000 (EST) Received: from peter-grehans-macbook.local (c-76-25-181-67.hsd1.co.comcast.net [76.25.181.67]) by dommail.onthenet.com.au (MOS 3.8.6-GA) with ESMTP id EUR53066 (AUTH peterg@ptree32.com.au); Wed, 10 Jun 2009 11:50:03 +1000 (EST) Message-ID: <4A2F1148.9090706@freebsd.org> Date: Tue, 09 Jun 2009 19:50:00 -0600 From: Peter Grehan User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jeff Roberson References: <20090609201127.GA50903@alchemy.franken.de> In-Reply-To: <20090609201127.GA50903@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Marius Strobl Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed 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: Wed, 10 Jun 2009 01:50:11 -0000 > As for sparc64 allocating the storage for the dynamic area > from end probably isn't a good idea as the pmap code assumes > that the range from KERNBASE to end is covered by the pages > allocated by and locked into the TLB for the kernel by the > loader Ditto for ppc. It's possible to get the additional space from within or after return from pmap_bootstrap() (like thread0's kstack, or the msgbuf). later, Peter. From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 12:24:30 2009 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 A8D6E1065670 for ; Wed, 10 Jun 2009 12:24:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6338FC13 for ; Wed, 10 Jun 2009 12:24:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1959246B2E; Wed, 10 Jun 2009 08:24:30 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 04F5F8A06A; Wed, 10 Jun 2009 08:24:29 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 10 Jun 2009 08:22:15 -0400 User-Agent: KMail/1.9.7 References: <20090609.174249.-1435625969.imp@bsdimp.com> In-Reply-To: <20090609.174249.-1435625969.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906100822.15516.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 08:24:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: devclass_find_free_unit 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: Wed, 10 Jun 2009 12:24:30 -0000 On Tuesday 09 June 2009 7:42:49 pm M. Warner Losh wrote: > What purpose does devclass_find_free_unit serve? I think it can safely be > eliminated from the tree. The current design is racy. > > Comments? > > It is currently used: > > ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: devclass_find_free_unit(ata_devclass, 0)); > > # All the above can be replaced with a simple '-1'. > > ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); > ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) == NULL) { > > These can likely be replaced by '2', but that may result in a warning > message being printed that likely can be eliminated... ata does this so it can reserve ata0 and ata1 for the "legacy" ATA channels on legacy ATA PCI adapters. That is, if you have both SATA controllers and a PATA controller, this allows the two PATA channels to always be ata0 and ata1 and the PATA drivers to always be ad0 - ad3. You could perhaps implement this in 8.x now by a really horrendous hack of having ISA hints for ata0 and ata1 and letting bus_hint_device_unit() in the atapci driver claim those hints for the channels on PATA controllers. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 16:22:32 2009 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 EDF1C106566C; Wed, 10 Jun 2009 16:22:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 859258FC26; Wed, 10 Jun 2009 16:22:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n5AGLO8o065400; Wed, 10 Jun 2009 10:21:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 10 Jun 2009 10:21:44 -0600 (MDT) Message-Id: <20090610.102144.324381338.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200906100822.15516.jhb@freebsd.org> References: <20090609.174249.-1435625969.imp@bsdimp.com> <200906100822.15516.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jun_10_10_21_44_2009_872)--" Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: devclass_find_free_unit 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: Wed, 10 Jun 2009 16:22:33 -0000 ----Next_Part(Wed_Jun_10_10_21_44_2009_872)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: <200906100822.15516.jhb@freebsd.org> John Baldwin writes: : On Tuesday 09 June 2009 7:42:49 pm M. Warner Losh wrote: : > What purpose does devclass_find_free_unit serve? I think it can safely be : > eliminated from the tree. The current design is racy. : > : > Comments? : > : > It is currently used: : > : > ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); : > ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", : devclass_find_free_unit(ata_devclass, 0)); : > ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); : > ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", : devclass_find_free_unit(ata_devclass, 0)); : > ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: : devclass_find_free_unit(ata_devclass, 0)); : > : > # All the above can be replaced with a simple '-1'. : > : > ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); : > ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) == : NULL) { : > : > These can likely be replaced by '2', but that may result in a warning : > message being printed that likely can be eliminated... : : ata does this so it can reserve ata0 and ata1 for the "legacy" ATA channels on : legacy ATA PCI adapters. That is, if you have both SATA controllers and a : PATA controller, this allows the two PATA channels to always be ata0 and ata1 : and the PATA drivers to always be ad0 - ad3. You could perhaps implement : this in 8.x now by a really horrendous hack of having ISA hints for ata0 and : ata1 and letting bus_hint_device_unit() in the atapci driver claim those : hints for the channels on PATA controllers. I think it already does something akin to this: /* attach all channels on this controller */ for (unit = 0; unit < ctlr->channels; unit++) { if ((ctlr->ichannels & (1 << unit)) == 0) continue; child = device_add_child(dev, "ata", ((unit == 0 || unit == 1) && ctlr->legacy) ? unit : devclass_find_free_unit(ata_devclass, 2)); if (child == NULL) device_printf(dev, "failed to add ata child device\n"); else device_set_ivars(child, (void *)(intptr_t)unit); } Why not just replace devclass_find_free_unit with '2'? All the other users in the tree aer bogus and should be replaced by -1. Well, I'm not 100% sure about the ata-usb.c patch, since that would also be necessary to avoid collision. And the above code really only applies to x86-based machine, right? There's no need to do that for non-intel boxes. Or is the assumption on those boxes the controller would never be in legacy. Warner ----Next_Part(Wed_Jun_10_10_21_44_2009_872)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="devclass_find_free_fix.diff" Index: arm/xscale/ixp425/avila_ata.c =================================================================== --- arm/xscale/ixp425/avila_ata.c (revision 193873) +++ arm/xscale/ixp425/avila_ata.c (working copy) @@ -248,7 +248,7 @@ NULL, ata_avila_intr, sc, &sc->sc_ih); /* attach channel on this controller */ - device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); + device_add_child(dev, "ata", -1); bus_generic_attach(dev); return 0; Index: arm/at91/at91_cfata.c =================================================================== --- arm/at91/at91_cfata.c (revision 193873) +++ arm/at91/at91_cfata.c (working copy) @@ -94,7 +94,7 @@ /* XXX: init CF controller? */ callout_init(&sc->tick, 1); /* Callout to poll the device. */ - device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); + device_add_child(dev, "ata", -1); bus_generic_attach(dev); return (0); } Index: arm/at91/files.at91 =================================================================== --- arm/at91/files.at91 (revision 193873) +++ arm/at91/files.at91 (working copy) @@ -18,6 +18,11 @@ arm/at91/uart_bus_at91usart.c optional uart arm/at91/uart_cpu_at91rm9200usart.c optional uart arm/at91/uart_dev_at91usart.c optional uart + +dev/cfi/cfi_bus_lbc.c optional cfi +dev/cfi/cfi_core.c optional cfi +dev/cfi/cfi_dev.c optional cfi + # # All the boards we support # Index: arm/at91/at91_machdep.c =================================================================== --- arm/at91/at91_machdep.c (revision 193873) +++ arm/at91/at91_machdep.c (working copy) @@ -179,6 +179,14 @@ PTE_NOCACHE, }, { + AT91RM92_FLS_BASE, + AT91RM92_FLS_PA_BASE, + AT91RM92_FLS_SIZE, + VM_PROT_READ|VM_PROT_WRITE, + PTE_NOCACHE, + }, + + { /* CompactFlash controller. */ AT91RM92_CF_BASE, AT91RM92_CF_PA_BASE, Index: arm/at91/at91_mci.c =================================================================== --- arm/at91/at91_mci.c (revision 193873) +++ arm/at91/at91_mci.c (working copy) @@ -62,8 +62,15 @@ #include "mmcbr_if.h" -#define BBSZ 512 +// #define AT91_MCI_DEBUG +#define MAX_SIZE 1 +#define BBSZ 512 * MAX_SIZE +/* + * Note: This driver only supports the SlotA card. No attempt has been made + * to support SlotB. + */ + struct at91_mci_softc { void *intrhand; /* Interrupt handle */ device_t dev; @@ -204,10 +211,16 @@ sc->host.f_min = 375000; sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; + sc->host.caps = 0; + /* + * The in-tree Linux driver doesn't allow 4-wire operation for the + * at91rm9200, but does for other members of the family. The atmel + * patches to this do allow it, or have in the past. It is unclear + * that the hardware even works, but my boot loader uses 4-bit bus + * in polling mode successfully. + */ if (sc->sc_cap & CAP_HAS_4WIRE) - sc->host.caps = MMC_CAP_4_BIT_DATA; - else - sc->host.caps = 0; + sc->host.caps |= MMC_CAP_4_BIT_DATA; child = device_add_child(dev, "mmc", 0); device_set_ivars(dev, &sc->host); err = bus_generic_attach(dev); @@ -300,9 +313,9 @@ clkdiv = (at91_master_clock / ios->clock) / 2; } if (ios->bus_width == bus_width_4) - WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); + WR4(sc, MCI_SDCR, MCI_SDCR_SDCBUS); else - WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); + WR4(sc, MCI_SDCR, 0); WR4(sc, MCI_MR, (RD4(sc, MCI_MR) & ~MCI_MR_CLKDIV) | clkdiv); /* Do we need a settle time here? */ /* XXX We need to turn the device on/off here with a GPIO pin */ @@ -341,7 +354,9 @@ if (!data) { // The no data case is fairly simple at91_mci_pdc_disable(sc); -// printf("CMDR %x ARGR %x\n", cmdr, cmd->arg); +#ifdef AT91_MCI_DEBUG + printf("CMDR %x ARGR %x\n", cmdr, cmd->arg); +#endif WR4(sc, MCI_ARGR, cmd->arg); WR4(sc, MCI_CMDR, cmdr); WR4(sc, MCI_IER, MCI_SR_ERROR | MCI_SR_CMDRDY); @@ -399,7 +414,9 @@ ier = MCI_SR_TXBUFE; } } -// printf("CMDR %x ARGR %x with data\n", cmdr, cmd->arg); +#ifdef AT91_MCI_DEBUG + printf("CMDR %x ARGR %x with data\n", cmdr, cmd->arg); +#endif WR4(sc, MCI_ARGR, cmd->arg); if (cmdr & MCI_CMDR_TRCMD_START) { if (cmdr & MCI_CMDR_TRDIR) { @@ -438,6 +455,14 @@ sc->req = NULL; sc->curcmd = NULL; req->done(req); + /* + * Attempted hack-a-round for the DMA bug for multiple reads. + */ + if (req->cmd->opcode == MMC_READ_MULTIPLE_BLOCK) { + at91_mci_fini(sc->dev); + at91_mci_init(sc->dev); + at91_mci_update_ios(sc->dev, NULL); + } } static int @@ -498,7 +523,9 @@ uint32_t *walker; struct mmc_command *cmd; int i, len; - +#ifdef AT91_MCI_DEBUG + char *w2; +#endif cmd = sc->curcmd; bus_dmamap_sync(sc->dmatag, sc->map, BUS_DMASYNC_POSTREAD); bus_dmamap_unload(sc->dmatag, sc->map); @@ -509,6 +536,15 @@ for (i = 0; i < len; i++) walker[i] = bswap32(walker[i]); } +#ifdef AT91_MCI_DEBUG + printf("Read data\n"); + for (i = 0, w2 = cmd->data->data; i < cmd->data->len; i++) { + if (i % 16 == 0) + printf("%08x ", cmd->arg + i); + printf("%02x%s", w2[i], (i + 1) % 16 ? " " : "\n"); + } + printf("\n"); +#endif // Finish up the sequence... WR4(sc, MCI_IDR, MCI_SR_ENDRX); WR4(sc, MCI_IER, MCI_SR_RXBUFF); @@ -544,14 +580,19 @@ if ((sr & MCI_SR_RCRCE) && (cmd->opcode == MMC_SEND_OP_COND || cmd->opcode == ACMD_SD_SEND_OP_COND)) cmd->error = MMC_ERR_NONE; - else if (sr & (MCI_SR_RTOE | MCI_SR_DTOE)) + else if (sr & (MCI_SR_RTOE | MCI_SR_DTOE)) { + printf("TIMEOUT %#x\n", sr); cmd->error = MMC_ERR_TIMEOUT; - else if (sr & (MCI_SR_RCRCE | MCI_SR_DCRCE)) + } else if (sr & (MCI_SR_RCRCE | MCI_SR_DCRCE)) { + printf("CRC %#x\n", sr); cmd->error = MMC_ERR_BADCRC; - else if (sr & (MCI_SR_OVRE | MCI_SR_UNRE)) + } else if (sr & (MCI_SR_OVRE | MCI_SR_UNRE)) { + printf("FIFO %#x\n", sr); cmd->error = MMC_ERR_FIFO; - else + } else { + printf("FAILED %#x\n", sr); cmd->error = MMC_ERR_FAILED; + } done = 1; if (sc->mapped && cmd->error) { bus_dmamap_unload(sc->dmatag, sc->map); @@ -656,7 +697,7 @@ *(int *)result = sc->host.caps; break; case MMCBR_IVAR_MAX_DATA: - *(int *)result = 1; + *(int *)result = MAX_SIZE; break; } return (0); Index: arm/at91/at91rm92reg.h =================================================================== --- arm/at91/at91rm92reg.h (revision 193873) +++ arm/at91/at91rm92reg.h (working copy) @@ -341,6 +341,10 @@ #define AT91RM92_OHCI_PA_BASE 0x00300000 #define AT91RM92_OHCI_SIZE 0x00100000 +#define AT91RM92_FLS_BASE 0xdf000000 +#define AT91RM92_FLS_PA_BASE 0x10000000 +#define AT91RM92_FLS_SIZE 0x02000000 /* Support up to 32MB flash */ + #define AT91RM92_CF_BASE 0xdfd00000 #define AT91RM92_CF_PA_BASE 0x51400000 #define AT91RM92_CF_SIZE 0x00100000 Index: powerpc/psim/ata_iobus.c =================================================================== --- powerpc/psim/ata_iobus.c (revision 193873) +++ powerpc/psim/ata_iobus.c (working copy) @@ -114,9 +114,7 @@ * Add a single child per controller. Should be able * to add two */ - device_add_child(dev, "ata", - devclass_find_free_unit(ata_devclass, 0)); - + device_add_child(dev, "ata", -1); return (bus_generic_attach(dev)); } Index: dev/ata/ata-all.c =================================================================== --- dev/ata/ata-all.c (revision 193873) +++ dev/ata/ata-all.c (working copy) @@ -663,7 +663,7 @@ btrim(atacap->serial, sizeof(atacap->serial)); bpack(atacap->serial, atacap->serial, sizeof(atacap->serial)); - if (bootverbose) + if (bootverbose || 1) printf("ata%d-%s: pio=%s wdma=%s udma=%s cable=%s wire\n", device_get_unit(ch->dev), ata_unit2str(atadev), Index: dev/ata/ata-usb.c =================================================================== --- dev/ata/ata-usb.c (revision 193873) +++ dev/ata/ata-usb.c (working copy) @@ -414,11 +414,10 @@ /* ata channels are children to this USB control device */ for (i = 0; i <= sc->maxlun; i++) { - if ((child = device_add_child(sc->dev, "ata", - devclass_find_free_unit(ata_devclass, 2))) == NULL) { + if ((child = device_add_child(sc->dev, "ata", -1)) == NULL) device_printf(sc->dev, "failed to add ata child device\n"); - } else - device_set_ivars(child, (void *)(intptr_t)i); + else + device_set_ivars(child, (void *)(intptr_t)i); } bus_generic_attach(sc->dev); ----Next_Part(Wed_Jun_10_10_21_44_2009_872)---- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 17:09:14 2009 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 28084106564A for ; Wed, 10 Jun 2009 17:09:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D68CB8FC12 for ; Wed, 10 Jun 2009 17:09:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 03CC946B06; Wed, 10 Jun 2009 13:09:13 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CFAD28A06A; Wed, 10 Jun 2009 13:09:11 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Date: Wed, 10 Jun 2009 13:02:02 -0400 User-Agent: KMail/1.9.7 References: <20090609.174249.-1435625969.imp@bsdimp.com> <200906100822.15516.jhb@freebsd.org> <20090610.102144.324381338.imp@bsdimp.com> In-Reply-To: <20090610.102144.324381338.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101302.03211.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 13:09:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: devclass_find_free_unit 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: Wed, 10 Jun 2009 17:09:14 -0000 On Wednesday 10 June 2009 12:21:44 pm M. Warner Losh wrote: > In message: <200906100822.15516.jhb@freebsd.org> > John Baldwin writes: > : On Tuesday 09 June 2009 7:42:49 pm M. Warner Losh wrote: > : > What purpose does devclass_find_free_unit serve? I think it can safely be > : > eliminated from the tree. The current design is racy. > : > > : > Comments? > : > > : > It is currently used: > : > > : > ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: > : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > : > ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", > : devclass_find_free_unit(ata_devclass, 0)); > : > ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: > : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > : > ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", > : devclass_find_free_unit(ata_devclass, 0)); > : > ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: > : devclass_find_free_unit(ata_devclass, 0)); > : > > : > # All the above can be replaced with a simple '-1'. > : > > : > ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); > : > ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) == > : NULL) { > : > > : > These can likely be replaced by '2', but that may result in a warning > : > message being printed that likely can be eliminated... > : > : ata does this so it can reserve ata0 and ata1 for the "legacy" ATA channels on > : legacy ATA PCI adapters. That is, if you have both SATA controllers and a > : PATA controller, this allows the two PATA channels to always be ata0 and ata1 > : and the PATA drivers to always be ad0 - ad3. You could perhaps implement > : this in 8.x now by a really horrendous hack of having ISA hints for ata0 and > : ata1 and letting bus_hint_device_unit() in the atapci driver claim those > : hints for the channels on PATA controllers. > > I think it already does something akin to this: > > /* attach all channels on this controller */ > for (unit = 0; unit < ctlr->channels; unit++) { > if ((ctlr->ichannels & (1 << unit)) == 0) > continue; > child = device_add_child(dev, "ata", > ((unit == 0 || unit == 1) && ctlr->legacy) ? > unit : devclass_find_free_unit(ata_devclass, 2)); > if (child == NULL) > device_printf(dev, "failed to add ata child device\n"); > else > device_set_ivars(child, (void *)(intptr_t)unit); > } > > Why not just replace devclass_find_free_unit with '2'? Because if you add 'ata2', and 'ata2' exists it will fail, it won't rename it to ata3. And that is what ata is trying to do. It basically wants to "reserve" ata0 and ata1 and then use device_add_child(..., -1). However, device_add_child(..., -1) will not "reserve" ata0 and ata1. > All the other users in the tree aer bogus and should be replaced by > -1. Well, I'm not 100% sure about the ata-usb.c patch, since that > would also be necessary to avoid collision. And the above code really > only applies to x86-based machine, right? There's no need to do that > for non-intel boxes. Or is the assumption on those boxes the > controller would never be in legacy. Any machine that can have a PCI PATA controller or a PCI SATA controller operating in "legacy" mode. That said, the compatability bits probably don't matter as much on non-x86 as there are not older releases to be compatible with (or the impact would be less severe if we renumber people's drives at least). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 17:32:13 2009 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 9A4221065670; Wed, 10 Jun 2009 17:32:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 43EA78FC0A; Wed, 10 Jun 2009 17:32:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n5AHRq77066216; Wed, 10 Jun 2009 11:27:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 10 Jun 2009 11:28:13 -0600 (MDT) Message-Id: <20090610.112813.623117012.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200906101302.03211.jhb@freebsd.org> References: <200906100822.15516.jhb@freebsd.org> <20090610.102144.324381338.imp@bsdimp.com> <200906101302.03211.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: devclass_find_free_unit 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: Wed, 10 Jun 2009 17:32:13 -0000 In message: <200906101302.03211.jhb@freebsd.org> John Baldwin writes: : On Wednesday 10 June 2009 12:21:44 pm M. Warner Losh wrote: : > In message: <200906100822.15516.jhb@freebsd.org> : > John Baldwin writes: : > : On Tuesday 09 June 2009 7:42:49 pm M. Warner Losh wrote: : > : > What purpose does devclass_find_free_unit serve? I think it can safely : be : > : > eliminated from the tree. The current design is racy. : > : > : > : > Comments? : > : > : > : > It is currently used: : > : > : > : > ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: : > : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); : > : > ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", : > : devclass_find_free_unit(ata_devclass, 0)); : > : > ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: : > : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); : > : > ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", : > : devclass_find_free_unit(ata_devclass, 0)); : > : > ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: : > : devclass_find_free_unit(ata_devclass, 0)); : > : > : > : > # All the above can be replaced with a simple '-1'. : > : > : > : > ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); : > : > ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) : == : > : NULL) { : > : > : > : > These can likely be replaced by '2', but that may result in a warning : > : > message being printed that likely can be eliminated... : > : : > : ata does this so it can reserve ata0 and ata1 for the "legacy" ATA : channels on : > : legacy ATA PCI adapters. That is, if you have both SATA controllers and a : > : PATA controller, this allows the two PATA channels to always be ata0 and : ata1 : > : and the PATA drivers to always be ad0 - ad3. You could perhaps implement : > : this in 8.x now by a really horrendous hack of having ISA hints for ata0 : and : > : ata1 and letting bus_hint_device_unit() in the atapci driver claim those : > : hints for the channels on PATA controllers. : > : > I think it already does something akin to this: : > : > /* attach all channels on this controller */ : > for (unit = 0; unit < ctlr->channels; unit++) { : > if ((ctlr->ichannels & (1 << unit)) == 0) : > continue; : > child = device_add_child(dev, "ata", : > ((unit == 0 || unit == 1) && ctlr->legacy) ? : > unit : devclass_find_free_unit(ata_devclass, 2)); : > if (child == NULL) : > device_printf(dev, "failed to add ata child device\n"); : > else : > device_set_ivars(child, (void *)(intptr_t)unit); : > } : > : > Why not just replace devclass_find_free_unit with '2'? : : Because if you add 'ata2', and 'ata2' exists it will fail, it won't rename it : to ata3. And that is what ata is trying to do. It basically wants : to "reserve" ata0 and ata1 and then use device_add_child(..., -1). However, : device_add_child(..., -1) will not "reserve" ata0 and ata1. Ah yes. It does just fail. However, setting the unit here is racy. If we were to make the device tree probe more parallel, then we may have a case where devclass_find_free_unit gets called from two different threads, returning the same number, then the device_child_add works for only one of these threads... : > All the other users in the tree aer bogus and should be replaced by : > -1. Well, I'm not 100% sure about the ata-usb.c patch, since that : > would also be necessary to avoid collision. And the above code really : > only applies to x86-based machine, right? There's no need to do that : > for non-intel boxes. Or is the assumption on those boxes the : > controller would never be in legacy. : : Any machine that can have a PCI PATA controller or a PCI SATA controller : operating in "legacy" mode. That said, the compatability bits probably don't : matter as much on non-x86 as there are not older releases to be compatible : with (or the impact would be less severe if we renumber people's drives at : least). Yes. I guess I was asking if we need an ifdef for this behavior or not... I guess not.. I think we need to have a better way to 'reserve' a unit than we have today. I think this will be better to do that and retire devclass_find_free_unit. I think that only one or two uses in the tree are legit... Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 10 17:45:14 2009 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 2E6491065690 for ; Wed, 10 Jun 2009 17:45:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F338D8FC21 for ; Wed, 10 Jun 2009 17:45:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 842C746B45; Wed, 10 Jun 2009 13:45:13 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 629FC8A06C; Wed, 10 Jun 2009 13:45:12 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Date: Wed, 10 Jun 2009 13:43:15 -0400 User-Agent: KMail/1.9.7 References: <200906100822.15516.jhb@freebsd.org> <200906101302.03211.jhb@freebsd.org> <20090610.112813.623117012.imp@bsdimp.com> In-Reply-To: <20090610.112813.623117012.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101343.15311.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 10 Jun 2009 13:45:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: devclass_find_free_unit 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: Wed, 10 Jun 2009 17:45:14 -0000 On Wednesday 10 June 2009 1:28:13 pm M. Warner Losh wrote: > In message: <200906101302.03211.jhb@freebsd.org> > John Baldwin writes: > : On Wednesday 10 June 2009 12:21:44 pm M. Warner Losh wrote: > : > In message: <200906100822.15516.jhb@freebsd.org> > : > John Baldwin writes: > : > : On Tuesday 09 June 2009 7:42:49 pm M. Warner Losh wrote: > : > : > What purpose does devclass_find_free_unit serve? I think it can safely > : be > : > : > eliminated from the tree. The current design is racy. > : > : > > : > : > Comments? > : > : > > : > : > It is currently used: > : > : > > : > : > ./arm/xscale/ixp425/.svn/text-base/avila_ata.c.svn-base: > : > : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > : > : > ./arm/xscale/ixp425/avila_ata.c: device_add_child(dev, "ata", > : > : devclass_find_free_unit(ata_devclass, 0)); > : > : > ./arm/at91/.svn/text-base/at91_cfata.c.svn-base: > : > : device_add_child(dev, "ata", devclass_find_free_unit(ata_devclass, 0)); > : > : > ./arm/at91/at91_cfata.c: device_add_child(dev, "ata", > : > : devclass_find_free_unit(ata_devclass, 0)); > : > : > ./powerpc/psim/.svn/text-base/ata_iobus.c.svn-base: > : > : devclass_find_free_unit(ata_devclass, 0)); > : > : > > : > : > # All the above can be replaced with a simple '-1'. > : > : > > : > : > ata/ata-pci.c: unit : devclass_find_free_unit(ata_devclass, 2)); > : > : > ata/ata-usb.c: devclass_find_free_unit(ata_devclass, 2))) > : == > : > : NULL) { > : > : > > : > : > These can likely be replaced by '2', but that may result in a warning > : > : > message being printed that likely can be eliminated... > : > : > : > : ata does this so it can reserve ata0 and ata1 for the "legacy" ATA > : channels on > : > : legacy ATA PCI adapters. That is, if you have both SATA controllers and a > : > : PATA controller, this allows the two PATA channels to always be ata0 and > : ata1 > : > : and the PATA drivers to always be ad0 - ad3. You could perhaps implement > : > : this in 8.x now by a really horrendous hack of having ISA hints for ata0 > : and > : > : ata1 and letting bus_hint_device_unit() in the atapci driver claim those > : > : hints for the channels on PATA controllers. > : > > : > I think it already does something akin to this: > : > > : > /* attach all channels on this controller */ > : > for (unit = 0; unit < ctlr->channels; unit++) { > : > if ((ctlr->ichannels & (1 << unit)) == 0) > : > continue; > : > child = device_add_child(dev, "ata", > : > ((unit == 0 || unit == 1) && ctlr->legacy) ? > : > unit : devclass_find_free_unit(ata_devclass, 2)); > : > if (child == NULL) > : > device_printf(dev, "failed to add ata child device\n"); > : > else > : > device_set_ivars(child, (void *)(intptr_t)unit); > : > } > : > > : > Why not just replace devclass_find_free_unit with '2'? > : > : Because if you add 'ata2', and 'ata2' exists it will fail, it won't rename it > : to ata3. And that is what ata is trying to do. It basically wants > : to "reserve" ata0 and ata1 and then use device_add_child(..., -1). However, > : device_add_child(..., -1) will not "reserve" ata0 and ata1. > > Ah yes. It does just fail. However, setting the unit here is racy. > If we were to make the device tree probe more parallel, then we may > have a case where devclass_find_free_unit gets called from two > different threads, returning the same number, then the > device_child_add works for only one of these threads... Yes, it is quite racey. > : > All the other users in the tree aer bogus and should be replaced by > : > -1. Well, I'm not 100% sure about the ata-usb.c patch, since that > : > would also be necessary to avoid collision. And the above code really > : > only applies to x86-based machine, right? There's no need to do that > : > for non-intel boxes. Or is the assumption on those boxes the > : > controller would never be in legacy. > : > : Any machine that can have a PCI PATA controller or a PCI SATA controller > : operating in "legacy" mode. That said, the compatability bits probably don't > : matter as much on non-x86 as there are not older releases to be compatible > : with (or the impact would be less severe if we renumber people's drives at > : least). > > Yes. I guess I was asking if we need an ifdef for this behavior or > not... I guess not.. > > I think we need to have a better way to 'reserve' a unit than we have > today. I think this will be better to do that and retire > devclass_find_free_unit. I think that only one or two uses in the > tree are legit... Well, that was why I suggested possibly depending on the (already-existing) ata[01] ISA hints and having a bus_hint_device_unit() method for the atapci driver that let PATA channels claim ata[01]. Then the ata driver could always use device_add_unit(..., -1) to add "ata" devices. It is sort of odd, but it actually maps what the code is trying to do: let the PATA ATA channels "look like" the old ISA channels. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jun 11 10:57:05 2009 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 5953B1065674 for ; Thu, 11 Jun 2009 10:57:05 +0000 (UTC) (envelope-from "") Received: from 95-83-46-127.saransk.ru (95-83-46-127.saransk.ru [95.83.46.127]) by mx1.freebsd.org (Postfix) with SMTP id 530BA8FC15 for ; Thu, 11 Jun 2009 10:57:03 +0000 (UTC) (envelope-from "") Received: from fio.hqqpch ([37.142.116.57]) by 95-83-46-127.saransk.ru with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Jun 2009 14:35:52 +0300 Message-ID: <002901c9ea80$64863400$258e7439@homepcfio.hqqpch> From: "Dorothy Reid" To: Date: Thu, 11 Jun 2009 14:35:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2578 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2578 Subject: Replica Watches 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: Thu, 11 Jun 2009 10:57:05 -0000 A lot of brands, 100-300 usd. Mail to order: myama@lbix.com From owner-freebsd-arch@FreeBSD.ORG Fri Jun 12 13:23:05 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB15E106564A for ; Fri, 12 Jun 2009 13:23:05 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 84E218FC18 for ; Fri, 12 Jun 2009 13:23:05 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id k40so740603rvb.43 for ; Fri, 12 Jun 2009 06:23:05 -0700 (PDT) Received: by 10.141.3.10 with SMTP id f10mr1546381rvi.258.1244812984964; Fri, 12 Jun 2009 06:23:04 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id g22sm4547411rvb.16.2009.06.12.06.23.01 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 06:23:02 -0700 (PDT) Date: Fri, 12 Jun 2009 03:23:31 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Peter Grehan In-Reply-To: <4A2F1148.9090706@freebsd.org> Message-ID: References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Marius Strobl Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed 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: Fri, 12 Jun 2009 13:23:05 -0000 On Tue, 9 Jun 2009, Peter Grehan wrote: >> As for sparc64 allocating the storage for the dynamic area >> from end probably isn't a good idea as the pmap code assumes >> that the range from KERNBASE to end is covered by the pages >> allocated by and locked into the TLB for the kernel by the >> loader > > Ditto for ppc. It's possible to get the additional space from within or > after return from pmap_bootstrap() (like thread0's kstack, or the msgbuf). > OK, I had originally split it into two stages. It sounds like I should return to this and revise the patch again. We worked out the i386 problems. I'll split it up again and post something that hopefully you two can try. Thanks, Jeff > later, > > Peter. >