From owner-freebsd-amd64@FreeBSD.ORG Sun Dec 7 09:00:05 2008 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 804631065673 for ; Sun, 7 Dec 2008 09:00:05 +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 620A98FC13 for ; Sun, 7 Dec 2008 09:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB7905BV071907 for ; Sun, 7 Dec 2008 09:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB7905Ia071906; Sun, 7 Dec 2008 09:00:05 GMT (envelope-from gnats) Date: Sun, 7 Dec 2008 09:00:05 GMT Message-Id: <200812070900.mB7905Ia071906@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kumar Krishnamoorthy X-Mailman-Approved-At: Sun, 07 Dec 2008 12:38:03 +0000 Cc: Subject: Re: amd64/128978: [install] FreeBSD 6.3 64-bit panics at boot time during installation on HP DL580 G5 with 128GB physical memory X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kumar Krishnamoorthy List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2008 09:00:05 -0000 The following reply was made to PR amd64/128978; it has been noted by GNATS. From: Kumar Krishnamoorthy To: "bug-followup@FreeBSD.org" , Kumar Krishnamoorthy Cc: Subject: Re: amd64/128978: [install] FreeBSD 6.3 64-bit panics at boot time during installation on HP DL580 G5 with 128GB physical memory Date: Sun, 7 Dec 2008 00:50:55 -0800 --_000_7A7D327E99D30143AC98BDABFCABFF012271549D65PAEXMBX04vmwa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is from freeBSD6.4 64 GA SMAP type=3D01 base=3D0000000000000000 len 000000000009f800 SMAP type=3D02 base=3D000000000009f800 len 0000000000000800 SMAP type=3D02 base=3D00000000000ca000 len 0000000000002000 SMAP type=3D02 base=3D00000000000dc000 len 0000000000004000 SMAP type=3D02 base=3D00000000000e4000 len 000000000001c000 SMAP type=3D01 base=3D0000000000100000 len 00000000bfdf0000 SMAP type=3D03 base=3D00000000bfef0000 len 000000000000f000 SMAP type=3D04 base=3D00000000bfeff000 len 0000000000001000 SMAP type=3D01 base=3D00000000bff00000 len 0000000000100000 SMAP type=3D02 base=3D00000000e0000000 len 0000000010000000 SMAP type=3D02 base=3D00000000fec00000 len 0000000000010000 SMAP type=3D02 base=3D00000000fee00000 len 0000000000001000 SMAP type=3D02 base=3D00000000fffe0000 len 0000000000020000 SMAP type=3D01 base=3D0000000100000000 len 0000001f40000000 I could not reproduce this on freeBSD7.0 GA. It boots well without any issu= es. -Kumar --_000_7A7D327E99D30143AC98BDABFCABFF012271549D65PAEXMBX04vmwa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is f= rom=20 freeBSD6.4 64 GA
SMAP type= =3D01=20 base=3D0000000000000000   len 000000000009f800
SMAP type= =3D02=20 base=3D000000000009f800    len 0000000000000800
SMAP type= =3D02=20 base=3D00000000000ca000   len 0000000000002000
SMAP type=3D02=20 base=3D00000000000dc000   len=20 0000000000004000
SMAP type=3D02=20 base=3D00000000000e4000   len=20 000000000001c000
SMAP type=3D01=20 base=3D0000000000100000   len=20 00000000bfdf0000
SMAP type=3D03=20 base=3D00000000bfef0000     len=20 000000000000f000
SMAP type=3D04=20 base=3D00000000bfeff000      len=20 0000000000001000
SMAP type=3D01=20 base=3D00000000bff00000     len=20 0000000000100000
SMAP type=3D02=20 base=3D00000000e0000000   len=20 0000000010000000
SMAP type=3D02=20 base=3D00000000fec00000    len=20 0000000000010000
SMAP type=3D02=20 base=3D00000000fee00000    len=20 0000000000001000
SMAP type=3D02=20 base=3D00000000fffe0000      len=20 0000000000020000
SMAP type=3D01=20 base=3D0000000100000000   len=20 0000001f40000000
 
I could not reproduce this on freeBSD7.0 GA. It = boots=20 well without any issues.
 
-Kumar
<= /SPAN>
--_000_7A7D327E99D30143AC98BDABFCABFF012271549D65PAEXMBX04vmwa_-- From owner-freebsd-amd64@FreeBSD.ORG Sun Dec 7 22:30:01 2008 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 6FA081065672 for ; Sun, 7 Dec 2008 22:30:01 +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 4BD148FC1B for ; Sun, 7 Dec 2008 22:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB7MU0Pp003934 for ; Sun, 7 Dec 2008 22:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB7MU055003933; Sun, 7 Dec 2008 22:30:00 GMT (envelope-from gnats) Resent-Date: Sun, 7 Dec 2008 22:30:00 GMT Resent-Message-Id: <200812072230.mB7MU055003933@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, Eric Sabban Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D3C6106564A for ; Sun, 7 Dec 2008 22:21:08 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5888FC24 for ; Sun, 7 Dec 2008 22:21:08 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mB7ML7SH016043 for ; Sun, 7 Dec 2008 22:21:07 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mB7ML7Br016042; Sun, 7 Dec 2008 22:21:07 GMT (envelope-from nobody) Message-Id: <200812072221.mB7ML7Br016042@www.freebsd.org> Date: Sun, 7 Dec 2008 22:21:07 GMT From: Eric Sabban To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Sun, 07 Dec 2008 22:57:51 +0000 Cc: Subject: amd64/129488: Kernel "bug" when using smbfs in smbfs_smb.c: kernel: bug: ecnt = 1, but m_len = 0 and m_next = 0 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: Sun, 07 Dec 2008 22:30:01 -0000 >Number: 129488 >Category: amd64 >Synopsis: Kernel "bug" when using smbfs in smbfs_smb.c: kernel: bug: ecnt = 1, but m_len = 0 and m_next = 0 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Dec 07 22:30:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Eric Sabban >Release: 7.0-RELEASE-p7 >Organization: none >Environment: FreeBSD sekret.lame.net 7.0-RELEASE-p6 FreeBSD 7.0-RELEASE-p6 #3: Thu Dec 4 21:48:54 PST 2008 root@sekret.lame.net:/usr/obj/usr/src/sys/SEKRET amd64 >Description: Shortly after booting the fileserver (leopard g5) and the smb client (freebsd 7.0p6) I mounted two disks over smb (mount //eric@g5/blah) from the server. I did an awful thing, just for the sake of it: for i in *.avi; do file=`echo ${i} | sed -e 's/.avi$//'`; ffmpeg -i "${file}.avi" "/usr/tmp/${file}.mp4" > /tmp/ffmpeg.$$ 2>&1 & done Ugly as that may have been, the kernel then spit out: smb_iod_recvall: drop resp with mid 4526 smb_iod_recvall: drop resp with mid 4527 smb_iod_recvall: drop resp with mid 4528 smb_iod_recvall: drop resp with mid 4530 smb_iod_recvall: drop resp with mid 4531 bug: ecnt = 1, but m_len = 0 and m_next = 0 (please report) Nothing really HAPPENED, but you asked me to report, so here I am. >How-To-Repeat: Start out a bunch of concurrent I/O from a fileserver that likely cannot handle it, I did it shortly after booting both the fileserver and the client. >Fix: If only I knew. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 8 08:00:11 2008 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 A92F9106564A for ; Mon, 8 Dec 2008 08:00:11 +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 8B52F8FC16 for ; Mon, 8 Dec 2008 08:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB880BfG067741 for ; Mon, 8 Dec 2008 08:00:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB880BY1067740; Mon, 8 Dec 2008 08:00:11 GMT (envelope-from gnats) Date: Mon, 8 Dec 2008 08:00:11 GMT Message-Id: <200812080800.mB880BY1067740@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kumar Krishnamoorthy X-Mailman-Approved-At: Mon, 08 Dec 2008 12:25:02 +0000 Cc: Subject: Re: amd64/128978: [install] FreeBSD 6.3 64-bit panics at boot time during installation on HP DL580 G5 with 128GB physical memory X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kumar Krishnamoorthy List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 08:00:11 -0000 The following reply was made to PR amd64/128978; it has been noted by GNATS. From: Kumar Krishnamoorthy To: "bug-followup@FreeBSD.org" , Kumar Krishnamoorthy Cc: Subject: Re: amd64/128978: [install] FreeBSD 6.3 64-bit panics at boot time during installation on HP DL580 G5 with 128GB physical memory Date: Sun, 7 Dec 2008 23:50:40 -0800 --_000_7A7D327E99D30143AC98BDABFCABFF012271549D98PAEXMBX04vmwa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I could see the failure on all freebsd6.x-64 with more than 64GB of memory.= I ran this test on virtual machine that was created on the same HP DL580 = G5 server with 128GB server. Failures 7 FAIL Duration=3D15m29s guestOS=3Dfreebsd6.2-64 memSize=3D1310= 72 8 FAIL Duration=3D15m35s guestOS=3Dfreebsd6.3-64 memSize=3D1310= 72 9 FAIL Duration=3D15m33s guestOS=3Dfreebsd6.4-beta1-64 memSize=3D131072 10 FAIL Duration=3D15m32s guestOS=3Dfreebsd6.4-rc1-64 memSize=3D131072 11 FAIL Duration=3D15m32s guestOS=3Dfreebsd6.4-rc2-64 memSize=3D131072 Passed 0 PASS Duration=3D46m53s guestOS=3Dfreebsd6.2-64 memSize=3D65536 1 PASS Duration=3D52m48s guestOS=3Dfreebsd6.3-64 memSize=3D65536 3 PASS Duration=3D23m14s guestOS=3Dfreebsd6.4-rc1-64 memSize=3D65536 4 PASS Duration=3D23m20s guestOS=3Dfreebsd6.4-rc2-64 memSize=3D65536 .= . memSize - Guest memory that was used for the test in MB. Duration - Time it tool to install the guestOS. --_000_7A7D327E99D30143AC98BDABFCABFF012271549D98PAEXMBX04vmwa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I could see the failure on all freebsd6.x-64= with=20 more than 64GB of memory.  I ran this test on virtual machin= e=20 that was created on the same HP DL580 G5 server with=20 128GB server.
Failures
  7 FAIL Duration=3D15m29s=20 guestOS=3Dfreebsd6.2-64         =  =20 memSize=3D131072 
  8 FAIL Duration=3D15m35s=20 guestOS=3Dfreebsd6.3-64         =  =20 memSize=3D131072 
  9 FAIL Duration=3D15m33s guestOS=3Dfreebsd6.4= -beta1-64=20 memSize=3D131072
 10 FAIL Duration=3D15m32s=20 guestOS=3Dfreebsd6.4-rc1-64  &nb= sp;=20 memSize=3D131072 
 11 FAIL Duration=3D15m32s=20 guestOS=3Dfreebsd6.4-rc2-64  =20  memSize=3D131072 
Passed
  0 PASS Duration=3D46m53s=20 guestOS=3Dfreebsd6.2-64         = =20 memSize=3D65536 
  1 PASS Duration=3D52m48s=20 guestOS=3Dfreebsd6.3-64         = =20 memSize=3D65536 
  3 PASS Duration=3D23m14s=20 guestOS=3Dfreebsd6.4-rc1-64  &nb= sp;=20 memSize=3D65536 
  4 PASS Duration=3D23m20s=20 guestOS=3Dfreebsd6.4-rc2-64  &nb= sp;=20 memSize=3D65536 ..
memSize -=  Guest=20 memory that was used for the test in MB.
Duration  -  Time it tool to= =20 install the guestOS.
 
