From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 30 03:24:06 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9997E89C for ; Sun, 30 Dec 2012 03:24:06 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 516A88FC0C for ; Sun, 30 Dec 2012 03:24:06 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id qBU3O3u5029483; Sat, 29 Dec 2012 22:24:03 -0500 (EST) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id qBU3O3JM029482; Sat, 29 Dec 2012 22:24:03 -0500 (EST) (envelope-from lidl) Date: Sat, 29 Dec 2012 22:24:03 -0500 From: Kurt Lidl To: Chris Ross Subject: Re: Changes to kern.geom.debugflags? Message-ID: <20121230032403.GA29164@pix.net> References: <7AA0B5D0-D49C-4D5A-8FA0-AA57C091C040@distal.com> <6A0C1005-F328-4C4C-BB83-CA463BD85127@distal.com> <20121225232507.GA47735@alchemy.franken.de> <8D01A854-97D9-4F1F-906A-7AB59BF8850B@distal.com> <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6FC4189B-85FA-466F-AA00-C660E9C16367@distal.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org, Marius Strobl X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 03:24:06 -0000 On Sat, Dec 29, 2012 at 03:01:55PM -0500, Chris Ross wrote: > On Dec 27, 2012, at 1:15 PM, Chris Ross wrote: > > > On Dec 27, 2012, at 10:43 AM, Chris Ross wrote: > >>>> FreeBSD/sparc64 ZFS boot block > >> Boot path: /pci@1c,600000/scsi@2/disk@1,0:a > >> Consoles: Open Firmware console > >> ERROR: Last Trap: Division by Zero > >> > >> {1} ok ctrace > >> No saved state > >> {1} ok > >> > >> Anything else you can suggest to get debugging information out of zfsloader? > > > > So, I've started with the tiring process of "printf debugging". I have gotten out of > > the loader code, and can show that it's inside of the call to the zfs devsw dv_init() > > call where it's failing. > > Okay. Many many iterations, and I found out where it's crashing. In > sys/boot/zfs/zfsimpl.c, in dnode_read(), the first line of the while loop > is: > > uint64_t bn = offset / bsize; > > And, bsize is calculated from: > > int bsize = dnode->dn_datablkszsec << SPA_MINBLOCKSHIFT; > > When running the code, though, I can confirm that bsize is 0 before > the divide is hit, thus causing the divide by zero trap. > > I'm going to guess this is a problem with dnode->dn_datablkszsec. > Has anything changed recently in zfs_fmtdev, or more likely zfs_get_root() > or objset_get_dnode(), which is the callchain right before dnode_read() ? Well, there has been a big set of bugfixes integrated into zfs since the 9.1-RELEASE, particularly revision r243674: ------------------------------------------------------------------------ r243674 | mm | 2012-11-29 09:05:04 -0500 (Thu, 29 Nov 2012) | 223 lines Merge ZFS feature flags support and related bugfixes: 236884, 237001, 237119, 237458, 237972, 238113, 238391, 238422, 238926, 238950, 238951, 239389, 239394, 239620, 239774, 239953, 239958, 239967, 239968, 240063, 240133, 240153, 240303, 240345, 240415, 240955, 241655, 243014, 243505, 243506 [ long, long description elided ] ------------------------------------------------------------------------ However, I think it's more likely that this revision, particularly r239068 that is the probably cause of the issue you are seeing. I don't particularly care for giant patches like this, where trying to figure out exactly what piece of what patch did what, but that's the way it goes. So, to answer your question, "Yes, lots of stuff has changed recently with ZFS". -Kurt ------------------------------------------------------------------------ r243243 | ae | 2012-11-18 12:09:29 -0500 (Sun, 18 Nov 2012) | 135 lines MFC 239054,239057,239058,239060,239066,239067,239068,239070,239073, 239087,239088,239127,239210,239211,239230,239231,239232,239243, 239292,239293,239294,239325,240272,240273,240274,240275,240276, 240277,240335,240481,241023,241047,241053,241065,241068,241069, 241070,241164,241809,241876 239054: Create the interface to work with various partition tables from the loader(8). The following partition tables are supported: BSD label, GPT, MBR, EBR and VTOC8. 239057: Remove unused variables. 239058: Introduce new API to work with disks from the loader's drivers. It uses new API from the part.c to work with partition tables. 239060: When GPT signature is invalid in the primary GPT header, then try to read backup GPT header. 239066: Add offset field to the i386_devdesc structure to be compatible with disk_devdesc structure. Update biosdisk driver to the new disk API. 239067: Remove unneeded flag. 239068: Teach the ZFS use new partitions API when probing. Note: now ZFS does probe only for partitions with type "freebsd-zfs" and "freebsd". 239070: Add simple test program that uses the partition tables handling code. It is useful to test and debug how boot loader handles partition tables metadata. 239073: Bump USERBOOT_VERSION. 239087: Add to the debug output the offset from the parent partitioning scheme. 239088: Fix start offset calculation for the EBR partitions. 239127: As it turned out, there are some installations, where BSD label contains partitions with type zero. And it has worked. So, allow detect these partitions. 239210: Add more debug messages. 239211: Add another debug message. 239230: Unbreak booting from the true dedicated disks. When we open the disk, check the type of partition table, that has been detected. If this is BSD label, then we assume this is DD mode. 239231: Remove colons from the debug message, device name returned by the disk_fmtdev() already has the colons. 239232: Restore the old behaviour. If requested partition is a BSD slice, but d_partition isn't explicitly set, then try to open BSD label and its first partition. 239243: After r239066, reinitialize v86.ctl and v86.addr for int 13 EDD probing in sys/boot/i386/libi386/biosdisk.c. Otherwise, when DISK_DEBUG is enabled, the DEBUG() macros will clobber those fields, and cause the probing to always fail mysteriously when debugging is enabled. 239292: Explicitly terminate the string after strncpy(3). 239293: Rework r239232 to unbreak ZFS detection on MBR slices. 239294: Some BIOSes return incorrect number of sectors, make checks less strictly, to do not lost some partitions. 239325: Add comment why the code has been disabled. 240272: Make struct uboot_devdesc compatible with struct disk_devdesc. 240273: Use disk_fmtdev() and disk_parsedev() functions from the new DISK API. 240274: Update uboot's disk driver to use new DISK API. 240275: Build disk.c only when DISK_SUPPORT is enabled. 240276: Update according to the change of struct uboot_devdesc. 240277: Handle LOADER_NO_DISK_SUPPORT knob in the arm and powerpc ubldr. 240335: Slightly reduce an overhead for the open() call in the zfsloader. libstand(3) tries to detect file system in the predefined order, but zfsloader usually is used for the booting from ZFS, and there is no need to try detect several file system types for each open() call. 240481: The MBR data is not necessarily aligned. This is a problem on ARM. 241023: Make the loader a bit smarter, when it tries to open disk and the slice number is not exactly specified. When the disk has MBR, also try to read BSD label after ptable_getpart() call. When the disk has GPT, also set d_partition to 255. Mostly, this is how it worked before. 241047: Disable splitfs support, since we aren't support floppies for a long time. This slightly reduces an overhead, when loader tries to open file that doesn't exist. 241053: Almost each time when loader opens a file, this leads to calling disk_open(). Very often this is called several times for one file. This leads to reading partition table metadata for each call. To reduce the number of disk I/O we have a simple block cache, but it is very dumb and more than half of I/O operations related to reading metadata, misses this cache. Introduce new cache layer to resolve this problem. It is independent and doesn't need initialization like bcache, and will work by default for all loaders which use the new DISK API. A successful disk_open() call to each new disk or partition produces new entry in the cache. Even more, when disk was already open, now opening of any nested partitions does not require reading top level partition table. So, if without this cache, partition table metadata was read around 20-50 times during boot, now it reads only once. This affects the booting from GPT and MBR from the UFS. 241065: Fix disk_cleanup() to work without DISK_DEBUG too. 241068: Reduce the number of attempts to detect proper kld format for the amd64 loader. 241069: Remember the file format of the last loaded module and try to use it for next files. 241070: Fix the style. 241164: Replace all references to loader_callbacks_v1 with loader_callbacks. 241809: Add the flags parameter to the disk_open() function and DISK_F_NOCACHE flag, that disables the caching of partition tables metadata. Use this flag for floppies in the libi386/biosdisk driver. 241876: When loader tries to open GPT partition, but partition table is not GPT, then try automatically detect an appropriate partition type. ------------------------------------------------------------------------ > > - Chris > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 30 17:24:29 2012 Return-Path: Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E096503 for ; Sun, 30 Dec 2012 17:24:29 +0000 (UTC) (envelope-from fazli932@gmail.com) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6128FC0C for ; Sun, 30 Dec 2012 17:24:29 +0000 (UTC) Received: by mail-da0-f49.google.com with SMTP id v40so5490266dad.36 for ; Sun, 30 Dec 2012 09:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:subject:to:mime-version :content-type:content-disposition:content-transfer-encoding; bh=ReqSxlclpyx++2Q9QhfIGl82RxYdmUEPQrjpfLf2+5Y=; b=b/e1MMA7/yFbL5ydDewm2BO13M39Bdo6a4jpYl9BchnF31VKfUdtgybEBIRHn2M93+ DMyew3oJHhZMLd0dHsNkOvS6AX5BHZIcpjohKX2cqS3LNO0//CGS7nDnE2kawKLNNZSV Fudu3Ny1yc/hdVyO0CRdnAEg0Bc/erKKQ37Kuzv0g8g7psaVW2ML7TcTdJH8aNxWjw1p ZGqUr+CRjfDlvfGShBomLC9PgZgYzBj4jWgMpGCbZBb+L6Cy3jB0FZ3eVQgrGlsOd6Cm bVdJfwlkyYXccuv05BgTlKHHFUcbiP8Fy3NYwiT7I0ctHD3yOJJsM/2ylTaAJDK4bQ0q Ys7g== X-Received: by 10.66.82.35 with SMTP id f3mr114717427pay.49.1356888263684; Sun, 30 Dec 2012 09:24:23 -0800 (PST) Received: from [10.134.1.47] ([203.82.95.158]) by mx.google.com with ESMTPS id kp4sm23380573pbc.52.2012.12.30.09.24.21 (version=SSLv3 cipher=OTHER); Sun, 30 Dec 2012 09:24:23 -0800 (PST) Message-ID: <50e078c7.64cb440a.52cc.ffff98de@mx.google.com> Date: Mon, 31 Dec 2012 01:20:40 +0800 From: "Md Fazli" Subject: To: freebsd-sparc@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 17:24:29 -0000 Sent using a Sony Ericsson mobile phone From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 30 18:21:38 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 462FEA0F; Sun, 30 Dec 2012 18:21:38 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C724A8FC08; Sun, 30 Dec 2012 18:21:37 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBUILbMs076137; Sun, 30 Dec 2012 11:21:37 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBUILXIv084724; Sun, 30 Dec 2012 11:21:33 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Scott Long In-Reply-To: <2D98F70D-4031-4860-BABB-1F4663896234@yahoo.com> References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> <1356381775.1129.181.camel@revolution.hippie.lan> <1356390225.1129.217.camel@revolution.hippie.lan> <2D98F70D-4031-4860-BABB-1F4663896234@yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 30 Dec 2012 11:21:33 -0700 Message-ID: <1356891693.54953.31.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 30 Dec 2012 18:41:11 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, "mav@freebsd.org Motin" , "attilio@FreeBSD.org Rao" , Jeff Roberson , sparc64@freebsd.org, arm@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:21:38 -0000 On Mon, 2012-12-24 at 22:13 -0500, Scott Long wrote: > >>> > >>> Still unresolved is what to do about the remaining cases -- attempts to > >>> do dma in arbitrary buffers not obtained from bus_dmamem_alloc() which > >>> are not aligned and padded appropriately. There was some discussion a > >>> while back, but no clear resolution. I decided not to get bogged down > >>> by that fact and to fix the mbuf and allocated-buffer situations that we > >>> know how to deal with for now. > >> > > Why would these allocations not be handled as normal dynamic buffers > would with bus_dmamap_load()? > > Scott That's my point -- for "normal dynamic buffers" (that is, they weren't obtained from bus_dmamem_alloc() and they aren't mbufs) which can have arbitrary alignment and padding in relation to cache line boundaries -- we don't handle them correctly now unless they're accidentally already aligned and sized to the right boundaries. What's unresolved is how to handle them correctly if they're not aligned/padded, that is, what to do about them that avoids needing a partial cacheline flush at sync time. -- Ian From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 30 18:26:13 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20BB9B2C for ; Sun, 30 Dec 2012 18:26:13 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by mx1.freebsd.org (Postfix) with ESMTP id 883C08FC15 for ; Sun, 30 Dec 2012 18:26:12 +0000 (UTC) Received: from [98.139.212.144] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 30 Dec 2012 18:23:15 -0000 Received: from [98.139.211.161] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 30 Dec 2012 18:23:14 -0000 Received: from [127.0.0.1] by smtp218.mail.bf1.yahoo.com with NNFMP; 30 Dec 2012 18:23:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356891794; bh=aQikHoh3iRhB0ugZltL00Av3n8BidDAaxqutBqlcXws=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=0Abgj6ZaJs6W3BzC3y+bpmSA3qoQgVYZx3rCuJ7z2BGezcVpG/HTb0GV8TRK8yplfxf8fP6L0LKs2Ep9PdKk0VBWomd1A3JnrJIueWvby13MYbqKQagoOJzNref71o4y/PoFeoTP3e9Lve1hVQu6tGdfLNY+MAmLYRC2qv72gjw= X-Yahoo-Newman-Id: 957165.61229.bm@smtp218.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GTgpwDIVM1mAXIqTAHCqTGsphgy8mZCs0IqZ67iLbIZ9g7h 9tOoC80117cgOO14mQbz.9qXgzlfJvi7gKnfzOW8kCf5fkrdcZf3NLHWrdmn KwztSwTf9XFo0u6SG4vFR4uUHSPRuR9R2HPjyMnVTt7xxJFXYJeVaj0FRPVi Zc7Wqn7ZRYT3m6.RHQMaK4w1Tnyz94fB4DMpXQJu5FnWbTV9iybZn9NWSgoq bgvyqP44EMeXlkYNw4e.9GQexvDCUICUsyr3haVwjrBC5ASl8wQVuhFXMc.m EeNmtaHnTdeI2PK_3yusuKkldRc40KOw.vrr1tYfucOOPO9hMxt60e4ArwVZ SncC4rdwxdfdQiXOEELh2xU_pVvhjhFEGZMm7dtjDCSxBfSb0wzFKP4vvInI LQOnUakQovuviwk3.uDZXYAEinyHIEY7SNP5q_HOTy.5mWj8kcbZJ0wXVOIy 6MPcqd9jlORhk1g-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Received: from [10.64.26.18] (scott4long@69.53.237.126 with plain) by smtp218.mail.bf1.yahoo.com with SMTP; 30 Dec 2012 10:23:14 -0800 PST Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Call for testing and review, busdma changes From: Scott Long In-Reply-To: <1356891693.54953.31.camel@revolution.hippie.lan> Date: Sun, 30 Dec 2012 11:23:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30DCC8A9-8E26-4500-AF33-2D81981B554F@yahoo.com> References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> <1356381775.1129.181.camel@revolution.hippie.lan> <1356390225.1129.217.camel@revolution.hippie.lan> <2D98F70D-4031-4860-BABB-1F4663896234@yahoo.com> <1356891693.54953.31.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sun, 30 Dec 2012 19:48:47 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, "mav@freebsd.org Motin" , "attilio@FreeBSD.org Rao" , Jeff Roberson , sparc64@freebsd.org, arm@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:26:13 -0000 On Dec 30, 2012, at 11:21 AM, Ian Lepore = wrote: > On Mon, 2012-12-24 at 22:13 -0500, Scott Long wrote: >>>>>=20 >>>>> Still unresolved is what to do about the remaining cases -- = attempts to >>>>> do dma in arbitrary buffers not obtained from bus_dmamem_alloc() = which >>>>> are not aligned and padded appropriately. There was some = discussion a >>>>> while back, but no clear resolution. I decided not to get bogged = down >>>>> by that fact and to fix the mbuf and allocated-buffer situations = that we >>>>> know how to deal with for now. >>>>=20 >>=20 >> Why would these allocations not be handled as normal dynamic buffers >> would with bus_dmamap_load()? >>=20 >> Scott >=20 > That's my point -- for "normal dynamic buffers" (that is, they weren't > obtained from bus_dmamem_alloc() and they aren't mbufs) which can have > arbitrary alignment and padding in relation to cache line boundaries = -- > we don't handle them correctly now unless they're accidentally already > aligned and sized to the right boundaries. What's unresolved is how = to > handle them correctly if they're not aligned/padded, that is, what to = do > about them that avoids needing a partial cacheline flush at sync time. >=20 Alignment is already handled. Scott From owner-freebsd-sparc64@FreeBSD.ORG Sun Dec 30 18:28:42 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C5DCD08; Sun, 30 Dec 2012 18:28:42 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4258FC0A; Sun, 30 Dec 2012 18:28:41 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBUISebg076182; Sun, 30 Dec 2012 11:28:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBUISbWD084746; Sun, 30 Dec 2012 11:28:37 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Scott Long In-Reply-To: <30DCC8A9-8E26-4500-AF33-2D81981B554F@yahoo.com> References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> <1356381775.1129.181.camel@revolution.hippie.lan> <1356390225.1129.217.camel@revolution.hippie.lan> <2D98F70D-4031-4860-BABB-1F4663896234@yahoo.com> <1356891693.54953.31.camel@revolution.hippie.lan> <30DCC8A9-8E26-4500-AF33-2D81981B554F@yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 30 Dec 2012 11:28:37 -0700 Message-ID: <1356892117.54953.37.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 30 Dec 2012 19:48:54 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, "mav@freebsd.org Motin" , "attilio@FreeBSD.org Rao" , Jeff Roberson , sparc64@freebsd.org, arm@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 18:28:42 -0000 On Sun, 2012-12-30 at 11:23 -0700, Scott Long wrote: > On Dec 30, 2012, at 11:21 AM, Ian Lepore wrote: > > > On Mon, 2012-12-24 at 22:13 -0500, Scott Long wrote: > >>>>> > >>>>> Still unresolved is what to do about the remaining cases -- attempts to > >>>>> do dma in arbitrary buffers not obtained from bus_dmamem_alloc() which > >>>>> are not aligned and padded appropriately. There was some discussion a > >>>>> while back, but no clear resolution. I decided not to get bogged down > >>>>> by that fact and to fix the mbuf and allocated-buffer situations that we > >>>>> know how to deal with for now. > >>>> > >> > >> Why would these allocations not be handled as normal dynamic buffers > >> would with bus_dmamap_load()? > >> > >> Scott > > > > That's my point -- for "normal dynamic buffers" (that is, they weren't > > obtained from bus_dmamem_alloc() and they aren't mbufs) which can have > > arbitrary alignment and padding in relation to cache line boundaries -- > > we don't handle them correctly now unless they're accidentally already > > aligned and sized to the right boundaries. What's unresolved is how to > > handle them correctly if they're not aligned/padded, that is, what to do > > about them that avoids needing a partial cacheline flush at sync time. > > > > Alignment is already handled. > > Scott > No it's not. -- Ian From owner-freebsd-sparc64@FreeBSD.ORG Mon Dec 31 11:06:51 2012 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4615D11 for ; Mon, 31 Dec 2012 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C7FCF8FC1D for ; Mon, 31 Dec 2012 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBVB6ptC081015 for ; Mon, 31 Dec 2012 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBVB6pO0081013 for freebsd-sparc64@FreeBSD.org; Mon, 31 Dec 2012 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Dec 2012 11:06:51 GMT Message-Id: <201212311106.qBVB6pO0081013@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 11:06:52 -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 sparc/170663 sparc64 panics with VIA 6421 SATA150 controller on Blade 1500 o sparc/169669 sparc64 Something seems broken in sparc64 TLS or lang/lua o sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 s sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 11 problems total.