From owner-freebsd-i386@FreeBSD.ORG Sun Feb 3 10:20:03 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D8A16A417; Sun, 3 Feb 2008 10:20:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3001813C461; Sun, 3 Feb 2008 10:19:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m13AJvwU005378; Sun, 3 Feb 2008 05:19:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.1) with ESMTP id m13AJv98097565; Sun, 3 Feb 2008 05:19:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E398F73039; Sun, 3 Feb 2008 05:19:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080203101956.E398F73039@freebsd-current.sentex.ca> Date: Sun, 3 Feb 2008 05:19:56 -0500 (EST) X-Virus-Scanned: ClamAV 0.92/5493/Thu Jan 17 13:09:26 2008 clamav-milter version 0.91.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 10:20:03 -0000 TB --- 2008-02-03 09:02:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-03 09:02:46 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-03 09:02:46 - cleaning the object tree TB --- 2008-02-03 09:03:18 - cvsupping the source tree TB --- 2008-02-03 09:03:18 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-03 09:03:24 - building world (CFLAGS=-O -pipe) TB --- 2008-02-03 09:03:24 - cd /src TB --- 2008-02-03 09:03:24 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 3 09:03:26 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 3 10:03:58 UTC 2008 TB --- 2008-02-03 10:03:58 - generating LINT kernel config TB --- 2008-02-03 10:03:58 - cd /src/sys/i386/conf TB --- 2008-02-03 10:03:58 - /usr/bin/make -B LINT TB --- 2008-02-03 10:03:59 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-03 10:03:59 - cd /src TB --- 2008-02-03 10:03:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 3 10:03:59 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp_pci.c ld -d -warn-common -r -d -o rp.kld rp.o rp_pci.o :> export_syms awk -f /src/sys/modules/rp/../../conf/kmod_syms.awk rp.kld export_syms | xargs -J% objcopy % rp.kld ld -Bshareable -d -warn-common -o rp.ko rp.kld objcopy --strip-debug rp.ko ===> rr232x (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-03 10:19:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-03 10:19:56 - ERROR: failed to build lint kernel TB --- 2008-02-03 10:19:56 - tinderbox aborted TB --- 3534.18 user 410.66 system 4630.22 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Sun Feb 3 11:04:36 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAB816A417; Sun, 3 Feb 2008 11:04:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EBB3F13C44B; Sun, 3 Feb 2008 11:04:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m13B4Z2o063045; Sun, 3 Feb 2008 06:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m13B4ZoK050613; Sun, 3 Feb 2008 06:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 16E341B5078; Sun, 3 Feb 2008 06:04:35 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080203110435.16E341B5078@freebsd-stable.sentex.ca> Date: Sun, 3 Feb 2008 06:04:35 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 11:04:36 -0000 TB --- 2008-02-03 09:40:09 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-03 09:40:09 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-02-03 09:40:09 - cleaning the object tree TB --- 2008-02-03 09:40:31 - cvsupping the source tree TB --- 2008-02-03 09:40:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-02-03 09:40:37 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-03 09:40:37 - cd /src TB --- 2008-02-03 09:40:37 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 3 09:40:38 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 3 10:42:58 UTC 2008 TB --- 2008-02-03 10:42:58 - generating LINT kernel config TB --- 2008-02-03 10:42:58 - cd /src/sys/i386/conf TB --- 2008-02-03 10:42:58 - /usr/bin/make -B LINT TB --- 2008-02-03 10:42:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-03 10:42:59 - cd /src TB --- 2008-02-03 10:42:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 3 10:42:59 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp_pci.c ld -d -warn-common -r -d -o rp.kld rp.o rp_pci.o :> export_syms awk -f /src/sys/modules/rp/../../conf/kmod_syms.awk rp.kld export_syms | xargs -J% objcopy % rp.kld ld -Bshareable -d -warn-common -o rp.ko rp.kld objcopy --strip-debug rp.ko ===> rr232x (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-03 11:04:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-03 11:04:34 - ERROR: failed to build lint kernel TB --- 2008-02-03 11:04:34 - tinderbox aborted TB --- 4358.50 user 411.61 system 5065.52 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Sun Feb 3 22:29:33 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EA2B16A419; Sun, 3 Feb 2008 22:29:33 +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 DEBE113C45A; Sun, 3 Feb 2008 22:29:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m13MTWrf060443; Sun, 3 Feb 2008 22:29:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m13MTWnB060439; Sun, 3 Feb 2008 22:29:32 GMT (envelope-from linimon) Date: Sun, 3 Feb 2008 22:29:32 GMT Message-Id: <200802032229.m13MTWnB060439@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-bugs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/120177: [ata] ATA DMA modes don't work on CF cards X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 22:29:33 -0000 Old Synopsis: ATA DMA modes don't work on CF cards New Synopsis: [ata] ATA DMA modes don't work on CF cards Responsible-Changed-From-To: freebsd-i386->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 3 22:28:47 UTC 2008 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=120177 From owner-freebsd-i386@FreeBSD.ORG Mon Feb 4 09:30:02 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5922416A421 for ; Mon, 4 Feb 2008 09: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 35F5113C45A for ; Mon, 4 Feb 2008 09: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.2/8.14.2) with ESMTP id m149U25V009849 for ; Mon, 4 Feb 2008 09:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m149U2VJ009846; Mon, 4 Feb 2008 09:30:02 GMT (envelope-from gnats) Resent-Date: Mon, 4 Feb 2008 09:30:02 GMT Resent-Message-Id: <200802040930.m149U2VJ009846@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Marko Kobal Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A335116A420 for ; Mon, 4 Feb 2008 09:23:19 +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 8E38E13C478 for ; Mon, 4 Feb 2008 09:23:19 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m149LLLV023662 for ; Mon, 4 Feb 2008 09:21:21 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m149LKj4023661; Mon, 4 Feb 2008 09:21:20 GMT (envelope-from nobody) Message-Id: <200802040921.m149LKj4023661@www.freebsd.org> Date: Mon, 4 Feb 2008 09:21:20 GMT From: Marko Kobal To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/120247: freeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 09:30:02 -0000 >Number: 120247 >Category: i386 >Synopsis: freeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 04 09:30:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Marko Kobal >Release: FreeBSD 6.3-RELEASE i386 >Organization: Arctur d.o.o. >Environment: FreeBSD corvus.arctur.si 6.3-RELEASE FreeBSD 6.3-RELEASE #12: Tue Jan 29 19:02:45 CET 2008 root@corvus.arctur.si:/usr/obj/usr/src/sys/CORVUS i386 >Description: I've upgraded one of my boxes from 6.2 to freeBSD 6.3. I have on-board LSI Logic 1030 SCSI Ultra4 Adapter, on it I have attached two IBM Ultra-320 SCSI 36GB disks. The machine is IBM xServer 225. See the dmesg output: .. mpt0: port 0xb000-0xb0ff mem 0xf5010000-0xf501ffff,0xf5000000-0xf500ffff irq 32 at device 3.0 on pci4 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.14.0 mpt0: Capabilities: ( RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) .. da1 at mpt0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 3.300MB/s transfers, Tagged Queueing Enabled da1: 34702MB (71071560 512 byte sectors: 255H 63S/T 4424C) .. It is showing that logical device da1 has only 3.3MB/s transfer rate!? Before the upgrade it was showing the correct 320MB/s. After a few quick disk test I can confirm that it is running sloooow: # dd if=/dev/da1 of=/dev/null bs=16384 count=1000 1000+0 records in 1000+0 records out 16384000 bytes transferred in 4.393638 secs (3729028 bytes/sec) # dd if=/dev/da1 of=/dev/null bs=16384 count=1000 1000+0 records in 1000+0 records out 16384000 bytes transferred in 6.619820 secs (2474992 bytes/sec) Is there something wrong with the mpt driver in 6.3? And also, is there any utility to access LSI Logic 1030 BIOS under freeBSD? Thanks for help! -- Kind regards, Marko Kobal. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Mon Feb 4 11:07:00 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F3416A46D for ; Mon, 4 Feb 2008 11:07:00 +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 1CF9613C4E3 for ; Mon, 4 Feb 2008 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m14B70Bj017260 for ; Mon, 4 Feb 2008 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m14B6xmk017256 for freebsd-i386@FreeBSD.org; Mon, 4 Feb 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Feb 2008 11:06:59 GMT Message-Id: <200802041106.m14B6xmk017256@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-i386@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-i386@FreeBSD.org X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 11:07:00 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/89202 i386 [ufs] [panic] Kernel crash when accessing filesystem w 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/70525 i386 [boot] boot0cfg: -o packet not effective o i386/70531 i386 [boot0] [patch] boot0 hides Lilo in extended slice o i386/71000 i386 [boot] BTX halted when booting from CD on a machine wi o i386/72960 i386 BTX halted with Promise Tx2000 Raid o i386/74008 i386 IBM eServer x225 cannot boot any v5.x - endless dump s o i386/74044 i386 [smb] ServerWorks OSB4 SMBus interface does not detect o i386/75887 i386 [pcvt] with vt0.disabled=0 and PCVT in kernel video/ke o i386/76944 i386 [busdma] [patch] i386 bus_dmamap_create() bug o i386/78339 i386 BTX loader crashes on boot on HP Proliant DL140 s i386/79169 i386 freeze with striped USB Drives under high load o i386/79409 i386 Coming back from idles make the server reboot o i386/79729 i386 umass, da0 not detected by devfs for o i386/79784 i386 [bfe] Broadcom BCM4401 : no carrier o i386/80268 i386 [crash] System with Transmeta Efficeon cpu crashes whi o i386/80989 i386 [install] Cannot install 5.4-RELEASE both in my system p i386/81111 i386 /boot/loader causes reboot due to CFLAGS+= -msse3 o i386/85072 i386 [psm] ps/2 Mouse detection failure on compaq chipset o i386/85866 i386 [hang] bootloader freezes on Pentium2/3 o i386/85938 i386 Install fails, unable to write partitions o i386/85944 i386 FreeBSD restarts after showing "Welcome to FreeBSD" sc o i386/86612 i386 SCSI DAT Drive Issue o i386/86667 i386 GNOME Battery Applet causing keyboard to lag/drop char o i386/86806 i386 Couldn't alloc kernel virtual memory o i386/86880 i386 [hang] 6.0 hangs or reboots whilst 5.4 is stable (ASUS o i386/86920 i386 [ndis] ifconfig: SIOCS80211: Invalid argument (regress o i386/87085 i386 [install] Will not install on Microtel system o i386/87155 i386 [boot] [panic] Can't Alloc Virtual Memory in FreeBSD 6 o i386/87576 i386 [install] no installation on Acer aspire 1304xc laptop o i386/87630 i386 [ndis] No match for NdisIMGetCurrentPacketStack o i386/87876 i386 Installation Problems for i368 Compaq R3000 s i386/88139 i386 [i386] [request] 53C875 Chipset HP 5064-6016 doesn't w o i386/88459 i386 [panic] Fatal trap 19 (process: idle: cpu0) on HP prol o i386/88610 i386 FreeBSD 6.0 bootonly crashes during boot after sis0, d o i386/88717 i386 freebsd 5.4 boots from lsi 53c1030 only in safe mode o i386/88755 i386 [install] FreeBSD R6.0 on ThinkPad R40 installation re o i386/88853 i386 [hang] SMP system FreeBSD 6.0-STABLE crashed while tra o i386/88929 i386 [install] FreeBSD 6.0 install CD fails to find disks o o i386/89249 i386 HighPoint RocketRAID 1520 (HPT372N) can't write on har o i386/89288 i386 [acpi] DMA error while booting with acpi enable o i386/89340 i386 [panic] 6.0-STABLE (2005-11-07) panic when mostly idle f i386/89383 i386 [sio] [panic] page fault o i386/90065 i386 [wi] System hangs if wireless card wasn't disabled bef o i386/91038 i386 [panic] 6.0-RELEASE on Fujitsu Siemens Amilo Pro v2040 o i386/91282 i386 [install] 6.0R install CD crashes on Promise PDC20267 o i386/91745 i386 Second processor not detected on Proliant ML530 G2 wit o i386/92193 i386 Can't boot from 6.0 Installation CD: BTX halted (Gigab o i386/93524 i386 Automatic reboot o i386/93615 i386 [install] Operating system wont install. Problem with o i386/93752 i386 Cannot activate the serial ports on boot probe. BIOS o o i386/93762 i386 Machine lockup at boot loader countdown on SuperMicro o i386/93787 i386 freebsd 6.0 hangs on atkbd0 on Proliant 1850r server a o i386/93809 i386 panic: could not copy LDT on RELENG_5_3 through RELENG o i386/93923 i386 [ata] FreeBSD Install, Sil3112: Cannot dump. No dump d o i386/93989 i386 [install] Can't install FreeBSD from IEEE1394 DVD-RW o o i386/94141 i386 [iwi] iwi doesn't work on Acer Laptop o i386/94364 i386 [kbd] Unable to boot on NX9110 laptop o i386/94420 i386 FreeBSD does NOT support the pcChips M925 motherboard. o i386/94911 i386 [ata] ata regression with DOM-IDE o i386/95087 i386 System freeze irrespective of load on Promise FastTrak o i386/96014 i386 [install] HP Pavilion zv5000(Intel) reboot installatio o i386/96225 i386 Toshiba M70-CL3 Hangs Up During Booting o i386/96302 i386 [ata] nVidia nForce CK804 SATA300 controller not recog o i386/96357 i386 FreeBSD cannot recognize all the logical partitions o i386/96382 i386 [bge] In 6.1-RC1 the bge driver does not reliably work o i386/97025 i386 fbsd (2 cd) dont install in vmware 5.5.0 - reboot. o i386/97263 i386 [ata] FreeBSD only detects first drive on PDC20378 378 o i386/97287 i386 Screen Corruption In FreeBSD 6.X When Apps Started In o i386/98154 i386 6-STABLE crashes when being online via modem (Fujitsu o i386/98215 i386 [geode] regression: FreeBSD can no longer boot Geode G o i386/98765 i386 [sata] timeouts on sata drive (Asus a7n8x-e) o i386/98964 i386 [iwi] iwi totally freezes system o i386/99608 i386 [atapicam] ATAPI or CAM crash on FreeBSD 6.1-stable wi o i386/100420 i386 boot1/boot2 lba error o i386/100831 i386 [sio] sio ignores BIOS information about serial ports o i386/101135 i386 [iwi] iwi goes up and down o i386/101616 i386 FreeBSD freeze on bootup, Compaq Proliant (legacy) ser o i386/101667 i386 [ata] ATA problems when power management is on o i386/101857 i386 Mouse not moving after switching with StarView SV411 K o i386/102410 i386 [install] FreeBSD 6.1-RELEASE installation boot freeze o i386/102562 i386 [em] no traffic pass through a em card after approx. a o i386/103063 i386 [install] Can not install on Dell XPS 700 s i386/103624 i386 [ata] [install] Problem installing on Dell Powervault o i386/104349 i386 [bfe] Panic while uploading data via bfe network inter o i386/104473 i386 boot loader reboots before loading kernel on Albatron o i386/104572 i386 [ata] issues with detecting HDD on Intel Q965 Express o i386/104711 i386 [pcvt] with vt0.disabled=0 and PCVT in kernel - video/ o i386/104719 i386 Seagate ST3802110A errors/delays when using PIO4 or UD o i386/104867 i386 Clock running at 2x speed of wall clock o i386/105708 i386 [em] em driver failed to initialize on thinkpad X60 o i386/107382 i386 [install] "Fatal trap 12" when installing FreeBSD 6.1 o i386/107564 i386 [install] fatal trap 19 during installation on a Dell o i386/108139 i386 [patch] System hangs after /sbin/shutdown o i386/108185 i386 [panic] freebsd 6.2 fatal kernel trap s i386/109200 i386 [ata] READ_UDMA UDMA ICRC error cause not detecting ca o i386/109568 i386 [panic] Reboot server with "Fatal trap 12" o i386/109610 i386 [panic] Fatal trap 12: page fault while in kernel mode o i386/110111 i386 [install] install hangs after APIC inspection, Xeon on o i386/110214 i386 [hang] FreeBSD 6.2 freezes on SSH activitiy caused by o i386/110218 i386 kmem_malloc(4096): kmem_map too small: 335544320 total o i386/112036 i386 [ata] TIMEOUT - WRITE_DMA retrying, TIMEOUT - READ_DMA o i386/112487 i386 [sio] kernel panic on swi0:sio o i386/112580 i386 BTX Halted on HP DV6255 Notebook o i386/112596 i386 [aac] aac driver causes kernel panic - page fault on 2 o i386/112635 i386 [hang] Hang during boot installation o i386/112700 i386 SMP Kernel with FreeBSD 6.2 release on compaq dl360 g1 o i386/114192 i386 Fail to boot with "error issuing ATA_IDENTIFY command" o i386/114208 i386 Problem booting the FreeBSD CD ISO image o i386/114535 i386 Toshiba Satellite 105A: "no driver attached" for vario o i386/115285 i386 [panic] fatal trap 1 on freebsd 6.2 install boot up on o i386/115854 i386 Install FreeBSD with USB CDROM causes panic in BTX loa o i386/115947 i386 Dell poweredge 860 hangs when stressed and ACPI is ena o i386/116297 i386 system hangs during installation o i386/116844 i386 cannot boot from cd when using Dell Vostro 200 Desktop o i386/117297 i386 [hang] System hangs up every day f i386/117795 i386 When I try to boot FreeBSD on i386 the monitor cuts ou o i386/118285 i386 Segmentation fault in reloc_non_plt. o i386/118656 i386 Init dies in single user mode and box get kernel panic o i386/119903 i386 Fast increase in loading of the processor. Almost 100% o i386/119946 i386 [est] sysctl dev.cpu.0.freq on 75 Hz, cannot be change o i386/120247 i386 freeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s 120 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/73921 i386 [sysctl] [patch] sysctlbyname for machdep.tsc_freq doe o i386/74153 i386 [pst] FreeBSD 5.3 cannot boot ftom pst o i386/74327 i386 [pmap] [patch] mlock() causes physical memory leakage o i386/74454 i386 [bsd.cpu.mk] [patch] Adding VIA Eden family o i386/74650 i386 System Reboot with umount command p i386/75898 i386 Exception and reboot: Loader and kernel use SSE2 instr o i386/79091 i386 [i386] [patch] Small optimization for i386/support.s o i386/79840 i386 [sysinstall] Partitioning and formating a new disk fai o i386/80095 i386 ld-elf.so.1 crashes with executables produced by tinyc o i386/85417 i386 [i386] [patch] Possible bug in ia32 floating-point exc o i386/85423 i386 [ex] ex(4) does not correctly recognize NIC in PnP mod o i386/85652 i386 [loader] [patch] deal with out-of-memory errors during o i386/85653 i386 [i386] [patch] relieve hangs in tight loops in process o i386/85654 i386 [i386] [patch] separate max cpu from max apic in i386 o i386/85655 i386 [i386] [patch] expose cpu info for i386 systems o i386/85656 i386 [i386] [patch] expose more i386 specific CPU informati o i386/88020 i386 cannot boot unless: hint.apic.0.disabled="1" is set on o i386/88491 i386 [install] Panic when boot installation CD1 (Acer Trave o i386/88965 i386 vidcontrol hangs with 2 modules of RAM o i386/90243 i386 Laptop fan doesn't turn off (ACPI enabled) (Packard Be o i386/90839 i386 [ata] burncd gets error on CDRIOCFIXATE with HL-DT-ST o i386/91594 i386 FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT o i386/91871 i386 [boot1] [patch] boot1: jump to 0xf000:0xfff0 instead o o i386/92501 i386 [irq] Hang on boot with ACPI enabled on ASUS A6R noteb o i386/93793 i386 [kbd] Keyboard stops working after a shutdown -p now ( o i386/95106 i386 [install] cannot install freebsd, Nvidia nForce 2 base o i386/95993 i386 Cyrix 5530 unable to map interrupt o i386/96406 i386 System freezes on IBM xSeries 335 with FreeBSD-6.0-REL o i386/98366 i386 [em] Intel PRO/1000 MT Dual PCI-X: simulatenious 1000 o i386/98932 i386 [i386] [patch] Kernel compilation failed on specific P o i386/100142 i386 [pci] [patch] /dev/smb0 device not available on system o i386/100204 i386 FreeBSD reports raid as broken - but it is not o i386/101062 i386 Freeze on detect Intel 900 VGA on boot with ACPI p i386/101379 i386 [i386] [patch] page fault clobbers error code in trap f i386/103192 i386 no CD/DVD devices found while install Freebsd o i386/105063 i386 [sio] US Robotics (3Com) 3CP5609 PCI 16550 Modem works o i386/105175 i386 [ipmi] ipmi acpi trouble on supermicro server o i386/106789 i386 [nfe] or [nve]: Internal NIC of GA-K8N51GMF-RH does no o i386/106850 i386 [powerd] powernow0 attach returned 6 o i386/109423 i386 [ichsmb] ICH5 smb interface problems o i386/113110 i386 [mk] [patch] i686 is not an alias of pentiumpro on GCC o i386/113160 i386 [install] mountroot> prompt during first boot for inst o i386/113177 i386 [pci] [patch] Extended PCI Configuration register (>= o i386/116100 i386 Fatal trap 12 right after reboot (da0s1error = 6) o i386/116347 i386 [apm] [patch] APM does not suspend USB devices o i386/118350 i386 [hang] BTX loader hangs on PC Engines WRAP o i386/119175 i386 [busdma] [patch] Typo in bus_dmamem_alloc() o i386/119350 i386 [i386] [patch] cpufreq(est) reports invalid frequency. o i386/119491 i386 [i386] [patch] [request] padlock enable for new VIA C7 o i386/119574 i386 [i386] 7.0-RC1 times out in calibrate_clocks() (regres 50 problems total. From owner-freebsd-i386@FreeBSD.ORG Mon Feb 4 18:50:01 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE0916A4E5 for ; Mon, 4 Feb 2008 18:50:00 +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 CE5D413C455 for ; Mon, 4 Feb 2008 18:50:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m14Io01F059811 for ; Mon, 4 Feb 2008 18:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m14Io0PI059810; Mon, 4 Feb 2008 18:50:00 GMT (envelope-from gnats) Resent-Date: Mon, 4 Feb 2008 18:50:00 GMT Resent-Message-Id: <200802041850.m14Io0PI059810@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Oleg Borovkov Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D32DD16A419 for ; Mon, 4 Feb 2008 18:47:01 +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 C227D13C4F8 for ; Mon, 4 Feb 2008 18:47:01 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m14Ij2Lm015596 for ; Mon, 4 Feb 2008 18:45:02 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m14Ij2T7015595; Mon, 4 Feb 2008 18:45:02 GMT (envelope-from nobody) Message-Id: <200802041845.m14Ij2T7015595@www.freebsd.org> Date: Mon, 4 Feb 2008 18:45:02 GMT From: Oleg Borovkov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/120264: double fault in freebsd 7.0 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 18:50:01 -0000 >Number: 120264 >Category: i386 >Synopsis: double fault in freebsd 7.0 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 04 18:50:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Oleg Borovkov >Release: 7 >Organization: LAI >Environment: vpn9# uname -a FreeBSD vpn 7.0-BETA4 FreeBSD 7.0-BETA4 #0: Sun Feb 3 23:11:52 MSK 2008 root@vpn.lai:/usr/src/sys/i386/compile/my i386 >Description: Comp reboot after panic... backtrace of kernel's vmcore: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0531107 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc05313c9 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:563 #3 0xc0760b9b in dblfault_handler () at ../../../i386/i386/trap.c:901 #4 0xc05c64b6 in ether_vlanencap (m=0x0, tag=192) at ../../../net/if_ethersubr.c:1273 #5 0xc05c99a6 in vlan_start (ifp=0xc1e48400) at ../../../net/if_vlan.c:853 #6 0xc05bfca9 in if_start (ifp=0xc1e48400) at ../../../net/if.c:2704 #7 0xc05c63db in ether_output_frame (ifp=0xc1e48400, m=0xc1ee2d00) at ../../../net/if_ethersubr.c:405 #8 0xc20204f7 in ?? () #9 0xc1e48400 in ?? () #10 0xc1ee2d00 in ?? () #11 0x02570000 in ?? () #12 0x98c0ee98 in ?? () #13 0x000010e4 in ?? () #14 0xda7a0000 in ?? () #15 0x00006400 in ?? () #16 0xc1d28a50 in ?? () #17 0xc1d28a50 in ?? () #18 0xc1ee0b00 in ?? () #19 0xcbb210f8 in ?? () #20 0xc054ca50 in sched_add (td=0xc206a450, flags=4) ---Type to continue, or q to quit---(kgdb) bt at ../../../kern/sched_4bsd.c:1150 #21 0xc201f490 in ?? () #22 0xc1f7ab54 in ?? () #23 0x00000004 in ?? () #24 0xcbb211a4 in ?? () #25 0xc0746c85 in bus_dmamap_load (dmat=0xc206a450, map=0x0, buf=0xc1faec00, buflen=0, callback=0xc1faed00, callback_arg=0xc1e23680, flags=-1042720768) at ../../../i386/i386/busdma_machdep.c:765 #26 0xc208775f in ?? () #27 0xc206a450 in ?? () #28 0x00000000 in ?? () #29 0xc1faec00 in ?? () #30 0x00000000 in ?? () #31 0xc1faed00 in ?? () #32 0xc1e23680 in ?? () #33 0xc1d95800 in ?? () #34 0xcbb211e0 in ?? () #35 0x00000000 in ?? () #36 0xc1df7800 in ?? () #37 0xc08152e0 in bounce_map_callbacklist () #38 0xc1ee4834 in ?? () #39 0x00000000 in ?? () #40 0xc06c3380 in rl_start () at ../../../pci/if_rl.c:1435 ---Type to continue, or q to quit---#0 doadump () at pcpu.h:195 #41 0xc20204f7 in ?? () #42 0xc21f2d80 in ?? () #43 0xc206a450 in ?? () #44 0xcbb21224 in ?? () #45 0x00000000 in ?? () #46 0xc1fb2de8 in ?? () #47 0xc05c64ca in ether_vlanencap (m=0xc21e36c0, tag=49658) at ../../../net/if_ethersubr.c:1273 #48 0xc201f490 in ?? () #49 0xc1faed54 in ?? () #50 0x00000004 in ?? () #51 0xc206a450 in ?? () #52 0xc2204e80 in ?? () #53 0xc1faed00 in ?? () #54 0x00000000 in ?? () #55 0x00000000 in ?? () #56 0x00000016 in ?? () #57 0xc21dfe00 in ?? () #58 0xc206a450 in ?? () #59 0xc21e1100 in ?? () #60 0xcbb21384 in ?? () #61 0xc20204f7 in ?? () #62 0xc206a450 in ?? () ---Type to continue, or q to quit---#1 0xc0531107 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #63 0x00000000 in ?? () #64 0xcbb21394 in ?? () #65 0xc2020440 in ?? () #66 0xc1f7ab54 in ?? () #67 0x00000004 in ?? () #68 0xc10523c0 in ?? () #69 0xcbb2131c in ?? () #70 0xc05c63db in ether_output_frame (ifp=0xc1faed00, m=0x0) at ../../../net/if_ethersubr.c:405 Previous frame inner to this frame (corrupt stack?) (kgdb) #2 0xc05313c9 in panic (fmt=Variable "fmt" is not available. (kgdb) ) at ../../../kern/kern_shutdown.c:563 Undefined command: "". Try "help". (kgdb) #3 0xc0760b9b in dblfault_handler () at ../../../i386/i386/trap.c:901 (kgdb) #4 0xc05c64b6 in ether_vlanencap (m=0x0, tag=192) (kgdb) at ../../../net/if_ethersubr.c:1273 Illegal process-id: ../../../net/if_ethersubr.c:1273 (kgdb) #5 0xc05c99a6 in vlan_start (ifp=0xc1e48400) at ../../../net/if_vlan.c:853 (kgdb) #6 0xc05bfca9 in if_start (ifp=0xc1e48400) at ../../../net/if.c:2704 (kgdb) #7 0xc05c63db in ether_output_frame (ifp=0xc1e48400, m=0xc1ee2d00) (kgdb) at ../../../net/if_ethersubr.c:405 Illegal process-id: ../../../net/if_ethersubr.c:405 >How-To-Repeat: approx every hour >Fix: don't know :-(( >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Mon Feb 4 18:55:22 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D2616A469; Mon, 4 Feb 2008 18:55:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C01B413C459; Mon, 4 Feb 2008 18:55:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m14ItM5H060150; Mon, 4 Feb 2008 18:55:22 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m14ItMFF060146; Mon, 4 Feb 2008 18:55:22 GMT (envelope-from gavin) Date: Mon, 4 Feb 2008 18:55:22 GMT Message-Id: <200802041855.m14ItMFF060146@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-i386@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/103192: no CD/DVD devices found while install Freebsd X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 18:55:23 -0000 Synopsis: no CD/DVD devices found while install Freebsd Responsible-Changed-From-To: freebsd-i386->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Mon Feb 4 18:53:08 UTC 2008 Responsible-Changed-Why: To submitter: Firstly, I'm really sorry that this PR has taken so long to look at. I wonder, are you able to recreate the issue with more recent versions of FreeBSD? If your drive is still not recognised, would you be willing to assist in some minor debugging? Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=103192 From owner-freebsd-i386@FreeBSD.ORG Tue Feb 5 06:33:17 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79C2F16A419; Tue, 5 Feb 2008 06:33:17 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 54BD013C458; Tue, 5 Feb 2008 06:33:17 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m156XHQp018155; Tue, 5 Feb 2008 06:33:17 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m156XHZv018151; Tue, 5 Feb 2008 06:33:17 GMT (envelope-from remko) Date: Tue, 5 Feb 2008 06:33:17 GMT Message-Id: <200802050633.m156XHZv018151@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: i386/120264: double fault in freebsd 7.0 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2008 06:33:17 -0000 Synopsis: double fault in freebsd 7.0 Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Feb 5 06:32:56 UTC 2008 Responsible-Changed-Why: >From the backtrace this appears to be something in the networking code (as far as I am able to interpret) http://www.freebsd.org/cgi/query-pr.cgi?pr=120264 From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 05:55:00 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5EBF16A417; Wed, 6 Feb 2008 05:55:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9693D13C447; Wed, 6 Feb 2008 05:55:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m165sxvF061926; Wed, 6 Feb 2008 00:55:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m165sxal051535; Wed, 6 Feb 2008 00:54:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6FD9F73039; Wed, 6 Feb 2008 00:54:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206055459.6FD9F73039@freebsd-current.sentex.ca> Date: Wed, 6 Feb 2008 00:54:59 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 05:55:00 -0000 TB --- 2008-02-06 04:43:15 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-06 04:43:15 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-06 04:43:15 - cleaning the object tree TB --- 2008-02-06 04:43:42 - cvsupping the source tree TB --- 2008-02-06 04:43:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-06 04:43:50 - building world (CFLAGS=-O -pipe) TB --- 2008-02-06 04:43:50 - cd /src TB --- 2008-02-06 04:43:50 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 04:43:52 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 6 05:44:55 UTC 2008 TB --- 2008-02-06 05:44:55 - generating LINT kernel config TB --- 2008-02-06 05:44:55 - cd /src/sys/i386/conf TB --- 2008-02-06 05:44:55 - /usr/bin/make -B LINT TB --- 2008-02-06 05:44:55 - building LINT kernel (COPTFLAGS=) TB --- 2008-02-06 05:44:55 - cd /src TB --- 2008-02-06 05:44:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 05:44:55 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 05:54:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 05:54:59 - ERROR: failed to build lint kernel TB --- 2008-02-06 05:54:59 - tinderbox aborted TB --- 3207.69 user 387.42 system 4303.76 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 07:04:36 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4218C16A4A5; Wed, 6 Feb 2008 07:04:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 127A213C458; Wed, 6 Feb 2008 07:04:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1674ZaI038209; Wed, 6 Feb 2008 02:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.1) with ESMTP id m1674ZNK039388; Wed, 6 Feb 2008 02:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id D209F1B5078; Wed, 6 Feb 2008 02:04:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206070434.D209F1B5078@freebsd-stable.sentex.ca> Date: Wed, 6 Feb 2008 02:04:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 07:04:36 -0000 TB --- 2008-02-06 05:47:15 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-06 05:47:15 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-02-06 05:47:15 - cleaning the object tree TB --- 2008-02-06 05:47:41 - cvsupping the source tree TB --- 2008-02-06 05:47:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-02-06 05:47:53 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-06 05:47:53 - cd /src TB --- 2008-02-06 05:47:53 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 05:47:54 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 6 06:50:00 UTC 2008 TB --- 2008-02-06 06:50:00 - generating LINT kernel config TB --- 2008-02-06 06:50:00 - cd /src/sys/i386/conf TB --- 2008-02-06 06:50:00 - /usr/bin/make -B LINT TB --- 2008-02-06 06:50:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-06 06:50:01 - cd /src TB --- 2008-02-06 06:50:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 06:50:01 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 07:04:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 07:04:34 - ERROR: failed to build lint kernel TB --- 2008-02-06 07:04:34 - tinderbox aborted TB --- 3977.81 user 388.74 system 4639.51 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 11:50:02 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD69816A419 for ; Wed, 6 Feb 2008 11:50: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 9CD0013C45B for ; Wed, 6 Feb 2008 11:50: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.2/8.14.2) with ESMTP id m16Bo2ZE052815 for ; Wed, 6 Feb 2008 11:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m16Bo2Qi052814; Wed, 6 Feb 2008 11:50:02 GMT (envelope-from gnats) Date: Wed, 6 Feb 2008 11:50:02 GMT Message-Id: <200802061150.m16Bo2Qi052814@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Oliver B. Warzecha" Cc: Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Oliver B. Warzecha" List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 11:50:02 -0000 The following reply was made to PR i386/119574; it has been noted by GNATS. From: "Oliver B. Warzecha" To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Date: Wed, 6 Feb 2008 12:37:21 +0100 Okay, it took some time, one reason the machine in question being used as my router, which reduces research options when test booting kernels... On Mon, Jan 14, 2008 at 12:11:34AM +1100, Bruce Evans wrote: > On Fri, 11 Jan 2008, Oliver B. Warzecha wrote: > > >As I noticed that rtcin() was reworked during the change to 7.0, > >(http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.222.2.2;r2=1.239.2.1;f=h) > >it occurred to me that perhaps there might be some condition > >in the new code. > > Probably. I wrote both. Apparently I optimized rtcin() too much. > Try adding some delays to it, and/or more debugging code. For debugging > code, just read the RTC index register and verify that it is set to > the memory value that is supposed to track it. Check after writing > to it and when the write is avoided because it already has the desired > value according to the memory value. I came relatively fast to the conclusion that reading the register leads nowhere, it seems to be a write-only register that never yields the value just written to it. > > > > /* Read the mc146818A seconds counter. */ > > for (;;) { > > if (!(rtcin(RTC_STATUSA) & RTCSA_TUP)) { > > sec = rtcin(RTC_SEC); > > break; > > } > > if (--timeout == 0) > > goto fail; > > } > >// printf("seconds counter read ... \n"); > > The optimization might break this by going too fast -- it now reads the > status register as fast as possible, where before it had lots of delays. > It still has the delays (supposed to be done more carefully than before > when switching to reading the seconds register, so I would expect the > read of the seconds register to be as correct as before, but it apparently > isn't. I have found at least one design - one of these compact PC on a PCI card designs: http://www.pt.com/Manuals_Legacy/ZT_5510_Manual_PTI.pdf - where it is explicitely mentioned in the documentation that for repeated access to the same register in the RTC you have to set the address register again. This card is also based on the HX chipset, maybe this limitation was lifted in newer designs. Maybe accesses on newer systems are fast enough that any capacitors in the circuit are refreshed, whatever, this is pure speculation. It is tough to find some definitive documentation on the net about this issue. Anyway, at least for this specific case, it seems that only the original way of clock access was the right one, I am afraid. For what it's worth, I just checked the linux sources, it's also straight "write address register, then read/write data" there. It would be nice to have some definitive documentation on that case, but I have no idea right now. OBW (rest snipped, as it does not apply as long as the register is not read correctly) From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 12:08:31 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E261F16A417; Wed, 6 Feb 2008 12:08:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9FD13C448; Wed, 6 Feb 2008 12:08:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m16C8UHq049673; Wed, 6 Feb 2008 07:08:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m16C8UNg044626; Wed, 6 Feb 2008 07:08:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 97E431B5078; Wed, 6 Feb 2008 07:08:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206120830.97E431B5078@freebsd-stable.sentex.ca> Date: Wed, 6 Feb 2008 07:08:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [releng_7_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 12:08:32 -0000 TB --- 2008-02-06 10:50:01 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-06 10:50:01 - starting RELENG_7_0 tinderbox run for i386/i386 TB --- 2008-02-06 10:50:01 - cleaning the object tree TB --- 2008-02-06 10:50:30 - cvsupping the source tree TB --- 2008-02-06 10:50:30 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_0/i386/i386/supfile TB --- 2008-02-06 10:50:40 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-06 10:50:40 - cd /src TB --- 2008-02-06 10:50:40 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 10:50:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 6 11:53:41 UTC 2008 TB --- 2008-02-06 11:53:41 - generating LINT kernel config TB --- 2008-02-06 11:53:41 - cd /src/sys/i386/conf TB --- 2008-02-06 11:53:41 - /usr/bin/make -B LINT TB --- 2008-02-06 11:53:42 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-06 11:53:42 - cd /src TB --- 2008-02-06 11:53:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 11:53:42 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 12:08:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 12:08:30 - ERROR: failed to build lint kernel TB --- 2008-02-06 12:08:30 - tinderbox aborted TB --- 3976.78 user 392.48 system 4709.47 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_0-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 12:08:47 2008 Return-Path: Delivered-To: freebsd-i386@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9D316A419 for ; Wed, 6 Feb 2008 12:08:47 +0000 (UTC) (envelope-from obw@amarok.ping.de) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by mx1.freebsd.org (Postfix) with SMTP id 46C6F13C474 for ; Wed, 6 Feb 2008 12:08:45 +0000 (UTC) (envelope-from obw@amarok.ping.de) Received: (qmail 10855 invoked by uid 10); 6 Feb 2008 11:42:05 -0000 Received: from amarok.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 6 Feb 2008 11:42:05 -0000 Received: from karnevil9.amarok.ping.de (localhost [127.0.0.1]) by karnevil9.amarok.ping.de (8.13.8/8.13.8) with ESMTP id m16BbL8K002635; Wed, 6 Feb 2008 12:37:21 +0100 (CET) (envelope-from obw@karnevil9.amarok.ping.de) Received: (from obw@localhost) by karnevil9.amarok.ping.de (8.13.8/8.13.8/Submit) id m16BbLJ0002634; Wed, 6 Feb 2008 12:37:21 +0100 (CET) (envelope-from obw) Date: Wed, 6 Feb 2008 12:37:21 +0100 From: "Oliver B. Warzecha" To: Bruce Evans Message-ID: <20080206113721.GB1361@karnevil9.amarok.ping.de> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080113225917.Y50887@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-message-flag: Please send plain text messages only. Thank you. Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 12:08:47 -0000 Okay, it took some time, one reason the machine in question being used as my router, which reduces research options when test booting kernels... On Mon, Jan 14, 2008 at 12:11:34AM +1100, Bruce Evans wrote: > On Fri, 11 Jan 2008, Oliver B. Warzecha wrote: > > >As I noticed that rtcin() was reworked during the change to 7.0, > >(http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.222.2.2;r2=1.239.2.1;f=h) > >it occurred to me that perhaps there might be some condition > >in the new code. > > Probably. I wrote both. Apparently I optimized rtcin() too much. > Try adding some delays to it, and/or more debugging code. For debugging > code, just read the RTC index register and verify that it is set to > the memory value that is supposed to track it. Check after writing > to it and when the write is avoided because it already has the desired > value according to the memory value. I came relatively fast to the conclusion that reading the register leads nowhere, it seems to be a write-only register that never yields the value just written to it. > > > > /* Read the mc146818A seconds counter. */ > > for (;;) { > > if (!(rtcin(RTC_STATUSA) & RTCSA_TUP)) { > > sec = rtcin(RTC_SEC); > > break; > > } > > if (--timeout == 0) > > goto fail; > > } > >// printf("seconds counter read ... \n"); > > The optimization might break this by going too fast -- it now reads the > status register as fast as possible, where before it had lots of delays. > It still has the delays (supposed to be done more carefully than before > when switching to reading the seconds register, so I would expect the > read of the seconds register to be as correct as before, but it apparently > isn't. I have found at least one design - one of these compact PC on a PCI card designs: http://www.pt.com/Manuals_Legacy/ZT_5510_Manual_PTI.pdf - where it is explicitely mentioned in the documentation that for repeated access to the same register in the RTC you have to set the address register again. This card is also based on the HX chipset, maybe this limitation was lifted in newer designs. Maybe accesses on newer systems are fast enough that any capacitors in the circuit are refreshed, whatever, this is pure speculation. It is tough to find some definitive documentation on the net about this issue. Anyway, at least for this specific case, it seems that only the original way of clock access was the right one, I am afraid. For what it's worth, I just checked the linux sources, it's also straight "write address register, then read/write data" there. It would be nice to have some definitive documentation on that case, but I have no idea right now. OBW (rest snipped, as it does not apply as long as the register is not read correctly) From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 15:57:06 2008 Return-Path: Delivered-To: freebsd-i386@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226C216A421 for ; Wed, 6 Feb 2008 15:57:06 +0000 (UTC) (envelope-from obw@amarok.ping.de) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by mx1.freebsd.org (Postfix) with SMTP id 80DDF13C46A for ; Wed, 6 Feb 2008 15:57:05 +0000 (UTC) (envelope-from obw@amarok.ping.de) Received: (qmail 2116 invoked by uid 10); 6 Feb 2008 15:57:03 -0000 Received: from amarok.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 6 Feb 2008 15:57:03 -0000 Received: from karnevil9.amarok.ping.de (localhost [127.0.0.1]) by karnevil9.amarok.ping.de (8.13.8/8.13.8) with ESMTP id m16FtEKZ004900; Wed, 6 Feb 2008 16:55:15 +0100 (CET) (envelope-from obw@karnevil9.amarok.ping.de) Received: (from obw@localhost) by karnevil9.amarok.ping.de (8.13.8/8.13.8/Submit) id m16FtE6V004899; Wed, 6 Feb 2008 16:55:14 +0100 (CET) (envelope-from obw) Date: Wed, 6 Feb 2008 16:55:14 +0100 From: "Oliver B. Warzecha" To: Bruce Evans Message-ID: <20080206155514.GD1361@karnevil9.amarok.ping.de> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080113225917.Y50887@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-message-flag: Please send plain text messages only. Thank you. Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 15:57:06 -0000 Addon to my last mail, as I just discovered the i440BX-Specs, just 2 clicks away from one of the pages where I last searched for info. They are downloadable from http://www.intel.com/design/intarch/datashts/290562.htm On page 84, there is specified that the RTC index register is write only (as I found out in practical testing :-). And it is also described as a latch register, which makes the current code "working by pure chance", as it's implementation dependent which bus noise happens on the other side of the gate. (If I didn't get the meaning of "latch" in this case totally wrong) regards, OBW From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 16:00:03 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2270A16A419 for ; Wed, 6 Feb 2008 16:00: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 EE69D13C442 for ; Wed, 6 Feb 2008 16:00: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.2/8.14.2) with ESMTP id m16G02u6072216 for ; Wed, 6 Feb 2008 16:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m16G0228072215; Wed, 6 Feb 2008 16:00:02 GMT (envelope-from gnats) Date: Wed, 6 Feb 2008 16:00:02 GMT Message-Id: <200802061600.m16G0228072215@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Oliver B. Warzecha" Cc: Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Oliver B. Warzecha" List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 16:00:03 -0000 The following reply was made to PR i386/119574; it has been noted by GNATS. From: "Oliver B. Warzecha" To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Date: Wed, 6 Feb 2008 16:55:14 +0100 Addon to my last mail, as I just discovered the i440BX-Specs, just 2 clicks away from one of the pages where I last searched for info. They are downloadable from http://www.intel.com/design/intarch/datashts/290562.htm On page 84, there is specified that the RTC index register is write only (as I found out in practical testing :-). And it is also described as a latch register, which makes the current code "working by pure chance", as it's implementation dependent which bus noise happens on the other side of the gate. (If I didn't get the meaning of "latch" in this case totally wrong) regards, OBW From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 22:48:49 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95CE16A417; Wed, 6 Feb 2008 22:48:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9B16F13C455; Wed, 6 Feb 2008 22:48:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m16MmmYW042294; Wed, 6 Feb 2008 17:48:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m16MmmDh029080; Wed, 6 Feb 2008 17:48:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DB22873039; Wed, 6 Feb 2008 17:48:47 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206224847.DB22873039@freebsd-current.sentex.ca> Date: Wed, 6 Feb 2008 17:48:47 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 22:48:49 -0000 TB --- 2008-02-06 22:21:19 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-06 22:21:19 - starting HEAD tinderbox run for i386/i386 TB --- 2008-02-06 22:21:19 - cleaning the object tree TB --- 2008-02-06 22:21:49 - cvsupping the source tree TB --- 2008-02-06 22:21:49 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2008-02-06 22:21:55 - building world (CFLAGS=-O -pipe) TB --- 2008-02-06 22:21:55 - cd /src TB --- 2008-02-06 22:21:55 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 22:21:56 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mattr_init.c -o thr_mattr_init.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mattr_kind_np.c -o thr_mattr_kind_np.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mattr_pshared.c -o thr_mattr_pshared.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_msync.c -o thr_msync.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_multi_np.c -o thr_multi_np.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mutex.c -o thr_mutex.So cc1: warnings being treated as errors /src/lib/libkse/thread/thr_mutex.c:1856: warning: no previous prototype for '_pthread_mutex_isowned_np' *** Error code 1 Stop in /src/lib/libkse. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 22:48:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 22:48:47 - ERROR: failed to build world TB --- 2008-02-06 22:48:47 - tinderbox aborted TB --- 1217.80 user 155.27 system 1648.19 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 22:52:10 2008 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 443F116A417; Wed, 6 Feb 2008 22:52:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E9E4B13C45B; Wed, 6 Feb 2008 22:52:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m16Mq9MD042660; Wed, 6 Feb 2008 17:52:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m16Mq9O4031710; Wed, 6 Feb 2008 17:52:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3256373039; Wed, 6 Feb 2008 17:52:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206225209.3256373039@freebsd-current.sentex.ca> Date: Wed, 6 Feb 2008 17:52:09 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 22:52:10 -0000 TB --- 2008-02-06 22:24:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-02-06 22:24:26 - starting HEAD tinderbox run for i386/pc98 TB --- 2008-02-06 22:24:26 - cleaning the object tree TB --- 2008-02-06 22:24:51 - cvsupping the source tree TB --- 2008-02-06 22:24:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2008-02-06 22:24:57 - building world (CFLAGS=-O -pipe) TB --- 2008-02-06 22:24:57 - cd /src TB --- 2008-02-06 22:24:57 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 22:25:00 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mattr_init.c -o thr_mattr_init.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mattr_kind_np.c -o thr_mattr_kind_np.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mattr_pshared.c -o thr_mattr_pshared.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_msync.c -o thr_msync.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_multi_np.c -o thr_multi_np.So cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL -I/src/lib/libkse/../libc/include -I/src/lib/libkse/thread -I/src/lib/libkse/../../include -I/src/lib/libkse/arch/i386/include -I/src/lib/libkse/sys -I/src/lib/libkse/../../libexec/rtld-elf -I/src/lib/libkse/../../libexec/rtld-elf/i386 -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/src/lib/libkse/../libc/i386 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libkse/thread/thr_mutex.c -o thr_mutex.So cc1: warnings being treated as errors /src/lib/libkse/thread/thr_mutex.c:1856: warning: no previous prototype for '_pthread_mutex_isowned_np' *** Error code 1 Stop in /src/lib/libkse. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 22:52:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 22:52:09 - ERROR: failed to build world TB --- 2008-02-06 22:52:09 - tinderbox aborted TB --- 1220.34 user 159.85 system 1663.05 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-i386@FreeBSD.ORG Thu Feb 7 08:04:13 2008 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10C1D16A418 for ; Thu, 7 Feb 2008 08:04:13 +0000 (UTC) (envelope-from lauciani@ingv.it) Received: from ultra.ingv.it (ultra.ingv.it [193.206.122.133]) by mx1.freebsd.org (Postfix) with ESMTP id 6896813C442 for ; Thu, 7 Feb 2008 08:04:12 +0000 (UTC) (envelope-from lauciani@ingv.it) Received: from [192.168.1.2] (host80-231-dynamic.16-87-r.retail.telecomitalia.it [87.16.231.80]) by ultra.ingv.it (Postfix) with ESMTP id BD9CC1EC012 for ; Thu, 7 Feb 2008 08:35:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v753) To: freebsd-i386@freebsd.org Message-Id: <1A8C2170-7EA0-4653-B1DA-429E23893E01@ingv.it> From: Valentino Lauciani Date: Thu, 7 Feb 2008 08:35:12 +0100 X-Mailer: Apple Mail (2.753) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: HELP ME! Update 6.2 -> 6.3 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 08:04:13 -0000 Hi I've read the guide: http://www.cyberciti.biz/faq/upgrade-freebsd-server-software/ And after first reboot, I received this message: Trying to mount root from ufs: /dev/mf1d0s1a Segmentation fault Starting file system check: /dev/mfid0s1a: file system clean; skipping checks pid 84 (fsck), uid0: exited on signal 11 Segmentation fault Unknow error: help! Feb 6 21:19:39 init: /bin/sh on /etc/rc terminated abnormaly, going =20 to single mode Enter full pathname of shell or Return for /bin/sh What does it mean? What am I doing now? Can I reload last configuration? Help me, thank=92s.= From owner-freebsd-i386@FreeBSD.ORG Thu Feb 7 21:30:02 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0273516A4C1 for ; Thu, 7 Feb 2008 21: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 D59B913C4DD for ; Thu, 7 Feb 2008 21: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.2/8.14.2) with ESMTP id m17LU1t5007759 for ; Thu, 7 Feb 2008 21:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m17LU17v007758; Thu, 7 Feb 2008 21:30:01 GMT (envelope-from gnats) Resent-Date: Thu, 7 Feb 2008 21:30:01 GMT Resent-Message-Id: <200802072130.m17LU17v007758@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, chris Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C0B16A418 for ; Thu, 7 Feb 2008 21:25:45 +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 49CF013C46E for ; Thu, 7 Feb 2008 21:25:45 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m17LNdTc014318 for ; Thu, 7 Feb 2008 21:23:39 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m17LNdKu014307; Thu, 7 Feb 2008 21:23:39 GMT (envelope-from nobody) Message-Id: <200802072123.m17LNdKu014307@www.freebsd.org> Date: Thu, 7 Feb 2008 21:23:39 GMT From: chris To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/120372: linux-sun-jre1.6.0 plugin doesn't work with a linux browser X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2008 21:30:02 -0000 >Number: 120372 >Category: i386 >Synopsis: linux-sun-jre1.6.0 plugin doesn't work with a linux browser >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 07 21:30:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: chris >Release: freeBSD 6.3 >Organization: >Environment: # uname -a FreeBSD bsd.ch.bluee.net 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: linux java plugin doesn't work with linux-seamonkey ! I have installed on freeBSD 6.3 from ports: linux-sun-jre16 nspluginwrapper linux-seamonkey I've tried to create a symlink to the java plugin: # ln -s /usr/X11R6/linux-sun-jre1.6.0/plugin/i386/ns7/libjavaplugin_oji.so /usr/X11R6/lib/linux-seamonkey/plugins/libjavaplugin_oji.so[/code] and: # ln -s /usr/X11R6/linux-sun-jre1.6.0/plugin/i386/ns7/libjavaplugin_oji.so /usr/X11R6/lib/browser_plugins/libjavaplugin_oji.so but still doesn't work. >How-To-Repeat: install linux-sun-jre16 and create a symlink in the linux browser plugin. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Fri Feb 8 09:10:43 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B7016A417; Fri, 8 Feb 2008 09:10:43 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2230D13C4E9; Fri, 8 Feb 2008 09:10:43 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m189AglG064098; Fri, 8 Feb 2008 09:10:43 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m189AgVB064094; Fri, 8 Feb 2008 09:10:42 GMT (envelope-from remko) Date: Fri, 8 Feb 2008 09:10:42 GMT Message-Id: <200802080910.m189AgVB064094@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: ports/120372: java/linux-sun-jdk16: linux-sun-jre1.6.0 plugin doesn't work with a linux browser X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 09:10:43 -0000 Old Synopsis: linux-sun-jre1.6.0 plugin doesn't work with a linux browser New Synopsis: java/linux-sun-jdk16: linux-sun-jre1.6.0 plugin doesn't work with a linux browser Responsible-Changed-From-To: freebsd-i386->freebsd-ports-bugs Responsible-Changed-By: remko Responsible-Changed-When: Fri Feb 8 09:10:25 UTC 2008 Responsible-Changed-Why: reassign to ports group http://www.freebsd.org/cgi/query-pr.cgi?pr=120372 From owner-freebsd-i386@FreeBSD.ORG Fri Feb 8 12:30:23 2008 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 202A716A419; Fri, 8 Feb 2008 12:30:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id B1D1013C45A; Fri, 8 Feb 2008 12:30:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m18CUCno015548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 23:30:15 +1100 Date: Fri, 8 Feb 2008 23:30:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Oliver B. Warzecha" In-Reply-To: <20080206155514.GD1361@karnevil9.amarok.ping.de> Message-ID: <20080208222001.K25038@besplex.bde.org> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> <20080206155514.GD1361@karnevil9.amarok.ping.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 12:30:23 -0000 On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: > Addon to my last mail, as I just discovered the i440BX-Specs, just > 2 clicks away from one of the pages where I last searched for info. > They are downloadable from > http://www.intel.com/design/intarch/datashts/290562.htm I found I even have the 1998 version of that locally. > On page 84, there is specified that the RTC index register > is write only (as I found out in practical testing :-). And it I think it actually says that the register is more or less readable "Reads ... flow through to the ISA bus, but no RT... will be generated". It says that the register is traditionally write-only. However, ISTR successfully reading this register from debuggers on 5-10 machines over the last 15-20 years. Van Gilluwe's book published in 1993 or 1994 says that the index register is write-only and complains that h/w designers keep making the mistake of write-only registers. Van Gilluwe gives mainly access methods that take not just 2, but 3 ISA accesses to the RTC ports, and 2 I/O delays of 1-16 usec to ensure slowing things down further. The extra RTC access is to turn the NMI disable bit in the index register back off after turning it on together with setting the index. It doesn't bother to preserve either the old or the new index, and always leaves the index set at 0. This NMI bit is more portable than I thought -- the Intel data sheet documents it. This much care with NMIs may be required if NMIs actually happen. FreeBSD is generally careless with NMIs, and doesn't touch the NMI bit in its RTC access functions except to blindly clear it. > is also described as a latch register, which makes the current > code "working by pure chance", as it's implementation dependent > which bus noise happens on the other side of the gate. (If I > didn't get the meaning of "latch" in this case totally wrong) The wording is: "[Index register]: latched by the real time clock..."; [Data register]: Data written to standard RAM bank address selected by RTC Index...". These descriptions conflict a bit. The first one doesn't quite say that the data value at the time of the write to the index register is latched to be read by any later read of the data register, and the second one doesn't quite say that the index register is just a select (latched at the time of read of the data register) for the data. The first behaviour can be tested for (try to latch the current seconds value and read the data register several seconds later and see if you got the old value (*)), but we know that it doesn't work like that on more machines, else my change would break most machines (RTC interrupts would be broken if reading the data register didn't give current data). I think you just have unusual hardware, else more machines would have broken. However, I fear there is a problem somewhere, since RTC interrupts broke a couple of times last week on my main machine (with a VIA VT8237(??) bridge). It's surprising how well FreeBSD works with the statistics clock stopped. I haven't looked at your other hardware reference yet. (*) A quick test using ddb on my hardware shows that reading the data register for the seconds register gives its current value, not the value at the time of the write of the seconds register index (0) to the index register. Then subsequent reads of the data register with no intervening write to the index register keep returning the current seconds register. I tested using ddb, and trust ddb not to access the RTC in normal operation. What does your hardware do for this? Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Feb 8 12:40:02 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99A0D16A421 for ; Fri, 8 Feb 2008 12:40: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 897B213C45E for ; Fri, 8 Feb 2008 12:40: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.2/8.14.2) with ESMTP id m18Ce2B1080913 for ; Fri, 8 Feb 2008 12:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m18Ce2nh080906; Fri, 8 Feb 2008 12:40:02 GMT (envelope-from gnats) Date: Fri, 8 Feb 2008 12:40:02 GMT Message-Id: <200802081240.m18Ce2nh080906@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 12:40:02 -0000 The following reply was made to PR i386/119574; it has been noted by GNATS. From: Bruce Evans To: "Oliver B. Warzecha" Cc: Bruce Evans , FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Date: Fri, 8 Feb 2008 23:30:12 +1100 (EST) On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: > Addon to my last mail, as I just discovered the i440BX-Specs, just > 2 clicks away from one of the pages where I last searched for info. > They are downloadable from > http://www.intel.com/design/intarch/datashts/290562.htm I found I even have the 1998 version of that locally. > On page 84, there is specified that the RTC index register > is write only (as I found out in practical testing :-). And it I think it actually says that the register is more or less readable "Reads ... flow through to the ISA bus, but no RT... will be generated". It says that the register is traditionally write-only. However, ISTR successfully reading this register from debuggers on 5-10 machines over the last 15-20 years. Van Gilluwe's book published in 1993 or 1994 says that the index register is write-only and complains that h/w designers keep making the mistake of write-only registers. Van Gilluwe gives mainly access methods that take not just 2, but 3 ISA accesses to the RTC ports, and 2 I/O delays of 1-16 usec to ensure slowing things down further. The extra RTC access is to turn the NMI disable bit in the index register back off after turning it on together with setting the index. It doesn't bother to preserve either the old or the new index, and always leaves the index set at 0. This NMI bit is more portable than I thought -- the Intel data sheet documents it. This much care with NMIs may be required if NMIs actually happen. FreeBSD is generally careless with NMIs, and doesn't touch the NMI bit in its RTC access functions except to blindly clear it. > is also described as a latch register, which makes the current > code "working by pure chance", as it's implementation dependent > which bus noise happens on the other side of the gate. (If I > didn't get the meaning of "latch" in this case totally wrong) The wording is: "[Index register]: latched by the real time clock..."; [Data register]: Data written to standard RAM bank address selected by RTC Index...". These descriptions conflict a bit. The first one doesn't quite say that the data value at the time of the write to the index register is latched to be read by any later read of the data register, and the second one doesn't quite say that the index register is just a select (latched at the time of read of the data register) for the data. The first behaviour can be tested for (try to latch the current seconds value and read the data register several seconds later and see if you got the old value (*)), but we know that it doesn't work like that on more machines, else my change would break most machines (RTC interrupts would be broken if reading the data register didn't give current data). I think you just have unusual hardware, else more machines would have broken. However, I fear there is a problem somewhere, since RTC interrupts broke a couple of times last week on my main machine (with a VIA VT8237(??) bridge). It's surprising how well FreeBSD works with the statistics clock stopped. I haven't looked at your other hardware reference yet. (*) A quick test using ddb on my hardware shows that reading the data register for the seconds register gives its current value, not the value at the time of the write of the seconds register index (0) to the index register. Then subsequent reads of the data register with no intervening write to the index register keep returning the current seconds register. I tested using ddb, and trust ddb not to access the RTC in normal operation. What does your hardware do for this? Bruce From owner-freebsd-i386@FreeBSD.ORG Sat Feb 9 01:42:15 2008 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847D016A41A for ; Sat, 9 Feb 2008 01:42:15 +0000 (UTC) (envelope-from obw@amarok.ping.de) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by mx1.freebsd.org (Postfix) with SMTP id 8FDD513C457 for ; Sat, 9 Feb 2008 01:42:14 +0000 (UTC) (envelope-from obw@amarok.ping.de) Received: (qmail 9268 invoked by uid 10); 9 Feb 2008 01:42:12 -0000 Received: from amarok.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 9 Feb 2008 01:42:12 -0000 Received: from karnevil9.amarok.ping.de (localhost [127.0.0.1]) by karnevil9.amarok.ping.de (8.13.8/8.13.8) with ESMTP id m191ZRfF001537; Sat, 9 Feb 2008 02:35:27 +0100 (CET) (envelope-from obw@karnevil9.amarok.ping.de) Received: (from obw@localhost) by karnevil9.amarok.ping.de (8.13.8/8.13.8/Submit) id m191ZQUr001536; Sat, 9 Feb 2008 02:35:26 +0100 (CET) (envelope-from obw) Date: Sat, 9 Feb 2008 02:35:26 +0100 From: "Oliver B. Warzecha" To: Bruce Evans Message-ID: <20080209013526.GA1216@karnevil9.amarok.ping.de> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> <20080206155514.GD1361@karnevil9.amarok.ping.de> <20080208222001.K25038@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080208222001.K25038@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-message-flag: Please send plain text messages only. Thank you. Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 01:42:15 -0000 On Fri, Feb 08, 2008 at 11:30:12PM +1100, Bruce Evans wrote: > On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: > > >Addon to my last mail, as I just discovered the i440BX-Specs, just > >2 clicks away from one of the pages where I last searched for info. > >They are downloadable from > >http://www.intel.com/design/intarch/datashts/290562.htm > > I found I even have the 1998 version of that locally. Note that I have a 430HX chipset, the datasheet of the 82371SB is some kind of vague concerning the RTC access, in fact only the NMI functionality seems documented there. I also checked the ICH (i815) specs, on page 234 of the PDF (p. 8-44) it says: "Software must preserve the value of bit 7 at I/O addresses 70h and 74h. When writing to these addresses, software must first read the value, and then write the same value for bit 7 during the sequential address write." Given that in the 440BX documentation there is a written "Attribute: write-only", which is admittedly contradicted in the next sentence, which you quoted below, it may well be that the access specification for this particular address has changed over time. > >On page 84, there is specified that the RTC index register > >is write only (as I found out in practical testing :-). And it > > I think it actually says that the register is more or less readable > "Reads ... flow through to the ISA bus, but no RT... will be generated". > It says that the register is traditionally write-only. However, ISTR > successfully reading this register from debuggers on 5-10 machines > over the last 15-20 years. Well... IIRC a read of the register always resulted in 0xA9 here, no matter what was written before. But "more or less readable" seems to describe the status quo quite well. ;-) Do you remember if there was any machine with a HX chipset in your list of machines. Perhaps this is a peculiarity of the 82437SB. I see that this chip (also called PIIX3) was also used in the VX chipset. > Van Gilluwe's book published in 1993 or 1994 says that the index Oh :-) This was the book that I thought to be helpful if after some googling. > register is write-only and complains that h/w designers keep making > the mistake of write-only registers. Van Gilluwe gives mainly access > methods that take not just 2, but 3 ISA accesses to the RTC ports, and > 2 I/O delays of 1-16 usec to ensure slowing things down further. The > extra RTC access is to turn the NMI disable bit in the index register > back off after turning it on together with setting the index. It > doesn't bother to preserve either the old or the new index, and always > leaves the index set at 0. This NMI bit is more portable than I thought > -- the Intel data sheet documents it. This much care with NMIs may > be required if NMIs actually happen. FreeBSD is generally careless > with NMIs, and doesn't touch the NMI bit in its RTC access functions > except to blindly clear it. Mmmh... NMIs seem to be used for indicating ECC errors in RAM. But this is a different story... > The wording is: "[Index register]: latched by the real time clock..."; > [Data register]: Data written to standard RAM bank address selected > by RTC Index...". These descriptions conflict a bit. The first one I think this may be well the major problem here, that the descriptions are less than clear and the specifications have varied over the years. > doesn't quite say that the data value at the time of the write to the > index register is latched to be read by any later read of the data > register, and the second one doesn't quite say that the index register > is just a select (latched at the time of read of the data register) > for the data. The first behaviour can be tested for (try to latch the > current seconds value and read the data register several seconds later > and see if you got the old value (*)), but we know that it doesn't work > like that on more machines, else my change would break most machines > (RTC interrupts would be broken if reading the data register didn't > give current data). What is the call profile? Does "read same register again" happen in the normal use case? Or maybe there are intermittent accesses which mask the problem. It might even be depending on a running ntpd or timed, which is correcting the RTC... Also, this machine here is relatively slow (200 Mhz K6), it can also be that on a faster machine the access follows up fast enough so that the circuits behind that gate keep state (see my comment on capacitors in a past mail). > I think you just have unusual hardware, else more machines would have > broken. However, I fear there is a problem somewhere, since RTC > interrupts broke a couple of times last week on my main machine (with > a VIA VT8237(??) bridge). It's surprising how well FreeBSD works with > the statistics clock stopped. I haven't looked at your other hardware > reference yet. Given this other reference I think that the problem might only occur in this particular chip set (As I mentioned, it's the reference for a "PC on a PCI card" system which uses the 430HX). I don't think, a 430HX is that unusual, although it's rapidly reaching highschool age. Given that the problem only gets noticed when the machine boots up under surveillance (When it gets switched on it does come up after some minutes... if unattended, you might not notice the delay) I just found I have another HX board lying around here (a P55T2P4 - no SCSI and only 4 mem slots), maybe I can slap something together, so I can check it with this one, major problem being the AT power supply. A pragmatic solution would be to implement both the "secure" and the "fast" strategy and to select the correct one at boot time after checking for signs that the "fast" does not work, for example. A config option might be overkill. ;) > (*) A quick test using ddb on my hardware shows that reading the data > register for the seconds register gives its current value, not the > value at the time of the write of the seconds register index (0) to > the index register. Then subsequent reads of the data register > with no intervening write to the index register keep returning the > current seconds register. I tested using ddb, and trust ddb not to > access the RTC in normal operation. What does your hardware do for > this? Having played around with ddb now, how do you do it? I don't see any possibility to access I/O space besides writing some assembler code. Coming from a happy 6502/68k background, where all I/O was memory mapped, I am scratching my head here. That the man page for ddb needs an urgent update does not help here, too. So maybe I missed the command, there seem to be roughly 4 dozen undocumented options for show only. OBW From owner-freebsd-i386@FreeBSD.ORG Sat Feb 9 01:50:03 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F2C16A418 for ; Sat, 9 Feb 2008 01:50: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 16FFF13C447 for ; Sat, 9 Feb 2008 01:50: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.2/8.14.2) with ESMTP id m191o2Cj043562 for ; Sat, 9 Feb 2008 01:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m191o20h043561; Sat, 9 Feb 2008 01:50:02 GMT (envelope-from gnats) Date: Sat, 9 Feb 2008 01:50:02 GMT Message-Id: <200802090150.m191o20h043561@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Oliver B. Warzecha" Cc: Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Oliver B. Warzecha" List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 01:50:03 -0000 The following reply was made to PR i386/119574; it has been noted by GNATS. From: "Oliver B. Warzecha" To: Bruce Evans Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Date: Sat, 9 Feb 2008 02:35:26 +0100 On Fri, Feb 08, 2008 at 11:30:12PM +1100, Bruce Evans wrote: > On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: > > >Addon to my last mail, as I just discovered the i440BX-Specs, just > >2 clicks away from one of the pages where I last searched for info. > >They are downloadable from > >http://www.intel.com/design/intarch/datashts/290562.htm > > I found I even have the 1998 version of that locally. Note that I have a 430HX chipset, the datasheet of the 82371SB is some kind of vague concerning the RTC access, in fact only the NMI functionality seems documented there. I also checked the ICH (i815) specs, on page 234 of the PDF (p. 8-44) it says: "Software must preserve the value of bit 7 at I/O addresses 70h and 74h. When writing to these addresses, software must first read the value, and then write the same value for bit 7 during the sequential address write." Given that in the 440BX documentation there is a written "Attribute: write-only", which is admittedly contradicted in the next sentence, which you quoted below, it may well be that the access specification for this particular address has changed over time. > >On page 84, there is specified that the RTC index register > >is write only (as I found out in practical testing :-). And it > > I think it actually says that the register is more or less readable > "Reads ... flow through to the ISA bus, but no RT... will be generated". > It says that the register is traditionally write-only. However, ISTR > successfully reading this register from debuggers on 5-10 machines > over the last 15-20 years. Well... IIRC a read of the register always resulted in 0xA9 here, no matter what was written before. But "more or less readable" seems to describe the status quo quite well. ;-) Do you remember if there was any machine with a HX chipset in your list of machines. Perhaps this is a peculiarity of the 82437SB. I see that this chip (also called PIIX3) was also used in the VX chipset. > Van Gilluwe's book published in 1993 or 1994 says that the index Oh :-) This was the book that I thought to be helpful if after some googling. > register is write-only and complains that h/w designers keep making > the mistake of write-only registers. Van Gilluwe gives mainly access > methods that take not just 2, but 3 ISA accesses to the RTC ports, and > 2 I/O delays of 1-16 usec to ensure slowing things down further. The > extra RTC access is to turn the NMI disable bit in the index register > back off after turning it on together with setting the index. It > doesn't bother to preserve either the old or the new index, and always > leaves the index set at 0. This NMI bit is more portable than I thought > -- the Intel data sheet documents it. This much care with NMIs may > be required if NMIs actually happen. FreeBSD is generally careless > with NMIs, and doesn't touch the NMI bit in its RTC access functions > except to blindly clear it. Mmmh... NMIs seem to be used for indicating ECC errors in RAM. But this is a different story... > The wording is: "[Index register]: latched by the real time clock..."; > [Data register]: Data written to standard RAM bank address selected > by RTC Index...". These descriptions conflict a bit. The first one I think this may be well the major problem here, that the descriptions are less than clear and the specifications have varied over the years. > doesn't quite say that the data value at the time of the write to the > index register is latched to be read by any later read of the data > register, and the second one doesn't quite say that the index register > is just a select (latched at the time of read of the data register) > for the data. The first behaviour can be tested for (try to latch the > current seconds value and read the data register several seconds later > and see if you got the old value (*)), but we know that it doesn't work > like that on more machines, else my change would break most machines > (RTC interrupts would be broken if reading the data register didn't > give current data). What is the call profile? Does "read same register again" happen in the normal use case? Or maybe there are intermittent accesses which mask the problem. It might even be depending on a running ntpd or timed, which is correcting the RTC... Also, this machine here is relatively slow (200 Mhz K6), it can also be that on a faster machine the access follows up fast enough so that the circuits behind that gate keep state (see my comment on capacitors in a past mail). > I think you just have unusual hardware, else more machines would have > broken. However, I fear there is a problem somewhere, since RTC > interrupts broke a couple of times last week on my main machine (with > a VIA VT8237(??) bridge). It's surprising how well FreeBSD works with > the statistics clock stopped. I haven't looked at your other hardware > reference yet. Given this other reference I think that the problem might only occur in this particular chip set (As I mentioned, it's the reference for a "PC on a PCI card" system which uses the 430HX). I don't think, a 430HX is that unusual, although it's rapidly reaching highschool age. Given that the problem only gets noticed when the machine boots up under surveillance (When it gets switched on it does come up after some minutes... if unattended, you might not notice the delay) I just found I have another HX board lying around here (a P55T2P4 - no SCSI and only 4 mem slots), maybe I can slap something together, so I can check it with this one, major problem being the AT power supply. A pragmatic solution would be to implement both the "secure" and the "fast" strategy and to select the correct one at boot time after checking for signs that the "fast" does not work, for example. A config option might be overkill. ;) > (*) A quick test using ddb on my hardware shows that reading the data > register for the seconds register gives its current value, not the > value at the time of the write of the seconds register index (0) to > the index register. Then subsequent reads of the data register > with no intervening write to the index register keep returning the > current seconds register. I tested using ddb, and trust ddb not to > access the RTC in normal operation. What does your hardware do for > this? Having played around with ddb now, how do you do it? I don't see any possibility to access I/O space besides writing some assembler code. Coming from a happy 6502/68k background, where all I/O was memory mapped, I am scratching my head here. That the man page for ddb needs an urgent update does not help here, too. So maybe I missed the command, there seem to be roughly 4 dozen undocumented options for show only. OBW From owner-freebsd-i386@FreeBSD.ORG Sat Feb 9 06:13:56 2008 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F84316A418; Sat, 9 Feb 2008 06:13:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id DF5B913C4CE; Sat, 9 Feb 2008 06:13:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m196DjL6011366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 17:13:48 +1100 Date: Sat, 9 Feb 2008 17:13:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Oliver B. Warzecha" In-Reply-To: <20080209013526.GA1216@karnevil9.amarok.ping.de> Message-ID: <20080209162051.N28112@besplex.bde.org> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> <20080206155514.GD1361@karnevil9.amarok.ping.de> <20080208222001.K25038@besplex.bde.org> <20080209013526.GA1216@karnevil9.amarok.ping.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 06:13:56 -0000 On Sat, 9 Feb 2008, Oliver B. Warzecha wrote: > On Fri, Feb 08, 2008 at 11:30:12PM +1100, Bruce Evans wrote: >> On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: >> >>> Addon to my last mail, as I just discovered the i440BX-Specs, just >>> 2 clicks away from one of the pages where I last searched for info. >>> They are downloadable from >>> http://www.intel.com/design/intarch/datashts/290562.htm >> >> I found I even have the 1998 version of that locally. > > Note that I have a 430HX chipset, the datasheet of the 82371SB > is some kind of vague concerning the RTC access, in fact only > the NMI functionality seems documented there. I happen to have an old BX system online. It is my only system handy that has an unreadable port 0x70: %%% Intel 82371AB/EB/MB PIIX4/4E/4M ISA Bridge on an Abit BP6 port 0x70 is w/o (reads return 0xff) optimized RTC accesses work NVIDIA nForce MCP2 ISA Bridge on an ASUS A7N8X-E port 0x70 is r/w optimized RTC accesses work VIA VT8237(??) PCI to ISA Bridge on a Gigabyte K8VT800 port 0x70 is r/w optimized RTC accesses work ATI PCI-ISA bridge on an HP nx6325 port 0x70 is r/w optimized RTC accesses work %%% > I also checked the ICH (i815) specs, on page 234 of the PDF > (p. 8-44) it says: > "Software must preserve the value of bit 7 at I/O addresses 70h and 74h. > When writing to these addresses, software must first read the value, > and then write the same value for bit 7 during the sequential address > write." Maybe it is actually readable on the i815. On my 82371, FreeBSD never sets the NMI bit in writes, so the read return of 0xff indicates that even the NMI bit is w/o. > Given that in the 440BX documentation there is a written "Attribute: > write-only", which is admittedly contradicted in the next sentence, > which you quoted below, it may well be that the access specification > for this particular address has changed over time. Or it may be w/o mainly on original ATs and Intel chipsets. > Do you remember if there was any machine with a HX chipset in your > list of machines. Perhaps this is a peculiarity of the 82437SB. > I see that this chip (also called PIIX3) was also used in the VX chipset. I think I had nothing between PIIX1 and PIIX4 except some other VIA chipsets. The system with the PIIX1 still works but is not worth turning on even for testing :-). >> doesn't quite say that the data value at the time of the write to the >> index register is latched to be read by any later read of the data >> register, and the second one doesn't quite say that the index register >> is just a select (latched at the time of read of the data register) >> for the data. The first behaviour can be tested for (try to latch the >> current seconds value and read the data register several seconds later >> and see if you got the old value (*)), but we know that it doesn't work >> like that on more machines, else my change would break most machines >> (RTC interrupts would be broken if reading the data register didn't >> give current data). > > What is the call profile? Does "read same register again" happen in > the normal use case? Or maybe there are intermittent accesses which > mask the problem. It might even be depending on a running ntpd > or timed, which is correcting the RTC... The RTC is almost never accessed accept by rtcintr(), and with LAPIC timer interrupts rtcintr() is not used. At least a few years ago, the only other RTC accesses were for reading the time and initializing the RTC and the fd driver on bootup, for setting the time later, and for APM and maybe ACPI to reinitialize the RTC after un-suspend (the un-suspend hook seems to be broken on amd64). ntpd only sets the RTC when it steps the clock; slews by ntpd and timed only do micro-adjustments which don't affect the RTC. Since the RTC is rarely accessed by anything except rtcintr(), missing locking for the accesses rarely mattered. (The locking is mostly fixed now.) > Also, this machine here is relatively slow (200 Mhz K6), it can also > be that on a faster machine the access follows up fast enough so > that the circuits behind that gate keep state (see my comment on > capacitors in a past mail). There would only be timing preoblems like that if the hardware is really primitive or has weird latching semantics. I see no problems with the index and data register accesses separated by many seconds due to my typing in the accesses in ddb. > Given this other reference I think that the problem might only occur in > this particular chip set (As I mentioned, it's the reference for > a "PC on a PCI card" system which uses the 430HX). I don't think, > a 430HX is that unusual, although it's rapidly reaching highschool age. > Given that the problem only gets noticed when the machine boots up > under surveillance (When it gets switched on it does come up after some > minutes... if unattended, you might not notice the delay) I checked your other reference, where the need to rewrite the index register but not much else is clearly stated. Was that for the 430HX? > I just found I have another HX board lying around here (a P55T2P4 - > no SCSI and only 4 mem slots), maybe I can slap something together, so > I can check it with this one, major problem being the AT power supply. My PIIX1 is on the slghtly earlier and/or lower end P55TP4XE. > A pragmatic solution would be to implement both the "secure" and the > "fast" strategy and to select the correct one at boot time after > checking for signs that the "fast" does not work, for example. > A config option might be overkill. ;) Any configuration might be overkill. >> (*) A quick test using ddb on my hardware shows that reading the data >> register for the seconds register gives its current value, not the >> value at the time of the write of the seconds register index (0) to >> the index register. Then subsequent reads of the data register >> with no intervening write to the index register keep returning the >> current seconds register. I tested using ddb, and trust ddb not to >> access the RTC in normal operation. What does your hardware do for >> this? > > Having played around with ddb now, how do you do it? I don't see any > possibility to access I/O space besides writing some assembler code. > Coming from a happy 6502/68k background, where all I/O was > memory mapped, I am scratching my head here. That the man page > for ddb needs an urgent update does not help here, too. So maybe > I missed the command, there seem to be roughly 4 dozen undocumented > options for show only. It's just "call inb(port) and call outb(port, data)", where inb() and outb() are ordinary functions whose sole purpose is to let ddb call them (the kernel uses inline or different versions of these in normal operations). ddb can call any function (but most not safely, and these not safely unless the parameters are safe) and the man page is too small to list them all. I sometimes miss inw/outw/inl/outl but am too lazy to add these to ddb. My 1980's debugger has these. Ports could also be mapped to (virtual) memory so that you can examine and write to them using memory access commands and not have to learn a different and less convenient set of commands. My 1980's debugger doesn't do this but copies DOS DEBUG with minor improvements. Bruce From owner-freebsd-i386@FreeBSD.ORG Sat Feb 9 06:20:02 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A2616A419 for ; Sat, 9 Feb 2008 06:20: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 AA69413C45B for ; Sat, 9 Feb 2008 06:20: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.2/8.14.2) with ESMTP id m196K22a064261 for ; Sat, 9 Feb 2008 06:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m196K20c064260; Sat, 9 Feb 2008 06:20:02 GMT (envelope-from gnats) Date: Sat, 9 Feb 2008 06:20:02 GMT Message-Id: <200802090620.m196K20c064260@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Bruce Evans Cc: Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 06:20:02 -0000 The following reply was made to PR i386/119574; it has been noted by GNATS. From: Bruce Evans To: "Oliver B. Warzecha" Cc: Bruce Evans , FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Date: Sat, 9 Feb 2008 17:13:45 +1100 (EST) On Sat, 9 Feb 2008, Oliver B. Warzecha wrote: > On Fri, Feb 08, 2008 at 11:30:12PM +1100, Bruce Evans wrote: >> On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: >> >>> Addon to my last mail, as I just discovered the i440BX-Specs, just >>> 2 clicks away from one of the pages where I last searched for info. >>> They are downloadable from >>> http://www.intel.com/design/intarch/datashts/290562.htm >> >> I found I even have the 1998 version of that locally. > > Note that I have a 430HX chipset, the datasheet of the 82371SB > is some kind of vague concerning the RTC access, in fact only > the NMI functionality seems documented there. I happen to have an old BX system online. It is my only system handy that has an unreadable port 0x70: %%% Intel 82371AB/EB/MB PIIX4/4E/4M ISA Bridge on an Abit BP6 port 0x70 is w/o (reads return 0xff) optimized RTC accesses work NVIDIA nForce MCP2 ISA Bridge on an ASUS A7N8X-E port 0x70 is r/w optimized RTC accesses work VIA VT8237(??) PCI to ISA Bridge on a Gigabyte K8VT800 port 0x70 is r/w optimized RTC accesses work ATI PCI-ISA bridge on an HP nx6325 port 0x70 is r/w optimized RTC accesses work %%% > I also checked the ICH (i815) specs, on page 234 of the PDF > (p. 8-44) it says: > "Software must preserve the value of bit 7 at I/O addresses 70h and 74h. > When writing to these addresses, software must first read the value, > and then write the same value for bit 7 during the sequential address > write." Maybe it is actually readable on the i815. On my 82371, FreeBSD never sets the NMI bit in writes, so the read return of 0xff indicates that even the NMI bit is w/o. > Given that in the 440BX documentation there is a written "Attribute: > write-only", which is admittedly contradicted in the next sentence, > which you quoted below, it may well be that the access specification > for this particular address has changed over time. Or it may be w/o mainly on original ATs and Intel chipsets. > Do you remember if there was any machine with a HX chipset in your > list of machines. Perhaps this is a peculiarity of the 82437SB. > I see that this chip (also called PIIX3) was also used in the VX chipset. I think I had nothing between PIIX1 and PIIX4 except some other VIA chipsets. The system with the PIIX1 still works but is not worth turning on even for testing :-). >> doesn't quite say that the data value at the time of the write to the >> index register is latched to be read by any later read of the data >> register, and the second one doesn't quite say that the index register >> is just a select (latched at the time of read of the data register) >> for the data. The first behaviour can be tested for (try to latch the >> current seconds value and read the data register several seconds later >> and see if you got the old value (*)), but we know that it doesn't work >> like that on more machines, else my change would break most machines >> (RTC interrupts would be broken if reading the data register didn't >> give current data). > > What is the call profile? Does "read same register again" happen in > the normal use case? Or maybe there are intermittent accesses which > mask the problem. It might even be depending on a running ntpd > or timed, which is correcting the RTC... The RTC is almost never accessed accept by rtcintr(), and with LAPIC timer interrupts rtcintr() is not used. At least a few years ago, the only other RTC accesses were for reading the time and initializing the RTC and the fd driver on bootup, for setting the time later, and for APM and maybe ACPI to reinitialize the RTC after un-suspend (the un-suspend hook seems to be broken on amd64). ntpd only sets the RTC when it steps the clock; slews by ntpd and timed only do micro-adjustments which don't affect the RTC. Since the RTC is rarely accessed by anything except rtcintr(), missing locking for the accesses rarely mattered. (The locking is mostly fixed now.) > Also, this machine here is relatively slow (200 Mhz K6), it can also > be that on a faster machine the access follows up fast enough so > that the circuits behind that gate keep state (see my comment on > capacitors in a past mail). There would only be timing preoblems like that if the hardware is really primitive or has weird latching semantics. I see no problems with the index and data register accesses separated by many seconds due to my typing in the accesses in ddb. > Given this other reference I think that the problem might only occur in > this particular chip set (As I mentioned, it's the reference for > a "PC on a PCI card" system which uses the 430HX). I don't think, > a 430HX is that unusual, although it's rapidly reaching highschool age. > Given that the problem only gets noticed when the machine boots up > under surveillance (When it gets switched on it does come up after some > minutes... if unattended, you might not notice the delay) I checked your other reference, where the need to rewrite the index register but not much else is clearly stated. Was that for the 430HX? > I just found I have another HX board lying around here (a P55T2P4 - > no SCSI and only 4 mem slots), maybe I can slap something together, so > I can check it with this one, major problem being the AT power supply. My PIIX1 is on the slghtly earlier and/or lower end P55TP4XE. > A pragmatic solution would be to implement both the "secure" and the > "fast" strategy and to select the correct one at boot time after > checking for signs that the "fast" does not work, for example. > A config option might be overkill. ;) Any configuration might be overkill. >> (*) A quick test using ddb on my hardware shows that reading the data >> register for the seconds register gives its current value, not the >> value at the time of the write of the seconds register index (0) to >> the index register. Then subsequent reads of the data register >> with no intervening write to the index register keep returning the >> current seconds register. I tested using ddb, and trust ddb not to >> access the RTC in normal operation. What does your hardware do for >> this? > > Having played around with ddb now, how do you do it? I don't see any > possibility to access I/O space besides writing some assembler code. > Coming from a happy 6502/68k background, where all I/O was > memory mapped, I am scratching my head here. That the man page > for ddb needs an urgent update does not help here, too. So maybe > I missed the command, there seem to be roughly 4 dozen undocumented > options for show only. It's just "call inb(port) and call outb(port, data)", where inb() and outb() are ordinary functions whose sole purpose is to let ddb call them (the kernel uses inline or different versions of these in normal operations). ddb can call any function (but most not safely, and these not safely unless the parameters are safe) and the man page is too small to list them all. I sometimes miss inw/outw/inl/outl but am too lazy to add these to ddb. My 1980's debugger has these. Ports could also be mapped to (virtual) memory so that you can examine and write to them using memory access commands and not have to learn a different and less convenient set of commands. My 1980's debugger doesn't do this but copies DOS DEBUG with minor improvements. Bruce From owner-freebsd-i386@FreeBSD.ORG Sat Feb 9 13:11:22 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FDF516A41A; Sat, 9 Feb 2008 13:11:22 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58F9C13C44B; Sat, 9 Feb 2008 13:11:22 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m19DBMBe094436; Sat, 9 Feb 2008 13:11:22 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m19DBLgI094432; Sat, 9 Feb 2008 13:11:21 GMT (envelope-from remko) Date: Sat, 9 Feb 2008 13:11:21 GMT Message-Id: <200802091311.m19DBLgI094432@freefall.freebsd.org> To: freebsd@chillt.de, remko@FreeBSD.org, freebsd-i386@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: i386/75898: Exception and reboot: Loader and kernel use SSE2 instructions before they get enabled X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2008 13:11:22 -0000 Synopsis: Exception and reboot: Loader and kernel use SSE2 instructions before they get enabled State-Changed-From-To: patched->closed State-Changed-By: remko State-Changed-When: Sat Feb 9 13:11:21 UTC 2008 State-Changed-Why: This needs MFC to RELENG_5, though I would like people facing this to encourage them to use FreeBSD-6 and/or FreeBSD-7 (preferred) since in the not too long future REL_5 will no longer be supported. Close the ticket for those reasons http://www.freebsd.org/cgi/query-pr.cgi?pr=75898