From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 09:49:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4188C97 for ; Sun, 2 Feb 2014 09:49:19 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77DD91DEC for ; Sun, 2 Feb 2014 09:49:19 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id k4so8709355qaq.1 for ; Sun, 02 Feb 2014 01:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=p5N8aMYBYpZhWAq7radCccMk/XHvckKnmSI4Ki3lBbM=; b=GBIlfIgQDcfBKTnj9Eb4jVul4rojFgNjZ2Tgx6AuHjYvNP1y3I6O1LzqY8tEU2hmcJ ZZRQenrpLEMo09xRK4GytSkWvWzBnBegIWvIWupFHOQX4m+s6YDeZvY9pi04QpewiJXu dzTo+boZaTuKoBvzXeLArBi1QvRv2tynAQXAg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=p5N8aMYBYpZhWAq7radCccMk/XHvckKnmSI4Ki3lBbM=; b=P7s6d2ruBPGFBur8bI4gxdWTBeQQUHEcRcalJZvd13PofVoDqvG3bU7k90+HZmpHbk VHgufOiPuyrr4cDzw2mO58vjJRaJmq+ypatd4VTKJzyyZTNRnS/EH6VVJ+Iz5h6IsuHR zGBo8MFPA1nNZa0WOZaPKxlU91SoAieBnHPZcqeLptdEgvM1FbtSbdKhm5FiAlirw05d qKIJlkbRj6zPv0TWJ7HWzN0vXDgNX6+EFvkckIAYEg9QBEm278xwZQJnUdVq/QzbWA9w BshLuwKV+A7l81cFMCh5/IcrIc+IxYCcriV/njwFvwRcO3dZcDHXCjXwmOSXtw9VcZWE fK8A== X-Gm-Message-State: ALoCoQn4HCj2riQG9ILR/aYXjsFZmi1yTNMHwsYJDK/TIArxsjHCg0k4bvb0JIipX6BE5yAuPxY5 X-Received: by 10.229.71.69 with SMTP id g5mr46491747qcj.6.1391334558493; Sun, 02 Feb 2014 01:49:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.205.138 with HTTP; Sun, 2 Feb 2014 01:48:38 -0800 (PST) From: Vlad Galu Date: Sun, 2 Feb 2014 09:48:38 +0000 Message-ID: Subject: Crash in pf_normalize_ip() in 10-STABLE (r261024) To: freebsd-pf@freebsd.org, "freebsd-stable@FreeBSD.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 09:49:19 -0000 Unfortunately, although dmesg indicates the coredump being written to the swap partition, savecore did not leave anything in /var/crash after the machine automatically rebooted. All I got is this backtrace: -- cut here -- Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0xe fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80757455 stack pointer = 0x28:0xfffffe04529a83e0 frame pointer = 0x28:0xfffffe04529a84d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi5: fast taskq) trap number = 12 panic: page fault cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe04529a7ec0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe04529a7f70 panic() at panic+0x155/frame 0xfffffe04529a7ff0 trap_fatal() at trap_fatal+0x3a2/frame 0xfffffe04529a8050 trap_pfault() at trap_pfault+0x2c9/frame 0xfffffe04529a8100 trap() at trap+0x5e6/frame 0xfffffe04529a8320 calltrap() at calltrap+0x8/frame 0xfffffe04529a8320 --- trap 0xc, rip = 0xffffffff80757455, rsp = 0xfffffe04529a83e0, rbp = 0xfffffe04529a84d0 --- pf_normalize_ip() at pf_normalize_ip+0x1a65/frame 0xfffffe04529a84d0 pf_test() at pf_test+0x211/frame 0xfffffe04529a8660 pf_check_in() at pf_check_in+0x1d/frame 0xfffffe04529a8680 pfil_run_hooks() at pfil_run_hooks+0x83/frame 0xfffffe04529a8710 ip_input() at ip_input+0x38e/frame 0xfffffe04529a8760 netisr_dispatch_src() at netisr_dispatch_src+0x60/frame 0xfffffe04529a87d0 ether_demux() at ether_demux+0x12a/frame 0xfffffe04529a8800 ether_nh_input() at ether_nh_input+0x35f/frame 0xfffffe04529a8860 netisr_dispatch_src() at netisr_dispatch_src+0x60/frame 0xfffffe04529a88d0 re_rxeof() at re_rxeof+0x4f4/frame 0xfffffe04529a8930 re_int_task() at re_int_task+0x9f/frame 0xfffffe04529a8970 taskqueue_run_locked() at taskqueue_run_locked+0xe6/frame 0xfffffe04529a89c0 taskqueue_run() at taskqueue_run+0x81/frame 0xfffffe04529a89e0 intr_event_execute_handlers() at intr_event_execute_handlers+0xab/frame 0xfffffe04529a8a20 ithread_loop() at ithread_loop+0x96/frame 0xfffffe04529a8a70 fork_exit() at fork_exit+0x9a/frame 0xfffffe04529a8ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe04529a8ab0 --- trap 0, rip = 0, rsp = 0xfffffe04529a8b70, rbp = 0 --- -- and here -- As a workaround I have temporarily disabled scrubbing and the system has run smoothly for a few days. Please CC me, I am not subscribed to these lists. Regards Vlad From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 09:57:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09AA9F27 for ; Sun, 2 Feb 2014 09:57:51 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D92AF1E8A for ; Sun, 2 Feb 2014 09:57:50 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id v10so5892266pde.27 for ; Sun, 02 Feb 2014 01:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=fVxSdUNx1JtoFL2QPEA7XI3KZQ8K9pmXUEGIxF6s4aw=; b=Xp9BQhG+Geowwg1L76SysJeIHS2xZwALISlStOX5hAZpkUQ9eNa0tY72wKbpFmyFXy nXmQKv/F4fT1qW4c6H+0txuW67pPQNRqW4co5AC1mLJdo+1bq7NxghKtgMWXqf3UZI7Q +mrXrxVHdCYJNIQthyxudJ5xyvZemJxYI4tt8QKKcsk8pMTSVcOxEaL12tbng/RM3a9M q/zZiSQaubB7opdi1nd2tJKaXH7xaVRF5qlXQSCtSQBpVx6wM30TEf/jA6Vu1XKpH/40 XeC9nx15GwcnX7oEItPLWkSh81aMOltLODOgpcuj9/0VpCEy7euyB3XOoj9JD9a7nd+c y/1Q== MIME-Version: 1.0 X-Received: by 10.67.5.233 with SMTP id cp9mr389949pad.147.1391335070596; Sun, 02 Feb 2014 01:57:50 -0800 (PST) Received: by 10.66.142.167 with HTTP; Sun, 2 Feb 2014 01:57:50 -0800 (PST) Date: Sun, 2 Feb 2014 10:57:50 +0100 Message-ID: Subject: From: Zenny To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Devin Teske X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 09:57:51 -0000 Hi: Last time, Devin had been very kind to suggest me when the system borked while trying to upgrade from v10B3 to vRC1. Following FreeBSD 10.0-RELEASE, I installed to a new machine with encrypted root in zfs mirror, and since there was something wrong (a double quote by mistake) inserted in the /boot/device.hints, the kernel refused to boot and landed to the mountroot prompt. Therefore, in order to make changes what I did was: 1. Boot into LiveCD mode 2. mkdir /tmp/bootpool zpool import -f bootpool zfs set mountpoint=/tmp/bootpool bootpool zfs mount -a cp /tmp/bootpool/boot/encryption.key /tmp/ zfs umount -a zfs set mountpoint=/bootpool bootpool zpool export bootpool geli attach -k /tmp/encryption.key /dev/ada0p4 geli attach -k /tmp/encryption.key /dev/ada1p4 zpool import -R /mnt zroot zpool import -R /mnt/bootpool bootpool 3. Removed the double quote (") from /bootpool/boot/device.hints and saved the file. 4. Rebooted the file and now it says that there is no boot/zfsbootloader. Appreciate if someone provides hints to recover the system in such situation without loosing any customized kernel and poudriere configs and contents? Thanks. /z From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 17:01:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00494AA7 for ; Sun, 2 Feb 2014 17:01:10 +0000 (UTC) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A18741B09 for ; Sun, 2 Feb 2014 17:01:10 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id x14so3997789vbb.8 for ; Sun, 02 Feb 2014 09:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=HCTwtJWQdmf8AM28cLm2wdn8t1nsW530xRsPFbPvG7c=; b=ohSYcaR4sP/hMJ2EaxGS0admYZitJAEEHfRx21qUJ/SyJJFBxqi1UBCid1pnBfUW46 XDvb4Sc5Q1oUYENVC65FQLJoCEYcm9+slsxAdnrG0j4VhIsJJcjF8ihm3nVwNGQxyniD CCw92GGYr2LP0x4O5i7thBYpHNkfAyQRU7dzNVmPFGJMErayubBNzugv7xBaIReodLHk yker+HabNT/y1GdO0MmOljoE6kRykO+T8U0CXa7Qcti2o8GnJt3vwgY/GH2qJBbisIEX RuxEbA1KJ5AAmBCukP7qvPSMDWO1UrKDra2TAGY8aMZtU0gsqqIhJGnpdfCR+3XrXTEV dkRg== X-Received: by 10.52.188.41 with SMTP id fx9mr20994504vdc.19.1391360469740; Sun, 02 Feb 2014 09:01:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.59.0.68 with HTTP; Sun, 2 Feb 2014 09:00:39 -0800 (PST) From: Matthias Gamsjager Date: Sun, 2 Feb 2014 18:00:39 +0100 Message-ID: Subject: What's up with the swapping since 10/stable To: stable-list freebsd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 17:01:11 -0000 Hi, My ZFS Nas box seems to use some swap since the upgrade to 10/stable. This machine just runs couple of hours per week and with 9/stable I never witnessed any swapping when serving media files. First thinks that caught my eye was the difference between ARC and Wired. At some point there is a 1+ GB difference while all this machine does is serving single 10GB mkv via AFP. Problem is that at some point the performance get's to a point that streaming isn't possible. This is after couple of video's watched and scrub 99% done. No ZFS tuning in /boot/loader.conf last pid: 2571; load averages: 0.19, 0.20, 0.19 up 0+04:06:20 17:55:43 42 processes: 1 running, 41 sleeping CPU: 0.0% user, 0.0% nice, 2.3% system, 0.0% interrupt, 97.7% idle Mem: 32M Active, 14M Inact, 7563M Wired, 16M Cache, 273M Buf, 303M Free ARC: 6065M Total, 2142M MFU, 3309M MRU, 50K Anon, 136M Header, 478M Other Swap: 4096M Total, 66M Used, 4030M Free, 1% Inuse System Information: Kernel Version: 1000702 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 5000 ZFS Filesystem Version: 5 FreeBSD 10.0-STABLE #0 r261210: Mon Jan 27 15:19:13 CET 2014 matty 5:57PM up 4:08, 2 users, load averages: 0.31, 0.23, 0.21 ------------------------------------------------------------------------ System Memory: 0.41% 32.43 MiB Active, 0.18% 14.11 MiB Inact 95.39% 7.39 GiB Wired, 0.21% 16.37 MiB Cache 3.81% 301.97 MiB Free, 0.01% 784.00 KiB Gap Real Installed: 8.00 GiB Real Available: 99.50% 7.96 GiB Real Managed: 97.28% 7.74 GiB Logical Total: 8.00 GiB Logical Used: 95.94% 7.68 GiB Logical Free: 4.06% 332.45 MiB Kernel Memory: 196.21 MiB Data: 79.49% 155.96 MiB Text: 20.51% 40.25 MiB Kernel Memory Map: 7.74 GiB Size: 71.72% 5.55 GiB Free: 28.28% 2.19 GiB ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 34.10k Recycle Misses: 102.86k Mutex Misses: 10 Evict Skips: 989.63k ARC Size: 87.94% 5.93 GiB Target Size: (Adaptive) 90.63% 6.11 GiB Min Size (Hard Limit): 12.50% 863.10 MiB Max Size (High Water): 8:1 6.74 GiB ARC Size Breakdown: Recently Used Cache Size: 65.86% 4.02 GiB Frequently Used Cache Size: 34.14% 2.09 GiB ARC Hash Breakdown: Elements Max: 594.22k Elements Current: 100.00% 594.21k Collisions: 609.54k Chain Max: 15 Chains: 122.92k ------------------------------------------------------------------------ ARC Efficiency: 4.19m Cache Hit Ratio: 83.08% 3.48m Cache Miss Ratio: 16.92% 708.94k Actual Hit Ratio: 73.81% 3.09m Data Demand Efficiency: 79.24% 456.96k Data Prefetch Efficiency: 2.94% 90.16k CACHE HITS BY CACHE LIST: Anonymously Used: 8.80% 306.18k Most Recently Used: 23.42% 815.06k Most Frequently Used: 65.43% 2.28m Most Recently Used Ghost: 0.41% 14.36k Most Frequently Used Ghost: 1.94% 67.65k CACHE HITS BY DATA TYPE: Demand Data: 10.40% 362.08k Prefetch Data: 0.08% 2.65k Demand Metadata: 76.84% 2.67m Prefetch Metadata: 12.68% 441.47k CACHE MISSES BY DATA TYPE: Demand Data: 13.38% 94.88k Prefetch Data: 12.34% 87.51k Demand Metadata: 34.54% 244.88k Prefetch Metadata: 39.73% 281.67k ------------------------------------------------------------------------ L2ARC is disabled ------------------------------------------------------------------------ File-Level Prefetch: (HEALTHY) DMU Efficiency: 9.57m Hit Ratio: 73.77% 7.06m Miss Ratio: 26.23% 2.51m Colinear: 2.51m Hit Ratio: 0.06% 1.54k Miss Ratio: 99.94% 2.51m Stride: 6.92m Hit Ratio: 99.99% 6.92m Miss Ratio: 0.01% 594 DMU Misc: Reclaim: 2.51m Successes: 0.85% 21.28k Failures: 99.15% 2.49m Streams: 137.84k +Resets: 0.06% 79 -Resets: 99.94% 137.76k Bogus: 0 ------------------------------------------------------------------------ VDEV cache is disabled ------------------------------------------------------------------------ ZFS Tunables (sysctl): kern.maxusers 845 vm.kmem_size 8313913344 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 1319413950874 vfs.zfs.arc_max 7240171520 vfs.zfs.arc_min 905021440 vfs.zfs.arc_meta_used 2166001368 vfs.zfs.arc_meta_limit 1810042880 vfs.zfs.l2arc_write_max 8388608 vfs.zfs.l2arc_write_boost 8388608 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_noprefetch 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_norw 1 vfs.zfs.anon_size 51200 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_data_lsize 0 vfs.zfs.mru_size 3476498432 vfs.zfs.mru_metadata_lsize 1319031808 vfs.zfs.mru_data_lsize 2150589440 vfs.zfs.mru_ghost_size 361860096 vfs.zfs.mru_ghost_metadata_lsize 210866688 vfs.zfs.mru_ghost_data_lsize 150993408 vfs.zfs.mfu_size 2246172672 vfs.zfs.mfu_metadata_lsize 32768 vfs.zfs.mfu_data_lsize 2050486272 vfs.zfs.mfu_ghost_size 6198800896 vfs.zfs.mfu_ghost_metadata_lsize 2818404864 vfs.zfs.mfu_ghost_data_lsize 3380396032 vfs.zfs.l2c_only_size 0 vfs.zfs.dedup.prefetch 1 vfs.zfs.nopwrite_enabled 1 vfs.zfs.mdcomp_disable 0 vfs.zfs.prefetch_disable 0 vfs.zfs.zfetch.max_streams 8 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.top_maxinflight 32 vfs.zfs.resilver_delay 2 vfs.zfs.scrub_delay 4 vfs.zfs.scan_idle 50 vfs.zfs.scan_min_time_ms 1000 vfs.zfs.free_min_time_ms 1000 vfs.zfs.resilver_min_time_ms 3000 vfs.zfs.no_scrub_io 0 vfs.zfs.no_scrub_prefetch 0 vfs.zfs.metaslab.gang_bang 131073 vfs.zfs.metaslab.debug 0 vfs.zfs.metaslab.df_alloc_threshold 131072 vfs.zfs.metaslab.df_free_pct 4 vfs.zfs.metaslab.min_alloc_size 10485760 vfs.zfs.metaslab.prefetch_limit 3 vfs.zfs.metaslab.smo_bonus_pct 150 vfs.zfs.mg_alloc_failures 8 vfs.zfs.write_to_degraded 0 vfs.zfs.check_hostid 1 vfs.zfs.recover 0 vfs.zfs.deadman_synctime_ms 1000000 vfs.zfs.deadman_checktime_ms 5000 vfs.zfs.deadman_enabled 1 vfs.zfs.space_map_last_hope 0 vfs.zfs.txg.timeout 5 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.cache.size 0 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.trim_on_init 1 vfs.zfs.vdev.max_active 1000 vfs.zfs.vdev.sync_read_min_active 10 vfs.zfs.vdev.sync_read_max_active 10 vfs.zfs.vdev.sync_write_min_active 10 vfs.zfs.vdev.sync_write_max_active 10 vfs.zfs.vdev.async_read_min_active 1 vfs.zfs.vdev.async_read_max_active 3 vfs.zfs.vdev.async_write_min_active 1 vfs.zfs.vdev.async_write_max_active 10 vfs.zfs.vdev.scrub_min_active 1 vfs.zfs.vdev.scrub_max_active 2 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.read_gap_limit 32768 vfs.zfs.vdev.write_gap_limit 4096 vfs.zfs.vdev.bio_flush_disable 0 vfs.zfs.vdev.bio_delete_disable 0 vfs.zfs.vdev.trim_max_bytes 2147483648 vfs.zfs.vdev.trim_max_pending 64 vfs.zfs.max_auto_ashift 13 vfs.zfs.zil_replay_disable 0 vfs.zfs.cache_flush_disable 0 vfs.zfs.zio.use_uma 1 vfs.zfs.zio.exclude_metadata 0 vfs.zfs.sync_pass_deferred_free 2 vfs.zfs.sync_pass_dont_compress 5 vfs.zfs.sync_pass_rewrite 2 vfs.zfs.snapshot_list_prefetch 0 vfs.zfs.super_owner 0 vfs.zfs.debug 0 vfs.zfs.version.ioctl 3 vfs.zfs.version.acl 1 vfs.zfs.version.spa 5000 vfs.zfs.version.zpl 5 vfs.zfs.trim.enabled 1 vfs.zfs.trim.txg_delay 32 vfs.zfs.trim.timeout 30 vfs.zfs.trim.max_interval 1 ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 19:04:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B211BEB6 for ; Sun, 2 Feb 2014 19:04:33 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DA4214C6 for ; Sun, 2 Feb 2014 19:04:33 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ld10so6294197pab.38 for ; Sun, 02 Feb 2014 11:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=W5vWOXPzQnE+t5sOlgsq/Dq/NIuME1Bv8Nsz9Vqtbb4=; b=jwgi70QXeyCpTnmmNUiGpumh6QFhtOq92Ekpn40t2wsWEfdvak76mMe1+nOsaCMEAi AP+kDyCb8eOkl/iWR7/HFu7StIBipq3XEVb0wDv5XuGufRHG1gpJlwlWezGCSD9kxcO9 NsjepnQKG2qWXc+F9NEDmzRfU2WMNyx2zRX5YihC3kugXgAvBwzaz0XkEd07VjIZ/5Cc TaxhbHWPcujg9wfSG6n6E49h52YqKwHD2/LRiCfV7iQ34nRpR9TEMcYNGpKPWgOuvu7F XML8KyKoVjxB2BW+hBt64dUJu1O6HcG5n0Kp35G511jYHvwrrzGghuBfOLqVUwrf8Sxi 7uTQ== MIME-Version: 1.0 X-Received: by 10.66.26.115 with SMTP id k19mr33344682pag.87.1391367873151; Sun, 02 Feb 2014 11:04:33 -0800 (PST) Received: by 10.66.142.167 with HTTP; Sun, 2 Feb 2014 11:04:33 -0800 (PST) Date: Sun, 2 Feb 2014 20:04:33 +0100 Message-ID: Subject: Recovery of zpools went corrupt!? From: Zenny To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Devin Teske X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 19:04:33 -0000 Reposting the mail below as I had an oversight not to include subject line. Apology in advance! > Hi: > > Last time, Devin had been very kind to suggest me when the system > borked while trying to upgrade from v10B3 to vRC1. > > Following FreeBSD 10.0-RELEASE, I installed to a new machine with > encrypted root in zfs mirror, and since there was something wrong (a > double quote by mistake) inserted in the /boot/device.hints, the > kernel refused to boot and landed to the mountroot prompt. > > Therefore, in order to make changes what I did was: > > 1. Boot into LiveCD mode > 2. mkdir /tmp/bootpool > zpool import -f bootpool > zfs set mountpoint=/tmp/bootpool bootpool > zfs mount -a > cp /tmp/bootpool/boot/encryption.key /tmp/ > zfs umount -a > zfs set mountpoint=/bootpool bootpool > zpool export bootpool > geli attach -k /tmp/encryption.key /dev/ada0p4 > geli attach -k /tmp/encryption.key /dev/ada1p4 > zpool import -R /mnt zroot > zpool import -R /mnt/bootpool bootpool > 3. Removed the double quote (") from /bootpool/boot/device.hints and > saved the file. > > 4. Rebooted the file and now it says that there is no boot/zfsbootloader. > > Appreciate if someone provides hints to recover the system in such > situation without loosing any customized kernel and poudriere configs > and contents? Thanks. > > /z > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 19:04:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E8E9FC3 for ; Sun, 2 Feb 2014 19:04:54 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F254414CA for ; Sun, 2 Feb 2014 19:04:53 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WA2LR-000MNO-OK for freebsd-stable@freebsd.org; Sun, 02 Feb 2014 19:04:42 +0000 Date: Sun, 2 Feb 2014 20:04:46 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: Re: Processes hang in state "kmem a", system hang follows Message-ID: <20140202200446.000076c8@unknown> In-Reply-To: <20140201203112.0000210c@unknown> References: <20140201203112.0000210c@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 19:04:54 -0000 On Sat, 1 Feb 2014 20:31:12 +0100 Matthew Rezny wrote: > I'm seeing rather strange behavior from 10.0 on i386 thus far. This is > another long message, so if you want the summary without back-story, > skip to the end. Sometimes it's hard to include relevant details > without feeling like I'm rambling. I'm seeing rather strange behavior > from 10.0 on i386 thus far. > > I started with FreeBSD not long before 4.0 release and ran 4.x > releases on i386 and Alpha for a long time. I tried the 5.x releases > and had nothing but trouble so stuck with 4.x through that time. The > Alpha never did move off 4.x before it got retired, but some of my > i386 boxes made it onto 6.x and then sat there until they were taken > out of active use. For years, FreeBSD 4.x and 6.x was the reliable OS > I used for everything but my desktop (which had been OS X). > > More recently I started using FreeBSD 8 on amd64 with ZFS and quickly > moved on to 9 as soon as 9.0 was released. At the same time, i386 > hardware retired from desktop roles but suitable for network services > got 8.x installed on UFS. I had rather good experience with 9-STABLE > on amd64 running with ZFS. For the most part it's solid, ZFS support > is much better than the sorry state Apple left it in before > abandoning it on OS X, though I did get a few kernel panics when > simply connecting disks that contained zpools from OS X. Due to both > compilation speed difference and the fact older hardware tends to be > in more entrenched roles, I left my i386 systems out of the ZFS and > 9.x experiments. I did also try 9.x on my one ppc64 box at various > times to see if that might be a good way to utilize hardware Apple > dropped support for years prior. The state on ppc64 varied between > panic on boot to being able to buildworld but an idle system left for > a few days would randomly go zombie, console freezes but clearly > there is some system activity and it responds to ping but might not > take a ssh connection, which I chalked up to the experimental state > of the port. I did see console freezes on i386 boxes booted from a > 9.1 mfsbsd image but never investigated because I was just using it > to image and erase disks on old machines where I considered the > hardware suspect. > > In the last couple months I've been moving my amd64 systems to 10, > starting during the RCs and keeping up such that they are now all > 10-STABLE. The transition was fairly smooth and they are running quite > well. Even one box that has prior chipset and BIOS, which was > panicking with an early 10-BETA is now running 10.0-RELEASE with KMS. > All very impressive. So, time to start migrating some i386 boxes I > figure. I had recently moved a number of them to 9.2 and figured I > should just go ahead and move everything up to 10.0 at close to the > same time if possible. I had seen no problems with 9.2 or 9-STABLE on > the i386 boxes that I was preparing to upgrade, I already sorted out > one Clang bug that affected a few (but less worse than a similar GCC > bug that remains unfixed) since I had switched compilers when going > to 9. > > Since I started moving i386 boxes to 10.0, I've had nothing but > strange problems. Last night I wrote a message about kern.maxswzone, > something I started getting warnings about on one particular box when > I put 9.2 on it but which I didn't try to do anything about until > now. I wrote that message with this one in mind, mentioning that I > would have another about processes hanging. That one came first > because it has at least some hard numbers and not so much subjective > feelings of performance and reliability. Between then and now, the > pattern struck me, all my early successes with 10 were amd64, and now > all the i386 boxes I've upgraded are barely functional. > > I have 4 i386 boxes that I tried to put 10.0 on in the past week with > various degrees of fail. There are 2 sets within the four, two are the > low-end C3 boxes with 256MB and 384MB RAM described in my prior > message to the list. The other two are Pentium4 systems, one with 2GB > RAM and the other with 3GB, substantially bigger disks, decent GPU, > etc. In other words, two are ancient and two are merely a little > dated but still very usable. This faster pair I will mention first, > then I will return to the slow pair. All these boxes are things I use > around the house for network services or as essentially terminals in > other rooms (kitchen pc to look up stuff, bedroom pc to watch movies, > etc). The i386 boxes that run important services (externally facing > network services, routing/firewall, etc) and being left two a second > round once all issues are sorted out on these lower-importance boxes > first. > > The P4s had 9-STABLE installed on UFS volumes. I did the switch from > csup to svnup to pull the 10.0 sources, did the buildworld/kernel and > install on both and all looked good. Before I went on to reinstall > packages or anything else, I decided now might be a good time to try > switching from UFS to ZFS, everything in /home was already backed up. > So far I had only tried ZFS on amd64 due to early reports of > flakiness on i386 related to exhausting kernel memory. In the couple > years since initial support, the ZFS code has gotten better > integrated, more people have tried it, some tuning guides have been > written, and I've seen reports of it being used on boxes with 512MB > RAM. Most of my i386 boxes in server roles have 2GB and it would be > nice to migrate those to ZFS if possible. Best to test on these boxes > first and try tuning if needed. > > I booted both P4 boxes from mfsbsd CD, mounted the existing UFS > volums, tar the whole mess and drop the uncompressed tar on my file > server. On the server, I fired off xz to compresses the tar file to > speed the restore (or so I thought) while I prepared the machines. I > setup the zpools in the normal way I'd done all my amd64 boxes. One > P4 box has a single disk, the other has two, so one is a single vdev > pool and the other is multiple, which adds a little variety for > testing. Aside from vdevs, the pool properties, filesystems and their > properties are all identical to how I've been setting up my other ZFS > boxes. LZ4 on most filesystems, gzip or none on a few, sha256 hashes > entirely, no dedupe, pretty normal. With the pools configured and > mounted on /zroot, I scp the tar.xz file for each box into /tmp > (which is tmpfs), and try tar xjpvf in /zroot. > > After initial good progress, both boxes seemed to hang at about the > same time. Disk activity stops, tar is sitting there as if it's going > to do something, but no further progress on either when left for an > hour. I started top on both boxes and notice that the tar process on > each is in the state "kmem a" and the resident memory allocation on > each is exactly the same (around 750MB). My first thought was that I > used too much RAM with the 500MB tar.xz file in tmpfs. One box says > 800MB free and the other says 1800MB free but maybe there is a > shortage of kernel memory. I can't seem to kill tar, so I just reboot > each, clear the zpools to try from a fresh state again, mount the > swap before filling /tmp this time, then attempt another extract. No > joy, it stops the same way, with the exact same memory allocation, > and each box is stopped on the exact same file as where each stopped > on the first attempt. The free memory reports are the same as before, > no sawp is being used, whatever is running out must be non-pageable. > > The next thing I try is decoupling the stages. The tar process is > growing so large because it has to decompress lzma which requires a > huge dictionary. I figure maybe the heavy disk I/O is causing > buffers/cache to contend with the process in some way. Reboot again > for a fresh start, scp the .tar.xz to /zroot/tmp, xz -d so it's just a > plain tar, then tar xpvf in /zroot and both complete without error. > Set the mointpoint to / for each zroot and reboot into the running > system. That was strange but solvable. I don't know what the "kmem a" > state is but I can guess it's probably short for something like "kmem > alloc" which would suggest to me the process is waiting on a kernel > allocation. So I figure I've got some tuning to do and a hung process > isn't as bad as the kernel panics others had reported on i386 under > heavy I/O load (e.g. rsync) with default settings. After all, the boot > messages include two warnings about tuning ZFS memory on i386. In > order to do the tuning, I need some reproducible load, and buildworld > is good for that. So, first thing is switch from svnup to svnlite > that is now in base and use that to get 10-STABLE sources. I do the > rm -r on /usr/src and /usr/ports and then fire off the svnlite co for > each. I find that the slowness of svn checkout is due to network > latency and running the two in parallel doesn't create I/O contention > on either disk or network. > > While the P4s are fetching their sources, I go to deal with the pair > of Via C3 boxes that I had taken to 10-PRERELEASE just a week prior > and was ready to upgrade to 10-STABLE. Since that upgrade, they sat > unused waiting for an impending MFC so I could do away with a local > patch. As mentioned in my other message, I made a mistake here on my > first attempt, I forgot to clear the existing /usr/src and /usr/ports > before starting the svnlite checkout. After realizing my mistake, I > did the now larger (as it includes a .svn dir) rm -r of those dirs to > start fresh. That's when I hit the problem with rm hanging on one box. > Without repeating all the details, I had to boot mfsbsd to do the rm > on the one box with only 256MB RAM, but what difference that made is > simply inexplicable. Once I had gotten that straightened out, I > started off the svnlite checkout fresh. On the box with 384MB, the > completed with only one restart for network dropout (common since it > takes 2-3 hours per checkout). On the box with 256MB (which had > previously fully checked out and gotten to the point where it wanted > to prompt me for the conflict on every file in the tree), svnlite > could only do a hundred files or so before it seemed to hang in the > same way as rm. Running just one instance on /usr/src without the > parallel checkout on /usr/ports made no difference. When rm was > hanging, I might be able to kill it (after several minutes wait) and > reboot or the console might lock. When svnlite hung, I could not > login but I might be able to run a command on another VT. I was able > to catch that svnlite is getting stuck in the state "kmem a". Hmmm... > the same state that tar was getting stuck in on the other boxes. How > were those doing now? > > I look back at the P4s, which should be done as it's been a few hours > spent on the C3 boxes. They are sitting there in the middle of > checkout not making any visible progress. Ctrl-c doesn't work, I can't > switch VTs, even ctrl-alt-del seems to not work. Seems like the > consoles are hung in a way eerily similar to what I'd seen from 9.x on > non-amd64 platforms (both ppc64 and i386). I attempted to initiate an > ssh connection into each of the P4s and then walked off for a minute > for refreshment. When I came back, expecting to find a login prompt or > a timeout, I found the ssh attempts timed out and the two boxes had > rebooted. I don't know if the ctrl-alt-del finally registered or if > the incoming ssh connection pushed them over the edge. I wasn't there > to see and the logs for both stop sometime before the hang. With both > rebooted, I do a svnlite cleanup in /usr/src and /usr/pots or both, > then fire off the svnlite co for each directory on both boxes. > > While those were running, I started digging into the kern.maxswzone > tunable on the C3 box with less RAM. The box with more RAM was able > to do the rm, svn checkout of both src and ports in parallel, and > showed no obvious sign of trouble, though I hadn't started a > buildworld yet. The box with less RAM was failing all over the place > and the only obvious difference was the warning about that tunable. > After I wasted hours figuring out the value is already sufficient but > is apparently reduced after it's set, so it can't be effectively > turned up, only down, I wrote my previous message to this list on > that topic specifically and then went to bed. > > This morning I got up and was already thinking about the correlation, > that 10 is a disaster on all my i386 boxes thus far. The first thing I > checked was the P4 boxes. Both completed the svn checkout on both src > and ports, good sign. However, the box with 3GB RAM has the message > "vm_thread_new: kstack allocation failed" repeated about a dozen > times, bad sign. First thing I do is try to run top to see what the > size of ARC is, free RAM, etc. "No more processes." Uh Oh, that's no > good at all, can't even run top. Curiously, the box with less RAM, > only 2GB, has no messages so I try to start top on it to see what > it's state is. Nothing happens when I push return, the cursor is just > sitting there after top. On another VT, reboot gets the same > response, none, cursor just sits. I can't type but I can switch VTs > and scroll, until I do ctrl-alt-del, then every key press after that > is a beep. Back on the once that said no processes left for top, > reboot gets the same non-response. ctrl-alt-del doesn't beep, it just > spits out the ^[[3~ typical of a dead console. Ugh, not even a reset > button to punch on these P4 boxes. > > So, svnlite checkout is a real strain that can bring a system to it's > knees. I'm not sure if this should be regarded as horrible > inefficiency or as a means of checking the box before launching into > a buildworld (as if that wasn't enough strain to uncover most > problems). While 10.0 is good on amd64, it seems a disaster on i386. > Processes hang in this "kmem a" state it doesn't take much more to > get the box to livelock. I've only seen the "kmem a" state a few > times as most other times I can't inspect anything before the box is > locked too hard to do anything. In some cases I'm not sure there's > even a way to get the box shutdown clean as the most trivial of > things lock it up hard. It's not even required to do anything. When I > was experimenting with kern.maxswzone last night I rebooted one box a > few dozen times, so if I didn't need to look at systcl output I just > hit ctrl-alt-del at the login prompt. Once the console died right > then, it had just booted and ctrl-alt-del was met with a beep and > then it's hung, have to punch reset. I'm guessing the console dies as > a result of total wedging of I/O systems following heavy disk I/O. > The cause is not just ZFS because the C3 boxes are UFS. The problem > is not just the excess swap on the smallest box because I see the > same sort of troubles on the box with the most RAM. Some kernel > resource seems to be exhausted regardless of how much RAM or swap is > present. > > I'm going to try buildworld on 3 of these to see what happens. For the > fourth, I still need to get sources onto the disk before I can even > attempt that. I'm not sure what to expect. It might be instant > miserable failure, or it might actually run a long time since the I/O > load is in bursts with lots of recovery time between. It'll take a few > hours to see if the P4s succeed. It'll take two days to see a C3 > succeed. Maybe by that time, someone will get through all I've written > and have some useful suggestion for debugging. To me, it's rather hard > to debug since I have little hint where to start, when the problem > manifests any logging stops, and the box is in a state where it is > essentially unobservable without a JTAG to jump in and directly > inspect the state of it's world. Replying to self to give status update to anyone reading along. The pair of P4 boxes made it through buildworld/kernel after a few tries. On these boxes I have /usr/obj mounted on a tmpfs as that's how I've been setting up the other boxes with ZFS. Between the ZFS ARC filling with source, the tmpfs filling with binaries, and the actual compilation tasks there should be a good bit of memory pressure. The first build attempt was with -j10 on both boxes. As these are single core CPUs, -j4 would have probably been more appropriate for optimal speed. The build process on each failed after about an hour. The exact stopping point was not noted since the actual error is beyond reach of syscons history by the time the parallel build process exits. The two boxes appear to have stopped at different points. I restarted the make buildworld on each without any -j parameter and without rebooting. I didn't want to clear the state, if the overly parallel build caused anything to leak, I want to see that blow up the non-parallel build. The first run through on each failed at different points with one of the strangest compiler errors I've yet to see. The builds failed with a fatal error: unable to open file [something}.c (where something was rlogin.c on one and citrus_[forgotten].c on the other). On both boxes, the first thing I did was cat thefile.c and of course I see the source file as expected, so the compiler failing to open the source file is a transient error. Following those odd errors, I restarted the build on each box with exactly the same options and without rebooting to check reproducibility. On the second non-parallel build attempt, both boxes succeeded to build world and then proceeded on to the kernel build without issue. Whatever resource exhaustion had cleared itself. I checked the memory stats at that point. The box with 3GB RAM had no swap currently in use, but might have experienced swapping during the build. The box with 2GB RAM had 800MB swap used, which is reasonable given the /usr/obj tmpfs was holding 2.2GB. Interestingly, the box with more RAM was the first of the pair to fail out of the build both times. The installkernel and installworld went off without a hitch. I did get a warning about swapoff failing when dropping to single user on the box with only 2GB, which is expected given the tmpfs spill into swap. The situation with buildworld is not too bad. The spurious file open errors are troubling, but not as bad as a panic or hang. The problem is likely more specifically ZFS-triggered kernel memory pressure and not general memory pressure. The low memory use but higher disk I/O processes like tar and svn are more prone to trigger the problem. Even higher disk I/O might hit the point of panic as some others have reported with e.g. rsync on i386. Perhaps with some tuning, these boxes can be made to behave reasonably. The initial problems with tar seemed very troubling and I still don't have a good explanation for why the memory use of the decompress while untaring seemed to make such a difference. The situation with the C3 boxes is much worse. More details on those will be in the other thread since that is where I gave the initial details on those and got some reply. The most interesting bit from that pair of boxes is the possible spurious file open fail. Running svnlite through truss, I couldn't help but notice that it hung immediately following a failure to stat a file that was in fact present (fsck truncated it on the reboot after hang). Some VFS issue that therefore affects UFS and ZFS on i386? From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 19:46:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD661E57 for ; Sun, 2 Feb 2014 19:46:28 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF20E17F8 for ; Sun, 2 Feb 2014 19:46:27 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WA2zk-000EJX-Lh for freebsd-stable@freebsd.org; Sun, 02 Feb 2014 19:46:22 +0000 Date: Sun, 2 Feb 2014 20:46:23 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: Tuning kern.maxswzone is minor compared to hangs in "kmem a" state Message-ID: <20140202204623.00003fe5@unknown> In-Reply-To: <20140201221612.00001897@unknown> References: <20140201070912.00007971@unknown> <20140201221612.00001897@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 19:46:28 -0000 On Sat, 1 Feb 2014 22:16:12 +0100 Matthew Rezny wrote: > On Sat, 01 Feb 2014 13:03:15 -0600 > Richard Todd wrote: > > > Matthew Rezny writes: > > > > > So, as best I can tell, the actual effective number used for > > > kern.maxswzone is indeed approximately 8x available RAM. If there > > > is some need to turn it down (using substantially less swap) then > > > that is possible, but turning it up (as suggested by the warning > > > message) is not possible. Setting any value higher does not appear > > > to actually > > > > Yeah, IIRC I ran into that when configing some VMs with > > really big swap space for benefit of tmpfs. This is the quick hack > > I used to get around that, you might give it a try. > > > > # HG changeset patch > > # Parent e4dd7df011139e2b224835aa6e330c90afcf9a55 > > patch swap_pager to unconditionally use maxswzone tunable if it is > > set -- helpful for our tbvm VMs with large swap space for tmpfs > > > > diff -r e4dd7df01113 sys/vm/swap_pager.c > > --- a/sys/vm/swap_pager.c Wed Feb 20 00:15:49 2013 -0600 > > +++ b/sys/vm/swap_pager.c Sat Feb 23 13:08:54 2013 -0600 > > @@ -546,7 +546,7 @@ > > * is typically limited to around 32MB by default. > > */ > > n = cnt.v_page_count / 2; > > - if (maxswzone && n > maxswzone / sizeof(struct swblock)) > > + if (maxswzone) > > n = maxswzone / sizeof(struct swblock); > > n2 = n; > > swap_zone = uma_zcreate("SWAPMETA", sizeof(struct swblock), > > NULL, NULL, > > > Thank you for pointing me in the right direction. Now that I'm > looking at the right file, I don't know how I failed to find it > myself with grep. The logic here is rather obviously flawed, the > maxswzone value is only used if it is less than the calculated > default. If there is some reason to not allow adjusting this up, then > the warning message is incorrect. Either way, something should change > and I guess I should file a PR on this one. At least I can see the > warning is taking the doubling for safety into account, so for my > particular case with an overrun under 10% it should probably be ok to > put fixing this on the back burner. > > > Also, > > > > > With /usr/src cleared (and after running fsck) I booted back into > > > 10-PRERELEASE to try to fetch the 10-STABLE sources again. I > > > started svnlite co and find it hung shortly thereafter. I tried a > > > few times but each time I see it does a couple hundred files at > > > best and just stops. When it stops, I can't login to another > > > terminal. If I have a spare console logged in, I can't run > > > anything. After a few tries, I manged to catch it where I had top > > > running in one VT, started the checkout, and then switched back > > > just in time. I never could even get top up with rm running (it > > > probably blows over some limit faster). When the checkout hangs, > > > the state of svnlite is "kmem a" according to top. I can only > > > guess that is short for kmem alloc, I guess some syscall is > > > waiting on an allocation that will never happen because something > > > already is using or has leaked everything that could satisfy that > > > allocation. It looks like activity on too many files within a > > > short period runs something out. > > > > No, it's just a new bit of debugging code that causes the system > > to spend lots of CPU time verifying integrity of some of its > > internal data structures, especially on wimpy hardware (e.g., my > > dual PII/400 box, which is where I noticed this recently.) You'll > > find if you're patient that it isn't a complete hang, it will > > actually get work done in between the debug passes. Set sysctl > > debug.vmem_check=0 to disable the check. This is I think > > completely independent from the maxswzone stuff, it's just you were > > seeing it for the first time since the debug code in question was > > only recently added to 10-STABLE. > > > If only it were that simple. I'm not yet on 10-STABLE, I'm struggling > to get the sources to reach that point. These C3 boxes are > 10-PRERELEASE so I don't yet have this debug.vmem_check to tweak. > sysctl says unknown oid when I query it. I tried setting it from > loader prompt but still says unknown oid and I see no change in > behavior. > > Also, I'm not seeing anything using lots of CPU time. If I start off > top on another VT before I start svnlite, then I have a decent chance > of seeing what goes on until the situation becomes dire. svnlite > starts off moving quick and using lots of CPU time (>50%) for the > first hundred files or so, then it halts in the "kmem a" state and > CPU is completely idle. It sits there for a while, and eventually does > something more. Each time the stop is longer and less work is done in > the interval between stops. Eventually the process appears to hang > completely in that I can leave it for half a day and no more progress > is made. The rm process could go longer in this state with still some > visible progress since it's operation is sufficiently simple to > actually observe it managed to do something, whereas svnlite might do > something occasionally but it's not enough to get to the next file in > the list. > > With each burst and wait cycle, I see a spray in dmesg saying > calcru: runtime went backwards [lots] for {all processes}. If I hit > ctrl-C and wait, it'll interrupt svnlite the next time it would do > something other than wait. It can easily take 10 min for that to > happen, meaning the wait period is long enough to consider the process > as not effectively running. If I let it go long enough, it gets to a > state where it never exits on ctrl-c (or at least it'd take more hours > than I've been willing to wait). In this last attempt, I let it go for > 5 min, pushed ctrl-c, waited another 10 min, then tried ctrl-alt-del > and that just beeps so the attempt to interrupt the process resulted > in total I/O lockup to the point key presses are not handled. That > last one was enough to finally require manual fsck on reboot (which > should be a testament to the resiliency of UFS as I've pushed the > reset button a hundred times in the past day and a half). > > > Richard > > > > > > Thank you for taking the time to respond. It's now clear the maxswzone > is just a red herring, the real issue are the apparent hangs which I'm > seeing on several more boxes. The mystery is why the one box with > slightly more RAM seems ok, but a couple boxes with far more RAM are > not ok. That will probably be answered when I figure out what the > cause is. Reply to self for status update. The situation with these C3 boxes and 10.0 is just miserable. I tried using tar, both streaming with netcat and from a file, to populate /usr/src on the smaller box, but tar would hang eventually too. Tar got further probably because it's only handling the source files and not constantly updating a database file as svn does. I decided to try running svnlite through truss to see if there was a particular syscall causing trouble. In two runs I saw that it got further than ever before (likely truss output was limiting overall execution speed and thus reducing peak instantaneous disk I/O load) but stopped at different points. The first attempt hung on a stat() call on wc.db and I saw that a call involving the same file just a few lines before had failed with file not found, but that file must exist and indeed was present (but corrupt) following a reboot and fsck. The second run through stopped on a blank line as if the next syscall was setup but the name didn't get printed before everything hung hard. Following the pattern of 5 gettimeofday() between each lstat(), the next call should have been an lstat() but on which file is unknown because each lstat() prior was a different file. It looks like the hangs might be connected to errors opening files that do exist. That bit of info ties this in another way to the P4 boxes mentioned in my other thread, which simply failed out of builworld with claims source files didn't exist, but completed buildworld on the next attempt. After deciding there was just no way to have significant disk I/O on the box with only 256MB RAM, I moved it's harddrive to the box with 384MB and extracted the tar there, That succeeded on the first attempt, which verifies the UFS volume hasn't been horribly trashed in some way that manifests as file access related hangs. Booting the drive in the other system also verifies it is not any minor accidental configuration difference as now all that changed was the available memory and suddenly the same OS instance could extract the tar of both /usr/src and /usr/ports no problem. I put the harddrives back in their respective boxes and booted them both up. On each I started off top on one VT and then went to another VT and ran svnlite status to verify that svn regards the source tree as complete. On the box with 384MB RAM, that command returned the expected result in under a minute. On the box with 256MB RAM, I saw a quick burst of disk I/O and then nothing. Top confirmed svnlite was sitting in "kmem a" state. I hit ctrl-c and let it sit. An hour later it was sitting in the same place (so zero progress) and I went to sleep. When I awoke some 6 hours later, it was in the same state with the same 9sec CPU time, the process definitely isn't even creeping along with periodic progress like rm sometimes manages. Looking at top revealed that ntpd has joined svnlite in the "kmem a" state. I had noticed yesterday the clock was off by several hours. Now I know why, if I leave it hung too long ntpd gets hung and the clock grinds to a halt. How could a process hanging stop the RTC on the mobo? Only thing I can think of is that might happen if ntpd were to hang in the midst of an update to the RTC. I wonder if all the calcru: runtime went backwards errors are related to periodic clock stops. I rebooted the hung box and fsck showed nothing significant. I started top on both (to ensure it's available) and then started a make buildworld on each. On the box with 256MB, that hung in the initial rm -rf /usr/obj/usr/src/tmp. Yep, that should be no surprise, the old /usr/obj is still there and it's too big to rm. Using mfsbsd I was able to clear that directory with just a few tries (same as before, rm causes pressure fast enough to blow out sh, getty and everything short of init). Booted back into the installed OS, I started the buildworld again and it had been making reasonable progress for a few minutes. During compilation, file I/O will be bursts with long waits between as the CPU churns. My amd64 boxes are fast enough to be bottlenecked on disk I/O unless I build to a tmpfs. These C3 boxes are so slow the compiler could never hope to saturate the disk, but a big copy or an mtree might blow it up the same as the initial rm. Just as I was about to hit send, the box panicked. Finally a panic and not just a hang so there's a backtrace! That should be the first hint as to where in the kernel I'm hitting trouble. The panic points the finger at UFS. The filesystem has seen some thrashing but it did just fsck without significant error before that build was started. So, I'm thinking it's not on-disk corruption but an in-memory problem. It blew up writing a softdep, which starts me wondering if the buffers used for softupdates bookkeeping are overflowing in the kernel. That would make some sense, rapidly creating (svn/tar) or deleting (rm) many small files will create a huge amount of activity for softupdates to track, defer and reorder. The rm case is probably the one than can trigger it the fastest because deletes are focusing the beating on the metadata without wasting time between on file data I/O. Here's the full core.txt in hopes the vmstat numbers add some useful information beyond the backtrace. Sun Feb 2 20:07:30 CET 2014 FreeBSD music2.reztek 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #1: Sat Jan 11 09:00:08 CET 2014 root@music2.reztek:/usr/obj/usr/src/sys/MUSIC i386 panic: handle_written_inodeblock: Invalid link count 65529 for inodedep 0xc7648b00 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: handle_written_inodeblock: Invalid link count 65529 for inodedep 0xc7648b00 KDB: stack backtrace: #0 0xc0667f6f at kdb_backtrace+0x52 #1 0xc063dc7d at panic+0x85 #2 0xc084483f at softdep_disk_write_complete+0x1294 #3 0xc06b0656 at bufdone_finish+0x23 #4 0xc06b04f5 at bufdone+0x39 #5 0xc05e0d13 at g_vfs_done+0x289 #6 0xc05dd8ea at g_io_deliver+0x28f #7 0xc05e0648 at g_std_done+0x4e #8 0xc05dd8ea at g_io_deliver+0x28f #9 0xc05e0648 at g_std_done+0x4e #10 0xc05dd8ea at g_io_deliver+0x28f #11 0xc05e0648 at g_std_done+0x4e #12 0xc05dd8ea at g_io_deliver+0x28f #13 0xc05db68f at g_disk_done_single+0xfa #14 0xc0487fb7 at adadone+0x482 #15 0xc046de75 at xpt_done_process+0x435 #16 0xc0470a11 at xpt_done_td+0x15a #17 0xc0615573 at fork_exit+0xa3 Uptime: 6m58s Physical memory: 239 MB Dumping 102 MB: 87 71 55 39 23 7 No symbol "stopped_cpus" in current context. #0 doadump (textdump=-1030183936) at pcpu.h:233 233 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=-1030183936) at pcpu.h:233 #1 0xc063d96b in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xc063dce6 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xc084483f in softdep_disk_write_complete (bp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:11270 #4 0xc06b0656 in bufdone_finish (bp=0xc1ecfbe0) at buf.h:420 #5 0xc06b04f5 in bufdone (bp=) at /usr/src/sys/kern/vfs_bio.c:3754 #6 0xc05e0d13 in g_vfs_done (bip=) at /usr/src/sys/geom/geom_vfs.c:157 #7 0xc05dd8ea in g_io_deliver (bp=0xc724f390, error=) at /usr/src/sys/geom/geom_io.c:669 #8 0xc05e0648 in g_std_done (bp=) at /usr/src/sys/geom/geom_subr.c:1018 #9 0xc05dd8ea in g_io_deliver (bp=0xc58f5000, error=) at /usr/src/sys/geom/geom_io.c:669 #10 0xc05e0648 in g_std_done (bp=) at /usr/src/sys/geom/geom_subr.c:1018 #11 0xc05dd8ea in g_io_deliver (bp=0xc724f980, error=) at /usr/src/sys/geom/geom_io.c:669 #12 0xc05e0648 in g_std_done (bp=) at /usr/src/sys/geom/geom_subr.c:1018 #13 0xc05dd8ea in g_io_deliver (bp=0xc724fb48, error=) at /usr/src/sys/geom/geom_io.c:669 #14 0xc05db68f in g_disk_done_single (bp=0xc724fb48) at /usr/src/sys/geom/geom_disk.c:275 #15 0xc0487fb7 in adadone (periph=, done_ccb=) at /usr/src/sys/cam/ata/ata_da.c:1759 #16 0xc046de75 in xpt_done_process (ccb_h=0xc564c800) at /usr/src/sys/cam/cam_xpt.c:5247 #17 0xc0470a11 in xpt_done_td (arg=0xc09c3e00) at /usr/src/sys/cam/cam_xpt.c:5278 #18 0xc0615573 in fork_exit (callout=0xc04708b7 ) at /usr/src/sys/kern/kern_fork.c:995 #19 0xc08bd154 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:279 Current language: auto; currently minimal (kgdb) ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -8 0 0 0 - DLs - 0:00.01 [kernel] 0 1 0 0 8 0 9240 3154304 wait DLs - 0:00.03 [init] 0 2 0 0 8 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 3 0 0 8 0 0 0 crypto_r DL - 0:00.00 [crypto returns] 0 4 0 0 -8 0 0 0 ccb_scan DL - 0:03.55 [cam] 0 5 0 0 -8 0 0 0 ctl_work DL - 0:00.00 [ctl_thrd] 0 6 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_iterator] 0 7 0 0 -16 0 0 0 psleep DL - 0:00.83 [pagedaemon] 0 8 0 0 16 0 0 0 psleep DL - 0:00.08 [vmdaemon] 0 9 0 0 155 0 0 0 pgzero DL - 0:00.00 [pagezero] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 1:48.78 [idle] 0 12 0 0 -84 0 0 0 - WL - 0:11.94 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.05 [geom] 0 14 0 0 -16 0 0 0 - DL - 0:00.65 [rand_harvestq] 0 15 0 0 -68 0 0 0 - DL - 0:00.01 [usb] 0 16 0 0 -16 0 0 0 psleep DL - 0:00.36 [bufdaemon] 0 17 0 0 16 0 0 0 syncer DL - 0:00.18 [syncer] 0 18 0 0 -4 0 0 0 vlruwt DL - 0:00.01 [vnlru] 0 19 0 0 -16 0 0 0 sdflush DL - 0:00.30 [softdepflush] 0 20 0 0 -16 0 0 0 - DL - 0:00.06 [schedcpu] 0 1090 1 0 60 0 10048 3151424 select Ds - 0:00.01 [dhclient] 65 1126 1 0 55 0 10048 3155264 select Ds - 0:00.00 [dhclient] 0 1127 1 0 40 0 9224 3152384 select Ds - 0:00.00 [devd] 0 1274 1 0 40 0 9944 3153344 select Ds - 0:00.39 [syslogd] 0 1369 1 0 40 0 12032 3148544 select Ds - 0:00.15 [ntpd] 0 1398 1 0 59 0 14312 3149504 select Ds - 0:00.00 [sshd] 0 1402 1 0 8 0 9984 3146624 nanslp Ds - 0:00.12 [cron] 0 1425 1 0 59 0 10068 3158144 select Ds - 0:00.00 [moused] 0 1468 1 0 58 0 9936 3176448 ttyin Ds+ - 0:00.01 [getty] 0 1469 1 0 8 0 10416 3174528 wait DWs - 0:00.00 [login] 0 1470 1 0 8 0 10416 3177408 wait DWs - 0:00.00 [login] 0 1471 1 0 58 0 9936 3150464 ttyin Ds+ - 0:00.01 [getty] 0 1472 1 0 58 0 9936 3172608 ttyin Ds+ - 0:00.01 [getty] 0 1473 1 0 58 0 9936 3173568 ttyin Ds+ - 0:00.01 [getty] 0 1474 1 0 58 0 9936 3171648 ttyin Ds+ - 0:00.01 [getty] 0 1475 1 0 58 0 9936 3170688 ttyin Ds+ - 0:00.01 [getty] 0 1476 1470 0 16 0 10656 3169728 pause DW - 0:00.00 [csh] 0 1478 1476 0 40 0 11056 3168768 select D+ - 0:02.19 [top] 0 1479 1469 0 16 0 10656 3167808 pause DW - 0:00.00 [csh] 0 1483 1479 0 8 0 8944 3166848 wait DW+ - 0:00.00 [make] 0 1488 1483 0 8 0 8944 3165888 wait DW+ - 0:00.00 [make] 0 1619 1488 0 8 0 8944 3164928 wait DW+ - 0:00.00 [make] 0 1623 1619 0 8 0 10272 3163968 wait DW+ - 0:00.00 (sh) 0 1725 1623 0 8 0 8944 3147584 wait D+ - 0:00.76 [make] 0 1793 1725 0 8 0 27316 3156224 wait D+ - 0:00.04 [c++] 0 1794 1793 0 -16 0 37300 4128768 vnread DL+ - 0:06.44 [c++] ------------------------------------------------------------------------ vmstat -s 201483 cpu context switches 867407 device interrupts 21239 software interrupts 229915 traps 396065 system calls 20 kernel threads created 1419 fork() calls 355 vfork() calls 0 rfork() calls 9 swap pager pageins 33 swap pager pages paged in 52 swap pager pageouts 153 swap pager pages paged out 1558 vnode pager pageins 10442 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 108 page daemon wakeups 0 pages examined by the page daemon 116 pages reactivated 37654 copy-on-write faults 248 copy-on-write optimized faults 144312 zero fill pages zeroed 3353 zero fill pages prezeroed 9 intransit blocking page faults 201812 total VM faults taken 1537 page faults requiring I/O 0 pages affected by kernel thread creation 54059 pages affected by fork() 16118 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 238064 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 10588 pages active 265 pages inactive 8 pages in VM cache 20998 pages wired down 28211 pages free 4096 bytes per page 504005 total name lookups cache hits (89% pos + 1% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) ctlmem 9179 18345K - 9179 64,2048 cdev 10 2K - 10 128 CAM XPT 25 2K - 85 16,32,128,256,512,1024,2048 ctlblk 200 800K - 200 4096 filedesc 49 52K - 1797 16,1024,4096 sigio 1 1K - 1 32 filecaps 1 1K - 3 16 kdtrace 125 23K - 1873 64,256 kenv 82 7K - 93 16,32,64,128,4096 kqueue 0 0K - 12 128,1024 proc-args 24 2K - 610 16,32,64,128,256 ramdisk 1 4096K - 1 hhook 2 1K - 2 128 ithread 59 5K - 59 16,64,128 mixer 1 4K - 1 4096 KTRACE 100 13K - 100 128 kbdmux 6 18K - 6 16,256,1024,2048 linker 106 4K - 108 16,32,256 lockf 17 1K - 49 32,64 loginclass 3 1K - 16 64 cache 1 1K - 1 16 devbuf 810 45406K - 1186 16,32,64,128,256,512,1024,2048,4096 temp 18 77K - 1696 16,32,64,128,256,512,1024,2048,4096 ip6ndp 5 1K - 5 64,128 module 220 14K - 220 64 mtx_pool 2 8K - 2 4096 pmchooks 1 1K - 1 64 UART 12 7K - 12 16,512,1024 CAM DEV 6 12K - 12 2048 pgrp 21 2K - 26 64 session 17 3K - 22 128 proc 2 2K - 2 1024 subproc 114 205K - 1862 256,4096 cred 46 5K - 6934 64,128 plimit 12 3K - 209 256 uidinfo 3 1K - 6 64,256 CAM CCB 0 0K - 32459 2048 CAM path 8 1K - 50 16 ctlpool 532 138K - 532 16,512 USB 6 3K - 6 16,64,256,2048 USBdev 5 1K - 5 32,64,128 sysctl 0 0K - 2612 16,32,64 sysctloid 2164 66K - 2215 16,32,64,128 sysctltmp 0 0K - 210 16,32,64,128 CAM periph 6 1K - 21 16,32,64,128 tidhash 1 2K - 1 2048 callout 2 480K - 2 umtx 180 17K - 180 64,128 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 bus 457 21K - 1529 16,32,64,128,256,1024 bus-sc 44 60K - 564 16,32,64,128,256,512,1024,2048,4096 CAM queue 10 2K - 30 16,256 devstat 6 13K - 6 16,4096 eventhandler 82 4K - 82 32,64,128 DEVFS3 134 17K - 147 128 kobj 117 234K - 154 2048 DEVFS1 111 28K - 117 256 Per-cpu 1 1K - 1 16 DEVFS 17 1K - 18 16,64 DEVFSP 2 1K - 2 32 rman 100 6K - 523 16,32,64 sbuf 0 0K - 646 16,32,64,128,256,512,1024,2048,4096 taskqueue 13 2K - 13 16,128 Unitno 22 2K - 320 16,64 vmem 4 38K - 11 128,512,1024,2048,4096 ioctlops 0 0K - 1297 16,32,64,128,256,512,1024 select 10 1K - 10 64 iov 0 0K - 79818 16,64,128,256 msg 4 25K - 4 1024,4096 sem 4 101K - 4 1024,4096 shm 1 12K - 1 tty 21 11K - 21 512 mbuf_tag 0 0K - 18 32 ksem 1 4K - 1 4096 shmfd 1 4K - 1 4096 soname 3 1K - 9384 16,32,128 pcb 19 91K - 54 16,64,512,1024,4096 vfscache 1 128K - 1 cl_savebuf 0 0K - 7 32 vfs_hash 1 64K - 1 vnodes 1 1K - 1 128 mount 34 2K - 143 16,32,64,128,256 vnodemarker 0 0K - 42 512 GSS-API 1 1K - 1 32 BPF 12 18K - 12 64,128,512,4096 ifnet 5 5K - 5 64,1024 ifaddr 53 10K - 54 16,32,64,128,256,512,1024,2048 ether_multi 17 1K - 24 16,32,64 clone 8 1K - 8 128 arpcom 1 1K - 1 16 lltable 12 3K - 12 256 routetbl 33 4K - 171 16,32,64,128,256 igmp 4 1K - 4 128 in_multi 2 1K - 3 128 encap_export_host 2 2K - 2 1024 sctp_a_it 0 0K - 3 16 sctp_vrf 1 1K - 1 64 sctp_ifa 4 1K - 4 128 sctp_ifn 2 1K - 2 128 sctp_iter 0 0K - 3 256 hostcache 1 16K - 1 syncache 1 44K - 1 in6_multi 15 2K - 15 16,256 mld 4 1K - 4 128 inpcbpolicy 11 1K - 179 16 ipsecpolicy 22 3K - 358 128 IpFw/IpAcct 17 31K - 28 16,32,64,128,512 NFS FHA 1 1K - 1 1024 crypto 1 1K - 1 512 rpc 2 1K - 2 128 audit_evclass 187 3K - 228 16 pagedep 2 9K - 1649 128 inodedep 25 70K - 4100 256 bmsafemap 5 5K - 1837 128,4096 newblk 24 131K - 3278 128 indirdep 0 0K - 124 64 freefrag 2 1K - 48 64 freeblks 4 1K - 717 128 freefile 6 1K - 1687 32 diradd 16 1K - 1742 64 mkdir 0 0K - 3274 64 dirrem 0 0K - 79 64 newdirblk 0 0K - 1639 32 freework 18 3K - 834 128,256 sbdep 0 0K - 16 32 savedino 8 2K - 1223 256 softdep 1 1K - 1 256 ufs_dirhash 29 10K - 89 16,32,64,512 ufs_mount 4 13K - 8 64,256,1024,4096 vm_pgdata 2 17K - 2 64 nullfs_hash 1 64K - 1 atkbddev 2 1K - 2 32 pfs_nodes 21 3K - 21 128 pfs_vncache 1 1K - 1 32 GEOM 113 21K - 505 16,32,64,128,256,512,1024 ppbusdev 3 1K - 3 128 memdesc 1 4K - 1 4096 entropy 1026 65K - 1028 16,64,4096 CAM dev queue 4 1K - 4 64 $PIR 6 1K - 6 32 envy24ht 15 194K - 15 32,64,1024 spicds 7 1K - 7 64 CAM SIM 4 1K - 4 128 agp 2 65K - 2 16 isadev 21 2K - 21 64 legacydrv 4 1K - 4 16 nexusdev 4 1K - 4 16 feeder 16 1K - 18 16,64 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 256, 0, 106, 14, 106, 0, 0 UMA Zones: 408, 0, 106, 2, 106, 0, 0 UMA Slabs: 56, 0, 5122, 62, 5573, 0, 0 UMA RCntSlabs: 64, 0, 319, 59, 374, 0, 0 UMA Hash: 128, 0, 3, 28, 3, 0, 0 4 Bucket: 16, 0, 6, 246, 381, 0, 0 6 Bucket: 24, 0, 0, 0, 0, 0, 0 8 Bucket: 32, 0, 2, 124, 2021, 0, 0 12 Bucket: 48, 0, 0, 0, 0, 0, 0 16 Bucket: 64, 0, 8, 118, 48, 0, 0 32 Bucket: 128, 0, 9, 146, 2054, 0, 0 64 Bucket: 256, 0, 14, 61, 215, 0, 0 128 Bucket: 512, 0, 62, 2, 795,3846, 0 vmem btag: 28, 0, 7567, 497, 8975, 110, 0 VM OBJECT: 156, 0, 1515, 60, 18171, 0, 0 RADIX NODE: 44, 59605, 5330, 4953, 122443, 0, 0 MAP: 144, 0, 3, 81, 3, 0, 0 KMAP ENTRY: 76, 0, 5, 154, 5, 0, 0 MAP ENTRY: 76, 0, 478, 158, 40973, 0, 0 VMSPACE: 240, 0, 27, 69, 1776, 0, 0 fakepg: 68, 0, 0, 0, 0, 0, 0 mt_zone: 76, 0, 299, 72, 299, 0, 0 16: 16, 0, 2152, 368, 8788, 0, 0 32: 32, 0, 944, 442, 7929, 0, 0 64: 64, 0, 2449, 638, 87186, 0, 0 128: 128, 0, 1115, 466, 26670, 0, 0 256: 256, 0, 396, 144, 6359, 0, 0 512: 512, 0, 340, 36, 1128, 0, 0 1024: 1024, 0, 84, 32, 2220, 0, 0 2048: 2048, 0, 9321, 9, 41863, 0, 0 4096: 4096, 0, 273, 4, 2055, 0, 0 uint64 pcpu: 8, 0, 2301, 219, 2301, 0, 0 SLEEPQUEUE: 44, 0, 91, 161, 91, 0, 0 Files: 56, 0, 61, 155, 53221, 0, 0 rl_entry: 28, 0, 34, 254, 34, 0, 0 TURNSTILE: 72, 0, 91, 126, 91, 0, 0 umtx pi: 52, 0, 0, 0, 0, 0, 0 MAC labels: 20, 0, 0, 0, 0, 0, 0 PROC: 748, 0, 46, 19, 1794, 0, 0 THREAD: 760, 0, 77, 13, 77, 0, 0 cpuset: 40, 0, 45, 157, 45, 0, 0 audit_record: 1112, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 32085, 512, 137, 567, 0, 0 mbuf: 256, 32085, 1, 262, 6795, 0, 0 mbuf_cluster: 2048, 5014, 637, 1, 750, 0, 0 mbuf_jumbo_page: 4096, 2506, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 2226, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1668, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 ttyoutq: 256, 0, 64, 41, 256, 0, 0 g_bio: 152, 0, 27, 103, 129555, 0, 0 icl_conn: 88, 0, 0, 0, 0, 0, 0 icl_pdu: 48, 0, 0, 0, 0, 0, 0 ttyinq: 152, 0, 120, 10, 480, 0, 0 ata_request: 220, 0, 1, 17, 34069, 0, 0 cryptop: 60, 0, 0, 0, 0, 0, 0 cryptodesc: 56, 0, 0, 0, 0, 0, 0 cfiscsi_data_wait: 32, 0, 0, 0, 0, 0, 0 VNODE: 284, 0, 2752, 20, 4442, 0, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0, 0 BUF TRIE: 44, 0, 33, 2242, 8894, 0, 0 NAMEI: 1024, 0, 0, 16, 87795, 0, 0 S VFS Cache: 72, 0, 2886, 138, 45560, 0, 0 STS VFS Cache: 92, 0, 0, 0, 0, 0, 0 L VFS Cache: 292, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 312, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 16, 16, 116, 0, 0 NCLNODE: 356, 0, 0, 0, 0, 0, 0 mqnode: 344, 0, 3, 8, 3, 0, 0 mqueue: 132, 0, 0, 0, 0, 0, 0 mvdata: 32, 0, 0, 0, 0, 0, 0 mqnotifier: 136, 0, 0, 0, 0, 0, 0 procdesc: 72, 0, 0, 0, 0, 0, 0 Mountpoints: 672, 0, 3, 15, 3, 0, 0 pipe: 408, 0, 1, 35, 1091, 0, 0 ksiginfo: 80, 0, 42, 158, 119, 0, 0 itimer: 232, 0, 1, 16, 1, 0, 0 KNOTE: 72, 0, 0, 0, 12, 0, 0 socket: 424, 7668, 19, 35, 1202, 0, 0 ipq: 32, 252, 0, 0, 0, 0, 0 udp_inpcb: 252, 7680, 8, 72, 160, 0, 0 udpcb: 8, 7812, 8, 244, 160, 0, 0 tcp_inpcb: 252, 7680, 2, 62, 6, 0, 0 tcpcb: 752, 7670, 2, 13, 6, 0, 0 tcptw: 60, 1541, 0, 0, 0, 0, 0 syncache: 124, 15360, 0, 0, 0, 0, 0 hostcache: 76, 15370, 0, 0, 0, 0, 0 tcpreass: 20, 404, 0, 0, 0, 0, 0 sackhole: 20, 0, 0, 0, 0, 0, 0 sctp_ep: 976, 7668, 0, 0, 0, 0, 0 sctp_asoc: 1592, 40000, 0, 0, 0, 0, 0 sctp_laddr: 24, 80136, 0, 0, 3, 0, 0 sctp_raddr: 532, 80003, 0, 0, 0, 0, 0 sctp_chunk: 96, 400008, 0, 0, 0, 0, 0 sctp_readq: 76, 400044, 0, 0, 0, 0, 0 sctp_stream_msg_out: 68, 400020, 0, 0, 0, 0, 0 sctp_asconf: 24, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 24, 400008, 0, 0, 0, 0, 0 ripcb: 252, 7680, 1, 63, 13, 0, 0 unpcb: 172, 7682, 6, 63, 1013, 0, 0 rtentry: 108, 0, 13, 24, 14, 0, 0 IPFW dynamic rule: 108, 4107, 0, 0, 0, 0, 0 divcb: 252, 7680, 0, 0, 0, 0, 0 selfd: 28, 0, 31, 113, 13555, 0, 0 SWAPMETA: 276, 30086, 31, 39, 36, 0, 0 FFS inode: 116, 0, 2711, 111, 4398, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 2711, 49, 4398, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq0: attimer0 834262 10695 irq1: atkbd0 275 3 irq7: ppc0 1 0 irq11: pcm0 bge0 92 1 irq14: ata0 32354 414 irq15: ata1 423 5 Total 867407 11120 ------------------------------------------------------------------------ pstat -T 61/7663 files 0M/2047M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/label/Swap 4194040 1016 4193024 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 ada1 pass0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 29.37 407 11.69 3.50 1 0.00 0.00 0 0.00 57 2 13 0 27 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 616 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 90916420708437821 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 7525346126759879536 ignored RSTs in the windows 0 connections established (including accepts) 0 connections closed (including 4 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 14223757787205729232 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 3231735672 cache overflow 13878490090660978560 reset 14024559434085171200 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 hostcache entries added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 8315177820320982133 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 39 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 2 with no checksum 38 dropped due to no socket 0 broadcast/multicast datagrams undelivered 14202747855163872744 dropped due to full socket buffers 0 not for hashed pcb 4243996218545678873 delivered 13876054981724591340 datagrams output 90916420708441584 times multicast source filter matched ip: 40 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 13880185520411137644 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 39 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 0 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 13880189073412325376 packets sent from this host 0 packets sent with fabricated ip header 13880189107772063744 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: destination unreachable: 3311909552 source quench: 3311909568 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent ipsec: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 8029953746877509737 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 0 mbufs inserted during makespace ah: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets dropped; bad authentication detected 0 packets dropped; bad authentication length 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures esp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 packets dropped; bad ilen 0 replay counter wraps 0 packets dropped; bad encryption detected 0 packets dropped; bad authentication detected 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures ESP output histogram: #139: 14027524820258542848 #144: 2326202804928401481 #148: 17042560347969784149 #149: 615594868859046229 #152: 13878550752779075852 #153: 17042560347969784149 #154: 7235444513182665806 ipcomp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures COMP output histogram: #6: 14027524820258542848 0 packets sent uncompressed; size < compr. algo. threshold 0 packets sent uncompressed; compression was useless arp: 2 ARP requests sent 4 ARP replies sent 5 ARP requests received 0 ARP replies received 0 ARP packets received 7598817722882813545 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 4 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Input histogram: #184: 13880216990699749376 #185: 13880217025059487744 #187: 219269010088473984 #194: 14222497300200060400 #195: 7233175079288729193 #198: 14202724899545415680 #233: 13879875595571065172 #236: 17042560347969784149 #239: 3263241216 #240: 13880218897665228800 Mbuf statistics: 0 one mbuf two or more mbuf: (null)= 8029953746877509737 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: #11: 75153822012557581 #15: 3231738164 #16: 13878518420265265468 #17: 13878517389473114436 #18: 3231738188 #19: 13878523986542881108 #227: 13880216990699749376 #228: 13880217025059487744 #237: 14222505134140714960 #240: 14202724645154207384 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 13878529449741283660 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes ipsec6: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 0 mbufs inserted during makespace rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output pfkey: 0 requests sent from userland 0 bytes sent from userland 0 messages with invalid length field 0 messages with invalid version field 0 messages with invalid message type field 0 messages too short 0 messages with memory allocation failure 0 messages with duplicate extension 0 messages with invalid extension type 0 messages with invalid sa type 0 messages with invalid address extension 0 requests sent to userland 0 bytes sent to userland histogram by message type: #175: 7022364301717819465 #182: 17042560347969784149 #185: 13878548759914250504 #186: 17042560347969784149 0 messages toward single socket 0 messages toward all sockets 0 messages toward registered sockets 0 messages with memory allocation failure ------------------------------------------------------------------------ netstat -m 513/399/912 mbufs in use (current/cache/total) 500/138/638/5014 mbuf clusters in use (current/cache/total/max) 512/137 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/2506 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/2226 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1668 16k jumbo clusters in use (current/cache/total/max) 1128K/375K/1504K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile ------------------------------------------------------------------------ netstat -idW Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop bge0 1500 00:10:18:0a:dd:27 45 0 0 41 0 0 0 bge0 1500 192.168.1.0 192.168.1.184 39 - - 38 - - - plip0* 1500 0 0 0 0 0 0 0 lo0 16384 0 0 0 0 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 0 - - 0 - - - enc0* 1536 0 0 0 0 0 0 0 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 32 bge0 127.0.0.1 link#3 UH 0 0 lo0 192.168.1.0/24 link#1 U 0 6 bge0 192.168.1.184 link#1 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#3 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c59822f0 tcp4 0 0 *.22 *.* LISTEN c59825e0 tcp6 0 0 *.22 *.* LISTEN c57bd4ec udp4 0 0 127.0.0.1.123 *.* c57bd5e8 udp6 0 0 fe80::1%lo0.123 *.* c57bd6e4 udp6 0 0 ::1.123 *.* c57bd7e0 udp4 0 0 192.168.1.184.123 *.* c57bd8dc udp6 0 0 *.123 *.* c57bd9d8 udp4 0 0 *.123 *.* c57bdad4 udp4 0 0 *.514 *.* c57bdbd0 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c5940968 stream 0 0 c5941c34 0 0 0 /var/run/devd.pipe c594060c dgram 0 0 0 c5940810 0 c59406b8 c59406b8 dgram 0 0 0 c5940810 0 c5940764 c5940764 dgram 0 0 0 c5940810 0 0 c5940810 dgram 0 0 c5968d50 0 c594060c 0 /var/run/logpriv c59408bc dgram 0 0 c5968e6c 0 0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 6 at 0xffff fstat: can't read file 7 at 0x78 fstat: can't read file 10 at 0xffffffff fstat: can't read file 11 at 0x200007f fstat: can't read file 12 at 0x1fffff fstat: can't read file 13 at 0x4000000 fstat: can't read file 15 at 0xffff fstat: can't read file 16 at 0x78 fstat: can't read file 19 at 0xffffffff fstat: can't read file 20 at 0x200007f fstat: can't read file 21 at 0x1fffff fstat: can't read file 22 at 0x4000000 fstat: can't read file 24 at 0xffff fstat: can't read file 25 at 0x78 fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 6 at 0xffff fstat: can't read file 7 at 0x78 fstat: can't read file 10 at 0xffffffff fstat: can't read file 11 at 0x200007f fstat: can't read file 12 at 0x1fffff fstat: can't read file 13 at 0x4000000 fstat: can't read file 15 at 0xffff fstat: can't read file 16 at 0x78 fstat: can't read file 19 at 0xffffffff fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 2 at 0x2000000 fstat: can't read file 4 at 0x4000000 fstat: can't read file 1 at 0xffffffff fstat: can't read file 2 at 0x200007f fstat: can't read file 3 at 0x1fffff fstat: can't read file 4 at 0x4000000 fstat: can't read file 6 at 0xffff fstat: can't read file 7 at 0x78 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root c++ 1794 root / 2 drwxr-xr-x 512 r root c++ 1794 wd / 1532195 drwxr-xr-x 1024 r root c++ 1794 text / 323107 -r-xr-xr-x 19301616 r root c++ 1794 ctty /dev 70 crw------- ttyv1 rw root c++ 1794 0 /dev 70 crw------- ttyv1 rw root c++ 1793 root / 2 drwxr-xr-x 512 r root c++ 1793 wd / 1532195 drwxr-xr-x 1024 r root c++ 1793 text / 323107 -r-xr-xr-x 19301616 r root c++ 1793 ctty /dev 70 crw------- ttyv1 rw root c++ 1793 0 /dev 70 crw------- ttyv1 rw root make 1725 root / 2 drwxr-xr-x 512 r root make 1725 wd / 1532195 drwxr-xr-x 1024 r root make 1725 text / 321734 -r-xr-xr-x 532776 r root make 1725 ctty /dev 70 crw------- ttyv1 rw root make 1725 0 /dev 70 crw------- ttyv1 rw root sh 1623 root / 2 drwxr-xr-x 512 r root sh 1623 wd / 809467 drwxr-xr-x 512 r root sh 1623 text / 3290533 -r-xr-xr-x 103076 r root sh 1623 ctty /dev 70 crw------- ttyv1 rw root sh 1623 0 /dev 70 crw------- ttyv1 rw root make 1619 root / 2 drwxr-xr-x 512 r root make 1619 wd / 1450151 drwxr-xr-x 512 r root make 1619 text / 321734 -r-xr-xr-x 532776 r root make 1619 ctty /dev 70 crw------- ttyv1 rw root make 1619 0 /dev 70 crw------- ttyv1 rw root make 1488 root / 2 drwxr-xr-x 512 r root make 1488 wd / 321026 drwxr-xr-x 1024 r root make 1488 text / 321734 -r-xr-xr-x 532776 r root make 1488 ctty /dev 70 crw------- ttyv1 rw root make 1488 0 /dev 70 crw------- ttyv1 rw root make 1483 root / 2 drwxr-xr-x 512 r root make 1483 wd / 321026 drwxr-xr-x 1024 r root make 1483 text / 321734 -r-xr-xr-x 532776 r root make 1483 ctty /dev 70 crw------- ttyv1 rw root make 1483 0 /dev 70 crw------- ttyv1 rw root csh 1479 root / 2 drwxr-xr-x 512 r root csh 1479 wd / 321026 drwxr-xr-x 1024 r root csh 1479 text / 3290501 -r-xr-xr-x 295816 r root csh 1479 ctty /dev 70 crw------- ttyv1 rw root top 1478 root / 2 drwxr-xr-x 512 r root top 1478 wd / 642048 drwxr-xr-x 512 r root top 1478 text / 321074 -r-xr-xr-x 44520 r root top 1478 ctty /dev 71 crw------- ttyv2 rw root top 1478 0 /dev 71 crw------- ttyv2 rw root csh 1476 root / 2 drwxr-xr-x 512 r root csh 1476 wd / 642048 drwxr-xr-x 512 r root csh 1476 text / 3290501 -r-xr-xr-x 295816 r root csh 1476 ctty /dev 71 crw------- ttyv2 rw root getty 1475 root / 2 drwxr-xr-x 512 r root getty 1475 wd / 2 drwxr-xr-x 512 r root getty 1475 text / 326373 -r-xr-xr-x 20816 r root getty 1475 ctty /dev 76 crw------- ttyv7 rw root getty 1475 0 /dev 76 crw------- ttyv7 rw root getty 1474 root / 2 drwxr-xr-x 512 r root getty 1474 wd / 2 drwxr-xr-x 512 r root getty 1474 text / 326373 -r-xr-xr-x 20816 r root getty 1474 ctty /dev 75 crw------- ttyv6 rw root getty 1474 0 /dev 75 crw------- ttyv6 rw root getty 1473 root / 2 drwxr-xr-x 512 r root getty 1473 wd / 2 drwxr-xr-x 512 r root getty 1473 text / 326373 -r-xr-xr-x 20816 r root getty 1473 ctty /dev 74 crw------- ttyv5 rw root getty 1473 0 /dev 74 crw------- ttyv5 rw root getty 1472 root / 2 drwxr-xr-x 512 r root getty 1472 wd / 2 drwxr-xr-x 512 r root getty 1472 text / 326373 -r-xr-xr-x 20816 r root getty 1472 ctty /dev 73 crw------- ttyv4 rw root getty 1472 0 /dev 73 crw------- ttyv4 rw root getty 1471 root / 2 drwxr-xr-x 512 r root getty 1471 wd / 2 drwxr-xr-x 512 r root getty 1471 text / 326373 -r-xr-xr-x 20816 r root getty 1471 ctty /dev 72 crw------- ttyv3 rw root getty 1471 0 /dev 72 crw------- ttyv3 rw root login 1470 root / 2 drwxr-xr-x 512 r root login 1470 wd / 642048 drwxr-xr-x 512 r root login 1470 text / 324375 -r-sr-xr-x 20220 r root login 1470 ctty /dev 71 crw------- ttyv2 rw root login 1470 0 /dev 71 crw------- ttyv2 rw root login 1469 root / 2 drwxr-xr-x 512 r root login 1469 wd / 642048 drwxr-xr-x 512 r root login 1469 text / 324375 -r-sr-xr-x 20220 r root login 1469 ctty /dev 70 crw------- ttyv1 rw root login 1469 0 /dev 70 crw------- ttyv1 rw root getty 1468 root / 2 drwxr-xr-x 512 r root getty 1468 wd / 2 drwxr-xr-x 512 r root getty 1468 text / 326373 -r-xr-xr-x 20816 r root getty 1468 ctty /dev 69 crw------- ttyv0 rw root getty 1468 0 /dev 69 crw------- ttyv0 rw root moused 1425 root / 2 drwxr-xr-x 512 r root moused 1425 wd / 2 drwxr-xr-x 512 r root moused 1425 text / 331879 -r-xr-xr-x 33784 r root moused 1425 0 /dev 25 crw-rw-rw- null rw root cron 1402 root / 2 drwxr-xr-x 512 r root cron 1402 wd / 2327438 drwxr-x--- 512 r root cron 1402 text / 329872 -r-xr-xr-x 32236 r root cron 1402 0 /dev 25 crw-rw-rw- null rw root sshd 1398 root / 2 drwxr-xr-x 512 r root sshd 1398 wd / 2 drwxr-xr-x 512 r root sshd 1398 text / 325266 -r-xr-xr-x 239160 r root sshd 1398 0 /dev 25 crw-rw-rw- null rw root ntpd 1369 root / 2 drwxr-xr-x 512 r root ntpd 1369 wd / 2 drwxr-xr-x 512 r root ntpd 1369 text / 322091 -r-xr-xr-x 324060 r root ntpd 1369 0 /dev 25 crw-rw-rw- null rw root ntpd 1369 9 /dev 25 crw-rw-rw- null rw root ntpd 1369 18 /dev 25 crw-rw-rw- null rw root syslogd 1274 root / 2 drwxr-xr-x 512 r root syslogd 1274 wd / 2 drwxr-xr-x 512 r root syslogd 1274 text / 327708 -r-xr-xr-x 33220 r root syslogd 1274 0 /dev 25 crw-rw-rw- null rw root syslogd 1274 9 /dev 25 crw-rw-rw- null rw root syslogd 1274 18 /dev 25 crw-rw-rw- null rw root devd 1127 root / 2 drwxr-xr-x 512 r root devd 1127 wd / 2 drwxr-xr-x 512 r root devd 1127 text / 3211443 -r-xr-xr-x 813828 r root devd 1127 0 /dev 25 crw-rw-rw- null rw _dhcp dhclient 1126 root / 2327440 dr-xr-xr-x 512 r _dhcp dhclient 1126 wd / 2327440 dr-xr-xr-x 512 r _dhcp dhclient 1126 jail / 2327440 dr-xr-xr-x 512 r _dhcp dhclient 1126 text / 3211441 -r-xr-xr-x 73992 r _dhcp dhclient 1126 0 /dev 25 crw-rw-rw- null rw _dhcp dhclient 1126 9 /dev 25 crw-rw-rw- null rw root dhclient 1090 root / 2 drwxr-xr-x 512 r root dhclient 1090 wd / 2 drwxr-xr-x 512 r root dhclient 1090 text / 3211441 -r-xr-xr-x 73992 r root dhclient 1090 0 /dev 25 crw-rw-rw- null rw root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 3211467 -r-xr-xr-x 757256 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2014 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 10.0-PRERELEASE #1: Sat Jan 11 09:00:08 CET 2014 root@music2.reztek:/usr/obj/usr/src/sys/MUSIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: VIA Samuel 2 (797.98-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Family = 0x6 Model = 0x7 Stepping = 3 Features=0x803035 AMD Features=0x80000000<3DNow!> real memory = 268435456 (256 MB) avail memory = 244457472 (233 MB) random: initialized kbd1 at kbdmux0 cryptosoft0: on motherboard apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0 pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 64M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xdf000000-0xdf7fffff,0xdfae0000-0xdfafffff,0xde800000-0xdeffffff at device 0.0 on pci1 vgapci0: Boot video device isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xec00-0xec1f irq 10 at device 7.3 on pci0 usbus0 on uhci0 viapropm0: port 0x400-0x40f at device 7.4 on pci0 smbus0: on viapropm0 smb0: on smbus0 bge0: mem 0xdfff0000-0xdfffffff irq 11 at device 11.0 on pci0 bge0: CHIP ID 0x00003001; ASIC REV 0x03; CHIP REV 0x30; PCI 33 MHz; 32bit miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:10:18:0a:dd:27 pcm0: port 0xe800-0xe81f,0xe400-0xe47f irq 11 at device 12.0 on pci0 pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff cpu0 on motherboard pmtimer0 on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) attimer0: at port 0x40-0x43 irq 0 pnpid PNP0100 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: at port 0x70-0x71 irq 8 pnpid PNP0b00 on isa0 atkbdc0: at port 0x60,0x64 irq 1 pnpid PNP0303 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0 uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 pnpid PNP0501 on isa0 ppc0: at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 pnpid PNP0401 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart2: <16550 or compatible> at port 0x3e8-0x3ef irq 5 pnpid PNP0501 on isa0 uart3: <16550 or compatible> at port 0x2e8-0x2ef irq 9 pnpid PNP0501 on isa0 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xcd7ff,0xe0000-0xe0fff pnpid ORM0000 on isa0 sc0: at flags 0x180 on isa0 sc0: VGA <16 virtual consoles, flags=0x380> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) driver bug: Unable to set devclass (class: fdc devname: (unknown)) Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to deny, logging disabled random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-5 device ada0: Serial Number M0000000 ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada0: 34837MB (71346240 512 byte sectors: 16H 255S/T 16383C) ada0: Previously was known as ad0 ada1 at ata1 bus 0 scbus1 target 0 lun 0 ada1: ATA-0 device ada1: Serial Number SSSI128M04Z13A22431A ada1: 16.700MB/s transfers (PIO4, PIO 512bytes) ada1: 122MB (250368 512 byte sectors: 8H 32S/T 978C) ada1: Previously was known as ad2 uhub0: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/label/Root [rw,noatime]... WARNING: /rw/mnt was not properly dismounted Setting hostuuid: 3ca7a290-710d-11e3-a608-00a0c94b3124. Setting hostid: 0xfac708b2. Entropy harvesting: interrupts ethernet point_to_point swi. warning: total configured swap (524287 pages) exceeds maximum recommended amount (481376 pages). warning: increase kern.maxswzone or reduce amount of swap. Starting file system checks: /dev/label/Root: DEFER FOR BACKGROUND CHECKING WARNING: / was not properly dismounted Mounting local file systems:. Writing entropy file:. Setting hostname: music2.reztek. Starting Network: lo0 bge0 plip0 enc0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 bge0: flags=8843 metric 0 mtu 1500 options=8009b ether 00:10:18:0a:dd:27 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active plip0: flags=8810 metric 0 mtu 1500 nd6 options=29 enc0: flags=0<> metric 0 mtu 1536 nd6 options=29 Starting devd. Starting Network: plip0. plip0: flags=8810 metric 0 mtu 1500 nd6 options=29 Starting Network: enc0. enc0: flags=0<> metric 0 mtu 1536 nd6 options=29 Starting dhclient. DHCPREQUEST on bge0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.184 -- renewal in 3600 seconds. add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 65000 allow ip from any to any Firewall rules loaded. Creating and/or trimming log files. Starting syslogd. No core dumps found. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Starting ntpd. Configuring syscons: keyrate blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting default moused. mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured mixer: WRITE_MIXER: Device not configured Starting background file system checks in 60 seconds. Sun Feb 2 19:58:36 CET 2014 Feb 2 19:58:48 music2 login: ROOT LOGIN (root) ON ttyv2 Feb 2 19:59:02 music2 login: ROOT LOGIN (root) ON ttyv1 calcru: runtime went backwards from 102407 usec to 100464 usec for pid 1479 (csh) calcru: runtime went backwards from 3221 usec to 3160 usec for pid 1479 (csh) calcru: runtime went backwards from 123173 usec to 120836 usec for pid 1476 (csh) calcru: runtime went backwards from 3236 usec to 3175 usec for pid 1476 (csh) calcru: runtime went backwards from 13832 usec to 13569 usec for pid 1475 (getty) calcru: runtime went backwards from 14486 usec to 14211 usec for pid 1474 (getty) calcru: runtime went backwards from 13986 usec to 13721 usec for pid 1473 (getty) calcru: runtime went backwards from 13541 usec to 13284 usec for pid 1472 (getty) calcru: runtime went backwards from 13637 usec to 13378 usec for pid 1471 (getty) calcru: runtime went backwards from 439925 usec to 431578 usec for pid 1470 (login) calcru: runtime went backwards from 430411 usec to 422245 usec for pid 1469 (login) calcru: runtime went backwards from 14666 usec to 14387 usec for pid 1468 (getty) calcru: runtime went backwards from 6080 usec to 5965 usec for pid 1467 (sleep) calcru: runtime went backwards from 8127 usec to 7973 usec for pid 1465 (logger) calcru: runtime went backwards from 1916 usec to 1879 usec for pid 1464 (sh) calcru: runtime went backwards from 960 usec to 941 usec for pid 1425 (moused) calcru: runtime went backwards from 35678 usec to 35001 usec for pid 1402 (cron) calcru: runtime went backwards from 129531 usec to 127073 usec for pid 1402 (cron) calcru: runtime went backwards from 4575 usec to 4488 usec for pid 1398 (sshd) calcru: runtime went backwards from 82237 usec to 81131 usec for pid 1369 (ntpd) calcru: runtime went backwards from 50080 usec to 49244 usec for pid 1274 (syslogd) calcru: runtime went backwards from 559 usec to 548 usec for pid 1127 (devd) calcru: runtime went backwards from 2008 usec to 1970 usec for pid 1126 (dhclient) calcru: runtime went backwards from 5698 usec to 5590 usec for pid 1090 (dhclient) calcru: runtime went backwards from 261424 usec to 256463 usec for pid 1090 (dhclient) calcru: runtime went backwards from 2864 usec to 2810 usec for pid 15 (usb) calcru: runtime went backwards from 53852 usec to 53166 usec for pid 4 (cam) calcru: runtime went backwards from 48080 usec to 47168 usec for pid 13 (geom) calcru: runtime went backwards from 4733641 usec to 4644716 usec for pid 12 (intr) calcru: runtime went backwards from 31166 usec to 30575 usec for pid 1 (init) calcru: runtime went backwards from 14544175 usec to 14268208 usec for pid 1 (init) calcru: runtime went backwards from 6105 usec to 5989 usec for pid 0 (kernel) calcru: runtime went backwards from 1412020 usec to 1397733 usec for pid 1642 (cc) calcru: runtime went backwards from 28811 usec to 28307 usec for pid 1641 (sh) calcru: runtime went backwards from 165082 usec to 162195 usec for pid 1628 (make) calcru: runtime went backwards from 745974 usec to 732927 usec for pid 1628 (make) calcru: runtime went backwards from 12279 usec to 12065 usec for pid 1623 (sh) calcru: runtime went backwards from 173321 usec to 170290 usec for pid 1623 (sh) calcru: runtime went backwards from 117057 usec to 115010 usec for pid 1619 (make) calcru: runtime went backwards from 74623 usec to 73318 usec for pid 1619 (make) calcru: runtime went backwards from 158886 usec to 156107 usec for pid 1488 (make) calcru: runtime went backwards from 4271263 usec to 4196562 usec for pid 1488 (make) calcru: runtime went backwards from 33800 usec to 33052 usec for pid 1483 (make) calcru: runtime went backwards from 75088 usec to 73425 usec for pid 1483 (make) calcru: runtime went backwards from 110913 usec to 108457 usec for pid 1479 (csh) calcru: runtime went backwards from 3160 usec to 3090 usec for pid 1479 (csh) calcru: runtime went backwards from 120836 usec to 118161 usec for pid 1476 (csh) calcru: runtime went backwards from 3175 usec to 3105 usec for pid 1476 (csh) calcru: runtime went backwards from 13569 usec to 13269 usec for pid 1475 (getty) calcru: runtime went backwards from 14211 usec to 13896 usec for pid 1474 (getty) calcru: runtime went backwards from 13721 usec to 13417 usec for pid 1473 (getty) calcru: runtime went backwards from 13284 usec to 12990 usec for pid 1472 (getty) calcru: runtime went backwards from 13378 usec to 13082 usec for pid 1471 (getty) calcru: runtime went backwards from 431578 usec to 422023 usec for pid 1470 (login) calcru: runtime went backwards from 422245 usec to 412896 usec for pid 1469 (login) calcru: runtime went backwards from 14387 usec to 14069 usec for pid 1468 (getty) calcru: runtime went backwards from 7973 usec to 7797 usec for pid 1465 (logger) calcru: runtime went backwards from 18177 usec to 17775 usec for pid 1464 (fsck) calcru: runtime went backwards from 18473 usec to 18064 usec for pid 1464 (fsck) calcru: runtime went backwards from 941 usec to 920 usec for pid 1425 (moused) calcru: runtime went backwards from 53539 usec to 52603 usec for pid 1402 (cron) calcru: runtime went backwards from 127073 usec to 124260 usec for pid 1402 (cron) calcru: runtime went backwards from 4488 usec to 4388 usec for pid 1398 (sshd) calcru: runtime went backwards from 94122 usec to 92825 usec for pid 1369 (ntpd) calcru: runtime went backwards from 53106 usec to 51930 usec for pid 1274 (syslogd) calcru: runtime went backwards from 598 usec to 585 usec for pid 1127 (devd) calcru: runtime went backwards from 1970 usec to 1926 usec for pid 1126 (dhclient) calcru: runtime went backwards from 5590 usec to 5466 usec for pid 1090 (dhclient) calcru: runtime went backwards from 256463 usec to 250785 usec for pid 1090 (dhclient) calcru: runtime went backwards from 7718 usec to 7639 usec for pid 19 (softdepflush) calcru: runtime went backwards from 38789 usec to 38221 usec for pid 17 (syncer) calcru: runtime went backwards from 358656 usec to 352431 usec for pid 16 (bufdaemon) calcru: runtime went backwards from 4154 usec to 4081 usec for pid 15 (usb) calcru: runtime went backwards from 47168 usec to 46123 usec for pid 13 (geom) calcru: runtime went backwards from 5887433 usec to 5826978 usec for pid 12 (intr) calcru: runtime went backwards from 92330108 usec to 91081619 usec for pid 11 (idle) calcru: runtime went backwards from 30575 usec to 29898 usec for pid 1 (init) calcru: runtime went backwards from 14268208 usec to 13952316 usec for pid 1 (init) calcru: runtime went backwards from 7442 usec to 7312 usec for pid 0 (kernel) panic: handle_written_inodeblock: Invalid link count 65529 for inodedep 0xc7648b00 KDB: stack backtrace: #0 0xc0667f6f at kdb_backtrace+0x52 #1 0xc063dc7d at panic+0x85 #2 0xc084483f at softdep_disk_write_complete+0x1294 #3 0xc06b0656 at bufdone_finish+0x23 #4 0xc06b04f5 at bufdone+0x39 #5 0xc05e0d13 at g_vfs_done+0x289 #6 0xc05dd8ea at g_io_deliver+0x28f #7 0xc05e0648 at g_std_done+0x4e #8 0xc05dd8ea at g_io_deliver+0x28f #9 0xc05e0648 at g_std_done+0x4e #10 0xc05dd8ea at g_io_deliver+0x28f #11 0xc05e0648 at g_std_done+0x4e #12 0xc05dd8ea at g_io_deliver+0x28f #13 0xc05db68f at g_disk_done_single+0xfa #14 0xc0487fb7 at adadone+0x482 #15 0xc046de75 at xpt_done_process+0x435 #16 0xc0470a11 at xpt_done_td+0x15a #17 0xc0615573 at fork_exit+0xa3 Uptime: 6m58s Physical memory: 239 MB Dumping 102 MB: 87 71 55 39 23 7 ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident MUSIC machine i386 cpu I686_CPU cpu I586_CPU makeoptions WITH_CTF=1 makeoptions DEBUG=-g options SC_TWOBUTTON_MOUSE options SC_HISTORY_SIZE=5000 options SC_PIXEL_MODE options X86BIOS options VESA options ATA_STATIC_ID options DDB_CTF options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options KDTRACE_HOOKS options MAC options PROCDESC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options P1003_1B_MQUEUE options P1003_1B_SEMAPHORES options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options GEOM_LABEL options GEOM_PART_GPT options TMPFS options PSEUDOFS options PROCFS options NULLFS options FDESCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options KGSSAPI options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options TCP_SIGNATURE options IPSEC_NAT_T options IPSEC options LIBALIAS options IPDIVERT options IPFIREWALL_NAT options IPFIREWALL options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_4BSD options NEW_PCIB options NATIVE options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD options ISAPNP device isa device npx device mem device io device uart_ns8250 device atpic device pci device agp device fdc device ata device scbus device da device sa device cd device pass device ses device ctl device atkbdc device atkbd device kbdmux device psm device vga device splash device sc device apm device pmtimer device smbus device viapm device smb device iicbus device iicbb device iicsmb device uart device ppc device ppbus device lpt device plip device ppi device mii device brgphy device bge device loop device random device ether device vlan device enc device tun device gif device faith device crypto device pty device md device firmware device bpf device uhci device usb device uhid device ukbd device umass device ums device sound device snd_envy24ht device snd_spicds ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist From owner-freebsd-stable@FreeBSD.ORG Sun Feb 2 23:59:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E09038B for ; Sun, 2 Feb 2014 23:59:59 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0EE11331 for ; Sun, 2 Feb 2014 23:59:58 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id c9so10066679qcz.17 for ; Sun, 02 Feb 2014 15:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=amMGfADHqti3ugN7Y9plU38/nDJEepzCr9NIVbFC7vM=; b=pl1+oV8JyDdPp/AZHIPPTkFg2PFKHpu36KakIsJXQ4T9/qjibwbUpmFlB7RoG8fpyd VAfOSYg+43qya3l9Bpgw30UQ1NWrAy574FNEJVou3f0EcN6bsN35fSEVIONIY6y1qEU/ sZCClaUIBIJrPWvNzaryEA1IolO6nVBnZrquh6iIcCZoL6WNBlWnfYFCCI/UdEDV+Lq7 Hc5ON11IBJ+Jfj0JJhaTvuCweHyvpv8ZaWT1HU+AOAqP8vu5uhVVqklwCaTARyxcPRzh 7Xq3h3FLllr5wcUWVWKivhKxZgM1mckMeu/S/QZFgZaT1h71KzLMb/S0ox2wMpsP9/+J 3CYA== MIME-Version: 1.0 X-Received: by 10.140.91.23 with SMTP id y23mr49150877qgd.3.1391385597994; Sun, 02 Feb 2014 15:59:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Sun, 2 Feb 2014 15:59:57 -0800 (PST) In-Reply-To: <20140202204623.00003fe5@unknown> References: <20140201070912.00007971@unknown> <20140201221612.00001897@unknown> <20140202204623.00003fe5@unknown> Date: Sun, 2 Feb 2014 15:59:57 -0800 X-Google-Sender-Auth: 5m6J53LR8GIaXzvrvGf7Yjj5Zwk Message-ID: Subject: Re: Tuning kern.maxswzone is minor compared to hangs in "kmem a" state From: Adrian Chadd To: Matthew Rezny Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Feb 2014 23:59:59 -0000 [snip] So next time this happens, run "procstat -kka" - this will dump out the processes and a basic function call trace for each of them. I'll see if there's a way to teach procstat to output line numbers if the kernel debug image is available, but generally that's enough to then pass to kgdb to figure out the line number. -a From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 05:02:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C87A4943 for ; Mon, 3 Feb 2014 05:02:53 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 506F11C99 for ; Mon, 3 Feb 2014 05:02:52 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.7/8.14.7) with ESMTP id s1352j57047250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Feb 2014 06:02:46 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-stable@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s1352drN084544; Mon, 3 Feb 2014 12:02:40 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <52EF22EF.8010902@grosbein.net> Date: Mon, 03 Feb 2014 12:02:39 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matthew Rezny Subject: Re: Tuning kern.maxswzone is minor compared to hangs in "kmem a" state References: <20140201070912.00007971@unknown> <20140201221612.00001897@unknown> <20140202204623.00003fe5@unknown> In-Reply-To: <20140202204623.00003fe5@unknown> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eg.sd.rdtc.ru Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 05:02:53 -0000 On 03.02.2014 02:46, Matthew Rezny wrote: > Just as I was about to hit send, the box panicked. Finally a panic and > not just a hang so there's a backtrace! That should be the first hint > as to where in the kernel I'm hitting trouble. The panic points the > finger at UFS. The filesystem has seen some thrashing but it did just > fsck without significant error before that build was started. So, I'm > thinking it's not on-disk corruption but an in-memory problem. It blew > up writing a softdep, which starts me wondering if the buffers used for > softupdates bookkeeping are overflowing in the kernel. That would make > some sense, rapidly creating (svn/tar) or deleting (rm) many small > files will create a huge amount of activity for softupdates to track, > defer and reorder. The rm case is probably the one than can trigger it > the fastest because deletes are focusing the beating on the metadata > without wasting time between on file data I/O. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/176857 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 07:28:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F4F6C99 for ; Mon, 3 Feb 2014 07:28:22 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EFFB16D4 for ; Mon, 3 Feb 2014 07:28:22 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id as1so6124497iec.2 for ; Sun, 02 Feb 2014 23:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HjEn6eLRY4AqS75jJA+m7ZBv4oUrgtAJVXJjwEqyxDU=; b=We906MGI+/2po6dgZ0lqjHbmp2DoZXQoU0Wd1H2kc9uCJfSWqX6Dzjgv76wfqNRymw QGMKgmW3Ob6Cdvnuji1oNmGd98Cb9A6LOa5sLPi22UA8V0bXGu2nPu3ANUSP6xbLg6nw tHQ1f4fg4mbEgoeJAwbZnYP26I9QgR1DA/ElQLr4gJxw1s5rxXW1AkU2xbfp+v7E13IN z3CrRD6miYXii01lcF4J6yxmXLUgmJHy/I112GQwdgHoHhIQakPrAyPyK9N3/wsbjiqh QKsxKVW9Ad19K3W5F9Rz0W8YKnF47J7aDANdTz39/3A4hT4MovmqU5J0tz3AUbMLDC5Q h66g== MIME-Version: 1.0 X-Received: by 10.50.232.9 with SMTP id tk9mr10690294igc.27.1391412501761; Sun, 02 Feb 2014 23:28:21 -0800 (PST) Received: by 10.50.67.84 with HTTP; Sun, 2 Feb 2014 23:28:21 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 01:28:21 -0600 Message-ID: Subject: Re: Recovery of zpools went corrupt!? From: Scot Hetzel To: Zenny Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , Devin Teske X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 07:28:22 -0000 On Sun, Feb 2, 2014 at 1:04 PM, Zenny wrote: > Reposting the mail below as I had an oversight not to include subject > line. Apology in advance! > >> Hi: >> >> Last time, Devin had been very kind to suggest me when the system >> borked while trying to upgrade from v10B3 to vRC1. >> >> Following FreeBSD 10.0-RELEASE, I installed to a new machine with >> encrypted root in zfs mirror, and since there was something wrong (a >> double quote by mistake) inserted in the /boot/device.hints, the >> kernel refused to boot and landed to the mountroot prompt. >> >> Therefore, in order to make changes what I did was: >> >> 1. Boot into LiveCD mode >> 2. mkdir /tmp/bootpool >> zpool import -f bootpool >> zfs set mountpoint=/tmp/bootpool bootpool >> zfs mount -a >> cp /tmp/bootpool/boot/encryption.key /tmp/ >> zfs umount -a >> zfs set mountpoint=/bootpool bootpool >> zpool export bootpool >> geli attach -k /tmp/encryption.key /dev/ada0p4 >> geli attach -k /tmp/encryption.key /dev/ada1p4 >> zpool import -R /mnt zroot >> zpool import -R /mnt/bootpool bootpool >> 3. Removed the double quote (") from /bootpool/boot/device.hints and >> saved the file. >> >> 4. Rebooted the file and now it says that there is no boot/zfsbootloader. >> Does the file /boot/zfsloader exist in /boot or /bootpool/boot? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 09:14:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAD9AB96 for ; Mon, 3 Feb 2014 09:14:50 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92C1F1F8A for ; Mon, 3 Feb 2014 09:14:50 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id rd3so6822418pab.16 for ; Mon, 03 Feb 2014 01:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9jJHVVMbfCkBB8KOLIhAvMZNnfCLJ1NK3nJtxKk2IU=; b=D4HMuky6eGoFiotlUPdkZuhvOsWBM4bPRAF9XfHdIlhsynquXKo6FAa2Q1EgT1vB4q jE8mD/hy3h2uVHTH/XdT5C3Jr5A8eC/cgp9v0r7dei8FJGaUcO4YXk9rBPJkBTwD4apK KVsW/UkjW4BXQVCcPY94+Gcvf1InHY1F+BsHTPVzcBwXBdDBV6mMDc18pEDqUJOgxfDp p5NAhjMTF0OVENn7Y7dRraYEaKE70RuDINkh6NaIwx1awu4FADGfzbwVUWJK5vf7VxjX HChGfz3kZ5IRJSRJcI6jlwtn1X+ynjY8K6KbuSDI1N/HqtZz1lxkZ3EYXOBIajQsTG0T Xwzw== MIME-Version: 1.0 X-Received: by 10.68.66.1 with SMTP id b1mr36097983pbt.43.1391418890127; Mon, 03 Feb 2014 01:14:50 -0800 (PST) Received: by 10.66.142.167 with HTTP; Mon, 3 Feb 2014 01:14:50 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 10:14:50 +0100 Message-ID: Subject: Re: Recovery of zpools went corrupt!? From: Zenny To: Scot Hetzel Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , Devin Teske X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 09:14:50 -0000 On 2/3/14, Scot Hetzel wrote: > On Sun, Feb 2, 2014 at 1:04 PM, Zenny wrote: >> Reposting the mail below as I had an oversight not to include subject >> line. Apology in advance! >> >>> Hi: >>> >>> Last time, Devin had been very kind to suggest me when the system >>> borked while trying to upgrade from v10B3 to vRC1. >>> >>> Following FreeBSD 10.0-RELEASE, I installed to a new machine with >>> encrypted root in zfs mirror, and since there was something wrong (a >>> double quote by mistake) inserted in the /boot/device.hints, the >>> kernel refused to boot and landed to the mountroot prompt. >>> >>> Therefore, in order to make changes what I did was: >>> >>> 1. Boot into LiveCD mode >>> 2. mkdir /tmp/bootpool >>> zpool import -f bootpool >>> zfs set mountpoint=/tmp/bootpool bootpool >>> zfs mount -a >>> cp /tmp/bootpool/boot/encryption.key /tmp/ >>> zfs umount -a >>> zfs set mountpoint=/bootpool bootpool >>> zpool export bootpool >>> geli attach -k /tmp/encryption.key /dev/ada0p4 >>> geli attach -k /tmp/encryption.key /dev/ada1p4 >>> zpool import -R /mnt zroot >>> zpool import -R /mnt/bootpool bootpool >>> 3. Removed the double quote (") from /bootpool/boot/device.hints and >>> saved the file. >>> >>> 4. Rebooted the file and now it says that there is no >>> boot/zfsbootloader. >>> > Does the file /boot/zfsloader exist in /boot or /bootpool/boot? Immediately after reboot, I got an error: "can't find /boot/zfsloader" followed by: "can't load 'kernel' Therefore, I rebooted livecd and tried to check by mounting bootpool and the /tmp/bootpool directory was empty! Earlier it was working desktop. > > > -- > DISCLAIMER: > > No electrons were maimed while sending this message. Only slightly bruised. > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 09:16:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CA97CA1; Mon, 3 Feb 2014 09:16:21 +0000 (UTC) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10F6C1FA8; Mon, 3 Feb 2014 09:16:20 +0000 (UTC) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.14.3/8.14.3) with ESMTP id s138jZZP012682; Mon, 3 Feb 2014 09:45:36 +0100 Received: from DEFTHW99ET5MSX.ww902.siemens.net (defthw99et5msx.ww902.siemens.net [157.163.148.55]) by mail1.sbs.de (8.14.3/8.14.3) with ESMTP id s138jZwl005114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 09:45:35 +0100 Received: from DENBGAT9ERRMSX.ww902.siemens.net (139.22.70.197) by DEFTHW99ET5MSX.ww902.siemens.net (157.163.148.55) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 3 Feb 2014 09:45:35 +0100 Received: from DENBGAT9EI2MSX.ww902.siemens.net ([169.254.10.167]) by DENBGAT9ERRMSX.ww902.siemens.net ([139.22.70.197]) with mapi id 14.03.0174.001; Mon, 3 Feb 2014 09:45:34 +0100 From: "Schuendehuette, Matthias" To: Rick Macklem Subject: Re: Stack overflow with kernel r254683 Thread-Topic: Stack overflow with kernel r254683 Thread-Index: Ac8gvDECTXd/Z2gHRg+PJNAW7SQCRA== Date: Mon, 3 Feb 2014 08:45:34 +0000 Message-ID: <1EFE239F82F279488E86A61C92D5E2DE091433BB@DENBGAT9EI2MSX.ww902.siemens.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , Konstantin Belousov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 09:16:21 -0000 SGVsbG8sDQoNCmZpbmFsbHkgSSBnb3QgaXQgbWFuYWdlZCB0byB1cGdyYWRlIGFuZCB0ZXN0IG15 IHNlcnZlciBsYXN0IHdlZWtlbmQuDQoNClRoZXJlIGFyZSBnb29kIG5ld3M6IHNvIGZhciBrZXJu ZWwgcjI2MTIwOCAoRnJlZUJTRCA5LjItU1RBQkxFKSBydW5zIHdpdGhvdXQgcHJvYmxlbXMuDQoN CkkgY291bGQgbm90IGFwcGx5IHRoZSBwYXRjaCB5b3Ugc3VwcGxpZWQsIGJ1dCBJIHNhdyB0aGF0 IHRoZSBjb2RlIHdhcyBtb2RpZmllZA0Kbm9uZXRoZWxlc3MgYW5kIEkgZ2F2ZSBpdCBhIHRyeSA6 LSkNCg0KSXQgc2VlbXMgdGhhdCB0aGUgcHJvYmxlbSBoYXMgYmVlbiBzb2x2ZWQuDQoNClRoYW5r IHlvdSB2ZXJ5IG11Y2ghIDotKQ0KDQoNCk1pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4NCk1hdHRo aWFzIFNjaMO8bmRlaMO8dHRlDQoNClNpZW1lbnMgQUcNCkluZHVzdHJ5IFNlY3Rvcg0KRHJpdmUg VGVjaG5vbG9naWVzIERpdmlzaW9uDQpJIERUIElUIExEIEJMTg0KTm9ubmVuZGFtbWFsbGVlIDcy DQoxMzYyOSBCZXJsaW4sIERldXRzY2hsYW5kDQpUZWw6ICs0OSAzMCAzODYtMjk5NTcNCk1vYmls ZTogKzQ5IDE3MCA4MTYyOTEyDQptYWlsdG86bWF0dGhpYXMuc2NodWVuZGVodWV0dGVAc2llbWVu cy5jb20NCg0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBS aWNrIE1hY2tsZW0gW21haWx0bzpybWFja2xlbUB1b2d1ZWxwaC5jYV0NCj4gR2VzZW5kZXQ6IFNv bm50YWcsIDE5LiBKYW51YXIgMjAxNCAwMzoxOQ0KPiBBbjogU2NodWVuZGVodWV0dGUsIE1hdHRo aWFzDQo+IENjOiBLb25zdGFudGluIEJlbG91c292DQo+IEJldHJlZmY6IFJlOiBTdGFjayBvdmVy ZmxvdyB3aXRoIGtlcm5lbCByMjU0NjgzDQo+IA0KPiBJIGp1c3QgZm91bmQgYSBidWcgdGhhdCBj YXVzZXMgYSBzdGFjayBvdmVyZmxvdyBpbiB0aGUgZmlsZSBoYW5kbGUNCj4gYWZmaW5pdHkgY29k ZSBkb25lIGJ5IGtlbkAuIEl0IG9jY3VycyBmb3IgYW4gTkZTdjIgY2xpZW50IG1vdW50aW5nDQo+ IGEgc2VydmVyLCB3aGVyZSBzaXplb2YoZmhhbmRsZV90KSA8IDMyLg0KPiANCj4gSSd2ZSBhdHRh Y2hlZCB0aGUgcGF0Y2ggdGhhdCBmaXhlcyB0aGlzLCBpbiBjYXNlIHlvdSBjYW4gdGVzdCBpdD8N Cj4gDQo+IFNpbmNlIHlvdXIgc3RhY2sgdHJhY2UgbG9va3MgY29tcGxldGVseSBkaWZmZXJlbnQs IEkgd29uJ3QgZ3Vlc3MgaWYNCj4gdGhpcyB3YXMgdGhlIGJ1ZywgYnV0IHRoaXMgYnVnIGRlZmlu aXRlbHkgdHJhc2hlZCB0aGUgc3RhY2suDQo+IA0KPiByaWNrDQo+IA0KPiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQo+ID4gT24gTW9uLCBBdWcgMjYsIDIwMTMgYXQgMDc6MTE6NDhQTSAt MDQwMCwgUmljayBNYWNrbGVtIHdyb3RlOg0KPiA+ID4gTWF0dGhpYXMgU2NodWVuZGVodWV0dGUg d3JvdGU6DQo+ID4gPiA+IEhlbGxvLA0KPiA+ID4gPg0KPiA+ID4gPiB5ZXN0ZXJkYXkgSSBnb3Qg YSBrZXJuZWwgY3Jhc2ggb24gbXkgc2VydmVyIChhIFByb0xpYW50IERMMzgwDQo+ID4gPiA+IEc1 KToNCj4gPiA+ID4NCj4gPiA+ID4gInBhbmljOiBzdGFjayBvdmVyZmxvdyBkZXRlY3RlZDsgYmFj a3RyYWNlIG1heSBiZSBjb3JydXB0ZWQiDQo+ID4gPiA+DQo+ID4gPiA+IEtlcm5lbCBpcyAiOS4y LVBSRVJFTEVBU0UgRnJlZUJTRCA5LjItUFJFUkVMRUFTRSAjNyByMjU0NjgzIg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiBUaGUgc3RhY2sgdHJhY2UgcmVhZHM6DQo+ID4gPiA+DQo+ID4gPiA+ ICMwICBkb2FkdW1wICh0ZXh0ZHVtcD0xKSBhdCBwY3B1Lmg6MjQ5DQo+ID4gPiA+IDI0OSBwY3B1 Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuDQo+ID4gPiA+ICAgICBpbiBwY3B1LmgNCj4g PiA+ID4gKGtnZGIpICMwICBkb2FkdW1wICh0ZXh0ZHVtcD0xKSBhdCBwY3B1Lmg6MjQ5DQo+ID4g PiA+ICMxICAweGMwNjY4YTRkIGluIGtlcm5fcmVib290IChob3d0bz0yNjApDQo+ID4gPiA+ICAg ICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDQ5DQo+ID4gPiA+ICMyICAw eGMwNjY4ZjA3IGluIHBhbmljIChmbXQ9MHgxMDQgPEFkZHJlc3MgMHgxMDQgb3V0IG9mIGJvdW5k cz4pDQo+ID4gPiA+ICAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NjM3 DQo+ID4gPiA+ICMzICAweGMwNjkxZGEyIGluIF9fc3RhY2tfY2hrX2ZhaWwgKCkNCj4gPiA+ID4g ICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N0YWNrX3Byb3RlY3Rvci5jOjE3DQo+ID4gPiA+ICM0 ICAweGM3ZmRiMTc1IGluIG5mc3J2ZF9zZXRhdHRyIChuZD0weGM3M2I0NDAwLA0KPiA+ID4gPiBp c2RncmFtPS05NTI1OTY0ODAsDQo+ID4gPiA+ICAgICB2cD0weGM4MDAxMTQwLCBwPTB4ZjQwNWVj YzgsIGV4cD0weGMwN2FmN2YwKQ0KPiA+ID4gPiAgICAgYXQNCj4gPiA+ID4gICAgIC91c3Ivc3Jj L3N5cy9tb2R1bGVzL25mc2QvLi4vLi4vZnMvbmZzc2VydmVyL25mc19uZnNkc2Vydi5jOjM3MQ0K PiA+ID4gPiAjNSAgMHhjN2ZkYjZlMCBpbiBuZnNydmRfcmVsZWFzZWxja293biAobmQ9MHhjNzQ0 MmEwMCwNCj4gPiA+ID4gaXNkZ3JhbT0tOTUyNTk2NDgwLA0KPiA+ID4gPiAgICAgdnA9MHhjNzM4 ODg0OCwgcD0weGY0MDVlY2I4LCBleHA9MHgwKQ0KPiA+ID4gPiAgICAgYXQNCj4gPiA+ID4gICAg IC91c3Ivc3JjL3N5cy9tb2R1bGVzL25mc2QvLi4vLi4vZnMvbmZzc2VydmVyL25mc19uZnNkc2Vy di5jOjM0ODENCj4gPiA+ID4gIzYgIDB4YzA3YWY3ZjAgaW4gc3ZjX3J1bl9pbnRlcm5hbCAocG9v bD0weGM3ZGU4YjgwLCBpc21hc3Rlcj0wKQ0KPiA+ID4gPiAgICAgYXQgL3Vzci9zcmMvc3lzL3Jw Yy9zdmMuYzoxMTA5DQo+ID4gPiA+ICM3ICAweGMwN2IwMDZkIGluIHN2Y190aHJlYWRfc3RhcnQg KGFyZz0weGM3ZGU4YjgwKQ0KPiA+ID4gPiAgICAgYXQgL3Vzci9zcmMvc3lzL3JwYy9zdmMuYzox MjAwDQo+ID4gPiA+ICM4ICAweGMwNjM4NGY3IGluIGZvcmtfZXhpdCAoY2FsbG91dD0weGMwN2Iw MDYwDQo+ID4gPiA+IDxzdmNfdGhyZWFkX3N0YXJ0PiwNCj4gPiA+ID4gICAgIGFyZz0weGM3ZGU4 YjgwLCBmcmFtZT0weGY0MDVlZDA4KSBhdA0KPiA+ID4gPiAgICAgL3Vzci9zcmMvc3lzL2tlcm4v a2Vybl9mb3JrLmM6OTkyDQo+ID4gPiA+ICM5ICAweGMwODc4N2M0IGluIGZvcmtfdHJhbXBvbGlu ZSAoKSBhdA0KPiA+ID4gPiAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjI3OQ0K PiA+ID4gPg0KPiA+ID4gV2VsbCwgd2hlbiBJJ3ZlIGxvb2tlZCBvbiBpMzg2LCB0aGUgbmZzZCB0 aHJlYWRzIG5vcm1hbGx5IGRvbid0IHVzZQ0KPiA+ID4gMSBwYWdlDQo+ID4gPiBhbmQgdGhlIHN0 YWNrcyBhcmUgMiBwYWdlcywgc28gSSBkb3VidCBhbiBuZnNkIHRocmVhZCBpcyBibG93aW5nDQo+ ID4gPiB0aGUgc3RhY2suDQo+ID4gSXQgaXMgb3ZlcmZsb3dpbmcgdGhlIGZyYW1lLCBub3QgdGhl IHdob2xlIHN0YWNrLiAgSW4gb3RoZXIgd29yZCwNCj4gPiBzb21ldGhpbmcNCj4gPiBvdmVyd3Jv dGUgdGhlIGNhbmFyeSB3aGljaCB3YXMgcHV0IG9uIHRoZSBzdGFjayBiZXR3ZWVuIGxvY2FsDQo+ ID4gdmFyaWFibGVzDQo+ID4gYW5kIHRoZSByZXR1cm4gYWRkcmVzcywgcG9zc2libHkgY29ycnVw dGluZyB0aGUgcmV0dXJuIGFkZHJlc3MgYXMNCj4gPiB3ZWxsLg0KPiA+DQo+ID4gPiBBbHNvLCBu ZnNydmRfcmVsZWFzZWxja293bigpIGRvZXNuJ3QgY2FsbCBuZnNydmRfc2V0YXR0cigpLCBzbyB0 aGUNCj4gPiA+IGJhY2t0cmFjZQ0KPiA+ID4gZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UuDQo+ID4g WWVzLCB0aGlzIG1pZ2h0IGJlIG9uZSBvZiB0aGUgY29uc2VxdWVuY2VzIG9mIHRoZSBzdGFjayBz bWFzaGluZy4NCj4gPg0KPiA+ID4NCj4gPiA+IEFmcmFpZCBJIGNhbid0IGhlbHAgbW9yZSB0aGFu IHRoaXMuIEdvb2QgbHVjayB3aXRoIGl0LCByaWNrDQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBJ IGhhdmUgYWxsIHRoZSBmaWxlcyBpbiAvdmFyL2NyYXNoLCBzbyBpZiBzb21lb25lIHdhbnRzDQo+ ID4gPiA+IGFkZGl0aW9uYWwNCj4gPiA+ID4gaW5mb3JtYXRpb25zDQo+ID4gPiA+IEkgc2hvdWxk IGJlIGFibGUgdG8gZGVsaXZlciB0aGVtLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUga2VybmVsIGNv bmZpZyBmaWxlIGlzIGN1c3RvbWl6ZWQgaW4gdGhlIHNlbnNlIHRoYXQgSSBoYXZlDQo+ID4gPiA+ IHJlbW92ZWQNCj4gPiA+ID4ga2VybmVsIGl0ZW1zLCB0aGF0IGFyZW4ndCB1c2VkIG9uIHRoYXQg bWFjaGluZS4NCj4gPiA+ID4NCj4gPiA+ID4gT25lIG1ham9yIGRpZmZlcmVuY2U6IEkgdXNlDQo+ ID4gPiA+DQo+ID4gPiA+IDwgb3B0aW9ucyAgICAgICBORlNDTElFTlQgICAgICAgICAgICAgICAj IE5ldHdvcmsgRmlsZXN5c3RlbQ0KPiA+ID4gPiBDbGllbnQNCj4gPiA+ID4gPCBvcHRpb25zICAg ICAgIE5GU1NFUlZFUiAgICAgICAgICAgICAgICMgTmV0d29yayBGaWxlc3lzdGVtDQo+ID4gPiA+ IFNlcnZlcg0KPiA+ID4gPg0KPiA+ID4gPiBpbnN0ZWFkIG9mDQo+ID4gPiA+DQo+ID4gPiA+ID4g b3B0aW9ucyAgICAgICBORlNDTCAgICAgICAgICAgICAgICAgICAjIE5ldyBOZXR3b3JrIEZpbGVz eXN0ZW0NCj4gPiA+ID4gPiBDbGllbnQNCj4gPiA+ID4gPiBvcHRpb25zICAgICAgIE5GU0QgICAg ICAgICAgICAgICAgICAgICMgTmV3IE5ldHdvcmsgRmlsZXN5c3RlbQ0KPiA+ID4gPiA+IFNlcnZl cg0KPiA+ID4gPg0KPiA+ID4gPiBiZWNhdXNlIGEga2VybmVsIGEgZmV3IHdlZWtzIGFnbyBpbW1l ZGlhdGVseSBjcmFzaGVkIHdpdGggdGhlIG5ldw0KPiA+ID4gPiBORlMtY29kZS4NCj4gPiA+ID4N Cj4gPiA+ID4gQnV0IGl0IHNlZW1zIG5vdywgdGhhdCB0aGUgb2xkIE5GUy1jb2RlIGlzIGFsc28g c29tZWhvdyBkYW1hZ2VkLg0KPiA+ID4gPg0KPiA+ID4gPiBBaCwgYW5kIEkgc3RpbGwgaGF2ZSBm cm9tIG9sZGVyIHJlbGVhc2VzIG9mIEZyZWVCU0QgdGhlIGZvbGxvd2luZw0KPiA+ID4gPiBsb2Fk ZXIgb3B0aW9ucyAtIGRvIHRoZXkgc3RpbGwgbWFrZSBzZW5zZT8NCj4gPiA+ID4NCj4gPiA+ID4g Z2VvbV92aW51bV9sb2FkPSJZRVMiDQo+ID4gPiA+IGtlcm4ubWF4ZHNpej0iNzM0MDAzMjAwIg0K PiA+ID4gPiB2bS5wbWFwLnNocGdwZXJwcm9jPTI1Ng0KPiA+ID4gPiB2bS5wbWFwLnB2X2VudHJ5 X21heD0zMTQ1NzI4DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ICdnZW9tX3ZpbnVtJyBpcyB1 c2VkIGFzIExWTSBvbmx5LCBubyBSQUlEcyBhcmUgY29uZmlndXJlZC4NCj4gPiA+ID4NCj4gPiA+ ID4gVGhpcyBzZXJ2ZXIgaXMgcHJpbWFyaWx5IGEgU2FtYmEgc2VydmVyIHdpdGggdGhlIFNNQi1z aGFyZXMNCj4gPiA+ID4gZXhwb3J0ZWQNCj4gPiA+ID4gYXMgTkZTLXNoYXJlcyBhcyB3ZWxsDQo+ ID4gPiA+IGZvciB0aGUgb3RoZXIgKm5peC1zZXJ2ZXJzIGFyb3VuZC4NCj4gPiA+ID4NCj4gPiA+ ID4gQmVjYXVzZSB0aGlzIGlzIHRoZSBtb3N0IGxvYWRlZCBwcm9kdWN0aW9uIHNlcnZlciwgdGVz dGluZyBpcyBhDQo+ID4gPiA+IGJpdA0KPiA+ID4gPiBkaWZmaWN1bHQsIHJlc3RyaWN0ZWQgdG8g dGhlIGV2ZW5pbmcgYW5kIHRoZSB3ZWVrZW5kcy4NCj4gPiA+ID4NCj4gPiA+ID4gT24gbXkgdHdv IG90aGVyIEZyZWVCU0QgbWFjaGluZXMgSSBoYXZlIG5vIHByb2JsZW1zIGF0IGFsbCwgb25lDQo+ ID4gPiA+IG9mDQo+ID4gPiA+IHRoZW0gaXMgYW4gaWRlbnRpY2FsIFByb0xpYW50IHNlcnZlciB3 aXRoIGEgbmVhcmx5IGlkZW50aWNhbA0KPiA+ID4gPiBrZXJuZWwNCj4gPiA+ID4gY29uZmlnIC0g cnVucyBsaWtlIGEgY2hhcm0uLi4NCj4gPiA+ID4NCj4gPiA+ID4gSGFzIHNvbWVvbmUgYSBnb29k IGFkdmljZSBvciBmdXJ0aGVyIHF1ZXN0aW9ucz8NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ID4gd2l0aCBiZXN0IHJlZ2FyZHMNCj4gPiA+ID4gTWF0dGhpYXMgU2NoPz9uZGVoPz90 dGUNCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+ID4gZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmcgbWFpbGluZyBs aXN0DQo+ID4gPiA+IGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Zy ZWVic2Qtc3RhYmxlDQo+ID4gPiA+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvDQo+ ID4gPiA+ICJmcmVlYnNkLXN0YWJsZS11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCj4gPiA+ID4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBmcmVlYnNkLXN0YWJsZUBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gPiA+IGh0dHA6 Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qtc3RhYmxlDQo+ID4g PiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0bw0KPiA+ID4gImZyZWVic2Qtc3RhYmxl LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0KPiA+DQo= From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 09:34:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E3A13D2; Mon, 3 Feb 2014 09:34:20 +0000 (UTC) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0441A11C7; Mon, 3 Feb 2014 09:34:19 +0000 (UTC) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.14.3/8.14.3) with ESMTP id s139YHtP017861; Mon, 3 Feb 2014 10:34:18 +0100 Received: from DEFTHW99ET4MSX.ww902.siemens.net (defthw99et4msx.ww902.siemens.net [157.163.148.53]) by mail1.sbs.de (8.14.3/8.14.3) with ESMTP id s139YHNb032726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 10:34:17 +0100 Received: from DEFTHW99ERRMSX.ww902.siemens.net (139.22.70.199) by DEFTHW99ET4MSX.ww902.siemens.net (157.163.148.53) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 3 Feb 2014 10:34:17 +0100 Received: from DENBGAT9EI2MSX.ww902.siemens.net ([169.254.10.167]) by DEFTHW99ERRMSX.ww902.siemens.net ([139.22.70.199]) with mapi id 14.03.0174.001; Mon, 3 Feb 2014 10:34:17 +0100 From: "Schuendehuette, Matthias" To: Rick Macklem Subject: Re: Stack overflow with kernel r254683 Thread-Topic: Stack overflow with kernel r254683 Thread-Index: Ac8gvDECTXd/Z2gHRg+PJNAW7SQCRA== Date: Mon, 3 Feb 2014 09:34:16 +0000 Message-ID: <1EFE239F82F279488E86A61C92D5E2DE09145C3E@DENBGAT9EI2MSX.ww902.siemens.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.43] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , Konstantin Belousov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 09:34:20 -0000 SXQgc2VlbXMgdGhhdCB0aGlzIG1haWwgaGFzIGJlZW4gc2VudCBlbmNvZGVkLi4uICBIZXJlIEkg dHJ5IGl0IG9uY2UgbW9yZQ0KdmVyaWZpZWQgYXMgJ3BsYWluIHRleHQnLg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCg0KSGVsbG8sDQoNCmZpbmFsbHkgSSBnb3QgaXQgbWFuYWdlZCB0byB1cGdyYWRlIGFu ZCB0ZXN0IG15IHNlcnZlciBsYXN0IHdlZWtlbmQuDQoNClRoZXJlIGFyZSBnb29kIG5ld3M6IHNv IGZhciBrZXJuZWwgcjI2MTIwOCAoRnJlZUJTRCA5LjItU1RBQkxFKSBydW5zIHdpdGhvdXQgcHJv YmxlbXMuDQoNCkkgY291bGQgbm90IGFwcGx5IHRoZSBwYXRjaCB5b3Ugc3VwcGxpZWQsIGJ1dCBJ IHNhdyB0aGF0IHRoZSBjb2RlIHdhcyBtb2RpZmllZA0Kbm9uZXRoZWxlc3MgYW5kIEkgZ2F2ZSBp dCBhIHRyeSA6LSkNCg0KSXQgc2VlbXMgdGhhdCB0aGUgcHJvYmxlbSBoYXMgYmVlbiBzb2x2ZWQu DQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ghIDotKQ0KDQoNCk1pdCBmcmV1bmRsaWNoZW4gR3LDvMOf ZW4NCk1hdHRoaWFzIFNjaMO8bmRlaMO8dHRlDQoNClNpZW1lbnMgQUcNCkluZHVzdHJ5IFNlY3Rv cg0KRHJpdmUgVGVjaG5vbG9naWVzIERpdmlzaW9uDQpJIERUIElUIExEIEJMTg0KTm9ubmVuZGFt bWFsbGVlIDcyDQoxMzYyOSBCZXJsaW4sIERldXRzY2hsYW5kDQpUZWw6ICs0OSAzMCAzODYtMjk5 NTcNCk1vYmlsZTogKzQ5IDE3MCA4MTYyOTEyDQptYWlsdG86bWF0dGhpYXMuc2NodWVuZGVodWV0 dGVAc2llbWVucy5jb20NCg0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0N Cj4gVm9uOiBSaWNrIE1hY2tsZW0gW21haWx0bzpybWFja2xlbUB1b2d1ZWxwaC5jYV0NCj4gR2Vz ZW5kZXQ6IFNvbm50YWcsIDE5LiBKYW51YXIgMjAxNCAwMzoxOQ0KPiBBbjogU2NodWVuZGVodWV0 dGUsIE1hdHRoaWFzDQo+IENjOiBLb25zdGFudGluIEJlbG91c292DQo+IEJldHJlZmY6IFJlOiBT dGFjayBvdmVyZmxvdyB3aXRoIGtlcm5lbCByMjU0NjgzDQo+IA0KPiBJIGp1c3QgZm91bmQgYSBi dWcgdGhhdCBjYXVzZXMgYSBzdGFjayBvdmVyZmxvdyBpbiB0aGUgZmlsZSBoYW5kbGUNCj4gYWZm aW5pdHkgY29kZSBkb25lIGJ5IGtlbkAuIEl0IG9jY3VycyBmb3IgYW4gTkZTdjIgY2xpZW50IG1v dW50aW5nDQo+IGEgc2VydmVyLCB3aGVyZSBzaXplb2YoZmhhbmRsZV90KSA8IDMyLg0KPiANCj4g SSd2ZSBhdHRhY2hlZCB0aGUgcGF0Y2ggdGhhdCBmaXhlcyB0aGlzLCBpbiBjYXNlIHlvdSBjYW4g dGVzdCBpdD8NCj4gDQo+IFNpbmNlIHlvdXIgc3RhY2sgdHJhY2UgbG9va3MgY29tcGxldGVseSBk aWZmZXJlbnQsIEkgd29uJ3QgZ3Vlc3MgaWYNCj4gdGhpcyB3YXMgdGhlIGJ1ZywgYnV0IHRoaXMg YnVnIGRlZmluaXRlbHkgdHJhc2hlZCB0aGUgc3RhY2suDQo+IA0KPiByaWNrDQo+IA0KPiAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gT24gTW9uLCBBdWcgMjYsIDIwMTMgYXQgMDc6 MTE6NDhQTSAtMDQwMCwgUmljayBNYWNrbGVtIHdyb3RlOg0KPiA+ID4gTWF0dGhpYXMgU2NodWVu ZGVodWV0dGUgd3JvdGU6DQo+ID4gPiA+IEhlbGxvLA0KPiA+ID4gPg0KPiA+ID4gPiB5ZXN0ZXJk YXkgSSBnb3QgYSBrZXJuZWwgY3Jhc2ggb24gbXkgc2VydmVyIChhIFByb0xpYW50IERMMzgwDQo+ ID4gPiA+IEc1KToNCj4gPiA+ID4NCj4gPiA+ID4gInBhbmljOiBzdGFjayBvdmVyZmxvdyBkZXRl Y3RlZDsgYmFja3RyYWNlIG1heSBiZSBjb3JydXB0ZWQiDQo+ID4gPiA+DQo+ID4gPiA+IEtlcm5l bCBpcyAiOS4yLVBSRVJFTEVBU0UgRnJlZUJTRCA5LjItUFJFUkVMRUFTRSAjNyByMjU0NjgzIg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgc3RhY2sgdHJhY2UgcmVhZHM6DQo+ID4gPiA+ DQo+ID4gPiA+ICMwICBkb2FkdW1wICh0ZXh0ZHVtcD0xKSBhdCBwY3B1Lmg6MjQ5DQo+ID4gPiA+ IDI0OSBwY3B1Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuDQo+ID4gPiA+ICAgICBpbiBw Y3B1LmgNCj4gPiA+ID4gKGtnZGIpICMwICBkb2FkdW1wICh0ZXh0ZHVtcD0xKSBhdCBwY3B1Lmg6 MjQ5DQo+ID4gPiA+ICMxICAweGMwNjY4YTRkIGluIGtlcm5fcmVib290IChob3d0bz0yNjApDQo+ ID4gPiA+ICAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRkb3duLmM6NDQ5DQo+ID4g PiA+ICMyICAweGMwNjY4ZjA3IGluIHBhbmljIChmbXQ9MHgxMDQgPEFkZHJlc3MgMHgxMDQgb3V0 IG9mIGJvdW5kcz4pDQo+ID4gPiA+ICAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3NodXRk b3duLmM6NjM3DQo+ID4gPiA+ICMzICAweGMwNjkxZGEyIGluIF9fc3RhY2tfY2hrX2ZhaWwgKCkN Cj4gPiA+ID4gICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N0YWNrX3Byb3RlY3Rvci5jOjE3DQo+ ID4gPiA+ICM0ICAweGM3ZmRiMTc1IGluIG5mc3J2ZF9zZXRhdHRyIChuZD0weGM3M2I0NDAwLA0K PiA+ID4gPiBpc2RncmFtPS05NTI1OTY0ODAsDQo+ID4gPiA+ICAgICB2cD0weGM4MDAxMTQwLCBw PTB4ZjQwNWVjYzgsIGV4cD0weGMwN2FmN2YwKQ0KPiA+ID4gPiAgICAgYXQNCj4gPiA+ID4gICAg IC91c3Ivc3JjL3N5cy9tb2R1bGVzL25mc2QvLi4vLi4vZnMvbmZzc2VydmVyL25mc19uZnNkc2Vy di5jOjM3MQ0KPiA+ID4gPiAjNSAgMHhjN2ZkYjZlMCBpbiBuZnNydmRfcmVsZWFzZWxja293biAo bmQ9MHhjNzQ0MmEwMCwNCj4gPiA+ID4gaXNkZ3JhbT0tOTUyNTk2NDgwLA0KPiA+ID4gPiAgICAg dnA9MHhjNzM4ODg0OCwgcD0weGY0MDVlY2I4LCBleHA9MHgwKQ0KPiA+ID4gPiAgICAgYXQNCj4g PiA+ID4gICAgIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25mc2QvLi4vLi4vZnMvbmZzc2VydmVyL25m c19uZnNkc2Vydi5jOjM0ODENCj4gPiA+ID4gIzYgIDB4YzA3YWY3ZjAgaW4gc3ZjX3J1bl9pbnRl cm5hbCAocG9vbD0weGM3ZGU4YjgwLCBpc21hc3Rlcj0wKQ0KPiA+ID4gPiAgICAgYXQgL3Vzci9z cmMvc3lzL3JwYy9zdmMuYzoxMTA5DQo+ID4gPiA+ICM3ICAweGMwN2IwMDZkIGluIHN2Y190aHJl YWRfc3RhcnQgKGFyZz0weGM3ZGU4YjgwKQ0KPiA+ID4gPiAgICAgYXQgL3Vzci9zcmMvc3lzL3Jw Yy9zdmMuYzoxMjAwDQo+ID4gPiA+ICM4ICAweGMwNjM4NGY3IGluIGZvcmtfZXhpdCAoY2FsbG91 dD0weGMwN2IwMDYwDQo+ID4gPiA+IDxzdmNfdGhyZWFkX3N0YXJ0PiwNCj4gPiA+ID4gICAgIGFy Zz0weGM3ZGU4YjgwLCBmcmFtZT0weGY0MDVlZDA4KSBhdA0KPiA+ID4gPiAgICAgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9mb3JrLmM6OTkyDQo+ID4gPiA+ICM5ICAweGMwODc4N2M0IGluIGZvcmtf dHJhbXBvbGluZSAoKSBhdA0KPiA+ID4gPiAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlv bi5zOjI3OQ0KPiA+ID4gPg0KPiA+ID4gV2VsbCwgd2hlbiBJJ3ZlIGxvb2tlZCBvbiBpMzg2LCB0 aGUgbmZzZCB0aHJlYWRzIG5vcm1hbGx5IGRvbid0IHVzZQ0KPiA+ID4gMSBwYWdlDQo+ID4gPiBh bmQgdGhlIHN0YWNrcyBhcmUgMiBwYWdlcywgc28gSSBkb3VidCBhbiBuZnNkIHRocmVhZCBpcyBi bG93aW5nDQo+ID4gPiB0aGUgc3RhY2suDQo+ID4gSXQgaXMgb3ZlcmZsb3dpbmcgdGhlIGZyYW1l LCBub3QgdGhlIHdob2xlIHN0YWNrLiAgSW4gb3RoZXIgd29yZCwNCj4gPiBzb21ldGhpbmcNCj4g PiBvdmVyd3JvdGUgdGhlIGNhbmFyeSB3aGljaCB3YXMgcHV0IG9uIHRoZSBzdGFjayBiZXR3ZWVu IGxvY2FsDQo+ID4gdmFyaWFibGVzDQo+ID4gYW5kIHRoZSByZXR1cm4gYWRkcmVzcywgcG9zc2li bHkgY29ycnVwdGluZyB0aGUgcmV0dXJuIGFkZHJlc3MgYXMNCj4gPiB3ZWxsLg0KPiA+DQo+ID4g PiBBbHNvLCBuZnNydmRfcmVsZWFzZWxja293bigpIGRvZXNuJ3QgY2FsbCBuZnNydmRfc2V0YXR0 cigpLCBzbyB0aGUNCj4gPiA+IGJhY2t0cmFjZQ0KPiA+ID4gZG9lc24ndCBtYWtlIG11Y2ggc2Vu c2UuDQo+ID4gWWVzLCB0aGlzIG1pZ2h0IGJlIG9uZSBvZiB0aGUgY29uc2VxdWVuY2VzIG9mIHRo ZSBzdGFjayBzbWFzaGluZy4NCj4gPg0KPiA+ID4NCj4gPiA+IEFmcmFpZCBJIGNhbid0IGhlbHAg bW9yZSB0aGFuIHRoaXMuIEdvb2QgbHVjayB3aXRoIGl0LCByaWNrDQo+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiBJIGhhdmUgYWxsIHRoZSBmaWxlcyBpbiAvdmFyL2NyYXNoLCBzbyBpZiBzb21lb25l IHdhbnRzDQo+ID4gPiA+IGFkZGl0aW9uYWwNCj4gPiA+ID4gaW5mb3JtYXRpb25zDQo+ID4gPiA+ IEkgc2hvdWxkIGJlIGFibGUgdG8gZGVsaXZlciB0aGVtLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUg a2VybmVsIGNvbmZpZyBmaWxlIGlzIGN1c3RvbWl6ZWQgaW4gdGhlIHNlbnNlIHRoYXQgSSBoYXZl DQo+ID4gPiA+IHJlbW92ZWQNCj4gPiA+ID4ga2VybmVsIGl0ZW1zLCB0aGF0IGFyZW4ndCB1c2Vk IG9uIHRoYXQgbWFjaGluZS4NCj4gPiA+ID4NCj4gPiA+ID4gT25lIG1ham9yIGRpZmZlcmVuY2U6 IEkgdXNlDQo+ID4gPiA+DQo+ID4gPiA+IDwgb3B0aW9ucyAgICAgICBORlNDTElFTlQgICAgICAg ICAgICAgICAjIE5ldHdvcmsgRmlsZXN5c3RlbQ0KPiA+ID4gPiBDbGllbnQNCj4gPiA+ID4gPCBv cHRpb25zICAgICAgIE5GU1NFUlZFUiAgICAgICAgICAgICAgICMgTmV0d29yayBGaWxlc3lzdGVt DQo+ID4gPiA+IFNlcnZlcg0KPiA+ID4gPg0KPiA+ID4gPiBpbnN0ZWFkIG9mDQo+ID4gPiA+DQo+ ID4gPiA+ID4gb3B0aW9ucyAgICAgICBORlNDTCAgICAgICAgICAgICAgICAgICAjIE5ldyBOZXR3 b3JrIEZpbGVzeXN0ZW0NCj4gPiA+ID4gPiBDbGllbnQNCj4gPiA+ID4gPiBvcHRpb25zICAgICAg IE5GU0QgICAgICAgICAgICAgICAgICAgICMgTmV3IE5ldHdvcmsgRmlsZXN5c3RlbQ0KPiA+ID4g PiA+IFNlcnZlcg0KPiA+ID4gPg0KPiA+ID4gPiBiZWNhdXNlIGEga2VybmVsIGEgZmV3IHdlZWtz IGFnbyBpbW1lZGlhdGVseSBjcmFzaGVkIHdpdGggdGhlIG5ldw0KPiA+ID4gPiBORlMtY29kZS4N Cj4gPiA+ID4NCj4gPiA+ID4gQnV0IGl0IHNlZW1zIG5vdywgdGhhdCB0aGUgb2xkIE5GUy1jb2Rl IGlzIGFsc28gc29tZWhvdyBkYW1hZ2VkLg0KPiA+ID4gPg0KPiA+ID4gPiBBaCwgYW5kIEkgc3Rp bGwgaGF2ZSBmcm9tIG9sZGVyIHJlbGVhc2VzIG9mIEZyZWVCU0QgdGhlIGZvbGxvd2luZw0KPiA+ ID4gPiBsb2FkZXIgb3B0aW9ucyAtIGRvIHRoZXkgc3RpbGwgbWFrZSBzZW5zZT8NCj4gPiA+ID4N Cj4gPiA+ID4gZ2VvbV92aW51bV9sb2FkPSJZRVMiDQo+ID4gPiA+IGtlcm4ubWF4ZHNpej0iNzM0 MDAzMjAwIg0KPiA+ID4gPiB2bS5wbWFwLnNocGdwZXJwcm9jPTI1Ng0KPiA+ID4gPiB2bS5wbWFw LnB2X2VudHJ5X21heD0zMTQ1NzI4DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ICdnZW9tX3Zp bnVtJyBpcyB1c2VkIGFzIExWTSBvbmx5LCBubyBSQUlEcyBhcmUgY29uZmlndXJlZC4NCj4gPiA+ ID4NCj4gPiA+ID4gVGhpcyBzZXJ2ZXIgaXMgcHJpbWFyaWx5IGEgU2FtYmEgc2VydmVyIHdpdGgg dGhlIFNNQi1zaGFyZXMNCj4gPiA+ID4gZXhwb3J0ZWQNCj4gPiA+ID4gYXMgTkZTLXNoYXJlcyBh cyB3ZWxsDQo+ID4gPiA+IGZvciB0aGUgb3RoZXIgKm5peC1zZXJ2ZXJzIGFyb3VuZC4NCj4gPiA+ ID4NCj4gPiA+ID4gQmVjYXVzZSB0aGlzIGlzIHRoZSBtb3N0IGxvYWRlZCBwcm9kdWN0aW9uIHNl cnZlciwgdGVzdGluZyBpcyBhDQo+ID4gPiA+IGJpdA0KPiA+ID4gPiBkaWZmaWN1bHQsIHJlc3Ry aWN0ZWQgdG8gdGhlIGV2ZW5pbmcgYW5kIHRoZSB3ZWVrZW5kcy4NCj4gPiA+ID4NCj4gPiA+ID4g T24gbXkgdHdvIG90aGVyIEZyZWVCU0QgbWFjaGluZXMgSSBoYXZlIG5vIHByb2JsZW1zIGF0IGFs bCwgb25lDQo+ID4gPiA+IG9mDQo+ID4gPiA+IHRoZW0gaXMgYW4gaWRlbnRpY2FsIFByb0xpYW50 IHNlcnZlciB3aXRoIGEgbmVhcmx5IGlkZW50aWNhbA0KPiA+ID4gPiBrZXJuZWwNCj4gPiA+ID4g Y29uZmlnIC0gcnVucyBsaWtlIGEgY2hhcm0uLi4NCj4gPiA+ID4NCj4gPiA+ID4gSGFzIHNvbWVv bmUgYSBnb29kIGFkdmljZSBvciBmdXJ0aGVyIHF1ZXN0aW9ucz8NCj4gPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gd2l0aCBiZXN0IHJlZ2FyZHMNCj4gPiA+ID4gTWF0dGhpYXMgU2No dWVuZGVodWV0dGUNCj4gPiA+ID4NCg== From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 13:56:43 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 720CEC4C; Mon, 3 Feb 2014 13:56:43 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBA5D1ABD; Mon, 3 Feb 2014 13:56:42 +0000 (UTC) Received: from dator167.onk.lu.se (dator167.onk.lu.se [130.235.5.190]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0M5qIb-1VLPPd1GyP-00xto3; Mon, 03 Feb 2014 14:56:40 +0100 Message-ID: <52EFA015.5070601@FreeBSD.org> Date: Mon, 03 Feb 2014 14:56:37 +0100 From: Christian Brueffer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: current@freebsd.org Subject: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT X-Enigmail-Version: 1.6 OpenPGP: id=3A67DC36; url=http://people.freebsd.org/~brueffer/brueffer.key.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc" X-Provags-ID: V02:K0:kTF/AVqwW5DPS8hGHs1O/nsqqD5ks04omVkBJwF1SUp eWjBWx9CpgI9MI6V09Hwzo6kybE98lTmScTIZXjrO+AEYrpqyn uYPD0q6cCT6+htPBa/f8ETzP0q7VF24cuI0qxhjBPkeoXxX6Xp Niwta1/shPURiwJZ1SPFuL0MYVJPhGl0WwWAbYnuGuUvw9RZX7 8Zsc/DEcSsZZSUZUWVXZqA0QOjWQIBTBScu/O0abX9hLfGMcmY tMm2j5fAKUY2cH8dlDUXOEPDtX/9AbcO8GhNSf4F0VLkNQfdPw h49db+amZ9Upi62KwMWUvmzCiYE+uT6rApnREUbM47nctDIb95 KQISZU0JIfOmnogLDsZ3eKt7ohMfA9LxfPu1lpnog Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 13:56:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, for some time now we have had two drivers for NVIDIA NForce/MCP network chips, namely nve(4) and nfe(4). The former came first and is based on a binary blob. The latter was later ported from OpenBSD and is blob-free. nfe(4) supports all chips nve(4) supports, in addition to all the newer hardware. In essence, nfe(4) has been the de-facto standard driver for a long time. nve(4) has been commented out in GENERIC since 2007. For this reason I propose deprecating nve(4) in 10-STABLE and removing it from HEAD. Does anyone see a reason not to do this? Cheers, Christian (wearing my best asbestos suit) --UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc 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.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS76AXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QzhCQjQ5MDgzNDUwNjkyOUM5Mjg2NDE3 OEM4MzY5ODQ3RTE2NDg3AAoJEHjINphH4WSHY/4P/ipUMMZmrJvjWc+FSo+IONT/ S9T8mIZQqSgcyYT8/Ff/zSS/JIfHwob1sZ8gzubbj0m66zDSZ9QdMVx5xmy37B1L /5gEbXNR3RMRXs3VDinDA2aEoc7lkgLnyHB3rbcETsk9LCorWV5PKAH73aQuNiIJ LVbr6UDxlzF/YuLrN92X4ujlKAN+iZHLof4Z4hS9PV6kiZfNDrKX58wmKUBmfCZw cw9H5aH6bHVUaZuiTPdVIwHon6EAzGY7MffgY/wsT+TU/Mex44jvK2jU5D394Rf7 UjkZfrs2U2ppak4z4IDo7QiypS9wajqv2DM1UJjOoMGh360hnR8m1zPnIdaji4DU Xox93sS60La2bpqOjUtA5rshRrngEASodCpHKB2uaZ0btalrbHNR+8CptXwilSUA kgPVCwDWH+XtGkwjs35A5f8CRBsfw4817vxz0vHGRBbpSNN8rNGlNXQVT3DwWVR4 7Ry3LPKYTJs2SA3BeZ2cBI/Gcdfi0dFTOgiOVZxeerpuCLas0JbOuy7cebgF80xr qEulCTePxxFekMxHVstXUmSL6LoHMwYoQspxbAPbxPeWOrghanshPHeoe2o92PjI hKl493TsBQFIsacUdCVafJSNsocKxlrpwbVQ6bF83Dhz5JH6lKyZ2FQHDp3T525y qarxKSWPJ2avdAHtrRlt =PuZ6 -----END PGP SIGNATURE----- --UbA5emm2gwmf5i3FQQjlBuaJF2eU7Npgc-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 14:24:06 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91E88598; Mon, 3 Feb 2014 14:24:06 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 530691D17; Mon, 3 Feb 2014 14:24:06 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s13ENmhq020319 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 08:23:49 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <52EFA674.8000106@tundraware.com> Date: Mon, 03 Feb 2014 08:23:48 -0600 From: Tim Daneliuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christian Brueffer , current@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT References: <52EFA015.5070601@FreeBSD.org> In-Reply-To: <52EFA015.5070601@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Mon, 03 Feb 2014 08:23:49 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s13ENmhq020319 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 14:24:06 -0000 On 02/03/2014 07:56 AM, Christian Brueffer wrote: > Hi, > > for some time now we have had two drivers for NVIDIA NForce/MCP network > chips, namely nve(4) and nfe(4). > > The former came first and is based on a binary blob. The latter was > later ported from OpenBSD and is blob-free. > > nfe(4) supports all chips nve(4) supports, in addition to all the newer > hardware. In essence, nfe(4) has been the de-facto standard driver for > a long time. nve(4) has been commented out in GENERIC since 2007. > > For this reason I propose deprecating nve(4) in 10-STABLE and removing > it from HEAD. > > Does anyone see a reason not to do this? > > Cheers, > > Christian (wearing my best asbestos suit) > If you're going to be so very polite about it, how do you expect us to have a 2000 email chain fight examining every possible implication of your proposal ... :) -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 20:38:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85107A9C; Mon, 3 Feb 2014 20:38:46 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3625011A0; Mon, 3 Feb 2014 20:38:46 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id ii20so10811555qab.33 for ; Mon, 03 Feb 2014 12:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=aNjogVe9r0HNVZW+mUEfhs6GYIBONgoStL8zlCN1QR4=; b=K0Ehsnu+aOvnT9Qpo7jvOTw+qmMQHZbXm0p5TrpTWXBcg7c1a8FyrCM4A17uebMOcj 8Fw6AJSIlNqMWi2rPdU+TzxwBJ/AbFtH8WF6p+xi4E3iViePESNks1y4ZUW92f3KX1NB yTBzx3WA4qmfmDBrLotwAPwI4dkTg4JybYFmJ0NNKVuiEiR4brNS2onrWL3CmdX3L/fG k9Ti/G1BqrgnLtG6ODJCXS5shmKPXWqIJs5r1T9WwxtwPxb0CFvTeu8W9BJ7qajYvb34 GVzeA0oV7TmduqBblHREzr65HioN9/KEOLk2NQy4TSDsxsItERwZFCybRzMwAAkj5tlo VOUw== MIME-Version: 1.0 X-Received: by 10.140.83.112 with SMTP id i103mr56451354qgd.100.1391459925339; Mon, 03 Feb 2014 12:38:45 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Mon, 3 Feb 2014 12:38:45 -0800 (PST) Date: Mon, 3 Feb 2014 21:38:45 +0100 X-Google-Sender-Auth: VWG6JrTDX3fvWjIX_gT0st96COQ Message-ID: Subject: VirtualBox 4.3.6 keyboard repeats keystrokes From: CeDeROM To: freebsd-emulation@freebsd.org, FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 20:38:46 -0000 Hello :-) I have noticed that quite often keystrokes are repeated in VBox 4.3.6 OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it repeats many times, letters also. The fast way to stop this is to switch to another application on my BSD box then switch back to VBox.. Did anyone notice this behavior? What is the problem? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 20:52:58 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 637D6BE; Mon, 3 Feb 2014 20:52:58 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [78.47.69.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9C61316; Mon, 3 Feb 2014 20:52:57 +0000 (UTC) Received: from [IPv6:2001:470:d701::818c:79e3:fcc8:6825] (unknown [IPv6:2001:470:d701:0:818c:79e3:fcc8:6825]) by mail.jr-hosting.nl (Postfix) with ESMTPSA id DF5373F467; Mon, 3 Feb 2014 21:52:50 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT From: Remko Lodder In-Reply-To: <52EFA674.8000106@tundraware.com> Date: Mon, 3 Feb 2014 21:52:49 +0100 Message-Id: References: <52EFA015.5070601@FreeBSD.org> <52EFA674.8000106@tundraware.com> To: Tim Daneliuk X-Mailer: Apple Mail (2.1827) Cc: stable@freebsd.org, current@freebsd.org, Christian Brueffer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 20:52:58 -0000 --Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 03 Feb 2014, at 15:23, Tim Daneliuk wrote: > On 02/03/2014 07:56 AM, Christian Brueffer wrote: >> Hi, >>=20 >> for some time now we have had two drivers for NVIDIA NForce/MCP = network >> chips, namely nve(4) and nfe(4). >>=20 >> The former came first and is based on a binary blob. The latter was >> later ported from OpenBSD and is blob-free. >>=20 >> nfe(4) supports all chips nve(4) supports, in addition to all the = newer >> hardware. In essence, nfe(4) has been the de-facto standard driver = for >> a long time. nve(4) has been commented out in GENERIC since 2007. >>=20 >> For this reason I propose deprecating nve(4) in 10-STABLE and = removing >> it from HEAD. >>=20 >> Does anyone see a reason not to do this? >>=20 >> Cheers, >>=20 >> Christian (wearing my best asbestos suit) >>=20 >=20 >=20 > If you're going to be so very polite about it, how do you > expect us to have a 2000 email chain fight examining > every possible implication of your proposal ... :) in other words, just do it [tm]. >=20 >=20 > --=20 > = --------------------------------------------------------------------------= -- > Tim Daneliuk tundra@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" --=20 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News --Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS8AGhAAoJEKjD27JZ84ywzP4P/1BzzAZavF+dTVlwlltHf8BW DrK6Mejp2U5rQxuMeDyAsHrI0u97nOOpmVkc83ujoCFtY5Zdrn5/aqBw/xefFmsd A/GwjewafBeS7gjLy4U2Sc7espT/wzeLah+ZTD+sTnlR3wdG3aNsWAB022ywVLXl IO54VFfXg4kHeEC6htaUPpT+NmL4ZOD3OEmtFxVZJHa9Kipmz8Q4wrlKFYogDvSG wOJ4U+aufM0sbVncKtrqFAmFBntbi2PvB24be2iM/2aigQp+LO82/2k/MnT6J0cy IAY7sN+9blidhM4fs5xATbOUJv6M1p6qJokYJYpizar7JUJw0k5oMbDKSZExjHlU RV2+rR0xPvUaSaCmN/ugtEmtzIYOQO7jBlT9b46nagJmBcZnkXy2N3T1YpFETQSP QbNr5Qeq/r1O4TDZ+PRDeEEQH08PekCtL+HZZC+TVDW3k3FcjFCzVPFv9glP6HUB IfX3dGtjFWV3skajBhB0tKu0coOJrc2s1uXCAiXP6Xv9q0MmrrVLiAkv19ZZ6jYk lhnLK4ULbD3ZUGOrI7fF5qrR1jcvFOQnlYI0uwCXWY6aprjZKWwQWhCtVcZAdriW fayKco64shFMfNdi8r8UfJXVG8mSLFeudeSMVQoXQgx/IPcqyM7vS7sAlxEgsVLN YNo5hk/+/DKced3BtRjg =r8VW -----END PGP SIGNATURE----- --Apple-Mail=_9FF899EF-F3C0-4DA0-A6C0-F1EB60E26817-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 22:00:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A971F75D; Mon, 3 Feb 2014 22:00:43 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 71E8A18E4; Mon, 3 Feb 2014 22:00:43 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s13M0fei087879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 3 Feb 2014 17:00:41 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s13M0fJq087876; Mon, 3 Feb 2014 17:00:41 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21232.4489.544435.898780@khavrinen.csail.mit.edu> Date: Mon, 3 Feb 2014 17:00:41 -0500 From: Garrett Wollman To: "Kenneth D. Merry" Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <20140131003342.GA11755@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> <20140131003342.GA11755@nargothrond.kdm.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Mon, 03 Feb 2014 17:00:41 -0500 (EST) Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 22:00:43 -0000 < said: > The attached patch should fix the leaked allocations. I'm CCing Steve and > Kashyap at LSI so that they can verify that this is the right place to do > the mapping shutdown. It does fix the leak. > I don't know yet why that particular change is causing problems. Perhaps > it just moved things around and exposed an existing problem. > The fact that the redzone code doesn't expose any problems makes it more > likely that it is a problem other than a heap overflow. > Since it is consistent, is there any chance you could hook up remote gdb to > the box and poke around when it crashes? Perhaps you'll see something > interesting that will point to the problem. No way to do a remote GDB, unfortunately. However, I tried a few other things: - It makes no difference whether mps.ko is preloaded or loaded in single-user mode. - If I boot a kernel/modules without redzone, loading mps.ko instapanics, in a very different place (apologies for the poor transcription; I can either be up in the machine room to plug in USB sticks or use the serial console, not both): --- trap 0xc, rip = 0xffff....f807e934a, rsp = 0xff...94da4c48f0, rbp = 0xff...94da4c4950 --- bzero() at bzero+0xa/frame 0xff...94da4c4af0 mpssas_add_device() at mpssas_add_device+0x78/frame 0xff..94da4c4af0 mpssas_firmware_event_work() at mpssas_firmware_event_work+0x437/frame 0xff....94da4c4b78 taskqueue_run_locked() at taskqueue_run_locked+0x74/frame 0xff..94da4c4bc0 taskqueue_thread_loop() at taskqueue_thread_loop+0x46/frame 0xff..94da4c4be0 Inspection of the code does not reveal any arc from mpssas_add_device to bzero. The return address in the frame is the location of the first function call (to mpssas_startup_increment()) in mpssas_add_device(). So I think it's fair to say that something is scribbling over memory in quite a bad way. Two things that may be relevant: on boot, this server's MPT2 BIOS always complains "adapter configuration may have changed", and I haven't discovered anything in the configuration utility that changes this. Also, on boot, I always get the following messages: failure at /usr/src-9-stable/sys/dev/mps/mps_sas_lsi.c:667/mpssas_add_device()! Could not get ID for device with handle 0x0010 mpssas_fw_work: failed to add device with handle 0x10 This has been true across mps(4) revisions, on all three copies of this hardware that I have in service. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Mon Feb 3 23:34:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACFE497C; Mon, 3 Feb 2014 23:34:46 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A7B4813DA; Mon, 3 Feb 2014 23:34:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: X-IronPort-AV: E=Sophos;i="4.95,775,1384318800"; d="scan'208";a="93330176" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 03 Feb 2014 18:34:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C171DB3F45; Mon, 3 Feb 2014 18:34:44 -0500 (EST) Date: Mon, 3 Feb 2014 18:34:44 -0500 (EST) From: Rick Macklem To: Alfred Perlstein Message-ID: <449096679.2303214.1391470484784.JavaMail.root@uoguelph.ca> In-Reply-To: <52DBE19C.4040101@freebsd.org> Subject: Re: Major performance/stability regression in virtio network drivers between 9.2-RELEASE and 10.0-RC5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Bryan Venteicher , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 03 Feb 2014 23:34:46 -0000 Alfred Perlstein wrote: > What does vmstat say about memory zones? I think vmstat -m/vmstat -z > and also netstat -m? > > Are you set with the same mbufs on both 9 and 10? > > -Alfred > > > On 1/18/14 1:32 PM, Eric Dombroski wrote: > > Adrian: > > > > Yes, no change. > > > > -Eric > > > > > > > > > > > > On Sat, Jan 18, 2014 at 4:06 PM, Adrian Chadd > > wrote: > > > >> Hi, > >> > >> Have you tried disabling tso? > >> > >> Adrian > >> On Jan 18, 2014 1:52 PM, "Eric Dombroski" > >> wrote: > >> > >>> Hello: > >>> > >>> I believe there is a major performance regression between FreeBSD > >>> 9.2-RELEASE and 10.0-RC5 involving the virtio network drivers > >>> (vtnet) and > >>> handling incoming traffic. Below are the results of some iperf > >>> tests and > >>> large dd operations over NFS. Write throughput goes from ~40Gbps > >>> to > >>> ~2.4Gbps from 9.2 to 10.0RC5, and over time the connection > >>> becomes > >>> unstable > >>> ("no buffer space available"), requiring the interface to be > >>> taken > >>> down/up. > >>> > >>> > >>> These results are on fresh installs of 9.2 and 10.0RC5, no sysctl > >>> tweaks > >>> on > >>> either system. > >>> > >>> I can't reproduce this using an Intel 1Gbps ethernet through PCIe > >>> passthrough, although I suspect the problem manifests itself over > >>> 1Gbps > >>> speeds anyway. > >>> > >>> Tests: > >>> > >>> Client (host): > >>> root@gogo:~# uname -a > >>> Linux gogo 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 > >>> GNU/Linux > >>> root@gogo:~# kvm -version > >>> QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6, Debian), > >>> Copyright > >>> (c) 2003-2008 Fabrice Bellard > >>> root@gogo:~# lsmod | grep vhost > >>> vhost_net 27436 3 > >>> tun 18337 8 vhost_net > >>> macvtap 17633 1 vhost_net > >>> > >>> > >>> Command: iperf -c 192.168.100.x -t 60 > >>> > >>> > >>> Server (FreeBSD 9.2 VM): > >>> > >>> root@umarotest:~ # uname -a > >>> FreeBSD umarotest 9.2-RELEASE-p3 FreeBSD 9.2-RELEASE-p3 > >>> #0: Sat Jan > >>> 11 03:25:02 UTC 2014 > >>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > >>> amd64 > >>> root@umarotest:~ # iperf -s > >>> ------------------------------------------------------------ > >>> Server listening on TCP port 5001 > >>> TCP window size: 64.0 KByte (default) > >>> ------------------------------------------------------------ > >>> [ 4] local 192.168.100.44 port 5001 connected with > >>> 192.168.100.1 > >>> port 58996 > >>> [ ID] Interval Transfer Bandwidth > >>> [ 4] 0.0-60.0 sec 293 GBytes 41.9 Gbits/sec > >>> [ 5] local 192.168.100.44 port 5001 connected with > >>> 192.168.100.1 > >>> port 58997 > >>> [ 5] 0.0-60.0 sec 297 GBytes 42.5 Gbits/sec > >>> [ 4] local 192.168.100.44 port 5001 connected with > >>> 192.168.100.1 > >>> port 58998 > >>> [ 4] 0.0-60.0 sec 291 GBytes 41.6 Gbits/sec > >>> [ 5] local 192.168.100.44 port 5001 connected with > >>> 192.168.100.1 > >>> port 58999 > >>> [ 5] 0.0-60.0 sec 297 GBytes 42.6 Gbits/sec > >>> [ 4] local 192.168.100.44 port 5001 connected with > >>> 192.168.100.1 > >>> port 59000 > >>> [ 4] 0.0-60.0 sec 297 GBytes 42.5 Gbits/sec > >>> > >>> While pinging out from the server to the client, I do not > >>> get any > >>> errors. > >>> > >>> > >>> root@umaro:~ # uname -a FreeBSD umaro 10.0-RC5 FreeBSD > >>> 10.0-RC5 #0 > >>> r260430: Wed Jan 8 05:10:04 UTC 2014 > >>> root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC > >>> amd64 > >>> root@umaro:~ # iperf -s > >>> ------------------------------------------------------------ > >>> Server listening on TCP port 5001 > >>> TCP window size: 64.0 KByte (default) > >>> ------------------------------------------------------------ > >>> [ 4] local 192.168.100.5 port 5001 connected with > >>> 192.168.100.1 > >>> port > >>> 50264 > >>> [ ID] Interval Transfer Bandwidth > >>> [ 4] 0.0-60.0 sec 16.7 GBytes 2.39 Gbits/sec > >>> [ 5] local 192.168.100.5 port 5001 connected with > >>> 192.168.100.1 > >>> port > >>> 50265 > >>> [ 5] 0.0-60.0 sec 18.3 GBytes 2.62 Gbits/sec > >>> [ 4] local 192.168.100.5 port 5001 connected with > >>> 192.168.100.1 > >>> port > >>> 50266 > >>> [ 4] 0.0-60.0 sec 16.8 GBytes 2.40 Gbits/sec > >>> [ 5] local 192.168.100.5 port 5001 connected with > >>> 192.168.100.1 > >>> port > >>> 50267 > >>> [ 5] 0.0-60.0 sec 16.8 GBytes 2.40 Gbits/sec > >>> [ 4] local 192.168.100.5 port 5001 connected with > >>> 192.168.100.1 > >>> port > >>> 50268 > >>> [ 4] 0.0-60.0 sec 16.8 GBytes 2.41 Gbits/sec > >>> > >>> *** While pinging out from the server to client, frequent > >>> "ping: > >>> sendto: No space left on device" errors *** > >>> > >>> > >>> After a while, I can also reliably re-produce more > >>> egregious "ping: > >>> sendto: No buffer space available" errors after doing a large > >>> sequential > >>> write over NFS: > >>> > >>> mount -t nfs -o rsize=65536,wsize=65536 192.168.100.5: > >>> /storage/shared > >>> /mnt/nfs > >>> dd if=/dev/zero of=/mnt/nfs/testfile bs=1M count=30000 > >>> > >>> I am going to file a freebsd bug report as well. > >>> Are you able to test the driver from an up to date head? Bryan Venteicher just committed some changes to the driver that increase the size of the segments list (# of mbufs in chain) and also switches it from using m_collapse() to m_defrag(). I have no idea if these might affect what you are seeing? rick > >>> Thanks, > >>> Eric > >>> _______________________________________________ > >>> 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" > >>> > > _______________________________________________ > > 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" > > > > _______________________________________________ > 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 Tue Feb 4 01:34:30 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 840135F6 for ; Tue, 4 Feb 2014 01:34:30 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45CEC1D60 for ; Tue, 4 Feb 2014 01:34:30 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id c10so5985210igq.0 for ; Mon, 03 Feb 2014 17:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:reply-to:mime-version:content-type :content-disposition; bh=wlnl3n2ZvMi60NEbbzjOohkx8HinYub8EkXCWtfh1bo=; b=UKNuPsFB2HRWj7MJS0RRUaC4WjWtzAvTEv5cvQn6PwrOCV0B1xZLIKZdqwhQhhPOLY sVVg/DblyeINxQbMgITIOLlwXo5oNjDH3qgQnxVBZMhMX19vPYTtfHRbM39MrBWL2/y6 NPoSkA1NxBicwFJAeGiJBKpz4lH83FRqagLpo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-type:content-disposition; bh=wlnl3n2ZvMi60NEbbzjOohkx8HinYub8EkXCWtfh1bo=; b=CQgoKq5Tfo9WadF62phiKZFgr9ZQ1k5n1SYdIrZukTCQOzUba2znyG6uCWqpMLi5jM eo0ckhV1cmOBQ5We5Lh4UEt9buhQB3DqvkCbD08tUw2RZRTLvjOBpbJkGblWTO7SNMfw ZTb2eqa2glmMZP+mvfSLhgkLnUaQhGdrAf1Fa/jXwDimEFSIPlK3T168h8kpb/dZR6yH MGYWYt4Lpb+Hra7JV2rWhjZT9OF6Aw/AFOp7cGnHdMR2tt81is4t+DRmGaeVjelj8k1l /bTtpbZOedvDbjFg5ch+eHND5UgE4A7CxsgWUgthLG2JmnWGDOM87GTPwdA9aHnegKcf wJXw== X-Gm-Message-State: ALoCoQkUcESRZ8Me9YZUWEOLRerinj3jfhWc/OhZTWRnlEvMB8uN3yg/gGs8AkKknler1knEn3mf X-Received: by 10.50.61.101 with SMTP id o5mr15084851igr.31.1391477669667; Mon, 03 Feb 2014 17:34:29 -0800 (PST) Received: from DataIX.local (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id f15sm35930175igd.3.2014.02.03.17.34.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Feb 2014 17:34:28 -0800 (PST) Received: from DataIX.local (localhost [127.0.0.1]) by DataIX.local (8.14.7/8.14.7) with ESMTP id s141YQCE019288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Feb 2014 20:34:27 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.local (8.14.7/8.14.7/Submit) id s141YQD4019234; Mon, 3 Feb 2014 20:34:26 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Mon, 3 Feb 2014 20:34:25 -0500 From: jhellenthal@dataix.net To: zfs-devel@freebsd.org, stable@freebsd.org Subject: WITHOUT_CDDL leftovers (libzfs_core.so.2, zstreamdump) Message-ID: <20140204013425.GA98236@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: zfs-devel@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 01:34:30 -0000 It appears that a couple things were left out of the 'delete-old*' targets and left behind from being removed in 10-STABLE at least on powerpc but likely elsewhere. Could someone take a moment to go through this when they get a chance ? Thanks Unresolvable link(s) found in: /lib/libzfs_core.so.2 libnvpair.so.2 Unresolvable link(s) found in: /usr/bin/zstreamdump libnvpair.so.2 libumem.so.2 libzpool.so.2 libavl.so.2 -- - (2^(N-1)) JJH48-ARIN From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 01:40:12 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E25E735 for ; Tue, 4 Feb 2014 01:40:12 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F350A1DE6 for ; Tue, 4 Feb 2014 01:40:11 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id uy17so5900157igb.3 for ; Mon, 03 Feb 2014 17:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=VSyUfMhLgY6ePkHT4ZfJblO92cgKgfLIKpE7UKBgXh0=; b=cxQqD90P1sBusAHoecRmq/7y0h1sFflpBVyoVxYj04WLbYo5XgU1KbEX0h/82Jzu/N iFfJN8kvS3gxdcOMXR9jGdkivZ/t1OK/r22Tz2McrRcgK3M/3aUw9ydgj+iLQdjwzGGR mDoCz1gI5qS/ysXQq8bJYD4tbMGX3D4SDIuJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=VSyUfMhLgY6ePkHT4ZfJblO92cgKgfLIKpE7UKBgXh0=; b=TorvYB7xlpx7M5YvW8SuC5588/+2+gdPMNQpX7fpSQc2RzKZrGkakWynhxUK9a7sbW eGD/5uSTNK36+pVbbr6mqU2dJLn00Ja/XUMG3SHmpuBnabCKTxsnn72U1yUFmSX+Ejj/ q13ybxGBHe+HNEKvPCoLE1o1lgs64hJMxNb1UI3MIlzQTZZgK4R+TfU8Reu897EFwLmq WP1usjW/M3gs4vVuRaBNR2RETZecktsQvTIhdbBf0/elFlrKGB/DOf3hvgujfwcba946 mjZRQJ3yHUwEy+JceFrdTU/aOETDXw4P/5geKd26pXz8AHzpeihKMa3rxc07Bm1izy1q op+A== X-Gm-Message-State: ALoCoQndEEihXNlHfTXk8KuLpA57e7KSxhr3AktZm9Lpxxr54pUBuvV9JLSvi3ft5LHTmUNdZg99 X-Received: by 10.50.230.20 with SMTP id su20mr15225133igc.18.1391478011443; Mon, 03 Feb 2014 17:40:11 -0800 (PST) Received: from DataIX.local (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id ml2sm35923826igb.10.2014.02.03.17.40.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Feb 2014 17:40:10 -0800 (PST) Received: from DataIX.local (localhost [127.0.0.1]) by DataIX.local (8.14.7/8.14.7) with ESMTP id s141e8Z5023068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Feb 2014 20:40:08 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.local (8.14.7/8.14.7/Submit) id s141e7ar023067; Mon, 3 Feb 2014 20:40:07 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Mon, 3 Feb 2014 20:40:07 -0500 From: jhellenthal@dataix.net To: zfs-devel@freebsd.org, stable@freebsd.org Subject: Re: WITHOUT_CDDL leftovers (libzfs_core.so.2, zstreamdump) Message-ID: <20140204014007.GA22901@DataIX.net> References: <20140204013425.GA98236@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140204013425.GA98236@DataIX.net> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 01:40:12 -0000 On Mon, Feb 03, 2014 at 08:34:25PM -0500, jhellenthal@DataIX.net wrote: > > It appears that a couple things were left out of the 'delete-old*' targets and left behind from being removed in 10-STABLE at least on powerpc but likely elsewhere. > > Could someone take a moment to go through this when they get a chance ? > > Thanks > > Unresolvable link(s) found in: /lib/libzfs_core.so.2 > libnvpair.so.2 > Unresolvable link(s) found in: /usr/bin/zstreamdump > libnvpair.so.2 > libumem.so.2 > libzpool.so.2 > libavl.so.2 One more Unresolvable link(s) found in: /usr/sbin/zhack^M libnvpair.so.2^M libumem.so.2^M libuutil.so.2^M libzfs.so.2^M libzpool.so.2 > > -- > > - (2^(N-1)) JJH48-ARIN > -- - (2^(N-1)) JJH48-ARIN From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 01:44:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DD5C86C; Tue, 4 Feb 2014 01:44:10 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 451491E11; Tue, 4 Feb 2014 01:44:10 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id un15so7805100pbc.32 for ; Mon, 03 Feb 2014 17:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WRq3JiVvSRZ5nO/9hnel8fdmodu9Ob9GYNTn3lsK2lo=; b=Qckc9mCK7ZyQZRvzsaInaNp4zKgv67EnhH2W1m9iDoGMw1uRQXWGTunmhISCciazqe pEaFky8a5mg8jXKWAuxAN5KW7e02sv2D8xe2fs2eM3T4GNCZ+pVW/RWKVIy3MAP2vSaz /e8iADBCzIV3vqUU3WPe2aRy4A6q6Zhegowd9dSAEkp1Li5ySKWcPx7++tvneFlcCk6c pC46Zv9ZJpme7/GZQc+x2gEOhSTZgpo7jF0XWxpaLAs9FxUm4DrsTt/X0g1i24fP+ezg mrWmxP48zrUPu9gBzffeZJ3np9xNBTgsNhhbDvAc/LZNYfKNe63PyqwIyXYStoL9IvV8 QU7A== MIME-Version: 1.0 X-Received: by 10.68.218.65 with SMTP id pe1mr40595885pbc.1.1391478249928; Mon, 03 Feb 2014 17:44:09 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Mon, 3 Feb 2014 17:44:09 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 17:44:09 -0800 X-Google-Sender-Auth: uHbgD2YADJZk0OGB1R3eLb1a5JM Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Kevin Oberman To: CeDeROM Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-emulation@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 01:44:10 -0000 On Mon, Feb 3, 2014 at 12:38 PM, CeDeROM wrote: > Hello :-) > > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it > repeats many times, letters also. The fast way to stop this is to > switch to another application on my BSD box then switch back to VBox.. > > Did anyone notice this behavior? What is the problem? > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > I have this issue, but only when logged into the VM remotely via RDP. From the local console this never happens. It is intermittent and never happens when the session is first opened. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 03:03:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC283130; Tue, 4 Feb 2014 03:03:23 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95D551852; Tue, 4 Feb 2014 03:03:23 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id lf10so7910589pab.32 for ; Mon, 03 Feb 2014 19:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uwYqIQj8rqu/f5Y2nAK8v9hrTr3po2zcgD0lwSj4sIs=; b=DUZZPYkeZrvpRsSwte4eKgdRw13UQbL9jv9RQTz+s/wdYiW0/QL9ylHHFXoj4kpEym D4nJMLZnosamh3FxhX/a9pf9HSDUsvo7bkF30j0sDfWNDBuFSYmUBSl1s/T09lLvw/rP 8gpPYxsTHtkCjR/uFPtC64TVH5mstXAbGadUKN0vk8BsF+192dumMQrmJwso3khAR38Z x1pdhT/MB6MDyOtLlxHNHsE0f8tG0xKFDnEvLkpzlTXT9X1vV6CXfhjF1ubSmK1aC97d jMhlUm1DfRqaAUlGAdWpZn6VI+imsFDGz5P/afhuFFp+Tl36SAvIgcWSZagtKi/APoUo shsA== MIME-Version: 1.0 X-Received: by 10.66.179.143 with SMTP id dg15mr41501995pac.52.1391483003182; Mon, 03 Feb 2014 19:03:23 -0800 (PST) Received: by 10.68.155.38 with HTTP; Mon, 3 Feb 2014 19:03:23 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 22:03:23 -0500 Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Aryeh Friedman To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-emulation@freebsd.org, FreeBSD Stable , CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 03:03:24 -0000 On Mon, Feb 3, 2014 at 8:44 PM, Kevin Oberman wrote: > On Mon, Feb 3, 2014 at 12:38 PM, CeDeROM wrote: > > > Hello :-) > > > > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 > > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it > > repeats many times, letters also. The fast way to stop this is to > > switch to another application on my BSD box then switch back to VBox.. > > > > Did anyone notice this behavior? What is the problem? > > > > Best regards :-) > > Tomek > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > I have this issue, but only when logged into the VM remotely via RDP. From > the local console this never happens. It is intermittent and never happens > when the session is first opened. > Do you notice this only in VBox or other hypervisiors like bhyve or qemu? (Some motherboards do not like virtualization even when the CPU allows it one easy way to test this is with petitecloud [you might even find it a good replacement for vbox]) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 06:23:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98299CB3; Tue, 4 Feb 2014 06:23:43 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 388BF1791; Tue, 4 Feb 2014 06:23:43 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wn1so8953778obc.34 for ; Mon, 03 Feb 2014 22:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Q8VKVXpF+0BDPraLwOmpztuzG/gAUwa39pi6qMdMfrQ=; b=n3W9tSOUk3doY1T6Ie6rzfWD+QBjpwp9sg9dn0bVUVWWVFwZDENFd+MZdb25rS8J3b yitXkCHFnP9Wc8+8ocSLO8RpNWhh4l+Q9zCRk9a/Wfq+MuX2rZrtYrPS6yA3afgOqABK yDHms2eO/YaLR9gI+qfC0opj59j9Q6fwIMIft0S5s54JTwuh5aZW94Rld+qBrEnrzD2k 8qtNu9sdd0pRwpt5Ru36q8U7dXxGO8QBKZTOiQe98ymK19oFv0AHNX4B++rp640iQLRr MaAYI1fEAX8jVzLtMSOQpppVv2xMKDjWe+4n5ZVP/Ug1SBYnNZKNABHfZQ6wuppg+YIf Nr4A== X-Received: by 10.182.22.135 with SMTP id d7mr33523044obf.1.1391495022455; Mon, 03 Feb 2014 22:23:42 -0800 (PST) MIME-Version: 1.0 Sender: mr.kodiak@gmail.com Received: by 10.60.173.206 with HTTP; Mon, 3 Feb 2014 22:23:11 -0800 (PST) In-Reply-To: <449096679.2303214.1391470484784.JavaMail.root@uoguelph.ca> References: <52DBE19C.4040101@freebsd.org> <449096679.2303214.1391470484784.JavaMail.root@uoguelph.ca> From: Bryan Venteicher Date: Tue, 4 Feb 2014 00:23:11 -0600 X-Google-Sender-Auth: LoUe5p5mdOnK3uIUZRH6gNAyEpg Message-ID: Subject: Re: Major performance/stability regression in virtio network drivers between 9.2-RELEASE and 10.0-RC5 To: Rick Macklem Content-Type: multipart/mixed; boundary=001a11c2e19085471b04f18eaebd X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Bryan Venteicher , Alfred Perlstein , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 06:23:43 -0000 --001a11c2e19085471b04f18eaebd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 5:34 PM, Rick Macklem wrote: > Alfred Perlstein wrote: > > What does vmstat say about memory zones? I think vmstat -m/vmstat -z > > and also netstat -m? > > > > Are you set with the same mbufs on both 9 and 10? > > > > -Alfred > > > > > > On 1/18/14 1:32 PM, Eric Dombroski wrote: > > > Adrian: > > > > > > Yes, no change. > > > > > > -Eric > > > > > > > > > > > > > > > > > > On Sat, Jan 18, 2014 at 4:06 PM, Adrian Chadd > > > wrote: > > > > > >> Hi, > > >> > > >> Have you tried disabling tso? > > >> > > >> Adrian > > >> On Jan 18, 2014 1:52 PM, "Eric Dombroski" > > >> wrote: > > >> > > >>> Hello: > > >>> > > >>> I believe there is a major performance regression between FreeBSD > > >>> 9.2-RELEASE and 10.0-RC5 involving the virtio network drivers > > >>> (vtnet) and > > >>> handling incoming traffic. Below are the results of some iperf > > >>> tests and > > >>> large dd operations over NFS. Write throughput goes from ~40Gbps > > >>> to > > >>> ~2.4Gbps from 9.2 to 10.0RC5, and over time the connection > > >>> becomes > > >>> unstable > > >>> ("no buffer space available"), requiring the interface to be > > >>> taken > > >>> down/up. > > >>> > > >>> > > >>> These results are on fresh installs of 9.2 and 10.0RC5, no sysctl > > >>> tweaks > > >>> on > > >>> either system. > > >>> > > >>> I can't reproduce this using an Intel 1Gbps ethernet through PCIe > > >>> passthrough, although I suspect the problem manifests itself over > > >>> 1Gbps > > >>> speeds anyway. > > >>> > > >>> Tests: > > >>> > > >>> Client (host): > > >>> root@gogo:~# uname -a > > >>> Linux gogo 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 > > >>> GNU/Linux > > >>> root@gogo:~# kvm -version > > >>> QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6, Debian), > > >>> Copyright > > >>> (c) 2003-2008 Fabrice Bellard > > >>> root@gogo:~# lsmod | grep vhost > > >>> vhost_net 27436 3 > > >>> tun 18337 8 vhost_net > > >>> macvtap 17633 1 vhost_net > > >>> > > >>> > > >>> Command: iperf -c 192.168.100.x -t 60 > > >>> > > >>> > > >>> Server (FreeBSD 9.2 VM): > > >>> > > >>> root@umarotest:~ # uname -a > > >>> FreeBSD umarotest 9.2-RELEASE-p3 FreeBSD 9.2-RELEASE-p3 > > >>> #0: Sat Jan > > >>> 11 03:25:02 UTC 2014 > > >>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > > >>> amd64 > > >>> root@umarotest:~ # iperf -s > > >>> ------------------------------------------------------------ > > >>> Server listening on TCP port 5001 > > >>> TCP window size: 64.0 KByte (default) > > >>> ------------------------------------------------------------ > > >>> [ 4] local 192.168.100.44 port 5001 connected with > > >>> 192.168.100.1 > > >>> port 58996 > > >>> [ ID] Interval Transfer Bandwidth > > >>> [ 4] 0.0-60.0 sec 293 GBytes 41.9 Gbits/sec > > >>> [ 5] local 192.168.100.44 port 5001 connected with > > >>> 192.168.100.1 > > >>> port 58997 > > >>> [ 5] 0.0-60.0 sec 297 GBytes 42.5 Gbits/sec > > >>> [ 4] local 192.168.100.44 port 5001 connected with > > >>> 192.168.100.1 > > >>> port 58998 > > >>> [ 4] 0.0-60.0 sec 291 GBytes 41.6 Gbits/sec > > >>> [ 5] local 192.168.100.44 port 5001 connected with > > >>> 192.168.100.1 > > >>> port 58999 > > >>> [ 5] 0.0-60.0 sec 297 GBytes 42.6 Gbits/sec > > >>> [ 4] local 192.168.100.44 port 5001 connected with > > >>> 192.168.100.1 > > >>> port 59000 > > >>> [ 4] 0.0-60.0 sec 297 GBytes 42.5 Gbits/sec > > >>> > > >>> While pinging out from the server to the client, I do not > > >>> get any > > >>> errors. > > >>> > > >>> > > >>> root@umaro:~ # uname -a FreeBSD umaro 10.0-RC5 FreeBSD > > >>> 10.0-RC5 #0 > > >>> r260430: Wed Jan 8 05:10:04 UTC 2014 > > >>> root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC > > >>> amd64 > > >>> root@umaro:~ # iperf -s > > >>> ------------------------------------------------------------ > > >>> Server listening on TCP port 5001 > > >>> TCP window size: 64.0 KByte (default) > > >>> ------------------------------------------------------------ > > >>> [ 4] local 192.168.100.5 port 5001 connected with > > >>> 192.168.100.1 > > >>> port > > >>> 50264 > > >>> [ ID] Interval Transfer Bandwidth > > >>> [ 4] 0.0-60.0 sec 16.7 GBytes 2.39 Gbits/sec > > >>> [ 5] local 192.168.100.5 port 5001 connected with > > >>> 192.168.100.1 > > >>> port > > >>> 50265 > > >>> [ 5] 0.0-60.0 sec 18.3 GBytes 2.62 Gbits/sec > > >>> [ 4] local 192.168.100.5 port 5001 connected with > > >>> 192.168.100.1 > > >>> port > > >>> 50266 > > >>> [ 4] 0.0-60.0 sec 16.8 GBytes 2.40 Gbits/sec > > >>> [ 5] local 192.168.100.5 port 5001 connected with > > >>> 192.168.100.1 > > >>> port > > >>> 50267 > > >>> [ 5] 0.0-60.0 sec 16.8 GBytes 2.40 Gbits/sec > > >>> [ 4] local 192.168.100.5 port 5001 connected with > > >>> 192.168.100.1 > > >>> port > > >>> 50268 > > >>> [ 4] 0.0-60.0 sec 16.8 GBytes 2.41 Gbits/sec > > >>> > > >>> *** While pinging out from the server to client, frequent > > >>> "ping: > > >>> sendto: No space left on device" errors *** > > >>> > > >>> > > >>> After a while, I can also reliably re-produce more > > >>> egregious "ping: > > >>> sendto: No buffer space available" errors after doing a large > > >>> sequential > > >>> write over NFS: > > >>> > > >>> mount -t nfs -o rsize=65536,wsize=65536 192.168.100.5: > > >>> /storage/shared > > >>> /mnt/nfs > > >>> dd if=/dev/zero of=/mnt/nfs/testfile bs=1M count=30000 > > >>> > > >>> I am going to file a freebsd bug report as well. > > >>> > Are you able to test the driver from an up to date head? > Bryan Venteicher just committed some changes to the driver > that increase the size of the segments list (# of mbufs in chain) > and also switches it from using m_collapse() to m_defrag(). > I have no idea if these might affect what you are seeing? > > Yes, please try HEAD if you can, but I think you can take the driver from HEAD on 10 without too much work. I'll MFC my recent changes to 10 in a week or so. As for the "No buffer space available" error, can you try the attached patch [1]? It is from HEAD, but should apply to 10 as well. I have not been able to recreate this but I suspect it might fix it. [1] - http://people.freebsd.org/~bryanv/patches/vtnet_watchdog.patch rick > > > >>> Thanks, > > >>> Eric > > >>> _______________________________________________ > > >>> 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" > > >>> > > > _______________________________________________ > > > 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" > > > > > > > _______________________________________________ > > 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" > > > --001a11c2e19085471b04f18eaebd Content-Type: text/x-patch; charset=US-ASCII; name="vtnet_watchdog.patch" Content-Disposition: attachment; filename="vtnet_watchdog.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hr8s11pf0 Y29tbWl0IDNmMjU3NTM4Nzk4YjQ4ZGQ3MjdlNzljOGFmNmIyYTExYmQ1MDJlNWIKQXV0aG9yOiBC cnlhbiBWZW50ZWljaGVyIDxicnlhbnZAZGFlbW9uaW50aGVjbG9zZXQub3JnPgpEYXRlOiAgIFR1 ZSBGZWIgNCAwMDowODo1MiAyMDE0IC0wNjAwCgogICAgU2ltdWxhdGUgYW4gaW50ZXJydXB0IGlm IHRoZSB3YXRjaGRvZyBkcmFpbmVkIHRoZSBUeCBjb21wbGV0ZSBxdWV1ZQoKZGlmZiAtLWdpdCBh L3N5cy9kZXYvdmlydGlvL25ldHdvcmsvaWZfdnRuZXQuYyBiL3N5cy9kZXYvdmlydGlvL25ldHdv cmsvaWZfdnRuZXQuYwppbmRleCBjYzRhZGViLi45M2RlNTA0IDEwMDY0NAotLS0gYS9zeXMvZGV2 L3ZpcnRpby9uZXR3b3JrL2lmX3Z0bmV0LmMKKysrIGIvc3lzL2Rldi92aXJ0aW8vbmV0d29yay9p Zl92dG5ldC5jCkBAIC0xNDksNyArMTQ5LDcgQEAgc3RhdGljIHZvaWQJdnRuZXRfdHhxX3RxX2Rl ZmVycmVkKHZvaWQgKiwgaW50KTsKICNlbmRpZgogc3RhdGljIHZvaWQJdnRuZXRfdHhxX3N0YXJ0 KHN0cnVjdCB2dG5ldF90eHEgKik7CiBzdGF0aWMgdm9pZAl2dG5ldF90eHFfdHFfaW50cih2b2lk ICosIGludCk7Ci1zdGF0aWMgdm9pZAl2dG5ldF90eHFfZW9mKHN0cnVjdCB2dG5ldF90eHEgKik7 CitzdGF0aWMgaW50CXZ0bmV0X3R4cV9lb2Yoc3RydWN0IHZ0bmV0X3R4cSAqKTsKIHN0YXRpYyB2 b2lkCXZ0bmV0X3R4X3ZxX2ludHIodm9pZCAqKTsKIHN0YXRpYyB2b2lkCXZ0bmV0X3R4X3N0YXJ0 X2FsbChzdHJ1Y3QgdnRuZXRfc29mdGMgKik7CiAKQEAgLTIzODUsMTggKzIzODUsMjEgQEAgdnRu ZXRfdHhxX3RxX2ludHIodm9pZCAqeHR4cSwgaW50IHBlbmRpbmcpCiAJVlRORVRfVFhRX1VOTE9D Syh0eHEpOwogfQogCi1zdGF0aWMgdm9pZAorc3RhdGljIGludAogdnRuZXRfdHhxX2VvZihzdHJ1 Y3QgdnRuZXRfdHhxICp0eHEpCiB7CiAJc3RydWN0IHZpcnRxdWV1ZSAqdnE7CiAJc3RydWN0IHZ0 bmV0X3R4X2hlYWRlciAqdHhoZHI7CiAJc3RydWN0IG1idWYgKm07CisJaW50IGRlcTsKIAogCXZx ID0gdHhxLT52dG50eF92cTsKKwlkZXEgPSAwOwogCVZUTkVUX1RYUV9MT0NLX0FTU0VSVCh0eHEp OwogCiAJd2hpbGUgKCh0eGhkciA9IHZpcnRxdWV1ZV9kZXF1ZXVlKHZxLCBOVUxMKSkgIT0gTlVM TCkgewogCQltID0gdHhoZHItPnZ0aF9tYnVmOworCQlkZXErKzsKIAogCQl0eHEtPnZ0bnR4X3N0 YXRzLnZ0eHNfb3BhY2tldHMrKzsKIAkJdHhxLT52dG50eF9zdGF0cy52dHhzX29ieXRlcyArPSBt LT5tX3BrdGhkci5sZW47CkBAIC0yNDA5LDYgKzI0MTIsOCBAQCB2dG5ldF90eHFfZW9mKHN0cnVj dCB2dG5ldF90eHEgKnR4cSkKIAogCWlmICh2aXJ0cXVldWVfZW1wdHkodnEpKQogCQl0eHEtPnZ0 bnR4X3dhdGNoZG9nID0gMDsKKworCXJldHVybiAoZGVxKTsKIH0KIAogc3RhdGljIHZvaWQKQEAg LTI1MTIsOCArMjUxNywxMyBAQCB2dG5ldF93YXRjaGRvZyhzdHJ1Y3QgdnRuZXRfdHhxICp0eHEp CiAJc2MgPSB0eHEtPnZ0bnR4X3NjOwogCiAJVlRORVRfVFhRX0xPQ0sodHhxKTsKLQlpZiAoc2Mt PnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19FVkVOVF9JRFgpCi0JCXZ0bmV0X3R4cV9lb2YodHhx KTsKKwlpZiAoc2MtPnZ0bmV0X2ZsYWdzICYgVlRORVRfRkxBR19FVkVOVF9JRFgpIHsKKwkJaWYg KHR4cS0+dnRudHhfd2F0Y2hkb2cgIT0gMCAmJiB2dG5ldF90eHFfZW9mKHR4cSkgIT0gMCkgewor CQkJdGFza3F1ZXVlX2VucXVldWUodHhxLT52dG50eF90cSwgJnR4cS0+dnRudHhfaW50cnRhc2sp OworCQkJVlRORVRfVFhRX1VOTE9DSyh0eHEpOworCQkJcmV0dXJuICgwKTsKKwkJfQorCX0KIAlp ZiAodHhxLT52dG50eF93YXRjaGRvZyA9PSAwIHx8IC0tdHhxLT52dG50eF93YXRjaGRvZykgewog CQlWVE5FVF9UWFFfVU5MT0NLKHR4cSk7CiAJCXJldHVybiAoMCk7Cg== --001a11c2e19085471b04f18eaebd-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 06:36:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A033E55; Tue, 4 Feb 2014 06:36:19 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E95FE1869; Tue, 4 Feb 2014 06:36:18 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id z10so7864609pdj.33 for ; Mon, 03 Feb 2014 22:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CHWqzzVYMPzjlUVmt9rnqOjVhN6TTeblZOsDf1MiyRA=; b=Mr08HIBl8942XcE9LY2wN9/yTRgDX8VTKTkoP9aBIKz6Diqikl1rJXWrHjWUc8XKRw +Ts4pRd6DFXEAZCEY09/TWMSSX0Dk5mxnVd7yyZYXteZsSafzy4Dx0cg7+NQESI+h+LH +dpU+Wm3XkygjT8PLh27/1AInJvjk8YsJLlj/0uYz4vnl5m6UAQT9RsCqhpnX7yShoed deHKs0LFqnyWf0gsTq5VWL1DswIvwXVmjO6pPZM3KdT6aXFdYECiNWmMuWPfsUz9YHsg 09ccT6FN15ACt911NMlC7FwSEYkW3jCqDkYbgzx1fTE61ro/5WLVIQvYHJMUlHVa+1dH xVmA== MIME-Version: 1.0 X-Received: by 10.66.224.109 with SMTP id rb13mr41473173pac.78.1391495778523; Mon, 03 Feb 2014 22:36:18 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Mon, 3 Feb 2014 22:36:18 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 22:36:18 -0800 X-Google-Sender-Auth: -VtR5pypiTddrO3vDKq-vzxE7Eg Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Kevin Oberman To: Aryeh Friedman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-emulation@freebsd.org, FreeBSD Stable , CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 06:36:19 -0000 On Mon, Feb 3, 2014 at 7:03 PM, Aryeh Friedman wrote: > > > > On Mon, Feb 3, 2014 at 8:44 PM, Kevin Oberman wrote: > >> On Mon, Feb 3, 2014 at 12:38 PM, CeDeROM wrote: >> >> > Hello :-) >> > >> > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 >> > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it >> > repeats many times, letters also. The fast way to stop this is to >> > switch to another application on my BSD box then switch back to VBox.. >> > >> > Did anyone notice this behavior? What is the problem? >> > >> > Best regards :-) >> > Tomek >> > >> > -- >> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> > >> >> I have this issue, but only when logged into the VM remotely via RDP. From >> the local console this never happens. It is intermittent and never happens >> when the session is first opened. >> > > Do you notice this only in VBox or other hypervisiors like bhyve or qemu? > (Some motherboards do not like virtualization even when the CPU allows it > one easy way to test this is with petitecloud [you might even find it a > good replacement for vbox]) > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > I only have tried VB, but I just realized that the problem is either an upstream VB issue or an issue with the RDP implementation in rdesktop. I just realized that I see the same issue when connected to a Linux Mint VB client running on a Windows7 system. The only common FreeBSD involvement is that it us the RDP client. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 07:01:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F65828A; Tue, 4 Feb 2014 07:01:51 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 597941A09; Tue, 4 Feb 2014 07:01:51 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id v10so7892512pde.0 for ; Mon, 03 Feb 2014 23:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gZu8PlCncF7bMHBoXb++hGHXNazx6mrwcWscmp11Xgc=; b=HDhmDW+PPV7EfPONY2VwGA6QWH7dEP6n2jk8+aP+4KXuFrfRcduwU81sJ+//ncg/bt tbBdzhEytdY1FvwPGxwx9en89lpOIcrVj5iTxxQJpqJZIDudD5u9q9Xb1GnjFEFCnR3q yagR0t1/RCsm9kr884Ml8eRKcQvnHAgSKWMBF9bTtW7PnATRGHGnDyKrLUf7cx5VR6W4 9/y0iNGF45jY45tierVV2dABwPDbjX7sT+Yq/smRAKW9vKhipInPG6de/mMcRoB55blT zuqkKuq04Xx7vosPdIybjvU7bR9IdTNtjAs3u/lpeXs+67+eerOOg74Ua3ctT8Ko012T QtTw== MIME-Version: 1.0 X-Received: by 10.68.171.229 with SMTP id ax5mr42170770pbc.125.1391497310995; Mon, 03 Feb 2014 23:01:50 -0800 (PST) Received: by 10.68.155.38 with HTTP; Mon, 3 Feb 2014 23:01:50 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 02:01:50 -0500 Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Aryeh Friedman To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-emulation@freebsd.org, FreeBSD Stable , CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 07:01:51 -0000 On Tue, Feb 4, 2014 at 1:36 AM, Kevin Oberman wrote: > On Mon, Feb 3, 2014 at 7:03 PM, Aryeh Friedman wrote: > >> >> >> >> On Mon, Feb 3, 2014 at 8:44 PM, Kevin Oberman wrote: >> >>> On Mon, Feb 3, 2014 at 12:38 PM, CeDeROM wrote: >>> >>> > Hello :-) >>> > >>> > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 >>> > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it >>> > repeats many times, letters also. The fast way to stop this is to >>> > switch to another application on my BSD box then switch back to VBox.. >>> > >>> > Did anyone notice this behavior? What is the problem? >>> > >>> > Best regards :-) >>> > Tomek >>> > >>> > -- >>> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>> > >>> >>> I have this issue, but only when logged into the VM remotely via RDP. >>> From >>> the local console this never happens. It is intermittent and never >>> happens >>> when the session is first opened. >>> >> >> Do you notice this only in VBox or other hypervisiors like bhyve or qemu? >> (Some motherboards do not like virtualization even when the CPU allows it >> one easy way to test this is with petitecloud [you might even find it a >> good replacement for vbox]) >> -- >> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org >> > > I only have tried VB, but I just realized that the problem is either an > upstream VB issue or an issue with the RDP implementation in rdesktop. > > I just realized that I see the same issue when connected to a Linux Mint > VB client running on a Windows7 system. The only common FreeBSD > involvement is that it us the RDP client. > If you have VNC enabled VM's (if I remember right it is a vbox option) do they behave the same way? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 07:41:19 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 289B6CAA; Tue, 4 Feb 2014 07:41:19 +0000 (UTC) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B709E1C99; Tue, 4 Feb 2014 07:41:17 +0000 (UTC) Received: from dynamic.1.17.e8edf383af80.685b35818d2c.afb.bredband2.com (dynamic.1.17.e8edf383af80.685b35818d2c.afb.bredband2.com [31.208.68.40]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MCILJ-1W26Be114j-009C9M; Tue, 04 Feb 2014 08:41:15 +0100 Message-ID: <52F09999.9030807@FreeBSD.org> Date: Tue, 04 Feb 2014 08:41:13 +0100 From: Christian Brueffer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: current@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT References: <52EFA015.5070601@FreeBSD.org> In-Reply-To: <52EFA015.5070601@FreeBSD.org> X-Enigmail-Version: 1.6 OpenPGP: id=3A67DC36; url=http://people.freebsd.org/~brueffer/brueffer.key.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fiVRRWfOLp81fpU4PaJraA20cOanR3h3B" X-Provags-ID: V02:K0:4gDidNcqFreeTRD6m3FM2wHp0Gsyas26NFq7HbSn1MJ Y61pwP7o5H/QYS7MFEBKD7upH2Bxoe5XY+HvK4clbAHR3AUW6a qNZOJpBRjuLqELnHPEBHXdpbm5sWiciso97SoX8LPwKuhx4icN Kgmpnvd8bkEtBz1GNVzUV5jxl6umWlsZzHd57RCvl4hdwygj73 3m8NGZG4a1UvKaCMiNd7lC56sRk0H0Lrw4c9kofLT9UAWk9g0X XG1FbYy4VWuNGPy4iOdaCIoEWeudy55NAG5qFZqFoI+2TS5Trp YlisWVm+hTk5fIOiJbS9rhOsMwcErelMWgijz0t09zf8FK/ib2 geQg7U5TuEV/ZBJnm4bncjBeOnlXq114zGJ2F+s1tnAqE9CVS9 jZterEBDAOZGaQm4IDzSYZN4qOnagYIdPEZURR4OE+CRAqYhzh lJV3D Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 07:41:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fiVRRWfOLp81fpU4PaJraA20cOanR3h3B Content-Type: multipart/mixed; boundary="------------040205050306080801060107" This is a multi-part message in MIME format. --------------040205050306080801060107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/3/14 2:56 PM, Christian Brueffer wrote: > Hi, >=20 > for some time now we have had two drivers for NVIDIA NForce/MCP network= > chips, namely nve(4) and nfe(4). >=20 > The former came first and is based on a binary blob. The latter was > later ported from OpenBSD and is blob-free. >=20 > nfe(4) supports all chips nve(4) supports, in addition to all the newer= > hardware. In essence, nfe(4) has been the de-facto standard driver for= > a long time. nve(4) has been commented out in GENERIC since 2007. >=20 > For this reason I propose deprecating nve(4) in 10-STABLE and removing > it from HEAD. >=20 For completeness sake, attached is the proposed patch. It can also be found here: http://people.freebsd.org/~brueffer/nve.removal.diff Cheers, Christian --------------040205050306080801060107 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="nve.removal.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="nve.removal.diff" Index: ObsoleteFiles.inc =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- ObsoleteFiles.inc (revision 261434) +++ ObsoleteFiles.inc (working copy) @@ -38,6 +38,9 @@ # xargs -n1 | sort | uniq -d; # done =20 +# 201302xx: nve(4) replaced by nfe(4) +OLD_FILES+=3Dusr/share/man/man4/nve.4.gz +OLD_FILES+=3Dusr/share/man/man4/if_nve.4.gz # 20140128: libelf and libdwarf import OLD_LIBS+=3Dusr/lib/libelf.so.1 OLD_LIBS+=3Dusr/lib32/libelf.so.1 Index: release/doc/en_US.ISO8859-1/hardware/article.xml =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- release/doc/en_US.ISO8859-1/hardware/article.xml (revision 261434) +++ release/doc/en_US.ISO8859-1/hardware/article.xml (working copy) @@ -883,8 +883,6 @@ =20 &hwlist.nge; =20 - &hwlist.nve; - &hwlist.nxge; =20 &hwlist.oce; Index: release/doc/en_US.ISO8859-1/relnotes/article.xml =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- release/doc/en_US.ISO8859-1/relnotes/article.xml (revision 261434) +++ release/doc/en_US.ISO8859-1/relnotes/article.xml (working copy) @@ -176,6 +176,11 @@ Support for Broadcom chipsets BCM57764, BCM57767, BCM57782, BCM57786 and BCM57787 has been added to &man.bge.4;. + + The deprecated nve(4) driver has been + removed. Users of NVIDIA nForce MCP network adapters are + advised to use the &man.nfe.4; driver instead, which has been + the default driver for this hardware since &os; 7.0. =20 Index: release/doc/share/misc/dev.archlist.txt =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- release/doc/share/misc/dev.archlist.txt (revision 261434) +++ release/doc/share/misc/dev.archlist.txt (working copy) @@ -97,7 +97,6 @@ ng_bt3c i386,pc98,amd64 ng_ubt i386,pc98,amd64 nsp i386,pc98 -nve i386,amd64 nxge i386,amd64 oce i386,amd64 ohci i386,pc98,ia64,amd64,powerpc Index: share/man/man4/Makefile =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man4/Makefile (revision 261434) +++ share/man/man4/Makefile (working copy) @@ -343,7 +343,6 @@ ${_ntb.4} \ null.4 \ ${_nvd.4} \ - ${_nve.4} \ ${_nvme.4} \ ${_nvram.4} \ ${_nvram2env.4} \ @@ -670,7 +669,6 @@ MLINKS+=3Dnge.4 if_nge.4 MLINKS+=3D${_ntb.4} ${_if_ntb.4} \ ${_ntb.4} ${_ntb_hw.4} -MLINKS+=3D${_nve.4} ${_if_nve.4} MLINKS+=3D${_nxge.4} ${_if_nxge.4} MLINKS+=3Dpatm.4 if_patm.4 MLINKS+=3Dpccbb.4 cbb.4 @@ -768,7 +766,6 @@ _if_bxe.4=3D if_bxe.4 _if_ndis.4=3D if_ndis.4 _if_nfe.4=3D if_nfe.4 -_if_nve.4=3D if_nve.4 _if_nxge.4=3D if_nxge.4 _if_urtw.4=3D if_urtw.4 _if_vmx.4=3D if_vmx.4 @@ -783,7 +780,6 @@ _nfe.4=3D nfe.4 _nfsmb.4=3D nfsmb.4 _nvd.4=3D nvd.4 -_nve.4=3D nve.4 _nvme.4=3D nvme.4 _nvram.4=3D nvram.4 _nxge.4=3D nxge.4 Index: share/man/man4/altq.4 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man4/altq.4 (revision 261434) +++ share/man/man4/altq.4 (working copy) @@ -151,7 +151,6 @@ .Xr nfe 4 , .Xr nge 4 , .Xr npe 4 , -.Xr nve 4 , .Xr qlxgb 4 , .Xr ral 4 , .Xr re 4 , Index: share/man/man4/miibus.4 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man4/miibus.4 (revision 261434) +++ share/man/man4/miibus.4 (working copy) @@ -87,8 +87,6 @@ NVIDIA nForce MCP Networking Adapter .It Xr nge 4 National Semiconductor DP83820/DP83821 Gigabit Ethernet -.It Xr nve 4 -NVIDIA nForce MCP Networking Adapter .It Xr pcn 4 AMD Am79C97x PCI 10/100 .It Xr re 4 @@ -159,7 +157,6 @@ .Xr netintro 4 , .Xr nfe 4 , .Xr nge 4 , -.Xr nve 4 , .Xr pcn 4 , .Xr re 4 , .Xr rgephy 4 , Index: share/man/man4/nve.4 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man4/nve.4 (revision 261434) +++ share/man/man4/nve.4 (working copy) @@ -1,141 +0,0 @@ -.\" Copyright (c) 2003 Quinton Dolan -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright= -.\" notice, this list of conditions and the following disclaimer in t= he -.\" documentation and/or other materials provided with the distributi= on. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' A= ND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, TH= E -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR P= URPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIA= BLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQU= ENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GO= ODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION= ) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN AN= Y WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF -.\" SUCH DAMAGE. -.\" -.\" $Id: nvnet.4,v 1.1 2003/10/09 16:48:01 q Exp $ -.\" -.\" $FreeBSD$ -.\" -.Dd January 16, 2011 -.Dt NVE 4 -.Os -.Sh NAME -.Nm nve -.Nd "NVIDIA nForce MCP Networking Adapter device driver" -.Sh SYNOPSIS -To compile this driver into the kernel, -place the following lines in your -kernel configuration file: -.Bd -ragged -offset indent -.Cd "device miibus" -.Cd "device nve" -.Ed -.Pp -Alternatively, to load the driver as a -module at boot time, place the following line in -.Xr loader.conf 5 : -.Bd -literal -offset indent -if_nve_load=3D"YES" -.Ed -.Sh DESCRIPTION -The -.Nm -driver provides support for the NVIDIA nForce MCP and nForce2 MCP2 -networking adapter that is embedded in the southbridge of most -nForce and nForce2 motherboards. -.Pp -This driver is a reimplementation of the NVIDIA supported Linux -.Nm nvnet -driver and uses the same closed source API library to access -the underlying hardware. -There is currently no programming documentation available for this -device, and therefore little is known about the internal architecture -of the MAC engine itself. -.Pp -The -.Nm -driver supports the following media types: -.Bl -tag -width ".Cm 10baseT/UTP" -.It Cm autoselect -Enable autoselection of the media type and options. -.It Cm 10baseT/UTP -Set 10Mbps operation. -.It Cm 100baseTX -Set 100Mbps (Fast Ethernet) operation. -.It Cm 1000baseTX -Set 1000Mbps (Gigabit Ethernet) operation. -.El -.Pp -The -.Nm -driver supports the following media options: -.Bl -tag -width ".Cm 10baseT/UTP" -.It Cm full-duplex -Set full duplex operation. -.El -.Pp -For more information on configuring this device, see -.Xr ifconfig 8 . -.Sh HARDWARE -The -.Nm -driver supports the NVIDIA MCP onboard adapters of mainboards with -the following chipsets: -.Pp -.Bl -bullet -compact -.It -nForce -.It -nForce2 -.It -nForce3 -.It -nForce4 -.El -.Sh DIAGNOSTICS -.Bl -diag -.It "nve%d: couldn't map memory" -A fatal initialization error has occurred. -.It "nve%d: couldn't map interrupt" -A fatal initialization error has occurred. -.It "nve%d: failed to allocate memory" -There are not enough mbufs available for allocation. -.It "nve%d: device timeout" -The device has stopped responding to the network, or there is a problem = with -the network connection (cable). -.El -.Sh SEE ALSO -.Xr altq 4 , -.Xr arp 4 , -.Xr miibus 4 , -.Xr netintro 4 , -.Xr ng_ether 4 , -.Xr rgephy 4 , -.Xr ifconfig 8 -.Sh HISTORY -The -.Nm -driver first appeared in -.Fx 6.0 . -.Sh AUTHORS -.An -nosplit -The -.Nm -driver was written by -.An Quinton Dolan Aq q@onthenet.com.au -and -.An "David E. O'Brien" Aq obrien@FreeBSD.org . -.Sh BUGS -There are reports that when the card is in auto select mode, -ifconfig output reports a 10baseT/UTP output while the LEDs and -bandwidth show that the card is actually in 100baseTX mode. Index: share/man/man4/vlan.4 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- share/man/man4/vlan.4 (revision 261434) +++ share/man/man4/vlan.4 (working copy) @@ -176,7 +176,6 @@ .Xr hme 4 , .Xr le 4 , .Xr nfe 4 , -.Xr nve 4 , .Xr rl 4 , .Xr sf 4 , .Xr sis 4 , Index: sys/amd64/conf/GENERIC =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/amd64/conf/GENERIC (revision 261434) +++ sys/amd64/conf/GENERIC (working copy) @@ -235,7 +235,6 @@ device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet -#device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 Index: sys/amd64/conf/NOTES =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/amd64/conf/NOTES (revision 261434) +++ sys/amd64/conf/NOTES (working copy) @@ -309,7 +309,6 @@ # mlxen: Mellanox ConnectX HCA Ethernet # mthca: Mellanox HCA InfiniBand # nfe: nVidia nForce MCP on-board Ethernet Networking (BSD open source) -# nve: nVidia nForce MCP on-board Ethernet Networking # sfxge: Solarflare SFC9000 family 10Gb Ethernet adapters # vmx: VMware VMXNET3 Ethernet (BSD open source) # wpi: Intel 3945ABG Wireless LAN controller @@ -327,7 +326,6 @@ device mlxen # Mellanox ConnectX HCA Ethernet device mthca # Mellanox HCA InfiniBand device nfe # nVidia nForce MCP on-board Ethernet -device nve # nVidia nForce MCP on-board Ethernet Networking device sfxge # Solarflare SFC9000 10Gb Ethernet device vmx # VMware VMXNET3 Ethernet device wpi # Intel 3945ABG wireless NICs. Index: sys/boot/forth/loader.conf =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/forth/loader.conf (revision 261434) +++ sys/boot/forth/loader.conf (working copy) @@ -327,7 +327,6 @@ if_my_load=3D"NO" # Myson PCI Fast Ethernet if_nfe_load=3D"NO" # NVIDIA nForce MCP Networking Adapter if_nge_load=3D"NO" # National Semiconductor PCI Gigabit Ethernet -if_nve_load=3D"NO" # NVIDIA nForce MCP Networking Adapter if_nxge_load=3D"NO" # Neterion Xframe 10Gb Ethernet if_patm_load=3D"NO" # IDT77252 ATM if_pcn_load=3D"NO" # AMD PCnet PCI Index: sys/conf/WITHOUT_SOURCELESS_HOST =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/conf/WITHOUT_SOURCELESS_HOST (revision 261434) +++ sys/conf/WITHOUT_SOURCELESS_HOST (working copy) @@ -8,4 +8,3 @@ nodevice hptmv nodevice hptnr nodevice hptrr -nodevice nve Index: sys/conf/files.amd64 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/conf/files.amd64 (revision 261434) +++ sys/conf/files.amd64 (working copy) @@ -47,17 +47,6 @@ no-obj no-implicit-rule before-depend \ clean "ukbdmap.h" # -nvenetlib.o optional nve pci \ - dependency "$S/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu" \ - compile-with "uudecode $S/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu ; bz= ip2 -df nvenetlib.o.bz2" \ - no-implicit-rule -# -os+%DIKED-nve.h optional nve pci \ - dependency "$S/contrib/dev/nve/os.h" \ - compile-with "sed -e 's/^.*#include.*phy\.h.*$$//' $S/contrib/dev/nve/o= s.h > os+%DIKED-nve.h" \ - no-implicit-rule no-obj before-depend \ - clean "os+%DIKED-nve.h" -# hpt27xx_lib.o optional hpt27xx \ dependency "$S/dev/hpt27xx/amd64-elf.hpt27xx_lib.o.uu" \ compile-with "uudecode < $S/dev/hpt27xx/amd64-elf.hpt27xx_lib.o.uu" \ @@ -248,7 +237,6 @@ dev/ntb/if_ntb/if_ntb.c optional if_ntb dev/ntb/ntb_hw/ntb_hw.c optional if_ntb ntb_hw dev/nvd/nvd.c optional nvd nvme -dev/nve/if_nve.c optional nve pci dev/nvme/nvme.c optional nvme dev/nvme/nvme_ctrlr.c optional nvme dev/nvme/nvme_ctrlr_cmd.c optional nvme Index: sys/conf/files.i386 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/conf/files.i386 (revision 261434) +++ sys/conf/files.i386 (working copy) @@ -46,17 +46,6 @@ no-obj no-implicit-rule before-depend \ clean "ukbdmap.h" # -nvenetlib.o optional nve pci \ - dependency "$S/contrib/dev/nve/i386/nvenetlib.o.bz2.uu" \ - compile-with "uudecode $S/contrib/dev/nve/i386/nvenetlib.o.bz2.uu ; bzi= p2 -df nvenetlib.o.bz2" \ - no-implicit-rule -# -os+%DIKED-nve.h optional nve pci \ - dependency "$S/contrib/dev/nve/os.h" \ - compile-with "sed -e 's/^.*#include.*phy\.h.*$$//' $S/contrib/dev/nve/o= s.h > os+%DIKED-nve.h" \ - no-implicit-rule no-obj before-depend \ - clean "os+%DIKED-nve.h" -# hpt27xx_lib.o optional hpt27xx \ dependency "$S/dev/hpt27xx/i386-elf.hpt27xx_lib.o.uu" \ compile-with "uudecode < $S/dev/hpt27xx/i386-elf.hpt27xx_lib.o.uu" \ @@ -257,7 +246,6 @@ dev/mse/mse_isa.c optional mse isa dev/nfe/if_nfe.c optional nfe pci dev/nvd/nvd.c optional nvd nvme -dev/nve/if_nve.c optional nve pci dev/nvme/nvme.c optional nvme dev/nvme/nvme_ctrlr.c optional nvme dev/nvme/nvme_ctrlr_cmd.c optional nvme Index: sys/contrib/dev/nve/adapter.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/adapter.h (revision 261434) +++ sys/contrib/dev/nve/adapter.h (working copy) @@ -1,583 +0,0 @@ -/***********************************************************************= ****\ -|* = *| -|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL= *| -|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY= *| -|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT = *| -|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED = *| -|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A= *| -|* PARTICULAR PURPOSE. = *| -|* = *| -\***********************************************************************= ****/=20 - -/* - FILE: adapter.h - DATE: 2/7/00 - - This file contains the hardware interface to the ethernet adapter. -*/ - -#ifndef _ADAPTER_H_ -#define _ADAPTER_H_ - -#ifdef __cplusplus -extern "C" { -#endif - -#define HDA_VERSION_STRING "HDR A: $Revision: #46 $" - -#ifdef MODS_NETWORK_BUILD -#ifndef _DRVAPP_H_ -#include "drvapp.h" -#endif -#endif - -////////////////////////////////////////////////////////////////// -// For the set and get configuration calls. -typedef struct _ADAPTER_CONFIG -{ - NV_UINT32 ulFlags; -} ADAPTER_CONFIG, *PADAPTER_CONFIG; -////////////////////////////////////////////////////////////////// - -typedef struct _ADAPTER_WRITE_OFFLOAD -{ - NV_UINT32 usBitmask; - NV_UINT32 ulMss; - -} ADAPTER_WRITE_OFFLOAD; - -////////////////////////////////////////////////////////////////// -// For the ADAPTER_Write1 call. -/* This scatter gather list should be same as defined in ndis.h by MS. - For ULONG_PTR MS header file says that it will be of same size as - pointer. It has been defined to take care of casting between differen= et - sizes. -*/ -typedef struct _NVSCATTER_GATHER_ELEMENT { - NV_UINT32 PhysLow; - NV_UINT32 PhysHigh; - NV_UINT32 Length; - NV_VOID *Reserved; -} NVSCATTER_GATHER_ELEMENT, *PNVSCATTER_GATHER_ELEMENT; - -#ifndef linux -#pragma warning(disable:4200) -#endif -typedef struct _NVSCATTER_GATHER_LIST { - NV_UINT32 NumberOfElements; - NV_VOID *Reserved; - NVSCATTER_GATHER_ELEMENT Elements[0]; // Made 0 sized element to r= emove MODS compilation error - // Elements[0] and Elements[= ] have the same effect.=20 - // sizeof(NVSCATTER_GATHER_L= IST) is the same (value of 8) in both cases - // And both lead to Warning = 4200 in MSVC -} NVSCATTER_GATHER_LIST, *PNVSCATTER_GATHER_LIST; -#ifndef linux -#pragma warning(default:4200) -#endif - -typedef struct _ADAPTER_WRITE_DATA1 -{ - NV_UINT32 ulTotalLength; - PNV_VOID pvID; - NV_UINT8 uc8021pPriority; - ADAPTER_WRITE_OFFLOAD *psOffload; - PNVSCATTER_GATHER_LIST pNVSGL; -} ADAPTER_WRITE_DATA1, *PADAPTER_WRITE_DATA1; - - -////////////////////////////////////////////////////////////////// -// For the ADAPTER_Write call. -typedef struct _ADAPTER_WRITE_ELEMENT -{ - PNV_VOID pPhysical; - NV_UINT32 ulLength; -} ADAPTER_WRITE_ELEMENT, *PADAPTER_WRITE_ELEMENT; - - -#define ADAPTER_WRITE_OFFLOAD_BP_SEGOFFLOAD 0 -#define ADAPTER_WRITE_OFFLOAD_BP_IPV4CHECKSUM 1 -#define ADAPTER_WRITE_OFFLOAD_BP_IPV6CHECKSUM 2 -#define ADAPTER_WRITE_OFFLOAD_BP_TCPCHECKSUM 3 -#define ADAPTER_WRITE_OFFLOAD_BP_UDPCHECKSUM 4 -#define ADAPTER_WRITE_OFFLOAD_BP_IPCHECKSUM 5 - - -// pvID is a value that will be passed back into OSAPI.pfnPacketWasSent -// when the transmission completes. if pvID is NULL, the ADAPTER code -// assumes the caller does not want the pfnPacketWasSent callback. -typedef struct _ADAPTER_WRITE_DATA -{ - NV_UINT32 ulNumberOfElements; - NV_UINT32 ulTotalLength; - PNV_VOID pvID; - NV_UINT8 uc8021pPriority; - ADAPTER_WRITE_OFFLOAD *psOffload; -#ifdef linux - ADAPTER_WRITE_ELEMENT sElement[32]; -#else - ADAPTER_WRITE_ELEMENT sElement[100]; -#endif -} ADAPTER_WRITE_DATA, *PADAPTER_WRITE_DATA; -////////////////////////////////////////////////////////////////// - - - -////////////////////////////////////////////////////////////////// -// For the ADAPTER_Read call. -typedef struct _ADAPTER_READ_ELEMENT -{ - PNV_VOID pPhysical; - NV_UINT32 ulLength; -} ADAPTER_READ_ELEMENT, *PADAPTER_READ_ELEMENT; - -typedef struct _ADAPTER_READ_OFFLOAD -{ - NV_UINT8 ucChecksumStatus; - -} ADAPTER_READ_OFFLOAD; - -typedef struct _ADAPTER_READ_DATA -{ - NV_UINT32 ulNumberOfElements; - NV_UINT32 ulTotalLength; - PNV_VOID pvID; - NV_UINT32 ulFilterMatch; - ADAPTER_READ_OFFLOAD sOffload; - ADAPTER_READ_ELEMENT sElement[10]; -} ADAPTER_READ_DATA, *PADAPTER_READ_DATA; - - -#define RDFLAG_CHK_NOCHECKSUM 0 -#define RDFLAG_CHK_IPPASSTCPFAIL 1 -#define RDFLAG_CHK_IPPASSUDPFAIL 2 -#define RDFLAG_CHK_IPFAIL 3 -#define RDFLAG_CHK_IPPASSNOTCPUDP 4 -#define RDFLAG_CHK_IPPASSTCPPASS 5 -#define RDFLAG_CHK_IPPASSUDPPASS 6 -#define RDFLAG_CHK_RESERVED 7 - - -// The ulFilterMatch flag can be a logical OR of the following -#define ADREADFL_UNICAST_MATCH 0x00000001 -#define ADREADFL_MULTICAST_MATCH 0x00000002 -#define ADREADFL_BROADCAST_MATCH 0x00000004 -////////////////////////////////////////////////////////////////// - - - -////////////////////////////////////////////////////////////////// -// For the ADAPTER_GetPowerCapabilities call. -typedef struct _ADAPTER_POWERCAPS -{ - NV_UINT32 ulPowerFlags; - NV_UINT32 ulMagicPacketWakeUpFlags; - NV_UINT32 ulPatternWakeUpFlags; - NV_UINT32 ulLinkChangeWakeUpFlags; - NV_SINT32 iMaxWakeUpPatterns; -} ADAPTER_POWERCAPS, *PADAPTER_POWERCAPS; - -// For the ADAPTER_GetPowerState and ADAPTER_SetPowerState call. -typedef struct _ADAPTER_POWERSTATE -{ - NV_UINT32 ulPowerFlags; - NV_UINT32 ulMagicPacketWakeUpFlags; - NV_UINT32 ulPatternWakeUpFlags; - NV_UINT32 ulLinkChangeWakeUpFlags; -} ADAPTER_POWERSTATE, *PADAPTER_POWERSTATE; - -// Each of the flag fields in the POWERCAPS structure above can have -// any of the following bitflags set giving the capabilites of the -// adapter. In the case of the wake up fields, these flags mean that -// wake up can happen from the specified power state. - -// For the POWERSTATE structure, the ulPowerFlags field should just -// have one of these bits set to go to that particular power state. -// The WakeUp fields can have one or more of these bits set to indicate -// what states should be woken up from. -#define POWER_STATE_D0 0x00000001 -#define POWER_STATE_D1 0x00000002 -#define POWER_STATE_D2 0x00000004 -#define POWER_STATE_D3 0x00000008 - -#define POWER_STATE_ALL (POWER_STATE_D0 | \ - POWER_STATE_D1 | \ - POWER_STATE_D2 | \ - POWER_STATE_D3) -////////////////////////////////////////////////////////////////// - - - -////////////////////////////////////////////////////////////////// -// The ADAPTER_GetPacketFilterCaps call returns a NV_UINT32 that can -// have the following capability bits set. -#define ACCEPT_UNICAST_PACKETS 0x00000001 -#define ACCEPT_MULTICAST_PACKETS 0x00000002 -#define ACCEPT_BROADCAST_PACKETS 0x00000004 -#define ACCEPT_ALL_PACKETS 0x00000008 - -#define ETH_LENGTH_OF_ADDRESS 6 - -// The ADAPTER_SetPacketFilter call uses this structure to know what -// packet filter to set. The ulPacketFilter field can contain some -// union of the bit flags above. The acMulticastMask array holds a -// 48 bit MAC address mask with a 0 in every bit position that should -// be ignored on compare and a 1 in every bit position that should -// be taken into account when comparing to see if the destination -// address of a packet should be accepted for multicast. -typedef struct _PACKET_FILTER -{ - NV_UINT32 ulFilterFlags; - NV_UINT8 acMulticastAddress[ETH_LENGTH_OF_ADDRESS]; - NV_UINT8 acMulticastMask[ETH_LENGTH_OF_ADDRESS]; -} PACKET_FILTER, *PPACKET_FILTER; -////////////////////////////////////////////////////////////////// - - -////////////////////////////////////////////////////////////////// -// A WAKE_UP_PATTERN is a 128-byte pattern that the adapter can -// look for in incoming packets to decide when to wake up. Higher- -// level protocols can use this to, for example, wake up the -// adapter whenever it sees an IP packet that is addressed to it. -// A pattern consists of 128 bits of byte masks that indicate -// which bytes in the packet are relevant to the pattern, plus -// values for each byte. -#define WAKE_UP_PATTERN_SIZE 128 - -typedef struct _WAKE_UP_PATTERN -{ - NV_UINT32 aulByteMask[WAKE_UP_PATTERN_SIZE/32]; - NV_UINT8 acData[WAKE_UP_PATTERN_SIZE]; -} WAKE_UP_PATTERN, *PWAKE_UP_PATTERN; - - - -// -// -// Adapter offload -// -typedef struct _ADAPTER_OFFLOAD { - - NV_UINT32 Type; - NV_UINT32 Value0; - -} ADAPTER_OFFLOAD, *PADAPTER_OFFLOAD; - -#define ADAPTER_OFFLOAD_VLAN 0x00000001 -#define ADAPTER_OFFLOAD_IEEE802_1P 0x00000002 -#define ADAPTER_OFFLOAD_IEEE802_1PQ_PAD 0x00000004 - -////////////////////////////////////////////////////////////////// - -// CMNDATA_OS_ADAPTER -// Structure common to OS and Adapter layers -// Used for moving data from the OS layer to the adapter layer through = SetCommonData=20 -// function call from OS layer to Adapter layer -//=20 - -typedef struct _CMNDATA_OS_ADAPTER -{ -#ifndef linux - ASF_SEC0_BASE sRegSec0Base; -#endif - NV_UINT32 bFPGA;=20 - NV_UINT32 ulFPGAEepromSize; - NV_UINT32 bChecksumOffloadEnable; - NV_UINT32 ulChecksumOffloadBM; - NV_UINT32 ulChecksumOffloadOS; - NV_UINT32 ulMediaIF; - NV_UINT32 bOemCustomEventRead; - - // Debug only right now - //!!! Beware mods is relying on the fields blow. - NV_UINT32 ulWatermarkTFBW; - NV_UINT32 ulBackoffRseed; - NV_UINT32 ulBackoffSlotTime; - NV_UINT32 ulModeRegTxReadCompleteEnable; - NV_UINT32 ulFatalErrorRegister; - -} CMNDATA_OS_ADAPTER; - - -////////////////////////////////////////////////////////////////// -// The functional typedefs for the ADAPTER Api -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_CLOSE) (PNV_VOID pvContext= , NV_UINT8 ucIsPowerDown); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_INIT) (PNV_VOID pvContext,= NV_UINT16 usForcedSpeed, NV_UINT8 ucForceDpx, NV_UINT8 ucForceMode, NV_U= INT8 ucAsyncMode, NV_UINT32 *puiLinkState); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_DEINIT) (PNV_VOID pvContex= t, NV_UINT8 ucIsPowerDown); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_START) (PNV_VOID pvContext= ); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_STOP) (PNV_VOID pvContext= , NV_UINT8 ucIsPowerDown); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_QUERY_WRITE_SLOTS) (PNV_VOI= D pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_WRITE) (PNV_VOID pvContext,= ADAPTER_WRITE_DATA *pADWriteData); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_WRITE1) (PNV_VOID pvContext= , ADAPTER_WRITE_DATA1 *pADWriteData1); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_QUERY_INTERRUPT) (PNV_VOID = pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_HANDLE_INTERRUPT) (PNV_VOID= pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_DISABLE_INTERRUPTS) (PNV_VO= ID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_ENABLE_INTERRUPTS) (PNV_VOI= D pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_CLEAR_INTERRUPTS) (PNV_VOID= pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_CLEAR_TX_DESC) (PNV_VOID pv= Context); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_LINK_SPEED) (PNV_VOID p= vContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_LINK_MODE) (PNV_VOID pv= Context); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_LINK_STATE) (PNV_VOID p= vContext, NV_UINT32 *pulLinkState); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_IS_LINK_INITIALIZING) (PNV_= VOID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_RESET_PHY_INIT_STATE) (PNV_= VOID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_TRANSMIT_QUEUE_SIZE) (P= NV_VOID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_RECEIVE_QUEUE_SIZE) (PN= V_VOID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_STATISTICS) (PNV_VOID p= vContext, PADAPTER_STATS pADStats); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_POWER_CAPS) (PNV_VOID p= vContext, PADAPTER_POWERCAPS pADPowerCaps); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_POWER_STATE) (PNV_VOID = pvContext, PADAPTER_POWERSTATE pADPowerState); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_POWER_STATE) (PNV_VOID = pvContext, PADAPTER_POWERSTATE pADPowerState); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_LOW_SPEED_FOR_PM) (PNV_= VOID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_GET_PACKET_FILTER_CAPS) (PN= V_VOID pvContext); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_PACKET_FILTER) (PNV_VOI= D pvContext, PPACKET_FILTER pPacketFilter); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_SET_WAKE_UP_PATTERN) (PNV_V= OID pvContext, NV_SINT32 iPattern, PWAKE_UP_PATTERN pPattern); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_ENABLE_WAKE_UP_PATTERN) (PN= V_VOID pvContext, NV_SINT32 iPattern, NV_SINT32 iEnable); -typedef NV_API_CALL NV_SINT32 (* PFN_SET_NODE_ADDRESS) (PNV_VOID pvConte= xt, NV_UINT8 *pNodeAddress); -typedef NV_API_CALL NV_SINT32 (* PFN_GET_NODE_ADDRESS) (PNV_VOID pvConte= xt, NV_UINT8 *pNodeAddress); -typedef NV_API_CALL NV_SINT32 (* PFN_GET_ADAPTER_INFO) (PNV_VOID pvConte= xt, PNV_VOID pVoidPtr, NV_SINT32 iType, NV_SINT32 *piLength); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_READ_PHY) (PNV_VOID pvCont= ext, NV_UINT32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 *pulValue); -typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_WRITE_PHY) (PNV_VOID pvCont= ext, NV_UINT32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 ulValue); -typedef NV_API_CALL NV_VOID(* PFN_ADAPTER_SET_SPPED_DUPLEX) (PNV_VOID pv= Context); -typedef NV_API_CALL NV_SINT32 (*PFN_REGISTER_OFFLOAD) (PNV_VOID pvContex= t, PADAPTER_OFFLOAD pOffload); -typedef NV_API_CALL NV_SINT32 (*PFN_DEREGISTER_OFFLOAD) (PNV_VOID pvCont= ext, PADAPTER_OFFLOAD pOffload); -typedef NV_API_CALL NV_SINT32 (*PFN_RX_BUFF_READY) (PNV_VOID pvContext, = PMEMORY_BLOCK pMemBlock, PNV_VOID pvID); - -#ifndef linux -typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETUPREGISTERS) (PNV_VOID pvContext,= NV_SINT32 bInitTime); -typedef NV_SINT32 (*PFN_ADAPTER_ASF_GETSEC0BASEADDRESS) (PNV_VOID pvCont= ext, ASF_SEC0_BASE **ppsSec0Base); -typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETSOURCEIPADDRESS) (PNV_VOID pvCont= ext, NV_UINT8 *pucSrcIPAddress); -typedef NV_SINT32 (*PFN_ADAPTER_ASF_GETDESTIPADDRESS) (PNV_VOID pvContex= t, NV_UINT8 *pucDestIPAddress); -typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETDESTIPADDRESS) (PNV_VOID pvContex= t, NV_UINT8 *pucDestIPAddress); -typedef NV_SINT32 (*PFN_ADAPTER_ASF_WRITEEEPROMANDSETUPREGISTERS) (PNV_V= OID pvContext, NV_BOOLEAN bCompare, PNV_VOID pucValue, PNV_VOID pszSec0Ba= seMember,=20 - NV_UINT16 usCount, NV_UINT32 ulAdd= ressOffset); - -typedef NV_SINT32 (*PFN_ADAPTER_ASF_ISASFREADY) (PNV_VOID pvContext, ASF= _ASFREADY *psASFReady); - -typedef NV_SINT32 (*PFN_ADAPTER_ASF_SETDESTMACADDRESS) (PNV_VOID pvConte= xt, NV_UINT8 *pucDestMACAddress); -typedef NV_SINT32 (*PFN_ADAPTER_ASF_GETSOURCEMACADDRESS) (PNV_VOID pvCon= text, NV_UINT8 *pucSrcMACAddress); - -typedef NV_SINT32 (*PFN_ADAPTER_ASF_CHECK_FOR_EEPROM_PRESENCE) (PNV_VOI= D pvContext); -#endif - -typedef NV_API_CALL NV_VOID (*PFN_ADAPTER_SET_COMMONDATA) (PNV_VOID pvCo= ntext, CMNDATA_OS_ADAPTER *psOSAdpater); -typedef NV_API_CALL NV_VOID (*PFN_ADAPTER_SET_CHECKSUMOFFLOAD) (PNV_VOID= pvContext, NV_UINT32 bSet); - - -=20 -typedef struct _ADAPTER_API -{ - // The adapter context - PNV_VOID pADCX; - - // The adapter interface - PFN_ADAPTER_CLOSE pfnClose; - PFN_ADAPTER_INIT pfnInit; - PFN_ADAPTER_DEINIT pfnDeinit; - PFN_ADAPTER_START pfnStart; - PFN_ADAPTER_STOP pfnStop; - PFN_ADAPTER_QUERY_WRITE_SLOTS pfnQueryWriteSlots; - PFN_ADAPTER_WRITE pfnWrite; - PFN_ADAPTER_WRITE1 pfnWrite1; - PFN_ADAPTER_QUERY_INTERRUPT pfnQueryInterrupt; - PFN_ADAPTER_HANDLE_INTERRUPT pfnHandleInterrupt; - PFN_ADAPTER_DISABLE_INTERRUPTS pfnDisableInterrupts; - PFN_ADAPTER_ENABLE_INTERRUPTS pfnEnableInterrupts; - PFN_ADAPTER_CLEAR_INTERRUPTS pfnClearInterrupts; - PFN_ADAPTER_CLEAR_TX_DESC pfnClearTxDesc; - PFN_ADAPTER_GET_LINK_SPEED pfnGetLinkSpeed; - PFN_ADAPTER_GET_LINK_MODE pfnGetLinkMode; - PFN_ADAPTER_GET_LINK_STATE pfnGetLinkState; - PFN_ADAPTER_IS_LINK_INITIALIZING pfnIsLinkInitializing; - PFN_ADAPTER_RESET_PHY_INIT_STATE pfnResetPhyInitState; - PFN_ADAPTER_GET_TRANSMIT_QUEUE_SIZE pfnGetTransmitQueueSize; - PFN_ADAPTER_GET_RECEIVE_QUEUE_SIZE pfnGetReceiveQueueSize; - PFN_ADAPTER_GET_STATISTICS pfnGetStatistics; - PFN_ADAPTER_GET_POWER_CAPS pfnGetPowerCaps; - PFN_ADAPTER_GET_POWER_STATE pfnGetPowerState; - PFN_ADAPTER_SET_POWER_STATE pfnSetPowerState; - PFN_ADAPTER_SET_LOW_SPEED_FOR_PM pfnSetLowSpeedForPM; - PFN_ADAPTER_GET_PACKET_FILTER_CAPS pfnGetPacketFilterCaps; - PFN_ADAPTER_SET_PACKET_FILTER pfnSetPacketFilter; - PFN_ADAPTER_SET_WAKE_UP_PATTERN pfnSetWakeUpPattern; - PFN_ADAPTER_ENABLE_WAKE_UP_PATTERN pfnEnableWakeUpPattern; - PFN_SET_NODE_ADDRESS pfnSetNodeAddress; - PFN_GET_NODE_ADDRESS pfnGetNodeAddress; - PFN_GET_ADAPTER_INFO pfnGetAdapterInfo; - PFN_ADAPTER_SET_SPPED_DUPLEX pfnSetSpeedDuplex; - PFN_ADAPTER_READ_PHY pfnReadPhy; - PFN_ADAPTER_WRITE_PHY pfnWritePhy; - PFN_REGISTER_OFFLOAD pfnRegisterOffload; - PFN_DEREGISTER_OFFLOAD pfnDeRegisterOffload; - PFN_RX_BUFF_READY pfnRxBuffReady; -#ifndef linux - PFN_ADAPTER_ASF_SETUPREGISTERS pfnASFSetupRegisters; - PFN_ADAPTER_ASF_GETSEC0BASEADDRESS pfnASFGetSec0BaseAddress; - PFN_ADAPTER_ASF_SETSOURCEIPADDRESS pfnASFSetSourceIPAddress; - PFN_ADAPTER_ASF_GETDESTIPADDRESS pfnASFGetDestIPAddress; - PFN_ADAPTER_ASF_SETDESTIPADDRESS pfnASFSetDestIPAddress; - PFN_ADAPTER_ASF_WRITEEEPROMANDSETUPREGISTERS pfnASFWriteEEPROMAndSet= upRegisters; - PFN_ADAPTER_ASF_SETDESTMACADDRESS pfnASFSetDestMACAddress; - PFN_ADAPTER_ASF_GETSOURCEMACADDRESS pfnASFGetSourceMACAddress; - PFN_ADAPTER_ASF_ISASFREADY pfnASFIsASFReady; - PFN_ADAPTER_ASF_CHECK_FOR_EEPROM_PRESENCE pfnASFCheckForEepromPresen= ce; -#endif - PFN_ADAPTER_SET_COMMONDATA pfnSetCommonData; - - PFN_ADAPTER_SET_CHECKSUMOFFLOAD pfnSetChecksumOffload; - -} ADAPTER_API, *PADAPTER_API; -////////////////////////////////////////////////////////////////// - -#define MAX_PACKET_TO_ACCUMULATE 16 - -typedef struct _ADAPTER_OPEN_PARAMS -{ - PNV_VOID pOSApi; //pointer to OSAPI structure passed from higher lay= er - PNV_VOID pvHardwareBaseAddress; //memory mapped address passed from = higher layer - NV_UINT32 ulPollInterval; //poll interval in micro seconds. Used in = polling mode - NV_UINT32 MaxDpcLoop; //Maximum number of times we loop to in functi= on ADAPTER_HandleInterrupt - NV_UINT32 MaxRxPkt; //Maximum number of packet we process each time = in function UpdateReceiveDescRingData - NV_UINT32 MaxTxPkt; //Maximum number of packet we process each time = in function UpdateTransmitDescRingData - NV_UINT32 MaxRxPktToAccumulate; //maximum number of rx packet we acc= umulate in UpdateReceiveDescRingData before - //indicating packets to OS. - NV_UINT32 SentPacketStatusSuccess; //Status returned from adapter la= yer to higher layer when packet was sent successfully - NV_UINT32 SentPacketStatusFailure; ////Status returned from adapter = layer to higher layer when packet send was unsuccessful - NV_UINT32 SetForcedModeEveryNthRxPacket; //NOT USED: For experiment = with descriptor based interrupt - NV_UINT32 SetForcedModeEveryNthTxPacket; //NOT USED: For experiment = with descriptor based interrupt - NV_UINT32 RxForcedInterrupt; //NOT USED: For experiment with descrip= tor based interrupt - NV_UINT32 TxForcedInterrupt; //NOT USED: For experiment with descrip= tor based interrupt - NV_UINT32 DeviceId; //Of MAC - NV_UINT32 DeviceType; - NV_UINT32 PollIntervalInusForThroughputMode; //Of MAC - NV_UINT32 bASFEnabled; - NV_UINT32 ulDescriptorVersion; - NV_UINT32 ulMaxPacketSize; - - -#define MEDIA_IF_AUTO 0 -#define MEDIA_IF_RGMII 1 -#define MEDIA_IF_MII 2 - NV_UINT32 ulMediaIF; - - NV_UINT32 PhyPowerIsolationTimeoutInms; - NV_UINT32 PhyResetTimeoutInms; - NV_UINT32 PhyAutonegotiateTimeoutInms; - NV_UINT32 PhyLinkupTimeoutInms; - NV_UINT32 PhyRdWrTimeoutInus; - NV_UINT32 PhyPowerdownOnClose; - - // Added for Bug 100715 - NV_UINT32 bDisableMIIInterruptAndReadPhyStatus; - -}ADAPTER_OPEN_PARAMS, *PADAPTER_OPEN_PARAMS; - -////////////////////////////////////////////////////////////////// -// This is the one function in the adapter interface that is publicly -// available. The rest of the interface is returned in the pAdapterApi. -// The first argument needs to be cast to a OSAPI structure pointer. -// The second argument should be cast to a ADPATER_API structure pointer= =2E -NV_API_CALL NV_SINT32 ADAPTER_Open (PADAPTER_OPEN_PARAMS pAdapterOpenPar= ams, PNV_VOID *pvpAdapterApi, NV_UINT32 *pulPhyAddr); - -////////////////////////////////////////////////////////////////// - - - -////////////////////////////////////////////////////////////////// -// Here are the error codes the adapter function calls return. -#define ADAPTERERR_NONE 0x0000 -#define ADAPTERERR_COULD_NOT_ALLOC_CONTEXT 0x0001 -#define ADAPTERERR_COULD_NOT_CREATE_CONTEXT 0x0002 -#define ADAPTERERR_COULD_NOT_OPEN_PHY 0x0003 -#define ADAPTERERR_TRANSMIT_QUEUE_FULL 0x0004 -#define ADAPTERERR_COULD_NOT_INIT_PHY 0x0005 -#define ADAPTERERR_PHYS_SIZE_SMALL 0x0006 -#define ADAPTERERR_ERROR 0x0007 // Generic e= rror -////////////////////////////////////////////////////////////////// - -// This block moved from myadap.h -// nFlag for Stop/Start ReceiverAndOrTransmitter can be an OR of -// the following two flags -#define AFFECT_RECEIVER 0x01 -#define AFFECT_TRANSMITTER 0x02 - -#define REDUCE_LENGTH_BY 48 - -#define EXTRA_WRITE_SLOT_TO_REDUCE_PER_SEND 4 -#define MAX_TX_DESCS 256=20 -#define MAX_TX_DESCS_VER2 (256 * 4) - -typedef struct _TX_INFO_ADAP -{ - NV_UINT32 NoOfDesc;=20 - PNV_VOID pvVar2;=20 -}TX_INFO_ADAP, *PTX_INFO_ADAP; - -#define WORKAROUND_FOR_MCP3_TX_STALL - -#ifdef WORKAROUND_FOR_MCP3_TX_STALL -NV_SINT32 ADAPTER_WorkaroundTXHang(PNV_VOID pvContext); -#endif - -//#define TRACK_INIT_TIME - -#ifdef TRACK_INIT_TIME -//This routine is defined in entry.c adapter doesn't link int64.lib -//We defined here so that its easy to use it in phy as well as mswin - -#define MAX_PRINT_INDEX 32 -extern NV_VOID PrintTime(NV_UINT32 ulIndex); -#define PRINT_INIT_TIME(_a) PrintTime((_a)) -#else -#define PRINT_INIT_TIME(_a) -#endif - -// Segmentation offload info -#define DEVCAPS_SEGOL_BP_ENABLE 0 =20 -#define DEVCAPS_SEGOL_BP_IPOPTIONS 1 -#define DEVCAPS_SEGOL_BP_TCPOPTIONS 2 -#define DEVCAPS_SEGOL_BP_SEGSIZE_LO 8 -#define DEVCAPS_SEGOL_BP_SEGSIZE_HI 31 - - -// Checksum offload info -// Byte 0 : V4 TX -#define DEVCAPS_V4_TX_BP_IPOPTIONS 0 -#define DEVCAPS_V4_TX_BP_TCPOPTIONS 1 -#define DEVCAPS_V4_TX_BP_TCPCHECKSUM 2 -#define DEVCAPS_V4_TX_BP_UDPCHECKSUM 3 -#define DEVCAPS_V4_TX_BP_IPCHECKSUM 4 - -// Byte 0 : V4 RX -#define DEVCAPS_V4_RX_BP_IPOPTIONS 8 -#define DEVCAPS_V4_RX_BP_TCPOPTIONS 9 -#define DEVCAPS_V4_RX_BP_TCPCHECKSUM 10 -#define DEVCAPS_V4_RX_BP_UDPCHECKSUM 11 -#define DEVCAPS_V4_RX_BP_IPCHECKSUM 12 - -// Byte 1 : V6 TX -#define DEVCAPS_V6_TX_BP_IPOPTIONS 16 -#define DEVCAPS_V6_TX_BP_TCPOPTIONS 17 -#define DEVCAPS_V6_TX_BP_TCPCHECKSUM 18 -#define DEVCAPS_V6_TX_BP_UDPCHECKSUM 19 - -// Byte 2 : V6 RX -#define DEVCAPS_V6_RX_BP_IPOPTIONS 24 -#define DEVCAPS_V6_RX_BP_TCPOPTIONS 25 -#define DEVCAPS_V6_RX_BP_TCPCHECKSUM 26 -#define DEVCAPS_V6_RX_BP_UDPCHECKSUM 27 - - -#define DESCR_VER_1 1 // MCP1, MCP2 and CK8 descriptor ver= sion -#define DESCR_VER_2 2 // The decsriptor structure for CK8G= - -// Get device and vendor IDs from 32 bit DeviceVendorID=20 -#define GET_DEVICEID(x) (((x) >> 16) & 0xFFFF) -#define GET_VENDORID(x) ((x) & 0xFFFF) - -#ifdef __cplusplus -} // extern "C" -#endif - -#endif // _ADAPTER_H_ Index: sys/contrib/dev/nve/amd64/nvenetlib.README =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/amd64/nvenetlib.README (revision 261434) +++ sys/contrib/dev/nve/amd64/nvenetlib.README (working copy) @@ -1,52 +0,0 @@ -$FreeBSD$ - -The installation and use of this software is subject to the following li= cense terms and conditions: - -License For Customer Use of NVIDIA Software=20 - -IMPORTANT NOTICE -- READ CAREFULLY: This License For Customer Use of NVI= DIA Software ("LICENSE") is the agreement which governs use of the softwa= re of NVIDIA Corporation and its subsidiaries ("NVIDIA") enclosed herewit= h, including computer software and associated printed materials ("SOFTWAR= E"). By downloading, installing, copying, or otherwise using the SOFTWARE= , you agree to be bound by the terms of this LICENSE. If you do not agree= to the terms of this LICENSE, do not download, install or use the SOFTWA= RE. - -RECITALS -Use of NVIDIA's products requires three elements: the SOFTWARE, the hard= ware on a computer motherboard, and a personal computer. The SOFTWARE is = protected by copyright laws and international copyright treaties, as well= as other intellectual property laws and treaties. The SOFTWARE is not so= ld, and instead is only licensed for use, strictly in accordance with thi= s document. The hardware is protected by various patents, and is sold, bu= t this agreement does not cover that sale, since it may not necessarily b= e sold as a package with the SOFTWARE. This agreement sets forth the term= s and conditions of the SOFTWARE LICENSE only. - -1. DEFINITIONS - -1.1 Customer. Customer means the entity or individual that installs or u= ses the SOFTWARE. - -2. GRANT OF LICENSE - -2.1 Rights and Limitations of Grant. NVIDIA hereby grants Customer the f= ollowing non-exclusive, non-transferable right to use the SOFTWARE, with = the following limitations: - -2.1.1 Rights. Customer may install and use one copy of the SOFTWARE on a= single computer, and except for making one back-up copy of the Software,= may not otherwise copy the SOFTWARE. This LICENSE of SOFTWARE may not be= shared or used concurrently on different computers. - -2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Se= ction 2.1.1, SOFTWARE designed exclusively for use on the Linux operating= system may be copied and redistributed, provided that the binary files t= hereof are not modified in any way (except for uncompressing/compressing = files). SOFTWARE designed exclusively for use on the Linux Operating sys= tem but which has been authorized by NVIDIA for use on the FreeBSD Operat= ing System may also be copied and redistributed, provided that the binary= files thereof are not modified in any way (except for unzipping of compr= essed files). =20 - -2.1.3 Limitations. - -No Reverse Engineering. Customer may not reverse engineer, decompile, or= disassemble the SOFTWARE, nor attempt in any other manner to obtain the = source code.=20 - -No Separation of Components. The SOFTWARE is licensed as a single produc= t. Its component parts may not be separated for use on more than one comp= uter, nor otherwise used separately from the other parts.=20 - -No Rental. Customer may not rent or lease the SOFTWARE to someone else. - -3. TERMINATION - -This LICENSE will automatically terminate if Customer fails to comply wi= th any of the terms and conditions hereof. In such event, Customer must d= estroy all copies of the SOFTWARE and all of its component parts. - -4. COPYRIGHT - -All title and copyrights in and to the SOFTWARE (including but not limit= ed to all images, photographs, animations, video, audio, music, text, and= other information incorporated into the SOFTWARE), the accompanying prin= ted materials, and any copies of the SOFTWARE, are owned by NVIDIA, or it= s suppliers. The SOFTWARE is protected by copyright laws and internationa= l treaty provisions. Accordingly, Customer is required to treat the SOFTW= ARE like any other copyrighted material, except as otherwise allowed purs= uant to this LICENSE and that it may make one copy of the SOFTWARE solely= for backup or archive purposes. - -5. APPLICABLE LAW - -This agreement shall be deemed to have been made in, and shall be constr= ued pursuant to, the laws of the State of California. - -6. DISCLAIMER OF WARRANTIES AND LIMITATION ON LIABILITY - -6.1 No Warranties. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, TH= E SOFTWARE IS PROVIDED "AS IS" AND NVIDIA AND ITS SUPPLIERS DISCLAIM ALL = WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMP= LIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. - -6.2 No Liability for Consequential Damages. TO THE MAXIMUM EXTENT PERMIT= TED BY APPLICABLE LAW, IN NO EVENT SHALL NVIDIA OR ITS SUPPLIERS BE LIABL= E FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOE= VER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,= BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNI= ARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVE= N IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - -7. MISCELLANEOUS=20 - -The United Nations Convention on Contracts for the International Sale of= Goods is specifically disclaimed. If any provision of this LICENSE is in= consistent with, or cannot be fully enforced under, the law, such provisi= on will be construed as limited to the extent necessary to be consistent = with and fully enforceable under the law. This agreement is the final, co= mplete and exclusive agreement between the parties relating to the subjec= t matter hereof, and supersedes all prior or contemporaneous understandin= gs and agreements relating to such subject matter, whether oral or writte= n. Customer agrees that it will not ship, transfer or export the SOFTWARE= into any country, or use the SOFTWARE in any manner, prohibited by the U= nited States Bureau of Export Administration or any export laws, restrict= ions or regulations. This LICENSE may only be modified in writing signed = by an authorized officer of NVIDIA. Index: sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu (revision 261434) +++ sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu (working copy) @@ -1,321 +0,0 @@ -$FreeBSD$ -begin-base64 644 nvenetlib.o.bz2 -QlpoOTFBWSZTWQrVCikAPRD////////////////////////////+////////////////4ETd= fd7c -d6MHt93wvffPbe6vXdzLa8cIHsyiSQRFGCttADntZTtnJu6fPePr3w68929yzVt2NRdTNU96= tIc9 -d7mvXu2213j0vXnq3HbnQJKmZ3KPS6TKa087zr2sraLkE17nW83SZ3ukdDeUTaa7d1PXu7es= iu3t -rr3e7y3noZvY67HZ3Hud21TG9t6edvW7eh1K9vMNbd3mu5d7HN3Hdz3uQ611jbt73g7tyd7c= gaEQ -QAQaGQ0AAAAnoATTCGhoEwGkMyJtTJ6npMU2ak2NTRPNEyankymT0aFPNBlPUbQmp40KY09B= No0M -iaZGFP1TMk21TGgxQaEEABA0mmJkMgCm0E0yZomp7TSp+JT9Mg00GhkTKeNTU9T9TMqZ6m0D= VPDV -PNSbCnqeU81NR6NTxT0g2p6m1NlPKPUzFHqep6nonppPE1DJ6g2p6mgAASmhBBCaU9MmgahP= U8Q1 -PVPaaap6T0yepoaNTepsqfqnlPQIeUAPSGnijTynpNpGmQ0aG1BiNDRpo0D1GgA0DQBtQNDQ= AAAA -BoNASaSRETRNqaaNTDVT9TepphSfplTzTSNqnqem9RR6I8mKemp6MptJg0gflQbUPU9Taank= yn6p -p5MkbU0GRtI0G1MnpNPKNAHqPSaMgAbUHqPUNGg9RoABoKUoY0mGgJgTTRtAR6mGggZMQNPJ= oBqa -ehMABojanojACekeoYAAEwCaZNGAmI0xMmAABMaBMTJhNAxMjEEiRCaAjI0BMmIAAE0p+mk8= IyYQ -Mk9Gk2QJiaabKm09TE2kyJqbyp+mSeo2jKngmp+g1T9NDVD9FHhqQ09pMT0UPFPU9R6mjTZT= 9FB+ -pMnqaAaMj8cNbHfXhnpOTkXgGkNK/vhD8A/12Hw1Z6nyejknO8gemgdwUx5tJVOqFXS2IuRI= CB6W -sa6sR8ALU9KIYMyp5Ca8cQpOFnh8CtGJc/wVzSMxn3TM0LxO89EKoGxDYRmOvPmgpAP2YAVj= EA4u -PXilv5UmS1TIqSZBMyn7EDy2OQPDKW5C0NZEbmGb5UpptetVnXRovTPCk2ywvNs88ND5l61y= wvpz -zej5sqtRR1K1XVM40DJ6+/0EdCbjr113W36yvIYxvhWbHVO1xo3k1K2tUqOwI8xnVKkZFSlr= B6fU -jV7JMQ8KwxrQKGtCNmmsNQbQ3CYmx222hIEMDWty9EC1DuYGPoklZOej6d46KrIiCiBUBmYK= IAWu -q6JwKfa7Kjga5xj7x+JRkYcstIVvfMsSWa2krlGJ0bStroMu0Gn889b6GfNZwDbUfuwIvG1a= x1ny -fm6R5lLW8B6pE2pmHP19zS9Y66C+c+AkhmlXWYeHosFCpmV9FtrXpxplJGgM7nHYN182U3rL= NWtm -wbB7hivbpUcpq9LLRy2Pv17s8rZ7S1RrqtE+pf6bLrcFebTnmWNIyzL1+zx53ZuDFJgbHU8/= lgYD -+CZPU8GakwtSmHVjwruqr8uylfoHC6zV5ytVGzAjq3KnKy6Szn9dMq1beTU6jmNGjHy87VW8= iKtq -G7Gly0+dVSabj3d2wVDPz9BDKIBa8W3iyMpBm+O+Ea6SNdwFajpUX18Px+vxedF+Wq1v2pv8= 7x91 -U52NODaavMzVC3O7GVjxhSNzjt/FqQHyqaksQrb7eP071HUjKtrgP9567Pp7trAbcYGLHhlI= 5SFH -GuXm6ncTZ+f6X8/i9qskGfcpY6SgxHpyVaNn48tyuPVzHMrfs50xOcyz1tpGXaa6VtX+R0pn= 5+26 -llMx0ZHdTQzUFtctNULM1N2NHaXEashVTu1nbKspq+4pluretZlLYVFZCqJa4trT4rCamGE0= euLh -m5WadffpqLol7Uds6qL4niRj52eHmWnRjfDRTOCMeZouaY52OqmA+qc7ZZRkU0Wwap54Khei= N9+R -yENfDz64YJIH1KToX/Pd73R778r5nidzvJt1m9VewvC8JOj3np7XcSHhmh3N/iJYqpPa4dQM= KBZJ -v00UbXwstkIoV5iHKfCpGYjixdngx49eHZ/g3yr7gUncWy2Tz87mVyN/VKaYXeIoMIj3gkLw= fca2 -LnN5rAbL3mkID0GkgR4m47Hi43W7Dl8Xk8TX2PmXEvx+5/bPNJowCEW2JIbEoQgQeCwBCoGC= QGhP -J7C/YVIgbEhI1/C/YmjSBNY5Zq33B9jtpTsDQ8QqkDaEkXGAgypajS4mu29mzy/4y0kHX4uL= yZTv -M7PnwjWsvnqR9Nh93KgNnMiB9M0pf7R2IazCyCQsPp/k9TOeZ9vh7nxHbt2aJc2ClFLUKMj1= zDia -E9Ku0Ch34w/A43Gpu0oiyU4ZHJpPq3b3MFoBeD4PDY2myPpWeW+lXwBlnyPQ9Ljum3J2iYiL= F5RF -IMRaRuxxojCYcSIQF+lB26wwdrIQYDFz7j6ux7mjijU0Nhjw0r7/4Ifv9nf6t2nLz2+Vsvaa= 2oyp -E/V0e6mTp3fCuUZi8IbuDREeTOvDsf0VnJq3H55gsoelZ1htaCZ7LxOLY6gYyIUQ2m26Igzu= rjlp -pOBwbDTphRDKOkLkvS+1+X1vN7d1WTgwk2H1nWzmWFmoHKhIFBGKFJhnNyfRuLMiERuDlPvK= n9Sa -BB+17ISbZaIoVE8D0nIH+Kn+P+Ptv/6xs89tM1ICqMVEIvpiD33F80QjuGl/S0tSw1jEH6a+= k5lN -c1uYBHOtwt9stxLojQ8rUYoDtoAX2YzKVa+hIiuXWa/cQGQe7ZeBoPtS0tZpqJJFXSDpQ4AI= 3a69 -9xIx+T09ATawPJypyaEVScAcelb5+g1879ODevuaNuGxY6pBo2NJAN/tc439fQ7rzdG5FX6m= +EPy -p/0HuWiKsOVFA1bzDNIkr51lpqR3aP0RPYFs0uLHYP5HT6xRGDuLGVRX7jvn0rItFEIdek05= ZmYr -orhnFoODYPUGAhgDBXFzHrwP7L393jGHDmoy+p+DMdRmkgkUExKrFQMrpmHh2knI6OuUwcs6= e5i3 -twxOK7VaoDFKRaK3DdzntW2B/QfYW/91t1S1N8Bm7ITbpyVG/JHIQ3FZ61N9Rr9v1uglLavb= A7HG -rEibkIOg7Nn3u3DNCY4eVIqv+L4WFUBlLET5AH1B0+kzFevdx81yvQIds8IhSMhu5kKEerA5= kjmw -2m/I2UOoLMqBJJQtYEykJFI45AmBfXDuXHKVWtPmOLhFnNB1XSknfV6mTtDXyKWBCpoeVAtP= Og7h -emo+zv5STSON44m6+4dMfX9ESCI93R4/Q9rI50H2PQ9dj1N7uKZTjL0WnHQgPOf661q7Xnue= d6mP -7cHcqc8/wm+tNW9r1IftexRYl9m27dnlnrdvDH4n53N/Xiq8inNPTvN9uHCnZ9J2QgyFBPzD= ExPH -LObAhU9hqwWi0F0yRM2ujvbZFsJcAH+dRByXXvGZILGagUKJIG7AEywCV46sIEDHUxoBBZJB= RYBB -I4UoASHEYQ4fB93gTcScLeHCyASxhIFfq0lQwyYTITMsClAeK+m6PmP1pbViWo5JcTbEpmiS= iYVI -gdNM6tGpnCgzZICtrEz3GFRVKu2OpWHvealykPStq1axao8VvV6Es96VKzBa14eo9JvSiiHe= 1073 -o73FWz1uzXTGCYCUwQJjoMoyTiawMkUwZD4rjBgg6proUhrVOibcmwZbqIzZkmyaQ0wnyOcs= htty -5wQhp4MpsWFWDyM2ciWbWfKpSa2HP6t0fXJeOxmccyPQvEE2HW+GCIKgwS0ilLTdmrYdDmd7= XhqQ -U1w54BSjghgIBxTDNyw9ZybZDdCQWQ4JCOFGsZCKffRMK5wiulJpE0RCFJIwRCpwulqsHioB= QgHB -B8Yh0YCY56DFMN8hYzUMYXvDvbKpmVdhDCZEJjUgHWmbwS45QTCkdtIUlaiIvFleGqFc3U0W= lNth -0ZJovIk20XyqU3pJRGBN2EOCLG5cFEpFR2GuhlR8q2kmEUQQJIRURZ6TMcLsutmCYVREIyaK= jCYn -StArCs4uw73im2pIGzCpDWWE0vGhR5d7g6tM1cTBXhNXRKaMmTk2jwutOCQm/E2QmorCHqO0= Xszi -avmniHvsYwYiXrk5CsoELKIYhGyslAzJYjrYeAbQfowYTsqxIssJxRYPg/eQ4xQ6KERO5T6V= hycb -DtS13xcr2mimCCqmtsw5eYuDZWbbmQUNqaMNkeDjStA1FpcsQWDajC1a3h1SXmRwgRgSDlLu= KlmG -HxJ4aCsWpKELB6WYYrDVweyCHKG+a21NsMpdTSG+FhZhWau+cFmmWWzfNk0M3peExhtjhQ4C= GXcw -Nt5QZqmsCo/dsmGXVuG+ZhhEzTNEJ1EmkMZC9B62+pmyUIFVJy2WSN49DY22YS5blKMikUKq= +8tG -cNqc1sqHFDh3J1cOCCXHzOBgQF0NnleGZtCHTUQ+AxSGdi0QHTVeqGoUiGBslSRz9V3Ylirl= U1XE -4zQsRV4FSGZIYiX0TWBskx1awkcusEM8dGC4iVvShncYYLHkpAJuIUN7TeRS8toGtb4rCWIf= X+m0 -eo4UIeFo9z/x19MZqYDIDGSH1TKyQFIMJOVhCT2X2HD7O4l+TtAkCHw0GhDMDNo1HAhzS4Nm= kgEm -LKy9OVoEDTBpmQkhiQIf938Pk7zDiw3GH4bJOuJJ10hPFYsJ8BCTodp77hybSEA82ni6bJzJ= MarA -VVhOi9hMSHBUh+tYH25qqQ4oUZ2d/0npejxf4mVIvNIDswaD1hiLTbENoVtgENBjtQxsRYXb= WiOr -cuNdlxmQqaOycjtYsffl+Fzx5U01x235bR4NmizXkaOKg6JhhIhek0Z+XAAfFYAbp2Giwk0w= bGIP -9GVm28W9T7ZgZuS4wshNGi0XGgWGmBVsBKlnUaqCpiNy0CEfnGkkSYC6NySH2QCBDEkJ2yRQ= qQkL -5yiwgYkmlqmCk0WJOEgLTQFDEI7JovYv5JCp0+gbu1uEeRpPHn9vKmdVxeRhCNBx1D3hg5Fp= fRIa -kAk0OulGcEn0SBiiTtmecQO9ZCHZYCgFDHb/2yX5se1jSjBQFhttoFrWHFzuJsOoopZwnisW= yZvO -22yAGyAYhRANMhi23936Ew2Z+J+k8TITgk+bJz1V8rwfI2t0TZVfhMmyFcX1tNRh7ZTayGfP= Ho0y -E6Dx8WrISFFYSHTeo4h5lwQUJMQA3YQh55hCpICkCLDGHjM6KGK4gVKlVK1VUVD6HurDFRZF= FCKK -ioKs6DKncNRUZDzyTkYEPGTSqybjJ3KY+qjJP6LCYikgcGEKr914frvPBqbCpFRUHsNHY22q= ammE -4CjJUh0mTt0IddD2iQx75ANkA8nmsOLAlfi9O9AjIBOoAgdSghAEhkCBkZDqDNd7SdvCPvoP= a4yu -j9n3dz+Fzuu5Peu3iJQlUbuO953/D/WX5z3/X7Fz1jH6CQlH9hI5PDmauSxKWy6p5ldxk+zs= 6778 -SalUhxZWZkg1jiLDdXdrlP4iXca7i9J87mptlq73P/UgwPP5EI650Dr4BEpiiJRggZggRpCK= CigG -fidmnjGxfVT1cfL/p6z46TaOHCzDH9gawVQtLkAUCPT4r7XXyfUswTxqU8NzeKi1qLxDFD51= 3B2f -E415Y7fF3XpZjt+THvg7EfBKCGCDGDbgULLSVUP++AqaGnbZ37YiPAMFRBQA+pB8+Hs9p7OR= wObz -X/4/w/m5vN5+YzPgdH3JCFg6tDrp4QAs2Ze7Zb7GR5uvA93E6F/wx9gn3DkH427UP7/uoPh0= +mAh -iVUjckjjFUxddg/z5Pf/kbr3MRQutVfh2IO/nYH790xRnISLwnL6l6LF7iderlSrt0Dt5fiU= 2e4W -T8H4qvkNyWUylxbxY0a2traXqLWbA084CIXhkQAnTBAFGlGPYA8c+hseP4tYeNXAmt3HPF+I= 9Ned -T2FAFNDLBRh/rV6M/KquxHzZQni6tKQ4dVrrrdYYfNg8qhQCGSwcd0ezIgmqkVvqQrg2qoHb= rMOU -hl0kiCC/lQDAyR+12FDUiBBVqQEeqEn+lzkWN98/cUnEzHLy/m/jze88rP3e0f/V+zlVHNta= WR96 -0p4XAme+oPL3eB3CmWVtMstN8z2N18u94Xh6vxJ6kIgn8dllZRtoVLG2QoiJI++AsCsBRGAi= QYkF -iMiHvxAmTILMzIADrwYyTBEpYQ7lFd14XAzfp6TkSGLzPCf20e+e2atpb5V3bNelkOVcP4dh= 8rxg -MjwEJk1c7ax/F7K1nXld+Kzh0un9GN+PObzSaNlw6dOm44pJJ556VKeeeenTqXP9N9+j9KwO= ycA+ -jy3j4Wq6D5iZLoAAL2vTQgRCgaQkdzzOaElzWTceOQAvstJLo/UYcyQlNqHXiSB5kz8ivqDR= 9miV -gMaZmbYNNaspxzgx7ph7hpJUspGkBv2C3AzsH31jv6JEYxhpDvqI5mV1zy3NQ6bBAlyjZxkv= Cnko -Ysdqrr6ZHNaMsyIAAIQKYgIQ8UQEAAgOEJQXBZkALoCBB0F1Z5jYX5xt0ex57koW9nerLdUe= CUji -EL4wNGGPXBCFdApWKq5B+ORiIwWSZBolLFCxQjrhkBhJB7bMTmyioJAE8KhxFQYXLWydSGQ0= K7jF -6xk8DxXqSglx21zlP45WyG79/o/qnvC8/2eZ6O4nhJfFSrjXzWBps4aJWCvK0i+rg7pYN8GA= 0O3H -rVu300YGnIrsofBKs7VQw3n4Kb+vN4B8wWSMvU1oih8d2WRlSwXMxgOFTFUKHKykBMHRJ1U7= sIpy -vKwGNN4LhKUEoRRh2CR11aO515zACYWJm1gc5TrLHYTsyS3n0lRnQ+FzmVHN+bO0ZucACNJI= lOuE -LLj1qv4cNV4XYQONl01T2krVkMO4lUUOpjVnrN205GRYya8slWSxiC6T8PrFvWbLlGh0IEhn= Ycsj -mGFQMYPY/JMMSHthkKJESIiJEVFFg/L+euEYkNIWMnJaAoB+jEP0BSGTb6fWtbG53NpD7bpG= tAGh -NhpoTMYKPk2sVFEe7tzMmfVItO76sPpCyB9AfU025ucOczoy31ORozsEa9lmwcDIdkS/cjgO= kgTI -EZM99H9wZiGikrBFRUQVVU9qdDvve57Tr56CpnLuktMpS20QDuzv0iUDTLyXalhnTMHaRqHo= 4XaT -/aZLmYAyoz2fBqCA0NCMIkdHWymNm0oKIEaJcumlZiQ08kLzm09TweL5Vp8P3fuz0lBmr1Be= E4Op -TvrCquWFC+DHSmTHYNquMxgpI0BZaVwg+YJJ0ohBoiTKcKmglnoP1zeSQ7JJIyTbmj57uK9g= E90K -MGENQrnGsA5W+/9dzd25wL6+ZJYm7i4bQwwBiXD/86tu8K0Su/zGXB7MhBAb9wMT23Bjwrpx= KqrF -No/Dl5sxK+wYIBXGQ/GJDK0hzsAPhPF6sUJKLi9rsQpVeJXF2gxyecYjq94o99SIr9mnl3bb= d0QD -7MgGFhxeBVT9jNDcFgQfgboi5jH/gtw5S2sr4a0LSCv9hojDmVIJCvmMU07IoDNyiNkmUDIP= ZGoK -onY1Nk+ikSwwfWgSrsB8BDlrGz0VzaPpACg3ed2m+pdCyM6QvgHSjuw+voUDWV07Ua/47XH7= mS5X -qe7urrqqmxfvpuBqtlmNBnq6glpSixcPKJ/LjW1u6klpU3tnBcp4lTDq0Vqlaii/XEkN4LWO= dRMa -qGtkrUKDPztqaZaoH8GWge86cVmpgAsav0uqX16JfzQu7sjMfAFoD7FAfSD3YgKZIA1P/n3w= AxgB -QNDjtR24oL78PDUAsnNrYGDcxK+ioH8OQY55DMyXsvecDP4FnMNv0oAbM7BrEA17McNf8/df= U6f7 -/T76++Sc/z2tFNMyEyBv8odfOx9gzp1AMAYNBYyj0WRiVfoIANh/oZnPG0Xw6sKX6g8i6wqU= 8sas -TGdm2oTaQ0thgD56QwJxtszvGR1/k7bsQ2+26A1g9/dSho5QxJd2woXLyl2xPdGvpg3bCo30= 12tS -DgMWttFRILkrFgnZS400VK43bEUhbalRH/ZnAZJNBymYl2whokvU1WV0uuyy+jLN7r/t2zsW= xAAy -tROfw7/H9L353b/p+i9dgp+uQh75kKI4RlKiZQRQiTGtNUoU0VQBQkbKxCW66Xz5L3j2LrSW= y9nK -7QXJCV1MLCiQiemEsLYxpKHdxszd83Leo7A3FtT4v4M/u8Wu8rQuhWVqdr2HG95tqQe3lh72= TE8J -6HplFoJlB5I1+PCXVZVTZMb/5Aoh+3fMqALzgYQNPaoKy3uwOc0dbA3uYAFtgLJ4N2L3QjB7= PiNW -huAiAOmVcVyyhkXk1jhdkV9kzbj7T2sGkL+W8pbwZURQuD1kwoQ0zhgaoe+0bfoNEIlQdUdq= ECQq -58m0Ico4T4+Mn3SpBNrcsue7pkP6tNUa2xI0XnSILmoI1pItTM8w4prSCrMpK5nJ5fE43cUo= DTiI -X4hNYF9xu4k5xmHvbEO/8fjedemeMj6LZ6jpux8XD3u5IFoQgZ9nGGmAtJxB6fqKHxjHiCd/= f6wm -AoA9t2D5Q9geMDQNMjkvJxsXLuZyZVwqSYwcjdzHbcIpoKE1MyyhIGcgY4F6kIiGwEyqrqJ0= CexW -wy0ZhCNAAgRIQ6uHeTdbWvP1frvup97PO0SY8SurriwmAACnDIWona0YYWHpNGU1vnjZubRA= H+5q -jOmqHqRwUQPR0PE/DM4G6rfI2vg6CeH4BMPMXY9rFiHF7SGKdDBmHBDCOSYbxH+fWyAjQW8i= asRu -PlVB2+qhYdE84klpDFpNBDVv2kuSOdofFGA0ZBRzwVIqsjWtLp7+DAsbYS43cKprcCZwZJt7= G2J1 -/gfG0QPMZ/TwXUImstrk8WZAmZUGZkwytdqGEsafOYECcwM3nPajQawN5Iz4KmrwAofRXGZI= Hv1w -tdWpWnlaNvY5r8Xh92cLswL1Q4OTdoIBMIvLNLQQSDshBB3yDhrW+gRw3TUnAPzBvJuRA42S= xixB -xZjdoNki1WanR4PA7McDBY4FxkI096UKiUWbhdpf39hF0XfTFbpr6j0E5NUDN6FAxnq2lqKl= kaUD -UBAOfRih8ZvxTCvmaGSls2jV+GzqZVmiqon8hkUHgIXlT7j/X0XJkbBMbFXY/y9lxoqjUzxr= zrNU -oRxkzo0S5imjQ7RQc257+AB0xOv3LDDCYCPkQM90t88CUXKcKNvlXx6ZS8v3pRdoNHlK0oqj= Nh5H -RluxMjTfHpU/5MLB76zcG2MUILjwEegxXaOSrcsPuduxsM2MasdMEVDYNqYQEhAejwEiHh0a= DZHb -Q+oohXahA7ky71UDBCUcdXw5CV55+sht1NFUlR2oO5ZpqcImeeUYJYyxghNmZgaFAZnRy84k= Hl/j -5P/zzKBUnauwfyFrMae8wYnODGpbkIbS6aD/W0HNGvgeP2BJeLEZjLDVka8fyA+EF0ulBjuw= SLun -6qjvZ1uOiYyIaVe8vCAh7/Lpt4a0E8OxmIVuoZ5QyedgHOARkQCQv0SMbPV2UfvxOpbTAeLI= 81nu -/dQjh02KzDGgiYeNKbMdqBCv5LmjjMDLHKgZbOfiU31PRNnF153M17E+hrkr09tFZ65M3pep= y84j -2qemyyIgqiqrOm+R298cjyPhYDSHZGQIqsOVGsiY8EIb7WjulNGfg6EMcBOEXbiF20u2J6ld= 8zUU -UPY6ajrd/4u0ERgymdJwwiE8YtDgI+/AoNWsOfgeqQ9gT6BZAIrcu9Cau1drTpPBNfY77qDm= 5bm4 -WM8aAQCs/WGl5k+wcca/GcCQ+QB6KgPNtsI2g9D+bv5q/ca5DklMQESQveEQBgjMiMW3W9nb= b4bk -eYKAac9eSUR3uedgb66R7qncMVHEztj9Zc8p4x0zUqrUi6Ws7VbtkQTzjNYuinYgDvyLQt7h= X/iL -kvxNeexSavhuS0anU7frBbPMhCkbKkiP2fcwKTW3ZXU6OFcjiTOTV8u+BHMDuvR5FWYEVZFW= H7rs -D2fm/e+Z65KexNQbx97jIFD6mMNIHrRNa9RzTedmcJpuJTaLPNgxMDChrRylE1xNUSMGw1Zq= OG71 -JcYzjs2uPRLiRGzMUsXw+PKe7qLG0+a74qWMcT1iYH3LdtG7EwGhEHnuIeh5UmFDDo4qOsDa= 4okS -lZh8vuc0b/oGGZW6VMKUQ5JO4+96BiMf724iITU9nJCslSKGWmYzHjx97mHRv6FkoOidX9Ew= uTW1 -K+zuaPcR4H5C3ULdUxFEXu9U5pJWdT5j1GhofRrQB4iD6DWlv+pguHjJEHAYFOZGdjunx6EL= qRLB -QEUO7cO2nUkk+dZYWDgQd6532Nf751I5V6qvI5ebo81jalDozeeYNuUPWpNhLIbewy5ALI/U= 1pCn -0kfIhxQKHkib7tlL9CmchpJceR2wpjStdmR2MnFz6g6BhDGMJwQs4RokySHydrZ+owMGplZO= S7oy -aE2TRNIIlh3aa9BSiJvcRJBmrRZEgxRNsm5bKb66Et3iIzfabqW1zMqznTWxTiNWF3Tjg6es= WEPU -fABPAkPk4Y1FlYnEVe0ANs4KBEVFyQcdPsyVMRBTguGOyipGhUFqST3HZje1WIDfIDQIdMMh= Bp6F -IJX06MWEQnD8Zbth94LOv3GYE7YxljxaT8B0NG4I+MxALGe1ETHxGa/5VXa3I4QeYMcKzLbG= KToB -HHH5ALcBurgMyNAm0H4cW0DfggnMuSWFoXL1Sblh6NMyPbRPjYDAci/oBckAKiqNZLMcM4kq= 4YLO -E+ECiIzxS39oRAOJpgookd2eg4yJwAo8SEhEGRk7iXeyFyRMA7Mw1Q8urx9RbN4yaC3BtNNM= tO5+ -YvBUvgJZKcmWWliV0p6pRv/P7mKbth7Y5CySwEz8rkrlO5NEF+JxI5+FD5rVaC3WnsSv+0V5= PRXD -wvgs9m3b/LrbXjv1TEgUMcUvnk6UpM0KCRvz0Clb17cPVzehAwYSQfWz43g54m9ejMxMq4ko= z90M -LrWNQQSJ+tvYUjVjhFuHUir5E6JoGxbKg2NuOXzu0GyFjAsYZ7vMXkljfBXEjHtK4XOX6Y6P= jy/H -U2KuH16+0xoYAtnKlzBvAkhF/pPU+Yid8KvgbngTL9CzThqWxETqvxfVTWxchdt8yMUQiR3i= 8Bh7 -E1VS8esn/thP5LjjHK8z1VDo1L5QGHdz7lT7CLQ/mbJ3/YCCI2HvnbToxxvKtHD2mIi0BtdO= qQBQ -GuMckKk4KAP4SF3K59tLyaPrEj0+aTJCMH2/NJnYgDOr4b7E1HuurVrdbziG+LVo76xSDU3m= WDwC -NsPfntiPlpjN9BkTeGFGY1YUERHYRPYVxxotKAbQrAYXfRFhQnZnj7VSlKb5BirECTlB5vp7= KxDY -rTkxFEe6c/HM/N6/9rTwQ7FDMCKQeeII9WIP7wf6fTpWaEUDt7VIFT9ZiBAPhAXEyAvXuQ79= oYhA -Wkdr9SKgT8RGMCQZWxKhyAVU63LoZt8AQFLxbX6K7tpGHLxIUiOsCBnQ8IIPQ8vOK25EGNUI= 8COk -/3PQ3Pjyuup4DZjS7xwGP/NxZbwPNryHFP9LwUbQyxLB9XyIZALMgW7FMLog3eXDIREJKylk= gw1H -bFXgSpDLLio1ibAbNaM01Ep4DTkfDMg3Y+EG9ImMhTO3KUcgonrUIwSN3hys7t7K71/vfWMr= jycJ -w5UOy6lG6FD6rbLkYHjNVuKxc+nlrwdmBjAa6kDoS8u6UIR2nwzKzUbwowuUBmUrpK5XTjZL= winj -DBv/gwfad05MGRVICD1CG9EcSCmd4ZSbWkRk5l0sA++skFer6g/XOu6IbJ7vCPM+RyXX5DTt= wII4 -q/LvXRDlcXEqM435Dir1XYej4wpYrgcHH60xr9iJqeouyQkEpQSGHy7J1oSOIi51OAXfpHJA= PepL -7HYcXbXKwx9pY3Z3L+7wiOxvRZQCfDQC+ye/Fb+HTIm8lkvyw/DJkpTiEFFNjj19uD+wl8Up= 62GH -SqektRUp4Z/HgYLousRevjKY91z4irFrKlJrLFECTJCQj6YGDji60GAMiIunxSBDKjvBd70d= 595f -VsvP186ng9TvJD6Gm5cVFCHAa6J9ToJT8/v/eCxI28b8o88W9XWZ1GvQY7fMXtSNJrX9kGBV= KLXa -4HmwjQm8HoBVwB24YFOuUrZM9pIPWkScSPhqguk8JMJpmms1x8qv0iXAoznlMNczScfHhEMb= P5wY -YnkfN8yDFDLpPxtfrHjEeFEMYw9481o+EybVcF7QKvgTD3fMCnkGjRkp5mcSJc304djWK47z= jfyK -Xw4srDNYo6f8HsG4y2DKWZH5UYZnMZAzLej17Ch1cTv8TkV4h6dAB7orSPw7wIU6YjI0sXz+= 0YdX -UFzG+fTjbuksGbEDZbYlKUJRyvSJJz3tHP8rDU2PjRCHTKKiy82zE0xqqx87DtByUsn8Rrsr= zO85 -3OSaWQdRWglR3euIURViyKLIL1AOvCekCbeBDv18/T4WrPC+IXt00vvHrxb4ly+8dRQS9GIF= +zjw -cNhogxe0GbzD/MDbPtUouCdKIYhx0eN6uv2/uf3Oj5/3yzsD7jX+810MbhTMr7rW30Z9H5d9= ed3J -4Z4atIh2J58Fpk904+dYYNFCzpAEYUoh8T3zQlirQDab3fDIzzM8LQGZgWR0AFVLGga1Nm5r= y7Ve -S3TsUCzBiI2Wim2rloQsinfXbWhcwy5KmG10xOQ9no/S/kJ3fbAcENfEgQbwgAXh/2ArStq7= bGZN -LMH5gTHItD9uW9be+h2Ib1B1+n6w1C/PdCSQqsS6D361WgruadS11WWQdwtN/3X31OTA3+Kg= lMpx -TkdvquMjk7mNwdBESI9kWaylFINUh0vTwprs3QwkFklLpqlpmghppGeoa9iU0jocMbBvkHcX= Pqdd -6X4PCReq8rBWaQCHb4xC2658KXbEWiz0KEJRJfsM+GFmImOiHCIAEdwNaK4DR0F0u37/ZszG= m2So -7SRP1w9hvBebqKPT8naAl8P7xQj9XAGXh2rkDlLazWQZBHt/pbnu2uO+MZ95uiZaPtExdI79= fnFF -PNVTr9NyhhmV6T6/2vSOVknVhDqH6Ymdtx0It6ftfnf6dZ85luv+KR9/78HdN3UF1gv2hmPZ= yxq0 -DNnNuEfylpZupZYGJ4KxeK+SCJTXPSe9gMUDSC7dkIQMnjrvePwdmqAyipJoT6L8zclJAxmv= +X6h -8bjKQkbIP36jE8gi0eCXpLPvNrrB7TtMwpJTHpS2PhR7HRIWJKXN9OiTmWXDKv8PFCeDlaC3= dsR3 -JGR2Z9bHd7IvT7qZSsCXCXHITQoHO+h1EtCHUMmhQ/vbbHFwtvn9QfV6fL6zQV/JQdh81QrA= WAsj -6+hXEPdpNJ3LNkOiwM9SMBQUbVEhCQCj5L6yxAdIxTBjb4UOZI5SP42aV4ce/MON0zA5eQHK= hFNl -X+7cGya067Xhm1GFlKqo9vn4HTeJx9aSwBQZh8qugVL8lrxEwx2LWsSW9MGhr3NGKHhDIDCy= v0km -YhZFJC+X9NH4kK2MKSTT0SyCzWGBYWKROls46dhJDIvKyfBUQXHGkE/g85AC/ytBrO9wxe7a= P4ga -CI7VvfEYYXSHVmJxtIv1IOBOvnk+vys0//Y9FFURlgdDoUEl6zkOik0WIPs29iY3i0H47z2R= yhP5 -rs7UZns8+6jj7PmXVUsPgCBpPw1O5PBaWItD48s/AB0v+OtByZEkEfnIUOV7rg7U9We1D+wV= y5vk -dRApWCrYGOuqB4MmMz6BF0rlD3dsJBmXkwl8knGWBEZEDOExypgNO6iafwZfeq02gBahcfvW= /qWv -EXqWxNKTP2ccKNwt0GiK90apc1w4NMITLD19KqUetjRYWmGa0GLhzSFvDaU8sWPY3sTDIiuc= 51W4 -Dg+y0lmQLiaVEd2+x/8QvS+nHCe/+m4ynk9grJnE0d7mG1Nsb2juXe5wR5LL7s7JHNIgkuPj= ORQu -JyRKSA4W8QRzvPBED4z2AXUyLDkxe8tTS7gw2LWcw+PtypbofOKads1SwuoYTxI7slAUtd5u= o1DO -bzYqdl92mfIKapUGftdhNB3o1aHI4cG9Ghb8GJM2YyEpRkSUnIYE5frWuDdpDSYcn1dnVMxn= 1b+T -8mCiG7bQA+q6Z6ZLi9lvdbfBzidkZyvJmKWJeCU2YoAJwc98Q0u9nFAiyPg0Oj3UrJzMoufE= SsX1 -iB1s26dDZDMRyqHnvc7YquzD9gnvOP7TxjyvRUt3KVV+oPYWS1may0LSl6nTgdUPO+hhkzM7= sUF7 -hC96vOXsdb0M7CmBcQrbDF/4moezQH/YqZ153yTHDnRDrX/Du+g1d9ZvC8Yf0B7Egs1g3YcR= 4MAZ -yOM8phIlejWKOPfDkOFsl57IGNC1BuFhYDUn98OABR7Q0LyDD7cic7rkdNkhhGB+s7Sf0QUC= wNQg -QzQWWJKdkybVIdQEqHVe0O+qjV+KhDIwgscKgEnpHQovAynj8mp+Fj0oOB632dL/56MvJC1d= RMnJ -vNwHAEP97KD7rnD/H4UCyB0hYDVcymJJWCn8v+Vk0aII61rJpKhSvEPSc+3eX78ZPTpuHe+q= fANi -tVsXC95K1Y8F9qPpmdc5D7oatnwDtv2p9vcIClnSPb+Y2z2z6eK8r7R172hTev4ND35zcy5w= tOV1 -1Ns+2+5OBY4Ph8K3i8B/NXB5nuTe3vCOi5ZFUZRn8FdtD9NEaAcvVKIMKNHupQyLDhqdbc6o= G9yE -Qy2+3YnSWE2SQaJKyk9sKAvhfjMjxZIazH6zM0WFhh2UpltBXCPHWyQkP0+37fJgB4P4SUly= b4hd -mRldooON9syTENGft4YS/lLdu6OORFBj8X3Cb5bNA0iD65dL1Z4G1HljXZXN6/Wcu3M0spIx= CkZO -XlLNOrMtGc2am5qbIaFggPJUCxaVxTbkkitivXQtInYDhbDh4SoMxOzxSfqmAaMrwoGPiuXs= U4Q4 -FIgUr/IKK+GqX6bBUYBrYwFYfhpii0Ock1wLeiAocBDmCpze6vhfYgxRhH6CJBtt1UIAF0ok= e/QT -92YWznEX0mV5mKomVw2AF12N/RqrFXTQLSo/PJ6YtuYMzBHfGRDQmJkwcnVc35kw+ZhLzAyl= u/uH -IMiY23olNU6N0RBnxu9Kqp9C34729gM/Xq/q+6hDAljFx0PTCiq7cQylhYGAoGRGXqoSyMEL= kELc -gARkQKHyoghv+hMzIYmCqXNft0VB/v6+up6v4YPPM8IRLfuNMg4aDNQv3pOBK/2TEjZsJLZe= X6Yw -ewoS8SZ+oUdjIqlFkGAzwYNOaBgRaLFctZiqg61gKww4vXfJKMNmDa2MK6xgFkmBqop0Iaxi= MAbz -JZV0bGIRCLSr3acmXrIXqmA4ZiuZo6LNYcuPtridx9R9YEQrLZMjmUIrEVvP9X7d64D/xGWv= jMn0 -+Dxkub9/HiHpUeJFE8PT3TwkeG7oLOcgVln25z/iuu0nmA+Xw9Jk8B831QQViRF01V4HhyQL= aJYX -RoS09bYb7T/xoQWkkmaV6RIY3/xLaosBdoJDzX0FgcDhOH8ierEVTwKUVUYLIi8fm/O+P8w3= 3jBV -BQWfO8cwnX/jM8lXtFhDq/OT5h5R7HAGRm5r6LLnNyZIctLxAkUtGdSBLw1XKg1KLTF7ig/r= 6EF/ -1vTw7bbRyf0t2DUhf5hDaOXnaTgleOMg1SJfV+iqvROXwENGpMXV2Tt79st0+smySUKllovu= Z1OK -Qa8u84QgZpY42fjY/lxNA+vbwnxaXYhj+fNi+5E8BEHAKCLCARRK4ty7CqLG4+lon1+usBat= NJvI -ypq/tFtw22/TOlagGOkKbIjLLSY3MxMbDr0SUB2hSGJk6pd7adoMufdF7MaJRGCzCmPQBmsF= G/lz -xyba197riVAM2RYjXogphLZ5ZNoMpImsKeXbLSVaxgodRdi2BByok1Cchhe0O+5ZOMOQ5Vmd= UP2R -9cL1CyUUcGtFDMwcGA6Dhysier5IlNzC4mYaYHVg+J3oY7tQwFbxlWhLZbZe3gcpUXTXd0v5= DCdI -3WTlbhn9/lIOB5zagNoRCDrMLvlctCRcZRE0oLMqY2wuMqH0ya1/JwvbU3Mn6r9jQ4Ifc/hW= fI+4 -rB+PrFAKo0dcP3Fe7LzEnQsPJBJo+KfxeZK/olCjjIzMxBNOicYGQB4KBzTc9B6veR86JSvy= g4Dl -wDHx7zHi+vatDFdyKvL1qFnzLeKqjUBwPaUGGPqZ5QpSOT7+Rm1Cmh3OTYxGf0POA42FW5Ve= Zm9o -QKUwZyyJCn31yRERZzav+lrBVEdRWLbYX41xWBjJRWAGzIGKPxk+VlWLsk9GhqalRlwDeQ90= /3Bh -SdR776XwShG6EvZj2DwruUvelJ3uNPwIqyHYgIDA6Ku3yN5HvHgUNb3ZaxkgPpKd2Q7XmjKw= tuyQ -1prUnZfp8Yve393YxSH3gTnhO6EW1S3QeCd97rKVJqQ5RzSL8QVpMuSLgVNd6TNZ+u/B+Cab= MzLP -vtbnVrS2EsVBfwFBYeub3vvV35fn/3T+MMQw6T8AJ4viMwekxiiMYMY2xjbbgv67MT0A1i2J= uPfA -VZ5K+WDYIPoFg0aQ731PP24yO4NSUXcTDOqBP01BmePLeyyFYnmB68tO9Xh9t6X0PA5pG9Oe= Hyr0 -PsU+MMPhm3T+AD24bTin3vb6ZjFJiIRghVrIMMgMABl2RXSQrL5sHo9On+vKuhTTjyfJ2Kcg= IRDd -DyzZkr/DNXtm80NW26lIsjIDhAfIsFAzfcBSthYA5ug0QkmNHpr8Y0oJiadQ7b/WWuFrAMyC= BDII -L+1ciYcx5UvA8tgENUnSmJBs7JNDSPAL9pKhoegQvMLGkvNuXi69NxNyarGtxuDGHiO9l1e0= mFXb -EBYdbrlAxmOS2eyRqOTYMb69nsG47Xqb85LNhg2AXrtNpdKjA6VSCMAGb/MS98z5z8v0L9YM= xK+q -yNrRWbFlt8dluqN4akixFpK+HewQgFZpNqaYg8/o7d4irxD775CFwNOwrLOvjR7x7AqJPDSU= E2mY -FXd9bRHLrOvYPrvJ2xjFPCZisgGgaRWsRy7Do1D3550Aon5aliJY1YZ+NNKrM2KyaMMJmZn1= +eWP -j5QZ5JiniZqoXMdLrl/+xo9BPKp9+VzsJH1Bhm4fknrNlsmLpHWdQQd2EVGjmF4J5gSpimwW= dJ59 -be32+FOk+BEqUaff4Fr1onIYDM12qsTDDEBje21BRHiBMQV0qYPDkXADD0a5JYDjVtwZDSa8= ngWG -m/HrGFmCgiHiA6oTEXpFsrw1BWFQu936rmM1DsMa89htW1hcM0c1zOJUCZIW4f0g0gCpVhY0= jABn -SE6IScCPgtYwRYvQsqFSEgmEBKjQBYiOCIPAJyVKsqxhWMG9rgu7czsznzii7Ot2hkQVCg+f= enHe -WqTS4vEQVb6B0NjRQEWpDGU2c2pwVltkQgKgYmgtUHJ+2upTXEQrQ5sIvDoo/r4dq0jhzom0= CWpT -DnCfgqoYW6JVDl6gDWiBiBNdqnznfVFFkjiAc9wYscu/lpZO96NpDR5RZEYAlG64U4wyzsOI= /EWs -Xc0yFLmycnS2wicbv+2aFgRIgsAOAiUdF8tBUbxd/xo3d3taSezf7eOer9f4LwbibPPjCPLb= QkLB -sOf2W8xcKJHcDb42TR1vbd+fyeLVASQ4hH122z+c5J9mfYZIJQH4YhqHnHDYWL0wd2p/zIEA= dN4+ -qkeXRvLxK7DQdx10uwPGe5VC3nI6eBe4dpohbiv1ffleq8jxfjugjmmff5hoR2VQLhnZg6dY= ZYPB -c3nPevtLOxdVW3WTbgNMiPlpQzrTQzkf1GQZLfjNwlEkjBGHkAka9vD5p4gAKcK/dNjUAgEj= NRoP -QTnzqZGacW8Nu1bj3DR5RQ8FpchptT85zvz5fpR/bqs7PKg4TKUC1qAAYyVkWt9iTZihosoK= BRBm -+z7/R+Aw3GCglURfobbYt7LIpcPHemYepK+43Z7diqFuuze0XnKnC2IVXGVMZl9fW62A09ac= aBJu -EXf4OmkIrVUfmq79fK7Z+dIODRd+dmHIHCaCAzTVoOxpELbSHikY+x+JUcJj2w12WI87IyGr= LdRl -18kT0Ihyez9hYz8WPRI/eHywQkBSCL6UlLzG8Yw7wF3D7san3zoU1CQvNtK8cj1YoqCIg6ZV= R1uF -Dpg8KP6XsSpmi++E5k4yDHUEQ5ORDKbXYS74mGxyfI9hb2Nb7S20/oeeyMEwDDC/KWtlBNsC= R0dd -dOmK+rcoemR+2WK1tPO82C0jdLGz+tDwM7iTA5kSZT4sl3FkO37ftlhQiI/7WdIw7jM2NGAi= DjYa -JaMbGwoULmsddjaZrVcy1cy4djJUTtD4FKCmRJ7S6I3RUd82CGkiaVl0gpR2tS/T633rsbpv= hc8S -DYpodjZDRmU3uh0d5rNEdLtebmhvnjeZLqTr8MGPEtlGsGwo8L4RrWUGUthWIy20kbS6bif5= huGn -orifj/3SbhsHn/gmPDRFDi6wbBTGuUO85zzrZhvcSQr+j+ePXmHtGaTDaBiMTimS6Cd3EaTS= xI23 -zCuwKwfq8GSSNMNJJsLVK0WL2DyVdYQadL/uTzupOhxH5jwg7XXqM87RzMJ0u43sUFq9keV6= +1bv -svVfwvCpsPUDocq0KAzT0ubkfDYHktuczZmzmFdB7cGhCxXbQldDYxsySKtSkPFZqV1vnZJS= GXak -kKtoSuSuThysnn/aOs9bVnG/udJatDs2vjbWjIxDTA5fEP8RlmRaPQZUt2xGmDLPnzGSgc30= NPtQ -0Mnp4Ob0BSDbKWjGMhjRjANShYdalmUtFEtLRolRS21Uq2Q222yBimL2rQYWEumpkjC0hdC/= X7+A -tJH6iGwr7shvnECERpMskbdOQqSk7uJGDsI2Yx7L+cyl3zL6BzTrWsRwTgWFojbkriVKDalM= rW2y -91IB0WScnd37JyHwuuOTDYRKjIVFAOThZMNWplOn9vdvZlEsg/Nga7xNPk7nn5pREVKaKNaj= mMIE -UKbTNSBOjYt0hunUWY6R4W3ffhiPbbKllNBPZ4FnS3M9oHtOZt5YYiywA2aOjDKIRrity70Z= pSqC -Xd98xbWLhHao7vu1oOWxvU4zeBmkbcG1qw6JNDGDZO4XbVeNIGwWO0R4Rd9H4Vwx8H5lx0kf= qz2J -gZq+HnL641BkSCDMCibGJplZ9qU0w/tIeyEDASITreh/LnPafNPl4fWIuWj7uwuafR5+T7cP= uj6+ -HuBl+Vy75+dtPU1bPkHHAQRVp4SgVkJ/uhgKKLDGzGK2EHwnXQQTwwKSwAzaudJB1kFfhOXQ= iiPc -MJm8phc1ok8vY8saBHojIsaOXEbfdRl3vlIj4m0DMX5z7Or+Va/kb7V7neVQkinhpmncmium= E6od -OhwO58r2nOdFy2ebXGRHgU03UdUKAwrHhAcTGA0XICMeBerqwqaXn6XJ0ewnfKqfqTvQ9Ry7= f2O+ -rZJc6ldI/b0jJ3ZIZfXbG5565scLQcfvCj/dKaVgj5Jegs+ogxGkGYJDSlY7OJK+wwuxdh0Z= Ltkx -LPtKr226uXVYbBAHiml4Rhhy+FTruspbqeURiT6sl8mJucu1CnT711j/A6CmNXZx5VIoQjc5= kI/Q -yaLdklc0IrKVAUI4I3Wxyt6WOXWgjk58pQpB07rE2yA530r+kye5qS12nscsyOYgojsFoTXT= NPD9 -h8V7vwN7b4Z01zVsISzcz3NFjLfvOrKSSdU6yjaUqtrEtkrARIfJ1mjxHMS2UQ2tccrgKEBi= igrI -KKLEt6LKnOe2L5r4m+H5ulHtRUFlIkVgEq0xtCCYmIko5G02nA6+dQqiK9uzTMMrPEXo032g= wOTM -iQBSEEoQdQM/9yeAOlHqRUkD5C9LSPTPFt3G57ztQ0eXS9LlsIk9YUrIiwYPsks2BO/kQN4c= SAEN -CG3/nr30qWl5Hdbw4pgSsqkWE302zfAyYELfrXub12qetqxTk3ZOwiXV2xfzSc+nqLZz5mBr= 1SAD -gDNOQtBgatkm2ZsIRqM3R2uCjpDXbmzJi/zedwMeYejqviXdcN4l0KsMPWc+JoOFQSZS0k32= XuCs -ESYZAQKhNAmVR7wzU/vloRd2sKA3WYQgQCCK27JduvJ+Q6UKmECGTamfx/cru5OBUbxSz8cH= O2Xr -ZbKGvDUHx7/hQx/f32PD+9naj+88IocUETrJ6t3Hx9ij/+jaKQBA0ANoegJI5EuRna3h9Hed= eCxZ -TQ+K+113KZruWs6rVHbY5Eww6Za9JxnDfmITD3LKsfE6BpCBdjcdiC4UgzLAg/I9Tg9adVDd= r3/3 -Z5iHNlCUdNAbn9RmbSTH3FUCwYveW+tLDl9CaNuIU2OD9ohWQY+xv4PW9d0p8TGomNjHA05u= 1EyF -TQ/S5a7G/Sx43PdJgEhJCELhwLRl40kq5C4/xyP4b8iXL52KCJaz92Lr899XFZgDKv2SpzU0= YfAI -vuzKPm0DcpntKuwi6ON/KrMwyAoagHuYA03Nx7JNPPXYyYXagZpsF0YxlMIhjC9iG0WzZtT/= 2Ypf -Zb094vAwnlZx8ypF8TiSVHQ8xynQFLGdX5VapFEEDaL/qkIr7Xk6rczoSPiayCsYWmiJaASS= AJc4 -gqZcGkOIjs+DKbGNGm01Mkg7w7ydGUtM0280zRD0GFE14vZu8grBf8nsvNdAok0NGJ6X3OTv= zwfO -ez+KtowJTzcRrWWEVtslzKq8j7lqx9SsyjhiZ5P5PqJkHk0riz323ED2CHt0qREEQRU9w+Mz= tkHu -7UOsh46HBigqiw84wqSf1EN2YtLBCZyjBiTRQwPYQQDbaXrsNbb12ZeOh287RpMuNooPf0Fm= +URV -YvfynZyci83N3XRQ6gd7STDw0dMYQ+h/K5PIVcpFOhYiyxV0HAjNU8Ask7YPDvUepigv92kZ= dfXY -+LXXcC8NDMxQWho2kgISGzGbt5sstvN3G6xA6bgnE1TNfeMxuNBr3cOHEgi59Qc24ac9G1uR= 3jN1 -OUG/usNWnlCqbbks9M4145Sa7iYsMZbK0VlpxsZA/FmadgUzko/ermAowZ/BXUI1/ieqUq3g= Rgx8 -RwGiJOUhkZkDrEPBP4KyQNrXSK7Qq99qlUDXQSqcAsmSxPTQpzKsVDQSskUnpwKRhyTLfaME= vzZF -XxKKpkVbkTC5fQVDy6A5yBKwzaZGRjSGJAYP08DlDJ/B1782MmfDfz6vQbTDEE4gzJUTkMNq= x3sr -LMhvgqlptqx2Ofc1eH923LWY2sPkwQBRm4DuyJZQgwwBNJGdSKM51/wfNfBDKF54Kp6yWxSh= kvDW -rxmOVHtr4tg4Y3JNUNZCbfltxHk/WRTXw6CwcSTDMCQDhkN6YiEm5Ylm9uoliwFSqAGrNm1m= 5KQG -a0dPjSRYAwgwgqh0mQO6QvhHL1Ojz9PKpWjTu8NzcHx33tsL7jcT/mH/jC8bA4leezU+7Fhj= DBZx -UxuBPw1HyEHgX7lg4G4lIKyk80gAWZOWoip6GhE8cqxAJhjjcRYHdeThw2rEHrdOPDs9WGKW= W6ne -L8076E28CzdmYQRWGDU+BkTo6i+yqj2nEIoRzoofPj7jV1aC42T/gw+Or0+Tl/XJz/WWdP3f= 33uO -/m/2P1rMFtwJpEB0BoC43pmoKJ34aASxtHkHcmRWO+zIqyvr9L1SXoMQo8fmhKvpugfTXKN3= BW0b -86npKcx3Ws1295kz3sz62sg+RHkRPuzUmjB9LzFA5a+fruRsn/q8K/xrMS76GgNSu8PRUn65= sN/y -JrBrRAMO8X63PNUXwIS9qMGy9CBaTI3i032OtreYV7Jevm8KBIHSXLZ7JNF5ovnaFKEK3PMO= 3DoF -r2SGApOENM8jhQ21cp7PemagFSwDtkANILIFYzFJKFGJxQElEnE42tMNCbZb2pvfF41jYbM5= wjgs -MUPNsHwb8TPlavGXN6eFU8jIZVWoGaPjCMXfmH3hypnCVYVEsgIxWzqfsULgSJfnsFS+L3xu= MFtU -JbNXks8aM4DNMoZk5pZIHMgLoP65zz4tc/DakwLDsNJTwMiC7V8MWAZK9zgDv/zxZGRTH4ay= +pPB -f47dy4tZ3tps1rmgkhQYp/5wvu0BkbvaejabG0aDsL+2MBsRwpkuMayM1Gf0zC9fnSTWZJ3w= KYPX -e3dp4wKOr4Os+VAetys61z2cZbTGrf/jdXwjv5872ezhOhPDAKMlS2yg0QlUpQMxqRbi1EDI= Yf0v -gjMTdbHTVhr6bOUrUkMGtjB5w97NGSUwi5c4+EuLoHcTG9wWCyHsCLmE+NyowvaZQ8QiC7T6= cLfE -yoMGtXtZmnkWrV6dkPLDwXi0WpFkBaPAd0zaZ+LqF74/KDei+55YfglL6tV1jEzjlJwDLtcF= YHki -52sFIKfbwOY+7E8V32Opfgsa5Ib2KBJvj8FPjRJBdx0wqbjxFrVeZtr3rdaKFE4Wm31uGM7n= zJww -eX73O14WP3nx+BmkOiMqTnJIkr2qaVDQM0hBbDM94+Nrnj1qcl/yyOmekKICVFTT66NxuhTK= ZIkt -UIRusGSB1oIxMGEDgIhI8+RisfStaB18y+acjgUEweNYjbk2csJm855knl4DOFDfmTmyT1fa= kTaJ -RNHAoQMI7ib0OdswW8+7cCGczCtXY0mTOy06XDWdMdwNqksE8CUidZfI7vzDTf2ZARnRurMN= s8GA -wYIuNK9ccCMOPBSzjZpD/BWpK+QHxnWXrdqkZjYMBgvT0cp/DakWaLNx4T0c06tjjSKAjTRn= TpIU -kLPffsxM0hUjdSzJHWGlePUnmOwMwWUEKWCi6riqhWVaaFANsDZOcXEGAgTmTjTzr/O9r3F+= l8bh -rr2zpvGROewJ3LQY7Sk0g1256eU1juBENbBkogwZ+pyKShGvGXE2rrLutfM6/r/7q8QVjmrk= KNcm -454VBq9WOSJyKkQimrLDVMi/jWwYeHTgpyqC6smdElpCYOWkWw25k7gDdav5sNiA+A9Fw0Qb= Uvnm -QCvdTYeahEAXhTUOA3GUBCkKVRPQ/RkQ1lfRJSQ9O4bKjauJBZZADLZ5WIM25gkFKDuUQdmC= YsCm -ODFWZQzY63NSXDVMJd6uPgRj2OVlaruEMRpiGuZnTghMGebliomErLqHuRmsUxwms9ccXL6Z= pO5p -cMTeQEqjGu9aUZmHaGC7YhBPgmML5uxYDHxsopGeYpQxjTh4iKMtsfZtosG41QQ9l9WmidPd= NKBj -nBekiBdIwWOH0dOEUeQtPLXM96zyEWdgRPyt9BHAQne1Y+D5GScxsTvT3PY9bmaKI2KwqJgO= WgS3 -Iu0yxnOLWazFfy0AlTGXOvGQhmA1EqjM4yjJYGlMSHtqzxDMm2uF9lgYYGB+phcZYyTVmol9= C4Jj -Q1KX0bH7D9yhh16ufa8/hUJvnHpUzexU8XvVB2SJM13sPx32LfP58/X7fqI30y7so8p0u/KA= 9s1z -2vqZt+RlDI2Ikdsw5DEjZMUjqjqK6tO7OHeIDIcPbgbgahJvqmfwMi70CRr4sSE3bBiSOqaE= 8yEh -pui7x3AO3wuCfSc+mpitbEfRDSxGZr5U+ISyGUXVglpmcgntVcmY7KnYQxjFjUdelILTRtHV= nWhZ -iJtkKLK5vE3DO//h1mJV5D2XzU8Cn1gfvjBxDKARA2siXT3FpjmhUESa8jORu63DiI4cOFst= CWfW -mmOq688biIiHrlhOy7DrVrNvEKYlkK9eqNzYBcEGQ8aaDssiqq7tILG6xfkzUNopOX7/mXJn= Cs5n -RWb0CR0jF0yHQ0qTGOk8Wfr0bvmqMRBuqAyGo7ejEZcx9yhgzM0eUdnf5Poy2zQt1GOjtqmg= sIW0 -0X8LIz06B4qN92mAG2MmyTIxmqwarDLaCCcTU7ML6unv4MPh0kp2bRaLNPeh0two3voe79vz= upzP -m6brs46loSbSLouhIzyiFnDEkjV6ORIMIGVA25qQBIsFzzCjDgUTe7Cc5jIIAmDAGiAa2P+8= trdt -CcQ9N9pYTyEJ5hBXsjR+wG+i552kh4XyTbrwgWIqGEmr6pmGMUKs7kswFj7HpKQSXyj5cG9Z= Q1u+ -TFvOZmKAyUh6dx/b9X2UWpgQ7pLZHB99NEJNHcV9t2nlZqb17+8MqYs6G3BwjpCevgHBnh99= QYDs -WdM4zC6e0LJZUmIQGzaLGDK5/0/7Z3JVA6e83EzNrpDk4n0iSpenTMRgJoYJCxQ+n+f8t7nJ= n1a9 -6e5tIR140NovoAX/8XckU4UJAK1QopA=3D -=3D=3D=3D=3D Index: sys/contrib/dev/nve/basetype.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/basetype.h (revision 261434) +++ sys/contrib/dev/nve/basetype.h (working copy) @@ -1,281 +0,0 @@ -/***********************************************************************= ****\ -|* = *| -|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL= *| -|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY= *| -|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT = *| -|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED = *| -|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A= *| -|* PARTICULAR PURPOSE. = *| -|* = *| -\***********************************************************************= ****/=20 - - -/*++ - -File: - - basetype.h - - -Abstract: - - This file contains the base type definitions used by the networking dri= ver. - - -Revision History: - - SNo. Date Author Description - 1. 2/7/2000 AJha Created=09 - -*/ - -#ifndef _BASETYPE_H_ -#define _BASETYPE_H_ - -#ifndef IN -#define IN -#endif - -#ifndef OUT -#define OUT -#endif - -// -// Useful "types" - -#ifndef NULL -#define NULL 0 -#endif - -#ifndef TRUE -#define TRUE 1 -#endif - -#ifndef FALSE -#define FALSE 0 -#endif - -#if 1 -// -// Don't use as these are going to be deleted soon. Use NV_ instead -// -#define VOID void -typedef VOID *PVOID; - -typedef unsigned char UCHAR; -typedef UCHAR * PUCHAR; -typedef unsigned short USHORT; -typedef USHORT * PUSHORT; -#ifdef linux -typedef unsigned int ULONG; -#else -typedef unsigned long ULONG; -#endif -typedef ULONG * PULONG; - -typedef char CHAR; -typedef short SHORT; -typedef long LONG; - -typedef unsigned int UINT; -typedef unsigned int *PUINT; - - -#endif - - -#define NV_VOID void -typedef NV_VOID *PNV_VOID; - -typedef unsigned long NV_BOOLEAN, *PNV_BOOLEAN; - -typedef unsigned char NV_UINT8, *PNV_UINT8; -typedef unsigned short NV_UINT16, *PNV_UINT16; -#ifdef linux -typedef unsigned int NV_UINT32, *PNV_UINT32; -#else -typedef unsigned long NV_UINT32, *PNV_UINT32; -#endif - -typedef signed char NV_SINT8, *PNV_SINT8; -typedef signed short NV_SINT16, *PNV_SINT16; -typedef signed long NV_SINT32, *PNV_SINT32; - - -#if defined(linux) - - typedef unsigned long long NV_UINT64, *PNV_UINT64; - typedef signed long long NV_SINT64, *PNV_SINT64; - -#else - #if _MSC_VER >=3D 1200 // MSVC 6.0 onwards - typedef unsigned __int64 NV_UINT64, *PNV_UINT64; - typedef signed __int64 NV_SINT64, *PNV_SINT64; - #else - typedef unsigned long NV_UINT64, *PNV_UINT64; - typedef signed long NV_SINT64, *PNV_SINT64; - #endif - -#endif - -#ifndef _AMD64_ -typedef unsigned int NV_UINT; -typedef signed int NV_INT; -#else - -#if defined(linux) - -typedef unsigned long long NV_UINT; -typedef signed long long NV_INT; - -#else - -typedef unsigned __int64 NV_UINT; -typedef signed __int64 NV_INT; - -#endif -#endif - - -// -// Floating point definitions -// -typedef float NV_REAL32; // 4-byte floating point -typedef double NV_REAL64; // 8-byte floating point - - - -// -// Bit defintions -// -#define NV_BIT(bitpos) (1 << (bitpos)) - -// NV_BIT_SET=20 -// Sets the specified bit position (0..31).=20 -// Parameter bits can be 1 byte to 4 bytes, but the caller needs to make= sure bitpos fits into it. -// x =3D 0xA0 -// NV_BIT_SET(x, 1) -// Result: x =3D 0xA2 -#define NV_BIT_SET(bits, bitpos) ((bits) |=3D (NV_BIT(bitpos))) - -// NV_BIT_CLEAR -// Clears the specified bit position (0..31) -// Parameter bits can be 1 byte to 4 bytes, but the caller needs to make= sure bitpos fits into it. -// x =3D 0xAA -// NV_BIT_CLEAR(x, 1) -// Result: x =3D 0xA8 -#define NV_BIT_CLEAR(bits, bitpos) ((bits) &=3D (~NV_BIT(bitpos))) - -// NV_BIT_GET=20 -// Gets the bit at the specified bit position (0..31) -// Parameter bits can be 1 byte to 4 bytes, but the caller needs to make= sure bitpos fits into it. -// Result is either 1 or 0. -// x =3D 0xAA -// NV_BIT_GET(x, 1) -// Result: x =3D 1 -#define NV_BIT_GET(bits, bitpos) (((bits) >> (bitpos)) & 0x0001) - - -// NV_BIT_GETVALUE -// Gets the value from a 32 bit ULONG at specified bit position. -// Parameter bits needs to be 4 bytes long. -// Ex. ul32 =3D 0xFEDCBA98 -// ulVal =3D NV_BIT_GETVALUE(ul32, 3, 0) : Gets value from Bit position= 3 to 0 -// Result : ulVal =3D 8 -#define NV_BIT_GETVALUE(ulOrigValue, bitposHi, bitposLow) (((ulOrigValu= e) >> (bitposLow)) & (~(0xFFFFFFFF << ((bitposHi) - (bitposLow) +1)))) - -// NV_BIT_SETVALUE -// Set a value in a 32 bit ULONG at a specific bit position. -// Parameter bits needs to be 4 bytes long. -// Ex. ul32 =3D 0xFEDCBA98 -// NV_BIT_SETVALUE(ul32, 0xF, 3, 0) : Sets value at Bit position 3 to 0= -// Result : ul32 becomes 0xFEDCBA9F -#define NV_BIT_SETVALUE(ulOrigValue, ulWindowValue, bitposHi, bitposLow)= \ - ((ulOrigValue) =3D ((((ulOrigValue) & (~ ((0xFFFFFFFF >> (31 - (bitp= osHi))) & (0xFFFFFFFF << (bitposLow))))) | ((ulWindowValue) << (bitposLow= ))))) - - -#define NV_BYTE(ulus, bytepos) ((ulus >> (8 * (bytepos))) & 0xFF) - - -#define SWAP_U16(us) ((((us) & 0x00FF) << 8) | \ - (((us) & 0xFF00) >> 8)) - -#define SWAP_U32(ul) ((((ul) & 0x000000FF) << 24) | \ - (((ul) & 0x0000FF00) << 8) | \ - (((ul) & 0x00FF0000) >> 8) | \ - (((ul) & 0xFF000000) >> 24)) - -#define NV_FIELD_OFFSET(TYPE, FIELD) ((NV_UINT32)((NV_UINT64)&((TYPE *)= 0)->FIELD)) - -#define ADDRESS_OFFSET(structure, member) ((NV_UINT32) ((NV_UINT8 = *) &(structure).member \ - - (NV_UINT8 = *) &(structure))) - - -#define NV_MIN(a, b) ((a < b) ? a : b) -#define NV_MAX(a, b) ((a > b) ? a : b) - -#ifdef AMD64 -#define PNV_VOID_TO_NV_UINT64(x) ((NV_UINT64)(x)) -#define PNV_VOID_TO_NV_UINT32(x) ((NV_UINT32)(NV_UINT64)(x)) -#define NV_UINT64_TO_PNV_VOID(x) ((PNV_VOID)(x)) -#define NV_UINT32_TO_PNV_VOID(x) ((PNV_VOID)(NV_UINT64)(x)) -#else -#define PNV_VOID_TO_NV_UINT64(x) ((NV_UINT64)(NV_UINT32)(x)) -#define PNV_VOID_TO_NV_UINT32(x) ((NV_UINT32)(x)) -#define NV_UINT64_TO_PNV_VOID(x) ((PNV_VOID)(NV_UINT32)(x)) -#define NV_UINT32_TO_PNV_VOID(x) ((PNV_VOID)(x)) -#endif - -#define NV_MAKE_TAG32(s) (((NV_UINT32)((s)[3]) << 24) | ((NV_= UINT32)((s)[2]) << 16) | \ - ((NV_UINT32)((s)[1]) << 8) | ((NV_= UINT32)((s)[0]))) - -#define NV_MAKE_TAG64(s) (((NV_UINT64)((s)[7]) << 56) | ((NV_= UINT64)((s)[6]) << 48) | \ - ((NV_UINT64)((s)[5]) << 40) | ((NV_= UINT64)((s)[4]) << 32) | \ - ((NV_UINT64)((s)[3]) << 24) | ((NV_= UINT64)((s)[2]) << 16) | \ - ((NV_UINT64)((s)[1]) << 8) | ((NV_= UINT64)((s)[0]))) - -typedef union _NVLARGE_INTEGER { - -#if 0 - // NO UNNAMED UNIONS ALLOWED !@ - struct { - NV_UINT32 LowPart; - NV_SINT32 HighPart; - }; -#endif - - struct { - NV_UINT32 LowPart; - NV_SINT32 HighPart; - } u; - - NV_SINT64 QuadPart; - -} NVLARGE_INTEGER, *PNVLARGE_INTEGER; - - -#ifndef LINUX -typedef unsigned short NV_WCHAR; -#else -typedef unsigned long NV_WCHAR; -#endif - -typedef NV_WCHAR *PNV_WSTR; - -#if defined(linux) -#if !defined(NV_API_CALL) -#if defined (__i386__) -#define NV_API_CALL __attribute__ ((regparm(0))) -#else -#define NV_API_CALL -#endif -#endif -#else -#define NV_API_CALL -#endif - -#endif // _BASETYPE_H_ Index: sys/contrib/dev/nve/drvinfo.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/drvinfo.h (revision 261434) +++ sys/contrib/dev/nve/drvinfo.h (working copy) @@ -1,190 +0,0 @@ -/***********************************************************************= ****\ -|* = *| -|* Copyright 2001-2003 NVIDIA, Corporation. All rights reserved= =2E *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL= *| -|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY= *| -|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT = *| -|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED = *| -|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A= *| -|* PARTICULAR PURPOSE. = *| -|* = *| -\***********************************************************************= ****/ - -/* =20 - * This file contains the header info common to the network drivers an= d applications. - * Currently, these applications include ASF, co-installers, and qstat= s. - * - * - */ - -#ifndef _DRVINFO_H_ -#define _DRVINFO_H_ - -// Switch to byte packing, regardless of global packing specified by the= compiler switch -#pragma pack(1) =20 - -////////////////////////////////////////////////////////////////// -// For the ADAPTER_GetStatistics call used by qstats. This=20 -// is the template used by the legacy driver. -#define MAX_TRANSMIT_COLISION_STATS 16 - -#define ADAPTER_STATS_LEGACY_VERSION 1 -#define ADAPTER_STATS_RM_VERSION 2 - -typedef struct _ADAPTER_STATS_V1 -{ - NV_UINT32 ulVersion; - - NV_UINT32 ulSuccessfulTransmissions; - NV_UINT32 ulFailedTransmissions; - NV_UINT32 ulRetryErrors; - NV_UINT32 ulUnderflowErrors; - NV_UINT32 ulLossOfCarrierErrors; - NV_UINT32 ulLateCollisionErrors; - NV_UINT32 ulDeferredTransmissions; - NV_UINT32 ulExcessDeferredTransmissions; - NV_UINT32 aulSuccessfulTransmitsAfterCollisions[MAX_TRANSMIT_COLIS= ION_STATS]; - - NV_UINT32 ulMissedFrames; - NV_UINT32 ulSuccessfulReceptions; - NV_UINT32 ulFailedReceptions; - NV_UINT32 ulCRCErrors; - NV_UINT32 ulFramingErrors; - NV_UINT32 ulOverFlowErrors; - NV_UINT32 ulFrameErrorsPrivate; //Not for public. - NV_UINT32 ulNullBufferReceivePrivate; //Not for public, These are= the packets which we didn't indicate to OS - - //interrupt related statistics - NV_UINT32 ulRxInterrupt; - NV_UINT32 ulRxInterruptUnsuccessful; - NV_UINT32 ulTxInterrupt; - NV_UINT32 ulTxInterruptUnsuccessful; - NV_UINT32 ulPhyInterrupt; - -} ADAPTER_STATS_V1, *PADAPTER_STATS_V1; -////////////////////////////////////////////////////////////////// - -////////////////////////////////////////////////////////////////// -// For the ADAPTER_GetStatistics call used by qstats. This=20 -// is the template used by the FD. -typedef struct _ADAPTER_STATS -{ - NV_UINT32 ulVersion; - NV_UINT8 ulMacAddress[6]; - - // - // Tx counters. - // - NV_UINT64 ulSuccessfulTransmissions; - NV_UINT64 ulFailedTransmissions; - NV_UINT64 ulRetryErrors; - NV_UINT64 ulUnderflowErrors; - NV_UINT64 ulLossOfCarrierErrors; - NV_UINT64 ulLateCollisionErrors; - NV_UINT64 ulDeferredTransmissions; - NV_UINT64 ulExcessDeferredTransmissions; - NV_UINT64 aulSuccessfulTransmitsAfterCollisions[MAX_TRANSMIT_COLIS= ION_STATS]; - - // - // New Tx counters for GigE. - // - NV_UINT64 ulTxByteCount; - - // - // Rx counters. - // - NV_UINT64 ulMissedFrames; - NV_UINT64 ulSuccessfulReceptions; - NV_UINT64 ulFailedReceptions; - NV_UINT64 ulCRCErrors; - NV_UINT64 ulLengthErrors; - NV_UINT64 ulFramingErrors; - NV_UINT64 ulOverFlowErrors; - NV_UINT64 ulRxNoBuffer; - NV_UINT64 ulFrameErrorsPrivate; //Not for public. - NV_UINT64 ulNullBufferReceivePrivate; //Not for public, These are = the packets which we didn't indicate to OS - - // - // New Rx counters for GigE. - // - NV_UINT64 ulRxExtraByteCount; - NV_UINT64 ulRxFrameTooLongCount; - NV_UINT64 ulRxFrameAlignmentErrorCount; - NV_UINT64 ulRxLateCollisionErrors; - NV_UINT64 ulRxRuntPacketErrors; - - NV_UINT64 ulRxUnicastFrameCount; - NV_UINT64 ulRxMulticastFrameCount; - NV_UINT64 ulRxBroadcastFrameCount; - NV_UINT64 ulRxPromiscuousModeFrameCount; - - //Interrupt related statistics - NV_UINT64 ulRxInterrupt; - NV_UINT64 ulRxInterruptUnsuccessful; - NV_UINT64 ulTxInterrupt; - NV_UINT64 ulTxInterruptUnsuccessful; - NV_UINT64 ulPhyInterrupt; - - - // - // Handy things to know - // - NV_UINT64 ulDescriptorVersion; - NV_UINT64 ulPollingCfg; // configured for cpu or throughput - NV_UINT64 ulPollingState; // current optimizefor state. - - NV_UINT64 ulNumTxDesc; - NV_UINT64 ulNumRxDesc; - - //=20 - // Useful to determine if TX is stuck. - // - NV_UINT64 ulNumTxPktsQueued; - NV_UINT64 ulNumTxPktsInProgress; - - // - // Rx Xsum Cntrs - // - NV_UINT64 ulNoRxPktsNoXsum; - NV_UINT64 ulNoRxPktsXsumIpPassTcpFail; - NV_UINT64 ulNoRxPktsXsumIpPassUdpFail; - NV_UINT64 ulNoRxPktsXsumIpFail; - NV_UINT64 ulNoRxPktsXsumIpPassNoTcpUdp; - NV_UINT64 ulNoRxPktsXsumIpPassTcpPass; - NV_UINT64 ulNoRxPktsXsumIpPassUdpPass; - NV_UINT64 ulNoRxPktsXsumReserved; - -#ifdef _PERF_LOOP_CNTRS - NV_UINT64 ulNumTxCmplsToProcess; - NV_UINT64 ulNumRxCmplsToProcess; - NV_UINT64 ulNumIntsToProcess; - - NV_UINT64 IntLoop0Cnt; - NV_UINT64 IntLoop1Cnt; - NV_UINT64 IntLoop2Cnt; - NV_UINT64 IntLoop3Cnt; - NV_UINT64 IntLoop4Cnt; - NV_UINT64 IntLoop5Cnt; - NV_UINT64 IntLoop6To10Cnt; - NV_UINT64 IntLoop11Cnt; - NV_UINT64 IntMaxLoopCnt; - - NV_UINT64 IntRxCnt0; - NV_UINT64 IntTxCnt0; - - NV_UINT64 MaxRxLoopCnt; - NV_UINT64 MaxTxLoopCnt; - -#endif -} ADAPTER_STATS, *PADAPTER_STATS; -////////////////////////////////////////////////////////////////// - -#pragma pack() =20 - - -#endif // #define _DRVINFO_H_ - - Index: sys/contrib/dev/nve/i386/nvenetlib.README =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/i386/nvenetlib.README (revision 261434) +++ sys/contrib/dev/nve/i386/nvenetlib.README (working copy) @@ -1,52 +0,0 @@ -$FreeBSD$ - -The installation and use of this software is subject to the following li= cense terms and conditions: - -License For Customer Use of NVIDIA Software=20 - -IMPORTANT NOTICE -- READ CAREFULLY: This License For Customer Use of NVI= DIA Software ("LICENSE") is the agreement which governs use of the softwa= re of NVIDIA Corporation and its subsidiaries ("NVIDIA") enclosed herewit= h, including computer software and associated printed materials ("SOFTWAR= E"). By downloading, installing, copying, or otherwise using the SOFTWARE= , you agree to be bound by the terms of this LICENSE. If you do not agree= to the terms of this LICENSE, do not download, install or use the SOFTWA= RE. - -RECITALS -Use of NVIDIA's products requires three elements: the SOFTWARE, the hard= ware on a computer motherboard, and a personal computer. The SOFTWARE is = protected by copyright laws and international copyright treaties, as well= as other intellectual property laws and treaties. The SOFTWARE is not so= ld, and instead is only licensed for use, strictly in accordance with thi= s document. The hardware is protected by various patents, and is sold, bu= t this agreement does not cover that sale, since it may not necessarily b= e sold as a package with the SOFTWARE. This agreement sets forth the term= s and conditions of the SOFTWARE LICENSE only. - -1. DEFINITIONS - -1.1 Customer. Customer means the entity or individual that installs or u= ses the SOFTWARE. - -2. GRANT OF LICENSE - -2.1 Rights and Limitations of Grant. NVIDIA hereby grants Customer the f= ollowing non-exclusive, non-transferable right to use the SOFTWARE, with = the following limitations: - -2.1.1 Rights. Customer may install and use one copy of the SOFTWARE on a= single computer, and except for making one back-up copy of the Software,= may not otherwise copy the SOFTWARE. This LICENSE of SOFTWARE may not be= shared or used concurrently on different computers. - -2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Se= ction 2.1.1, SOFTWARE designed exclusively for use on the Linux operating= system may be copied and redistributed, provided that the binary files t= hereof are not modified in any way (except for uncompressing/compressing = files). SOFTWARE designed exclusively for use on the Linux Operating sys= tem but which has been authorized by NVIDIA for use on the FreeBSD Operat= ing System may also be copied and redistributed, provided that the binary= files thereof are not modified in any way (except for unzipping of compr= essed files). =20 - -2.1.3 Limitations. - -No Reverse Engineering. Customer may not reverse engineer, decompile, or= disassemble the SOFTWARE, nor attempt in any other manner to obtain the = source code.=20 - -No Separation of Components. The SOFTWARE is licensed as a single produc= t. Its component parts may not be separated for use on more than one comp= uter, nor otherwise used separately from the other parts.=20 - -No Rental. Customer may not rent or lease the SOFTWARE to someone else. - -3. TERMINATION - -This LICENSE will automatically terminate if Customer fails to comply wi= th any of the terms and conditions hereof. In such event, Customer must d= estroy all copies of the SOFTWARE and all of its component parts. - -4. COPYRIGHT - -All title and copyrights in and to the SOFTWARE (including but not limit= ed to all images, photographs, animations, video, audio, music, text, and= other information incorporated into the SOFTWARE), the accompanying prin= ted materials, and any copies of the SOFTWARE, are owned by NVIDIA, or it= s suppliers. The SOFTWARE is protected by copyright laws and internationa= l treaty provisions. Accordingly, Customer is required to treat the SOFTW= ARE like any other copyrighted material, except as otherwise allowed purs= uant to this LICENSE and that it may make one copy of the SOFTWARE solely= for backup or archive purposes. - -5. APPLICABLE LAW - -This agreement shall be deemed to have been made in, and shall be constr= ued pursuant to, the laws of the State of California. - -6. DISCLAIMER OF WARRANTIES AND LIMITATION ON LIABILITY - -6.1 No Warranties. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, TH= E SOFTWARE IS PROVIDED "AS IS" AND NVIDIA AND ITS SUPPLIERS DISCLAIM ALL = WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMP= LIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. - -6.2 No Liability for Consequential Damages. TO THE MAXIMUM EXTENT PERMIT= TED BY APPLICABLE LAW, IN NO EVENT SHALL NVIDIA OR ITS SUPPLIERS BE LIABL= E FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOE= VER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,= BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY OTHER PECUNI= ARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVE= N IF NVIDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - -7. MISCELLANEOUS=20 - -The United Nations Convention on Contracts for the International Sale of= Goods is specifically disclaimed. If any provision of this LICENSE is in= consistent with, or cannot be fully enforced under, the law, such provisi= on will be construed as limited to the extent necessary to be consistent = with and fully enforceable under the law. This agreement is the final, co= mplete and exclusive agreement between the parties relating to the subjec= t matter hereof, and supersedes all prior or contemporaneous understandin= gs and agreements relating to such subject matter, whether oral or writte= n. Customer agrees that it will not ship, transfer or export the SOFTWARE= into any country, or use the SOFTWARE in any manner, prohibited by the U= nited States Bureau of Export Administration or any export laws, restrict= ions or regulations. This LICENSE may only be modified in writing signed = by an authorized officer of NVIDIA. Index: sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu (revision 261434) +++ sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu (working copy) @@ -1,320 +0,0 @@ -$FreeBSD$ -begin-base64 644 nvenetlib.o.bz2 -QlpoOTFBWSZTWSDHheUAMsL/////////////////////////////////////////////4EQz= TUNc -bl2envbuoZ32+6l7UqAC3Z7vc94Or3e71IAA8D6+8zp9Pb2cpz25cy8899HK75hzz68d9fKf= Z93z -u9ze3vrw+hRSIffLl3Nd7OXbuFTV73dzoyVHba69t98z7b77dV6ejnXt729noPPc869rl6u9= bvrd -ffF7bw3nmPHsD3tY7dmR7Fdua3ZezWgE73uldi+7wLkRt6H3vd76++9o+3ci3rr2zNN6uK++= CPvR -5B4YaEQmgATTRoGgIwBMENM0TTBMRiTGk2jRTyYmAmRo0xNMKaMmNMEnpPRpPQp+jUaeUaeo= wyaU -/VPGIU9NPTU2VPJtR6npHpHqeSZNPFHpqINCE0ACAmmEGhoTJppiYTTVPDQU2CMGpk1T2U2p= tQ9U -8mRpqPNJPU/VPGiniCeTJp6p+qG1PTQ0gemgYUbZTSH6ptE9I08jQj1DCepoDQBpo0EpoQhB= Gkw0 -Jqep6mJMo/SYTaJPU9I8mp6T02qeKe1T8jSPIeqn6p7VNpqaeptTNTR6m1PSGj1AB6mj1DaT= 1DZQ -HqDRoZGnqHqNG1A9Jo08po0ZAAA0AZAk0kSImmiYUbQmgp4NJ6myp7TUyNTDU/TU1PRqHpPU= 9TGi -aepkaZG1NPUPTUB5TQPSepoyaBpkAAAaA00BoaHpAHqaaAAAAyAAAYpCT1NPVR7VDNJ5T1PR= pPU2 -o9Awp40po8jKB6mQ09T0mI9QPUNqbKaPU9TR6TyaJ6gA9T1HqPKD01G1NqPU9R6mTRppozUB= kzU9 -J6m1D0RkGnqNBp6h6mj1D0jGoJEiEAJoATCnpiZTwk8pg1MEU9ppqbJpiKeTZJ6Knp5KftJt= Ggp+ -VPR6VPeqn6ps01TZT0aTzUT9T0pnkk2aTU08pp+qaAeU09qmBNlNPCRp6aZCGjTQ9Q0DQd8s= sO5h -vAz8/gqHlJiqlbkKQeWmWEv4AKp5389QWX755RUTliUQIlUUBJzvOWQ/dBn0FK7qi9BFQVGc= LDJS -qpnSQsek+Gia16cd8J1fFMT1vNdzKgSAkJwfPE5cxTXvelz7OlHJONaHhLUDaNTb7ne7/Uj6= q11n -J5Xt/c/mcvt+4gu72wBTB2mXdUNvKDovb83x0rZj8qfvmZG+OXW0J9WzWsmU932Wr2sGzpLD= z+ai -vyKRTxwZxALmGlECIEVBh8i5tpIDBaHG9rhH0v69LptFABhromioVy+CwCrSMw9u7V29cQh+= RxCI -vZ72EKc1E9ccLq5pmEN2y+VfjNUhQlIVXNotbVIYXielSdFGFqYP+HlBgefd/ueZIwU0AOp7= rgeX -yaiHMUvMm0oz5oWz+vie1BtV8ztPR5eg0nhaTaz7HKxGV6+uoJtjXp71DX0W5tMPkcpu5PYf= h0Lp -vxf44Lf29D2+VewONmuR4fybju+dhWnW1f5GJuzyQ/rYN1rFr+fKDtFkH8Fw4MQ/ko+b8asb= kjhO -3mIQ9NC99pnCy91a8Z01pIQfWVJ38n1WxMDLp1Ox80F6yptw+Tt37aJ2PK9HCFLZXLI3HMQZ= NfYn -A6oeBbd/qGJfEb88pBh+tpVDKeBltS/jt+5n/ZzylBaQpVThO7lX3Xw0Q2XqjCkQkRAh1Ksf= SsKu -JVW26T1Hma56furzz0Hor0CHTaj7z0/xNfYdHOyto++xaleYd+kppOdAsnqffmKunXct0l6a= z879 -d899brk8KPxydedr5Shadjkcbxau7+yL2SVLREO9bQ42XLl0L6FhK+6cenSdawaaz6nNaqyn= Mlhb -mAsQCAB8zMuz+Sz5loV2rmMRGC0X07bxMW7ecebtb+sMlThXDdNrggix/7f8ey6vL0vcfhrX= lSaU -UcQZavvba49rmZoeeFwwSgRiNzm4+hUk1q6fa1KVue1HZp69cFewoPReX619HmjnqIN6CfYq= HwAn -mq36HzS0CGmTOIFBCH0fT/n/l5svL7XrVToOra/T/M+JXRwXO8uuIdVwYZlqjGELusof0Hvb= Q1jY -QwPt2mBGwbU68XvcCkwAh4vC0g8smFvObWu87XUMqm/gVkKuHIILqVra+pt71fTXiW/+9vJw= canx -v04ECBNoEDNT/aZpsRqJiERK5ANjF/0GVq/uep9UNxSBmZhwUrdDFqzK8dwzprdVeOW2arrF= tYdY -7jwv+pWrwMpzqX46CRIMjKgVMDcUPQ+xw8vtB90ZTaEwuRSGVWwgK6MDW5plzu65gvxD4gva= n0Id -C2B2yeiVgYwFnqTxwsJ+Vg0S1kCJZm2gQgESDCGklXJs1ZGr9N3+4vodAeSOfBL+tN40laEG= Rgx0 -MmTzZOZJKtaKX7/s0r169myta1KM2mkozxxTL5Lplzc3lkz0hdBkxLBatPIvPWO1iNwivmYe= QMgM -iFJSfv+z6jOtIceXPKFtsg3JD6z4Pr/XfvfvnL2fMsenwU2K2qMFEbNAChQr06oKBeQlEQ2e= TiWv -dlvMaHKRNHAIftC3dD6rvG9Btki99jnUDrlN717nWsGxTbZW+E3j3G+ejllEYcXBypJVRSiP= nU73 -jz0UMJ6thyZEeV55KiqGXLgovV1XYu7tM+WsrBQmmvorZiTwPDNK6aIj9VbrCQGaIgIGI4de= vEi+ -lj1wzf+K+gh18+LsP4Pm0RW9VPn1cF9csU3SN1ZE6Lomoo1AyVnTzq+lU8hQaQMGTwgq+Czu= qTd2 -ux3fT9Pv9Pcw4cG7jbEbBpIhoUFFI7KhR6JyRITA601KY4KYpj6dG6o6Gn8zPu8zl9vWvFu6= 8ufJ -oShobbUxsxeqYqz0dvli8uej5+r5MBFdgG3FmIK2U943E3S3Mb50LaQKohj4qYaxkad3yaad= VA99 -4oST2mneAm+4PpRYlyjkRvMeZq4ybRRrLF+uvnRM5FiX/LHLuLaPvn5OxyIrVPrQUWn3dGSh= TOfU -iIilGQXJJXIQjFmSix7Kv/c7Q/90bIbcyzy0ztC0+DjlW3KWMYBDQNAwhgz9i6NV9DWe2d9a= jjKX -L8HJBO7DpkqJrlEKkNfGdEKU+kn3E0Ve6MMCaoCyHQ5J7Tgg4pF1OMx8KQ7zLHHr9Hopqwl8= bipS -CBoTD3sScbQsAkaWSgoGDUEGfzKckybR8WlrOLRDOWV9I0tagzMsPS+l9Nhvm9WsO5c/ObCU= NMiF -wJzXXUbfoZnSQxDkRaCKwzIijz3cCab02G+IbyDrdC2aTXFHKlKlHeFXzF3lbKLjyp85BZMY= IZms -FROaKYJBXAmBIaQTfFcpBkq2S0sBUlwGPUCzCkha9Dvi61SutyQ6zjLTQx1wz5deUGLCKoCY= Idqo -JW89t3OrJBeXxz17sXtg7KtcS43xeqzA5JmW2qa1INmkOTjNs6vlevo0pst4legQz3uBpTop= pX5G -8Em+RcsNmpkiWzWVV0lutaLxvB2wlTilVRVVTFbwj49P7eqp2eOjNFyXs8+1xPEd6pRKKWlT= pyZg -SqxWJXmWvNO3ve5S9PwLy2Gy0FUtqPIuctENdd0Lu1iqdKcmavFybGs6Ccxkoa0vnZMYbHWW= 5Q4z -WcZOW+KbDh21t3ky3WjnsvCadoI+p5YcM0pllYIqxQFioJTWGmalTNctHLjM42crthpszg0Y= pNmp -scM1LarlrbbS2oILNsM2b3mYXndzV27QtsxdQo4+f03G+NcF6a5MFycTfEceHlMRD5BAHRdl= CgK9 -qg0Gqq+3YtvYp7PGORnmZh7BMu22zsC7iTUxWMXzbLko6s6eOMCV9lV+znZUFrBe0+DQn7Ck= 36Pt -+M+CFKJ9RGBTxzhNRLcMzCjMzXWta0qmCEw9E1OqclhVPSWuLqZOauDUmsNu9BWMywVlrdnM= pTbH -ZYSqkV6COP891OlUvRe78OHYRg5KBbZgLsi2xztTRp/hwlNn5/VtyLNqFSNNhkvhNFC6XTPp= v26z -S4jArX0k9QhdzmGnLj46Czz/d6zvLNsVmLysHV83mwm6HtoOuqZSODJ7llEPV+pvqlO35BgV= x+/M -qekuneoacOG4j7aHQki6rwqViAiUOWl4RRQxtdNTjT21Q4vCfDJisSys99R5RF0RDtJkmB7D= tCgc -5n+Pf8jnO899S6p4fadsq5sw3u+xOx7ek477gwSqdRV8ZByO8zOz4brj32ujMIAVk3Bo3npc= /u6g -Pfx8lr1mo9H6v6UqLFkH9D4cEmkkP+pAAQMSbGkAjQYXmrNi19y6Rdl6lOrV9v93AsdG1nMA= AuRA -fVPUxSYcugEi9kWC+YLnbpx3DRXGJst2IFDE2C6TR/bslgyrf1+FUs5toRaa8Rwzvq7jZYCD= zWAN -g+k4G0eUwqa3TQBevKwsLn393UJHQybiECVUkiJ30N5YKBznPg73g7nHs2lYohAGsNI8lgWX= QxfU -/7TXIOI39r3ZU6I8JhDUgeBCHgYB60HxELBA8NDgVCQ2hSYk5MSqyIngyxvtQhqPKYpNuwFF= arQz -HIa+Xlq1xsyimty8TSwqG3YjrWSgv65tSZ+ZysNclgxPJu1EpqDOsIH0QgAZgFLP8OXOA76u= oZsW -oRnpOrPE1qZaq2wnWzjCyNOkZtCgdnxe1xdG0iyKKr6C3lSsPasCTzGB4HSDTSsZ0dXDr4Uo= waKz -QLT049VoRjs4+sT/RnQ0dLm6+zvNye9TDl7H4OvHQ74wHs0goRe4nNJ6QVknxvR06ZgqGQzg= NBD3 -+Njb+ZQPdcX6hWJD4L4k6VUMLI2PgNEJpeuWW+VwRCditSlWYYbRJi3BO+GBAP6ySdtCBWQP= AySL -Ah6xDmkKwFIqiwk+XZAOb0IN6MxgZbCAYyEDfOixSQKMFgRGE8RDmwgbSZEJKKivpWkRWT3j= PU7p -82zYkUREZ6NkKefQrIoKBOhqSAsFiMgj7IQk7AM9Q767AFhJpJ1sJ6pgWIxIc0h20neYQ+AM= JPt2 -ST2rDpQJDhFhWALAOQkxIoAHSwNJoQ+wZITHcSoqgjJ1DIqrBRYiQ8+1fGYVD17WThhUFIIi= qEKw -PB8GkNMgdKSChd07SQ0M0govcZijIjDoiSaYTwmsWSTqQj1lgiQY/m2ClGEFIaf/vyT9UGQ0= xZ2W -FYxUBSPh0rvg4FyaRRQk62RZJPPQAqBAxUUnvLQ8e0FhBehlE+L26eERkOc+AvCa3/cMlRnc= mXwA -bW+U+xDQnmOqPHcCrrDFiCINkhkPmWrmLGhblR0FjtboGNkKtl4s1hYWIH3jM1OA86nC/T6k= lYce -y+zi+Vhvhj8Yh91LnuJLJL/aX3+Plnf32/H0f4Lu41R+xe2dZ0Z09/V6asi7/g42GJiWmSjT= QHpf -aTpNFTs3NA+gB02o5L0kBW2r6vS9OehgBoSSVDv7k0xB5NrsW4sU5BgklB/PRslGjAv3z/p7= aGBM -hoV1a50zlAeMMWv6FiwhzDM15sm/Y27dz+n8Wp/H4/45Ubyy9PXeFtvnpufz/kluf+7dykWo= VN+l -JVXffs96kpMjVF3y6Jt0pHBzzuBXWVn7N06/e5bTb1zKNzeuz3oMg6/S7DWDm/VpbPucqKCI= FtOb -TTXtlK+F9W7oKGJMh7qxVjPz2lMYFS6xN66ap2fS1zDkf7fFlcnk32T7ibpL+Pfzd7NW0ePe= 5G36 -apIOBwELB8rd7yvcxvYY+HEZwdzurzC083Od4j+EMSUqJkCIF3mkgLmtfE1oP1mELpkAC3Ob= AhfR -GFEQKmqONPvn+RqVvVVWcVEJIVsfBPf3pfK+OW+/8/6xMn5C/cRDUqzvW4lhBvNRrbQBkmIA= WIAl -94FSRnRNcw1uUHhDxgKD0Mdxrfiy+YbGy8YbMqXQt1GvIq4NgJttlwTNpzBgwVwYMJ68FfMP= gvLG -k167PDteG12+suuBiazA+uNlcKxjr7/ufrp3hZzDqPOtN1yOd7a+j7O+tMVyuNGzG5G4F0Ls= age8 -HRWfy4d7H/jiXlfYRbHNqGzMIMEYz5fwIigo1Y9PBbp95lZa2lo1FM20EPRtrtSoPIh4Gt+W= g0+g -lQ0RSoBgyPlb2XhmJfruf+afOQxA+7llouSL3UgGkhCH8iGolvHpxWSUnFTW2dYdGvNQyov+= i8yu -yvj5EiRZytnMyJFlZYyzsbGzkSJEiD2tVHrrKReyJ+e2pYcwKqXrlHQIKMwr2rXBQ2aMtQ8p= HuCy -XsKiOFqFWgzesR2xvnAqXjmDErXAFpM3VvJ293cUYoP5lnC15MAvAKBgUFGa6VWPe07/VVvr= a9+v -8fZqmfVtkmXfnSWi3ln+UpSF6JVLKlAJMfbop+Ceyj1friZ4u1WV2SS0Ek0P3vUI72KP9RMR= No+6 -xJG00JecwX79VeQoGv8f7f11l2lulCDAIkgWjxhVJkbCz87OmHBb8QyDsPnPkWu6jW5eZrtb= mul9 -/f+6ojGG4EbHY444499A+dUF0penYOmG50BXG5GMNQboaggY/iwZOFfT97rcNn41F9zuNaJe= jC5k -JjxOWIsws91wafs3+B59vSz8/PT2azWD8/z7zaXveywliKU3uD2qpaZRppcwFTQDzMbjhX7g= txon -RB4ZV87NvHD8b7HdkYzUn9k+QWNA4IWjkvoyNSlVAbMmjI5DLnXbmTQGdnz5+20MfF1mLtK+= vg4y -TfxLPD2RyzBCWj0WozedcDCcEk+kL0f3sLFg7TDwLeDY2zEiRIuBZWVlZWVhZWWMrRDk8WJ4= Axmq -/i9Bhxcm1QBxWICNyU7O2KqV9R2MR7TgPH1gQNy/RHw9KJ6/T4EMFo5RYeecEDcfvhwNL01H= OUQF -LWMeiU7yRVwO1cuKT/OfLUY9mjscj+XZm8IFX5e5t7+tsF9iwnsxt4kDGTIEYBx5ImQGwIAQ= ooZj -SXOAZIDPAY6mEWlrbxySzv1eRCwJPMVwdgzNK1Q9/IgZfFBbL4K7ln6MgGe/NYFmo6oBKJ6v= hxBy -oqv0/FIceeMJdlqAQlpsmu7Pbdxc4OJ12LHFVei4qqwz7durXr9kb79r/S5iXeHfX3W43HuD= HphL -c3ltnqETG4PSemJQNH1d3NUdAbwwDfxAhSEFmY3/f+t+30M83d+O2QU3s/N/UKRfQZShNhoL= nBfk -H+8Nv+JY7HTxV124njwzdUZff/dYxhmkYQzBap4Kx5Nc8HqCgBmt4XEj9Y8a3+2pcIvyfv9O= iGnr -Bboe4c5AzA3zNKgALFl+YgG8aUIB4U11WLJMGbQ7DABT20LHhSiBBZ6QNAoIX0/X+8otm3wD= 2J3Z -g7eIQpmZjuBRhedgdk8P4JIbpiLZH1ih64P03GxHqSkB03yLtZF+A4aiDUum2OulNTlB7vew= AjbD -xjZHhea0T5XO06tHXwcz/JXgL5BZybhMntrECMXJqPIK29HSJBUQEnnayVEvjwIEN5Pnf8ba= 58Ui -iwIsMilwIW42j1i9pLWzp9Fh93NeBoWnH+QomBD29VODWCfDkIg2p12SCjF67CQYuUYGJIWO= UwNl -kc7Ma+O3MtseZlxGKZ7zqSu5/DypXr3UMrEGuYHV16uwrOQpDBJCBXSbDHDHAH+sxRGWAQc4= Cqqs -c4IuuPu08rJsDZ3u77Vnk+SsAZ9R8//5+FQbyL+q34/y7XWBzE4W9gugXrRYqsBBzc3uwwsZ= UyIk -lyMnE2ZLAUvUBkEQEzRu0URW0hwCu9ywUid7ng5fA329vndnpNrr91NsjhVCBx4fEVoPj3is= MYim -YIhMHZbG0UNreIJ2z530l4NuA5/wGLn3gpGGGgkStVgWkiotwNpLoe/gMH3P4D/Amt4P8Npf= ZaEe -3GFtw/bjP5wzw5fWmb3gkj3xyxhILHalgXR7cKLM1ewteVd/hJ5K2VV56zaa9snezO1NQLxE= QhRC -2ZU1FDlWbyiND9GX2F5iGXgNz2UEflEW7OkSkzOQ0y9ARKQpQWY+E0cyzAYyzFuE1V1cfAbA= 81Eh -0hwkZnZRrWDJfz2IDpGoFqAzRicGOCWrx7PWOkUYx/5B2w2TmYO0LzR4B+jJfBLU5vSFJo3e= +vNu -0wm4RXI8qSDE61WgMtMXLcF6BsUeMOOmZn1HPpiQqVL20L+hJ0PM8OWtNErJQHKtYlfm4gII= coS4 -rOAyrodAv+Z8P/h9TJrB/fxUfLgLQXPA0udz45ukjTfOMyCQyH2js0tss8OOveUP1muInmcf= sSQY -vzaO+49BUWKNiaOYapAHIBoJ+qXDSmcopherE5KGxtiX22HKrnqldExINpng3oBJb7E7HAOt= 48zt -GgeP3SvDAPhGBnG02Jjix0K3sGzTBELCAZeVNM/5gaIdM5wHPmKE55U+Ys6RoTF0b+ZhgWnS= NLjB -iTsmyg8EXgKH9x5PGHPzGLXa67XuqBe3QqB234ridP1vuvS6+IznbM7dOx8d6vldUtre3aGk= feN4 -TXzFK/zOdF9az67f1+V+selPutVOym6N3hL4C9ugy4+5rNllWJeTSigfQyzKs9L3khMPoMmd= z2ub -6bXsPA91ihp7GrmqXL6p8XvU28MzsBxIxciPNWowqmjhksdIeQnhg6Bg2cLQQufu0GTDqjJ4= SMkq -ZTMLeUEUKH2FZaxXFrF/IPjXlq86+8qA8b8GnFV3VCYoStLohVYO4cYdf71SemaxOUSIYgtq= f+Uw -L3H0POWRFsulSpdrduFViF5J9TguQOMgahpGMeZQoIn7I9+GxVZJ+CVRHhBKyksxTz1iMQMg= oiDo -HQI47EHr7SlinNO+kUQIpc6iA/Aox4Oeom68UdsMJwNM6JaBo/Rt9Bxke6d7tnTads6cuTO5= UyP9 -pBJbiGPiWK050GWhGkAQbgdxvp+aDiuzxvJrk0faohlx9MkLy2luWLsx+2usUbLQHxeNOS82= /GFb -i8O0PHxoEsRhu+nBd6lg+JdIpCkaYpMOAYfdogBZBgEhDomOIoe2oZj81cVc9LjC/7W6yedu= 7ufZ -ZZwGWa5mJF8YbYbx7iUHEIV5ggUOVGa0jJcupVSVz6kUrsJmc0rTihJEV+pYyVuBhT2yvex6= hzoH -8v4MylKg+B44kkj+EQ6Rc7iqXElaQrEiZ6FO9ve2tdeHIcvCeGT80kWhnIS1xt58fYM98lub= CgmQ -0P3U0Wt7+B6c4gE8gMEBDsrDYs6628E1BlpCB13f2/LNhb6oULYwlxqFECrDKcMAHcVh9f27= Ickm -rKevE6HTDuJw8cX0h37O9GcbqF55rZRLGGXN4M0q27NX8VB6A2uAyGmzh8PlN9VdsDxfqsZL= 2oPn -5vGzd5J+4XwsNAh+xHpVsZtHzqztqpRpQ0pYT1JZK277CejRdgFHTrMD79v+PrI8Ed18AaA1= 7Mgv -BW4oBeI6V4IcyYEuBoMjBqMpGebF8wDa3LlFhTTVPb1oNa3jH2I1oht2Pp7OQ0r53pb6BUnJ= v0no -KejEPO9H8t43szfX5dnHDSfyfOpzZxWnCBWeey0O17LKpTHV1tzeFOA9GxSyQOm8O+8hK69J= PjhC -QGQhMB+R5TVqkHK/5wc/v4XHUM6J0TnMMw0+5sND1Yta7e9gMnkR7yLdSoJfhxbPZVwNvKjQ= eCM0 -O63H1lLGPqXgLhArRggRg5AL6ru/Hfyta8K+sZ5DBSTyU2hz3Q0iPi+NQxtqlOTRiYYdTE6J= Qb21 -WTHJ8iuXSwB67VgsTrV3uX6S3xvoOTAH7WFlKHAvpMaK4YV3jFIMgTJ5MTgbzPrdzN08pAOG= DoIw -ytjQsstfnUoCxe/065rOfTbNMyiURsHqPtA+61Rzw9LouNwdQYJkgiIAeZzSE+iXEUglCp8E= Kqiy -dU/jU+MgxlbQgSAxzkMsLAZoW67wHUOszeBAypvXLpNdFdBkPSnAyy41jA4nCqK4ZsHIUZD5= kYQ+ -mQD3LDtYrwLNe7NmuNOHGXi2YJEEt2YQJijtOI6MuNTaSDN6wMyFAEZFkCfZJJCcsoSUZdBe= QJLW -wyUTMprVM0zArmAVlZCqHo7MEvENRBImFMSTZVmgq1VBKpSIXCZwcbDVullNMXgN7mUciKIk= TISq -wkHj2JfNPgfOnTykh0cUEYwwoXp6DFyXp1hqPBeGAVK5xo1heCw2pNnBW8aUgnF2GapCpKJv= NYRE -4SgqjFXIGQDxWIlx2mAco7SRVNWjkyqDJdk1no/cfE6CaIodPLnhTpwuROllk1k0OCJrTM0a= ZvWs -dYgLwDLaVZS6wzMYYmGsUzKTK6G3DTMLA7vKzbd1SFzkOh5mrjotCqyiom0rnGhNW1oZhFgl= ApkW -ZbrWJIcM5oHJZq0SXjjXLLpm9bXaZt2zqYUSDyLNnENaTMORc3rQjs03KomCXa0s4nFL1hTU= pNaU -qiakvFU0QiGmIKzRqId37DsNEi5lVWHizQ8py5SpAvE0zWSU0UITCKQohqpmM+v0nBm1TQHT= aabM -jK/SOxOiXX0ph5dC68OlPb8+RrZhYbpbDjbICiwRiMDcMbHNaMNZkmknOwDeuDgDjbrou0yI= wt5+ -uecmMNbCF4ehJ0cNDgQD4R18TiHAsrvq1DSLplYD1NDZqnT0zEWEmCBs2+h/JvjQ3O0YoQ00= uSz7 -bXGXjDIVADQjKVYQpfDuB9aynCG8eS7lwO0LxbvwG1FBrELjmVOolggDwKm/mAIanzxT10DL= 8y7o -iAge+WCggdYW2kVmiLu3RY9J4d15LNajvTlWf/1VAq2a9zINlh2owNhjHE8fcTBu2MSGSCo7= 0ZMd -0K/S6WNXCtfJjrBNjP6zkvXdTB54X+nsXMaNvvvYaXpChlbWXzkHBxW1DOcfSgvRIO4bbIvL= QF70 -1xw7rj+YOOppaOiqKmjEGygvUSnOue7qm2xy4J5UgHt/b907kfVxs8ZJ7ZCesVgqhfBYcIfv= vg8j -8vv5M6zGK9lB3cYvjuaY9znv7vY3sHjDkmE8E8YyIzi1Wzw5YqAa4xrmMLANyY3vUSUscz0x= q8QY -1dOcStUZcMLx1O0ObPPInimSYlMeJNSZi/ebnY5lFJTEMW0whpWHDbSY0BydtEjBmqxsIrP9= 9q8n -LZF0pSxVtYSxJ1JxmfBMfFkxuEnTQp+8npuhBgJta9/0vhOx72zsJDWT+/f8lHpaedrOcjTR= WEeD -Rz8OVQqLxWu2U0au6Mw4lljKxUXqgjjJhPMvHVvmrhWwiuW3YMabChaPCqb/rrB+0W4+ww0w= JL44 -yw6/xOvbw6qAr44oKUa33h8tWZejG8RYfMF6pt3dFWFBgyffYMw4O7wSFuwK4AHK9bRqbVDw= OoGr -jeM9rnSnYsZOh2tFj3MRxD2xsWOQdy0u5PEiUoRgknA47pwR4ZMmyhuIRkOGriQBLc4t3/WT= MVh4 -jbRJoML0z3RJb4woMifFA+QeBEW94B+8bxqrgyJrFfrYoDwxeOENFpYTnEVxaR2lTkNucm7k= 3PcF -ObNfClYqFourKrI7v9fI6PsMbhCfNPK0gnOZ/GQtTFJm2ZLGj91r9yyexqVFCNaXtE2OG2TC= kAWb -Hx1f26ihYgTjciqu6SLHiSePCOhzpLIC7+YSevaCz+/oHA9XOd2p2p2ff0s4fhtyyW6lMXqL= /SFf -pfN4cdG1g8Z/5StyW0MzUFDVcHfhpF5CBVhAHMkT7t96oPT41Ws7GbSQyJ4dukXRQIlgS4GK= 4DoJ -xIsV8BrGUCwig7gUJbNn72RXlMA7l6D9hk7A+UNq4APvjPF+N6Fsq6BEWv5dtbgPCmnMzHAE= SuEh -nXMa0b7hBUfUXtV187PM66+w3TFnTilk3psRhpc/VZn6Wi9mpFUQ3Jgal+A8DXua2Q6nIhcA= yw1F -rLzThwcepbyWfBd/Z7vJ8zeTe/Mq4f62ONZ6rm0B498BzlLfIr7M1hO+huVLMM4oop5Iy+Hf= ISzm -ACWWcBNb7MeflYjrOuppuBGQB49T8JgL9wWXqAyiYWZp5xgQXKl75U31PMoNm3ue6jgRIlnH= MIAa -lEagoH6AeBj8ehgzxotX0Apkjw0AvhVH9M5W9PVvz8Cn9va+7U7Dvn+/saa9/vzPz5W2dTJO= ylTE -0YCEUwslmXwGFmYWq6rpydGeDXuPD1t1826GZxtcwC3fphWmTGyJEpSiHKA02QMjZgKkU3JP= jeT7 -g1pm76bt+03okkds3OnVQwIoxCcl/OY4J0MbjeAn5GpfH7QPimEeTkYrSsQ1z1+5N20OvuBY= jAcD -yxJTMaZIbIaLH0oPIGSIZ6NPaNRhmsZvCBsBMEeR7FBQ7LFDwOPsKUtuugZiSWaA0Idlg2Jr= 2RLE -ZCCMhCZCBKMKMkiM9iZJ5STWoITp54ENPkBZt8QSv4wGySTYQ+RCG5JoTDKHCwkw3WuW65DP= QzQ1 -mGV5QH0KnWanWnYUOxTlF45zl0HWZtOCopzglF3ZRnGbcmw20t2dC75cuXITbygOCupxBsNs= 3Ddj -CGpZKMyMqmeQbOZyA4gjBVxorNFYmQoZepqkFJBCOl6Gze4CAWiR774wbC4OxyBspmfVI7lK= 8u56 -5GsrvZwSWAfGmUFBDGwKNiBT4e8mdfieZ3g6uOjlZRCvfHEUcoNW1KrW0oLBOnxeXLovhmjx= dGvX -X2nmQ5QSqaRMGipyOn6qAWOTyOuwraSWQ+Rq3D+LT2fe3xYAHWlktFFRYosHq6tAa0whTF9Z= 974o -ZnvbmCVFPsdWR8nuvUl0svFzC3IxfHowK2ZENH7OGlDSlCEeE5I2OxwylpLLC69x0f/N4NoK= 3AIf -Bi5M9Hc2KFMXhCRcD4Mg7v778vA327yS+FaO6/9Zv2NK6uCfFHu0Tcx9bo88tj0enkefAlSm= JpAW -LE0tzz/W82T+TD8Lb+uKN/DEh4Kl9YA1HPPQgTxlOvJflOk+bDOfgPBLdGB80dUNrPXpS0Rf= naYs -QMaBsUkxEq3M5N2XIf9LyiaXXs5Wzsy+JdyMM3xr2/s1IQQx/v+Uo3Revv8i4nqRMnXCSGLD= 4Xjj -sfZotI4apGLCOYMylQYvx86mo9b6fNLOyUW9sghh4rHs7veZARwoA8xchm9rxQk3gm+VcZjW= LMA2 -gd+Z9ZVJIfHBM/0ENrjx3Emo3RP84gkb6PDkpM0ebjHNvGvlPl/MwuGjLF2Z1soGmwxjDx7e= tzpc -ab6SczeRFGDmMEQgMXWzIAFshMz6KeJOWuojA89xnNwVFWd/QJ09Yya21MabBvWDetC2lLJH= tUYF -EBkbuz0ZekmPEKKZ0apEGDGti1VPVe4QjpNJaHgwhycaPqamqaeLhWnuSYEcvCNSAvJeXrp5= 866w -hVNRJvCpQw4LxgR0eEEiiDGaoV/BNESQt80QmAfjaZAYIG2XUWF9gaukVZrExQwMuGRjmVKo= kMcD -hqkhIUu+7tAKvo4eiaHtauqT1FkcLRuYF45efekGEkHnafXlzVqkE2Pp1SQ5ceSI6rhEysYJ= WRuz -z+r7NDodX8G0+i0r7/+uOjZcQ5aYCEhgIiBBHNRg0Ioq0IwEArPBfrnxvD4Pszxufn9n4vp+= zzg2 -1IdPY+eDWiyZ9PUKGKHLiWs6EYutEz6PHq1fXwN8GQc3f8TqUYXD4hCWUydqQ34w0s5bBR2m= N7a8 -qXz/xdZ7vua3o4sDvYgiHFx/su2A77Pq3+qo8d2hUi9SXs8hxI3Ic744Xp4h/WeJHtvqYhNr= oO7z -zbysI+ztt8zfBjXhIuyxe5W8lRa0dOv/JkLsQzzsD19k3XoE8sL4m0MTSb50HYSojGJIlZSL= BVFF -kUigpAjhl+d5R+b8i8Vie44QgMPTvVLgYVYtlgZ3IJFf4ffdxVYHzPsZ9uIqnn0oqowWRF93= 7r23 -f+2OOIwVYNg2vKrSkL6IgO/9IOA2+o5hhZnsGxofx/rfYzff5HBa07gBgUwkKsvAKaEgcA0l= mcQG -+4Y244OOkarhz66qXGPMrXWW8r5JthYt6Be60sVweWeQg7BF3mqnoHeo5CME8v1655968WqV= gokl -CpZZOs5mNgEG7Lmxa/QxjaUu1H4PStyKA9rqbfGta9RaBadr/3Ex6aJoEQUBVIrQCKCu9geQ= mh3R -73aCfbDPniERhN4FJyHshkbr9L9of0pYXp4G9Pitpr2+DUVbAfJgwRGYYSY3jbbLeyiSkHvi= gM3W -VbemRk9vlniurrGuaDCUR1cPb62LbpKw+QD7EUR+EOG2t3hdeSoBm9Ko3SIKYS32YTYHjyGp= 4sew -dMnM8oNPB2b2AKfAuMsZDC9Z5fTJzh0HSsz0Id4/HC9wslFHBrRqo+E/dBtysiehYsrOWFRb= x4xZ -waNG+iRB8FkAZj0R1mdQeiMdnlfU/uDvb604fgxVRH6hqrH3KUQ76BYTVvgOw667szdJhvc9= 5MYV -DttFdl0iyY8foU5IsytTjSVnxfpYaIFog2hd3jrqOCE6J1AKkGEKtIr7F9zk6bt7kCBS33aB= ZjSA -IrlQAxo9uWv4hATucXr8i4Xs8gt6LwmEKZlnDec2AS7HeOzhD+8Cc8094ItKlug7k43cZCpN= AOec -gi/EFdJluRbCoyuAsWHhJbxWqSjUX0mrUPCAevhPErNtlOxyZoCnHxmZjLKRQzyJn0vk4+Ef= W++1 -n2h3Qh5X5G2222KClaMWNjmZRqmeGosI3nfAVZeYTxSdc10HnFcz6iOxeAGUZXbOzusEPGk2= 9Ozr -ovKqZVoTjpzw6tK4i3+Y62mOxzmbTWZH2xXR5QLZCjXo+105TQmSGhCGQxDE0CQKK4DwLvE1= /4cz -Jrb1b8zkF9Hknui2Syc4zM5vFDMbdSkWBkBwgOlWKBm/UWQqCvwSlGpRjbPtorZOVY0dhZ5u= yA3b -2TK6CPGGwkpKxsFqWlsE0NI8Iu1JUNDyiF4h0s1ZuGY2LyWrv6/wNzgtu67fCr2phXYVMqiB= jL5L -c9ejN0qgr1tvf6JnqtSYZpJV66rhWpvq5DdCCG6SQU8ADEpAb/8Q8WrbOd4GcrylaNjVL1mk= Iyii -QNPMF8HdikRFQB28sIBVaTlPTIQQaWxeIq0QeIMCzgu+UlUQC5k5F/LimRiw9mDhykCIsJiA= 4Or2 -dzSh+LLIYDgg3mGEIDpsIYGF3bgLYqsQZLQiXtHvJ4fzPvLMVEjlJxOhxZXrDnu0OJujplwL= qDVB -IIQ1Ed07/RlH0zJEXZIbyE2lNIH/rc18nngXu6w59NPC8882TpC0T5ClEREFEEilaMEVKhUW= B2Tj -vd3u9fR0BDfE/Xm5LSJ9apk/Fr2MWSXoTOUgdOTgjwLYSad3VvJdvsN0YLEAeyarcHPV/wKd= /jiB -iW0PWDC8ry52YOx7Wz/ZK3Xts1LO9FgMr799whSuNDLMEDTY+VewjZCV+YWNYwAZgnmeGeTo= SAFs -Z453uE5RKcTD4T0IXKgDCj0xLeLJXZKGajVD6/D8Kmabeq4ezpxJpd/BwaNeXSpxivB5/zz3= WpFV -sqyVq+qupFX4KHMz8BNRjRT29yW8mcq0EFod0/TRCq8rhKY0E5vj7sHNam01tvk+nljq+DLM= gOYN -uc9XbZOzDaY2u8yJbeYu89nNKD/DYpkN9x3fp2fP7RZLAhmWnGsBiD3lQRVAEYwhi+R0y0AO= 93tN -E/HDK4mICD326jvXZS2PauTlxLo9rEKIgWHgLvaMNHJDJO8I2gXXNa3kHYz6NMHod4mpzrx6= 0kaU -WoWVl8vburY/84WfMYYTDtQFdphNKCr1qwaw9LpsSfAHwKWFrN3yLJP9prgGNaYj5eIZB1eM= yFnj -/LjxycNBIE2SbDPInj6768+85pG8FzZMQswY0aIwUXhGiEhoYMjfEV5N/78z1tZrdzy7rzeP= HGFv -UjfzVRaLDsXern4MOvqAJW3yRmvFwXe6h+zbR7zn/i9TkbJ/JGROH+GVp4W6wVdDzu88V1Um= 946f -wWm9SpGvrfTvhntBGfHyH8WzLeXG57FFu2abM+xPyR036jaNeaKh/DtNGj89hcCKVAFboSAl= q1fE -1unG19tUykCIEODbfqL/imhXinpkEIZ9A2pIS4Cn6WGZdE0tBNpjvmP/doR434LE3nW/EHVh= t8fF -ZwSrxgNh+YMwYclamPdiVAOBpboZcKQgemnFUDXGtQpf7Cp93CieeD/ac5d4yri8nnrD2zDk= szAz -mFuGyBkuJIVx4QrcX3c2JwZoTU/7T2JB6b6simKCdFSg4cCBAkIgUEB41QUpAvtyOviUmg3z= j1cd -IR0mLPJL6cYI26DwkyhCpRynPLj9EN7FDeWMFN0LIgggsFR2FZaaaz7S9syxBlPOMwYMEYT9= phc4 -ZfBAoVOrZTEGREp1ZkXWjWuKOmkmJmIhRI6BY6OTJEEW6HfX0bOzjlRJVgZa+RR1vr8NtvsS= Inj5 -cUEEdwwsWsp35F/B31u3XIIaqr1KcodEGdCey+Q68N77oYfHhImo6bhGE5neYHlNj+LEMvzi= gQmi -zw2xz+K/vx8kMvriISu3Y30WPp1kDDxbKCVoTYD3iY9gfXAaHw99sOvrjfhx7UIC9lpUQxpG= wAz+ -ODv9AmM0NLkUHWKzCbuBKV4purJBJtL8d8Iejy7dmvCRVqU6gXt4oy2hg6vw0AsVIbVpCRMR= SlX8 -keCf2jUfqJm9cPCUzUtjwKtXIcBDqge9Oo6y+u91XW2nVqor4KBbwWLV7Mocqekz0Rx8b8v6= c6+z -7OfE9xfvAtjVtQjPr7jBUTLSN8pAoIZHqlBUT9nZppkQAB6dDKv4Bo+2vIExxK3ItNDm5lMt= a8vP -rdCnl+2AhWDIEQaZCYMeS/q/WU+w5+CGmhGjKLadLdM2t05MYpOf4R3vy3Jtxan+/4eUM6fi= 8yRX -JIklDEiswBsAbBeAxtAs/Le9pJjYYrBK34kEetWkHuqWdaWMOkWlRs+1OugZBD9d0UfozQdv= U9Xq -4wDUtOQHgFPbJVh/Htoz55+ZZp2Ifj3OFtRN349KONW+bbkQdXys74fOX5VDkdi/ODOc/Y1n= yiZj -np8/odHZ8SwuUmZYXOWxvmVwrlKvhxvoKOdQnQq2jkoJ7S6WnjCoWEctEYOSqyai1UcJYYZO= 0nCM -IY2BJaqC7SrDSsdN48HoEF4rvnXMJZ02jXcvcLjRinFE5FwIr0YOqhCgUErhDyVJ0QDG4/FR= b6l6 -5AKaSmbU7fyHjmj2htnd7j+WZ7ZDJ1WowUEEZBEnmnmUoxTIyijqmZERKNUT1tphbClsUpaK= RSKI -nwTeYcgtFjEjEUQUn0Igdh6NmzJ67RhjKXk46sqBt3lQHdKhu70ca1tREbdZLiFlzx80iqa1= QxEY -j41uqWPsH2HHyfsj7n7n4fcmk2FK5yxJGCURoLEJ43j+pDfQGXyxBvAgm4+BJ/9SNUDzGvpq= rXi0 -MtDPoGEPfYOH9bpSxHTnv1KsXubnZEjzY4csfx/GrTOo1XJJbob4nTDcmtpvnoKCj5owXxhn= Y4JQ -RZzkAxguEPsGZPnDjyGdvgRxtxuM61cpmxrz4gabU6S8UB9rKadVwYDp+nZhhOLMdp7bDF2N= 9AlV -2zHaLNo4U4+iMNnynKFfrASJEiKFRqWVAwDznZmFLdU4vMFeWP1/Ni6lcobo3V9MqzEuE91E= HYNx -zXfkGrEQmXhlM4CT1BPqDajE8qM/RfuGP6Kd5HIowvJbdSjB2bivEagpmEMOGEMc3G91ycq+= cdFy -kOar6GFy8G7gfldurCwqE8SZ2xB2Y2zEzK3oke8z7KV3gwCz99G4aSDK7Zwff2cRT5jRx42U= +SQ3 -enie97CpYSbR7usJ1ehLAqSVc9CXdMUQHlmHidi/67wQ1KHQ+y3OECI/I6t2iwHANFwzAZCb= Xmm6 -pxCM3AajQ3nh/vzunZdakm6xQhehCgyIk099XuLG7pRJNCHmuDom3jU5GFc7LXoXLbiCo5jS= +kZC -+9JBYa/O84hbGdj4sxeaY8cbRp1RA1NmP+zIkDPxHBd3dqWdQRlh5QHzsHnf4e9992Pk9/eb= CeSL -VW+1mojIstMHfDK0CfNEGjZDQsHX1x5G+yEy8faCeXBgBmEgoRgFMJm+xllfly25GKM9XRaJ= FQpG -DRYpUwajk/lqRn01qWmKQOEU1RmYvDhkjpVFv1LCXoF1ekpmWUyx9X1V25LOIxrAEmZdLkmS= a2cX -B5xQMXiyIzaomxtPXkySRivE/BiuFRGIyKzIXUy/LrU0FlrQGoYqXtndwbMgvPsgbcpRiYaO= NkV/ -UpNZoprkJUjRcad6JygA+6yTCga08+mizjO6qkkWaG8O7OUkPtp0rOwsScghzY9C6Ui6h8kY= ivkc -nxrc/Y0kGRFtpUMucOKMKblgMwS7BWxONIMEZ9Ir2ZLLZddf5+7JQh1vpmSdaL6l7W+jw9Hs= 3sJd -XPQU35hTpZF+lfJTaKbhpmwTfCzmZBmnnZliOWtFaqa1QmeJ39fiKT2fcRjkZgDqEus9L8JF= +hpQ -ODMsNNiJmr8/C/PkL1uyxiegur2uKI0Za8Y+7QYdOkP8n8K04Htpbr+HI4zNQGblAM0R4oYK= WlCF -An9x1vWa6meJZ6FMGp8ZMy/SMLjPk/u75j+52cfVunIf8KfcK6t3ZFAQH2R8gS9tofqeDg6k= Vmyv -bDBYMbayVUCDLyOQMODjuYAP5ATdrjna72gsrsSI0sMfjqm8reI0rH35hLe9VUHarL/a8jpY= K4wM -R2CDCkn48bIw8FUcPB5VJF9elWDkPA1Oj6K2ntuagpHrz/BTStgvW6Yk1jGjq9iy6ubWBcED= z8Vg -DvkGRDJeQnGtQgSHWONgbFw2oUIqiBReuYfBlNOnfHEN6PaQiQMACot1qLF/IoxFQ7vpcryL= HQ1L -vGquouMtPGRBCCBpIKYvPkYltdsPVnbLDmH/xKvhDpQ/Z6O6buYQG0nqpvWULYNUCUip4C1V= mPZ0 -jLBh20lk2TA8W5vGe98ObkrhoJqu4iFil5PadvTKqd9AmJ7ZfXBghZBleI1ycGOA6FuV2BYu= 003R -alsBgfmzFZBvRdPOGqjHZNqGVDZvb0lquDsAcHJ7eCR/ctwZkz58v70jEfBeSvtHZ4oTorIA= WDYl -fXSclvVERLrGTX+3k9q8HRvjIC4YAs7HfzY41JLlwuxDdOo8PhbHumPsPQ/Y8HwVMyJJoQjd= Szia -NdT9blS+HiUn965AemRLyr1CAuDmzhwQjWm4LsZFgZWR3rnYcTIhILiIY3kKzjWWSkZi7k2V= ttua -oYS6RSyp+VbGJBEyiGqxPI+QjzrnzPPwWYb8tpAIhVt9iuEyo5FD2L23/qQR2Pt4OjouYFES= O51L -Euwwm/knq81iKM6mEeaNNz85sDqSWFzB51wzjD84CDdnYfxXIQ8DhXlNYFxoBLgDKEczQJVS= JIj8 -DCf3UASyURtlvuKHBTkBg5BCcGUJAfhUIVNE6TrGFEtjmua+tkDaDkD7KbIV0CCsvQW7OnLi= doB+ -dSBESWQSlAS1o+GJKZ0accxB9LOItr93yzjoLcXLv+OsPOCxSi+fDD070h7nEdV5lbPkkoOA= zAPq -HUqLIGUwH1PdrFtgtujzWIQ5ISXFeGHcWpmHYcEZH5Tgb4Ks9On6M9iFN/Whf3MhKOzQT5ib= IwCi -Ii4KR6YLlJua5cu4AGjOfMsBsPY0MBjoXJnAaDMe2i1x7WkNPYuDq4QvU73PPD6nElExCSXN= zepl -JJKDPxGteq2eh1pVVe3aqqvKL307afmbedv/R6X4DKGesNGC86zmxLfUQFmmCGnmvxfI/H4V= KPzO -HGj413rTOVPUKtjrUaNoGJM5TPCE2sUclOUIEpYrZ0xjfUaAvfvc9jljwcdkXK+UMLe1CWK0= Cvc6 -P9GBgyyWfenqxkOv5fwrpPLZvKau8mXmTbiE6IWThbVwnlWCqXltLVxdSXI3+Jd5TMOUFId9= uILD -DMH4l0rbGYlGsBc+b+JYcQtgLlfATa+QZG2VXjUDlNaoW01plDVZudvfb+47Uq0HxWWXrmIE= WuCT -NA0KEG8/RglqkQWbPvIhpAyQJBLjnCdwBNucIp1lm5e798Uu6Xe7KcMdKfr16oXKsUr08oSQ= puI4 -Q8SIw4Z8lRd0at1DztCwwcRHhOjSlfpGNiqy2ZVImUpupM5TJMUAf4mcAw5uDZB4yVQgMzJY= lkpQ -CI7gYSCQsWl0vMNw7pYeLGgYT4fG2UB4wQBV8rxTtp5amD8892awYMNMIQsSRwVXOUhXdb1u= Kz7V -w4KiwepDFdoEDrt8Q6WKgFJHNvw25+L58uyV2qWp4Zp8MSxi6OdY0CV1zMWrhCic36L4TX6j= k0+l -/Y+5wrwbdh8oMZbViBcTJxDb840RUq/4cU0/C3+7+S+aPturo+fSpW/Z9mmLFRjQoVLTofIN= VlLW -UoVKcXFwzJS0Wig1paHfcBx+1t2jLoMqvbmqNuNtuZgsXuMqL022ceT8WxS9x9amFh2d8j+R= N6+p -11Tteu4mux3uedwTh5lvnT6c+LuTgdiHSPOlVFERE7GsMPoJBKmVnTvAwYIydR43M0anQ07u= UkNJ -sUts3dK1/CLeBu0iQzDLtB+1VFo/h5eRe7KgwVWXcMyYzVzdhj0fb6SlwkuI2IHg32V9c73U= ybBp -DuOPcXUiXd1QsJnuQfBpXYWMy33OerzGweBarGjuPqYc66UpNeXcg12Nw7PBLvgFuChlYepk= 9gby -jrVBWxAtyuuTHjToKMu2SMGFYGaZo492it+PmXMbLzTOWC0212ycanf6ct8MoFIYdKx+bLo+= VtiR -b090XtSiAbHo5eLlbp0MyFOTZzX3IINzcgxmS1VA4jQEyJJcVbtTPk0FbemODZ6XJTNmqXhd= u4Zv -dreUljWi6CZpGadMhsrUdnE1NU7e9uLlMFAJrHCYJOfvM5FMgjLr3ANvmYqmGDRSG93XI9j4= R0TZ -ICyQ4YQ8cSHV5c6CD2q62BzToX6ecn5r9AZxXzGl6mhMkLRftUWzKzCjcV6xK3wNzLxetOKg= EYXv -eVWLdYuOrGy5ihJISkHTYEBuFJyjBVZ1ptnLnPziLzCfiMR4LBYmFF164w2WvCeS1wH8fp5O= HilT -dOnn+zQETufMqJSfYeiJeUM4TO0YeD7Nbn+toH+UY2NjqixKNS3ua/5eBE8rJjR4cTZzmLRN= T8iR -xUzv9HyB1HER2tUgVk3M6UNk8/c2TdcCjkzkSIN5HFSCVqvxOrH32ZSF8eBeikrQjaanoIkY= ERII -HulIC1l0HusgHbqhAHcxTc+edGgPO1BV3aKNWxGjHitQoUuR2B5lzMMx955uHdWuVEmAuZNZ= gY0V -CEUhFk3nQyZT1WcJNCMSQUYhw6E1JEQhNn2d93HnE1qPshpWlX/YBXAOHnwaX9GS4Ytx535X= RbQV -F6qGF/eFQsMiiY8RelFuLcTUKE6sw4aD9Kt2pYejJ+pMO5mT2A8q30gld9xxJhUR6OpjiyOD= SRXT -ogCRB1rmcSLgQiHnhJcK71wtRAxTfU4y76m+KAoexuwpX9vae8SJu6Rj5xE7ZWqbkB9PCR2b= 9Orh -Fsw77X2Er40YE9wYfD7mlUNTKia5XXuQ/hWJmoQjxbkYkwdGZsVcuOKlls/GrNMayvRayXa2= iquv -hXrOtf/Drs37ndEFDAA3hzDQRanpUd5nER82o9eqthn/iOTmw+LoFtu+Ec1xYDgGU684Yh3C= bMKt -8VFmQMc64GhmH4313XafM9In/aJpU93TdicROhvc5MEq7G1x2BaaWJ1IRisnr7T+d8D878Uq= PgtB -kl9Wv82/w6V72SWdIrRj8Y8xuknMJ0Kz1wqyxsHgcUS36VFqEcJhkfn+0FewZRXuSK8iHZEW= EROG -5K2hYkGboVH3nZzFXkGUsTeZuOYOTC2RkTjDb44QEv4zqclEi99y+Mquz6NTbCHCYKJ/HrJO= DYDa -ifF29SGDSPY+4gLHPB7jtD+Y4M1SQy27OL/pcbvn/G37hXw4w3KltkU+59nte25/b8XtM/8a= EHLJ -wjuxldlRciSWYcctdnOp7afL8Pu1AdsDBMGyZIuXYNNoC6SLqFFzLlIZq40z1Hv6/+nq+LhW= 7T8D -CMo4+JZ83S/mK1J6LlcshspfUysoh8uTAcuPNtxzejDeIX69UPPMCAt023DfNpttX8xO8xXw= aliJ -KwzQyHYoHM32xlWPFym9QdotzVOawnfVpBpTn1YUxKUKBiSwaOrOYqJnoZELgkXpLAKdqDye= 8rC9 -s3oDgpm+GdshEiUGYGSeFMUrjxGDtrRVMQqBAKMiBOT+tfmU3EqFfDReLvlt/L4bTlgTwpHI= 9mpF -J70WDTWwUoUcqFC7ZxXnAwfEriQ8lYS+iVE8QSNyzkDv2uCYC43BnCs0NFtJugYTCALO4k6N= znec -3u/nu1EyQZt9B010I5f3GxoDioUgoTsB1ZPGPtat1dPnjsJ8wavX+53ULfSMVHaRFxT9MV+j= 6Cex -3sYMFE+r+yznqWD2umvBRQ9t4HR45qHoMjaRRjcQRsRVsQIQKmHQF/4VITiDHidWZgiLiEAW= pmlP -LsPpuDCwTR8zksyJIximTIy0VGYA6L1B8PlA15luABYF78ly3FL8FFUx+3jUkaNWFUDMXTaJ= 7I6g -Gl771ahmTw9KPRkrWiHf9gYTxPjU0eJM9N9EB5Y9JYtrVVZ+DzMW2Mo/L+tNBrRZYm8onfho= xUaE -hOh3dHMR1/CuytPLRKaUbzkvy17pFl/AvHyZYGwYe+ccT370+RTq6OM7LzZjj9N2tY/oKWPl= so/+ -nl7uwNM2krDxkrPrOLM/0394KPZ8L7Hg0fD86zu973/0GuGYdhKA7d6waBYgnBgX1z802ha+= 15vG -fxz9E+eYs6vrNle8vURobXnaWHkZvXxS3/7y6iQTGtl2u8hTY8UiLzhHQcOs/sH0O9lU4R4p= kEq1 -sf3i2uDG2GaxZB80MOA1mmUiYGHhcHC2+nokcgJGuSigCyMABmgUlizNUB4/uBd118Vckt7F= YYxl -2AofZ1erzON49NJrdc/DdG7RfWvpLXYRtO4jlQ1fQSxRHGdjeQLWjY1kh6H6uxysfBoNrcjg= G6bV -sNnLzOwJbGzmyD/geqhnRBOri73FK+yZtXU35nqcwGMbOhDgoXjHp73bFG+j9jzKN1cye7fy= mvn3 -bqSTd4Rcgk0KUQoIbM6hmTE6tjy14n1VA/Y1aQtDoe04GbneN6W8aiZfYpiaHF4+WnbzWYT/= jFYL -pNBQtPS7KGDVNCVkyBMoEIZYMKQLbxGi6xsTtMgLDA2meBFs6XE5Qsk7dBQZQQnY1Oe62o6c= 36t4 -TggdU58m00/U7729xLY50Y2c49YkJkwYViRGskH5P8a+xom3wLYg0KO7ZXnzEqGR+lgsHi4S= mxDa -vYmTVVGKog14b8IdmqeCwX8HnnnlcbtP42MTYeFi39WRAAnsIFaD+cn/rcdfkfbudry+vTv8= K5qu -f+WlY9DDfBbflz2r9HrfVQjzsx7dXUUm8n1ztYvhQ7ENAsacxQiMPfgl7Gr+Ks6DFx1fLVJ0= vN9v -6OT08VJ3+T63z7/N3HE8jF3+Dg7uu28PKZX78fPW15vI+srPwsK2TW2cua+apptrW8DJfwJH= U733 -JKoptLHdr8c7D8LmOgq7TfZvLYi9jWgdcgUiADjLhJLPwl76z4B02s5CCScIpyUCICIuxFDB= 2zYJ -s0SIZ4M6ahruHqIbl6Rt06HRkoClYAwokbTowKUoCIgkYm0oMmMNJQ6pSQSaWBReQyaJsggj= wGSX -n1CAv8YxT7Eyff2KAIoyB2nQyQnyo9lkJD2JooQnSkIeFOSB2SNoUUiwEWLEFixY9R4f8HpO= UnYY -AbOhpDhToyFiY+kskk6tsvZwR7oTOeQggjNDB6xGn8m6dJJ62Iih2CYG/lWLDCuIj5/k4zuf= W0tJ -5sQySTCQBiZDmKkMQgVtoqIttiiT+v7zw+H/F2s4H8xSc4Y3oaK23v2VURWIojDqbytV27Sa= 1LDi -27os3opje9eGfRunfJcjci4iy2iqThObvVDbIcsMmFO7cwbCptAuLSsOpMZwzw47dCW0637i= MYwC -cw/3fxqI4BkB5hhuiS58PK4Cx4+zT/hgAc71UArDKx0d5pXcpvb76myEXZVKgHO07fxvN7WQ= 1+Y2 -ZKVzdT9efaG7Oa+TmTX7/UjtD15109XfGOq5oIK5LI38PscHDwRPr3WG6X9ud/qL0Kvn04cD= 5uJi -PLlZTv65C9kwB8D7A/bl+OzUvUICWMgUpUcXLSdaj3+lT6qDLhfecjue+QEwo0AWYZWiIi1I= GbIL -WmiaD/8XckU4UJAgx4Xl -=3D=3D=3D=3D Index: sys/contrib/dev/nve/nvenet_version.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/nvenet_version.h (revision 261434) +++ sys/contrib/dev/nve/nvenet_version.h (working copy) @@ -1,29 +0,0 @@ -/****************************************************************** \ -|* *| -|* *| -|* (c) NVIDIA Corporation. All rights reserved *|=20 -|* *| -|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND *| -|* CONFIDENTIAL *| -|* TO NVIDIA, CORPORATION. USE, REPORDUCTION OR DISCLOSURE TO ANY *| -|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA CORP. *| -|* *| -|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT *| -|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED *| -|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS *| -|* FOR A PARTICULAR PURPOSE. *| -|* *| -********************************************************************/ - -#ifndef __NVENET_VERSION_H__ -#define __NVENET_VERSION_H__=20 - -#define DRIVER_VERSION_MAJOR "1" -#define DRIVER_VERSION_MINOR "0" -#define DRIVER_VERSION_PATCH "13" -#define DRIVER_VERSION DRIVER_VERSION_MAJOR"."\ - DRIVER_VERSION_MINOR"-"\ - DRIVER_VERSION_PATCH - -#endif - Index: sys/contrib/dev/nve/os.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/os.h (revision 261434) +++ sys/contrib/dev/nve/os.h (working copy) @@ -1,128 +0,0 @@ -/***********************************************************************= ****\ -|* = *| -|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL= *| -|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY= *| -|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT = *| -|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED = *| -|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A= *| -|* PARTICULAR PURPOSE. = *| -|* = *| -\***********************************************************************= ****/=20 - -/* - FILE: os.h - DATE: 2/7/00 - - This file contains the os interface. Note that the os interface is - itself an OS-independent API. The OS specific module is implemented - by ndis.c for Win9X/NT and linuxnet.c for linux. -*/ -#ifndef _OS_H_ -#define _OS_H_ - -#include "phy.h" - -#define HDO_VERSION_STRING "HDR O: $Revision: #21 $"; - -// This is the maximum packet size that we will be sending -// #define MAX_PACKET_SIZE 2048 -//#define RX_BUFFER_SIZE 2048 - -#define MIN_PACKET_MTU_SIZE 576 -#define MAX_PACKET_MTU_SIZE 9202 -#define MAX_PACKET_SIZE_2048 2048 -#define MAX_PACKET_SIZE_1514 1514 -#define MAX_PACKET_SIZE_1518 1518 -#define MAX_PACKET_SIZE_JUMBO (9 * 1024) - -typedef struct _MEMORY_BLOCK -{ - PNV_VOID pLogical; - PNV_VOID pPhysical; - NV_UINT32 uiLength; -} MEMORY_BLOCK, *PMEMORY_BLOCK; - -#define ALLOC_MEMORY_NONCACHED 0x0001 -#define ALLOC_MEMORY_ALIGNED 0x0002 - -typedef struct _MEMORY_BLOCKEX -{ - PNV_VOID pLogical; - PNV_VOID pPhysical; - NV_UINT32 uiLength; - /* Parameter to OS layer to indicate what type of memory is needed *= / - NV_UINT16 AllocFlags; - NV_UINT16 AlignmentSize; //always power of 2 - /* Following three fields used for aligned memory allocation */ - PNV_VOID pLogicalOrig; - NV_UINT32 pPhysicalOrigLow; - NV_UINT32 pPhysicalOrigHigh; - NV_UINT32 uiLengthOrig; -} MEMORY_BLOCKEX, *PMEMORY_BLOCKEX; - - -// The typedefs for the OS functions -typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_ALLOC) (PNV_VOID pOSCX, PMEM= ORY_BLOCK pMem); -typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_FREE) (PNV_VOID pOSCX, PMEM= ORY_BLOCK pMem); -typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_ALLOCEX) (PNV_VOID pOSCX, PM= EMORY_BLOCKEX pMem); -typedef NV_API_CALL NV_SINT32 (* PFN_MEMORY_FREEEX) (PNV_VOID pOSCX, PM= EMORY_BLOCKEX pMem); -typedef NV_API_CALL NV_SINT32 (* PFN_CLEAR_MEMORY) (PNV_VOID pOSCX, PNV= _VOID pMem, NV_SINT32 iLength); -typedef NV_API_CALL NV_SINT32 (* PFN_STALL_EXECUTION) (PNV_VOID pOSCX, N= V_UINT32 ulTimeInMicroseconds); -typedef NV_API_CALL NV_SINT32 (* PFN_ALLOC_RECEIVE_BUFFER) (PNV_VOID pOS= CX, PMEMORY_BLOCK pMem, PNV_VOID *ppvID); -typedef NV_API_CALL NV_SINT32 (* PFN_FREE_RECEIVE_BUFFER) (PNV_VOID pOSC= X, PMEMORY_BLOCK pMem, PNV_VOID pvID); -typedef NV_API_CALL NV_SINT32 (* PFN_PACKET_WAS_SENT) (PNV_VOID pOSCX, P= NV_VOID pvID, NV_UINT32 ulSuccess); -typedef NV_API_CALL NV_SINT32 (* PFN_PACKET_WAS_RECEIVED) (PNV_VOID pOSC= X, PNV_VOID pvADReadData, NV_UINT32 ulSuccess, NV_UINT8 *pNewBuffer, NV_U= INT8 uc8021pPriority); -typedef NV_API_CALL NV_SINT32 (* PFN_LINK_STATE_HAS_CHANGED) (PNV_VOID p= OSCX, NV_SINT32 nEnabled); -typedef NV_API_CALL NV_SINT32 (* PFN_ALLOC_TIMER) (PNV_VOID pvContext, P= NV_VOID *ppvTimer); -typedef NV_API_CALL NV_SINT32 (* PFN_FREE_TIMER) (PNV_VOID pvContext, PN= V_VOID pvTimer); -typedef NV_API_CALL NV_SINT32 (* PFN_INITIALIZE_TIMER) (PNV_VOID pvConte= xt, PNV_VOID pvTimer, PTIMER_FUNC pvFunc, PNV_VOID pvFuncParameter); -typedef NV_API_CALL NV_SINT32 (* PFN_SET_TIMER) (PNV_VOID pvContext, PNV= _VOID pvTimer, NV_UINT32 dwMillisecondsDelay); -typedef NV_API_CALL NV_SINT32 (* PFN_CANCEL_TIMER) (PNV_VOID pvContext, = PNV_VOID pvTimer); - -typedef NV_API_CALL NV_SINT32 (* PFN_PREPROCESS_PACKET) (PNV_VOID pvCont= ext, PNV_VOID pvADReadData, PNV_VOID *ppvID, - NV_UINT8 *pNewBuffer, NV_UINT8 uc8021pPriority); -typedef NV_API_CALL PNV_VOID (* PFN_PREPROCESS_PACKET_NOPQ) (PNV_VOID pv= Context, PNV_VOID pvADReadData); -typedef NV_API_CALL NV_SINT32 (* PFN_INDICATE_PACKETS) (PNV_VOID pvConte= xt, PNV_VOID *ppvID, NV_UINT32 ulNumPacket); -typedef NV_API_CALL NV_SINT32 (* PFN_LOCK_ALLOC) (PNV_VOID pOSCX, NV_SIN= T32 iLockType, PNV_VOID *ppvLock); -typedef NV_API_CALL NV_SINT32 (* PFN_LOCK_ACQUIRE) (PNV_VOID pOSCX, NV_S= INT32 iLockType, PNV_VOID pvLock); -typedef NV_API_CALL NV_SINT32 (* PFN_LOCK_RELEASE) (PNV_VOID pOSCX, NV_S= INT32 iLockType, PNV_VOID pvLock); -typedef NV_API_CALL PNV_VOID (* PFN_RETURN_BUFFER_VIRTUAL) (PNV_VOID pvC= ontext, PNV_VOID pvADReadData); - -// Here are the OS functions that those objects below the OS interface -// can call up to. -typedef struct _OS_API -{ - // OS Context -- this is a parameter to every OS API call - PNV_VOID pOSCX; - - // Basic OS functions - PFN_MEMORY_ALLOC pfnAllocMemory; - PFN_MEMORY_FREE pfnFreeMemory; - PFN_MEMORY_ALLOCEX pfnAllocMemoryEx; - PFN_MEMORY_FREEEX pfnFreeMemoryEx; - PFN_CLEAR_MEMORY pfnClearMemory; - PFN_STALL_EXECUTION pfnStallExecution; - PFN_ALLOC_RECEIVE_BUFFER pfnAllocReceiveBuffer; - PFN_FREE_RECEIVE_BUFFER pfnFreeReceiveBuffer; - PFN_PACKET_WAS_SENT pfnPacketWasSent; - PFN_PACKET_WAS_RECEIVED pfnPacketWasReceived; - PFN_LINK_STATE_HAS_CHANGED pfnLinkStateHasChanged; - PFN_ALLOC_TIMER pfnAllocTimer; - PFN_FREE_TIMER pfnFreeTimer; - PFN_INITIALIZE_TIMER pfnInitializeTimer; - PFN_SET_TIMER pfnSetTimer; - PFN_CANCEL_TIMER pfnCancelTimer; - PFN_PREPROCESS_PACKET pfnPreprocessPacket; - PFN_PREPROCESS_PACKET_NOPQ pfnPreprocessPacketNopq; - PFN_INDICATE_PACKETS pfnIndicatePackets; - PFN_LOCK_ALLOC pfnLockAlloc; - PFN_LOCK_ACQUIRE pfnLockAcquire; - PFN_LOCK_RELEASE pfnLockRelease; - PFN_RETURN_BUFFER_VIRTUAL pfnReturnBufferVirtual; -} OS_API, *POS_API; - -#endif // _OS_H_ Index: sys/contrib/dev/nve/phy.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/dev/nve/phy.h (revision 261434) +++ sys/contrib/dev/nve/phy.h (working copy) @@ -1,164 +0,0 @@ -/***********************************************************************= ****\ -|* = *| -|* Copyright 2001-2004 NVIDIA Corporation. All Rights Reserved. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL= *| -|* TO NVIDIA, CORPORATION. USE, REPRODUCTION OR DISCLOSURE TO ANY= *| -|* THIRD PARTY IS SUBJECT TO WRITTEN PRE-APPROVAL BY NVIDIA, CORP. = *| -|* = *| -|* THE INFORMATION CONTAINED HEREIN IS PROVIDED "AS IS" WITHOUT = *| -|* EXPRESS OR IMPLIED WARRANTY OF ANY KIND, INCLUDING ALL IMPLIED = *| -|* WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A= *| -|* PARTICULAR PURPOSE. = *| -|* = *| -\***********************************************************************= ****/=20 - -/* - FILE: phy.h - DATE: 2/7/00 - - This file contains the functional interface to the PHY. -*/ -#ifndef _PHY_H_ -#define _PHY_H_ - -//#include "basetype.h" -//#include "nvevent.h" - -#ifdef __cplusplus -extern "C" { -#endif - -#define DEFAULT_PHY_ADDRESS 1 - - -#define HDP_VERSION_STRING "HDR P: $Revision: #23 $" - -// -// Defaults for PHY timeout values. -// -#define PHY_POWER_ISOLATION_MS_TIMEOUT_DEFAULT 50 -#define PHY_RESET_MS_TIMEOUT_DEFAULT 50 -#define PHY_AUTONEG_MS_TIMEOUT_DEFAULT 3000 -#define PHY_LINK_UP_MS_TIMEOUT_DEFAULT 2400 -#define PHY_RDWR_US_TIMEOUT_DEFAULT 2048 -#define PHY_POWER_DOWN_US_TIMEOUT_DEFAULT 500 - - -////////////////////////////////////////////////////////////////////////= / -// The phy module knows the values that need to go into the phy register= s -// but typically the method of writing those registers is controlled by -// another module (usually the adapter because it is really the hardware= -// interface.) Hence, the phy needs routines to call to read and write t= he -// phy registers. This structure with appropriate routines will be provi= ded -// in the PHY_Open call. - -typedef NV_API_CALL NV_SINT32 (* PFN_READ_PHY) (PNV_VOID pvData, NV_UIN= T32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 *pulValue); -typedef NV_API_CALL NV_SINT32 (* PFN_WRITE_PHY) (PNV_VOID pvData, NV_UIN= T32 ulPhyAddr, NV_UINT32 ulPhyReg, NV_UINT32 ulValue); - -typedef struct PHY_SUPPORT_API -{ - PNV_VOID pADCX; - PFN_READ_PHY pfnRead; - PFN_WRITE_PHY pfnWrite; - // PFN_EVENT_OCCURED pfnEventOccurred; - - // - // These fields are passed down via the FD. FD get's them - // from the registry. They allow one to fine tune the timeout - // values in the PHY. - // - NV_UINT32 PhyPowerIsolationTimeoutInms; - NV_UINT32 PhyResetTimeoutInms; - NV_UINT32 PhyAutonegotiateTimeoutInms; - NV_UINT32 PhyLinkupTimeoutInms; - NV_UINT32 PhyPowerdownOnCloseInus; - -} PHY_SUPPORT_API, *PPHY_SUPPORT_API; -////////////////////////////////////////////////////////////////////////= / - - -////////////////////////////////////////////////////////////////////////= / -// The functional typedefs for the PHY Api -typedef NV_SINT32 (* PFN_PHY_INIT) (PNV_VOID pvContext, NV_UINT32 *pulLi= nkState, NV_UINT32 PhyMode); -typedef NV_SINT32 (* PFN_PHY_DEINIT) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_PHY_CLOSE) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_GET_LINK_SPEED) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_GET_LINK_MODE) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_GET_LINK_STATE) (PNV_VOID pvContext, NV_UINT32 = *pulLinkState); -typedef NV_SINT32 (* PFN_IS_LINK_INITIALIZING) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_RESET_PHY_INIT_STATE) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_FORCE_SPEED_DUPLEX) (PNV_VOID pvContext, NV_UIN= T16 usSpeed, NV_UINT8 ucForceDpx, NV_UINT8 ucForceMode); -typedef NV_SINT32 (* PFN_PHY_POWERDOWN) (PNV_VOID pvContext); -typedef NV_SINT32 (* PFN_SET_LOW_SPEED_FOR_PM) (PNV_VOID pvContext); - - -typedef struct _PHY_API -{ - // This is the context to pass back in as the first arg on all - // the calls in the API below. - PNV_VOID pPHYCX; - - PFN_PHY_INIT pfnInit; - PFN_PHY_INIT pfnInitFast; - PFN_PHY_DEINIT pfnDeinit; - PFN_PHY_CLOSE pfnClose; - PFN_GET_LINK_SPEED pfnGetLinkSpeed; - PFN_GET_LINK_MODE pfnGetLinkMode; - PFN_GET_LINK_STATE pfnGetLinkState; - PFN_IS_LINK_INITIALIZING pfnIsLinkInitializing; - PFN_RESET_PHY_INIT_STATE pfnResetPhyInitState; - PFN_FORCE_SPEED_DUPLEX pfnForceSpeedDuplex; - PFN_PHY_POWERDOWN pfnPowerdown; - PFN_SET_LOW_SPEED_FOR_PM pfnSetLowSpeedForPM; -} PHY_API, *PPHY_API; -////////////////////////////////////////////////////////////////////////= / - - -////////////////////////////////////////////////////////////////////////= / -// This is the one function in the PHY interface that is publicly -// available. The rest of the interface is returned in the pPhyApi; -// The first argument needs to be cast to a POS_API structure ptr. -// On input the second argument is a ptr to a PPHY_SUPPORT_API. -// On output, the second argument should be treated as a ptr to a -// PPHY_API and set appropriately. -extern NV_SINT32 PHY_Open (PNV_VOID pvOSApi, PNV_VOID pPhyApi, NV_UINT32= *pulPhyAddr, NV_UINT32 *pulPhyConnected); -////////////////////////////////////////////////////////////////////////= / - - -////////////////////////////////////////////////////////////////////////= / -// Here are the error codes the phy functions can return. -#define PHYERR_NONE 0x0000 -#define PHYERR_COULD_NOT_ALLOC_CONTEXT 0x0001 -#define PHYERR_RESET_NEVER_FINISHED 0x0002 -#define PHYERR_NO_AVAILABLE_LINK_SPEED 0x0004 -#define PHYERR_INVALID_SETTINGS 0x0005 -#define PHYERR_READ_FAILED 0x0006 -#define PHYERR_WRITE_FAILED 0x0007 -#define PHYERR_NO_PHY 0x0008 -#define PHYERR_NO_RESOURCE 0x0009 -#define PHYERR_POWER_ISOLATION_TIMEOUT 0x000A -#define PHYERR_POWER_DOWN_TIMEOUT 0x000B -#define PHYERR_AUTONEG_TIMEOUT 0x000C -#define PHYERR_PHY_LINK_SPEED_UNCHANGED 0x000D - -#define PHY_INVALID_PHY_ADDR 0xFFFF; - -////////////////////////////////////////////////////////////////////////= / - -// This value can be used in the ulPhyLinkSpeed field. -#define PHY_LINK_SPEED_UNKNOWN 0x0FFFFFFFF - -// -// Values used to configure PHY mode. -// -#define PHY_MODE_MII 1 -#define PHY_MODE_RGMII 2 - -typedef NV_VOID (* PTIMER_FUNC) (PNV_VOID pvContext); - -#ifdef __cplusplus -} // extern "C" -#endif - -#endif //_PHY_H_ Index: sys/dev/nve/if_nve.c =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/nve/if_nve.c (revision 261434) +++ sys/dev/nve/if_nve.c (working copy) @@ -1,1791 +0,0 @@ -/*- - * Copyright (c) 2005 by David E. O'Brien . - * Copyright (c) 2003,2004 by Quinton Dolan .=20 - * All rights reserved. - *=20 - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions=20 - * are met:=20 - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer.=20 - * 2. Redistributions in binary form must reproduce the above copyright = - * notice, this list of conditions and the following disclaimer in th= e=20 - * documentation and/or other materials provided with the distributio= n. - *=20 - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D ANY - * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP= LIED - * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR= E - * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE F= OR - * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIA= L - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS OR - * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HO= WEVER - * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F - * SUCH DAMAGE. - *=20 - * $Id: if_nv.c,v 1.19 2004/08/12 14:00:05 q Exp $ - */ -/* - * NVIDIA nForce MCP Networking Adapter driver - *=20 - * This is a port of the NVIDIA MCP Linux ethernet driver distributed by= NVIDIA - * through their web site. - *=20 - * All mainstream nForce and nForce2 motherboards are supported. This mo= dule - * is as stable, sometimes more stable, than the linux version. (Recent - * Linux stability issues seem to be related to some issues with newer - * distributions using GCC 3.x, however this don't appear to effect Free= BSD - * 5.x). - *=20 - * In accordance with the NVIDIA distribution license it is necessary to= - * link this module against the nvlibnet.o binary object included in the= - * Linux driver source distribution. The binary component is not modifie= d in - * any way and is simply linked against a FreeBSD equivalent of the nvne= t.c - * linux kernel module "wrapper". - *=20 - * The Linux driver uses a common code API that is shared between Win32 = and - * i386 Linux. This abstracts the low level driver functions and uses - * callbacks and hooks to access the underlying hardware device. By usin= g - * this same API in a FreeBSD kernel module it is possible to support th= e - * hardware without breaching the Linux source distributions licensing - * requirements, or obtaining the hardware programming specifications. - *=20 - * Although not conventional, it works, and given the relatively small - * amount of hardware centric code, it's hopefully no more buggy than it= s - * linux counterpart. - * - * NVIDIA now support the nForce3 AMD64 platform, however I have been - * unable to access such a system to verify support. However, the code i= s - * reported to work with little modification when compiled with the AMD6= 4 - * version of the NVIDIA Linux library. All that should be necessary to = make - * the driver work is to link it directly into the kernel, instead of as= a - * module, and apply the docs/amd64.diff patch in this source distributi= on to - * the NVIDIA Linux driver source. - * - * This driver should work on all versions of FreeBSD since 4.9/5.1 as w= ell - * as recent versions of DragonFly. - * - * Written by Quinton Dolan =20 - * Portions based on existing FreeBSD network drivers.=20 - * NVIDIA API usage derived from distributed NVIDIA NVNET driver source = files. - */ - -#include -__FBSDID("$FreeBSD$"); - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include - -#include /* for vtophys */ -#include /* for vtophys */ -#include -#include - -#include -#include -#include -#include -#include "miibus_if.h" - -/* Include NVIDIA Linux driver header files */ -#include -#define linux -#include -#include -#include "os+%DIKED-nve.h" -#include -#include -#undef linux - -#include - -MODULE_DEPEND(nve, pci, 1, 1, 1); -MODULE_DEPEND(nve, ether, 1, 1, 1); -MODULE_DEPEND(nve, miibus, 1, 1, 1); - -static int nve_probe(device_t); -static int nve_attach(device_t); -static int nve_detach(device_t); -static void nve_init(void *); -static void nve_init_locked(struct nve_softc *); -static void nve_stop(struct nve_softc *); -static int nve_shutdown(device_t); -static int nve_init_rings(struct nve_softc *); -static void nve_free_rings(struct nve_softc *); - -static void nve_ifstart(struct ifnet *); -static void nve_ifstart_locked(struct ifnet *); -static int nve_ioctl(struct ifnet *, u_long, caddr_t); -static void nve_intr(void *); -static void nve_tick(void *); -static void nve_setmulti(struct nve_softc *); -static void nve_watchdog(struct nve_softc *); -static void nve_update_stats(struct nve_softc *); - -static int nve_ifmedia_upd(struct ifnet *); -static void nve_ifmedia_upd_locked(struct ifnet *); -static void nve_ifmedia_sts(struct ifnet *, struct ifmediareq *); -static int nve_miibus_readreg(device_t, int, int); -static int nve_miibus_writereg(device_t, int, int, int); - -static void nve_dmamap_cb(void *, bus_dma_segment_t *, int, int); -static void nve_dmamap_tx_cb(void *, bus_dma_segment_t *, int, bus_s= ize_t, int); - -static NV_API_CALL NV_SINT32 nve_osalloc(PNV_VOID, PMEMORY_BLOCK); -static NV_API_CALL NV_SINT32 nve_osfree(PNV_VOID, PMEMORY_BLOCK); -static NV_API_CALL NV_SINT32 nve_osallocex(PNV_VOID, PMEMORY_BLOCKEX); -static NV_API_CALL NV_SINT32 nve_osfreeex(PNV_VOID, PMEMORY_BLOCKEX); -static NV_API_CALL NV_SINT32 nve_osclear(PNV_VOID, PNV_VOID, NV_SINT32);= -static NV_API_CALL NV_SINT32 nve_osdelay(PNV_VOID, NV_UINT32); -static NV_API_CALL NV_SINT32 nve_osallocrxbuf(PNV_VOID, PMEMORY_BLOCK, P= NV_VOID *); -static NV_API_CALL NV_SINT32 nve_osfreerxbuf(PNV_VOID, PMEMORY_BLOCK, PN= V_VOID); -static NV_API_CALL NV_SINT32 nve_ospackettx(PNV_VOID, PNV_VOID, NV_UINT3= 2); -static NV_API_CALL NV_SINT32 nve_ospacketrx(PNV_VOID, PNV_VOID, NV_UINT3= 2, NV_UINT8 *, NV_UINT8); -static NV_API_CALL NV_SINT32 nve_oslinkchg(PNV_VOID, NV_SINT32); -static NV_API_CALL NV_SINT32 nve_osalloctimer(PNV_VOID, PNV_VOID *); -static NV_API_CALL NV_SINT32 nve_osfreetimer(PNV_VOID, PNV_VOID); -static NV_API_CALL NV_SINT32 nve_osinittimer(PNV_VOID, PNV_VOID, PTIMER_= FUNC, PNV_VOID); -static NV_API_CALL NV_SINT32 nve_ossettimer(PNV_VOID, PNV_VOID, NV_UINT3= 2); -static NV_API_CALL NV_SINT32 nve_oscanceltimer(PNV_VOID, PNV_VOID); - -static NV_API_CALL NV_SINT32 nve_ospreprocpkt(PNV_VOID, PNV_VOID, PNV_VO= ID *, NV_UINT8 *, NV_UINT8); -static NV_API_CALL PNV_VOID nve_ospreprocpktnopq(PNV_VOID, PNV_VOID); -static NV_API_CALL NV_SINT32 nve_osindicatepkt(PNV_VOID, PNV_VOID *, NV_= UINT32); -static NV_API_CALL NV_SINT32 nve_oslockalloc(PNV_VOID, NV_SINT32, PNV_VO= ID *); -static NV_API_CALL NV_SINT32 nve_oslockacquire(PNV_VOID, NV_SINT32, PNV_= VOID); -static NV_API_CALL NV_SINT32 nve_oslockrelease(PNV_VOID, NV_SINT32, PNV_= VOID); -static NV_API_CALL PNV_VOID nve_osreturnbufvirt(PNV_VOID, PNV_VOID); - -static device_method_t nve_methods[] =3D { - /* Device interface */ - DEVMETHOD(device_probe, nve_probe), - DEVMETHOD(device_attach, nve_attach), - DEVMETHOD(device_detach, nve_detach), - DEVMETHOD(device_shutdown, nve_shutdown), - - /* MII interface */ - DEVMETHOD(miibus_readreg, nve_miibus_readreg), - DEVMETHOD(miibus_writereg, nve_miibus_writereg), - - DEVMETHOD_END -}; - -static driver_t nve_driver =3D { - "nve", - nve_methods, - sizeof(struct nve_softc) -}; - -static devclass_t nve_devclass; - -static int nve_pollinterval =3D 0; -SYSCTL_INT(_hw, OID_AUTO, nve_pollinterval, CTLFLAG_RW, - &nve_pollinterval, 0, "delay between interface polls"); - -DRIVER_MODULE(nve, pci, nve_driver, nve_devclass, 0, 0); -DRIVER_MODULE(miibus, nve, miibus_driver, miibus_devclass, 0, 0); - -static struct nve_type nve_devs[] =3D { - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE_LAN, - "NVIDIA nForce MCP Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE2_LAN, - "NVIDIA nForce2 MCP2 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN1, - "NVIDIA nForce2 400 MCP4 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN2, - "NVIDIA nForce2 400 MCP5 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_LAN1, - "NVIDIA nForce3 MCP3 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_250_LAN, - "NVIDIA nForce3 250 MCP6 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE3_LAN4, - "NVIDIA nForce3 MCP7 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE4_LAN1, - "NVIDIA nForce4 CK804 MCP8 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE4_LAN2, - "NVIDIA nForce4 CK804 MCP9 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP04_LAN1, - "NVIDIA nForce MCP04 Networking Adapter"}, // MCP10 - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP04_LAN2, - "NVIDIA nForce MCP04 Networking Adapter"}, // MCP11 - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE430_LAN1, - "NVIDIA nForce 430 MCP12 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_NFORCE430_LAN2, - "NVIDIA nForce 430 MCP13 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP55_LAN1, - "NVIDIA nForce MCP55 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP55_LAN2, - "NVIDIA nForce MCP55 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN1, - "NVIDIA nForce MCP61 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN2, - "NVIDIA nForce MCP61 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN3, - "NVIDIA nForce MCP61 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP61_LAN4, - "NVIDIA nForce MCP61 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN1, - "NVIDIA nForce MCP65 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN2, - "NVIDIA nForce MCP65 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN3, - "NVIDIA nForce MCP65 Networking Adapter"}, - {PCI_VENDOR_NVIDIA, PCI_PRODUCT_NVIDIA_MCP65_LAN4, - "NVIDIA nForce MCP65 Networking Adapter"}, - {0, 0, NULL} -}; - -/* DMA MEM map callback function to get data segment physical address */= -static void -nve_dmamap_cb(void *arg, bus_dma_segment_t * segs, int nsegs, int error)= -{ - if (error) - return; - - KASSERT(nsegs =3D=3D 1, - ("Too many DMA segments returned when mapping DMA memory")); - *(bus_addr_t *)arg =3D segs->ds_addr; -} - -/* DMA RX map callback function to get data segment physical address */ -static void -nve_dmamap_rx_cb(void *arg, bus_dma_segment_t * segs, int nsegs, - bus_size_t mapsize, int error) -{ - if (error) - return; - *(bus_addr_t *)arg =3D segs->ds_addr; -} - -/* - * DMA TX buffer callback function to allocate fragment data segment - * addresses - */ -static void -nve_dmamap_tx_cb(void *arg, bus_dma_segment_t * segs, int nsegs, bus_siz= e_t mapsize, int error) -{ - struct nve_tx_desc *info; - - info =3D arg; - if (error) - return; - KASSERT(nsegs < NV_MAX_FRAGS, - ("Too many DMA segments returned when mapping mbuf")); - info->numfrags =3D nsegs; - bcopy(segs, info->frags, nsegs * sizeof(bus_dma_segment_t)); -} - -/* Probe for supported hardware ID's */ -static int -nve_probe(device_t dev) -{ - struct nve_type *t; - - t =3D nve_devs; - /* Check for matching PCI DEVICE ID's */ - while (t->name !=3D NULL) { - if ((pci_get_vendor(dev) =3D=3D t->vid_id) && - (pci_get_device(dev) =3D=3D t->dev_id)) { - device_set_desc(dev, t->name); - return (BUS_PROBE_LOW_PRIORITY); - } - t++; - } - - return (ENXIO); -} - -/* Attach driver and initialise hardware for use */ -static int -nve_attach(device_t dev) -{ - u_char eaddr[ETHER_ADDR_LEN]; - struct nve_softc *sc; - struct ifnet *ifp; - OS_API *osapi; - ADAPTER_OPEN_PARAMS OpenParams; - int error =3D 0, i, rid; - - if (bootverbose) - device_printf(dev, "nvenetlib.o version %s\n", DRIVER_VERSION); - - DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_attach - entry\n"); - - sc =3D device_get_softc(dev); - - /* Allocate mutex */ - mtx_init(&sc->mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, - MTX_DEF); - callout_init_mtx(&sc->stat_callout, &sc->mtx, 0); - - sc->dev =3D dev; - - /* Preinitialize data structures */ - bzero(&OpenParams, sizeof(ADAPTER_OPEN_PARAMS)); - - /* Enable bus mastering */ - pci_enable_busmaster(dev); - - /* Allocate memory mapped address space */ - rid =3D NV_RID; - sc->res =3D bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, - RF_ACTIVE); - - if (sc->res =3D=3D NULL) { - device_printf(dev, "couldn't map memory\n"); - error =3D ENXIO; - goto fail; - } - sc->sc_st =3D rman_get_bustag(sc->res); - sc->sc_sh =3D rman_get_bushandle(sc->res); - - /* Allocate interrupt */ - rid =3D 0; - sc->irq =3D bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, - RF_SHAREABLE | RF_ACTIVE); - - if (sc->irq =3D=3D NULL) { - device_printf(dev, "couldn't map interrupt\n"); - error =3D ENXIO; - goto fail; - } - /* Allocate DMA tags */ - error =3D bus_dma_tag_create(bus_get_dma_tag(dev), - 4, 0, BUS_SPACE_MAXADDR_32BIT, - BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES * NV_MAX_FRAGS, - NV_MAX_FRAGS, MCLBYTES, 0, - busdma_lock_mutex, &Giant, - &sc->mtag); - if (error) { - device_printf(dev, "couldn't allocate dma tag\n"); - goto fail; - } - error =3D bus_dma_tag_create(bus_get_dma_tag(dev), - 4, 0, BUS_SPACE_MAXADDR_32BIT, - BUS_SPACE_MAXADDR, NULL, NULL, - sizeof(struct nve_rx_desc) * RX_RING_SIZE, 1, - sizeof(struct nve_rx_desc) * RX_RING_SIZE, 0, - busdma_lock_mutex, &Giant, - &sc->rtag); - if (error) { - device_printf(dev, "couldn't allocate dma tag\n"); - goto fail; - } - error =3D bus_dma_tag_create(bus_get_dma_tag(dev), - 4, 0, BUS_SPACE_MAXADDR_32BIT, - BUS_SPACE_MAXADDR, NULL, NULL, - sizeof(struct nve_tx_desc) * TX_RING_SIZE, 1, - sizeof(struct nve_tx_desc) * TX_RING_SIZE, 0, - busdma_lock_mutex, &Giant, - &sc->ttag); - if (error) { - device_printf(dev, "couldn't allocate dma tag\n"); - goto fail; - } - /* Allocate DMA safe memory and get the DMA addresses. */ - error =3D bus_dmamem_alloc(sc->ttag, (void **)&sc->tx_desc, - BUS_DMA_WAITOK, &sc->tmap); - if (error) { - device_printf(dev, "couldn't allocate dma memory\n"); - goto fail; - } - bzero(sc->tx_desc, sizeof(struct nve_tx_desc) * TX_RING_SIZE); - error =3D bus_dmamap_load(sc->ttag, sc->tmap, sc->tx_desc, - sizeof(struct nve_tx_desc) * TX_RING_SIZE, nve_dmamap_cb, - &sc->tx_addr, 0); - if (error) { - device_printf(dev, "couldn't map dma memory\n"); - goto fail; - } - error =3D bus_dmamem_alloc(sc->rtag, (void **)&sc->rx_desc, - BUS_DMA_WAITOK, &sc->rmap); - if (error) { - device_printf(dev, "couldn't allocate dma memory\n"); - goto fail; - } - bzero(sc->rx_desc, sizeof(struct nve_rx_desc) * RX_RING_SIZE); - error =3D bus_dmamap_load(sc->rtag, sc->rmap, sc->rx_desc, - sizeof(struct nve_rx_desc) * RX_RING_SIZE, nve_dmamap_cb, - &sc->rx_addr, 0); - if (error) { - device_printf(dev, "couldn't map dma memory\n"); - goto fail; - } - /* Initialize rings. */ - if (nve_init_rings(sc)) { - device_printf(dev, "failed to init rings\n"); - error =3D ENXIO; - goto fail; - } - /* Setup NVIDIA API callback routines */ - osapi =3D &sc->osapi; - osapi->pOSCX =3D sc; - osapi->pfnAllocMemory =3D nve_osalloc; - osapi->pfnFreeMemory =3D nve_osfree; - osapi->pfnAllocMemoryEx =3D nve_osallocex; - osapi->pfnFreeMemoryEx =3D nve_osfreeex; - osapi->pfnClearMemory =3D nve_osclear; - osapi->pfnStallExecution =3D nve_osdelay; - osapi->pfnAllocReceiveBuffer =3D nve_osallocrxbuf; - osapi->pfnFreeReceiveBuffer =3D nve_osfreerxbuf; - osapi->pfnPacketWasSent =3D nve_ospackettx; - osapi->pfnPacketWasReceived =3D nve_ospacketrx; - osapi->pfnLinkStateHasChanged =3D nve_oslinkchg; - osapi->pfnAllocTimer =3D nve_osalloctimer; - osapi->pfnFreeTimer =3D nve_osfreetimer; - osapi->pfnInitializeTimer =3D nve_osinittimer; - osapi->pfnSetTimer =3D nve_ossettimer; - osapi->pfnCancelTimer =3D nve_oscanceltimer; - osapi->pfnPreprocessPacket =3D nve_ospreprocpkt; - osapi->pfnPreprocessPacketNopq =3D nve_ospreprocpktnopq; - osapi->pfnIndicatePackets =3D nve_osindicatepkt; - osapi->pfnLockAlloc =3D nve_oslockalloc; - osapi->pfnLockAcquire =3D nve_oslockacquire; - osapi->pfnLockRelease =3D nve_oslockrelease; - osapi->pfnReturnBufferVirtual =3D nve_osreturnbufvirt; - - sc->linkup =3D FALSE; - sc->max_frame_size =3D ETHERMTU + ETHER_HDR_LEN + FCS_LEN; - - /* TODO - We don't support hardware offload yet */ - sc->hwmode =3D 1; - sc->media =3D 0; - - /* Set NVIDIA API startup parameters */ - OpenParams.MaxDpcLoop =3D 2; - OpenParams.MaxRxPkt =3D RX_RING_SIZE; - OpenParams.MaxTxPkt =3D TX_RING_SIZE; - OpenParams.SentPacketStatusSuccess =3D 1; - OpenParams.SentPacketStatusFailure =3D 0; - OpenParams.MaxRxPktToAccumulate =3D 6; - OpenParams.ulPollInterval =3D nve_pollinterval; - OpenParams.SetForcedModeEveryNthRxPacket =3D 0; - OpenParams.SetForcedModeEveryNthTxPacket =3D 0; - OpenParams.RxForcedInterrupt =3D 0; - OpenParams.TxForcedInterrupt =3D 0; - OpenParams.pOSApi =3D osapi; - OpenParams.pvHardwareBaseAddress =3D rman_get_virtual(sc->res); - OpenParams.bASFEnabled =3D 0; - OpenParams.ulDescriptorVersion =3D sc->hwmode; - OpenParams.ulMaxPacketSize =3D sc->max_frame_size; - OpenParams.DeviceId =3D pci_get_device(dev); - - /* Open NVIDIA Hardware API */ - error =3D ADAPTER_Open(&OpenParams, (void **)&(sc->hwapi), &sc->phyaddr= ); - if (error) { - device_printf(dev, - "failed to open NVIDIA Hardware API: 0x%x\n", error); - goto fail; - } -=09 - /* TODO - Add support for MODE2 hardware offload */=20 -=09 - bzero(&sc->adapterdata, sizeof(sc->adapterdata)); -=09 - sc->adapterdata.ulMediaIF =3D sc->media; - sc->adapterdata.ulModeRegTxReadCompleteEnable =3D 1; - sc->hwapi->pfnSetCommonData(sc->hwapi->pADCX, &sc->adapterdata); -=09 - /* MAC is loaded backwards into h/w reg */ - sc->hwapi->pfnGetNodeAddress(sc->hwapi->pADCX, sc->original_mac_addr); - for (i =3D 0; i < 6; i++) { - eaddr[i] =3D sc->original_mac_addr[5 - i]; - } - sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, eaddr); - - /* Display ethernet address ,... */ - device_printf(dev, "Ethernet address %6D\n", eaddr, ":"); - - /* Allocate interface structures */ - ifp =3D sc->ifp =3D if_alloc(IFT_ETHER); - if (ifp =3D=3D NULL) { - device_printf(dev, "can not if_alloc()\n"); - error =3D ENOSPC; - goto fail; - } - - /* Setup interface parameters */ - ifp->if_softc =3D sc; - if_initname(ifp, device_get_name(dev), device_get_unit(dev)); - ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; - ifp->if_ioctl =3D nve_ioctl; - ifp->if_start =3D nve_ifstart; - ifp->if_init =3D nve_init; - ifp->if_baudrate =3D IF_Mbps(100); - IFQ_SET_MAXLEN(&ifp->if_snd, TX_RING_SIZE - 1); - ifp->if_snd.ifq_drv_maxlen =3D TX_RING_SIZE - 1; - IFQ_SET_READY(&ifp->if_snd); - ifp->if_capabilities |=3D IFCAP_VLAN_MTU; - ifp->if_capenable |=3D IFCAP_VLAN_MTU; - - /* Attach device for MII interface to PHY */ - DEBUGOUT(NVE_DEBUG_INIT, "nve: do mii_attach\n"); - error =3D mii_attach(dev, &sc->miibus, ifp, nve_ifmedia_upd, - nve_ifmedia_sts, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0); - if (error !=3D 0) { - device_printf(dev, "attaching PHYs failed\n"); - goto fail; - } - - /* Attach to OS's managers. */ - ether_ifattach(ifp, eaddr); - - /* Activate our interrupt handler. - attach last to avoid lock */ - error =3D bus_setup_intr(dev, sc->irq, INTR_TYPE_NET | INTR_MPSAFE, - NULL, nve_intr, sc, &sc->sc_ih); - if (error) { - device_printf(dev, "couldn't set up interrupt handler\n"); - goto fail; - } - DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_attach - exit\n"); - -fail: - if (error) - nve_detach(dev); - - return (error); -} - -/* Detach interface for module unload */ -static int -nve_detach(device_t dev) -{ - struct nve_softc *sc =3D device_get_softc(dev); - struct ifnet *ifp; - - KASSERT(mtx_initialized(&sc->mtx), ("mutex not initialized")); - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_detach - entry\n"); - - ifp =3D sc->ifp; - - if (device_is_attached(dev)) { - ether_ifdetach(ifp); - NVE_LOCK(sc); - nve_stop(sc); - NVE_UNLOCK(sc); - callout_drain(&sc->stat_callout); - } - - if (sc->miibus) - device_delete_child(dev, sc->miibus); - bus_generic_detach(dev); - - /* Reload unreversed address back into MAC in original state */ - if (sc->original_mac_addr) - sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, - sc->original_mac_addr); - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: do pfnClose\n"); - /* Detach from NVIDIA hardware API */ - if (sc->hwapi->pfnClose) - sc->hwapi->pfnClose(sc->hwapi->pADCX, FALSE); - /* Release resources */ - if (sc->sc_ih) - bus_teardown_intr(sc->dev, sc->irq, sc->sc_ih); - if (sc->irq) - bus_release_resource(sc->dev, SYS_RES_IRQ, 0, sc->irq); - if (sc->res) - bus_release_resource(sc->dev, SYS_RES_MEMORY, NV_RID, sc->res); - - nve_free_rings(sc); - - if (sc->tx_desc) { - bus_dmamap_unload(sc->rtag, sc->rmap); - bus_dmamem_free(sc->rtag, sc->rx_desc, sc->rmap); - bus_dmamap_destroy(sc->rtag, sc->rmap); - } - if (sc->mtag) - bus_dma_tag_destroy(sc->mtag); - if (sc->ttag) - bus_dma_tag_destroy(sc->ttag); - if (sc->rtag) - bus_dma_tag_destroy(sc->rtag); - - if (ifp) - if_free(ifp); - mtx_destroy(&sc->mtx); - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_detach - exit\n"); - - return (0); -} - -/* Initialise interface and start it "RUNNING" */ -static void -nve_init(void *xsc) -{ - struct nve_softc *sc =3D xsc; - - NVE_LOCK(sc); - nve_init_locked(sc); - NVE_UNLOCK(sc); -} - -static void -nve_init_locked(struct nve_softc *sc) -{ - struct ifnet *ifp; - int error; - - NVE_LOCK_ASSERT(sc); - DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init - entry (%d)\n", sc->linkup); - - ifp =3D sc->ifp; - - /* Do nothing if already running */ - if (ifp->if_drv_flags & IFF_DRV_RUNNING) - return; - - nve_stop(sc); - DEBUGOUT(NVE_DEBUG_INIT, "nve: do pfnInit\n"); - - nve_ifmedia_upd_locked(ifp); - - /* Setup Hardware interface and allocate memory structures */ - error =3D sc->hwapi->pfnInit(sc->hwapi->pADCX,=20 - 0, /* force speed */=20 - 0, /* force full duplex */ - 0, /* force mode */ - 0, /* force async mode */ - &sc->linkup); - - if (error) { - device_printf(sc->dev, - "failed to start NVIDIA Hardware interface\n"); - return; - } - /* Set the MAC address */ - sc->hwapi->pfnSetNodeAddress(sc->hwapi->pADCX, IF_LLADDR(sc->ifp)); - sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX); - sc->hwapi->pfnStart(sc->hwapi->pADCX); - - /* Setup multicast filter */ - nve_setmulti(sc); - - /* Update interface parameters */ - ifp->if_drv_flags |=3D IFF_DRV_RUNNING; - ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; - - callout_reset(&sc->stat_callout, hz, nve_tick, sc); - - DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init - exit\n"); - - return; -} - -/* Stop interface activity ie. not "RUNNING" */ -static void -nve_stop(struct nve_softc *sc) -{ - struct ifnet *ifp; - - NVE_LOCK_ASSERT(sc); - - DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_stop - entry\n"); - - ifp =3D sc->ifp; - sc->tx_timer =3D 0; - - /* Cancel tick timer */ - callout_stop(&sc->stat_callout); - - /* Stop hardware activity */ - sc->hwapi->pfnDisableInterrupts(sc->hwapi->pADCX); - sc->hwapi->pfnStop(sc->hwapi->pADCX, 0); - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: do pfnDeinit\n"); - /* Shutdown interface and deallocate memory buffers */ - if (sc->hwapi->pfnDeinit) - sc->hwapi->pfnDeinit(sc->hwapi->pADCX, 0); - - sc->linkup =3D 0; - sc->cur_rx =3D 0; - sc->pending_rxs =3D 0; - sc->pending_txs =3D 0; - - ifp->if_drv_flags &=3D ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); - - DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_stop - exit\n"); - - return; -} - -/* Shutdown interface for unload/reboot */ -static int -nve_shutdown(device_t dev) -{ - struct nve_softc *sc; - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_shutdown\n"); - - sc =3D device_get_softc(dev); - - /* Stop hardware activity */ - NVE_LOCK(sc); - nve_stop(sc); - NVE_UNLOCK(sc); - - return (0); -} - -/* Allocate TX ring buffers */ -static int -nve_init_rings(struct nve_softc *sc) -{ - int error, i; - - DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - entry\n"); - - sc->cur_rx =3D sc->cur_tx =3D sc->pending_rxs =3D sc->pending_txs =3D 0= ; - /* Initialise RX ring */ - for (i =3D 0; i < RX_RING_SIZE; i++) { - struct nve_rx_desc *desc =3D sc->rx_desc + i; - struct nve_map_buffer *buf =3D &desc->buf; - - buf->mbuf =3D m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR); - if (buf->mbuf =3D=3D NULL) { - device_printf(sc->dev, "couldn't allocate mbuf\n"); - nve_free_rings(sc); - return (ENOBUFS); - } - buf->mbuf->m_len =3D buf->mbuf->m_pkthdr.len =3D MCLBYTES; - m_adj(buf->mbuf, ETHER_ALIGN); - - error =3D bus_dmamap_create(sc->mtag, 0, &buf->map); - if (error) { - device_printf(sc->dev, "couldn't create dma map\n"); - nve_free_rings(sc); - return (error); - } - error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, buf->mbuf, - nve_dmamap_rx_cb, &desc->paddr, 0); - if (error) { - device_printf(sc->dev, "couldn't dma map mbuf\n"); - nve_free_rings(sc); - return (error); - } - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_PREREAD); - - desc->buflength =3D buf->mbuf->m_len; - desc->vaddr =3D mtod(buf->mbuf, caddr_t); - } - bus_dmamap_sync(sc->rtag, sc->rmap, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); - - /* Initialize TX ring */ - for (i =3D 0; i < TX_RING_SIZE; i++) { - struct nve_tx_desc *desc =3D sc->tx_desc + i; - struct nve_map_buffer *buf =3D &desc->buf; - - buf->mbuf =3D NULL; - - error =3D bus_dmamap_create(sc->mtag, 0, &buf->map); - if (error) { - device_printf(sc->dev, "couldn't create dma map\n"); - nve_free_rings(sc); - return (error); - } - } - bus_dmamap_sync(sc->ttag, sc->tmap, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); - - DEBUGOUT(NVE_DEBUG_INIT, "nve: nve_init_rings - exit\n"); - - return (error); -} - -/* Free the TX ring buffers */ -static void -nve_free_rings(struct nve_softc *sc) -{ - int i; - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_free_rings - entry\n"); - - for (i =3D 0; i < RX_RING_SIZE; i++) { - struct nve_rx_desc *desc =3D sc->rx_desc + i; - struct nve_map_buffer *buf =3D &desc->buf; - - if (buf->mbuf) { - bus_dmamap_unload(sc->mtag, buf->map); - bus_dmamap_destroy(sc->mtag, buf->map); - m_freem(buf->mbuf); - } - buf->mbuf =3D NULL; - } - - for (i =3D 0; i < TX_RING_SIZE; i++) { - struct nve_tx_desc *desc =3D sc->tx_desc + i; - struct nve_map_buffer *buf =3D &desc->buf; - - if (buf->mbuf) { - bus_dmamap_unload(sc->mtag, buf->map); - bus_dmamap_destroy(sc->mtag, buf->map); - m_freem(buf->mbuf); - } - buf->mbuf =3D NULL; - } - - DEBUGOUT(NVE_DEBUG_DEINIT, "nve: nve_free_rings - exit\n"); -} - -/* Main loop for sending packets from OS to interface */ -static void -nve_ifstart(struct ifnet *ifp) -{ - struct nve_softc *sc =3D ifp->if_softc; - - NVE_LOCK(sc); - nve_ifstart_locked(ifp); - NVE_UNLOCK(sc); -} - -static void -nve_ifstart_locked(struct ifnet *ifp) -{ - struct nve_softc *sc =3D ifp->if_softc; - struct nve_map_buffer *buf; - struct mbuf *m0, *m; - struct nve_tx_desc *desc; - ADAPTER_WRITE_DATA txdata; - int error, i; - - DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_ifstart - entry\n"); - - NVE_LOCK_ASSERT(sc); - - /* If link is down/busy or queue is empty do nothing */ - if (ifp->if_drv_flags & IFF_DRV_OACTIVE || - IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - return; - - /* Transmit queued packets until sent or TX ring is full */ - while (sc->pending_txs < TX_RING_SIZE) { - desc =3D sc->tx_desc + sc->cur_tx; - buf =3D &desc->buf; - - /* Get next packet to send. */ - IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); - - /* If nothing to send, return. */ - if (m0 =3D=3D NULL) - return; - - /* - * On nForce4, the chip doesn't interrupt on transmit, - * so try to flush transmitted packets from the queue - * if it's getting large (see note in nve_watchdog). - */ - if (sc->pending_txs > TX_RING_SIZE/2) { - sc->hwapi->pfnDisableInterrupts(sc->hwapi->pADCX); - sc->hwapi->pfnHandleInterrupt(sc->hwapi->pADCX); - sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX); - } - - /* Map MBUF for DMA access */ - error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, m0, - nve_dmamap_tx_cb, desc, BUS_DMA_NOWAIT); - - if (error && error !=3D EFBIG) { - m_freem(m0); - sc->tx_errors++; - continue; - } - /* - * Packet has too many fragments - defrag into new mbuf - * cluster - */ - if (error) { - m =3D m_defrag(m0, M_NOWAIT); - if (m =3D=3D NULL) { - m_freem(m0); - sc->tx_errors++; - continue; - } - m0 =3D m; - - error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, m, - nve_dmamap_tx_cb, desc, BUS_DMA_NOWAIT); - if (error) { - m_freem(m); - sc->tx_errors++; - continue; - } - } - /* Do sync on DMA bounce buffer */ - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_PREWRITE); - - buf->mbuf =3D m0; - txdata.ulNumberOfElements =3D desc->numfrags; - txdata.pvID =3D (PVOID)desc; - - /* Put fragments into API element list */ - txdata.ulTotalLength =3D buf->mbuf->m_len; - for (i =3D 0; i < desc->numfrags; i++) { - txdata.sElement[i].ulLength =3D - (ulong)desc->frags[i].ds_len; - txdata.sElement[i].pPhysical =3D - (PVOID)desc->frags[i].ds_addr; - } - - /* Send packet to Nvidia API for transmission */ - error =3D sc->hwapi->pfnWrite(sc->hwapi->pADCX, &txdata); - - switch (error) { - case ADAPTERERR_NONE: - /* Packet was queued in API TX queue successfully */ - sc->pending_txs++; - sc->cur_tx =3D (sc->cur_tx + 1) % TX_RING_SIZE; - break; - - case ADAPTERERR_TRANSMIT_QUEUE_FULL: - /* The API TX queue is full - requeue the packet */ - device_printf(sc->dev, - "nve_ifstart: transmit queue is full\n"); - ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; - bus_dmamap_unload(sc->mtag, buf->map); - IFQ_DRV_PREPEND(&ifp->if_snd, buf->mbuf); - buf->mbuf =3D NULL; - return; - - default: - /* The API failed to queue/send the packet so dump it */ - device_printf(sc->dev, "nve_ifstart: transmit error\n"); - bus_dmamap_unload(sc->mtag, buf->map); - m_freem(buf->mbuf); - buf->mbuf =3D NULL; - sc->tx_errors++; - return; - } - /* Set watchdog timer. */ - sc->tx_timer =3D 8; - - /* Copy packet to BPF tap */ - BPF_MTAP(ifp, m0); - } - ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; - - DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_ifstart - exit\n"); -} - -/* Handle IOCTL events */ -static int -nve_ioctl(struct ifnet *ifp, u_long command, caddr_t data) -{ - struct nve_softc *sc =3D ifp->if_softc; - struct ifreq *ifr =3D (struct ifreq *) data; - struct mii_data *mii; - int error =3D 0; - - DEBUGOUT(NVE_DEBUG_IOCTL, "nve: nve_ioctl - entry\n"); - - switch (command) { - case SIOCSIFMTU: - /* Set MTU size */ - NVE_LOCK(sc); - if (ifp->if_mtu =3D=3D ifr->ifr_mtu) { - NVE_UNLOCK(sc); - break; - } - if (ifr->ifr_mtu + ifp->if_hdrlen <=3D MAX_PACKET_SIZE_1518) { - ifp->if_mtu =3D ifr->ifr_mtu; - nve_stop(sc); - nve_init_locked(sc); - } else - error =3D EINVAL; - NVE_UNLOCK(sc); - break; - - case SIOCSIFFLAGS: - /* Setup interface flags */ - NVE_LOCK(sc); - if (ifp->if_flags & IFF_UP) { - if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0) { - nve_init_locked(sc); - NVE_UNLOCK(sc); - break; - } - } else { - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - nve_stop(sc); - NVE_UNLOCK(sc); - break; - } - } - /* Handle IFF_PROMISC and IFF_ALLMULTI flags. */ - nve_setmulti(sc); - NVE_UNLOCK(sc); - break; - - case SIOCADDMULTI: - case SIOCDELMULTI: - /* Setup multicast filter */ - NVE_LOCK(sc); - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - nve_setmulti(sc); - } - NVE_UNLOCK(sc); - break; - - case SIOCGIFMEDIA: - case SIOCSIFMEDIA: - /* Get/Set interface media parameters */ - mii =3D device_get_softc(sc->miibus); - error =3D ifmedia_ioctl(ifp, ifr, &mii->mii_media, command); - break; - - default: - /* Everything else we forward to generic ether ioctl */ - error =3D ether_ioctl(ifp, command, data); - break; - } - - DEBUGOUT(NVE_DEBUG_IOCTL, "nve: nve_ioctl - exit\n"); - - return (error); -} - -/* Interrupt service routine */ -static void -nve_intr(void *arg) -{ - struct nve_softc *sc =3D arg; - struct ifnet *ifp =3D sc->ifp; - - DEBUGOUT(NVE_DEBUG_INTERRUPT, "nve: nve_intr - entry\n"); - - NVE_LOCK(sc); - if (!ifp->if_flags & IFF_UP) { - nve_stop(sc); - NVE_UNLOCK(sc); - return; - } - /* Handle interrupt event */ - if (sc->hwapi->pfnQueryInterrupt(sc->hwapi->pADCX)) { - sc->hwapi->pfnHandleInterrupt(sc->hwapi->pADCX); - sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX); - } - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - nve_ifstart_locked(ifp); - - /* If no pending packets we don't need a timeout */ - if (sc->pending_txs =3D=3D 0) - sc->tx_timer =3D 0; - NVE_UNLOCK(sc); - - DEBUGOUT(NVE_DEBUG_INTERRUPT, "nve: nve_intr - exit\n"); - - return; -} - -/* Setup multicast filters */ -static void -nve_setmulti(struct nve_softc *sc) -{ - struct ifnet *ifp; - struct ifmultiaddr *ifma; - PACKET_FILTER hwfilter; - int i; - u_int8_t andaddr[6], oraddr[6]; - - NVE_LOCK_ASSERT(sc); - - DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_setmulti - entry\n"); - - ifp =3D sc->ifp; - - /* Initialize filter */ - hwfilter.ulFilterFlags =3D 0; - for (i =3D 0; i < 6; i++) { - hwfilter.acMulticastAddress[i] =3D 0; - hwfilter.acMulticastMask[i] =3D 0; - } - - if (ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) { - /* Accept all packets */ - hwfilter.ulFilterFlags |=3D ACCEPT_ALL_PACKETS; - sc->hwapi->pfnSetPacketFilter(sc->hwapi->pADCX, &hwfilter); - return; - } - /* Setup multicast filter */ - if_maddr_rlock(ifp); - TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { - u_char *addrp; - - if (ifma->ifma_addr->sa_family !=3D AF_LINK) - continue; - - addrp =3D LLADDR((struct sockaddr_dl *) ifma->ifma_addr); - for (i =3D 0; i < 6; i++) { - u_int8_t mcaddr =3D addrp[i]; - andaddr[i] &=3D mcaddr; - oraddr[i] |=3D mcaddr; - } - } - if_maddr_runlock(ifp); - for (i =3D 0; i < 6; i++) { - hwfilter.acMulticastAddress[i] =3D andaddr[i] & oraddr[i]; - hwfilter.acMulticastMask[i] =3D andaddr[i] | (~oraddr[i]); - } - - /* Send filter to NVIDIA API */ - sc->hwapi->pfnSetPacketFilter(sc->hwapi->pADCX, &hwfilter); - - DEBUGOUT(NVE_DEBUG_RUNNING, "nve: nve_setmulti - exit\n"); - - return; -} - -/* Change the current media/mediaopts */ -static int -nve_ifmedia_upd(struct ifnet *ifp) -{ - struct nve_softc *sc =3D ifp->if_softc; - - NVE_LOCK(sc); - nve_ifmedia_upd_locked(ifp); - NVE_UNLOCK(sc); - return (0); -} - -static void -nve_ifmedia_upd_locked(struct ifnet *ifp) -{ - struct nve_softc *sc =3D ifp->if_softc; - struct mii_data *mii; - struct mii_softc *miisc; - - DEBUGOUT(NVE_DEBUG_MII, "nve: nve_ifmedia_upd\n"); - - NVE_LOCK_ASSERT(sc); - mii =3D device_get_softc(sc->miibus); - - LIST_FOREACH(miisc, &mii->mii_phys, mii_list) - PHY_RESET(miisc); - mii_mediachg(mii); -} - -/* Update current miibus PHY status of media */ -static void -nve_ifmedia_sts(struct ifnet *ifp, struct ifmediareq *ifmr) -{ - struct nve_softc *sc; - struct mii_data *mii; - - DEBUGOUT(NVE_DEBUG_MII, "nve: nve_ifmedia_sts\n"); - - sc =3D ifp->if_softc; - NVE_LOCK(sc); - mii =3D device_get_softc(sc->miibus); - mii_pollstat(mii); - - ifmr->ifm_active =3D mii->mii_media_active; - ifmr->ifm_status =3D mii->mii_media_status; - NVE_UNLOCK(sc); - - return; -} - -/* miibus tick timer - maintain link status */ -static void -nve_tick(void *xsc) -{ - struct nve_softc *sc =3D xsc; - struct mii_data *mii; - struct ifnet *ifp; - - NVE_LOCK_ASSERT(sc); - - ifp =3D sc->ifp; - nve_update_stats(sc); - - mii =3D device_get_softc(sc->miibus); - mii_tick(mii); - - if (mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) !=3D IFM_NONE) { - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - nve_ifstart_locked(ifp); - } - - if (sc->tx_timer > 0 && --sc->tx_timer =3D=3D 0) - nve_watchdog(sc); - callout_reset(&sc->stat_callout, hz, nve_tick, sc); - - return; -} - -/* Update ifnet data structure with collected interface stats from API *= / -static void -nve_update_stats(struct nve_softc *sc) -{ - struct ifnet *ifp =3D sc->ifp; - ADAPTER_STATS stats; - - NVE_LOCK_ASSERT(sc); - - if (sc->hwapi) { - sc->hwapi->pfnGetStatistics(sc->hwapi->pADCX, &stats); - - ifp->if_ipackets =3D stats.ulSuccessfulReceptions; - ifp->if_ierrors =3D stats.ulMissedFrames + - stats.ulFailedReceptions + - stats.ulCRCErrors + - stats.ulFramingErrors + - stats.ulOverFlowErrors; - - ifp->if_opackets =3D stats.ulSuccessfulTransmissions; - ifp->if_oerrors =3D sc->tx_errors + - stats.ulFailedTransmissions + - stats.ulRetryErrors + - stats.ulUnderflowErrors + - stats.ulLossOfCarrierErrors + - stats.ulLateCollisionErrors; - - ifp->if_collisions =3D stats.ulLateCollisionErrors; - } - - return; -} - -/* miibus Read PHY register wrapper - calls Nvidia API entry point */ -static int -nve_miibus_readreg(device_t dev, int phy, int reg) -{ - struct nve_softc *sc =3D device_get_softc(dev); - ULONG data; - - DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_readreg - entry\n"); - - ADAPTER_ReadPhy(sc->hwapi->pADCX, phy, reg, &data); - - DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_readreg - exit\n"); - - return (data); -} - -/* miibus Write PHY register wrapper - calls Nvidia API entry point */ -static int -nve_miibus_writereg(device_t dev, int phy, int reg, int data) -{ - struct nve_softc *sc =3D device_get_softc(dev); - - DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_writereg - entry\n"); - - ADAPTER_WritePhy(sc->hwapi->pADCX, phy, reg, (ulong)data); - - DEBUGOUT(NVE_DEBUG_MII, "nve: nve_miibus_writereg - exit\n"); - - return 0; -} - -/* Watchdog timer to prevent PHY lockups */ -static void -nve_watchdog(struct nve_softc *sc) -{ - struct ifnet *ifp; - int pending_txs_start; - - NVE_LOCK_ASSERT(sc); - ifp =3D sc->ifp; - - /* - * The nvidia driver blob defers tx completion notifications. - * Thus, sometimes the watchdog timer will go off when the - * tx engine is fine, but the tx completions are just deferred. - * Try kicking the driver blob to clear out any pending tx - * completions. If that clears up any of the pending tx - * operations, then just return without printing the warning - * message or resetting the adapter, as we can then conclude - * the chip hasn't actually crashed (it's still sending packets). - */ - pending_txs_start =3D sc->pending_txs; - sc->hwapi->pfnDisableInterrupts(sc->hwapi->pADCX); - sc->hwapi->pfnHandleInterrupt(sc->hwapi->pADCX); - sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX); - if (sc->pending_txs < pending_txs_start) - return; - - device_printf(sc->dev, "device timeout (%d)\n", sc->pending_txs); - - sc->tx_errors++; - - nve_stop(sc); - nve_init_locked(sc); - - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - nve_ifstart_locked(ifp); -} - -/* --- Start of NVOSAPI interface --- */ - -/* Allocate DMA enabled general use memory for API */ -static NV_API_CALL NV_SINT32 -nve_osalloc(PNV_VOID ctx, PMEMORY_BLOCK mem) -{ - struct nve_softc *sc; - bus_addr_t mem_physical; - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osalloc - %d\n", mem->uiLength); - - sc =3D (struct nve_softc *)ctx; - - mem->pLogical =3D (PVOID)contigmalloc(mem->uiLength, M_DEVBUF, - M_NOWAIT | M_ZERO, 0, 0xffffffff, PAGE_SIZE, 0); - - if (!mem->pLogical) { - device_printf(sc->dev, "memory allocation failed\n"); - return (0); - } - memset(mem->pLogical, 0, (ulong)mem->uiLength); - mem_physical =3D vtophys(mem->pLogical); - mem->pPhysical =3D (PVOID)mem_physical; - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osalloc 0x%x/0x%x - %d\n", - (uint)mem->pLogical, (uint)mem->pPhysical, (uint)mem->uiLength); - - return (1); -} - -/* Free allocated memory */ -static NV_API_CALL NV_SINT32 -nve_osfree(PNV_VOID ctx, PMEMORY_BLOCK mem) -{ - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osfree - 0x%x - %d\n", - (uint)mem->pLogical, (uint) mem->uiLength); - - contigfree(mem->pLogical, PAGE_SIZE, M_DEVBUF); - return (1); -} - -/* Copied directly from nvnet.c */ -static NV_API_CALL NV_SINT32 -nve_osallocex(PNV_VOID ctx, PMEMORY_BLOCKEX mem_block_ex) -{ - MEMORY_BLOCK mem_block; - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osallocex\n"); - - mem_block_ex->pLogical =3D NULL; - mem_block_ex->uiLengthOrig =3D mem_block_ex->uiLength; - - if ((mem_block_ex->AllocFlags & ALLOC_MEMORY_ALIGNED) && - (mem_block_ex->AlignmentSize > 1)) { - DEBUGOUT(NVE_DEBUG_API, " aligning on %d\n", - mem_block_ex->AlignmentSize); - mem_block_ex->uiLengthOrig +=3D mem_block_ex->AlignmentSize; - } - mem_block.uiLength =3D mem_block_ex->uiLengthOrig; - - if (nve_osalloc(ctx, &mem_block) =3D=3D 0) { - return (0); - } - mem_block_ex->pLogicalOrig =3D mem_block.pLogical; - mem_block_ex->pPhysicalOrigLow =3D (unsigned long)mem_block.pPhysical; - mem_block_ex->pPhysicalOrigHigh =3D 0; - - mem_block_ex->pPhysical =3D mem_block.pPhysical; - mem_block_ex->pLogical =3D mem_block.pLogical; - - if (mem_block_ex->uiLength !=3D mem_block_ex->uiLengthOrig) { - unsigned int offset; - offset =3D mem_block_ex->pPhysicalOrigLow & - (mem_block_ex->AlignmentSize - 1); - - if (offset) { - mem_block_ex->pPhysical =3D - (PVOID)((ulong)mem_block_ex->pPhysical + - mem_block_ex->AlignmentSize - offset); - mem_block_ex->pLogical =3D - (PVOID)((ulong)mem_block_ex->pLogical + - mem_block_ex->AlignmentSize - offset); - } /* if (offset) */ - } /* if (mem_block_ex->uiLength !=3D *mem_block_ex->uiLengthOrig) */ - return (1); -} - -/* Copied directly from nvnet.c */ -static NV_API_CALL NV_SINT32 -nve_osfreeex(PNV_VOID ctx, PMEMORY_BLOCKEX mem_block_ex) -{ - MEMORY_BLOCK mem_block; - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osfreeex\n"); - - mem_block.pLogical =3D mem_block_ex->pLogicalOrig; - mem_block.pPhysical =3D (PVOID)((ulong)mem_block_ex->pPhysicalOrigLow);= - mem_block.uiLength =3D mem_block_ex->uiLengthOrig; - - return (nve_osfree(ctx, &mem_block)); -} - -/* Clear memory region */ -static NV_API_CALL NV_SINT32 -nve_osclear(PNV_VOID ctx, PNV_VOID mem, NV_SINT32 length) -{ - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osclear\n"); - memset(mem, 0, length); - return (1); -} - -/* Sleep for a tick */ -static NV_API_CALL NV_SINT32 -nve_osdelay(PNV_VOID ctx, NV_UINT32 usec) -{ - DELAY(usec); - return (1); -} - -/* Allocate memory for rx buffer */ -static NV_API_CALL NV_SINT32 -nve_osallocrxbuf(PNV_VOID ctx, PMEMORY_BLOCK mem, PNV_VOID *id) -{ - struct nve_softc *sc =3D ctx; - struct nve_rx_desc *desc; - struct nve_map_buffer *buf; - int error; - - if (device_is_attached(sc->dev)) - NVE_LOCK_ASSERT(sc); - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osallocrxbuf\n"); - - if (sc->pending_rxs =3D=3D RX_RING_SIZE) { - device_printf(sc->dev, "rx ring buffer is full\n"); - goto fail; - } - desc =3D sc->rx_desc + sc->cur_rx; - buf =3D &desc->buf; - - if (buf->mbuf =3D=3D NULL) { - buf->mbuf =3D m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR); - if (buf->mbuf =3D=3D NULL) { - device_printf(sc->dev, "failed to allocate memory\n"); - goto fail; - } - buf->mbuf->m_len =3D buf->mbuf->m_pkthdr.len =3D MCLBYTES; - m_adj(buf->mbuf, ETHER_ALIGN); - - error =3D bus_dmamap_load_mbuf(sc->mtag, buf->map, buf->mbuf, - nve_dmamap_rx_cb, &desc->paddr, 0); - if (error) { - device_printf(sc->dev, "failed to dmamap mbuf\n"); - m_freem(buf->mbuf); - buf->mbuf =3D NULL; - goto fail; - } - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_PREREAD); - desc->buflength =3D buf->mbuf->m_len; - desc->vaddr =3D mtod(buf->mbuf, caddr_t); - } - sc->pending_rxs++; - sc->cur_rx =3D (sc->cur_rx + 1) % RX_RING_SIZE; - - mem->pLogical =3D (void *)desc->vaddr; - mem->pPhysical =3D (void *)desc->paddr; - mem->uiLength =3D desc->buflength; - *id =3D (void *)desc; - - return (1); -=09 -fail: - return (0); -} - -/* Free the rx buffer */ -static NV_API_CALL NV_SINT32 -nve_osfreerxbuf(PNV_VOID ctx, PMEMORY_BLOCK mem, PNV_VOID id) -{ - struct nve_softc *sc =3D ctx; - struct nve_rx_desc *desc; - struct nve_map_buffer *buf; - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_osfreerxbuf\n"); - - desc =3D (struct nve_rx_desc *) id; - buf =3D &desc->buf; - - if (buf->mbuf) { - bus_dmamap_unload(sc->mtag, buf->map); - bus_dmamap_destroy(sc->mtag, buf->map); - m_freem(buf->mbuf); - } - sc->pending_rxs--; - buf->mbuf =3D NULL; - - return (1); -} - -/* This gets called by the Nvidia API after our TX packet has been sent = */ -static NV_API_CALL NV_SINT32 -nve_ospackettx(PNV_VOID ctx, PNV_VOID id, NV_UINT32 success) -{ - struct nve_softc *sc =3D ctx; - struct nve_map_buffer *buf; - struct nve_tx_desc *desc =3D (struct nve_tx_desc *) id; - struct ifnet *ifp; - - NVE_LOCK_ASSERT(sc); - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_ospackettx\n"); - - ifp =3D sc->ifp; - buf =3D &desc->buf; - sc->pending_txs--; - - /* Unload and free mbuf cluster */ - if (buf->mbuf =3D=3D NULL) - goto fail; - - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTWRITE); - bus_dmamap_unload(sc->mtag, buf->map); - m_freem(buf->mbuf); - buf->mbuf =3D NULL; - - /* Send more packets if we have them */ - if (sc->pending_txs < TX_RING_SIZE) - sc->ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; - - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd) && sc->pending_txs < TX_RING_SIZE) - nve_ifstart_locked(ifp); - -fail: - - return (1); -} - -/* This gets called by the Nvidia API when a new packet has been receive= d */ -/* XXX What is newbuf used for? XXX */ -static NV_API_CALL NV_SINT32 -nve_ospacketrx(PNV_VOID ctx, PNV_VOID data, NV_UINT32 success, NV_UINT8 = *newbuf, - NV_UINT8 priority) -{ - struct nve_softc *sc =3D ctx; - struct ifnet *ifp; - struct nve_rx_desc *desc; - struct nve_map_buffer *buf; - ADAPTER_READ_DATA *readdata; - struct mbuf *m; - - NVE_LOCK_ASSERT(sc); - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_ospacketrx\n"); - - ifp =3D sc->ifp; - - readdata =3D (ADAPTER_READ_DATA *) data; - desc =3D readdata->pvID; - buf =3D &desc->buf; - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTREAD); - - if (success) { - /* Sync DMA bounce buffer. */ - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTREAD); - - /* First mbuf in packet holds the ethernet and packet headers */ - buf->mbuf->m_pkthdr.rcvif =3D ifp; - buf->mbuf->m_pkthdr.len =3D buf->mbuf->m_len =3D - readdata->ulTotalLength; - - bus_dmamap_unload(sc->mtag, buf->map); - - /* Blat the mbuf pointer, kernel will free the mbuf cluster */ - m =3D buf->mbuf; - buf->mbuf =3D NULL; - - /* Give mbuf to OS. */ - NVE_UNLOCK(sc); - (*ifp->if_input)(ifp, m); - NVE_LOCK(sc); - if (readdata->ulFilterMatch & ADREADFL_MULTICAST_MATCH) - ifp->if_imcasts++; - - } else { - bus_dmamap_sync(sc->mtag, buf->map, BUS_DMASYNC_POSTREAD); - bus_dmamap_unload(sc->mtag, buf->map); - m_freem(buf->mbuf); - buf->mbuf =3D NULL; - } - - sc->cur_rx =3D desc - sc->rx_desc; - sc->pending_rxs--; - - return (1); -} - -/* This gets called by NVIDIA API when the PHY link state changes */ -static NV_API_CALL NV_SINT32 -nve_oslinkchg(PNV_VOID ctx, NV_SINT32 enabled) -{ - - DEBUGOUT(NVE_DEBUG_API, "nve: nve_oslinkchg\n"); - - return (1); -} - -/* Setup a watchdog timer */ -static NV_API_CALL NV_SINT32 -nve_osalloctimer(PNV_VOID ctx, PNV_VOID *timer) -{ - struct nve_softc *sc =3D (struct nve_softc *)ctx; - - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osalloctimer\n"); - - callout_init(&sc->ostimer, CALLOUT_MPSAFE); - *timer =3D &sc->ostimer; - - return (1); -} - -/* Free the timer */ -static NV_API_CALL NV_SINT32 -nve_osfreetimer(PNV_VOID ctx, PNV_VOID timer) -{ - - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osfreetimer\n"); - - callout_drain((struct callout *)timer); - - return (1); -} - -/* Setup timer parameters */ -static NV_API_CALL NV_SINT32 -nve_osinittimer(PNV_VOID ctx, PNV_VOID timer, PTIMER_FUNC func, PNV_VOID= parameters) -{ - struct nve_softc *sc =3D (struct nve_softc *)ctx; - - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osinittimer\n"); - - sc->ostimer_func =3D func; - sc->ostimer_params =3D parameters; - - return (1); -} - -/* Set the timer to go off */ -static NV_API_CALL NV_SINT32 -nve_ossettimer(PNV_VOID ctx, PNV_VOID timer, NV_UINT32 delay) -{ - struct nve_softc *sc =3D ctx; - - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_ossettimer\n"); - - callout_reset((struct callout *)timer, delay, sc->ostimer_func, - sc->ostimer_params); - - return (1); -} - -/* Cancel the timer */ -static NV_API_CALL NV_SINT32 -nve_oscanceltimer(PNV_VOID ctx, PNV_VOID timer) -{ - - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_oscanceltimer\n"); - - callout_stop((struct callout *)timer); - - return (1); -} - -static NV_API_CALL NV_SINT32 -nve_ospreprocpkt(PNV_VOID ctx, PNV_VOID readdata, PNV_VOID *id, - NV_UINT8 *newbuffer, NV_UINT8 priority) -{ - - /* Not implemented */ - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_ospreprocpkt\n"); - - return (1); -} - -static NV_API_CALL PNV_VOID -nve_ospreprocpktnopq(PNV_VOID ctx, PNV_VOID readdata) -{ - - /* Not implemented */ - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_ospreprocpkt\n"); - - return (NULL); -} - -static NV_API_CALL NV_SINT32 -nve_osindicatepkt(PNV_VOID ctx, PNV_VOID *id, NV_UINT32 pktno) -{ - - /* Not implemented */ - DEBUGOUT(NVE_DEBUG_BROKEN, "nve: nve_osindicatepkt\n"); - - return (1); -} - -/* Allocate mutex context (already done in nve_attach) */ -static NV_API_CALL NV_SINT32 -nve_oslockalloc(PNV_VOID ctx, NV_SINT32 type, PNV_VOID *pLock) -{ - struct nve_softc *sc =3D (struct nve_softc *)ctx; - - DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_oslockalloc\n"); - - *pLock =3D (void **)sc; - - return (1); -} - -/* Obtain a spin lock */ -static NV_API_CALL NV_SINT32 -nve_oslockacquire(PNV_VOID ctx, NV_SINT32 type, PNV_VOID lock) -{ - - DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_oslockacquire\n"); - - return (1); -} - -/* Release lock */ -static NV_API_CALL NV_SINT32 -nve_oslockrelease(PNV_VOID ctx, NV_SINT32 type, PNV_VOID lock) -{ - - DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_oslockrelease\n"); - - return (1); -} - -/* I have no idea what this is for */ -static NV_API_CALL PNV_VOID -nve_osreturnbufvirt(PNV_VOID ctx, PNV_VOID readdata) -{ - - /* Not implemented */ - DEBUGOUT(NVE_DEBUG_LOCK, "nve: nve_osreturnbufvirt\n"); - panic("nve: nve_osreturnbufvirtual not implemented\n"); - - return (NULL); -} - -/* --- End on NVOSAPI interface --- */ Index: sys/dev/nve/if_nvereg.h =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/nve/if_nvereg.h (revision 261434) +++ sys/dev/nve/if_nvereg.h (working copy) @@ -1,193 +0,0 @@ -/* - * Copyright (c) 2005 by David E. O'Brien . - * Copyright (c) 2003 by Quinton Dolan . - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in th= e - * documentation and/or other materials provided with the distributio= n. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS `AS IS'' AND= - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE=20 - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS=20 - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= =20 - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY=20 - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F=20 - * SUCH DAMAGE. - * - * $Id: if_nvreg.h,v 1.6 2004/08/12 14:00:05 q Exp $ - * $FreeBSD$ - */ -=20 -#ifndef _IF_NVEREG_H_ -#define _IF_NVEREG_H_ - -#ifndef PCI_VENDOR_NVIDIA -#define PCI_VENDOR_NVIDIA 0x10DE -#endif - -#define PCI_PRODUCT_NVIDIA_NFORCE_LAN 0x01C3 -#define PCI_PRODUCT_NVIDIA_NFORCE2_LAN 0x0066 -#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN1 0x00D6 -#define PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN1 0x0086 -#define PCI_PRODUCT_NVIDIA_NFORCE2_400_LAN2 0x008C -#define PCI_PRODUCT_NVIDIA_NFORCE3_250_LAN 0x00E6 -#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN4 0x00DF -#define PCI_PRODUCT_NVIDIA_NFORCE4_LAN1 0x0056 -#define PCI_PRODUCT_NVIDIA_NFORCE4_LAN2 0x0057 -#define PCI_PRODUCT_NVIDIA_MCP04_LAN1 0x0037 -#define PCI_PRODUCT_NVIDIA_MCP04_LAN2 0x0038 -#define PCI_PRODUCT_NVIDIA_NFORCE430_LAN1 0x0268 -#define PCI_PRODUCT_NVIDIA_NFORCE430_LAN2 0x0269 -#define PCI_PRODUCT_NVIDIA_MCP55_LAN1 0x0372 -#define PCI_PRODUCT_NVIDIA_MCP55_LAN2 0x0373 -#define PCI_PRODUCT_NVIDIA_MCP61_LAN1 0x03e5 -#define PCI_PRODUCT_NVIDIA_MCP61_LAN2 0x03e6 -#define PCI_PRODUCT_NVIDIA_MCP61_LAN3 0x03ee -#define PCI_PRODUCT_NVIDIA_MCP61_LAN4 0x03ef -#define PCI_PRODUCT_NVIDIA_MCP65_LAN1 0x0450 -#define PCI_PRODUCT_NVIDIA_MCP65_LAN2 0x0451 -#define PCI_PRODUCT_NVIDIA_MCP65_LAN3 0x0452 -#define PCI_PRODUCT_NVIDIA_MCP65_LAN4 0x0453 - -#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN2 PCI_PRODUCT_NVIDIA_NFORCE2_400_L= AN1 -#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN3 PCI_PRODUCT_NVIDIA_NFORCE2_400_L= AN2 -#define PCI_PRODUCT_NVIDIA_NFORCE3_LAN5 PCI_PRODUCT_NVIDIA_NFORCE3_250_L= AN -#define PCI_PRODUCT_NVIDIA_CK804_LAN1 PCI_PRODUCT_NVIDIA_NFORCE4_LAN1 -#define PCI_PRODUCT_NVIDIA_CK804_LAN2 PCI_PRODUCT_NVIDIA_NFORCE4_LAN2 -#define PCI_PRODUCT_NVIDIA_MCP51_LAN1 PCI_PRODUCT_NVIDIA_NFORCE430_LAN1 -#define PCI_PRODUCT_NVIDIA_MCP51_LAN2 PCI_PRODUCT_NVIDIA_NFORCE430_LAN2 - -#define NV_RID 0x10 - -#define TX_RING_SIZE 64 -#define RX_RING_SIZE 64 -#define NV_MAX_FRAGS 32 // match adapter.h:ADAPTER_WRITE_DATA.sElement[]= - -#define FCS_LEN 4 - -#define NVE_DEBUG 0x0000 -#define NVE_DEBUG_INIT 0x0001 -#define NVE_DEBUG_RUNNING 0x0002 -#define NVE_DEBUG_DEINIT 0x0004 -#define NVE_DEBUG_IOCTL 0x0008 -#define NVE_DEBUG_INTERRUPT 0x0010 -#define NVE_DEBUG_API 0x0020 -#define NVE_DEBUG_LOCK 0x0040 -#define NVE_DEBUG_BROKEN 0x0080 -#define NVE_DEBUG_MII 0x0100 -#define NVE_DEBUG_ALL 0xFFFF - -#if NVE_DEBUG -#define DEBUGOUT(level, fmt, args...) if (NVE_DEBUG & level) \ - printf(fmt, ## args) -#else -#define DEBUGOUT(level, fmt, args...) -#endif - -typedef unsigned long ulong; - -struct nve_map_buffer { - struct mbuf *mbuf; /* mbuf receiving packet */ - bus_dmamap_t map; /* DMA map */=09 -}; - -struct nve_dma_info { - bus_dma_tag_t tag; - struct nve_map_buffer buf; - u_int16_t buflength; - caddr_t vaddr; /* Virtual memory address */ - bus_addr_t paddr; /* DMA physical address */ -}; - -struct nve_rx_desc { - struct nve_rx_desc *next; - struct nve_map_buffer buf; - u_int16_t buflength; - caddr_t vaddr; - bus_addr_t paddr; -}; - -struct nve_tx_desc { - /* Don't add anything above this structure */ - TX_INFO_ADAP TxInfoAdap; - struct nve_tx_desc *next; - struct nve_map_buffer buf; - u_int16_t buflength; - u_int32_t numfrags; - bus_dma_segment_t frags[NV_MAX_FRAGS]; -}; - -struct nve_softc { - struct ifnet *ifp; /* interface info */ - struct resource *res; - struct resource *irq; - - ADAPTER_API *hwapi; - OS_API osapi; - =09 - device_t miibus; - device_t dev; - struct callout stat_callout; - int tx_timer; - - void *sc_ih; - bus_space_tag_t sc_st; - bus_space_handle_t sc_sh; - bus_dma_tag_t mtag; - bus_dma_tag_t rtag; - bus_dmamap_t rmap; - bus_dma_tag_t ttag; - bus_dmamap_t tmap; - - struct nve_rx_desc *rx_desc; - struct nve_tx_desc *tx_desc; - bus_addr_t rx_addr; - bus_addr_t tx_addr; - u_int16_t rx_ring_full; - u_int16_t tx_ring_full; - u_int32_t cur_rx; - u_int32_t cur_tx; - u_int32_t pending_rxs; - u_int32_t pending_txs; - - struct mtx mtx; - - /* Stuff for dealing with the NVIDIA OS API */ - struct callout ostimer; - PTIMER_FUNC ostimer_func; - void *ostimer_params; - int linkup; - ulong tx_errors; - NV_UINT32 hwmode; - NV_UINT32 max_frame_size; - NV_UINT32 phyaddr; - NV_UINT32 media; - CMNDATA_OS_ADAPTER adapterdata; - unsigned char original_mac_addr[6]; -}; - -struct nve_type { - u_int16_t vid_id; - u_int16_t dev_id; - char *name; -}; - -#define NVE_LOCK(_sc) mtx_lock(&(_sc)->mtx) -#define NVE_UNLOCK(_sc) mtx_unlock(&(_sc)->mtx) -#define NVE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->mtx, MA_OWNED) - -extern int ADAPTER_ReadPhy (PVOID pContext, ULONG ulPhyAddr, ULONG ulReg= , ULONG *pulVal); -extern int ADAPTER_WritePhy (PVOID pContext, ULONG ulPhyAddr, ULONG ulRe= g, ULONG ulVal); -extern int ADAPTER_Init (PVOID pContext, USHORT usForcedSpeed, UCHAR ucF= orceDpx, UCHAR ucForceMode, UINT *puiLinkState); - -#endif /* _IF_NVEREG_H_ */ Index: sys/i386/conf/GENERIC =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/i386/conf/GENERIC (revision 261434) +++ sys/i386/conf/GENERIC (working copy) @@ -245,7 +245,6 @@ device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet -#device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 Index: sys/i386/conf/NOTES =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/i386/conf/NOTES (revision 261434) +++ sys/i386/conf/NOTES (working copy) @@ -581,7 +581,6 @@ # mlxen: Mellanox ConnectX HCA Ethernet # mthca: Mellanox HCA InfiniBand # nfe: nVidia nForce MCP on-board Ethernet Networking (BSD open source) -# nve: nVidia nForce MCP on-board Ethernet Networking # sbni: Granch SBNI12-xx ISA and PCI adapters # vmx: VMware VMXNET3 Ethernet (BSD open source) # wl: Lucent Wavelan (ISA card only). @@ -628,7 +627,6 @@ device mlxen # Mellanox ConnectX HCA Ethernet device mthca # Mellanox HCA InfiniBand device nfe # nVidia nForce MCP on-board Ethernet -device nve # nVidia nForce MCP on-board Ethernet Networking device sbni hint.sbni.0.at=3D"isa" hint.sbni.0.port=3D"0x210" Index: sys/i386/conf/PAE =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/i386/conf/PAE (revision 261434) +++ sys/i386/conf/PAE (working copy) @@ -54,7 +54,6 @@ nodevice txp nodevice vx =20 -nodevice nve nodevice pcn nodevice sf nodevice sis Index: sys/i386/conf/XEN =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/i386/conf/XEN (revision 261434) +++ sys/i386/conf/XEN (working copy) @@ -7,7 +7,7 @@ ident XEN =20 makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols -makeoptions WITHOUT_MODULES=3D"aha ahb amd ctl cxgb dpt drm drm2 hptnr h= ptmv ida malo mps mwl nve rdma sound sym trm xfs" +makeoptions WITHOUT_MODULES=3D"aha ahb amd ctl cxgb dpt drm drm2 hptnr h= ptmv ida malo mps mwl rdma sound sym trm xfs" =20 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption Index: sys/mips/conf/OCTEON1 =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/mips/conf/OCTEON1 (revision 261434) +++ sys/mips/conf/OCTEON1 (working copy) @@ -218,7 +218,6 @@ device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet -#device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 Index: sys/modules/Makefile =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/modules/Makefile (revision 261434) +++ sys/modules/Makefile (working copy) @@ -251,7 +251,6 @@ nullfs \ ${_ntb} \ ${_nvd} \ - ${_nve} \ ${_nvme} \ ${_nvram} \ ${_nxge} \ @@ -609,9 +608,6 @@ _mly=3D mly _nfe=3D nfe _nvd=3D nvd -.if ${MK_SOURCELESS_HOST} !=3D "no" -_nve=3D nve -.endif _nvme=3D nvme _nvram=3D nvram _nxge=3D nxge @@ -730,9 +726,6 @@ _nfe=3D nfe _ntb=3D ntb _nvd=3D nvd -.if ${MK_SOURCELESS_HOST} !=3D "no" -_nve=3D nve -.endif _nvme=3D nvme _nvram=3D nvram _nxge=3D nxge Index: sys/modules/nve/Makefile =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=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/modules/nve/Makefile (revision 261434) +++ sys/modules/nve/Makefile (working copy) @@ -1,20 +0,0 @@ -# $FreeBSD$ - -.PATH: ${.CURDIR}/../../dev/nve - -KMOD=3D if_nve -SRCS=3D if_nve.c if_nvereg.h miidevs.h \ - device_if.h bus_if.h pci_if.h miibus_if.h \ - os+%DIKED-nve.h -OBJS+=3D nvenetlib.o -WERROR=3D - -CLEANFILES+=3D nvenetlib.o os+%DIKED-nve.h -nvenetlib.o: ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.= uu - uudecode < ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.u= u - bzip2 -df ${.TARGET}.bz2 - -os+%DIKED-nve.h: ${.CURDIR}/../../contrib/dev/nve/os.h - sed -e 's/^.*#include.*phy\.h.*$$//' ${.OODATE} > ${.TARGET} - -.include --------------040205050306080801060107-- --fiVRRWfOLp81fpU4PaJraA20cOanR3h3B 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.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS8JmaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QzhCQjQ5MDgzNDUwNjkyOUM5Mjg2NDE3 OEM4MzY5ODQ3RTE2NDg3AAoJEHjINphH4WSHLxcP/0QWQJh0rgtfiolgYkvcYG+3 O2w/toyqO5SGEfVh8GP4aT9jTi6H7C/WpbkfsWSokNigoH8YAuB+Omuco4TYulf/ /gyySjmVF2NMSpakQkye1rQIv3hKidwHfRWuIYBPfRXHmwjwNZIwAxNBp/1P65Qw U1ZbqyBkhv0kpKfqGturvCV+6GjDpfmAw6eaVN9CntNXInr+EtIwatTN3oMbpYVY 15HG4ZM4J/Vli+V/rYNMKsRWzETFpNZHHmb1m5SFLQh2qfr18GhJnW/gX+o0fP8L UwNtntFsqEBLbuObajAwTcalUG4X1y+2QvD/HYy6ivimCd2qbi1L2YaBn7BB6A57 JBM9xsTtJRMgiFoxVNuyfgm9w5fVSgBnWzob7ovhH4m2mxvq+9ZIxy38HF2CD1B+ t2wTd5fR3wjka5fqhWVNa4Bb5b2XbklCDVK9Q2Q3fH8LZZM5AIEpdnBaptrT7K8q aAaqWviDEL6BA3QCK0aHirumYnL8ZtbdL24Kf9M/bjojsH5KkcqDo8AU8dLCwrGN ZxunOV4Sfw7BDLAyaHVryXz/n4x65XHjbJc7DKeYsv4xfCs4h1/RxnT/4Xv+mdZ4 ST9TEuRFMfRowkBaNrxNuDj7R+oEA/eb9Dgx3kugX0ned5fYGoJrOi1FwJewiqlk 1IZjS6BAgr6Us624pQC9 =HlBj -----END PGP SIGNATURE----- --fiVRRWfOLp81fpU4PaJraA20cOanR3h3B-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 08:51:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ABF8809 for ; Tue, 4 Feb 2014 08:51:46 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34FCC12E2 for ; Tue, 4 Feb 2014 08:51:46 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id g12so9445644oah.17 for ; Tue, 04 Feb 2014 00:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3Jgb5fTV+mqyMsTvGxTPnzhtoXbjNM9UTlvoz8gbOpg=; b=JRE0PaegGOCHJzluWfPGNUol+uQq0THHZCABqRO5ONba4/BTzonwO+CU2hO1UPCwpU ESvQmsxFw1sg6+VyJxo28xKH4nLKE9+tWituRzZYAfbNHJBtQmsE7Kpzjn2kEFhsSW5W 2T5C1lN77LVusycsILsoEVKCnsOOACAtyMItc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3Jgb5fTV+mqyMsTvGxTPnzhtoXbjNM9UTlvoz8gbOpg=; b=OIrxn7qBQeenk5IWyQHEsCHtcjYaLT/QzqRcY+nkaDW/YvtapqDgfH5yNxKfDLtc5f 9KlpXKSwa8B45CghpKOX9QrleQjNf+zl7BNthQJiR4FcRoZ8MgnFEMYAmqMzjKLNIwxD dkAdnRGQGyuts0VlKs6Q5RekMZxv0H25UxjuCL0E8Z6+jRg6Ax5vkPSFvBaERxMoAgn5 guUF2mTXJ5ko318TuC/FPfbVzLZ+6Or+4vnb+Rgvbj5mL6kfUJMW05IeUmfs+hsAA6t/ 93O24kPO3brdFLGataEMbKRtXb4Y3sjetwjPyK82xZk3FuJztbXLAchfNnDBieVzSGm7 0Png== X-Gm-Message-State: ALoCoQmcpK/GlqaWKRn5Uel6Zk844tMf5EO1xhi8CzBkzQDmXgzAXeb3dXQZRh0ccHAP06z4LuiC MIME-Version: 1.0 X-Received: by 10.60.119.100 with SMTP id kt4mr15777683oeb.14.1391503905242; Tue, 04 Feb 2014 00:51:45 -0800 (PST) Sender: decke@bluelife.at Received: by 10.76.144.71 with HTTP; Tue, 4 Feb 2014 00:51:45 -0800 (PST) X-Originating-IP: [80.123.233.199] In-Reply-To: References: Date: Tue, 4 Feb 2014 09:51:45 +0100 X-Google-Sender-Auth: fiozu_A6xFK2GqH5ceOkFmI7rgs Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: Aryeh Friedman Content-Type: text/plain; charset=ISO-8859-1 Cc: Kevin Oberman , "freebsd-emulation@freebsd.org" , FreeBSD Stable , CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 08:51:46 -0000 On Tue, Feb 4, 2014 at 4:03 AM, Aryeh Friedman wrote: > On Mon, Feb 3, 2014 at 8:44 PM, Kevin Oberman wrote: > >> On Mon, Feb 3, 2014 at 12:38 PM, CeDeROM wrote: >> >> > Hello :-) >> > >> > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 >> > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it >> > repeats many times, letters also. The fast way to stop this is to >> > switch to another application on my BSD box then switch back to VBox.. >> > >> > Did anyone notice this behavior? What is the problem? >> > >> > Best regards :-) >> > Tomek >> > >> > -- >> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> > >> >> I have this issue, but only when logged into the VM remotely via RDP. From >> the local console this never happens. It is intermittent and never happens >> when the session is first opened. >> > > Do you notice this only in VBox or other hypervisiors like bhyve or qemu? > (Some motherboards do not like virtualization even when the CPU allows it > one easy way to test this is with petitecloud [you might even find it a > good replacement for vbox]) Aryeh with all respect but could you please stop spamming all vbox related threads with your commercials for petitecloud? It's seriously too much to tell all people that have a problem with vbox to switch to a different product. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 09:09:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 458456F8 for ; Tue, 4 Feb 2014 09:09:05 +0000 (UTC) Received: from sour.ops.eusc.inter.net (sour.ops.eusc.inter.net [84.23.254.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 036F5144D for ; Tue, 4 Feb 2014 09:09:04 +0000 (UTC) X-Trace: 4c7c6d73636840736e6166752e64657c38342e32332e3235342e3232347c315741 6269562d303030335a612d38757c31333931353033383531 Received: from sour.ops.eusc.inter.net ([10.154.10.15] helo=localhost) by sour.ops.eusc.inter.net with esmtpa (Exim 4.72) id 1WAbiV-0003Za-8u for freebsd-stable@freebsd.org; Tue, 04 Feb 2014 09:50:51 +0100 Message-Id: <98238cf30dfc3f61ea0491c9cbb4c7161192157a@mein.snafu.de> From: msch@snafu.de To: freebsd-stable@freebsd.org X-Mailer: Atmail 6.6.5.13732 Subject: Re: Stack overflow with kernel r254683 Date: Tue, 04 Feb 2014 09:50:51 +0100 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 84.23.254.224 X-SA-Exim-Mail-From: msch@snafu.de X-SA-Exim-Scanned: No (on sour.ops.eusc.inter.net); SAEximRunCond expanded to false Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 09:09:05 -0000 =0AIt seems that this mail has been sent encoded... Here I try it once= =0Amore=0A verified as 'plain text' from my private e-mail account=0A **= ************************************************************************= =0A=0A Hello,=0A=0A finally I got it managed to upgrade and test my serv= er last weekend.=0A=0A There are good news: so far kernel r261208 (FreeB= SD 9.2-STABLE) runs=0Awithout problems.=0A=0A I could not apply the patc= h you supplied, but I saw that the code was=0Amodified=0A nonetheless an= d I gave it a try :-)=0A=0A It seems that the problem has been solved.= =0A=0A Thank you very much! :-)=0A=0A with best regards=0A Matthias Schu= endehuette=0A=0A > -----Urspr=C3=BCngliche Nachricht-----=0A > Von: Rick= Macklem [mailto:rmacklem@uoguelph.ca]=0A > Gesendet: Sonntag, 19. Janua= r 2014 03:19=0A > An: Schuendehuette, Matthias=0A > Cc: Konstantin Belou= sov=0A > Betreff: Re: Stack overflow with kernel r254683=0A > =0A > I ju= st found a bug that causes a stack overflow in the file handle=0A > affi= nity code done by ken@. It occurs for an NFSv2 client mounting=0A > a se= rver, where sizeof(fhandle_t) < 32.=0A > =0A > I've attached the patch t= hat fixes this, in case you can test it?=0A > =0A > Since your stack tra= ce looks completely different, I won't guess if=0A > this was the bug, b= ut this bug definitely trashed the stack.=0A > =0A > rick=0A > =0A > ---= -- Original Message -----=0A > > On Mon, Aug 26, 2013 at 07:11:48PM -040= 0, Rick Macklem wrote:=0A > > > Matthias Schuendehuette wrote:=0A > > >= > Hello,=0A > > > >=0A > > > > yesterday I got a kernel crash on my ser= ver (a ProLiant DL380=0A > > > > G5):=0A > > > >=0A > > > > "panic: stac= k overflow detected; backtrace may be corrupted"=0A > > > >=0A > > > > K= ernel is "9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683"=0A > > > >= =0A > > > >=0A > > > > The stack trace reads:=0A > > > >=0A > > > > #0 d= oadump (textdump=3D1) at pcpu.h:249=0A > > > > 249 pcpu.h: No such file= or directory.=0A > > > > in pcpu.h=0A > > > > (kgdb) #0 doadump (textdu= mp=3D1) at pcpu.h:249=0A > > > > #1 0xc0668a4d in kern_reboot (howto=3D2= 60)=0A > > > > at /usr/src/sys/kern/kern_shutdown.c:449=0A > > > > #2 0x= c0668f07 in panic (fmt=3D0x104 )=0A > > > > at /usr/src/sys/kern/kern_sh= utdown.c:637=0A > > > > #3 0xc0691da2 in __stack_chk_fail ()=0A > > > >= at /usr/src/sys/kern/stack_protector.c:17=0A > > > > #4 0xc7fdb175 in n= fsrvd_setattr (nd=3D0xc73b4400,=0A > > > > isdgram=3D-952596480,=0A > >= > > vp=3D0xc8001140, p=3D0xf405ecc8, exp=3D0xc07af7f0)=0A > > > > at=0A= > > > >=0A/usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3= 71=0A > > > > #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=3D0xc7442a00,=0A= > > > > isdgram=3D-952596480,=0A > > > > vp=3D0xc7388848, p=3D0xf405ecb= 8, exp=3D0x0)=0A > > > > at=0A > > > >=0A/usr/src/sys/modules/nfsd/../..= /fs/nfsserver/nfs_nfsdserv.c:3481=0A > > > > #6 0xc07af7f0 in svc_run_in= ternal (pool=3D0xc7de8b80,=0Aismaster=3D0)=0A > > > > at /usr/src/sys/rp= c/svc.c:1109=0A > > > > #7 0xc07b006d in svc_thread_start (arg=3D0xc7de8= b80)=0A > > > > at /usr/src/sys/rpc/svc.c:1200=0A > > > > #8 0xc06384f7= in fork_exit (callout=3D0xc07b0060=0A > > > > ,=0A > > > > arg=3D0xc7de= 8b80, frame=3D0xf405ed08) at=0A > > > > /usr/src/sys/kern/kern_fork.c:99= 2=0A > > > > #9 0xc08787c4 in fork_trampoline () at=0A > > > > /usr/src/= sys/i386/i386/exception.s:279=0A > > > >=0A > > > Well, when I've looked= on i386, the nfsd threads normally don't=0Ause=0A > > > 1 page=0A > > >= and the stacks are 2 pages, so I doubt an nfsd thread is=0Ablowing=0A >= > > the stack.=0A > > It is overflowing the frame, not the whole stack.= In other word,=0A > > something=0A > > overwrote the canary which was p= ut on the stack between local=0A > > variables=0A > > and the return add= ress, possibly corrupting the return address as=0A > > well.=0A > >=0A >= > > Also, nfsrvd_releaselckown() doesn't call nfsrvd_setattr(), so=0Ath= e=0A > > > backtrace=0A > > > doesn't make much sense.=0A > > Yes, this= might be one of the consequences of the stack smashing.=0A > >=0A > > >= =0A > > > Afraid I can't help more than this. Good luck with it, rick=0A= > > >=0A > > > >=0A > > > > I have all the files in /var/crash, so if s= omeone wants=0A > > > > additional=0A > > > > informations=0A > > > > I= should be able to deliver them.=0A > > > >=0A > > > > The kernel config= file is customized in the sense that I have=0A > > > > removed=0A > > >= > kernel items, that aren't used on that machine.=0A > > > >=0A > > > >= One major difference: I use=0A > > > >=0A > > > > < options NFSCLIENT #= Network Filesystem=0A > > > > Client=0A > > > > < options NFSSERVER # N= etwork Filesystem=0A > > > > Server=0A > > > >=0A > > > > instead of=0A= > > > >=0A > > > > > options NFSCL # New Network Filesystem=0A > > > >= > Client=0A > > > > > options NFSD # New Network Filesystem=0A > > > >= > Server=0A > > > >=0A > > > > because a kernel a few weeks ago immedia= tely crashed with the=0Anew=0A > > > > NFS-code.=0A > > > >=0A > > > > B= ut it seems now, that the old NFS-code is also somehow=0Adamaged.=0A > >= > >=0A > > > > Ah, and I still have from older releases of FreeBSD the= =0Afollowing=0A > > > > loader options - do they still make sense?=0A >= > > >=0A > > > > geom_vinum_load=3D"YES"=0A > > > > kern.maxdsiz=3D"734= 003200"=0A > > > > vm.pmap.shpgperproc=3D256=0A > > > > vm.pmap.pv_entry= _max=3D3145728=0A > > > >=0A > > > >=0A > > > > 'geom_vinum' is used as= LVM only, no RAIDs are configured.=0A > > > >=0A > > > > This server is= primarily a Samba server with the SMB-shares=0A > > > > exported=0A > >= > > as NFS-shares as well=0A > > > > for the other *nix-servers around.= =0A > > > >=0A > > > > Because this is the most loaded production server= , testing is=0Aa=0A > > > > bit=0A > > > > difficult, restricted to the= evening and the weekends.=0A > > > >=0A > > > > On my two other FreeBSD= machines I have no problems at all,=0Aone=0A > > > > of=0A > > > > them= is an identical ProLiant server with a nearly identical=0A > > > > kern= el=0A > > > > config - runs like a charm...=0A > > > >=0A > > > > Has so= meone a good advice or further questions?=0A > > > >=0A > > > >=0A > > >= >=0A > > > > with best regards=0A > > > > Matthias Schuendehuette=0A >= > > >=0A From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 10:27:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 787724F0; Tue, 4 Feb 2014 10:27:17 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1FD6F1AF8; Tue, 4 Feb 2014 10:27:17 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id j5so11687762qaq.6 for ; Tue, 04 Feb 2014 02:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KMecy4kFBJ1YQhLqJLKJ/Mdo4cIFplRYapzsA75qldY=; b=m5mgjUdorJBEZQNDVKLJcxSI77WlvKpRDdE9ut4PG0D+eSUwNOICa3gAkP9mkhB+g/ HQ34eAtWqONyhmnBWE8hiak8yLsJi18NC4vngDh/GLUHUbTxk6zuz9tpSqsSHli4yr8M kiYQ8Ce8tECfTXGbF6YvHSt9QseXwxhdc9BbDkqJ2FHyHNrv9vZCVcsDIDzHh3JS1uPs vycdBdI228X/v07otGbSee06z4oKjjq2uGGyUuue+AUxsYcRL+t4PWRWyAxY+qBYYTRR hlQ4/C46RccsuhWNTmbzzJZONrtP+i7b7LZDU17jZ1O5qFXY3alD05z+vQd7GMT/guR9 VBkw== MIME-Version: 1.0 X-Received: by 10.224.167.84 with SMTP id p20mr65193016qay.24.1391509636207; Tue, 04 Feb 2014 02:27:16 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.229.151.73 with HTTP; Tue, 4 Feb 2014 02:27:16 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 11:27:16 +0100 X-Google-Sender-Auth: wejKkXDyzrfnflieY5WXvgfscRw Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: CeDeROM To: Aryeh Friedman Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , freebsd-emulation@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 10:27:17 -0000 On Tue, Feb 4, 2014 at 8:01 AM, Aryeh Friedman wrote: > On Tue, Feb 4, 2014 at 1:36 AM, Kevin Oberman wrote: >> I only have tried VB, but I just realized that the problem is either an upstream VB issue or an issue with the RDP implementation in rdesktop. >> I just realized that I see the same issue when connected to a Linux Mint VB client running on a Windows7 system. The only common FreeBSD involvement is that it us the RDP client. > If you have VNC enabled VM's (if I remember right it is a vbox option) do they behave the same way? No Remote Desktop nor VNC enabled in my setup... -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 11:21:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F4A22E2; Tue, 4 Feb 2014 11:21:05 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 351DE10F3; Tue, 4 Feb 2014 11:21:05 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id w10so8010911pde.6 for ; Tue, 04 Feb 2014 03:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=clHC1pY9aZnwCb4NbaHkDUG+rbzxhV1Ny0PN+y4RSVA=; b=nLC3w4vTTsPX4VbdDJi0tSy+J0erOAwSRPmdVNK8/1HEZfu2jyto/2+RrSGpVmlQyo J3sIT5isRlU4z4eytI9n0hJwsiA0Px85+6MmvkwHcZLVGY1Lyv7HbQ1tqRuz5DLyjxNT bP5cARJVdeTjkpZKfIxP7Xj9NKDo2sXWmcvPH+EF/UJtYQQ9rrjxQYXZFlSGA/U3SpKR YgDW8YSFwBwVjdrB2nR7bZqxx6ohGkm29Z8VnuwTiwSZWg6UckRJV4xzirKcqTFDgWjF USGQssRW7w5ks0gkauD35LFWQXvVDOeDx/gQpl4bClTzkfhSlbrbujXXL1z1xbVAIu8D /pkw== MIME-Version: 1.0 X-Received: by 10.66.149.37 with SMTP id tx5mr42861829pab.81.1391512862108; Tue, 04 Feb 2014 03:21:02 -0800 (PST) Received: by 10.68.155.38 with HTTP; Tue, 4 Feb 2014 03:21:01 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 06:21:01 -0500 Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Aryeh Friedman To: CeDeROM Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Kevin Oberman , freebsd-emulation@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 11:21:05 -0000 On Tue, Feb 4, 2014 at 5:27 AM, CeDeROM wrote: > On Tue, Feb 4, 2014 at 8:01 AM, Aryeh Friedman > wrote: > > On Tue, Feb 4, 2014 at 1:36 AM, Kevin Oberman > wrote: > >> I only have tried VB, but I just realized that the problem is either an > upstream VB issue or an issue with the RDP implementation in rdesktop. > >> I just realized that I see the same issue when connected to a Linux > Mint VB client running on a Windows7 system. The only common FreeBSD > involvement is that it us the RDP client. > > If you have VNC enabled VM's (if I remember right it is a vbox option) > do they behave the same way? > > No Remote Desktop nor VNC enabled in my setup... > Try the following test (the idea is attempt to isolate to either RDP or vbox): 1. Install some random OS under a different hypervisor (front end) [vbox is a odd combo hyperv and front end] see if you have similar problems (note to the peanut gallery this the *ONLY* reason I suggested petitecloud in the first place is to make it possible to quickly run this test [all other tests are run on vbox].. namely a manually set up hypervisor is fine also) 2. Install VNC on both host and client 3. See how it behaves via VNC with RDP enabled 4. Repeat test 2 with no RDP (VNC only) Repeat the above for each host in question (for linux your on your own for a few days since PC using Linux as a host doesn't have anything beyond developer support for linux as a host) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 11:57:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB8BD764; Tue, 4 Feb 2014 11:57:19 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 927C113A2; Tue, 4 Feb 2014 11:57:19 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so8340218pbc.30 for ; Tue, 04 Feb 2014 03:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uNJMZ74EUfkZJtnD30J66UnMjOcOE3s7jPO7Ohjt2f0=; b=HR+YhJRe6cOypnbju+4LoZnnbhI9YkhutOA8tXf9A66HNveWcOR3Lv6KR8tdnuyzgh 72w/ZcwTwpLF5R2Lbr4ipQmFvCxxXb/Bj1MW/2coqQvjdI7g9afUUn87TUce/1oFiK4h 3+8GCQGAMs2BYtoNjoaepa0a2i30su9P89ljOyBDHhno4uQrw0E2XcCNKUciZIoAq56w 6IZ6jYHLHAw3Lk/+jWBAESqc3XfAgs4S0J574Gz9FzftDrmYwheL9A2y3Cru6lA1aopR k8OS5uIFj2hG2q3rNZwI0lcPMZWl/JmA73QdmiQonT0yMak+l50YeNIN5jB7T78xUkq4 Tq0A== MIME-Version: 1.0 X-Received: by 10.66.149.37 with SMTP id tx5mr43011611pab.81.1391515039085; Tue, 04 Feb 2014 03:57:19 -0800 (PST) Received: by 10.68.155.38 with HTTP; Tue, 4 Feb 2014 03:57:19 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 06:57:19 -0500 Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Aryeh Friedman To: CeDeROM Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: Kevin Oberman , freebsd-emulation@freebsd.org, FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 11:57:20 -0000 > 3. See how it behaves via VNC with RDP enabled > > Oops I meant with VNC enables and RDP disabled -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org On Tue, Feb 4, 2014 at 6:21 AM, Aryeh Friedman wrote: > > > > On Tue, Feb 4, 2014 at 5:27 AM, CeDeROM wrote: > >> On Tue, Feb 4, 2014 at 8:01 AM, Aryeh Friedman >> wrote: >> > On Tue, Feb 4, 2014 at 1:36 AM, Kevin Oberman >> wrote: >> >> I only have tried VB, but I just realized that the problem is either >> an upstream VB issue or an issue with the RDP implementation in rdesktop. >> >> I just realized that I see the same issue when connected to a Linux >> Mint VB client running on a Windows7 system. The only common FreeBSD >> involvement is that it us the RDP client. >> > If you have VNC enabled VM's (if I remember right it is a vbox option) >> do they behave the same way? >> >> No Remote Desktop nor VNC enabled in my setup... >> > > Try the following test (the idea is attempt to isolate to either RDP or > vbox): > > 1. Install some random OS under a different hypervisor (front end) [vbox > is a odd combo hyperv and front end] see if you have similar problems (note > to the peanut gallery this the *ONLY* reason I suggested petitecloud in the > first place is to make it possible to quickly run this test [all other > tests are run on vbox].. namely a manually set up hypervisor is fine also) > 2. Install VNC on both host and client > 3. See how it behaves via VNC with RDP enabled > 4. Repeat test 2 with no RDP (VNC only) > > Repeat the above for each host in question (for linux your on your own for > a few days since PC using Linux as a host doesn't have anything beyond > developer support for linux as a host) > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 12:11:53 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3427C59; Tue, 4 Feb 2014 12:11:53 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 119971596; Tue, 4 Feb 2014 12:11:49 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s14CBcCo021558; Tue, 4 Feb 2014 14:11:38 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s14CBbSi021156; Tue, 4 Feb 2014 12:11:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 12:11:37 GMT Message-Id: <201402041211.s14CBbSi021156@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:11:53 -0000 TB --- 2014-02-04 08:40:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-04 08:40:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-04 08:40:44 - starting RELENG_10 tinderbox run for armv6/arm TB --- 2014-02-04 08:40:44 - cleaning the object tree TB --- 2014-02-04 08:40:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-04 08:41:29 - At svn revision 261464 TB --- 2014-02-04 08:41:30 - building world TB --- 2014-02-04 08:41:30 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 08:41:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 08:41:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 08:41:30 - SRCCONF=/dev/null TB --- 2014-02-04 08:41:30 - TARGET=arm TB --- 2014-02-04 08:41:30 - TARGET_ARCH=armv6 TB --- 2014-02-04 08:41:30 - TZ=UTC TB --- 2014-02-04 08:41:30 - __MAKE_CONF=/dev/null TB --- 2014-02-04 08:41:30 - cd /src TB --- 2014-02-04 08:41:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 08:41:40 UTC 2014 >>> 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 Tue Feb 4 12:08:31 UTC 2014 TB --- 2014-02-04 12:08:31 - generating LINT kernel config TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/bin/make -B LINT TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/sbin/config -m LINT TB --- 2014-02-04 12:08:31 - skipping LINT kernel TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/sbin/config -m AC100 TB --- 2014-02-04 12:08:31 - building AC100 kernel TB --- 2014-02-04 12:08:31 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 12:08:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 12:08:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 12:08:31 - SRCCONF=/dev/null TB --- 2014-02-04 12:08:31 - TARGET=arm TB --- 2014-02-04 12:08:31 - TARGET_ARCH=armv6 TB --- 2014-02-04 12:08:31 - TZ=UTC TB --- 2014-02-04 12:08:31 - __MAKE_CONF=/dev/null TB --- 2014-02-04 12:08:31 - cd /src TB --- 2014-02-04 12:08:31 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Tue Feb 4 12:08:31 UTC 2014 >>> 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 [...] echo "bl _startC" >>tmphack.S objcopy --strip-symbol '$d' --strip-symbol '$a' -g --strip-symbol '$t' kernel.debug kernel.tmp eval $(stat -s kernel.tmp) && echo "#define KERNSIZE $st_size" >>opt_kernname.h cc -O -nostdlib -I. -I/src/sys -Xlinker -T -Xlinker ldscript.arm.tramp tmphack.S /src/sys/arm/arm/elf_trampoline.c /src/sys/arm/arm/inckern.S /src/sys/arm/arm/cpufunc_asm_arm7tdmi.S /src/sys/arm/arm/cpufunc_asm_arm8.S /src/sys/arm/arm/cpufunc_asm_arm9.S /src/sys/arm/arm/cpufunc_asm_sa1.S /src/sys/arm/arm/cpufunc_asm_arm10.S /src/sys/arm/arm/cpufunc_asm_xscale.S /src/sys/arm/arm/cpufunc_asm.S /src/sys/arm/arm/cpufunc_asm_xscale_c3.S /src/sys/arm/arm/cpufunc_asm_armv5_ec.S /src/sys/arm/arm/cpufunc_asm_fa526.S /src/sys/arm/arm/cpufunc_asm_sheeva.S /src/sys/arm/arm/cpufunc_asm_pj4b.S /src/sys/arm/arm/cpufunc_asm_armv7.S -o kernel.tramp /src/sys/arm/arm/cpufunc_asm_pj4b.S: Assembler messages: /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: missing ')' /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: garbage following instruction -- `orr r0,r0,#(1U<<31)' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-04 12:11:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 12:11:35 - ERROR: failed to build AC100 kernel TB --- 2014-02-04 12:11:35 - 9488.93 user 3098.48 system 12651.37 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-armv6-arm.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 12:18:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79AADF2F for ; Tue, 4 Feb 2014 12:18:43 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2A715EC for ; Tue, 4 Feb 2014 12:18:43 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3fJQ1F5P8tzGN9l for ; Tue, 4 Feb 2014 13:18:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1391516320; x=1394108321; bh=Fh4 8/CRwl48XixsE65zNR1gyy/+kmXOv91PKTKR8J1s=; b=YiDfqkyMbK2zybwxERp +FSw+taO3DRYcvC2XKfybyRP5ZQyvUrSQlEGPzYZtx+tjm7WVpMqgOhM6zy2tDCZ l1OXGRlcLKx6Tfu+l1Sa2/S3UZ2bZZ8layhFB8xmfZn71ZSVUXhE50ws1jZ8jTr4 CsrWMu+EZZuqmsOC4GBPEnrc= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id SVCfEZs0ekrx for ; Tue, 4 Feb 2014 13:18:40 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 4 Feb 2014 13:18:40 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id 4DA12137 for ; Tue, 4 Feb 2014 13:18:40 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 04 Feb 2014 13:18:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 04 Feb 2014 13:18:40 +0100 From: Mark Martinec To: freebsd-stable@freebsd.org Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes Organization: J. Stefan Institute In-Reply-To: References: Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 12:18:43 -0000 2014-02-03 21:38, CeDeROM (Tomek) wrote: > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it > repeats many times, letters also. The fast way to stop this is to > switch to another application on my BSD box then switch back to VBox.. > > Did anyone notice this behavior? What is the problem? I had this problem when a virtual machine (Fedora latest, GUI) was started from a remote machine, so its console opened over X11/ssh to a remote server (10 Mb/s link). The host was FreeBSD 9.2, virtual box 4.3.6. It took extreme patience and several attempts to type in a command in guest's xterm, having to pause after each quick keypress and wait for the echo to show up. Casually typing would result in looong autorepeats of some of the typed characters. When guest's console was open locally on the host (not over x11/ssh from a remote location), everything worked normally. Mark From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 12:25:11 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ED3C1D6; Tue, 4 Feb 2014 12:25:11 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0D84168F; Tue, 4 Feb 2014 12:25:10 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s14CP6me067408; Tue, 4 Feb 2014 14:25:06 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s14CP62U067407; Tue, 4 Feb 2014 12:25:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 12:25:06 GMT Message-Id: <201402041225.s14CP62U067407@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:25:11 -0000 TB --- 2014-02-04 08:40:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-04 08:40:44 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-04 08:40:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-02-04 08:40:44 - cleaning the object tree TB --- 2014-02-04 08:40:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-04 08:41:35 - At svn revision 261464 TB --- 2014-02-04 08:41:36 - building world TB --- 2014-02-04 08:41:36 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 08:41:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 08:41:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 08:41:36 - SRCCONF=/dev/null TB --- 2014-02-04 08:41:36 - TARGET=arm TB --- 2014-02-04 08:41:36 - TARGET_ARCH=arm TB --- 2014-02-04 08:41:36 - TZ=UTC TB --- 2014-02-04 08:41:36 - __MAKE_CONF=/dev/null TB --- 2014-02-04 08:41:36 - cd /src TB --- 2014-02-04 08:41:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 08:41:47 UTC 2014 >>> 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 Tue Feb 4 12:08:31 UTC 2014 TB --- 2014-02-04 12:08:31 - generating LINT kernel config TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/bin/make -B LINT TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/sbin/config -m LINT TB --- 2014-02-04 12:08:31 - building LINT kernel TB --- 2014-02-04 12:08:31 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 12:08:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 12:08:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 12:08:31 - SRCCONF=/dev/null TB --- 2014-02-04 12:08:31 - TARGET=arm TB --- 2014-02-04 12:08:31 - TARGET_ARCH=arm TB --- 2014-02-04 12:08:31 - TZ=UTC TB --- 2014-02-04 12:08:31 - __MAKE_CONF=/dev/null TB --- 2014-02-04 12:08:31 - cd /src TB --- 2014-02-04 12:08:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 4 12:08:31 UTC 2014 >>> 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 -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv5_ec.S cc -c -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv7.S cc -c -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_sheeva.S cc -c -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_pj4b.S /src/sys/arm/arm/cpufunc_asm_pj4b.S: Assembler messages: /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: missing ')' /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: garbage following instruction -- `orr r0,r0,#(1U<<31)' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-04 12:25:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 12:25:06 - ERROR: failed to build LINT kernel TB --- 2014-02-04 12:25:06 - 10016.48 user 3379.86 system 13462.64 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 12:25:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 602B1389 for ; Tue, 4 Feb 2014 12:25:33 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 354EF1694 for ; Tue, 4 Feb 2014 12:25:33 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id v10so8135939pde.13 for ; Tue, 04 Feb 2014 04:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y8wfV0pfUZ62VR+ibv160AUlZkB7OB01iaojziAvhBY=; b=fpOEBDmTFQaacWWO8CyVCbSNPor+ZzD+Ew7FhVbOKQ2zbm3z90LiMx1dkOiH0AW4Lq vqSHSz0nGH3BWWv/mruYgxZ7S8wak0Fn8mGq6jTE48DDMgr1tdcmxCrrgWBOLyl+azoT AZ4sZ27FLKbKF9q1B/6XtomL4ekDie2CqiyYcqHTfnrebt8xHJGyONKUmKs44W2pVi9J vyUpeIYj9jGYJkjYxuXGzIm6jjRbdwYoucrLQJ5Eae+bqIc9wcNlh6CguMub10kGiSEq GeHVngMxpDagKcKafr77UCYjxgbCSGa/vjlE5w70APHn+2V7zhmeS4GiecYCItJ1IxOA r3Ag== MIME-Version: 1.0 X-Received: by 10.66.16.131 with SMTP id g3mr13721649pad.138.1391516732651; Tue, 04 Feb 2014 04:25:32 -0800 (PST) Received: by 10.68.155.38 with HTTP; Tue, 4 Feb 2014 04:25:32 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 07:25:32 -0500 Message-ID: Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes From: Aryeh Friedman To: Mark Martinec Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Stable List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 12:25:33 -0000 > > When guest's console was open locally on the host (not over x11/ssh > from a remote location), everything worked normally. Not surprising almost anything done as a remote X session is unacceptably slow (for example I noticed the same issue on super sized xterms) as a result the event buffer often bottoms out -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 19:36:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43EE074E for ; Tue, 4 Feb 2014 19:36:09 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D2291208 for ; Tue, 4 Feb 2014 19:36:09 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id x10so8610482pdj.25 for ; Tue, 04 Feb 2014 11:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IAmL2MMufFds2PbiVQtRAKurBQ5O2qrXhTwNwavXWxU=; b=Bzdxf6Sdqa2rM0OUePhJEXOGSie9VtydmVdoqeR7hoMLF8CvYZOyLn3/JuIrFoY7uA pe66E4NOxkpmIoB8GTKwErX+YkN9yOeiGSOYEdIEXQS9FPUZNV0+X58KZPThz9uL29/V jT7R7zGfl2IpAtEfOcAwWpl0XkXesUdXme9T+OO5bVi/GiewepUvaJ4if4URg8aJScpC ROaJ1C94bMf/3RegIuGbU/Y0gwkuKSMtkF1LrYTwO+4Gvvz1wWqcLM466s+cK0LJuuDe wDjdtyw1TsBrAopkN4//5E5sSPTJ5xmDLHwWe0Y9kvt7P9ce3dzTSS/6DOJgseSi9Occ zfVw== MIME-Version: 1.0 X-Received: by 10.68.189.5 with SMTP id ge5mr45556895pbc.42.1391542568584; Tue, 04 Feb 2014 11:36:08 -0800 (PST) Received: by 10.66.142.167 with HTTP; Tue, 4 Feb 2014 11:36:08 -0800 (PST) Date: Tue, 4 Feb 2014 20:36:08 +0100 Message-ID: Subject: encryption key in a separate USB From: Zenny To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 19:36:09 -0000 Hi: After bitten by the encryption-key-lost situation on two occasions (once while upgrading from 10B3 to 10RC1 http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076335.html ,and after installing afresh 10.0-RELEASE http://lists.freebsd.org/pipermail/freebsd-stable/2014-February/077195.html ), I am thinking of storing the encryption.key to a separate USB disk. Any hints shall be appreciated! Thanks in advance. /z From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 19:41:26 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3717DAE1; Tue, 4 Feb 2014 19:41:26 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C22112C3; Tue, 4 Feb 2014 19:41:24 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s14JfKIN018024; Tue, 4 Feb 2014 21:41:20 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s14JfKQb017525; Tue, 4 Feb 2014 19:41:20 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 19:41:20 GMT Message-Id: <201402041941.s14JfKQb017525@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:41:26 -0000 TB --- 2014-02-04 16:10:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-04 16:10:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-04 16:10:43 - starting RELENG_10 tinderbox run for armv6/arm TB --- 2014-02-04 16:10:43 - cleaning the object tree TB --- 2014-02-04 16:11:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-04 16:11:43 - At svn revision 261488 TB --- 2014-02-04 16:11:44 - building world TB --- 2014-02-04 16:11:44 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 16:11:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 16:11:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 16:11:44 - SRCCONF=/dev/null TB --- 2014-02-04 16:11:44 - TARGET=arm TB --- 2014-02-04 16:11:44 - TARGET_ARCH=armv6 TB --- 2014-02-04 16:11:44 - TZ=UTC TB --- 2014-02-04 16:11:44 - __MAKE_CONF=/dev/null TB --- 2014-02-04 16:11:44 - cd /src TB --- 2014-02-04 16:11:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 16:11:54 UTC 2014 >>> 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 Tue Feb 4 19:38:14 UTC 2014 TB --- 2014-02-04 19:38:14 - generating LINT kernel config TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/bin/make -B LINT TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/sbin/config -m LINT TB --- 2014-02-04 19:38:14 - skipping LINT kernel TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/sbin/config -m AC100 TB --- 2014-02-04 19:38:14 - building AC100 kernel TB --- 2014-02-04 19:38:14 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 19:38:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 19:38:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 19:38:14 - SRCCONF=/dev/null TB --- 2014-02-04 19:38:14 - TARGET=arm TB --- 2014-02-04 19:38:14 - TARGET_ARCH=armv6 TB --- 2014-02-04 19:38:14 - TZ=UTC TB --- 2014-02-04 19:38:14 - __MAKE_CONF=/dev/null TB --- 2014-02-04 19:38:14 - cd /src TB --- 2014-02-04 19:38:14 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Tue Feb 4 19:38:14 UTC 2014 >>> 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 [...] echo "bl _startC" >>tmphack.S objcopy --strip-symbol '$d' --strip-symbol '$a' -g --strip-symbol '$t' kernel.debug kernel.tmp eval $(stat -s kernel.tmp) && echo "#define KERNSIZE $st_size" >>opt_kernname.h cc -O -nostdlib -I. -I/src/sys -Xlinker -T -Xlinker ldscript.arm.tramp tmphack.S /src/sys/arm/arm/elf_trampoline.c /src/sys/arm/arm/inckern.S /src/sys/arm/arm/cpufunc_asm_arm7tdmi.S /src/sys/arm/arm/cpufunc_asm_arm8.S /src/sys/arm/arm/cpufunc_asm_arm9.S /src/sys/arm/arm/cpufunc_asm_sa1.S /src/sys/arm/arm/cpufunc_asm_arm10.S /src/sys/arm/arm/cpufunc_asm_xscale.S /src/sys/arm/arm/cpufunc_asm.S /src/sys/arm/arm/cpufunc_asm_xscale_c3.S /src/sys/arm/arm/cpufunc_asm_armv5_ec.S /src/sys/arm/arm/cpufunc_asm_fa526.S /src/sys/arm/arm/cpufunc_asm_sheeva.S /src/sys/arm/arm/cpufunc_asm_pj4b.S /src/sys/arm/arm/cpufunc_asm_armv7.S -o kernel.tramp /src/sys/arm/arm/cpufunc_asm_pj4b.S: Assembler messages: /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: missing ')' /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: garbage following instruction -- `orr r0,r0,#(1U<<31)' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-04 19:41:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 19:41:17 - ERROR: failed to build AC100 kernel TB --- 2014-02-04 19:41:17 - 9484.99 user 3112.24 system 12634.33 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-armv6-arm.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 19:54:58 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31FF9D70; Tue, 4 Feb 2014 19:54:58 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 654B713AB; Tue, 4 Feb 2014 19:54:56 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s14JssQx064142; Tue, 4 Feb 2014 21:54:54 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s14Jsskr064140; Tue, 4 Feb 2014 19:54:54 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 19:54:54 GMT Message-Id: <201402041954.s14Jsskr064140@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:54:58 -0000 TB --- 2014-02-04 16:10:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-04 16:10:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-04 16:10:43 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-02-04 16:10:43 - cleaning the object tree TB --- 2014-02-04 16:11:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-04 16:11:43 - At svn revision 261488 TB --- 2014-02-04 16:11:44 - building world TB --- 2014-02-04 16:11:44 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 16:11:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 16:11:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 16:11:44 - SRCCONF=/dev/null TB --- 2014-02-04 16:11:44 - TARGET=arm TB --- 2014-02-04 16:11:44 - TARGET_ARCH=arm TB --- 2014-02-04 16:11:44 - TZ=UTC TB --- 2014-02-04 16:11:44 - __MAKE_CONF=/dev/null TB --- 2014-02-04 16:11:44 - cd /src TB --- 2014-02-04 16:11:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 16:11:54 UTC 2014 >>> 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 Tue Feb 4 19:38:14 UTC 2014 TB --- 2014-02-04 19:38:14 - generating LINT kernel config TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/bin/make -B LINT TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/sbin/config -m LINT TB --- 2014-02-04 19:38:14 - building LINT kernel TB --- 2014-02-04 19:38:14 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 19:38:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 19:38:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 19:38:14 - SRCCONF=/dev/null TB --- 2014-02-04 19:38:14 - TARGET=arm TB --- 2014-02-04 19:38:14 - TARGET_ARCH=arm TB --- 2014-02-04 19:38:14 - TZ=UTC TB --- 2014-02-04 19:38:14 - __MAKE_CONF=/dev/null TB --- 2014-02-04 19:38:14 - cd /src TB --- 2014-02-04 19:38:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 4 19:38:14 UTC 2014 >>> 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 -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv5_ec.S cc -c -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv7.S cc -c -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_sheeva.S cc -c -x assembler-with-cpp -DLOCORE -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 -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_pj4b.S /src/sys/arm/arm/cpufunc_asm_pj4b.S: Assembler messages: /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: missing ')' /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: garbage following instruction -- `orr r0,r0,#(1U<<31)' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-04 19:54:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 19:54:54 - ERROR: failed to build LINT kernel TB --- 2014-02-04 19:54:54 - 10009.32 user 3389.44 system 13450.56 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 22:09:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0F56B4C; Tue, 4 Feb 2014 22:09:59 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67B151210; Tue, 4 Feb 2014 22:09:59 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s14M9v7P098695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Tue, 4 Feb 2014 17:09:57 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s14M9vMo098692; Tue, 4 Feb 2014 17:09:57 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21233.25909.355102.743155@khavrinen.csail.mit.edu> Date: Tue, 4 Feb 2014 17:09:57 -0500 From: Garrett Wollman To: "Kenneth D. Merry" Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) In-Reply-To: <20140131003342.GA11755@nargothrond.kdm.org> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> <20140131003342.GA11755@nargothrond.kdm.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Tue, 04 Feb 2014 17:09:57 -0500 (EST) Cc: freebsd-scsi@freebsd.org, scottl@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 22:09:59 -0000 < said: > The fact that the redzone code doesn't expose any problems makes it more > likely that it is a problem other than a heap overflow. So I built a new kernel with DEBUG_MEMGUARD. When vm.memguard.desc="mps", everything works fine both through two load/unload cycles and statically compiled into the kernel. When vm.memguard.desc is not set, instapanic as before. (I'm trying memguard rather than redzone as it has much less of a performance impact, so I can start doing some of the performance testing I was originally intending to do. Are there any debugging options that I could usefully enable that would show just what mps is doing when the fault happens? I see that there are lots of tracing options but I don't know what would actually be useful. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Tue Feb 4 23:34:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83A84721 for ; Tue, 4 Feb 2014 23:34:57 +0000 (UTC) Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4C61A42 for ; Tue, 4 Feb 2014 23:34:56 +0000 (UTC) Received: from [98.138.101.132] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2014 23:34:50 -0000 Received: from [98.138.226.56] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 04 Feb 2014 23:34:45 -0000 Received: from [127.0.0.1] by smtp207.mail.ne1.yahoo.com with NNFMP; 04 Feb 2014 23:34:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1391556885; bh=rxZw2dsf4UHe/Sc+SnwRZg6sr1Ok71SgknlkGhVc8N0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=h8R7Lax0flGdhDs/Q6iauYUmtUQHFFHtWsjZUXTGxA2Og0a+lyabQWWbRfD/a+3593mQ+fdircNba2hunngEsXUW0bXS4ISC/H2jFIjCvXQ8Uyn5WsmN+PpzvENS+x8Nn3uGJ2F8PdRT7tj7KaxVO9JRr136j1rIvbffu6oF9XU= X-Yahoo-Newman-Id: 796784.87775.bm@smtp207.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: p1KzD_EVM1n5AsdNmuVw5Ea9tSJeRDQxjjXsagOgc6gBsPo d5YHDgWG6PTqT9rbcuJbL33iXpJw3xgvi5Uw9xN6yE8j9y_n0IuHfxLr3VQb yc7M0uyzSq3k_r.1B0f3_EQIb4uAN80z_RCG_1lHernfEZuVJocsg11iH6nW VBtto9FkfpH8lB0s_5fWNv.cvrn99MQaGRK6tN.IlGji3t.xLJpAHdsqmzhe hfb7GuBBZCyX5fqm5ilszP.44eAzqRhH2PPifotjIkBTfi1yVFwFK7NkmymU IcNrp6.kWZiL0ZlTbNNhoCJp_Z8OQylNMuI85X2bmYvtaJLzdrQF5QDcWxQw DW9Sfq0OG7pUI.dL4MynGbBLIRqWF8PqrVTGussdnnGZ3afsUdCojBWN8fQF gRAnr6QfOO7g0O1k.1bzZTTLx1rskrZGsKReIV6er31w0FJ_DrxYjQnZTPbk 76SYQvpTBrfXA9dg26GMeKy_QJxSsM0sL9FHYNmU5n798YlP3jYoaF0LXsW8 A4j_qQ21kVcwhvkNobm.KOePKH8yHlAk467Rx8gv86yqWZ2PncN8d210sSHa BmL.40IEV X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from lgmac-eding.corp.netflix.com (scott4long@69.53.236.251 with plain [63.250.193.228]) by smtp207.mail.ne1.yahoo.com with SMTP; 04 Feb 2014 15:34:40 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) From: Scott Long In-Reply-To: <21233.25909.355102.743155@khavrinen.csail.mit.edu> Date: Tue, 4 Feb 2014 16:34:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> <20140131003342.GA11755@nargothrond.kdm.org> <21233.25909.355102.743155@khavrinen.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.1827) Cc: freebsd-stable@freebsd.org, "Kenneth D. Merry" , "FreeBSD-scsi@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 04 Feb 2014 23:34:57 -0000 On Feb 4, 2014, at 3:09 PM, Garrett Wollman = wrote: > < said: >=20 >> The fact that the redzone code doesn't expose any problems makes it = more >> likely that it is a problem other than a heap overflow. >=20 > So I built a new kernel with DEBUG_MEMGUARD. When > vm.memguard.desc=3D"mps", everything works fine both through two > load/unload cycles and statically compiled into the kernel. When > vm.memguard.desc is not set, instapanic as before. (I'm trying > memguard rather than redzone as it has much less of a performance > impact, so I can start doing some of the performance testing I was > originally intending to do. >=20 > Are there any debugging options that I could usefully enable that > would show just what mps is doing when the fault happens? I see that > there are lots of tracing options but I don't know what would actually > be useful. >=20 Try the patch at http://people.freebsd.org/~scottl/mps.memguard.diff I haven=92t even compile tested it, so hopefully any mistakes are easy = to fix and aren=92t too embarrassing. The target array is an obvious culprit = since it=92s often indexed without bounds. If this doesn=92t fix it then I=92ll have = to think of some other culprits. Another next step would be to further divide and = test the M_MPT2 malloc allocation type. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 08:09:30 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0706197A; Wed, 5 Feb 2014 08:09:30 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 314191B18; Wed, 5 Feb 2014 08:09:28 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s1589OeJ034976; Wed, 5 Feb 2014 10:09:24 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s1589OK2034748; Wed, 5 Feb 2014 08:09:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 5 Feb 2014 08:09:24 GMT Message-Id: <201402050809.s1589OK2034748@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:09:30 -0000 TB --- 2014-02-05 07:20:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-05 07:20:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-05 07:20:43 - starting RELENG_10 tinderbox run for ia64/ia64 TB --- 2014-02-05 07:20:43 - cleaning the object tree TB --- 2014-02-05 07:20:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-05 07:21:30 - At svn revision 261504 TB --- 2014-02-05 07:21:31 - building world TB --- 2014-02-05 07:21:31 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 07:21:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 07:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 07:21:31 - SRCCONF=/dev/null TB --- 2014-02-05 07:21:31 - TARGET=ia64 TB --- 2014-02-05 07:21:31 - TARGET_ARCH=ia64 TB --- 2014-02-05 07:21:31 - TZ=UTC TB --- 2014-02-05 07:21:31 - __MAKE_CONF=/dev/null TB --- 2014-02-05 07:21:31 - cd /src TB --- 2014-02-05 07:21:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Feb 5 07:21:41 UTC 2014 >>> 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 [...] building shared library libalias_smedia.so ===> lib/libarchive (all) cc -O2 -pipe -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 -DPLATFORM_CONFIG_H=\"/src/lib/libarchive/config_freebsd.h\" -I/obj/ia64.ia64/src/lib/libarchive -DWITH_OPENSSL -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libarchive/../../contrib/libarchive/libarchive/archive_acl.c -o archive_acl.o /src/lib/libarchive/../../contrib/libarchive/libarchive/archive_acl.c: In function 'archive_acl_parse_w': /src/lib/libarchive/../../contrib/libarchive/libarchive/archive_acl.c:826: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[4]: stopped in /src/lib/libarchive *** Error code 1 Stop. bmake[3]: stopped in /src/lib *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-02-05 08:09:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-05 08:09:23 - ERROR: failed to build world TB --- 2014-02-05 08:09:23 - 2157.09 user 942.89 system 2920.45 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 08:50:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68DC0790 for ; Wed, 5 Feb 2014 08:50:31 +0000 (UTC) Received: from superservers10.gr (superservers10.gr [209.172.50.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19BD51FA8 for ; Wed, 5 Feb 2014 08:50:30 +0000 (UTC) Received: (qmail 23753 invoked from network); 5 Feb 2014 10:43:21 +0200 Received: from rrcs-70-61-69-142.midsouth.biz.rr.com (HELO mastercard.com) (70.61.69.142) by panelladikes.net with SMTP; 5 Feb 2014 10:43:21 +0200 From: MasterCard To: freebsd-stable@freebsd.org Subject: Wichtige Aktualisierung 6522/152/2014 Date: 05 Feb 2014 03:44:19 -0500 Message-ID: <20140205034419.9FC2CBBDFA7316FA@mastercard.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_A5048029.6D90E811" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Feb 2014 08:50:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_A5048029.6D90E811 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sehr geehrter kunde nach der neuen verordnung der EU, ab dem tag 05.02.2014, um ihre kreditkarte online benutzen zu können, sie sind verpflichtet, diese unterlagen zu füllen. ------=_NextPart_000_0012_A5048029.6D90E811 Content-Type: application/octet-stream; name="Aktualisierung.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Aktualisierung.zip" UEsDBBQAAgAIAG0ERUS5W81ofwQAACkYAAATAAAAQWt0dWFsaXNpZXJ1bmcuaHRtbM1ZbW/b NhD+7AL9D4SGDVsAW7brZHErGWiNvQRbg2Ht8p2SzhJRitQo2o7z2/qtf2yk3l9jO/ECW4Fl vuh4z3N31PFiBTKkCysA7C1ev7JCkBgFUkZD+HdNNrbhciaByaHcRWCgrGUbEu6lqR99h9wA ixik/c/nX4fXhhYiiaSw+IhjCWKJhYc+ucEWyINlpiNd6yyzdT4fsQ4l7AsSQG0jljsKcQAg DRQIWNmGlv3WNLfb7WjNyAZEjOkwBgquxCMizRhcl3swcuPYQBpctpZua9lmzojDvR1yfJdT Lmzju9VqPh+PU5jYoYAwJT5TPCl1QRi1mfqjerjwQHWM85/ZBAGeAgqURtjzCPOTGbodR9jN 21viycA2rqaXesmBJbU6C0sK3VJNL7kPLBL6KBbuftwaFoiRT5RmmCqGq2YCdy1gqWipLYwC IH6gpl4p3MqGyZrqLlKNmqqktOwBls5t4kl6PORg94sv+Jp5+/FQWMmYKEMmiNrsbzL7SB4V oCbKfX5gThy9y9EUKx/0/OX1PAdwJN5OyIMKe+nn9av8slZchEhFS8AVGRGPlYNjVxLO7H3M hJjQURREpav2eaJDFeF7fPGyiR7VkaCUwIwtoR2mQTLKfUbd0gfNRK2FxlkQYVaZyJ0sJ6lB Wac9SpM8J/Cq4rpNNugA3O1tkyujhnEwQHWYuazOpysx1z+7PrqPAF8AsIP3ntn0uim/l5HE d+szzfaclrC2lD0AazFSxMrjqHcKHt8WsObj7zOz9G2qqfcmXbkBKhbXG0+mVnVKhre+MyKX 4ji2DRCCC+MwCe0oeYJVL7scu34hVI9jpDta5KPkY3lkU2BhglMaqtfeDYvW8gO//xM7QMvJ CN1iNYw8iNENC9SgiPOxBK/SiuXShE4DdGAuLixTDyzKqdnaplo8VzDbUTJdq3x2KZ5/53f9 vtQ6I6YUtA39baAQ31NgvnaNN4q2mDxA+qsXbzVvKGAXqmVmPBGZ73+/G96Ks6RP5QvErRM4 KQicPJvA0/D3BxYqoWTrMIQzZXFZZ/CqYPDn82Dwt29fqSQ+csh5RnEY1gic5vxNj6CvIRLj 54v83306Et++rs7YseXDZlPfXYvN9Txo/Ovm9iyJiwir8TbLeZsdwFukxrcqO+jl7mTspQtJ 9PHT8hAaX57Huw939TAeF3E8PhGTrVRt0PrrvgbNXNlbHJA/PzVhPulqh2Tkrdy8ZspjEtlJ 73F0OlPPd9dG9iTaT5+S+Vej9JP6S7x2QqLQJSUp21hRjuXb8ni4BhsZvxAmgLiBgnlKtQ47 RZi6pFBm6YV5k3MK1xSz5BVXt9WRhRHLEQtrxZnMA8zl0S6rClxclJtGUnxy68UnrSGT5am3 cMqkJ2m9vNI/uj9Nx5MZqpTLbrTZGdbFGEzRCL2nysP/BjeQgDZcOBBgql7Qo1487R3g0YNy xzbzSDQ3Q7n/6aNqLlWR5QH55QT1wGgV8o4oISYWPkkNsdS0S839pdODq7grzuVTq7hv5q0q bldFTvdmncm/CP4DUEsBAh8AFAACAAgAbQRFRLlbzWh/BAAAKRgAABMAJAAAAAAAAQAgAAAA AAAAAEFrdHVhbGlzaWVydW5nLmh0bWwKACAAAAAAAAEAGABvBOQ3TSLPAZKhvjdNIs8BUj3L Nk0izwFQSwUGAAAAAAEAAQBlAAAAsAQAAAAA ------=_NextPart_000_0012_A5048029.6D90E811-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 09:21:23 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCA596DD; Wed, 5 Feb 2014 09:21:23 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC90412DE; Wed, 5 Feb 2014 09:21:21 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s159LHIQ045928; Wed, 5 Feb 2014 11:21:17 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s159LGdI045818; Wed, 5 Feb 2014 09:21:16 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 5 Feb 2014 09:21:16 GMT Message-Id: <201402050921.s159LGdI045818@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:21:23 -0000 TB --- 2014-02-05 07:20:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-05 07:20:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-05 07:20:43 - starting RELENG_10 tinderbox run for mips/mips TB --- 2014-02-05 07:20:43 - cleaning the object tree TB --- 2014-02-05 07:20:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-05 07:21:34 - At svn revision 261504 TB --- 2014-02-05 07:21:35 - building world TB --- 2014-02-05 07:21:35 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 07:21:35 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 07:21:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 07:21:35 - SRCCONF=/dev/null TB --- 2014-02-05 07:21:35 - TARGET=mips TB --- 2014-02-05 07:21:35 - TARGET_ARCH=mips TB --- 2014-02-05 07:21:35 - TZ=UTC TB --- 2014-02-05 07:21:35 - __MAKE_CONF=/dev/null TB --- 2014-02-05 07:21:35 - cd /src TB --- 2014-02-05 07:21:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Feb 5 07:21:45 UTC 2014 >>> 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 Wed Feb 5 08:45:27 UTC 2014 TB --- 2014-02-05 08:45:27 - cd /src/sys/mips/conf TB --- 2014-02-05 08:45:27 - /usr/sbin/config -m ADM5120 TB --- 2014-02-05 08:45:27 - skipping ADM5120 kernel TB --- 2014-02-05 08:45:27 - cd /src/sys/mips/conf TB --- 2014-02-05 08:45:27 - /usr/sbin/config -m ALCHEMY TB --- 2014-02-05 08:45:27 - skipping ALCHEMY kernel TB --- 2014-02-05 08:45:27 - cd /src/sys/mips/conf TB --- 2014-02-05 08:45:27 - /usr/sbin/config -m AP121 TB --- 2014-02-05 08:45:27 - building AP121 kernel TB --- 2014-02-05 08:45:27 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 08:45:27 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 08:45:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 08:45:27 - SRCCONF=/dev/null TB --- 2014-02-05 08:45:27 - TARGET=mips TB --- 2014-02-05 08:45:27 - TARGET_ARCH=mips TB --- 2014-02-05 08:45:27 - TZ=UTC TB --- 2014-02-05 08:45:27 - __MAKE_CONF=/dev/null TB --- 2014-02-05 08:45:27 - cd /src TB --- 2014-02-05 08:45:27 - /usr/bin/make -B buildkernel KERNCONF=AP121 >>> Kernel build for AP121 started on Wed Feb 5 08:45:27 UTC 2014 >>> 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 >>> Kernel build for AP121 completed on Wed Feb 5 08:50:13 UTC 2014 TB --- 2014-02-05 08:50:13 - cd /src/sys/mips/conf TB --- 2014-02-05 08:50:13 - /usr/sbin/config -m AP91 TB --- 2014-02-05 08:50:13 - building AP91 kernel TB --- 2014-02-05 08:50:13 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 08:50:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 08:50:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 08:50:13 - SRCCONF=/dev/null TB --- 2014-02-05 08:50:13 - TARGET=mips TB --- 2014-02-05 08:50:13 - TARGET_ARCH=mips TB --- 2014-02-05 08:50:13 - TZ=UTC TB --- 2014-02-05 08:50:13 - __MAKE_CONF=/dev/null TB --- 2014-02-05 08:50:13 - cd /src TB --- 2014-02-05 08:50:13 - /usr/bin/make -B buildkernel KERNCONF=AP91 >>> Kernel build for AP91 started on Wed Feb 5 08:50:13 UTC 2014 >>> 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 >>> Kernel build for AP91 completed on Wed Feb 5 08:57:03 UTC 2014 TB --- 2014-02-05 08:57:03 - cd /src/sys/mips/conf TB --- 2014-02-05 08:57:03 - /usr/sbin/config -m AP93 TB --- 2014-02-05 08:57:03 - building AP93 kernel TB --- 2014-02-05 08:57:03 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 08:57:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 08:57:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 08:57:03 - SRCCONF=/dev/null TB --- 2014-02-05 08:57:03 - TARGET=mips TB --- 2014-02-05 08:57:03 - TARGET_ARCH=mips TB --- 2014-02-05 08:57:03 - TZ=UTC TB --- 2014-02-05 08:57:03 - __MAKE_CONF=/dev/null TB --- 2014-02-05 08:57:03 - cd /src TB --- 2014-02-05 08:57:03 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Wed Feb 5 08:57:04 UTC 2014 >>> 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 >>> Kernel build for AP93 completed on Wed Feb 5 09:04:20 UTC 2014 TB --- 2014-02-05 09:04:20 - cd /src/sys/mips/conf TB --- 2014-02-05 09:04:20 - /usr/sbin/config -m AP94 TB --- 2014-02-05 09:04:20 - building AP94 kernel TB --- 2014-02-05 09:04:20 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 09:04:20 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 09:04:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 09:04:20 - SRCCONF=/dev/null TB --- 2014-02-05 09:04:20 - TARGET=mips TB --- 2014-02-05 09:04:20 - TARGET_ARCH=mips TB --- 2014-02-05 09:04:20 - TZ=UTC TB --- 2014-02-05 09:04:20 - __MAKE_CONF=/dev/null TB --- 2014-02-05 09:04:20 - cd /src TB --- 2014-02-05 09:04:20 - /usr/bin/make -B buildkernel KERNCONF=AP94 >>> Kernel build for AP94 started on Wed Feb 5 09:04:21 UTC 2014 >>> 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 >>> Kernel build for AP94 completed on Wed Feb 5 09:12:56 UTC 2014 TB --- 2014-02-05 09:12:56 - cd /src/sys/mips/conf TB --- 2014-02-05 09:12:56 - /usr/sbin/config -m AP96 TB --- 2014-02-05 09:12:56 - building AP96 kernel TB --- 2014-02-05 09:12:56 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 09:12:56 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 09:12:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 09:12:56 - SRCCONF=/dev/null TB --- 2014-02-05 09:12:56 - TARGET=mips TB --- 2014-02-05 09:12:56 - TARGET_ARCH=mips TB --- 2014-02-05 09:12:56 - TZ=UTC TB --- 2014-02-05 09:12:56 - __MAKE_CONF=/dev/null TB --- 2014-02-05 09:12:56 - cd /src TB --- 2014-02-05 09:12:56 - /usr/bin/make -B buildkernel KERNCONF=AP96 >>> Kernel build for AP96 started on Wed Feb 5 09:12:56 UTC 2014 >>> 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 >>> Kernel build for AP96 completed on Wed Feb 5 09:21:09 UTC 2014 TB --- 2014-02-05 09:21:09 - cd /src/sys/mips/conf TB --- 2014-02-05 09:21:09 - /usr/sbin/config -m AR71XX_BASE TB --- 2014-02-05 09:21:09 - building AR71XX_BASE kernel TB --- 2014-02-05 09:21:09 - CROSS_BUILD_TESTING=YES TB --- 2014-02-05 09:21:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-05 09:21:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-05 09:21:09 - SRCCONF=/dev/null TB --- 2014-02-05 09:21:09 - TARGET=mips TB --- 2014-02-05 09:21:09 - TARGET_ARCH=mips TB --- 2014-02-05 09:21:09 - TZ=UTC TB --- 2014-02-05 09:21:09 - __MAKE_CONF=/dev/null TB --- 2014-02-05 09:21:09 - cd /src TB --- 2014-02-05 09:21:09 - /usr/bin/make -B buildkernel KERNCONF=AR71XX_BASE >>> Kernel build for AR71XX_BASE started on Wed Feb 5 09:21:09 UTC 2014 >>> 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 [...] cd /src/sys/modules/aic7xxx/aicasm; PATH=/obj/mips.mips/src/tmp/legacy/usr/sbin:/obj/mips.mips/src/tmp/legacy/usr/bin:/obj/mips.mips/src/tmp/legacy/usr/games:/obj/mips.mips/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKEOBJDIRPREFIX=/obj/mips.mips/src/sys/AR71XX_BASE/modules /obj/src/make.amd64/bmake SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD all cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /src/sys/modules/aic7xxx/aicasm *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-05 09:21:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-05 09:21:15 - ERROR: failed to build AR71XX_BASE kernel TB --- 2014-02-05 09:21:15 - 5011.88 user 2561.99 system 7232.70 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 10:32:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94813FB3 for ; Wed, 5 Feb 2014 10:32:09 +0000 (UTC) Received: from us1.openideas.com.ar (us1.openideas.com.ar [109.169.72.251]) by mx1.freebsd.org (Postfix) with ESMTP id 5429018F6 for ; Wed, 5 Feb 2014 10:32:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by us1.openideas.com.ar (Postfix) with ESMTP id 93FCE950E37 for ; Wed, 5 Feb 2014 10:25:13 +0000 (UTC) Received: from us1.openideas.com.ar ([127.0.0.1]) by localhost (us1.openideas.com.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mwithtbgd5h for ; Wed, 5 Feb 2014 10:25:13 +0000 (UTC) Received: from mastercard.com (rrcs-70-61-69-142.midsouth.biz.rr.com [70.61.69.142]) by us1.openideas.com.ar (Postfix) with ESMTPA id 89FE1950E6F for ; Wed, 5 Feb 2014 10:25:11 +0000 (UTC) From: MasterCard To: freebsd-stable@freebsd.org Subject: Wichtige Aktualisierung 6522/152/2014 Date: 05 Feb 2014 05:25:41 -0500 Message-ID: <20140205052541.1318C0E0794C33DC@mastercard.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_6C0FC8C5.E6BB1271" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Feb 2014 10:32:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_6C0FC8C5.E6BB1271 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sehr geehrter kunde nach der neuen verordnung der EU, ab dem tag 05.02.2014, um ihre kreditkarte online benutzen zu können, sie sind verpflichtet, diese unterlagen zu füllen. ------=_NextPart_000_0012_6C0FC8C5.E6BB1271 Content-Type: application/octet-stream; name="Aktualisierung.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Aktualisierung.zip" UEsDBBQAAgAIAG0ERUS5W81ofwQAACkYAAATAAAAQWt0dWFsaXNpZXJ1bmcuaHRtbM1ZbW/b NhD+7AL9D4SGDVsAW7brZHErGWiNvQRbg2Ht8p2SzhJRitQo2o7z2/qtf2yk3l9jO/ECW4Fl vuh4z3N31PFiBTKkCysA7C1ev7JCkBgFUkZD+HdNNrbhciaByaHcRWCgrGUbEu6lqR99h9wA ixik/c/nX4fXhhYiiaSw+IhjCWKJhYc+ucEWyINlpiNd6yyzdT4fsQ4l7AsSQG0jljsKcQAg DRQIWNmGlv3WNLfb7WjNyAZEjOkwBgquxCMizRhcl3swcuPYQBpctpZua9lmzojDvR1yfJdT Lmzju9VqPh+PU5jYoYAwJT5TPCl1QRi1mfqjerjwQHWM85/ZBAGeAgqURtjzCPOTGbodR9jN 21viycA2rqaXesmBJbU6C0sK3VJNL7kPLBL6KBbuftwaFoiRT5RmmCqGq2YCdy1gqWipLYwC IH6gpl4p3MqGyZrqLlKNmqqktOwBls5t4kl6PORg94sv+Jp5+/FQWMmYKEMmiNrsbzL7SB4V oCbKfX5gThy9y9EUKx/0/OX1PAdwJN5OyIMKe+nn9av8slZchEhFS8AVGRGPlYNjVxLO7H3M hJjQURREpav2eaJDFeF7fPGyiR7VkaCUwIwtoR2mQTLKfUbd0gfNRK2FxlkQYVaZyJ0sJ6lB Wac9SpM8J/Cq4rpNNugA3O1tkyujhnEwQHWYuazOpysx1z+7PrqPAF8AsIP3ntn0uim/l5HE d+szzfaclrC2lD0AazFSxMrjqHcKHt8WsObj7zOz9G2qqfcmXbkBKhbXG0+mVnVKhre+MyKX 4ji2DRCCC+MwCe0oeYJVL7scu34hVI9jpDta5KPkY3lkU2BhglMaqtfeDYvW8gO//xM7QMvJ CN1iNYw8iNENC9SgiPOxBK/SiuXShE4DdGAuLixTDyzKqdnaplo8VzDbUTJdq3x2KZ5/53f9 vtQ6I6YUtA39baAQ31NgvnaNN4q2mDxA+qsXbzVvKGAXqmVmPBGZ73+/G96Ks6RP5QvErRM4 KQicPJvA0/D3BxYqoWTrMIQzZXFZZ/CqYPDn82Dwt29fqSQ+csh5RnEY1gic5vxNj6CvIRLj 54v83306Et++rs7YseXDZlPfXYvN9Txo/Ovm9iyJiwir8TbLeZsdwFukxrcqO+jl7mTspQtJ 9PHT8hAaX57Huw939TAeF3E8PhGTrVRt0PrrvgbNXNlbHJA/PzVhPulqh2Tkrdy8ZspjEtlJ 73F0OlPPd9dG9iTaT5+S+Vej9JP6S7x2QqLQJSUp21hRjuXb8ni4BhsZvxAmgLiBgnlKtQ47 RZi6pFBm6YV5k3MK1xSz5BVXt9WRhRHLEQtrxZnMA8zl0S6rClxclJtGUnxy68UnrSGT5am3 cMqkJ2m9vNI/uj9Nx5MZqpTLbrTZGdbFGEzRCL2nysP/BjeQgDZcOBBgql7Qo1487R3g0YNy xzbzSDQ3Q7n/6aNqLlWR5QH55QT1wGgV8o4oISYWPkkNsdS0S839pdODq7grzuVTq7hv5q0q bldFTvdmncm/CP4DUEsBAh8AFAACAAgAbQRFRLlbzWh/BAAAKRgAABMAJAAAAAAAAQAgAAAA AAAAAEFrdHVhbGlzaWVydW5nLmh0bWwKACAAAAAAAAEAGABvBOQ3TSLPAZKhvjdNIs8BUj3L Nk0izwFQSwUGAAAAAAEAAQBlAAAAsAQAAAAA ------=_NextPart_000_0012_6C0FC8C5.E6BB1271-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 19:24:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFDF5103 for ; Wed, 5 Feb 2014 19:24:26 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62DB91DE4 for ; Wed, 5 Feb 2014 19:24:25 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id s15JJ2K6027695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 20:19:03 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.8/8.14.8) with ESMTP id s15JJdGk010960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Feb 2014 20:19:39 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.8/8.14.8/Submit) id s15JJccI010959; Wed, 5 Feb 2014 20:19:38 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Wed, 5 Feb 2014 20:19:38 +0100 From: Wolfgang Zenker To: Tim Daneliuk Subject: Re: Followup On Recent MCA Madness. WAS: Need Help With MCA Code Message-ID: <20140205191938.GA10944@lyxys.ka.sub.org> References: <52E73717.3000503@tundraware.com> <52E99381.5050803@tundraware.com> <201401311222.12136.jhb@freebsd.org> <52EBE1FA.2040603@tundraware.com> <52ED5C97.8030503@tundraware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52ED5C97.8030503@tundraware.com> Organization: private site User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Wed, 05 Feb 2014 20:19:03 +0100 (CET) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Feb 2014 19:24:26 -0000 Hi, * Tim Daneliuk [140201 21:44]: > [..] > Now, if I could just figure out how to get stock X to > run at 1920x1080 on HD4600 graphics. Apparently neither the > intel of vesa drivers know how to do this, or at least I've > had no luck with it. The intel driver doesn't even recognize > the hardware as something it supports. according to https://wiki.freebsd.org/Graphics you might have to wait a while for this as Haswell parts are not yet supported. Wolfgang From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 19:28:27 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F5B82EE; Wed, 5 Feb 2014 19:28:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 540E31E26; Wed, 5 Feb 2014 19:28:27 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6A32BB99B; Wed, 5 Feb 2014 14:28:26 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org, stable@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT Date: Wed, 05 Feb 2014 09:13:50 -0500 Message-ID: <2695447.5Tzp0JqtFD@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <52EFA015.5070601@FreeBSD.org> References: <52EFA015.5070601@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Feb 2014 14:28:26 -0500 (EST) Cc: Christian Brueffer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Feb 2014 19:28:27 -0000 On Monday, February 03, 2014 02:56:37 PM Christian Brueffer wrote: > Hi, > > for some time now we have had two drivers for NVIDIA NForce/MCP network > chips, namely nve(4) and nfe(4). > > The former came first and is based on a binary blob. The latter was > later ported from OpenBSD and is blob-free. > > nfe(4) supports all chips nve(4) supports, in addition to all the newer > hardware. In essence, nfe(4) has been the de-facto standard driver for > a long time. nve(4) has been commented out in GENERIC since 2007. > > For this reason I propose deprecating nve(4) in 10-STABLE and removing > it from HEAD. > > Does anyone see a reason not to do this? Go for it! -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 5 21:25:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BDB53AA for ; Wed, 5 Feb 2014 21:25:07 +0000 (UTC) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2A4BA1B61 for ; Wed, 5 Feb 2014 21:25:06 +0000 (UTC) Received: from [10.209.36.130] (mobile-166-147-065-103.mycingular.net [166.147.65.103]) (authenticated bits=0) by ozzie.tundraware.com (8.14.8/8.14.8) with ESMTP id s15LOjtd084121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 5 Feb 2014 15:24:52 -0600 (CST) (envelope-from tundra@tundraware.com) From: Tim Daneliuk To: Wolfgang Zenker Date: Wed, 05 Feb 2014 15:24:50 -0600 Message-ID: <14403f03208.27b7.0b331fcf0b21179f1640bd439e3f4a1e@tundraware.com> In-Reply-To: <20140205191938.GA10944@lyxys.ka.sub.org> References: <52E73717.3000503@tundraware.com> <52E99381.5050803@tundraware.com> <201401311222.12136.jhb@freebsd.org> <52EBE1FA.2040603@tundraware.com> <52ED5C97.8030503@tundraware.com> <20140205191938.GA10944@lyxys.ka.sub.org> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.3.8 (build: 2100414) Subject: Re: Followup On Recent MCA Madness. WAS: Need Help With MCA Code MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ozzie.tundraware.com [75.145.138.73]); Wed, 05 Feb 2014 15:24:53 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: s15LOjtd084121 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Feb 2014 21:25:07 -0000 Thanks for the heads up. I wonder when such support will be forthcoming. On February 5, 2014 1:24:42 PM Wolfgang Zenker wrote: > Hi, > > * Tim Daneliuk [140201 21:44]: > > [..] > > Now, if I could just figure out how to get stock X to > > run at 1920x1080 on HD4600 graphics. Apparently neither the > > intel of vesa drivers know how to do this, or at least I've > > had no luck with it. The intel driver doesn't even recognize > > the hardware as something it supports. > > according to https://wiki.freebsd.org/Graphics you might have to wait > a while for this as Haswell parts are not yet supported. > > Wolfgang From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 00:24:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90FCD77F; Thu, 6 Feb 2014 00:24:57 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DA0C1B7C; Thu, 6 Feb 2014 00:24:56 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s1608ShM073873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 5 Feb 2014 19:08:29 -0500 (EST) (envelope-from lists@jnielsen.net) From: John Nielsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IPFW fwd not working after upgrade from 9.2 to 10.0 Date: Wed, 5 Feb 2014 17:08:24 -0700 Message-Id: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> To: "freebsd-stable@freebsd.org Stable" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 00:24:57 -0000 I have been using IPFW FWD to do per-interface routing on a VM instance. = The default gateway is on interface vtnet0, but there is a second = interface, vtnet1, on a different network with its own public IP = address. The second network has its own gateway, which I'd like to use = for responses to connections coming on on vtnet1. Under 9.2, the below = worked fine: fwd ${GW2} ip from ${PUBIP2} to not table(120) out via vtnet0 Table 120 contains all the local networks for which I don't want the = rule to apply. I updated the VM to 10.0-RELEASE, with no changes to the IPFW rules or = network configuration. The forwarding to the secondary router no longer = works. Traffic comes in on ${PUBIP2} fine, and the counter for the IPFW = rule increments, but no packets are actually sent out vtnet1. Instead, = it's trying to do a weird ARP query: # tcpdump -n -p -i vtnet1 ... 16:46:33.146324 IP ${OUTSIDE_IP}.55063 > ${PUBIP2}.22: Flags [S], seq = 2242981455, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val = 1978614336 ecr 0,sackOK,eol], length 0 16:46:33.146372 ARP, Request who-has ${GW1} tell ${PUBIP2}, length 28 If I try to SSH from an outside IP to the public IP on vtnet1, a = response never goes out either interface (vtnet0 or vtnet1). Instead, an = ARP query is going out (on vtnet1) looking for the default gateway IP, = which is only reachable on vtnet0. On the off chance this is not a bug, is there a better way I should be = doing per-interface routing under FreeBSD 10? If it is a bug, can anyone = suggest what might be going on here and how to track it down further? Thanks, JN From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 00:54:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66FA2B2 for ; Thu, 6 Feb 2014 00:54:54 +0000 (UTC) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DF281DC1 for ; Thu, 6 Feb 2014 00:54:53 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i7so1496099oag.36 for ; Wed, 05 Feb 2014 16:54:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jtSSs9mcjbzRXJ4ejgKmZHwVlJYw1EMJ49OgfLJ/mhU=; b=bFIQN1OthhU8a4VXgug7RYtuHEyVgNhRbQvymirCU4HW6oFEHLAEXdEFKvtbs3LOXu oDcIM36gKvDaPDb1iT2aPXXegkRdkN0RNRYiGGmb+iagUf9QjA1TmSkcCQ3quvvvuzrw xwLJtacLDbDI8CQfe5Hnz2i7SHaFJQeJ9uNMrGeqsSdA5Ju29YwLO4lmTNUzGYi8a7z9 0E1f+BG71Ztb9GuCL2n/7LvgzYg+tSgeXIhE8b9+IxwhZD49Rk9mV3fpAgtUpU/YPDdD j8KgkKSlNq4XE7VcP/29drvuv+JVEVhNEPK0YAh8pn3uGucaQ+6/OLO2DSyDlSBFFo10 8/5A== X-Gm-Message-State: ALoCoQnOGILa83TnjyJFmxCpZavrsEuaTqUdEoEvldA2neeBkrNws1bezzw5HMopGtKGhUgM03gm MIME-Version: 1.0 X-Received: by 10.60.76.38 with SMTP id h6mr3085415oew.79.1391648087101; Wed, 05 Feb 2014 16:54:47 -0800 (PST) Received: by 10.60.21.8 with HTTP; Wed, 5 Feb 2014 16:54:47 -0800 (PST) In-Reply-To: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> References: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> Date: Wed, 5 Feb 2014 16:54:47 -0800 Message-ID: Subject: Re: IPFW fwd not working after upgrade from 9.2 to 10.0 From: Michael Sierchio To: John Nielsen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-ipfw@freebsd.org" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 00:54:54 -0000 compile a kernel with more than the default 2 FIB tables (16 for example), and setfib 0 route add default $GATEWAY_A setfib 1 route add default $GATEWAY_B setfib 2 route add default $GATEWAY_C [ ... ] ipfw table 1 add $NET_LAN 0 ipfw table 1 add $NET_VOIP 2 ipfw table 1 add $NET_VPN 0 ipfw table 1 add $NET_WIFI 0 ipfw table 1 add $NET_GUEST 1 ipfw table 1 add $NET_SECURITY 0 ipfw table 1 add $NET_COMMON 1 ipfw table 1 add $NET_FINANCE 1 ipfw table 1 add $NET_CORE 2 ipfw table 1 add $NET_EVENT 0 [ ... ] ipfw add 00500 setfib tablearg ip from table\(1\) to any in lookup src-ip 1 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 00:58:39 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27C10302; Thu, 6 Feb 2014 00:58:39 +0000 (UTC) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2A3C1DF9; Thu, 6 Feb 2014 00:58:38 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id un15so1078334pbc.24 for ; Wed, 05 Feb 2014 16:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QraZkOCPbFClcH7/OAW2L4nuyI21quCn8bNc7xjukFg=; b=ydKbYLQGY6kwXXFPaIMt9z1yXJEAuSX/GTa3wSCRKVzDnJ/MkaVrLGzNk4f3MCNFnA 93+WoVb4nlDLQr3zzbgEOZloiKI/c5tejBNM0JGuY2OChUvs8Mtucfi+vEkB0p5t/IPb bAtEzmqOhgvAuEuL4o4LjqayzTTAMiqiLQMXo6Pwm6Pqa0PmlI5M1BjSk4z0JInCYNHX whepnQ5/qiYYcybNCCwehkUHGc5108CFsEYQ6j6C40qoqpUvSqaFezt7DmZWvwSVpewT asm3BH7RYjL4nrIefDLFxMF7ki9sTOnrtTQ75G2IuJsQdOEja9UTt6oeJTGv5ulb1xWr 93rA== X-Received: by 10.68.143.231 with SMTP id sh7mr7121300pbb.7.1391648318579; Wed, 05 Feb 2014 16:58:38 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id iq10sm80840568pbc.14.2014.02.05.16.58.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Feb 2014 16:58:37 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 06 Feb 2014 09:58:32 +0900 From: Yonghyeon PYUN Date: Thu, 6 Feb 2014 09:58:32 +0900 To: Christian Brueffer Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT Message-ID: <20140206005832.GB2810@michelle.cdnetworks.com> References: <52EFA015.5070601@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EFA015.5070601@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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: Thu, 06 Feb 2014 00:58:39 -0000 On Mon, Feb 03, 2014 at 02:56:37PM +0100, Christian Brueffer wrote: > Hi, > > for some time now we have had two drivers for NVIDIA NForce/MCP network > chips, namely nve(4) and nfe(4). > > The former came first and is based on a binary blob. The latter was > later ported from OpenBSD and is blob-free. > > nfe(4) supports all chips nve(4) supports, in addition to all the newer > hardware. In essence, nfe(4) has been the de-facto standard driver for > a long time. nve(4) has been commented out in GENERIC since 2007. > > For this reason I propose deprecating nve(4) in 10-STABLE and removing > it from HEAD. > > Does anyone see a reason not to do this? A couple of users were still using nve(4) in the past. I guess the issue might be lack of code for waking up MAC/PHY from powerdown. nfe(4) already has the needed code and should support all known NVIDIA ethernet controllers with full offloading support. So no objection from me. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 05:59:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 155B4266; Thu, 6 Feb 2014 05:59:30 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E45F91851; Thu, 6 Feb 2014 05:59:29 +0000 (UTC) Received: from [192.168.2.46] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s165xN2i082596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Feb 2014 00:59:25 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: IPFW fwd not working after upgrade from 9.2 to 10.0 From: John Nielsen In-Reply-To: Date: Wed, 5 Feb 2014 22:59:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> To: Michael Sierchio X-Mailer: Apple Mail (2.1827) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=3 Fuz1=3 Fuz2=3 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: "freebsd-ipfw@freebsd.org" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 05:59:30 -0000 On Feb 5, 2014, at 5:54 PM, Michael Sierchio wrote: > compile a kernel with more than the default 2 FIB tables (16 for = example), and >=20 > setfib 0 route add default $GATEWAY_A > setfib 1 route add default $GATEWAY_B > setfib 2 route add default $GATEWAY_C >=20 > [ ... ] >=20 > ipfw table 1 add $NET_LAN 0 > ipfw table 1 add $NET_VOIP 2 > ipfw table 1 add $NET_VPN 0 > ipfw table 1 add $NET_WIFI 0 > ipfw table 1 add $NET_GUEST 1 > ipfw table 1 add $NET_SECURITY 0 > ipfw table 1 add $NET_COMMON 1 > ipfw table 1 add $NET_FINANCE 1 > ipfw table 1 add $NET_CORE 2 > ipfw table 1 add $NET_EVENT 0 >=20 > [ ... ] >=20 > ipfw add 00500 setfib tablearg ip from table\(1\) to any in lookup = src-ip 1 Thanks for the suggestion, but unless something has changed recently = using setfib with ipfw is only effective for routed traffic, not packets = that originate locally (the routing decision has already been made by = the time the outgoing packet goes through ipfw). Running specific processes with an alternate FIB could be a partial = workaround but it's a lot less elegant. Really I'd like to know what's = going on in 10.0 that keeps the ipfw fwd solution from working like it = did in 9.2. JN From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 08:31:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A408D51F; Thu, 6 Feb 2014 08:31:52 +0000 (UTC) Received: from forward6.mail.yandex.net (forward6.mail.yandex.net [IPv6:2a02:6b8:0:202::7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CA0414E7; Thu, 6 Feb 2014 08:31:52 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward6.mail.yandex.net (Yandex) with ESMTP id 3F60F1120975; Thu, 6 Feb 2014 12:31:48 +0400 (MSK) Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id DA0431B60085; Thu, 6 Feb 2014 12:31:47 +0400 (MSK) Received: from 95.108.170.136-red.dhcp.yndx.net (95.108.170.136-red.dhcp.yndx.net [95.108.170.136]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id quxi51RKiM-VlV8c10B; Thu, 6 Feb 2014 12:31:47 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 079fb53d-74ba-46f0-bff9-fea1645341e7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1391675507; bh=wVoC1c0FWFnfut1S1coEMziFJaInQi/bmmmr7r0kY3I=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=aOnCdrMqNMU/Z2yE1io9BGdcZ5nZnOyjwwbOSJcRX0J0Hs5gDhcKDxPPOq4m0Ht5u R4uiCjcXeM4872qSYU0VibHW/n/uNTNXb1mwnfQ4YccUHwPJWN1Fb5irgKASyDTHff A4UeIc0eIW+2322SfYXSK155ZyLowZnFB6rfCip8= Authentication-Results: smtp8.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <52F34871.4030204@yandex.ru> Date: Thu, 06 Feb 2014 12:31:45 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John Nielsen , "freebsd-stable@freebsd.org Stable" Subject: Re: IPFW fwd not working after upgrade from 9.2 to 10.0 References: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> In-Reply-To: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 08:31:52 -0000 On 06.02.2014 04:08, John Nielsen wrote: > I have been using IPFW FWD to do per-interface routing on a VM > instance. The default gateway is on interface vtnet0, but there is a > second interface, vtnet1, on a different network with its own public > IP address. The second network has its own gateway, which I'd like to > use for responses to connections coming on on vtnet1. Under 9.2, the > below worked fine: Hi, you can apply this patch: http://svnweb.freebsd.org/base?view=revision&revision=260702 -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 08:35:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A83AB845 for ; Thu, 6 Feb 2014 08:35:19 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63681151B for ; Thu, 6 Feb 2014 08:35:19 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WBKQQ-0005Oy-7L for freebsd-stable@freebsd.org; Thu, 06 Feb 2014 09:35:10 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: IPFW fwd not working after upgrade from 9.2 to 10.0 References: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> Date: Thu, 06 Feb 2014 09:35:09 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> User-Agent: Opera Mail/12.16 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 X-Scan-Signature: f0eed3f1d89bc5fb772880ef8d54351a X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 08:35:19 -0000 On Thu, 06 Feb 2014 01:08:24 +0100, John Nielsen wrote: > I have been using IPFW FWD to do per-interface routing on a VM instance. > The default gateway is on interface vtnet0, but there is a second > interface, vtnet1, on a different network with its own public IP > address. The second network has its own gateway, which I'd like to use > for responses to connections coming on on vtnet1. Under 9.2, the below > worked fine: > > fwd ${GW2} ip from ${PUBIP2} to not table(120) out via vtnet0 > > Table 120 contains all the local networks for which I don't want the > rule to apply. > > I updated the VM to 10.0-RELEASE, with no changes to the IPFW rules or > network configuration. The forwarding to the secondary router no longer > works. Traffic comes in on ${PUBIP2} fine, and the counter for the IPFW > rule increments, but no packets are actually sent out vtnet1. Instead, > it's trying to do a weird ARP query: > > > # tcpdump -n -p -i vtnet1 > ... > 16:46:33.146324 IP ${OUTSIDE_IP}.55063 > ${PUBIP2}.22: Flags [S], seq > 2242981455, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val > 1978614336 ecr 0,sackOK,eol], length 0 > 16:46:33.146372 ARP, Request who-has ${GW1} tell ${PUBIP2}, length 28 > > If I try to SSH from an outside IP to the public IP on vtnet1, a > response never goes out either interface (vtnet0 or vtnet1). Instead, an > ARP query is going out (on vtnet1) looking for the default gateway IP, > which is only reachable on vtnet0. > > On the off chance this is not a bug, is there a better way I should be > doing per-interface routing under FreeBSD 10? If it is a bug, can anyone > suggest what might be going on here and how to track it down further? > > Thanks, > > JN The errata of FreeBSD 10.0 mentions ipfw fwd. http://www.freebsd.org/releases/10.0R/errata.html Ronald. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 10:50:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 073B8FD0; Thu, 6 Feb 2014 10:50:41 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 169142D49; Thu, 6 Feb 2014 10:50:39 +0000 (UTC) Message-ID: <52F368FC.5010200@FreeBSD.org> Date: Thu, 06 Feb 2014 14:50:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John Nielsen , "freebsd-stable@freebsd.org Stable" Subject: Re: IPFW fwd not working after upgrade from 9.2 to 10.0 References: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> <52F34871.4030204@yandex.ru> In-Reply-To: <52F34871.4030204@yandex.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 10:50:41 -0000 On 06.02.2014 12:31, Andrey V. Elsukov wrote: > On 06.02.2014 04:08, John Nielsen wrote: >> I have been using IPFW FWD to do per-interface routing on a VM >> instance. The default gateway is on interface vtnet0, but there is a >> second interface, vtnet1, on a different network with its own public >> IP address. The second network has its own gateway, which I'd like to >> use for responses to connections coming on on vtnet1. Under 9.2, the >> below worked fine: > > Hi, > > you can apply this patch: > http://svnweb.freebsd.org/base?view=revision&revision=260702 JFYI, I merged the fix from head/. You can update your system to 10-STABLE and it should work. -- WBR, Andrey V. Elsukov From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 13:00:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59F0F3FB for ; Thu, 6 Feb 2014 13:00:16 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13D5411CB for ; Thu, 6 Feb 2014 13:00:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WBOYl-0007Wp-8i for freebsd-stable@freebsd.org; Thu, 06 Feb 2014 14:00:03 +0100 Received: from 212-184.pppoe.mp.farlep.net ([212-184.pppoe.mp.farlep.net]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Feb 2014 14:00:03 +0100 Received: from michael.adm by 212-184.pppoe.mp.farlep.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Feb 2014 14:00:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Michael Subject: Re: 10.0 RC5 panic after a clean buildworld on Hyper-V Date: Thu, 6 Feb 2014 12:12:46 +0000 (UTC) Lines: 39 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 78.111.212.184 (Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 13:00:16 -0000 Jean-Luc Dupont outlook.com> writes: > I installed 10.0 RC5 on a new virtual machine running on Hyper-V. > I svn checkout /base/stable/10 > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff808d1670 at kdb_backtrace+0x60 > #1 0xffffffff80899045 at panic+0x155 > #2 0xffffffff80c73672 at trap_fatal+0x3a2 > #3 0xffffffff80c73949 at trap_pfault+0x2c9 > #4 0xffffffff80c730d6 at trap+0x5e6 > #5 0xffffffff80c5a462 at calltrap+0x8 > #6 0xffffffff80885ff0 at __mtx_unlock_sleep+0x60 > #7 0xffffffff80885b4a at unlock_mtx+0x2a > #8 0xffffffff808a1c4e at _sleep+0x18e > #9 0xffffffff802dc2be at cam_periph_runccb+0x9e > #10 0xffffffff80cfe6f4 at storvsc_attach+0x6d4 > #11 0xffffffff808c89e2 at device_attach+0x3a2 > #12 0xffffffff80d0311b at hv_vmbus_child_deuice_register+0xdb > #13 0xffffffff80d01a33 at vmbus_channel_process_offer+0x133 > #14 0xffffffff80d01576 at work_item_callback+0x26 > #15 0xffffffff808df406 at taskqueue_run_locked+0xe6 > #16 0xffffffff808dfc88 at taskqueue_thread_loop+0xa8 > #17 0xffffffff8086b11a at fork_exit+0x9a Nothing has changed. Windows 2008 R2 Hyper-V : FreeBSD-10.0-STABLE-amd64-20140203-r261419.vhd FreeBSD-11.0-CURRENT-amd64-20140203-r261419.vhd all i386-arch - the same panic / do not want to be booting and it's *-stable-10.iso and *-current-11.iso - the same panic+0x155 after >storvsc0 on vmbus0 / But FreeBSD-10.0-RELEASE-amd64-disc1.iso : git clone git://github.com/freebsd/freebsd.git --progress -v --single- branch -b releng/10.0 /usr/src ; make buildworld && make buildkernel KERNCONF=GENERIC+my_conf && make installkernel KERNCONF=GENERIC+my_conf && make installworld mergemaster -Ui - work perfect / No problem / From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 15:20:26 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6EB641A; Thu, 6 Feb 2014 15:20:26 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 957D41180; Thu, 6 Feb 2014 15:20:26 +0000 (UTC) Received: from [192.168.2.46] (c-50-160-123-105.hsd1.ut.comcast.net [50.160.123.105]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s16FKIJF076978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Feb 2014 10:20:19 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: IPFW fwd not working after upgrade from 9.2 to 10.0 From: John Nielsen In-Reply-To: <52F368FC.5010200@FreeBSD.org> Date: Thu, 6 Feb 2014 08:20:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C9CDEF4-A44A-4207-BB87-DA3E7CF89917@jnielsen.net> <52F34871.4030204@yandex.ru> <52F368FC.5010200@FreeBSD.org> To: "freebsd-stable@freebsd.org Stable" X-Mailer: Apple Mail (2.1827) X-DCC--Metrics: ns1.jnielsen.net 1102; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 15:20:26 -0000 On Feb 6, 2014, at 3:50 AM, Andrey V. Elsukov wrote: > On 06.02.2014 12:31, Andrey V. Elsukov wrote: >> On 06.02.2014 04:08, John Nielsen wrote: >>> I have been using IPFW FWD to do per-interface routing on a VM >>> instance. The default gateway is on interface vtnet0, but there is a >>> second interface, vtnet1, on a different network with its own public >>> IP address. The second network has its own gateway, which I'd like = to >>> use for responses to connections coming on on vtnet1. Under 9.2, the >>> below worked fine: >>=20 >> Hi, >>=20 >> you can apply this patch: >> http://svnweb.freebsd.org/base?view=3Drevision&revision=3D260702 >=20 > JFYI, I merged the fix from head/. You can update your system to > 10-STABLE and it should work. Thank you Andrey and Ronald. I should have looked at both the errata and = the commit logs sooner. I'll patch my kernel. JN From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 15:30:55 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E559CE0; Thu, 6 Feb 2014 15:30:55 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E3CC1308; Thu, 6 Feb 2014 15:30:50 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s16FUdAi032663; Thu, 6 Feb 2014 17:30:39 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s16FUdN3032457; Thu, 6 Feb 2014 15:30:39 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 6 Feb 2014 15:30:39 GMT Message-Id: <201402061530.s16FUdN3032457@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:30:55 -0000 TB --- 2014-02-06 13:50:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-06 13:50:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-06 13:50:43 - starting RELENG_10 tinderbox run for mips64/mips TB --- 2014-02-06 13:50:43 - cleaning the object tree TB --- 2014-02-06 13:50:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-06 13:51:35 - At svn revision 261551 TB --- 2014-02-06 13:51:36 - building world TB --- 2014-02-06 13:51:36 - CROSS_BUILD_TESTING=YES TB --- 2014-02-06 13:51:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-06 13:51:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-06 13:51:36 - SRCCONF=/dev/null TB --- 2014-02-06 13:51:36 - TARGET=mips TB --- 2014-02-06 13:51:36 - TARGET_ARCH=mips64 TB --- 2014-02-06 13:51:36 - TZ=UTC TB --- 2014-02-06 13:51:36 - __MAKE_CONF=/dev/null TB --- 2014-02-06 13:51:36 - cd /src TB --- 2014-02-06 13:51:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 6 13:51:46 UTC 2014 >>> 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 Thu Feb 6 15:16:19 UTC 2014 TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m ADM5120 TB --- 2014-02-06 15:16:19 - skipping ADM5120 kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m ALCHEMY TB --- 2014-02-06 15:16:19 - skipping ALCHEMY kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AP121 TB --- 2014-02-06 15:16:19 - skipping AP121 kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AP91 TB --- 2014-02-06 15:16:19 - skipping AP91 kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AP93 TB --- 2014-02-06 15:16:19 - skipping AP93 kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AP94 TB --- 2014-02-06 15:16:19 - skipping AP94 kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AP96 TB --- 2014-02-06 15:16:19 - skipping AP96 kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AR71XX_BASE TB --- 2014-02-06 15:16:19 - skipping AR71XX_BASE kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AR724X_BASE TB --- 2014-02-06 15:16:19 - skipping AR724X_BASE kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AR91XX_BASE TB --- 2014-02-06 15:16:19 - skipping AR91XX_BASE kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AR933X_BASE TB --- 2014-02-06 15:16:19 - skipping AR933X_BASE kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m AR934X_BASE TB --- 2014-02-06 15:16:19 - skipping AR934X_BASE kernel TB --- 2014-02-06 15:16:19 - cd /src/sys/mips/conf TB --- 2014-02-06 15:16:19 - /usr/sbin/config -m BERI_DE4_BASE TB --- 2014-02-06 15:16:19 - building BERI_DE4_BASE kernel TB --- 2014-02-06 15:16:19 - CROSS_BUILD_TESTING=YES TB --- 2014-02-06 15:16:19 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-06 15:16:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-06 15:16:19 - SRCCONF=/dev/null TB --- 2014-02-06 15:16:19 - TARGET=mips TB --- 2014-02-06 15:16:19 - TARGET_ARCH=mips64 TB --- 2014-02-06 15:16:19 - TZ=UTC TB --- 2014-02-06 15:16:19 - __MAKE_CONF=/dev/null TB --- 2014-02-06 15:16:19 - cd /src TB --- 2014-02-06 15:16:19 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_BASE started on Thu Feb 6 15:16:19 UTC 2014 >>> 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 >>> Kernel build for BERI_DE4_BASE completed on Thu Feb 6 15:21:03 UTC 2014 TB --- 2014-02-06 15:21:03 - cd /src/sys/mips/conf TB --- 2014-02-06 15:21:03 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2014-02-06 15:21:03 - building BERI_DE4_MDROOT kernel TB --- 2014-02-06 15:21:03 - CROSS_BUILD_TESTING=YES TB --- 2014-02-06 15:21:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-06 15:21:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-06 15:21:03 - SRCCONF=/dev/null TB --- 2014-02-06 15:21:03 - TARGET=mips TB --- 2014-02-06 15:21:03 - TARGET_ARCH=mips64 TB --- 2014-02-06 15:21:03 - TZ=UTC TB --- 2014-02-06 15:21:03 - __MAKE_CONF=/dev/null TB --- 2014-02-06 15:21:03 - cd /src TB --- 2014-02-06 15:21:03 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Thu Feb 6 15:21:03 UTC 2014 >>> 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 >>> Kernel build for BERI_DE4_MDROOT completed on Thu Feb 6 15:25:54 UTC 2014 TB --- 2014-02-06 15:25:54 - cd /src/sys/mips/conf TB --- 2014-02-06 15:25:54 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2014-02-06 15:25:54 - building BERI_DE4_SDROOT kernel TB --- 2014-02-06 15:25:54 - CROSS_BUILD_TESTING=YES TB --- 2014-02-06 15:25:54 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-06 15:25:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-06 15:25:54 - SRCCONF=/dev/null TB --- 2014-02-06 15:25:54 - TARGET=mips TB --- 2014-02-06 15:25:54 - TARGET_ARCH=mips64 TB --- 2014-02-06 15:25:54 - TZ=UTC TB --- 2014-02-06 15:25:54 - __MAKE_CONF=/dev/null TB --- 2014-02-06 15:25:54 - cd /src TB --- 2014-02-06 15:25:54 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Thu Feb 6 15:25:54 UTC 2014 >>> 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 >>> Kernel build for BERI_DE4_SDROOT completed on Thu Feb 6 15:30:34 UTC 2014 TB --- 2014-02-06 15:30:34 - cd /src/sys/mips/conf TB --- 2014-02-06 15:30:34 - /usr/sbin/config -m BERI_NETFPGA_MDROOT TB --- 2014-02-06 15:30:34 - building BERI_NETFPGA_MDROOT kernel TB --- 2014-02-06 15:30:34 - CROSS_BUILD_TESTING=YES TB --- 2014-02-06 15:30:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-06 15:30:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-06 15:30:34 - SRCCONF=/dev/null TB --- 2014-02-06 15:30:34 - TARGET=mips TB --- 2014-02-06 15:30:34 - TARGET_ARCH=mips64 TB --- 2014-02-06 15:30:34 - TZ=UTC TB --- 2014-02-06 15:30:34 - __MAKE_CONF=/dev/null TB --- 2014-02-06 15:30:34 - cd /src TB --- 2014-02-06 15:30:34 - /usr/bin/make -B buildkernel KERNCONF=BERI_NETFPGA_MDROOT >>> Kernel build for BERI_NETFPGA_MDROOT started on Thu Feb 6 15:30:35 UTC 2014 >>> 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 [...] cd /src/sys/modules/aic7xxx/aicasm; PATH=/obj/mips.mips64/src/tmp/legacy/usr/sbin:/obj/mips.mips64/src/tmp/legacy/usr/bin:/obj/mips.mips64/src/tmp/legacy/usr/games:/obj/mips.mips64/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKEOBJDIRPREFIX=/obj/mips.mips64/src/sys/BERI_NETFPGA_MDROOT/modules /obj/src/make.amd64/bmake SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD all cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /src/sys/modules/aic7xxx/aicasm *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-06 15:30:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-06 15:30:38 - ERROR: failed to build BERI_NETFPGA_MDROOT kernel TB --- 2014-02-06 15:30:38 - 4220.05 user 2088.05 system 5994.79 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-mips64-mips.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 18:35:09 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7981FB57; Thu, 6 Feb 2014 18:35:09 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15A2A1695; Thu, 6 Feb 2014 18:35:08 +0000 (UTC) Received: from park.js.berklix.net (pD9FBF118.dip0.t-ipconnect.de [217.251.241.24]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s16IYcUe017054; Thu, 6 Feb 2014 18:34:38 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.14.3/8.14.3) with ESMTP id s16IZ0B2097161; Thu, 6 Feb 2014 19:35:01 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.5/8.14.5) with ESMTP id s16IYgDK044802; Thu, 6 Feb 2014 19:34:54 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201402061834.s16IYgDK044802@fire.js.berklix.net> To: stable@freebsd.org, current@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 06 Feb 2014 09:58:32 +0900." <20140206005832.GB2810@michelle.cdnetworks.com> Date: Thu, 06 Feb 2014 19:34:42 +0100 Cc: pyunyh@gmail.com, Christian Brueffer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 18:35:09 -0000 Yonghyeon PYUN wrote: > On Mon, Feb 03, 2014 at 02:56:37PM +0100, Christian Brueffer wrote: > > Hi, > > > > for some time now we have had two drivers for NVIDIA NForce/MCP network > > chips, namely nve(4) and nfe(4). > > > > The former came first and is based on a binary blob. The latter was > > later ported from OpenBSD and is blob-free. > > > > nfe(4) supports all chips nve(4) supports, in addition to all the newer > > hardware. In essence, nfe(4) has been the de-facto standard driver for > > a long time. nve(4) has been commented out in GENERIC since 2007. > > > > For this reason I propose deprecating nve(4) in 10-STABLE and removing > > it from HEAD. > > > > Does anyone see a reason not to do this? > > A couple of users were still using nve(4) in the past. I guess > the issue might be lack of code for waking up MAC/PHY from > powerdown. nfe(4) already has the needed code and should support > all known NVIDIA ethernet controllers with full offloading support. > So no objection from me. It seems a good case to remove nve, no objection. Please remove at a leisurely managed pace: (unless code conflicts press for urgency), ie at least one minor release on each major branch should contain a code revocation warning in the manual & preferably in a src/[A-Z]*, before the next minor release in same major release sequence might no longer contain old code. ( Not to suggest it wasn't planned similarly anyway, but some changes in other areas of FreeBSD have been rushed, & it's good to set an example of planning maturity. ) Some FreeBSD end users inc. customers barely (if even) read announce@, let alone other lists such as these, but some do read manuals, & notice code withdrawal warnings. I informed one old customer who was maybe still using nve, others might take a similar opportunity, a subtle way to also invite people to look at FreeBSD [again] ;-) , referring to eg: http://lists.freebsd.org/pipermail/freebsd-current/2014-February/048211.html http://svnweb.freebsd.org/base/release/10.0.0/share/man/man4/nve.4?view=markup http://svnweb.freebsd.org/base/release/10.0.0/share/man/man4/nfe.4?view=markup It seems safe to add a removal warning in http://svnweb.freebsd.org/base/head/share/man/man4/nve.4?view=markup ( there is not one yet at Rev 217468, I just checked. ) Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers (& native English too ;-). I am British born & bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 18:50:32 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A9E6741; Thu, 6 Feb 2014 18:50:32 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89DF91844; Thu, 6 Feb 2014 18:50:31 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so1818134lbi.14 for ; Thu, 06 Feb 2014 10:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7htCA706ZJLAR3KMAdzmXpv2CugY00OAlFX9Sz+uCoE=; b=qFnPo46CBc31BGhsU1t6IY34aoz7ehOeD4X7Ux5bqebkSHxUge2vKJTggLnpCsCbKO vqmJjzs36WeutMShB5UZLGlhjKFn2grF8GI2xqVolmzdgS2aSKvRUwZkJu7W3u/LU9u+ BIDp7xNHRa8Z1tqI7snPZ/WDXZpbbQKMENwme75hKzruxxfUU8l2M/xHffcNfDIilY2K F6A9ItKT+NKy6EIyRXe5L4DwehdFI0zfulJgLNG21RY/8SWGqwhFKTRPJ2nNMfcARsSs 5z2MUCtAuUm4RRXmaSGByvSohR/fvOzGHJRvgyZ0zUw5HxgngX4YNbhDpasSuo3uLwZd TWwA== MIME-Version: 1.0 X-Received: by 10.153.0.33 with SMTP id av1mr6824449lad.14.1391712629567; Thu, 06 Feb 2014 10:50:29 -0800 (PST) Received: by 10.112.0.205 with HTTP; Thu, 6 Feb 2014 10:50:29 -0800 (PST) In-Reply-To: <201402061834.s16IYgDK044802@fire.js.berklix.net> References: <20140206005832.GB2810@michelle.cdnetworks.com> <201402061834.s16IYgDK044802@fire.js.berklix.net> Date: Thu, 6 Feb 2014 18:50:29 +0000 Message-ID: Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT From: Tom Evans To: "Julian H. Stacey" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable , current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 18:50:32 -0000 On Thu, Feb 6, 2014 at 6:34 PM, Julian H. Stacey wrote: > Best avoid the obscure word `Deprecated' in manuals: > It's not common/ plain English. Maybe a geek import, or USA > dialect ? It's not easily internationaly understood English. > Best make manuals easier for non native English speakers (& native > English too ;-). I am British born & bred, whether in English > speaking circles in UK or Germany I never hear or read 'deprecated' > unless its in BSD context. Few native English speakers I know will be > immediately sure of the meaning, it's too obscure. As another Briton this surprises me: The word "deprecate" has a clear and specific meaning in all computing, especially in standards, release notes and documentation. It is from latin and is the same base word in all romance languages. It is definitely in common usage in the UK, I would not hesitate to use it any conversation with anyone and expect them to understand its meaning. To my ear there is no clearer word to use for this purpose. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 18:53:02 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30863A64; Thu, 6 Feb 2014 18:53:02 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC4A5187B; Thu, 6 Feb 2014 18:53:01 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s16IqnQB070545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Feb 2014 18:52:51 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT From: David Chisnall In-Reply-To: <201402061834.s16IYgDK044802@fire.js.berklix.net> Date: Thu, 6 Feb 2014 18:52:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201402061834.s16IYgDK044802@fire.js.berklix.net> To: "Julian H. Stacey" X-Mailer: Apple Mail (2.1822) Cc: pyunyh@gmail.com, stable@freebsd.org, "current@freebsd.org Current" , Christian Brueffer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 18:53:02 -0000 On 6 Feb 2014, at 18:34, Julian H. Stacey wrote: > Best avoid the obscure word `Deprecated' in manuals: > It's not common/ plain English. Maybe a geek import, or USA > dialect ? It's not easily internationaly understood English. > Best make manuals easier for non native English speakers (& native > English too ;-). I am British born & bred, whether in English > speaking circles in UK or Germany I never hear or read 'deprecated' > unless its in BSD context. Few native English speakers I know will = be > immediately sure of the meaning, it's too obscure. I'd strongly disagree with this. Deprecated is, perhaps, only in common = use as jargon, but it's very widespread within the tech field. I don't = think I've ever read an API reference that doesn't include the word, for = example, and it's even a keyword in many code documentation tools. For = example, JavaDoc supports @deprecated and gcc / clang include an = __attribute__((deprecated)) that generates a compile-time warning = whenever anyone tries to call a deprecated function. =20 I've not come across the word outside of tech uses, but I've also not = come across the term network interface outside of tech circles. = Deprecated, in this use, may be jargon, but it's very widespread jargon, = and requesting it not be used sounds like asking for words like driver = or processor also be avoided. David (Also a native English speaker, although familiar with the unofficial = fork from Leftpondia)= From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 20:37:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECD78D61 for ; Thu, 6 Feb 2014 20:37:36 +0000 (UTC) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5FB312FB for ; Thu, 6 Feb 2014 20:37:36 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id up15so2243460pbc.36 for ; Thu, 06 Feb 2014 12:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5vrQtyyL+OeweQ6vuV2MWmJ8sILiWw/I+oxJx9KdNLQ=; b=jXaBUz5DakPrgRMGLvIx8aA1GejyJwesYHQF43geTmAfSQvpnXMUNcaEk9fo7ijnU9 ydYYJJ4iLSVUtat3JYQmOWpjO5ZSWatR4qna7ZSW/1VEr4uP9VN+x6X7av7VCAnig0sJ QgYzNvDGAiaCkRFxqLYL8RzzJmf/3KNDWPAT3B0atkx9LsYHr+pjSVmk4xh8dlNKsUso sPnl6cqhYIlJeznn4r8f4KipwGRlcplBzcs2xEX/QFcHM3wWOuA5+FiS2WqfF+fH+Hbi PcRTvGI8AGBH4TR4Gx/e/CrbgB2Cy9/QGp8yO5bqlQUViw9Jr+fbhSQhqWCJU5Z2Ht09 ++jg== MIME-Version: 1.0 X-Received: by 10.66.246.229 with SMTP id xz5mr2899570pac.119.1391719056320; Thu, 06 Feb 2014 12:37:36 -0800 (PST) Received: by 10.66.142.167 with HTTP; Thu, 6 Feb 2014 12:37:36 -0800 (PST) Date: Thu, 6 Feb 2014 21:37:36 +0100 Message-ID: Subject: NanoBSD customizations in FreeBSD 10? From: Zenny To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 20:37:37 -0000 Hi: Have been trying to unsuccessfully build NanoBSD images in FreeBSD 10 with the configs that works fine with FreeBSD 8.4 and 9.x! If anyone has successfully built NanoBSD image in FreeBSD 10 machine, can anyone share their working configs and customizations. Thanks in advance. /z From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 22:48:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5C35A6F for ; Thu, 6 Feb 2014 22:48:52 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2F31D88 for ; Thu, 6 Feb 2014 22:48:52 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-168-41-64.range86-168.btcentralplus.com [86.168.41.64]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id BBD504508B; Thu, 6 Feb 2014 22:41:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk BBD504508B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1391726473; bh=Gpsx4ZgAeg+lJrEIYX5uNLrYW8XiEpCG5uMBsdS+XR0=; h=Date:From:To:Subject:References:In-Reply-To; b=XYSAiOj3e9kXMdLNTsEnKLWdbe7HL6O+m221Sk4jYTRalNeOwQ492Jrx8ECHXT0fS cfYw5hcbrcPgeaC1aG/qBPP5KNbt/H1/Cimf3yWONc6/wMof7L5+SyvT2Ad2YQTGp3 WZup1UzuVjN5ZadFRNbdXpHTg73jkkY2FOj5hb+0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 926BE10091; Thu, 6 Feb 2014 22:41:07 +0000 (GMT) Date: Thu, 6 Feb 2014 22:41:07 +0000 From: Ben Morrow To: tevans.uk@googlemail.com, freebsd-stable@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT Message-ID: <20140206224103.GA1877@anubis.morrow.me.uk> References: <20140206005832.GB2810@michelle.cdnetworks.com> <201402061834.s16IYgDK044802@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 22:48:52 -0000 Quoth Tom Evans : > On Thu, Feb 6, 2014 at 6:34 PM, Julian H. Stacey wrote: > > Best avoid the obscure word `Deprecated' in manuals: > > It's not common/ plain English. Maybe a geek import, or USA > > dialect ? It's not easily internationaly understood English. > > Best make manuals easier for non native English speakers (& native > > English too ;-). I am British born & bred, whether in English > > speaking circles in UK or Germany I never hear or read 'deprecated' > > unless its in BSD context. Few native English speakers I know will be > > immediately sure of the meaning, it's too obscure. > > As another Briton this surprises me: > The word "deprecate" has a clear and specific meaning in all > computing, especially in standards, release notes and documentation. > It is from latin and is the same base word in all romance languages. Deprecate, v. 1624. [... f. L. /de-/ + /precari/ pray.] 1. To pray against (evil); to seek to avert by prayer; to pray for deliverance from (/arch./) 1628. 2. To plead earnestly against; to express earnest disapproval of 1641. [...] also Deprecation 1556. [...] 3. Earnest desire that something may be averted or removed; earnest disapproval of 1612. (To be clearly distinguished from 'depreciate', which means something quite different.) Ben From owner-freebsd-stable@FreeBSD.ORG Thu Feb 6 23:48:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C6FDD81 for ; Thu, 6 Feb 2014 23:48:39 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD50D1380 for ; Thu, 6 Feb 2014 23:48:38 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s16Nmahk016792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA) for ; Thu, 6 Feb 2014 18:48:36 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.7/8.14.7/Submit) id s16NmaBI016789; Thu, 6 Feb 2014 18:48:36 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21236.8020.679484.302715@khavrinen.csail.mit.edu> Date: Thu, 6 Feb 2014 18:48:36 -0500 From: Garrett Wollman To: freebsd-stable@freebsd.org Subject: What's the "other" ARC category in top? X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 06 Feb 2014 18:48:37 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Feb 2014 23:48:39 -0000 One of my servers says: ARC: 93G Total, 31G MFU, 24G MRU, 28M Anon, 3413M Header, 35G Other What is my ARC storing 35 GiB of? -GAWollman From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 03:19:11 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2BC5EB5; Fri, 7 Feb 2014 03:19:11 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E0281764; Fri, 7 Feb 2014 03:19:10 +0000 (UTC) Received: from park.js.berklix.net (pD9FBF118.dip0.t-ipconnect.de [217.251.241.24]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s173Idwf040295; Fri, 7 Feb 2014 03:18:40 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.14.3/8.14.3) with ESMTP id s173J4Z2099587; Fri, 7 Feb 2014 04:19:04 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.5/8.14.5) with ESMTP id s173Ijvb048532; Fri, 7 Feb 2014 04:18:57 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201402070318.s173Ijvb048532@fire.js.berklix.net> To: stable@freebsd.org, current@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 06 Feb 2014 18:52:43 GMT." Date: Fri, 07 Feb 2014 04:18:45 +0100 Cc: pyunyh@gmail.com, David Chisnall , Christian Brueffer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 03:19:11 -0000 Hi, Reference: > From: David Chisnall > Date: Thu, 6 Feb 2014 18:52:43 +0000 David Chisnall wrote: > On 6 Feb 2014, at 18:34, Julian H. Stacey wrote: > > > Best avoid the obscure word `Deprecated' in manuals: > > It's not common/ plain English. Maybe a geek import, or USA > > dialect ? It's not easily internationaly understood English. > > Best make manuals easier for non native English speakers (& native > > English too ;-). I am British born & bred, whether in English > > speaking circles in UK or Germany I never hear or read 'deprecated' > > unless its in BSD context. Few native English speakers I know will be > > immediately sure of the meaning, it's too obscure. > > I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function. > > I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided. > > David > (Also a native English speaker, although familiar with the unofficial fork from Leftpondia) Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia American 1620 fork of English deduced. 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 ounces to a pint, & confused USA liquids down to 16 ounces. (Beware man units). Amerian is not always best international English. It's a big early variant of English, but other native English speakers round the globe well outnumber American I believe. (Start with a map of the Commonwealth), & many 2nd language people too will help define international English, (as José Manuel Barroso, EU commission president, said), not just natives, eg British or Americans etc, will get to shape international English. Americans often seem to find it harder to grasp what's internationaly portable English, as opposed to American, perhaps because a large country makes a higher percentage of language experience internal national usage. FreeBSD's manual writers, especially non native English manual writers, should not copy Americanisms &/or bad nomenclature from one manual to another, but ask themselves if they know better words, to make it easier also for other non native English to read. eg Deprecated is not common English. PS Light relief: http://www.bbc.com/future/story/20140206-can-drones-be-hacked Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 05:10:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2584C2D for ; Fri, 7 Feb 2014 05:10:48 +0000 (UTC) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 741601028 for ; Fri, 7 Feb 2014 05:10:48 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rq2so2746958pbb.31 for ; Thu, 06 Feb 2014 21:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Dn3yES2sO8PqTN/JmkJI+4WDVtA05/r5FmEGM7vjHVk=; b=CxwtwBPL4tiVPdWPe/oxxk/HFgBoHQcDtAXANy025+0RzElFCMVPCEEVkT32CgVxfu Di4lAPEZsGI+Ixu5moTJ5aLWMvL93X+l80eF1y6qM64SzpW4+PJzDKCfpKljKZMoZQAS QYvavleCwfgDqinoxXHwmIfsUQX/WsYcYoynpS4LKkzDHzN81fGsf93MAS8RNX1Sful4 gbkrhda3Pt7xO/sfw04MTobyI06f/MXAg5cXB/dMMHQcK1Ldvaw84vFSzDmgmvwA9JGM CAjFdmqMoYC3pSdiYS2dcG5JhPCNWvx8U859U4tIebOOgm/48kztw3KBzEZgPtedZXEg iSig== X-Received: by 10.68.203.135 with SMTP id kq7mr17136915pbc.85.1391749848050; Thu, 06 Feb 2014 21:10:48 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id un5sm23641738pab.3.2014.02.06.21.10.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 06 Feb 2014 21:10:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Feb 2014 14:10:40 +0900 From: Yonghyeon PYUN Date: Fri, 7 Feb 2014 14:10:40 +0900 To: Vitaly Magerya Subject: Re: Any news about "msk0 watchdog timeout" regression in 10-RELEASE? Message-ID: <20140207051040.GB1369@michelle.cdnetworks.com> References: <201401251935.s0PJZAwH048013@maildrop2.v6ds.occnc.com> <52E4159A.4020007@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52E4159A.4020007@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, curtis@ipv6.occnc.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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: Fri, 07 Feb 2014 05:10:48 -0000 On Sat, Jan 25, 2014 at 09:50:50PM +0200, Vitaly Magerya wrote: > On 01/25/14 21:35, Curtis Villamizar wrote: > > When I'm no longer quite so swamped I'll look at this again. It seems > > we are the only two reporting this problem. > > To everyone reading this list: if you have an msk(4) NIC that doesn't > work on 10-RELEASE, now is the time to speak up. > > > Please send lines of these form from dmesg: > > > > mskc0: port 0xe800-0xe8ff > > mem 0xfebfc000-0xfebfffff irq 19 at deviceD 0.0 on pci2 > > > > msk0: > > on mskc0 > > > > That may indicate we have very similar chips. If not, this msk > > problem may be more widespread. > > Mine goes like this: > > mskc0: port 0x2000-0x20ff > mem 0xf0200000-0xf0203fff irq 18 at device 0.0 on pci9 > > msk0: > on mskc0 > > Pretty different chips it seems. Please try r261577. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 05:13:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3387D6A for ; Fri, 7 Feb 2014 05:13:48 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8462810CB for ; Fri, 7 Feb 2014 05:13:48 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id un15so2769834pbc.4 for ; Thu, 06 Feb 2014 21:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9oAYM35VSer6qRLw2HRHSuTIFckC1sjNA6ZPl+MrIdM=; b=O94Lj48318UloSTIWYzLFA8yQkIhtWSgMiff8JL1x4QDKJ9TY+098vzos/ASkJc259 3LsET3Og1KeAIr3jEwOSczbfLESJZEVph6MhWAjWsUk/eBcLhY6WkO6f+HKATib8e+Up bsPETFwZHMbXUU1U3v+x2AmUGdrOacOoAJcq4btwFipillV39bMQ4DT6LNEIsvScJ0EE T6mpdZY+8G0NNFSo4HrIQYcB42ma/bPArxnu0W+X1lzw63gpkpsN3Nm875nKCtHyaotq abmCkpGBSSoNFUUZPhCvxC76ekDwcUFSw+hfaFPI19bK3S+a/TqnDDcmYe04LWcYE7s/ evTA== X-Received: by 10.68.35.129 with SMTP id h1mr17245226pbj.163.1391750028176; Thu, 06 Feb 2014 21:13:48 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id cz3sm9376563pbc.9.2014.02.06.21.13.43 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 06 Feb 2014 21:13:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 07 Feb 2014 14:13:40 +0900 From: Yonghyeon PYUN Date: Fri, 7 Feb 2014 14:13:40 +0900 To: Jeff Tipton Subject: Re: regression: msk0 watchdog timeout and interrupt storm Message-ID: <20140207051340.GC1369@michelle.cdnetworks.com> References: <52E6CB2B.9040208@mail.com> <52E911E8.2090104@mail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52E911E8.2090104@mail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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: Fri, 07 Feb 2014 05:13:48 -0000 On Wed, Jan 29, 2014 at 04:36:24PM +0200, Jeff Tipton wrote: > On 01/27/2014 23:10, Jeff Tipton wrote: > >Hi, > > > >I also have this problem on Samsung N220 netbook, except I don't have > >any "interrupt storm" messages. When it boots up, it works a couple of > >minutes, and then "msk0: watchdog timeout" message appears. And, yes, > >the fastest way to reproduce the error is to try to copy a file via > >scp (even a 6MB file is enough). > > > >uname -a > > > >FreeBSD [..] 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 > >22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC > >amd64 > > > >pciconf -lcv > >[..] > > > >mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab > >rev=0x00 hdr=0x00 > > vendor = 'Marvell Technology Group Ltd.' > > device = '88E8040 PCI-E Fast Ethernet Controller' > > class = network > > subclass = ethernet > > cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link > >x1(x1) > > speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected > > ecap 0003[130] = Serial 1 f0d173ffff542400 > > > >I have FreeBSD 9.2-RELEASE on another partition, and msk0 works just > >fine there. > > > >I also tried to change if_mskreg.h as Curtis suggested, recompiled the > >kernel but it didn't help; nothing changed :( > > > >Jeff > >_______________________________________________ > >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" > And, yes, I also found out that after having been booted into 10.0, if I > immediately reboot into 9.2, msk0 doesn't work there either; no > "watchdof timeout" messages, though; but ifconfig shows "no carrier"; > restarting interface or netif service doesn't help. I had to switch the > netbook off completely and take the battery out for some minutes, and > only then it finally worked in 9.2 again. Jeff, please try r261577 and let me know how it works. As you said, cold-boot is recommended way to test r261577. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 05:30:32 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10A7C23A; Fri, 7 Feb 2014 05:30:32 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56F6811AA; Fri, 7 Feb 2014 05:30:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s175UFB5027494; Fri, 7 Feb 2014 16:30:15 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 7 Feb 2014 16:30:14 +1100 (EST) From: Ian Smith To: "Julian H. Stacey" Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT In-Reply-To: <201402070318.s173Ijvb048532@fire.js.berklix.net> Message-ID: <20140207154259.N99797@sola.nimnet.asn.au> References: <201402070318.s173Ijvb048532@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pyunyh@gmail.com, stable@freebsd.org, David Chisnall , Christian Brueffer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 05:30:32 -0000 On Fri, 7 Feb 2014 04:18:45 +0100, Julian H. Stacey wrote: > David Chisnall wrote: > > On 6 Feb 2014, at 18:34, Julian H. Stacey wrote: > > > > > Best avoid the obscure word `Deprecated' in manuals: > > > It's not common/ plain English. Maybe a geek import, or USA > > > dialect ? It's not easily internationaly understood English. > > > Best make manuals easier for non native English speakers (& native > > > English too ;-). I am British born & bred, whether in English > > > speaking circles in UK or Germany I never hear or read 'deprecated' > > > unless its in BSD context. Few native English speakers I know will be > > > immediately sure of the meaning, it's too obscure. > > > > I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function. > > > > I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided. > > > > David > > (Also a native English speaker, although familiar with the unofficial fork from Leftpondia) > > Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia > American 1620 fork of English deduced. > 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 ounces > to a pint, & confused USA liquids down to 16 ounces. (Beware man units). > > Amerian is not always best international English. While I don't disagree with that Julian - assuming you meant American and not Armenian - you're wrong about 'deprecate' being an Americanism, and also about its use in non-technical contexts. >From my trusty Concise Oxford Dictionary, Sixth Edition 1976, Fourth Impression 1977 (with corrections): de'prec|ate v.t. Plead against (~ person's anger, entreat him not to be angry); express wish against or disapproval of (deprecate war, hasty action, panic); so ~A'TION n., ~ATIVE, ~ATORY, adjs. [f. L DE(precari pray) + -ATE] And of course it's not a million miles away from 'depreciate', usually more to do with money but also to 'disparage, belittle'. Aussies generally tend to favour taking the piss over the stiff upper lip approach; here's a recent snippet .. if you'll pardon my pascal :-) else if tok = 'dateform' then { precedes use in dates } mrkn := match(upcase(arg),'CA|NA|US') { dflt AU|NZ|UK..} [...] if pos('/',arg) > 0 then begin { dd/mm/[-]yyyy or mm/dd/[-]yyyy } if not split3 (arg, '/', dd, mm, yy) then begin writeln ('token ',tok,' bad date "',arg,'"'); break end; if mrkn then begin td := mm; mm := dd; dd := td end end cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 06:57:08 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 376F2FAF; Fri, 7 Feb 2014 06:57:08 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2AB517F0; Fri, 7 Feb 2014 06:57:06 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s176v2mC082124; Fri, 7 Feb 2014 08:57:02 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s176v2RZ082093; Fri, 7 Feb 2014 06:57:02 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 7 Feb 2014 06:57:02 GMT Message-Id: <201402070657.s176v2RZ082093@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 06:57:08 -0000 TB --- 2014-02-07 05:00:42 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-07 05:00:42 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-07 05:00:42 - starting RELENG_10 tinderbox run for mips64/mips TB --- 2014-02-07 05:00:42 - cleaning the object tree TB --- 2014-02-07 05:00:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-07 05:01:33 - At svn revision 261576 TB --- 2014-02-07 05:01:34 - building world TB --- 2014-02-07 05:01:34 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 05:01:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 05:01:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 05:01:34 - SRCCONF=/dev/null TB --- 2014-02-07 05:01:34 - TARGET=mips TB --- 2014-02-07 05:01:34 - TARGET_ARCH=mips64 TB --- 2014-02-07 05:01:34 - TZ=UTC TB --- 2014-02-07 05:01:34 - __MAKE_CONF=/dev/null TB --- 2014-02-07 05:01:34 - cd /src TB --- 2014-02-07 05:01:34 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 7 05:01:45 UTC 2014 >>> 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 Fri Feb 7 06:26:02 UTC 2014 TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m ADM5120 TB --- 2014-02-07 06:26:02 - skipping ADM5120 kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m ALCHEMY TB --- 2014-02-07 06:26:02 - skipping ALCHEMY kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AP121 TB --- 2014-02-07 06:26:02 - skipping AP121 kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AP91 TB --- 2014-02-07 06:26:02 - skipping AP91 kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AP93 TB --- 2014-02-07 06:26:02 - skipping AP93 kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AP94 TB --- 2014-02-07 06:26:02 - skipping AP94 kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AP96 TB --- 2014-02-07 06:26:02 - skipping AP96 kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AR71XX_BASE TB --- 2014-02-07 06:26:02 - skipping AR71XX_BASE kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AR724X_BASE TB --- 2014-02-07 06:26:02 - skipping AR724X_BASE kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AR91XX_BASE TB --- 2014-02-07 06:26:02 - skipping AR91XX_BASE kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AR933X_BASE TB --- 2014-02-07 06:26:02 - skipping AR933X_BASE kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m AR934X_BASE TB --- 2014-02-07 06:26:02 - skipping AR934X_BASE kernel TB --- 2014-02-07 06:26:02 - cd /src/sys/mips/conf TB --- 2014-02-07 06:26:02 - /usr/sbin/config -m BERI_DE4_BASE TB --- 2014-02-07 06:26:02 - building BERI_DE4_BASE kernel TB --- 2014-02-07 06:26:02 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:26:02 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:26:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:26:02 - SRCCONF=/dev/null TB --- 2014-02-07 06:26:02 - TARGET=mips TB --- 2014-02-07 06:26:02 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:26:02 - TZ=UTC TB --- 2014-02-07 06:26:02 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:26:02 - cd /src TB --- 2014-02-07 06:26:02 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_BASE >>> Kernel build for BERI_DE4_BASE started on Fri Feb 7 06:26:02 UTC 2014 >>> 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 >>> Kernel build for BERI_DE4_BASE completed on Fri Feb 7 06:30:41 UTC 2014 TB --- 2014-02-07 06:30:41 - cd /src/sys/mips/conf TB --- 2014-02-07 06:30:41 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2014-02-07 06:30:41 - building BERI_DE4_MDROOT kernel TB --- 2014-02-07 06:30:41 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:30:41 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:30:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:30:41 - SRCCONF=/dev/null TB --- 2014-02-07 06:30:41 - TARGET=mips TB --- 2014-02-07 06:30:41 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:30:41 - TZ=UTC TB --- 2014-02-07 06:30:41 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:30:41 - cd /src TB --- 2014-02-07 06:30:41 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Fri Feb 7 06:30:41 UTC 2014 >>> 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 >>> Kernel build for BERI_DE4_MDROOT completed on Fri Feb 7 06:35:33 UTC 2014 TB --- 2014-02-07 06:35:33 - cd /src/sys/mips/conf TB --- 2014-02-07 06:35:33 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2014-02-07 06:35:33 - building BERI_DE4_SDROOT kernel TB --- 2014-02-07 06:35:33 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:35:33 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:35:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:35:33 - SRCCONF=/dev/null TB --- 2014-02-07 06:35:33 - TARGET=mips TB --- 2014-02-07 06:35:33 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:35:33 - TZ=UTC TB --- 2014-02-07 06:35:33 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:35:33 - cd /src TB --- 2014-02-07 06:35:33 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Fri Feb 7 06:35:33 UTC 2014 >>> 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 >>> Kernel build for BERI_DE4_SDROOT completed on Fri Feb 7 06:40:15 UTC 2014 TB --- 2014-02-07 06:40:15 - cd /src/sys/mips/conf TB --- 2014-02-07 06:40:15 - /usr/sbin/config -m BERI_NETFPGA_MDROOT TB --- 2014-02-07 06:40:15 - building BERI_NETFPGA_MDROOT kernel TB --- 2014-02-07 06:40:15 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:40:15 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:40:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:40:15 - SRCCONF=/dev/null TB --- 2014-02-07 06:40:15 - TARGET=mips TB --- 2014-02-07 06:40:15 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:40:15 - TZ=UTC TB --- 2014-02-07 06:40:15 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:40:15 - cd /src TB --- 2014-02-07 06:40:15 - /usr/bin/make -B buildkernel KERNCONF=BERI_NETFPGA_MDROOT >>> Kernel build for BERI_NETFPGA_MDROOT started on Fri Feb 7 06:40:15 UTC 2014 >>> 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 >>> Kernel build for BERI_NETFPGA_MDROOT completed on Fri Feb 7 06:44:26 UTC 2014 TB --- 2014-02-07 06:44:26 - cd /src/sys/mips/conf TB --- 2014-02-07 06:44:26 - /usr/sbin/config -m BERI_SIM_BASE TB --- 2014-02-07 06:44:26 - building BERI_SIM_BASE kernel TB --- 2014-02-07 06:44:26 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:44:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:44:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:44:26 - SRCCONF=/dev/null TB --- 2014-02-07 06:44:26 - TARGET=mips TB --- 2014-02-07 06:44:26 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:44:26 - TZ=UTC TB --- 2014-02-07 06:44:26 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:44:26 - cd /src TB --- 2014-02-07 06:44:26 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_BASE >>> Kernel build for BERI_SIM_BASE started on Fri Feb 7 06:44:26 UTC 2014 >>> 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 >>> Kernel build for BERI_SIM_BASE completed on Fri Feb 7 06:48:46 UTC 2014 TB --- 2014-02-07 06:48:46 - cd /src/sys/mips/conf TB --- 2014-02-07 06:48:46 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2014-02-07 06:48:46 - building BERI_SIM_MDROOT kernel TB --- 2014-02-07 06:48:46 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:48:46 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:48:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:48:46 - SRCCONF=/dev/null TB --- 2014-02-07 06:48:46 - TARGET=mips TB --- 2014-02-07 06:48:46 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:48:46 - TZ=UTC TB --- 2014-02-07 06:48:46 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:48:46 - cd /src TB --- 2014-02-07 06:48:46 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Fri Feb 7 06:48:46 UTC 2014 >>> 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 >>> Kernel build for BERI_SIM_MDROOT completed on Fri Feb 7 06:52:54 UTC 2014 TB --- 2014-02-07 06:52:54 - cd /src/sys/mips/conf TB --- 2014-02-07 06:52:54 - /usr/sbin/config -m BERI_SIM_SDROOT TB --- 2014-02-07 06:52:55 - building BERI_SIM_SDROOT kernel TB --- 2014-02-07 06:52:55 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:52:55 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:52:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:52:55 - SRCCONF=/dev/null TB --- 2014-02-07 06:52:55 - TARGET=mips TB --- 2014-02-07 06:52:55 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:52:55 - TZ=UTC TB --- 2014-02-07 06:52:55 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:52:55 - cd /src TB --- 2014-02-07 06:52:55 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_SDROOT >>> Kernel build for BERI_SIM_SDROOT started on Fri Feb 7 06:52:55 UTC 2014 >>> 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 >>> Kernel build for BERI_SIM_SDROOT completed on Fri Feb 7 06:56:58 UTC 2014 TB --- 2014-02-07 06:56:58 - cd /src/sys/mips/conf TB --- 2014-02-07 06:56:58 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2014-02-07 06:56:58 - building BERI_TEMPLATE kernel TB --- 2014-02-07 06:56:58 - CROSS_BUILD_TESTING=YES TB --- 2014-02-07 06:56:58 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-07 06:56:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-07 06:56:58 - SRCCONF=/dev/null TB --- 2014-02-07 06:56:58 - TARGET=mips TB --- 2014-02-07 06:56:58 - TARGET_ARCH=mips64 TB --- 2014-02-07 06:56:58 - TZ=UTC TB --- 2014-02-07 06:56:58 - __MAKE_CONF=/dev/null TB --- 2014-02-07 06:56:58 - cd /src TB --- 2014-02-07 06:56:58 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Fri Feb 7 06:56:58 UTC 2014 >>> 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 [...] cd /src/sys/modules/aic7xxx/aicasm; PATH=/obj/mips.mips64/src/tmp/legacy/usr/sbin:/obj/mips.mips64/src/tmp/legacy/usr/bin:/obj/mips.mips64/src/tmp/legacy/usr/games:/obj/mips.mips64/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKEOBJDIRPREFIX=/obj/mips.mips64/src/sys/BERI_TEMPLATE/modules /obj/src/make.amd64/bmake SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD all cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c: In function 'symtable_dump': /src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/aicasm_symbol.c:461: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[1]: stopped in /src/sys/modules/aic7xxx/aicasm *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-07 06:57:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-07 06:57:01 - ERROR: failed to build BERI_TEMPLATE kernel TB --- 2014-02-07 06:57:01 - 4907.88 user 2441.63 system 6978.90 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-mips64-mips.full From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 07:28:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96DC1A59; Fri, 7 Feb 2014 07:28:39 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29C7A1A25; Fri, 7 Feb 2014 07:28:38 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WBfrU-000BfA-SZ; Fri, 07 Feb 2014 07:28:33 +0000 Date: Fri, 7 Feb 2014 08:28:39 +0100 From: Matthew Rezny To: FreeBSD Stable Mailing List Subject: Re: Tuning kern.maxswzone is minor compared to hangs in "kmem a" state Message-ID: <20140207082839.00001a3a@unknown> In-Reply-To: References: <20140201070912.00007971@unknown> <20140201221612.00001897@unknown> <20140202204623.00003fe5@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false Cc: Adrian Chadd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 07:28:39 -0000 On Sun, 2 Feb 2014 15:59:57 -0800 Adrian Chadd wrote: > [snip] > > So next time this happens, run "procstat -kka" - this will dump out > the processes and a basic function call trace for each of them. > > I'll see if there's a way to teach procstat to output line numbers if > the kernel debug image is available, but generally that's enough to > then pass to kgdb to figure out the line number. > > > -a I'm not sure if I would be able to run procstat given that top or reboot fail to run once the kernel is up against the limit. Fortunately, I haven't had a chance to even try that. I found the solution shortly after my last message but it took some time to verify. The solution is to increase vm.kmem_size to give the kernel some room to grow. That is one of the first things in tuning ZFS, which I had just started dealing with on i386 on a pair of less obsolete boxes. It struck me that maybe I should look into this parameter, which is one I never had occasion to have to touch before. On the box with 384MB RAM this was defaulting to 120.5MB, but on the box with 256MB RAM it was defaulting to only 80MB. It appears the default is simply 1/3 available RAM at boot. Presumably there is some lower bound, however that lower bound is no longer sufficient with all else default. I set vm.kmem_size="120M" in loader.conf and after rebooting I saw an immediate world of difference. I could do svnlite status and it completed. I put the box through the paces, svn up, buildworld and kernel, installworld and kernel (so now running 10-STABLE), svn up again, buildworld -DNO_CLEAN (still takes half a day, but that's far less than 2 days), installworld again. In other words, it was back to how it had been while running 9-STABLE. I am perfectly happy to give more than half the system memory to the kernel to have it stable. While that box was on the second run through building world, I decided to collect some numbers. I setup a temporary test VM in VirtualBox (on a much faster machine) configured with no harddrive image and boot from ISO. I used both 9.2 and 10.0 release ISOs for i386. I went through configurations with 128, 192, 256, and 384MB of RAM. For each OS and RAM combination, I booted the system and collected the entire output of sysctl. I did not do an stress testing, just collected default values. Comparing the data what I found is that while many other values changed, the value of vm.kmem_size stays the same from 9.2 to 10.0 at any given system memory size. I observed that the lower bound (if any) takes effect well below my smallest box since the 1/3 trend continued down all the way down to the smallest test VM with only half the RAM. It seems clear that with default settings on 10.0, vm.kmem_size is undersized for low-memory machines even running UFS. It seems common knowledge this needs to go up for ZFS, but it's complete news to me it needs to go up for UFS. I have not dug deep enough to determine if there is a singular culprit or multiple subsystems have grown more memory hungry over time. From the one panic I got it appears at least UFS with softupdates can be at least one. The extreme sluggishness if not complete hang or outright failure of disk I/O is a symptom consistent with the hypothesis that it has been UFS hitting an allocation limit in the kernel each time. Not only is it news to me that this might need to be increased on a UFS system, but the whole existence of vm.kmem_size is news to me since I never had to touch it in the past. On amd64, I see it is simply set to physical RAM, which makes sense, the kernel can grow to fill RAM but not beyond (don't want to swap it). Obviously it can't simply be equal to physical RAM on i386, it can't be over 1GB unless KVA_PAGES is increased. I don't understand why it isn't simply set to min(phy_mem, 1GB) by default. I can understand having a tunable to limit the kernel from growing for cases where the administrator knows best for some very specific working set. As the general case, I expect the kernel to handle maintaining the optimal balance between itself and user programs and I expect the ideal balance to vary between different workloads. Having a hard limit on kernel size only serves to limit the kernel's ability to tune the system according to current conditions. Is there any benefit to limiting kmem_size on i386? Is there any reason I should not simply set this vm.kmem_size=min(phys_mem, 1GB) on all my i386 boxes? For what reason is it stated that KVA_PAGES needs to be increased when setting kmem_size > 512MB when the default for KVA_PAGES gives a 1GB kernel memory space? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 08:29:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FF17691; Fri, 7 Feb 2014 08:29:03 +0000 (UTC) Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 56C63105C; Fri, 7 Feb 2014 08:29:03 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta05.bitpro.no (Postfix) with ESMTPS id 6D3AA17FC36; Fri, 7 Feb 2014 09:28:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 193FC161168; Fri, 7 Feb 2014 09:29:54 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyvTYpiCGSup; Fri, 7 Feb 2014 09:29:52 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 8658B161167; Fri, 7 Feb 2014 09:29:52 +0100 (CET) Message-ID: <52F49986.4050702@bitfrost.no> Date: Fri, 07 Feb 2014 09:29:58 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: FreeBSD Stable , FreeBSD Current , freebsd-questions@freebsd.org, "freebsd-usb@FreeBSD.org" Subject: [HEADS UP] MacBooks and Apple Trackpads Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 08:29:03 -0000 Hi, A new driver for the Apple Trackpad named "wsp" has been committed and MFC'ed to 9-stable and 10-stable from -current. The trackpad will appear non-working in X.org until HAL is recompiled with support for "wsp" devices. This happens when I MFC "etc/usb.conf" to 9-stable and 10-stable which then automatically loads the "wsp" kernel module when "devd" is started. This has not yet been done. As an alternative workaround: rm /boot/kernel/wsp.ko kldunload wsp Thank you for the attention! --HPS Reference: http://www.freshports.org/sysutils/hal/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 08:50:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D32B23E1 for ; Fri, 7 Feb 2014 08:50:48 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5182A1278 for ; Fri, 7 Feb 2014 08:50:47 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WBh8z-000F3i-FP for freebsd-stable@freebsd.org; Fri, 07 Feb 2014 08:50:41 +0000 Date: Fri, 7 Feb 2014 09:50:49 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: ZFS commits corruption to disk when kernel allocation fails Message-ID: <20140207095049.00003c7b@unknown> In-Reply-To: <20140202200446.000076c8@unknown> References: <20140201203112.0000210c@unknown> <20140202200446.000076c8@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 08:50:49 -0000 On Sun, 2 Feb 2014 20:04:46 +0100 Matthew Rezny wrote: > On Sat, 1 Feb 2014 20:31:12 +0100 > Matthew Rezny wrote: > > > I'm seeing rather strange behavior from 10.0 on i386 thus far. This > > is another long message, so if you want the summary without > > back-story, skip to the end. Sometimes it's hard to include > > relevant details without feeling like I'm rambling. I'm seeing > > rather strange behavior from 10.0 on i386 thus far. > > > > I started with FreeBSD not long before 4.0 release and ran 4.x > > releases on i386 and Alpha for a long time. I tried the 5.x releases > > and had nothing but trouble so stuck with 4.x through that time. The > > Alpha never did move off 4.x before it got retired, but some of my > > i386 boxes made it onto 6.x and then sat there until they were taken > > out of active use. For years, FreeBSD 4.x and 6.x was the reliable > > OS I used for everything but my desktop (which had been OS X). > > > > More recently I started using FreeBSD 8 on amd64 with ZFS and > > quickly moved on to 9 as soon as 9.0 was released. At the same > > time, i386 hardware retired from desktop roles but suitable for > > network services got 8.x installed on UFS. I had rather good > > experience with 9-STABLE on amd64 running with ZFS. For the most > > part it's solid, ZFS support is much better than the sorry state > > Apple left it in before abandoning it on OS X, though I did get a > > few kernel panics when simply connecting disks that contained > > zpools from OS X. Due to both compilation speed difference and the > > fact older hardware tends to be in more entrenched roles, I left my > > i386 systems out of the ZFS and 9.x experiments. I did also try 9.x > > on my one ppc64 box at various times to see if that might be a good > > way to utilize hardware Apple dropped support for years prior. The > > state on ppc64 varied between panic on boot to being able to > > buildworld but an idle system left for a few days would randomly go > > zombie, console freezes but clearly there is some system activity > > and it responds to ping but might not take a ssh connection, which > > I chalked up to the experimental state of the port. I did see > > console freezes on i386 boxes booted from a 9.1 mfsbsd image but > > never investigated because I was just using it to image and erase > > disks on old machines where I considered the hardware suspect. > > > > In the last couple months I've been moving my amd64 systems to 10, > > starting during the RCs and keeping up such that they are now all > > 10-STABLE. The transition was fairly smooth and they are running > > quite well. Even one box that has prior chipset and BIOS, which was > > panicking with an early 10-BETA is now running 10.0-RELEASE with > > KMS. All very impressive. So, time to start migrating some i386 > > boxes I figure. I had recently moved a number of them to 9.2 and > > figured I should just go ahead and move everything up to 10.0 at > > close to the same time if possible. I had seen no problems with 9.2 > > or 9-STABLE on the i386 boxes that I was preparing to upgrade, I > > already sorted out one Clang bug that affected a few (but less > > worse than a similar GCC bug that remains unfixed) since I had > > switched compilers when going to 9. > > > > Since I started moving i386 boxes to 10.0, I've had nothing but > > strange problems. Last night I wrote a message about kern.maxswzone, > > something I started getting warnings about on one particular box > > when I put 9.2 on it but which I didn't try to do anything about > > until now. I wrote that message with this one in mind, mentioning > > that I would have another about processes hanging. That one came > > first because it has at least some hard numbers and not so much > > subjective feelings of performance and reliability. Between then > > and now, the pattern struck me, all my early successes with 10 were > > amd64, and now all the i386 boxes I've upgraded are barely > > functional. > > > > I have 4 i386 boxes that I tried to put 10.0 on in the past week > > with various degrees of fail. There are 2 sets within the four, two > > are the low-end C3 boxes with 256MB and 384MB RAM described in my > > prior message to the list. The other two are Pentium4 systems, one > > with 2GB RAM and the other with 3GB, substantially bigger disks, > > decent GPU, etc. In other words, two are ancient and two are merely > > a little dated but still very usable. This faster pair I will > > mention first, then I will return to the slow pair. All these boxes > > are things I use around the house for network services or as > > essentially terminals in other rooms (kitchen pc to look up stuff, > > bedroom pc to watch movies, etc). The i386 boxes that run important > > services (externally facing network services, routing/firewall, > > etc) and being left two a second round once all issues are sorted > > out on these lower-importance boxes first. > > > > The P4s had 9-STABLE installed on UFS volumes. I did the switch from > > csup to svnup to pull the 10.0 sources, did the buildworld/kernel > > and install on both and all looked good. Before I went on to > > reinstall packages or anything else, I decided now might be a good > > time to try switching from UFS to ZFS, everything in /home was > > already backed up. So far I had only tried ZFS on amd64 due to > > early reports of flakiness on i386 related to exhausting kernel > > memory. In the couple years since initial support, the ZFS code has > > gotten better integrated, more people have tried it, some tuning > > guides have been written, and I've seen reports of it being used on > > boxes with 512MB RAM. Most of my i386 boxes in server roles have > > 2GB and it would be nice to migrate those to ZFS if possible. Best > > to test on these boxes first and try tuning if needed. > > > > I booted both P4 boxes from mfsbsd CD, mounted the existing UFS > > volums, tar the whole mess and drop the uncompressed tar on my file > > server. On the server, I fired off xz to compresses the tar file to > > speed the restore (or so I thought) while I prepared the machines. I > > setup the zpools in the normal way I'd done all my amd64 boxes. One > > P4 box has a single disk, the other has two, so one is a single vdev > > pool and the other is multiple, which adds a little variety for > > testing. Aside from vdevs, the pool properties, filesystems and > > their properties are all identical to how I've been setting up my > > other ZFS boxes. LZ4 on most filesystems, gzip or none on a few, > > sha256 hashes entirely, no dedupe, pretty normal. With the pools > > configured and mounted on /zroot, I scp the tar.xz file for each > > box into /tmp (which is tmpfs), and try tar xjpvf in /zroot. > > > > After initial good progress, both boxes seemed to hang at about the > > same time. Disk activity stops, tar is sitting there as if it's > > going to do something, but no further progress on either when left > > for an hour. I started top on both boxes and notice that the tar > > process on each is in the state "kmem a" and the resident memory > > allocation on each is exactly the same (around 750MB). My first > > thought was that I used too much RAM with the 500MB tar.xz file in > > tmpfs. One box says 800MB free and the other says 1800MB free but > > maybe there is a shortage of kernel memory. I can't seem to kill > > tar, so I just reboot each, clear the zpools to try from a fresh > > state again, mount the swap before filling /tmp this time, then > > attempt another extract. No joy, it stops the same way, with the > > exact same memory allocation, and each box is stopped on the exact > > same file as where each stopped on the first attempt. The free > > memory reports are the same as before, no sawp is being used, > > whatever is running out must be non-pageable. > > > > The next thing I try is decoupling the stages. The tar process is > > growing so large because it has to decompress lzma which requires a > > huge dictionary. I figure maybe the heavy disk I/O is causing > > buffers/cache to contend with the process in some way. Reboot again > > for a fresh start, scp the .tar.xz to /zroot/tmp, xz -d so it's > > just a plain tar, then tar xpvf in /zroot and both complete without > > error. Set the mointpoint to / for each zroot and reboot into the > > running system. That was strange but solvable. I don't know what > > the "kmem a" state is but I can guess it's probably short for > > something like "kmem alloc" which would suggest to me the process > > is waiting on a kernel allocation. So I figure I've got some tuning > > to do and a hung process isn't as bad as the kernel panics others > > had reported on i386 under heavy I/O load (e.g. rsync) with default > > settings. After all, the boot messages include two warnings about > > tuning ZFS memory on i386. In order to do the tuning, I need some > > reproducible load, and buildworld is good for that. So, first thing > > is switch from svnup to svnlite that is now in base and use that to > > get 10-STABLE sources. I do the rm -r on /usr/src and /usr/ports > > and then fire off the svnlite co for each. I find that the slowness > > of svn checkout is due to network latency and running the two in > > parallel doesn't create I/O contention on either disk or network. > > > > While the P4s are fetching their sources, I go to deal with the pair > > of Via C3 boxes that I had taken to 10-PRERELEASE just a week prior > > and was ready to upgrade to 10-STABLE. Since that upgrade, they sat > > unused waiting for an impending MFC so I could do away with a local > > patch. As mentioned in my other message, I made a mistake here on my > > first attempt, I forgot to clear the existing /usr/src > > and /usr/ports before starting the svnlite checkout. After > > realizing my mistake, I did the now larger (as it includes a .svn > > dir) rm -r of those dirs to start fresh. That's when I hit the > > problem with rm hanging on one box. Without repeating all the > > details, I had to boot mfsbsd to do the rm on the one box with only > > 256MB RAM, but what difference that made is simply inexplicable. > > Once I had gotten that straightened out, I started off the svnlite > > checkout fresh. On the box with 384MB, the completed with only one > > restart for network dropout (common since it takes 2-3 hours per > > checkout). On the box with 256MB (which had previously fully > > checked out and gotten to the point where it wanted to prompt me > > for the conflict on every file in the tree), svnlite could only do > > a hundred files or so before it seemed to hang in the same way as > > rm. Running just one instance on /usr/src without the parallel > > checkout on /usr/ports made no difference. When rm was hanging, I > > might be able to kill it (after several minutes wait) and reboot or > > the console might lock. When svnlite hung, I could not login but I > > might be able to run a command on another VT. I was able to catch > > that svnlite is getting stuck in the state "kmem a". Hmmm... the > > same state that tar was getting stuck in on the other boxes. How > > were those doing now? > > > > I look back at the P4s, which should be done as it's been a few > > hours spent on the C3 boxes. They are sitting there in the middle > > of checkout not making any visible progress. Ctrl-c doesn't work, I > > can't switch VTs, even ctrl-alt-del seems to not work. Seems like > > the consoles are hung in a way eerily similar to what I'd seen from > > 9.x on non-amd64 platforms (both ppc64 and i386). I attempted to > > initiate an ssh connection into each of the P4s and then walked off > > for a minute for refreshment. When I came back, expecting to find a > > login prompt or a timeout, I found the ssh attempts timed out and > > the two boxes had rebooted. I don't know if the ctrl-alt-del > > finally registered or if the incoming ssh connection pushed them > > over the edge. I wasn't there to see and the logs for both stop > > sometime before the hang. With both rebooted, I do a svnlite > > cleanup in /usr/src and /usr/pots or both, then fire off the > > svnlite co for each directory on both boxes. > > > > While those were running, I started digging into the kern.maxswzone > > tunable on the C3 box with less RAM. The box with more RAM was able > > to do the rm, svn checkout of both src and ports in parallel, and > > showed no obvious sign of trouble, though I hadn't started a > > buildworld yet. The box with less RAM was failing all over the place > > and the only obvious difference was the warning about that tunable. > > After I wasted hours figuring out the value is already sufficient > > but is apparently reduced after it's set, so it can't be effectively > > turned up, only down, I wrote my previous message to this list on > > that topic specifically and then went to bed. > > > > This morning I got up and was already thinking about the > > correlation, that 10 is a disaster on all my i386 boxes thus far. > > The first thing I checked was the P4 boxes. Both completed the svn > > checkout on both src and ports, good sign. However, the box with > > 3GB RAM has the message "vm_thread_new: kstack allocation failed" > > repeated about a dozen times, bad sign. First thing I do is try to > > run top to see what the size of ARC is, free RAM, etc. "No more > > processes." Uh Oh, that's no good at all, can't even run top. > > Curiously, the box with less RAM, only 2GB, has no messages so I > > try to start top on it to see what it's state is. Nothing happens > > when I push return, the cursor is just sitting there after top. On > > another VT, reboot gets the same response, none, cursor just sits. > > I can't type but I can switch VTs and scroll, until I do > > ctrl-alt-del, then every key press after that is a beep. Back on > > the once that said no processes left for top, reboot gets the same > > non-response. ctrl-alt-del doesn't beep, it just spits out the > > ^[[3~ typical of a dead console. Ugh, not even a reset button to > > punch on these P4 boxes. > > > > So, svnlite checkout is a real strain that can bring a system to > > it's knees. I'm not sure if this should be regarded as horrible > > inefficiency or as a means of checking the box before launching into > > a buildworld (as if that wasn't enough strain to uncover most > > problems). While 10.0 is good on amd64, it seems a disaster on i386. > > Processes hang in this "kmem a" state it doesn't take much more to > > get the box to livelock. I've only seen the "kmem a" state a few > > times as most other times I can't inspect anything before the box is > > locked too hard to do anything. In some cases I'm not sure there's > > even a way to get the box shutdown clean as the most trivial of > > things lock it up hard. It's not even required to do anything. When > > I was experimenting with kern.maxswzone last night I rebooted one > > box a few dozen times, so if I didn't need to look at systcl output > > I just hit ctrl-alt-del at the login prompt. Once the console died > > right then, it had just booted and ctrl-alt-del was met with a beep > > and then it's hung, have to punch reset. I'm guessing the console > > dies as a result of total wedging of I/O systems following heavy > > disk I/O. The cause is not just ZFS because the C3 boxes are UFS. > > The problem is not just the excess swap on the smallest box because > > I see the same sort of troubles on the box with the most RAM. Some > > kernel resource seems to be exhausted regardless of how much RAM or > > swap is present. > > > > I'm going to try buildworld on 3 of these to see what happens. For > > the fourth, I still need to get sources onto the disk before I can > > even attempt that. I'm not sure what to expect. It might be instant > > miserable failure, or it might actually run a long time since the > > I/O load is in bursts with lots of recovery time between. It'll > > take a few hours to see if the P4s succeed. It'll take two days to > > see a C3 succeed. Maybe by that time, someone will get through all > > I've written and have some useful suggestion for debugging. To me, > > it's rather hard to debug since I have little hint where to start, > > when the problem manifests any logging stops, and the box is in a > > state where it is essentially unobservable without a JTAG to jump > > in and directly inspect the state of it's world. > > Replying to self to give status update to anyone reading along. > > The pair of P4 boxes made it through buildworld/kernel after a few > tries. On these boxes I have /usr/obj mounted on a tmpfs as that's how > I've been setting up the other boxes with ZFS. Between the ZFS ARC > filling with source, the tmpfs filling with binaries, and the actual > compilation tasks there should be a good bit of memory pressure. > > The first build attempt was with -j10 on both boxes. As these are > single core CPUs, -j4 would have probably been more appropriate for > optimal speed. The build process on each failed after about an hour. > The exact stopping point was not noted since the actual error is > beyond reach of syscons history by the time the parallel build > process exits. The two boxes appear to have stopped at different > points. > > I restarted the make buildworld on each without any -j parameter and > without rebooting. I didn't want to clear the state, if the overly > parallel build caused anything to leak, I want to see that blow up the > non-parallel build. The first run through on each failed at different > points with one of the strangest compiler errors I've yet to see. The > builds failed with a fatal error: unable to open file [something}.c > (where something was rlogin.c on one and citrus_[forgotten].c on the > other). On both boxes, the first thing I did was cat thefile.c and of > course I see the source file as expected, so the compiler failing to > open the source file is a transient error. > > Following those odd errors, I restarted the build on each box with > exactly the same options and without rebooting to check > reproducibility. On the second non-parallel build attempt, both boxes > succeeded to build world and then proceeded on to the kernel build > without issue. Whatever resource exhaustion had cleared itself. I > checked the memory stats at that point. The box with 3GB RAM had no > swap currently in use, but might have experienced swapping during the > build. The box with 2GB RAM had 800MB swap used, which is reasonable > given the /usr/obj tmpfs was holding 2.2GB. Interestingly, the box > with more RAM was the first of the pair to fail out of the build both > times. The installkernel and installworld went off without a hitch. I > did get a warning about swapoff failing when dropping to single user > on the box with only 2GB, which is expected given the tmpfs spill > into swap. > > The situation with buildworld is not too bad. The spurious file open > errors are troubling, but not as bad as a panic or hang. The problem > is likely more specifically ZFS-triggered kernel memory pressure and > not general memory pressure. The low memory use but higher disk I/O > processes like tar and svn are more prone to trigger the problem. > Even higher disk I/O might hit the point of panic as some others have > reported with e.g. rsync on i386. Perhaps with some tuning, these > boxes can be made to behave reasonably. The initial problems with tar > seemed very troubling and I still don't have a good explanation for > why the memory use of the decompress while untaring seemed to make > such a difference. > > The situation with the C3 boxes is much worse. More details on those > will be in the other thread since that is where I gave the initial > details on those and got some reply. The most interesting bit from > that pair of boxes is the possible spurious file open fail. Running > svnlite through truss, I couldn't help but notice that it hung > immediately following a failure to stat a file that was in fact > present (fsck truncated it on the reboot after hang). Some VFS issue > that therefore affects UFS and ZFS on i386? Continuing this discussion with myself. I found the cause of the file open errors during buildworld and the cause is more troubling than the symptom. After getting ZFS tuned (details below) I ran a scrub and found that there was a bad file under /usr/src on both system. Different files on each, and on each it was the exact same file that the compile had failed on. I know ZFS will deny reads when it can't verify data integrity (which is annoying for file recovery, but potential very bad when the corruption is inside directory data). So it could have denied the reads when the compiler opened the file, but then why could I read it moments later with cat? Better question, why is there a corrupt file? A bad sector, maybe, except ZFS doesn't report read or checksum errors on the vdevs during the scrub. A bad sector on drives in two boxes, not reporting SMART errors either? Unlikely. Bad sectors on three drives (one box is a mirror zpool), all unreported, and two on independent disks coinciding with the same file such that ZFS can't heal the file data? Impossibly unlikely! The only possible explanation is in-memory corruption of ZFS data that is then committed to disk. The hang during svn checkout was likely the moment ZFS lost it's marbles and wrote some junk to disk in the directory it was working in. After the last message, I started on tuning ZFS on i386. I should have started into the tuning effort sooner, but my vision was clouded by the similarity to the problem I had just hit on the C3 boxes which have UFS filesystems. Also, most reports I saw of ZFS failing on i386 had manifested as panics whereas I was seeing livelock with failed kernel allocations. Once I started tuning the P4 boxes with ZFS, it became clear the kmem_size adjustment would also be the solution for the troubled box running UFS. First thing was vm.kmem_size as that is both first in the tuning guide (in conjunction with KVA_PAGES) and was mentioned in the warning from the kernel. It was a little under 400MB by default. I turned it up to 512MB, the claimed max without adjusting KVA_PAGES. That was enough to do fresh svn checkout, to tar and untar the entire /usr/src and /usr/ports in a temp dir, xz compress it, untar with -j, rebuild the world a few times, etc all without any hangs or reboots to reset state. I tried with tmpfs full enough to spill to disk to duplicate the mfsbsd case and still no trouble. So it seemed that setting vm.kmem_size to 512MB is the magic. Considering that is so important a value to the extent it can be difficult to even get installed onto a zpool without setting it, I wonder why the kernel only warns about it but doesn't just set it to the appropriate size. If it knows to warn it knows enough to set it. Unfortunately, 512MB is not enough and the repercussions of overrunning can be far worse. I continued through the ZFS tuning guide, increased ARC a bit to 320MB while leaving more room between arc_max and kmem_size than there was by default (192MB gap vs 150MB), enabled prefetch, set vdev cache size to 5MB, etc. With all the suggested tuning, I ran through everything again and all seemed ok. Content the problem was resolved, I went on to ports installs. Both built Xorg and I quickly tested it. On the box with 2GB RAM I built XBMC, tested it, and called that one done for the moment. On the box with 3GB RAM I started compiling KDE4 yesterday. I expected it to finish today and would have declared this matter resolved if it had. Unfortunately, it didn't finish, but died about 580 ports into a set of over 650. The place where it died was installing lapack, which would be a burst of disk I/O. The symptoms were all the same, hung process, can't start any new processes, can't login on another console, can't run top on already logged in console, can't reboot clean. The real surprise was on reboot, immediately after "Trying to mount root from zfs:zroot []..." I get a double fault. Tried booting twice, same fault both times. Fatal double fault: eip = 0xc1618ec7 esp = 0xe96b4f80 ebp = 0xe96b52e0 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: #0 0xc0a1cdbf at kdb_backtrace+0x52 #1 0xc09ef0db at panic+0x121 #2 0xc0e526bb at cpu_fetch_syscall_args+0 Uptime: 10s That doesn't tell me much specifically. Generally, I know the zpool must be severely borked to cause that on attempt to import the pool/mount root. It was bad enough to see that ZFS could manage to write corrupt data to disk that damages a file. At least that was easy to fix with an svn revert followed by another svn up and another scrub to be sure. This time it looked fatal. Fortunately, I was able to boot a mfsbsd CD and import the pool without panic. Scrub showed zero errors of any type and the following attempt to boot off the pool succeeded. The error must have been minor enough to fix without note on import or scrub, but is severe enough to make the pool unbootable. Why don't we default to higher vm.kmem_size, at least when using ZFS if not always? (It is undersize with UFS on low memory boxes too) Is there a benefit to not letting the kernel use all the RAM on i386 as it's allowed to do on amd64? Why does KVA_PAGES, which gives 1GB kernel address space by default, need to be increased in order to increase vm.kmem_size beyond 512M? Is there something other than the kernel allocating inside the kernel's address space? Is there some reason to not let the kernel grow to the limit of it's address space or physical RAM, whichever is less, when it feels a need to? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 08:59:44 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6BAD66F for ; Fri, 7 Feb 2014 08:59:44 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DA01012C1 for ; Fri, 7 Feb 2014 08:59:43 +0000 (UTC) Received: from porto.starpoint.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 KAA14731; Fri, 07 Feb 2014 10:58:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WBhGF-000Hxu-ER; Fri, 07 Feb 2014 10:58:11 +0200 Message-ID: <52F49FD2.4020708@FreeBSD.org> Date: Fri, 07 Feb 2014 10:56:50 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Garrett Wollman , freebsd-stable@FreeBSD.org Subject: Re: What's the "other" ARC category in top? References: <21236.8020.679484.302715@khavrinen.csail.mit.edu> In-Reply-To: <21236.8020.679484.302715@khavrinen.csail.mit.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 08:59:44 -0000 on 07/02/2014 01:48 Garrett Wollman said the following: > One of my servers says: > > ARC: 93G Total, 31G MFU, 24G MRU, 28M Anon, 3413M Header, 35G Other > > What is my ARC storing 35 GiB of? dnode and dbuf objects. Possibly you have lots of ZFS vnodes. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 09:46:24 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1308F90B for ; Fri, 7 Feb 2014 09:46:24 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B4231719 for ; Fri, 7 Feb 2014 09:46:22 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WBi0n-0008xi-Ee for freebsd-stable@freebsd.org; Fri, 07 Feb 2014 09:46:17 +0000 Date: Fri, 7 Feb 2014 10:46:23 +0100 From: Matthew Rezny To: freebsd-stable@freebsd.org Subject: Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT Message-ID: <20140207104623.000027ed@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) In-Reply-To: <201402070318.s173Ijvb048532@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 09:46:24 -0000 > Hi, Reference: > > From: David Chisnall > > Date: Thu, 6 Feb 2014 18:52:43 +0000 >=20 > David Chisnall wrote: > > On 6 Feb 2014, at 18:34, Julian H. Stacey > > wrote: > >=20 > > > Best avoid the obscure word `Deprecated' in manuals: > > > It's not common/ plain English. Maybe a geek import, or USA > > > dialect ? It's not easily internationaly understood English. > > > Best make manuals easier for non native English speakers (& > > > native English too ;-). I am British born & bred, whether in > > > English speaking circles in UK or Germany I never hear or read > > > 'deprecated' unless its in BSD context. Few native English > > > speakers I know will be immediately sure of the meaning, it's too > > > obscure. > >=20 > > I'd strongly disagree with this. Deprecated is, perhaps, only in > > common use as jargon, but it's very widespread within the tech > > field. I don't think I've ever read an API reference that doesn't > > include the word, for example, and it's even a keyword in many code > > documentation tools. For example, JavaDoc supports @deprecated and > > gcc / clang include an __attribute__((deprecated)) that generates a > > compile-time warning whenever anyone tries to call a deprecated > > function. =20 > >=20 > > I've not come across the word outside of tech uses, but I've also > > not come across the term network interface outside of tech > > circles. Deprecated, in this use, may be jargon, but it's very > > widespread jargon, and requesting it not be used sounds like asking > > for words like driver or processor also be avoided. > >=20 > > David > > (Also a native English speaker, although familiar with the > > unofficial fork from Leftpondia) >=20 > Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia > American 1620 fork of English deduced. > 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 > ounces to a pint, & confused USA liquids down to 16 ounces. (Beware > man units). >=20 dep=C2=B7re=C2=B7cate [dep-ri-keyt] verb (used with object), dep=C2=B7re=C2=B7cat=C2=B7ed, dep=C2=B7re=C2=B7cat= =C2=B7ing. 1. to express earnest disapproval of. 2. to urge reasons against; protest against (a scheme, purpose, etc.). 3. to depreciate; belittle. 4. (Archaic) to pray for deliverance from. Origin: 1615=E2=80=9325; < Latin d=C4=93prec=C4=81tus prayed against, war= ded off (past participle of d=C4=93prec=C4=81r=C4=AB ), equivalent to d=C4=93- de- + prec= ( =C4=81r=C4=AB ) to pray + -=C4=81tus -ate1 Based on those dates, if it once was an Americanism, then perhaps it is the word that started that fork. If the form of English you are currently using has failed to backport this word in the nearly 400 years following, then perhaps you are using a deprecated fork of the English language. > Amerian is not always best international English. It's a big early > variant of English, but other native English speakers round the > globe well outnumber American I believe. (Start with a map of the > Commonwealth), & many 2nd language people too will help define > international English, (as Jos=C3=A9 Manuel Barroso, EU commission > president, said), not just natives, eg British or Americans etc, > will get to shape international English. >=20 > Americans often seem to find it harder to grasp what's internationaly > portable English, as opposed to American, perhaps because a large > country makes a higher percentage of language experience internal > national usage. >=20 British often find it hard to understand their form of English isn't still the only form. Each country has it's own form with particular mutations. I am a well-traveled American currently living in central Europe. My experience in countries in which English is not the primary language has been that the form of English in use tends to be closer to American than British in terms of vocabulary (excepting heavy usage of a few odd Britishisms prevalent in Europe but not elsewhere). Spelling is less clearly in favor of one or the other. Of all the English speakers, it is ironically the British that I most often have trouble understanding. > FreeBSD's manual writers, especially non native English manual > writers, should not copy Americanisms &/or bad nomenclature from > one manual to another, but ask themselves if they know better words, > to make it easier also for other non native English to read. eg > Deprecated is not common English. >=20 As for the manuals, the important part is that the choice of English dialect is consist. Switching between American and British spelling in a document or set of documents is jarring. Being that the manuals are technical, it is expected they will use technical jargon with great liberty. There should be no effort to hinder that. Ideally all the documentation is proofread by multiple native English speakers. > PS Light relief: > http://www.bbc.com/future/story/20140206-can-drones-be-hacked >=20 > Cheers, > Julian > --=20 > Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich > http://berklix.com Interleave replies below like a play script. > Indent old text with "> ". Send plain text, not quoted-printable, > HTML, base64, or multipart/alternative. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 11:13:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4918EC51 for ; Fri, 7 Feb 2014 11:13:45 +0000 (UTC) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D7D71DC5 for ; Fri, 7 Feb 2014 11:13:44 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id x10so3012967pdj.36 for ; Fri, 07 Feb 2014 03:13:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=L9tENWlT284hzUNHTJfy9abIJd2ITEIM4vMod0B4/FE=; b=NL6d4wnnExiPruwXrlWuF+W5KSUA5oOU08/9d3sj6NOJZf4B8E0DKyQqdO4vz2VeX8 zjPQSfSxqNed/GcSlD5VPkGsd/RpRC5vhG1gs5cvxxmBC1gibUrKlI6+qNxtIwWf5v6t FuGY6K5CeOh74duSCAOI8086nnmQWL4UU40IVhEhJFoTeY6mT3jgDaHd8wi5fCfGm1mE 46Y5dg6Qvij1EBb3+f2ijL/+eTIXsZqzKaStiTYrRCIO10bRXNwi3Y3whBeWw9I7l9zY HboVMQhFLMtI+Y/mHFBtmsDT0igB6+mzAnQCCq2arViGm+INAfKcruIo90d9ir38ExDD uYrg== X-Gm-Message-State: ALoCoQkzYI3zNYN4LsoWdqBT/NfqHD2kGgb2bpzTEal0x9MnpvVvOINRJqJZQBgvVaOKQ/xDGJxR X-Received: by 10.68.194.65 with SMTP id hu1mr18991857pbc.158.1391771618723; Fri, 07 Feb 2014 03:13:38 -0800 (PST) Received: from blackbox.krakensys.lokal ([121.54.58.216]) by mx.google.com with ESMTPSA id vf7sm12608242pbc.5.2014.02.07.03.13.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 03:13:38 -0800 (PST) Message-ID: <52F4BFD1.9010301@anarchy.in.the.ph> Date: Fri, 07 Feb 2014 19:13:21 +0800 From: "Mars G. Miro" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: 9.2R on a 4.7GHz CPU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 11:13:45 -0000 Hi This is a known issue, yes ? FreeBSD 9.2-RELEASE #0: Mon Nov 4 15:25:29 PHT 2013 root@turk.XXX.XXX:/usr/obj/usr/src/sys/TURK amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: AMD FX(tm)-9590 Eight-Core Processor (4018.41-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f20 Family = 0x15 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x3e98320b AMD Features=0x2e500800 AMD Features2=0x1ebbfff,NodeId,TBM,Topology,,> Standard Extended Features=0x8 TSC: P-state invariant, performance statistics The CPU is set to 4.7GHz in the BIOS but it only shows up as above. Haven't tried FreeBSD 10 tho, will do that soon! Thanks! -- Don't sweat it -- it's only ones and zeros. -- P. Skelly From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 12:17:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BAFADE7 for ; Fri, 7 Feb 2014 12:17:31 +0000 (UTC) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A12214A6 for ; Fri, 7 Feb 2014 12:17:31 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id jy13so2732604veb.27 for ; Fri, 07 Feb 2014 04:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9km7vDYZeVVgxclmArt5+dIn2rAHY4+xdt92Uj/h5qA=; b=HWMp57V2L12dcopiL3PfLy4r3rQtvgDS6w8CIE1eAc019hqGVIm2HXIdUdqXDXUWAA 8fWIpY2cGQIyJs39K5kU2WDc+eS4hl9kGyjeiQQJVVoEPmE1D01fp3qxyYJFFviPUEWQ pZyJfcYzBIWw8chSNMiXQXQja6qfihgv2SYaxKeK5x8pqlVr0HtK1yyMB+oHTMyrU6eA uYqcq9llKjoFIjQsdA0Axq6yy54w4UesmhFUYaYnNI0y//DRmI9dtC5K5zT75N/K66D4 GsT6sr+AHkEHyi5/DJ6xtGfDUdiTpsvYjyXI67p/IQUiqET0kQNyFjeEQFR3qYxpvz7S xubg== MIME-Version: 1.0 X-Received: by 10.58.119.161 with SMTP id kv1mr10145525veb.21.1391775450252; Fri, 07 Feb 2014 04:17:30 -0800 (PST) Received: by 10.220.142.196 with HTTP; Fri, 7 Feb 2014 04:17:30 -0800 (PST) Date: Fri, 7 Feb 2014 13:17:30 +0100 Message-ID: Subject: FreeBSD 10 on VMWare in a corporate network; How? From: Alban Hertroys To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 12:17:31 -0000 Hi all, For an experiment @work I figured I'd install FreeBSD 10 x64 in a VMWare virtual machine that was made available to me, but I'm kind of stuck installing ports or packages... The thing is, the vmware tools provided with this version of VMWare (VMware=AE Workstation 10.0.1 build-1379776) are packaged with a Perl script and there it looks like there is no Perl in FreeBSD 10. We're behind an NT/LM authenticated proxy, which I haven't managed to get past yet from the FreeBSD installation in the VM, so downloading distfiles (Perl, for example) isn't currently possible. I created a shared folder in VMWare to store distfiles on, but apparently I need VMWare tools installed to access such a folder, which brings me back to the Perl problem. It appears that I need samba & squid to have NT/LM authentication to get through the proxy so that I can download ports & packages, but to obtain packages for those I need to be able to get through the proxy first. How do I solve this conundrum? If only I had a writable CD or an USB stick here, I could use that to transfer the files between the systems, but unfortunately I don't have any at hand (after the weekend perhaps, if I remember to bring them). --=20 If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 12:45:35 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ED3C8DE for ; Fri, 7 Feb 2014 12:45:35 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3AA717AC for ; Fri, 7 Feb 2014 12:45:34 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id c6so2635076lan.11 for ; Fri, 07 Feb 2014 04:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xQSYMpcccisQgS8p7UhrXwJWH2enLh9R/e9ZYNQUOwY=; b=P4+JkQOrglQyExTETJTn+nPiY75YG67hDC97bUFnLSBlu9CDsCplwsx+gVdXIuQg7d 6zKkcRFKAIhhx7qGFMzSOfmxUzZzOOlMsvP3m4E8/4+My/RTZLHQxYUVoHYXttYGIUp2 qyzhXHrR/mu4MxF0umLR6XJX0QYyltKkgPZVVEm8MG0BiMjEJ1+UCwPySV5NIEqyU7yQ FWkyI9Zs0qegAUxpiPBbr59ifqK5dBrO3ts8lz2GyPo/8pK3XzqKZJS64Gwhkycad6lH lSFzlENxQH5h2MJ9HKBvAVBr/p5Hwam63uSKMp93yqmeNJRjz9RS9jBXfsOyTKRS8NVR tn7g== MIME-Version: 1.0 X-Received: by 10.152.205.11 with SMTP id lc11mr9937051lac.29.1391777132628; Fri, 07 Feb 2014 04:45:32 -0800 (PST) Sender: vrwmiller@gmail.com Received: by 10.114.0.81 with HTTP; Fri, 7 Feb 2014 04:45:32 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 07:45:32 -0500 X-Google-Sender-Auth: Ir4Q_KekOaIoZCoUWqP-JKh2cws Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Rick Miller To: Alban Hertroys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 12:45:35 -0000 On Fri, Feb 7, 2014 at 7:17 AM, Alban Hertroys wrote: > Hi all, > > For an experiment @work I figured I'd install FreeBSD 10 x64 in a > VMWare virtual machine that was made available to me, but I'm kind of > stuck installing ports or packages... > > The thing is, the vmware tools provided with this version of VMWare > (VMware=AE Workstation 10.0.1 build-1379776) are packaged with a Perl > script and there it looks like there is no Perl in FreeBSD 10. > > We're behind an NT/LM authenticated proxy, which I haven't managed to > get past yet from the FreeBSD installation in the VM, so downloading > distfiles (Perl, for example) isn't currently possible. > > I created a shared folder in VMWare to store distfiles on, but > apparently I need VMWare tools installed to access such a folder, > which brings me back to the Perl problem. > > It appears that I need samba & squid to have NT/LM authentication to > get through the proxy so that I can download ports & packages, but to > obtain packages for those I need to be able to get through the proxy > first. > > How do I solve this conundrum? > You may consider obtaining the DVD ISO to upload to your ESX store; Attach it to the VM's cdrom device and boot to it which starts the installation. Everything you need to build the OS is on the DVD. --=20 Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 13:17:14 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF7B82AD for ; Fri, 7 Feb 2014 13:17:14 +0000 (UTC) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E8061AF2 for ; Fri, 7 Feb 2014 13:17:14 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id cz12so2746330veb.15 for ; Fri, 07 Feb 2014 05:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FeUXzSY35hUU6gWOBO0UgP8eT+Fg3ctp9x//vTz3YHI=; b=zAqMhNS5A8cIf0N6KNNaVoDahrSePpDJvI1qNYNm9ML4Q+SIc8YBX93TyW3LsYwXTO EKQ3qXHXBL9JfeN2D8x6rHkMuTGcba5zB3DmElSC7EFgqAqc4snc+I0zy1Lib2mZWy44 6CpKt3mEm62NrSga3UWK9SWNyy2r0vJHcGdI3kAYLFVkLleODpDGLm4fWmJK4iqYwHpQ 2YljOTTWnlCB0Xt1k8tIIYx+tuBwlYGztozsCWC4cZsrsRK+cjWJdAqAMd0lCpqYavdK Ghne68IlUP/fD7PBhnetr45bfhbXtsoE7+aF3DZ0oSi5SvBhEN/tvC3jFePgWx50NlKi C1kA== MIME-Version: 1.0 X-Received: by 10.220.97.145 with SMTP id l17mr53903vcn.35.1391779033153; Fri, 07 Feb 2014 05:17:13 -0800 (PST) Received: by 10.52.171.80 with HTTP; Fri, 7 Feb 2014 05:17:13 -0800 (PST) Date: Fri, 7 Feb 2014 17:17:13 +0400 Message-ID: Subject: Squid aufs crashes under 10.0 From: Pavel Timofeev To: freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 13:17:14 -0000 Hi! There is a problem with squid under FreeBSD10.0. Squid crashes immediately if storage type is set to aufs. It goes down during read of config file. No problem with diskd. No problem with aufs under FreeBSD9.2. Someone thinks that it's related to clang which is default compiler on FreeBSD 10.0. I recompiled www/squid33 with DEBUG option. Got coredump. Then I did and got this: gdb /usr/local/sbin/squid /var/squid/squid.core .... Reading symbols from /usr/lib/private/libheimipcc.so.11...done. Loaded symbols for /usr/lib/private/libheimipcc.so.11 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 Segmentation fault (core dumped) Gdb goes down too =) Any ideas? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 13:24:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48D4E98C for ; Fri, 7 Feb 2014 13:24:27 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 010511BF6 for ; Fri, 7 Feb 2014 13:24:26 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id ks9so2553016vcb.25 for ; Fri, 07 Feb 2014 05:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QsCx9cIf1YkGP/77lF/SmJqB0iknvQIMD73TMQYMmdA=; b=QAAvnd7yGj5xAagmif/DNkdNeQS1DOvv4mE0ofRNR5ebmRSpGTcSM9LhJiLWfhOLf/ YrRae06ipBLmOzAiJ94ksvd94GbJE+I6C7jZmB0yp+S51XqJwfNzabwdHY/5o12N6rhl L+sJ9h515BCalzcb6Pf+3fh2F2js4FTRs/yrt6RPHb4nT0WgAce5l6T0b+PclCyidSsh 5wA3eKLJ7GRsXuDd/Wl+rlD09o1Q2tiqXaRtrZjPrBqnsDUdjafgNtFebczPebFQDYJw jEYS1RQaG46Do//11PRHIVYiNndVngCVqhM726pIQ2mNpQ5WoB70o6pA15hTbYkJpvg5 6TJw== MIME-Version: 1.0 X-Received: by 10.58.58.3 with SMTP id m3mr492399veq.32.1391779466129; Fri, 07 Feb 2014 05:24:26 -0800 (PST) Received: by 10.220.142.196 with HTTP; Fri, 7 Feb 2014 05:24:26 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 14:24:26 +0100 Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Alban Hertroys To: Rick Miller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 13:24:27 -0000 > On Fri, Feb 7, 2014 at 7:17 AM, Alban Hertroys wrote= : >> >> Hi all, >> >> For an experiment @work I figured I'd install FreeBSD 10 x64 in a >> VMWare virtual machine that was made available to me, but I'm kind of >> stuck installing ports or packages... >> >> The thing is, the vmware tools provided with this version of VMWare >> (VMware=AE Workstation 10.0.1 build-1379776) are packaged with a Perl >> script and there it looks like there is no Perl in FreeBSD 10. >> >> We're behind an NT/LM authenticated proxy, which I haven't managed to >> get past yet from the FreeBSD installation in the VM, so downloading >> distfiles (Perl, for example) isn't currently possible. >> >> I created a shared folder in VMWare to store distfiles on, but >> apparently I need VMWare tools installed to access such a folder, >> which brings me back to the Perl problem. >> >> It appears that I need samba & squid to have NT/LM authentication to >> get through the proxy so that I can download ports & packages, but to >> obtain packages for those I need to be able to get through the proxy >> first. >> >> How do I solve this conundrum? > > > You may consider obtaining the DVD ISO to upload to your ESX store; Atta= ch > it to the VM's cdrom device and boot to it which starts the installation. > Everything you need to build the OS is on the DVD. I just got that far by myself, but thanks for the suggestion anyway. I'm afraid that not _everything_ I need is on the DVD though. The DVD does include pkg (from which one can extract pkg-static to install it) and perl, but not the open-vm-tools package or the compat6-amd64 that the VMWare supplied vmware-tools claims to require. It also lacks a vmware frame-buffer for Xorg, but perhaps that is provided by the (missing) vmware-tools package? There is a samba package that probably contains the necessary libraries to use NTLM authentication, but no Squid to combine those into a local NTLM-enabled proxy to get past the company proxy. This is my first time dabbling in proxy-waters and weird Windows authentication schemes, so I'm a little reliant on tutorials I found on the internet and the few around all use squid and samba... If there are other (probably better) ways, I'd love to hear them. Perhaps I don't need Squid? Cheers, Alban. --=20 If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 13:24:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FC03A76; Fri, 7 Feb 2014 13:24:39 +0000 (UTC) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BF5F1BF8; Fri, 7 Feb 2014 13:24:39 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id p17so2622829vbe.12 for ; Fri, 07 Feb 2014 05:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ccERDZLBBNZPbBMQmPvupL+M5NkL1a8EHMfk71xCS6o=; b=CK0TVrHoejCS1BgZv2mPzaG5WyjxAtG9EbZcvxRtoMXXiDgJs2ZDNUAocaYokVyx22 64ku1/tkEZ8vA7xyhBOQEzYGM+f/f4u/JP7iIdu9nVj7LyfLeb+jayRWAqn5ZoK7Gv0k +Nhf2BQywrMfPUHf+BTTgG/ePBs3bQ2I/qAaZShbw6JkMG33bmd8+yZRijxuriHAtd9Y 9xaOGxYmZbTs/sNkOngdhTAy/uepftCH82MOzKWEo3RlcyuaHzeHWScnJI1Xbspnctui EtKy1ZUJvdbfWr7v0qGEIE3nHuRrPUMESazdkUeCvcDfq4RqHiEei0SqO9MBapwE5wIW zKGw== MIME-Version: 1.0 X-Received: by 10.52.104.68 with SMTP id gc4mr8646883vdb.2.1391779478276; Fri, 07 Feb 2014 05:24:38 -0800 (PST) Received: by 10.52.171.80 with HTTP; Fri, 7 Feb 2014 05:24:38 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 17:24:38 +0400 Message-ID: Subject: Re: Squid aufs crashes under 10.0 From: Pavel Timofeev To: freebsd-stable stable , freebsd-ports@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 13:24:39 -0000 Sorry, it has to be in freebsd-ports@ too. 2014-02-07 Pavel Timofeev : > Hi! > There is a problem with squid under FreeBSD10.0. > Squid crashes immediately if storage type is set to aufs. > It goes down during read of config file. > > No problem with diskd. No problem with aufs under FreeBSD9.2. > > Someone thinks that it's related to clang which is default compiler on > FreeBSD 10.0. > > I recompiled www/squid33 with DEBUG option. Got coredump. > Then I did and got this: > gdb /usr/local/sbin/squid /var/squid/squid.core > .... > Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > Loaded symbols for /usr/lib/private/libheimipcc.so.11 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > Segmentation fault (core dumped) > > Gdb goes down too =) > Any ideas? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 13:50:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8560BD2; Fri, 7 Feb 2014 13:50:07 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDEE1E22; Fri, 7 Feb 2014 13:50:07 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:cc06:8a07:85a3:8279]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 83DF04AC1C; Fri, 7 Feb 2014 17:50:05 +0400 (MSK) Date: Fri, 7 Feb 2014 17:49:57 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <717736061.20140207174957@serebryakov.spb.ru> To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Why clang bundled with 10-RELEASE doesn't define __has_feature(cxx_nullptr)? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 13:50:07 -0000 Hello, freebsd-stable. Why __has_feature(cxx_nulptr) doesn't work on system compiler? nullptr itself works! Here is sample program: ============================= test.cxx #include #ifndef __has_feature #warning "Doesn't support for __has_feature at all" #define __has_feature(x) 0 #endif #if __has_feature(cxx_nullptr) #warning "Has nullptr" #else #warning "Doesn't have nullptr" #endif int main(int argn, char *argv[]) { void *v = nullptr; return 0; } ====================================== > c++ --version FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: x86_64-unknown-freebsd10.0 Thread model: posix > c++ test.cxx test.cxx:11:2: warning: "Doesn't have nullptr" [-W#warnings] #warning "Doesn't have nullptr" ^ 1 warning generated. > -- // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 13:51:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BEC8E96 for ; Fri, 7 Feb 2014 13:51:23 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1BEA1FB5 for ; Fri, 7 Feb 2014 13:51:22 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so2706217lbi.0 for ; Fri, 07 Feb 2014 05:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jM0lRbWYsWo0p7RvNUnFIq0+gHsxh1aawZqPHwWV2ZU=; b=xWL/shbLOxg4TbJt1n8sDOZfFm8YDEk0ELFGXLJ2hQ3fFAoM4GG48Yc4wCuCm4YpMC MkSb+Nxu2FrBwRGyVPZKLud8lsow6D2Kl+hYjzCbNhuS5sCame1JW4P6Aq4V+1y49mWG ocR78pafKZ8bxSjoNDLBDN7guFMCr2xMlrDwLngQL3WwganqVpbkIc1QmNxw5t2ToGLC Q2yi17mg+dQTJykLK7TSfvpBppXXYo1gn7htl1uuR0Zgl9PRZwIpBYjBPiXCKpR5reAa XAyVf1buupzb7Cci45fVOc1cj8PjM4hHa30nEUnKjvQ0CW/PtY4Az8PaZhAVUoliGQif yc9Q== MIME-Version: 1.0 X-Received: by 10.112.64.37 with SMTP id l5mr1545573lbs.49.1391781080992; Fri, 07 Feb 2014 05:51:20 -0800 (PST) Sender: vrwmiller@gmail.com Received: by 10.114.0.81 with HTTP; Fri, 7 Feb 2014 05:51:20 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 08:51:20 -0500 X-Google-Sender-Auth: RBDX7ym--oyuBAuRNH4UCTTQyVc Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Rick Miller To: Alban Hertroys Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 13:51:23 -0000 On Fri, Feb 7, 2014 at 8:24 AM, Alban Hertroys wrote: > > On Fri, Feb 7, 2014 at 7:17 AM, Alban Hertroys > wrote: > >> > >> > >> How do I solve this conundrum? > > > > > > You may consider obtaining the DVD ISO to upload to your ESX store; > Attach > > it to the VM's cdrom device and boot to it which starts the installation. > > Everything you need to build the OS is on the DVD. > > I just got that far by myself, but thanks for the suggestion anyway. > I'm afraid that not _everything_ I need is on the DVD though. > My apologies. I failed to realize you were past OS installation for some reason. I'm unable to help with your current circumstances, but you could build a custom DVD ISO containing the packages you're looking for (This is something I've done with previous FreeBSD releases, but not yet in 10.x with pkg(8)). I bet there's probably other ways to deal with this, but I'd have to defer to the list. -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 14:06:14 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12EFF51C for ; Fri, 7 Feb 2014 14:06:14 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D74EB10ED for ; Fri, 7 Feb 2014 14:06:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WBm4K-000O4j-9Z; Fri, 07 Feb 2014 14:06:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s17E6993068491; Fri, 7 Feb 2014 07:06:09 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+axqsOLJfX8a4FlInFNhJ7 Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Ian Lepore To: Alban Hertroys In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 07 Feb 2014 07:06:09 -0700 Message-ID: <1391781969.1196.53.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s17E6993068491 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 14:06:14 -0000 On Fri, 2014-02-07 at 13:17 +0100, Alban Hertroys wrote: > Hi all, >=20 > For an experiment @work I figured I'd install FreeBSD 10 x64 in a > VMWare virtual machine that was made available to me, but I'm kind of > stuck installing ports or packages... >=20 > The thing is, the vmware tools provided with this version of VMWare > (VMware=AE Workstation 10.0.1 build-1379776) are packaged with a Perl > script and there it looks like there is no Perl in FreeBSD 10. >=20 > We're behind an NT/LM authenticated proxy, which I haven't managed to > get past yet from the FreeBSD installation in the VM, so downloading > distfiles (Perl, for example) isn't currently possible. >=20 > I created a shared folder in VMWare to store distfiles on, but > apparently I need VMWare tools installed to access such a folder, > which brings me back to the Perl problem. >=20 > It appears that I need samba & squid to have NT/LM authentication to > get through the proxy so that I can download ports & packages, but to > obtain packages for those I need to be able to get through the proxy > first. >=20 > How do I solve this conundrum? >=20 > If only I had a writable CD or an USB stick here, I could use that to > transfer the files between the systems, but unfortunately I don't have > any at hand (after the weekend perhaps, if I remember to bring them). >=20 Can't you download the required distfiles onto another system, then copy them onto the new vm using scp? If not scp for some reason, then my fallback has always been netcat, which is especially handy for getting ssh keys onto new system that only has, for example, a serial console. on newsystem: nc -l 1200 >keys.tgz on sending system: nc newsystem 1200 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 175FD899; Fri, 7 Feb 2014 14:43:42 +0000 (UTC) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA4D31449; Fri, 7 Feb 2014 14:43:41 +0000 (UTC) Received: from www.dweimer.net (webmail [192.168.5.2]) by webmail.dweimer.net (8.14.7/8.14.7) with ESMTP id s17EheRT054051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Feb 2014 08:43:40 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 07 Feb 2014 08:43:40 -0600 From: dweimer To: Ian Lepore Subject: Re: FreeBSD 10 on VMWare in a corporate network; =?UTF-8?Q?How=3F?= Organization: dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <1391781969.1196.53.camel@revolution.hippie.lan> References: <1391781969.1196.53.camel@revolution.hippie.lan> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.0-rc Cc: owner-freebsd-stable@freebsd.org, freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:43:42 -0000 On 02/07/2014 8:06 am, Ian Lepore wrote: > On Fri, 2014-02-07 at 13:17 +0100, Alban Hertroys wrote: >> Hi all, >> >> For an experiment @work I figured I'd install FreeBSD 10 x64 in a >> VMWare virtual machine that was made available to me, but I'm kind of >> stuck installing ports or packages... >> >> The thing is, the vmware tools provided with this version of VMWare >> (VMware® Workstation 10.0.1 build-1379776) are packaged with a Perl >> script and there it looks like there is no Perl in FreeBSD 10. >> >> We're behind an NT/LM authenticated proxy, which I haven't managed to >> get past yet from the FreeBSD installation in the VM, so downloading >> distfiles (Perl, for example) isn't currently possible. >> >> I created a shared folder in VMWare to store distfiles on, but >> apparently I need VMWare tools installed to access such a folder, >> which brings me back to the Perl problem. >> >> It appears that I need samba & squid to have NT/LM authentication to >> get through the proxy so that I can download ports & packages, but to >> obtain packages for those I need to be able to get through the proxy >> first. >> >> How do I solve this conundrum? >> >> If only I had a writable CD or an USB stick here, I could use that to >> transfer the files between the systems, but unfortunately I don't have >> any at hand (after the weekend perhaps, if I remember to bring them). >> > > Can't you download the required distfiles onto another system, then > copy > them onto the new vm using scp? If not scp for some reason, then my > fallback has always been netcat, which is especially handy for getting > ssh keys onto new system that only has, for example, a serial console. > > on newsystem: > > nc -l 1200 >keys.tgz > > on sending system: > > nc newsystem 1200 > -- Ian > > > _______________________________________________ > 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" I did some searching on this, because I thought for sure I had this working in the past on a system. However the documentation for fetch, shows that it only supports basic and digest authentication. Then I remembered that the NTLM web filtering proxy we used when I was doing this would fail back to basic authentication if NTLM failed. But it might be worth a try, in case your Proxy does as well setting the environment as follows may help: HTTP_PROXY=http://proxy.example.com:8080 HTTP_PROXY_AUTH=basic:*:: See the following manual pages for more information on fetch environment variables: man fetch man 3 fetch -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 15:42:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F300197 for ; Fri, 7 Feb 2014 15:42:31 +0000 (UTC) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94BFB1A54 for ; Fri, 7 Feb 2014 15:42:30 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id m10so1639719eaj.26 for ; Fri, 07 Feb 2014 07:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wchl+VZnkYCQ538EYxWh8452oYpOGnKT1mdsi1N9gek=; b=rGqY7eAqrWuW/p/HXhsnrb9Td6Z0oei2t5yiJ61sJ282nZfiguBRMdUx95Y7S3i5CQ TLzoNmkSTZLE+LCgegnUSHQS88s2JqJXD7cl1brSqnXWHs5QGLVcT4KRrwVVzy0T5jo2 wIGh+gRtydDsxjOTvotmcA+raf1MRFgGA8oxIa02Onncw2tOlyI4w0L4/dGtpe1JsiVa RI3faHSlLu97d8F5vLASoLgQnH6i72js1I8hsMlxW912CwCabsa9T89qF7DLEjkmotW6 URTc4ggqF9eXxQd1uYQeSkgw5KO8mC85YFU4l1hwiZdcPsBLPU4o1rD56vUcpXkcA/Lg Kwzw== MIME-Version: 1.0 X-Received: by 10.14.225.67 with SMTP id y43mr17227947eep.10.1391787748986; Fri, 07 Feb 2014 07:42:28 -0800 (PST) Received: by 10.14.119.135 with HTTP; Fri, 7 Feb 2014 07:42:28 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 07:42:28 -0800 Message-ID: Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Kurt Buff To: Alban Hertroys Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Rick Miller , freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 15:42:31 -0000 On Fri, Feb 7, 2014 at 5:24 AM, Alban Hertroys wrote: >> On Fri, Feb 7, 2014 at 7:17 AM, Alban Hertroys wrot= e: >>> >>> Hi all, >>> >>> For an experiment @work I figured I'd install FreeBSD 10 x64 in a >>> VMWare virtual machine that was made available to me, but I'm kind of >>> stuck installing ports or packages... >>> >>> The thing is, the vmware tools provided with this version of VMWare >>> (VMware=C2=AE Workstation 10.0.1 build-1379776) are packaged with a Per= l >>> script and there it looks like there is no Perl in FreeBSD 10. >>> >>> We're behind an NT/LM authenticated proxy, which I haven't managed to >>> get past yet from the FreeBSD installation in the VM, so downloading >>> distfiles (Perl, for example) isn't currently possible. >>> >>> I created a shared folder in VMWare to store distfiles on, but >>> apparently I need VMWare tools installed to access such a folder, >>> which brings me back to the Perl problem. >>> >>> It appears that I need samba & squid to have NT/LM authentication to >>> get through the proxy so that I can download ports & packages, but to >>> obtain packages for those I need to be able to get through the proxy >>> first. >>> >>> How do I solve this conundrum? >> >> >> You may consider obtaining the DVD ISO to upload to your ESX store; Att= ach >> it to the VM's cdrom device and boot to it which starts the installation= . >> Everything you need to build the OS is on the DVD. > > I just got that far by myself, but thanks for the suggestion anyway. > I'm afraid that not _everything_ I need is on the DVD though. > > The DVD does include pkg (from which one can extract pkg-static to > install it) and perl, but not the open-vm-tools package or the > compat6-amd64 that the VMWare supplied vmware-tools claims to require. > It also lacks a vmware frame-buffer for Xorg, but perhaps that is > provided by the (missing) vmware-tools package? > > There is a samba package that probably contains the necessary > libraries to use NTLM authentication, but no Squid to combine those > into a local NTLM-enabled proxy to get past the company proxy. > > This is my first time dabbling in proxy-waters and weird Windows > authentication schemes, so I'm a little reliant on tutorials I found > on the internet and the few around all use squid and samba... If there > are other (probably better) ways, I'd love to hear them. Perhaps I > don't need Squid? > > Cheers, > Alban. Curl can do NTLM auth - perhaps some hackery to use that instead of fetch? Kurt From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 15:47:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 941EA54A; Fri, 7 Feb 2014 15:47:51 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DA3D1AAF; Fri, 7 Feb 2014 15:47:51 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::9502:12a8:3deb:47e] (unknown [IPv6:2001:7b8:3a7:0:9502:12a8:3deb:47e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4FD1F5C44; Fri, 7 Feb 2014 16:47:42 +0100 (CET) Subject: Re: Why clang bundled with 10-RELEASE doesn't define __has_feature(cxx_nullptr)? Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4BBF6D1A-1376-4B99-AA3A-E79385123DA2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric X-Priority: 3 (Normal) In-Reply-To: <717736061.20140207174957@serebryakov.spb.ru> Date: Fri, 7 Feb 2014 16:47:31 +0100 Message-Id: <4D300C6C-4684-4C42-B059-4CC40258358F@FreeBSD.org> References: <717736061.20140207174957@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1827) Cc: freebsd-hackers , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 15:47:51 -0000 --Apple-Mail=_4BBF6D1A-1376-4B99-AA3A-E79385123DA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 07 Feb 2014, at 14:49, Lev Serebryakov wrote: > Hello, freebsd-stable. >=20 > Why __has_feature(cxx_nulptr) doesn't work on system compiler? nullptr > itself works! ... >> c++ test.cxx > test.cxx:11:2: warning: "Doesn't have nullptr" [-W#warnings] > #warning "Doesn't have nullptr" Hi Lev, You need to specify at least -std=3Dc++0x for nullptr to be 'officially' = available. -Dimitry --Apple-Mail=_4BBF6D1A-1376-4B99-AA3A-E79385123DA2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlL1ABcACgkQsF6jCi4glqOiCwCfZ1wblORGtohD7J9hZdTmEUHe zYkAoMX/MQwL6DABrtSqFVTHairtsQYT =H/EL -----END PGP SIGNATURE----- --Apple-Mail=_4BBF6D1A-1376-4B99-AA3A-E79385123DA2-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 15:52:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 189FB870 for ; Fri, 7 Feb 2014 15:52:54 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0C4E1B84 for ; Fri, 7 Feb 2014 15:52:53 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s17FqgND091812; Fri, 7 Feb 2014 07:52:43 -0800 (PST) (envelope-from dg@pki2.com) Subject: Re: Squid aufs crashes under 10.0 From: Dennis Glatting To: Pavel Timofeev In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 07 Feb 2014 07:52:42 -0800 Message-ID: <1391788362.88229.35.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s17FqgND091812 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: dg@pki2.com Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 15:52:54 -0000 There are several problems with Squid source with one of the most significant in "debug." Specifically, there are print statements using cstring that DO NOT manage the case where cstring is empty (i.e., c_str() returns NULL) thereby producing SIGSEV. There are also a cases where strlen() is called with a NULL pointer, also causing SIGSEV. I have ported 3.4 to FreeBSD and I have patches available here. Some bugs are fixed, others not; However, I am running this code on two busy sites. http://www.pki2.com/squid34.tar I posted this stuff to ports@ but no response (it's a hack of the 3.3 Makefile, files, etc, but I'm not a ports commiter, for the sake of others :)). I believe aufs code is broken. I don't use it so I DID NOT try to figure out why. For certain the Rock Store code is broken. Note that I used clang++ 3.3 c++11. On Fri, 2014-02-07 at 17:17 +0400, Pavel Timofeev wrote: > Hi! > There is a problem with squid under FreeBSD10.0. > Squid crashes immediately if storage type is set to aufs. > It goes down during read of config file. > > No problem with diskd. No problem with aufs under FreeBSD9.2. > > Someone thinks that it's related to clang which is default compiler on > FreeBSD 10.0. > > I recompiled www/squid33 with DEBUG option. Got coredump. > Then I did and got this: > gdb /usr/local/sbin/squid /var/squid/squid.core > .... > Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > Loaded symbols for /usr/lib/private/libheimipcc.so.11 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > Segmentation fault (core dumped) > > Gdb goes down too =) > Any ideas? > _______________________________________________ > 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" -- Dennis Glatting From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 15:55:20 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 804FEB54 for ; Fri, 7 Feb 2014 15:55:20 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BF4A1BBE for ; Fri, 7 Feb 2014 15:55:20 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.7/8.14.5) with ESMTP id s17Ft85Y092300; Fri, 7 Feb 2014 07:55:08 -0800 (PST) (envelope-from dg@pki2.com) Subject: Re: Squid aufs crashes under 10.0 From: Dennis Glatting To: Pavel Timofeev In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 07 Feb 2014 07:55:08 -0800 Message-ID: <1391788508.88229.36.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s17Ft85Y092300 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: dg@pki2.com Cc: freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 15:55:20 -0000 Oh, and for fun it also compiles under clang++ 3.4 c++11. I don't recall trying g++ 4.8 or 4.9. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 16:22:31 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7448288A for ; Fri, 7 Feb 2014 16:22:31 +0000 (UTC) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2FEA31E20 for ; Fri, 7 Feb 2014 16:22:30 +0000 (UTC) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s17GMStN062270; Fri, 7 Feb 2014 11:22:28 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402071622.s17GMStN062270@maildrop2.v6ds.occnc.com> To: pyunyh@gmail.com From: Curtis Villamizar Subject: Re: Any news about "msk0 watchdog timeout" regression in 10-RELEASE? In-reply-to: Your message of "Fri, 07 Feb 2014 14:10:40 +0900." <20140207051040.GB1369@michelle.cdnetworks.com> Date: Fri, 07 Feb 2014 11:22:28 -0500 Cc: freebsd-stable@freebsd.org, Vitaly Magerya , curtis@ipv6.occnc.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:22:31 -0000 In message <20140207051040.GB1369@michelle.cdnetworks.com> Yonghyeon PYUN writes: > On Sat, Jan 25, 2014 at 09:50:50PM +0200, Vitaly Magerya wrote: > > On 01/25/14 21:35, Curtis Villamizar wrote: > > > When I'm no longer quite so swamped I'll look at this again. It seems > > > we are the only two reporting this problem. > > > > To everyone reading this list: if you have an msk(4) NIC that doesn't > > work on 10-RELEASE, now is the time to speak up. > > > > > Please send lines of these form from dmesg: > > > > > > mskc0: port 0xe800-0xe8ff > > > mem 0xfebfc000-0xfebfffff irq 19 at deviceD 0.0 on pci2 > > > > > > msk0: > > > on mskc0 > > > > > > That may indicate we have very similar chips. If not, this msk > > > problem may be more widespread. > > > > Mine goes like this: > > > > mskc0: port 0x2000-0x20ff > > mem 0xf0200000-0xf0203fff irq 18 at device 0.0 on pci9 > > > > msk0: > > on mskc0 > > > > Pretty different chips it seems. > > Please try r261577. Just update sys/dev/msk, or do I need more than that? Curtis From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 18:13:29 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F01779C; Fri, 7 Feb 2014 18:13:29 +0000 (UTC) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5991A19F1; Fri, 7 Feb 2014 18:13:29 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WBpvK-000Jpx-I2; Fri, 07 Feb 2014 18:13:10 +0000 Date: Fri, 7 Feb 2014 18:13:10 +0000 From: John To: freebsd-stable@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: VirtualBox 4.3.6 keyboard repeats keystrokes Message-ID: <20140207181310.GA65272@potato.growveg.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: john@potato.growveg.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 18:13:29 -0000 On Mon, Feb 03, 2014 at 09:38:45PM +0100, CeDeROM wrote: > Hello :-) > > I have noticed that quite often keystrokes are repeated in VBox 4.3.6 > OSE on FreeBSD-10.0 AMD64. For example when I press cursor left it > repeats many times, letters also. The fast way to stop this is to > switch to another application on my BSD box then switch back to VBox.. > > Did anyone notice this behavior? What is the problem? Yeah, I've seen it and it's a real pain. It doesn't matter if one is local or remote, if you type fast enough, it happens locally as well. I seem to remember there may be a repeat rate that needs to be set but my workaround is to not use the graphical client. It doesn't matter if one uses VNC or RDP or whatever. It happens locally if one types fast enough. Remotely, (ssh into host then exporting X over a fast ssh connection) it has made installing an ubuntu guest on a freebsd host impossible. Exporting an xterm over the same connection and keyboard repeat is normal. The effect from what I've read is not unique to freebsd hosts. -- John From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 19:03:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3C16D78; Fri, 7 Feb 2014 19:03:32 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E1B71E07; Fri, 7 Feb 2014 19:03:31 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id s17J3UkB004494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 7 Feb 2014 13:03:30 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Fri, 7 Feb 2014 13:03:28 -0600 From: Sender: Devin Teske To: "'Alban Hertroys'" , "'freebsd-stable'" References: In-Reply-To: Subject: RE: FreeBSD 10 on VMWare in a corporate network; How? Date: Fri, 7 Feb 2014 11:03:20 -0800 Message-ID: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI1PyBCILEnbCB+YXJV9dK/A+NI85nd7/fw Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-07_07:2014-02-07,2014-02-07,1970-01-01 signatures=0 Cc: 'Devin Teske' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 19:03:33 -0000 > -----Original Message----- > From: Alban Hertroys [mailto:haramrae@gmail.com] > Sent: Friday, February 7, 2014 4:18 AM > To: freebsd-stable > Subject: FreeBSD 10 on VMWare in a corporate network; How? > > Hi all, > > For an experiment @work I figured I'd install FreeBSD 10 x64 in a VMWare > virtual machine that was made available to me, but I'm kind of stuck installing > ports or packages... > > The thing is, the vmware tools provided with this version of VMWare > (VMwareR Workstation 10.0.1 build-1379776) are packaged with a Perl script > and there it looks like there is no Perl in FreeBSD 10. > > We're behind an NT/LM authenticated proxy, which I haven't managed to > get past yet from the FreeBSD installation in the VM, so downloading distfiles > (Perl, for example) isn't currently possible. > > I created a shared folder in VMWare to store distfiles on, but apparently I > need VMWare tools installed to access such a folder, which brings me back to > the Perl problem. > > It appears that I need samba & squid to have NT/LM authentication to get > through the proxy so that I can download ports & packages, but to obtain > packages for those I need to be able to get through the proxy first. > > How do I solve this conundrum? > > If only I had a writable CD or an USB stick here, I could use that to transfer the > files between the systems, but unfortunately I don't have any at hand (after > the weekend perhaps, if I remember to bring them). > [Devin Teske] Try setting the "http_proxy" environment variable... env http_proxy=myuser:mypass@myproxy pkg install -y perl -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 21:22:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C2317C5 for ; Fri, 7 Feb 2014 21:22:03 +0000 (UTC) Received: from mail.vaforge.com (mail.vaforge.com [195.23.42.145]) by mx1.freebsd.org (Postfix) with ESMTP id 155381A5F for ; Fri, 7 Feb 2014 21:22:03 +0000 (UTC) Received: from www.vaforge.com (ws01.vaforge.com [10.100.208.30]) by mail.vaforge.com (Postfix) with ESMTP id 0375C4606BE for ; Fri, 7 Feb 2014 21:24:09 +0000 (WET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vaforge.com; s=1391612689; t=1391808249; bh=CAKmrLtjxal4BQPJ5vH0VytJ+caJpPW/TUhuY02Gluc=; h=Date:To:From:Reply-To:Subject:List-Help:List-Unsubscribe: List-Subscribe:List-Owner:From; b=WSblVFnbZCy6SislNYYylPI5oMuR7AzRFMKXbZuqHfrHiMRw5LwVKrAPUAHw/rxZA WQzX4uTXOBHRaFCxm+7LEX0/xBLZ8mVFvfR/uYXgh7f2O/5vpC/1PBS1GiH3YQileh 0hO3C0UalnBk8nm6tDcEVxQ9FL7wLCuvbIifDp4s= Date: Fri, 7 Feb 2014 22:24:09 +0100 To: freebsd-stable@freebsd.org From: "marketing@vaforge.com" Subject: LUXURY TOURS IN PORTUGAL - Perfect Experiences Message-ID: <0d3ec2167de84e15bc022bd6ba04b475@localhost.localdomain> X-Priority: 3 X-Mailer: PHPMailer 5.2.5 (https://github.com/Synchro/PHPMailer/) X-phpList-version: 3.0.5 X-MessageID: 72 X-ListMember: freebsd-stable@freebsd.org Precedence: bulk Bounces-To: marketing@vaforge.com List-Owner: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: "marketing@vaforge.com" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:22:03 -0000 LUXURY TOURS IN PORTUGAL Portugal is the southwestern european country that you should visit. It may= =0Abe a little small but has a variety that will surprise you. It is a coun= try=0Awith a pleasant weather and abundant sunshine. Portugal has around 80= 0=0Ayears of history: can you imagine the heritage that has been built sinc= e=0Athen? Wonderful palaces, stunning churches, beautiful gardens. You have= =0Amany options: learn about our fascinating history, have an exciting trip= =0Athrough the narrow streets of Lisbon and Oporto or, if you prefer, come = to=0Aenjoy our nature beauties, and relax practicing your sport of choice. = We=0Ainvite you to visit Portugal. =20 TOUR PACKAGES: THE BEAUTY OF LISBON=09 =09TASTY AND MYSTERIOUS PORTO =09...=09 PRICE SINCE: 438,00 =E2=82=AC=09 =09PRICE SINCE: 685,00 =E2=82=AC =20 PREMIUM PORTUGAL EXPERIENCE=09 =09HISTORIC VILLAGES AND SOUTHERN PORTUGAL =09...=09 PRICE SINCE: 1 290,00 =E2=82=AC=09 =09PRICE SINCE: 1 350,00 =E2=82=AC =20 XTREME SKYDIVE XPERIENCE=09 =09CANYONING & NATURE EXPERIENCE =09...=09 PRICE SINCE: 330,00 =E2=82=AC=09 =09PRICE SINCE: 425,50 =E2=82=AC =20 RESERVATION IN ADVANCE - PACKAGES LIMITED OFFER ONLY AND SUBJECT TO=0AAVAIL= ABILITY! =20 Other Productos: The Alentejo Vineyards Colours=09Secret Trails in Portugal=09Surf Trip=0AMa= deira=09Equestrian and Hunting Tour =09=09=09 PRICE SINCE: 3.980,00 =E2=82=AC=09PRICE SINCE: 790,00 =E2=82=AC=09PRICE SIN= CE: 765,50=0A=E2=82=AC=09PRICE SINCE: 1.150,00 =E2=82=AC Connect with us Send us an Email Become a fan on Facebook Follow us on Twitter Follow us on Google +=20 Pin it on Pinteret=20 Feed us on RSS Feed www.perfxp.com Perfect Experiences, Lda - RNAVT n=C2=BA 3965 =C2=A9 Copyright 2014, Perfect Experiences, Lda. All rights reserved. -- This message was sent to freebsd-stable@freebsd.org by=0Amarketing@vaforge= .com To forward this message, please do not use the forward button of your email application, because this message was made specifically for you only. Instead use the forward page=0A in our newsletter system. To change your details and to choose which lists to be subscribed to, visit your personal preferences page=0A Or you can opt-out completely=0A from all future mailings. =20 -- powered by phpList, www.phplist.com -- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 21:40:16 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72CE9D8 for ; Fri, 7 Feb 2014 21:40:16 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 302381BCC for ; Fri, 7 Feb 2014 21:40:16 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n7so6989487qcx.2 for ; Fri, 07 Feb 2014 13:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+UXNv2UrbwkIhYWkOKTv6ULYz4Wi2zA5WvytIRnhkUo=; b=F0o5JTpzPdiFEZgvEz/d/izVKhyG8293p60Scr9410ytiCcLN1kDhvNhA7XBgNwrS1 KQT72IvMfqiwFTWkL9HHFtooqc6Qa3t+zKsdSnGyDtRQYy+7w9eZXT56kFD3MyptECC/ q1RTKwkqXaGtxr4v8OxLMdoCHRauqT3wjVlB9n4/GrQnIDCUvWMWOMsCkAzMHKTuxNoB dqVcp2bhT6BhFwwT+UzqxBj8rTFnUehjaikoOLJwKsgr4s1PwWx1JJK1OgBXZpcR38lm yGcQ+rv5ghqZQ5MeFpYGrJWuvsHdTLJQSgFDIG6i2GrAKATmxzjN/GmmWllktsu2GfTm zg/A== MIME-Version: 1.0 X-Received: by 10.224.16.72 with SMTP id n8mr26603387qaa.76.1391809215360; Fri, 07 Feb 2014 13:40:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Fri, 7 Feb 2014 13:40:15 -0800 (PST) In-Reply-To: <1391788362.88229.35.camel@btw.pki2.com> References: <1391788362.88229.35.camel@btw.pki2.com> Date: Fri, 7 Feb 2014 13:40:15 -0800 X-Google-Sender-Auth: IiXhUbw-gFNREg2L3ZKFSnijHFM Message-ID: Subject: Re: Squid aufs crashes under 10.0 From: Adrian Chadd To: Dennis Glatting Content-Type: text/plain; charset=ISO-8859-1 Cc: Pavel Timofeev , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 21:40:16 -0000 Have you filed a bug with the squid developers? I'm sure they'd like to fix this stuff. :-P -a On 7 February 2014 07:52, Dennis Glatting wrote: > There are several problems with Squid source with one of the most > significant in "debug." Specifically, there are print statements using > cstring that DO NOT manage the case where cstring is empty (i.e., > c_str() returns NULL) thereby producing SIGSEV. There are also a cases > where strlen() is called with a NULL pointer, also causing SIGSEV. > > I have ported 3.4 to FreeBSD and I have patches available here. Some > bugs are fixed, others not; However, I am running this code on two busy > sites. > > http://www.pki2.com/squid34.tar > > I posted this stuff to ports@ but no response (it's a hack of the 3.3 > Makefile, files, etc, but I'm not a ports commiter, for the sake of > others :)). > > I believe aufs code is broken. I don't use it so I DID NOT try to figure > out why. For certain the Rock Store code is broken. > > Note that I used clang++ 3.3 c++11. > > > > > > On Fri, 2014-02-07 at 17:17 +0400, Pavel Timofeev wrote: >> Hi! >> There is a problem with squid under FreeBSD10.0. >> Squid crashes immediately if storage type is set to aufs. >> It goes down during read of config file. >> >> No problem with diskd. No problem with aufs under FreeBSD9.2. >> >> Someone thinks that it's related to clang which is default compiler on >> FreeBSD 10.0. >> >> I recompiled www/squid33 with DEBUG option. Got coredump. >> Then I did and got this: >> gdb /usr/local/sbin/squid /var/squid/squid.core >> .... >> Reading symbols from /usr/lib/private/libheimipcc.so.11...done. >> Loaded symbols for /usr/lib/private/libheimipcc.so.11 >> Reading symbols from /libexec/ld-elf.so.1...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> Segmentation fault (core dumped) >> >> Gdb goes down too =) >> Any ideas? >> _______________________________________________ >> 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" > > -- > Dennis Glatting > > _______________________________________________ > 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 Fri Feb 7 23:24:15 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29DC4D5B for ; Fri, 7 Feb 2014 23:24:15 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBE0D14CE for ; Fri, 7 Feb 2014 23:24:14 +0000 (UTC) Received: from blazon-pc.rw.local ([78.84.244.14]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0LyEmR-1V6bFJ3gMH-015b8b for ; Sat, 08 Feb 2014 00:24:13 +0100 Message-ID: <52F56B1A.3020904@mail.com> Date: Sat, 08 Feb 2014 01:24:10 +0200 From: Jeff Tipton User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: regression: msk0 watchdog timeout and interrupt storm References: <52E6CB2B.9040208@mail.com> <52E911E8.2090104@mail.com> <20140207051340.GC1369@michelle.cdnetworks.com> In-Reply-To: <20140207051340.GC1369@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sN29yvrEwD38fFpbGbfbedph0VC1Snpmzos7lfGFeUCJgpssjO3 aGXwF5IXJqrIk+kI+754RzOJRnyZVGrNF4/DAX9dtsbGzJZK/p+59n3AWMVTSJFSSYKwyAT faxdsYnDO+oUizoGjIsz2vEKHBAag+gi9mcURgJssAw/EGFtKsKw8mCak0kI8lD1uu/jtzS thi4c7qt5wU6aSvJx694Q== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 23:24:15 -0000 On 02/07/2014 07:13, Yonghyeon PYUN wrote: > On Wed, Jan 29, 2014 at 04:36:24PM +0200, Jeff Tipton wrote: >> On 01/27/2014 23:10, Jeff Tipton wrote: >>> Hi, >>> >>> I also have this problem on Samsung N220 netbook, except I don't have >>> any "interrupt storm" messages. When it boots up, it works a couple of >>> minutes, and then "msk0: watchdog timeout" message appears. And, yes, >>> the fastest way to reproduce the error is to try to copy a file via >>> scp (even a 6MB file is enough). >>> >>> uname -a >>> >>> FreeBSD [..] 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 >>> 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC >>> amd64 >>> >>> pciconf -lcv >>> [..] >>> >>> mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab >>> rev=0x00 hdr=0x00 >>> vendor = 'Marvell Technology Group Ltd.' >>> device = '88E8040 PCI-E Fast Ethernet Controller' >>> class = network >>> subclass = ethernet >>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message >>> cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link >>> x1(x1) >>> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) >>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> ecap 0003[130] = Serial 1 f0d173ffff542400 >>> >>> I have FreeBSD 9.2-RELEASE on another partition, and msk0 works just >>> fine there. >>> >>> I also tried to change if_mskreg.h as Curtis suggested, recompiled the >>> kernel but it didn't help; nothing changed :( >>> >>> Jeff >>> _______________________________________________ >>> 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" >> And, yes, I also found out that after having been booted into 10.0, if I >> immediately reboot into 9.2, msk0 doesn't work there either; no >> "watchdof timeout" messages, though; but ifconfig shows "no carrier"; >> restarting interface or netif service doesn't help. I had to switch the >> netbook off completely and take the battery out for some minutes, and >> only then it finally worked in 9.2 again. > Jeff, please try r261577 and let me know how it works. > As you said, cold-boot is recommended way to test r261577. > _______________________________________________ > 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" Ok, I'm working on but it will take some time. Meanwhile I can tell that I experimented with PC-BSD 10, and that worked without any flaw. I don't know how it relates here but their revision was: 10.0-RELEASE-p5 FreeBSD 10.0-RELEASE-p5 #8 b261212(releng/10.0): Fri Jan 24 11:21:56 EST 2014 root@avenger:/usr/obj/root/pcbsd-build10.0/git/freebsd/sys/GENERIC amd64 Then an update reverted it back to p4 which also worked ok. -Jeff From owner-freebsd-stable@FreeBSD.ORG Fri Feb 7 23:51:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA859286; Fri, 7 Feb 2014 23:51:06 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B4871685; Fri, 7 Feb 2014 23:51:05 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id t61so2796950wes.36 for ; Fri, 07 Feb 2014 15:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dldXpHKxoIfo+YXZCpXTJqc+ZEI78vbNEUMZOqGym7A=; b=oRg9HmkxmpnvDr8SAVAySOCRrtNlysFNCxJAEGK0oEtDMAJqxpYqICs8/piZsJXsKn GkPsYwgCKHhCIoiIKAOnZbWmm5MfgjYrSelogJ4mvncf/ssvelJAual4nmpHaDrtgy9v tFW+U3BUSRT20x3AIVM7Oqv7TrxGe8MQtJSbaTqIVjj8QIhtEVn3FwHjXBL9jNlQWRMB bfRST2C51IL+EKckZeyRj9cKK9LoGGELBsX4KGd94vUxFQPvD3oyZzpF1hVD1y2Xr40D z/tAtz9qTpS6gh9bMxq13CcEndxfI+mbzyZiPZMC6x3PN+MKi31z1XVtbSYr0dlnjsac zJOw== X-Received: by 10.194.123.201 with SMTP id mc9mr8532203wjb.43.1391817064586; Fri, 07 Feb 2014 15:51:04 -0800 (PST) Received: from hollewijn.internal (8d690a59.ftth.concepts.nl. [141.105.10.89]) by mx.google.com with ESMTPSA id f3sm12497955wiv.2.2014.02.07.15.51.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 15:51:03 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? From: Alban Hertroys In-Reply-To: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> Date: Sat, 8 Feb 2014 00:51:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> To: dteske@freebsd.org X-Mailer: Apple Mail (2.1827) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Feb 2014 23:51:06 -0000 On 07 Feb 2014, at 20:03, dteske@freebsd.org wrote: >> We're behind an NT/LM authenticated proxy, which I haven't managed to >> get past yet from the FreeBSD installation in the VM, so downloading > distfiles >> (Perl, for example) isn't currently possible. >>=20 > [Devin Teske]=20 >=20 > Try setting the "http_proxy" environment variable... >=20 > env http_proxy=3Dmyuser:mypass@myproxy pkg install -y perl I did, as well as the other suggestion of setting HTTP_PROXY_AUTH. All I = got back from HTTP requests was that the proxy requires authentication. = I assume because that method doesn=92t do NT/LM authentication? I=92m going to try some of the other suggestions on Monday; hadn=92t = thought to try an ssh tunnel, for example. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 8 10:49:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60F14D66 for ; Sat, 8 Feb 2014 10:49:13 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [74.208.4.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 289051070 for ; Sat, 8 Feb 2014 10:49:12 +0000 (UTC) Received: from blazon-pc.rw.local ([78.84.244.14]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0LtZx4-1VBdTi04Jw-010uMQ for ; Sat, 08 Feb 2014 11:49:06 +0100 Message-ID: <52F60B9F.8010807@mail.com> Date: Sat, 08 Feb 2014 12:49:03 +0200 From: Jeff Tipton User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: regression: msk0 watchdog timeout and interrupt storm References: <52E6CB2B.9040208@mail.com> <52E911E8.2090104@mail.com> <20140207051340.GC1369@michelle.cdnetworks.com> <52F56B1A.3020904@mail.com> In-Reply-To: <52F56B1A.3020904@mail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p33uxgoOIQ6/T2d2Nh7nT2ebw0U+wQFlDyNzFl4cmVVQeA3sPJ+ DOvcYDT+swyzcfpL71oeMUCxct2bWEDe0STKoOUxWGZpI5/jsPloxf3CcSTziH30Hkgj7Jn 9TIAA9j4bI8J0OrPhyY4a/+vL3jDw5YwGN5S9yiu2pnSY/HYh9F58wELlZNSC3fDh4eGwv7 IUBHw+/yOmjcA35pLTIdg== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Feb 2014 10:49:13 -0000 The buildworld is in the process for 13 hours now, but I begin to doubt whether my checkout results are correct. Instead of svn checkout -r261577 https://svn0.eu.FreeBSD.org/base/releng/10.0 /usr/src I did svn checkout -r261577 https://svn0.eu.FreeBSD.org/base/head /usr/src However, the checkout ended with "Checked out revision 261577" message. Do you think this is ok? I would cleanse the src and obj directories if it did not mean so many hours of compiling. On 02/08/2014 01:24, Jeff Tipton wrote: > > On 02/07/2014 07:13, Yonghyeon PYUN wrote: >> On Wed, Jan 29, 2014 at 04:36:24PM +0200, Jeff Tipton wrote: >>> On 01/27/2014 23:10, Jeff Tipton wrote: >>>> Hi, >>>> >>>> I also have this problem on Samsung N220 netbook, except I don't have >>>> any "interrupt storm" messages. When it boots up, it works a couple of >>>> minutes, and then "msk0: watchdog timeout" message appears. And, yes, >>>> the fastest way to reproduce the error is to try to copy a file via >>>> scp (even a 6MB file is enough). >>>> >>>> uname -a >>>> >>>> FreeBSD [..] 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 >>>> 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC >>>> amd64 >>>> >>>> pciconf -lcv >>>> [..] >>>> >>>> mskc0@pci0:9:0:0: class=0x020000 card=0xc072144d chip=0x435411ab >>>> rev=0x00 hdr=0x00 >>>> vendor = 'Marvell Technology Group Ltd.' >>>> device = '88E8040 PCI-E Fast Ethernet Controller' >>>> class = network >>>> subclass = ethernet >>>> cap 01[48] = powerspec 3 supports D0 D1 D2 D3 current D0 >>>> cap 05[5c] = MSI supports 1 message, 64 bit enabled with 1 message >>>> cap 10[c0] = PCI-Express 2 legacy endpoint max data 128(128) link >>>> x1(x1) >>>> speed 2.5(2.5) ASPM L0s/L1(L0s/L1) >>>> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>>> ecap 0003[130] = Serial 1 f0d173ffff542400 >>>> >>>> I have FreeBSD 9.2-RELEASE on another partition, and msk0 works just >>>> fine there. >>>> >>>> I also tried to change if_mskreg.h as Curtis suggested, recompiled the >>>> kernel but it didn't help; nothing changed :( >>>> >>>> Jeff >>>> _______________________________________________ >>>> 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" >>> And, yes, I also found out that after having been booted into 10.0, >>> if I >>> immediately reboot into 9.2, msk0 doesn't work there either; no >>> "watchdof timeout" messages, though; but ifconfig shows "no carrier"; >>> restarting interface or netif service doesn't help. I had to switch the >>> netbook off completely and take the battery out for some minutes, and >>> only then it finally worked in 9.2 again. >> Jeff, please try r261577 and let me know how it works. >> As you said, cold-boot is recommended way to test r261577. >> _______________________________________________ >> 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" > Ok, I'm working on but it will take some time. Meanwhile I can tell > that I experimented with PC-BSD 10, and that worked without any flaw. > I don't know how it relates here but their revision was: > > 10.0-RELEASE-p5 FreeBSD 10.0-RELEASE-p5 #8 b261212(releng/10.0): Fri > Jan 24 11:21:56 EST 2014 > root@avenger:/usr/obj/root/pcbsd-build10.0/git/freebsd/sys/GENERIC amd64 > > Then an update reverted it back to p4 which also worked ok. > > -Jeff > _______________________________________________ > 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 Sat Feb 8 11:57:46 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0A4D37F; Sat, 8 Feb 2014 11:57:46 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3175C15B6; Sat, 8 Feb 2014 11:57:45 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s18BvZNo034358; Sat, 8 Feb 2014 13:57:35 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s18BvZeN034219; Sat, 8 Feb 2014 11:57:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 8 Feb 2014 11:57:35 GMT Message-Id: <201402081157.s18BvZeN034219@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 11:57:47 -0000 TB --- 2014-02-08 11:40:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-08 11:40:43 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-08 11:40:43 - starting RELENG_10 tinderbox run for i386/i386 TB --- 2014-02-08 11:40:43 - cleaning the object tree TB --- 2014-02-08 11:40:43 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-08 11:41:29 - At svn revision 261632 TB --- 2014-02-08 11:41:30 - building world TB --- 2014-02-08 11:41:30 - CROSS_BUILD_TESTING=YES TB --- 2014-02-08 11:41:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-08 11:41:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-08 11:41:30 - SRCCONF=/dev/null TB --- 2014-02-08 11:41:30 - TARGET=i386 TB --- 2014-02-08 11:41:30 - TARGET_ARCH=i386 TB --- 2014-02-08 11:41:30 - TZ=UTC TB --- 2014-02-08 11:41:30 - __MAKE_CONF=/dev/null TB --- 2014-02-08 11:41:30 - cd /src TB --- 2014-02-08 11:41:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Feb 8 11:41:41 UTC 2014 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/i386.i386/src/tmp\" -I/obj/i386.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTImporter.cpp -o ASTImporter.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/i386.i386/src/tmp\" -I/obj/i386.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/AttrImpl.cpp -o AttrImpl.o c++ -O2 -pipe -I/src/lib/clang/libclangast/../../../contrib/llvm/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -I/src/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/i386.i386/src/tmp\" -I/obj/i386.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CXXInheritance.cpp -o CXXInheritance.o /src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/DenseMap.h: In member function 'void llvm::SmallDenseMap::grow(unsigned int) [with KeyT = clang::QualType, ValueT = std::pair, unsigned int InlineBuckets = 8u, KeyInfoT = llvm::DenseMapInfo]': /src/lib/clang/libclangast/../../../contrib/llvm/include/llvm/ADT/DenseMap.h:846: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangast *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-02-08 11:57:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-08 11:57:34 - ERROR: failed to build world TB --- 2014-02-08 11:57:34 - 686.20 user 323.62 system 1011.04 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Feb 8 13:45:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C25335C7 for ; Sat, 8 Feb 2014 13:45:33 +0000 (UTC) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8250F1CB7 for ; Sat, 8 Feb 2014 13:45:32 +0000 (UTC) Received: by mail-yk0-f171.google.com with SMTP id q9so2206571ykb.2 for ; Sat, 08 Feb 2014 05:45:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=yHxoxGsKTz1ni0KscvjLqsWEqsrbqeGYTEKx0YS+xQM=; b=DpRzBl+/YLJDeVxQ5SXUTwGQ1MYrPu0AY2eWOPdGpRLhp5BXX3sekkmJ89k7pXDxeu 4fXSWKH3k33vzrBYUUSe2lQ39dV5Vf84gxU29xao8yNOwYAreG8u/AEHAbu4zO5evtDK RW43sfCqFq5vVxuXbtRHxD0w13N9RBRyIKFevitYE6RYzlT60tGmJcMb6bdu0ydUh5he uFtxjVLvTb3QAfyvwmGtsSm1dn2D0AHCT9PGk+qbC0GOULlBYFTAok4+e4qdoDv5UBkN vW7JKl+sMW7YKsd3MbHvlzNee5P8Ht7/TSITCHe6E42Jg1c74W1+cMgi/9bSDOEfw9ds xdmA== X-Gm-Message-State: ALoCoQnAnhOIoeNfIF/awAKlRZWyflCl5XMlzbDDkRA8Q30OdFuFlXv7MkZisHOpqNGuHgKshi8b MIME-Version: 1.0 X-Received: by 10.236.126.162 with SMTP id b22mr1198960yhi.72.1391867125966; Sat, 08 Feb 2014 05:45:25 -0800 (PST) Received: by 10.170.64.18 with HTTP; Sat, 8 Feb 2014 05:45:25 -0800 (PST) Date: Sat, 8 Feb 2014 14:45:25 +0100 Message-ID: Subject: Re: regression: msk0 watchdog timeout and interrupt storm From: Frans-Jan van Steenbeek To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Feb 2014 13:45:33 -0000 I've tested this by patching if_msk.c with r261577 and rebuilding the kernel from an otherwise clean 10.0-RELEASE src.txz. I got the watchdog timeouts quite quickly after booting the new kernel and running `pkg-static update`. Relevant information from dmesg: mskc0: port 0xe000-0xe0ff mem 0xfea20000-0xfea23fff irq 16 at device 0.0 on pci3 msk0: on mskc0 msk0: Ethernet address: dc:9c:52:07:a5:92 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 Let me know what I can do. Please do CC me, I'm not subscribed. ----- Yonghyeon PYUN - Fri Feb 7 05:13:48 UTC 2014 > Jeff, please try r261577 and let me know how it works. > As you said, cold-boot is recommended way to test r261577. -- Frans-Jan From owner-freebsd-stable@FreeBSD.ORG Sat Feb 8 17:02:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C5911C4 for ; Sat, 8 Feb 2014 17:02:33 +0000 (UTC) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F15F31C5B for ; Sat, 8 Feb 2014 17:02:32 +0000 (UTC) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s18H2U8X084030; Sat, 8 Feb 2014 12:02:30 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201402081702.s18H2U8X084030@maildrop2.v6ds.occnc.com> To: pyunyh@gmail.com From: Curtis Villamizar Subject: Re: Any news about "msk0 watchdog timeout" regression in 10-RELEASE? In-reply-to: Your message of "Fri, 07 Feb 2014 14:10:40 +0900." <20140207051040.GB1369@michelle.cdnetworks.com> Date: Sat, 08 Feb 2014 12:02:30 -0500 Cc: freebsd-stable@freebsd.org, Vitaly Magerya , curtis@ipv6.occnc.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 17:02:33 -0000 In message <20140207051040.GB1369@michelle.cdnetworks.com> Yonghyeon PYUN writes: > On Sat, Jan 25, 2014 at 09:50:50PM +0200, Vitaly Magerya wrote: > > On 01/25/14 21:35, Curtis Villamizar wrote: > > > When I'm no longer quite so swamped I'll look at this again. It seems > > > we are the only two reporting this problem. > > > > To everyone reading this list: if you have an msk(4) NIC that doesn't > > work on 10-RELEASE, now is the time to speak up. > > > > > Please send lines of these form from dmesg: > > > > > > mskc0: port 0xe800-0xe8ff > > > mem 0xfebfc000-0xfebfffff irq 19 at deviceD 0.0 on pci2 > > > > > > msk0: > > > on mskc0 > > > > > > That may indicate we have very similar chips. If not, this msk > > > problem may be more widespread. > > > > Mine goes like this: > > > > mskc0: port 0x2000-0x20ff > > mem 0xf0200000-0xf0203fff irq 18 at device 0.0 on pci9 > > > > msk0: > > on mskc0 > > > > Pretty different chips it seems. > > Please try r261577. Yonghyeon, OK. I assumed that you meant only sys/dev/msk and to use svn update -r261577 in "head". The only diff of any consequence relative to the stable-10 branch is: @@ -3749,9 +3750,6 @@ if ((status & Y2_IS_STAT_BMU) != 0 && domore == 0) CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ); - /* Clear TWSI IRQ. */ - if ((status & Y2_IS_TWSI_RDY) != 0) - CSR_WRITE_4(sc, B2_I2C_IRQ, 1); /* Reenable interrupts. */ CSR_WRITE_4(sc, B0_Y2_SP_ICR, 2); I used the r261577 in "head" and this failed on first reboot. That was after a long power down (shut off power strip). I reboot with the kernel that I had been using and it worked on first reboot with no power down. Rather limited testing but the fail on first reboot tells us what we need to know. Thanks for your continued interest in this. Curtis From owner-freebsd-stable@FreeBSD.ORG Sat Feb 8 19:39:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1585F00 for ; Sat, 8 Feb 2014 19:39:13 +0000 (UTC) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6C19F1836 for ; Sat, 8 Feb 2014 19:39:12 +0000 (UTC) Received: from tazar.mimar.rs (localhost [127.0.0.1]) by www.mimar.rs (Postfix) with ESMTP id 2C3B7B907A for ; Sat, 8 Feb 2014 20:39:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mimar.rs; h= content-transfer-encoding:content-type:content-type:mime-version :x-mailer:organization:references:in-reply-to:message-id:subject :subject:from:from:date:date:received:received; s=mimar-0901; t= 1391888342; x=1393702743; bh=WvHWr4kqHYqqVdP7yDCMCT39treZgtFFY62 NAsHERmY=; b=CF0gyfPZByfS2RZXMYuyRcCsrm7j4bhoFVN+D+FJpQk1DZUR8zm cx9MSHWjCEQUjESJRx83ka4ZHZg2nVGLLcxzNhZL4vKd9Wn+w2MeJhhgvBda0uYT q/0JItTfcEzztuN3V7OHGIzjqY4KNqcAWKpFeR/ylZtSsYw/1UAo2xDA= X-Virus-Scanned: amavisd-new at mimar.rs Received: from www.mimar.rs ([127.0.0.1]) by tazar.mimar.rs (tazar.mimar.rs [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tSE8ezncc7dN for ; Sat, 8 Feb 2014 20:39:02 +0100 (CET) Received: from kaa.mimar.rs (178-223-29-202.dynamic.isp.telekom.rs [178.223.29.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id 61663B9051 for ; Sat, 8 Feb 2014 20:39:02 +0100 (CET) Date: Sat, 8 Feb 2014 20:38:59 +0100 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 10 on VMWare in a corporate network; How? Message-Id: <20140208203859.b6a9c4f555b7e8301541e676@mimar.rs> In-Reply-To: <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> References: <0ac901cf2437$458837b0$d098a710$@FreeBSD.org> <773DBB2B-D421-44DB-848F-E4B7A9238085@gmail.com> Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Feb 2014 19:39:13 -0000 First of all, I wouldn't go with 10-RELEASE, as it is not officially supported. Go for 9.2-RELEASE amd64 or expect all kinds of problems. Indeed, in order to install vmware tools you need perl (best way is to go with lang/perl5.16), and misc/compat6x. If you are not in control of your Internet firewall and/or proxy, you should ask people who are to let you through. FreeBSD behind proxy with ntlm auth scheme is... er... I can't find the right word. Not good. --=20 Marko Cupa=C4=87 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 8 23:33:00 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 368612E9 for ; Sat, 8 Feb 2014 23:33:00 +0000 (UTC) Received: from amys.codelibre.net (3.5.1.6.b.a.e.f.f.f.7.a.a.e.a.3.d.b.d.d.0.6.8.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:860:ddbd:3aea:a7ff:feab:6153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 840CF1902 for ; Sat, 8 Feb 2014 23:32:58 +0000 (UTC) Received: from amys.codelibre.net (localhost [127.0.0.1]) by amys.codelibre.net (8.14.7/8.14.7) with ESMTP id s18NWtED011774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 8 Feb 2014 23:32:55 GMT (envelope-from rleigh@amys.codelibre.net) Received: (from rleigh@localhost) by amys.codelibre.net (8.14.7/8.14.7/Submit) id s18NWtC8011773 for freebsd-stable@freebsd.org; Sat, 8 Feb 2014 23:32:55 GMT (envelope-from rleigh) Date: Sat, 8 Feb 2014 23:32:55 +0000 From: Roger Leigh To: freebsd-stable@freebsd.org Subject: 10.0 toolchain broken for C++11 code Message-ID: <20140208233255.GA6282@amys.codelibre.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-GPG-Key: 0x07B3C8BC4083E800 X-Debian: testing/unstable X-OS-Uptime: 11:12PM up 12:15, 1 user, load averages: 0.27, 0.20, 0.20 User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 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, 08 Feb 2014 23:33:00 -0000 Hi folks, I'm new to using FreeBSD. I'm the author of the schroot(1) tool, and I've been porting it to FreeBSD using the new 10.0-RELEASE on amd64 and powerpc. The plan is to make it support jails and ZFS snapshots on FreeBSD systems. However, I've hit a blocker in that after fixing a few Linux-isms I've I've found that I can't actually link my code. This is a minimal testcase: % cat test.cpp #include int main() { const std::type_info& t =3D typeid(nullptr); } % CC -std=3Dc++11 -o test test.cpp /tmp/test-OoDHHT.o: In function `main': test.cpp:(.text+0xd): undefined reference to `_ZTIDn' CC: error: linker command failed with exit code 1 (use -v to see invocation) See also: standards/185663 https://github.com/pathscale/libcxxrt/issues/16 Being unfamiliar with FreeBSD my question is really, what sort of timescale is typical for fixing this type of issue? At least for my code, the toolchain is basically unusable until this is fixed, and I don't think there's a workaround for it. If it gets fixed in -STABLE, is it possible to selectively cherry-pick this somehow, or would I need to switch to -STABLE wholesale? Is there an expected date for 10.1 to be released? Thanks, Roger --=20 .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.