From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 10 01:20:09 2011 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 468201065673 for ; Mon, 10 Jan 2011 01:20:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7F48FC13 for ; Mon, 10 Jan 2011 01:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0A1K8AM035069 for ; Mon, 10 Jan 2011 01:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0A1K8i8035068; Mon, 10 Jan 2011 01:20:08 GMT (envelope-from gnats) Resent-Date: Mon, 10 Jan 2011 01:20:08 GMT Resent-Message-Id: <201101100120.p0A1K8i8035068@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, mike figley Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAFA71065675 for ; Mon, 10 Jan 2011 01:12:58 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id B0BEC8FC12 for ; Mon, 10 Jan 2011 01:12:58 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p0A1CwoM034456 for ; Mon, 10 Jan 2011 01:12:58 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p0A1CwsV034455; Mon, 10 Jan 2011 01:12:58 GMT (envelope-from nobody) Message-Id: <201101100112.p0A1CwsV034455@red.freebsd.org> Date: Mon, 10 Jan 2011 01:12:58 GMT From: mike figley To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Mon, 10 Jan 2011 01:32:33 +0000 Cc: Subject: amd64/153831: CD bootloader won't on Tyan s2912G2nr X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:20:09 -0000 >Number: 153831 >Category: amd64 >Synopsis: CD bootloader won't on Tyan s2912G2nr >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jan 10 01:20:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: mike figley >Release: 8.1 - install CD >Organization: dTC >Environment: won't boot >Description: I've attempted booting from CD the last several dev releases - the bootloader sprite spins a few times then hangs! The hardware: Tyan SG2912G2NR 8GB RAM (2) Dual Core Opterons 2214HE (8) 1TB WD Drives lastest BIOS v 4.00 The CDs Boot fine on another amd64 system with one dual-core CPU: ASUS 8-VX, 1GB RAM anybody else see this? Cheers! mike >How-To-Repeat: see above >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 10 11:06:57 2011 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47D981065694 for ; Mon, 10 Jan 2011 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1B99B8FC0C for ; Mon, 10 Jan 2011 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0AB6uf0001692 for ; Mon, 10 Jan 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0AB6uuG001689 for freebsd-amd64@FreeBSD.org; Mon, 10 Jan 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Jan 2011 11:06:56 GMT Message-Id: <201101101106.p0AB6uuG001689@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/153831 amd64 [boot] CD bootloader won't on Tyan s2912G2nr o amd64/153746 amd64 kernel crash with 2 X11 sessions on amd64 with radeon o amd64/153665 amd64 [ahci] AHCI module unconsistent behaviour with SATA3 d o amd64/153496 amd64 [hyper-v] [install] Install on Hyper-V leaves corrupt o amd64/153372 amd64 [panic] kernel panic o amd64/153175 amd64 [amd64] Kernel Panic on only FreeBSD 8 amd64 o amd64/152874 amd64 [install] 8.1 install fails where 7.3 works due to lac o amd64/152430 amd64 HP ProLiant Microserver n36l cannot boot into installe o amd64/151385 amd64 [boot] Installation hangs on MacBook o amd64/150170 amd64 [patch] [amd64] [headers] SIG_ATOMIC_MIN/SIG_ATOMIC_MA o amd64/148526 amd64 [ahci] ahci driver does not boot on AMD chip o amd64/145991 amd64 [NOTES] [patch] Add a requires line to /sys/amd64/conf o amd64/144405 amd64 [build] [patch] include /usr/obj/lib32 in cleanworld t s amd64/143173 amd64 [ata] Promise FastTrack TX4 + SATA DVD, installer can' o amd64/141413 amd64 [hang] Tyan 2881 m3289 SMDC freeze o amd64/141060 amd64 [install] Can't install 8.0-RELEASE on the server wher o amd64/140715 amd64 [boot] Dell M600 Blade fails to boot 7.2+ 64 bit o amd64/140145 amd64 sysinstall(8): Installation boot sequence freezes o amd64/139998 amd64 [panic][net] 7.2 amd64 panic in rtrequest1_fib o amd64/139924 amd64 [boot] cd or dvd not load o amd64/138029 amd64 [panic][bpf] periodically kernel panic and reboot o amd64/137942 amd64 [pci] 8.0-BETA2 having problems with Asus M2N-SLI-delu o amd64/135265 amd64 [mpt] Boot from install cd hangs on HP DL160 G5 with L o amd64/135040 amd64 [ata] FreeBSD/amd64 does not (always) detect disk on S o amd64/133977 amd64 [panic] [ffs] "panic: ffs_blkfree: freeing free block" o amd64/133701 amd64 Recompiling the kernel with k8temp or smbios break GEO o amd64/132574 amd64 [boot] [hang] Freeze on bootstrap loader (CD) using AT o amd64/131456 amd64 [acpi] [ata] ACPI & ATA problems s amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] [hang] The booting process stops at the line mo o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [em] amd64 motherboard: Intel DG965WH motherboard comp o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/127640 amd64 [amd64] gcc(1) will not build shared libraries with -f o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial f amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c f amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 46 problems total. From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 07:11:06 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2CCD106564A for ; Tue, 11 Jan 2011 07:11:06 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id 39FE38FC14 for ; Tue, 11 Jan 2011 07:11:03 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0B7Anq5009784; Mon, 10 Jan 2011 23:10:58 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Mon, 10 Jan 2011 23:10:58 -0800 (PST) Message-ID: Date: Mon, 10 Jan 2011 23:10:58 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:11:06 -0000 Greetings, I have been receiving these messages on a recent 8.1/AMD64 install. src/ports && world/kern about a week ago. Here is a block from the most recent output: nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 It appears to only occur when transmitting largish amounts of data across an NFS mount. I'm not sure where the MIN-threshold lies. But appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a largish server farm comprised of 7+ - 8.0 i386 servers. This one is the only AMD64. It is also the only AMD64. I experience this when mounting an 8.0/i386 server from this 8.1/AMD64. The i386 also has mounts on this 8.1/AMD64. relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: /usr/obj/usr/src/sys/UDNS01 i386 Tyan 2-CPU MB 2 NIC's: fxp0 (only one in use) ### 8.1/AMD64 FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 MSI K9N4 Ultra CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz K8-class CPU) 1 NIC nfe0 ### common to both: rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" nfs_server_enable="YES" NIC's on both boards are 10/100's @100mbps Can anyone provide any insight as to why I should be receiving these messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible with earlier versions? Thank you for all your time and consideration. --Chris From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 08:10:27 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BD2810656A4 for ; Tue, 11 Jan 2011 08:10:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C43E88FC1A for ; Tue, 11 Jan 2011 08:10:26 +0000 (UTC) Received: by wyf19 with SMTP id 19so20610273wyf.13 for ; Tue, 11 Jan 2011 00:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=dGmhYF7sHxvygItOliX5sKJXiqqbJrNeTByxmCTa+NM=; b=MyEpCotl8SgMI5nNvmA2BaW2l2HgxloZpLiWIGyFPFNlk8r9x4+YK6dx97NGkdLJwL eVkbSj5bLLs4g13uu1lYiMMj4KYs2wDLm2Mn9DDwDhiUH/cDnhG1JLy9IjPfRiF3RlAV TVndMokxMMFDiCe8tACrRB9EQz0Vj+xtyZEs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=VLAHAmaIFNaBOPTjqXyd6IUgcPmpLqmUYRTE7+P95yCZXizYr/t4FU6+hqeGXzOaj2 Cx3NHoCP0nuG8QIbtkm6oii29XfQ6TuoogoeESQBEGvW1CYDNAb6aMInRtCi/XUQW7zI UgmdohUjDylqyfqg1ei4HTO5Qj0meTwig2IVo= MIME-Version: 1.0 Received: by 10.216.180.77 with SMTP id i55mr4108387wem.76.1294731633281; Mon, 10 Jan 2011 23:40:33 -0800 (PST) Received: by 10.216.254.194 with HTTP; Mon, 10 Jan 2011 23:40:33 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 23:40:33 -0800 Message-ID: From: Pyun YongHyeon To: fbsdmail@dnswatch.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:10:27 -0000 On Mon, Jan 10, 2011 at 11:10 PM, wrote: > Greetings, > =A0I have been receiving these messages on a recent 8.1/AMD64 install. > src/ports && world/kern about a week ago. Here is a block from the most > recent output: > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > > It appears to only occur when transmitting largish amounts of data > across an NFS mount. I'm not sure where the MIN-threshold lies. But > appears to be >=3D1.5Mb. > This fresh 8.1/AMD64 is part of a largish server farm comprised of > 7+ - 8.0 i386 servers. This one is the only AMD64. It is also the > only AMD64. I experience this when mounting an 8.0/i386 server from > this 8.1/AMD64. The i386 also has mounts on this 8.1/AMD64. > relevant info: > ### 8.0/i386 > 8.0-STABLE FreeBSD 8.0-STABLE #0: /usr/obj/usr/src/sys/UDNS01 =A0i386 > Tyan 2-CPU MB > 2 NIC's: fxp0 (only one in use) > ### 8.1/AMD64 > FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 > MSI K9N4 Ultra > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz K8-class > CPU) > 1 NIC nfe0 > ### common to both: > rc.conf > nfs_client_enable=3D"YES" > nfs_reserved_port_only=3D"YES" > nfs_server_enable=3D"YES" > > NIC's on both boards are 10/100's @100mbps > > Can anyone provide any insight as to why I should be receiving these > messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible with > earlier versions? > No, I guess you're seeing one of unresolved nfe(4) issues. By chance, are you using forced media configuration instead of auto-negotiation? Posting both dmesg and "ifconfig nfe0" output would be useful. > Thank you for all your time and consideration. > > --Chris From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 08:28:08 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 372061065670 for ; Tue, 11 Jan 2011 08:28:08 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id ED5D08FC0C for ; Tue, 11 Jan 2011 08:28:07 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0B8Rx9H010012; Tue, 11 Jan 2011 00:28:06 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Tue, 11 Jan 2011 00:28:06 -0800 (PST) Message-ID: In-Reply-To: References: Date: Tue, 11 Jan 2011 00:28:06 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:28:08 -0000 Greetings Pyun YongHyeon, and thank you for your reply. On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: > On Mon, Jan 10, 2011 at 11:10 PM, wrote: > >> Greetings, >> I have been receiving these messages on a recent 8.1/AMD64 install. >> src/ports && world/kern about a week ago. Here is a block from the most >> recent output: nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> nfe0: tx v2 error 0x6204 >> >> >> It appears to only occur when transmitting largish amounts of data >> across an NFS mount. I'm not sure where the MIN-threshold lies. But >> appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a largish server >> farm comprised of 7+ - 8.0 i386 servers. This one is the only AMD64. It >> is also the only AMD64. I experience this when mounting an 8.0/i386 >> server from this 8.1/AMD64. The i386 also has mounts on this 8.1/AMD64. >> relevant info: ### 8.0/i386 >> 8.0-STABLE FreeBSD 8.0-STABLE #0: /usr/obj/usr/src/sys/UDNS01  i386 >> Tyan 2-CPU MB >> 2 NIC's: fxp0 (only one in use) >> ### 8.1/AMD64 >> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 >> MSI K9N4 Ultra >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz >> K8-class >> CPU) >> 1 NIC nfe0 >> ### common to both: >> rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" >> nfs_server_enable="YES" >> >> NIC's on both boards are 10/100's @100mbps >> >> >> Can anyone provide any insight as to why I should be receiving these >> messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible with earlier >> versions? >> > > No, I guess you're seeing one of unresolved nfe(4) issues. > By chance, are you using forced media configuration instead of > auto-negotiation? Posting both dmesg and "ifconfig nfe0" output would be > useful. As dmesg(8) goes, I have no dmesg.boot on either box, and bouncing them is not an immediate option. ifconfig nfe0 (the 8.1/amd64) follows: # ifconfig nfe0 nfe0: flags=8843 metric 0 mtu 1500 options=8010b ether 00:19:db:22:74:87 inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active FWIW ifconfig fxp0 on the 8.0/i386 follows: # ifconfig fxp0 fxp0: flags=8843 metric 0 mtu 1500 options=2009 ether 00:e0:81:20:9d:66 inet XXX.XXX.XXX.20 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet XXX.XXX.XXX.21 netmask 0xffffffff broadcast XXX.XXX.XXX.21 inet XXX.XXX.XXX.22 netmask 0xffffffff broadcast XXX.XXX.XXX.22 inet XXX.XXX.XXX.23 netmask 0xffffffff broadcast XXX.XXX.XXX.23 inet XXX.XXX.XXX.24 netmask 0xffffffff broadcast XXX.XXX.XXX.24 inet XXX.XXX.XXX.25 netmask 0xffffffff broadcast XXX.XXX.XXX.25 media: Ethernet autoselect (100baseTX) status: active They're all on the same /24, and as you can see, there is no forced media configuration. I /do/ have an old (pre-kern-build) dmesg.boot for the 8.1/amd64, if you (or anyone else) thinks it would help. If the dmesg.boot is absolutely required, I'll schedule an opportunity to bounce both of them - I'll need to know, tho. Thank you again for your thoughtful reply. --Chris > >> Thank you for all your time and consideration. >> >> >> --Chris >> > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > -- kern: FreeBSD 8.1-RELEASE amd64 From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 08:42:43 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E31B2106564A for ; Tue, 11 Jan 2011 08:42:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 748D58FC08 for ; Tue, 11 Jan 2011 08:42:43 +0000 (UTC) Received: by wwf26 with SMTP id 26so20168099wwf.31 for ; Tue, 11 Jan 2011 00:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=rEtVMPQWPYj2gqQ58G3dWouCkHyvRtRONMX/ot4mxKY=; b=Il7p+UAJ6tnxRBv12QusX6DCnhTFJ31+MQqHsSIA8h4rRJIv8UCU5fvW3wCz3ZursP ouTe1mr//UWPEC57HCqdAWR+uV4wAkAUVXCHio7shGNS8LniQE44Ov+2BBPDouMT4LWj +S/cC2OocNZuNFJp5TYenPte9s6iYAjXNZ7pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=WJfKFppgT5U+TaQPpJiH6V0g5DNxZBZcvWp+AqpEdLilk6nhAIu9Jt0vJ6pcu0CdaC GQuwt5YH7rOxL58aB5ezAbs7GpKxi4tTUAjPoWISzba0UDxkH33+sp2xB5eP3ZHFFK2k xuuHFvR2sbYOjevJFgxipIMu4XI+BXXg4Istg= MIME-Version: 1.0 Received: by 10.216.63.81 with SMTP id z59mr27030878wec.91.1294735362247; Tue, 11 Jan 2011 00:42:42 -0800 (PST) Received: by 10.216.254.194 with HTTP; Tue, 11 Jan 2011 00:42:42 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Jan 2011 00:42:42 -0800 Message-ID: From: Pyun YongHyeon To: fbsdmail@dnswatch.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:42:44 -0000 On Tue, Jan 11, 2011 at 12:28 AM, wrote: > Greetings Pyun YongHyeon, and thank you for your reply. > On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: >> On Mon, Jan 10, 2011 at 11:10 PM, =A0 wrote: >> >>> Greetings, >>> I have been receiving these messages on a recent 8.1/AMD64 install. >>> src/ports && world/kern about a week ago. Here is a block from the most >>> recent output: nfe0: tx v2 error 0x6204 >>> nfe0: tx v2 error 0x6204 [...] >>> nfe0: tx v2 error 0x6204 >>> >>> >>> It appears to only occur when transmitting largish amounts of data >>> across an NFS mount. I'm not sure where the MIN-threshold lies. But >>> appears to be >=3D1.5Mb. This fresh 8.1/AMD64 is part of a largish serv= er >>> farm comprised of 7+ - 8.0 i386 servers. This one is the only AMD64. It >>> is also the only AMD64. I experience this when mounting an 8.0/i386 >>> server from this 8.1/AMD64. The i386 also has mounts on this 8.1/AMD64. >>> relevant info: ### 8.0/i386 >>> 8.0-STABLE FreeBSD 8.0-STABLE #0: /usr/obj/usr/src/sys/UDNS01 =A0i386 >>> Tyan 2-CPU MB >>> 2 NIC's: fxp0 (only one in use) >>> ### 8.1/AMD64 >>> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 >>> MSI K9N4 Ultra >>> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz >>> K8-class >>> CPU) >>> 1 NIC nfe0 >>> ### common to both: >>> rc.conf nfs_client_enable=3D"YES" nfs_reserved_port_only=3D"YES" >>> nfs_server_enable=3D"YES" >>> >>> NIC's on both boards are 10/100's @100mbps >>> >>> >>> Can anyone provide any insight as to why I should be receiving these >>> messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible with earlier >>> versions? >>> >> >> No, I guess you're seeing one of unresolved nfe(4) issues. >> By chance, are you using forced media configuration instead of >> auto-negotiation? Posting both dmesg and "ifconfig nfe0" output would be >> useful. > > As dmesg(8) goes, I have no dmesg.boot on either box, and bouncing them > is not an immediate option. > > ifconfig nfe0 (the 8.1/amd64) follows: > # ifconfig nfe0 > nfe0: flags=3D8843 metric 0 mtu 1= 500 > =A0 =A0 =A0 =A0options=3D8010b > =A0 =A0 =A0 =A0ether 00:19:db:22:74:87 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.X= XX.31 > =A0 =A0 =A0 =A0inet6 fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0= x1 > =A0 =A0 =A0 =A0nd6 options=3D3 > =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX ) Does the link partner also agree on the resolved duplex(half-duplex)? It's not common to see half-duplex in these days. Please make sure link partner is also using auto-negotiation. > =A0 =A0 =A0 =A0status: active > > FWIW ifconfig fxp0 on the 8.0/i386 follows: > # ifconfig fxp0 > fxp0: flags=3D8843 metric 0 mtu 1= 500 > =A0 =A0 =A0 =A0options=3D2009 > =A0 =A0 =A0 =A0ether 00:e0:81:20:9d:66 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.20 netmask 0xffffffe0 broadcast XXX.XXX.X= XX.31 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.21 netmask 0xffffffff broadcast XXX.XXX.X= XX.21 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.22 netmask 0xffffffff broadcast XXX.XXX.X= XX.22 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.23 netmask 0xffffffff broadcast XXX.XXX.X= XX.23 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.24 netmask 0xffffffff broadcast XXX.XXX.X= XX.24 > =A0 =A0 =A0 =A0inet XXX.XXX.XXX.25 netmask 0xffffffff broadcast XXX.XXX.X= XX.25 > =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX) > =A0 =A0 =A0 =A0status: active > > They're all on the same /24, and as you can see, there is no > forced media configuration. > > I /do/ have an old (pre-kern-build) dmesg.boot for the 8.1/amd64, if > you (or anyone else) thinks it would help. If the dmesg.boot is > absolutely required, I'll schedule an opportunity to bounce both of > them - I'll need to know, tho. > Then show me the output of "devinfo -rv" and "pciconf -lcbv". > Thank you again for your thoughtful reply. > > --Chris > > >> >>> Thank you for all your time and consideration. >>> >>> >>> --Chris >>> >> _______________________________________________ >> freebsd-amd64@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >> To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" >> >> > > > -- > kern: > FreeBSD 8.1-RELEASE amd64 > > > From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 09:01:52 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4A831065674 for ; Tue, 11 Jan 2011 09:01:52 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id 876D08FC0C for ; Tue, 11 Jan 2011 09:01:52 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0B91iSm010143; Tue, 11 Jan 2011 01:01:50 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Tue, 11 Jan 2011 01:01:51 -0800 (PST) Message-ID: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> In-Reply-To: References: Date: Tue, 11 Jan 2011 01:01:51 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:01:52 -0000 On Tue, January 11, 2011 12:42 am, Pyun YongHyeon wrote: > On Tue, Jan 11, 2011 at 12:28 AM, wrote: > >> Greetings Pyun YongHyeon, and thank you for your reply. >> On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: >> >>> On Mon, Jan 10, 2011 at 11:10 PM,   wrote: >>> >>> >>>> Greetings, >>>> I have been receiving these messages on a recent 8.1/AMD64 install. >>>> src/ports && world/kern about a week ago. Here is a block from the >>>> most recent output: nfe0: tx v2 error 0x6204 nfe0: tx v2 >>>> error 0x6204 > > [...] > > >>>> nfe0: tx v2 error 0x6204 >>>> >>>> >>>> >>>> It appears to only occur when transmitting largish amounts of data >>>> across an NFS mount. I'm not sure where the MIN-threshold lies. But >>>> appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a largish >>>> server farm comprised of 7+ - 8.0 i386 servers. This one is the only >>>> AMD64. It >>>> is also the only AMD64. I experience this when mounting an 8.0/i386 >>>> server from this 8.1/AMD64. The i386 also has mounts on this >>>> 8.1/AMD64. >>>> relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: >>>> /usr/obj/usr/src/sys/UDNS01  i386 >>>> Tyan 2-CPU MB >>>> 2 NIC's: fxp0 (only one in use) >>>> ### 8.1/AMD64 >>>> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 >>>> MSI K9N4 Ultra >>>> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz >>>> K8-class >>>> CPU) >>>> 1 NIC nfe0 >>>> ### common to both: >>>> rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" >>>> nfs_server_enable="YES" >>>> >>>> NIC's on both boards are 10/100's @100mbps >>>> >>>> >>>> >>>> Can anyone provide any insight as to why I should be receiving >>>> these messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible >>>> with earlier versions? >>>> >>> >>> No, I guess you're seeing one of unresolved nfe(4) issues. >>> By chance, are you using forced media configuration instead of >>> auto-negotiation? Posting both dmesg and "ifconfig nfe0" output would >>> be useful. >> >> As dmesg(8) goes, I have no dmesg.boot on either box, and bouncing them >> is not an immediate option. >> >> ifconfig nfe0 (the 8.1/amd64) follows: # ifconfig nfe0 >> nfe0: flags=8843 metric 0 mtu >> 1500 >> options=8010b ether >> 00:19:db:22:74:87 >> inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 >> fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 >> nd6 options=3 media: Ethernet autoselect >> (100baseTX ) >> > > Does the link partner also agree on the resolved duplex(half-duplex)? > It's not common to see half-duplex in these days. > Please make sure link partner is also using auto-negotiation. > I thought that odd, as well. Both kerns have as nearly the same options as is possible. Because the 8.1/amd64 is intended as a replacement for the 8.0/i386. They're both on the same switch. > >> status: active >> >> >> FWIW ifconfig fxp0 on the 8.0/i386 follows: >> # ifconfig fxp0 >> fxp0: flags=8843 metric 0 mtu >> 1500 >> options=2009 ether 00:e0:81:20:9d:66 inet >> XXX.XXX.XXX.20 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 >> inet XXX.XXX.XXX.21 netmask 0xffffffff broadcast XXX.XXX.XXX.21 inet >> XXX.XXX.XXX.22 netmask 0xffffffff broadcast XXX.XXX.XXX.22 >> inet XXX.XXX.XXX.23 netmask 0xffffffff broadcast XXX.XXX.XXX.23 inet >> XXX.XXX.XXX.24 netmask 0xffffffff broadcast XXX.XXX.XXX.24 >> inet XXX.XXX.XXX.25 netmask 0xffffffff broadcast XXX.XXX.XXX.25 media: >> Ethernet autoselect (100baseTX) >> status: active >> >> >> They're all on the same /24, and as you can see, there is no >> forced media configuration. >> >> I /do/ have an old (pre-kern-build) dmesg.boot for the 8.1/amd64, if >> you (or anyone else) thinks it would help. If the dmesg.boot is >> absolutely required, I'll schedule an opportunity to bounce both of them >> - I'll need to know, tho. >> >> > > Then show me the output of "devinfo -rv" and "pciconf -lcbv". Sorry, my bad. I forgot that there would be a copy of dmesg.boot in /var/run/. dmesg.boot.udns0 = 8.1/amd64 dmesg.boot.udns = 8.0/i386 My mailer is acting up, or I would simply attach them. So in the meantime they can be found here: https://dnswatch.com/_tmp/dmesg.boot.udns0 and here: https://dnswatch.com/_tmp/dmesg.boot.udns Thanks again. --Chris > > >> Thank you again for your thoughtful reply. >> >> >> --Chris >> >> >> >>> >>>> Thank you for all your time and consideration. >>>> >>>> >>>> >>>> --Chris >>>> >>>> >>> _______________________________________________ >>> freebsd-amd64@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >>> To unsubscribe, send any mail to >>> "freebsd-amd64-unsubscribe@freebsd.org" >>> >>> >>> >> >> >> -- >> kern: >> FreeBSD 8.1-RELEASE amd64 >> >> >> >> > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > -- kern: FreeBSD 8.1-RELEASE amd64 From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 09:14:50 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1F2E106566B for ; Tue, 11 Jan 2011 09:14:50 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id 759DB8FC0C for ; Tue, 11 Jan 2011 09:14:50 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0B9Egas010194; Tue, 11 Jan 2011 01:14:48 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Tue, 11 Jan 2011 01:14:49 -0800 (PST) Message-ID: In-Reply-To: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> Date: Tue, 11 Jan 2011 01:14:49 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:14:50 -0000 On Tue, January 11, 2011 1:01 am, fbsdmail@dnswatch.com wrote: > > On Tue, January 11, 2011 12:42 am, Pyun YongHyeon wrote: > >> On Tue, Jan 11, 2011 at 12:28 AM, wrote: >> >> >>> Greetings Pyun YongHyeon, and thank you for your reply. >>> On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: >>> >>> >>>> On Mon, Jan 10, 2011 at 11:10 PM,   wrote: >>>> >>>> >>>> >>>>> Greetings, >>>>> I have been receiving these messages on a recent 8.1/AMD64 >>>>> install. src/ports && world/kern about a week ago. Here is a block >>>>> from the most recent output: nfe0: tx v2 error 0x6204 >>>>> nfe0: tx v2 >>>>> error 0x6204 >> >> [...] >> >> >> >>>>> nfe0: tx v2 error 0x6204 >>>>> >>>>> >>>>> >>>>> >>>>> It appears to only occur when transmitting largish amounts of >>>>> data across an NFS mount. I'm not sure where the MIN-threshold >>>>> lies. But appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a >>>>> largish server farm comprised of 7+ - 8.0 i386 servers. This one >>>>> is the only AMD64. It >>>>> is also the only AMD64. I experience this when mounting an >>>>> 8.0/i386 >>>>> server from this 8.1/AMD64. The i386 also has mounts on this >>>>> 8.1/AMD64. >>>>> relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: >>>>> /usr/obj/usr/src/sys/UDNS01  i386 >>>>> Tyan 2-CPU MB >>>>> 2 NIC's: fxp0 (only one in use) >>>>> ### 8.1/AMD64 >>>>> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 >>>>> MSI K9N4 Ultra >>>>> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz >>>>> K8-class >>>>> CPU) >>>>> 1 NIC nfe0 >>>>> ### common to both: >>>>> rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" >>>>> nfs_server_enable="YES" >>>>> >>>>> NIC's on both boards are 10/100's @100mbps >>>>> >>>>> >>>>> >>>>> >>>>> Can anyone provide any insight as to why I should be receiving >>>>> these messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible >>>>> with earlier versions? >>>>> >>>> >>>> No, I guess you're seeing one of unresolved nfe(4) issues. >>>> By chance, are you using forced media configuration instead of >>>> auto-negotiation? Posting both dmesg and "ifconfig nfe0" output >>>> would be useful. >>> >>> As dmesg(8) goes, I have no dmesg.boot on either box, and bouncing >>> them is not an immediate option. >>> >>> ifconfig nfe0 (the 8.1/amd64) follows: # ifconfig nfe0 nfe0: >>> flags=8843 metric 0 mtu 1500 >>> options=8010b ether >>> 00:19:db:22:74:87 >>> inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 >>> fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 >>> nd6 options=3 media: Ethernet autoselect >>> (100baseTX ) >>> >>> >> >> Does the link partner also agree on the resolved duplex(half-duplex)? >> It's not common to see half-duplex in these days. >> Please make sure link partner is also using auto-negotiation. >> >> > > I thought that odd, as well. Both kerns have as nearly the same options > as is possible. Because the 8.1/amd64 is intended as a replacement for the > 8.0/i386. They're both on the same switch. OK. Sorry, it just occurred to me that they /aren't/ both 10/100's The 8.1/amd64 (nfe0) is 10/100/1000, which might account for the half-dup. Just thought I'd mention it - but I'm sure you already discovered that :P > > >> >>> status: active >>> >>> >>> >>> FWIW ifconfig fxp0 on the 8.0/i386 follows: >>> # ifconfig fxp0 >>> fxp0: flags=8843 metric 0 mtu >>> 1500 >>> options=2009 ether 00:e0:81:20:9d:66 inet >>> XXX.XXX.XXX.20 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 >>> inet XXX.XXX.XXX.21 netmask 0xffffffff broadcast XXX.XXX.XXX.21 inet >>> XXX.XXX.XXX.22 netmask 0xffffffff broadcast XXX.XXX.XXX.22 >>> inet XXX.XXX.XXX.23 netmask 0xffffffff broadcast XXX.XXX.XXX.23 inet >>> XXX.XXX.XXX.24 netmask 0xffffffff broadcast XXX.XXX.XXX.24 >>> inet XXX.XXX.XXX.25 netmask 0xffffffff broadcast XXX.XXX.XXX.25 media: >>> Ethernet autoselect (100baseTX) >>> status: active >>> >>> >>> >>> They're all on the same /24, and as you can see, there is no >>> forced media configuration. >>> >>> I /do/ have an old (pre-kern-build) dmesg.boot for the 8.1/amd64, if >>> you (or anyone else) thinks it would help. If the dmesg.boot is >>> absolutely required, I'll schedule an opportunity to bounce both of >>> them - I'll need to know, tho. >>> >>> >>> >> >> Then show me the output of "devinfo -rv" and "pciconf -lcbv". >> > > Sorry, my bad. I forgot that there would be a copy of dmesg.boot in > /var/run/. > > > dmesg.boot.udns0 = 8.1/amd64 dmesg.boot.udns = 8.0/i386 > > My mailer is acting up, or I would simply attach them. So in the meantime > they can be found here: > > https://dnswatch.com/_tmp/dmesg.boot.udns0 > and here: https://dnswatch.com/_tmp/dmesg.boot.udns > > > Thanks again. > > > --Chris > > >> >> >>> Thank you again for your thoughtful reply. >>> >>> >>> >>> --Chris >>> >>> >>> >>> >>>> >>>>> Thank you for all your time and consideration. >>>>> >>>>> >>>>> >>>>> >>>>> --Chris >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> freebsd-amd64@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >>>> To unsubscribe, send any mail to >>>> "freebsd-amd64-unsubscribe@freebsd.org" >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> kern: >>> FreeBSD 8.1-RELEASE amd64 >>> >>> >>> >>> >>> >> _______________________________________________ >> freebsd-amd64@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 >> To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" >> >> >> > > > -- > kern: > FreeBSD 8.1-RELEASE amd64 > > > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > -- kern: FreeBSD 8.1-RELEASE amd64 From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 18:33:54 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C84106564A for ; Tue, 11 Jan 2011 18:33:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA5A8FC13 for ; Tue, 11 Jan 2011 18:33:54 +0000 (UTC) Received: by pvc22 with SMTP id 22so4245164pvc.13 for ; Tue, 11 Jan 2011 10:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=o2jw5giRQiHzlrogIqY/4ptwWGh0LTa4Y1XKXt1bIT8=; b=eugCOeaOUZKqvynR29kpsXbwU11zm/tuDIdlOCWCFffagWtVO5dVNLi6jYNOaoL7Lf ouQwiwJhlnTyWeJVSVFI4Hzu1rnvyeqNzQ1Hi5EgrVOst1b1OJM4ca567KM4/ODeQ7gM Y6rg2fW8Tdd1GIPjnV87jjiR5CVS58bHK1DpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PYJ15/5I4rRXzD1knTU0ykT3tt6S63yBZnXmSGAQ5n5uH02PtjvZIRNMcj95Meand5 Y94IVGZdMcWMJrkPn6qRyItyheXtjRWdRrLlp7IbcMggQlSwUsUctxxu6KgwxiKmXMtL IGrioNcLCjL6aCLGVdhja7VrEmgPw5DmOGUfU= Received: by 10.142.131.7 with SMTP id e7mr86512wfd.316.1294770833762; Tue, 11 Jan 2011 10:33:53 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w14sm9537471wfd.18.2011.01.11.10.33.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 10:33:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jan 2011 10:33:15 -0800 From: Pyun YongHyeon Date: Tue, 11 Jan 2011 10:33:15 -0800 To: fbsdmail@dnswatch.com Message-ID: <20110111183315.GA6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 18:33:54 -0000 On Tue, Jan 11, 2011 at 01:14:49AM -0800, fbsdmail@dnswatch.com wrote: > > On Tue, January 11, 2011 1:01 am, fbsdmail@dnswatch.com wrote: > > > > > On Tue, January 11, 2011 12:42 am, Pyun YongHyeon wrote: > > > >> On Tue, Jan 11, 2011 at 12:28 AM, wrote: > >> > >> > >>> Greetings Pyun YongHyeon, and thank you for your reply. > >>> On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: > >>> > >>> > >>>> On Mon, Jan 10, 2011 at 11:10 PM, ? wrote: > >>>> > >>>> > >>>> > >>>>> Greetings, > >>>>> I have been receiving these messages on a recent 8.1/AMD64 > >>>>> install. src/ports && world/kern about a week ago. Here is a block > >>>>> from the most recent output: nfe0: tx v2 error 0x6204 > >>>>> nfe0: tx v2 > >>>>> error 0x6204 > >> > >> [...] > >> > >> > >> > >>>>> nfe0: tx v2 error 0x6204 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> It appears to only occur when transmitting largish amounts of > >>>>> data across an NFS mount. I'm not sure where the MIN-threshold > >>>>> lies. But appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a > >>>>> largish server farm comprised of 7+ - 8.0 i386 servers. This one > >>>>> is the only AMD64. It > >>>>> is also the only AMD64. I experience this when mounting an > >>>>> 8.0/i386 > >>>>> server from this 8.1/AMD64. The i386 also has mounts on this > >>>>> 8.1/AMD64. > >>>>> relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: > >>>>> /usr/obj/usr/src/sys/UDNS01 ?i386 > >>>>> Tyan 2-CPU MB > >>>>> 2 NIC's: fxp0 (only one in use) > >>>>> ### 8.1/AMD64 > >>>>> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 > >>>>> MSI K9N4 Ultra > >>>>> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz > >>>>> K8-class > >>>>> CPU) > >>>>> 1 NIC nfe0 > >>>>> ### common to both: > >>>>> rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" > >>>>> nfs_server_enable="YES" > >>>>> > >>>>> NIC's on both boards are 10/100's @100mbps > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Can anyone provide any insight as to why I should be receiving > >>>>> these messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible > >>>>> with earlier versions? > >>>>> > >>>> > >>>> No, I guess you're seeing one of unresolved nfe(4) issues. > >>>> By chance, are you using forced media configuration instead of > >>>> auto-negotiation? Posting both dmesg and "ifconfig nfe0" output > >>>> would be useful. > >>> > >>> As dmesg(8) goes, I have no dmesg.boot on either box, and bouncing > >>> them is not an immediate option. > >>> > >>> ifconfig nfe0 (the 8.1/amd64) follows: # ifconfig nfe0 nfe0: > >>> flags=8843 metric 0 mtu 1500 > >>> options=8010b ether > >>> 00:19:db:22:74:87 > >>> inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 > >>> fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 > >>> nd6 options=3 media: Ethernet autoselect > >>> (100baseTX ) > >>> > >>> > >> > >> Does the link partner also agree on the resolved duplex(half-duplex)? > >> It's not common to see half-duplex in these days. > >> Please make sure link partner is also using auto-negotiation. > >> > >> > > > > I thought that odd, as well. Both kerns have as nearly the same options > > as is possible. Because the 8.1/amd64 is intended as a replacement for the > > 8.0/i386. They're both on the same switch. > > OK. Sorry, it just occurred to me that they /aren't/ both 10/100's > The 8.1/amd64 (nfe0) is 10/100/1000, which might account for the half-dup. > Just thought I'd mention it - but I'm sure you already discovered that :P > I don't know any auto-negotiation issues of ciphy(4) so please verify whether the switch sees the same resolved speed/duplex. If you manually configured switch port to use 100Mbps/full-duplex it would create problems since resolved duplex for the parallel detection is normally half-duplex. This will cause duplex mismatch and you will see lots of unexpected problems. If both parties use the same forced media configuration in 10/100Mbps mode it would work but nfe(4) has one unresolved issue for that case(mainly due to lack of documentation). Without auto-negotiation, some nfe(4) controllers do not work correctly. nfe(4) also supports hardware MAC counters for supported controllers and I think your controller supports that. See what counters you have with "sysctl dev.nfe.0.stats". From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 00:16:46 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E990D1065670 for ; Wed, 12 Jan 2011 00:16:46 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id AC5068FC15 for ; Wed, 12 Jan 2011 00:16:46 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0C0GcqH013798; Tue, 11 Jan 2011 16:16:44 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Tue, 11 Jan 2011 16:16:45 -0800 (PST) Message-ID: <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> In-Reply-To: <20110111183315.GA6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> <20110111183315.GA6278@michelle.cdnetworks.com> Date: Tue, 11 Jan 2011 16:16:45 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 00:16:47 -0000 On Tue, January 11, 2011 10:33 am, Pyun YongHyeon wrote: > On Tue, Jan 11, 2011 at 01:14:49AM -0800, fbsdmail@dnswatch.com wrote: > >> >> On Tue, January 11, 2011 1:01 am, fbsdmail@dnswatch.com wrote: >> >>> >> >>> On Tue, January 11, 2011 12:42 am, Pyun YongHyeon wrote: >>> >>> >>>> On Tue, Jan 11, 2011 at 12:28 AM, wrote: >>>> >>>> >>>> >>>>> Greetings Pyun YongHyeon, and thank you for your reply. >>>>> On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: >>>>> >>>>> >>>>> >>>>>> On Mon, Jan 10, 2011 at 11:10 PM, ? >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Greetings, >>>>>>> I have been receiving these messages on a recent 8.1/AMD64 >>>>>>> install. src/ports && world/kern about a week ago. Here is a >>>>>>> block from the most recent output: nfe0: tx v2 error >>>>>>> 0x6204 >>>>>>> nfe0: tx v2 >>>>>>> error 0x6204 >>>> >>>> [...] >>>> >>>> >>>> >>>> >>>>>>> nfe0: tx v2 error 0x6204 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It appears to only occur when transmitting largish amounts of >>>>>>> data across an NFS mount. I'm not sure where the >>>>>>> MIN-threshold >>>>>>> lies. But appears to be >=1.5Mb. This fresh 8.1/AMD64 is part >>>>>>> of a largish server farm comprised of 7+ - 8.0 i386 servers. >>>>>>> This one >>>>>>> is the only AMD64. It is also the only AMD64. I experience this >>>>>>> when mounting an 8.0/i386 >>>>>>> server from this 8.1/AMD64. The i386 also has mounts on this >>>>>>> 8.1/AMD64. >>>>>>> relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: >>>>>>> /usr/obj/usr/src/sys/UDNS01 ?i386 >>>>>>> Tyan 2-CPU MB >>>>>>> 2 NIC's: fxp0 (only one in use) >>>>>>> ### 8.1/AMD64 >>>>>>> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 >>>>>>> MSI K9N4 Ultra >>>>>>> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ >>>>>>> (3511.34-MHz >>>>>>> K8-class >>>>>>> CPU) >>>>>>> 1 NIC nfe0 >>>>>>> ### common to both: >>>>>>> rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" >>>>>>> nfs_server_enable="YES" >>>>>>> >>>>>>> NIC's on both boards are 10/100's @100mbps >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can anyone provide any insight as to why I should be >>>>>>> receiving these messages on a fresh 8.1/amd64 install. Is 8.1 >>>>>>> INcompatible >>>>>>> with earlier versions? >>>>>>> >>>>>> >>>>>> No, I guess you're seeing one of unresolved nfe(4) issues. >>>>>> By chance, are you using forced media configuration instead of >>>>>> auto-negotiation? Posting both dmesg and "ifconfig nfe0" output >>>>>> would be useful. >>>>> >>>>> As dmesg(8) goes, I have no dmesg.boot on either box, and >>>>> bouncing them is not an immediate option. >>>>> >>>>> ifconfig nfe0 (the 8.1/amd64) follows: # ifconfig nfe0 nfe0: >>>>> flags=8843 metric 0 mtu >>>>> 1500 >>>>> options=8010b ether >>>>> 00:19:db:22:74:87 >>>>> inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 >>>>> inet6 fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 >>>>> nd6 options=3 media: Ethernet autoselect >>>>> (100baseTX ) >>>>> >>>>> >>>>> >>>> >>>> Does the link partner also agree on the resolved >>>> duplex(half-duplex)? It's not common to see half-duplex in these >>>> days. Please make sure link partner is also using auto-negotiation. >>>> >>>> >>>> >>> >>> I thought that odd, as well. Both kerns have as nearly the same >>> options as is possible. Because the 8.1/amd64 is intended as a >>> replacement for the 8.0/i386. They're both on the same switch. >>> >> >> OK. Sorry, it just occurred to me that they /aren't/ both 10/100's >> The 8.1/amd64 (nfe0) is 10/100/1000, which might account for the >> half-dup. Just thought I'd mention it - but I'm sure you already >> discovered that :P >> > > I don't know any auto-negotiation issues of ciphy(4) so please > verify whether the switch sees the same resolved speed/duplex. If you > manually configured switch port to use 100Mbps/full-duplex it would create > problems since resolved duplex for the parallel detection is normally > half-duplex. This will cause duplex mismatch and you will see lots of > unexpected problems. If both parties use the same forced media > configuration in 10/100Mbps mode it would work but nfe(4) has one > unresolved issue for that case(mainly due to lack of documentation). > Without > auto-negotiation, some nfe(4) controllers do not work correctly. > > nfe(4) also supports hardware MAC counters for supported controllers and I > think your controller supports that. See what counters you have with > "sysctl dev.nfe.0.stats". I'm going to be away for a couple of hours. Here's a dump of sysctl dev.nfe.0.stats, in the meantime: dev.nfe.0.stats.rx.frame_errors: 0 dev.nfe.0.stats.rx.extra_bytes: 0 dev.nfe.0.stats.rx.late_cols: 0 dev.nfe.0.stats.rx.runts: 0 dev.nfe.0.stats.rx.jumbos: 0 dev.nfe.0.stats.rx.fifo_overuns: 0 dev.nfe.0.stats.rx.crc_errors: 0 dev.nfe.0.stats.rx.fae: 0 dev.nfe.0.stats.rx.len_errors: 0 dev.nfe.0.stats.rx.unicast: 711887 dev.nfe.0.stats.rx.multicast: 0 dev.nfe.0.stats.rx.broadcast: 36072 dev.nfe.0.stats.tx.octets: 400617598 dev.nfe.0.stats.tx.zero_rexmits: 420611 dev.nfe.0.stats.tx.one_rexmits: 171560 dev.nfe.0.stats.tx.multi_rexmits: 64390 dev.nfe.0.stats.tx.late_cols: 0 dev.nfe.0.stats.tx.fifo_underuns: 0 dev.nfe.0.stats.tx.carrier_losts: 0 dev.nfe.0.stats.tx.excess_deferrals: 0 dev.nfe.0.stats.tx.retry_errors: 182 Thank you for all your time and consideration Pyun YongHyeon. --Chris > > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > -- kern: FreeBSD 8.1-RELEASE amd64 From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 00:28:28 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCE65106564A for ; Wed, 12 Jan 2011 00:28:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 40AB48FC0C for ; Wed, 12 Jan 2011 00:28:27 +0000 (UTC) Received: by iwn39 with SMTP id 39so15854iwn.13 for ; Tue, 11 Jan 2011 16:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=VhKxXWup0YH3TWSTxhXmXBIBvfBZoikTonbxsJRONm8=; b=aBiZBJNuzFBw+h1zl4fyBaI2gSgRpv+R7mvL6/pW+a8ZJMKuqAZAGMV9OoEmQPkuY9 KwRDbPxR3Z+fh+nzThh1XgM9OnGXrp+w0CbM5YGXxQANYrWMguYpvRYuJhFfjHwrv1Oc Sf4yE/mBSERj7O2XB0blUd3Du2cPZjgd5egvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=XZH/H6kflcpABmOllNOLIk2oZDyKR1481Y5hTFXt37NUqmhOp0jO4fzvM5PChPsE5C sQn4D8Jj2he9LE+IlqScunXdD7avjhS57fjHWrd6F9foQ3IA4YJkUAmwXQJfBjipn2yd pG0y2mIbiCWNRqp+n0qDEPl/Jh7QG1LAFHWUs= Received: by 10.231.36.137 with SMTP id t9mr259438ibd.195.1294792107632; Tue, 11 Jan 2011 16:28:27 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id i16sm56613ibl.6.2011.01.11.16.28.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 16:28:26 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jan 2011 16:27:51 -0800 From: Pyun YongHyeon Date: Tue, 11 Jan 2011 16:27:51 -0800 To: fbsdmail@dnswatch.com Message-ID: <20110112002751.GE6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> <20110111183315.GA6278@michelle.cdnetworks.com> <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 00:28:28 -0000 On Tue, Jan 11, 2011 at 04:16:45PM -0800, fbsdmail@dnswatch.com wrote: > > On Tue, January 11, 2011 10:33 am, Pyun YongHyeon wrote: [...] > >>>> Does the link partner also agree on the resolved > >>>> duplex(half-duplex)? It's not common to see half-duplex in these > >>>> days. Please make sure link partner is also using auto-negotiation. > >>>> > >>>> > >>>> > >>> > >>> I thought that odd, as well. Both kerns have as nearly the same > >>> options as is possible. Because the 8.1/amd64 is intended as a > >>> replacement for the 8.0/i386. They're both on the same switch. > >>> > >> > >> OK. Sorry, it just occurred to me that they /aren't/ both 10/100's > >> The 8.1/amd64 (nfe0) is 10/100/1000, which might account for the > >> half-dup. Just thought I'd mention it - but I'm sure you already > >> discovered that :P > >> > > > > I don't know any auto-negotiation issues of ciphy(4) so please > > verify whether the switch sees the same resolved speed/duplex. If you > > manually configured switch port to use 100Mbps/full-duplex it would create > > problems since resolved duplex for the parallel detection is normally > > half-duplex. This will cause duplex mismatch and you will see lots of > > unexpected problems. If both parties use the same forced media > > configuration in 10/100Mbps mode it would work but nfe(4) has one > > unresolved issue for that case(mainly due to lack of documentation). > > Without > > auto-negotiation, some nfe(4) controllers do not work correctly. > > > > nfe(4) also supports hardware MAC counters for supported controllers and I > > think your controller supports that. See what counters you have with > > "sysctl dev.nfe.0.stats". > I'm going to be away for a couple of hours. > Here's a dump of sysctl dev.nfe.0.stats, in the meantime: > > dev.nfe.0.stats.rx.frame_errors: 0 > dev.nfe.0.stats.rx.extra_bytes: 0 > dev.nfe.0.stats.rx.late_cols: 0 > dev.nfe.0.stats.rx.runts: 0 > dev.nfe.0.stats.rx.jumbos: 0 > dev.nfe.0.stats.rx.fifo_overuns: 0 > dev.nfe.0.stats.rx.crc_errors: 0 > dev.nfe.0.stats.rx.fae: 0 > dev.nfe.0.stats.rx.len_errors: 0 > dev.nfe.0.stats.rx.unicast: 711887 > dev.nfe.0.stats.rx.multicast: 0 > dev.nfe.0.stats.rx.broadcast: 36072 > dev.nfe.0.stats.tx.octets: 400617598 > dev.nfe.0.stats.tx.zero_rexmits: 420611 > dev.nfe.0.stats.tx.one_rexmits: 171560 > dev.nfe.0.stats.tx.multi_rexmits: 64390 Two counters above clearly indicates there are collisions in link. Check switch configuration and make it use auto-negotiation. > dev.nfe.0.stats.tx.late_cols: 0 > dev.nfe.0.stats.tx.fifo_underuns: 0 > dev.nfe.0.stats.tx.carrier_losts: 0 > dev.nfe.0.stats.tx.excess_deferrals: 0 > dev.nfe.0.stats.tx.retry_errors: 182 > > Thank you for all your time and consideration Pyun YongHyeon. > > --Chris From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 07:01:18 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4650E106566C for ; Wed, 12 Jan 2011 07:01:18 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id E59488FC14 for ; Wed, 12 Jan 2011 07:01:17 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0C719u3014831; Tue, 11 Jan 2011 23:01:15 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Tue, 11 Jan 2011 23:01:16 -0800 (PST) Message-ID: In-Reply-To: <20110112002751.GE6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> <20110111183315.GA6278@michelle.cdnetworks.com> <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> <20110112002751.GE6278@michelle.cdnetworks.com> Date: Tue, 11 Jan 2011 23:01:16 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 07:01:18 -0000 Greetings Pyun YongHyeon, and thank you for your reply. On Tue, January 11, 2011 4:27 pm, Pyun YongHyeon wrote: > On Tue, Jan 11, 2011 at 04:16:45PM -0800, fbsdmail@dnswatch.com wrote: > >> >> On Tue, January 11, 2011 10:33 am, Pyun YongHyeon wrote: >> > > [...] > > >>>>>> Does the link partner also agree on the resolved >>>>>> duplex(half-duplex)? It's not common to see half-duplex in these >>>>>> days. Please make sure link partner is also using >>>>>> auto-negotiation. >>>>>> >>>>>> >>>>>> >>>>> >>>>> I thought that odd, as well. Both kerns have as nearly the same >>>>> options as is possible. Because the 8.1/amd64 is intended as a >>>>> replacement for the 8.0/i386. They're both on the same switch. >>>>> >>>> >>>> OK. Sorry, it just occurred to me that they /aren't/ both 10/100's >>>> The 8.1/amd64 (nfe0) is 10/100/1000, which might account for the >>>> half-dup. Just thought I'd mention it - but I'm sure you already >>>> discovered that :P >>>> >>> >>> I don't know any auto-negotiation issues of ciphy(4) so please >>> verify whether the switch sees the same resolved speed/duplex. If you >>> manually configured switch port to use 100Mbps/full-duplex it would >>> create problems since resolved duplex for the parallel detection is >>> normally half-duplex. This will cause duplex mismatch and you will see >>> lots of unexpected problems. If both parties use the same forced media >>> configuration in 10/100Mbps mode it would work but nfe(4) has one >>> unresolved issue for that case(mainly due to lack of documentation). >>> Without >>> auto-negotiation, some nfe(4) controllers do not work correctly. >>> >>> nfe(4) also supports hardware MAC counters for supported controllers >>> and I think your controller supports that. See what counters you have >>> with "sysctl dev.nfe.0.stats". >>> >> I'm going to be away for a couple of hours. >> Here's a dump of sysctl dev.nfe.0.stats, in the meantime: >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> dev.nfe.0.stats.rx.extra_bytes: 0 >> dev.nfe.0.stats.rx.late_cols: 0 >> dev.nfe.0.stats.rx.runts: 0 >> dev.nfe.0.stats.rx.jumbos: 0 >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> dev.nfe.0.stats.rx.crc_errors: 0 >> dev.nfe.0.stats.rx.fae: 0 >> dev.nfe.0.stats.rx.len_errors: 0 >> dev.nfe.0.stats.rx.unicast: 711887 >> dev.nfe.0.stats.rx.multicast: 0 >> dev.nfe.0.stats.rx.broadcast: 36072 >> dev.nfe.0.stats.tx.octets: 400617598 >> dev.nfe.0.stats.tx.zero_rexmits: 420611 >> dev.nfe.0.stats.tx.one_rexmits: 171560 >> dev.nfe.0.stats.tx.multi_rexmits: 64390 >> > > Two counters above clearly indicates there are collisions in link. > Check switch configuration and make it use auto-negotiation. Closer examination of the switch seems to indicate one of the ports is flaky (the nfe0 port). Well, that's good enough for me - this switch is going to go to the recycling depot, and I'm going to purchase a new one tomorrow. I'll report back as to whether the errors stop with the use of the new switch. Thank you very much Pyun YongHyeon for all your time and consideration. --Chris > > >> dev.nfe.0.stats.tx.late_cols: 0 >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> dev.nfe.0.stats.tx.carrier_losts: 0 >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> dev.nfe.0.stats.tx.retry_errors: 182 >> >> >> Thank you for all your time and consideration Pyun YongHyeon. >> >> >> --Chris >> > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > -- kern: FreeBSD 8.1-RELEASE amd64 From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 18:20:08 2011 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3BA01065670 for ; Wed, 12 Jan 2011 18:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 85F2A8FC18 for ; Wed, 12 Jan 2011 18:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0CIK8kn022537 for ; Wed, 12 Jan 2011 18:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0CIK8ZC022536; Wed, 12 Jan 2011 18:20:08 GMT (envelope-from gnats) Resent-Date: Wed, 12 Jan 2011 18:20:08 GMT Resent-Message-Id: <201101121820.p0CIK8ZC022536@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Sebastian Chmielewski Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24671065670 for ; Wed, 12 Jan 2011 18:16:02 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id A10858FC15 for ; Wed, 12 Jan 2011 18:16:02 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p0CIG21H070694 for ; Wed, 12 Jan 2011 18:16:02 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p0CIG2L7070693; Wed, 12 Jan 2011 18:16:02 GMT (envelope-from nobody) Message-Id: <201101121816.p0CIG2L7070693@red.freebsd.org> Date: Wed, 12 Jan 2011 18:16:02 GMT From: Sebastian Chmielewski To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Wed, 12 Jan 2011 18:42:07 +0000 Cc: Subject: amd64/153935: system hangs while trying to do 'shutdown -h now' after resuming from ACPI suspend X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:20:08 -0000 >Number: 153935 >Category: amd64 >Synopsis: system hangs while trying to do 'shutdown -h now' after resuming from ACPI suspend >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jan 12 18:20:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Sebastian Chmielewski >Release: 8.0-RELEASE, 8.1-RELEASE, 8.2-PRERELEASE (-stable) >Organization: >Environment: FreeBSD chulak.pl 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Tue Jan 11 19:41:19 CET 2011 root@chulak.pl:/disk0/obj/usr/src/sys/LAPTOP amd64 T5500 Dual Core 2 CPU (ASUS F3F Laptop) >Description: Systems hangs displaying message: The operating system has halted. Please press any key to reboot. Rebooting... cpu_reset: Stopping other CPUs when shutdown -h now is used to switch off the system after resuming from ACPI suspend. I've tried to debug this issue but setting break at 'generic_stop_cpus' by using gdb seems to be impossible: cpu_reset: Stopping other CPUs Fatal double fault rip = 0xffffffff803e7cf0 rsp = 0xffffff8000023018 rbp = 0xffffff8000023050 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff803dd2be at kdb_backtrace+0x5e #1 0xffffffff803a97d7 at panic+0x187 #2 0xffffffff80645694 at dblfault_handler+0xa4 #3 0xffffffff8062d7ed at Xdblfault+0xad KDB: enter: panic System does not hang when 'Poweroff' button is pressed (except the case when pressing the button is not working, this is why 'shutdown -h now' is used) >How-To-Repeat: - power on - use command 'zzz' or Fn+F1 hotkey to suspend the system - resume - use command 'shutdown -h now' - system hangs with message posted above >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 19:40:08 2011 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169EC10656E8 for ; Wed, 12 Jan 2011 19:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CDBC48FC16 for ; Wed, 12 Jan 2011 19:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0CJe7ve010865 for ; Wed, 12 Jan 2011 19:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0CJe7TZ010863; Wed, 12 Jan 2011 19:40:07 GMT (envelope-from gnats) Resent-Date: Wed, 12 Jan 2011 19:40:07 GMT Resent-Message-Id: <201101121940.p0CJe7TZ010863@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, sergio lenzi Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C3571065670 for ; Wed, 12 Jan 2011 19:37:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 0B3178FC19 for ; Wed, 12 Jan 2011 19:37:26 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p0CJbP0v024643 for ; Wed, 12 Jan 2011 19:37:25 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p0CJbPdZ024642; Wed, 12 Jan 2011 19:37:25 GMT (envelope-from nobody) Message-Id: <201101121937.p0CJbPdZ024642@red.freebsd.org> Date: Wed, 12 Jan 2011 19:37:25 GMT From: sergio lenzi To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Wed, 12 Jan 2011 20:10:55 +0000 Cc: Subject: amd64/153937: ralink (if_ral) panics the sistem (amd64 freeBSDd 8.X) when in hostap or adhoc. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 19:40:08 -0000 >Number: 153937 >Category: amd64 >Synopsis: ralink (if_ral) panics the sistem (amd64 freeBSDd 8.X) when in hostap or adhoc. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jan 12 19:40:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: sergio lenzi >Release: 8.1, 8.2, 9.0 >Organization: k1 sistemas >Environment: FreeBSD dist.lenzicasa 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Wed Jan 12 14:20:09 BRST 2011 lzt@dist.lenzicasa:/usr/src/sys/amd64/compile/server amd64 >Description: trying to put if_ral (and so wlan) to work in ap mode, when the interface goes up and with an IP number, the sistem panics. due to the ral driver does not initialize the ratectl struture neede by wlan_amrr when in mode not client. A fix follows (must be auditted) by the gurus... >How-To-Repeat: kldload if_ral ifconfig wlan create wlandev ral0 \ wlanmode hostap \ mode 11g ifconfig wlan0 192.168.1.1 ============================ the system panics >Fix: --- sys/dev/ral/rt2560.c.orig 2011-01-12 17:05:23.000000000 -0200 +++ sys/dev/ral/rt2560.c 2011-01-12 17:05:36.000000000 -0200 @@ -786,6 +786,7 @@ struct ieee80211_node *ni = vap->iv_bss; struct mbuf *m; + ieee80211_ratectl_node_init(ni); if (vap->iv_opmode != IEEE80211_M_MONITOR) { rt2560_update_plcp(sc); rt2560_set_basicrates(sc); --- sys/dev/ral/rt2661.c.orig 2011-01-12 17:06:11.000000000 -0200 +++ sys/dev/ral/rt2661.c 2011-01-12 17:06:17.000000000 -0200 @@ -792,6 +792,7 @@ if (error == 0 && nstate == IEEE80211_S_RUN) { struct ieee80211_node *ni = vap->iv_bss; + ieee80211_ratectl_node_init(ni); if (vap->iv_opmode != IEEE80211_M_MONITOR) { rt2661_enable_mrr(sc); rt2661_set_txpreamble(sc); >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 22:25:01 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2552210656A4; Wed, 12 Jan 2011 22:25:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BEE038FC12; Wed, 12 Jan 2011 22:25:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p0CMP0Pr089986; Wed, 12 Jan 2011 17:25:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p0CMP0Ct089976; Wed, 12 Jan 2011 22:25:00 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 12 Jan 2011 22:25:00 GMT Message-Id: <201101122225.p0CMP0Ct089976@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 22:25:01 -0000 TB --- 2011-01-12 22:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-12 22:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-12 22:00:00 - cleaning the object tree TB --- 2011-01-12 22:00:29 - cvsupping the source tree TB --- 2011-01-12 22:00:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-12 22:00:43 - building world TB --- 2011-01-12 22:00:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-12 22:00:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-12 22:00:43 - TARGET=amd64 TB --- 2011-01-12 22:00:43 - TARGET_ARCH=amd64 TB --- 2011-01-12 22:00:43 - TZ=UTC TB --- 2011-01-12 22:00:43 - __MAKE_CONF=/dev/null TB --- 2011-01-12 22:00:43 - cd /src TB --- 2011-01-12 22:00:43 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 12 22:00:46 UTC 2011 >>> 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 [...] /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:678: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:682: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:684: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:686: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:689: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:691: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:694: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:698: error: expected ')' before '(' token *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-12 22:25:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-12 22:25:00 - ERROR: failed to build world TB --- 2011-01-12 22:25:00 - 1122.29 user 252.47 system 1499.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 23:34:04 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 260D3106566B; Wed, 12 Jan 2011 23:34:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C33258FC1A; Wed, 12 Jan 2011 23:34:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p0CNY3u5081791; Wed, 12 Jan 2011 18:34:03 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p0CNY32o081782; Wed, 12 Jan 2011 23:34:03 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 12 Jan 2011 23:34:03 GMT Message-Id: <201101122334.p0CNY32o081782@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 23:34:04 -0000 TB --- 2011-01-12 23:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-12 23:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-12 23:10:00 - cleaning the object tree TB --- 2011-01-12 23:10:04 - cvsupping the source tree TB --- 2011-01-12 23:10:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-12 23:10:20 - building world TB --- 2011-01-12 23:10:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-12 23:10:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-12 23:10:20 - TARGET=amd64 TB --- 2011-01-12 23:10:20 - TARGET_ARCH=amd64 TB --- 2011-01-12 23:10:20 - TZ=UTC TB --- 2011-01-12 23:10:20 - __MAKE_CONF=/dev/null TB --- 2011-01-12 23:10:20 - cd /src TB --- 2011-01-12 23:10:20 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 12 23:10:20 UTC 2011 >>> 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 [...] /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:678: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:682: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:684: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:686: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:689: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:691: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:694: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:698: error: expected ')' before '(' token *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-12 23:34:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-12 23:34:03 - ERROR: failed to build world TB --- 2011-01-12 23:34:03 - 1115.60 user 238.19 system 1442.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 13 00:39:10 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36616106567A; Thu, 13 Jan 2011 00:39:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CAC188FC1C; Thu, 13 Jan 2011 00:39:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p0D0d9xs087266; Wed, 12 Jan 2011 19:39:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p0D0d9MH087254; Thu, 13 Jan 2011 00:39:09 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 13 Jan 2011 00:39:09 GMT Message-Id: <201101130039.p0D0d9MH087254@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:39:10 -0000 TB --- 2011-01-13 00:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-13 00:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-13 00:15:00 - cleaning the object tree TB --- 2011-01-13 00:15:04 - cvsupping the source tree TB --- 2011-01-13 00:15:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-13 00:15:16 - building world TB --- 2011-01-13 00:15:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-13 00:15:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-13 00:15:16 - TARGET=amd64 TB --- 2011-01-13 00:15:16 - TARGET_ARCH=amd64 TB --- 2011-01-13 00:15:16 - TZ=UTC TB --- 2011-01-13 00:15:16 - __MAKE_CONF=/dev/null TB --- 2011-01-13 00:15:16 - cd /src TB --- 2011-01-13 00:15:16 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 13 00:15:18 UTC 2011 >>> 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 [...] /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:678: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:682: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:684: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:686: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:689: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:691: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:694: error: expected ')' before '(' token /src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:698: error: expected ')' before '(' token *** Error code 1 Stop in /src/cddl/lib/libzpool. *** Error code 1 Stop in /src/cddl/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-13 00:39:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-13 00:39:09 - ERROR: failed to build world TB --- 2011-01-13 00:39:09 - 1115.74 user 239.64 system 1448.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 13 10:07:22 2011 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB8F1065693; Thu, 13 Jan 2011 10:07:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C13B48FC1A; Thu, 13 Jan 2011 10:07:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0DA7Mdi098306; Thu, 13 Jan 2011 10:07:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0DA7Mx9098302; Thu, 13 Jan 2011 10:07:22 GMT (envelope-from linimon) Date: Thu, 13 Jan 2011 10:07:22 GMT Message-Id: <201101131007.p0DA7Mx9098302@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153937: [ral] ralink panics the system (amd64 freeBSDD 8.X) when in hostap or adhoc. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 10:07:23 -0000 Old Synopsis: ralink (if_ral) panics the sistem (amd64 freeBSDd 8.X) when in hostap or adhoc. New Synopsis: [ral] ralink panics the system (amd64 freeBSDD 8.X) when in hostap or adhoc. Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 13 10:06:50 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153937 From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 15 03:33:58 2011 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C31AB106566B; Sat, 15 Jan 2011 03:33:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 938CA8FC0A; Sat, 15 Jan 2011 03:33:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p0F3Xv4o053751; Fri, 14 Jan 2011 22:33:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p0F3Xva9053724; Sat, 15 Jan 2011 03:33:57 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 15 Jan 2011 03:33:57 GMT Message-Id: <201101150333.p0F3Xva9053724@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 03:33:59 -0000 TB --- 2011-01-15 01:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-01-15 01:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-01-15 01:10:00 - cleaning the object tree TB --- 2011-01-15 01:10:26 - cvsupping the source tree TB --- 2011-01-15 01:10:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-01-15 01:10:38 - building world TB --- 2011-01-15 01:10:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 01:10:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 01:10:38 - TARGET=amd64 TB --- 2011-01-15 01:10:38 - TARGET_ARCH=amd64 TB --- 2011-01-15 01:10:38 - TZ=UTC TB --- 2011-01-15 01:10:38 - __MAKE_CONF=/dev/null TB --- 2011-01-15 01:10:38 - cd /src TB --- 2011-01-15 01:10:38 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 15 01:10:42 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jan 15 03:19:32 UTC 2011 TB --- 2011-01-15 03:19:32 - generating LINT kernel config TB --- 2011-01-15 03:19:32 - cd /src/sys/amd64/conf TB --- 2011-01-15 03:19:32 - /usr/bin/make -B LINT TB --- 2011-01-15 03:19:32 - building LINT kernel TB --- 2011-01-15 03:19:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-01-15 03:19:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-01-15 03:19:32 - TARGET=amd64 TB --- 2011-01-15 03:19:32 - TARGET_ARCH=amd64 TB --- 2011-01-15 03:19:32 - TZ=UTC TB --- 2011-01-15 03:19:32 - __MAKE_CONF=/dev/null TB --- 2011-01-15 03:19:32 - cd /src TB --- 2011-01-15 03:19:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 15 03:19:32 UTC 2011 >>> 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 [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel nfs_nfsdkrpc.o(.text+0x49): In function `nfsrvd_init': : undefined reference to `nfsd_master_proc' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-01-15 03:33:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-01-15 03:33:57 - ERROR: failed to build lint kernel TB --- 2011-01-15 03:33:57 - 6889.09 user 1193.27 system 8636.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full