From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 01:52:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5984106564A for ; Sun, 3 Oct 2010 01:52:55 +0000 (UTC) (envelope-from prvs=1892e23437=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3B08FC16 for ; Sun, 3 Oct 2010 01:52:55 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 03 Oct 2010 02:42:24 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 03 Oct 2010 02:42:23 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011345411.msg for ; Sun, 03 Oct 2010 02:42:23 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1892e23437=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <4EA584AB40D644BFAC3E46787D468CE8@multiplay.co.uk> From: "Steven Hartland" To: "Rumen Telbizov" References: Date: Sun, 3 Oct 2010 02:42:22 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: MySQL performance concern X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 01:52:56 -0000 You similar hardware specs are hardly similar an 8 core 2.3Ghz box vs a 4 core 1.8Ghz according to Intel cpu comparison:- http://ark.intel.com/Compare.aspx?ids=3D37092,33080, If you want to compare you really need to do so on the same hardware or all bets are off. Regards Steve ----- Original Message -----=20 From: Rumen Telbizov=20 To: Steven Hartland=20 Cc: freebsd-stable@freebsd.org=20 Sent: Saturday, October 02, 2010 9:18 PM Subject: Re: MySQL performance concern Hello everyone, Here's the requested information below: FreeBSD mysql 5.1.51: my.cnf: skip-external-locking key_buffer_size =3D 8192M max_allowed_packet =3D 16M table_open_cache =3D 2048 sort_buffer_size =3D 64M read_buffer_size =3D 8M read_rnd_buffer_size =3D 16M myisam_sort_buffer_size =3D 256M thread_cache_size =3D 64 query_cache_size =3D 32M thread_concurrency =3D 8 max_heap_table_size =3D 6G hardware: FreeBSD 8.1-STABLE amd64 (Tue Sep 14 15:29:22 PDT 2010) running on a SuperMicro machine with X8DTU motherboard and 2 x Dual Core Xeon E5502 1.87Ghz ; 4 x SAS 15K in RAID10 setup under ZFS (two mirrored pairs) and 2 x SSD X25-E partitioned for: 8G for ZIL and the rest for L2ARC; 16G RAM. Disk controller is LSI 4Hi in IT (Initiator Target) mode. -- Linux Gentoo (2.6.18-164.10.1.el5.028stab067.4) mysql 5.1.50 -- my.cnf: skip-external-locking key_buffer =3D 4G max_heap_table_size =3D 6G max_allowed_packet =3D 1M table_cache =3D 64 sort_buffer_size =3D 512K net_buffer_length =3D 8K read_buffer_size =3D 256K read_rnd_buffer_size =3D 512K myisam_sort_buffer_size =3D 8M Linux runs as an OpenVZ VE inside CentOS. It's the only VE and has all the memory allocated to it hardware node: 2 x Xeon Quad E5410 @ 2.33GHz on SuperMicro X7DBU motherboard; 16G RAM; 4 SATA 1T disks in hardware raid 5 attached to a 3ware controller; NO SSDs Some other notes: * It is indeed a single thread which inserts into the mysql so yes it's only one core which handles the application and another one for MySQL. What is interesting here, like I mentioned, is that on FreeBSD mysql process doesn't get more than 30-40% CPU utilization. So it has a lot of headroom. gstat also shows 0% disk load * It is exactly the same database schema. In fact it's only one table that's inserted heavily into. It is a partition table with only one HASH index which looks something like this: PRIMARY KEY (`IntField`,`DateField`,`Varchar150Field`) USING HASH. The speed difference is obvious right from the beginning. I don't have to wait for any data to accrue to see a degradation. I don't wait for more than a 100'000 records to be processed. * Application maintains only 1 local TCP connection to mysql. They both run on the same host * As for the ZFS. Here's the pool configuration: pool: tank config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/tank0 ONLINE 0 0 0 gpt/tank1 ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/tank2 ONLINE 0 0 0 gpt/tank3 ONLINE 0 0 0 logs ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/zil0 ONLINE 0 0 0 gpt/zil1 ONLINE 0 0 0 cache gpt/l2arc0 ONLINE 0 0 0 gpt/l2arc1 ONLINE 0 0 0 pool: zroot config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/zroot0 ONLINE 0 0 0 gpt/zroot1 ONLINE 0 0 0 zroot is a couple of small partitions from two of the same SAS disks. zil and l2arc are 8 and 22G partitions from 32G SSDs I pretty much have no zfs tuning done since from what I've found there shouldn't be any needed since I'm running 8.1 on a 64bit machine. Let me know if you'd like me to experiment with any ... Some additional information: # sysctl vm.kmem_size vm.kmem_size: 5539958784 # sysctl vm.kmem_size_max vm.kmem_size_max: 329853485875 # sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 4466216960 I think this answers all the questions so far. Let me know what you think. I might be missing something obvious. Thank you, Rumen Telbizov =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.=20 In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 02:04:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 959961065673 for ; Sun, 3 Oct 2010 02:04:35 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 363068FC12 for ; Sun, 3 Oct 2010 02:04:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 66BCE509A5; Sun, 3 Oct 2010 03:04:34 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcnXaPO7t1Ga; Sun, 3 Oct 2010 03:04:34 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id DD8D6509A3 ; Sun, 3 Oct 2010 03:04:33 +0100 (BST) Message-ID: <4CA7E4AE.4060607@langille.org> Date: Sat, 02 Oct 2010 22:04:30 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> In-Reply-To: <20101002235024.GA80643@icarus.home.lan> Content-Type: multipart/mixed; boundary="------------010500090204080302050204" Cc: freebsd-stable Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 02:04:35 -0000 This is a multi-part message in MIME format. --------------010500090204080302050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/2/2010 7:50 PM, Jeremy Chadwick wrote: > On Sat, Oct 02, 2010 at 07:23:16PM -0400, Dan Langille wrote: >> On 10/2/2010 6:36 PM, Jeremy Chadwick wrote: >>> On Sat, Oct 02, 2010 at 06:09:25PM -0400, Dan Langille wrote: >>>> On 10/2/2010 10:19 AM, Jeremy Chadwick wrote: >>>>> On Sat, Oct 02, 2010 at 09:43:30AM -0400, Dan Langille wrote: >>>>>> Overnight I was running a zfs send | zfs receive (both within the >>>>>> same system / zpool). The system ran out of space, a drive went off >>>>>> line, and the system is degraded. >>>>>> >>>>>> This is a raidz2 array running on FreeBSD 8.1-STABLE #0: Sat Sep 18 >>>>>> 23:43:48 EDT 2010. >>>>>> >>>>>> The following logs are also available at >>>>>> http://www.langille.org/tmp/zfs-space.txt<- no line wrapping >>>>>> >>>>>> This is what was running: >>>>>> >>>>>> # time zfs send storage/bacula@transfer | mbuffer | zfs receive >>>>>> storage/compressed/bacula-mbuffer >>>>>> in @ 0.0 kB/s, out @ 0.0 kB/s, 3670 GB total, buffer 100% >>>>>> fullcannot receive new filesystem stream: out of space >>>>>> mbuffer: error: outputThread: error writing to at offset >>>>>> 0x395917c4000: Broken pipe >>>>>> >>>>>> summary: 3670 GByte in 10 h 40 min 97.8 MB/s >>>>>> mbuffer: warning: error during output to: Broken pipe >>>>>> warning: cannot send 'storage/bacula@transfer': Broken pipe >>>>>> >>>>>> real 640m48.423s >>>>>> user 8m52.660s >>>>>> sys 211m40.862s >>>>>> >>>>>> >>>>>> Looking in the logs, I see this: >>>>>> >>>>>> Oct 2 00:50:53 kraken kernel: (ada0:siisch0:0:0:0): lost device >>>>>> Oct 2 00:50:54 kraken kernel: siisch0: Timeout on slot 30 >>>>>> Oct 2 00:50:54 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>> Oct 2 00:50:54 kraken kernel: siisch0: Error while READ LOG EXT >>>>>> Oct 2 00:50:55 kraken kernel: siisch0: Timeout on slot 30 >>>>>> Oct 2 00:50:55 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>> Oct 2 00:50:55 kraken kernel: siisch0: Error while READ LOG EXT >>>>>> Oct 2 00:50:56 kraken kernel: siisch0: Timeout on slot 30 >>>>>> Oct 2 00:50:56 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>> Oct 2 00:50:56 kraken kernel: siisch0: Error while READ LOG EXT >>>>>> Oct 2 00:50:57 kraken kernel: siisch0: Timeout on slot 30 >>>>>> Oct 2 00:50:57 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>> Oct 2 00:50:57 kraken kernel: siisch0: Error while READ LOG EXT >>>>>> Oct 2 00:50:58 kraken kernel: siisch0: Timeout on slot 30 >>>>>> Oct 2 00:50:58 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>> Oct 2 00:50:58 kraken kernel: siisch0: Error while READ LOG EXT >>>>>> Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage >>>>>> path=/dev/gpt/disk06-live offset=270336 size=8192 error=6 >>>>>> >>>>>> Oct 2 00:50:59 kraken kernel: (ada0:siisch0:0:0:0): Synchronize >>>>>> cache failed >>>>>> Oct 2 00:50:59 kraken kernel: (ada0:siisch0:0:0:0): removing device entry >>>>>> >>>>>> Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage >>>>>> path=/dev/gpt/disk06-live offset=2000187564032 size=8192 error=6 >>>>>> Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage >>>>>> path=/dev/gpt/disk06-live offset=2000187826176 size=8192 error=6 >>>>>> >>>>>> $ zpool status >>>>>> pool: storage >>>>>> state: DEGRADED >>>>>> scrub: scrub in progress for 5h32m, 17.16% done, 26h44m to go >>>>>> config: >>>>>> >>>>>> NAME STATE READ WRITE CKSUM >>>>>> storage DEGRADED 0 0 0 >>>>>> raidz2 DEGRADED 0 0 0 >>>>>> gpt/disk01-live ONLINE 0 0 0 >>>>>> gpt/disk02-live ONLINE 0 0 0 >>>>>> gpt/disk03-live ONLINE 0 0 0 >>>>>> gpt/disk04-live ONLINE 0 0 0 >>>>>> gpt/disk05-live ONLINE 0 0 0 >>>>>> gpt/disk06-live REMOVED 0 0 0 >>>>>> gpt/disk07-live ONLINE 0 0 0 >>>>>> >>>>>> $ zfs list >>>>>> NAME USED AVAIL REFER MOUNTPOINT >>>>>> storage 6.97T 1.91T 1.75G /storage >>>>>> storage/bacula 4.72T 1.91T 4.29T /storage/bacula >>>>>> storage/compressed 2.25T 1.91T 46.9K /storage/compressed >>>>>> storage/compressed/bacula 2.25T 1.91T 42.7K /storage/compressed/bacula >>>>>> storage/pgsql 5.50G 1.91T 5.50G /storage/pgsql >>>>>> >>>>>> $ sudo camcontrol devlist >>>>>> Password: >>>>>> at scbus2 target 0 lun 0 (pass1,ada1) >>>>>> at scbus3 target 0 lun 0 (pass2,ada2) >>>>>> at scbus4 target 0 lun 0 (pass3,ada3) >>>>>> at scbus5 target 0 lun 0 (pass4,ada4) >>>>>> at scbus6 target 0 lun 0 (pass5,ada5) >>>>>> at scbus7 target 0 lun 0 (pass6,ada6) >>>>>> at scbus8 target 0 lun 0 (pass7,ada7) >>>>>> at scbus9 target 0 lun 0 (cd0,pass8) >>>>>> at scbus10 target 0 lun 0 (pass9,ada8) >>>>>> >>>>>> I'm not yet sure if the drive is fully dead or not. This is not a >>>>>> hot-swap box. >>>>> >>>>> It looks to me like the disk labelled gpt/disk06-live literally stopped >>>>> responding to commands. The errors you see are coming from the OS and >>>>> the siis(4) controller, and both indicate the actual hard disk isn't >>>>> responding to the ATA command READ LOG EXT. error=6 means Device not >>>>> configured. >>>>> >>>>> I can't see how/why running out of space would cause this. It looks >>>>> more like that you had a hardware issue of some sort happen during the >>>>> course of the operations you were running. It may not have happened >>>>> until now because you hadn't utilised writes to that area of the disk >>>>> (could have bad sectors there, or physical media/platter problems). >>>>> >>>>> Please provide smartctl -a output for the drive that's gpt/disk06-live, >>>>> which I assume is /dev/ada6 (glabel sure makes correlation easy, doesn't >>>>> it? Sigh...). Please put the results up on the web somewhere, not >>>>> copy-pasted, otherwise I have to do a bunch of manual work with regarsd >>>>> to line wrapping/etc... I'll provide an analysis of SMART stats for >>>>> you, to see if anything crazy happened to the disk itself. >>>> >>>> It is ada0, I'm sure, based on the 'lost device' mentioned in >>>> /var/log/messages above. >>>> >>>> I'm getting nowhere. /dev/ada0 does not exist so there is nothing >>>> for smartctl to work on. >>>> >>>> [...] >>>> >>>> $ ls -l /dev/ada0* >>>> ls: /dev/ada0*: No such file or directory >>> >>> Okay, so gpt/disk06-live is /dev/ada0. (I won't ask why the label is >>> called "disk06", but whatever. :-) ) >>> >>>> I am tempted to reboot or do a camontrol scan. >>> >>> DO NOT REBOOT.You can try the following -- I'm not sure whether to >>> use scbus0 or scbus1 as the argument however, since I don't know what >>> scbusX number ada0 was attached to previously. "dmesg" from when the >>> machine booted would show this. >>> >>> camcontrol reset scbusX >>> camcontrol rescan scbusX >> >> I see this in /var/run/dmesg.boot: >> >> ada0 at siisch0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> >> $ sudo camcontrol reset scbus0 >> Password: >> Reset of bus 0 was successful >> >> $ sudo camcontrol rescan scbus0 >> Re-scan of bus 0 was successful >> >>> If the disk comes back, please smartctl -a it. >> >> I didn't come back: >> >> $ ls /dev/ada* >> /dev/ada1 /dev/ada2p1 /dev/ada4 /dev/ada5p1 /dev/ada7 >> /dev/ada1p1 /dev/ada3 /dev/ada4p1 /dev/ada6 /dev/ada8 >> /dev/ada2 /dev/ada3p1 /dev/ada5 /dev/ada6p1 >> >> FYI, there's nothing new in /var/log/messages as a results of those >> commands. > > Then I would recommend power-cycling (not rebooting or pressing of the > reset button) the machine. There's a good chance the ada0 disk has > fallen off the bus and needs a full power-cycle, since a LUN scan didn't > result in its reappearance. > > I see this kind of problem on a weekly basis at my workplace, in 3 > different datacenters, with Fujitsu SCSI-3 disks. A system reboot > doesn't make the disk reappear on on the bus, nor does a reset (pressing > of the reset button). Only a full power-cycle works. And when I say > weekly, I'm not exaggerating. > > I realise your disks are Hitachi not Fujitsu, and are SATA not SCSI, but > it really doesn't matter -- there are cases where the drive firmware is > wedged so hard that a physical power-cycle is required. > > If a power-cycle works, smartctl -a /dev/ada0 the disk and save the > SMART stats somewhere. If the same disk fails in this way again, I > strongly recommend advance RMA'ing it (to ensure you get a completely > different disk). > > Good luck! thanks. After a 'shutdown -p now', it was about 20 minutes before I went and powered it up (I was on minecraft). The box came back with the missing HDD: $ zpool status storage pool: storage state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk01-live ONLINE 0 0 0 gpt/disk02-live ONLINE 0 0 0 gpt/disk03-live ONLINE 0 0 0 gpt/disk04-live ONLINE 0 0 0 gpt/disk05-live ONLINE 0 0 0 gpt/disk06-live ONLINE 0 0 12 gpt/disk07-live ONLINE 0 0 0 smartctl output attached and and http://www.langille.org/tmp/ada0.txt -- Dan Langille - http://langille.org/ --------------010500090204080302050204 Content-Type: text/plain; name="ada0.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ada0.txt" $ sudo smartctl -a /dev/ada0 smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.1-STABLE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Hitachi Deskstar 7K2000 Device Model: Hitachi HDS722020ALA330 Serial Number: JK1131YAHLJWLV Firmware Version: JKAOA28A User Capacity: 2,000,398,934,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Sat Oct 2 21:59:03 2010 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (22771) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 255) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 132 132 054 Pre-fail Offline - 103 3 Spin_Up_Time 0x0007 180 180 024 Pre-fail Always - 441 (Average 361) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 17 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 114 114 020 Pre-fail Offline - 38 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 1671 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 17 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 28 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 28 194 Temperature_Celsius 0x0002 181 181 000 Old_age Always - 33 (Lifetime Min/Max 25/42) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 SMART Error Log Version: 0 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. --------------010500090204080302050204-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 02:26:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11C5A106566C for ; Sun, 3 Oct 2010 02:26:06 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id D243E8FC12 for ; Sun, 3 Oct 2010 02:26:05 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o932Bd4C048116 for ; Sat, 2 Oct 2010 19:11:39 -0700 (PDT) Message-Id: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: freebsd-stable Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Oct 2010 19:11:39 -0700 From: Dave Hayes Subject: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 02:26:06 -0000 What does the above mentioned panic mean? I'm booting from an mfsroot off of a DVD with a loader.conf like this: autoboot_delay="5" mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/mfsboot" vfs.root.mountfrom="ufs:md0" vfs.root.mountfrom.options="rw" kern.ipc.nmbclusters=32768 net.inet.tcp.tcbhashsize=16384 vm.pmap.pg_ps_enabled=1 vm.kmem_size="2G" accf_http_load="YES" net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 This is FreeBSD 8.1-RELEASE amd64 running with the debugger installed into the kernel. Thanks in advance for any insight provided. :) -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< No one is lazy except in the pursuit of another one's goal. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 02:37:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1204310656AA for ; Sun, 3 Oct 2010 02:37:50 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id AA7B18FC12 for ; Sun, 3 Oct 2010 02:37:49 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id E2NU1f0051ei1Bg5A2Qabr; Sun, 03 Oct 2010 02:24:34 +0000 Received: from [10.0.0.51] ([71.199.122.142]) by omta24.westchester.pa.mail.comcast.net with comcast id E2Qa1f00134Sj4f3k2QaHk; Sun, 03 Oct 2010 02:24:34 +0000 Message-ID: <4CA7E98E.3040701@comcast.net> Date: Sat, 02 Oct 2010 22:25:18 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dan Langille References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> In-Reply-To: <4CA7E4AE.4060607@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Jeremy Chadwick Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 02:37:50 -0000 On 10/2/2010 10:04 PM, Dan Langille wrote: > On 10/2/2010 7:50 PM, Jeremy Chadwick wrote: >> On Sat, Oct 02, 2010 at 07:23:16PM -0400, Dan Langille wrote: >>> On 10/2/2010 6:36 PM, Jeremy Chadwick wrote: >>>> On Sat, Oct 02, 2010 at 06:09:25PM -0400, Dan Langille wrote: >>>>> On 10/2/2010 10:19 AM, Jeremy Chadwick wrote: >>>>>> On Sat, Oct 02, 2010 at 09:43:30AM -0400, Dan Langille wrote: >>>>>>> Overnight I was running a zfs send | zfs receive (both within the >>>>>>> same system / zpool). The system ran out of space, a drive went >>>>>>> off >>>>>>> line, and the system is degraded. >>>>>>> >>>>>>> This is a raidz2 array running on FreeBSD 8.1-STABLE #0: Sat Sep 18 >>>>>>> 23:43:48 EDT 2010. >>>>>>> >>>>>>> The following logs are also available at >>>>>>> http://www.langille.org/tmp/zfs-space.txt<- no line wrapping >>>>>>> >>>>>>> This is what was running: >>>>>>> >>>>>>> # time zfs send storage/bacula@transfer | mbuffer | zfs receive >>>>>>> storage/compressed/bacula-mbuffer >>>>>>> in @ 0.0 kB/s, out @ 0.0 kB/s, 3670 GB total, buffer 100% >>>>>>> fullcannot receive new filesystem stream: out of space >>>>>>> mbuffer: error: outputThread: error writing to at offset >>>>>>> 0x395917c4000: Broken pipe >>>>>>> >>>>>>> summary: 3670 GByte in 10 h 40 min 97.8 MB/s >>>>>>> mbuffer: warning: error during output to: Broken pipe >>>>>>> warning: cannot send 'storage/bacula@transfer': Broken pipe >>>>>>> >>>>>>> real 640m48.423s >>>>>>> user 8m52.660s >>>>>>> sys 211m40.862s >>>>>>> >>>>>>> >>>>>>> Looking in the logs, I see this: >>>>>>> >>>>>>> Oct 2 00:50:53 kraken kernel: (ada0:siisch0:0:0:0): lost device >>>>>>> Oct 2 00:50:54 kraken kernel: siisch0: Timeout on slot 30 >>>>>>> Oct 2 00:50:54 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>>> Oct 2 00:50:54 kraken kernel: siisch0: Error while READ LOG EXT >>>>>>> Oct 2 00:50:55 kraken kernel: siisch0: Timeout on slot 30 >>>>>>> Oct 2 00:50:55 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>>> Oct 2 00:50:55 kraken kernel: siisch0: Error while READ LOG EXT >>>>>>> Oct 2 00:50:56 kraken kernel: siisch0: Timeout on slot 30 >>>>>>> Oct 2 00:50:56 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>>> Oct 2 00:50:56 kraken kernel: siisch0: Error while READ LOG EXT >>>>>>> Oct 2 00:50:57 kraken kernel: siisch0: Timeout on slot 30 >>>>>>> Oct 2 00:50:57 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>>> Oct 2 00:50:57 kraken kernel: siisch0: Error while READ LOG EXT >>>>>>> Oct 2 00:50:58 kraken kernel: siisch0: Timeout on slot 30 >>>>>>> Oct 2 00:50:58 kraken kernel: siisch0: siis_timeout is 00040000 ss >>>>>>> 40000000 rs 40000000 es 00000000 sts 801f0040 serr 00000000 >>>>>>> Oct 2 00:50:58 kraken kernel: siisch0: Error while READ LOG EXT >>>>>>> Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage >>>>>>> path=/dev/gpt/disk06-live offset=270336 size=8192 error=6 >>>>>>> >>>>>>> Oct 2 00:50:59 kraken kernel: (ada0:siisch0:0:0:0): Synchronize >>>>>>> cache failed >>>>>>> Oct 2 00:50:59 kraken kernel: (ada0:siisch0:0:0:0): removing >>>>>>> device entry >>>>>>> >>>>>>> Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage >>>>>>> path=/dev/gpt/disk06-live offset=2000187564032 size=8192 error=6 >>>>>>> Oct 2 00:50:59 kraken root: ZFS: vdev I/O failure, zpool=storage >>>>>>> path=/dev/gpt/disk06-live offset=2000187826176 size=8192 error=6 >>>>>>> >>>>>>> $ zpool status >>>>>>> pool: storage >>>>>>> state: DEGRADED >>>>>>> scrub: scrub in progress for 5h32m, 17.16% done, 26h44m to go >>>>>>> config: >>>>>>> >>>>>>> NAME STATE READ WRITE CKSUM >>>>>>> storage DEGRADED 0 0 0 >>>>>>> raidz2 DEGRADED 0 0 0 >>>>>>> gpt/disk01-live ONLINE 0 0 0 >>>>>>> gpt/disk02-live ONLINE 0 0 0 >>>>>>> gpt/disk03-live ONLINE 0 0 0 >>>>>>> gpt/disk04-live ONLINE 0 0 0 >>>>>>> gpt/disk05-live ONLINE 0 0 0 >>>>>>> gpt/disk06-live REMOVED 0 0 0 >>>>>>> gpt/disk07-live ONLINE 0 0 0 >>>>>>> >>>>>>> $ zfs list >>>>>>> NAME USED AVAIL REFER MOUNTPOINT >>>>>>> storage 6.97T 1.91T 1.75G /storage >>>>>>> storage/bacula 4.72T 1.91T 4.29T /storage/bacula >>>>>>> storage/compressed 2.25T 1.91T 46.9K /storage/compressed >>>>>>> storage/compressed/bacula 2.25T 1.91T 42.7K >>>>>>> /storage/compressed/bacula >>>>>>> storage/pgsql 5.50G 1.91T 5.50G /storage/pgsql >>>>>>> >>>>>>> $ sudo camcontrol devlist >>>>>>> Password: >>>>>>> at scbus2 target 0 lun 0 >>>>>>> (pass1,ada1) >>>>>>> at scbus3 target 0 lun 0 >>>>>>> (pass2,ada2) >>>>>>> at scbus4 target 0 lun 0 >>>>>>> (pass3,ada3) >>>>>>> at scbus5 target 0 lun 0 >>>>>>> (pass4,ada4) >>>>>>> at scbus6 target 0 lun 0 >>>>>>> (pass5,ada5) >>>>>>> at scbus7 target 0 lun 0 >>>>>>> (pass6,ada6) >>>>>>> at scbus8 target 0 lun 0 >>>>>>> (pass7,ada7) >>>>>>> at scbus9 target 0 lun 0 >>>>>>> (cd0,pass8) >>>>>>> at scbus10 target 0 lun 0 >>>>>>> (pass9,ada8) >>>>>>> >>>>>>> I'm not yet sure if the drive is fully dead or not. This is not a >>>>>>> hot-swap box. >>>>>> >>>>>> It looks to me like the disk labelled gpt/disk06-live literally >>>>>> stopped >>>>>> responding to commands. The errors you see are coming from the >>>>>> OS and >>>>>> the siis(4) controller, and both indicate the actual hard disk isn't >>>>>> responding to the ATA command READ LOG EXT. error=6 means Device >>>>>> not >>>>>> configured. >>>>>> >>>>>> I can't see how/why running out of space would cause this. It looks >>>>>> more like that you had a hardware issue of some sort happen >>>>>> during the >>>>>> course of the operations you were running. It may not have happened >>>>>> until now because you hadn't utilised writes to that area of the >>>>>> disk >>>>>> (could have bad sectors there, or physical media/platter problems). >>>>>> >>>>>> Please provide smartctl -a output for the drive that's >>>>>> gpt/disk06-live, >>>>>> which I assume is /dev/ada6 (glabel sure makes correlation easy, >>>>>> doesn't >>>>>> it? Sigh...). Please put the results up on the web somewhere, not >>>>>> copy-pasted, otherwise I have to do a bunch of manual work with >>>>>> regarsd >>>>>> to line wrapping/etc... I'll provide an analysis of SMART stats for >>>>>> you, to see if anything crazy happened to the disk itself. >>>>> >>>>> It is ada0, I'm sure, based on the 'lost device' mentioned in >>>>> /var/log/messages above. >>>>> >>>>> I'm getting nowhere. /dev/ada0 does not exist so there is nothing >>>>> for smartctl to work on. >>>>> >>>>> [...] >>>>> >>>>> $ ls -l /dev/ada0* >>>>> ls: /dev/ada0*: No such file or directory >>>> >>>> Okay, so gpt/disk06-live is /dev/ada0. (I won't ask why the label is >>>> called "disk06", but whatever. :-) ) >>>> >>>>> I am tempted to reboot or do a camontrol scan. >>>> >>>> DO NOT REBOOT.You can try the following -- I'm not sure whether to >>>> use scbus0 or scbus1 as the argument however, since I don't know what >>>> scbusX number ada0 was attached to previously. "dmesg" from when the >>>> machine booted would show this. >>>> >>>> camcontrol reset scbusX >>>> camcontrol rescan scbusX >>> >>> I see this in /var/run/dmesg.boot: >>> >>> ada0 at siisch0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-8 SATA 2.x device >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> >>> $ sudo camcontrol reset scbus0 >>> Password: >>> Reset of bus 0 was successful >>> >>> $ sudo camcontrol rescan scbus0 >>> Re-scan of bus 0 was successful >>> >>>> If the disk comes back, please smartctl -a it. >>> >>> I didn't come back: >>> >>> $ ls /dev/ada* >>> /dev/ada1 /dev/ada2p1 /dev/ada4 /dev/ada5p1 /dev/ada7 >>> /dev/ada1p1 /dev/ada3 /dev/ada4p1 /dev/ada6 /dev/ada8 >>> /dev/ada2 /dev/ada3p1 /dev/ada5 /dev/ada6p1 >>> >>> FYI, there's nothing new in /var/log/messages as a results of those >>> commands. >> >> Then I would recommend power-cycling (not rebooting or pressing of the >> reset button) the machine. There's a good chance the ada0 disk has >> fallen off the bus and needs a full power-cycle, since a LUN scan didn't >> result in its reappearance. >> >> I see this kind of problem on a weekly basis at my workplace, in 3 >> different datacenters, with Fujitsu SCSI-3 disks. A system reboot >> doesn't make the disk reappear on on the bus, nor does a reset (pressing >> of the reset button). Only a full power-cycle works. And when I say >> weekly, I'm not exaggerating. >> >> I realise your disks are Hitachi not Fujitsu, and are SATA not SCSI, but >> it really doesn't matter -- there are cases where the drive firmware is >> wedged so hard that a physical power-cycle is required. >> >> If a power-cycle works, smartctl -a /dev/ada0 the disk and save the >> SMART stats somewhere. If the same disk fails in this way again, I >> strongly recommend advance RMA'ing it (to ensure you get a completely >> different disk). >> >> Good luck! > > thanks. > > After a 'shutdown -p now', it was about 20 minutes before I went and > powered it up (I was on minecraft). The box came back with the > missing HDD: > > $ zpool status storage > pool: storage > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. > action: Determine if the device needs to be replaced, and clear the > errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > gpt/disk01-live ONLINE 0 0 0 > gpt/disk02-live ONLINE 0 0 0 > gpt/disk03-live ONLINE 0 0 0 > gpt/disk04-live ONLINE 0 0 0 > gpt/disk05-live ONLINE 0 0 0 > gpt/disk06-live ONLINE 0 0 12 > gpt/disk07-live ONLINE 0 0 0 > > > smartctl output attached and and http://www.langille.org/tmp/ada0.txt > I thin its worth it to think about TLER (or the absence of it) here - http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery . Your consumer / SATA Hitachi drives likely do not put a limit on the time the drive may block on a command while handling inernal errors. If we consider that gpt/gisk06-live encountered some kind of error and had to relocate a significant number of blocks or perform some other error recovery, then it very well may have timed out long enough for siis(4) to drop the device. I have no idea what the timeouts are set to in the siis(4) driver, nor does anything in your SMART report stick out to me (though I'm certainly no expert with SMART data, and my understanding is that many drive manufacturers report the various parameters in different ways). What I can tell you is that I have seen similar timeouts once or twice in a ZFS system with siis(4). The particular system is using drives on port multipliers, and I can't find records of it resulting in a device being lost. Once a whole port multiplier reported timeouts (one message for each of the 5 drives), afterwards the whole PMP and all of the drives came back online immediately afterwards. - Steve From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 06:18:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B505B106564A for ; Sun, 3 Oct 2010 06:18:14 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 763F68FC12 for ; Sun, 3 Oct 2010 06:18:14 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 3E8938A2866; Sun, 3 Oct 2010 08:18:13 +0200 (CEST) Message-ID: <4CA82024.8010503@bsdforen.de> Date: Sun, 03 Oct 2010 08:18:12 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.12) Gecko/20100918 Thunderbird/3.0.8 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4CA78EE3.9020005@quip.cz> In-Reply-To: <4CA78EE3.9020005@quip.cz> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: is there a bug in AWK on 6.x and 7.x (fixed in 8.x)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 06:18:14 -0000 On 02/10/2010 21:58, Miroslav Lachman wrote: > I think there is a bug in AWK in base of FreeBSD 6.x and 7.x (tested on > 6.4 i386 and 7.3 i386) > > I have this simple test case, where I want 2 columns from GeoIP CSV file: > > awk 'FS="," { print $1"-"$2 }' GeoIPCountryWhois.csv You know that with this syntax FS="," is treated as a condition to run the following block in angle brackets? I.e. you assign FS for every line of input. What seems to have changed is when and how a variable assignment returns true or false in a boolean condition. Any way, I doubt it was your intention to conditionally execute the code, so this is a bug in your programming. The correct approach to do what you want to is the BEGIN block if you want to do it in the code. For your use of head, consider the following: > awk 'BEGIN {FS=","} NR <= 5 { print $1"-"$2 }' GeoIPCountryWhois.csv That way the code is executed under the condition that the line number is less or equal 5. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 06:29:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28538106564A for ; Sun, 3 Oct 2010 06:29:37 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id DA0E38FC15 for ; Sun, 3 Oct 2010 06:29:36 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id A08FD8A2866; Sun, 3 Oct 2010 08:29:35 +0200 (CEST) Message-ID: <4CA822CF.4060905@bsdforen.de> Date: Sun, 03 Oct 2010 08:29:35 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.12) Gecko/20100918 Thunderbird/3.0.8 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <4CA78EE3.9020005@quip.cz> <4CA82024.8010503@bsdforen.de> In-Reply-To: <4CA82024.8010503@bsdforen.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: is there a bug in AWK on 6.x and 7.x (fixed in 8.x)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 06:29:37 -0000 On 03/10/2010 08:18, Dominic Fandrey wrote: > On 02/10/2010 21:58, Miroslav Lachman wrote: >> I think there is a bug in AWK in base of FreeBSD 6.x and 7.x (tested on >> 6.4 i386 and 7.3 i386) >> >> I have this simple test case, where I want 2 columns from GeoIP CSV file: >> >> awk 'FS="," { print $1"-"$2 }' GeoIPCountryWhois.csv > > You know that with this syntax FS="," is treated as a condition to > run the following block in angle brackets? Sorry, I meant to say curly brackets. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 06:34:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06332106564A for ; Sun, 3 Oct 2010 06:34:16 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A95968FC13 for ; Sun, 3 Oct 2010 06:34:15 +0000 (UTC) Received: by qwd6 with SMTP id 6so2891639qwd.13 for ; Sat, 02 Oct 2010 23:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=SElVl++wsMaUdL3RGEf8R9N1tfsvWR3h/ic0w79H7j8=; b=cZe8Qsm3+2HI6J2vyzGQxMDjyBnBEZsp7CybrwlDHkCPy/IlXxryzIOoWHYxfk7B9e vhyDRLNttv+s4Jm4Odyq0BjXDUySKV36FQCmS+LCpysIXtf9MG0DKmi/fy5UCKBOjZgQ rUf1OQ23fQKMP51tgG0nWCZmO8NGBcSCv8ayY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MjX9vXZ3rR7giKnSsGGmG7bzyDOWqBZPDljp40c+BiVahL5sNK9dmQs7JKhgVYpe9v YJoA0r21QBwXTbwi+bQigBN5oRXdsWP/3dFEUOaDNTugsauYmcxAe0fLH9NNWbMxVqK0 fDmfJeU19+CHmcOUHwEnXNIbS/TRSQGfCXOwY= MIME-Version: 1.0 Received: by 10.220.26.205 with SMTP id f13mr2029030vcc.97.1286087654685; Sat, 02 Oct 2010 23:34:14 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.176.77 with HTTP; Sat, 2 Oct 2010 23:34:14 -0700 (PDT) In-Reply-To: References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> Date: Sat, 2 Oct 2010 23:34:14 -0700 X-Google-Sender-Auth: DkA-zFGoUbgeAlX54bXaKVZiD3g Message-ID: From: Artem Belevich To: Sean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable , Dan Langille Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 06:34:16 -0000 I've just tested on my box and loopback interface does not seem to be the bottleneck. I can easily push through ~400MB/s through two instances of mbuffer. --Artem On Fri, Oct 1, 2010 at 7:51 PM, Sean wrote: > > On 02/10/2010, at 11:43 AM, Artem Belevich wrote: > >>> As soon as I opened this email I knew what it would say. >>> >>> >>> # time zfs send storage/bacula@transfer | mbuffer | zfs receive >>> storage/compressed/bacula-mbuffer >>> in @ =A0197 MB/s, out @ =A0205 MB/s, 1749 MB total, buffer =A0 0% full >> .. >>> Big difference. =A0:) >> >> I'm glad it helped. >> >> Does anyone know why sending/receiving stuff via loopback is so much >> slower compared to pipe? > > > Up and down the entire network stack, in and out of TCP buffers at both e= nds... might add some overhead, and other factors in limiting it. > > Increasing TCP buffers, and disabling delayed acks might help. Nagle migh= t also have to be disabled too. (delayed acks and nagle in combination can = interact in odd ways) > > >> >> --Artem >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " > > From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 06:49:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE9C7106564A; Sun, 3 Oct 2010 06:49:36 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAEE8FC16; Sun, 3 Oct 2010 06:49:36 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-158-125.lns6.adl6.internode.on.net [121.45.158.125]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o936nRxA030220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 Oct 2010 17:19:33 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Sun, 3 Oct 2010 17:19:27 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB5FCB2-E11B-456A-B574-D10431A0C871@gsoft.com.au> References: <4C89DE32.9050402@icyb.net.ua> <4C8A24F5.7040100@freebsd.org> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable Stable , "John H. Baldwin" , Andriy Gapon Subject: Re: Enabling MCA causes system hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 06:49:37 -0000 On 14/09/2010, at 16:49, Daniel O'Connor wrote: >> So, you either have to disable one of them or upgrade to a more = recent version. >> The version you need is r206183. The latest stable/8 would do, = obviously. >=20 > I'll try updating to stable/8 - I've been meaning to anyway. >=20 > Just to find the spare time to do it :) I found some time, and now it seems to work fine. Thanks! :) I also wrapped = http://ftp2.pl.freebsd.org/pub/FreeBSD/HEAD/src/sbin/mca/mca.c in a = script and run it every hour. Is there a periodic in current for it? IMO it would be handy to do so. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 09:28:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50ADC1065670 for ; Sun, 3 Oct 2010 09:28:50 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 082728FC19 for ; Sun, 3 Oct 2010 09:28:49 +0000 (UTC) Received: from outgoing.leidinger.net (p5B32F3E7.dip.t-dialin.net [91.50.243.231]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6EB6B84400C; Sun, 3 Oct 2010 11:03:50 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id ED149154C; Sun, 3 Oct 2010 11:03:41 +0200 (CEST) Date: Sun, 3 Oct 2010 11:03:38 +0200 From: Alexander Leidinger To: Steve Polyack Message-ID: <20101003110338.00004197@unknown> In-Reply-To: <4CA7E98E.3040701@comcast.net> References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> <4CA7E98E.3040701@comcast.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 6EB6B84400C.A5EA3 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1286701432.47906@bbT/pceqEctrUtISf6UPog X-EBL-Spam-Status: No Cc: mav@FreeBSD.org, freebsd-stable , Dan Langille , Jeremy Chadwick Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 09:28:50 -0000 On Sat, 02 Oct 2010 22:25:18 -0400 Steve Polyack wrote: > I thin its worth it to think about TLER (or the absence of it) here - > http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery . Your > consumer / SATA Hitachi drives likely do not put a limit on the time > the drive may block on a command while handling inernal errors. If > we consider that gpt/gisk06-live encountered some kind of error and > had to relocate a significant number of blocks or perform some other > error recovery, then it very well may have timed out long enough for > siis(4) to drop the device. I have no idea what the timeouts are set > to in the siis(4) driver, nor does anything in your SMART report > stick out to me (though I'm certainly no expert with SMART data, and > my understanding is that many drive manufacturers report the various > parameters in different ways). IIRC mav@ (CCed) made a commit regarding this to -current in the not so distant past. I do not know about the MFC status of this, or if it may have helped or not in this situation. Bye, Alexander. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 12:08:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DEA61065670 for ; Sun, 3 Oct 2010 12:08:22 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id D09698FC18 for ; Sun, 3 Oct 2010 12:08:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 12C18508D8; Sun, 3 Oct 2010 13:08:21 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP9JWju2fwql; Sun, 3 Oct 2010 13:08:20 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id BF079508AD ; Sun, 3 Oct 2010 13:08:20 +0100 (BST) Message-ID: <4CA87233.2050308@langille.org> Date: Sun, 03 Oct 2010 08:08:19 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> In-Reply-To: <4CA7E4AE.4060607@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 12:08:22 -0000 On 10/2/2010 10:04 PM, Dan Langille wrote: > After a 'shutdown -p now', it was about 20 minutes before I went and > powered it up (I was on minecraft). The box came back with the missing HDD: > > $ zpool status storage > pool: storage > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > gpt/disk01-live ONLINE 0 0 0 > gpt/disk02-live ONLINE 0 0 0 > gpt/disk03-live ONLINE 0 0 0 > gpt/disk04-live ONLINE 0 0 0 > gpt/disk05-live ONLINE 0 0 0 > gpt/disk06-live ONLINE 0 0 12 > gpt/disk07-live ONLINE 0 0 0 Overnight, the following appeared in /var/log/messages: Oct 2 21:56:46 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=123103157760 size=1024 Oct 2 21:56:47 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=123103159808 size=1024 Oct 2 21:56:47 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=123103164416 size=512 Oct 2 21:56:47 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=123103162880 size=512 Oct 2 23:00:58 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1875352305152 size=1024 Oct 3 02:44:55 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1914424351744 size=512 Oct 3 03:01:01 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1875175041536 size=512 Oct 3 03:01:02 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1886724290048 size=1024 Oct 3 04:05:44 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1953680806912 size=512 Oct 3 04:05:44 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1953680807424 size=512 Oct 3 04:05:44 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1953680807936 size=512 Oct 3 04:05:44 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=1953680808448 size=512 Oct 3 04:59:38 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=98172631552 size=512 Oct 3 04:59:38 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=98172729856 size=512 Oct 3 04:59:38 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=98172730368 size=512 Oct 3 04:59:38 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=98172730880 size=512 Oct 3 04:59:38 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=98172731392 size=512 Given the outage from yesterday when ada0 was offline for several hours, I'm guessing that checksum mismatches on that drive are expected. Yes, /dev/gpt/disk06-live == ada0. The current zpool status is: $ zpool status pool: storage state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h1m with 0 errors on Sun Oct 3 00:01:17 2010 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk01-live ONLINE 0 0 0 gpt/disk02-live ONLINE 0 0 0 gpt/disk03-live ONLINE 0 0 0 gpt/disk04-live ONLINE 0 0 0 gpt/disk05-live ONLINE 0 0 0 gpt/disk06-live ONLINE 0 0 25 778M resilvered gpt/disk07-live ONLINE 0 0 0 errors: No known data errors -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 13:14:48 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 764CD106566B; Sun, 3 Oct 2010 13:14:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3038A8FC12; Sun, 3 Oct 2010 13:14:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o93DEl6J079834; Sun, 3 Oct 2010 09:14:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o93DElwa079833; Sun, 3 Oct 2010 13:14:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Oct 2010 13:14:47 GMT Message-Id: <201010031314.o93DElwa079833@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:14:48 -0000 TB --- 2010-10-03 12:36:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-03 12:36:18 - starting RELENG_8_1 tinderbox run for i386/pc98 TB --- 2010-10-03 12:36:18 - cleaning the object tree TB --- 2010-10-03 12:38:45 - cvsupping the source tree TB --- 2010-10-03 12:38:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/i386/pc98/supfile TB --- 2010-10-03 13:14:47 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-10-03 13:14:47 - ERROR: unable to cvsup the source tree TB --- 2010-10-03 13:14:47 - 1.47 user 111.86 system 2308.38 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 13:24:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48B8E1065673 for ; Sun, 3 Oct 2010 13:24:34 +0000 (UTC) (envelope-from Zdenek.Roubicek@t-systems.cz) Received: from mx1.t-systems.cz (mx1o.t-systems.cz [212.67.76.232]) by mx1.freebsd.org (Postfix) with ESMTP id C961D8FC17 for ; Sun, 3 Oct 2010 13:24:32 +0000 (UTC) X-AuditID: d4434ce6-b7be3ae000004333-85-4ca880889016 Received: from SRVPP07.t-systems.cz (Unknown_Domain [10.246.109.18]) by mx1.t-systems.cz (TSSMSGW) with SMTP id FA.11.17203.88088AC4; Sun, 3 Oct 2010 15:09:28 +0200 (CEST) To: undisclosed-recipients:; Received: from SRVPPE02.t-systems.cz ([10.246.109.16]) by SRVPP07.t-systems.cz ([10.246.109.18]) with mapi; Sun, 3 Oct 2010 15:09:35 +0200 From: =?iso-8859-2?Q?Roub=ED=E8ek_Zden=ECk?= CC: freebsd-stable Date: Sun, 3 Oct 2010 15:09:35 +0200 Thread-Topic: is there a bug in AWK on 6.x and 7.x (fixed in 8.x)? Thread-Index: ActixJ5Im9X2TRomTdymbMlrPa7WhAANp8a/ Message-ID: References: <4CA78EE3.9020005@quip.cz> <4CA82024.8010503@bsdforen.de>,<4CA822CF.4060905@bsdforen.de> In-Reply-To: <4CA822CF.4060905@bsdforen.de> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, cs-CZ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: RE: is there a bug in AWK on 6.x and 7.x (fixed in 8.x)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:24:34 -0000 Hello > On 02/10/2010 21:58, Miroslav Lachman wrote: >> I think there is a bug in AWK in base of FreeBSD 6.x and 7.x (tested on >> 6.4 i386 and 7.3 i386) >> >> I have this simple test case, where I want 2 columns from GeoIP CSV file= : >> >> awk 'FS=3D"," { print $1"-"$2 }' GeoIPCountryWhois.csv > > You know that with this syntax FS=3D"," is treated as a condition to > run the following block in angle brackets? I met the very same problem some time ago, not a bug, feature. http://www.mail-archive.com/freebsd-questions@freebsd.org/msg55958.html Still, one interesting question remains, why 8.x behaves in a different way= then the previous versions. rouba= From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 13:51:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286FA106566C for ; Sun, 3 Oct 2010 13:51:27 +0000 (UTC) (envelope-from steven43126@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A5D248FC14 for ; Sun, 3 Oct 2010 13:51:26 +0000 (UTC) Received: by wwb17 with SMTP id 17so5719082wwb.31 for ; Sun, 03 Oct 2010 06:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XgpAHwDcGP/n65ikBxZsVO/im2jMq+zwS4tqO4XHSg0=; b=jAHFcGKnAHtgk++iH/l+ZMHOdrKSa0WGnvArz90EiYlsVAPCkgkplM8U6SQ0TTf68R yIcKwDtx37knNiaiXlxqzSqg98TBNUd+hvAPzowjcunnJVWHYnGhpXHzl0+eIsNqedzo QF22TmWwa675zmi0eFmgBb8W8XE3pQZu9vByw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PTS+HxoiKBacGTWJPwkeNlsJwrtbfu5/PdVog9FIHt8LdEUnNcFbPh7X17l3U0HGxi bfh5PFfBTb48b0EAyrMv2RYfhN4+koN0W2DhkLLFj1XPkc24CXtkBOGD8q4KIJ1BIZ+e hDrHPTfd2EqWsQFtBLgv2K1zQAt/WaLxZ4kgA= MIME-Version: 1.0 Received: by 10.227.147.144 with SMTP id l16mr7045006wbv.45.1286112466713; Sun, 03 Oct 2010 06:27:46 -0700 (PDT) Received: by 10.227.139.143 with HTTP; Sun, 3 Oct 2010 06:27:46 -0700 (PDT) In-Reply-To: <20101002223005.GA78136@icarus.home.lan> References: <20101002223005.GA78136@icarus.home.lan> Date: Sun, 3 Oct 2010 14:27:46 +0100 Message-ID: From: Steven Williamson To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Rumen Telbizov , Steven Hartland , freebsd-stable@freebsd.org Subject: Re: MySQL performance concern X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:51:27 -0000 The tunings between your Linux and FreeBSD instances differ severely, > and some of the variables don't even exist any longer (example: > table_cache is now known as table_open_cache as of MySQL 5.1.3, and > probably key_buffer vs. key_buffer_size too). > > Can you please rule out MySQL tunings being responsible for the problem? > > Quick and dirty performance comparison ruling out MySQL tuning, install sysbench. This will give you a quick overview of how the OS / Hardware is performing. For a decent comparison there are too many variables here, the hardware is vastly different. Would be nice to see the same Linux install on the new hardware and the benchmarks for that if you have time. P.S Performance tuning can be a very time consuming business, an almost unending task. Best method is not to see if system x is faster than system y. But to state exactly what performance you require. If you only need 600 inserts per min for now and the next year, tune to that and your good to go. Otherwise you can end up spending days to get that extra 2 or 3 inserts per min which you really didn't need :) Regards Steven Williamson From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 13:51:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E291065758; Sun, 3 Oct 2010 13:51:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 806C28FC0C; Sun, 3 Oct 2010 13:51:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o93DpWXF027114; Sun, 3 Oct 2010 09:51:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o93DpWh1027101; Sun, 3 Oct 2010 13:51:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Oct 2010 13:51:32 GMT Message-Id: <201010031351.o93DpWh1027101@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:51:33 -0000 TB --- 2010-10-03 13:14:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-03 13:14:47 - starting RELENG_8_1 tinderbox run for ia64/ia64 TB --- 2010-10-03 13:14:47 - cleaning the object tree TB --- 2010-10-03 13:17:13 - cvsupping the source tree TB --- 2010-10-03 13:17:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/ia64/ia64/supfile TB --- 2010-10-03 13:51:32 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-10-03 13:51:32 - ERROR: unable to cvsup the source tree TB --- 2010-10-03 13:51:32 - 1.15 user 107.95 system 2205.41 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 13:57:15 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18156106564A; Sun, 3 Oct 2010 13:57:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD51C8FC17; Sun, 3 Oct 2010 13:57:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o93DvDoY034649; Sun, 3 Oct 2010 09:57:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o93DvDM2034646; Sun, 3 Oct 2010 13:57:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Oct 2010 13:57:13 GMT Message-Id: <201010031357.o93DvDM2034646@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 13:57:15 -0000 TB --- 2010-10-03 13:19:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-03 13:19:08 - starting RELENG_8_1 tinderbox run for mips/mips TB --- 2010-10-03 13:19:08 - cleaning the object tree TB --- 2010-10-03 13:20:13 - cvsupping the source tree TB --- 2010-10-03 13:20:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/mips/mips/supfile TB --- 2010-10-03 13:57:13 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-10-03 13:57:13 - ERROR: unable to cvsup the source tree TB --- 2010-10-03 13:57:13 - 0.68 user 55.59 system 2285.52 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 14:31:35 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 324CC106566C; Sun, 3 Oct 2010 14:31:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E03718FC0A; Sun, 3 Oct 2010 14:31:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o93EVXeU073875; Sun, 3 Oct 2010 10:31:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o93EVXPi073874; Sun, 3 Oct 2010 14:31:33 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 3 Oct 2010 14:31:33 GMT Message-Id: <201010031431.o93EVXPi073874@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8_1 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 14:31:35 -0000 TB --- 2010-10-03 13:51:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-03 13:51:32 - starting RELENG_8_1 tinderbox run for powerpc/powerpc TB --- 2010-10-03 13:51:32 - cleaning the object tree TB --- 2010-10-03 13:53:13 - cvsupping the source tree TB --- 2010-10-03 13:53:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8_1/powerpc/powerpc/supfile TB --- 2010-10-03 14:31:33 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-10-03 14:31:33 - ERROR: unable to cvsup the source tree TB --- 2010-10-03 14:31:33 - 1.02 user 85.30 system 2400.90 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_1-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 18:20:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49BA6106566B for ; Sun, 3 Oct 2010 18:20:08 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C64A88FC1E for ; Sun, 3 Oct 2010 18:20:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P2TAK-0008AX-Fm for freebsd-stable@freebsd.org; Sun, 03 Oct 2010 20:20:04 +0200 Received: from 93-141-115-47.adsl.net.t-com.hr ([93.141.115.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Oct 2010 20:20:04 +0200 Received: from ivoras by 93-141-115-47.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Oct 2010 20:20:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sun, 03 Oct 2010 20:19:52 +0200 Lines: 87 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-115-47.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100620 Thunderbird/3.0.4 In-Reply-To: Subject: Re: MySQL performance concern X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 18:20:08 -0000 On 10/02/10 22:18, Rumen Telbizov wrote: > pool: tank > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > mirror ONLINE 0 0 0 > gpt/tank0 ONLINE 0 0 0 > gpt/tank1 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > gpt/tank2 ONLINE 0 0 0 > gpt/tank3 ONLINE 0 0 0 > logs ONLINE 0 0 0 > mirror ONLINE 0 0 0 > gpt/zil0 ONLINE 0 0 0 > gpt/zil1 ONLINE 0 0 0 > cache > gpt/l2arc0 ONLINE 0 0 0 > gpt/l2arc1 ONLINE 0 0 0 > > pool: zroot > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror ONLINE 0 0 0 > gpt/zroot0 ONLINE 0 0 0 > gpt/zroot1 ONLINE 0 0 0 > > zroot is a couple of small partitions from two of the same SAS disks. zil > and l2arc are 8 and 22G partitions from 32G SSDs This looks a bit overly complex (your recovery procedure if some of the drives goes bad will include re-creating the partition layout), but it probably shouldn't affect performance. Just to check - mapped to physical drives this looks like this: ("gpt/" prefix omitted for brevity): * tank0..tank3 : on SAS drives * zroot0, zroot1 : on some of the same SAS drives as above * zil0, zil1 : on SSD drives * l2arc0, l2arc1 : on the same SSD drives as above ARC and ZIL have some very different IO characteristics, I don't know if they would interfere with each other. Can you spend some time looking at the output of "gstat" while the database task is running and see if there's something odd? Like "%busy" column going near 100% for some of them? What IO bandwidth and ops/s are you getting? > I pretty much have no zfs tuning done since from what I've found there > shouldn't be any needed since I'm running 8.1 on a 64bit machine. > Let me know if you'd like me to experiment with any ... > > Some additional information: > # sysctl vm.kmem_size > vm.kmem_size: 5539958784 > # sysctl vm.kmem_size_max > vm.kmem_size_max: 329853485875 > # sysctl vfs.zfs.arc_max > vfs.zfs.arc_max: 4466216960 I have done some digging myself and it seems that two settings have noticable impact on MySQL load: * zfs block size - you need to re-create all mysql files to change this; set to 8 KiB (or whatever MyISAM uses for block size) * reducing vfs.zfs.txg.timeout to about 5 seconds Are you using ZFS compression? See http://jp.planet.mysql.com/entry/?id=19489 for more ideas. Other than that, your CPUs are: New: 2 x Dual Core Xeon E5502 1.87Ghz Old: 2 x Xeon Quad E5410 @ 2.33GHz You can see here how different they are: http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors Specifically, as you are using a single-threaded client, you *need* the additional GHz of the old server. You are quoting 30% CPU usage on the new server - I assume this is the "total" CPU as reported by utilities like "top", "iostat", "vmstat", etc - meaning that if the system has four CPU cores, one of then is 100% busy (meaning 25% of the total) and another is about 20% used. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 18:36:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD9CB106564A for ; Sun, 3 Oct 2010 18:36:16 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 678FC8FC17 for ; Sun, 3 Oct 2010 18:36:16 +0000 (UTC) Received: by iwn10 with SMTP id 10so1328447iwn.13 for ; Sun, 03 Oct 2010 11:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=NifQFghR9PnGPPeHKxbb09eX+VlqpzBXHVkW7NCWhyk=; b=dVLKz07SpXr1yhYYqIemVT/jJvexL/OKlT8QNLjuG85PVlYGd6TnsfB8r36HE44H3i jXKygVelDAXveGjpxI5ArYeYyrFkIzTPE46D7nmnbwRsZAGy/ZqEZXnf4QiOBzbpRuy+ S9Ixn4FSBR7EFHQ1qMRooq29oKcMm80aFiYnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=qKj9lck/pDPhn2YtU1Q+EdvhYPPylXiTQ8XU0WMQCFbHrWClkgHxeUcnutWPjXWanF /4rR+BRBielWrE5mmXI0/Lsv59HJvxUTf2zZRXwa5s0fR4+QoOdk24GljoLBrlyX0bnp StuSjJUFw76OP2Zv4tRNGa3Std3dMW+p8YkII= MIME-Version: 1.0 Received: by 10.42.5.140 with SMTP id 12mr10139005icw.28.1286129568143; Sun, 03 Oct 2010 11:12:48 -0700 (PDT) Received: by 10.42.170.136 with HTTP; Sun, 3 Oct 2010 11:12:48 -0700 (PDT) In-Reply-To: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> Date: Sun, 3 Oct 2010 13:12:48 -0500 Message-ID: From: Alan Cox To: Dave Hayes Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 18:36:16 -0000 On Sat, Oct 2, 2010 at 9:11 PM, Dave Hayes wrote: > What does the above mentioned panic mean? I'm booting from > an mfsroot off of a DVD with a loader.conf like this: > > autoboot_delay="5" > mfsroot_load="YES" > mfsroot_type="mfs_root" > mfsroot_name="/mfsboot" > vfs.root.mountfrom="ufs:md0" > vfs.root.mountfrom.options="rw" > kern.ipc.nmbclusters=32768 > net.inet.tcp.tcbhashsize=16384 > vm.pmap.pg_ps_enabled=1 > vm.kmem_size="2G" > accf_http_load="YES" > net.inet.tcp.syncache.hashsize=1024 > net.inet.tcp.syncache.bucketlimit=100 > > This is FreeBSD 8.1-RELEASE amd64 running with the debugger installed > into the kernel. Thanks in advance for any insight provided. :) > I'm afraid that I can't offer much insight without a stack trace. At initialization time, we map the kernel with 2MB pages. I suspect that something within the kernel is later trying to change one those mappings. If I had to guess, it's related to the mfs root. Regards, Alan From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 20:42:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D911065673 for ; Sun, 3 Oct 2010 20:42:22 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa04a.plala.or.jp (msa04.plala.or.jp [58.93.240.4]) by mx1.freebsd.org (Postfix) with ESMTP id D6C4C8FC1B for ; Sun, 3 Oct 2010 20:42:21 +0000 (UTC) Received: from i125-202-0-194.s02.a026.ap.plala.or.jp ([125.202.0.194]) by msa03b.plala.or.jp with ESMTP id <20101003203151.IITG19691.msa03b.plala.or.jp@i125-202-0-194.s02.a026.ap.plala.or.jp> for ; Mon, 4 Oct 2010 05:31:51 +0900 Date: Mon, 04 Oct 2010 05:31:50 +0900 Message-ID: <8662xjdnm1.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: freebsd-stable In-Reply-To: References: <4CA78EE3.9020005@quip.cz> <4CA82024.8010503@bsdforen.de> Mail-Followup-To: =?ISO-2022-JP-2?B?Um91YhskKEQrPystGyhCZWsgWmRlbg==?= =?ISO-2022-JP-2?B?GyQoRCs1GyhCaw==?= , freebsd-stable User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-VirusScan: Outbound; msa03b; Mon, 4 Oct 2010 05:31:51 +0900 Subject: Re: is there a bug in AWK on 6.x and 7.x (fixed in 8.x)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 20:42:22 -0000 At Sun, 3 Oct 2010 15:09:35 +0200, Roub$(D+?+-(Bek Zden$(D+5(Bk wrote: > >> awk 'FS="," { print $1"-"$2 }' GeoIPCountryWhois.csv This code is equivalent to awk '(FS=","){} { print $1"-"$2 }' GeoIPCountryWhois.csv so I think it is OK not to separate the first line with ",". However, from the latest one-true-awk/FIXES source we have in src/contrib, | Nov 26, 2009: | fixed a long-standing issue with when FS takes effect. a | change to FS is now noticed immediately for subsequent splits. AWK seems intentionally changed this behaviour. When FS has been changed, working line is immediately re-parsed with new FS. This explains why 8.x awk print *intended* $1"-"$2 though older and GNU ones do not. > I met the very same problem some time ago, not a bug, feature. > > http://www.mail-archive.com/freebsd-questions@freebsd.org/msg55958.html > > Still, one interesting question remains, why 8.x behaves in a different way then the previous versions. Now both are their own feature. Conclusion: avoid ambiguous code as far as it could. -- kuro From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 22:44:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F8021065672 for ; Sun, 3 Oct 2010 22:44:11 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C62028FC16 for ; Sun, 3 Oct 2010 22:44:10 +0000 (UTC) Received: by qyk35 with SMTP id 35so238110qyk.13 for ; Sun, 03 Oct 2010 15:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=nxhb6EzkE76FxXT/IK5NB6uY7eTlL8XgwS8XePyxg/g=; b=gJtXL1XnuAieBSoQ85AJiz/AiLL1zs48gY+lbc3DcMowo6ubueb7FM9spL7u+wo+nG KzBGwoNztQIGQNOn1B46evrMq5M7M46iW7+agYpHflKsQ7DzEVijjQe2trVcEjt/OpH8 p/tNCkdyC8FcfQ3vIuImU6UFGvClMFuY6XquA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=drRkuCN12UPHOrHdCdEFFGqkRNaVdsQhNKU4GyMXbPwWJtbjU2kBPKd0kmjJ6UrVKE Hc/N+mDdn7WFwFeeEIeyxBPFSOiLK4zfcPDuYQHF5qAhOvP00PPMhr1uEEmB3vI2upd0 UHohEwSAcxYHvtSRxDdIEtBiBXBFUB+l2Tbys= MIME-Version: 1.0 Received: by 10.229.1.129 with SMTP id 1mr6212889qcf.163.1286145848840; Sun, 03 Oct 2010 15:44:08 -0700 (PDT) Received: by 10.229.191.132 with HTTP; Sun, 3 Oct 2010 15:44:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Oct 2010 15:44:08 -0700 Message-ID: From: Rumen Telbizov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: MySQL performance concern X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 22:44:11 -0000 Thank you everyone for your comments! On Sun, Oct 3, 2010 at 11:19 AM, Ivan Voras wrote: > On 10/02/10 22:18, Rumen Telbizov wrote: > > pool: tank > > config: > > > > NAME STATE READ WRITE CKSUM > > tank ONLINE 0 0 0 > > mirror ONLINE 0 0 0 > > gpt/tank0 ONLINE 0 0 0 > > gpt/tank1 ONLINE 0 0 0 > > mirror ONLINE 0 0 0 > > gpt/tank2 ONLINE 0 0 0 > > gpt/tank3 ONLINE 0 0 0 > > logs ONLINE 0 0 0 > > mirror ONLINE 0 0 0 > > gpt/zil0 ONLINE 0 0 0 > > gpt/zil1 ONLINE 0 0 0 > > cache > > gpt/l2arc0 ONLINE 0 0 0 > > gpt/l2arc1 ONLINE 0 0 0 > > > > pool: zroot > > config: > > > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > mirror ONLINE 0 0 0 > > gpt/zroot0 ONLINE 0 0 0 > > gpt/zroot1 ONLINE 0 0 0 > > > > zroot is a couple of small partitions from two of the same SAS disks. zil > > and l2arc are 8 and 22G partitions from 32G SSDs > > This looks a bit overly complex (your recovery procedure if some of the > drives goes bad will include re-creating the partition layout), but it > probably shouldn't affect performance. Just to check - mapped to > physical drives this looks like this: ("gpt/" prefix omitted for brevity): > > * tank0..tank3 : on SAS drives > * zroot0, zroot1 : on some of the same SAS drives as above > * zil0, zil1 : on SSD drives > * l2arc0, l2arc1 : on the same SSD drives as above > > ARC and ZIL have some very different IO characteristics, I don't know if > they would interfere with each other. > > Can you spend some time looking at the output of "gstat" while the > database task is running and see if there's something odd? Like "%busy" > column going near 100% for some of them? What IO bandwidth and ops/s are > you getting? > > > I pretty much have no zfs tuning done since from what I've found there > > shouldn't be any needed since I'm running 8.1 on a 64bit machine. > > Let me know if you'd like me to experiment with any ... > > > > Some additional information: > > # sysctl vm.kmem_size > > vm.kmem_size: 5539958784 > > # sysctl vm.kmem_size_max > > vm.kmem_size_max: 329853485875 > > # sysctl vfs.zfs.arc_max > > vfs.zfs.arc_max: 4466216960 > > I have done some digging myself and it seems that two settings have > noticable impact on MySQL load: > > * zfs block size - you need to re-create all mysql files to change this; > set to 8 KiB (or whatever MyISAM uses for block size) > * reducing vfs.zfs.txg.timeout to about 5 seconds > > Are you using ZFS compression? > > See http://jp.planet.mysql.com/entry/?id=19489 for more ideas. > > Other than that, your CPUs are: > > New: 2 x Dual Core Xeon E5502 1.87Ghz > Old: 2 x Xeon Quad E5410 @ 2.33GHz > > You can see here how different they are: > http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors > > Specifically, as you are using a single-threaded client, you *need* the > additional GHz of the old server. You are quoting 30% CPU usage on the > new server - I assume this is the "total" CPU as reported by utilities > like "top", "iostat", "vmstat", etc - meaning that if the system has > four CPU cores, one of then is 100% busy (meaning 25% of the total) and > another is about 20% used. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Rumen Telbizov http://telbizov.com From owner-freebsd-stable@FreeBSD.ORG Sun Oct 3 22:58:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DA401065700 for ; Sun, 3 Oct 2010 22:58:28 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF18A8FC1C for ; Sun, 3 Oct 2010 22:58:27 +0000 (UTC) Received: by fxm9 with SMTP id 9so3805521fxm.13 for ; Sun, 03 Oct 2010 15:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YHhreNT3OO3nlPrs12bxnqLTgZvYjvuVmXkcTe2E5hw=; b=O2PEKEmd52WaQSIG9rJWrZVrcH22sB+Ddn+/nXBb903GOr3FOujUjvv8CoJLkTc5ci Dz6W34RdRr5eKfrU2J4NvBLMZjnihiYOd3PgWbYxtFb4iMvYIIyRy8NT6jIWnS3XZn8A 4x5a4OyiHzqSvYAmvg7oq2TSsOOp3ePAMXjIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=a65l2FNzxyHmVX2K6p5nlDMPCo98iW5D2a7yFoCWJ47fUYtTw7CYDIVUFG+awjUPLk Zh5I//ZKobfksBTExHBpXmCZ7lCC+rn66Jss4FAaWIjoMc4vmBmzjKNstgeEUafcT74o WiR7lB/f6/MPToySWFZ70M2uG9jffIKfLggas= MIME-Version: 1.0 Received: by 10.223.105.9 with SMTP id r9mr1985399fao.63.1286146706700; Sun, 03 Oct 2010 15:58:26 -0700 (PDT) Received: by 10.223.107.130 with HTTP; Sun, 3 Oct 2010 15:58:26 -0700 (PDT) In-Reply-To: References: <201009300940.43136.jhb@freebsd.org> <201009301325.15113.jhb@freebsd.org> Date: Sun, 3 Oct 2010 17:58:26 -0500 Message-ID: From: Adam Vande More To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: MCA messages in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 22:58:28 -0000 On Thu, Sep 30, 2010 at 1:45 PM, Adam Vande More wrote: > Thanks for looking into it, I'm going to play around with BIOS voltages to > see if I can achieve some stability since I don't have much to lose trying > that first. The system may work fine for a week or more, then have a really > bad day. I've made some raises to the cpu voltage and we'll see how that > goes. > Well neither voltage increases or swapping DIMM's helped the cause. Looks like it's time for new motherboard/cpu. Unfortunately, I have plenty of good DDR2 laying around, but it doesn't seem very viable since DDR2 boards/cpu are more money than DDR3 now. If anyone is looking for some DDR2 1GB sticks for a reasonable price, let me know off list. I have 6 of them and they are nice RAM, OCZ and GSKILL. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 01:11:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54849106566B for ; Mon, 4 Oct 2010 01:11:06 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 259B28FC13 for ; Mon, 4 Oct 2010 01:11:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 8B6DC509A5; Mon, 4 Oct 2010 02:11:05 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXJriZe1AooM; Mon, 4 Oct 2010 02:11:05 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 45171509A3 ; Mon, 4 Oct 2010 02:11:05 +0100 (BST) Message-ID: <4CA929A8.6000708@langille.org> Date: Sun, 03 Oct 2010 21:11:04 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Artem Belevich , freebsd-stable References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> In-Reply-To: <4CA68BBD.6060601@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 01:11:06 -0000 On 10/1/2010 9:32 PM, Dan Langille wrote: > On 10/1/2010 7:00 PM, Artem Belevich wrote: >> On Fri, Oct 1, 2010 at 3:49 PM, Dan Langille wrote: >>> FYI: this is all on the same box. >> >> In one of the previous emails you've used this command line: >>> # mbuffer -s 128k -m 1G -I 9090 | zfs receive >> >> You've used mbuffer in network client mode. I assumed that you did do >> your transfer over network. >> >> If you're running send/receive locally just pipe the data through >> mbuffer -- zfs send|mbuffer|zfs receive > > As soon as I opened this email I knew what it would say. > > > # time zfs send storage/bacula@transfer | mbuffer | zfs receive > storage/compressed/bacula-mbuffer > in @ 197 MB/s, out @ 205 MB/s, 1749 MB total, buffer 0% full > > > $ zpool iostat 10 10 > capacity operations bandwidth > pool used avail read write read write > ---------- ----- ----- ----- ----- ----- ----- > storage 9.78T 2.91T 1.11K 336 92.0M 17.3M > storage 9.78T 2.91T 769 436 95.5M 30.5M > storage 9.78T 2.91T 797 853 98.9M 78.5M > storage 9.78T 2.91T 865 962 107M 78.0M > storage 9.78T 2.91T 828 881 103M 82.6M > storage 9.78T 2.90T 1023 1.12K 127M 91.0M > storage 9.78T 2.90T 1.01K 1.01K 128M 89.3M > storage 9.79T 2.90T 962 1.08K 119M 89.1M > storage 9.79T 2.90T 1.09K 1.25K 139M 67.8M > > > Big difference. :) I'm rerunning my test after I had a drive go offline[1]. But I'm not getting anything like the previous test: time zfs send storage/bacula@transfer | mbuffer | zfs receive storage/compressed/bacula-buffer $ zpool iostat 10 10 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- storage 6.83T 5.86T 8 31 1.00M 2.11M storage 6.83T 5.86T 207 481 25.7M 17.8M storage 6.83T 5.86T 220 516 27.4M 17.2M storage 6.83T 5.86T 221 523 27.5M 21.0M storage 6.83T 5.86T 198 430 24.5M 20.4M storage 6.83T 5.86T 248 528 30.8M 26.7M storage 6.83T 5.86T 273 508 33.9M 22.6M storage 6.83T 5.86T 331 499 41.1M 22.7M storage 6.83T 5.86T 424 662 52.6M 34.7M storage 6.83T 5.86T 413 605 51.3M 36.7M [1] - http://docs.freebsd.org/cgi/mid.cgi?4CA73702.5080203 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 02:06:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE90106566C for ; Mon, 4 Oct 2010 02:06:21 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F3C68FC14 for ; Mon, 4 Oct 2010 02:06:20 +0000 (UTC) Received: by qwd6 with SMTP id 6so3390217qwd.13 for ; Sun, 03 Oct 2010 19:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JUumkBnMyRUv2GiNO62HWu+KH5js2PmzNWgbKUiq6IY=; b=wgqIvdyu2CRMmzCpJSOOr91T1kQZXmsl9ONCCx2PX06/oq8CFUYJC/HxbknlLijwHE IzlY1kY1r1Nuv00UdXATNdoOqxSSCejsfRv76t1hD04AzZDkyxBxi/fEs97BvoSTmnc9 sAP0mkVLDfOVlVc1mqWIFTzCu4GMQWvl6eZHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uLxA6MRtHBT+PyBqTyNN1FtI5jtwOuf/ZAMZf6ICQcbzamXYv7edWzMRdhGgAs/tPg Vbjmpt2oV+axXZPMlVaJWLwMshosrHzgfFoBB2A2Uc0mO9yjLmYuLgnnFdKK6zax/UCB qduOD3tiaJogNGURhe1v2DEr+HtvBoY3NnDhI= MIME-Version: 1.0 Received: by 10.220.63.5 with SMTP id z5mr2256722vch.245.1286157980258; Sun, 03 Oct 2010 19:06:20 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.176.77 with HTTP; Sun, 3 Oct 2010 19:06:20 -0700 (PDT) In-Reply-To: <4CA929A8.6000708@langille.org> References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org> Date: Sun, 3 Oct 2010 19:06:20 -0700 X-Google-Sender-Auth: nI87NwFUIWOQtNXWo4pPd8KuMdY Message-ID: From: Artem Belevich To: Dan Langille Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 02:06:21 -0000 On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille wrote: > I'm rerunning my test after I had a drive go offline[1]. =A0But I'm not > getting anything like the previous test: > > time zfs send storage/bacula@transfer | mbuffer | zfs receive > storage/compressed/bacula-buffer > > $ zpool iostat 10 10 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 capacity =A0 =A0 operations =A0 =A0bandwidth > pool =A0 =A0 =A0 =A0 used =A0avail =A0 read =A0write =A0 read =A0write > ---------- =A0----- =A0----- =A0----- =A0----- =A0----- =A0----- > storage =A0 =A0 6.83T =A05.86T =A0 =A0 =A08 =A0 =A0 31 =A01.00M =A02.11M > storage =A0 =A0 6.83T =A05.86T =A0 =A0207 =A0 =A0481 =A025.7M =A017.8M It may be worth checking individual disk activity using gstat -f 'da.$' Some time back I had one drive that was noticeably slower than the rest of the drives in RAID-Z2 vdev and was holding everything back. SMART looked OK, there were no obvious errors and yet performance was much worse than what I'd expect. gstat clearly showed that one drive was almost constantly busy with much lower number of reads and writes per second than its peers. Perhaps previously fast transfer rates were due to caching effects. I.e. if all metadata already made it into ARC, subsequent "zfs send" commands would avoid a lot of random seeks and would show much better throughput. --Artem From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 03:53:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32673106566B; Mon, 4 Oct 2010 03:53:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DCA948FC14; Mon, 4 Oct 2010 03:53:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o943r5TM033042; Sun, 3 Oct 2010 23:53:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o943r5TW033041; Mon, 4 Oct 2010 03:53:05 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Oct 2010 03:53:05 GMT Message-Id: <201010040353.o943r5TW033041@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 03:53:07 -0000 TB --- 2010-10-04 00:09:03 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-04 00:09:03 - starting RELENG_8 tinderbox run for mips/mips TB --- 2010-10-04 00:09:03 - cleaning the object tree TB --- 2010-10-04 00:10:27 - cvsupping the source tree TB --- 2010-10-04 00:10:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2010-10-04 00:14:52 - building world TB --- 2010-10-04 00:14:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-04 00:14:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-04 00:14:52 - TARGET=mips TB --- 2010-10-04 00:14:52 - TARGET_ARCH=mips TB --- 2010-10-04 00:14:52 - TZ=UTC TB --- 2010-10-04 00:14:52 - __MAKE_CONF=/dev/null TB --- 2010-10-04 00:14:52 - cd /src TB --- 2010-10-04 00:14:52 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 4 00:14:53 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1899 /obj/mips/src/tmp/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail /src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elfxx-mips.c:1902 *** Error code 1 Stop in /src/usr.bin/tftp. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-04 03:53:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-04 03:53:05 - ERROR: failed to build world TB --- 2010-10-04 03:53:05 - 2070.40 user 7444.00 system 13442.27 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 05:12:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 477F5106564A for ; Mon, 4 Oct 2010 05:12:30 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id 29E848FC18 for ; Mon, 4 Oct 2010 05:12:29 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o945CTor092854; Sun, 3 Oct 2010 22:12:29 -0700 (PDT) Message-Id: <201010040512.o945CTor092854@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: alc@freebsd.org In-reply-to: References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Oct 2010 22:12:29 -0700 From: Dave Hayes Cc: freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 05:12:30 -0000 Alan Cox writes: > I'm afraid that I can't offer much insight without a stack trace. At > initialization time, we map the kernel with 2MB pages. I suspect that > something within the kernel is later trying to change one those mappings. > If I had to guess, it's related to the mfs root. Here is the stack trace. The machine is sitting here in KDB if you need me to extract any information from it. I db> bt Tracing pid 0 tid 0 td 0xffffffff80c67140 kdb_enter() at kdbenter+0x3d panic() at panic+0x17b pmap_enter() at pmap_enter+0x641 kmem_malloc() at kmem_malloc+0x1b5 uma_large_malloc() at uma_large_malloc+0x4a malloc() at malloc+0xd7 acpi_alloc_wakeup_handler() at acpi_alloc_wakeup_handler+0x82 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Only one who is seeking certainty can be uncertain. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 07:27:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF121106564A for ; Mon, 4 Oct 2010 07:27:58 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:100:1043::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3C88FC0A for ; Mon, 4 Oct 2010 07:27:58 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id 6DED612630E; Mon, 4 Oct 2010 09:27:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id J9AUw0oX4rwC; Mon, 4 Oct 2010 09:27:55 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 4A530126306; Mon, 4 Oct 2010 09:27:55 +0200 (CEST) Message-ID: <4CA981FC.80405@FreeBSD.org> Date: Mon, 04 Oct 2010 09:27:56 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Artem Belevich References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable , Dan Langille Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 07:27:58 -0000 Try using zfs receive with the -v flag (gives you some stats at the end): # zfs send storage/bacula@transfer | zfs receive -v storage/compressed/bacula And use the following sysctl (you may set that in /boot/loader.conf, too): # sysctl vfs.zfs.txg.write_limit_override=805306368 I have good results with the 768MB writelimit on systems with at least 8GB RAM. With 4GB ram, you might want to try to set the TXG write limit to a lower threshold (e.g. 256MB): # sysctl vfs.zfs.txg.write_limit_override=268435456 You can experiment with that setting to get the best results on your system. A value of 0 means using calculated default (which is very high). During the operation you can observe what your disks actually do: a) via ZFS pool I/O statistics: # zpool iostat -v 1 b) via GEOM: # gstat -a mm Dňa 4. 10. 2010 4:06, Artem Belevich wrote / napísal(a): > On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille wrote: >> I'm rerunning my test after I had a drive go offline[1]. But I'm not >> getting anything like the previous test: >> >> time zfs send storage/bacula@transfer | mbuffer | zfs receive >> storage/compressed/bacula-buffer >> >> $ zpool iostat 10 10 >> capacity operations bandwidth >> pool used avail read write read write >> ---------- ----- ----- ----- ----- ----- ----- >> storage 6.83T 5.86T 8 31 1.00M 2.11M >> storage 6.83T 5.86T 207 481 25.7M 17.8M > > It may be worth checking individual disk activity using gstat -f 'da.$' > > Some time back I had one drive that was noticeably slower than the > rest of the drives in RAID-Z2 vdev and was holding everything back. > SMART looked OK, there were no obvious errors and yet performance was > much worse than what I'd expect. gstat clearly showed that one drive > was almost constantly busy with much lower number of reads and writes > per second than its peers. > > Perhaps previously fast transfer rates were due to caching effects. > I.e. if all metadata already made it into ARC, subsequent "zfs send" > commands would avoid a lot of random seeks and would show much better > throughput. > > --Artem > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 08:37:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE2C2106566B for ; Mon, 4 Oct 2010 08:37:41 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id A45718FC14 for ; Mon, 4 Oct 2010 08:37:41 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1P2gYG-0003R5-94 for freebsd-stable@freebsd.org; Mon, 04 Oct 2010 09:37:40 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2gYG-000Khe-8P for freebsd-stable@freebsd.org; Mon, 04 Oct 2010 09:37:40 +0100 Date: Mon, 04 Oct 2010 09:37:40 +0100 Message-Id: To: freebsd-stable@freebsd.org From: Pete French Subject: Has anyone usd hast in production yet - opinions ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 08:37:41 -0000 I've been testing out hast intrenally here, and as a replacement for the gmirror+ggate stack which we are currently using it seems excellent. I am actually about to take the plunge and deploy this in production for our main database server as it seems to operate fine in testing, but before I do has anyone else done this and are there any interesting things I need to know ? cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 08:44:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9812D106564A for ; Mon, 4 Oct 2010 08:44:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBF48FC1A for ; Mon, 4 Oct 2010 08:44:00 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta08.emeryville.ca.mail.comcast.net with comcast id EYjW1f0021Y3wxoA8Yk0V6; Mon, 04 Oct 2010 08:44:00 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id EYjz1f0093LrwQ28bYjzcQ; Mon, 04 Oct 2010 08:44:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6D6F39B427; Mon, 4 Oct 2010 01:43:59 -0700 (PDT) Date: Mon, 4 Oct 2010 01:43:59 -0700 From: Jeremy Chadwick To: Pete French Message-ID: <20101004084359.GA2038@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Has anyone usd hast in production yet - opinions ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 08:44:01 -0000 On Mon, Oct 04, 2010 at 09:37:40AM +0100, Pete French wrote: > I've been testing out hast intrenally here, and as a replacement for the > gmirror+ggate stack which we are currently using it seems excellent. I am > actually about to take the plunge and deploy this in production for our > main database server as it seems to operate fine in testing, but before I > do has anyone else done this and are there any interesting things I need > to know ? Please see the freebsd-fs mailing list, which has quite a large number of problem reports/issues being posted to it on a regular basis (and patches are often provided). http://lists.freebsd.org/pipermail/freebsd-fs/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 11:19:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111CF1065673 for ; Mon, 4 Oct 2010 11:19:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B53CC8FC1B for ; Mon, 4 Oct 2010 11:19:26 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B4E4.dip.t-dialin.net [87.179.180.228]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 4FFCF84400A; Mon, 4 Oct 2010 13:19:23 +0200 (CEST) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 6D45F1647; Mon, 4 Oct 2010 13:19:20 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o94BJBsF098316; Mon, 4 Oct 2010 13:19:11 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 04 Oct 2010 13:19:11 +0200 Message-ID: <20101004131911.6737284xpe0sv23o@webmail.leidinger.net> Date: Mon, 04 Oct 2010 13:19:11 +0200 From: Alexander Leidinger To: Dan Langille References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> <4CA87233.2050308@langille.org> In-Reply-To: <4CA87233.2050308@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 4FFCF84400A.A52BE X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.951, required 6, autolearn=disabled, J_CHICKENPOX_57 0.60, RDNS_NONE 1.27, TW_ZF 0.08) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1286795964.5809@KCO+7VnZoKqtGK4Nv4FSSw X-EBL-Spam-Status: No Cc: freebsd-stable , Jeremy Chadwick Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 11:19:27 -0000 Quoting Dan Langille (from Sun, 03 Oct 2010 08:08:19 -0400): > Overnight, the following appeared in /var/log/messages: > > Oct 2 21:56:46 kraken root: ZFS: checksum mismatch, zpool=storage > path=/dev/gpt/disk06-live offset=123103157760 size=1024 > Oct 2 21:56:47 kraken root: ZFS: checksum mismatch, zpool=storage > path=/dev/gpt/disk06-live offset=123103159808 size=1024 [...] > Given the outage from yesterday when ada0 was offline for several > hours, I'm guessing that checksum mismatches on that drive are > expected. Yes, /dev/gpt/disk06-live == ada0. If you have the possibility to run a scrub of the pool, there should be no additional checksum errors accouring *after* the scrub is *finished*. If checksum errors still appear on this disk after the scrub is finished, you should have a look at the hardware (cable/disk) and take appropriate replacement actions. Bye, Alexander. -- If your mother knew what you're doing, she'd probably hang her head and cry. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 14:04:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDEF3106564A for ; Mon, 4 Oct 2010 14:03:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 653448FC13 for ; Mon, 4 Oct 2010 14:03:59 +0000 (UTC) Received: by fxm9 with SMTP id 9so4181007fxm.13 for ; Mon, 04 Oct 2010 07:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=goaGer2rOL+v5j/VPMgwLdYsrHX/OKVWvPmJEhin6JY=; b=ViEfIIpeN81kO/qRS0grWCbMLdLZTuqLkCIihB7qZ2mvQl+FbWYRsLWIvwwdStbK79 SOl6FsCtiiECr5mmgqpI9t6xKas8PVW3M+g57RQRFClo0JZPZYr5ijj2VkzfVvA/IWfg XZRiSoq8MQ5ZxQ8EbjERWfgHPaVgydB1gQE28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=L06pE/axxyldv21ndniI2stjCGVUXUX2V3WQJ9xmlmdjU65+Aa0IpDg7AZn/zN8UGY 4E5j49OXYvYxGmZD/cg/pPcsoUi4A+zzSgQBztH4pJEnLFYxMA9tYynTY45Qg7x6oraZ MpwMVJHxph5/VRh8mNM0suX1DYmB/X/svq+uc= Received: by 10.204.76.205 with SMTP id d13mr6969132bkk.93.1286201038094; Mon, 04 Oct 2010 07:03:58 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y19sm3722870bkw.6.2010.10.04.07.03.55 (version=SSLv3 cipher=RC4-MD5); Mon, 04 Oct 2010 07:03:56 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CA9DEC3.1000302@FreeBSD.org> Date: Mon, 04 Oct 2010 17:03:47 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Alexander Leidinger References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> <4CA7E98E.3040701@comcast.net> <20101003110338.00004197@unknown> In-Reply-To: <20101003110338.00004197@unknown> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Steve Polyack , Jeremy Chadwick , Dan Langille Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 14:04:00 -0000 Alexander Leidinger wrote: > On Sat, 02 Oct 2010 22:25:18 -0400 Steve Polyack > wrote: > >> I thin its worth it to think about TLER (or the absence of it) here - >> http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery . Your >> consumer / SATA Hitachi drives likely do not put a limit on the time >> the drive may block on a command while handling inernal errors. If >> we consider that gpt/gisk06-live encountered some kind of error and >> had to relocate a significant number of blocks or perform some other >> error recovery, then it very well may have timed out long enough for >> siis(4) to drop the device. I have no idea what the timeouts are set >> to in the siis(4) driver, nor does anything in your SMART report >> stick out to me (though I'm certainly no expert with SMART data, and >> my understanding is that many drive manufacturers report the various >> parameters in different ways). Timeouts for commands usually defined by ada(4) peripheral driver and ATA transport layer of CAM. Most of timeouts set to 30 seconds. Only time value defined by siis(4) is hard reset time - 15 seconds now. As soon as drive didn't reappeared after `camcontrol reset/rescan ...` done after significant period of time, but required power cycle, I have doubt that any timeout value could help it. It may be also theoretically possible that it was controller firmware stuck, not drive. It would be interesting to power cycle specific drive if problem repeats. > IIRC mav@ (CCed) made a commit regarding this to -current in the not so > distant past. I do not know about the MFC status of this, or if it may > have helped or not in this situation. My last commit to siis(4) 2 weeks ago (merged recently) fixed specific bug in timeout handling, leading to system crash. I don't see alike symptoms here. If there was any messages before "Oct 2 00:50:53 kraken kernel: (ada0:siisch0:0:0:0): lost device", they could give some hints about original problem. Messages after it could be consequence. Enabling verbose kernel messages could give some more information about what happened there. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 14:59:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C8EB10656A5 for ; Mon, 4 Oct 2010 14:59:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id DC4A38FC16 for ; Mon, 4 Oct 2010 14:59:26 +0000 (UTC) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id EcNa1f0040bG4ec58ezTKe; Mon, 04 Oct 2010 14:59:27 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta03.westchester.pa.mail.comcast.net with comcast id EezR1f00H3LrwQ23PezSFe; Mon, 04 Oct 2010 14:59:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 231379B427; Mon, 4 Oct 2010 07:59:24 -0700 (PDT) Date: Mon, 4 Oct 2010 07:59:24 -0700 From: Jeremy Chadwick To: Alexander Motin Message-ID: <20101004145924.GA9190@icarus.home.lan> References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> <4CA7E98E.3040701@comcast.net> <20101003110338.00004197@unknown> <4CA9DEC3.1000302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA9DEC3.1000302@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Leidinger , freebsd-stable , Steve Polyack , Dan Langille Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 14:59:27 -0000 On Mon, Oct 04, 2010 at 05:03:47PM +0300, Alexander Motin wrote: > Alexander Leidinger wrote: > > On Sat, 02 Oct 2010 22:25:18 -0400 Steve Polyack > > wrote: > > > >> I thin its worth it to think about TLER (or the absence of it) here - > >> http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery . Your > >> consumer / SATA Hitachi drives likely do not put a limit on the time > >> the drive may block on a command while handling inernal errors. If > >> we consider that gpt/gisk06-live encountered some kind of error and > >> had to relocate a significant number of blocks or perform some other > >> error recovery, then it very well may have timed out long enough for > >> siis(4) to drop the device. I have no idea what the timeouts are set > >> to in the siis(4) driver, nor does anything in your SMART report > >> stick out to me (though I'm certainly no expert with SMART data, and > >> my understanding is that many drive manufacturers report the various > >> parameters in different ways). > > Timeouts for commands usually defined by ada(4) peripheral driver and > ATA transport layer of CAM. Most of timeouts set to 30 seconds. Only > time value defined by siis(4) is hard reset time - 15 seconds now. > > As soon as drive didn't reappeared after `camcontrol reset/rescan ...` > done after significant period of time, but required power cycle, I have > doubt that any timeout value could help it. > > It may be also theoretically possible that it was controller firmware > stuck, not drive. It would be interesting to power cycle specific drive > if problem repeats. FWIW, I agree with mav@. I also wanted to talk a bit about TLER, since it wouldn't have helped in this situation. TLER wouldn't have helped because the drive (either mechanically or the firmware) went catatonic and required a power-cycle. TLER would have caused siis(4) to witness a proper ATA error code for the read/write it submit to the drive, and the timeout would (ideally) be shorter than what of the siis(4) or ada(4) layers. So that ATA command would have failed and the OS, almost certainly, would have continued to submit more requests, resulted in an error response, etc... Depending on how the drivers were written, this situation could cause the storage driver to get stuck in an infinite loop trying to read or write to a device that's catatonic. I've seen this happen on Solaris with, again, those Fujitsu disks (the drives return an error status in response to the CDB, the OS/driver says "that's nice" and continues to submit commands to the drive because it's still responding). What I'm trying to say: what ada(4) and/or siis(4) did was the Correct Thing(tm) in my opinion. This is one of the reasons I don't blindly enable TLER on WDC Black disks that I have. Someone would need to quite honestly test the behaviour of TLER with FreeBSD (testing both disk catatonic state as well as transient error + recovery) to see how things behave. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 15:55:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C093B106566C for ; Mon, 4 Oct 2010 15:55:06 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7A18FC18 for ; Mon, 4 Oct 2010 15:55:06 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1P2nNZ-0005nU-2l; Mon, 04 Oct 2010 16:55:05 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2nNZ-000Ldg-1r; Mon, 04 Oct 2010 16:55:05 +0100 Date: Mon, 04 Oct 2010 16:55:05 +0100 Message-Id: To: freebsd@jdc.parodius.com In-Reply-To: <20101004084359.GA2038@icarus.home.lan> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: Has anyone usd hast in production yet - opinions ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 15:55:06 -0000 > Please see the freebsd-fs mailing list, which has quite a large number > of problem reports/issues being posted to it on a regular basis (and > patches are often provided). Thanks have signed up - I was signed up to 'geom' but not that one. A large number of problem reports is not quite what I was hping for, but good to know,a nd maybe I shall hold off for a while :-) cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 16:29:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC7D106566B for ; Mon, 4 Oct 2010 16:29:37 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id EA5058FC13 for ; Mon, 4 Oct 2010 16:29:36 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id 47F482BB34A; Mon, 4 Oct 2010 11:57:04 -0400 (EDT) Date: Mon, 4 Oct 2010 11:57:02 -0400 From: "Peter C. Lai" To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20101004155702.GH70616@cesium.hyperfine.info> References: <4CA78EE3.9020005@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CA78EE3.9020005@quip.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable Subject: Re: is there a bug in AWK on 6.x and 7.x (fixed in 8.x)? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:29:37 -0000 Is this becuase the behavior of "FS=" was changed to match the behavior of awk -F On 2010-10-02 09:58:27PM +0200, Miroslav Lachman wrote: > I think there is a bug in AWK in base of FreeBSD 6.x and 7.x (tested on > 6.4 i386 and 7.3 i386) > > I have this simple test case, where I want 2 columns from GeoIP CSV file: > > awk 'FS="," { print $1"-"$2 }' GeoIPCountryWhois.csv > > It should produce output like this: > > # awk 'FS="," { print $1"-"$2 }' GeoIPCountryWhois.csv | head -n 5 > "1.0.0.0"-"1.7.255.255" > "1.9.0.0"-"1.9.255.255" > "1.10.10.0"-"1.10.10.255" > "1.11.0.0"-"1.11.255.255" > "1.12.0.0"-"1.15.255.255" > > (above is taken from FreeBSD 8.1 i386) > > On FreeBSD 6.4 and 7.3 it results in broken first line: > > awk 'FS="," { print $1"-"$2 }' GeoIPCountryWhois.csv | head -n 5 > "1.0.0.0","1.7.255.255","16777216","17301503","AU","Australia"- > "1.9.0.0"-"1.9.255.255" > "1.10.10.0"-"1.10.10.255" > "1.11.0.0"-"1.11.255.255" > "1.12.0.0"-"1.15.255.255" > > There are no errors in CSV file, it doesn't metter if I delete the > affected first line from the file. > > It is reproducible with handmade file: > > # cat test.csv > "1.9.0.0","1.9.255.255","17367040","17432575","MY","Malaysia" > "1.10.10.0","1.10.10.255","17435136","17435391","AU","Australia" > "1.11.0.0","1.11.255.255","17498112","17563647","KR","Korea, Republic of" > "1.12.0.0","1.15.255.255","17563648","17825791","CN","China" > "1.16.0.0","1.19.255.255","17825792","18087935","KR","Korea, Republic of" > "1.21.0.0","1.21.255.255","18153472","18219007","JP","Japan" > > > # awk 'FS="," { print $1"-"$2 }' test.csv > "1.9.0.0","1.9.255.255","17367040","17432575","MY","Malaysia"- > "1.10.10.0"-"1.10.10.255" > "1.11.0.0"-"1.11.255.255" > "1.12.0.0"-"1.15.255.255" > "1.16.0.0"-"1.19.255.255" > "1.21.0.0"-"1.21.255.255" > > > As it works in 8.1, can it be fixed in 7-STABLE? > (I don't know if it was purposely fixed or if it is coincidence of newer > version of AWK in 8.x) > > Should I file PR for it? > > Miroslav Lachman > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 17:31:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83FCF10656A3 for ; Mon, 4 Oct 2010 17:31:08 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5056F8FC12 for ; Mon, 4 Oct 2010 17:31:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id A56B6509A8; Mon, 4 Oct 2010 18:31:07 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsKHhJa9gnvl; Mon, 4 Oct 2010 18:31:07 +0100 (BST) Received: from nyi.unixathome.org (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id B0682509A5; Mon, 4 Oct 2010 18:31:06 +0100 (BST) Received: from 68.64.144.221 (SquirrelMail authenticated user dan) by nyi.unixathome.org with HTTP; Mon, 4 Oct 2010 13:31:07 -0400 Message-ID: <283dbba8841ab6da40c1d72b05fda618.squirrel@nyi.unixathome.org> In-Reply-To: <4CA981FC.80405@FreeBSD.org> References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org> <4CA981FC.80405@FreeBSD.org> Date: Mon, 4 Oct 2010 13:31:07 -0400 From: "Dan Langille" To: "Martin Matuska" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable , Artem Belevich , Dan Langille Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 17:31:08 -0000 On Mon, October 4, 2010 3:27 am, Martin Matuska wrote: > Try using zfs receive with the -v flag (gives you some stats at the end): > # zfs send storage/bacula@transfer | zfs receive -v > storage/compressed/bacula > > And use the following sysctl (you may set that in /boot/loader.conf, too): > # sysctl vfs.zfs.txg.write_limit_override=805306368 > > I have good results with the 768MB writelimit on systems with at least > 8GB RAM. With 4GB ram, you might want to try to set the TXG write limit > to a lower threshold (e.g. 256MB): > # sysctl vfs.zfs.txg.write_limit_override=268435456 > > You can experiment with that setting to get the best results on your > system. A value of 0 means using calculated default (which is very high). I will experiment with the above. In the meantime: > During the operation you can observe what your disks actually do: > a) via ZFS pool I/O statistics: > # zpool iostat -v 1 > b) via GEOM: > # gstat -a The following output was produced while the original copy was underway. $ sudo gstat -a -b -I 20s dT: 20.002s w: 20.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 7 452 387 24801 9.5 64 2128 7.1 79.4 ada0 7 452 387 24801 9.5 64 2128 7.2 79.4 ada0p1 4 492 427 24655 6.7 64 2128 6.6 63.0 ada1 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2 8 379 313 24798 13.5 65 2127 7.5 78.6 ada3 5 372 306 24774 14.2 64 2127 7.5 77.6 ada4 10 355 291 24741 15.9 63 2127 7.4 79.6 ada5 4 380 316 24807 13.2 64 2128 7.7 77.0 ada6 7 452 387 24801 9.5 64 2128 7.4 79.7 gpt/disk06-live 4 492 427 24655 6.7 64 2128 6.7 63.1 ada1p1 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2p1 8 379 313 24798 13.5 65 2127 7.6 78.6 ada3p1 5 372 306 24774 14.2 64 2127 7.6 77.6 ada4p1 10 355 291 24741 15.9 63 2127 7.5 79.6 ada5p1 4 380 316 24807 13.2 64 2128 7.8 77.0 ada6p1 4 492 427 24655 6.8 64 2128 6.9 63.4 gpt/disk01-live 4 494 428 24691 6.9 65 2127 6.8 67.2 gpt/disk02-live 8 379 313 24798 13.5 65 2127 7.7 78.8 gpt/disk03-live 5 372 306 24774 14.2 64 2127 7.8 77.8 gpt/disk04-live 10 355 291 24741 15.9 63 2127 7.7 79.8 gpt/disk05-live 4 380 316 24807 13.2 64 2128 8.0 77.2 gpt/disk07-live $ zpool ol iostat 10 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- storage 8.08T 4.60T 364 161 41.7M 7.94M storage 8.08T 4.60T 926 133 112M 5.91M storage 8.08T 4.60T 738 164 89.0M 9.75M storage 8.08T 4.60T 1.18K 179 146M 8.10M storage 8.08T 4.60T 1.09K 193 135M 9.94M storage 8.08T 4.60T 1010 185 122M 8.68M storage 8.08T 4.60T 1.06K 184 131M 9.65M storage 8.08T 4.60T 867 178 105M 11.8M storage 8.08T 4.60T 1.06K 198 131M 12.0M storage 8.08T 4.60T 1.06K 185 131M 12.4M Yeterday's write bandwidth was more 80-90M. It's down, a lot. I'll look closer this evening. > > mm > > Dňa 4. 10. 2010 4:06, Artem Belevich wrote / napísal(a): >> On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille wrote: >>> I'm rerunning my test after I had a drive go offline[1]. But I'm not >>> getting anything like the previous test: >>> >>> time zfs send storage/bacula@transfer | mbuffer | zfs receive >>> storage/compressed/bacula-buffer >>> >>> $ zpool iostat 10 10 >>> capacity operations bandwidth >>> pool used avail read write read write >>> ---------- ----- ----- ----- ----- ----- ----- >>> storage 6.83T 5.86T 8 31 1.00M 2.11M >>> storage 6.83T 5.86T 207 481 25.7M 17.8M >> >> It may be worth checking individual disk activity using gstat -f 'da.$' >> >> Some time back I had one drive that was noticeably slower than the >> rest of the drives in RAID-Z2 vdev and was holding everything back. >> SMART looked OK, there were no obvious errors and yet performance was >> much worse than what I'd expect. gstat clearly showed that one drive >> was almost constantly busy with much lower number of reads and writes >> per second than its peers. >> >> Perhaps previously fast transfer rates were due to caching effects. >> I.e. if all metadata already made it into ARC, subsequent "zfs send" >> commands would avoid a lot of random seeks and would show much better >> throughput. >> >> --Artem >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > > -- Dan Langille -- http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 18:10:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74F2B1065672 for ; Mon, 4 Oct 2010 18:10:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5127E8FC13 for ; Mon, 4 Oct 2010 18:10:33 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta04.emeryville.ca.mail.comcast.net with comcast id EcFG1f0050vp7WLA4iAZHg; Mon, 04 Oct 2010 18:10:33 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta05.emeryville.ca.mail.comcast.net with comcast id EiAY1f00L3LrwQ28RiAYG1; Mon, 04 Oct 2010 18:10:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 20C349B427; Mon, 4 Oct 2010 11:10:32 -0700 (PDT) Date: Mon, 4 Oct 2010 11:10:32 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20101004181032.GA12998@icarus.home.lan> References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org> <4CA981FC.80405@FreeBSD.org> <283dbba8841ab6da40c1d72b05fda618.squirrel@nyi.unixathome.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <283dbba8841ab6da40c1d72b05fda618.squirrel@nyi.unixathome.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable , Martin Matuska , Artem Belevich Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:10:34 -0000 On Mon, Oct 04, 2010 at 01:31:07PM -0400, Dan Langille wrote: > > On Mon, October 4, 2010 3:27 am, Martin Matuska wrote: > > Try using zfs receive with the -v flag (gives you some stats at the end): > > # zfs send storage/bacula@transfer | zfs receive -v > > storage/compressed/bacula > > > > And use the following sysctl (you may set that in /boot/loader.conf, too): > > # sysctl vfs.zfs.txg.write_limit_override=805306368 > > > > I have good results with the 768MB writelimit on systems with at least > > 8GB RAM. With 4GB ram, you might want to try to set the TXG write limit > > to a lower threshold (e.g. 256MB): > > # sysctl vfs.zfs.txg.write_limit_override=268435456 > > > > You can experiment with that setting to get the best results on your > > system. A value of 0 means using calculated default (which is very high). > > I will experiment with the above. In the meantime: > > > During the operation you can observe what your disks actually do: > > a) via ZFS pool I/O statistics: > > # zpool iostat -v 1 > > b) via GEOM: > > # gstat -a > > The following output was produced while the original copy was underway. > > $ sudo gstat -a -b -I 20s > dT: 20.002s w: 20.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 7 452 387 24801 9.5 64 2128 7.1 79.4 ada0 > 7 452 387 24801 9.5 64 2128 7.2 79.4 ada0p1 > 4 492 427 24655 6.7 64 2128 6.6 63.0 ada1 > 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2 > 8 379 313 24798 13.5 65 2127 7.5 78.6 ada3 > 5 372 306 24774 14.2 64 2127 7.5 77.6 ada4 > 10 355 291 24741 15.9 63 2127 7.4 79.6 ada5 > 4 380 316 24807 13.2 64 2128 7.7 77.0 ada6 > 7 452 387 24801 9.5 64 2128 7.4 79.7 gpt/disk06-live > 4 492 427 24655 6.7 64 2128 6.7 63.1 ada1p1 > 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2p1 > 8 379 313 24798 13.5 65 2127 7.6 78.6 ada3p1 > 5 372 306 24774 14.2 64 2127 7.6 77.6 ada4p1 > 10 355 291 24741 15.9 63 2127 7.5 79.6 ada5p1 > 4 380 316 24807 13.2 64 2128 7.8 77.0 ada6p1 > 4 492 427 24655 6.8 64 2128 6.9 63.4 gpt/disk01-live > 4 494 428 24691 6.9 65 2127 6.8 67.2 gpt/disk02-live > 8 379 313 24798 13.5 65 2127 7.7 78.8 gpt/disk03-live > 5 372 306 24774 14.2 64 2127 7.8 77.8 gpt/disk04-live > 10 355 291 24741 15.9 63 2127 7.7 79.8 gpt/disk05-live > 4 380 316 24807 13.2 64 2128 8.0 77.2 gpt/disk07-live > > $ zpool ol iostat 10 > capacity operations bandwidth > pool used avail read write read write > ---------- ----- ----- ----- ----- ----- ----- > storage 8.08T 4.60T 364 161 41.7M 7.94M > storage 8.08T 4.60T 926 133 112M 5.91M > storage 8.08T 4.60T 738 164 89.0M 9.75M > storage 8.08T 4.60T 1.18K 179 146M 8.10M > storage 8.08T 4.60T 1.09K 193 135M 9.94M > storage 8.08T 4.60T 1010 185 122M 8.68M > storage 8.08T 4.60T 1.06K 184 131M 9.65M > storage 8.08T 4.60T 867 178 105M 11.8M > storage 8.08T 4.60T 1.06K 198 131M 12.0M > storage 8.08T 4.60T 1.06K 185 131M 12.4M > > Yeterday's write bandwidth was more 80-90M. It's down, a lot. > > I'll look closer this evening. > > > > > > mm > > > > Dňa 4. 10. 2010 4:06, Artem Belevich wrote / napísal(a): > >> On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille wrote: > >>> I'm rerunning my test after I had a drive go offline[1]. But I'm not > >>> getting anything like the previous test: > >>> > >>> time zfs send storage/bacula@transfer | mbuffer | zfs receive > >>> storage/compressed/bacula-buffer > >>> > >>> $ zpool iostat 10 10 > >>> capacity operations bandwidth > >>> pool used avail read write read write > >>> ---------- ----- ----- ----- ----- ----- ----- > >>> storage 6.83T 5.86T 8 31 1.00M 2.11M > >>> storage 6.83T 5.86T 207 481 25.7M 17.8M > >> > >> It may be worth checking individual disk activity using gstat -f 'da.$' > >> > >> Some time back I had one drive that was noticeably slower than the > >> rest of the drives in RAID-Z2 vdev and was holding everything back. > >> SMART looked OK, there were no obvious errors and yet performance was > >> much worse than what I'd expect. gstat clearly showed that one drive > >> was almost constantly busy with much lower number of reads and writes > >> per second than its peers. > >> > >> Perhaps previously fast transfer rates were due to caching effects. > >> I.e. if all metadata already made it into ARC, subsequent "zfs send" > >> commands would avoid a lot of random seeks and would show much better > >> throughput. > >> > >> --Artem Please read all of the following items before responding in-line. Some are just informational items for other people reading the thread. 1) I don't see any indication in the thread of what "zpool status" looks like on this machine. I'd like to assume it's the same machine in another thread you started, but I can't reliably make that assumption. 2) All we know about the controller/disks is from your original dmesg. I've taken the below from it, including only the stuff relevant to disks ada[0-6]: siis0: port 0xdc00-0xdc0f mem 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci6 siisch0: at channel 0 on siis0 siisch1: at channel 1 on siis0 siisch2: at channel 2 on siis0 siisch3: at channel 3 on siis0 siis1: port 0xbc00-0xbc0f mem 0xfbcffc00-0xfbcffc7f,0xfbcf0000-0xfbcf7fff irq 19 at device 4.0 on pci3 siisch4: at channel 0 on siis1 siisch5: at channel 1 on siis1 siisch6: at channel 2 on siis1 siisch7: at channel 3 on siis1 ada0 at siisch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1 at siisch2 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2 at siisch3 bus 0 scbus3 target 0 lun 0 ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3 at siisch4 bus 0 scbus4 target 0 lun 0 ada3: ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada4 at siisch5 bus 0 scbus5 target 0 lun 0 ada4: ATA-8 SATA 2.x device ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada5 at siisch6 bus 0 scbus6 target 0 lun 0 ada5: ATA-8 SATA 2.x device ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada5: Command Queueing enabled ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada6 at siisch7 bus 0 scbus7 target 0 lun 0 ada6: ATA-8 SATA 2.x device ada6: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada6: Command Queueing enabled ada6: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) 2) There are no other devices on the machine which share IRQ 17 or 19, but that aside, please provide "vmstat -i" output during the time where the transfer is happening. I doubt this is the problem though. "pciconf -lvc" would also be useful (include only the siis0 and siis1 devices), just to rule out any oddities there (I doubt any). 3) Have you done "sysctl kstat.zfs.misc.arcstats" during the transfer to see which counters get incremented? If I remember right, the ARC being "starved" or under high utilisation can cause slow I/O, especially in the case where you were seeing decent I/O in the past but not now. I think kstat.zfs.misc.arcstats.memory_throttle_count monitors this, but it'd be best to watch everything. 4) The machine has 4GB of RAM; that said, what /boot/loader.conf tunings are in place on this system? 5) The machine where "sudo gstat -a -b -I 20s" is being run from shows both reads and writes happening at the same time (approximately 24MBytes/sec read and 2MBytes/sec write, on each individual device). Worth noting. 6) Are the abysmal performance numbers here with or without mbuffer? Your numbers without mbuffer were around 40MB/read and 40MB/write (per device), while with mbuffer (once tuned) were around 110MB/read and 80MB/write (per device). 7) ZFS compression is in use on the filesystems on this system. 8) Since you're testing zfs send/receive, don't you need to show what's happening on *both* systems (the sender and the recipient)? Footnote: Please use "-f '^ada[0-9]+$' in the future on your gstat, to include only the adaXX devices. The xxxp1 and gpt entries aren't of interest. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 23:24:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 306C9106566C for ; Mon, 4 Oct 2010 23:24:28 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id F3B4D8FC1F for ; Mon, 4 Oct 2010 23:24:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 5C084509B6; Tue, 5 Oct 2010 00:24:27 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDXmeUqzbP54; Tue, 5 Oct 2010 00:24:27 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 0D668509A8 ; Tue, 5 Oct 2010 00:24:27 +0100 (BST) Message-ID: <4CAA622B.4040904@langille.org> Date: Mon, 04 Oct 2010 19:24:27 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexander Leidinger References: <4CA73702.5080203@langille.org> <20101002141921.GC70283@icarus.home.lan> <4CA7AD95.9040703@langille.org> <20101002223626.GB78136@icarus.home.lan> <4CA7BEE4.9050201@langille.org> <20101002235024.GA80643@icarus.home.lan> <4CA7E4AE.4060607@langille.org> <4CA87233.2050308@langille.org> <20101004131911.6737284xpe0sv23o@webmail.leidinger.net> In-Reply-To: <20101004131911.6737284xpe0sv23o@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Jeremy Chadwick Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 23:24:28 -0000 On 10/4/2010 7:19 AM, Alexander Leidinger wrote: > Quoting Dan Langille (from Sun, 03 Oct 2010 08:08:19 > -0400): > >> Overnight, the following appeared in /var/log/messages: >> >> Oct 2 21:56:46 kraken root: ZFS: checksum mismatch, zpool=storage >> path=/dev/gpt/disk06-live offset=123103157760 size=1024 >> Oct 2 21:56:47 kraken root: ZFS: checksum mismatch, zpool=storage >> path=/dev/gpt/disk06-live offset=123103159808 size=1024 > > [...] > >> Given the outage from yesterday when ada0 was offline for several >> hours, I'm guessing that checksum mismatches on that drive are >> expected. Yes, /dev/gpt/disk06-live == ada0. > > If you have the possibility to run a scrub of the pool, there should be > no additional checksum errors accouring *after* the scrub is *finished*. > If checksum errors still appear on this disk after the scrub is > finished, you should have a look at the hardware (cable/disk) and take > appropriate replacement actions. For the record, -just finished a scrub. $ zpool status pool: storage state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 13h48m with 0 errors on Mon Oct 4 16:54:15 2010 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk01-live ONLINE 0 0 0 gpt/disk02-live ONLINE 0 0 0 gpt/disk03-live ONLINE 0 0 0 gpt/disk04-live ONLINE 0 0 0 gpt/disk05-live ONLINE 0 0 0 gpt/disk06-live ONLINE 0 0 141K 3.47G repaired gpt/disk07-live ONLINE 0 0 0 errors: No known data errors -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 4 23:39:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43B7F106564A; Mon, 4 Oct 2010 23:39:17 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id E5E1C8FC1A; Mon, 4 Oct 2010 23:39:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 33A22509B6; Tue, 5 Oct 2010 00:39:16 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twFqrprE9C14; Tue, 5 Oct 2010 00:39:15 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 996DD509A8 ; Tue, 5 Oct 2010 00:39:15 +0100 (BST) Message-ID: <4CAA65A4.9080108@langille.org> Date: Mon, 04 Oct 2010 19:39:16 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <45cfd27021fb93f9b0877a1596089776.squirrel@nyi.unixathome.org> <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org> <4CA981FC.80405@FreeBSD.org> <283dbba8841ab6da40c1d72b05fda618.squirrel@nyi.unixathome.org> <20101004181032.GA12998@icarus.home.lan> In-Reply-To: <20101004181032.GA12998@icarus.home.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable , Martin Matuska , Artem Belevich Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 23:39:17 -0000 On 10/4/2010 2:10 PM, Jeremy Chadwick wrote: > On Mon, Oct 04, 2010 at 01:31:07PM -0400, Dan Langille wrote: >> >> On Mon, October 4, 2010 3:27 am, Martin Matuska wrote: >>> Try using zfs receive with the -v flag (gives you some stats at the end): >>> # zfs send storage/bacula@transfer | zfs receive -v >>> storage/compressed/bacula >>> >>> And use the following sysctl (you may set that in /boot/loader.conf, too): >>> # sysctl vfs.zfs.txg.write_limit_override=805306368 >>> >>> I have good results with the 768MB writelimit on systems with at least >>> 8GB RAM. With 4GB ram, you might want to try to set the TXG write limit >>> to a lower threshold (e.g. 256MB): >>> # sysctl vfs.zfs.txg.write_limit_override=268435456 >>> >>> You can experiment with that setting to get the best results on your >>> system. A value of 0 means using calculated default (which is very high). >> >> I will experiment with the above. In the meantime: >> >>> During the operation you can observe what your disks actually do: >>> a) via ZFS pool I/O statistics: >>> # zpool iostat -v 1 >>> b) via GEOM: >>> # gstat -a >> >> The following output was produced while the original copy was underway. >> >> $ sudo gstat -a -b -I 20s >> dT: 20.002s w: 20.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 7 452 387 24801 9.5 64 2128 7.1 79.4 ada0 >> 7 452 387 24801 9.5 64 2128 7.2 79.4 ada0p1 >> 4 492 427 24655 6.7 64 2128 6.6 63.0 ada1 >> 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2 >> 8 379 313 24798 13.5 65 2127 7.5 78.6 ada3 >> 5 372 306 24774 14.2 64 2127 7.5 77.6 ada4 >> 10 355 291 24741 15.9 63 2127 7.4 79.6 ada5 >> 4 380 316 24807 13.2 64 2128 7.7 77.0 ada6 >> 7 452 387 24801 9.5 64 2128 7.4 79.7 gpt/disk06-live >> 4 492 427 24655 6.7 64 2128 6.7 63.1 ada1p1 >> 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2p1 >> 8 379 313 24798 13.5 65 2127 7.6 78.6 ada3p1 >> 5 372 306 24774 14.2 64 2127 7.6 77.6 ada4p1 >> 10 355 291 24741 15.9 63 2127 7.5 79.6 ada5p1 >> 4 380 316 24807 13.2 64 2128 7.8 77.0 ada6p1 >> 4 492 427 24655 6.8 64 2128 6.9 63.4 gpt/disk01-live >> 4 494 428 24691 6.9 65 2127 6.8 67.2 gpt/disk02-live >> 8 379 313 24798 13.5 65 2127 7.7 78.8 gpt/disk03-live >> 5 372 306 24774 14.2 64 2127 7.8 77.8 gpt/disk04-live >> 10 355 291 24741 15.9 63 2127 7.7 79.8 gpt/disk05-live >> 4 380 316 24807 13.2 64 2128 8.0 77.2 gpt/disk07-live >> >> $ zpool ol iostat 10 >> capacity operations bandwidth >> pool used avail read write read write >> ---------- ----- ----- ----- ----- ----- ----- >> storage 8.08T 4.60T 364 161 41.7M 7.94M >> storage 8.08T 4.60T 926 133 112M 5.91M >> storage 8.08T 4.60T 738 164 89.0M 9.75M >> storage 8.08T 4.60T 1.18K 179 146M 8.10M >> storage 8.08T 4.60T 1.09K 193 135M 9.94M >> storage 8.08T 4.60T 1010 185 122M 8.68M >> storage 8.08T 4.60T 1.06K 184 131M 9.65M >> storage 8.08T 4.60T 867 178 105M 11.8M >> storage 8.08T 4.60T 1.06K 198 131M 12.0M >> storage 8.08T 4.60T 1.06K 185 131M 12.4M >> >> Yeterday's write bandwidth was more 80-90M. It's down, a lot. >> >> I'll look closer this evening. >> >> >>> >>> mm >>> >>> Dňa 4. 10. 2010 4:06, Artem Belevich wrote / napísal(a): >>>> On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille wrote: >>>>> I'm rerunning my test after I had a drive go offline[1]. But I'm not >>>>> getting anything like the previous test: >>>>> >>>>> time zfs send storage/bacula@transfer | mbuffer | zfs receive >>>>> storage/compressed/bacula-buffer >>>>> >>>>> $ zpool iostat 10 10 >>>>> capacity operations bandwidth >>>>> pool used avail read write read write >>>>> ---------- ----- ----- ----- ----- ----- ----- >>>>> storage 6.83T 5.86T 8 31 1.00M 2.11M >>>>> storage 6.83T 5.86T 207 481 25.7M 17.8M >>>> >>>> It may be worth checking individual disk activity using gstat -f 'da.$' >>>> >>>> Some time back I had one drive that was noticeably slower than the >>>> rest of the drives in RAID-Z2 vdev and was holding everything back. >>>> SMART looked OK, there were no obvious errors and yet performance was >>>> much worse than what I'd expect. gstat clearly showed that one drive >>>> was almost constantly busy with much lower number of reads and writes >>>> per second than its peers. >>>> >>>> Perhaps previously fast transfer rates were due to caching effects. >>>> I.e. if all metadata already made it into ARC, subsequent "zfs send" >>>> commands would avoid a lot of random seeks and would show much better >>>> throughput. >>>> >>>> --Artem > > Please read all of the following items before responding in-line. Some > are just informational items for other people reading the thread. Thanks for the help. :) > > 1) I don't see any indication in the thread of what "zpool status" looks > like on this machine. I'd like to assume it's the same machine in > another thread you started, but I can't reliably make that assumption. It is the same machine as the one that had the ada0 problem over the weekend (as shown in the other thread). $ zpool status -v pool: storage state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed after 13h48m with 0 errors on Mon Oct 4 16:54:15 2010 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/disk01-live ONLINE 0 0 0 gpt/disk02-live ONLINE 0 0 0 gpt/disk03-live ONLINE 0 0 0 gpt/disk04-live ONLINE 0 0 0 gpt/disk05-live ONLINE 0 0 0 gpt/disk06-live ONLINE 0 0 141K 3.47G repaired gpt/disk07-live ONLINE 0 0 0 errors: No known data errors NOTE: an automatic scrub just ended... > > 2) All we know about the controller/disks is from your original dmesg. > I've taken the below from it, including only the stuff relevant to > disks ada[0-6]: > > siis0: port 0xdc00-0xdc0f mem 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci6 > siisch0: at channel 0 on siis0 > siisch1: at channel 1 on siis0 > siisch2: at channel 2 on siis0 > siisch3: at channel 3 on siis0 > siis1: port 0xbc00-0xbc0f mem 0xfbcffc00-0xfbcffc7f,0xfbcf0000-0xfbcf7fff irq 19 at device 4.0 on pci3 > siisch4: at channel 0 on siis1 > siisch5: at channel 1 on siis1 > siisch6: at channel 2 on siis1 > siisch7: at channel 3 on siis1 > ada0 at siisch0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada1 at siisch2 bus 0 scbus2 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada2 at siisch3 bus 0 scbus3 target 0 lun 0 > ada2: ATA-8 SATA 2.x device > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada3 at siisch4 bus 0 scbus4 target 0 lun 0 > ada3: ATA-8 SATA 2.x device > ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada3: Command Queueing enabled > ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada4 at siisch5 bus 0 scbus5 target 0 lun 0 > ada4: ATA-8 SATA 2.x device > ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada4: Command Queueing enabled > ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada5 at siisch6 bus 0 scbus6 target 0 lun 0 > ada5: ATA-8 SATA 2.x device > ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada5: Command Queueing enabled > ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada6 at siisch7 bus 0 scbus7 target 0 lun 0 > ada6: ATA-8 SATA 2.x device > ada6: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada6: Command Queueing enabled > ada6: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > > 2) There are no other devices on the machine which share IRQ 17 or 19, > but that aside, please provide "vmstat -i" output during the time where > the transfer is happening. I doubt this is the problem though. > "pciconf -lvc" would also be useful (include only the siis0 and siis1 > devices), just to rule out any oddities there (I doubt any). $ vmstat -i interrupt total rate irq1: atkbd0 5 0 irq16: ohci0 ohci1 3 0 irq18: ohci2 ohci3+ 4 0 irq20: ahc0 15 0 irq22: ahci0 849710 5 cpu0: timer 328126052 1999 irq256: em0 72404742 441 irq257: siis0 107712551 656 irq259: siis1 119319384 727 cpu1: timer 328107354 1999 cpu2: timer 328107355 1999 cpu3: timer 328107353 1999 Total 1612734528 9829 $ sudo pciconf -lvc hostb0@pci0:0:0:0: class=0x060000 card=0x59561002 chip=0x59561002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 GFX Dual Slot' class = bridge subclass = HOST-PCI cap 08[c4] = HT slave cap 08[40] = HT retry mode cap 08[54] = HT unit ID clumping cap 08[9c] = HT unknown d03c pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx0 port A)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x16) cap 05[a0] = MSI supports 1 message cap 0d[b0] = PCI Bridge card=0x59561002 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 pcib2@pci0:0:5:0: class=0x060400 card=0x59561002 chip=0x597b1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port B)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) cap 05[a0] = MSI supports 1 message cap 0d[b0] = PCI Bridge card=0x59561002 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x1) cap 05[a0] = MSI supports 1 message cap 0d[b0] = PCI Bridge card=0x59561002 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 pcib5@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx1 port A)' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 2 root port max data 128(128) link x1(x16) cap 05[a0] = MSI supports 1 message cap 0d[b0] = PCI Bridge card=0x59561002 cap 08[b8] = HT MSI fixed address window enabled at 0xfee00000 ahci0@pci0:0:17:0: class=0x01018f card=0x43901002 chip=0x43901002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Integrated SATA II Controller (SB700)' class = mass storage subclass = ATA cap 12[70] = SATA Index-Data Pair ohci0@pci0:0:18:0: class=0x0c0310 card=0x43971002 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB ohci1@pci0:0:18:1: class=0x0c0310 card=0x43981002 chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Standard OpenHCD USB-Hostcontroller (SB700)' class = serial bus subclass = USB ehci0@pci0:0:18:2: class=0x0c0320 card=0x43971002 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 ohci2@pci0:0:19:0: class=0x0c0310 card=0x43981002 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB ohci3@pci0:0:19:1: class=0x0c0310 card=0x43991002 chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Standard OpenHCD USB-Hostcontroller (SB700)' class = serial bus subclass = USB ehci1@pci0:0:19:2: class=0x0c0320 card=0x43961002 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB cap 01[c0] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 0a[e4] = EHCI Debug Port at offset 0xe0 in map 0x14 none0@pci0:0:20:0: class=0x0c0500 card=0x43851002 chip=0x43851002 rev=0x3a hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI SMBus (ATI RD600/RS600)' class = serial bus subclass = SMBus cap 08[b0] = HT MSI fixed address window disabled at 0xfee00000 atapci0@pci0:0:20:1: class=0x01018a card=0x439c1002 chip=0x439c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'PATA 133 Controller (SB7xx)' class = mass storage subclass = ATA cap 05[70] = MSI supports 2 messages isab0@pci0:0:20:3: class=0x060100 card=0x43831002 chip=0x439d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 LPC host controller' class = bridge subclass = PCI-ISA pcib7@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 PCI to PCI Bridge' class = bridge subclass = PCI-PCI ohci4@pci0:0:20:5: class=0x0c0310 card=0x43961002 chip=0x43991002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI2 Controller' class = serial bus subclass = USB hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI cap 08[80] = HT host hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron Miscellaneous Control' class = bridge subclass = HOST-PCI cap 0f[f0] = unknown hostb5@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon64/Opteron/Sempron Link Control' class = bridge subclass = HOST-PCI em0@pci0:7:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c pcib3@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0xe11112d8 rev=0x02 hdr=0x01 vendor = 'Pericom Semiconductor' class = bridge subclass = PCI-PCI cap 07[80] = PCI-X bridge cap 01[90] = powerspec 3 supports D0 D3 current D0 cap 0d[a8] = PCI Bridge card=0x00000000 cap 10[b0] = PCI-Express 1 PCI bridge max data 128(512) link x1(x1) cap 05[f0] = MSI supports 1 message, 64 bit siis0@pci0:6:4:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI-X to Serial ATA Controller (SiI 3124)' class = mass storage subclass = RAID cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message re0@pci0:4:0:0: class=0x020000 card=0x83851043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 03[48] = VPD cap 05[50] = MSI supports 2 messages, 64 bit enabled with 1 message cap 10[60] = PCI-Express 1 endpoint max data 128(128) link x1(x1) cap 09[84] = vendor (length 76) pcib6@pci0:2:0:0: class=0x060400 card=0x00000000 chip=0xe11112d8 rev=0x02 hdr=0x01 vendor = 'Pericom Semiconductor' class = bridge subclass = PCI-PCI cap 07[80] = PCI-X bridge cap 01[90] = powerspec 3 supports D0 D3 current D0 cap 0d[a8] = PCI Bridge card=0x00000000 cap 10[b0] = PCI-Express 1 PCI bridge max data 128(512) link x1(x1) cap 05[f0] = MSI supports 1 message, 64 bit siis1@pci0:3:4:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI-X to Serial ATA Controller (SiI 3124)' class = mass storage subclass = RAID cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message ahc0@pci0:1:5:0: class=0x010000 card=0x78849004 chip=0x84789004 rev=0x01 hdr=0x00 vendor = 'Adaptec Inc' device = 'Ultra-Wide Diff. SCSI Ctrlr (ADAPTEC 2940UW CN SCSI)' class = mass storage subclass = SCSI cap 01[dc] = powerspec 1 supports D0 D3 current D0 vgapci0@pci0:1:6:0: class=0x030000 card=0x00000000 chip=0x96601023 rev=0xd3 hdr=0x00 vendor = 'Trident Microsystems' device = 'TGUI9660XGi/968x/938x GUI Accelerator' class = display subclass = VGA > 3) Have you done "sysctl kstat.zfs.misc.arcstats" during the transfer to > see which counters get incremented? If I remember right, the ARC being > "starved" or under high utilisation can cause slow I/O, especially in > the case where you were seeing decent I/O in the past but not now. I > think kstat.zfs.misc.arcstats.memory_throttle_count monitors this, but > it'd be best to watch everything. The transfers is still underway so I just ran the command: $ sysctl kstat.zfs.misc.arcstats kstat.zfs.misc.arcstats.hits: 19654617 kstat.zfs.misc.arcstats.misses: 18760397 kstat.zfs.misc.arcstats.demand_data_hits: 17919024 kstat.zfs.misc.arcstats.demand_data_misses: 142871 kstat.zfs.misc.arcstats.demand_metadata_hits: 1734974 kstat.zfs.misc.arcstats.demand_metadata_misses: 534816 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 17941342 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 619 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 141368 kstat.zfs.misc.arcstats.mru_hits: 19057650 kstat.zfs.misc.arcstats.mru_ghost_hits: 85075 kstat.zfs.misc.arcstats.mfu_hits: 596480 kstat.zfs.misc.arcstats.mfu_ghost_hits: 64187 kstat.zfs.misc.arcstats.allocated: 40949126 kstat.zfs.misc.arcstats.deleted: 38057232 kstat.zfs.misc.arcstats.stolen: 31511274 kstat.zfs.misc.arcstats.recycle_miss: 248009 kstat.zfs.misc.arcstats.mutex_miss: 17349 kstat.zfs.misc.arcstats.evict_skip: 1981764 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 2504097772032 kstat.zfs.misc.arcstats.evict_l2_ineligible: 2377474798592 kstat.zfs.misc.arcstats.hash_elements: 54548 kstat.zfs.misc.arcstats.hash_elements_max: 90455 kstat.zfs.misc.arcstats.hash_collisions: 21246248 kstat.zfs.misc.arcstats.hash_chains: 14690 kstat.zfs.misc.arcstats.hash_chain_max: 11 kstat.zfs.misc.arcstats.p: 754974720 kstat.zfs.misc.arcstats.c: 805306368 kstat.zfs.misc.arcstats.c_min: 805306368 kstat.zfs.misc.arcstats.c_max: 6442450944 kstat.zfs.misc.arcstats.size: 805091968 kstat.zfs.misc.arcstats.hdr_size: 11792592 kstat.zfs.misc.arcstats.data_size: 791902208 kstat.zfs.misc.arcstats.other_size: 1397168 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 157695 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 18613226 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 > 4) The machine has 4GB of RAM; that said, what /boot/loader.conf tunings > are in place on this system? $ cat /boot/loader.conf geom_mirror_load="YES" ahci_load="YES" siis_load="YES" vm.kmem_size=7G > 5) The machine where "sudo gstat -a -b -I 20s" is being run from shows > both reads and writes happening at the same time (approximately > 24MBytes/sec read and 2MBytes/sec write, on each individual device). > Worth noting. > > 6) Are the abysmal performance numbers here with or without mbuffer? > Your numbers without mbuffer were around 40MB/read and 40MB/write (per > device), while with mbuffer (once tuned) were around 110MB/read and > 80MB/write (per device). With mbuffer: time zfs send storage/bacula@transfer | mbuffer | zfs receive storage/compressed/bacula-buffer > 7) ZFS compression is in use on the filesystems on this system. Compression is on the destination only. Source and destination are on the same machine. $ zfs list NAME USED AVAIL REFER MOUNTPOINT storage 6.07T 2.81T 1.75G /storage storage/bacula 4.85T 2.81T 4.29T /storage/bacula storage/compressed 1.21T 2.81T 44.8K /storage/compressed storage/compressed/bacula-mbuffer 1.21T 2.81T 1.21T /storage/compressed/bacula-mbuffer storage/pgsql 5.50G 2.81T 5.50G /storage/pgsql > 8) Since you're testing zfs send/receive, don't you need to show what's > happening on *both* systems (the sender and the recipient)? Sender = recipient. It's all in the same machine. > Footnote: Please use "-f '^ada[0-9]+$' in the future on your gstat, to > include only the adaXX devices. The xxxp1 and gpt entries aren't of > interest. That confirms what I was playing with earlier. Thanks. dT: 1.001s w: 1.000s filter: ^ada[0-9]+$ L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 395 116 8561 10.8 276 8830 5.7 77.7| ada0 1 408 107 8419 12.0 299 8851 5.7 64.0| ada1 1 400 111 8677 15.6 287 8663 8.6 77.9| ada2 1 384 107 8587 12.7 275 9246 8.2 70.6| ada3 1 393 109 8419 12.6 282 9292 7.8 68.7| ada4 1 385 107 8445 16.0 276 9385 7.7 72.8| ada5 1 381 101 8575 15.3 278 9428 8.0 67.1| ada6 0 0 0 0 0.0 0 0 0.0 0.0| ada7 0 0 0 0 0.0 0 0 0.0 0.0| ada8 -- Dan Langille - http://langille.org/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 5 06:07:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AF68106564A for ; Tue, 5 Oct 2010 06:07:50 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh8.mail.rice.edu (mh8.mail.rice.edu [128.42.201.24]) by mx1.freebsd.org (Postfix) with ESMTP id D6B918FC24 for ; Tue, 5 Oct 2010 06:07:49 +0000 (UTC) Received: from mh8.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh8.mail.rice.edu (Postfix) with ESMTP id BAFC228F825; Tue, 5 Oct 2010 00:51:58 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh8.mail.rice.edu, auth channel Received: from mh8.mail.rice.edu ([127.0.0.1]) by mh8.mail.rice.edu (mh8.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id XPx598wzAhxq; Tue, 5 Oct 2010 00:51:58 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh8.mail.rice.edu (Postfix) with ESMTPSA id 42D6628F824; Tue, 5 Oct 2010 00:51:58 -0500 (CDT) Message-ID: <4CAABCFD.6050709@rice.edu> Date: Tue, 05 Oct 2010 00:51:57 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Dave Hayes References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> <201010040512.o945CTor092854@hugeraid.jetcafe.org> In-Reply-To: <201010040512.o945CTor092854@hugeraid.jetcafe.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:07:50 -0000 Dave Hayes wrote: > Alan Cox writes: > >> I'm afraid that I can't offer much insight without a stack trace. At >> initialization time, we map the kernel with 2MB pages. I suspect that >> something within the kernel is later trying to change one those mappings. >> If I had to guess, it's related to the mfs root. >> > > Here is the stack trace. The machine is sitting here in KDB if you > need me to extract any information from it. I > > db> bt > Tracing pid 0 tid 0 td 0xffffffff80c67140 > kdb_enter() at kdbenter+0x3d > panic() at panic+0x17b > pmap_enter() at pmap_enter+0x641 > kmem_malloc() at kmem_malloc+0x1b5 > uma_large_malloc() at uma_large_malloc+0x4a > malloc() at malloc+0xd7 > acpi_alloc_wakeup_handler() at acpi_alloc_wakeup_handler+0x82 > mi_startup() at mi_startup+0x59 > btext() at btext+0x2c > db> > > Thanks. There are two pieces of information that might be helpful: the value of the global variable "kernel_vm_end" and the virtual address that was passed to pmap_enter(). Is this problem reproducible? I don't recall if you mentioned that earlier. Can you take a crash dump? Alan From owner-freebsd-stable@FreeBSD.ORG Tue Oct 5 06:47:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A9791065674 for ; Tue, 5 Oct 2010 06:47:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 776988FC14 for ; Tue, 5 Oct 2010 06:47:22 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta07.emeryville.ca.mail.comcast.net with comcast id Eufz1f0020lTkoCA7unNq2; Tue, 05 Oct 2010 06:47:22 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.emeryville.ca.mail.comcast.net with comcast id EunL1f0083LrwQ28QunMVb; Tue, 05 Oct 2010 06:47:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 863CF9B427; Mon, 4 Oct 2010 23:47:20 -0700 (PDT) Date: Mon, 4 Oct 2010 23:47:20 -0700 From: Jeremy Chadwick To: Dan Langille Message-ID: <20101005064720.GA25231@icarus.home.lan> References: <4C511EF8-591C-4BB9-B7AA-30D5C3DDC0FF@langille.org> <4CA68BBD.6060601@langille.org> <4CA929A8.6000708@langille.org> <4CA981FC.80405@FreeBSD.org> <283dbba8841ab6da40c1d72b05fda618.squirrel@nyi.unixathome.org> <20101004181032.GA12998@icarus.home.lan> <4CAA65A4.9080108@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CAA65A4.9080108@langille.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable , Martin Matuska , Artem Belevich Subject: Re: zfs send/receive: is this slow? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 06:47:22 -0000 On Mon, Oct 04, 2010 at 07:39:16PM -0400, Dan Langille wrote: > On 10/4/2010 2:10 PM, Jeremy Chadwick wrote: > >On Mon, Oct 04, 2010 at 01:31:07PM -0400, Dan Langille wrote: > >> > >>On Mon, October 4, 2010 3:27 am, Martin Matuska wrote: > >>>Try using zfs receive with the -v flag (gives you some stats at the end): > >>># zfs send storage/bacula@transfer | zfs receive -v > >>>storage/compressed/bacula > >>> > >>>And use the following sysctl (you may set that in /boot/loader.conf, too): > >>># sysctl vfs.zfs.txg.write_limit_override=805306368 > >>> > >>>I have good results with the 768MB writelimit on systems with at least > >>>8GB RAM. With 4GB ram, you might want to try to set the TXG write limit > >>>to a lower threshold (e.g. 256MB): > >>># sysctl vfs.zfs.txg.write_limit_override=268435456 > >>> > >>>You can experiment with that setting to get the best results on your > >>>system. A value of 0 means using calculated default (which is very high). > >> > >>I will experiment with the above. In the meantime: > >> > >>>During the operation you can observe what your disks actually do: > >>>a) via ZFS pool I/O statistics: > >>># zpool iostat -v 1 > >>>b) via GEOM: > >>># gstat -a > >> > >>The following output was produced while the original copy was underway. > >> > >>$ sudo gstat -a -b -I 20s > >>dT: 20.002s w: 20.000s > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > >> 7 452 387 24801 9.5 64 2128 7.1 79.4 ada0 > >> 7 452 387 24801 9.5 64 2128 7.2 79.4 ada0p1 > >> 4 492 427 24655 6.7 64 2128 6.6 63.0 ada1 > >> 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2 > >> 8 379 313 24798 13.5 65 2127 7.5 78.6 ada3 > >> 5 372 306 24774 14.2 64 2127 7.5 77.6 ada4 > >> 10 355 291 24741 15.9 63 2127 7.4 79.6 ada5 > >> 4 380 316 24807 13.2 64 2128 7.7 77.0 ada6 > >> 7 452 387 24801 9.5 64 2128 7.4 79.7 gpt/disk06-live > >> 4 492 427 24655 6.7 64 2128 6.7 63.1 ada1p1 > >> 4 494 428 24691 6.9 65 2127 6.6 66.9 ada2p1 > >> 8 379 313 24798 13.5 65 2127 7.6 78.6 ada3p1 > >> 5 372 306 24774 14.2 64 2127 7.6 77.6 ada4p1 > >> 10 355 291 24741 15.9 63 2127 7.5 79.6 ada5p1 > >> 4 380 316 24807 13.2 64 2128 7.8 77.0 ada6p1 > >> 4 492 427 24655 6.8 64 2128 6.9 63.4 gpt/disk01-live > >> 4 494 428 24691 6.9 65 2127 6.8 67.2 gpt/disk02-live > >> 8 379 313 24798 13.5 65 2127 7.7 78.8 gpt/disk03-live > >> 5 372 306 24774 14.2 64 2127 7.8 77.8 gpt/disk04-live > >> 10 355 291 24741 15.9 63 2127 7.7 79.8 gpt/disk05-live > >> 4 380 316 24807 13.2 64 2128 8.0 77.2 gpt/disk07-live > >> > >>$ zpool ol iostat 10 > >> capacity operations bandwidth > >>pool used avail read write read write > >>---------- ----- ----- ----- ----- ----- ----- > >>storage 8.08T 4.60T 364 161 41.7M 7.94M > >>storage 8.08T 4.60T 926 133 112M 5.91M > >>storage 8.08T 4.60T 738 164 89.0M 9.75M > >>storage 8.08T 4.60T 1.18K 179 146M 8.10M > >>storage 8.08T 4.60T 1.09K 193 135M 9.94M > >>storage 8.08T 4.60T 1010 185 122M 8.68M > >>storage 8.08T 4.60T 1.06K 184 131M 9.65M > >>storage 8.08T 4.60T 867 178 105M 11.8M > >>storage 8.08T 4.60T 1.06K 198 131M 12.0M > >>storage 8.08T 4.60T 1.06K 185 131M 12.4M > >> > >>Yeterday's write bandwidth was more 80-90M. It's down, a lot. > >> > >>I'll look closer this evening. > >> > >> > >>> > >>>mm > >>> > >>>Dňa 4. 10. 2010 4:06, Artem Belevich wrote / napísal(a): > >>>>On Sun, Oct 3, 2010 at 6:11 PM, Dan Langille wrote: > >>>>>I'm rerunning my test after I had a drive go offline[1]. But I'm not > >>>>>getting anything like the previous test: > >>>>> > >>>>>time zfs send storage/bacula@transfer | mbuffer | zfs receive > >>>>>storage/compressed/bacula-buffer > >>>>> > >>>>>$ zpool iostat 10 10 > >>>>> capacity operations bandwidth > >>>>>pool used avail read write read write > >>>>>---------- ----- ----- ----- ----- ----- ----- > >>>>>storage 6.83T 5.86T 8 31 1.00M 2.11M > >>>>>storage 6.83T 5.86T 207 481 25.7M 17.8M > >>>> > >>>>It may be worth checking individual disk activity using gstat -f 'da.$' > >>>> > >>>>Some time back I had one drive that was noticeably slower than the > >>>>rest of the drives in RAID-Z2 vdev and was holding everything back. > >>>>SMART looked OK, there were no obvious errors and yet performance was > >>>>much worse than what I'd expect. gstat clearly showed that one drive > >>>>was almost constantly busy with much lower number of reads and writes > >>>>per second than its peers. > >>>> > >>>>Perhaps previously fast transfer rates were due to caching effects. > >>>>I.e. if all metadata already made it into ARC, subsequent "zfs send" > >>>>commands would avoid a lot of random seeks and would show much better > >>>>throughput. > >>>> > >>>>--Artem > > > >Please read all of the following items before responding in-line. Some > >are just informational items for other people reading the thread. > > Thanks for the help. :) > > > > >1) I don't see any indication in the thread of what "zpool status" looks > >like on this machine. I'd like to assume it's the same machine in > >another thread you started, but I can't reliably make that assumption. > > It is the same machine as the one that had the ada0 problem over the > weekend (as shown in the other thread). > > $ zpool status -v > pool: storage > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are > unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. > see: http://www.sun.com/msg/ZFS-8000-9P > scrub: scrub completed after 13h48m with 0 errors on Mon Oct 4 > 16:54:15 2010 > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > gpt/disk01-live ONLINE 0 0 0 > gpt/disk02-live ONLINE 0 0 0 > gpt/disk03-live ONLINE 0 0 0 > gpt/disk04-live ONLINE 0 0 0 > gpt/disk05-live ONLINE 0 0 0 > gpt/disk06-live ONLINE 0 0 141K 3.47G repaired > gpt/disk07-live ONLINE 0 0 0 > > errors: No known data errors > > > NOTE: an automatic scrub just ended... scrubbing is a highly intensive process, so I'm not too surprised that your throughput was garbage since you had a scrub running simultaneously. This is normal/expected, and happens on both FreeBSD ZFS and Solaris ZFS. You shouldn't be testing performance of things during a scrub. > >2) All we know about the controller/disks is from your original dmesg. > >I've taken the below from it, including only the stuff relevant to > >disks ada[0-6]: > > > >siis0: port 0xdc00-0xdc0f mem 0xfbeffc00-0xfbeffc7f,0xfbef0000-0xfbef7fff irq 17 at device 4.0 on pci6 > >siisch0: at channel 0 on siis0 > >siisch1: at channel 1 on siis0 > >siisch2: at channel 2 on siis0 > >siisch3: at channel 3 on siis0 > >siis1: port 0xbc00-0xbc0f mem 0xfbcffc00-0xfbcffc7f,0xfbcf0000-0xfbcf7fff irq 19 at device 4.0 on pci3 > >siisch4: at channel 0 on siis1 > >siisch5: at channel 1 on siis1 > >siisch6: at channel 2 on siis1 > >siisch7: at channel 3 on siis1 > >ada0 at siisch0 bus 0 scbus0 target 0 lun 0 > >ada0: ATA-8 SATA 2.x device > >ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada0: Command Queueing enabled > >ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > >ada1 at siisch2 bus 0 scbus2 target 0 lun 0 > >ada1: ATA-8 SATA 2.x device > >ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada1: Command Queueing enabled > >ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > >ada2 at siisch3 bus 0 scbus3 target 0 lun 0 > >ada2: ATA-8 SATA 2.x device > >ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada2: Command Queueing enabled > >ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > >ada3 at siisch4 bus 0 scbus4 target 0 lun 0 > >ada3: ATA-8 SATA 2.x device > >ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada3: Command Queueing enabled > >ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > >ada4 at siisch5 bus 0 scbus5 target 0 lun 0 > >ada4: ATA-8 SATA 2.x device > >ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada4: Command Queueing enabled > >ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > >ada5 at siisch6 bus 0 scbus6 target 0 lun 0 > >ada5: ATA-8 SATA 2.x device > >ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada5: Command Queueing enabled > >ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > >ada6 at siisch7 bus 0 scbus7 target 0 lun 0 > >ada6: ATA-8 SATA 2.x device > >ada6: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >ada6: Command Queueing enabled > >ada6: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > > > >2) There are no other devices on the machine which share IRQ 17 or 19, > >but that aside, please provide "vmstat -i" output during the time where > >the transfer is happening. I doubt this is the problem though. > >"pciconf -lvc" would also be useful (include only the siis0 and siis1 > >devices), just to rule out any oddities there (I doubt any). > > > $ vmstat -i > interrupt total rate > irq1: atkbd0 5 0 > irq16: ohci0 ohci1 3 0 > irq18: ohci2 ohci3+ 4 0 > irq20: ahc0 15 0 > irq22: ahci0 849710 5 > cpu0: timer 328126052 1999 > irq256: em0 72404742 441 > irq257: siis0 107712551 656 > irq259: siis1 119319384 727 > cpu1: timer 328107354 1999 > cpu2: timer 328107355 1999 > cpu3: timer 328107353 1999 > Total 1612734528 9829 > > $ sudo pciconf -lvc > [...] > siis0@pci0:6:4:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x01 hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > device = 'PCI-X to Serial ATA Controller (SiI 3124)' > class = mass storage > subclass = RAID > cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions > cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message > siis1@pci0:3:4:0: class=0x010400 card=0x71241095 chip=0x31241095 rev=0x01 hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > device = 'PCI-X to Serial ATA Controller (SiI 3124)' > class = mass storage > subclass = RAID > cap 01[64] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 12 split transactions > cap 05[54] = MSI supports 1 message, 64 bit enabled with 1 message I asked for just the only the siis0 and siis1 devices, sigh. Sorry to bark, but when I outline something explicitly and someone can't follow directions, it's irritating. Thanks for the vmstat -i output. When the transfer is finished, run the command again and look for the interrupt rates associated with siis0 and siis1. They should be significantly lower than they are above. If not, something odd is going on interrupt-wise. Translation: you shouldn't be seeing 656 ints/sec or 727 ints/sec when there's little to no I/O on the device. If there is, there's a problem (driver bug, etc.). > >3) Have you done "sysctl kstat.zfs.misc.arcstats" during the transfer to > >see which counters get incremented? If I remember right, the ARC being > >"starved" or under high utilisation can cause slow I/O, especially in > >the case where you were seeing decent I/O in the past but not now. I > >think kstat.zfs.misc.arcstats.memory_throttle_count monitors this, but > >it'd be best to watch everything. > > > The transfers is still underway so I just ran the command: > > $ sysctl kstat.zfs.misc.arcstats > kstat.zfs.misc.arcstats.hits: 19654617 > kstat.zfs.misc.arcstats.misses: 18760397 > kstat.zfs.misc.arcstats.demand_data_hits: 17919024 > kstat.zfs.misc.arcstats.demand_data_misses: 142871 > kstat.zfs.misc.arcstats.demand_metadata_hits: 1734974 > kstat.zfs.misc.arcstats.demand_metadata_misses: 534816 > kstat.zfs.misc.arcstats.prefetch_data_hits: 0 > kstat.zfs.misc.arcstats.prefetch_data_misses: 17941342 > kstat.zfs.misc.arcstats.prefetch_metadata_hits: 619 > kstat.zfs.misc.arcstats.prefetch_metadata_misses: 141368 > kstat.zfs.misc.arcstats.mru_hits: 19057650 > kstat.zfs.misc.arcstats.mru_ghost_hits: 85075 > kstat.zfs.misc.arcstats.mfu_hits: 596480 > kstat.zfs.misc.arcstats.mfu_ghost_hits: 64187 > kstat.zfs.misc.arcstats.allocated: 40949126 > kstat.zfs.misc.arcstats.deleted: 38057232 > kstat.zfs.misc.arcstats.stolen: 31511274 > kstat.zfs.misc.arcstats.recycle_miss: 248009 > kstat.zfs.misc.arcstats.mutex_miss: 17349 > kstat.zfs.misc.arcstats.evict_skip: 1981764 > kstat.zfs.misc.arcstats.evict_l2_cached: 0 > kstat.zfs.misc.arcstats.evict_l2_eligible: 2504097772032 > kstat.zfs.misc.arcstats.evict_l2_ineligible: 2377474798592 > kstat.zfs.misc.arcstats.hash_elements: 54548 > kstat.zfs.misc.arcstats.hash_elements_max: 90455 > kstat.zfs.misc.arcstats.hash_collisions: 21246248 > kstat.zfs.misc.arcstats.hash_chains: 14690 > kstat.zfs.misc.arcstats.hash_chain_max: 11 > kstat.zfs.misc.arcstats.p: 754974720 > kstat.zfs.misc.arcstats.c: 805306368 > kstat.zfs.misc.arcstats.c_min: 805306368 > kstat.zfs.misc.arcstats.c_max: 6442450944 > kstat.zfs.misc.arcstats.size: 805091968 > kstat.zfs.misc.arcstats.hdr_size: 11792592 > kstat.zfs.misc.arcstats.data_size: 791902208 > kstat.zfs.misc.arcstats.other_size: 1397168 > kstat.zfs.misc.arcstats.l2_hits: 0 > kstat.zfs.misc.arcstats.l2_misses: 0 > kstat.zfs.misc.arcstats.l2_feeds: 0 > kstat.zfs.misc.arcstats.l2_rw_clash: 0 > kstat.zfs.misc.arcstats.l2_read_bytes: 0 > kstat.zfs.misc.arcstats.l2_write_bytes: 0 > kstat.zfs.misc.arcstats.l2_writes_sent: 0 > kstat.zfs.misc.arcstats.l2_writes_done: 0 > kstat.zfs.misc.arcstats.l2_writes_error: 0 > kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 > kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 > kstat.zfs.misc.arcstats.l2_evict_reading: 0 > kstat.zfs.misc.arcstats.l2_free_on_write: 0 > kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 > kstat.zfs.misc.arcstats.l2_cksum_bad: 0 > kstat.zfs.misc.arcstats.l2_io_error: 0 > kstat.zfs.misc.arcstats.l2_size: 0 > kstat.zfs.misc.arcstats.l2_hdr_size: 0 > kstat.zfs.misc.arcstats.memory_throttle_count: 157695 > kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 > kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 > kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 > kstat.zfs.misc.arcstats.l2_write_in_l2: 0 > kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 > kstat.zfs.misc.arcstats.l2_write_not_cacheable: 18613226 > kstat.zfs.misc.arcstats.l2_write_full: 0 > kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 > kstat.zfs.misc.arcstats.l2_write_pios: 0 > kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 > kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 > kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 Thanks. Others more familiar with these counters will need to analyse them and comment on what could be happening. > >4) The machine has 4GB of RAM; that said, what /boot/loader.conf tunings > >are in place on this system? > > $ cat /boot/loader.conf > geom_mirror_load="YES" > ahci_load="YES" > siis_load="YES" > > vm.kmem_size=7G Thanks. How about output from "sysctl -a | egrep '^vfs.zfs.arc_'" when the I/O rate is horrible? I don't see vfs.zfs.arc_max being set, which is why I ask. > >5) The machine where "sudo gstat -a -b -I 20s" is being run from shows > >both reads and writes happening at the same time (approximately > >24MBytes/sec read and 2MBytes/sec write, on each individual device). > >Worth noting. > > > >6) Are the abysmal performance numbers here with or without mbuffer? > >Your numbers without mbuffer were around 40MB/read and 40MB/write (per > >device), while with mbuffer (once tuned) were around 110MB/read and > >80MB/write (per device). > > With mbuffer: > > time zfs send storage/bacula@transfer | mbuffer | zfs receive > storage/compressed/bacula-buffer > > > >7) ZFS compression is in use on the filesystems on this system. > > Compression is on the destination only. Source and destination are > on the same machine. > > $ zfs list > NAME USED AVAIL REFER MOUNTPOINT > storage 6.07T 2.81T 1.75G /storage > storage/bacula 4.85T 2.81T 4.29T /storage/bacula > storage/compressed 1.21T 2.81T 44.8K /storage/compressed > storage/compressed/bacula-mbuffer 1.21T 2.81T 1.21T > /storage/compressed/bacula-mbuffer > storage/pgsql 5.50G 2.81T 5.50G /storage/pgsql > > >8) Since you're testing zfs send/receive, don't you need to show what's > >happening on *both* systems (the sender and the recipient)? > > Sender = recipient. It's all in the same machine. Is this even a legitimate test when it comes to benchmarking I/O? Your disks will be thrashing heavily (indicated by the %busy field in gstat): > >Footnote: Please use "-f '^ada[0-9]+$' in the future on your gstat, to > >include only the adaXX devices. The xxxp1 and gpt entries aren't of > >interest. > > That confirms what I was playing with earlier. Thanks. > > dT: 1.001s w: 1.000s filter: ^ada[0-9]+$ > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 395 116 8561 10.8 276 8830 5.7 77.7| ada0 > 1 408 107 8419 12.0 299 8851 5.7 64.0| ada1 > 1 400 111 8677 15.6 287 8663 8.6 77.9| ada2 > 1 384 107 8587 12.7 275 9246 8.2 70.6| ada3 > 1 393 109 8419 12.6 282 9292 7.8 68.7| ada4 > 1 385 107 8445 16.0 276 9385 7.7 72.8| ada5 > 1 381 101 8575 15.3 278 9428 8.0 67.1| ada6 > 0 0 0 0 0.0 0 0 0.0 0.0| ada7 > 0 0 0 0 0.0 0 0 0.0 0.0| ada8 I don't really have anything else to say at this point. Benchmarks being done during a scrub, in addition to send/receive being done on the same box? I'm not sure there will be much to investigate. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 5 09:18:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217CC106566B; Tue, 5 Oct 2010 09:18:29 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id EA8108FC15; Tue, 5 Oct 2010 09:18:28 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o959IR05065727; Tue, 5 Oct 2010 02:18:27 -0700 (PDT) Message-Id: <201010050918.o959IR05065727@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Alan Cox In-reply-to: <4CAABCFD.6050709@rice.edu> References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> <201010040512.o945CTor092854@hugeraid.jetcafe.org> <4CAABCFD.6050709@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Oct 2010 02:18:27 -0700 From: Dave Hayes Cc: alc@freebsd.org, freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 09:18:29 -0000 Alan Cox writes: > There are two pieces of information that might be helpful: the value of > the global variable "kernel_vm_end" and the virtual address that was > passed to pmap_enter(). I'm afraid I don't have enough experience with this debugger to get these values with offhand commands. I could trial and error my way through figuring it out, but I'd rather get the data you expect. :) If you could give me the commands to do this, I'd be happy to type them in and get a response to you. > Is this problem reproducible? I don't recall if you mentioned that > earlier. Sort of. It seems that everytime I generate a bootable FreeBSD ISO, a die is rolled. If it comes up a certain number then it crashes, otherwise it's fine. ;) My ISO generation process might be relevant; I create a 600MB ramdisk (it used to be 512 on FreeBSD 7.3) which loads from the ISO on boot. This winds up being the root partition. As a datapoint the same die roll happens on FreeBSD 7.3 although the chance of working seems to be greater. If you'd like a copy of the ISO to see this for yourself I can make it available. I'm guessing it will also crash for you in this way modulo hardware issues. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< The treasure house within you contains everything, and you are free to use it. You don't need to seek outside. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 5 13:42:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E84C106566C for ; Tue, 5 Oct 2010 13:42:35 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from mta04.eastlink.ca (mta04.eastlink.ca [24.224.136.10]) by mx1.freebsd.org (Postfix) with ESMTP id 059598FC18 for ; Tue, 5 Oct 2010 13:42:34 +0000 (UTC) MIME-version: 1.0 Received: from ip02.eastlink.ca ([unknown] [24.222.39.20]) by mta04.eastlink.ca (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep 1 2009)) with ESMTP id <0L9T00LBCJCZUAE1@mta04.eastlink.ca> for freebsd-stable@freebsd.org; Tue, 05 Oct 2010 10:12:35 -0300 (ADT) X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=mORQtGzMSGJSBwuMSvVfB0MKjPGmXehAuj88Uvu04o4= c=1 sm=1 a=fuijmVPJwygA:10 a=8Z25AiM9YVTHTjoppoMA:9 a=PZs15PPytPg_y8zMsOP3gcEoULIA:4 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=CqHmtUo7cI639Yrea0MA:9 a=Tj_EuNKBbwfbZ-v1YQQA:7 a=kyz08oSWwFZzXHGYFoaWdvbETp0A:4 a=Y4g+zi6NJtbRuBVJrbSZ6Q==:117 Received: from blk-222-10-85.eastlink.ca (HELO server7.acsi.ca) ([24.222.10.85]) by ip02.eastlink.ca with ESMTP; Tue, 05 Oct 2010 10:12:33 -0300 Received: from server7.acsi.ca ([192.168.9.7]) by server7.acsi.ca ([192.168.9.7]) with mapi; Tue, 05 Oct 2010 10:12:33 -0300 From: Chris Forgeron To: "freebsd-stable@freebsd.org" Date: Tue, 05 Oct 2010 10:12:32 -0300 Thread-topic: Dell T710 with Xeon x5660 Kernel Panics - Fixed under 8.1-STABLE Thread-index: ActkjvhNWGGShk7CQ9apguWtVbUdlw== Message-id: Accept-Language: en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Dell T710 with Xeon x5660 Kernel Panics - Fixed under 8.1-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 13:42:35 -0000 BTW, just passing on that my Dell T710 which would Kernel panic under 8.1-RELEASE randomly between 10 minutes-2 days, no longer does this under 8.1-STABLE. I was running it with 2 of the new Intel 6 core Xeon's - X5660 Under 8.1.-RELEASE FreeBSD didn't recognize the processor, and I guess that's causing APIC table load issues? I had tried 2 reinstalls, and building a custom kernel, and always the same issue. My CPU is detected properly under STABLE, and looks to be rock solid - Except for a small ZFS bug that may report a bit later when I have time for screen shots. I still have the old HD with 8.1 STABLE on it, and can load it up if anyone needed me to find out exactly the difference. Thanks. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 6 07:19:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE58106564A for ; Wed, 6 Oct 2010 07:19:20 +0000 (UTC) (envelope-from kalstrup@verizon.net) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9173F8FC0C for ; Wed, 6 Oct 2010 07:19:20 +0000 (UTC) Received: from [192.168.0.16] ([unknown] [74.107.145.151]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L9U00M7RUVUX450@vms173015.mailsrvcs.net> for freebsd-stable@freebsd.org; Wed, 06 Oct 2010 01:19:07 -0500 (CDT) Message-id: <4CAC14DA.7050409@verizon.net> Date: Tue, 05 Oct 2010 23:19:06 -0700 From: Kurt Alstrup User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100926 Lightning/1.0b3pre Thunderbird/3.1.3 MIME-version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.1 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: alc@rice.edu Subject: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 07:19:20 -0000 Up front disclaimer: I may very well be wrong on this.. This looks like a pmap bug I ran into a recently on a pre-release of 8.0. It's still present in stock 8.0, but I have not looked at 8.1 (see disclaimer). The bug was caused by a combination of a shortcut in pmap_unuse_pt() which didn't wipe pte entries when un-mapping VA's from kernel space and the VM entering multi-page allocations one at a time. Littering of the page table page by pmap_unuse_pt() does not cause problems by itself because the pages are sort of locked in place by the reservation. It may however fool the promotion check at the end of pmap_enter() in the case the kernel maps a multi-page allocation where; 1) cause the backing reservation to become fully populated, and 2) the backing pages has been used (mapped and unmapped) earlier. >From pmap.c: /* * If both the page table page and the reservation are fully * populated, then attempt promotion. */ if ((mpte == NULL || mpte->wire_count == NPTEPG) && pg_ps_enabled && vm_reserv_level_iffullpop(m) == 0) pmap_promote_pde(pmap, pde, va); When pmap_enter() of the first page in the allocation the following holds true: - mpte is null for kernel space VA's - pg_ps_enabled is set (otherwise there would be no 2M maps) - vm_reserv_level_iffullpop() will return 0 , so pmap_promote_pde() will be called. It may succeed in creating a 2MB map because of the litter pmap_unuse_pt() left behind (helped by the fact that other PTE attributes likely are the same because this is only used by the kernel) When pmap_enter() of the second page in the large allocation, the assert reported triggers. This fits the trace given db> bt Tracing pid 0 tid 0 td 0xffffffff80c67140 kdb_enter() at kdbenter+0x3d panic() at panic+0x17b pmap_enter() at pmap_enter+0x641 kmem_malloc() at kmem_malloc+0x1b5 uma_large_malloc() at uma_large_malloc+0x4a malloc() at malloc+0xd7 acpi_alloc_wakeup_handler() at acpi_alloc_wakeup_handler+0x82 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> My work-around was to add a check in pmap_enter() on whether the page entered already was correctly represented in the page table and if it was, leave things as they were. It had the nice side effect of limiting TLB shoot downs from page faults on same page from multiple CPUs in a threaded application. I considered changing pmap_unuse_pt() to clear the PTE entries for kernel space VA's but figured it would require TLB shoot downs too, which wasn't exactly what I wanted. Another idea was to make a pmap_enter_multiple() function to handle this case correctly by not trying to promote until all pages has been entered. Of course, turning off auto-promotion by setting vm.pmap.pg_ps_enabled to 0 also makes the problem go away, at the cost of less TLB coverage. Hope this was useful (helped more that it confused). Kurt A From owner-freebsd-stable@FreeBSD.ORG Wed Oct 6 17:46:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E62F106566C; Wed, 6 Oct 2010 17:46:44 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id 14D648FC0A; Wed, 6 Oct 2010 17:46:43 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 7B3AA28F79C; Wed, 6 Oct 2010 12:46:43 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id cMKhnEsdk6xz; Wed, 6 Oct 2010 12:46:43 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 3775B28F79F; Wed, 6 Oct 2010 12:46:42 -0500 (CDT) Message-ID: <4CACB601.6060205@rice.edu> Date: Wed, 06 Oct 2010 12:46:41 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Dave Hayes References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> <201010040512.o945CTor092854@hugeraid.jetcafe.org> <4CAABCFD.6050709@rice.edu> <201010050918.o959IR05065727@hugeraid.jetcafe.org> In-Reply-To: <201010050918.o959IR05065727@hugeraid.jetcafe.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:46:44 -0000 Dave Hayes wrote: > Alan Cox writes: > [snip] >> Is this problem reproducible? I don't recall if you mentioned that >> earlier. >> > > Sort of. > > It seems that everytime I generate a bootable FreeBSD ISO, a die is > rolled. If it comes up a certain number then it crashes, otherwise it's > fine. ;) > > My ISO generation process might be relevant; I create a 600MB ramdisk > (it used to be 512 on FreeBSD 7.3) which loads from the ISO on > boot. This winds up being the root partition. > > As a datapoint the same die roll happens on FreeBSD 7.3 although the > chance of working seems to be greater. > > If you'd like a copy of the ISO to see this for yourself I can make it > available. I'm guessing it will also crash for you in this way modulo > hardware issues. > When you build your kernel for this ISO are you increasing the value of NKPT? Alan From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 02:02:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A1941065670; Thu, 7 Oct 2010 02:02:51 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from hugeraid.jetcafe.org (hugeraid.jetcafe.org [205.147.26.109]) by mx1.freebsd.org (Postfix) with ESMTP id C56BD8FC0C; Thu, 7 Oct 2010 02:02:50 +0000 (UTC) Received: from hugeraid.jetcafe.org (localhost [127.0.0.1]) by hugeraid.jetcafe.org (8.13.8/8.13.8) with ESMTP id o9722onH012781; Wed, 6 Oct 2010 19:02:50 -0700 (PDT) Message-Id: <201010070202.o9722onH012781@hugeraid.jetcafe.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Alan Cox In-reply-to: <4CACB601.6060205@rice.edu> References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> <201010040512.o945CTor092854@hugeraid.jetcafe.org> <4CAABCFD.6050709@rice.edu> <201010050918.o959IR05065727@hugeraid.jetcafe.org> <4CACB601.6060205@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Oct 2010 19:02:50 -0700 From: Dave Hayes Cc: alc@freebsd.org, freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 02:02:51 -0000 Alan Cox writes: > When you build your kernel for this ISO are you increasing the value of > NKPT? No. I was under the impression that this value auto-tunes on amd64, is that correct? -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< >From your first day at school you are cut off from life to make theories. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 04:46:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BB13106564A; Thu, 7 Oct 2010 04:46:20 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC148FC18; Thu, 7 Oct 2010 04:46:20 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 4971E28F77C; Wed, 6 Oct 2010 23:46:17 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id MIe3nULrz4ph; Wed, 6 Oct 2010 23:46:17 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id C055E28F77A; Wed, 6 Oct 2010 23:46:16 -0500 (CDT) Message-ID: <4CAD5097.4060403@rice.edu> Date: Wed, 06 Oct 2010 23:46:15 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Dave Hayes References: <201010030211.o932Bd4C048116@hugeraid.jetcafe.org> <201010040512.o945CTor092854@hugeraid.jetcafe.org> <4CAABCFD.6050709@rice.edu> <201010050918.o959IR05065727@hugeraid.jetcafe.org> <4CACB601.6060205@rice.edu> <201010070202.o9722onH012781@hugeraid.jetcafe.org> In-Reply-To: <201010070202.o9722onH012781@hugeraid.jetcafe.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-stable Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 04:46:20 -0000 Dave Hayes wrote: > Alan Cox writes: > >> When you build your kernel for this ISO are you increasing the value of >> NKPT? >> > > No. I was under the impression that this value auto-tunes on amd64, > is that correct? > After initialization, yes. However, the kernel starts out with just NKPT page table pages. With a 600MB MFS root in your kernel, the default setting for NKPT won't provide enough page table pages to map your entire kernel during initialization. Try setting NKPT to 320, and let me know if the strange crashes go away. Alan From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 05:58:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7417C1065670 for ; Thu, 7 Oct 2010 05:58:52 +0000 (UTC) (envelope-from marcus@blazingdot.com) Received: from marklar.blazingdot.com (marklar.blazingdot.com [207.154.84.83]) by mx1.freebsd.org (Postfix) with SMTP id 62C918FC08 for ; Thu, 7 Oct 2010 05:58:51 +0000 (UTC) Received: (qmail 39504 invoked by uid 503); 7 Oct 2010 05:32:10 -0000 Date: Wed, 6 Oct 2010 22:32:10 -0700 From: Marcus Reid To: freebsd-stable@freebsd.org Message-ID: <20101007053210.GA39338@blazingdot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.6i Subject: ZFS root pool backup and recovery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 05:58:52 -0000 Hi, The process of creating a backup of the ZFS root pool on Solaris is simple and straightforward: http://docs.sun.com/app/docs/doc/819-5461/ghzwu?l=en&a=view So is restoring it on bare metal: http://docs.sun.com/app/docs/doc/819-5461/ghzur?a=view Has anybody done something similar on FreeBSD with ZFS root? What are the main differences? Thanks, Marcus From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 07:11:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBAC106564A for ; Thu, 7 Oct 2010 07:11:26 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (unknown [IPv6:2002:51af:3dc3:0:250:56ff:feb7:c]) by mx1.freebsd.org (Postfix) with ESMTP id 56E508FC13 for ; Thu, 7 Oct 2010 07:11:26 +0000 (UTC) Received: from [127.0.0.1] (w500.skogen.stillbilde.net [192.168.4.5]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 9AC1D23 for ; Thu, 7 Oct 2010 09:11:35 +0200 (CEST) Message-ID: <4CAD7298.5080200@stillbilde.net> Date: Thu, 07 Oct 2010 09:11:20 +0200 From: "Svein Skogen (Listmail account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20101007053210.GA39338@blazingdot.com> In-Reply-To: <20101007053210.GA39338@blazingdot.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D02F806BCE8A71383092442" Subject: Re: ZFS root pool backup and recovery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 07:11:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D02F806BCE8A71383092442 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07.10.2010 07:32, Marcus Reid wrote: > Hi, >=20 > The process of creating a backup of the ZFS root pool on Solaris > is simple and straightforward: >=20 > http://docs.sun.com/app/docs/doc/819-5461/ghzwu?l=3Den&a=3Dview >=20 > So is restoring it on bare metal: >=20 > http://docs.sun.com/app/docs/doc/819-5461/ghzur?a=3Dview >=20 How well does that method handle a single bit being toggled in transit? //Svein --=20 --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =D8stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ ------------------------------------------------------------ --------------enig0D02F806BCE8A71383092442 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkytcpwACgkQODUnwSLUlKQKrACfa8wu3qohj4M3udIdYY8v/xFE QMYAnjDEinuikBY0eL3bVQjQir9XI982 =UEQ6 -----END PGP SIGNATURE----- --------------enig0D02F806BCE8A71383092442-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 10:46:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D28881065674 for ; Thu, 7 Oct 2010 10:46:09 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9288FC1B for ; Thu, 7 Oct 2010 10:46:09 +0000 (UTC) Received: from russet.local (reflex.squiz.co.uk [83.217.109.164]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o97AjvrJ024346 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 7 Oct 2010 11:46:04 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk o97AjvrJ024346 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1286448364; bh=t6hzh+kXwprz6XK7/1pcgEI1HjhSQymeBauTC8QSAzM=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type:Cc: Content-Type:Date:From:In-Reply-To:Message-ID:Mime-Version: References:To; z=Message-ID:=20<4CADA4D5.7080204@infracaninophile.co.uk>|Date:=20T hu,=2007=20Oct=202010=2011:45:41=20+0100|From:=20Matthew=20Seaman= 20|User-Agent:=20Mozilla/5.0=20(M acintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B=20en-US=3B=20r v:1.9.2.9)=20Gecko/20100915=20Thunderbird/3.1.4|MIME-Version:=201. 0|To:=20freebsd-stable@freebsd.org|Subject:=20Multiple=20zdevs=20i n=20the=20root=20zpool?|X-Enigmail-Version:=201.1.1|Content-Type:= 20multipart/signed=3B=20micalg=3Dpgp-sha1=3B=0D=0A=20protocol=3D"a pplication/pgp-signature"=3B=0D=0A=20boundary=3D"------------enig0 402EA43580307E3D2299BAA"; b=hOhFuJUp1Aytx3tec2Di1sdft4m+2JqJEGRVTfkOT787DQ7wOFDDRIeeQdSY80oOw +mx9L8mUPjyWtiOTibe5eci2/a30m6X7XGZTqQWLpkO3ruzjfdMh94cTPMEtd3n8N5 UNgWSCzTKgwibtd/R2L7HjO1tbhxvoJ/Wxbu8iJA= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host reflex.squiz.co.uk [83.217.109.164] claimed to be russet.local Message-ID: <4CADA4D5.7080204@infracaninophile.co.uk> Date: Thu, 07 Oct 2010 11:45:41 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0402EA43580307E3D2299BAA" X-Virus-Scanned: clamav-milter 0.96.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Multiple zdevs in the root zpool? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 10:46:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0402EA43580307E3D2299BAA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, folks, Currently we have a RAIDZ1 system using 6 x 1TB drives, which we use as a bacula storage device. We now have another 6 x 1TB drives to increase capacity. I'd originally planned to just create another zpool and have two partitions mounted for bacula to store stuff in. However, it would be better in many ways if we could just add the capacity to the existing setup, presumably by creating a second vdev in the original pool. However, according to my understanding, if you want to boot from a zpool, you can only have one vdev in that pool. But what exactly does this mean? Is it really mounting the root fs that's the problem, or is it reading the kernel out of /boot ? Originally I followed the recipe in http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 for creating a system using a RAIDZ1 pool, so I have small freebsd-boot and -swap partitions on every drive. I don't really need that much swap space, so is there a way of parlaying that into something like the UFS /boot setup described in http://wiki.freebsd.org/RootOnZFS/UFSBoot ? Except I don't care about BIOS level compatibility with other OSes and so would happily forgo installing a MBR. Cheers Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig0402EA43580307E3D2299BAA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkytpOUACgkQ8Mjk52CukIw0dACfQulFUauT6c2nvI081hORRrhk VoIAn1cbEdeZWifxr3CkDuFU8v2hzel/ =I82r -----END PGP SIGNATURE----- --------------enig0402EA43580307E3D2299BAA-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 12:16:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F3FA106566C for ; Thu, 7 Oct 2010 12:16:03 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id B998D8FC13 for ; Thu, 7 Oct 2010 12:16:00 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 698AA39824; Thu, 7 Oct 2010 14:15:58 +0200 (SAST) Date: Thu, 7 Oct 2010 14:15:58 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20101007121558.GA70199@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 12:16:03 -0000 Hi, I got hold of a SunFire X4500 with 48 X 500G disks and thought to try FreeBSD 8-stable with zfs on it. I have setup the two boot disks in a zfs mirror and then the rest in a pool of 6 X raidz2 of 7 disks each. I have created a 10G file with dd in the second pool, but if I try to read it with dd, dd will hang in "zio->io_cv)" according to ^T. This happens everytime. The first time I saw messages about an interrupt storm, so I have put "hw.intr_storm_threshold=10000" in /etc/sysctl.conf. According to "systat -vm 1" there is atapci for 2-3 seconds and then it is quiet. The commandline that I use: > cd /export/bonnie/ > ls -l total 43812978 -rw------- 1 jhay jhay 34359738368 Oct 5 20:06 Bonnie.20252 -rw-r--r-- 1 jhay jhay 10485760000 Oct 5 20:20 tst.dd > dd if=tst.dd of=/dev/null bs=64k ^T load: 0.98 cmd: dd 1391 [zio->io_cv)] 17.77r 0.00u 0.88s 0% 880k ^T load: 0.00 cmd: dd 1391 [zio->io_cv)] 4473.68r 0.00u 0.88s 0% 880k thumper1# procstat -k 1391 PID TID COMM TDNAME KSTACK 1391 100205 dd - mi_switch sleepq_wait _cv_wait zio_wait dmu_buf_hold_array_by_dnode dmu_buf_hold_array dmu_read_uio zfs_freebsd_read vn_read dofileread kern_readv read syscall Xfast_syscall thumper1# thumper1# zfs list NAME USED AVAIL REFER MOUNTPOINT dam 12.9G 436G 21K none dam/ROOT 12.9G 436G 21K legacy dam/ROOT/amd64 12.9G 436G 12.9G legacy dam/tmp 22.2M 436G 22.2M /tmp dam/usr_local 2.19M 436G 2.19M /usr/local dam/var 10.4M 436G 10.4M /var meer 41.8G 13.2T 44.8K none meer/export 41.8G 13.2T 41.8G /export thumper1# zpool status pool: dam state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM dam ONLINE 0 0 0 mirror ONLINE 0 0 0 gptid/3c3167d3-cc45-11df-b85d-00144f211378 ONLINE 0 0 0 gptid/3c6eeb97-cc45-11df-b85d-00144f211378 ONLINE 0 0 0 errors: No known data errors pool: meer state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM meer ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/6e4ae922-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6e647dae-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6e7c905b-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6e961440-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6ed0304d-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6ee9d7cb-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6f0341a4-d067-11df-bc29-00144f211378 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/6f1fbb2b-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6f3530cc-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6f4f7635-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6f6342f8-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6f78bd12-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6f8ec2d0-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6fa35b89-d067-11df-bc29-00144f211378 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/6fd319f7-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/6fefa464-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/70084d1a-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/70225bd7-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/703b892d-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/705649a0-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/706f0a93-d067-11df-bc29-00144f211378 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/7087f6c9-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/70a04cca-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/70bbdc2d-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/70d4b6ed-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/70eabeba-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/7100fc20-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/71165baa-d067-11df-bc29-00144f211378 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/716a084d-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/71853bf5-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/719e0201-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/71b74306-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/71d1c11d-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/71ea1b93-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/7203c8d9-d067-11df-bc29-00144f211378 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gptid/721b5a67-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/723a30d3-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/7256a502-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/72707600-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/7289edd1-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/72a21a0f-d067-11df-bc29-00144f211378 ONLINE 0 0 0 gptid/72be2559-d067-11df-bc29-00144f211378 ONLINE 0 0 0 spares gptid/6e378541-d067-11df-bc29-00144f211378 AVAIL gptid/6fb986d9-d067-11df-bc29-00144f211378 AVAIL gptid/712f8225-d067-11df-bc29-00144f211378 AVAIL gptid/72d70248-d067-11df-bc29-00144f211378 AVAIL errors: No known data errors thumper1# dmesg Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-STABLE #0: Thu Oct 7 10:43:27 UTC 2010 jhay@thumper1:/usr/obj/usr/src/sys/THUMPER1 amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 285 (2592.63-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Family = f Model = 21 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 real memory = 17179869184 (16384 MB) avail memory = 16476504064 (15713 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-30 on motherboard ioapic2 irqs 31-37 on motherboard ioapic3 irqs 38-44 on motherboard ioapic4 irqs 45-51 on motherboard ioapic5 irqs 52-58 on motherboard ioapic6 irqs 59-65 on motherboard ioapic7 irqs 66-72 on motherboard ioapic8 irqs 73-79 on motherboard ioapic9 irqs 80-86 on motherboard ioapic10 irqs 87-93 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f9f00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 atapci0: port 0x7c00-0x7cff mem 0xfae00000-0xfaefffff irq 24 at device 1.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ata8: on atapci0 ata8: [ITHREAD] ata9: on atapci0 ata9: [ITHREAD] pcib2: at device 2.0 on pci0 pci2: on pcib2 atapci1: port 0x8c00-0x8cff mem 0xfb000000-0xfb0fffff irq 32 at device 1.0 on pci2 atapci1: [ITHREAD] ata10: on atapci1 ata10: [ITHREAD] ata11: on atapci1 ata11: [ITHREAD] ata12: on atapci1 ata12: [ITHREAD] ata13: on atapci1 ata13: [ITHREAD] ata14: on atapci1 ata14: [ITHREAD] ata15: on atapci1 ata15: [ITHREAD] ata16: on atapci1 ata16: [ITHREAD] ata17: on atapci1 ata17: [ITHREAD] pcib3: at device 6.0 on pci0 pci3: on pcib3 ohci0: mem 0xfd1fe000-0xfd1fefff irq 19 at device 0.0 on pci3 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfd1fd000-0xfd1fdfff irq 19 at device 0.1 on pci3 ohci1: [ITHREAD] usbus1: on ohci1 vgapci0: port 0x9800-0x98ff mem 0xfc000000-0xfcffffff,0xfd1ff000-0xfd1fffff irq 16 at device 3.0 on pci3 ohci2: mem 0xfd1fc000-0xfd1fcfff irq 17 at device 4.0 on pci3 ohci2: [ITHREAD] usbus2: on ohci2 ohci3: mem 0xfd1fb000-0xfd1fbfff irq 18 at device 4.1 on pci3 ohci3: [ITHREAD] usbus3: on ohci3 ehci0: mem 0xfd1fac00-0xfd1facff irq 19 at device 4.2 on pci3 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0 ata0: on atapci2 ata0: [ITHREAD] ata1: on atapci2 ata1: [ITHREAD] pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pcib4: on acpi0 pci4: on pcib4 pcib5: at device 3.0 on pci4 pci5: on pcib5 atapci3: port 0xac00-0xacff mem 0xfd700000-0xfd7fffff irq 38 at device 1.0 on pci5 atapci3: [ITHREAD] ata18: on atapci3 ata18: [ITHREAD] ata19: on atapci3 ata19: [ITHREAD] ata20: on atapci3 ata20: [ITHREAD] ata21: on atapci3 ata21: [ITHREAD] ata22: on atapci3 ata22: [ITHREAD] ata23: on atapci3 ata23: [ITHREAD] ata24: on atapci3 ata24: [ITHREAD] ata25: on atapci3 ata25: [ITHREAD] pcib6: at device 4.0 on pci4 pci6: on pcib6 atapci4: port 0xbc00-0xbcff mem 0xfd900000-0xfd9fffff irq 46 at device 1.0 on pci6 atapci4: [ITHREAD] ata26: on atapci4 ata26: [ITHREAD] ata27: on atapci4 ata27: [ITHREAD] ata28: on atapci4 ata28: [ITHREAD] ata29: on atapci4 ata29: [ITHREAD] ata30: on atapci4 ata30: [ITHREAD] ata31: on atapci4 ata31: [ITHREAD] ata32: on atapci4 ata32: [ITHREAD] ata33: on atapci4 ata33: [ITHREAD] pcib7: at device 5.0 on pci4 pci7: on pcib7 em0: port 0xcc00-0xcc3f mem 0xfdae0000-0xfdafffff irq 52 at device 1.0 on pci7 em0: [FILTER] em0: Ethernet address: 00:14:4f:21:13:78 em1: port 0xc800-0xc83f mem 0xfdac0000-0xfdadffff irq 53 at device 1.1 on pci7 em1: [FILTER] em1: Ethernet address: 00:14:4f:21:13:79 pcib8: at device 6.0 on pci4 pci8: on pcib8 em2: port 0xdc00-0xdc3f mem 0xfdbe0000-0xfdbfffff irq 61 at device 1.0 on pci8 em2: [FILTER] em2: Ethernet address: 00:14:4f:21:13:7a em3: port 0xd800-0xd83f mem 0xfdbc0000-0xfdbdffff irq 62 at device 1.1 on pci8 em3: [FILTER] em3: Ethernet address: 00:14:4f:21:13:7b pcib9: on acpi0 pci12: on pcib9 pcib10: at device 9.0 on pci12 pci13: on pcib10 pcib11: at device 10.0 on pci12 pci14: on pcib11 pcib12: on acpi0 pci9: on pcib12 pcib13: at device 7.0 on pci9 pci10: on pcib13 atapci5: port 0xec00-0xecff mem 0xfe300000-0xfe3fffff irq 68 at device 1.0 on pci10 atapci5: [ITHREAD] ata34: on atapci5 ata34: [ITHREAD] ata35: on atapci5 ata35: [ITHREAD] ata36: on atapci5 ata36: [ITHREAD] ata37: on atapci5 ata37: [ITHREAD] ata38: on atapci5 ata38: [ITHREAD] ata39: on atapci5 ata39: [ITHREAD] ata40: on atapci5 ata40: [ITHREAD] ata41: on atapci5 ata41: [ITHREAD] pcib14: at device 8.0 on pci9 pci11: on pcib14 atapci6: port 0xfc00-0xfcff mem 0xfe500000-0xfe5fffff irq 76 at device 1.0 on pci11 atapci6: [ITHREAD] ata42: on atapci6 ata42: [ITHREAD] ata43: on atapci6 ata43: [ITHREAD] ata44: on atapci6 ata44: [ITHREAD] ata45: on atapci6 ata45: [ITHREAD] ata46: on atapci6 ata46: [ITHREAD] ata47: on atapci6 ata47: [ITHREAD] ata48: on atapci6 ata48: [ITHREAD] ata49: on atapci6 ata49: [ITHREAD] acpi_button0: on acpi0 atrtc0: port 0x70-0x71 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] acpi_hpet0: iomem 0xfec01000-0xfec013ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 orm0: at iomem 0xc0000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xd57ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range powernow0: on cpu0 powernow1: on cpu1 powernow2: on cpu2 powernow3: on cpu3 ZFS filesystem version 4 ZFS storage pool version 15 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ad4: 476940MB at ata2-master UDMA100 SATA 3Gb/s ad6: 476940MB at ata3-master UDMA100 SATA 3Gb/s ad8: 476940MB at ata4-master UDMA100 SATA 3Gb/s ad10: 476940MB at ata5-master UDMA100 SATA 3Gb/s ad12: 476940MB at ata6-master UDMA100 SATA 3Gb/s ad14: 476940MB at ata7-master UDMA100 SATA 3Gb/s uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered ad16: 476940MB at ata8-master UDMA100 SATA 3Gb/s uhub3: 2 ports with 2 removable, self powered ad18: 476940MB at ata9-master UDMA100 SATA 3Gb/s ad20: 476940MB at ata10-master UDMA100 SATA 3Gb/s uhub2: 3 ports with 3 removable, self powered ad22: 476940MB at ata11-master UDMA100 SATA 3Gb/s ad24: 476940MB at ata12-master UDMA100 SATA 3Gb/s ad26: 476940MB at ata13-master UDMA100 SATA 3Gb/s ad28: 476940MB at ata14-master UDMA100 SATA 3Gb/s ad30: 476940MB at ata15-master UDMA100 SATA 3Gb/s ad32: 476940MB at ata16-master UDMA100 SATA 3Gb/s ad34: 476940MB at ata17-master UDMA100 SATA 3Gb/s ad36: 476940MB at ata18-master UDMA100 SATA 3Gb/s ad38: 476940MB at ata19-master UDMA100 SATA 3Gb/s ad40: 476940MB at ata20-master UDMA100 SATA 3Gb/s ad42: 476940MB at ata21-master UDMA100 SATA 3Gb/s ad44: 476940MB at ata22-master UDMA100 SATA 3Gb/s ad46: 476940MB at ata23-master UDMA100 SATA 3Gb/s ad48: 476940MB at ata24-master UDMA100 SATA 3Gb/s ad50: 476940MB at ata25-master UDMA100 SATA 3Gb/s ad52: 476940MB at ata26-master UDMA100 SATA 3Gb/s ad54: 476940MB at ata27-master UDMA100 SATA 3Gb/s ad56: 476940MB at ata28-master UDMA100 SATA 3Gb/s ad58: 476940MB at ata29-master UDMA100 SATA 3Gb/s ad60: 476940MB at ata30-master UDMA100 SATA 3Gb/s ad62: 476940MB at ata31-master UDMA100 SATA 3Gb/s ad64: 476940MB at ata32-master UDMA100 SATA 3Gb/s ad66: 476940MB at ata33-master UDMA100 SATA 3Gb/s ad68: 476940MB at ata34-master UDMA100 SATA 3Gb/s ad70: 476940MB at ata35-master UDMA100 SATA 3Gb/s ad72: 476940MB at ata36-master UDMA100 SATA 3Gb/s ad74: 476940MB at ata37-master UDMA100 SATA 3Gb/s ad76: 476940MB at ata38-master UDMA100 SATA 3Gb/s ad78: 476940MB at ata39-master UDMA100 SATA 3Gb/s ad80: 476940MB at ata40-master UDMA100 SATA 3Gb/s ad82: 476940MB at ata41-master UDMA100 SATA 3Gb/s ad84: 476940MB at ata42-master UDMA100 SATA 3Gb/s ugen0.2: at usbus0 ukbd0: on usbus0 ad86: 476940MB at ata43-master UDMA100 SATA 3Gb/s kbd2 at ukbd0 ums0: on usbus0 ums0: 3 buttons and [XY] coordinates ID=0 ad88: 476940MB at ata44-master UDMA100 SATA 3Gb/s ad90: 476940MB at ata45-master UDMA100 SATA 3Gb/s ad92: 476940MB at ata46-master UDMA100 SATA 3Gb/s ad94: 476940MB at ata47-master UDMA100 SATA 3Gb/s ad96: 476940MB at ata48-master UDMA100 SATA 3Gb/s ad98: 476940MB at ata49-master UDMA100 SATA 3Gb/s SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Root mount waiting for: usbus4 uhub4: 5 ports with 5 removable, self powered ugen4.2: at usbus4 uhub5: on usbus4 Root mount waiting for: usbus4 uhub5: 4 ports with 4 removable, self powered ugen4.3: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 umass0:0:0:-1: Attached to scbus0 Trying to mount root from zfs:dam/ROOT/amd64 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7636MB (15638528 512 byte sectors: 255H 63S/T 973C) em0: link state changed to UP lagg0: link state changed to UP lagg0.6: link state changed to UP em2: link state changed to UP em1: link state changed to UP em3: link state changed to UP thumper1# glabel status Name Status Components gptid/6e378541-d067-11df-bc29-00144f211378 N/A ad4p1 gptid/6e4ae922-d067-11df-bc29-00144f211378 N/A ad6p1 gptid/6e647dae-d067-11df-bc29-00144f211378 N/A ad8p1 gptid/6e7c905b-d067-11df-bc29-00144f211378 N/A ad10p1 gptid/6e961440-d067-11df-bc29-00144f211378 N/A ad12p1 gptid/6ed0304d-d067-11df-bc29-00144f211378 N/A ad14p1 gptid/6ee9d7cb-d067-11df-bc29-00144f211378 N/A ad16p1 gptid/6f0341a4-d067-11df-bc29-00144f211378 N/A ad18p1 gptid/6f1fbb2b-d067-11df-bc29-00144f211378 N/A ad20p1 gptid/6f3530cc-d067-11df-bc29-00144f211378 N/A ad22p1 gptid/6f4f7635-d067-11df-bc29-00144f211378 N/A ad24p1 gptid/6f6342f8-d067-11df-bc29-00144f211378 N/A ad26p1 gptid/6f78bd12-d067-11df-bc29-00144f211378 N/A ad28p1 gptid/6f8ec2d0-d067-11df-bc29-00144f211378 N/A ad30p1 gptid/6fa35b89-d067-11df-bc29-00144f211378 N/A ad32p1 gptid/6fb986d9-d067-11df-bc29-00144f211378 N/A ad34p1 gptid/6fd319f7-d067-11df-bc29-00144f211378 N/A ad36p1 gptid/6fefa464-d067-11df-bc29-00144f211378 N/A ad38p1 gptid/70084d1a-d067-11df-bc29-00144f211378 N/A ad40p1 gptid/70225bd7-d067-11df-bc29-00144f211378 N/A ad42p1 gptid/703b892d-d067-11df-bc29-00144f211378 N/A ad44p1 gptid/705649a0-d067-11df-bc29-00144f211378 N/A ad46p1 gptid/706f0a93-d067-11df-bc29-00144f211378 N/A ad48p1 gptid/7087f6c9-d067-11df-bc29-00144f211378 N/A ad50p1 gptid/3c0ebfcf-cc45-11df-b85d-00144f211378 N/A ad52p1 gptid/3c3167d3-cc45-11df-b85d-00144f211378 N/A ad52p3 gptid/70a04cca-d067-11df-bc29-00144f211378 N/A ad54p1 gptid/70bbdc2d-d067-11df-bc29-00144f211378 N/A ad56p1 gptid/70d4b6ed-d067-11df-bc29-00144f211378 N/A ad58p1 gptid/3c4c7865-cc45-11df-b85d-00144f211378 N/A ad60p1 gptid/3c635efe-cc45-11df-b85d-00144f211378 N/A ad60p2 gptid/3c6eeb97-cc45-11df-b85d-00144f211378 N/A ad60p3 gptid/70eabeba-d067-11df-bc29-00144f211378 N/A ad62p1 gptid/7100fc20-d067-11df-bc29-00144f211378 N/A ad64p1 gptid/71165baa-d067-11df-bc29-00144f211378 N/A ad66p1 gptid/712f8225-d067-11df-bc29-00144f211378 N/A ad68p1 gptid/716a084d-d067-11df-bc29-00144f211378 N/A ad70p1 gptid/71853bf5-d067-11df-bc29-00144f211378 N/A ad72p1 gptid/719e0201-d067-11df-bc29-00144f211378 N/A ad74p1 gptid/71b74306-d067-11df-bc29-00144f211378 N/A ad76p1 gptid/71d1c11d-d067-11df-bc29-00144f211378 N/A ad78p1 gptid/71ea1b93-d067-11df-bc29-00144f211378 N/A ad80p1 gptid/7203c8d9-d067-11df-bc29-00144f211378 N/A ad82p1 gptid/721b5a67-d067-11df-bc29-00144f211378 N/A ad84p1 gptid/723a30d3-d067-11df-bc29-00144f211378 N/A ad86p1 gptid/7256a502-d067-11df-bc29-00144f211378 N/A ad88p1 gptid/72707600-d067-11df-bc29-00144f211378 N/A ad90p1 gptid/7289edd1-d067-11df-bc29-00144f211378 N/A ad92p1 gptid/72a21a0f-d067-11df-bc29-00144f211378 N/A ad94p1 gptid/72be2559-d067-11df-bc29-00144f211378 N/A ad96p1 gptid/72d70248-d067-11df-bc29-00144f211378 N/A ad98p1 ufsid/49a828ef1a6a2de8 N/A da0s1a ufs/flash1 N/A da0s1a ufsid/49a8c69e60e10953 N/A da0s2a ufs/flash2 N/A da0s2a ufsid/49b383f54383bf0d N/A da0s3a ufs/flash3 N/A da0s3a ufsid/49b383fca9c7233b N/A da0s4a ufs/flash4 N/A da0s4a thumper1# vmstat -i interrupt total rate irq17: ohci2 451815 98 irq18: ohci3 167391 36 irq19: ohci0 ohci1+ 137556 30 irq24: atapci0 19644 4 irq32: atapci1 15102 3 irq38: atapci3 19532 4 irq46: atapci4 23575 5 irq52: em0 452 0 irq53: em1 7582 1 irq61: em2 2319 0 irq62: em3 1427 0 irq68: atapci5 17632 3 irq76: atapci6 18112 3 cpu0: timer 9133048 1999 cpu1: timer 9126434 1998 cpu2: timer 9130320 1999 cpu3: timer 9130448 1999 Total 37402389 8189 John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 12:35:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 149AE1065674 for ; Thu, 7 Oct 2010 12:35:29 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BED6C8FC1A for ; Thu, 7 Oct 2010 12:35:28 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P3ph1-0007sj-Lb for freebsd-stable@freebsd.org; Thu, 07 Oct 2010 14:35:27 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2010 14:35:27 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2010 14:35:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 07 Oct 2010 14:35:31 +0200 Lines: 19 Message-ID: References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <20101007121558.GA70199@zibbi.meraka.csir.co.za> X-Enigmail-Version: 1.0.1 Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 12:35:29 -0000 On 10/07/10 14:15, John Hay wrote: > Hi, > > I got hold of a SunFire X4500 with 48 X 500G disks and thought to try > FreeBSD 8-stable with zfs on it. > > I have setup the two boot disks in a zfs mirror and then the rest in > a pool of 6 X raidz2 of 7 disks each. > > I have created a 10G file with dd in the second pool, but if I try to read > it with dd, dd will hang in "zio->io_cv)" according to ^T. This happens > everytime. The first time I saw messages about an interrupt storm, so I > have put "hw.intr_storm_threshold=10000" in /etc/sysctl.conf. According to > "systat -vm 1" there is atapci for 2-3 seconds and then it is quiet. There are two things you could try: 1) use the AHCI driver (ahci_load="YES" in /boot/loader.conf) and 2) disable superpages, they don't get along on a few models of Opterons (vm.pmap.pg_ps_enabled=0 in /boot/loader.conf). From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 13:01:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405B91065A2B for ; Thu, 7 Oct 2010 13:01:56 +0000 (UTC) (envelope-from 1wkmmr@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12F3B8FC16 for ; Thu, 7 Oct 2010 13:01:56 +0000 (UTC) Received: by pvc21 with SMTP id 21so145269pvc.13 for ; Thu, 07 Oct 2010 06:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=t6vvDGAYRtvnOgYs35Vacoe0MDCriBphvx4bT0oC+Vc=; b=CzzD2n0ABuPccxY4ohL88vjthKoOgy23IUWNRWOqYjN5WqBzLKyiBTZcckUTIC0L1K V3y2QFLVuojJWGdmBGqYqV36SlJebBP8E7v0NPWZ/IapvwRWUf4nxgS0S5FkgkNjXWb/ 9dQkYfexhsWMJlPECo2tcJubLgiGEW4/l9G0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=jyB2VrVeVF4X0HdU6otb8hDN0CKbvtBcXVceL9VQ4Mb1BX9l8Vh6q7y4Gv3t8933iZ FKxJJJ8bVdjCb2MlYbiklHgGrP4WqUfwUaX6rnQALsT9Hcn2iBWA9c/Ab+M48iVMkDn2 chfRjGWZ9p4hidnrHAiBQfzMp/CRTA2aTebtg= Received: by 10.114.160.2 with SMTP id i2mr717940wae.110.1286455094113; Thu, 07 Oct 2010 05:38:14 -0700 (PDT) Received: from [192.168.0.124] (tf-bsp03.eng.niigata-u.ac.jp [133.35.85.3]) by mx.google.com with ESMTPS id s5sm3359689wak.0.2010.10.07.05.38.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 07 Oct 2010 05:38:13 -0700 (PDT) Message-ID: <4CADBF20.1040000@gmail.com> Date: Thu, 07 Oct 2010 21:37:52 +0900 From: Mamoru Iwaki <1wkmmr@gmail.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Oct 2010 13:09:19 +0000 Subject: How dhcp client can set its hostname properly on lease time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:01:56 -0000 Hi, I'm using FreeBSD 8 stable as of 20101006. It is a dhcp client in a private local network, and xorg staff is installed. When I tried to use it from a remote pc with X11-forwarding set, xauth failed to set up .Xauthority as follows. /usr/local/bin/xauth: creating new authority file /home/hogehoge/.Xauthority /usr/local/bin/xauth: (stdin):1: bad display name "unix:10.0" in "remove" command /usr/local/bin/xauth: (stdin):2: bad display name "unix:10.0" in "add" command At this moment, hostname was not set (it's empty) because the FreeBSD box was a dhcp client. Meanwhile, if the hostname coresponding to the ip-address assigned by dhcp server was set manually, the above lines disappeared and X11-forwarding worked well. Now, my question is Are there good way for dhcp client to set its hostname properly on lease time? The following will be a possble workaround, but I'm wondering there can be a smart answer in FreeBSD itself. It is possible to resolve the hostname corresponding to a dhcp-delivered ip-address with a local name server. So, (1) resolve the corresponding hostname from the local name server, (2) set it as hostname, and (3) call them every time when dhcp lease is updated Cheers -- ----- Mamoru IWAKI Grad. Schl. Sci & Tech./Dept. Biocybernetics, Niigata University From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 13:43:39 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D5871065672 for ; Thu, 7 Oct 2010 13:43:39 +0000 (UTC) (envelope-from news@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by mx1.freebsd.org (Postfix) with ESMTP id 72C738FC08 for ; Thu, 7 Oct 2010 13:43:37 +0000 (UTC) Received: from uucp.dinoex.sub.de (uucp@uucp.dinoex.sub.de [194.45.71.2] (may be forged)) by uucp.dinoex.sub.de (8.14.4/8.14.4) with ESMTP id o97DD69V097865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Oct 2010 15:13:06 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.14.4/8.14.4/Submit) with UUCP id o97DD6YS097864 for freebsd-stable@FreeBSD.ORG; Thu, 7 Oct 2010 15:13:06 +0200 (CEST) (envelope-from news@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.14.3/8.14.3) with ESMTP id o97D6gFd099779 for ; Thu, 7 Oct 2010 15:06:42 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.14.3/8.14.3) with ESMTP id o97D43JV099471 for ; Thu, 7 Oct 2010 15:04:04 +0200 (CEST) (envelope-from news@gate.oper.dinoex.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.14.3/8.14.3/Submit) id o97D43um099462 for freebsd-stable@FreeBSD.ORG; Thu, 7 Oct 2010 15:04:03 +0200 (CEST) (envelope-from news) From: pmc@citylink.dinoex.sub.org (Peter Much) Message-ID: Date: Thu, 7 Oct 2010 12:35:01 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> Mime-Version: 1.0 Organization: dread of the bookshelf X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (uucp.dinoex.sub.de [194.45.71.2]); Thu, 07 Oct 2010 15:13:07 +0200 (CEST) Cc: Subject: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:43:39 -0000 aka Vadim Goncharov schrieb mit Datum Wed, 08 Sep 2010 04:31:46 +0700 in m2n.fbsd.stable: |You do not understand the problem. It is not in notices & volunteers, but |rather in the Project's policy - delete something which could still work. |Personally, I don't use ISDN, so didn't said anything that time, but now, Hi all, at this point I would like to speak up, because I am practically using ISDN4BSD. I just decided to upgrade to RELENG-8, and found out that I cannot. So now I have 1 1/2 years (until 7.3 EOL) to figure out a solution. I will not complain, because I think people here do an incredible good work, and the only very small thing I can contribute is occasional bug reports and sometimes patches. But what I want to say is: It is *NOT TRUE* that the I4B feature has become of limited usefulness today! I am using I4B as an answering machine for my phone-line, with the feature to monitor these calls and to download them as MP3 from anywhere in the world (could even be a web-interface, but I hadn't yet the time to write that). I don't want everybody to know my cellular nr; I don't want to (costly) forward calls to my cellular; but I want to be able to monitor and react on calls nevertheless! This is very easy and very comfortable - and currently I have no idea which other equipment could provide me with such functionality (if any would exist at all). And - my router is running anyway, it doesn't consume extra power when doing this - in fact, I think this is one of the most useful things one can do with a computer that is kept running all the time... So, I am sure my demand for this functionality will continue to exist for an indefinite time into the future, and in fact I am sad. To be honest, I am quite clueless now. Theoretically I do understand the problem with I4B. (Practically I do not understand it, because for me it has nothing to do with networking - I do only use the phone call monitoring/handling.) But staying with 7.3 will cut me off from other improvements/fixes, which I would much enjoy. Anyway, there is another open issue for me: my ISDN adapter card is ISA technology, so I will have to get a PCI type card as soon as I replace the mainboard of that system (which is imminent because it's too slow and too power-consuming - the ISDN being the main reason why I didnt do that already). But maybe, now I should look for some completely different approach? Any clues, ideas, pointers, hints, ressources,... are greatly welcomed!! rgds, PMc From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 13:58:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 314B7106566C for ; Thu, 7 Oct 2010 13:58:24 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DAC938FC2B for ; Thu, 7 Oct 2010 13:58:23 +0000 (UTC) Received: by qwb7 with SMTP id 7so56502qwb.13 for ; Thu, 07 Oct 2010 06:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VApOePAbBHf5wHSpAablryanHgKAzySaHjVvjZOlVKM=; b=jZW0BKsGISRTwwpDMqpUkdVGvQvBFW6GYAyWQ6A4/LzFMyrSWsGcfw8RN+bI1nx43+ LWrxXkXUT88v0ksHPd9mRmO/lyAfUtceYlVRtZ5OGig+UW04i0lQe81Q46gqtci00451 LuzOaqUGNrvVaLX5JU4pVOYWQwzpOFSwKQkSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OwUV7KE7k5HN0OYRhWMjDj6aqs7hrobRxjjKcVhRx6GBfOLSbDbwW7G3gDk9grY2U1 /o6bqJo5VjHrHUIvVs8b/iLwtjSdWyCXv3J1FQ62ae1i3erI5aP2eADKvDu/MUm5cztZ keAjsCobP5Cyhs8ONhr6SYzb4VxSpEo3/uNbc= MIME-Version: 1.0 Received: by 10.229.236.132 with SMTP id kk4mr788583qcb.116.1286459903128; Thu, 07 Oct 2010 06:58:23 -0700 (PDT) Received: by 10.229.187.130 with HTTP; Thu, 7 Oct 2010 06:58:23 -0700 (PDT) In-Reply-To: References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> Date: Thu, 7 Oct 2010 14:58:23 +0100 Message-ID: From: Tom Evans To: Peter Much Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 13:58:24 -0000 On Thu, Oct 7, 2010 at 1:35 PM, Peter Much wrote: > aka Vadim Goncharov schrieb > mit Datum Wed, 08 Sep 2010 04:31:46 +0700 in m2n.fbsd.stable: > > |You do not understand the problem. It is not in notices & volunteers, but > |rather in the Project's policy - delete something which could still work. > |Personally, I don't use ISDN, so didn't said anything that time, but now, > > Hi all, > > at this point I would like to speak up, because I am practically > using ISDN4BSD. > > I just decided to upgrade to RELENG-8, and found out that I cannot. > So now I have 1 1/2 years (until 7.3 EOL) to figure out a solution. > http://www.selasky.org/hans_petter/isdn4bsd/ HTH Tom From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 14:16:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A9F106566C for ; Thu, 7 Oct 2010 14:16:50 +0000 (UTC) (envelope-from kurt.lidl@cello.com) Received: from Mail.Fairview-Park.Com (Mail.Fairview-Park.Com [98.141.206.6]) by mx1.freebsd.org (Postfix) with ESMTP id EBEE68FC19 for ; Thu, 7 Oct 2010 14:16:49 +0000 (UTC) Received: from [192.168.8.101] (Kurt.Fairview-Park.Com [192.168.8.101]) (authenticated bits=0) by Mail.Fairview-Park.Com (8.14.4/8.14.4) with ESMTP id o97E4kBj028497 for ; Thu, 7 Oct 2010 10:04:46 -0400 (EDT) (envelope-from kurt.lidl@cello.com) X-FVP-rcvd: Kurt.Fairview-Park.Com [192.168.8.101] Thu, 7 Oct 2010 10:04:46 -0400 (EDT) Message-ID: <4CADD379.8010806@cello.com> Date: Thu, 07 Oct 2010 10:04:41 -0400 From: Kurt Lidl Organization: Cello Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.3 at Mail.Fairview-Park.Com X-Virus-Status: Clean Subject: How dhcp client can set its hostname properly on lease time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:16:50 -0000 Regarding your posting to freebsd-stable. Probably what you want to do is have the DHCP server send the machine name when it offers a lease to the client. -Kurt From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 15:14:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70EC9106566B for ; Thu, 7 Oct 2010 15:14:49 +0000 (UTC) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.freebsd.org (Postfix) with SMTP id D5ADC8FC1D for ; Thu, 7 Oct 2010 15:14:48 +0000 (UTC) Received: (qmail 65618 invoked by uid 1001); 7 Oct 2010 15:14:46 -0000 Date: Thu, 7 Oct 2010 11:14:46 -0400 From: Brian Reichert To: Mamoru Iwaki <1wkmmr@gmail.com> Message-ID: <20101007151446.GH67344@numachi.com> References: <4CADBF20.1040000@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CADBF20.1040000@gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org Subject: Re: How dhcp client can set its hostname properly on lease time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 15:14:49 -0000 On Thu, Oct 07, 2010 at 09:37:52PM +0900, Mamoru Iwaki wrote: > Now, my question is > > Are there good way for dhcp client to set its hostname properly on lease > time? Depends on 'properly'. I've hacked dhclient exit scripts to synthesize a hostname, if one was not offered by the DHCP server. The host, under these circumstances, gets a hostname derived from the IP address and the supplied domain name, eg: '10-12-34-56.example.com'. This at least gets the box into a place where it has a hostname associated with the address on an external interface. No one else knows that hostname, however. YMMV. > > Cheers > > -- > ----- > Mamoru IWAKI > Grad. Schl. Sci & Tech./Dept. Biocybernetics, Niigata University -- Brian Reichert 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 15:50:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F116710656B3 for ; Thu, 7 Oct 2010 15:50:45 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id E20EB8FC36 for ; Thu, 7 Oct 2010 15:50:44 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 2D17D39822; Thu, 7 Oct 2010 17:50:42 +0200 (SAST) Date: Thu, 7 Oct 2010 17:50:42 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20101007155042.GA88362@zibbi.meraka.csir.co.za> References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 15:50:46 -0000 On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote: > On 10/07/10 14:15, John Hay wrote: > >Hi, > > > >I got hold of a SunFire X4500 with 48 X 500G disks and thought to try > >FreeBSD 8-stable with zfs on it. > > > >I have setup the two boot disks in a zfs mirror and then the rest in > >a pool of 6 X raidz2 of 7 disks each. > > > >I have created a 10G file with dd in the second pool, but if I try to read > >it with dd, dd will hang in "zio->io_cv)" according to ^T. This happens > >everytime. The first time I saw messages about an interrupt storm, so I > >have put "hw.intr_storm_threshold=10000" in /etc/sysctl.conf. According to > >"systat -vm 1" there is atapci for 2-3 seconds and then it is quiet. > > There are two things you could try: 1) use the AHCI driver > (ahci_load="YES" in /boot/loader.conf) and 2) disable superpages, they > don't get along on a few models of Opterons (vm.pmap.pg_ps_enabled=0 in > /boot/loader.conf). ahci does not grab them. According to the ahci man page, it can handle Marvell 88SX61xx, while these are MV88SX6081 according to pciconf -lcv: atapci0@pci0:1:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X Controller' class = mass storage subclass = SCSI cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 4 split transactions I have also set vm.pmap.pg_ps_enabled=0 in loader.conf, but that did not make a difference either. :-( Once dd hang in that "zio->io_cv)" state the rest of the machine is ok and everything works as long as you stay away from the directory where the file is that you dd from. There are no messages in dmesg or /var/log/messages. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 16:04:50 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD360106566B for ; Thu, 7 Oct 2010 16:04:50 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B6A5E8FC0A for ; Thu, 7 Oct 2010 16:04:50 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o97G4B96019315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Oct 2010 09:04:11 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3E27A1CC3E; Thu, 7 Oct 2010 09:04:11 -0700 (PDT) To: pmc@citylink.dinoex.sub.org (Peter Much) In-reply-to: Your message of "Thu, 07 Oct 2010 12:35:01 GMT." Date: Thu, 07 Oct 2010 09:04:11 -0700 From: "Kevin Oberman" Message-Id: <20101007160411.3E27A1CC3E@ptavv.es.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:04:51 -0000 > From: pmc@citylink.dinoex.sub.org (Peter Much) > Date: Thu, 7 Oct 2010 12:35:01 GMT > Sender: owner-freebsd-stable@freebsd.org > > aka Vadim Goncharov schrieb > mit Datum Wed, 08 Sep 2010 04:31:46 +0700 in m2n.fbsd.stable: > > |You do not understand the problem. It is not in notices & volunteers, but > |rather in the Project's policy - delete something which could still work. > |Personally, I don't use ISDN, so didn't said anything that time, but now, > > Hi all, > > at this point I would like to speak up, because I am practically > using ISDN4BSD. > > I just decided to upgrade to RELENG-8, and found out that I cannot. > So now I have 1 1/2 years (until 7.3 EOL) to figure out a solution. > > I will not complain, because I think people here do an incredible > good work, and the only very small thing I can contribute is > occasional bug reports and sometimes patches. > > But what I want to say is: > > It is *NOT TRUE* that the I4B feature has become of limited > usefulness today! > > I am using I4B as an answering machine for my phone-line, with > the feature to monitor these calls and to download them as MP3 > from anywhere in the world (could even be a web-interface, but > I hadn't yet the time to write that). > I don't want everybody to know my cellular nr; I don't want to > (costly) forward calls to my cellular; but I want to be able to > monitor and react on calls nevertheless! > > This is very easy and very comfortable - and currently I have no > idea which other equipment could provide me with such functionality > (if any would exist at all). And - my router is running anyway, > it doesn't consume extra power when doing this - in fact, I think > this is one of the most useful things one can do with a computer > that is kept running all the time... > > So, I am sure my demand for this functionality will continue to > exist for an indefinite time into the future, and in fact I > am sad. > > > To be honest, I am quite clueless now. Theoretically I do > understand the problem with I4B. (Practically I do not understand > it, because for me it has nothing to do with networking - I do > only use the phone call monitoring/handling.) > But staying with 7.3 will cut me off from other improvements/fixes, > which I would much enjoy. > > Anyway, there is another open issue for me: my ISDN adapter card > is ISA technology, so I will have to get a PCI type card as soon > as I replace the mainboard of that system (which is imminent because > it's too slow and too power-consuming - the ISDN being the main > reason why I didnt do that already). > > But maybe, now I should look for some completely different approach? > > Any clues, ideas, pointers, hints, ressources,... are greatly > welcomed!! Please understand that the removal of isdn4bsd has nothing to do with any belief that it was no longer being used. It was removed because it would not work with a modern kernel as it relied on a locking mechanism that could not be retained if the system was to remain relevant in the modern world. There were many calls, though they may have not reached all those with a vested interest in isdn4bsd, asking if anyone could re-work the code to remove giant locks. Due to the magnitude of the change to the kernel to support a non-giant locked world, there was simply no way to make support for giant a build time option. When no one stepped up to update isdn4bsd, there was really no choice but to remove it. Happily, HPS and taken the job and has an isdn4bsd driver that works on v8 and I hope to see it move back into the base system in the future. http://www.selasky.org/hans_petter/isdn4bsd/ -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 16:12:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A8EB106566C for ; Thu, 7 Oct 2010 16:12:56 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.freebsd.org (Postfix) with SMTP id BEEB08FC14 for ; Thu, 7 Oct 2010 16:12:55 +0000 (UTC) Received: (qmail 38569 invoked from network); 7 Oct 2010 15:46:15 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 08:46:15 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: i_UBIe8VM1kDflKCEmIFrkMjzKT1mMB39oxk_w1KIcuYxN8 vgAeqeLZFVzpinraiAL49qrTyLCljVAajFhIoYlopOOdv6s_it1gBI_bEhle A_949_Kon46wUupRQeJYsDKzGWngpRbZ9AoLBPDSUyzPM41jMDrI6zAtGKTB PgMt9xXjHIei3z4nVN_kpwFkQYcCN7IjiWQSlXCMkl3TWaMp_qJpoJbPaomq yFa6ilJmThkiWGQsV3LoG0DlTHWKQ2N2t141nMTDcpkBX9i2XhaZh_1nN12c idOoSJsvWzZ9rFE3jKF_sYHA3msxC63jB4cl9zTH5C7KLKwzyfb6xoJKr52c ktcgOM5jI7E5Z1iQqEq_asoredwjO3aCmtx9aySlwsICzCOOp4pVSWGfKvjA zoEE7prz6ZMeTfAjPPlBL8C7TnioBeAhl0OMFFHyqv7s- X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id C3B74AB7B; Thu, 7 Oct 2010 11:46:14 -0400 (EDT) To: "Richard Lee" , "Jeremy Chadwick" , "jhell" , "Andriy Gapon" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 07 Oct 2010 11:46:14 -0400 From: Andriy Bakay Message-ID: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:12:56 -0000 Hi All, Do we have any new information about this issue (fixes, work arounds etc.)? Any input will be highly useful. http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057682.html I am experiencing kind of same problem on FreeBSD 8.1-RELEASE-p1 i386 2G RAM. Thanks, Andriy From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 16:38:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2960106566B for ; Thu, 7 Oct 2010 16:38:00 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5DEBE8FC23 for ; Thu, 7 Oct 2010 16:38:00 +0000 (UTC) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by dkim.mail.arcticgroup.se (Postfix) with ESMTP id 2F38B1D008; Thu, 7 Oct 2010 18:19:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ismobile.com; h=date:from :to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=selector1; bh=3TZzhLY +wWPPoUC7c0zn4cgXVX0=; b=WpoB94ZascXl/dhZ+mjPEcG7S4j1uNLwnEzxOYI BOMLqf4iDGIDsNpelSzbJfPfSJuAXF1Nf/uCaxjl7QboT3LiBX/M16niQrv9i8Jy kUneF2tnV9+p6lD64g5CFqFzarjYZDPP8sZlgSvCy6g9Yf/EYPp+TSZvcdSiMD4i 5Cio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ismobile.com; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=selector1; b=J 3pNDh5ObRuVt+aRqyJfrDI0GLK806Ol6syNbIoP6tbuUUyHS9tPuxvlmKYYpnS5N UXn0ljdZZXQZ2o+qZm+plwdQQUJXnlwWCkj5zD/T3O8xbCqjuhiViS3i8lZofUHb VCvYFFU3N0a6qoJ6Z0lP9uOFeDnqm+PUbBmWbBU3qY= Received: from [172.16.2.182] (syn.hq.ismobile.com [172.16.2.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTPSA id 801211CDFE; Thu, 7 Oct 2010 18:19:48 +0200 (CEST) Date: Thu, 07 Oct 2010 18:19:48 +0200 From: Goran Lowkrantz To: John Hay , freebsd-stable@freebsd.org Message-ID: In-Reply-To: <20101007155042.GA88362@zibbi.meraka.csir.co.za> References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:38:01 -0000 --On October 7, 2010 17:50:42 +0200 John Hay wrote: > On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote: >> On 10/07/10 14:15, John Hay wrote: >> > Hi, >> > >> > I got hold of a SunFire X4500 with 48 X 500G disks and thought to try >> > FreeBSD 8-stable with zfs on it. >> > >> > I have setup the two boot disks in a zfs mirror and then the rest in >> > a pool of 6 X raidz2 of 7 disks each. >> > >> > I have created a 10G file with dd in the second pool, but if I try to >> > read it with dd, dd will hang in "zio->io_cv)" according to ^T. This >> > happens everytime. The first time I saw messages about an interrupt >> > storm, so I have put "hw.intr_storm_threshold=10000" in >> > /etc/sysctl.conf. According to "systat -vm 1" there is atapci for 2-3 >> > seconds and then it is quiet. >> >> There are two things you could try: 1) use the AHCI driver >> (ahci_load="YES" in /boot/loader.conf) and 2) disable superpages, they >> don't get along on a few models of Opterons (vm.pmap.pg_ps_enabled=0 in >> /boot/loader.conf). > > ahci does not grab them. According to the ahci man page, it can handle > Marvell 88SX61xx, while these are MV88SX6081 according to pciconf -lcv: > > atapci0@pci0:1:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo > Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X > Controller' > class = mass storage > subclass = SCSI > cap 01[40] = powerspec 2 supports D0 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 4 split > transactions Then try mvs_load="YES" mvs0@pci0:6:2:0: class=0x010000 card=0x11ab11ab chip=0x608111ab rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X Controller' class = mass storage subclass = SCSI mvs1@pci0:5:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X Controller' class = mass storage subclass = SCSI > > I have also set vm.pmap.pg_ps_enabled=0 in loader.conf, but that did not > make a difference either. :-( > > Once dd hang in that "zio->io_cv)" state the rest of the machine is ok > and everything works as long as you stay away from the directory where > the file is that you dd from. > > There are no messages in dmesg or /var/log/messages. > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" /glz From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 16:52:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F94D106566C; Thu, 7 Oct 2010 16:52:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4538FC0A; Thu, 7 Oct 2010 16:52:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17536; Thu, 07 Oct 2010 19:52:51 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CADFAE2.1090107@freebsd.org> Date: Thu, 07 Oct 2010 19:52:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-mobile@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: acpi_ec: request for review and testing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:52:54 -0000 FYI: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6440 If you can test and would like to report, please followup to that thread on acpi@ mailing list. Please do not followup to this post. Thanks! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 17:03:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D355B1065672 for ; Thu, 7 Oct 2010 17:03:30 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8118FC16 for ; Thu, 7 Oct 2010 17:03:30 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id B8E8D28F74E; Thu, 7 Oct 2010 12:03:29 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 9RDLGTXGkLi6; Thu, 7 Oct 2010 12:03:29 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 3C3A828F74A; Thu, 7 Oct 2010 12:03:28 -0500 (CDT) Message-ID: <4CADFD60.9040005@rice.edu> Date: Thu, 07 Oct 2010 12:03:28 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Kurt Alstrup References: <4CAC14DA.7050409@verizon.net> In-Reply-To: <4CAC14DA.7050409@verizon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:03:30 -0000 Kurt Alstrup wrote: > Up front disclaimer: I may very well be wrong on this.. > > At a high-level, I agree with much of what you say. In particular, if pmap_enter() is applied to a virtual address that is already mapped by a large page, the reported panic could result. However, barring bugs, for example, in memory allocation by the upper levels of the kernel, the panic inducing situation shouldn't occur. At a lower-level, it appears that you are misinterpreting what pmap_unuse_pt() does. It is not pmap_unuse_pt()'s responsibility to clear page table entries, either for user-space page tables or the kernel page table. When a region of the kernel virtual address space is deallocated, we do clear the kernel page table entries. See, for example, pmap_remove_pte() (or pmap_qremove()). The special case for the kernel page table in pmap_unuse_pt() has a different purpose. User-space page table pages are reference counted. When there are no longer any valid mappings contained in a user-space page table page, we remove that page from the page table and free it. However, for the kernel page table, we never free unused page table pages. Instead, they persist, but with all of their mappings marked invalid. In other words, the special case for the kernel page table in pmap_unuse_pt() is skipping the code that unmaps and frees the unused page table page. This special handling of the kernel page table does create another special case when we destroy a large page mapping within the kernel address space. We have to reinsert into the kernel page table the old page table page (for small page mappings) that was sitting idle while the kernel page table held a large page mapping in its place. At the same time, all of the page table entries in this page must be invalidated. This is handled by pmap_remove_pde(). I'm curious to know more about you were doing when you encountered this panic. Were you also using ISO images containing large MFS roots? Regards, Alan From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 17:31:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E24106564A for ; Thu, 7 Oct 2010 17:31:06 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6418FC14 for ; Thu, 7 Oct 2010 17:31:05 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id A25AC39822; Thu, 7 Oct 2010 19:31:02 +0200 (SAST) Date: Thu, 7 Oct 2010 19:31:02 +0200 From: John Hay To: freebsd-stable@freebsd.org Message-ID: <20101007173102.GA95405@zibbi.meraka.csir.co.za> References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:31:06 -0000 On Thu, Oct 07, 2010 at 06:19:48PM +0200, Goran Lowkrantz wrote: > --On October 7, 2010 17:50:42 +0200 John Hay wrote: > > >On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote: > >>On 10/07/10 14:15, John Hay wrote: > >>> Hi, > >>> > >>> I got hold of a SunFire X4500 with 48 X 500G disks and thought to try > >>> FreeBSD 8-stable with zfs on it. > >>> > >>> I have setup the two boot disks in a zfs mirror and then the rest in > >>> a pool of 6 X raidz2 of 7 disks each. > >>> > >>> I have created a 10G file with dd in the second pool, but if I try to > >>> read it with dd, dd will hang in "zio->io_cv)" according to ^T. This > >>> happens everytime. The first time I saw messages about an interrupt > >>> storm, so I have put "hw.intr_storm_threshold=10000" in > >>> /etc/sysctl.conf. According to "systat -vm 1" there is atapci for 2-3 > >>> seconds and then it is quiet. > >> > >>There are two things you could try: 1) use the AHCI driver > >>(ahci_load="YES" in /boot/loader.conf) and 2) disable superpages, they > >>don't get along on a few models of Opterons (vm.pmap.pg_ps_enabled=0 in > >>/boot/loader.conf). > > > >ahci does not grab them. According to the ahci man page, it can handle > >Marvell 88SX61xx, while these are MV88SX6081 according to pciconf -lcv: > > > >atapci0@pci0:1:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > >rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo > >Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X > >Controller' > > class = mass storage > > subclass = SCSI > > cap 01[40] = powerspec 2 supports D0 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 4 split > >transactions > > Then try mvs_load="YES" > > mvs0@pci0:6:2:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > rev=0x09 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'MV88SX6081 8-port SATA II PCI-X Controller' > class = mass storage > subclass = SCSI > mvs1@pci0:5:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > rev=0x09 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'MV88SX6081 8-port SATA II PCI-X Controller' > class = mass storage > subclass = SCSI That helped, thanks. Now the disks are detected as adaXX devices. The problem still happens though. I think it takes a little longer after I have started dd before it hangs, but it still hangs. One thing seems a little different though. Occasionaly a short burst of interrupts on the mvsX devices do come through. It also seems that a few seconds after I press ^T in the dd window, I see a burst of mvsX interrupts happen and dd will report in/out records and bytes. This did not happen with the ata driver. It is still hanging in "zio->io_cv)" though. I also see these messages in /var/log/messages Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 16 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 17 (->0) 1 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 18 (->0) 2 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 20 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 21 (->0) 1 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 22 (->0) 2 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 23 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 24 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 25 (->0) 1 4000 Oct 7 17:08:04 thumper1 kernel: Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 26 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 27 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 28 (->0) 1 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 29 (->0) 2 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 30 (->0) 3 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 31 (->0) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 2 (->18) 1 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 5 (->18) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 6 (->18) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 7 (->18) 0 4000 Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 8 (->18) 1 4000 Oct 7 17:08:05 thumper1 kernel: Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 9 (->18) 2 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 10 (->18) 0 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 11 (->18) 1 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 12 (->18) 0 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 13 (->18) 0 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 14 (->18) 1 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 15 (->18) 2 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 16 (->18) 3 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 17 (->18) 0 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 18 (->22) 1 4000 Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 19 (->22) 2 4000 Oct 7 17:08:05 thumper1 kernel: Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 20 (->22) 3 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 30 (->31) 0 0000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 7 (->0) 0 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 8 (->0) 1 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 10 (->0) 3 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 11 (->0) 0 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 12 (->0) 1 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 13 (->0) 2 4000 Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 14 (->0) 3 4000 ... Oct 7 17:08:09 thumper1 kernel: mvsch19: EMPTY CRPB 9 (->10) 0 0000 Oct 7 17:08:39 thumper1 kernel: mvsch19: Timeout on slot 1 Oct 7 17:08:39 thumper1 kernel: mvsch19: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 19 (->0) 1 4000 Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 20 (->0) 3 4000 Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 21 (->0) 2 4000 ... Oct 7 17:08:43 thumper1 kernel: mvsch18: EMPTY CRPB 14 (->15) 0 4000 Oct 7 17:08:43 thumper1 kernel: mvsch29: EMPTY CRPB 29 (->0) 0 4000 Oct 7 17:09:13 thumper1 kernel: mvsch29: Timeout on slot 1 Oct 7 17:09:13 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001025 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 27 (->0) 1 4000 Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 29 (->0) 3 4000 Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 30 (->0) 0 4000 ... Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 26 (->29) 1 4000 Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 27 (->29) 2 4000 Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 28 (->29) 0 4000 Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 8 (->9) 0 0000 Oct 7 17:09:44 thumper1 kernel: mvsch20: Timeout on slot 1 Oct 7 17:09:44 thumper1 kernel: mvsch20: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001123 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:09:45 thumper1 kernel: mvsch12: EMPTY CRPB 26 (->27) 0 002a Oct 7 17:10:15 thumper1 kernel: mvsch12: Timeout on slot 1 Oct 7 17:10:15 thumper1 kernel: mvsch12: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001022 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:10:15 thumper1 kernel: mvsch4: EMPTY CRPB 14 (->15) 0 0000 Oct 7 17:10:45 thumper1 kernel: mvsch4: Timeout on slot 1 Oct 7 17:10:45 thumper1 kernel: mvsch4: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001020 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 7 (->0) 1 4000 Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 8 (->0) 0 4000 Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 9 (->0) 1 4000 ... Oct 7 17:10:48 thumper1 kernel: mvsch19: EMPTY CRPB 21 (->26) 3 4000 Oct 7 17:10:48 thumper1 kernel: mvsch21: EMPTY CRPB 19 (->20) 0 0000 Oct 7 17:10:48 thumper1 kernel: mvsch21: EMPTY CRPB 28 (->29) 0 0000 Oct 7 17:11:18 thumper1 kernel: mvsch21: Timeout on slot 2 Oct 7 17:11:18 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001026 dma_c 00000000 dma_s 00000000 rs 00000014 status 50 Oct 7 17:11:18 thumper1 kernel: mvsch21: ... waiting for slots 00000010 Oct 7 17:11:18 thumper1 kernel: mvsch21: Timeout on slot 4 Oct 7 17:11:18 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001026 dma_c 00000000 dma_s 00000000 rs 00000014 status 50 Oct 7 17:11:19 thumper1 kernel: mvsch27: EMPTY CRPB 22 (->23) 0 0000 Oct 7 17:11:19 thumper1 kernel: mvsch21: EMPTY CRPB 12 (->13) 0 4000 Oct 7 17:11:19 thumper1 kernel: mvsch29: EMPTY CRPB 6 (->7) 0 0000 ... Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 13 (->16) 0 4000 Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 14 (->16) 1 4000 Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 15 (->16) 0 4000 Oct 7 17:11:49 thumper1 kernel: mvsch27: Timeout on slot 1 Oct 7 17:11:49 thumper1 kernel: mvsch27: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001023 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:11:49 thumper1 kernel: mvsch21: Timeout on slot 1 Oct 7 17:11:49 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 Oct 7 17:11:49 thumper1 kernel: mvsch29: Timeout on slot 1 Oct 7 17:11:49 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 0000000a status 50 Oct 7 17:11:49 thumper1 kernel: mvsch29: ... waiting for slots 00000008 Oct 7 17:11:49 thumper1 kernel: mvsch3: Timeout on slot 2 Oct 7 17:11:49 thumper1 kernel: mvsch3: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001023 dma_c 00000000 dma_s 00000000 rs 00000004 status 50 Oct 7 17:11:49 thumper1 kernel: mvsch1: EMPTY CRPB 18 (->20) 1 4000 Oct 7 17:11:49 thumper1 kernel: mvsch29: Timeout on slot 3 Oct 7 17:11:49 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 0000000a status 50 Oct 7 17:11:49 thumper1 kernel: mvsch2: EMPTY CRPB 14 (->15) 0 0000 Oct 7 17:11:49 thumper1 kernel: mvsch30: EMPTY CRPB 21 (->22) 0 0000 Oct 7 17:11:49 thumper1 kernel: mvsch12: EMPTY CRPB 22 (->23) 0 0000 Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000 ... Ahh and dd did finish after a long time: > dd if=tst.dd of=/dev/null bs=64k load: 0.87 cmd: dd 1399 [zio->io_cv)] 35.50r 0.01u 10.57s 0% 868k 107740+0 records in 107740+0 records out 7060848640 bytes transferred in 48.836175 secs (144582344 bytes/sec) load: 0.44 cmd: dd 1399 [zio->io_cv)] 76.87r 0.01u 11.99s 0% 880k 114476+0 records in 114476+0 records out 7502299136 bytes transferred in 83.218699 secs (90151603 bytes/sec) load: 0.79 cmd: dd 1399 [zio->io_cv)] 104.27r 0.01u 12.37s 0% 880k 118032+0 records in 118032+0 records out 7735345152 bytes transferred in 114.212610 secs (67727593 bytes/sec) load: 0.29 cmd: dd 1399 [zio->io_cv)] 165.37r 0.01u 12.77s 0% 880k 121816+0 records in 121816+0 records out 7983333376 bytes transferred in 174.702303 secs (45696784 bytes/sec) load: 0.01 cmd: dd 1399 [zio->io_cv)] 454.84r 0.01u 15.57s 0% 880k 134566+0 records in 134566+0 records out 8818917376 bytes transferred in 455.140146 secs (19376268 bytes/sec) load: 0.00 cmd: dd 1399 [zio->io_cv)] 671.34r 0.02u 16.71s 0% 880k 143446+0 records in 143446+0 records out 9400877056 bytes transferred in 699.953712 secs (13430712 bytes/sec) 160000+0 records in 160000+0 records out 10485760000 bytes transferred in 1077.266770 secs (9733671 bytes/sec) > John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 17:39:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50D8F106566C for ; Thu, 7 Oct 2010 17:39:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id D65658FC08 for ; Thu, 7 Oct 2010 17:39:01 +0000 (UTC) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta12.westchester.pa.mail.comcast.net with comcast id FnAf1f0010ldTLk5Ctf1XJ; Thu, 07 Oct 2010 17:39:01 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.westchester.pa.mail.comcast.net with comcast id Ftf01f0013LrwQ23Qtf0Fd; Thu, 07 Oct 2010 17:39:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B004D9B427; Thu, 7 Oct 2010 10:38:58 -0700 (PDT) Date: Thu, 7 Oct 2010 10:38:58 -0700 From: Jeremy Chadwick To: John Hay Message-ID: <20101007173858.GA85862@icarus.home.lan> References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> <20101007173102.GA95405@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101007173102.GA95405@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:39:02 -0000 On Thu, Oct 07, 2010 at 07:31:02PM +0200, John Hay wrote: > On Thu, Oct 07, 2010 at 06:19:48PM +0200, Goran Lowkrantz wrote: > > --On October 7, 2010 17:50:42 +0200 John Hay wrote: > > > > >On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote: > > >>On 10/07/10 14:15, John Hay wrote: > > >>> Hi, > > >>> > > >>> I got hold of a SunFire X4500 with 48 X 500G disks and thought to try > > >>> FreeBSD 8-stable with zfs on it. > > >>> > > >>> I have setup the two boot disks in a zfs mirror and then the rest in > > >>> a pool of 6 X raidz2 of 7 disks each. > > >>> > > >>> I have created a 10G file with dd in the second pool, but if I try to > > >>> read it with dd, dd will hang in "zio->io_cv)" according to ^T. This > > >>> happens everytime. The first time I saw messages about an interrupt > > >>> storm, so I have put "hw.intr_storm_threshold=10000" in > > >>> /etc/sysctl.conf. According to "systat -vm 1" there is atapci for 2-3 > > >>> seconds and then it is quiet. > > >> > > >>There are two things you could try: 1) use the AHCI driver > > >>(ahci_load="YES" in /boot/loader.conf) and 2) disable superpages, they > > >>don't get along on a few models of Opterons (vm.pmap.pg_ps_enabled=0 in > > >>/boot/loader.conf). > > > > > >ahci does not grab them. According to the ahci man page, it can handle > > >Marvell 88SX61xx, while these are MV88SX6081 according to pciconf -lcv: > > > > > >atapci0@pci0:1:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > > >rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo > > >Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X > > >Controller' > > > class = mass storage > > > subclass = SCSI > > > cap 01[40] = powerspec 2 supports D0 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 4 split > > >transactions > > > > Then try mvs_load="YES" > > > > mvs0@pci0:6:2:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > > rev=0x09 hdr=0x00 > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device = 'MV88SX6081 8-port SATA II PCI-X Controller' > > class = mass storage > > subclass = SCSI > > mvs1@pci0:5:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > > rev=0x09 hdr=0x00 > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > device = 'MV88SX6081 8-port SATA II PCI-X Controller' > > class = mass storage > > subclass = SCSI > > That helped, thanks. Now the disks are detected as adaXX devices. > > The problem still happens though. I think it takes a little longer after > I have started dd before it hangs, but it still hangs. > > One thing seems a little different though. Occasionaly a short burst of > interrupts on the mvsX devices do come through. It also seems that a few > seconds after I press ^T in the dd window, I see a burst of mvsX > interrupts happen and dd will report in/out records and bytes. This did > not happen with the ata driver. It is still hanging in "zio->io_cv)" > though. > > I also see these messages in /var/log/messages > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 16 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 17 (->0) 1 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 18 (->0) 2 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 20 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 21 (->0) 1 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 22 (->0) 2 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 23 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 24 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 25 (->0) 1 4000 > Oct 7 17:08:04 thumper1 kernel: > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 26 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 27 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 28 (->0) 1 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 29 (->0) 2 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 30 (->0) 3 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 31 (->0) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 2 (->18) 1 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 5 (->18) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 6 (->18) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 7 (->18) 0 4000 > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 8 (->18) 1 4000 > Oct 7 17:08:05 thumper1 kernel: > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 9 (->18) 2 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 10 (->18) 0 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 11 (->18) 1 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 12 (->18) 0 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 13 (->18) 0 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 14 (->18) 1 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 15 (->18) 2 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 16 (->18) 3 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 17 (->18) 0 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 18 (->22) 1 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 19 (->22) 2 4000 > Oct 7 17:08:05 thumper1 kernel: > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 20 (->22) 3 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 30 (->31) 0 0000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 7 (->0) 0 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 8 (->0) 1 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 10 (->0) 3 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 11 (->0) 0 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 12 (->0) 1 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 13 (->0) 2 4000 > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 14 (->0) 3 4000 > ... > Oct 7 17:08:09 thumper1 kernel: mvsch19: EMPTY CRPB 9 (->10) 0 0000 > Oct 7 17:08:39 thumper1 kernel: mvsch19: Timeout on slot 1 > Oct 7 17:08:39 thumper1 kernel: mvsch19: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 19 (->0) 1 4000 > Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 20 (->0) 3 4000 > Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 21 (->0) 2 4000 > ... > Oct 7 17:08:43 thumper1 kernel: mvsch18: EMPTY CRPB 14 (->15) 0 4000 > Oct 7 17:08:43 thumper1 kernel: mvsch29: EMPTY CRPB 29 (->0) 0 4000 > Oct 7 17:09:13 thumper1 kernel: mvsch29: Timeout on slot 1 > Oct 7 17:09:13 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001025 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 27 (->0) 1 4000 > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 29 (->0) 3 4000 > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 30 (->0) 0 4000 > ... > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 26 (->29) 1 4000 > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 27 (->29) 2 4000 > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 28 (->29) 0 4000 > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 8 (->9) 0 0000 > Oct 7 17:09:44 thumper1 kernel: mvsch20: Timeout on slot 1 > Oct 7 17:09:44 thumper1 kernel: mvsch20: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001123 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:09:45 thumper1 kernel: mvsch12: EMPTY CRPB 26 (->27) 0 002a > Oct 7 17:10:15 thumper1 kernel: mvsch12: Timeout on slot 1 > Oct 7 17:10:15 thumper1 kernel: mvsch12: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001022 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:10:15 thumper1 kernel: mvsch4: EMPTY CRPB 14 (->15) 0 0000 > Oct 7 17:10:45 thumper1 kernel: mvsch4: Timeout on slot 1 > Oct 7 17:10:45 thumper1 kernel: mvsch4: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001020 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 7 (->0) 1 4000 > Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 8 (->0) 0 4000 > Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 9 (->0) 1 4000 > ... > Oct 7 17:10:48 thumper1 kernel: mvsch19: EMPTY CRPB 21 (->26) 3 4000 > Oct 7 17:10:48 thumper1 kernel: mvsch21: EMPTY CRPB 19 (->20) 0 0000 > Oct 7 17:10:48 thumper1 kernel: mvsch21: EMPTY CRPB 28 (->29) 0 0000 > Oct 7 17:11:18 thumper1 kernel: mvsch21: Timeout on slot 2 > Oct 7 17:11:18 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001026 dma_c 00000000 dma_s 00000000 rs 00000014 status 50 > Oct 7 17:11:18 thumper1 kernel: mvsch21: ... waiting for slots 00000010 > Oct 7 17:11:18 thumper1 kernel: mvsch21: Timeout on slot 4 > Oct 7 17:11:18 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001026 dma_c 00000000 dma_s 00000000 rs 00000014 status 50 > Oct 7 17:11:19 thumper1 kernel: mvsch27: EMPTY CRPB 22 (->23) 0 0000 > Oct 7 17:11:19 thumper1 kernel: mvsch21: EMPTY CRPB 12 (->13) 0 4000 > Oct 7 17:11:19 thumper1 kernel: mvsch29: EMPTY CRPB 6 (->7) 0 0000 > ... > Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 13 (->16) 0 4000 > Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 14 (->16) 1 4000 > Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 15 (->16) 0 4000 > Oct 7 17:11:49 thumper1 kernel: mvsch27: Timeout on slot 1 > Oct 7 17:11:49 thumper1 kernel: mvsch27: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001023 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:11:49 thumper1 kernel: mvsch21: Timeout on slot 1 > Oct 7 17:11:49 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > Oct 7 17:11:49 thumper1 kernel: mvsch29: Timeout on slot 1 > Oct 7 17:11:49 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 0000000a status 50 > Oct 7 17:11:49 thumper1 kernel: mvsch29: ... waiting for slots 00000008 > Oct 7 17:11:49 thumper1 kernel: mvsch3: Timeout on slot 2 > Oct 7 17:11:49 thumper1 kernel: mvsch3: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001023 dma_c 00000000 dma_s 00000000 rs 00000004 status 50 > Oct 7 17:11:49 thumper1 kernel: mvsch1: EMPTY CRPB 18 (->20) 1 4000 > Oct 7 17:11:49 thumper1 kernel: mvsch29: Timeout on slot 3 > Oct 7 17:11:49 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 0000000a status 50 > Oct 7 17:11:49 thumper1 kernel: mvsch2: EMPTY CRPB 14 (->15) 0 0000 > Oct 7 17:11:49 thumper1 kernel: mvsch30: EMPTY CRPB 21 (->22) 0 0000 > Oct 7 17:11:49 thumper1 kernel: mvsch12: EMPTY CRPB 22 (->23) 0 0000 > Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000 > ... > > Ahh and dd did finish after a long time: > > > dd if=tst.dd of=/dev/null bs=64k > load: 0.87 cmd: dd 1399 [zio->io_cv)] 35.50r 0.01u 10.57s 0% 868k > 107740+0 records in > 107740+0 records out > 7060848640 bytes transferred in 48.836175 secs (144582344 bytes/sec) > > load: 0.44 cmd: dd 1399 [zio->io_cv)] 76.87r 0.01u 11.99s 0% 880k > 114476+0 records in > 114476+0 records out > 7502299136 bytes transferred in 83.218699 secs (90151603 bytes/sec) > load: 0.79 cmd: dd 1399 [zio->io_cv)] 104.27r 0.01u 12.37s 0% 880k > 118032+0 records in > 118032+0 records out > 7735345152 bytes transferred in 114.212610 secs (67727593 bytes/sec) > load: 0.29 cmd: dd 1399 [zio->io_cv)] 165.37r 0.01u 12.77s 0% 880k > 121816+0 records in > 121816+0 records out > 7983333376 bytes transferred in 174.702303 secs (45696784 bytes/sec) > load: 0.01 cmd: dd 1399 [zio->io_cv)] 454.84r 0.01u 15.57s 0% 880k > 134566+0 records in > 134566+0 records out > 8818917376 bytes transferred in 455.140146 secs (19376268 bytes/sec) > load: 0.00 cmd: dd 1399 [zio->io_cv)] 671.34r 0.02u 16.71s 0% 880k > 143446+0 records in > 143446+0 records out > 9400877056 bytes transferred in 699.953712 secs (13430712 bytes/sec) > 160000+0 records in > 160000+0 records out > 10485760000 bytes transferred in 1077.266770 secs (9733671 bytes/sec) Isn't slow I/O one of the results of ARC starvation? Please also provide vmstat -i output. Also adding Andriy Gapon to the CC list. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 17:43:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EEC710656C7 for ; Thu, 7 Oct 2010 17:43:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0828FC0C for ; Thu, 7 Oct 2010 17:43:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA18590; Thu, 07 Oct 2010 20:43:39 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAE06CA.1010100@icyb.net.ua> Date: Thu, 07 Oct 2010 20:43:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> <20101007173102.GA95405@zibbi.meraka.csir.co.za> <20101007173858.GA85862@icarus.home.lan> In-Reply-To: <20101007173858.GA85862@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:43:50 -0000 on 07/10/2010 20:38 Jeremy Chadwick said the following: > Isn't slow I/O one of the results of ARC starvation? Slow I/O can be a result of very many things. Please remove me from CC, thanks :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 17:52:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE151065672 for ; Thu, 7 Oct 2010 17:52:26 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 892C58FC22 for ; Thu, 7 Oct 2010 17:52:26 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0L9X00IOPLNC2G40@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Thu, 07 Oct 2010 19:52:24 +0200 (CEST) Received: from kg-v2.kg4.no ([80.203.109.34]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0L9X009GELNC62Y1@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Thu, 07 Oct 2010 19:52:24 +0200 (CEST) Date: Thu, 07 Oct 2010 19:52:24 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101007195224.9c87af36.torfinn.ingolfsen@broadpark.no> In-reply-to: <4CADBF20.1040000@gmail.com> References: <4CADBF20.1040000@gmail.com> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: How dhcp client can set its hostname properly on lease time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:52:26 -0000 On Thu, 07 Oct 2010 21:37:52 +0900 Mamoru Iwaki <1wkmmr@gmail.com> wrote: > Are there good way for dhcp client to set its hostname properly on lease > time? Well, you *can* have the dhcp client on FreeBSD send an identifier, and with that identifier the dhcp server can assign the client a static ip lease. If that static ip is registered in your local dns, you're all set. Doesn't work well if you use the client on another network who doesn't offer static ip's. YMMV. > The following will be a possble workaround, but I'm wondering there can > be a smart answer in FreeBSD itself. > > It is possible to resolve the hostname corresponding to a dhcp-delivered > ip-address with a local name server. So, (1) resolve the corresponding > hostname from the local name server, (2) set it as hostname, and (3) > call them every time when dhcp lease is updated Isn't the proper way with dns to configure dynamic DNS updates, and allow the client to do that? HTH -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 18:02:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DF7106566B for ; Thu, 7 Oct 2010 18:02:22 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id ABC398FC1E for ; Thu, 7 Oct 2010 18:02:22 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P3unP-000JFa-OE for freebsd-stable@freebsd.org; Thu, 07 Oct 2010 20:02:23 +0200 Date: Thu, 7 Oct 2010 20:02:23 +0200 From: Kurt Jaeger To: freebsd-stable@freebsd.org Message-ID: <20101007180223.GV34314@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Intel em, SFPs and DDM ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:02:23 -0000 Hi! Does anyone know how to read SFP DDM values using Intel em cards ? SFP means Small Form Factor Pluggable fiber transceivers. DDM is Digital Diagnostics Monitoring http://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver#Digital_Diagnostics_Monitoring There seems to be a way to read it using i2c(8) ? Any pointers ? -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 18:25:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF28410656C1; Thu, 7 Oct 2010 18:25:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D53278FC12; Thu, 7 Oct 2010 18:25:31 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA19187; Thu, 07 Oct 2010 21:25:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAE1099.5010100@icyb.net.ua> Date: Thu, 07 Oct 2010 21:25:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ivan Voras References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:25:34 -0000 on 07/10/2010 15:35 Ivan Voras said the following: > /boot/loader.conf) and 2) disable superpages, they don't get along on a few models > of Opterons (vm.pmap.pg_ps_enabled=0 in /boot/loader.conf). Those who follow know that the issue is supposed to be resolved long ago. Just in case. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 18:28:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37F431065674 for ; Thu, 7 Oct 2010 18:28:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 68ADD8FC1A for ; Thu, 7 Oct 2010 18:28:27 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA19220; Thu, 07 Oct 2010 21:28:23 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAE1146.3030305@icyb.net.ua> Date: Thu, 07 Oct 2010 21:28:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Hay References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> <20101007173102.GA95405@zibbi.meraka.csir.co.za> In-Reply-To: <20101007173102.GA95405@zibbi.meraka.csir.co.za> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:28:28 -0000 on 07/10/2010 20:31 John Hay said the following: > Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000 Can you rule out hardware (or driver-level) problems? E.g. by dd-ing to/from disk directly. Doing that in parallel on the same and/or different disks. Running any disk I/O benchmarks. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 18:30:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDE25106576E; Thu, 7 Oct 2010 18:30:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E9C098FC29; Thu, 7 Oct 2010 18:30:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA19232; Thu, 07 Oct 2010 21:29:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CAE11A2.1000604@icyb.net.ua> Date: Thu, 07 Oct 2010 21:29:54 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> In-Reply-To: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick , Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:30:06 -0000 on 07/10/2010 18:46 Andriy Bakay said the following: > Hi All, > > Do we have any new information about this issue (fixes, work arounds etc.)? Any > input will be highly useful. Yes, _we_ do. Where have you been? :-) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 18:47:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69EB81065698 for ; Thu, 7 Oct 2010 18:47:05 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.freebsd.org (Postfix) with SMTP id E328C8FC27 for ; Thu, 7 Oct 2010 18:47:04 +0000 (UTC) Received: (qmail 55274 invoked from network); 7 Oct 2010 18:47:04 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 11:47:03 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: TrO1ZjgVM1ks2odRnmjQuEEi.8.pixVMIRJQSuV.yo4Aufb cdQat3WHKbHM2bkFhS3F8AbioGE9M8k7mnNX4klYYygR_RIamTnmSEmThE7Q 8eR5.TXxShEzlPr10HfVIchGKxf9OwXPjS0QJbo1YaIkA4KfUDcIUQUqu9yu Fn_gkOa3IbV_3peiv_4tVg.qgge0U8CaDHDcRTRx0QhPxOpJmVJoQ0XhdAtd _5AxNMF_8qegcrt6XFzrC04Tv8KXTQ.tMHR35S.s2rua9Bs5bdJMREqwphyp HqUpq66dyd0EBBx51ps1U2dto.tf1U.SECFml4Vp7Rq.izW7kIbWi.5w2Gww 1S5TgT_yyrVchjdjsHL7YmQ3i_FEyMzg3H.enIc7JJtWpNbm0yg9j4Upkl81 kJp_1gcwNkfEyeOBkXNmk2ff2anjabzBqHoTSxAVULCkX X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id 52ED5AC11; Thu, 7 Oct 2010 14:47:03 -0400 (EDT) To: Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 07 Oct 2010 14:47:03 -0400 From: Andriy Bakay In-Reply-To: <4CAE11A2.1000604@icyb.net.ua> References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> Message-ID: <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Jeremy Chadwick , Richard Lee Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:47:05 -0000 I expressed myself incorrectly. Sorry. :-( Do you Andriy :-) or anybody else from list(s) have more info how to fix or work around this issue? On Thu, 07 Oct 2010 21:29:54 +0300, Andriy Gapon wrote: > on 07/10/2010 18:46 Andriy Bakay said the following: >> Hi All, >> >> Do we have any new information about this issue (fixes, work arounds etc.)? Any >> input will be highly useful. > > Yes, _we_ do. Where have you been? :-) From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 18:49:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5101065672 for ; Thu, 7 Oct 2010 18:49:14 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 18B238FC1C for ; Thu, 7 Oct 2010 18:49:12 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id C6A9F39824; Thu, 7 Oct 2010 20:49:09 +0200 (SAST) Date: Thu, 7 Oct 2010 20:49:09 +0200 From: John Hay To: Jeremy Chadwick Message-ID: <20101007184909.GA4083@zibbi.meraka.csir.co.za> References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> <20101007173102.GA95405@zibbi.meraka.csir.co.za> <20101007173858.GA85862@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101007173858.GA85862@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 18:49:14 -0000 On Thu, Oct 07, 2010 at 10:38:58AM -0700, Jeremy Chadwick wrote: > On Thu, Oct 07, 2010 at 07:31:02PM +0200, John Hay wrote: > > On Thu, Oct 07, 2010 at 06:19:48PM +0200, Goran Lowkrantz wrote: > > > --On October 7, 2010 17:50:42 +0200 John Hay wrote: > > > > > > >On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote: > > > >>On 10/07/10 14:15, John Hay wrote: > > > >>> Hi, > > > >>> > > > >>> I got hold of a SunFire X4500 with 48 X 500G disks and thought to try > > > >>> FreeBSD 8-stable with zfs on it. > > > >>> > > > >>> I have setup the two boot disks in a zfs mirror and then the rest in > > > >>> a pool of 6 X raidz2 of 7 disks each. > > > >>> > > > >>> I have created a 10G file with dd in the second pool, but if I try to > > > >>> read it with dd, dd will hang in "zio->io_cv)" according to ^T. This > > > >>> happens everytime. The first time I saw messages about an interrupt > > > >>> storm, so I have put "hw.intr_storm_threshold=10000" in > > > >>> /etc/sysctl.conf. According to "systat -vm 1" there is atapci for 2-3 > > > >>> seconds and then it is quiet. > > > >> > > > >>There are two things you could try: 1) use the AHCI driver > > > >>(ahci_load="YES" in /boot/loader.conf) and 2) disable superpages, they > > > >>don't get along on a few models of Opterons (vm.pmap.pg_ps_enabled=0 in > > > >>/boot/loader.conf). > > > > > > > >ahci does not grab them. According to the ahci man page, it can handle > > > >Marvell 88SX61xx, while these are MV88SX6081 according to pciconf -lcv: > > > > > > > >atapci0@pci0:1:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > > > >rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo > > > >Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X > > > >Controller' > > > > class = mass storage > > > > subclass = SCSI > > > > cap 01[40] = powerspec 2 supports D0 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit > > > > cap 07[60] = PCI-X 64-bit supports 133MHz, 512 burst read, 4 split > > > >transactions > > > > > > Then try mvs_load="YES" > > > > > > mvs0@pci0:6:2:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > > > rev=0x09 hdr=0x00 > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > device = 'MV88SX6081 8-port SATA II PCI-X Controller' > > > class = mass storage > > > subclass = SCSI > > > mvs1@pci0:5:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab > > > rev=0x09 hdr=0x00 > > > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > > > device = 'MV88SX6081 8-port SATA II PCI-X Controller' > > > class = mass storage > > > subclass = SCSI > > > > That helped, thanks. Now the disks are detected as adaXX devices. > > > > The problem still happens though. I think it takes a little longer after > > I have started dd before it hangs, but it still hangs. > > > > One thing seems a little different though. Occasionaly a short burst of > > interrupts on the mvsX devices do come through. It also seems that a few > > seconds after I press ^T in the dd window, I see a burst of mvsX > > interrupts happen and dd will report in/out records and bytes. This did > > not happen with the ata driver. It is still hanging in "zio->io_cv)" > > though. > > > > I also see these messages in /var/log/messages > > > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 16 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 17 (->0) 1 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 18 (->0) 2 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 20 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 21 (->0) 1 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 22 (->0) 2 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 23 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 24 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 25 (->0) 1 4000 > > Oct 7 17:08:04 thumper1 kernel: > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 26 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 27 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 28 (->0) 1 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 29 (->0) 2 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 30 (->0) 3 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 31 (->0) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 2 (->18) 1 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 5 (->18) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 6 (->18) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 7 (->18) 0 4000 > > Oct 7 17:08:04 thumper1 kernel: mvsch31: EMPTY CRPB 8 (->18) 1 4000 > > Oct 7 17:08:05 thumper1 kernel: > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 9 (->18) 2 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 10 (->18) 0 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 11 (->18) 1 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 12 (->18) 0 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 13 (->18) 0 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 14 (->18) 1 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 15 (->18) 2 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 16 (->18) 3 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 17 (->18) 0 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 18 (->22) 1 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 19 (->22) 2 4000 > > Oct 7 17:08:05 thumper1 kernel: > > Oct 7 17:08:05 thumper1 kernel: mvsch31: EMPTY CRPB 20 (->22) 3 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 30 (->31) 0 0000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 7 (->0) 0 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 8 (->0) 1 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 10 (->0) 3 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 11 (->0) 0 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 12 (->0) 1 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 13 (->0) 2 4000 > > Oct 7 17:08:05 thumper1 kernel: mvsch20: EMPTY CRPB 14 (->0) 3 4000 > > ... > > Oct 7 17:08:09 thumper1 kernel: mvsch19: EMPTY CRPB 9 (->10) 0 0000 > > Oct 7 17:08:39 thumper1 kernel: mvsch19: Timeout on slot 1 > > Oct 7 17:08:39 thumper1 kernel: mvsch19: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 19 (->0) 1 4000 > > Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 20 (->0) 3 4000 > > Oct 7 17:08:39 thumper1 kernel: mvsch22: EMPTY CRPB 21 (->0) 2 4000 > > ... > > Oct 7 17:08:43 thumper1 kernel: mvsch18: EMPTY CRPB 14 (->15) 0 4000 > > Oct 7 17:08:43 thumper1 kernel: mvsch29: EMPTY CRPB 29 (->0) 0 4000 > > Oct 7 17:09:13 thumper1 kernel: mvsch29: Timeout on slot 1 > > Oct 7 17:09:13 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001025 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 27 (->0) 1 4000 > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 29 (->0) 3 4000 > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 30 (->0) 0 4000 > > ... > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 26 (->29) 1 4000 > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 27 (->29) 2 4000 > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 28 (->29) 0 4000 > > Oct 7 17:09:14 thumper1 kernel: mvsch20: EMPTY CRPB 8 (->9) 0 0000 > > Oct 7 17:09:44 thumper1 kernel: mvsch20: Timeout on slot 1 > > Oct 7 17:09:44 thumper1 kernel: mvsch20: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001123 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:09:45 thumper1 kernel: mvsch12: EMPTY CRPB 26 (->27) 0 002a > > Oct 7 17:10:15 thumper1 kernel: mvsch12: Timeout on slot 1 > > Oct 7 17:10:15 thumper1 kernel: mvsch12: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001022 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:10:15 thumper1 kernel: mvsch4: EMPTY CRPB 14 (->15) 0 0000 > > Oct 7 17:10:45 thumper1 kernel: mvsch4: Timeout on slot 1 > > Oct 7 17:10:45 thumper1 kernel: mvsch4: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001020 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 7 (->0) 1 4000 > > Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 8 (->0) 0 4000 > > Oct 7 17:10:45 thumper1 kernel: mvsch22: EMPTY CRPB 9 (->0) 1 4000 > > ... > > Oct 7 17:10:48 thumper1 kernel: mvsch19: EMPTY CRPB 21 (->26) 3 4000 > > Oct 7 17:10:48 thumper1 kernel: mvsch21: EMPTY CRPB 19 (->20) 0 0000 > > Oct 7 17:10:48 thumper1 kernel: mvsch21: EMPTY CRPB 28 (->29) 0 0000 > > Oct 7 17:11:18 thumper1 kernel: mvsch21: Timeout on slot 2 > > Oct 7 17:11:18 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001026 dma_c 00000000 dma_s 00000000 rs 00000014 status 50 > > Oct 7 17:11:18 thumper1 kernel: mvsch21: ... waiting for slots 00000010 > > Oct 7 17:11:18 thumper1 kernel: mvsch21: Timeout on slot 4 > > Oct 7 17:11:18 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001026 dma_c 00000000 dma_s 00000000 rs 00000014 status 50 > > Oct 7 17:11:19 thumper1 kernel: mvsch27: EMPTY CRPB 22 (->23) 0 0000 > > Oct 7 17:11:19 thumper1 kernel: mvsch21: EMPTY CRPB 12 (->13) 0 4000 > > Oct 7 17:11:19 thumper1 kernel: mvsch29: EMPTY CRPB 6 (->7) 0 0000 > > ... > > Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 13 (->16) 0 4000 > > Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 14 (->16) 1 4000 > > Oct 7 17:11:19 thumper1 kernel: mvsch1: EMPTY CRPB 15 (->16) 0 4000 > > Oct 7 17:11:49 thumper1 kernel: mvsch27: Timeout on slot 1 > > Oct 7 17:11:49 thumper1 kernel: mvsch27: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001023 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:11:49 thumper1 kernel: mvsch21: Timeout on slot 1 > > Oct 7 17:11:49 thumper1 kernel: mvsch21: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 > > Oct 7 17:11:49 thumper1 kernel: mvsch29: Timeout on slot 1 > > Oct 7 17:11:49 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 0000000a status 50 > > Oct 7 17:11:49 thumper1 kernel: mvsch29: ... waiting for slots 00000008 > > Oct 7 17:11:49 thumper1 kernel: mvsch3: Timeout on slot 2 > > Oct 7 17:11:49 thumper1 kernel: mvsch3: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001023 dma_c 00000000 dma_s 00000000 rs 00000004 status 50 > > Oct 7 17:11:49 thumper1 kernel: mvsch1: EMPTY CRPB 18 (->20) 1 4000 > > Oct 7 17:11:49 thumper1 kernel: mvsch29: Timeout on slot 3 > > Oct 7 17:11:49 thumper1 kernel: mvsch29: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001024 dma_c 00000000 dma_s 00000000 rs 0000000a status 50 > > Oct 7 17:11:49 thumper1 kernel: mvsch2: EMPTY CRPB 14 (->15) 0 0000 > > Oct 7 17:11:49 thumper1 kernel: mvsch30: EMPTY CRPB 21 (->22) 0 0000 > > Oct 7 17:11:49 thumper1 kernel: mvsch12: EMPTY CRPB 22 (->23) 0 0000 > > Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000 > > ... > > > > Ahh and dd did finish after a long time: > > > > > dd if=tst.dd of=/dev/null bs=64k > > load: 0.87 cmd: dd 1399 [zio->io_cv)] 35.50r 0.01u 10.57s 0% 868k > > 107740+0 records in > > 107740+0 records out > > 7060848640 bytes transferred in 48.836175 secs (144582344 bytes/sec) > > > > load: 0.44 cmd: dd 1399 [zio->io_cv)] 76.87r 0.01u 11.99s 0% 880k > > 114476+0 records in > > 114476+0 records out > > 7502299136 bytes transferred in 83.218699 secs (90151603 bytes/sec) > > load: 0.79 cmd: dd 1399 [zio->io_cv)] 104.27r 0.01u 12.37s 0% 880k > > 118032+0 records in > > 118032+0 records out > > 7735345152 bytes transferred in 114.212610 secs (67727593 bytes/sec) > > load: 0.29 cmd: dd 1399 [zio->io_cv)] 165.37r 0.01u 12.77s 0% 880k > > 121816+0 records in > > 121816+0 records out > > 7983333376 bytes transferred in 174.702303 secs (45696784 bytes/sec) > > load: 0.01 cmd: dd 1399 [zio->io_cv)] 454.84r 0.01u 15.57s 0% 880k > > 134566+0 records in > > 134566+0 records out > > 8818917376 bytes transferred in 455.140146 secs (19376268 bytes/sec) > > load: 0.00 cmd: dd 1399 [zio->io_cv)] 671.34r 0.02u 16.71s 0% 880k > > 143446+0 records in > > 143446+0 records out > > 9400877056 bytes transferred in 699.953712 secs (13430712 bytes/sec) > > 160000+0 records in > > 160000+0 records out > > 10485760000 bytes transferred in 1077.266770 secs (9733671 bytes/sec) > > Isn't slow I/O one of the results of ARC starvation? I doubt it. The machine has 16G RAM and is freshly rebooted. How do I check? arc sysctls? > > Please also provide vmstat -i output. > vmstat -i interrupt total rate irq17: ohci2 719371 196 irq18: ohci3 29530 8 irq19: ohci0 ohci1+ 88188 24 irq24: mvs0 31671 8 irq32: mvs1 29130 7 irq38: mvs2 34050 9 irq46: mvs3 33879 9 irq52: em0 360 0 irq53: em1 6272 1 irq61: em2 6557 1 irq62: em3 1257 0 irq68: mvs4 29187 7 irq76: mvs5 29659 8 cpu0: timer 7289010 1986 cpu1: timer 7284596 1984 cpu2: timer 7279595 1983 cpu3: timer 7292655 1987 Total 30184967 8224 John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 19:20:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06E67106566C; Thu, 7 Oct 2010 19:20:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 039298FC12; Thu, 7 Oct 2010 19:20:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA19762; Thu, 07 Oct 2010 22:20:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P3w0p-0007WW-Ch; Thu, 07 Oct 2010 22:20:19 +0300 Message-ID: <4CAE1D72.20208@icyb.net.ua> Date: Thu, 07 Oct 2010 22:20:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> In-Reply-To: <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:20:26 -0000 on 07/10/2010 21:47 Andriy Bakay said the following: > I expressed myself incorrectly. Sorry. :-( > > Do you Andriy :-) or anybody else from list(s) have more info how to > fix or work around this issue? First, I recommend to try to upgrade to the recent stable/8. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 19:24:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 599711065679 for ; Thu, 7 Oct 2010 19:24:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0C30E8FC13 for ; Thu, 7 Oct 2010 19:24:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P3w4Q-00015h-Us for freebsd-stable@freebsd.org; Thu, 07 Oct 2010 21:24:02 +0200 Received: from 93-142-89-240.adsl.net.t-com.hr ([93.142.89.240]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2010 21:24:02 +0200 Received: from ivoras by 93-142-89-240.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2010 21:24:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 07 Oct 2010 21:23:53 +0200 Lines: 11 Message-ID: References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <4CAE1099.5010100@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-142-89-240.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100620 Thunderbird/3.0.4 In-Reply-To: <4CAE1099.5010100@icyb.net.ua> Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:24:07 -0000 On 10/07/10 20:25, Andriy Gapon wrote: > on 07/10/2010 15:35 Ivan Voras said the following: >> /boot/loader.conf) and 2) disable superpages, they don't get along on a few models >> of Opterons (vm.pmap.pg_ps_enabled=0 in /boot/loader.conf). > > Those who follow know that the issue is supposed to be resolved long ago. > Just in case. Yes, it was. OTOH CPU errata lists are so long today I think it's justified to verify the assumptions. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 20:28:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AFC3106564A for ; Thu, 7 Oct 2010 20:28:45 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9478FC12 for ; Thu, 7 Oct 2010 20:28:44 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA20585; Thu, 07 Oct 2010 23:28:31 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P3x4o-0007Zi-O3; Thu, 07 Oct 2010 23:28:30 +0300 Message-ID: <4CAE2D6E.7070100@icyb.net.ua> Date: Thu, 07 Oct 2010 23:28:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matthew Seaman References: <4CADA4D5.7080204@infracaninophile.co.uk> In-Reply-To: <4CADA4D5.7080204@infracaninophile.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Multiple zdevs in the root zpool? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:28:45 -0000 on 07/10/2010 13:45 Matthew Seaman said the following: > However, according to my understanding, if you want to boot from a > zpool, you can only have one vdev in that pool. > > But what exactly does this mean? Yes, exactly, what does that mean? :) Where did your understanding come from? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 20:30:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D199A106566C for ; Thu, 7 Oct 2010 20:30:47 +0000 (UTC) (envelope-from 0110001101100100b@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 437BB8FC0C for ; Thu, 7 Oct 2010 20:30:46 +0000 (UTC) Received: by ewy27 with SMTP id 27so17592ewy.13 for ; Thu, 07 Oct 2010 13:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=4YSwv2fOA4dRlKVHYKyouiXoQ+ti4gHGWIEhxr4doYM=; b=uukRQR5uyGFdlIs8HntGS1c7TuKWLJWbJwkZWXNZggAsAy74Y8614V/ty+ACEpW/CZ 8GvYVgEPB1KzVCA6lweWb949dAFCVsY2t438UST2X9Q4K43EqH4ura8omG2dQJVSLr80 vc0uua00NPt4eBxYC3MCkta2UpQyA5ohtqW4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mQa3I38e2DLJby1/02cJPVBVtX/7gZa0KOTwdj/4eYqOICw4wWVNZp5H0u+xr+6xfn Fe+RdKrdCzQeF809wPOQneLmGDZB5vFY3cnu+t6tAqKV9b35DtK9nUPOZ44CyBgpjGio 1MClG8rf+4gVNI5/P/3+jLsm0I2NVWEaC0f2M= MIME-Version: 1.0 Received: by 10.213.106.7 with SMTP id v7mr825057ebo.31.1286481561488; Thu, 07 Oct 2010 12:59:21 -0700 (PDT) Received: by 10.213.19.11 with HTTP; Thu, 7 Oct 2010 12:59:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Oct 2010 19:59:21 +0000 Message-ID: From: 1 0 <0110001101100100b@gmail.com> To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 07 Oct 2010 20:43:48 +0000 Subject: FreeBSD 8.1-RELEASE Announcement - Typo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:30:47 -0000 Hello! There is a typo in FreeBSD 8.1-RELEASE Announcement: # dd if=8.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync should be # dd if=8.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=1024k conv=sync Best regards, -- 0110001101100100 From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 20:46:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9F01065672 for ; Thu, 7 Oct 2010 20:46:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 14CDF8FC18 for ; Thu, 7 Oct 2010 20:46:28 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Fw9w1f0020S2fkCAFwmUNU; Thu, 07 Oct 2010 20:46:28 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta09.emeryville.ca.mail.comcast.net with comcast id FwmT1f00i3LrwQ28VwmTzL; Thu, 07 Oct 2010 20:46:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 792D29B418; Thu, 7 Oct 2010 13:46:27 -0700 (PDT) Date: Thu, 7 Oct 2010 13:46:27 -0700 From: Jeremy Chadwick To: 1 0 <0110001101100100b@gmail.com> Message-ID: <20101007204627.GA19849@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.1-RELEASE Announcement - Typo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:46:29 -0000 On Thu, Oct 07, 2010 at 07:59:21PM +0000, 1 0 wrote: > There is a typo in FreeBSD 8.1-RELEASE Announcement: > > # dd if=8.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync > > should be > > # dd if=8.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=1024k conv=sync AFAIK, this isn't a typo. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 21:04:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F40F41065673 for ; Thu, 7 Oct 2010 21:04:18 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.freebsd.org (Postfix) with SMTP id 7B6EF8FC14 for ; Thu, 7 Oct 2010 21:04:18 +0000 (UTC) Received: (qmail 39494 invoked from network); 7 Oct 2010 21:04:17 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 14:04:17 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: 9qFN0U4VM1nhcUSLmGqABhn.gpFX6ft5h2CmuhP67DRcx44 7fuT5RlEul4DUF6brQwoNeHQFAjZXt2YV.mlom2TQC_uc_jNLUb6wKdKfdtP QtJ4wG1pqdItP6Ib23J9tcP_FNQeXjkoMeTG34dxFuN9WPNRiyCZTVz.N7Xo 5NBQBJmLGUofMD__4ZM1w.3fjiMQUI9YIKWOSrhZNFPlMfETqC4X9OFzq7vU Rw7DQXT4PsmYQPEUuxDQKN97VsDO3Q9vakCyn2SsokUew X-Yahoo-Newman-Property: ymail-3 Received: by smtp.irbisnet.com (Postfix, from userid 80) id 2ADE2AC59; Thu, 7 Oct 2010 17:04:17 -0400 (EDT) To: Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 07 Oct 2010 17:04:17 -0400 From: Andriy Bakay In-Reply-To: <4CAE1D72.20208@icyb.net.ua> References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> Message-ID: <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> X-Sender: andriy@irbisnet.com User-Agent: RoundCube Webmail/0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:04:19 -0000 Understood, but is it possible to apply "local" ZFS+UFS related changes? Because STABLE will bring all deltas which was accumulated since RELEASE and I really concern about stability of this box (which is router/firewall/mail server). Other people depend on it. On Thu, 07 Oct 2010 22:20:18 +0300, Andriy Gapon wrote: > on 07/10/2010 21:47 Andriy Bakay said the following: >> I expressed myself incorrectly. Sorry. :-( >> >> Do you Andriy :-) or anybody else from list(s) have more info how to >> fix or work around this issue? > > First, I recommend to try to upgrade to the recent stable/8. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 21:35:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F9861065670 for ; Thu, 7 Oct 2010 21:35:50 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id B2E2C8FC16 for ; Thu, 7 Oct 2010 21:35:49 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o97LZjD6031212 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Oct 2010 22:35:45 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk o97LZjD6031212 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1286487345; bh=viQY2ojktL5XQFiEajehfzITuB5wgkXoLTAo3XGCM5M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4CAE3D29.2020309@infracaninophile.co.uk>|Date:=20T hu,=2007=20Oct=202010=2022:35:37=20+0100|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Mozilla/5.0=20(Macintosh=3B=20U=3B=20Intel=20Mac= 20OS=20X=2010.6=3B=20en-GB=3B=20rv:1.9.2.9)=20Gecko/20100915=20Thu nderbird/3.1.4|MIME-Version:=201.0|To:=20Andriy=20Gapon=20|CC:=20freebsd-stable@freebsd.org|Subject:=20Re:=20Multip le=20zdevs=20in=20the=20root=20zpool?|References:=20<4CADA4D5.7080 204@infracaninophile.co.uk>=20<4CAE2D6E.7070100@icyb.net.ua>|In-Re ply-To:=20<4CAE2D6E.7070100@icyb.net.ua>|X-Enigmail-Version:=201.1 .1|OpenPGP:=20id=3D60AE908C|Content-Type:=20multipart/signed=3B=20 micalg=3Dpgp-sha1=3B=0D=0A=20protocol=3D"application/pgp-signature "=3B=0D=0A=20boundary=3D"------------enig04B2F3950D29F8E1C94E038C" ; b=bJ0oBTemtCtvBC9us0Cv2aFgiCHwJvv1KXRNtxgTVP1AL5mNqzNM2q0NJutuW9g+K 9jYBBP86xQr0I31SxIvYDZKthND4sKcX70qATnYmcMtNZMQIr7V43eELWpDDJqWyA4 FPFXPvT3lzDYOOEMRppNwNhCcy9LduPwtpvwcGAM= Message-ID: <4CAE3D29.2020309@infracaninophile.co.uk> Date: Thu, 07 Oct 2010 22:35:37 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Gapon References: <4CADA4D5.7080204@infracaninophile.co.uk> <4CAE2D6E.7070100@icyb.net.ua> In-Reply-To: <4CAE2D6E.7070100@icyb.net.ua> X-Enigmail-Version: 1.1.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04B2F3950D29F8E1C94E038C" X-Virus-Scanned: clamav-milter 0.96.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: Multiple zdevs in the root zpool? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04B2F3950D29F8E1C94E038C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/10/2010 21:28:30, Andriy Gapon wrote: > on 07/10/2010 13:45 Matthew Seaman said the following: >> However, according to my understanding, if you want to boot from a >> zpool, you can only have one vdev in that pool. >> >> But what exactly does this mean? >=20 > Yes, exactly, what does that mean? :) > Where did your understanding come from? >=20 It was from reading posts like this: http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211677.= html Plus the comments in cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c and sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (grep for the words 'root pool') Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig04B2F3950D29F8E1C94E038C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyuPTEACgkQ8Mjk52CukIw/DACgh3bwM+A1SO14FmfZhkLmsfNT rMUAn1daGlKiIxxewR+s4cbQm+lug8el =YlPK -----END PGP SIGNATURE----- --------------enig04B2F3950D29F8E1C94E038C-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 22:13:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECAE8106566C; Thu, 7 Oct 2010 22:13:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFE58FC21; Thu, 7 Oct 2010 22:13:02 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA21899; Fri, 08 Oct 2010 01:12:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P3yhu-0007fk-G7; Fri, 08 Oct 2010 01:12:58 +0300 Message-ID: <4CAE45EA.5070607@icyb.net.ua> Date: Fri, 08 Oct 2010 01:12:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> In-Reply-To: <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:13:04 -0000 on 08/10/2010 00:04 Andriy Bakay said the following: > Understood, but is it possible to apply "local" ZFS+UFS related > changes? Because STABLE will bring all deltas which was accumulated > since RELEASE and I really concern about stability of this box (which is > router/firewall/mail server). Other people depend on it. Nothing is impossible. But it's up to you to separate the changes you want from the changes you don't want. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 22:24:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECEF5106564A for ; Thu, 7 Oct 2010 22:24:11 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by mx1.freebsd.org (Postfix) with SMTP id 7EC458FC16 for ; Thu, 7 Oct 2010 22:24:11 +0000 (UTC) Received: (qmail 72635 invoked from network); 7 Oct 2010 22:24:10 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp105.rog.mail.re2.yahoo.com with SMTP; 07 Oct 2010 15:24:10 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: MHLmKiYVM1nCf6dolE8mayOGWP5GpV.GpTnmH.jil.ZrLIq tZyG0A3uwJ0JJs49HHtctHmyWYxbRUn.2wx9gqQLX6BPJJWuC287t5JztNB3 _ZJnPblB2Sru.NAoHa6UQowOmZU8Xg6qRlB7nmc9E.B9oIr25pBIhfmcBXI_ DneiWHLhyYM4odIMx1XSZLtZ7RNZs7.24chxqW4bf5fgV9M9eIRskNMDfGRa tU2RtWIncgO4omWhZtShAh2iLYf6b_.G1Tof7R.LJYOtkeV8kMTC_gzF4e2. l_MOX7eTLaB.3pwHyBYwJHAy.LX0NfkDR98yVc.SUrglSow9w1iT6iejT5jy 1t.F_iEdvXqYrtb6FBtTFJXcz_tRinBplxfHguG8QeZBngAtA9Z2qqzYCXZI YsO8vDH_YsaWPkVULX7l4h31J85ZhhFB23VXTGVhSnudl X-Yahoo-Newman-Property: ymail-3 Received: from [10.121.225.39] (unknown [74.198.28.216]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 16105AC78; Thu, 7 Oct 2010 18:24:10 -0400 (EDT) References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> <4CAE45EA.5070607@icyb.net.ua> In-Reply-To: <4CAE45EA.5070607@icyb.net.ua> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> X-Mailer: iPhone Mail (8B117) From: Andriy Bakay Date: Thu, 7 Oct 2010 18:24:41 -0400 To: Andriy Gapon Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:24:12 -0000 Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your o= pinion? On 2010-10-07, at 18:12, Andriy Gapon wrote: > on 08/10/2010 00:04 Andriy Bakay said the following: >> Understood, but is it possible to apply "local" ZFS+UFS related >> changes? Because STABLE will bring all deltas which was accumulated >> since RELEASE and I really concern about stability of this box (which is >> router/firewall/mail server). Other people depend on it. >=20 > Nothing is impossible. But it's up to you to separate the changes you wan= t from > the changes you don't want. >=20 > --=20 > Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Oct 7 22:24:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCFA310656D3; Thu, 7 Oct 2010 22:24:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0188FC22; Thu, 7 Oct 2010 22:24:14 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA22019; Fri, 08 Oct 2010 01:24:05 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P3ysf-0007gD-Bv; Fri, 08 Oct 2010 01:24:05 +0300 Message-ID: <4CAE4884.8080608@icyb.net.ua> Date: Fri, 08 Oct 2010 01:24:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matthew Seaman References: <4CADA4D5.7080204@infracaninophile.co.uk> <4CAE2D6E.7070100@icyb.net.ua> <4CAE3D29.2020309@infracaninophile.co.uk> In-Reply-To: <4CAE3D29.2020309@infracaninophile.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek , freebsd-stable@freebsd.org Subject: Re: Multiple zdevs in the root zpool? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:24:16 -0000 on 08/10/2010 00:35 Matthew Seaman said the following: > On 07/10/2010 21:28:30, Andriy Gapon wrote: >> on 07/10/2010 13:45 Matthew Seaman said the following: >>> However, according to my understanding, if you want to boot from a >>> zpool, you can only have one vdev in that pool. >>> >>> But what exactly does this mean? >> >> Yes, exactly, what does that mean? :) >> Where did your understanding come from? >> > > It was from reading posts like this: > http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211677.html > > Plus the comments in > cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c and > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (grep for > the words 'root pool') Hmm, it seems like a protection for limitations of OpenSolaris boot loader that slipped into our sources. I am pretty sure that our boot code can boot such pools without problems. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 04:36:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 429B810656A5 for ; Fri, 8 Oct 2010 04:36:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id A4CC38FC1D for ; Fri, 8 Oct 2010 04:36:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o984aMT4067938; Fri, 8 Oct 2010 15:36:23 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 8 Oct 2010 15:36:22 +1100 (EST) From: Ian Smith To: Jeremy Chadwick In-Reply-To: <20101007204627.GA19849@icarus.home.lan> Message-ID: <20101008152938.I59829@sola.nimnet.asn.au> References: <20101007204627.GA19849@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: 1 0 <0110001101100100b@gmail.com>, freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.1-RELEASE Announcement - Typo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 04:36:27 -0000 On Thu, 7 Oct 2010, Jeremy Chadwick wrote: > On Thu, Oct 07, 2010 at 07:59:21PM +0000, 1 0 wrote: > > There is a typo in FreeBSD 8.1-RELEASE Announcement: > > > > # dd if=8.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync > > > > should be > > > > # dd if=8.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=1024k conv=sync > > AFAIK, this isn't a typo. 10240 is correct (10KiB), but I don't know the rationale for that size. The typo is that, as per the release announcement, all of the filenames are now preceded by 'FreeBSD-'. I let Ken know ages ago, but suppose I should have submitted a PR .. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 06:24:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B159106564A; Fri, 8 Oct 2010 06:24:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6E38FC1E; Fri, 8 Oct 2010 06:24:11 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA27952; Fri, 08 Oct 2010 09:24:07 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P46ND-000A80-7y; Fri, 08 Oct 2010 09:24:07 +0300 Message-ID: <4CAEB906.10603@icyb.net.ua> Date: Fri, 08 Oct 2010 09:24:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Bakay References: <9cf48605f1dbddc7f1547b93715c1426@irbisnet.com> <4CAE11A2.1000604@icyb.net.ua> <61435f7c66c09f6cf48e39eab5999420@irbisnet.com> <4CAE1D72.20208@icyb.net.ua> <9037d8cbeb4716945204bc65e32a74f2@irbisnet.com> <4CAE45EA.5070607@icyb.net.ua> <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> In-Reply-To: <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 06:24:13 -0000 on 08/10/2010 01:24 Andriy Bakay said the following: > Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your opinion? I use it all the time :-) (And head too). In general, and this opinion is not only my own, the best FreeBSD "release" is the latest stable branch. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 09:11:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B848A106566B; Fri, 8 Oct 2010 09:11:31 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4578FC0A; Fri, 8 Oct 2010 09:11:29 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA01714; Fri, 08 Oct 2010 12:11:28 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P48zA-000AID-HT; Fri, 08 Oct 2010 12:11:28 +0300 Resent-From: Andriy Gapon Resent-To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Resent-Date: Fri, 8 Oct 2010 12:11:28 +0300 Resent-Message-Id: <4CAEE040.8020401@freebsd.org> Resent-User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 Message-ID: <4CAEDF48.1030602@freebsd.org> Date: Fri, 08 Oct 2010 12:07:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> <4BD1FC74.3090504@freebsd.org> <4CA30B24.8040707@freebsd.org> In-Reply-To: <4CA30B24.8040707@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UID: 18468 X-Keywords: Cc: Subject: [HEADSUP] changes to cam_get_device() and cam_open_device() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:11:31 -0000 As there was no objections, I am going to commit changes to cam_get_device() that remove the following features: - ignoring 'r' and 'n' at the start of device name - ignoring whitespace at end of device name - parsing and ignoring slice and partition names in a device name cam(3) manual page is going to be updated to reflect the changes. This would simplify the code and disambiguate its behavior. Non-rewound and character disk/SCSI devices has not been supported for quite a while now. Support for parsing partition/slice names is incomplete (e.g. GPT scheme is not supported) and of questionable usefulness. Full diff is here: http://people.freebsd.org/~avg/cam.diff If you know of any functionality or application that would be broken by this change please stop me ASAP. Also, if you have any other reason to object to the change please speak up before the change is committed. Thank you. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 09:12:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDEE510656A8 for ; Fri, 8 Oct 2010 09:12:35 +0000 (UTC) (envelope-from prvs=0897644702=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 516438FC27 for ; Fri, 8 Oct 2010 09:12:35 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P490C-000Amc-4I for freebsd-stable@freebsd.org; Fri, 08 Oct 2010 11:12:32 +0200 Date: Fri, 8 Oct 2010 11:12:32 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20101008091231.GS2532@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Subject: Re: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:12:35 -0000 Hello, On Thu, Oct 07, 2010 at 12:35:01PM +0000, Peter Much wrote: > Any clues, ideas, pointers, hints, ressources,... are greatly > welcomed!! Maybe you don't really want to hear this, but... ISDN is a dying technology. Any time soon you won't get ISDN termination by your telecom provider anymore. If at all, theyll deliver S0 in your home while doing VoIP from that little box on your wall. You've got 1.5yrs now to change your setup (as I understand we're talking about a small home setup, nothing very complex) to VoIP. This is technically not a very complex task and you can even transfer your phone number. You cannot only have an networked answering machine, but yould also connect with your notebook or an IP phone from nearly everywhere in the world. Not only to check your answering machine, but even make or take calls on your local number when needed. I did the same step several years ago and I didn't regret it for a single second. FreeBSD also offers plenty of VoIP software. So if the services your VoIP provider offers don't satisfy your needs you can even have your own complete telephony solution behind it which offers an own answering machine, selective call forwarding, VPN access, ... Give it a try first and when you get comfy then switch over and forget about ISDN at all. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 09:39:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E26A106566B for ; Fri, 8 Oct 2010 09:39:00 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (unknown [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 92FB68FC13 for ; Fri, 8 Oct 2010 09:38:59 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6718C39822; Fri, 8 Oct 2010 11:38:57 +0200 (SAST) Date: Fri, 8 Oct 2010 11:38:57 +0200 From: John Hay To: Andriy Gapon Message-ID: <20101008093857.GA78363@zibbi.meraka.csir.co.za> References: <20101007121558.GA70199@zibbi.meraka.csir.co.za> <20101007155042.GA88362@zibbi.meraka.csir.co.za> <20101007173102.GA95405@zibbi.meraka.csir.co.za> <4CAE1146.3030305@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CAE1146.3030305@icyb.net.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: zfs hang in zio->io_cv) with dd read X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:39:00 -0000 On Thu, Oct 07, 2010 at 09:28:22PM +0300, Andriy Gapon wrote: > on 07/10/2010 20:31 John Hay said the following: > > Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000 > > Can you rule out hardware (or driver-level) problems? > E.g. by dd-ing to/from disk directly. > Doing that in parallel on the same and/or different disks. > Running any disk I/O benchmarks. Well, it might not be conclusive, but here is what I have done/tried: dd from a few select disks. They all do about 64MB/s and 900 interrupts per second. No kernel messages in dmesg or /var/log/messages. Typical command is: dd if=/dev/ada17 of=/dev/null bs=64k count=80000 8 simultaneous dds from the 8 disks on a controller. I still get 64MB/s and 7000+ interrupts per second. No kernel messages. 6 simultaneous dds from a disk on each of the 6 controllers. I still get 64MB/s and 900+ interrupts per second per controller. No kernel messages. I made a small zfs raidz2 with 6 disks, one from each controller. dd to and from it with no problem. I made a small zfs raidz2 with 8 disks, all from one controller. dd to and from it at 190MB/s and 270MB/s, no problem. Bonnie++ finished without a problem. Next I made a zpool with 2 X raidz2 with 8 disks each. Each raidz2 on its own controller: zpool create -m none tst \ raidz2 ada0p1 ada1p1 ada2p1 ada3p1 ada4p1 ada5p1 ada6p1 ada7p1 \ raidz2 ada8p1 ada9p1 ada10p1 ada11p1 ada12p1 ada13p1 ada14p1 ada15p1 Creating a file with dd finished without a problem, about 245MB/s. # dd if=/dev/zero of=/export/tst.dd bs=64k count=160000 160000+0 records in 160000+0 records out 10485760000 bytes transferred in 42.732294 secs (245382567 bytes/sec) Reading from the file caused a hang again: # dd of=/dev/null if=/export/tst.dd bs=64k This message arrived in dmesg: mvsch15: EMPTY CRPB 13 (->14) 0 0000 And a little later there was a lot more: mvsch15: Timeout on slot 1 mvsch15: iec 02000000 sstat 00000123 serr 00000000 edma_s 00001100 dma_c 00000000 dma_s 00000000 rs 00000002 status 50 mvsch2: EMPTY CRPB 16 (->0) 2 4000 mvsch2: EMPTY CRPB 18 (->0) 1 4000 mvsch2: EMPTY CRPB 19 (->0) 2 4000 mvsch2: EMPTY CRPB 20 (->0) 3 4000 mvsch2: EMPTY CRPB 21 (->0) 0 4000 mvsch2: EMPTY CRPB 22 (->0) 1 4000 mvsch2: EMPTY CRPB 23 (->0) 2 4000 ... While this was happening, a dd from ada7p1 ran at normal speed, but from ada15p1 (which is on mvsch15) hanged for a while until there was a burst of mvsX interrupts and then finished without a further hickup. The original dd from tst.dd still have not finished. So it might be a driver problem, which only occur when pushed in a different than I could with my simultaneous dds to the raw partitions. If there are more tests that I can do, just say what. If someone wants a login to debug this, I can do it. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 09:43:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861D910656A9 for ; Fri, 8 Oct 2010 09:43:41 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 405EF8FC18 for ; Fri, 8 Oct 2010 09:43:40 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id ABD4D8A28C8 for ; Fri, 8 Oct 2010 11:43:39 +0200 (CEST) Message-ID: <4CAEE7CA.3090909@bsdforen.de> Date: Fri, 08 Oct 2010 11:43:38 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.12) Gecko/20100918 Thunderbird/3.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: rs(1) damages data X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 09:43:41 -0000 Recently rs has adopted a habit of damaging data in long lines of input. This can easily be tested: # jot -s\ -b 01234567 1000 | rs 0 1 | grep -vxF 01234567 012345 67 012 34567 012345 67 012 34567 012345 67 012 34567 The jot command prints the string 01234567 a thousand times in a single row. The rs command is supposed to generate an automatic(0) number of rows with 1 column per row. I.e. every word stands in its own line. The grep filters all intact words, so everything that is printed, was damaged by rs. This has the look of a repetitive pattern to me, probably this happens at a fixed buffer boundary. > uname -a FreeBSD mobileKamikaze.norad 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Sep 6 17:08:51 CEST 2010 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 10:11:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20AF6106566B; Fri, 8 Oct 2010 10:11:43 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id B80CD8FC17; Fri, 8 Oct 2010 10:11:42 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1P49vP-000AcZ-BX; Fri, 08 Oct 2010 11:11:39 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P49vP-000NDI-Ah; Fri, 08 Oct 2010 11:11:39 +0100 Date: Fri, 08 Oct 2010 11:11:39 +0100 Message-Id: To: andriy@irbisnet.com, avg@icyb.net.ua In-Reply-To: <7C062F92-B514-49FF-BE28-90B7784A5CB6@irbisnet.com> From: Pete French Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 10:11:43 -0000 > Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your opinion? I am running 8-STABLE from 27th September on all our ptoduction machines (from webservers to database servers to the company mail server) and it is fine. I am going to update again over the next few days, as there are some ZFS fixes in which I want - and which may benifit you too - so I will be able to report back next week as to how a more recent version behaves. In general though, I have never had problems running STABLE on prodyction systems over the years. Of course what I do is to test it on a singlre machine before rolling it out (a leaf in a webfarm so if it goes down it wont affect the business) but it is usually fine. keep an eye on -STABLE mailing list though, as that is where problems arise. I watch that, and also the dailing commits, either here http://www.freshbsd.org/?branch=RELENG_8&project=freebsd&committer=&module=&q= or here http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8 Just to see whats going into the tree relative to whats being discussed. It only takes a few minutes a dat to monitor the mailin lists and the commits, and the result is that we've been running STABLE for a very long time (close to a decade I suspect) with great success. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 15:43:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 547761065674 for ; Fri, 8 Oct 2010 15:43:36 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id E946D8FC13 for ; Fri, 8 Oct 2010 15:43:35 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AC88245CA0; Fri, 8 Oct 2010 17:20:08 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E251445684; Fri, 8 Oct 2010 17:20:01 +0200 (CEST) Date: Fri, 8 Oct 2010 17:19:36 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Message-ID: <20101008151936.GJ1733@garage.freebsd.pl> References: <4CADA4D5.7080204@infracaninophile.co.uk> <4CAE2D6E.7070100@icyb.net.ua> <4CAE3D29.2020309@infracaninophile.co.uk> <4CAE4884.8080608@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huBJOJF9BsF479P6" Content-Disposition: inline In-Reply-To: <4CAE4884.8080608@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Multiple zdevs in the root zpool? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:43:36 -0000 --huBJOJF9BsF479P6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 08, 2010 at 01:24:04AM +0300, Andriy Gapon wrote: > on 08/10/2010 00:35 Matthew Seaman said the following: > > On 07/10/2010 21:28:30, Andriy Gapon wrote: > >> on 07/10/2010 13:45 Matthew Seaman said the following: > >>> However, according to my understanding, if you want to boot from a > >>> zpool, you can only have one vdev in that pool. > >>> > >>> But what exactly does this mean? > >> > >> Yes, exactly, what does that mean? :) > >> Where did your understanding come from? > >> > >=20 > > It was from reading posts like this: > > http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/21167= 7.html > >=20 > > Plus the comments in > > cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c and > > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (grep for > > the words 'root pool') >=20 > Hmm, it seems like a protection for limitations of OpenSolaris boot loade= r that > slipped into our sources. > I am pretty sure that our boot code can boot such pools without problems. FreeBSD doesn't have OpenSolaris limitations when it comes to booting. You can boot from multi-vdev pools, from RAIDZ1, RAIDZ2, etc. There are some comments in the code that comes from OpenSolaris and suggests otherwise, but simply ignore them. There is also one change to be merged soon, that removes a check that prevents adding new vdevs when bootfs property is set (r212385). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --huBJOJF9BsF479P6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyvNocACgkQForvXbEpPzQC9QCfU0q3Ayu6rB4Uxe06AnSeyZ/C Sm4AoMd3/jN9lZIqzcc4ax9PeZkL3yjN =I0na -----END PGP SIGNATURE----- --huBJOJF9BsF479P6-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 16:12:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B1E1065672 for ; Fri, 8 Oct 2010 16:12:46 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id C425C8FC12 for ; Fri, 8 Oct 2010 16:12:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0L9Z00I18BOGVD40@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Fri, 08 Oct 2010 18:12:16 +0200 (CEST) Received: from kg-v2.kg4.no ([80.203.109.34]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0L9Z0090RBOG3EA0@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Fri, 08 Oct 2010 18:12:16 +0200 (CEST) Date: Fri, 08 Oct 2010 18:12:13 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> In-reply-to: <20101008091231.GS2532@e-Gitt.NET> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:12:46 -0000 This is straying a bit, but I think it is important: the only good measure of when a technology is too old, is when people (who use FreeBSD in this case) stop using it. On Fri, 08 Oct 2010 11:12:32 +0200 Oliver Brandmueller wrote: > Maybe you don't really want to hear this, but... > > ISDN is a dying technology. Any time soon you won't get ISDN termination > by your telecom provider anymore. If at all, theyll deliver S0 in your > home while doing VoIP from that little box on your wall. I don't know how it works in other countries, but here (in Norway) it works like this: yes - ISDN technology is dying. However, like all other technologies that major telcos have invested a lot in, its death is very slow. Extremely slow in fact. It could very well be that ISDN will live five or ten years still here, simply because it doesn't cost too much to maintain, and there is no new technology to push the dying ISDN over the edge off the cliff. Why is this? Well, telcos here are investing in mobile technologies for phones. They are _not_ interested in (and do not invest significant money in) things like VoIP. In fact, major telcos here doesn't invest significant money in fibre cables. They only put as much money into it as they need to keep the competition at bay. So who is investing in VoIP and fibre cables here? Answer: the ISP's that doesn't have any large investments in traditional telco cables. Another thing about VoIP calls: have they solved the "emergency call needs a location" problem? Here (again: in Norway) they are still working out how to solve this: if you call emergency services (police, fire department, etc.) from yout VoIP number; how do the emergency center locate you? I mean; how do they know that you are at home, and not at say, a cabin half across the country? With old landlines, there is no problem; it is always installed at an address. Just my point of view. -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 16:22:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B4F5106566C for ; Fri, 8 Oct 2010 16:22:38 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D06D18FC16 for ; Fri, 8 Oct 2010 16:22:37 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:492e:df18:69d9:a06f] (unknown [IPv6:2001:7b8:3a7:0:492e:df18:69d9:a06f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 26C275C43 for ; Fri, 8 Oct 2010 18:22:37 +0200 (CEST) Message-ID: <4CAF4550.90607@FreeBSD.org> Date: Fri, 08 Oct 2010 18:22:40 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12pre) Gecko/20101007 Lanikai/3.1.6pre MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:22:38 -0000 On 2010-10-08 18:12, Torfinn Ingolfsen wrote: > Another thing about VoIP calls: have they solved the "emergency call > needs a location" problem? Here (again: in Norway) they are still > working out how to solve this: if you call emergency services (police, > fire department, etc.) from yout VoIP number; how do the emergency > center locate you? Ehm, you tell them? You have them on the phone. :) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:21:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5573F1065673 for ; Fri, 8 Oct 2010 17:21:17 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5B828FC15 for ; Fri, 8 Oct 2010 17:20:57 +0000 (UTC) Received: by gyg4 with SMTP id 4so501275gyg.13 for ; Fri, 08 Oct 2010 10:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6x2o64XPf8owyCe3Dpj0Gky31UFKUt+Gfheth8wiW6g=; b=ISB/7gc6b/rEJK82e2Zj4Wj2FcEP2kSX7hGCeSUFZfJyLL8y1Glqxf+J56rvvqPs8n sXiDFM17mAdZS/OMtduZQ/wvd8AMwHl3lgmea6fp0YOHySJsQlYsC2lgate1MSIBOhcd CjiXxRxATAKc6NnirJWjlrv60DFEOvsTQyZmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Cs9oA1X0P5/ad7mHfpbC3Akt1/g35FbbgxGEsqbBHFxbp3bg6Lek9g9GK5lbFb4r3u 5ZRfZ3ci0dl6ehaQvC/aqg0tdwIjPzdgpkE0IqX1Odny6Wh+d+LAcqpJmVNsnwaheppN hTi/ivxJt2mlWs/ljSvYdCsQDguqthRGg8shw= MIME-Version: 1.0 Received: by 10.101.5.7 with SMTP id h7mr784990ani.152.1286557803080; Fri, 08 Oct 2010 10:10:03 -0700 (PDT) Received: by 10.100.191.9 with HTTP; Fri, 8 Oct 2010 10:08:50 -0700 (PDT) Date: Fri, 8 Oct 2010 13:08:50 -0400 Message-ID: From: Adam Stylinski To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:21:17 -0000 I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:21:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0131065674 for ; Fri, 8 Oct 2010 17:21:17 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1BB8FC1F for ; Fri, 8 Oct 2010 17:21:04 +0000 (UTC) Received: by gyg4 with SMTP id 4so501362gyg.13 for ; Fri, 08 Oct 2010 10:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6x2o64XPf8owyCe3Dpj0Gky31UFKUt+Gfheth8wiW6g=; b=ISB/7gc6b/rEJK82e2Zj4Wj2FcEP2kSX7hGCeSUFZfJyLL8y1Glqxf+J56rvvqPs8n sXiDFM17mAdZS/OMtduZQ/wvd8AMwHl3lgmea6fp0YOHySJsQlYsC2lgate1MSIBOhcd CjiXxRxATAKc6NnirJWjlrv60DFEOvsTQyZmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Cs9oA1X0P5/ad7mHfpbC3Akt1/g35FbbgxGEsqbBHFxbp3bg6Lek9g9GK5lbFb4r3u 5ZRfZ3ci0dl6ehaQvC/aqg0tdwIjPzdgpkE0IqX1Odny6Wh+d+LAcqpJmVNsnwaheppN hTi/ivxJt2mlWs/ljSvYdCsQDguqthRGg8shw= MIME-Version: 1.0 Received: by 10.101.5.7 with SMTP id h7mr784990ani.152.1286557803080; Fri, 08 Oct 2010 10:10:03 -0700 (PDT) Received: by 10.100.191.9 with HTTP; Fri, 8 Oct 2010 10:08:50 -0700 (PDT) Date: Fri, 8 Oct 2010 13:08:50 -0400 Message-ID: From: Adam Stylinski To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:21:17 -0000 I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:26:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D4A0106566B for ; Fri, 8 Oct 2010 17:26:29 +0000 (UTC) (envelope-from kalstrup@frontier.com) Received: from out01.roch.ny.frontiernet.net (out01.roch.ny.frontiernet.net [66.133.183.226]) by mx1.freebsd.org (Postfix) with ESMTP id 33E678FC12 for ; Fri, 8 Oct 2010 17:26:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPqrkxKa5GX/2dsb2JhbACiP75+hUcEhFGIcYF8hiQ X-IronPort-AV: E=Sophos;i="4.57,303,1283731200"; d="scan'208";a="62214880" Received: from relay02.roch.ny.frontiernet.net ([66.133.182.165]) by out01.roch.ny.frontiernet.net with ESMTP; 08 Oct 2010 16:57:10 +0000 X-Previous-IP: 74.107.145.151 Received: from [192.168.0.16] (pool-74-107-145-151.ptldor.fios.verizon.net [74.107.145.151]) by relay02.roch.ny.frontiernet.net (Postfix) with ESMTPA id 05D1010FA74; Fri, 8 Oct 2010 16:57:08 +0000 (UTC) Message-ID: <4CAF4D64.4050105@frontier.com> Date: Fri, 08 Oct 2010 09:57:08 -0700 From: Kurt Alstrup User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100926 Lightning/1.0b3pre Thunderbird/3.1.3 MIME-Version: 1.0 To: Alan Cox References: <4CAC14DA.7050409@verizon.net> <4CADFD60.9040005@rice.edu> In-Reply-To: <4CADFD60.9040005@rice.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:26:29 -0000 Apologies for late response, wanted to check the code again. On 10/07/2010 10:03 AM, Alan Cox wrote: > Alan Cox wrote: > At a high-level, I agree with much of what you say. In particular, if > pmap_enter() is applied to a virtual address that is already mapped by a large > page, the reported panic could result. However, barring bugs, for example, in > memory allocation by the upper levels of the kernel, the panic inducing > situation shouldn't occur. Calls to malloc() of items larger than a page takes a turn through UMA and eventually ends up in kmem_malloc() via its page_alloc() routine. Kmem_malloc() in turn gets the pages from vm_page_alloc(), parks them in the kmem_object and maps them into the kernel_pmap in a loop callings pmap_enter() for each page. The assigned VA's are pulled from kmem_map. Pages acquired through vm_page_alloc() may be backed by a super page reservation and thus are eligible for auto-promotion. Calls to free() initially take a similar route, ending up on kmem_free() via UMAs page_free() routine. From there the call path is vm_map_remove(), vm_map_remove(), vm_map_delete() to pmap_remove(). This logic indicate, that from the kernel/vm perspective the malloc/free() pair will map/unmap pages as needed. However, the pmapper never unmaps these pages as far as I can tell. The call path is pmap_remove(), pmap_remove_pte() to pmap_unuse_pt() who ignores the removal because the VA >= VM_MAXUSER_ADDRESS. Without superpages this works fine because pmap_enter() allow replacement of already mapped pages, but it kasserts on replacing a page that falls within a super page. I showed one way for this to happen in my first post. The problem is the safety checks for promotion are tricked into promoting before all pages of an allocation are pmap_entered(). > At a lower-level, it appears that you are misinterpreting what pmap_unuse_pt() > does. It is not pmap_unuse_pt()'s responsibility to clear page table entries, > either for user-space page tables or the kernel page table. When a region of > the kernel virtual address space is deallocated, we do clear the kernel page > table entries. See, for example, pmap_remove_pte() (or pmap_qremove()). I probably messed up the terminology in my post, mixing kernel_map and kmem_map. Also I'm ignoring for the moment where the page table pages come from, just observing that for VAs above user space, the PTE entries are not cleared by calling pmap_remove(). pmap_qremove() does, but it's not used by free(). > This special handling of the kernel page table does create another special > case when we destroy a large page mapping within the kernel address space. We > have to reinsert into the kernel page table the old page table page (for small > page mappings) that was sitting idle while the kernel page table held a large > page mapping in its place. At the same time, all of the page table entries in > this page must be invalidated. This is handled by pmap_remove_pde(). I never understood why invalidation is required following promotion/demotions. The mapping does not change, attributes are the same, so unless the hardware can't cope with co-existing 4K and 2M TLB entries then invalidation seems unnecessary (A&D bits may need to be handled, but that might be quicker than sending IPIs to invalidate). > I'm curious to know more about you were doing when you encountered this > panic. Were you also using ISO images containing large MFS roots? I saw it during sysctls I wrote to dump certain large kernel structures. The MO was to allocate really big formatting buffer using malloc(). Truth be said, I did not see this on 2MB super pages, mine were much smaller and therefore more prone to this. Sincerely, Kurt A From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:20:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F05D106566B for ; Fri, 8 Oct 2010 17:20:10 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2CE58FC18 for ; Fri, 8 Oct 2010 17:20:09 +0000 (UTC) Received: by gwb15 with SMTP id 15so500347gwb.13 for ; Fri, 08 Oct 2010 10:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=p2uBhir7m2rt20rkKT26i2JLRieVAo/ZXxCkzoJ/qlo=; b=f6TPSeWrCZa7xrWUweHr4dVWC+D3eDgVNuzllirXQGFyRvdhis1mOUkiNcD5ZspVDF 7ko2zUm0PtYrYtmv1fP/qLap8SQXSrPHsDPOOEHL4dsCQfdmMezZF5Xbdl8o8yPKt55V kuylMlxHkx2WTg7V/Y3ua9fZEjSLVn+3uSQF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CjXDDSezJrPjocQPmV1EMA8VrqS1jqymzM1tE6/NjsVaujFnAYjCFq1b/L5dhExoQQ jiskjkjErRiJwu3Gm5vf8kJx9CoBmJ8Jgln4vIFWIsXrR1NwHNoPKxDcgweEX9YuThcM 9Duum+U/wzlK/y7lVdrrd1I/vRuNkCjEcrtls= MIME-Version: 1.0 Received: by 10.100.225.1 with SMTP id x1mr782392ang.192.1286557730379; Fri, 08 Oct 2010 10:08:50 -0700 (PDT) Received: by 10.100.191.9 with HTTP; Fri, 8 Oct 2010 10:08:50 -0700 (PDT) Date: Fri, 8 Oct 2010 13:08:50 -0400 Message-ID: From: Adam Stylinski To: freebsd-stable@freebsd.org X-Mailman-Approved-At: Fri, 08 Oct 2010 17:36:31 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:20:10 -0000 I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:38:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EBE3106566C for ; Fri, 8 Oct 2010 17:38:46 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9648FC15 for ; Fri, 8 Oct 2010 17:38:45 +0000 (UTC) Received: by gxk8 with SMTP id 8so507502gxk.13 for ; Fri, 08 Oct 2010 10:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=aDaZa1lYokNbiuWeW+8BvggfxCHZVz/ocprSOgQmvV8=; b=hrd1J57epgD7dQZ3U6vM8QVOxfOWdFR0V+ysAMEFO4O5/UJ9uAgLoRo27qbn2Bkz3k 8l97KWpRO1RV3umO4Qlnpw5sazlr4Y/EYuNARyCjMco2b1i+tslsdX/EXLq6+/1DpIeE BYBGdEe7D0kbZSCmxfMf2u2MRNH3YvwMY29Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F1uQPXzWHruY7EIbtZgjXDWKAfa6QgpChG/+Z5ZFeDqX8WtQxvzLUb1e3BJG0n4y9x QdQI8DUg3Tar6fU4zV4bEq1ngQtR2qL7mVgSYUmGe7IR0W8ADCId5jyaLS7J15ahfqJ0 5bsmqfWxbXDY3//LLFndLYlgtneU2MmThXUCE= MIME-Version: 1.0 Received: by 10.90.63.14 with SMTP id l14mr1761577aga.187.1286557790384; Fri, 08 Oct 2010 10:09:50 -0700 (PDT) Received: by 10.100.191.9 with HTTP; Fri, 8 Oct 2010 10:08:50 -0700 (PDT) Date: Fri, 8 Oct 2010 13:08:50 -0400 Message-ID: From: Adam Stylinski To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:38:46 -0000 I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:39:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F34571065697 for ; Fri, 8 Oct 2010 17:39:55 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id C22308FC18 for ; Fri, 8 Oct 2010 17:39:55 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id DC2F328F731; Fri, 8 Oct 2010 12:39:54 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id DkRi+1so3B7V; Fri, 8 Oct 2010 12:39:54 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 7EF3628F6F1; Fri, 8 Oct 2010 12:39:53 -0500 (CDT) Message-ID: <4CAF5768.4020605@rice.edu> Date: Fri, 08 Oct 2010 12:39:52 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Kurt Alstrup References: <4CAC14DA.7050409@verizon.net> <4CADFD60.9040005@rice.edu> <4CAF4D64.4050105@frontier.com> In-Reply-To: <4CAF4D64.4050105@frontier.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Panic: attempted pmap_enter on 2MB page X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:39:56 -0000 Kurt Alstrup wrote: > Apologies for late response, wanted to check the code again. > > > On 10/07/2010 10:03 AM, Alan Cox wrote: > >> Alan Cox wrote: >> At a high-level, I agree with much of what you say. In particular, if >> pmap_enter() is applied to a virtual address that is already mapped by a large >> page, the reported panic could result. However, barring bugs, for example, in >> memory allocation by the upper levels of the kernel, the panic inducing >> situation shouldn't occur. >> > Calls to malloc() of items larger than a page takes a turn through UMA and > eventually ends up in kmem_malloc() via its page_alloc() routine. > Kmem_malloc() in turn gets the pages from vm_page_alloc(), parks them in > the kmem_object and maps them into the kernel_pmap in a loop callings > pmap_enter() for each page. The assigned VA's are pulled from kmem_map. > Pages acquired through vm_page_alloc() may be backed by a super page > reservation and thus are eligible for auto-promotion. > > Calls to free() initially take a similar route, ending up on kmem_free() > via UMAs page_free() routine. From there the call path is vm_map_remove(), > vm_map_remove(), vm_map_delete() to pmap_remove(). > > This logic indicate, that from the kernel/vm perspective the malloc/free() > pair will map/unmap pages as needed. However, the pmapper never unmaps > these pages as far as I can tell. The call path is pmap_remove(), > pmap_remove_pte() to pmap_unuse_pt() who ignores the removal because the > VA >= VM_MAXUSER_ADDRESS. > > No, consider: static int pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va, pd_entry_t ptepde, vm_page_t *free) { pt_entry_t oldpte; vm_page_t m; PMAP_LOCK_ASSERT(pmap, MA_OWNED); oldpte = pte_load_clear(ptq); pte_load_clear() zeroes the PTE, regardless of whether it is a kernel or user PTE. I'm afraid that I need to catch an airplane. I'll follow up to the rest of your message later. Regards, Alan From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 17:41:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA7D91065693 for ; Fri, 8 Oct 2010 17:41:56 +0000 (UTC) (envelope-from FreeBSD@insightbb.com) Received: from mxsf15.insightbb.com (mxsf15.insightbb.com [74.128.0.97]) by mx1.freebsd.org (Postfix) with ESMTP id 789278FC1C for ; Fri, 8 Oct 2010 17:41:56 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.57,303,1283745600"; d="scan'208";a="185710835" Received: from unknown (HELO asav02.insightbb.com) ([172.31.249.123]) by mxsf15.insightbb.com with ESMTP; 08 Oct 2010 13:13:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmU/APvtrkxKgCiCPGdsb2JhbACHcYxUjXkMAQEBATUtvhOFRwQ X-IronPort-AV: E=Sophos;i="4.57,303,1283745600"; d="scan'208";a="392723274" Received: from 74-128-40-130.dhcp.insightbb.com (HELO laptop2.stevenfriedrich.org) ([74.128.40.130]) by asavout02.manage.insightbb.com with ESMTP; 08 Oct 2010 13:13:03 -0400 From: Steven Friedrich To: freebsd-stable@freebsd.org Date: Fri, 8 Oct 2010 13:13:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.2; i386; ; ) References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> <4CAF4550.90607@FreeBSD.org> In-Reply-To: <4CAF4550.90607@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010081313.03116.FreeBSD@insightbb.com> Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:41:56 -0000 On Friday 08 October 2010 12:22:40 pm Dimitry Andric wrote: > On 2010-10-08 18:12, Torfinn Ingolfsen wrote: > > Another thing about VoIP calls: have they solved the "emergency call > > needs a location" problem? Here (again: in Norway) they are still > > working out how to solve this: if you call emergency services (police, > > fire department, etc.) from yout VoIP number; how do the emergency > > center locate you? > > Ehm, you tell them? You have them on the phone. :) Um, could be a kid that dialed the phone, or someone may have lost consciousness. How can this still be a problem? Congres mandated that all phones have GPS, didn't they? From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 18:18:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D31106566B for ; Fri, 8 Oct 2010 18:18:01 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 327AA8FC0A for ; Fri, 8 Oct 2010 18:17:59 +0000 (UTC) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 7BCAFD1B22D for ; Fri, 8 Oct 2010 20:00:56 +0200 (CEST) Received: from pollux.local.net (unknown [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id 180574C80B7; Fri, 8 Oct 2010 20:00:47 +0200 (CEST) Received: by pollux.local.net (Postfix, from userid 2000) id A637F2842C; Fri, 8 Oct 2010 20:00:46 +0200 (CEST) Date: Fri, 8 Oct 2010 20:00:46 +0200 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20101008180046.GA2867@pollux.local.net> Mail-Followup-To: freebsd-stable@freebsd.org, "C. P. Ghost" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: "C. P. Ghost" Subject: VirtualBox OpenSolaris guest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 18:18:02 -0000 Does anybody know how to correct the audio driver problem of the opensolaris guest? The internet advice to run pfexec update_drv -a -i '"pci8086,2415"' audio810 is better than nothing, but the audio quality is absolutely miserable. It is clearly not the required audio driver. Therefore the flashplayer, i.e. the ***only reason*** why I've installed the opensolaris guest (following the advice of C. P. Ghost on the questions list), is useless:-( The other point is that the installation of additional repositories (needed for mplayer for example, I dislike totem) does not work either. My hope to find an interim solution for the flashplayer nightmare (while waiting for gnash) can be measured by the amount of hours I've spent to get flash - easily and long-term-wise - playing on FreeBSD, Ubuntu, PCBSD... I guess that FreeBSD will never be supported by Adobe. Thanks in advance for any help. Harald Weis From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 18:33:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F045B1065672 for ; Fri, 8 Oct 2010 18:33:33 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8557E8FC13 for ; Fri, 8 Oct 2010 18:33:33 +0000 (UTC) Received: by fxm4 with SMTP id 4so598843fxm.13 for ; Fri, 08 Oct 2010 11:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=yGmDbV7sLWJCCdCCudySe78KqfKON9COEMQBU/YpGIk=; b=bd8aF/JxqMDwT49ekTM19hLy0aotHheOkPNSVwK0hP7xeqJCbDYE8bVVwRVDDijb0D MtpSJj3fapF6CmuwaHHyHfZyUHhYJmobXfm7yuDdRt6Onda+zEph5YJ6sxLIX6g9e1kN zBjcE1bfwc4kwYba9vQBtU1KvM/GllRYNqECg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pOcQGNuu307xsL5MUmxEODKNGeOavo+eyb2/3KaKTfubhDaBmmHdlNgxV0njg9Q2u5 GapXvaAPIajCu4/35tyLs589l8Cq26coDfIWFgBL6erLBLV8jkF3mRwf8h8OvxokqZn/ x3+3GAlaBg9gN3rb9GcbFTWst134lSWSgEjHM= MIME-Version: 1.0 Received: by 10.223.104.70 with SMTP id n6mr3663880fao.53.1286562810673; Fri, 08 Oct 2010 11:33:30 -0700 (PDT) Received: by 10.223.124.203 with HTTP; Fri, 8 Oct 2010 11:33:30 -0700 (PDT) In-Reply-To: <20101008180046.GA2867@pollux.local.net> References: <20101008180046.GA2867@pollux.local.net> Date: Fri, 8 Oct 2010 13:33:30 -0500 Message-ID: From: Adam Vande More To: freebsd-stable@freebsd.org, "C. P. Ghost" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: VirtualBox OpenSolaris guest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 18:33:34 -0000 On Fri, Oct 8, 2010 at 1:00 PM, Harald Weis wrote: > Does anybody know how to correct the audio driver problem of the > opensolaris guest? > The internet advice to run > pfexec update_drv -a -i '"pci8086,2415"' audio810 > > is better than nothing, but the audio quality is absolutely miserable. > It is clearly not the required audio driver. > Therefore the flashplayer, i.e. the ***only reason*** why I've installed > the opensolaris guest (following the advice of C. P. Ghost < > cpghost@cordula.ws> > on the questions list), is useless:-( > http://www.freebsd.org/doc/handbook/desktop-browsers.html -- No need for that run around. Flash at least mostly works on FreeBSD. Has some stall issues but flashblock takes care of most of that issue. Works that way for me across multiple installs and versions of FreeBSD(7 & 8). FreeBSD 7 requires a bit more work with the linuxulator. (while waiting for gnash) > That's the funniest thing I've heard all week. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 18:47:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D88191065673 for ; Fri, 8 Oct 2010 18:47:28 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4E28FC1A for ; Fri, 8 Oct 2010 18:47:28 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id GF621f07S0vyq2s5BJaD3Y; Fri, 08 Oct 2010 18:34:13 +0000 Received: from hanssachs.home ([24.61.85.144]) by omta05.westchester.pa.mail.comcast.net with comcast id GJaD1f00436qgMk3RJaDRj; Fri, 08 Oct 2010 18:34:13 +0000 Received: from algo by hanssachs.home with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4Hlj-000OG8-L8; Fri, 08 Oct 2010 14:34:11 -0400 Date: Fri, 08 Oct 2010 14:34:11 -0400 Message-Id: From: Alex Goncharov To: Harald Weis In-reply-to: <20101008180046.GA2867@pollux.local.net> (message from Harald Weis on Fri, 8 Oct 2010 20:00:46 +0200) References: <20101008180046.GA2867@pollux.local.net> Sender: Alex Goncharov Cc: freebsd-stable@freebsd.org Subject: Re: VirtualBox OpenSolaris guest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 18:47:28 -0000 ,--- You/Harald (Fri, 8 Oct 2010 20:00:46 +0200) ----* | My hope to find an interim solution for the flashplayer nightmare | (while waiting for gnash) can be measured by the amount of hours | I've spent to get flash - easily and long-term-wise - playing on FreeBSD, | Ubuntu, PCBSD... | | I guess that FreeBSD will never be supported by Adobe. Flash works beautifully for me on FreeBSD 8.1 in both Firefox 3.6 (use the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html) and in Opera (linux and native.) Is your problem "flash" or "audio" (i.e. can you play an mp3 file with mpg123, for example)? -- Alex -- alex-goncharov@comcast.net -- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 18:55:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA15106564A for ; Fri, 8 Oct 2010 18:55:15 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.52]) by mx1.freebsd.org (Postfix) with ESMTP id AA9488FC15 for ; Fri, 8 Oct 2010 18:55:15 +0000 (UTC) Received: (qmail 3747 invoked from network); 8 Oct 2010 18:28:33 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Oct 2010 18:28:33 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id B054550867; Fri, 8 Oct 2010 14:28:32 -0400 (EDT) From: Lowell Gilbert To: freebsd-stable@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> <4CAF4550.90607@FreeBSD.org> <201010081313.03116.FreeBSD@insightbb.com> Date: Fri, 08 Oct 2010 14:28:32 -0400 In-Reply-To: <201010081313.03116.FreeBSD@insightbb.com> (Steven Friedrich's message of "Fri, 8 Oct 2010 13:13:02 -0400") Message-ID: <44hbgwcze7.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 18:55:15 -0000 Steven Friedrich writes: > On Friday 08 October 2010 12:22:40 pm Dimitry Andric wrote: >> On 2010-10-08 18:12, Torfinn Ingolfsen wrote: >> > Another thing about VoIP calls: have they solved the "emergency call >> > needs a location" problem? Here (again: in Norway) they are still >> > working out how to solve this: if you call emergency services (police, >> > fire department, etc.) from yout VoIP number; how do the emergency >> > center locate you? >> >> Ehm, you tell them? You have them on the phone. :) > > Um, could be a kid that dialed the phone, or someone may have lost > consciousness. > > How can this still be a problem? Congres mandated that all phones have GPS, > didn't they? No. Not even cell phones have to have GPS. For Internet-based telephony, the regulatory requirement involves customer cooperation, not technology. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 19:05:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F2A106564A for ; Fri, 8 Oct 2010 19:05:16 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BAB1F8FC0A for ; Fri, 8 Oct 2010 19:05:15 +0000 (UTC) Received: by qwe4 with SMTP id 4so315829qwe.13 for ; Fri, 08 Oct 2010 12:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9mGbVqCTArCBZ2J02U2FSTUHAtDtgz287dUyvXUaVVE=; b=AG7DdMUfgF+BrL37Yc/795XZPlFR/8cRr+zs7aAHi79NYyIwokA4Zu7h3zQ2rRARiY uzjvO3tyPvMh3FWgKE5j17AFSIPFAwI/3BuMFSEoKA066rDLCOjHCSLKoOY6LnwyWgeq hxedi8S2mrErPq0k/6hx+ahCQfWws/a2c6lf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=L5Ns4MbvjVAfaSoKVyzhMUmlHlbE21yJOgO8SyuH5MNM4NKHGynJnqDvFSU2Hfq7Di bkS5BZJIXoSOs5YtTIYyralGr7k4cWNKfpdVfyt2HLket/lhQzHDwsIF6qRBBrv6Kpii y+PBTGqGyFUDyJAUlz385yb4vviHP0osA7ij0= MIME-Version: 1.0 Received: by 10.224.84.77 with SMTP id i13mr1823097qal.317.1286563408753; Fri, 08 Oct 2010 11:43:28 -0700 (PDT) Received: by 10.229.225.132 with HTTP; Fri, 8 Oct 2010 11:43:28 -0700 (PDT) In-Reply-To: <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> Date: Fri, 8 Oct 2010 20:43:28 +0200 Message-ID: From: Christian Walther To: Torfinn Ingolfsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:05:16 -0000 On 8 October 2010 18:12, Torfinn Ingolfsen wrote: [...] > I don't know how it works in other countries, but here (in Norway) it > works like this: yes - ISDN technology is dying. > However, like all other technologies that major telcos have invested a > lot in, its death is very slow. Extremely slow in fact. > > It could very well be that ISDN will live five or ten years still here, > simply because it doesn't cost too much to maintain, and there is no > new technology to push the dying ISDN over the edge off the cliff. I second that. Living in germany I feel that many people are even used to their good ol' analog phone lines. And since broadband here is called "DSL" we need phone lines anyway. So the only reason to call classic telephone services would be to use the freed frequency to extend the bandwith available to DSL. And I don't see that happen anytime soon. On the contrary, with all the investments in wireless technologies I think that ISDN will stay for several years. Personally I like having a good, solid backup when DSL goes down. And I don't trust VoIP enough to shut down my classic telephone lines. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 19:08:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F0D51065693; Fri, 8 Oct 2010 19:08:47 +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 E3A638FC17; Fri, 8 Oct 2010 19:08:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9178446B53; Fri, 8 Oct 2010 15:08:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07D978A050; Fri, 8 Oct 2010 15:08:45 -0400 (EDT) From: John Baldwin To: "Daniel O'Connor" Date: Fri, 8 Oct 2010 15:04:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CB5FCB2-E11B-456A-B574-D10431A0C871@gsoft.com.au> In-Reply-To: <4CB5FCB2-E11B-456A-B574-D10431A0C871@gsoft.com.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010081504.49924.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 08 Oct 2010 15:08:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable Stable , Andriy Gapon Subject: Re: Enabling MCA causes system hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:08:47 -0000 On Sunday, October 03, 2010 2:49:27 am Daniel O'Connor wrote: > > On 14/09/2010, at 16:49, Daniel O'Connor wrote: > >> So, you either have to disable one of them or upgrade to a more recent version. > >> The version you need is r206183. The latest stable/8 would do, obviously. > > > > I'll try updating to stable/8 - I've been meaning to anyway. > > > > Just to find the spare time to do it :) > > I found some time, and now it seems to work fine. > > Thanks! :) > > I also wrapped http://ftp2.pl.freebsd.org/pub/FreeBSD/HEAD/src/sbin/mca/mca.c in a script and run it every hour. > > Is there a periodic in current for it? IMO it would be handy to do so. That command is for ia64, not i386 and amd64. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 19:27:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 551B61065672 for ; Fri, 8 Oct 2010 19:27:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id D89658FC15 for ; Fri, 8 Oct 2010 19:27:49 +0000 (UTC) Received: (qmail 27474 invoked by uid 399); 8 Oct 2010 19:27:47 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Oct 2010 19:27:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CAF70BC.7@FreeBSD.org> Date: Fri, 08 Oct 2010 12:27:56 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> In-Reply-To: <20101008091231.GS2532@e-Gitt.NET> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:27:50 -0000 On 10/8/2010 2:12 AM, Oliver Brandmueller wrote: > ISDN is a dying technology. That sort of isn't relevant to the questions of: 1) Are there developers willing to support it, and 2) Are there users that want to use it. If both of those are true, then we need to do support it. Doug (tools, not policy) -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 19:37:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28D19106566B for ; Fri, 8 Oct 2010 19:37:21 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id F2B248FC14 for ; Fri, 8 Oct 2010 19:37:20 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id A4A372BB341; Fri, 8 Oct 2010 15:37:19 -0400 (EDT) Date: Fri, 8 Oct 2010 15:37:18 -0400 From: "Peter C. Lai" To: Doug Barton Message-ID: <20101008193717.GB70616@cesium.hyperfine.info> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> <4CAF70BC.7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CAF70BC.7@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:37:21 -0000 Or have they been superceded by voip stacks that abstract away the isdn layer? I would contend, at least in the US, ISDN is alive and well. Your basic smb softpbx installation is going to be talking to a digium card that is connected to a Basic/Primary Rate ISDN (B/PRI) or T-line. If the OP is using I4B to do voice data processing, perhaps he would be better served migrating to either freeswitch and/or asterisk ports? On 2010-10-08 12:27:56PM -0700, Doug Barton wrote: > On 10/8/2010 2:12 AM, Oliver Brandmueller wrote: > > ISDN is a dying technology. > > That sort of isn't relevant to the questions of: > 1) Are there developers willing to support it, and > 2) Are there users that want to use it. > > If both of those are true, then we need to do support it. > > > Doug (tools, not policy) > > -- > > Breadth of IT experience, and | Nothin' ever doesn't change, > depth of knowledge in the DNS. | but nothin' changes much. > Yours for the right price. :) | -- OK Go > http://SupersetSolutions.com/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 19:42:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DF5A106564A for ; Fri, 8 Oct 2010 19:42:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id CE7D08FC14 for ; Fri, 8 Oct 2010 19:42:21 +0000 (UTC) Received: (qmail 17438 invoked by uid 399); 8 Oct 2010 19:42:20 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Oct 2010 19:42:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CAF7426.2070104@FreeBSD.org> Date: Fri, 08 Oct 2010 12:42:30 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> <4CAF70BC.7@FreeBSD.org> <20101008193717.GB70616@cesium.hyperfine.info> In-Reply-To: <20101008193717.GB70616@cesium.hyperfine.info> X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:42:22 -0000 On 10/8/2010 12:37 PM, Peter C. Lai wrote: > If the OP is using I4B to do voice data processing, perhaps he would > be better served migrating to either freeswitch and/or asterisk ports? That's a policy decision. We don't do policy decisions, we do technology. I'll say it again, "Tools, not policy." -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 20:47:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579FE106566C for ; Fri, 8 Oct 2010 20:47:44 +0000 (UTC) (envelope-from stylinae@mail.uc.edu) Received: from bay0-omc3-s4.bay0.hotmail.com (bay0-omc3-s4.bay0.hotmail.com [65.54.190.142]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1CC8FC13 for ; Fri, 8 Oct 2010 20:47:43 +0000 (UTC) Received: from BL2PRD0103HT015.prod.exchangelabs.com ([65.54.190.189]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Oct 2010 13:35:42 -0700 Received: from mail-yw0-f54.google.com (209.85.213.54) by pod51000.outlook.com (10.6.4.250) with Microsoft SMTP Server (TLS) id 14.0.650.49; Fri, 8 Oct 2010 20:35:41 +0000 Received: by ywh2 with SMTP id 2so118133ywh.13 for ; Fri, 08 Oct 2010 13:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.174.13 with SMTP id w13mr963965ane.227.1286570141103; Fri, 08 Oct 2010 13:35:41 -0700 (PDT) Received: by 10.100.191.9 with HTTP; Fri, 8 Oct 2010 13:35:41 -0700 (PDT) Date: Fri, 8 Oct 2010 16:35:41 -0400 Message-ID: From: Adam Stylinski To: X-MS-Exchange-Transport-Rules-Loop: 0 X-OriginalArrivalTime: 08 Oct 2010 20:35:42.0603 (UTC) FILETIME=[608765B0:01CB6728] Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 20:47:44 -0000 I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 20:59:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2D6A1065674 for ; Fri, 8 Oct 2010 20:59:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id A74258FC1B for ; Fri, 8 Oct 2010 20:59:41 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta03.emeryville.ca.mail.comcast.net with comcast id GGJT1f0020lTkoCA3Lzh4M; Fri, 08 Oct 2010 20:59:41 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta04.emeryville.ca.mail.comcast.net with comcast id GLzg1f0053LrwQ28QLzgBD; Fri, 08 Oct 2010 20:59:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA95C9B418; Fri, 8 Oct 2010 13:59:39 -0700 (PDT) Date: Fri, 8 Oct 2010 13:59:39 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20101008205939.GA43557@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adam Stylinski , Adam Stylinski Subject: Re: out of HDD space - zfs degraded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 20:59:41 -0000 On Fri, Oct 08, 2010 at 04:35:41PM -0400, Adam Stylinski wrote: > I noticed this is occurring on the siis driver. Silicon Image has, in my > observations, had issues when any kind of port multiplication is occurring > (either by the card itself or by hardware port multiplier that you > purchase). I have timeouts on my drives for my Silicon Image based > controller card if I use more than two ports (it was two eSATA and two > internal SATA). If you search the mailing list other people have similar > issues who use port multipliers. I've had good, brand new drives timeout > randomly with this driver. Off-topic (and normally I'd send this privately, but I think 5 Emails to the list of the same content is enough to warrant a list-based response): Your mailer is going crazy. I've received a total of *five* Emails from you on this matter, all with the same content, but all sent at different times and all contain different (unique) submission queue IDs. My client: 661 10/08 13:08 Adam Stylinski (0.7K) └─> 662 10/08 13:08 Adam Stylinski (0.7K) ├=> 663 10/08 13:08 Adam Stylinski (0.7K) ├=> 664 10/08 13:08 Adam Stylinski (0.7K) ├=> 665 10/08 16:35 Adam Stylinski (0.7K) └─> The SMTP Received: headers, indicating its your mail client or mail server which is sending duplicates to gmail. I should note your From: line for #665 differs from all the rest, as do the mail headers. #661 -- Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5B828FC15 for ; Fri, 8 Oct 2010 17:20:57 +0000 (UTC) Received: by gyg4 with SMTP id 4so501275gyg.13 for ; Fri, 08 Oct 2010 10:20:36 -0700 (PDT) #662 -- Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1BB8FC1F for ; Fri, 8 Oct 2010 17:21:04 +0000 (UTC) Received: by gyg4 with SMTP id 4so501362gyg.13 for ; Fri, 08 Oct 2010 10:20:56 -0700 (PDT) #663 -- Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2CE58FC18 for ; Fri, 8 Oct 2010 17:20:09 +0000 (UTC) Received: by gwb15 with SMTP id 15so500347gwb.13 for ; Fri, 08 Oct 2010 10:20:09 -0700 (PDT) #664 -- Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9648FC15 for ; Fri, 8 Oct 2010 17:38:45 +0000 (UTC) Received: by gxk8 with SMTP id 8so507502gxk.13 for ; Fri, 08 Oct 2010 10:38:45 -0700 (PDT) #665 -- Received: from mail-yw0-f54.google.com (209.85.213.54) by pod51000.outlook.com (10.6.4.250) with Microsoft SMTP Server (TLS) id 14.0.650.49; Fri, 8 Oct 2010 20:35:41 +0000 Received: by ywh2 with SMTP id 2so118133ywh.13 for ; Fri, 08 Oct 2010 13:35:41 -0700 (PDT) Please do something about this, as it's highly irritating. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Oct 8 22:40:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC6DF106564A for ; Fri, 8 Oct 2010 22:40:36 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 743C08FC08 for ; Fri, 8 Oct 2010 22:40:36 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from terra-smin.broadpark.no ([80.202.8.13]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0L9Z003QATNL2Z60@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Sat, 09 Oct 2010 00:40:33 +0200 (CEST) Received: from kg-v2.kg4.no ([80.203.109.34]) by terra-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with SMTP id <0L9Z00DQZTNL1XF0@terra-smin.broadpark.no> for freebsd-stable@freebsd.org; Sat, 09 Oct 2010 00:40:33 +0200 (CEST) Date: Sat, 09 Oct 2010 00:40:33 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20101009004033.d34998cb.torfinn.ingolfsen@broadpark.no> In-reply-to: <4CAF4550.90607@FreeBSD.org> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <4C8627A6.1090308@icyb.net.ua> <20101008091231.GS2532@e-Gitt.NET> <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> <4CAF4550.90607@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 22:40:36 -0000 On Fri, 08 Oct 2010 18:22:40 +0200 Dimitry Andric wrote: > On 2010-10-08 18:12, Torfinn Ingolfsen wrote: > > Another thing about VoIP calls: have they solved the "emergency call > > needs a location" problem? Here (again: in Norway) they are still > > working out how to solve this: if you call emergency services (police, > > fire department, etc.) from yout VoIP number; how do the emergency > > center locate you? > > Ehm, you tell them? You have them on the phone. :) If you are in a state to tell them, yes of course you do. However, the situtation might mean that you aren't very coherent at all. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 07:11:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79522106566C for ; Sat, 9 Oct 2010 07:11:11 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 58F6C8FC08 for ; Sat, 9 Oct 2010 07:11:11 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o997BAtK009560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 9 Oct 2010 00:11:10 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o997BA5P009559; Sat, 9 Oct 2010 00:11:10 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA18680; Sat, 9 Oct 10 00:08:47 PDT Date: Sat, 09 Oct 2010 00:08:39 -0700 From: perryh@pluto.rain.com To: FreeBSD@insightbb.com Message-Id: <4cb014f7.v20YBE7K8CIaLBpz%perryh@pluto.rain.com> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <20101008181213.c9511a15.torfinn.ingolfsen@broadpark.no> <4CAF4550.90607@FreeBSD.org> <201010081313.03116.FreeBSD@insightbb.com> In-Reply-To: <201010081313.03116.FreeBSD@insightbb.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ISDN4BSD removal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 07:11:11 -0000 Steven Friedrich wrote: > On Friday 08 October 2010 12:22:40 pm Dimitry Andric wrote: > > On 2010-10-08 18:12, Torfinn Ingolfsen wrote: > > > Another thing about VoIP calls: have they solved the > > > "emergency call needs a location" problem? Here (again: in > > > Norway) they are still working out how to solve this: if you > > > call emergency services (police, fire department, etc.) from > > > yout VoIP number; how do the emergency center locate you? > > > > Ehm, you tell them? You have them on the phone. :) > > Um, could be a kid that dialed the phone, or someone may have > lost consciousness. Or still be conscious, but unable to speak for one reason or another, choking being the first example that comes to mind; or is just too stressed out by the situation to be coherent. Originally, at least in the U.S., 911 systems had no automatic locator mechanism and depended on the caller being able to provide location. It didn't take all that long to discover that a small but significant fraction of very serious emergencies demanded more. > How can this still be a problem? Congres mandated that all > phones have GPS, didn't they? Er, did you miss the part about "in Norway"? I somehow doubt that any U.S. mandate, even if one existed, would apply there. BTW cell phones are nowhere near as troublesome in this regard as VoIP. With cell, dispatch at least knows that the caller is within range of the tower that's handling the call. With VoIP they could be halfway around the world. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 14:55:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 785F6106566B for ; Sat, 9 Oct 2010 14:55:08 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.freebsd.org (Postfix) with SMTP id 061638FC0A for ; Sat, 9 Oct 2010 14:55:07 +0000 (UTC) Received: (qmail 21100 invoked from network); 9 Oct 2010 14:55:07 -0000 Received: from smtp.irbisnet.com (andriy@99.235.226.221 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 09 Oct 2010 07:55:06 -0700 PDT X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- X-YMail-OSG: lxj2XXEVM1mL.tU9HRkmISBAe5HCbOolKKWxWDeiIgwsHyO dYq5oGv4TAM4eRu1FRTBfh9.jjkx0He72cZs4fJLkncnb0RpDET4V.4eXR8U jIx6Yc4CPdWV9xitHAmasi8lOjWjAwNW4LDLboR4WXD4UD3hSO0tDue15mdF x60pKStio95VvvQwYVsj2jTPze6EGsnybLUjZO6mxR5cQE1sHAikGFiXm9uG XxP_Ntr1yud1MpM8n5sIKPjZngy1asOGgMX0REyqlf6ojJo2aSAPSgB..uTC lznkTcdKTp.S1kjHvFbJp7VgTPB83RW5Mxl30cGpyaBSk8IpMav88HT3.CYA GjKvTU0GqHCLfWwvRN74NkX1A2n_t38mVdbshEbYNfqJ2aSrPPpH17VzD8tM 4VZlUwXEZTRDqTPS3MPR3bZl4Wd3gLQimVWuHj98DRlaFQA-- X-Yahoo-Newman-Property: ymail-3 Received: from [10.123.50.70] (unknown [74.198.12.74]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 262CFA4F6; Sat, 9 Oct 2010 10:55:06 -0400 (EDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <169A4F62-0509-4AE9-A4A5-F9CADD08140D@irbisnet.com> X-Mailer: iPhone Mail (8B117) From: Andriy Bakay Date: Sat, 9 Oct 2010 10:55:35 -0400 To: Pete French , Andriy Gapon Cc: "freebsd-fs@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 14:55:08 -0000 Do you know any more convenient way (except make buildword, etc.) to upgrade= /update several boxes to STABLE on regular basis? Something like freebsd-upd= ate or maybe some process, tips, tricks, etc? Thanks. On 2010-10-08, at 6:11, Pete French wrote: >> Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is yo= ur opinion? >=20 > I am running 8-STABLE from 27th September on all our ptoduction > machines (from webservers to database servers to the company mail > server) and it is fine. I am going to update again over the next > few days, as there are some ZFS fixes in which I want - and which > may benifit you too - so I will be able to report back next > week as to how a more recent version behaves. >=20 > In general though, I have never had problems running STABLE on > prodyction systems over the years. Of course what I do is to test it > on a singlre machine before rolling it out (a leaf in a webfarm > so if it goes down it wont affect the business) but it is usually > fine. keep an eye on -STABLE mailing list though, as that is where > problems arise. I watch that, and also the dailing commits, either here >=20 > http://www.freshbsd.org/?branch=3DRELENG_8&project=3Dfreebsd&committer=3D&= module=3D&q=3D >=20 > or here >=20 > http://www.secnetix.de/olli/FreeBSD/svnews/?p=3Dstable/8 >=20 > Just to see whats going into the tree relative to whats being discussed. > It only takes a few minutes a dat to monitor the mailin lists and the > commits, and the result is that we've been running STABLE for a very > long time (close to a decade I suspect) with great success. >=20 > -pete. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 15:57:39 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 677CD106564A; Sat, 9 Oct 2010 15:57:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF168FC14; Sat, 9 Oct 2010 15:57:39 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o99FvTOJ010700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2010 11:57:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.4/8.14.4) with ESMTP id o99FvTVY043360; Sat, 9 Oct 2010 11:57:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 4A0961B5060; Sat, 9 Oct 2010 11:57:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20101009155729.4A0961B5060@freebsd-stable.sentex.ca> Date: Sat, 9 Oct 2010 11:57:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 15:57:39 -0000 TB --- 2010-10-09 14:18:05 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-10-09 14:18:05 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-10-09 14:18:05 - cleaning the object tree TB --- 2010-10-09 14:18:38 - cvsupping the source tree TB --- 2010-10-09 14:18:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-10-09 14:18:50 - building world TB --- 2010-10-09 14:18:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-09 14:18:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-09 14:18:50 - TARGET=amd64 TB --- 2010-10-09 14:18:50 - TARGET_ARCH=amd64 TB --- 2010-10-09 14:18:50 - TZ=UTC TB --- 2010-10-09 14:18:50 - __MAKE_CONF=/dev/null TB --- 2010-10-09 14:18:50 - cd /src TB --- 2010-10-09 14:18:50 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 9 14:18:51 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 9 15:49:21 UTC 2010 TB --- 2010-10-09 15:49:21 - generating LINT kernel config TB --- 2010-10-09 15:49:21 - cd /src/sys/amd64/conf TB --- 2010-10-09 15:49:21 - /usr/bin/make -B LINT TB --- 2010-10-09 15:49:21 - building LINT kernel TB --- 2010-10-09 15:49:21 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-09 15:49:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-09 15:49:21 - TARGET=amd64 TB --- 2010-10-09 15:49:21 - TARGET_ARCH=amd64 TB --- 2010-10-09 15:49:21 - TZ=UTC TB --- 2010-10-09 15:49:21 - __MAKE_CONF=/dev/null TB --- 2010-10-09 15:49:21 - cd /src TB --- 2010-10-09 15:49:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 9 15:49:21 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/sdhci/sdhci.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/sf/if_sf.c /src/sys/dev/sf/if_sf.c: In function 'sf_poll': /src/sys/dev/sf/if_sf.c:1827: error: 'rx_npkts' undeclared (first use in this function) /src/sys/dev/sf/if_sf.c:1827: error: (Each undeclared identifier is reported only once /src/sys/dev/sf/if_sf.c:1827: error: for each function it appears in.) cc1: warnings being treated as errors /src/sys/dev/sf/if_sf.c:1827: warning: 'return' with a value, in function returning void *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-09 15:57:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-09 15:57:29 - ERROR: failed to build lint kernel TB --- 2010-10-09 15:57:29 - 4972.50 user 554.31 system 5963.77 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 16:49:31 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92AD51065670; Sat, 9 Oct 2010 16:49:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5018FC17; Sat, 9 Oct 2010 16:49:31 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o99GnMX0012946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2010 12:49:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.4/8.14.4) with ESMTP id o99GnLNf075958; Sat, 9 Oct 2010 12:49:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 9413D1B5060; Sat, 9 Oct 2010 12:49:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20101009164921.9413D1B5060@freebsd-stable.sentex.ca> Date: Sat, 9 Oct 2010 12:49:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 16:49:31 -0000 TB --- 2010-10-09 15:35:24 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-10-09 15:35:24 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-10-09 15:35:24 - cleaning the object tree TB --- 2010-10-09 15:35:46 - cvsupping the source tree TB --- 2010-10-09 15:35:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-10-09 15:35:57 - building world TB --- 2010-10-09 15:35:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-09 15:35:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-09 15:35:57 - TARGET=i386 TB --- 2010-10-09 15:35:57 - TARGET_ARCH=i386 TB --- 2010-10-09 15:35:57 - TZ=UTC TB --- 2010-10-09 15:35:57 - __MAKE_CONF=/dev/null TB --- 2010-10-09 15:35:57 - cd /src TB --- 2010-10-09 15:35:57 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 9 15:35:58 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 9 16:40:40 UTC 2010 TB --- 2010-10-09 16:40:40 - generating LINT kernel config TB --- 2010-10-09 16:40:40 - cd /src/sys/i386/conf TB --- 2010-10-09 16:40:40 - /usr/bin/make -B LINT TB --- 2010-10-09 16:40:40 - building LINT kernel TB --- 2010-10-09 16:40:40 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-09 16:40:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-09 16:40:40 - TARGET=i386 TB --- 2010-10-09 16:40:40 - TARGET_ARCH=i386 TB --- 2010-10-09 16:40:40 - TZ=UTC TB --- 2010-10-09 16:40:40 - __MAKE_CONF=/dev/null TB --- 2010-10-09 16:40:40 - cd /src TB --- 2010-10-09 16:40:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 9 16:40:40 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/sdhci/sdhci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/sf/if_sf.c /src/sys/dev/sf/if_sf.c: In function 'sf_poll': /src/sys/dev/sf/if_sf.c:1827: error: 'rx_npkts' undeclared (first use in this function) /src/sys/dev/sf/if_sf.c:1827: error: (Each undeclared identifier is reported only once /src/sys/dev/sf/if_sf.c:1827: error: for each function it appears in.) cc1: warnings being treated as errors /src/sys/dev/sf/if_sf.c:1827: warning: 'return' with a value, in function returning void *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-09 16:49:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-09 16:49:21 - ERROR: failed to build lint kernel TB --- 2010-10-09 16:49:21 - 3704.47 user 385.04 system 4436.92 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 17:09:29 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232B210656B4; Sat, 9 Oct 2010 17:09:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (unknown [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7218FC33; Sat, 9 Oct 2010 17:09:28 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id o99H9KhW013754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2010 13:09:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.4/8.14.4) with ESMTP id o99H9JoF088289; Sat, 9 Oct 2010 13:09:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id D14BC1B5060; Sat, 9 Oct 2010 13:09:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20101009170919.D14BC1B5060@freebsd-stable.sentex.ca> Date: Sat, 9 Oct 2010 13:09:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.67 on 64.7.153.18 Cc: Subject: [releng_7 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 17:09:29 -0000 TB --- 2010-10-09 15:57:29 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-10-09 15:57:29 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2010-10-09 15:57:29 - cleaning the object tree TB --- 2010-10-09 15:57:53 - cvsupping the source tree TB --- 2010-10-09 15:57:53 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2010-10-09 15:58:04 - building world TB --- 2010-10-09 15:58:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-09 15:58:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-09 15:58:04 - TARGET=pc98 TB --- 2010-10-09 15:58:04 - TARGET_ARCH=i386 TB --- 2010-10-09 15:58:04 - TZ=UTC TB --- 2010-10-09 15:58:04 - __MAKE_CONF=/dev/null TB --- 2010-10-09 15:58:04 - cd /src TB --- 2010-10-09 15:58:04 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 9 15:58:04 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 9 17:02:18 UTC 2010 TB --- 2010-10-09 17:02:18 - generating LINT kernel config TB --- 2010-10-09 17:02:18 - cd /src/sys/pc98/conf TB --- 2010-10-09 17:02:18 - /usr/bin/make -B LINT TB --- 2010-10-09 17:02:18 - building LINT kernel TB --- 2010-10-09 17:02:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-09 17:02:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-09 17:02:18 - TARGET=pc98 TB --- 2010-10-09 17:02:18 - TARGET_ARCH=i386 TB --- 2010-10-09 17:02:18 - TZ=UTC TB --- 2010-10-09 17:02:18 - __MAKE_CONF=/dev/null TB --- 2010-10-09 17:02:18 - cd /src TB --- 2010-10-09 17:02:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 9 17:02:18 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/scd/scd_isa.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/sdhci/sdhci.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue /src/sys/dev/sf/if_sf.c /src/sys/dev/sf/if_sf.c: In function 'sf_poll': /src/sys/dev/sf/if_sf.c:1827: error: 'rx_npkts' undeclared (first use in this function) /src/sys/dev/sf/if_sf.c:1827: error: (Each undeclared identifier is reported only once /src/sys/dev/sf/if_sf.c:1827: error: for each function it appears in.) /src/sys/dev/sf/if_sf.c:1827: warning: 'return' with a value, in function returning void *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-09 17:09:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-09 17:09:19 - ERROR: failed to build lint kernel TB --- 2010-10-09 17:09:19 - 3573.51 user 388.46 system 4310.48 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 18:39:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CA07106564A for ; Sat, 9 Oct 2010 18:39:08 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C10E8FC14 for ; Sat, 9 Oct 2010 18:39:07 +0000 (UTC) Received: by fxm12 with SMTP id 12so133811fxm.13 for ; Sat, 09 Oct 2010 11:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uyhSlaklpSCLfc89C0EmAoj7QkZLxv+mqm9XyDgnYFw=; b=TrcskHJaCOYlvq/rVzjRbxOldC2FQDg3jnw6SiQP1vH1OC+ei3Ls+asgR5ln92wfsR j6OlHdIn11ICtHJ3UjJCpqRvWPZZ2/wtVG506RWhuUmxQ460ZNbM+/nQomg1LowwgGmg +t4HIPQNh0d/uEH2qHqbi8pjyT1VjVeC7VDEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=roLvbJZ2Gogk9h94NV0jmyuHyua/UfAc0UvsuW6sjEqgFogEQavYd0HmppFQtBFxu4 UtiwmtEhFx+cOmJwKuS4ZTMs4/ZdUJ6uKbVoWSXHhG8tB67DD3IG/uPPJ5U8bzFedK5N b2jxj+MnGNeJmmHIpSW3rrcEWpQl4mu8NZ8Q4= MIME-Version: 1.0 Received: by 10.223.122.137 with SMTP id l9mr665188far.47.1286649546957; Sat, 09 Oct 2010 11:39:06 -0700 (PDT) Received: by 10.223.124.203 with HTTP; Sat, 9 Oct 2010 11:39:06 -0700 (PDT) In-Reply-To: <169A4F62-0509-4AE9-A4A5-F9CADD08140D@irbisnet.com> References: <169A4F62-0509-4AE9-A4A5-F9CADD08140D@irbisnet.com> Date: Sat, 9 Oct 2010 13:39:06 -0500 Message-ID: From: Adam Vande More To: Andriy Bakay Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.). X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 18:39:08 -0000 On Sat, Oct 9, 2010 at 9:55 AM, Andriy Bakay wrote: > Do you know any more convenient way (except make buildword, etc.) to > upgrade/update several boxes to STABLE on regular basis? Something like > freebsd-update or maybe some process, tips, tricks, etc? > Can you not top-post please? Probably the most convenient method is NFS boot the systems and simply update the mfs_root image when needed. However getting that process worked out is tedious. Another method is simply to compile on one machine and use the resulting stuff to install from. Of course there is always ccache and distcc to help speed up the process, although last I tried ccache won't buildworld on amd4. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 20:36:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632EE106566C for ; Sat, 9 Oct 2010 20:36:39 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id DD3C98FC08 for ; Sat, 9 Oct 2010 20:36:36 +0000 (UTC) Received: from pollux.local.net (unknown [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id 8C6014C8070 for ; Sat, 9 Oct 2010 22:36:31 +0200 (CEST) Received: by pollux.local.net (Postfix, from userid 2000) id 1D94128428; Sat, 9 Oct 2010 22:36:30 +0200 (CEST) Date: Sat, 9 Oct 2010 22:36:30 +0200 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20101009203629.GA2135@pollux.local.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20101008180046.GA2867@pollux.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: VirtualBox OpenSolaris guest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 20:36:39 -0000 On Fri, Oct 08, 2010 at 02:34:11PM -0400, Alex Goncharov wrote: > ,--- You/Harald (Fri, 8 Oct 2010 20:00:46 +0200) ----* > | My hope to find an interim solution for the flashplayer nightmare > | (while waiting for gnash) can be measured by the amount of hours > | I've spent to get flash - easily and long-term-wise - playing on FreeBSD, > | Ubuntu, PCBSD... > | > | I guess that FreeBSD will never be supported by Adobe. > > Flash works beautifully for me on FreeBSD 8.1 in both Firefox 3.6 (use > the instructions at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html) > and in Opera (linux and native.) Yes, I know that very well and used it with success many times. There is a message exchange on the questions mailing list - "concerning flash under freebsd" starting on last June 15 - which confirms my own experience of ugly things like npviewer.bin coredumps and browser freezing. I found the suggestion interesting to install VirtualBox and OpenSolaris which is an operating system supported by Adobe. That's the reason why I gave it a try. > Is your problem "flash" or "audio" (i.e. can you play an mp3 file with > mpg123, for example)? "flash" installs like a charm. It's audio. There is no audio whatsoever after a perfectly clean OpenSolaris guest installation. The guest cannot determine the correct audio driver for the underlying audio card. Needless to say that the audio card works for the FreeBSD host (still on 8.0 for the moment). -- Harald From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 20:39:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DA8106564A for ; Sat, 9 Oct 2010 20:39:42 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0F13C8FC22 for ; Sat, 9 Oct 2010 20:39:39 +0000 (UTC) Received: from pollux.local.net (unknown [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id 1D6324C80F2 for ; Sat, 9 Oct 2010 22:39:33 +0200 (CEST) Received: by pollux.local.net (Postfix, from userid 2000) id D434728428; Sat, 9 Oct 2010 22:39:32 +0200 (CEST) Date: Sat, 9 Oct 2010 22:39:32 +0200 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20101009203932.GB2135@pollux.local.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20101008180046.GA2867@pollux.local.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: VirtualBox OpenSolaris guest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 20:39:43 -0000 On Fri, Oct 08, 2010 at 01:33:30PM -0500, Adam Vande More wrote: > On Fri, Oct 8, 2010 at 1:00 PM, Harald Weis wrote: > > > (while waiting for gnash) > > > > That's the funniest thing I've heard all week. > > -- > Adam Vande More Tell me. What is so funny about gnash ? -- Harald Weis From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 21:24:28 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA2E01065674 for ; Sat, 9 Oct 2010 21:24:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 896DC8FC18 for ; Sat, 9 Oct 2010 21:24:28 +0000 (UTC) Received: by pzk33 with SMTP id 33so345383pzk.13 for ; Sat, 09 Oct 2010 14:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=glFUurbAybc/Jpd1yFE+j1MPpNn2OZuQBP6dH6U7W0w=; b=nOlWf3xJDxCjgOd6NtJ0BUgqdxWuRcWgz5OmrGPTCrp8DItyAdR3SMQk6k3W7Ql+CO YQ+wmCThKD8j4jS7WomwODnENCrtYd9AiQABqTEh5hZPooobYnI6BZtsIDckZINuV7oQ YHHnbNwSIqnnDce3erv+qzl2RPUXYAkjip6oI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=U0LXDsnUEsnXl8bWygZp+blTP6WbEQMD/+xwyxpv/pyrO0tn5Pc24oX1F1rQoLhAym 2d3P9hxQwAbTOVYZ2xLPJo06CAAXfRkYMcGHYC2rWf1VTufHFrl/UAVmoYMgW03F3y3q vslLdKqQCCIbtzZhSB/ul+OUlWaBSdF9MkPG4= Received: by 10.143.28.9 with SMTP id f9mr1953713wfj.231.1286657652954; Sat, 09 Oct 2010 13:54:12 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d31sm6192551wam.17.2010.10.09.13.54.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 09 Oct 2010 13:54:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 9 Oct 2010 13:52:27 -0700 From: Pyun YongHyeon Date: Sat, 9 Oct 2010 13:52:27 -0700 To: FreeBSD Tinderbox Message-ID: <20101009205227.GA33450@michelle.cdnetworks.com> References: <20101009155729.4A0961B5060@freebsd-stable.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101009155729.4A0961B5060@freebsd-stable.sentex.ca> User-Agent: Mutt/1.4.2.3i Cc: amd64@freebsd.org, stable@freebsd.org Subject: Re: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 21:24:28 -0000 On Sat, Oct 09, 2010 at 11:57:29AM -0400, FreeBSD Tinderbox wrote: > TB --- 2010-10-09 14:18:05 - tinderbox 2.6 running on freebsd-stable.sentex.ca > TB --- 2010-10-09 14:18:05 - starting RELENG_7 tinderbox run for amd64/amd64 > TB --- 2010-10-09 14:18:05 - cleaning the object tree > TB --- 2010-10-09 14:18:38 - cvsupping the source tree > TB --- 2010-10-09 14:18:39 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile > TB --- 2010-10-09 14:18:50 - building world > TB --- 2010-10-09 14:18:50 - MAKEOBJDIRPREFIX=/obj > TB --- 2010-10-09 14:18:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-10-09 14:18:50 - TARGET=amd64 > TB --- 2010-10-09 14:18:50 - TARGET_ARCH=amd64 > TB --- 2010-10-09 14:18:50 - TZ=UTC > TB --- 2010-10-09 14:18:50 - __MAKE_CONF=/dev/null > TB --- 2010-10-09 14:18:50 - cd /src > TB --- 2010-10-09 14:18:50 - /usr/bin/make -B buildworld > >>> World build started on Sat Oct 9 14:18:51 UTC 2010 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Sat Oct 9 15:49:21 UTC 2010 > TB --- 2010-10-09 15:49:21 - generating LINT kernel config > TB --- 2010-10-09 15:49:21 - cd /src/sys/amd64/conf > TB --- 2010-10-09 15:49:21 - /usr/bin/make -B LINT > TB --- 2010-10-09 15:49:21 - building LINT kernel > TB --- 2010-10-09 15:49:21 - MAKEOBJDIRPREFIX=/obj > TB --- 2010-10-09 15:49:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-10-09 15:49:21 - TARGET=amd64 > TB --- 2010-10-09 15:49:21 - TARGET_ARCH=amd64 > TB --- 2010-10-09 15:49:21 - TZ=UTC > TB --- 2010-10-09 15:49:21 - __MAKE_CONF=/dev/null > TB --- 2010-10-09 15:49:21 - cd /src > TB --- 2010-10-09 15:49:21 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Sat Oct 9 15:49:21 UTC 2010 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/sdhci/sdhci.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/sf/if_sf.c > /src/sys/dev/sf/if_sf.c: In function 'sf_poll': > /src/sys/dev/sf/if_sf.c:1827: error: 'rx_npkts' undeclared (first use in this function) > /src/sys/dev/sf/if_sf.c:1827: error: (Each undeclared identifier is reported only once > /src/sys/dev/sf/if_sf.c:1827: error: for each function it appears in.) > cc1: warnings being treated as errors > /src/sys/dev/sf/if_sf.c:1827: warning: 'return' with a value, in function returning void > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2010-10-09 15:57:29 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2010-10-09 15:57:29 - ERROR: failed to build lint kernel > TB --- 2010-10-09 15:57:29 - 4972.50 user 554.31 system 5963.77 real > > > http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-amd64-amd64.full Should be fixed now. Sorry for the breakage. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 9 22:22:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37B22106564A for ; Sat, 9 Oct 2010 22:22:33 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id EBD748FC0A for ; Sat, 9 Oct 2010 22:22:32 +0000 (UTC) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id Glbb1f0010SCNGk5AmNZkF; Sat, 09 Oct 2010 22:22:33 +0000 Received: from hanssachs.home ([24.61.85.144]) by omta09.westchester.pa.mail.comcast.net with comcast id GmNY1f00G36qgMk3VmNYN1; Sat, 09 Oct 2010 22:22:33 +0000 Received: from algo by hanssachs.home with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4hoF-000Pul-IL; Sat, 09 Oct 2010 18:22:31 -0400 Date: Sat, 09 Oct 2010 18:22:31 -0400 Message-Id: From: Alex Goncharov To: Harald Weis In-reply-to: <20101009203629.GA2135@pollux.local.net> (message from Harald Weis on Sat, 9 Oct 2010 22:36:30 +0200) References: <20101008180046.GA2867@pollux.local.net> <20101009203629.GA2135@pollux.local.net> Sender: Alex Goncharov Cc: freebsd-stable@freebsd.org Subject: Re: VirtualBox OpenSolaris guest X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 22:22:33 -0000 ,--- You/Harald (Sat, 9 Oct 2010 22:36:30 +0200) ----* | On Fri, Oct 08, 2010 at 02:34:11PM -0400, Alex Goncharov wrote: | > | I guess that FreeBSD will never be supported by Adobe. | > | > Flash works beautifully for me on FreeBSD 8.1 in both Firefox 3.6... | > and in Opera (linux and native.) | | Yes, I know that very well and used it with success many times. There is | a message exchange on the questions mailing list - "concerning flash | under freebsd" starting on last June 15 - which confirms my own | experience of ugly things like npviewer.bin coredumps and browser | freezing. Out of the box, with the current 8.1-STABLE and ports, Firefox 3.6 works pretty good with Flash -- the freezes have been rare for me. But it can freeze forever on some sites. The latest www/linux-opera (run on FreeBSD) absolutely sucks when working with flash and other plugins, on the other hand. www/opera won't work with flash (it seems first). But I've found a non-trivial solution which for me works better than either of "(any) Opera by itself" or "Firefox by itself". The solution is: * Install Firefox plugins through www/nspluginwrapper-devel: nspluginwrapper -v -a -i You'll get e.g. ~/.mozilla/plugins/npwrapper.libflashplayer.so * Use www/opera, for which (there are many bizarre pieces below, but they all turned out to be necessary in my experiments (the names of newly created files can vary, of course): ** Disable all plugin paths ** ln -s ~/.mozilla ~/mozilla ** cp ~/mozilla/plugins/npwrapper.libflashplayer.so ~/mozilla/plugins/npwrapper.mvflashplayer.so ** Add ~/mozilla/plugins to the plugins path ** Discover the new plugins. ** Use "opera:config / Extensions" to set "PluginResponseTimeout" (mine is 8 sec). Yes, you may hang on some URI's (and what do you do?) but only for a limited time and not having to kill your browser. There are sites which predictably had hung my www/linux-opera, every time -- forever. And I am now happily visiting them with www/opera. | I found the suggestion interesting to install VirtualBox and | OpenSolaris which is an operating system supported by Adobe. That's | the reason why I gave it a try. If you insist on using VirtualBox as your "browser solution", you'd be much much better off installing Debian as your guest. For audio, OpenSolaris sucks (and it sucks in many other ways, too.) Don't go there, that would be my advice -- it's has been a time sink and the source of constant frustration for me. | > Is your problem "flash" or "audio" (i.e. can you play an mp3 file with | > mpg123, for example)? | | "flash" installs like a charm. It's audio. There is no audio whatsoever | after a perfectly clean OpenSolaris guest installation. The guest cannot | determine the correct audio driver for the underlying audio card. | Needless to say that the audio card works for the FreeBSD host (still | on 8.0 for the moment). I'll repeat: OpenSolaris is a disaster with (some) audio drivers. And I had asked about your experience running audio on FreeBSD. If it works for you, try my Opera recipe above. -- Alex -- alex-goncharov@comcast.net --