--_000_7A7D327E99D30143AC98BDABFCABFF012271549D98PAEXMBX04vmwa_-- From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 8 11:06:52 2008 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 3D2281065672 for ; Mon, 8 Dec 2008 11:06:52 +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 29E6B8FC0C for ; Mon, 8 Dec 2008 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB8B6q2U014185 for ; Mon, 8 Dec 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB8B6p6I014181 for freebsd-amd64@FreeBSD.org; Mon, 8 Dec 2008 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Dec 2008 11:06:51 GMT Message-Id: <200812081106.mB8B6p6I014181@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 X-Mailman-Approved-At: Mon, 08 Dec 2008 12:25:43 +0000 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, 08 Dec 2008 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/129488 amd64 [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [boot] amd64 motherboard: Intel DG965WH motherboard co o amd64/129238 amd64 [panic] System randomly panics f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128524 amd64 No geom documentation for loading gjournal o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/128236 amd64 portsdb -Uu Indexing error f kern/128102 amd64 AsusRock 939N68PV-GLAN not recognized o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa 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/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 87 problems total. From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 9 04:30:02 2008 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 47F17106564A for ; Tue, 9 Dec 2008 04:30:02 +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 254728FC1A for ; Tue, 9 Dec 2008 04:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB94U1xJ004499 for ; Tue, 9 Dec 2008 04:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB94U1SX004493; Tue, 9 Dec 2008 04:30:01 GMT (envelope-from gnats) Resent-Date: Tue, 9 Dec 2008 04:30:01 GMT Resent-Message-Id: <200812090430.mB94U1SX004493@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, Ven Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCA79106568A for ; Tue, 9 Dec 2008 04:22:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id B2B198FC1B for ; Tue, 9 Dec 2008 04:22:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mB94MvBO019137 for ; Tue, 9 Dec 2008 04:22:57 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mB94MvQb019126; Tue, 9 Dec 2008 04:22:57 GMT (envelope-from nobody) Message-Id: <200812090422.mB94MvQb019126@www.freebsd.org> Date: Tue, 9 Dec 2008 04:22:57 GMT From: Ven To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Tue, 09 Dec 2008 04:55:56 +0000 Cc: Subject: amd64/129515: apache activemq always cause system reboot 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, 09 Dec 2008 04:30:02 -0000 >Number: 129515 >Category: amd64 >Synopsis: apache activemq always cause system reboot >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Dec 09 04:30:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Ven >Release: 6.3-RELEASE-amd64 >Organization: Su2 >Environment: FreeBSD aop.su-fun.com 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Aug 27 18:52:34 CST 2008 root@aop.su-fun.com:/usr/obj/usr/src/sys/aop amd64 >Description: system always reboot while quit apache activemq (http://activemq.apache.org/index.html) same problem with diablo-jdk-freebsd6.amd64.1.5.0.07.01 and jdk 1.6. >How-To-Repeat: $ cd /usr/local/activemq/bin $ ./activemq << press Ctrl+C to quit >> .. then system reboot ... >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 9 05:33:48 2008 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 F12AC1065672; Tue, 9 Dec 2008 05:33:48 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id CACC78FC13; Tue, 9 Dec 2008 05:33:48 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id mB95Lh612546; Mon, 8 Dec 2008 21:21:43 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id mB95LhK15391; Mon, 8 Dec 2008 21:21:43 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Mon, 8 Dec 2008 21:21:43 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Ven In-Reply-To: <200812090422.mB94MvQb019126@www.freebsd.org> Message-ID: References: <200812090422.mB94MvQb019126@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/129515: apache activemq always cause system reboot 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, 09 Dec 2008 05:33:49 -0000 On Tue, 9 Dec 2008, Ven wrote: > >> Number: 129515 >> Category: amd64 >> Synopsis: apache activemq always cause system reboot >> Confidential: no >> Severity: critical >> Priority: medium >> Responsible: freebsd-amd64 >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Tue Dec 09 04:30:01 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Ven >> Release: 6.3-RELEASE-amd64 >> Organization: > Su2 >> Environment: > FreeBSD aop.su-fun.com 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Aug 27 18:52:34 CST 2008 root@aop.su-fun.com:/usr/obj/usr/src/sys/aop amd64 > >> Description: > system always reboot while quit apache activemq (http://activemq.apache.org/index.html) > > same problem with diablo-jdk-freebsd6.amd64.1.5.0.07.01 and jdk 1.6. > > >> How-To-Repeat: > $ cd /usr/local/activemq/bin > $ ./activemq > > << press Ctrl+C to quit >> > .. then system reboot ... >> Fix: Hi Ven, This might be related to http://security.freebsd.org/advisories/FreeBSD-SA-08:07.amd64.asc . I originally discovered the bug when running Java (a Linux binary in that case) caused the machine to reboot. Could you please apply the patch http://security.FreeBSD.org/patches/SA-08:07/amd64.patch , or else upgrade to FreeBSD 6.3-RELEASE-p6 or 6.4-RELEASE, and see if the problem still appears? -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 9 05:40:04 2008 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 4018F1065673 for ; Tue, 9 Dec 2008 05:40:04 +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 2E74D8FC14 for ; Tue, 9 Dec 2008 05:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB95e3te063681 for ; Tue, 9 Dec 2008 05:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB95e3fV063680; Tue, 9 Dec 2008 05:40:03 GMT (envelope-from gnats) Date: Tue, 9 Dec 2008 05:40:03 GMT Message-Id: <200812090540.mB95e3fV063680@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Nate Eldredge Cc: Subject: Re: amd64/129515: apache activemq always cause system reboot X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Eldredge List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 05:40:04 -0000 The following reply was made to PR amd64/129515; it has been noted by GNATS. From: Nate Eldredge To: Ven Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/129515: apache activemq always cause system reboot Date: Mon, 8 Dec 2008 21:21:43 -0800 (PST) On Tue, 9 Dec 2008, Ven wrote: > >> Number: 129515 >> Category: amd64 >> Synopsis: apache activemq always cause system reboot >> Confidential: no >> Severity: critical >> Priority: medium >> Responsible: freebsd-amd64 >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Tue Dec 09 04:30:01 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Ven >> Release: 6.3-RELEASE-amd64 >> Organization: > Su2 >> Environment: > FreeBSD aop.su-fun.com 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Aug 27 18:52:34 CST 2008 root@aop.su-fun.com:/usr/obj/usr/src/sys/aop amd64 > >> Description: > system always reboot while quit apache activemq (http://activemq.apache.org/index.html) > > same problem with diablo-jdk-freebsd6.amd64.1.5.0.07.01 and jdk 1.6. > > >> How-To-Repeat: > $ cd /usr/local/activemq/bin > $ ./activemq > > << press Ctrl+C to quit >> > .. then system reboot ... >> Fix: Hi Ven, This might be related to http://security.freebsd.org/advisories/FreeBSD-SA-08:07.amd64.asc . I originally discovered the bug when running Java (a Linux binary in that case) caused the machine to reboot. Could you please apply the patch http://security.FreeBSD.org/patches/SA-08:07/amd64.patch , or else upgrade to FreeBSD 6.3-RELEASE-p6 or 6.4-RELEASE, and see if the problem still appears? -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 9 10:10:04 2008 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 144F81065679 for ; Tue, 9 Dec 2008 10:10:04 +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 DE8B68FC21 for ; Tue, 9 Dec 2008 10:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB9AA3UW095566 for ; Tue, 9 Dec 2008 10:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB9AA356095565; Tue, 9 Dec 2008 10:10:03 GMT (envelope-from gnats) Date: Tue, 9 Dec 2008 10:10:03 GMT Message-Id: <200812091010.mB9AA356095565@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Nate Eldredge Cc: Subject: Re: amd64/129515: apache activemq always cause system reboot X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Eldredge List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 10:10:04 -0000 The following reply was made to PR amd64/129515; it has been noted by GNATS. From: Nate Eldredge To: YUHONG Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/129515: apache activemq always cause system reboot Date: Tue, 9 Dec 2008 02:08:59 -0800 (PST) On Tue, 9 Dec 2008, YUHONG wrote: > hi, Nate Eldredge: > > the issue disappeared after i upgrade to 6.4-RELEASE. Excellent! I take it this PR can be closed. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 9 19:11:08 2008 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 8A9751065672 for ; Tue, 9 Dec 2008 19:11:08 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 412918FC19 for ; Tue, 9 Dec 2008 19:11:06 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 3EB07119CF7; Tue, 9 Dec 2008 19:52:37 +0100 (CET) Date: Tue, 9 Dec 2008 19:52:37 +0100 From: Victor Balada Diaz To: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Message-ID: <20081209185236.GA1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Tue, 09 Dec 2008 19:16:21 +0000 Cc: Subject: [ATA] and re(4) stability issues 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, 09 Dec 2008 19:11:08 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, I got various machines[1] at hetzner.de and I've been having problems with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've been trying to narrow the problem so someone more knowledgeable than me is able to fix it. This mail is an other attempt to ask a question with regards ATA code to see if this time i got something. For the ones that don't actually know what happened: With FreeBSD 7.0 -RELEASE for amd64 and default kernel the system shared re0 interrupt with OHCI and this caused re(4) to corrupt packets and create interrupt storms. Tried updating to 7.1 -BETA2 and still had some problems with it. I've opened the PR kern/128287[2] and Remko quickly answered with a workaround: that workaround was removing USB support from my kernel. I did it and re(4) wasn't sharing interrupts anylonger, and the interrupt storms were gone. Now sometime later the interface goes up and down from time to time, but less often. Also sometimes the machine losts the network interface but continues to work. I know it continues to work because some days later i can see that it tried to deliver the status reports but was unable to resolve the aliases hostnames. I can't ping the machine and i know the network is OK. If i reboot the machine everything is working again. When switched from 7.0 to 7.1 BETA2 i also found that under load after some hours the machine created interrupt storms on ATA disks. Digging at linux source code i've found that they do some special things for this chipset that i've been unable to find on our code. This is linux code for my chipset: 371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | 372 AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | 373 AHCI_HFLAG_SECT255), File and the rest of the code in here[3]. As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could think of, switching MSI and MSI-x off for the whole system, so i added to /boot/loader.conf this tunables: hw.pci.enable_msix="0" hw.pci.enable_msi="0" And then rebooted the machine. After various hours of doing almost nothing i've found that the machine answered ping but was unable to answer any request (eg, ssh, nagios nrpe, etc). The machine recovered itself after some minutes and when i was able to ssh into i saw the following in dmesg: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly ad4: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=1463123158 and a lot more errors like that. I didn't get this errors with MSI enabled. I see WRITE_DMA48 and in linux code i saw AHCI_HFLAG_32BIT_ONLY which is later used for DMA related things. Could someone who is more knowledgeable check if we're doing the right thing? I've attached verbose dmesg of a machine that's like this one with 7.1 -BETA2, MSI enabled and GENERIC kernel minus USB and firewrire. Also, please, could someone give me a hand on how could i continue debugging this interrupt issues? I'm a bit lost and digging code and posting each time i think i've found something is not going to go anywhere. I would also like to say that i've seen reports of this kind of problems on amd64 machines in the lists since various years ago, so i don't think this is just a problem with this BIOS/motherboard (MSI K9AG Neo2 Digital) on the lists Thanks in advance for any help. Regards. [1]: http://www.hetzner.de/hosting/produkte_rootserver/ds7000/ [2]: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128287 [3]: http://fxr.watson.org/fxr/source/drivers/ata/ahci.c?v=linux-2.6#L369 -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.verbose" Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-BETA2 #1: Wed Oct 22 13:19:14 CEST 2008 victor@foo.bar.com:/usr/obj/usr/src/sys/NOUSB Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80c12000. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80c121a8. Preloaded elf obj module "/boot/kernel/accf_data.ko" at 0xffffffff80c12818. Preloaded elf obj module "/boot/kernel/accf_http.ko" at 0xffffffff80c12cc8. Preloaded elf obj module "/boot/kernel/k8temp.ko" at 0xffffffff80c13238. Preloaded elf obj module "/boot/kernel/geom_journal.ko" at 0xffffffff80c13720. Calibrating clock(s) ... i8254 clock: 1193242 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2999975813 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (2999.98-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 6395625472 (6099 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000d13000 - 0x00000000d1c6bfff, 3505754112 bytes (855897 pages) 0x0000000100000000 - 0x000000019ffeffff, 2684289024 bytes (655344 pages) avail memory = 6179069952 (5892 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf98a0/0x0014 (v 0 ACPIAM) ACPI: RSDT @ 0x0xddfd0000/0x003C (v 1 M S I OEMRSDT 0x10000731 MSFT 0x00000097) ACPI: FACP @ 0x0xddfd0200/0x0084 (v 2 M S I OEMFACP 0x10000731 MSFT 0x00000097) ACPI: DSDT @ 0x0xddfd0430/0x40D9 (v 1 1ADNC 1ADNC000 0x00000000 INTL 0x20051117) ACPI: FACS @ 0x0xddfde000/0x0040 ACPI: APIC @ 0x0xddfd0390/0x005C (v 1 M S I OEMAPIC 0x10000731 MSFT 0x00000097) ACPI: MCFG @ 0x0xddfd03f0/0x003C (v 1 M S I OEMMCFG 0x10000731 MSFT 0x00000097) ACPI: OEMB @ 0x0xddfde040/0x0060 (v 1 M S I AMI_OEM 0x10000731 MSFT 0x00000097) ACPI: EPTH @ 0x0xddfd4510/0x0038 (v 1 M S I OEMHPET 0x10000731 MSFT 0x00000097) ACPI: SSDT @ 0x0xddfd4550/0x030E (v 1 A M I POWERNOW 0x00000001 AMD 0x00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> ath_rate: version 1.2 wlan_amrr: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Oct 22 2008 13:19:08) acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.RS48.NB2_ -> bus 0 dev 0 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ddf00000 (3) failed ACPI timer: 0/838 0/839 0/841 0/895 0/842 0/840 0/837 0/890 0/836 0/837 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 7 10 11 12 14 15 Validation 0 7 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 3 4 5 7 10 11 12 14 15 Validation 0 4 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x7910, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7912, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7917, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x4380, revid=0x00 domain=0, bus=0, slot=18, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xa000, size 2, enabled map[18]: type I/O Port, range 32, base 0x9000, size 3, enabled map[1c]: type I/O Port, range 32, base 0x8000, size 2, enabled map[20]: type I/O Port, range 32, base 0x7000, size 4, enabled map[24]: type Memory, range 32, base 0xfe7ff800, size 10, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4387, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0517, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe7fe000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4388, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0517, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[10]: type Memory, range 32, base 0xfe7fd000, size 12, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4389, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe7fc000, size 12, enabled pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 18 found-> vendor=0x1002, dev=0x438a, revid=0x00 domain=0, bus=0, slot=19, func=3 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[10]: type Memory, range 32, base 0xfe7fb000, size 12, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x438b, revid=0x00 domain=0, bus=0, slot=19, func=4 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe7fa000, size 12, enabled pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4386, revid=0x00 domain=0, bus=0, slot=19, func=5 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0517, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe7ff000, size 8, enabled pcib0: matched entry for 0.19.INTD pcib0: slot 19 INTD hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x14 domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0401, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0xb00, size 4, enabled found-> vendor=0x1002, dev=0x438c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xff00, size 4, enabled found-> vendor=0x1002, dev=0x438d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfe800000-0xfe9fffff pcib1: prefetched decode 0xfc000000-0xfdffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x791e, revid=0x00 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xfc000000, size 25, enabled pcib1: requested memory range 0xfc000000-0xfdffffff: good map[18]: type Memory, range 64, base 0xfe9f0000, size 16, enabled pcib1: requested memory range 0xfe9f0000-0xfe9fffff: good map[20]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib1: requested I/O range 0xc000-0xc0ff: in range map[24]: type Memory, range 32, base 0xfe800000, size 20, enabled pcib1: requested memory range 0xfe800000-0xfe8fffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x7919, revid=0x00 domain=0, bus=1, slot=5, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9e8000, size 14, enabled pcib1: requested memory range 0xfe9e8000-0xfe9ebfff: good pcib1: matched entry for 1.5.INTB pcib1: slot 5 INTB hardwired to IRQ 19 vgapci0: port 0xc000-0xc0ff mem 0xfc000000-0xfdffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.2 (no driver attached) pcib2: at device 7.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x01 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type Memory, range 64, base 0xfeaff000, size 12, enabled pcib2: requested memory range 0xfeaff000-0xfeafffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfeaff000 re0: MSI count : 2 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:21:85:15:30:14 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 re0: [MPSAFE] re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x7000 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe7ff800 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect time=0ms ata3: SIGNATURE: 00000101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: SATA connect status=00000000 ata4: ahci_reset devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: SATA connect status=00000000 ata5: ahci_reset devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] pci0: at device 19.0 (no driver attached) pci0: at device 19.1 (no driver attached) pci0: at device 19.2 (no driver attached) pci0: at device 19.3 (no driver attached) pci0: at device 19.4 (no driver attached) pci0: at device 19.5 (no driver attached) pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 k8temp0: on hostb4 acpi_button0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 52 sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 53 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xcd800-0xce7ff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 235635 -> 100000 procfs registered lapic: Divisor 2, Frequency 99999202 hz Timecounter "TSC" frequency 2999975813 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 715404MB at ata2-master SATA300 ad4: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Silicon Image check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 715404MB at ata3-master SATA300 ad6: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Silicon Image check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 GEOM_MIRROR: Device mirror/os launched (2/2). GEOM_JOURNAL: Journal 647493113: mirror/oss1g contains data. GEOM_JOURNAL: Journal 647493113: mirror/oss1g contains journal. GEOM_JOURNAL: Journal mirror/oss1g clean. Trying to mount root from ufs:/dev/mirror/oss1a start_init: trying /sbin/init re0: link state changed to UP --XsQoSWH+UP9D9v3l-- From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 06:36:49 2008 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 B064C1065670 for ; Wed, 10 Dec 2008 06:36:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 75B1E8FC14 for ; Wed, 10 Dec 2008 06:36:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so276291rvf.43 for ; Tue, 09 Dec 2008 22:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QcNRwdk5TE4/471haVCtuNFM69b3fZbafBotTOqSmwA=; b=Dz+mcvUffJjlvXWPDYtcxPnGcySmBvvDV5Df16vh8Xbkt/MnnGKramOWv7S7f2rUzb qmCl8d/aeKvyMaITeAZS3Y97uoTW62Yj37xobLGqSP4F9PNHtC+0TGIYN+fft8LVnXyV KDDTGb9NkmsqPfDPq2QEk/baKc0jNJimmlpX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=llKlzC31kl9n38b+aeY3qjyk4/6JA956Fb/mV8d1d0/1f4LJmVDw/Aqspa+fr9Fuz4 Xzygh/MKCZ44Zooya4qhXwLi2zjGGLJg4/lXLggUFxejudUVWDvwl0WyP8oLHss37Et3 CAgv2VcF5RgmS+GUqUzRhJuiCPeOP61nl9mAw= Received: by 10.140.193.15 with SMTP id q15mr464966rvf.274.1228889558062; Tue, 09 Dec 2008 22:12:38 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id l31sm1974933rvb.2.2008.12.09.22.12.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 22:12:36 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBA6CTZ7038941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 15:12:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBA6CQjL038940; Wed, 10 Dec 2008 15:12:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 10 Dec 2008 15:12:26 +0900 From: Pyun YongHyeon To: Victor Balada Diaz Message-ID: <20081210061226.GC37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 06:36:49 -0000 On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > Hello, > > I got various machines[1] at hetzner.de and I've been having problems > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > been trying to narrow the problem so someone more knowledgeable than me > is able to fix it. This mail is an other attempt to ask a question > with regards ATA code to see if this time i got something. > > For the ones that don't actually know what happened: > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > the system shared re0 interrupt with OHCI and this caused > re(4) to corrupt packets and create interrupt storms. Tried re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily triggered on systems with > 4GB memory. But I dont' know whether this is related with interrupt storms. > updating to 7.1 -BETA2 and still had some problems with it. > > I've opened the PR kern/128287[2] and Remko quickly answered > with a workaround: that workaround was removing USB support from > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > and the interrupt storms were gone. Now sometime later the interface > goes up and down from time to time, but less often. Also sometimes > the machine losts the network interface but continues to work. > It seems that your controller supports MSI so you can set a tunable hw.re.msi_disable to 0 to enable MSI. With MSI you can remove interrupt sharing(e.g. add hw.re.msi_disable="0" to /boot/loader.conf file.) However there were several issues on re(4) w.r.t MSI so it was off by default. > I know it continues to work because some days later i can see that > it tried to deliver the status reports but was unable to resolve the > aliases hostnames. I can't ping the machine and i know the network > is OK. If i reboot the machine everything is working again. > Recently I've made small changes to re(4) which may help to detect link state change event. Would you try re(4) in HEAD? -- Regards, Pyun YongHyeon From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 10:28:15 2008 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 BB5621065679 for ; Wed, 10 Dec 2008 10:28:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 7D66C8FC24 for ; Wed, 10 Dec 2008 10:28:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so1302389rvb.6 for ; Wed, 10 Dec 2008 02:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=V4t22znMbAxNdMDLmK/8B6oe+dOwJ4C2xPuAepc2ONk=; b=ihCEW8SEoPPGvDNO5mZl1Ulal6UMSlfu2H+w8WSoZSfVzW+1TSgVAPKqIZfKjKh9iu pPHgX7993bo3u8M0LKk4ThgUdDcSu+HxQKiWbV0bEPiYxDOd50lZruzULVyv1xIhtieI 5PdOPujiAKQuVy/2y9qHyjE8OAum9qvQ0590E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=o03HV45TzzGHo2KwPoDJLIv2whfTnysWKpO42sXPETH59CSGY96em7ZSemeYB8fMPw P+jccPgyvbh05s+7deiS4sMg9h+1lfy93hhJ27khdWZrwO/keDB9FL4yKO5F5ew3vauy C2wa9KAUM0xUr2Lav+neYLO5LdVc4ZLqFNq1w= Received: by 10.141.87.13 with SMTP id p13mr570374rvl.286.1228904895217; Wed, 10 Dec 2008 02:28:15 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id l31sm2452342rvb.2.2008.12.10.02.28.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Dec 2008 02:28:14 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBAAS4bq039891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 19:28:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBAAS1Yl039890; Wed, 10 Dec 2008 19:28:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 10 Dec 2008 19:28:00 +0900 From: Pyun YongHyeon To: Victor Balada Diaz Message-ID: <20081210102800.GH37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081210085934.GB1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 10:28:15 -0000 On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > Hello, > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > been trying to narrow the problem so someone more knowledgeable than me > > > is able to fix it. This mail is an other attempt to ask a question > > > with regards ATA code to see if this time i got something. > > > > > > For the ones that don't actually know what happened: > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > the system shared re0 interrupt with OHCI and this caused > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > triggered on systems with > 4GB memory. But I dont' know whether > > this is related with interrupt storms. > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > with a workaround: that workaround was removing USB support from > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > and the interrupt storms were gone. Now sometime later the interface > > > goes up and down from time to time, but less often. Also sometimes > > > the machine losts the network interface but continues to work. > > > > > > > It seems that your controller supports MSI so you can set a tunable > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > /boot/loader.conf file.) However there were several issues on re(4) > > w.r.t MSI so it was off by default. > > This is undocumented and with sysctl -a i can't find the tunable. Is this > a HEAD feature or it's also in 7.1 -BETA2? Should i add Yeah it's an undocmented feature. But most drivers written by me have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have the tunable. > hw.re_msi_disable="0" to /boot/loader.conf? ^^^^^^^^^^^^^^^^^^^^^ Shoule be hw.re.msi_disable="0" > Yes, just add it to /boot/loader.conf. Note, you should not disable system-wide MSI control(e.g. hw.pci.enable_msi == 1). > This was sharing interrupt with USB, does USB need any special MSI handling > or with re using MSI is enough to not share the interrupt? If re(4) can use MSI, you don't need to worry about interrupt sharing with USB. Check the output of "vmstat -i". You normally get an irq256 or higher for MSI enabled driver. > > > > > > > I know it continues to work because some days later i can see that > > > it tried to deliver the status reports but was unable to resolve the > > > aliases hostnames. I can't ping the machine and i know the network > > > is OK. If i reboot the machine everything is working again. > > > > > > > Recently I've made small changes to re(4) which may help to detect > > link state change event. Would you try re(4) in HEAD? > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that Yes, you can. It should build without problems. Just replace re(4) on stable/7 with HEAD version. > or do i need to test the whole HEAD kernel? > No you don't have to that. -- Regards, Pyun YongHyeon From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 12:07:29 2008 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 5E88E1065675 for ; Wed, 10 Dec 2008 12:07:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 251B58FC0C for ; Wed, 10 Dec 2008 12:07:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so366262rvf.43 for ; Wed, 10 Dec 2008 04:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6D+Ra47muEmnYAQ1QZRzcDlC3iLHShC6NSG1/RcIdBs=; b=U8Y6GB/iw1bYN+E+oYVa9V8o9QXf79d7pmkkMhN3wSFwXTFZHKBdtXVKZioT+bwypU ncdj1z0bDNQOkLz1BCPMNhG7mXUV1rWIgTQ0Cw5nzrpfbUSs8O/j9mfdBiEk0yq28ExE p7JK+sVQjHGX4LOEyN8+/wQSYc+GQ4ryqSg4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=A+yKhLEZ7T2gZxYLj5Q3My37S6th2a79GKckzBDDbJg4EnPjeqqBoLsrCu7F/KKigq XsofD91ahm5ywzPIdRkr2nLZCZZZyCIklR/aaT+SoybmqVNNv29PjoaH1vzFRZDYfTYJ GiyEeE5kE89Xc+qBW4mNh5Sq+mJfPj0/slJvU= Received: by 10.141.106.14 with SMTP id i14mr630953rvm.143.1228910848644; Wed, 10 Dec 2008 04:07:28 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id l31sm2674990rvb.2.2008.12.10.04.07.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Dec 2008 04:07:27 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBAC7KmS040243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 21:07:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBAC7J55040242; Wed, 10 Dec 2008 21:07:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 10 Dec 2008 21:07:19 +0900 From: Pyun YongHyeon To: Victor Balada Diaz Message-ID: <20081210120719.GK37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081210113225.GD1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 12:07:29 -0000 On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 07:28:00PM +0900, Pyun YongHyeon wrote: > > On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > > > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > > > Hello, > > > > > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > > > been trying to narrow the problem so someone more knowledgeable than me > > > > > is able to fix it. This mail is an other attempt to ask a question > > > > > with regards ATA code to see if this time i got something. > > > > > > > > > > For the ones that don't actually know what happened: > > > > > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > > > the system shared re0 interrupt with OHCI and this caused > > > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > > > triggered on systems with > 4GB memory. But I dont' know whether > > > > this is related with interrupt storms. > > > > > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > > > with a workaround: that workaround was removing USB support from > > > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > > > and the interrupt storms were gone. Now sometime later the interface > > > > > goes up and down from time to time, but less often. Also sometimes > > > > > the machine losts the network interface but continues to work. > > > > > > > > > > > > > It seems that your controller supports MSI so you can set a tunable > > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > > /boot/loader.conf file.) However there were several issues on re(4) > > > > w.r.t MSI so it was off by default. > > > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > > > Yeah it's an undocmented feature. But most drivers written by me > > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > > the tunable. > > I think it could be great if you could document it or at least > show it by default when you do sysctl -ad with a small description. > If MSI worked as expected I would have documented it as I did in msk(4)/nfe(4)/ale(4)/age(4)/jme(4) etc. Using MSI on RealTek does not seem to stable. I tried hard to fix that but some users still reported watchdog timeouts. Working without documentation and hardware also made it hard to complete the work. This was the main reason why MSI was disabled on re(4). > > > > > hw.re_msi_disable="0" to /boot/loader.conf? > > ^^^^^^^^^^^^^^^^^^^^^ > > Shoule be hw.re.msi_disable="0" > > > > > > > Yes, just add it to /boot/loader.conf. Note, you should not disable > > system-wide MSI control(e.g. hw.pci.enable_msi == 1). > > > > > This was sharing interrupt with USB, does USB need any special MSI handling > > > or with re using MSI is enough to not share the interrupt? > > > > If re(4) can use MSI, you don't need to worry about interrupt > > sharing with USB. Check the output of "vmstat -i". You normally get > > an irq256 or higher for MSI enabled driver. > > > > > > > > > > > > > > > > > I know it continues to work because some days later i can see that > > > > > it tried to deliver the status reports but was unable to resolve the > > > > > aliases hostnames. I can't ping the machine and i know the network > > > > > is OK. If i reboot the machine everything is working again. > > > > > > > > > > > > > Recently I've made small changes to re(4) which may help to detect > > > > link state change event. Would you try re(4) in HEAD? > > > > > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that > > > > Yes, you can. It should build without problems. Just replace re(4) on > > stable/7 with HEAD version. > > > > > or do i need to test the whole HEAD kernel? > > > > > > > No you don't have to that. > > Backporting the changes i've found that it didn't compile so in > the end i got from HEAD the following files: > > base/head/sys/dev/re/if_re.c > base/head/sys/pci/if_rl.c > base/head/sys/pci/if_rlreg.h > Ah,, sorry about that. Recently there was some changes. I forgot that. > After that i've recompiled 7.1 -BETA2 GENERIC kernel and enabled > the knob you suggested in /boot/loader.conf. > > With the new kernel and MSI the interrupts are like this: > > # vmstat -i > interrupt total rate > irq9: acpi0 1 0 > irq16: ohci0 1 0 > irq17: ohci1 ohci3 1 0 > irq18: ohci2 ohci4 1 0 > irq22: atapci0 19215 15 > cpu0: timer 2502718 1998 > irq256: re0 4967726 3967 > cpu1: timer 2502525 1998 > Total 9992188 7980 > > The high interrupt numbers are because i've been running iperf to > check everything it's fine, not because of interrupt storms. So far > i didn't find any interrupt storms related to USB or re(4) driver > but while doing the tests i've found this error: > > re0: watchdog timeout (missed Tx interrupts) -- recovering > > This didn't create any error on the interfaces (netstat -i). > This was triggered by new code in HEAD. It indicates re(4) missed Tx completion interrupt. It could be a bug in driver or hardware bug. If you can live with that message you can safely ignore that as now re(4) does not reinitialize the hardware if it detect missing Tx completion interrupt. > Also i didn't see any problem with interfaces going up and down, > but that usually happen after some hours of uptime, so i'll let > you know if the error happens again. > Ok. > As these seems to improve the current situation, is there any > chance of merging -current driver in 7.1 before release? > I think re(4) in HEAD needs more testing. As you might know RealTek produced too many chipsets. :-( -- Regards, Pyun YongHyeon From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 14:02:14 2008 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 4C7BF10656D8; Wed, 10 Dec 2008 14:02:14 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id CB1778FC1D; Wed, 10 Dec 2008 14:02:13 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #65) id 1LAPdj-0001cg-Do; Wed, 10 Dec 2008 15:02:11 +0100 Received: from ma878.m.pppool.de ([89.49.168.120]:65294 helo=ernst.jennejohn.org) by 9.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #68) id 1LAPdj-0006Tm-6e; Wed, 10 Dec 2008 15:02:11 +0100 Date: Wed, 10 Dec 2008 15:02:07 +0100 From: Gary Jennejohn To: pyunyh@gmail.com Message-ID: <20081210150207.4951a157@ernst.jennejohn.org> In-Reply-To: <20081210120719.GK37837@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Victor Balada Diaz , freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 14:02:14 -0000 On Wed, 10 Dec 2008 21:07:19 +0900 Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > As these seems to improve the current situation, is there any > > chance of merging -current driver in 7.1 before release? > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > produced too many chipsets. :-( > FYI I've now turned MSI on in HEAD and will see what happens. Before my re0 was sharing interrupts with 3 USB controllers. Now it's all by itself on irq256. I'm running amd64 with re0: port 0xde00-0xdeff mem 0xfdaff000-0xfdafffff, 0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci2 --- Gary Jennejohn From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 08:59:38 2008 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 49B8B1065677; Wed, 10 Dec 2008 08:59:38 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id DD4948FC12; Wed, 10 Dec 2008 08:59:37 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 5382C119CF7; Wed, 10 Dec 2008 09:59:35 +0100 (CET) Date: Wed, 10 Dec 2008 09:59:35 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081210085934.GB1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081210061226.GC37837@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 10 Dec 2008 14:09:29 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 08:59:38 -0000 On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > Hello, > > > > I got various machines[1] at hetzner.de and I've been having problems > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > been trying to narrow the problem so someone more knowledgeable than me > > is able to fix it. This mail is an other attempt to ask a question > > with regards ATA code to see if this time i got something. > > > > For the ones that don't actually know what happened: > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > the system shared re0 interrupt with OHCI and this caused > > re(4) to corrupt packets and create interrupt storms. Tried > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > triggered on systems with > 4GB memory. But I dont' know whether > this is related with interrupt storms. > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > with a workaround: that workaround was removing USB support from > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > and the interrupt storms were gone. Now sometime later the interface > > goes up and down from time to time, but less often. Also sometimes > > the machine losts the network interface but continues to work. > > > > It seems that your controller supports MSI so you can set a tunable > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > interrupt sharing(e.g. add hw.re.msi_disable="0" to > /boot/loader.conf file.) However there were several issues on re(4) > w.r.t MSI so it was off by default. This is undocumented and with sysctl -a i can't find the tunable. Is this a HEAD feature or it's also in 7.1 -BETA2? Should i add hw.re_msi_disable="0" to /boot/loader.conf? This was sharing interrupt with USB, does USB need any special MSI handling or with re using MSI is enough to not share the interrupt? > > > I know it continues to work because some days later i can see that > > it tried to deliver the status reports but was unable to resolve the > > aliases hostnames. I can't ping the machine and i know the network > > is OK. If i reboot the machine everything is working again. > > > > Recently I've made small changes to re(4) which may help to detect > link state change event. Would you try re(4) in HEAD? Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that or do i need to test the whole HEAD kernel? Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 09:09:56 2008 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 AECCB1065672 for ; Wed, 10 Dec 2008 09:09:56 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forwards4.yandex.ru (forwards4.yandex.ru [77.88.32.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9C08FC16 for ; Wed, 10 Dec 2008 09:09:56 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp5.yandex.ru (smtp5.yandex.ru [77.88.32.24]) by forwards4.yandex.ru (Yandex) with ESMTP id 9A41D1935FE; Wed, 10 Dec 2008 11:58:24 +0300 (MSK) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:19191 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S6144119AbYLJI6P (ORCPT + 3 others); Wed, 10 Dec 2008 11:58:15 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp5 X-Yandex-TimeMark: 1228899495 X-BornDate: 1137963600 X-Yandex-Karma: 0 X-Yandex-KarmaStatus: 0 X-MsgDayCount: 4 X-Comment: RFC 2476 MSA function at smtp5.yandex.ru logged sender identity as: bu7cher Message-ID: <493F84A4.1080308@yandex.ru> Date: Wed, 10 Dec 2008 11:58:12 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Victor Balada Diaz References: <20081209185236.GA1320@alf.bsdes.net> In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Dec 2008 14:09:48 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org, =?UTF-8?B?U8O4?= =?UTF-8?B?cmVuIFNjaG1pZHQ=?= Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 09:09:56 -0000 Victor Balada Diaz wrote: > Digging at linux source code i've found that they do some special things > for this chipset that i've been unable to find on our code. This is > linux code for my chipset: > > 371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | > 372 AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | > 373 AHCI_HFLAG_SECT255), > > File and the rest of the code in here[3]. > > As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could > think of, switching MSI and MSI-x off for the whole system, so > i added to /boot/loader.conf this tunables: FreeBSD's ata(4) driver doesn't support MSI. This flag in linux's libata used in if ((hpriv->flags & AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev)) pci_intx(pdev, 1); In FreeBSD's code we have the same: /* enable PCI interrupt */ pci_write_config(dev, PCIR_COMMAND, pci_read_config(dev, PCIR_COMMAND, 2) & ~0x0400, 2); AHCI_HFLAG_IGN_SERR_INTERNAL flag targeted to ignore SERR_INTERNAL errors. FreeBSD's ata(4) driver ignores they too. AHCI_HFLAG_32BIT_ONLY flag limits to use 32-bit DMA only. If AHCI CAP register reports that controller supports 64-bit DMA driver will use 64-bit. So i think there can be added one quirk for you, but i'm not sure that problem is here.. AHCI_HFLAG_SECT255 flag limits I/O operation to 255 sectors, FreeBSD uses 128-limit by default. -- WBR, Andrey V. Elsukov From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 09:11:09 2008 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 6CD37106564A; Wed, 10 Dec 2008 09:11:09 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC368FC17; Wed, 10 Dec 2008 09:11:09 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id CFDF3119CF7; Wed, 10 Dec 2008 10:11:07 +0100 (CET) Date: Wed, 10 Dec 2008 10:11:07 +0100 From: Victor Balada Diaz To: "Andrey V. Elsukov" Message-ID: <20081210091107.GC1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <493F84A4.1080308@yandex.ru> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 10 Dec 2008 14:10:00 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org, =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 09:11:09 -0000 On Wed, Dec 10, 2008 at 11:58:12AM +0300, Andrey V. Elsukov wrote: > Victor Balada Diaz wrote: > >Digging at linux source code i've found that they do some special things > >for this chipset that i've been unable to find on our code. This is > >linux code for my chipset: > > > >371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | > >372 AHCI_HFLAG_32BIT_ONLY | > >AHCI_HFLAG_NO_MSI | > >373 AHCI_HFLAG_SECT255), > > > >File and the rest of the code in here[3]. > > > >As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could > >think of, switching MSI and MSI-x off for the whole system, so > >i added to /boot/loader.conf this tunables: > > FreeBSD's ata(4) driver doesn't support MSI. This flag in linux's libata > used in > > if ((hpriv->flags & AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev)) > pci_intx(pdev, 1); > > In FreeBSD's code we have the same: > > /* enable PCI interrupt */ > pci_write_config(dev, PCIR_COMMAND, > pci_read_config(dev, PCIR_COMMAND, 2) & ~0x0400, 2); > > AHCI_HFLAG_IGN_SERR_INTERNAL flag targeted to ignore SERR_INTERNAL errors. > FreeBSD's ata(4) driver ignores they too. > > AHCI_HFLAG_32BIT_ONLY flag limits to use 32-bit DMA only. > If AHCI CAP register reports that controller supports 64-bit DMA driver > will use 64-bit. > So i think there can be added one quirk for you, but i'm not sure that > problem is here.. > > AHCI_HFLAG_SECT255 flag limits I/O operation to 255 sectors, FreeBSD uses > 128-limit > by default. Thanks for explaining me what the flags do. I'm not skilled enough to create the DMA quirks but if you could give me some patches i'll test them. Also if you have any other idea on what could i test or how can i debug this it would be more than welcome. Thanks. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 09:55:40 2008 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 BC8E11065673; Wed, 10 Dec 2008 09:55:40 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from deepcore.dk (adsl.deepcore.dk [87.63.29.106]) by mx1.freebsd.org (Postfix) with ESMTP id 29DF68FC13; Wed, 10 Dec 2008 09:55:39 +0000 (UTC) (envelope-from sos@FreeBSD.ORG) Received: from [172.18.2.117] (axiell-gw1.novi.dk [77.243.61.137]) by deepcore.dk (8.14.3/8.14.2) with ESMTP id mBA9tZ1O029537; Wed, 10 Dec 2008 10:55:36 +0100 (CET) (envelope-from sos@FreeBSD.ORG) Message-Id: From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= To: Victor Balada Diaz In-Reply-To: <20081210091107.GC1320@alf.bsdes.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 10:55:35 +0100 References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (deepcore.dk [87.63.29.106]); Wed, 10 Dec 2008 10:55:36 +0100 (CET) X-Mailman-Approved-At: Wed, 10 Dec 2008 14:10:14 +0000 Cc: "Andrey V. Elsukov" , freebsd-stable@FreeBSD.ORG, freebsd-amd64@FreeBSD.ORG Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 09:55:40 -0000 On 10Dec, 2008, at 10:11 , Victor Balada Diaz wrote: > > Thanks for explaining me what the flags do. I'm not skilled enough =20 > to create > the DMA quirks but if you could give me some patches i'll test them. =20= > Also > if you have any other idea on what could i test or how can i debug =20 > this > it would be more than welcome. Comment out the following two lines in ata_ahci_dmainit(): if (ATA_INL(ctlr->r_res2, ATA_AHCI_CAP) & ATA_AHCI_CAP_64BIT) ch->dma->max_address =3D BUS_SPACE_MAXADDR; And you will not use 64bit DMA even if the chipset supports it. =20 However I have not seen any chipsets supporting this fail, YMMV as =20 usual :) -S=F8ren From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 11:32:28 2008 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 44F8B1065670; Wed, 10 Dec 2008 11:32:28 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 94C8C8FC12; Wed, 10 Dec 2008 11:32:27 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 16175119CF7; Wed, 10 Dec 2008 12:32:26 +0100 (CET) Date: Wed, 10 Dec 2008 12:32:25 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081210113225.GD1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081210102800.GH37837@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 10 Dec 2008 14:10:25 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 11:32:28 -0000 On Wed, Dec 10, 2008 at 07:28:00PM +0900, Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > > Hello, > > > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > > been trying to narrow the problem so someone more knowledgeable than me > > > > is able to fix it. This mail is an other attempt to ask a question > > > > with regards ATA code to see if this time i got something. > > > > > > > > For the ones that don't actually know what happened: > > > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > > the system shared re0 interrupt with OHCI and this caused > > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > > triggered on systems with > 4GB memory. But I dont' know whether > > > this is related with interrupt storms. > > > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > > with a workaround: that workaround was removing USB support from > > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > > and the interrupt storms were gone. Now sometime later the interface > > > > goes up and down from time to time, but less often. Also sometimes > > > > the machine losts the network interface but continues to work. > > > > > > > > > > It seems that your controller supports MSI so you can set a tunable > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > /boot/loader.conf file.) However there were several issues on re(4) > > > w.r.t MSI so it was off by default. > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > Yeah it's an undocmented feature. But most drivers written by me > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > the tunable. I think it could be great if you could document it or at least show it by default when you do sysctl -ad with a small description. > > > hw.re_msi_disable="0" to /boot/loader.conf? > ^^^^^^^^^^^^^^^^^^^^^ > Shoule be hw.re.msi_disable="0" > > > > Yes, just add it to /boot/loader.conf. Note, you should not disable > system-wide MSI control(e.g. hw.pci.enable_msi == 1). > > > This was sharing interrupt with USB, does USB need any special MSI handling > > or with re using MSI is enough to not share the interrupt? > > If re(4) can use MSI, you don't need to worry about interrupt > sharing with USB. Check the output of "vmstat -i". You normally get > an irq256 or higher for MSI enabled driver. > > > > > > > > > > > > I know it continues to work because some days later i can see that > > > > it tried to deliver the status reports but was unable to resolve the > > > > aliases hostnames. I can't ping the machine and i know the network > > > > is OK. If i reboot the machine everything is working again. > > > > > > > > > > Recently I've made small changes to re(4) which may help to detect > > > link state change event. Would you try re(4) in HEAD? > > > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that > > Yes, you can. It should build without problems. Just replace re(4) on > stable/7 with HEAD version. > > > or do i need to test the whole HEAD kernel? > > > > No you don't have to that. Backporting the changes i've found that it didn't compile so in the end i got from HEAD the following files: base/head/sys/dev/re/if_re.c base/head/sys/pci/if_rl.c base/head/sys/pci/if_rlreg.h After that i've recompiled 7.1 -BETA2 GENERIC kernel and enabled the knob you suggested in /boot/loader.conf. With the new kernel and MSI the interrupts are like this: # vmstat -i interrupt total rate irq9: acpi0 1 0 irq16: ohci0 1 0 irq17: ohci1 ohci3 1 0 irq18: ohci2 ohci4 1 0 irq22: atapci0 19215 15 cpu0: timer 2502718 1998 irq256: re0 4967726 3967 cpu1: timer 2502525 1998 Total 9992188 7980 The high interrupt numbers are because i've been running iperf to check everything it's fine, not because of interrupt storms. So far i didn't find any interrupt storms related to USB or re(4) driver but while doing the tests i've found this error: re0: watchdog timeout (missed Tx interrupts) -- recovering This didn't create any error on the interfaces (netstat -i). Also i didn't see any problem with interfaces going up and down, but that usually happen after some hours of uptime, so i'll let you know if the error happens again. As these seems to improve the current situation, is there any chance of merging -current driver in 7.1 before release? Thanks! Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 12:18:05 2008 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 D0E911065689; Wed, 10 Dec 2008 12:18:05 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from golanth.tzim.net (unknown [IPv6:2001:41d0:1:d91f:21c:c0ff:fe4b:cf32]) by mx1.freebsd.org (Postfix) with ESMTP id 734678FC19; Wed, 10 Dec 2008 12:18:05 +0000 (UTC) (envelope-from arnaud.houdelette@tzim.net) Received: from path-wifi.irisa.fr ([131.254.64.80]) by golanth.tzim.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAO0w-0008yc-7H; Wed, 10 Dec 2008 13:18:02 +0100 Message-ID: <493FB378.5030106@tzim.net> Date: Wed, 10 Dec 2008 13:18:00 +0100 From: Arnaud Houdelette User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Victor Balada Diaz References: <20081209185236.GA1320@alf.bsdes.net> In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: tzim@tzim.net X-Authenticator: plain X-Mailman-Approved-At: Wed, 10 Dec 2008 14:10:51 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 12:18:06 -0000 Victor Balada Diaz a crit : > Hello, > > I got various machines[1] at hetzner.de and I've been having problems > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > been trying to narrow the problem so someone more knowledgeable than me > is able to fix it. This mail is an other attempt to ask a question > with regards ATA code to see if this time i got something. > > For the ones that don't actually know what happened: > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > the system shared re0 interrupt with OHCI and this caused > re(4) to corrupt packets and create interrupt storms. Tried > updating to 7.1 -BETA2 and still had some problems with it. > > I've opened the PR kern/128287[2] and Remko quickly answered > with a workaround: that workaround was removing USB support from > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > and the interrupt storms were gone. Now sometime later the interface > goes up and down from time to time, but less often. Also sometimes > the machine losts the network interface but continues to work. > > I know it continues to work because some days later i can see that > it tried to deliver the status reports but was unable to resolve the > aliases hostnames. I can't ping the machine and i know the network > is OK. If i reboot the machine everything is working again. > > When switched from 7.0 to 7.1 BETA2 i also found that under load > after some hours the machine created interrupt storms on ATA disks. > > Digging at linux source code i've found that they do some special things > for this chipset that i've been unable to find on our code. This is > linux code for my chipset: > > 371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | > 372 AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | > 373 AHCI_HFLAG_SECT255), > > File and the rest of the code in here[3]. > > As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could > think of, switching MSI and MSI-x off for the whole system, so > i added to /boot/loader.conf this tunables: > > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" > > And then rebooted the machine. After various hours of doing almost nothing > i've found that the machine answered ping but was unable to answer any > request (eg, ssh, nagios nrpe, etc). The machine recovered itself after > some minutes and when i was able to ssh into i saw the following in dmesg: > > ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly > ad4: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=1463123158 > > and a lot more errors like that. I didn't get this errors with MSI enabled. > I see WRITE_DMA48 and in linux code i saw AHCI_HFLAG_32BIT_ONLY which is later > used for DMA related things. Could someone who is more knowledgeable check > if we're doing the right thing? > > I've attached verbose dmesg of a machine that's like this one with > 7.1 -BETA2, MSI enabled and GENERIC kernel minus USB and firewrire. > > Also, please, could someone give me a hand on how could i continue debugging > this interrupt issues? I'm a bit lost and digging code and posting each > time i think i've found something is not going to go anywhere. > > I would also like to say that i've seen reports of this kind of problems > on amd64 machines in the lists since various years ago, so i don't think > this is just a problem with this BIOS/motherboard (MSI K9AG Neo2 Digital) > on the lists > > > Thanks in advance for any help. > Regards. > > > [1]: http://www.hetzner.de/hosting/produkte_rootserver/ds7000/ > [2]: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128287 > [3]: http://fxr.watson.org/fxr/source/drivers/ata/ahci.c?v=linux-2.6#L369 > Sorry I didn't take the time to read all the thread, but I got similar problem with the same IXP600 chipset. Only it was'nt with a Realtek NIC (re) but with a Ralink wireless one. The simptoms where similar : interrupt 22 was shared between the sata controler and the wireless card. And I got Interrupt Storms at random times when using the wireless network. No problem since I removed the ral(4) NIC (got a real access point now). You might not want to point the finger at the re(4) driver too fast. Arnaud Houdelette From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 12:25:43 2008 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 2128E106564A; Wed, 10 Dec 2008 12:25:43 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id A89DD8FC35; Wed, 10 Dec 2008 12:25:42 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 1B9FC35FE6; Wed, 10 Dec 2008 12:08:52 +0000 (GMT) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id R-1fHWpc-Y1B; Wed, 10 Dec 2008 12:08:40 +0000 (GMT) Received: by nemesis.charlie.mouhaha.de (Postfix, from userid 1001) id ACC1335CEF; Wed, 10 Dec 2008 12:08:40 +0000 (GMT) Date: Wed, 10 Dec 2008 12:08:40 +0000 From: Oliver Peter To: Victor Balada Diaz Message-ID: <20081210120840.GA36443@nemesis.frida.mouhaha.de> References: <20081209185236.GA1320@alf.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20081209185236.GA1320@alf.bsdes.net> X-Operating-System: FreeBSD 7.0-RELEASE-p6 amd64 User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Wed, 10 Dec 2008 14:11:44 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 12:25:43 -0000 On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > Hello, >=20 > I got various machines[1] at hetzner.de and I've been having problems > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > been trying to narrow the problem so someone more knowledgeable than me > is able to fix it. This mail is an other attempt to ask a question > with regards ATA code to see if this time i got something. Just want to add a quick note and say that I'm having the same problem with my 7.0-RELEASE-p6/amd64 hetzner machine: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-September/005095.= html I would be happy to test patches as well. Thanks. --=20 Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 13:18:18 2008 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 C20B41065676 for ; Wed, 10 Dec 2008 13:18:18 +0000 (UTC) (envelope-from rabing@omc.net) Received: from office.omc.net (office.omc.net [212.77.224.22]) by mx1.freebsd.org (Postfix) with ESMTP id 40AA78FC18 for ; Wed, 10 Dec 2008 13:18:18 +0000 (UTC) (envelope-from rabing@omc.net) Received: from xoffice.omc.net (xoffice.omc.net [212.77.224.172]) by office.omc.net (8.14.1/8.14.1) with ESMTP id mBAD3SWw003477 for ; Wed, 10 Dec 2008 14:03:29 +0100 (CET) (envelope-from rabing@omc.net) Received: from [127.0.0.1] (lutz.omc.net [212.77.224.50]) by xoffice.omc.net (8.14.2/8.14.2) with ESMTP id mBAD3SQk086206 for ; Wed, 10 Dec 2008 14:03:29 +0100 (CET) (envelope-from rabing@omc.net) Message-ID: <493FBDEC.7010301@omc.net> Date: Wed, 10 Dec 2008 14:02:36 +0100 From: Lutz Rabing Organization: OMCnet IS GmbH User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-amd64@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Dec 2008 14:11:58 +0000 Subject: AMD Phenom(tm) 8450 Triple-Core Processor does not boot 7.1-PRERELESE X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rabing@omc.net List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 13:18:18 -0000 hi, I just upgraded a new system with an AMD "Triple-Core" CPU from amd64 7.0-RELEASE to amd64 7.1-PRERELEASE. the boot process hangs after "SMP: AP CPU #2 Launched!" as you can see from the attached dmesg output 7.0-RELEASE does boot. is this a known problem, or is there anything I can do? best regards, lutz rabing #------------------------- Dec 10 01:20:49 xXx kernel: FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 Dec 10 21:22:24 xXx kernel: root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Dec 10 21:22:24 xXx kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Dec 10 21:22:24 xXx kernel: CPU: AMD Phenom(tm) 8450 Triple-Core Processor (2109.33-MHz K8-class CPU) Dec 10 21:22:24 xXx kernel: Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Dec 10 21:22:24 xXx kernel: Features=0x178bfbff Dec 10 21:22:24 xXx kernel: Features2=0x802009> Dec 10 21:22:24 xXx kernel: AMD Features=0xee500800,RDTSCP,LM,3DNow!+,3DNow!> Dec 10 21:22:24 xXx kernel: AMD Features2=0x7ff,,,Prefetch,,> Dec 10 21:22:24 xXx kernel: Cores per package: 3 Dec 10 21:22:24 xXx kernel: usable memory = 8308195328 (7923 MB) Dec 10 21:22:24 xXx kernel: avail memory = 8028749824 (7656 MB) Dec 10 21:22:24 xXx kernel: ACPI APIC Table: <091908 APIC1057> Dec 10 21:22:24 xXx kernel: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs Dec 10 21:22:24 xXx kernel: cpu0 (BSP): APIC ID: 0 Dec 10 21:22:24 xXx kernel: cpu1 (AP): APIC ID: 1 Dec 10 21:22:24 xXx kernel: cpu2 (AP): APIC ID: 2 Dec 10 21:22:24 xXx kernel: ioapic0 irqs 0-23 on motherboard Dec 10 21:22:24 xXx kernel: kbd1 at kbdmux0 Dec 10 21:22:24 xXx kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Dec 10 21:22:24 xXx kernel: hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) Dec 10 21:22:24 xXx kernel: acpi0: <091908 RSDT1057> on motherboard Dec 10 21:22:24 xXx kernel: acpi0: [ITHREAD] Dec 10 21:22:24 xXx kernel: acpi0: Power Button (fixed) Dec 10 21:22:24 xXx kernel: acpi0: reservation of ffb80000, 80000 (3) failed Dec 10 21:22:24 xXx kernel: acpi0: reservation of 0, a0000 (3) failed Dec 10 21:22:24 xXx kernel: acpi0: reservation of 100000, cff00000 (3) failed Dec 10 21:22:24 xXx kernel: ACPI HPET table warning: Sequence is non-zero (2) Dec 10 21:22:24 xXx kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Dec 10 21:22:24 xXx kernel: acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Dec 10 21:22:24 xXx kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Dec 10 21:22:24 xXx kernel: acpi_hpet0: HPET never increments, disabling Dec 10 21:22:24 xXx kernel: device_attach: acpi_hpet0 attach returned 6 Dec 10 21:22:24 xXx kernel: cpu0: on acpi0 Dec 10 21:22:24 xXx kernel: acpi_throttle0: on cpu0 Dec 10 21:22:24 xXx kernel: cpu1: on acpi0 Dec 10 21:22:24 xXx kernel: cpu2: on acpi0 ... Dec 10 21:22:24 xXx kernel: SMP: AP CPU #2 Launched! Dec 10 21:22:24 xXx kernel: SMP: AP CPU #1 Launched! ... From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 14:01:32 2008 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 C14311065672; Wed, 10 Dec 2008 14:01:32 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id B7BFF8FC1B; Wed, 10 Dec 2008 14:01:31 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 437EF119CF8; Wed, 10 Dec 2008 15:01:30 +0100 (CET) Date: Wed, 10 Dec 2008 15:01:30 +0100 From: Victor Balada Diaz To: Oliver Peter Message-ID: <20081210140129.GE1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210120840.GA36443@nemesis.frida.mouhaha.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081210120840.GA36443@nemesis.frida.mouhaha.de> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 10 Dec 2008 14:12:09 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 14:01:32 -0000 On Wed, Dec 10, 2008 at 12:08:40PM +0000, Oliver Peter wrote: > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > Hello, > > > > I got various machines[1] at hetzner.de and I've been having problems > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > been trying to narrow the problem so someone more knowledgeable than me > > is able to fix it. This mail is an other attempt to ask a question > > with regards ATA code to see if this time i got something. > > Just want to add a quick note and say that I'm having the same problem > with my 7.0-RELEASE-p6/amd64 hetzner machine: > > http://lists.freebsd.org/pipermail/freebsd-acpi/2008-September/005095.html > > I would be happy to test patches as well. Thanks. Hello Oliver, What i did so far and improved a lot the experience was: 1) Upgrade at least the if_re code to RELENG_7. This fixes issues of packet corruption on ssh sessions. 2) Delete from your kernel config USB and firewire. This prevents the realtek interrupt to be shared. After this, with 7.1 -BETA2 the systems are more or less stable, but after a while the ATA controller starts to create interrupt storms. I wasn't able to find why. With the help that i've received in this thread from Pyun YongHyeon (Thanks!!) i'm also trying this suggestions: 3) Backport this 3 files from current to 7.1 -BETA2: base/head/sys/dev/re/if_re.c base/head/sys/pci/if_rl.c base/head/sys/pci/if_rlreg.h You can fetch them from http://svn.freebsd.org/. With them and adding to /boot/loader.conf this tunable: hw.re.msi_disable="0" I can use GENERIC kernel again (ie, USB enabled) and so far i didn't find any problem yet. No more interface up/down problems and no more interrupt storms. I must say that i haven't tested this enough, because the interrupt storms in ATA code start to happen after a few days of uptime load, but at least the problems with the realtek seem to be gone. If you upgrade to 7.1 -BETA2 you'll also get SATA support for the IXP card. With 7.0 it will work as ATA 33 in compatibility mode. Maybe someone with write access to the wiki could add it somewhere so that other hetzner users that are having the same problems could use the same workarounds :) I hope this helps you. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 14:08:26 2008 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 561691065670; Wed, 10 Dec 2008 14:08:26 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3A38FC08; Wed, 10 Dec 2008 14:08:25 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 76EAB119CF7; Wed, 10 Dec 2008 15:08:24 +0100 (CET) Date: Wed, 10 Dec 2008 15:08:24 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081210140823.GF1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081210120719.GK37837@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 10 Dec 2008 14:12:28 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 14:08:26 -0000 On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > On Wed, Dec 10, 2008 at 07:28:00PM +0900, Pyun YongHyeon wrote: > > > On Wed, Dec 10, 2008 at 09:59:35AM +0100, Victor Balada Diaz wrote: > > > > On Wed, Dec 10, 2008 at 03:12:26PM +0900, Pyun YongHyeon wrote: > > > > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: > > > > > > Hello, > > > > > > > > > > > > I got various machines[1] at hetzner.de and I've been having problems > > > > > > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > > > > > > been trying to narrow the problem so someone more knowledgeable than me > > > > > > is able to fix it. This mail is an other attempt to ask a question > > > > > > with regards ATA code to see if this time i got something. > > > > > > > > > > > > For the ones that don't actually know what happened: > > > > > > > > > > > > With FreeBSD 7.0 -RELEASE for amd64 and default kernel > > > > > > the system shared re0 interrupt with OHCI and this caused > > > > > > re(4) to corrupt packets and create interrupt storms. Tried > > > > > > > > > > re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily > > > > > triggered on systems with > 4GB memory. But I dont' know whether > > > > > this is related with interrupt storms. > > > > > > > > > > > updating to 7.1 -BETA2 and still had some problems with it. > > > > > > > > > > > > I've opened the PR kern/128287[2] and Remko quickly answered > > > > > > with a workaround: that workaround was removing USB support from > > > > > > my kernel. I did it and re(4) wasn't sharing interrupts anylonger, > > > > > > and the interrupt storms were gone. Now sometime later the interface > > > > > > goes up and down from time to time, but less often. Also sometimes > > > > > > the machine losts the network interface but continues to work. > > > > > > > > > > > > > > > > It seems that your controller supports MSI so you can set a tunable > > > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > > > /boot/loader.conf file.) However there were several issues on re(4) > > > > > w.r.t MSI so it was off by default. > > > > > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > > > > > Yeah it's an undocmented feature. But most drivers written by me > > > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > > > the tunable. > > > > I think it could be great if you could document it or at least > > show it by default when you do sysctl -ad with a small description. > > > > If MSI worked as expected I would have documented it as I did > in msk(4)/nfe(4)/ale(4)/age(4)/jme(4) etc. > Using MSI on RealTek does not seem to stable. I tried hard to fix > that but some users still reported watchdog timeouts. Working > without documentation and hardware also made it hard to complete > the work. This was the main reason why MSI was disabled on re(4). What do you think about adding a note in the man page telling that it's experimental and in some cases it could improve the situation but in others it will give errors? > > > > > > > > hw.re_msi_disable="0" to /boot/loader.conf? > > > ^^^^^^^^^^^^^^^^^^^^^ > > > Shoule be hw.re.msi_disable="0" > > > > > > > > > > Yes, just add it to /boot/loader.conf. Note, you should not disable > > > system-wide MSI control(e.g. hw.pci.enable_msi == 1). > > > > > > > This was sharing interrupt with USB, does USB need any special MSI handling > > > > or with re using MSI is enough to not share the interrupt? > > > > > > If re(4) can use MSI, you don't need to worry about interrupt > > > sharing with USB. Check the output of "vmstat -i". You normally get > > > an irq256 or higher for MSI enabled driver. > > > > > > > > > > > > > > > > > > > > > > I know it continues to work because some days later i can see that > > > > > > it tried to deliver the status reports but was unable to resolve the > > > > > > aliases hostnames. I can't ping the machine and i know the network > > > > > > is OK. If i reboot the machine everything is working again. > > > > > > > > > > > > > > > > Recently I've made small changes to re(4) which may help to detect > > > > > link state change event. Would you try re(4) in HEAD? > > > > > > > > Can i just drop HEAD's /stable/7/sys/dev/re/ in -STABLE and test that > > > > > > Yes, you can. It should build without problems. Just replace re(4) on > > > stable/7 with HEAD version. > > > > > > > or do i need to test the whole HEAD kernel? > > > > > > > > > > No you don't have to that. > > > > Backporting the changes i've found that it didn't compile so in > > the end i got from HEAD the following files: > > > > base/head/sys/dev/re/if_re.c > > base/head/sys/pci/if_rl.c > > base/head/sys/pci/if_rlreg.h > > > > Ah,, sorry about that. Recently there was some changes. I forgot > that. > > > After that i've recompiled 7.1 -BETA2 GENERIC kernel and enabled > > the knob you suggested in /boot/loader.conf. > > > > With the new kernel and MSI the interrupts are like this: > > > > # vmstat -i > > interrupt total rate > > irq9: acpi0 1 0 > > irq16: ohci0 1 0 > > irq17: ohci1 ohci3 1 0 > > irq18: ohci2 ohci4 1 0 > > irq22: atapci0 19215 15 > > cpu0: timer 2502718 1998 > > irq256: re0 4967726 3967 > > cpu1: timer 2502525 1998 > > Total 9992188 7980 > > > > The high interrupt numbers are because i've been running iperf to > > check everything it's fine, not because of interrupt storms. So far > > i didn't find any interrupt storms related to USB or re(4) driver > > but while doing the tests i've found this error: > > > > re0: watchdog timeout (missed Tx interrupts) -- recovering > > > > This didn't create any error on the interfaces (netstat -i). > > > > This was triggered by new code in HEAD. It indicates re(4) missed > Tx completion interrupt. It could be a bug in driver or hardware > bug. If you can live with that message you can safely ignore that > as now re(4) does not reinitialize the hardware if it detect > missing Tx completion interrupt. Yeah, just happened once, and i'm used to receiving a lot of interface UP/DOWN messages that now are gone, so this is an improvement. > > > Also i didn't see any problem with interfaces going up and down, > > but that usually happen after some hours of uptime, so i'll let > > you know if the error happens again. > > > > Ok. > > > As these seems to improve the current situation, is there any > > chance of merging -current driver in 7.1 before release? > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > produced too many chipsets. :-( Ok, i'll use the backported driver as it works better for me :-) If i can help you testing any patches i'm more than welcome to do it. Thanks a lot for your help Pyun YongHyeon. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 14:18:47 2008 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 D26D81065673; Wed, 10 Dec 2008 14:18:47 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from nemesis.charlie.mouhaha.de (nemesis.charlie.mouhaha.de [78.47.10.193]) by mx1.freebsd.org (Postfix) with ESMTP id 697D28FC12; Wed, 10 Dec 2008 14:18:47 +0000 (UTC) (envelope-from oliver@nemesis.charlie.mouhaha.de) Received: from localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) by nemesis.charlie.mouhaha.de (Postfix) with ESMTP id 460F22D2F4; Wed, 10 Dec 2008 14:18:46 +0000 (GMT) X-Virus-Scanned: amavisd-new at mouhaha.de Received: from nemesis.charlie.mouhaha.de ([78.47.10.193]) by localhost (nemesis.charlie.mouhaha.de [78.47.10.193]) (amavisd-new, port 10024) with ESMTP id vhmo2AubaKB5; Wed, 10 Dec 2008 14:18:34 +0000 (GMT) Received: by nemesis.charlie.mouhaha.de (Postfix, from userid 1001) id C19F42D2D3; Wed, 10 Dec 2008 14:18:34 +0000 (GMT) Date: Wed, 10 Dec 2008 14:18:34 +0000 From: Oliver Peter To: Victor Balada Diaz Message-ID: <20081210141834.GB36443@nemesis.frida.mouhaha.de> References: <20081209185236.GA1320@alf.bsdes.net> <20081210120840.GA36443@nemesis.frida.mouhaha.de> <20081210140129.GE1320@alf.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081210140129.GE1320@alf.bsdes.net> X-Operating-System: FreeBSD 7.0-RELEASE-p6 amd64 User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Wed, 10 Dec 2008 14:29:20 +0000 Cc: Oliver Peter , freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 14:18:47 -0000 On Wed, Dec 10, 2008 at 03:01:30PM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 12:08:40PM +0000, Oliver Peter wrote: > > On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote: ... > I can use GENERIC kernel again (ie, USB enabled) and so far > i didn't find any problem yet. No more interface up/down problems > and no more interrupt storms. I must say that i haven't tested > this enough, because the interrupt storms in ATA code start to > happen after a few days of uptime load, but at least the problems > with the realtek seem to be gone. I found out that I'm able to 'force' the interrupt storm by provoking higher disk I/O. Just let dd write to a file in a loop for some hours and watch vmstat: while true; do dd if=/dev/zero of=BLA bs=1M count=1000; done First you'll see that the throughput will decrease, and a few hours later you'll have /var/log/messages / dmesg full of interrupt storm messages. > If you upgrade to 7.1 -BETA2 you'll also get SATA support for > the IXP card. With 7.0 it will work as ATA 33 in compatibility mode. Wow! That's good to hear as well. I'll definitely switch to -STABLE or 7.1-PRERELASE sooner or later. I'll just give it a try on my other machines at first. > I hope this helps you. Absolutely, cheers mate. I owe you one! ~ollie -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 14:21:08 2008 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 D792C1065679; Wed, 10 Dec 2008 14:21:08 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 806058FC25; Wed, 10 Dec 2008 14:21:08 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 8DD3F119CF8; Wed, 10 Dec 2008 15:21:07 +0100 (CET) Date: Wed, 10 Dec 2008 15:21:07 +0100 From: Victor Balada Diaz To: Arnaud Houdelette Message-ID: <20081210142107.GG1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <493FB378.5030106@tzim.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <493FB378.5030106@tzim.net> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 10 Dec 2008 14:29:29 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 14:21:08 -0000 On Wed, Dec 10, 2008 at 01:18:00PM +0100, Arnaud Houdelette wrote: > Victor Balada Diaz a crit : > >Hello, > > > >I got various machines[1] at hetzner.de and I've been having problems > >with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've > >been trying to narrow the problem so someone more knowledgeable than me > >is able to fix it. This mail is an other attempt to ask a question > >with regards ATA code to see if this time i got something. > > > >[...] > > Sorry I didn't take the time to read all the thread, but I got similar > problem with the same IXP600 chipset. > Only it was'nt with a Realtek NIC (re) but with a Ralink wireless one. > The simptoms where similar : interrupt 22 was shared between the sata > controler and the wireless card. And I got Interrupt Storms at random > times when using the wireless network. > > No problem since I removed the ral(4) NIC (got a real access point now). > You might not want to point the finger at the re(4) driver too fast. > > Arnaud Houdelette Hello Arnaud, I didn't say the problem was just because of re(4). Actually i think the there were two problems, one with re(4) and other with ata(4). The reason why i talked about both of them in the same mail is because i thought that as two drivers were affected, maybe the problem was in other part of the operating system and that could help the developers to debug the problem. My re(4) card isn't sharing the interrupt with IXP600, it's sharing the interrupt with USB controller. In this case i think the problem is fixed with the advices from Pyun YongHyeon (backporting the driver from HEAD and using MSI for interrupts). I think the problems with ata(4) code will appear again after a few days of load, as they always do, so i'll keep trying to debug them. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 10 18:06:03 2008 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 34E6A1065678; Wed, 10 Dec 2008 18:06:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id BB3748FC13; Wed, 10 Dec 2008 18:06:02 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBAI60oL032389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 05:06:00 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mBAI5xGx007515; Thu, 11 Dec 2008 05:05:59 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mBAI5x3h007514; Thu, 11 Dec 2008 05:05:59 +1100 (EST) (envelope-from peter) Date: Thu, 11 Dec 2008 05:05:59 +1100 From: Peter Jeremy To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20081210180559.GC58682@server.vk2pj.dyndns.org> References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L9fXoLhVbEF7eqMD" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 10 Dec 2008 18:06:03 -0000 --L9fXoLhVbEF7eqMD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-10 10:55:35 +0100, S=F8ren Schmidt wrote: >And you will not use 64bit DMA even if the chipset supports it. =20 >However I have not seen any chipsets supporting this fail, YMMV as =20 >usual :) There's a reference in wikipedia pointing to http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06694.html that claims the AMD/ATI SB600 lies about supporting 64-bit DMA in AHCI mode. I have a SB600 but it doesn't have >4GB to test on. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --L9fXoLhVbEF7eqMD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklABQcACgkQ/opHv/APuIe93QCfVomKQ7lkv9N/vjy3nkE5nSW5 Ot0An295JWo0uNF+4T48Dn41o5rfUFSR =+Jwp -----END PGP SIGNATURE----- --L9fXoLhVbEF7eqMD-- From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 01:10:03 2008 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 E28351065675 for ; Thu, 11 Dec 2008 01:10:03 +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 BB9128FC16 for ; Thu, 11 Dec 2008 01:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBB1A3dg095606 for ; Thu, 11 Dec 2008 01:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBB1A3GW095605; Thu, 11 Dec 2008 01:10:03 GMT (envelope-from gnats) Resent-Date: Thu, 11 Dec 2008 01:10:03 GMT Resent-Message-Id: <200812110110.mBB1A3GW095605@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, Kai Gallasch Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93EF0106564A for ; Thu, 11 Dec 2008 01:08:15 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA3A8FC0C for ; Thu, 11 Dec 2008 01:08:15 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mBB18FHU012563 for ; Thu, 11 Dec 2008 01:08:15 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mBB18EaG012561; Thu, 11 Dec 2008 01:08:14 GMT (envelope-from nobody) Message-Id: <200812110108.mBB18EaG012561@www.freebsd.org> Date: Thu, 11 Dec 2008 01:08:14 GMT From: Kai Gallasch To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Thu, 11 Dec 2008 01:16:26 +0000 Cc: Subject: amd64/129563: [ACPI] sleep broken on IBM/Lenovo T61 [amd64] 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, 11 Dec 2008 01:10:04 -0000 >Number: 129563 >Category: amd64 >Synopsis: [ACPI] sleep broken on IBM/Lenovo T61 [amd64] >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 11 01:10:03 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Kai Gallasch >Release: amd64 7.1 PRERELEASE 20081211 >Organization: >Environment: FreeBSD boskoop.free.de 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Thu Dec 11 01:09:49 CET 2008 root@boskoop.free.de:/usr/obj/usr/src/sys/IBM-T61 amd64 >Description: Trying to put IBM/Lenovo Notebook T61 into supported sleep modes through command "acpiconf" provokes an error: ~ # acpiconf -s5 acpiconf: invalid sleep type (5) ~ # acpiconf -s4 acpiconf: request sleep type (4) failed: Operation not supported ~ # acpiconf -s3 acpiconf: request sleep type (3) failed: Operation not supported ~ # sysctl -a | grep sleep_state hw.acpi.supported_sleep_state: S3 S4 S5 ---- dmesg ---- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #5: Thu Dec 11 01:09:49 CET 2008 root@boskoop.free.de:/usr/obj/usr/src/sys/IBM-T61 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz (2493.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3bd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2119114752 (2020 MB) avail memory = 2044940288 (1950 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ef00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x207f mem 0xd2000000-0xd2ffffff,0xe0000000-0xefffffff,0xd0000000-0xd1ffffff irq 16 at device 0.0 on pci1 em0: port 0x1840-0x185f mem 0xfe200000-0xfe21ffff,0xfe225000-0xfe225fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:25:74:d1:01 uhci0: port 0x1860-0x187f irq 20 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1880-0x189f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfe226c00-0xfe226fff irq 22 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcm0: mem 0xfe220000-0xfe223fff irq 17 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) pcib3: irq 21 at device 28.1 on pci0 pci3: on pcib3 pci3: at device 0.0 (no driver attached) pcib4: irq 22 at device 28.2 on pci0 pci4: on pcib4 pcib5: irq 23 at device 28.3 on pci0 pci5: on pcib5 pcib6: irq 20 at device 28.4 on pci0 pci13: on pcib6 uhci2: port 0x18a0-0x18bf irq 16 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x18c0-0x18df irq 17 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18e0-0x18ff irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfe227000-0xfe2273ff irq 19 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib7: at device 30.0 on pci0 pci21: on pcib7 cbb0: mem 0xf8100000-0xf8100fff irq 16 at device 0.0 on pci21 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1830-0x183f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x1c48-0x1c4f,0x1c1c-0x1c1f,0x1c40-0x1c47,0x1c18-0x1c1b,0x1c20-0x1c3f mem 0xfe226000-0xfe2267ff irq 16 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 3 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Synaptics Touchpad, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd3fff,0xe0000-0xeffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 ugen0: on uhub0 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA33 ad4: 152627MB at ata2-master SATA150 pcm0: pcm0: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s2a WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ---- dmesg: END ---- ---- kldstat ---- boskoop:~ # kldstat Id Refs Address Size Name 1 13 0xffffffff80100000 7acee8 kernel 2 1 0xffffffff808ad000 1a6e8 snd_hda.ko 3 2 0xffffffff808c8000 66408 sound.ko 4 1 0xffffffff8092f000 5300 acpi_ibm.ko 5 1 0xffffffff80935000 9590 ng_ubt.ko 6 6 0xffffffff8093f000 14398 netgraph.ko 7 4 0xffffffffaeea6000 81e ng_bluetooth.ko 8 1 0xffffffffaeea7000 8742 ng_hci.ko 9 1 0xffffffffaeeb0000 ad40 ng_l2cap.ko 10 1 0xffffffffaeebb000 126e2 ng_btsocket.ko 11 1 0xffffffffaeece000 183e ng_socket.ko ---- kldstat: END ---- ---- sysctl -a | grep acpi ---- ~ # sysctl -a | grep acpi debug.acpi.semaphore_debug: 0 debug.acpi.suspend_bounce: 0 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 20070320 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 42.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 36.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 95.5C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 100.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.acpi.cpu.cx_lowest: C1 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1009872 dev.acpi.0.%desc: LENOVO TP-7L dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x12, ECDT dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPC_.EC__ dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%parent: acpi0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.MEM_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=0 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.LPC_.SIO_ dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=0 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%parent: acpi0 dev.acpi_hpet.0.%desc: High Precision Event Timer dev.acpi_hpet.0.%driver: acpi_hpet dev.acpi_hpet.0.%location: unknown dev.acpi_hpet.0.%pnpinfo: unknown dev.acpi_hpet.0.%parent: acpi0 dev.acpi_lid.0.%desc: Control Method Lid Switch dev.acpi_lid.0.%driver: acpi_lid dev.acpi_lid.0.%location: handle=\_SB_.LID_ dev.acpi_lid.0.%pnpinfo: _HID=PNP0C0D _UID=0 dev.acpi_lid.0.%parent: acpi0 dev.acpi_lid.0.wake: 1 dev.acpi_button.0.%desc: Sleep Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.SLPB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0E _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.pcib.0.%parent: acpi0 dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THM0 dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 dev.acpi_tz.1.%desc: Thermal Zone dev.acpi_tz.1.%driver: acpi_tz dev.acpi_tz.1.%location: handle=\_TZ_.THM1 dev.acpi_tz.1.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.1.%parent: acpi0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%parent: acpi0 dev.atdma.0.%parent: acpi0 dev.fpupnp.0.%parent: acpi0 dev.atkbdc.0.%parent: acpi0 dev.psmcpnp.0.%parent: acpi0 dev.battery.0.%parent: acpi0 dev.acpi_acad.0.%desc: AC Adapter dev.acpi_acad.0.%driver: acpi_acad dev.acpi_acad.0.%location: handle=\_SB_.PCI0.LPC_.EC__.AC__ dev.acpi_acad.0.%pnpinfo: _HID=ACPI0003 _UID=0 dev.acpi_acad.0.%parent: acpi0 dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 1 dev.acpi_ibm.0.eventmask: 16777215 dev.acpi_ibm.0.hotkey: 2471 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 7 dev.acpi_ibm.0.mute: 1 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 1 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 2598 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 42 39 28 48 50 -1 26 -1 dev.cpu.0.%parent: acpi0 dev.cpu.1.%parent: acpi0 dev.acpi_perf.0.%driver: acpi_perf dev.acpi_perf.0.%parent: cpu0 dev.acpi_perf.1.%driver: acpi_perf dev.acpi_perf.1.%parent: cpu1 ---- sysctl -a | grep acpi: END ---- ---- make.conf ---- CPUTYPE= nocona CFLAGS= -O2 -pipe ---- make.conf: END ---- >How-To-Repeat: /usr/sbin/acpiconf -s3 | -s4 | -s5 >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 02:20:14 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8746C1065677; Thu, 11 Dec 2008 02:20:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Wed, 10 Dec 2008 21:19:58 -0500 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> In-Reply-To: <49358684.7010508@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200812102120.03788.jkim@FreeBSD.org> Cc: Alexander Motin , peter@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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, 11 Dec 2008 02:20:14 -0000 On Tuesday 02 December 2008 02:03 pm, Alexander Motin wrote: > Hi. > > Jung-uk Kim wrote: > >> Here is problems I still have now: > >> - SMP kernel resume is not working, system reboots while doing > >> acpi_wakeup_cpus(); > > > > My dual-core CPU seems to resume okay but quite unstable. Can > > you try something like the following in amd64/mp_machdep.c and > > tell me if it helps? > > > > ------------ > > @@ -57,6 +57,7 @@ > > #include > > > > #include > > +#include > > #include > > #include > > #include > > @@ -1121,6 +1121,8 @@ > > int cpumask = PCPU_GET(cpumask); > > > > if (savectx2(&stopxpcbs[cpu])) { > > + /* Flush CPU cache. */ > > + wbinvd(); > > /* Indicate that we are suspended. */ > > atomic_set_int(&stopped_cpus, cpumask); > > } else { > > ------------ > > Wow, it works! > > I am writing this letter just after suspending/resuming my > dual-core C2D system 4 times straight. Music plays, USB, SATA, all > other hardware works fine. What kind of instability do you have? > > The only strange effect I have noticed was incorrect CPU time some > processes got: > %ps ax > PID TT STAT TIME COMMAND > 12 ?? WL 280503:38,05 [intr] > 1430 ?? Ss 280503:38,34 icewm > > But I think it is more timer driver related then resume itself. > > > Thanks for the feedback! > > Many thanks to you! I hope this long-waited feature will be > finished! FYI, I uploaded a new patch with some fixes (against today's CURRENT): http://people.freebsd.org/~jkim/amd64_suspend.diff This patch should be feature complete but I'd say it is still considered experimental as it is not properly reviewed. Now, some useful tips of the day for starters: Tip #1: Try 'sysctl debug.acpi.suspend_bounce=1" first. If it hangs, this patch won't do any good for you. Tip #2: Suspend/resume several times in single user mode first to be safe. I am sure you don't want to lose your data. ;-) Tip #3: If keyboard LEDs blink (keyboard reset) but nothing is displayed on screen, try 'sysctl hw.acpi.reset_video=1' next time. Tip #4: If #3 does not work for you, try 'vbetool post' (available from ports/sysutils/vbetool) next. It works better in some cases. Tip #5: With Xorg, it is always safe to suspend in console unless you have a hook in suspend script to do some magic. When you switch to console by pressing Ctrl+Alt+F[1-8], Xorg driver will save GPU states. After resume is complete, you can return to Xorg screen by pressing Alt-F9 later. Then, Xorg driver should restore GPU states and screen. Tip #6: If your mouse pointer does not move any more, try restarting moused by '/etc/rc.d/moused restart'. Cheers, Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 02:49:43 2008 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 C52A61065672 for ; Thu, 11 Dec 2008 02:49:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id 892568FC0C for ; Thu, 11 Dec 2008 02:49:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so661667rvf.43 for ; Wed, 10 Dec 2008 18:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ZDL0+brdl8NPk/hPUXGSk9wTWrqna+0ABjjaQ36I5X0=; b=nWFfaJIoEtYuqDWsqflgJINXk4P6wYblN/qsSSgZN7vQgh+xaOCbyLTlqq5D3GjC0P kuuopX1TH0R4cJ7qRGftzvStq5OV6kSWabEi7HxliDMYPnmbngWk+oEDWz5Rhh8jp9Dw jsRxsRoKQ9kMi5B9PrbFNR/SKsQQr3GU9JtlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dBQt46uEpURgX1ebra5eGC1vd/9H5+SQ6ZqGMoyQsnevbxMWCPo7Ndk0xDKlXVaOnU 82UEgdd1PW8oD3p13D0Y6yeGG8ShtmefAlt4hCKmty/BeU32ZKutxw5ONse2rCx1RzXu ntBHWb3jKnAgDue9VFVy2cUEDivZAMzkoP8Uw= Received: by 10.141.153.17 with SMTP id f17mr1008284rvo.99.1228963782994; Wed, 10 Dec 2008 18:49:42 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id b39sm2176657rvf.0.2008.12.10.18.49.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Dec 2008 18:49:40 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBB2nZqj042955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 11:49:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBB2nWeN042953; Thu, 11 Dec 2008 11:49:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 11 Dec 2008 11:49:32 +0900 From: Pyun YongHyeon To: Victor Balada Diaz Message-ID: <20081211024932.GC42370@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081210140823.GF1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081210140823.GF1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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: Thu, 11 Dec 2008 02:49:43 -0000 On Wed, Dec 10, 2008 at 03:08:24PM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: [...] > > > > > > It seems that your controller supports MSI so you can set a tunable > > > > > > hw.re.msi_disable to 0 to enable MSI. With MSI you can remove > > > > > > interrupt sharing(e.g. add hw.re.msi_disable="0" to > > > > > > /boot/loader.conf file.) However there were several issues on re(4) > > > > > > w.r.t MSI so it was off by default. > > > > > > > > > > This is undocumented and with sysctl -a i can't find the tunable. Is this > > > > > a HEAD feature or it's also in 7.1 -BETA2? Should i add > > > > > > > > Yeah it's an undocmented feature. But most drivers written by me > > > > have similar kobs. Both HEAD and stable/7 including 7.1 BETA2 have > > > > the tunable. > > > > > > I think it could be great if you could document it or at least > > > show it by default when you do sysctl -ad with a small description. > > > > > > > If MSI worked as expected I would have documented it as I did > > in msk(4)/nfe(4)/ale(4)/age(4)/jme(4) etc. > > Using MSI on RealTek does not seem to stable. I tried hard to fix > > that but some users still reported watchdog timeouts. Working > > without documentation and hardware also made it hard to complete > > the work. This was the main reason why MSI was disabled on re(4). > > What do you think about adding a note in the man page telling that > it's experimental and in some cases it could improve the situation > but in others it will give errors? Based on the your testing I have idea how to mitigate the missing Tx completion interrupt. If all goes well re(4) could reliably take advantage of MSI on RealTek controllers. If that miserably fail I would do as you suggested. > > > > I think re(4) in HEAD needs more testing. As you might know RealTek > > produced too many chipsets. :-( > > Ok, i'll use the backported driver as it works better for me :-) > > If i can help you testing any patches i'm more than welcome to do it. > > Thanks a lot for your help Pyun YongHyeon. > You're welcome. -- Regards, Pyun YongHyeon From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 04:50:00 2008 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 216FC1065670; Thu, 11 Dec 2008 04:50:00 +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 EE4818FC13; Thu, 11 Dec 2008 04:49:59 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mBB4nxoI060496; Thu, 11 Dec 2008 04:49:59 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mBB4nxYF060492; Thu, 11 Dec 2008 04:49:59 GMT (envelope-from linimon) Date: Thu, 11 Dec 2008 04:49:59 GMT Message-Id: <200812110449.mBB4nxYF060492@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org X-Mailman-Approved-At: Thu, 11 Dec 2008 05:31:48 +0000 Cc: Subject: Re: amd64/129563: [ACPI] sleep broken on IBM/Lenovo T61 [amd64] 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, 11 Dec 2008 04:50:00 -0000 Synopsis: [ACPI] sleep broken on IBM/Lenovo T61 [amd64] Responsible-Changed-From-To: freebsd-amd64->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 11 04:49:48 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129563 From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 09:01:08 2008 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 B1897106567C for ; Thu, 11 Dec 2008 09:01:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 79E2A8FC1F for ; Thu, 11 Dec 2008 09:01:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so770117rvf.43 for ; Thu, 11 Dec 2008 01:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fLbw/t3tzJee0Th9UJhwQrBVybeNZsoUm95H7eiAEwo=; b=Qi6VC7q68J8pz+PYbRI9wuNjZeE2lJWFRqz5Nt3cCFAb91j12Rq22srgtNj/627DX9 2HsCKO4LcS+pjk2tNa1+mHapmS55dv1PbMcD9WEtJSNOef2za1V6P/Abnp+/1w68hPRs idNoTBaHXZc5tbQ59yFWgk1Sr/4EnLQEYgAWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=QCqNST3sj4l5NzB0RciDraSzuoeAAFy1sAxWX1lyjlhGRAUlnjjfe3Wmi/vh4PKtpC Si+4XABobnxippxtCqD6fj3ivtb6GVTEYqCKxN8D97/XEQbFGiiuMCIPV30nSCfrTlk5 Qo1ZjM6AqCSQnFDhVkQjsPUDylA43s2qCYBA8= Received: by 10.141.42.10 with SMTP id u10mr1170696rvj.61.1228986068217; Thu, 11 Dec 2008 01:01:08 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k2sm1250855rvb.8.2008.12.11.01.01.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Dec 2008 01:01:07 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBB9106u044122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 18:01:00 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBB90uHg044121; Thu, 11 Dec 2008 18:00:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 11 Dec 2008 18:00:56 +0900 From: Pyun YongHyeon To: Victor Balada Diaz Message-ID: <20081211090056.GH42370@cdnetworks.co.kr> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081211081045.GJ1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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: Thu, 11 Dec 2008 09:01:08 -0000 On Thu, Dec 11, 2008 at 09:10:45AM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 08:57:07AM +0100, Victor Balada Diaz wrote: > > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > > > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > > > Also i didn't see any problem with interfaces going up and down, > > > > but that usually happen after some hours of uptime, so i'll let > > > > you know if the error happens again. > > > > > > > > After writing to the HD with dd for a few hours and using > > stress -i 10 -d 10 the machine lost connectivity. I waited until > > today to be sure if the machine hung, paniced or just lost network > > connectivity. I don't have local access or serial access, so this > > is the only way i could do it. I've seen in the logs during the > > night various messages of: > > > > > > Dec 10 00:33:49 yac kernel: re0: watchdog timeout > > Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN > > Dec 10 00:33:52 yac kernel: re0: link state changed to UP > > > > The interface never recovered and i wasn't able to ping the machine > > until i rebooted. Nagios was checking all the time and no recovery > > happened. > > > > The netstat -i in daily scripts shows just one Oerrs. I'm used to > > have a lot of them, but seems this time the card didn't recover from > > the only one. I also want to say that this is not a regression, as > > it happened before with 7.1 -BETA 2 code. > > > > Is there anything more i can try? > > Sorry it's too early in the morning and i thought today was 10 > instead of 11. I don't even know the day i'm today. > > Looking at today's log i see no link state changed messages > but i see this other messages that started happening more or > less at the same time i lost connectivity to the server: > > Dec 10 18:20:32 yac kernel: re0: link state changed to DOWN > Dec 10 18:20:32 yac kernel: re0: PHY read failed > I've reverted r185756 which caused GMII access issues on some controllers. If you are brave enough to try beta code, you can get latest re(4) in the following URL. Note, I don't have PCIe based RealTek controllers so the code was not tested at all. http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rlreg.h -- Regards, Pyun YongHyeon From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 07:57:10 2008 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 2DAD0106564A; Thu, 11 Dec 2008 07:57:10 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id C99558FC17; Thu, 11 Dec 2008 07:57:09 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id DEDBC119CF7; Thu, 11 Dec 2008 08:57:07 +0100 (CET) Date: Thu, 11 Dec 2008 08:57:07 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081211075707.GH1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081210120719.GK37837@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 11 Dec 2008 12:35:31 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 11 Dec 2008 07:57:10 -0000 On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > Also i didn't see any problem with interfaces going up and down, > > but that usually happen after some hours of uptime, so i'll let > > you know if the error happens again. > > After writing to the HD with dd for a few hours and using stress -i 10 -d 10 the machine lost connectivity. I waited until today to be sure if the machine hung, paniced or just lost network connectivity. I don't have local access or serial access, so this is the only way i could do it. I've seen in the logs during the night various messages of: Dec 10 00:33:49 yac kernel: re0: watchdog timeout Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN Dec 10 00:33:52 yac kernel: re0: link state changed to UP The interface never recovered and i wasn't able to ping the machine until i rebooted. Nagios was checking all the time and no recovery happened. The netstat -i in daily scripts shows just one Oerrs. I'm used to have a lot of them, but seems this time the card didn't recover from the only one. I also want to say that this is not a regression, as it happened before with 7.1 -BETA 2 code. Is there anything more i can try? Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 08:00:27 2008 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 CE4821065678; Thu, 11 Dec 2008 08:00:27 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0728FC12; Thu, 11 Dec 2008 08:00:27 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 8143B119CF7; Thu, 11 Dec 2008 09:00:26 +0100 (CET) Date: Thu, 11 Dec 2008 09:00:26 +0100 From: Victor Balada Diaz To: Peter Jeremy Message-ID: <20081211080026.GI1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <493F84A4.1080308@yandex.ru> <20081210091107.GC1320@alf.bsdes.net> <20081210180559.GC58682@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081210180559.GC58682@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 11 Dec 2008 12:35:40 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org, =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: Re: [ATA] and re(4) stability issues 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, 11 Dec 2008 08:00:27 -0000 On Thu, Dec 11, 2008 at 05:05:59AM +1100, Peter Jeremy wrote: > On 2008-Dec-10 10:55:35 +0100, Sren Schmidt wrote: > >And you will not use 64bit DMA even if the chipset supports it. > >However I have not seen any chipsets supporting this fail, YMMV as > >usual :) > > There's a reference in wikipedia pointing to > http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06694.html > that claims the AMD/ATI SB600 lies about supporting 64-bit DMA in AHCI > mode. I have a SB600 but it doesn't have >4GB to test on. I have 6 GB of RAM and can test patches, so once i'm done with the re(4) side of things i'll try commenting the code Soren's suggested and see if that improves the situation. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 08:10:47 2008 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 4D19D1065677; Thu, 11 Dec 2008 08:10:47 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id E36558FC1D; Thu, 11 Dec 2008 08:10:46 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id A7D6D119CF7; Thu, 11 Dec 2008 09:10:45 +0100 (CET) Date: Thu, 11 Dec 2008 09:10:45 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081211081045.GJ1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081211075707.GH1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 11 Dec 2008 12:35:47 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 11 Dec 2008 08:10:47 -0000 On Thu, Dec 11, 2008 at 08:57:07AM +0100, Victor Balada Diaz wrote: > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > > Also i didn't see any problem with interfaces going up and down, > > > but that usually happen after some hours of uptime, so i'll let > > > you know if the error happens again. > > > > > After writing to the HD with dd for a few hours and using > stress -i 10 -d 10 the machine lost connectivity. I waited until > today to be sure if the machine hung, paniced or just lost network > connectivity. I don't have local access or serial access, so this > is the only way i could do it. I've seen in the logs during the > night various messages of: > > > Dec 10 00:33:49 yac kernel: re0: watchdog timeout > Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN > Dec 10 00:33:52 yac kernel: re0: link state changed to UP > > The interface never recovered and i wasn't able to ping the machine > until i rebooted. Nagios was checking all the time and no recovery > happened. > > The netstat -i in daily scripts shows just one Oerrs. I'm used to > have a lot of them, but seems this time the card didn't recover from > the only one. I also want to say that this is not a regression, as > it happened before with 7.1 -BETA 2 code. > > Is there anything more i can try? Sorry it's too early in the morning and i thought today was 10 instead of 11. I don't even know the day i'm today. Looking at today's log i see no link state changed messages but i see this other messages that started happening more or less at the same time i lost connectivity to the server: Dec 10 18:20:32 yac kernel: re0: link state changed to DOWN Dec 10 18:20:32 yac kernel: re0: PHY read failed Sorry for the noise. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 09:50:23 2008 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 9A8C71065672; Thu, 11 Dec 2008 09:50:23 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3386C8FC19; Thu, 11 Dec 2008 09:50:22 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id C8AAD119CF7; Thu, 11 Dec 2008 10:50:21 +0100 (CET) Date: Thu, 11 Dec 2008 10:50:21 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081211095021.GL1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081211090056.GH42370@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 11 Dec 2008 12:36:31 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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, 11 Dec 2008 09:50:23 -0000 On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > On Thu, Dec 11, 2008 at 09:10:45AM +0100, Victor Balada Diaz wrote: > > On Thu, Dec 11, 2008 at 08:57:07AM +0100, Victor Balada Diaz wrote: > > > On Wed, Dec 10, 2008 at 09:07:19PM +0900, Pyun YongHyeon wrote: > > > > On Wed, Dec 10, 2008 at 12:32:25PM +0100, Victor Balada Diaz wrote: > > > > > Also i didn't see any problem with interfaces going up and down, > > > > > but that usually happen after some hours of uptime, so i'll let > > > > > you know if the error happens again. > > > > > > > > > > > After writing to the HD with dd for a few hours and using > > > stress -i 10 -d 10 the machine lost connectivity. I waited until > > > today to be sure if the machine hung, paniced or just lost network > > > connectivity. I don't have local access or serial access, so this > > > is the only way i could do it. I've seen in the logs during the > > > night various messages of: > > > > > > > > > Dec 10 00:33:49 yac kernel: re0: watchdog timeout > > > Dec 10 00:33:49 yac kernel: re0: link state changed to DOWN > > > Dec 10 00:33:52 yac kernel: re0: link state changed to UP > > > > > > The interface never recovered and i wasn't able to ping the machine > > > until i rebooted. Nagios was checking all the time and no recovery > > > happened. > > > > > > The netstat -i in daily scripts shows just one Oerrs. I'm used to > > > have a lot of them, but seems this time the card didn't recover from > > > the only one. I also want to say that this is not a regression, as > > > it happened before with 7.1 -BETA 2 code. > > > > > > Is there anything more i can try? > > > > Sorry it's too early in the morning and i thought today was 10 > > instead of 11. I don't even know the day i'm today. > > > > Looking at today's log i see no link state changed messages > > but i see this other messages that started happening more or > > less at the same time i lost connectivity to the server: > > > > Dec 10 18:20:32 yac kernel: re0: link state changed to DOWN > > Dec 10 18:20:32 yac kernel: re0: PHY read failed > > > > I've reverted r185756 which caused GMII access issues on some > controllers. If you are brave enough to try beta code, you can > get latest re(4) in the following URL. Note, I don't have PCIe > based RealTek controllers so the code was not tested at all. > > http://people.freebsd.org/~yongari/re/if_re.c > http://people.freebsd.org/~yongari/re/if_rlreg.h I've recompiled the kernel with the first file in sys/dev/re/ and the second one in sys/pci/. I'm still testing with MSI enabled. So far tried rebooting using nextboot(8) (just in case i lost the network card i could boot again) and the card seems to work but i'll continue stress testing the machine with stress + dd + iperf and see if i can take it down. I'll let you know how it goes. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 23:01:30 2008 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 9AF83106564A; Thu, 11 Dec 2008 23:01:30 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 69C508FC13; Thu, 11 Dec 2008 23:01:29 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 229547638; Fri, 12 Dec 2008 01:01:28 +0200 Message-ID: <49419BB9.8030408@FreeBSD.org> Date: Fri, 12 Dec 2008 01:01:13 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Jung-uk Kim References: <1224616985.00027652.1224606603@10.7.7.3> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> <200812102120.03788.jkim@FreeBSD.org> In-Reply-To: <200812102120.03788.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, peter@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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, 11 Dec 2008 23:01:30 -0000 Jung-uk Kim wrote: > FYI, I uploaded a new patch with some fixes (against today's CURRENT): > > http://people.freebsd.org/~jkim/amd64_suspend.diff It is still working for me. > This patch should be feature complete but I'd say it is still > considered experimental as it is not properly reviewed. This comment looks stale: /* Restore PAT and MTRRdefType. */ :) -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 11 23:17:43 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6D2F2106567A; Thu, 11 Dec 2008 23:17:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Thu, 11 Dec 2008 18:17:29 -0500 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <200812102120.03788.jkim@FreeBSD.org> <49419BB9.8030408@FreeBSD.org> In-Reply-To: <49419BB9.8030408@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200812111817.32334.jkim@FreeBSD.org> Cc: Alexander Motin , freebsd-amd64@freebsd.org, peter@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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, 11 Dec 2008 23:17:43 -0000 On Thursday 11 December 2008 06:01 pm, Alexander Motin wrote: > Jung-uk Kim wrote: > > FYI, I uploaded a new patch with some fixes (against today's > > CURRENT): > > > > http://people.freebsd.org/~jkim/amd64_suspend.diff > > It is still working for me. Good. > > This patch should be feature complete but I'd say it is still > > considered experimental as it is not properly reviewed. > > This comment looks stale: > /* Restore PAT and MTRRdefType. */ Corrected. Thanks for the feedback! Jung-uk Kim From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 12 12:13:12 2008 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 9796E1065672; Fri, 12 Dec 2008 12:13:12 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from alf.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 38A148FC16; Fri, 12 Dec 2008 12:13:11 +0000 (UTC) (envelope-from victor@bsdes.net) Received: by alf.bsdes.net (Postfix, from userid 1001) id 00184119CF7; Fri, 12 Dec 2008 13:13:09 +0100 (CET) Date: Fri, 12 Dec 2008 13:13:09 +0100 From: Victor Balada Diaz To: Pyun YongHyeon Message-ID: <20081212121309.GM1320@alf.bsdes.net> References: <20081209185236.GA1320@alf.bsdes.net> <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20081211095021.GL1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 12 Dec 2008 12:47:25 +0000 Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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: Fri, 12 Dec 2008 12:13:12 -0000 On Thu, Dec 11, 2008 at 10:50:21AM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > > > > I've reverted r185756 which caused GMII access issues on some > > controllers. If you are brave enough to try beta code, you can > > get latest re(4) in the following URL. Note, I don't have PCIe > > based RealTek controllers so the code was not tested at all. > > > > http://people.freebsd.org/~yongari/re/if_re.c > > http://people.freebsd.org/~yongari/re/if_rlreg.h > > I've recompiled the kernel with the first file in sys/dev/re/ > and the second one in sys/pci/. I'm still testing with MSI enabled. > > So far tried rebooting using nextboot(8) (just in case i lost the > network card i could boot again) and the card seems to work > but i'll continue stress testing the machine with stress + dd + > iperf and see if i can take it down. I'll let you know how it goes. After a day of stress testing the machine haven't got errors, interrupt storms or interface up/down problems. Everything seems fine. I'll continue stress testing the machine during the weekend, but i would say that this time it's fixed. Seems lately there have been a lot of testing of this driver. Is there any chance of it being on 7.1 or being MFCed after the release to RELENG_7? Thanks a lot. Regards. -- La prueba ms fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 12 12:29:39 2008 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 EFB871065672 for ; Fri, 12 Dec 2008 12:29:39 +0000 (UTC) (envelope-from gofda-freebsd-amd64@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A78DB8FC2A for ; Fri, 12 Dec 2008 12:29:39 +0000 (UTC) (envelope-from gofda-freebsd-amd64@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LB6v9-0002bN-J3 for freebsd-amd64@freebsd.org; Fri, 12 Dec 2008 12:15:03 +0000 Received: from firewall.andxor.it ([195.223.2.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Dec 2008 12:15:03 +0000 Received: from lapo by firewall.andxor.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Dec 2008 12:15:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-amd64@freebsd.org From: Lapo Luchini Date: Fri, 12 Dec 2008 13:00:41 +0100 Lines: 61 Message-ID: References: <32d8477c0612301410q2aaf9d39k859d242739554fd6@mail.gmail.com> <20061231003901.GA76688@slackbox.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: firewall.andxor.it User-Agent: Thunderbird 2.0.0.18 (X11/20081202) In-Reply-To: <20061231003901.GA76688@slackbox.xs4all.nl> X-Enigmail-Version: 0.95.7 OpenPGP: id=C8F252FB Sender: news X-Mailman-Approved-At: Fri, 12 Dec 2008 12:47:40 +0000 Subject: WINE in jail [Was: i386_set_ldt and wine on AMD64] 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: Fri, 12 Dec 2008 12:29:40 -0000 Roland Smith wrote: > On Sat, Dec 30, 2006 at 05:10:08PM -0500, Siavosh Benabbas wrote: >> Hi, >> I know that this is brought up several time on this list, but I wanted to >> run wine on my FreeBSD AMD64 machine. >> I know that a 64-bit wine is nearly impossible but I thought that an i386 >> compilation should work. > > You'd need a cross-compiler to start with. That's the easy part. > > Then you'd need ports infrastructure to compile 32-bit ports on amd64. Easiest approach to avoid that part seems to be seting up a full i386 jail inside the amd64 host, and install WINE normally from the ports. >From man jail(8): host# D=/here/is/the/jail host# cd /usr/src host# mkdir -p $D host# make world DESTDIR=$D host# make distribution DESTDIR=$D host# mount -t devfs devfs $D/dev But as suggested here I actually: host# make world distribution TARGET_ARCH=i386 TARGET=i386 DESTDIR=$D host# ln -s ld-elf.so.1 $D/libexec/ld-elf32.so.1 Then added IP alias for jail use, set up a unionfs over ports (to avoid having them double) and can correctly login in the jail: host# ifconfig em0 inet $IP/32 alias host# mount -t unionfs -o noatime,below /usr/ports $D/usr/ports host# jail $D $HOSTNAME $IP /bin/tcsh >From there I normally installed WINE: jail# cd /usr/ports/emulatos/wine jail# make install clean …but then it just “bus error” dumps on me… something to do with LDT: jail# winecfg Bus error (core dumped) jail# gdb `which wine-pthread` wine-pthread.core (gdb) bt #0 0x7df3b2e9 in wine_ldt_init_fs () from /usr/local/lib/libwine.so.1 #1 0x7bf00fb3 in init_pthread_functions () #2 0x7e36a81f in thread_init () from /usr/local/lib/wine/ntdll.dll.so #3 0x7e345d98 in __wine_process_init () from /usr/local/lib/wine/ntdll.dll.so #4 0x7df3bd74 in wine_init () from /usr/local/lib/libwine.so.1 #5 0x7df571eb in wine_casemap_upper () from /usr/local/lib/libwine.so.1 -- Lapo Luchini - http://lapo.it/ “Beware of bugs in the above code; I have only proved it correct, not tried it.” (Donald Knuth, 1977-03-22) From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 12 13:41:41 2008 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 4E12F106567A for ; Fri, 12 Dec 2008 13:41:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E00AF8FC23 for ; Fri, 12 Dec 2008 13:41:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LB7j2-0004Tc-2E; Fri, 12 Dec 2008 15:06:36 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBCD6WPP059274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 15:06:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBCD6W4C094057; Fri, 12 Dec 2008 15:06:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBCD6WFi094056; Fri, 12 Dec 2008 15:06:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Dec 2008 15:06:32 +0200 From: Kostik Belousov To: Lapo Luchini Message-ID: <20081212130631.GC2038@deviant.kiev.zoral.com.ua> References: <32d8477c0612301410q2aaf9d39k859d242739554fd6@mail.gmail.com> <20061231003901.GA76688@slackbox.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YyEPptUYZmwjRdlG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LB7j2-0004Tc-2E 44053b7b5e381d06af84f48f1f78f19c X-Terabit: YES Cc: freebsd-amd64@freebsd.org Subject: Re: WINE in jail [Was: i386_set_ldt and wine on AMD64] 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: Fri, 12 Dec 2008 13:41:41 -0000 --YyEPptUYZmwjRdlG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 12, 2008 at 01:00:41PM +0100, Lapo Luchini wrote: > Roland Smith wrote: > > On Sat, Dec 30, 2006 at 05:10:08PM -0500, Siavosh Benabbas wrote: > >> Hi, > >> I know that this is brought up several time on this list, but I wanted= to > >> run wine on my FreeBSD AMD64 machine. > >> I know that a 64-bit wine is nearly impossible but I thought that an i= 386 > >> compilation should work. > >=20 > > You'd need a cross-compiler to start with. That's the easy part. > >=20 > > Then you'd need ports infrastructure to compile 32-bit ports on amd64. >=20 > Easiest approach to avoid that part seems to be seting up a full i386 > jail inside the amd64 host, and install WINE normally from the ports. >=20 > >From man jail(8): >=20 > host# D=3D/here/is/the/jail > host# cd /usr/src > host# mkdir -p $D > host# make world DESTDIR=3D$D > host# make distribution DESTDIR=3D$D > host# mount -t devfs devfs $D/dev >=20 > But as suggested here I actually: >=20 > host# make world distribution TARGET_ARCH=3Di386 TARGET=3Di386 DESTDIR= =3D$D > host# ln -s ld-elf.so.1 $D/libexec/ld-elf32.so.1 This is not needed on recent HEAD or RELENG_7. >=20 > Then added IP alias for jail use, set up a unionfs over ports (to avoid > having them double) and can correctly login in the jail: >=20 > host# ifconfig em0 inet $IP/32 alias > host# mount -t unionfs -o noatime,below /usr/ports $D/usr/ports > host# jail $D $HOSTNAME $IP /bin/tcsh >=20 > >From there I normally installed WINE: >=20 > jail# cd /usr/ports/emulatos/wine > jail# make install clean >=20 > ???but then it just ???bus error??? dumps on me??? something to do with L= DT: >=20 > jail# winecfg > Bus error (core dumped) > jail# gdb `which wine-pthread` wine-pthread.core > (gdb) bt > #0 0x7df3b2e9 in wine_ldt_init_fs () from /usr/local/lib/libwine.so.1 > #1 0x7bf00fb3 in init_pthread_functions () > #2 0x7e36a81f in thread_init () from /usr/local/lib/wine/ntdll.dll.so > #3 0x7e345d98 in __wine_process_init () from > /usr/local/lib/wine/ntdll.dll.so > #4 0x7df3bd74 in wine_init () from /usr/local/lib/libwine.so.1 > #5 0x7df571eb in wine_casemap_upper () from > /usr/local/lib/libwine.so.1 Hmm, so you have a wine on amd64 and willingness to test ? Please, try http://people.freebsd.org/~kib/misc/amd64_ldt.2.patch patch is against HEAD. --YyEPptUYZmwjRdlG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklCYdcACgkQC3+MBN1Mb4jLPACg149nVupTP/+Fe65IC/Rhm+fa jbMAoJ9LLC/h/r8jyX2Jw2t1zWdU2m8Q =fBjH -----END PGP SIGNATURE----- --YyEPptUYZmwjRdlG-- From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 12 14:50:23 2008 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 0C649106564A for ; Fri, 12 Dec 2008 14:50:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A5DB38FC17 for ; Fri, 12 Dec 2008 14:50:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LB9LP-000GVe-9q; Fri, 12 Dec 2008 16:50:20 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mBCEoFAO066875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 16:50:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mBCEoFgF064338; Fri, 12 Dec 2008 16:50:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mBCEoFht064337; Fri, 12 Dec 2008 16:50:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Dec 2008 16:50:15 +0200 From: Kostik Belousov To: Lapo Luchini Message-ID: <20081212145015.GE2038@deviant.kiev.zoral.com.ua> References: <32d8477c0612301410q2aaf9d39k859d242739554fd6@mail.gmail.com> <20061231003901.GA76688@slackbox.xs4all.nl> <20081212130631.GC2038@deviant.kiev.zoral.com.ua> <49427649.20006@lapo.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EzoGi9kFQAnUjl0a" Content-Disposition: inline In-Reply-To: <49427649.20006@lapo.it> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LB9LP-000GVe-9q 6c8adad828170c8f14b3a134cb97ff5b X-Terabit: YES Cc: Andriy Gapon , freebsd-amd64@freebsd.org Subject: Re: WINE in jail [Was: i386_set_ldt and wine on AMD64] 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: Fri, 12 Dec 2008 14:50:23 -0000 --EzoGi9kFQAnUjl0a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 12, 2008 at 03:33:45PM +0100, Lapo Luchini wrote: > Kostik Belousov wrote: > > Hmm, so you have a wine on amd64 and willingness to test ? > > Please, try > > http://people.freebsd.org/~kib/misc/amd64_ldt.2.patch > > patch is against HEAD. The right URL is http://people.freebsd.org/~kib/misc/amd64_ctx.2.patch >=20 > Here in the office I've got a 7.0-RELEASE-p6 (updated with > freebsd-update binary updates) and I'm not willing to test a patch > against -CURRENT on it, but I may consider configuring a different host > at home just for the sake of testing it??? is the patch simply against > HEAD by accident or does really depend on changes that are not available > in 7-STABLE? I do not think that there is anything that prevents it from being backported to 7, but probably it would require some handwork for merge. You can install only HEAD kernel on the 7 machine, it should work with RELENG_7 world. --EzoGi9kFQAnUjl0a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklCeiYACgkQC3+MBN1Mb4hl7ACg7mdybRnUWseznjlYxTSJ2jK/ FcQAn15jdIDgBLa59dsQNiGZAAjWh5Jp =8Hvx -----END PGP SIGNATURE----- --EzoGi9kFQAnUjl0a-- From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 12 15:00:35 2008 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 F34C1106564A for ; Fri, 12 Dec 2008 15:00:35 +0000 (UTC) (envelope-from lapo@lapo.it) Received: from mail.lapo.it (motoko.lapo.it [88.198.0.105]) by mx1.freebsd.org (Postfix) with ESMTP id 447FA8FC08 for ; Fri, 12 Dec 2008 15:00:34 +0000 (UTC) (envelope-from lapo@lapo.it) Received: (qmail 11183 invoked by uid 89); 12 Dec 2008 14:33:53 -0000 Received: from unknown (HELO lapo.andxor.it) (lapo@lapo.it@195.223.2.2) by 0 with ESMTPA; 12 Dec 2008 14:33:53 -0000 Message-ID: <49427649.20006@lapo.it> Date: Fri, 12 Dec 2008 15:33:45 +0100 From: Lapo Luchini User-Agent: Thunderbird 2.0.0.18 (X11/20081202) MIME-Version: 1.0 To: Kostik Belousov References: <32d8477c0612301410q2aaf9d39k859d242739554fd6@mail.gmail.com> <20061231003901.GA76688@slackbox.xs4all.nl> <20081212130631.GC2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20081212130631.GC2038@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.7 OpenPGP: id=C8F252FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-amd64@freebsd.org Subject: Re: WINE in jail [Was: i386_set_ldt and wine on AMD64] 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: Fri, 12 Dec 2008 15:00:36 -0000 Kostik Belousov wrote: > Hmm, so you have a wine on amd64 and willingness to test ? > Please, try > http://people.freebsd.org/~kib/misc/amd64_ldt.2.patch > patch is against HEAD. Here in the office I've got a 7.0-RELEASE-p6 (updated with freebsd-update binary updates) and I'm not willing to test a patch against -CURRENT on it, but I may consider configuring a different host at home just for the sake of testing it… is the patch simply against HEAD by accident or does really depend on changes that are not available in 7-STABLE? -- Lapo Luchini - http://lapo.it/ “Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things.” (Robert A. Heinlein, 1973) From owner-freebsd-amd64@FreeBSD.ORG Fri Dec 12 13:50:33 2008 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 C40841065670 for ; Fri, 12 Dec 2008 13:50:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E191D8FC2A for ; Fri, 12 Dec 2008 13:50:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA06609; Fri, 12 Dec 2008 15:50:28 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49426C23.10905@icyb.net.ua> Date: Fri, 12 Dec 2008 15:50:27 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Kostik Belousov References: <32d8477c0612301410q2aaf9d39k859d242739554fd6@mail.gmail.com> <20061231003901.GA76688@slackbox.xs4all.nl> <20081212130631.GC2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20081212130631.GC2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 12 Dec 2008 18:31:43 +0000 Cc: Lapo Luchini , freebsd-amd64@freebsd.org Subject: Re: WINE in jail [Was: i386_set_ldt and wine on AMD64] 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: Fri, 12 Dec 2008 13:50:33 -0000 on 12/12/2008 15:06 Kostik Belousov said the following: > > Hmm, so you have a wine on amd64 and willingness to test ? > Please, try > http://people.freebsd.org/~kib/misc/amd64_ldt.2.patch > patch is against HEAD. Kostik, I also want to try your patch some time next week, but it seems that the URL has mistake - I got 404. Going to parent directory I see the following similarly named files: amd64_ldt-pre.1.patch amd64_ldt-pre.2.patch amd64_ldt-pre.3.patch amd64_ldt-pre.4.patch -- Andriy Gapon From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 13 01:42:40 2008 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 5074D1065677 for ; Sat, 13 Dec 2008 01:42:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 13D238FC16 for ; Sat, 13 Dec 2008 01:42:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1622648rvf.43 for ; Fri, 12 Dec 2008 17:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=lVP4K4mXRj3wQLrmGNDMdHgijB5umrLbVef9/DBwrbo=; b=AS3cnxPahX7V5u6igX6dOfZs9gompVp8FIRRNb2nWHNiXfjh/XncqBgfp87/0VZDvC QatoP58PevhhDYwfqS48t0vs1cUIVc5V0lrzj0d/U5qvFneSX6nnNKc/xC+33imNovSs mdIUjT93tDzh62rONluab1yUB7iHOk2USk7Fc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=h1ZF1/cgJt7A2O/Ql/B9h6CjKyGSoyTodrYygjAbGCZqA6cweoEn2BT/mDlT+boYnx yakClJgZLGIQth+L7+mlCvJuBrSE2cEOQipWWRiuqlx/n4erGMntGmGwzNHCDZBeveI6 zLKCyDlQMVUmvqqo+aE9hoRen2ijUW35GnwxM= Received: by 10.141.162.1 with SMTP id p1mr2219273rvo.190.1229132559724; Fri, 12 Dec 2008 17:42:39 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k41sm1776841rvb.6.2008.12.12.17.42.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Dec 2008 17:42:38 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mBD1gWgT051540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Dec 2008 10:42:32 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mBD1gT3E051539; Sat, 13 Dec 2008 10:42:29 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 13 Dec 2008 10:42:29 +0900 From: Pyun YongHyeon To: Victor Balada Diaz Message-ID: <20081213014229.GC51320@cdnetworks.co.kr> References: <20081210061226.GC37837@cdnetworks.co.kr> <20081210085934.GB1320@alf.bsdes.net> <20081210102800.GH37837@cdnetworks.co.kr> <20081210113225.GD1320@alf.bsdes.net> <20081210120719.GK37837@cdnetworks.co.kr> <20081211075707.GH1320@alf.bsdes.net> <20081211081045.GJ1320@alf.bsdes.net> <20081211090056.GH42370@cdnetworks.co.kr> <20081211095021.GL1320@alf.bsdes.net> <20081212121309.GM1320@alf.bsdes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212121309.GM1320@alf.bsdes.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [ATA] and re(4) stability issues 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: Sat, 13 Dec 2008 01:42:40 -0000 On Fri, Dec 12, 2008 at 01:13:09PM +0100, Victor Balada Diaz wrote: > On Thu, Dec 11, 2008 at 10:50:21AM +0100, Victor Balada Diaz wrote: > > On Thu, Dec 11, 2008 at 06:00:56PM +0900, Pyun YongHyeon wrote: > > > > > > I've reverted r185756 which caused GMII access issues on some > > > controllers. If you are brave enough to try beta code, you can > > > get latest re(4) in the following URL. Note, I don't have PCIe > > > based RealTek controllers so the code was not tested at all. > > > > > > http://people.freebsd.org/~yongari/re/if_re.c > > > http://people.freebsd.org/~yongari/re/if_rlreg.h > > > > I've recompiled the kernel with the first file in sys/dev/re/ > > and the second one in sys/pci/. I'm still testing with MSI enabled. > > > > So far tried rebooting using nextboot(8) (just in case i lost the > > network card i could boot again) and the card seems to work > > but i'll continue stress testing the machine with stress + dd + > > iperf and see if i can take it down. I'll let you know how it goes. > > After a day of stress testing the machine haven't got errors, interrupt > storms or interface up/down problems. Everything seems fine. > I'll continue stress testing the machine during the weekend, but > i would say that this time it's fixed. > Thanks for testing! > Seems lately there have been a lot of testing of this driver. Is > there any chance of it being on 7.1 or being MFCed after the release > to RELENG_7? > It's too early to say MFC but I think MFC would be done after releasing 7.1-RELEASE if all goes well. -- Regards, Pyun YongHyeon From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 13 20:06:52 2008 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 78BC81065672; Sat, 13 Dec 2008 20:06:52 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1DF8FC26; Sat, 13 Dec 2008 20:06:51 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (HELO mavbook.mavhome.dp.ua) by mail.alkar.net (CommuniGate Pro SMTP 5.2.10) with ESMTPS id 1759883591; Sat, 13 Dec 2008 22:06:50 +0200 Message-ID: <494415D8.4090904@FreeBSD.org> Date: Sat, 13 Dec 2008 22:06:48 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Alex Keda References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <4944115C.5020403@lissyara.su> In-Reply-To: <4944115C.5020403@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Sat, 13 Dec 2008 20:06:52 -0000 Alex Keda wrote: > I trie it with my HP Compaq 6715s > sleep OK, but after press power button, for wake up, i see blue screen, > and nothing... After hard reset, I have im /var/log/messages: > > Dec 13 22:35:19 acer acpi: suspend at 20081213 22:35:19 > Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 0, > val 32768) > Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 0, val > 0xffffffff) > Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 24, > val 0xffffffff) > Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 16, > val 0xffffffff) > Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 16, > val 0) > Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 23, > val 18) > Dec 13 22:35:31 acer kernel: bge0: RX CPU self-diagnostics failed! > Dec 13 22:35:31 acer kernel: bge0: flow-through queue init failed > Dec 13 22:35:31 acer kernel: bge0: initialization failure Just interesting, how hostname "acer" related to "HP Compaq 6715s"? It's just a coincidence? :) I have Acer TM6292 notebook with bge LAN. And my bge works fine after resume. The only specific of my notebook is that it's BIOS does not allocate resources for PCIe bridges. FreeBSD also unable to do it, so now I have to use dirty hack to initialize them. I think I have seen alike bge messages (but without reboot) when that hack was working only on boot, but not restoring PCIe bridges state on resume. > Dec 13 22:40:52 acer savecore: reboot after panic: page fault > Dec 13 22:40:52 acer savecore: writing core to vmcore.9 Core is good. May be it can be debugged? -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 13 20:22:36 2008 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 528C01065678; Sat, 13 Dec 2008 20:22:36 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 027AB8FC17; Sat, 13 Dec 2008 20:22:35 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.149.118] (port=63211 helo=acer.lissyara.int.otradno.ru) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LBaSi-000Njp-NH; Sat, 13 Dec 2008 22:47:40 +0300 Message-ID: <4944115C.5020403@lissyara.su> Date: Sat, 13 Dec 2008 22:47:40 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.18) Gecko/20081124 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> In-Reply-To: <4932F34C.1040804@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: peter@freebsd.org, freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Sat, 13 Dec 2008 20:22:36 -0000 Alexander Motin пишет: > Hi. > > Alexander Motin wrote: >> Jung-uk Kim wrote: >>> I was working on suspend/resume support for amd64 and this is the >>> result. It works with a modified QEMU (QEMU does not support S3) but >>> real boxes that I have don't seem to like it (e.g., broken BIOSes). >>> If there is someone interested in finishing it off or giving it a >>> try, the patch is here: >>> >>> http://people.freebsd.org/~jkim/amd64_suspend.diff I trie it with my HP Compaq 6715s sleep OK, but after press power button, for wake up, i see blue screen, and nothing... After hard reset, I have im /var/log/messages: Dec 13 22:35:19 acer acpi: suspend at 20081213 22:35:19 Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Dec 13 22:35:31 acer kernel: bge0: RX CPU self-diagnostics failed! Dec 13 22:35:31 acer kernel: bge0: flow-through queue init failed Dec 13 22:35:31 acer kernel: bge0: initialization failure and Dec 13 22:40:52 acer savecore: reboot after panic: page fault Dec 13 22:40:52 acer savecore: writing core to vmcore.9 ============= acer$ uname -a FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 13 22:29:48 MSK 2008 lissyara@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/color-console amd64 From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 13 20:41:05 2008 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 7291C1065672; Sat, 13 Dec 2008 20:41:05 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id F01588FC20; Sat, 13 Dec 2008 20:41:04 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.145.60] (port=37957 helo=acer.lissyara.int.otradno.ru) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LBbIM-0009wp-VZ; Sat, 13 Dec 2008 23:41:03 +0300 Message-ID: <49441DDE.2010706@lissyara.su> Date: Sat, 13 Dec 2008 23:41:02 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.18) Gecko/20081124 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin , freebsd-amd64@freebsd.org, freebsd-acpi@freebsd.org, peter@freebsd.org References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <4944115C.5020403@lissyara.su> In-Reply-To: <4944115C.5020403@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: Re: Semi-working patch for amd64 suspend/resume 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: Sat, 13 Dec 2008 20:41:05 -0000 Alex Keda пишет: > Alexander Motin пишет: > > Hi. > > > > Alexander Motin wrote: > >> Jung-uk Kim wrote: > >>> I was working on suspend/resume support for amd64 and this is the > >>> result. It works with a modified QEMU (QEMU does not support S3) but > >>> real boxes that I have don't seem to like it (e.g., broken BIOSes). > >>> If there is someone interested in finishing it off or giving it a > >>> try, the patch is here: > >>> > >>> http://people.freebsd.org/~jkim/amd64_suspend.diff > I trie it with my HP Compaq 6715s > sleep OK, but after press power button, for wake up, i see blue screen, sorry, read as 'dark screen' - no video... From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 13 20:53:27 2008 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 337941065670; Sat, 13 Dec 2008 20:53:27 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id B7DD18FC18; Sat, 13 Dec 2008 20:53:26 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.145.60] (port=29031 helo=acer.lissyara.int.otradno.ru) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LBbUK-000CY1-Ir; Sat, 13 Dec 2008 23:53:25 +0300 Message-ID: <494420C4.80702@lissyara.su> Date: Sat, 13 Dec 2008 23:53:24 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.18) Gecko/20081124 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Alexander Motin References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <4944115C.5020403@lissyara.su> In-Reply-To: <4944115C.5020403@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org, peter@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Sat, 13 Dec 2008 20:53:27 -0000 Alex Keda пишет: > Alexander Motin пишет: > > Hi. > > > > Alexander Motin wrote: > >> Jung-uk Kim wrote: > >>> I was working on suspend/resume support for amd64 and this is the > >>> result. It works with a modified QEMU (QEMU does not support S3) but > >>> real boxes that I have don't seem to like it (e.g., broken BIOSes). > >>> If there is someone interested in finishing it off or giving it a > >>> try, the patch is here: > >>> > >>> http://people.freebsd.org/~jkim/amd64_suspend.diff > I trie it with my HP Compaq 6715s > sleep OK, but after press power button, for wake up, i see blue screen, > and nothing... After hard reset, I have im /var/log/messages: > > > Dec 13 22:35:19 acer acpi: suspend at 20081213 22:35:19 > Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 0, > val 32768) > Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 0, val > 0xffffffff) > Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 24, > val 0xffffffff) > Dec 13 22:35:31 acer kernel: bge0: PHY read timed out (phy 1, reg 16, > val 0xffffffff) > Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 16, > val 0) > Dec 13 22:35:31 acer kernel: bge0: PHY write timed out (phy 1, reg 23, > val 18) > Dec 13 22:35:31 acer kernel: bge0: RX CPU self-diagnostics failed! > Dec 13 22:35:31 acer kernel: bge0: flow-through queue init failed > Dec 13 22:35:31 acer kernel: bge0: initialization failure > > and > > Dec 13 22:40:52 acer savecore: reboot after panic: page fault > Dec 13 22:40:52 acer savecore: writing core to vmcore.9 > ============= > acer$ uname -a > FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #0: > Sat Dec 13 22:29:48 MSK 2008 > lissyara@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/color-console > amd64 may be it useful... acer# kgdb -q /boot/kernel/kernel vmcore.9 Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. ... skip .... Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xffffffff80528008 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8052844c in panic (fmt=0xffffffff808a4cbc "%s") at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff807e4ca8 in trap_fatal (frame=0xffffff0001345720, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:759 #4 0xffffffff807e5074 in trap_pfault (frame=0xfffffffe4005ba20, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:675 #5 0xffffffff807e5970 in trap (frame=0xfffffffe4005ba20) at /usr/src/sys/amd64/amd64/trap.c:444 #6 0xffffffff807c80ae in calltrap () at /usr/src/sys/amd64/amd64/exception.S:217 #7 0xffffffff80551631 in device_attach (dev=0xffffff000772fb00) at bus_if.h:46 #8 0xffffffff805529ea in bus_generic_attach (dev=Variable "dev" is not available. ) at /usr/src/sys/kern/subr_bus.c:2953 #9 0xffffffff8024c2f7 in ata_identify (dev=0xffffff0001559a00) at /usr/src/sys/dev/ata/ata-all.c:713 #10 0xffffffff80254d22 in ata_sata_phy_event (context=Variable "context" is not available. ) at /usr/src/sys/dev/ata/ata-sata.c:69 #11 0xffffffff8056155a in taskqueue_run (queue=0xffffff0001499780) at /usr/src/sys/kern/subr_taskqueue.c:282 #12 0xffffffff80561802 in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/subr_taskqueue.c:403 #13 0xffffffff805069c8 in fork_exit (callout=0xffffffff80561790 , arg=0xffffffff80b6b250, frame=0xfffffffe4005bc90) at /usr/src/sys/kern/kern_fork.c:821 #14 0xffffffff807c84be in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:521 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000e8a000 in ?? () #40 0x000000000000000b in ?? () ---Type to continue, or q to quit--- #41 0xffffffff80b4f880 in affinity () #42 0xffffffff80b4f880 in affinity () #43 0xffffff0001345720 in ?? () #44 0xfffffffe4005b240 in ?? () #45 0xfffffffe4005b1f8 in ?? () #46 0xffffff0001346720 in ?? () #47 0xffffffff8054abad in sched_switch (td=0xffffffff80561790, newtd=0xffffffff80b6b250, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) quit ================================================= acer# dmesg | grep ata atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: port not implemented ata3: [ITHREAD] ata4: on atapci0 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci0 ata5: port not implemented ata5: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] acd0: DVDR at ata0-master PIO4 ad4: 152627MB at ata2-master SATA300 cd0 at ata0 bus 0 target 0 lun 0 acer# From owner-freebsd-amd64@FreeBSD.ORG Sat Dec 13 21:04:55 2008 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 045341065673; Sat, 13 Dec 2008 21:04:55 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi025.prodigy.net (nlpi025.sbcis.sbc.com [207.115.36.54]) by mx1.freebsd.org (Postfix) with ESMTP id C90418FC25; Sat, 13 Dec 2008 21:04:54 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-0-155.dsl.snfc21.pacbell.net [71.139.0.155]) (authenticated bits=0) by nlpi025.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id mBDL4qP6031167; Sat, 13 Dec 2008 15:04:53 -0600 Message-ID: <49442375.4010401@root.org> Date: Sat, 13 Dec 2008 13:04:53 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alex Keda References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <4944115C.5020403@lissyara.su> <494420C4.80702@lissyara.su> In-Reply-To: <494420C4.80702@lissyara.su> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 13 Dec 2008 21:27:09 +0000 Cc: Alexander Motin , freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Sat, 13 Dec 2008 21:04:55 -0000 Alex Keda wrote: >> Dec 13 22:40:52 acer savecore: reboot after panic: page fault >> Dec 13 22:40:52 acer savecore: writing core to vmcore.9 >> ============= >> acer$ uname -a >> FreeBSD acer.lissyara.int.otradno.ru 8.0-CURRENT FreeBSD 8.0-CURRENT >> #0: Sat Dec 13 22:29:48 MSK 2008 >> lissyara@acer.lissyara.int.otradno.ru:/usr/obj/usr/src/sys/color-console >> amd64 > > may be it useful... > > acer# kgdb -q /boot/kernel/kernel vmcore.9 > Reading symbols from /boot/kernel/sound.ko...Reading symbols from > /boot/kernel/sound.ko.symbols...done. > done. > ... skip .... > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /boot/kernel/drm.ko...Reading symbols from > /boot/kernel/drm.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/drm.ko > #0 doadump () at pcpu.h:196 > 196 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xffffffff80528008 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xffffffff8052844c in panic (fmt=0xffffffff808a4cbc "%s") at > /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xffffffff807e4ca8 in trap_fatal (frame=0xffffff0001345720, > eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:759 > #4 0xffffffff807e5074 in trap_pfault (frame=0xfffffffe4005ba20, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:675 > #5 0xffffffff807e5970 in trap (frame=0xfffffffe4005ba20) at > /usr/src/sys/amd64/amd64/trap.c:444 > #6 0xffffffff807c80ae in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:217 > #7 0xffffffff80551631 in device_attach (dev=0xffffff000772fb00) at > bus_if.h:46 > #8 0xffffffff805529ea in bus_generic_attach (dev=Variable "dev" is not > available. > ) at /usr/src/sys/kern/subr_bus.c:2953 > #9 0xffffffff8024c2f7 in ata_identify (dev=0xffffff0001559a00) at > /usr/src/sys/dev/ata/ata-all.c:713 > #10 0xffffffff80254d22 in ata_sata_phy_event (context=Variable "context" > is not available. > ) at /usr/src/sys/dev/ata/ata-sata.c:69 > #11 0xffffffff8056155a in taskqueue_run (queue=0xffffff0001499780) at > /usr/src/sys/kern/subr_taskqueue.c:282 > #12 0xffffffff80561802 in taskqueue_thread_loop (arg=Variable "arg" is > not available. > ) at /usr/src/sys/kern/subr_taskqueue.c:403 > #13 0xffffffff805069c8 in fork_exit (callout=0xffffffff80561790 > , arg=0xffffffff80b6b250, frame=0xfffffffe4005bc90) > at /usr/src/sys/kern/kern_fork.c:821 > #14 0xffffffff807c84be in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:521 > #15 0x0000000000000000 in ?? () > acer# dmesg | grep ata > atapci0: port > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f > mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 4 ports PM not supported > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: port not implemented > ata3: [ITHREAD] > ata4: on atapci0 > ata4: port not implemented > ata4: [ITHREAD] > ata5: on atapci0 > ata5: port not implemented > ata5: [ITHREAD] > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 > on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > acd0: DVDR at ata0-master PIO4 > ad4: 152627MB at ata2-master SATA300 > cd0 at ata0 bus 0 target 0 lun 0 ATA should be disabling its SATA PHY task during suspend, then re-enabling it after resume. Looks like it doesn't do this. -- Nate