From mmp at actinet.cz Wed Oct 1 22:40:02 2008 From: mmp at actinet.cz (Milon Papezik) Date: Wed Oct 1 23:45:44 2008 Subject: amd64/127787: [lor] 3 lock LOR in recent CURRENT Message-ID: <200810012234.m91MYq0s058514@www.freebsd.org> >Number: 127787 >Category: amd64 >Synopsis: [lor] 3 lock LOR in recent CURRENT >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 01 22:40:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Milon Papezik >Release: FreeBSD 8.0 - CURRENT >Organization: >Environment: FreeBSD fbsd8.papezik.cz 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sat Sep 27 03:35:37 CEST 2008 root@fbsd8.papezik.cz:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I have found three repeatable LORs in FreeBSD 8.0-CURRENT / amd64 cvsupped and rebuild in last 12 hours. I tried to identify whether some of the LORs were already reported, but I am not sure so I list them all. Especially the first is interesting as it involves 3 locks. Please let me know if I can somehow help to fix them. Trying to mount root from ufs:/dev/da0s1a lock order reversal: 1st 0xffffff0001379000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:372 2nd 0xffffff00012fed80 devfs (devfs) @ /usr/src/sys/kern/vfs_lookup.c:432 3rd 0xffffff0001378c80 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:372 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x7d8 __lockmgr_args() at __lockmgr_args+0xca8 vfs_busy() at vfs_busy+0xe7 vfs_mount_alloc() at vfs_mount_alloc+0x88 vfs_donmount() at vfs_donmount+0xdbd kernel_mount() at kernel_mount+0xa1 kernel_vmount() at kernel_vmount+0xce vfs_mountroot_try() at vfs_mountroot_try+0x102 vfs_mountroot() at vfs_mountroot+0x3f0 start_init() at start_init+0x62 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe4000ad40, rbp = 0 --- lock order reversal: 1st 0xffffff00012fe620 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2051 2nd 0xffffff0001379000 vfslock (vfslock) @ /usr/src/sys/kern/vfs_subr.c:372 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x7d8 __lockmgr_args() at __lockmgr_args+0xca8 vfs_busy() at vfs_busy+0xe7 lookup() at lookup+0x8c2 namei() at namei+0x43f kern_unlinkat() at kern_unlinkat+0x9d vfs_mountroot_try() at vfs_mountroot_try+0x418 vfs_mountroot() at vfs_mountroot+0x3f0 start_init() at start_init+0x62 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffffffe4000ad40, rbp = 0 --- lock order reversal: 1st 0xffffff0001125070 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xffffff00012fe270 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2051 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x7d8 __lockmgr_args() at __lockmgr_args+0xca8 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x92 vnode_pager_lock() at vnode_pager_lock+0x1d3 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = 0x7fffffffee90 --- >How-To-Repeat: reboot the system. >Fix: Unfortunately unknown to me. >Release-Note: >Audit-Trail: >Unformatted: From freebsd at sopwith.solgatos.com Sat Oct 4 22:30:55 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Sat Oct 4 22:31:02 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: Your message of "Fri, 26 Sep 2008 20:10:18 +0300." <20080926171018.GX47828@deviant.kiev.zoral.com.ua> Message-ID: <200810042226.WAA04290@sopwith.solgatos.com> Kostik writes: > > > Note that libgcov needs to be recompiled with -fPIC. > > > The R_X86_64_32 issue is systematic on amd64. When you build a shared > > > object, better make sure that all .o are compiled with -fPIC. > Should /usr/lib/libgcov.a be built with -fPIC, is debatable. I think it > is overkill for most other static libs from /usr/lib. I don't know what the pros and cons of -fPIC are, is there a case for libs with and without it? Having ports not build isn't acceptable. AMD64 isn't some rare and exotic architecture. > Note that there > are reasonable arguments against supplying static system libraries like > libc and libpthread. There are? I can't think of any. Mark writes: >> Ports should compile cleanly out of the box, on all archs, with no problems. > > A noble goal, but we are a long way from it, and rely on volunteers > to take maintainership of individual ports to make it happen. Does "tinderbox" build ports? Finding the problems as they are created should help a lot. From linimon at lonesome.com Sun Oct 5 06:46:13 2008 From: linimon at lonesome.com (Mark Linimon) Date: Sun Oct 5 11:28:26 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <200810042226.WAA04290@sopwith.solgatos.com> References: <20080926171018.GX47828@deviant.kiev.zoral.com.ua> <200810042226.WAA04290@sopwith.solgatos.com> Message-ID: <20081005064612.GA29867@soaustin.net> On Sat, Oct 04, 2008 at 03:26:04PM +0100, Dieter wrote: > Having ports not build isn't acceptable. AMD64 isn't some rare and exotic > architecture. [...] Does "tinderbox" build ports? Finding the problems > as they are created should help a lot. There is already a tremendous amount of QA work being done, every day, to improve the ports collection. To get some idea, see the latter part of http://www.freebsd.org/portmgr/qa.html; http://pointyhat.freebsd.org and the pages it leads to; the summary page on http://portsmon.freebsd.org/portsoverall.py, and all of its other reports (e.g.:, http://portsmon.freebsd.org/portsconcordanceforbuildenv.py?buildenv=amd64&buildenv2=i386, which is highly over-inflated right now due to a run of "try to build things on amd64 that are marked not-for-amd64 anyways); and various email sent from Ion-Mihai Tetcu on a daily basis as he does incremental builds (the former builds are bulk builds). mcl From bugmaster at FreeBSD.org Mon Oct 6 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 6 11:22:54 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200810061106.m96B6oiR035397@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125820 amd64 [k8temp] [patch] sysctl dev.k8temp.*.sensor1.* are inv o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on f amd64/116457 amd64 [install] can't install freebsd on dv9420us o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv f amd64/103259 amd64 [ar] Cannot use ataraid on nvidia nForce4+amd64 o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock called (by ata o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 78 problems total. From freebsd at max.af.czu.cz.cz Mon Oct 6 20:49:33 2008 From: freebsd at max.af.czu.cz.cz (Tomas Randa) Date: Mon Oct 6 20:52:54 2008 Subject: amd64/127451: top(1): incorrect load shown on quad core Message-ID: <48EA739A.3000506@max.af.czu.cz.cz> I have similar problem on my Xeon5000 quad core system with 7.1 PRERELEASE / AMD64. Tried anybody to change scheduler from ULE to 4BSD? I tried to change some sysctl variables, but no success. Thanks for help. Tomas Randa =============================== From: miks@skynet.lv To: bug-followup@FreeBSD.org, miks@skynet.lv Cc: Subject: Re: amd64/127451: top(1): incorrect load shown on quad core Date: Thu, 18 Sep 2008 21:50:06 +0300 I got load average around 0.5, and top show something like this "1021 processes: 1 running, 1020 sleeping CPU states: 4.9% user, 0.0% nice, 3.6% system, 0.9% interrupt, 90.6% idle" - this all is ok. then once in 2-5 minutes, there for 2-3 seconds are: "1020 processes:67 running, 912 sleeping, 1 zombie, 40 lock CPU states: 3.0% user, 0.0% nice, 96.7% system, 0.3% interrupt, 0.0% idle" - this is the problem. after this load average is 20-30 and dropping in 2-3min to 0.5. during this time system is very slow. even ssh session is freezing. most of processes are fastcgi/php, so there is not one big resource hungry process. found similar problem here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-11/msg00551.html From neldredge at math.ucsd.edu Tue Oct 7 02:00:19 2008 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Tue Oct 7 02:56:31 2008 Subject: amd64/102716: ex with no argument in an xterm gets SIGSEGV Message-ID: <200810070200.m9720JH0008770@freefall.freebsd.org> The following reply was made to PR amd64/102716; it has been noted by GNATS. From: Nate Eldredge To: bug-followup@FreeBSD.org, mjacob@FreeBSD.org Cc: Subject: Re: amd64/102716: ex with no argument in an xterm gets SIGSEGV Date: Mon, 6 Oct 2008 18:58:18 -0700 (PDT) Are you still seeing this on 7.0-RELEASE? I'm having trouble reproducing it. -- Nate Eldredge neldredge@math.ucsd.edu From rannumgen at globaleyes.net Tue Oct 7 02:20:01 2008 From: rannumgen at globaleyes.net (User1001) Date: Tue Oct 7 02:56:41 2008 Subject: amd64/127910: FBSD-7.0 amd64 nfe ethernet not completely working Message-ID: <200810070214.m972EF6I065474@www.freebsd.org> >Number: 127910 >Category: amd64 >Synopsis: FBSD-7.0 amd64 nfe ethernet not completely working >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 07 02:20:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: User1001 >Release: 7.0-Release >Organization: >Environment: FBSD-7.0-Release Sun Feb 24 2008 Sun Ultra 40 workstation dual-core AMD Opteron 2218 2GB RAM >Description: After install, NFE driver for nVidia nForce MCP55 Networking Adapter using Marvell 88E1149 Gigabit ethernet chip appears to fail to completely set up ethernet interface. IFCONFIG shows UP with proper IP, NETMASK, BROADCAST, MEDIA values with active STATUS. Yet, no external network connection works. Installing Red Hat Enterprise on same machine IS able to make external network conections. NFE driver chosen by system - not Admin. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From vwe at FreeBSD.org Tue Oct 7 20:33:44 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Tue Oct 7 20:33:50 2008 Subject: kern/127910: [nfe] FBSD-7.0 amd64 nfe ethernet not completely working Message-ID: <200810072033.m97KXicG035365@freefall.freebsd.org> Synopsis: [nfe] FBSD-7.0 amd64 nfe ethernet not completely working State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Tue Oct 7 20:31:00 UTC 2008 State-Changed-Why: Please provide a dmesg, devinfo -rv, pciconf -lv, ifconfig nfe0 for a first look at your problem. We're really bad in guessing your configuration. I don't think this is amd64 related -> kern Responsible-Changed-From-To: freebsd-amd64->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Tue Oct 7 20:31:00 UTC 2008 Responsible-Changed-Why: grab http://www.freebsd.org/cgi/query-pr.cgi?pr=127910 From volker at vwsoft.com Tue Oct 7 22:10:04 2008 From: volker at vwsoft.com (Volker) Date: Tue Oct 7 22:51:50 2008 Subject: amd64/127129: mdconfig(8) is core dumping with Segmentation Fault 11 Message-ID: <200810072210.m97MA40A040665@freefall.freebsd.org> The following reply was made to PR amd64/127129; it has been noted by GNATS. From: Volker To: bug-followup@FreeBSD.org, hakcenter@gmail.com Cc: Subject: Re: amd64/127129: mdconfig(8) is core dumping with Segmentation Fault 11 Date: Tue, 07 Oct 2008 23:43:48 +0200 Curtis, please tell us, if just running ``mdconfig'' is core dumping? Which parameters are you using? What does ``mdconfig -l'' give? Please provide gdb output (bt) of the failing mdconfig. If nobody else can reproduce your problem, we need debugging information from you. Please report back if your problem has been solved by recompiling world. Thanks Volker From tinderbox at freebsd.org Thu Oct 9 19:30:00 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 9 19:30:07 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081009192953.3699C73039@freebsd-current.sentex.ca> TB --- 2008-10-09 17:40:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-09 17:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-09 17:40:01 - cleaning the object tree TB --- 2008-10-09 17:40:53 - cvsupping the source tree TB --- 2008-10-09 17:40:53 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-09 17:41:00 - building world (CFLAGS=-O -pipe) TB --- 2008-10-09 17:41:00 - cd /src TB --- 2008-10-09 17:41:00 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 9 17:41:03 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Oct 9 19:19:30 UTC 2008 TB --- 2008-10-09 19:19:30 - generating LINT kernel config TB --- 2008-10-09 19:19:30 - cd /src/sys/amd64/conf TB --- 2008-10-09 19:19:30 - /usr/bin/make -B LINT TB --- 2008-10-09 19:19:30 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-09 19:19:30 - cd /src TB --- 2008-10-09 19:19:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 9 19:19:30 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 [...] /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c:163: warning: nested extern declaration of 'ata_atapi' /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c: In function 'ata_acard_86X_setmode': /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c:202: warning: implicit declaration of function 'ata_check_80pin' /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c:202: warning: nested extern declaration of 'ata_check_80pin' /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c: At top level: /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c:285: warning: data definition has no type or storage class /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c:285: warning: type defaults to 'int' in declaration of 'ATA_DECLARE_DRIVER' /src/sys/modules/ata/atapci/chipsets/ataacard/../../../../../dev/ata/chipsets/ata-acard.c:285: warning: parameter names (without types) in function declaration *** Error code 1 Stop in /src/sys/modules/ata/atapci/chipsets/ataacard. *** Error code 1 Stop in /src/sys/modules/ata/atapci/chipsets. *** Error code 1 Stop in /src/sys/modules/ata/atapci. *** Error code 1 Stop in /src/sys/modules/ata. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-09 19:29:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-09 19:29:52 - ERROR: failed to build lint kernel TB --- 2008-10-09 19:29:52 - tinderbox aborted TB --- 4907.62 user 613.63 system 6591.91 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Fri Oct 10 01:05:52 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 10 01:05:59 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081010010549.C7A2373039@freebsd-current.sentex.ca> TB --- 2008-10-09 23:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-09 23:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-09 23:20:00 - cleaning the object tree TB --- 2008-10-09 23:20:37 - cvsupping the source tree TB --- 2008-10-09 23:20:37 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-09 23:20:44 - building world (CFLAGS=-O -pipe) TB --- 2008-10-09 23:20:44 - cd /src TB --- 2008-10-09 23:20:44 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 9 23:20:45 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Oct 10 00:58:50 UTC 2008 TB --- 2008-10-10 00:58:50 - generating LINT kernel config TB --- 2008-10-10 00:58:50 - cd /src/sys/amd64/conf TB --- 2008-10-10 00:58:50 - /usr/bin/make -B LINT TB --- 2008-10-10 00:58:50 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-10 00:58:50 - cd /src TB --- 2008-10-10 00:58:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 10 00:58:50 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/ohci_pci.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/sl811hs.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/slhci_pccard.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/uark.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/u3g.c /src/sys/dev/usb/u3g.c: In function 'u3g_attach': /src/sys/dev/usb/u3g.c:169: error: 'struct u3g_softc' has no member named 'sc_intr_number' /src/sys/dev/usb/u3g.c:170: error: 'struct u3g_softc' has no member named 'sc_intr_pipe' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-10 01:05:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-10 01:05:49 - ERROR: failed to build lint kernel TB --- 2008-10-10 01:05:49 - tinderbox aborted TB --- 4739.32 user 600.56 system 6348.97 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Fri Oct 10 06:25:55 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 10 06:26:13 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081010062550.521A573039@freebsd-current.sentex.ca> TB --- 2008-10-10 04:40:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-10 04:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-10 04:40:01 - cleaning the object tree TB --- 2008-10-10 04:40:38 - cvsupping the source tree TB --- 2008-10-10 04:40:38 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-10 04:40:44 - building world (CFLAGS=-O -pipe) TB --- 2008-10-10 04:40:44 - cd /src TB --- 2008-10-10 04:40:44 - /usr/bin/make -B buildworld >>> World build started on Fri Oct 10 04:40:47 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Oct 10 06:18:50 UTC 2008 TB --- 2008-10-10 06:18:50 - generating LINT kernel config TB --- 2008-10-10 06:18:50 - cd /src/sys/amd64/conf TB --- 2008-10-10 06:18:50 - /usr/bin/make -B LINT TB --- 2008-10-10 06:18:50 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-10 06:18:50 - cd /src TB --- 2008-10-10 06:18:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 10 06:18:50 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/ohci_pci.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/sl811hs.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/slhci_pccard.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/uark.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/usb/u3g.c /src/sys/dev/usb/u3g.c: In function 'u3g_attach': /src/sys/dev/usb/u3g.c:169: error: 'struct u3g_softc' has no member named 'sc_intr_number' /src/sys/dev/usb/u3g.c:170: error: 'struct u3g_softc' has no member named 'sc_intr_pipe' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-10 06:25:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-10 06:25:50 - ERROR: failed to build lint kernel TB --- 2008-10-10 06:25:50 - tinderbox aborted TB --- 4741.84 user 598.29 system 6348.77 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From joao at matik.com.br Fri Oct 10 17:48:32 2008 From: joao at matik.com.br (JoaoBR) Date: Fri Oct 10 17:48:39 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition Message-ID: <200810101429.37244.joao@matik.com.br> I get a problem on several am2 motherboards when an SCSI Adaptor (LSI or Adaptec) is installed and with 4Gigs of Ram the problem is easy to repeat, after some minutes compiling world the machine crashes, sometimes a panic mmap ffs crossrefeerence or something, passes too fast to look an when the machine comes back often the complete root partition is gone or if not it needs manual fsck and mostly /dev references are gone or other important parts so the disk isn't bootable anymore funny is (for me) that the other partitions are ok ever and only root is fucked ever I tried MBs as Asus, Abit and Gigabyte all same result Same hardware with SATA works perfect Same hardware with scsi up to 3.5Gigs installed works perfect what calls my attention that all this MBs do not have the memroy hole remapping feature so the complete 4gigs are available what normally was not the case with amd64 Mbs for the Athlon 64 CPUs some has an opinion if this is a freebsd issue or MB falure or scsi drv problem? Gigabyte support tips a driver problem and no MB issue. Other manufactures don't answer. regarding the SCSI I tried the LSI U320, Adaptec U320 and Adaptec Raid SCSI (aacd) and all of them give me the same problem -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From freebsd at sopwith.solgatos.com Fri Oct 10 18:44:16 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Oct 10 18:44:28 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: Your message of "Fri, 10 Oct 2008 14:29:37 -0300." <200810101429.37244.joao@matik.com.br> Message-ID: <200810101843.SAA07538@sopwith.solgatos.com> > I get a problem on several am2 motherboards when an SCSI Adaptor (LSI or=20 > Adaptec) is installed and with 4Gigs of Ram > > the problem is easy to repeat, after some minutes compiling world the machi= > ne=20 > crashes, sometimes a panic mmap ffs crossrefeerence or something, passes to= > o=20 > fast to look an when the machine comes back often the complete root partiti= > on=20 > is gone or if not it needs manual fsck and mostly /dev references are gone = > or=20 > other important parts so the disk isn't bootable anymore > > funny is (for me) that the other partitions are ok ever and only root is=20 > fucked ever Are you running FreeBSD i386 or amd64? Is the compiler using /tmp and /tmp is in root partition? Maybe try having a seperate partition for /tmp, might keep root partition from getting trashed? > Same hardware with SATA works perfect Maybe try root partition on SATA, everything else on SCSI and see what happens. If the system supports a RS-232 console, you could capture panic message that way. Or aim a video camera at the screen. From joao at matik.com.br Fri Oct 10 19:12:31 2008 From: joao at matik.com.br (JoaoBR) Date: Fri Oct 10 19:12:37 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810101843.SAA07538@sopwith.solgatos.com> References: <200810101843.SAA07538@sopwith.solgatos.com> Message-ID: <200810101611.28175.joao@matik.com.br> On Friday 10 October 2008 07:43:07 Dieter wrote: > > I get a problem on several am2 motherboards when an SCSI Adaptor (LSI > > or=20 Adaptec) is installed and with 4Gigs of Ram > > > > the problem is easy to repeat, after some minutes compiling world the > > machi= ne=20 > > crashes, sometimes a panic mmap ffs crossrefeerence or something, passes > > to= o=20 > > fast to look an when the machine comes back often the complete root > > partiti= on=20 > > is gone or if not it needs manual fsck and mostly /dev references are > > gone = or=20 > > other important parts so the disk isn't bootable anymore > > > > funny is (for me) that the other partitions are ok ever and only root > > is=20 fucked ever > > Are you running FreeBSD i386 or amd64? > amd64 > Is the compiler using /tmp and /tmp is in root partition? > Maybe try having a seperate partition for /tmp, might keep > root partition from getting trashed? > > > Same hardware with SATA works perfect > > Maybe try root partition on SATA, everything else on SCSI > and see what happens. > > If the system supports a RS-232 console, you could capture panic > message that way. Or aim a video camera at the screen. > _____ > __________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. Service fornecido pelo Datacenter Matik > https://datacenter.matik.com.br -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From joao at matik.com.br Fri Oct 10 19:38:04 2008 From: joao at matik.com.br (JoaoBR) Date: Fri Oct 10 19:38:16 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810101843.SAA07538@sopwith.solgatos.com> References: <200810101843.SAA07538@sopwith.solgatos.com> Message-ID: <200810101637.01741.joao@matik.com.br> On Friday 10 October 2008 07:43:07 Dieter wrote: > > I get a problem on several am2 motherboards when an SCSI Adaptor (LSI > > or=20 Adaptec) is installed and with 4Gigs of Ram > > > > the problem is easy to repeat, after some minutes compiling world the > > machi= ne=20 > > crashes, sometimes a panic mmap ffs crossrefeerence or something, passes > > to= o=20 > > fast to look an when the machine comes back often the complete root > > partiti= on=20 > > is gone or if not it needs manual fsck and mostly /dev references are > > gone = or=20 > > other important parts so the disk isn't bootable anymore > > > > funny is (for me) that the other partitions are ok ever and only root > > is=20 fucked ever > > Are you running FreeBSD i386 or amd64? > amd64 > Is the compiler using /tmp and /tmp is in root partition? > Maybe try having a seperate partition for /tmp, might keep > root partition from getting trashed? > /tmp is linked to /var/tmp > > Same hardware with SATA works perfect > > Maybe try root partition on SATA, everything else on SCSI > and see what happens. > > If the system supports a RS-232 console, you could capture panic > message that way. Or aim a video camera at the screen. well to be more clear the machine hangs somewhere in buildworld I saw some panics all with mmap and crossreference, the panic does not complete either it hangs before getting to the pointer lines I have still a disk which wasn't completly wiped out so if you have some need for finding some info I try but without camera and dogs envolved please :) -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From gary.jennejohn at freenet.de Sat Oct 11 09:31:03 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Oct 11 09:31:15 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810101429.37244.joao@matik.com.br> References: <200810101429.37244.joao@matik.com.br> Message-ID: <20081011113057.7402300c@ernst.jennejohn.org> On Fri, 10 Oct 2008 14:29:37 -0300 JoaoBR wrote: > I tried MBs as Asus, Abit and Gigabyte all same result > > Same hardware with SATA works perfect > > Same hardware with scsi up to 3.5Gigs installed works perfect > > what calls my attention that all this MBs do not have the memroy hole > remapping feature so the complete 4gigs are available what normally was not > the case with amd64 Mbs for the Athlon 64 CPUs > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > problem? > It's a driver problem. If you want to use SCSI then you'll have to limit memory to 3.5 GB. --- Gary Jennejohn From jmz at FreeBSD.org Sat Oct 11 10:08:03 2008 From: jmz at FreeBSD.org (Jean-Marc Zucconi) Date: Sat Oct 11 11:24:58 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011113057.7402300c@ernst.jennejohn.org> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> Message-ID: <20081011100801.0868710B8@nyx.dalai-zebu.org> >>>>> Gary Jennejohn writes: > On Fri, 10 Oct 2008 14:29:37 -0300 > JoaoBR wrote: >> I tried MBs as Asus, Abit and Gigabyte all same result >> >> Same hardware with SATA works perfect >> >> Same hardware with scsi up to 3.5Gigs installed works perfect >> >> what calls my attention that all this MBs do not have the memroy hole >> remapping feature so the complete 4gigs are available what normally was not >> the case with amd64 Mbs for the Athlon 64 CPUs >> >> some has an opinion if this is a freebsd issue or MB falure or scsi drv >> problem? >> > It's a driver problem. If you want to use SCSI then you'll have to limit > memory to 3.5 GB. Is this specific to the Adaptec driver or all of them are affected by the bug? I am considering upgrading to such a config, but with a tekram controller (sym). Jean-Marc -- Jean-Marc Zucconi -- PGP Key: KeyID: 400B38E9 From koitsu at FreeBSD.org Sat Oct 11 10:29:18 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Oct 11 11:25:14 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011113057.7402300c@ernst.jennejohn.org> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> Message-ID: <20081011101316.GA58119@icarus.home.lan> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > On Fri, 10 Oct 2008 14:29:37 -0300 > JoaoBR wrote: > > > I tried MBs as Asus, Abit and Gigabyte all same result > > > > Same hardware with SATA works perfect > > > > Same hardware with scsi up to 3.5Gigs installed works perfect > > > > what calls my attention that all this MBs do not have the memroy hole > > remapping feature so the complete 4gigs are available what normally was not > > the case with amd64 Mbs for the Athlon 64 CPUs > > > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > > problem? > > > > It's a driver problem. If you want to use SCSI then you'll have to limit > memory to 3.5 GB. What you're saying is that Adaptec and LSI Logic SCSI controllers behave badly (and can cause data loss) on amd64 systems which contain more than 3.5GB of RAM. This is a very big claim. Have you talked to Scott Long about this? Please expand on this, and provide evidence or references. I need to document this in my Wiki if it is indeed true. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From gary.jennejohn at freenet.de Sat Oct 11 14:45:36 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Oct 11 14:45:48 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011101316.GA58119@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> Message-ID: <20081011164529.198f32c6@ernst.jennejohn.org> On Sat, 11 Oct 2008 03:13:16 -0700 Jeremy Chadwick wrote: > On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > > On Fri, 10 Oct 2008 14:29:37 -0300 > > JoaoBR wrote: > > > > > I tried MBs as Asus, Abit and Gigabyte all same result > > > > > > Same hardware with SATA works perfect > > > > > > Same hardware with scsi up to 3.5Gigs installed works perfect > > > > > > what calls my attention that all this MBs do not have the memroy hole > > > remapping feature so the complete 4gigs are available what normally was not > > > the case with amd64 Mbs for the Athlon 64 CPUs > > > > > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > > > problem? > > > > > > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > > What you're saying is that Adaptec and LSI Logic SCSI controllers behave > badly (and can cause data loss) on amd64 systems which contain more than > 3.5GB of RAM. This is a very big claim. > > Have you talked to Scott Long about this? > > Please expand on this, and provide evidence or references. I need to > document this in my Wiki if it is indeed true. > See the freebsd-scsi thread with Subject "data corruption with ahc driver and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan 2008. This was for ahc, but the bit-rot which Scott mentions in his reply might also apply to the LSI Logic controllers. Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem to have this problem. --- Gary Jennejohn From gary.jennejohn at freenet.de Sat Oct 11 14:48:51 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Oct 11 14:48:58 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011100801.0868710B8@nyx.dalai-zebu.org> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011100801.0868710B8@nyx.dalai-zebu.org> Message-ID: <20081011164844.3596a669@ernst.jennejohn.org> On Sat, 11 Oct 2008 12:08:00 +0200 (CEST) Jean-Marc Zucconi wrote: > >>>>> Gary Jennejohn writes: > > > On Fri, 10 Oct 2008 14:29:37 -0300 > > JoaoBR wrote: > > >> I tried MBs as Asus, Abit and Gigabyte all same result > >> > >> Same hardware with SATA works perfect > >> > >> Same hardware with scsi up to 3.5Gigs installed works perfect > >> > >> what calls my attention that all this MBs do not have the memroy hole > >> remapping feature so the complete 4gigs are available what normally was not > >> the case with amd64 Mbs for the Athlon 64 CPUs > >> > >> some has an opinion if this is a freebsd issue or MB falure or scsi drv > >> problem? > >> > > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > > Is this specific to the Adaptec driver or all of them are affected by > the bug? I am considering upgrading to such a config, but with a > tekram controller (sym). > I observed the same problem with ahc. Can't say whether the sym driver has the problem because I don't have such a controller. I've now taken my SCSI drives out of service and am using SATA only. --- Gary Jennejohn From koitsu at FreeBSD.org Sat Oct 11 14:58:21 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Oct 11 15:32:10 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011164529.198f32c6@ernst.jennejohn.org> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> Message-ID: <20081011144817.GB64861@icarus.home.lan> On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: > On Sat, 11 Oct 2008 03:13:16 -0700 > Jeremy Chadwick wrote: > > > On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > > > On Fri, 10 Oct 2008 14:29:37 -0300 > > > JoaoBR wrote: > > > > > > > I tried MBs as Asus, Abit and Gigabyte all same result > > > > > > > > Same hardware with SATA works perfect > > > > > > > > Same hardware with scsi up to 3.5Gigs installed works perfect > > > > > > > > what calls my attention that all this MBs do not have the memroy hole > > > > remapping feature so the complete 4gigs are available what normally was not > > > > the case with amd64 Mbs for the Athlon 64 CPUs > > > > > > > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > > > > problem? > > > > > > > > > > It's a driver problem. If you want to use SCSI then you'll have to limit > > > memory to 3.5 GB. > > > > What you're saying is that Adaptec and LSI Logic SCSI controllers behave > > badly (and can cause data loss) on amd64 systems which contain more than > > 3.5GB of RAM. This is a very big claim. > > > > Have you talked to Scott Long about this? > > > > Please expand on this, and provide evidence or references. I need to > > document this in my Wiki if it is indeed true. > > > > See the freebsd-scsi thread with Subject "data corruption with ahc driver > and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan > 2008. > > This was for ahc, but the bit-rot which Scott mentions in his reply might > also apply to the LSI Logic controllers. > > Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI > hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem > to have this problem. Thank you -- this is the exact information I was looking for. I will update my Wiki page to reflect this quite major problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mcdouga9 at egr.msu.edu Sat Oct 11 16:43:12 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sat Oct 11 16:43:19 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011144817.GB64861@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> Message-ID: <48F0D3B5.6070602@egr.msu.edu> Jeremy Chadwick wrote: > On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: >> On Sat, 11 Oct 2008 03:13:16 -0700 >> Jeremy Chadwick wrote: >> >>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: >>>> On Fri, 10 Oct 2008 14:29:37 -0300 >>>> JoaoBR wrote: >>>> >>>>> I tried MBs as Asus, Abit and Gigabyte all same result >>>>> >>>>> Same hardware with SATA works perfect >>>>> >>>>> Same hardware with scsi up to 3.5Gigs installed works perfect >>>>> >>>>> what calls my attention that all this MBs do not have the memroy hole >>>>> remapping feature so the complete 4gigs are available what normally was not >>>>> the case with amd64 Mbs for the Athlon 64 CPUs >>>>> >>>>> some has an opinion if this is a freebsd issue or MB falure or scsi drv >>>>> problem? >>>>> >>>> It's a driver problem. If you want to use SCSI then you'll have to limit >>>> memory to 3.5 GB. >>> What you're saying is that Adaptec and LSI Logic SCSI controllers behave >>> badly (and can cause data loss) on amd64 systems which contain more than >>> 3.5GB of RAM. This is a very big claim. >>> >>> Have you talked to Scott Long about this? >>> >>> Please expand on this, and provide evidence or references. I need to >>> document this in my Wiki if it is indeed true. >>> >> See the freebsd-scsi thread with Subject "data corruption with ahc driver >> and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan >> 2008. >> >> This was for ahc, but the bit-rot which Scott mentions in his reply might >> also apply to the LSI Logic controllers. >> >> Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI >> hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem >> to have this problem. > > Thank you -- this is the exact information I was looking for. > > I will update my Wiki page to reflect this quite major problem. > I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac driver) with a 5th generation RAID card with 8G of ram, both have no such corruption problems. Providing this as a counter-example just to document some evidence of which products seem to work fine. From mcdouga9 at egr.msu.edu Sat Oct 11 17:45:49 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Sat Oct 11 17:46:01 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011165250.GA67552@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> Message-ID: <48F0E649.20808@egr.msu.edu> Jeremy Chadwick wrote: > On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: >> Jeremy Chadwick wrote: >>> On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: >>>> On Sat, 11 Oct 2008 03:13:16 -0700 >>>> Jeremy Chadwick wrote: >>>> >>>>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: >>>>>> On Fri, 10 Oct 2008 14:29:37 -0300 >>>>>> JoaoBR wrote: >>>>>> >>>>>>> I tried MBs as Asus, Abit and Gigabyte all same result >>>>>>> >>>>>>> Same hardware with SATA works perfect >>>>>>> >>>>>>> Same hardware with scsi up to 3.5Gigs installed works perfect >>>>>>> >>>>>>> what calls my attention that all this MBs do not have the >>>>>>> memroy hole remapping feature so the complete 4gigs are >>>>>>> available what normally was not the case with amd64 Mbs for the >>>>>>> Athlon 64 CPUs >>>>>>> >>>>>>> some has an opinion if this is a freebsd issue or MB falure or >>>>>>> scsi drv problem? >>>>>>> >>>>>> It's a driver problem. If you want to use SCSI then you'll have to limit >>>>>> memory to 3.5 GB. >>>>> What you're saying is that Adaptec and LSI Logic SCSI controllers behave >>>>> badly (and can cause data loss) on amd64 systems which contain more than >>>>> 3.5GB of RAM. This is a very big claim. >>>>> >>>>> Have you talked to Scott Long about this? >>>>> >>>>> Please expand on this, and provide evidence or references. I need to >>>>> document this in my Wiki if it is indeed true. >>>>> >>>> See the freebsd-scsi thread with Subject "data corruption with ahc driver >>>> and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan >>>> 2008. >>>> >>>> This was for ahc, but the bit-rot which Scott mentions in his reply might >>>> also apply to the LSI Logic controllers. >>>> >>>> Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI >>>> hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem >>>> to have this problem. >>> Thank you -- this is the exact information I was looking for. >>> >>> I will update my Wiki page to reflect this quite major problem. >>> >> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS >> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac >> driver) with a 5th generation RAID card with 8G of ram, both have no >> such corruption problems. Providing this as a counter-example just to >> document some evidence of which products seem to work fine. > > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > Let's break down what we know for sure at this point: > > aac(4) - not affected > aha(4) - unknown > ahb(4) - unknown > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread > asr(4) - unknown > ips(4) - unknown > mpt(4) - not affected > mfi(4) - unknown > sym(4) - unknown > > Could the problem be specific to certain firmware revisions on the > cards? > > Also adding Scott Long to the CC list. > All the LSI I reported is driven by mpt, I have no mfi devices. From koitsu at FreeBSD.org Sat Oct 11 16:52:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Oct 11 18:41:24 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F0D3B5.6070602@egr.msu.edu> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> Message-ID: <20081011165250.GA67552@icarus.home.lan> On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: > Jeremy Chadwick wrote: >> On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: >>> On Sat, 11 Oct 2008 03:13:16 -0700 >>> Jeremy Chadwick wrote: >>> >>>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: >>>>> On Fri, 10 Oct 2008 14:29:37 -0300 >>>>> JoaoBR wrote: >>>>> >>>>>> I tried MBs as Asus, Abit and Gigabyte all same result >>>>>> >>>>>> Same hardware with SATA works perfect >>>>>> >>>>>> Same hardware with scsi up to 3.5Gigs installed works perfect >>>>>> >>>>>> what calls my attention that all this MBs do not have the >>>>>> memroy hole remapping feature so the complete 4gigs are >>>>>> available what normally was not the case with amd64 Mbs for the >>>>>> Athlon 64 CPUs >>>>>> >>>>>> some has an opinion if this is a freebsd issue or MB falure or >>>>>> scsi drv problem? >>>>>> >>>>> It's a driver problem. If you want to use SCSI then you'll have to limit >>>>> memory to 3.5 GB. >>>> What you're saying is that Adaptec and LSI Logic SCSI controllers behave >>>> badly (and can cause data loss) on amd64 systems which contain more than >>>> 3.5GB of RAM. This is a very big claim. >>>> >>>> Have you talked to Scott Long about this? >>>> >>>> Please expand on this, and provide evidence or references. I need to >>>> document this in my Wiki if it is indeed true. >>>> >>> See the freebsd-scsi thread with Subject "data corruption with ahc driver >>> and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan >>> 2008. >>> >>> This was for ahc, but the bit-rot which Scott mentions in his reply might >>> also apply to the LSI Logic controllers. >>> >>> Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI >>> hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem >>> to have this problem. >> >> Thank you -- this is the exact information I was looking for. >> >> I will update my Wiki page to reflect this quite major problem. >> > > I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > driver) with a 5th generation RAID card with 8G of ram, both have no > such corruption problems. Providing this as a counter-example just to > document some evidence of which products seem to work fine. Is your LSI SAS controller driven by mpt(4) or mfi(4)? Let's break down what we know for sure at this point: aac(4) - not affected aha(4) - unknown ahb(4) - unknown ahc(4) - affected ahd(4) - unknown; no one answered the OP's question in the thread asr(4) - unknown ips(4) - unknown mpt(4) - not affected mfi(4) - unknown sym(4) - unknown Could the problem be specific to certain firmware revisions on the cards? Also adding Scott Long to the CC list. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kris at FreeBSD.org Sat Oct 11 19:51:18 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat Oct 11 19:51:24 2008 Subject: amd64/127451: top(1): incorrect load shown on quad core In-Reply-To: <48EA739A.3000506@max.af.czu.cz.cz> References: <48EA739A.3000506@max.af.czu.cz.cz> Message-ID: <48F103D4.6050105@FreeBSD.org> Tomas Randa wrote: > I have similar problem on my Xeon5000 quad core system with 7.1 > PRERELEASE / AMD64. Tried anybody to change scheduler from ULE to 4BSD? > I tried to change some sysctl variables, but no success. > > Thanks for help. > > Tomas Randa > > > =============================== > > From: miks@skynet.lv > To: bug-followup@FreeBSD.org, miks@skynet.lv > Cc: Subject: Re: amd64/127451: top(1): incorrect load shown on quad core > Date: Thu, 18 Sep 2008 21:50:06 +0300 > > > > I got load average around 0.5, and top show something like this > "1021 processes: 1 running, 1020 sleeping > CPU states: 4.9% user, 0.0% nice, 3.6% system, 0.9% interrupt, > 90.6% idle" - this all is ok. > > then once in 2-5 minutes, there for 2-3 seconds are: > "1020 processes:67 running, 912 sleeping, 1 zombie, 40 lock > CPU states: 3.0% user, 0.0% nice, 96.7% system, 0.3% interrupt, > 0.0% idle" - this is the problem. > > after this load average is 20-30 and dropping in 2-3min to 0.5. during > this time system is very slow. even ssh session is freezing. > most of processes are fastcgi/php, so there is not one big resource > hungry process. > > found similar problem here: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2007-11/msg00551.html I sam not sure what you are claiming the problem is. Your system is being transiently overloaded by processes that eat all CPU, and that is what top shows you. Kris From fabian at wenks.ch Sat Oct 11 21:51:29 2008 From: fabian at wenks.ch (Fabian Wenk) Date: Sat Oct 11 21:51:40 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011165250.GA67552@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> Message-ID: <48F11FD6.7050007@wenks.ch> Hello Jeremy On 11.10.08 18:52, Jeremy Chadwick wrote: > Could the problem be specific to certain firmware revisions on the > cards? Some other idea, which versions of FreeBSD/amd64 are affected? Only 8-CURRENT, or also 6.x- and/or 7.x-RELEASE? As far as I have seen from the reports, it does only happen with more then 3.5 GB RAM and with SCSI disks. I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape drive connected. The disks are on an Areca RAID controller. Access to the disks and the tape drive does work just fine without any crashes. bye Fabian From gary.jennejohn at freenet.de Sun Oct 12 08:57:15 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Oct 12 08:57:22 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F11FD6.7050007@wenks.ch> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> <48F11FD6.7050007@wenks.ch> Message-ID: <20081012105711.33009734@ernst.jennejohn.org> On Sat, 11 Oct 2008 23:51:18 +0200 Fabian Wenk wrote: > Hello Jeremy > > On 11.10.08 18:52, Jeremy Chadwick wrote: > > Could the problem be specific to certain firmware revisions on the > > cards? > > Some other idea, which versions of FreeBSD/amd64 are affected? > Only 8-CURRENT, or also 6.x- and/or 7.x-RELEASE? > > As far as I have seen from the reports, it does only happen with > more then 3.5 GB RAM and with SCSI disks. > > I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM > and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape > drive connected. The disks are on an Areca RAID controller. Access > to the disks and the tape drive does work just fine without any > crashes. > This is interesting because the 29160 is exactly the controller with which I had all my problems, but I was running it with disks only. Maybe Scott, or someone, has fixed it in the meantime? I haven't tried to use the full 4 GB in my box since January since I can't afford data corruption. --- Gary Jennejohn From gary.jennejohn at freenet.de Sun Oct 12 09:01:22 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Oct 12 09:01:35 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011165250.GA67552@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> Message-ID: <20081012110115.5dccbc32@ernst.jennejohn.org> On Sat, 11 Oct 2008 09:52:50 -0700 Jeremy Chadwick wrote: [big snip] > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > Let's break down what we know for sure at this point: > > aac(4) - not affected > aha(4) - unknown > ahb(4) - unknown > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread I asked Scott whether he thought ahd would be affected, but he never responded. I was thinking about getting a PCIe controller but then I dropped the idea due to lack of funds for experimentation. --- Gary Jennejohn From pvanberlo at fastmail.fm Sun Oct 12 09:00:07 2008 From: pvanberlo at fastmail.fm (Paul van Berlo) Date: Sun Oct 12 11:20:36 2008 Subject: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Message-ID: <200810120900.m9C907b2063796@freefall.freebsd.org> The following reply was made to PR amd64/127484; it has been noted by GNATS. From: "Paul van Berlo" To: bug-followup@FreeBSD.org, tg@swox.com Cc: Subject: Re: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Date: Sun, 12 Oct 2008 10:50:55 +0200 Hi, the issue I was seeing is solved. It appears this is due to a specific BIOS setting (FSB Spread Spectrum), which was set to 'Auto' in my case. I disabled this, and now my clock runs absolutely fine. There should not be any side effects with disabling this option AFAIK. Thanks. Best regards, Paul van Berlo From petefrench at ticketswitch.com Sun Oct 12 17:32:15 2008 From: petefrench at ticketswitch.com (Pete French) Date: Sun Oct 12 17:32:27 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F22245.1030201@samsco.org> Message-ID: > Sorry for not responding back in Jan. I have a hard time recommending > the 29320/39320 cards because of the long history they have with > incompatibilities with certain U320 drives. I don't think that the Out of interest, what cards would you recommend ? I have just started running 4 drives off a 29320, and it does the "dump" thing on boot, so I was thinking of replacing it with another PCI-X card. > driver will be affected by memory size, but I haven't run it in several > years, and it could have rotted like ahc apparently did (though I still > have a hard time imagining how the rot could have taken place, hardly > anything has changed in the driver over the years). I have a hard time beliving these don't work either - mainly because I am running a 4GB system with ahc (and now ahd) in it and have had no problems at all. Certainly Adaptec cards are so common that if there was something majorly broken in that driver we would be seeing a lot more reports of corruption surely ? -pete. From gary.jennejohn at freenet.de Sun Oct 12 19:04:36 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Oct 12 19:04:49 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: References: <48F22245.1030201@samsco.org> Message-ID: <20081012210425.2e831414@ernst.jennejohn.org> On Sun, 12 Oct 2008 18:32:13 +0100 Pete French wrote: > > Sorry for not responding back in Jan. I have a hard time recommending > > the 29320/39320 cards because of the long history they have with > > incompatibilities with certain U320 drives. I don't think that the > > Out of interest, what cards would you recommend ? I have just > started running 4 drives off a 29320, and it does the "dump" thing > on boot, so I was thinking of replacing it with another PCI-X card. > > > driver will be affected by memory size, but I haven't run it in several > > years, and it could have rotted like ahc apparently did (though I still > > have a hard time imagining how the rot could have taken place, hardly > > anything has changed in the driver over the years). > > I have a hard time beliving these don't work either - mainly because I > am running a 4GB system with ahc (and now ahd) in it and have had no > problems at all. Certainly Adaptec cards are so common that if there > was something majorly broken in that driver we would be seeing a lot > more reports of corruption surely ? > Maybe it's BIOS related? I have a new mobo from a different vendor where I could give it a try and see if the corruption goes away. --- Gary Jennejohn From scottl at samsco.org Sun Oct 12 16:50:35 2008 From: scottl at samsco.org (Scott Long) Date: Sun Oct 12 20:27:58 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011165250.GA67552@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> Message-ID: <48F2217C.9010000@samsco.org> Jeremy Chadwick wrote: > On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: >> Jeremy Chadwick wrote: >>> On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: >>>> On Sat, 11 Oct 2008 03:13:16 -0700 >>>> Jeremy Chadwick wrote: >>>> >>>>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: >>>>>> On Fri, 10 Oct 2008 14:29:37 -0300 >>>>>> JoaoBR wrote: >>>>>> >>>>>>> I tried MBs as Asus, Abit and Gigabyte all same result >>>>>>> >>>>>>> Same hardware with SATA works perfect >>>>>>> >>>>>>> Same hardware with scsi up to 3.5Gigs installed works perfect >>>>>>> >>>>>>> what calls my attention that all this MBs do not have the >>>>>>> memroy hole remapping feature so the complete 4gigs are >>>>>>> available what normally was not the case with amd64 Mbs for the >>>>>>> Athlon 64 CPUs >>>>>>> >>>>>>> some has an opinion if this is a freebsd issue or MB falure or >>>>>>> scsi drv problem? >>>>>>> >>>>>> It's a driver problem. If you want to use SCSI then you'll have to limit >>>>>> memory to 3.5 GB. >>>>> What you're saying is that Adaptec and LSI Logic SCSI controllers behave >>>>> badly (and can cause data loss) on amd64 systems which contain more than >>>>> 3.5GB of RAM. This is a very big claim. >>>>> >>>>> Have you talked to Scott Long about this? >>>>> >>>>> Please expand on this, and provide evidence or references. I need to >>>>> document this in my Wiki if it is indeed true. >>>>> >>>> See the freebsd-scsi thread with Subject "data corruption with ahc driver >>>> and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan >>>> 2008. >>>> >>>> This was for ahc, but the bit-rot which Scott mentions in his reply might >>>> also apply to the LSI Logic controllers. >>>> >>>> Basically the driver doesn't correctly handle DMA above 4GB. Since the PCI >>>> hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't seem >>>> to have this problem. >>> Thank you -- this is the exact information I was looking for. >>> >>> I will update my Wiki page to reflect this quite major problem. >>> >> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS >> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac >> driver) with a 5th generation RAID card with 8G of ram, both have no >> such corruption problems. Providing this as a counter-example just to >> document some evidence of which products seem to work fine. > > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > I can personal vouch for MPT and MFI drivers working just fine with >4GB. > Let's break down what we know for sure at this point: > > aac(4) - not affected Works fine > aha(4) - unknown > ahb(4) - unknown These two will likely be using bounce buffers and should work, albeit slowly. > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread Both ahc and ahd were designed _AND_TESTED_ to work with >4GB. If they don't work anymore, it's due to unintended bitrot. > asr(4) - unknown Danger! Achtung! Beware of Dog! > ips(4) - unknown I'm pretty sure this works just fine. > mpt(4) - not affected > mfi(4) - unknown Both work just fine > sym(4) - unknown This has had problems in the past, but I think that it might have been fixed recently You forgot to mention isp(4), which also works just fine. > > Could the problem be specific to certain firmware revisions on the > cards? ahc/ahd use custom "firmware" that is part of the driver. Their BIOS can be flashed, but that does little to affect OS operation of the card. So, "firmware revisions" has nothing to do with whatever this problem is. Please do keep in mind that 32bit vs 64bit support, and by correlary, >4GB support, is something that is completely isolated on a per-driver basis. Trying to draw patterns between drivers to say, "FreeBSD SCSI support is broken," is not valid. In fact, traditionally, SCSI drivers in general have had the best support because they are so much more common in the high-end systems that need the support. Out of your whole list, the only card to explicitly stay away from is the asr(4) family, but that's been known for years. If ahc and/or ahd has problems, we need someone willing to dig into code and trace through the DMA path. Scott From scottl at samsco.org Sun Oct 12 16:50:36 2008 From: scottl at samsco.org (Scott Long) Date: Sun Oct 12 20:28:29 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081012110115.5dccbc32@ernst.jennejohn.org> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <20081011164529.198f32c6@ernst.jennejohn.org> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> <20081012110115.5dccbc32@ernst.jennejohn.org> Message-ID: <48F22245.1030201@samsco.org> Gary Jennejohn wrote: > On Sat, 11 Oct 2008 09:52:50 -0700 > Jeremy Chadwick wrote: > > [big snip] >> Is your LSI SAS controller driven by mpt(4) or mfi(4)? >> >> Let's break down what we know for sure at this point: >> >> aac(4) - not affected >> aha(4) - unknown >> ahb(4) - unknown >> ahc(4) - affected >> ahd(4) - unknown; no one answered the OP's question in the thread > > I asked Scott whether he thought ahd would be affected, but he never > responded. I was thinking about getting a PCIe controller but then > I dropped the idea due to lack of funds for experimentation. > Sorry for not responding back in Jan. I have a hard time recommending the 29320/39320 cards because of the long history they have with incompatibilities with certain U320 drives. I don't think that the driver will be affected by memory size, but I haven't run it in several years, and it could have rotted like ahc apparently did (though I still have a hard time imagining how the rot could have taken place, hardly anything has changed in the driver over the years). Scott From tg at swox.com Sun Oct 12 18:00:11 2008 From: tg at swox.com (Torbjorn Granlund) Date: Sun Oct 12 20:28:37 2008 Subject: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Message-ID: <200810121800.m9CI0Bvr089913@freefall.freebsd.org> The following reply was made to PR amd64/127484; it has been noted by GNATS. From: Torbjorn Granlund To: "Paul van Berlo" Cc: bug-followup@FreeBSD.org Subject: Re: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Date: Sun, 12 Oct 2008 19:40:24 +0200 "Paul van Berlo" writes: the issue I was seeing is solved. It appears this is due to a specific BIOS setting (FSB Spread Spectrum), which was set to 'Auto' in my case. I disabled this, and now my clock runs absolutely fine. There should not be any side effects with disabling this option AFAIK. =20=20 Thanks! My ASUS board didn't have any such option, but it had some "Overclocking" option which was set to "Auto". I changed this to "Standard". The clock now runs about 20 times closer to reality, which is enough for ntpd to work. I wonder if there is anything FreeBSD can do to work around these silly overclock options. One would really wish the BIOS defaults would be more conservative, and leave it to the tinkerers to play around with overclock options. --=20 Torbj=F6rn From koitsu at FreeBSD.org Mon Oct 13 05:42:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 13 05:43:02 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: References: <20081011165250.GA67552@icarus.home.lan> Message-ID: <20081013054253.GA10367@icarus.home.lan> On Mon, Oct 13, 2008 at 07:38:58AM +0200, David Peall wrote: > > aac(4) - not affected > > aha(4) - unknown > > ahb(4) - unknown > > ahc(4) - affected > > ahd(4) - unknown; no one answered the OP's question in the thread > > asr(4) - unknown > > ips(4) - unknown > > mpt(4) - not affected > > mfi(4) - unknown > > sym(4) - unknown > > I'm using amd64 with 8Gb RAM with the following: > mfi0: port 0xec00-0xecff mem > 0xfc480000-0xfc4bffff,0xfc440000-0xfc47ffff irq 16 at device 0.0 on pci1 > mfi0: Megaraid SAS driver Ver 2.00 > mfi0: 4914 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/1f0c/1028) > mfi0: 4915 (boot + 3s/0x0020/info) - Firmware version 1.11.52-0349 > mfi0: 4917 (boot + 3s/0x0020/info) - Package version 6.0.1-0080 > > No problems. Okay, I'm pulling this stuff off the Wiki, because so far there hasn't been any confirmation of the problem being wide-spread except in the case of asr(4) (which is supposedly evil. I fully trust Scott on this one!) Thanks everyone! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From david at esn.org.za Mon Oct 13 06:19:02 2008 From: david at esn.org.za (David Peall) Date: Mon Oct 13 11:23:38 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011165250.GA67552@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br><20081011113057.7402300c@ernst.jennejohn.org><20081011101316.GA58119@icarus.home.lan><20081011164529.198f32c6@ernst.jennejohn.org><20081011144817.GB64861@icarus.home.lan><48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> Message-ID: > aac(4) - not affected > aha(4) - unknown > ahb(4) - unknown > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread > asr(4) - unknown > ips(4) - unknown > mpt(4) - not affected > mfi(4) - unknown > sym(4) - unknown I'm using amd64 with 8Gb RAM with the following: mfi0: port 0xec00-0xecff mem 0xfc480000-0xfc4bffff,0xfc440000-0xfc47ffff irq 16 at device 0.0 on pci1 mfi0: Megaraid SAS driver Ver 2.00 mfi0: 4914 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) mfi0: 4915 (boot + 3s/0x0020/info) - Firmware version 1.11.52-0349 mfi0: 4917 (boot + 3s/0x0020/info) - Package version 6.0.1-0080 No problems. -- David Peall :: IT Manager e-Schools' Network :: http://www.esn.org.za/ Phone +27 (021) 674-9140 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Jeremy Chadwick > Sent: 11 October 2008 06:53 PM > To: Adam McDougall > Cc: freebsd-stable@freebsd.org; freebsd-amd64@freebsd.org > Subject: Re: am2 MBs - 4g + SCSI wipes out root partition > > On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: > > Jeremy Chadwick wrote: > >> On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: > >>> On Sat, 11 Oct 2008 03:13:16 -0700 > >>> Jeremy Chadwick wrote: > >>> > >>>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > >>>>> On Fri, 10 Oct 2008 14:29:37 -0300 > >>>>> JoaoBR wrote: > >>>>> > >>>>>> I tried MBs as Asus, Abit and Gigabyte all same result > >>>>>> > >>>>>> Same hardware with SATA works perfect > >>>>>> > >>>>>> Same hardware with scsi up to 3.5Gigs installed works perfect > >>>>>> > >>>>>> what calls my attention that all this MBs do not have the > >>>>>> memroy hole remapping feature so the complete 4gigs are > >>>>>> available what normally was not the case with amd64 Mbs for the > >>>>>> Athlon 64 CPUs > >>>>>> > >>>>>> some has an opinion if this is a freebsd issue or MB falure or > >>>>>> scsi drv problem? > >>>>>> > >>>>> It's a driver problem. If you want to use SCSI then you'll have to > limit > >>>>> memory to 3.5 GB. > >>>> What you're saying is that Adaptec and LSI Logic SCSI controllers behave > >>>> badly (and can cause data loss) on amd64 systems which contain more than > >>>> 3.5GB of RAM. This is a very big claim. > >>>> > >>>> Have you talked to Scott Long about this? > >>>> > >>>> Please expand on this, and provide evidence or references. I need to > >>>> document this in my Wiki if it is indeed true. > >>>> > >>> See the freebsd-scsi thread with Subject "data corruption with ahc driver > >>> and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, 30 Jan > >>> 2008. > >>> > >>> This was for ahc, but the bit-rot which Scott mentions in his reply might > >>> also apply to the LSI Logic controllers. > >>> > >>> Basically the driver doesn't correctly handle DMA above 4GB. Since the > PCI > >>> hole gets mapped above 4GB it causes problems. the (S)ATA drivers don't > seem > >>> to have this problem. > >> > >> Thank you -- this is the exact information I was looking for. > >> > >> I will update my Wiki page to reflect this quite major problem. > >> > > > > I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > > controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > > driver) with a 5th generation RAID card with 8G of ram, both have no > > such corruption problems. Providing this as a counter-example just to > > document some evidence of which products seem to work fine. > > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > Let's break down what we know for sure at this point: > > aac(4) - not affected > aha(4) - unknown > ahb(4) - unknown > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread > asr(4) - unknown > ips(4) - unknown > mpt(4) - not affected > mfi(4) - unknown > sym(4) - unknown > > Could the problem be specific to certain firmware revisions on the > cards? > > Also adding Scott Long to the CC list. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Oct 13 11:06:46 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 13 11:23:54 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200810131106.m9DB6k4k029359@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125820 amd64 [k8temp] [patch] sysctl dev.k8temp.*.sensor1.* are inv o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on f amd64/116457 amd64 [install] can't install freebsd on dv9420us o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv f amd64/103259 amd64 [ar] Cannot use ataraid on nvidia nForce4+amd64 o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock called (by ata o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 78 problems total. From gary.jennejohn at freenet.de Mon Oct 13 12:16:00 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Oct 13 12:16:07 2008 Subject: how does the kernel go about mapping memory for amd64? Message-ID: <20081013141556.7b7a0806@ernst.jennejohn.org> I have a new mother board, a Gigabyte GA-MA78GPM-DS2H, which shows really weird behavior under FreeBSD when I have 4GB of memory and a PCI card plugged into it. With an Adaptec 29160 plugged in FreeBSD sees only 3GB and there is _no_ memory mapped above 4GB. This seems like a bug in the BIOS. With no PCI card plugged in FreeBSD sees memory mapped above 4GB and almost 4GB are available. Note that this board has graphics in the chipset (AMD 780G) which uses UMA (128 MB) for the video buffer. This behavior leads me to believe that FreeBSD is only using the memory mapping hints provided by the BIOS and is not sizing and mapping memory itself. Is that correct? --- Gary Jennejohn From joao at matik.com.br Mon Oct 13 12:36:21 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 12:36:34 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011101316.GA58119@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> Message-ID: <200810130935.10570.joao@matik.com.br> On Saturday 11 October 2008 07:13:16 Jeremy Chadwick wrote: > On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > > On Fri, 10 Oct 2008 14:29:37 -0300 > > > > JoaoBR wrote: > > > I tried MBs as Asus, Abit and Gigabyte all same result > > > > > > Same hardware with SATA works perfect > > > > > > Same hardware with scsi up to 3.5Gigs installed works perfect > > > > > > what calls my attention that all this MBs do not have the memroy hole > > > remapping feature so the complete 4gigs are available what normally was > > > not the case with amd64 Mbs for the Athlon 64 CPUs > > > > > > some has an opinion if this is a freebsd issue or MB falure or scsi drv > > > problem? > > > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > > What you're saying is that Adaptec and LSI Logic SCSI controllers behave > badly (and can cause data loss) on amd64 systems which contain more than > 3.5GB of RAM. This is a very big claim. > > Have you talked to Scott Long about this? > > Please expand on this, and provide evidence or references. I need to > document this in my Wiki if it is indeed true. I have an Asus AM2 Mb which support ECC mem and at least with the Adaptec raid card (aacd) the problem does not happen (when ECC support enabled) I did 10x buildworld, ahc and mpt still same issue, first build cracks the data on da0s1a >On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > > It's a driver problem. ?If you want to use SCSI then you'll have to limit > memory to 3.5 GB. well indeed with less then 4G installed it works flawless, so the difference I see is that former athln64 MBs had memory hole remap options or when 4Gig installed they only gave 3.something to the OS even under amd64 - this is NOT the case with the AM2 MBs which should support up to 8/16Mb onboard but wth this amount freebsd amd64 does not even boot when a scsi adaptor is installed -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From joao at matik.com.br Mon Oct 13 12:39:01 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 12:39:07 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F0D3B5.6070602@egr.msu.edu> References: <200810101429.37244.joao@matik.com.br> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> Message-ID: <200810130937.48093.joao@matik.com.br> On Saturday 11 October 2008 13:26:29 Adam McDougall wrote: > Jeremy Chadwick wrote: > > On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: > >> On Sat, 11 Oct 2008 03:13:16 -0700 > >> > >> Jeremy Chadwick wrote: > >>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > >>>> On Fri, 10 Oct 2008 14:29:37 -0300 > >>>> > >>>> JoaoBR wrote: > >>>>> I tried MBs as Asus, Abit and Gigabyte all same result > >>>>> > >>>>> Same hardware with SATA works perfect > >>>>> > >>>>> Same hardware with scsi up to 3.5Gigs installed works perfect > >>>>> > >>>>> what calls my attention that all this MBs do not have the memroy hole > >>>>> remapping feature so the complete 4gigs are available what normally > >>>>> was not the case with amd64 Mbs for the Athlon 64 CPUs > >>>>> > >>>>> some has an opinion if this is a freebsd issue or MB falure or scsi > >>>>> drv problem? > >>>> > >>>> It's a driver problem. If you want to use SCSI then you'll have to > >>>> limit memory to 3.5 GB. > >>> > >>> What you're saying is that Adaptec and LSI Logic SCSI controllers > >>> behave badly (and can cause data loss) on amd64 systems which contain > >>> more than 3.5GB of RAM. This is a very big claim. > >>> > >>> Have you talked to Scott Long about this? > >>> > >>> Please expand on this, and provide evidence or references. I need to > >>> document this in my Wiki if it is indeed true. > >> > >> See the freebsd-scsi thread with Subject "data corruption with ahc > >> driver and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, > >> 30 Jan 2008. > >> > >> This was for ahc, but the bit-rot which Scott mentions in his reply > >> might also apply to the LSI Logic controllers. > >> > >> Basically the driver doesn't correctly handle DMA above 4GB. Since the > >> PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers > >> don't seem to have this problem. > > > > Thank you -- this is the exact information I was looking for. > > > > I will update my Wiki page to reflect this quite major problem. > > I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > driver) with a 5th generation RAID card with 8G of ram, both have no > such corruption problems. Providing this as a counter-example just to > document some evidence of which products seem to work fine. > _______________________________________________ well this for sure is NOT a AM2 MB but any server MB which indeed run fine as Tyans, SMs and others I guess -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From koitsu at FreeBSD.org Mon Oct 13 12:40:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 13 12:40:29 2008 Subject: how does the kernel go about mapping memory for amd64? In-Reply-To: <20081013141556.7b7a0806@ernst.jennejohn.org> References: <20081013141556.7b7a0806@ernst.jennejohn.org> Message-ID: <20081013124020.GA18797@icarus.home.lan> On Mon, Oct 13, 2008 at 02:15:56PM +0200, Gary Jennejohn wrote: > > I have a new mother board, a Gigabyte GA-MA78GPM-DS2H, which shows > really weird behavior under FreeBSD when I have 4GB of memory and a > PCI card plugged into it. > > With an Adaptec 29160 plugged in FreeBSD sees only 3GB and there is _no_ > memory mapped above 4GB. This seems like a bug in the BIOS. > > With no PCI card plugged in FreeBSD sees memory mapped above 4GB and > almost 4GB are available. > > Note that this board has graphics in the chipset (AMD 780G) which uses UMA > (128 MB) for the video buffer. > > This behavior leads me to believe that FreeBSD is only using the memory > mapping hints provided by the BIOS and is not sizing and mapping memory > itself. > > Is that correct? You might also try freebsd-hackers for this kind of thing, as it's pretty low-level. Does Linux and/or Windows exhibit the same problem? If so, I would open up a case with Gigabyte. This should be very easily reproducible, although I would not be surprised if they ask for you to send them your Adaptec controller. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From joao at matik.com.br Mon Oct 13 12:42:19 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 12:42:26 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081011165250.GA67552@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <48F0D3B5.6070602@egr.msu.edu> <20081011165250.GA67552@icarus.home.lan> Message-ID: <200810130941.11706.joao@matik.com.br> On Saturday 11 October 2008 13:52:50 Jeremy Chadwick wrote: > On Sat, Oct 11, 2008 at 12:26:29PM -0400, Adam McDougall wrote: > > Jeremy Chadwick wrote: > >> On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: > >>> On Sat, 11 Oct 2008 03:13:16 -0700 > >>> > >>> Jeremy Chadwick wrote: > >>>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > >>>>> On Fri, 10 Oct 2008 14:29:37 -0300 > >>>>> > >>>>> JoaoBR wrote: > >>>>>> I tried MBs as Asus, Abit and Gigabyte all same result > >>>>>> > >>>>>> Same hardware with SATA works perfect > >>>>>> > >>>>>> Same hardware with scsi up to 3.5Gigs installed works perfect > >>>>>> > >>>>>> what calls my attention that all this MBs do not have the > >>>>>> memroy hole remapping feature so the complete 4gigs are > >>>>>> available what normally was not the case with amd64 Mbs for the > >>>>>> Athlon 64 CPUs > >>>>>> > >>>>>> some has an opinion if this is a freebsd issue or MB falure or > >>>>>> scsi drv problem? > >>>>> > >>>>> It's a driver problem. If you want to use SCSI then you'll have to > >>>>> limit memory to 3.5 GB. > >>>> > >>>> What you're saying is that Adaptec and LSI Logic SCSI controllers > >>>> behave badly (and can cause data loss) on amd64 systems which contain > >>>> more than 3.5GB of RAM. This is a very big claim. > >>>> > >>>> Have you talked to Scott Long about this? > >>>> > >>>> Please expand on this, and provide evidence or references. I need to > >>>> document this in my Wiki if it is indeed true. > >>> > >>> See the freebsd-scsi thread with Subject "data corruption with ahc > >>> driver and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, > >>> 30 Jan 2008. > >>> > >>> This was for ahc, but the bit-rot which Scott mentions in his reply > >>> might also apply to the LSI Logic controllers. > >>> > >>> Basically the driver doesn't correctly handle DMA above 4GB. Since the > >>> PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers > >>> don't seem to have this problem. > >> > >> Thank you -- this is the exact information I was looking for. > >> > >> I will update my Wiki page to reflect this quite major problem. > > > > I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > > controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > > driver) with a 5th generation RAID card with 8G of ram, both have no > > such corruption problems. Providing this as a counter-example just to > > document some evidence of which products seem to work fine. > > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > Let's break down what we know for sure at this point: > > aac(4) - not affected > aha(4) - unknown > ahb(4) - unknown > ahc(4) - affected > ahd(4) - unknown; no one answered the OP's question in the thread > asr(4) - unknown > ips(4) - unknown > mpt(4) - not affected > mfi(4) - unknown > sym(4) - unknown > > Could the problem be specific to certain firmware revisions on the > cards? no, I tried different card versions AHD has the same problem AHC also AAC also MPT as well this is true for AM2 MBs but not true S939 and S940 MBs -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From joao at matik.com.br Mon Oct 13 12:44:28 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 12:44:40 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081012105711.33009734@ernst.jennejohn.org> References: <200810101429.37244.joao@matik.com.br> <48F11FD6.7050007@wenks.ch> <20081012105711.33009734@ernst.jennejohn.org> Message-ID: <200810130943.22079.joao@matik.com.br> On Sunday 12 October 2008 06:57:11 Gary Jennejohn wrote: > On Sat, 11 Oct 2008 23:51:18 +0200 > > Fabian Wenk wrote: > > Hello Jeremy > > > > On 11.10.08 18:52, Jeremy Chadwick wrote: > > > Could the problem be specific to certain firmware revisions on the > > > cards? > > > > Some other idea, which versions of FreeBSD/amd64 are affected? > > Only 8-CURRENT, or also 6.x- and/or 7.x-RELEASE? > > > > As far as I have seen from the reports, it does only happen with > > more then 3.5 GB RAM and with SCSI disks. > > > > I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM > > and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape > > drive connected. The disks are on an Areca RAID controller. Access > > to the disks and the tape drive does work just fine without any > > crashes. > > This is interesting because the 29160 is exactly the controller with > which I had all my problems, but I was running it with disks only. > > Maybe Scott, or someone, has fixed it in the meantime? I haven't > tried to use the full 4 GB in my box since January since I can't > afford data corruption. > I guess his MB is not an AM2 socket -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From joao at matik.com.br Mon Oct 13 12:48:38 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 12:48:44 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F2217C.9010000@samsco.org> References: <200810101429.37244.joao@matik.com.br> <20081011165250.GA67552@icarus.home.lan> <48F2217C.9010000@samsco.org> Message-ID: <200810130947.28905.joao@matik.com.br> On Sunday 12 October 2008 14:10:36 Scott Long wrote: > >> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > >> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > >> driver) with a 5th generation RAID card with 8G of ram, both have no > >> such corruption problems. Providing this as a counter-example just to > >> document some evidence of which products seem to work fine. > > > > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > I can personal vouch for MPT and MFI drivers working just fine with >4GB. > let narrow this a little bit, are you talking about AM2 sockets? because on AM2 the MPT drv is faulty as AHC, AHD and AACD with => 4Gigs -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From gary.jennejohn at freenet.de Mon Oct 13 12:51:00 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Oct 13 12:51:11 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810130935.10570.joao@matik.com.br> References: <200810101429.37244.joao@matik.com.br> <20081011113057.7402300c@ernst.jennejohn.org> <20081011101316.GA58119@icarus.home.lan> <200810130935.10570.joao@matik.com.br> Message-ID: <20081013145054.3b458aea@ernst.jennejohn.org> On Mon, 13 Oct 2008 09:35:10 -0200 JoaoBR wrote: > On Saturday 11 October 2008 07:13:16 Jeremy Chadwick wrote: > > It's a driver problem. If you want to use SCSI then you'll have to limit > > memory to 3.5 GB. > I probably should have written - it seems to be a problem with ahc. In general SCSI seems to work, as Scott has recently documented. But see below. > > well indeed with less then 4G installed it works flawless, so the difference I > see is that former athln64 MBs had memory hole remap options or when 4Gig > installed they only gave 3.something to the OS even under amd64 - this is NOT > the case with the AM2 MBs which should support up to 8/16Mb onboard but wth > this amount freebsd amd64 does not even boot when a scsi adaptor is installed > I'm beginning to believe that it's motherboard/BIOS related and not a general problem with ahc or any other SCSI driver. I can say that at least with my Gigabyte GA-M61P-S3 I observed data corruption with 4GB of memory installed and with the BIOS mapping a part of memory above 4GB. Forcing the kernel to use only 3.5GB solved the problem. --- Gary Jennejohn From koitsu at FreeBSD.org Mon Oct 13 12:52:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 13 12:52:37 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810130947.28905.joao@matik.com.br> References: <200810101429.37244.joao@matik.com.br> <20081011165250.GA67552@icarus.home.lan> <48F2217C.9010000@samsco.org> <200810130947.28905.joao@matik.com.br> Message-ID: <20081013125228.GA19035@icarus.home.lan> On Mon, Oct 13, 2008 at 09:47:28AM -0200, JoaoBR wrote: > On Sunday 12 October 2008 14:10:36 Scott Long wrote: > > > >> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > > >> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > > >> driver) with a 5th generation RAID card with 8G of ram, both have no > > >> such corruption problems. Providing this as a counter-example just to > > >> document some evidence of which products seem to work fine. > > > > > > Is your LSI SAS controller driven by mpt(4) or mfi(4)? > > > > I can personal vouch for MPT and MFI drivers working just fine with >4GB. > > > > let narrow this a little bit, are you talking about AM2 sockets? > > because on AM2 the MPT drv is faulty as AHC, AHD and AACD with => 4Gigs David, Fabian, and Adam -- are any of you using your cards in an AM2-based system? Also, I'm removing freebsd-stable from the list, since this appears to be mainly related to amd64 (not saying it's a FreeBSD problem, just saying it manifests itself so far on amd64). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From petefrench at ticketswitch.com Mon Oct 13 12:55:24 2008 From: petefrench at ticketswitch.com (Pete French) Date: Mon Oct 13 12:55:31 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081013125228.GA19035@icarus.home.lan> Message-ID: > David, Fabian, and Adam -- are any of you using your cards in an > AM2-based system? This suddenly has ccaught my attention - I have one AM2 system, and it will not boot amd64, and will only boot i386 in safe mode. In both cases the problems appear to be when it probes my SCSI RAID card. Having said that, I had a different motherboard with the same parts on it which ran BSD fine. but this one appears not to, and is AM2. -pete. From joao at matik.com.br Mon Oct 13 13:19:58 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 13:20:10 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081013145054.3b458aea@ernst.jennejohn.org> References: <200810101429.37244.joao@matik.com.br> <200810130935.10570.joao@matik.com.br> <20081013145054.3b458aea@ernst.jennejohn.org> Message-ID: <200810131018.49543.joao@matik.com.br> On Monday 13 October 2008 10:50:54 Gary Jennejohn wrote: > On Mon, 13 Oct 2008 09:35:10 -0200 > > JoaoBR wrote: > > On Saturday 11 October 2008 07:13:16 Jeremy Chadwick wrote: > > > It's a driver problem. If you want to use SCSI then you'll have to > > > limit memory to 3.5 GB. > > I probably should have written - it seems to be a problem with ahc. In > general SCSI seems to work, as Scott has recently documented. But see > below. > > > well indeed with less then 4G installed it works flawless, so the > > difference I see is that former athln64 MBs had memory hole remap options > > or when 4Gig installed they only gave 3.something to the OS even under > > amd64 - this is NOT the case with the AM2 MBs which should support up to > > 8/16Mb onboard but wth this amount freebsd amd64 does not even boot when > > a scsi adaptor is installed > > I'm beginning to believe that it's motherboard/BIOS related and not a > general problem with ahc or any other SCSI driver. I can say that > at least with my Gigabyte GA-M61P-S3 I observed data corruption with > 4GB of memory installed and with the BIOS mapping a part of memory > above 4GB. > > Forcing the kernel to use only 3.5GB solved the problem. > exactly, I have the same MB and Gigabytes support changed Ideas with me, even released a newer bios version but at the end they insisted that it is an OS issue since this problem does not appear with windows and fedora -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From gary.jennejohn at freenet.de Mon Oct 13 13:21:31 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Oct 13 13:21:38 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: References: <20081013125228.GA19035@icarus.home.lan> Message-ID: <20081013152125.5558af36@ernst.jennejohn.org> On Mon, 13 Oct 2008 13:55:22 +0100 Pete French wrote: > > David, Fabian, and Adam -- are any of you using your cards in an > > AM2-based system? > > This suddenly has ccaught my attention - I have one AM2 system, and > it will not boot amd64, and will only boot i386 in safe mode. In both > cases the problems appear to be when it probes my SCSI RAID card. > > Having said that, I had a different motherboard with the same parts on it > which ran BSD fine. but this one appears not to, and is AM2. > I have seen weird problems with two AM2 motherboards and 4GB of memory. In one case, using an Adaptec 29160 (ahc) and amd64 (64 bit) I saw data corruption. Note that the same setup worked just fine with i386 because FreeBSD ignored the memory mapped above 4GB. The other board failed to map any memory above 4GB when a PCI card was plugged in and FreeBSD saw only about 3GB. Might be a bug in the BIOS or an option which I failed to set - I didn't spend much time on it. --- Gary Jennejohn From tevans.uk at googlemail.com Mon Oct 13 13:34:13 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Mon Oct 13 13:55:44 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810130937.48093.joao@matik.com.br> References: <200810101429.37244.joao@matik.com.br> <20081011144817.GB64861@icarus.home.lan> <48F0D3B5.6070602@egr.msu.edu> <200810130937.48093.joao@matik.com.br> Message-ID: <1223903131.3262.45.camel@localhost> On Mon, 2008-10-13 at 09:37 -0200, JoaoBR wrote: > On Saturday 11 October 2008 13:26:29 Adam McDougall wrote: > > Jeremy Chadwick wrote: > > > On Sat, Oct 11, 2008 at 04:45:29PM +0200, Gary Jennejohn wrote: > > >> On Sat, 11 Oct 2008 03:13:16 -0700 > > >> > > >> Jeremy Chadwick wrote: > > >>> On Sat, Oct 11, 2008 at 11:30:57AM +0200, Gary Jennejohn wrote: > > >>>> On Fri, 10 Oct 2008 14:29:37 -0300 > > >>>> > > >>>> JoaoBR wrote: > > >>>>> I tried MBs as Asus, Abit and Gigabyte all same result > > >>>>> > > >>>>> Same hardware with SATA works perfect > > >>>>> > > >>>>> Same hardware with scsi up to 3.5Gigs installed works perfect > > >>>>> > > >>>>> what calls my attention that all this MBs do not have the memroy hole > > >>>>> remapping feature so the complete 4gigs are available what normally > > >>>>> was not the case with amd64 Mbs for the Athlon 64 CPUs > > >>>>> > > >>>>> some has an opinion if this is a freebsd issue or MB falure or scsi > > >>>>> drv problem? > > >>>> > > >>>> It's a driver problem. If you want to use SCSI then you'll have to > > >>>> limit memory to 3.5 GB. > > >>> > > >>> What you're saying is that Adaptec and LSI Logic SCSI controllers > > >>> behave badly (and can cause data loss) on amd64 systems which contain > > >>> more than 3.5GB of RAM. This is a very big claim. > > >>> > > >>> Have you talked to Scott Long about this? > > >>> > > >>> Please expand on this, and provide evidence or references. I need to > > >>> document this in my Wiki if it is indeed true. > > >> > > >> See the freebsd-scsi thread with Subject "data corruption with ahc > > >> driver and 4GB of memory using a FBSD-8 64-bit installation?" from Wed, > > >> 30 Jan 2008. > > >> > > >> This was for ahc, but the bit-rot which Scott mentions in his reply > > >> might also apply to the LSI Logic controllers. > > >> > > >> Basically the driver doesn't correctly handle DMA above 4GB. Since the > > >> PCI hole gets mapped above 4GB it causes problems. the (S)ATA drivers > > >> don't seem to have this problem. > > > > > > Thank you -- this is the exact information I was looking for. > > > > > > I will update my Wiki page to reflect this quite major problem. > > > > I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > > controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > > driver) with a 5th generation RAID card with 8G of ram, both have no > > such corruption problems. Providing this as a counter-example just to > > document some evidence of which products seem to work fine. > > _______________________________________________ > > > well this for sure is NOT a AM2 MB but any server MB which indeed run fine as > Tyans, SMs and others I guess > It sounds like your issue is specific to certain motherboards and BIOS, which would be non driver specific. Unless this is something that can be worked around, I think the 'solution' is that with this hardware, you are limited to 3.5 GB RAM. Perhaps different SoHo boards would provide different behaviour... Cheers Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20081013/efb5db58/attachment.pgp From scottl at samsco.org Mon Oct 13 13:39:55 2008 From: scottl at samsco.org (Scott Long) Date: Mon Oct 13 13:55:52 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810130947.28905.joao@matik.com.br> References: <200810101429.37244.joao@matik.com.br> <20081011165250.GA67552@icarus.home.lan> <48F2217C.9010000@samsco.org> <200810130947.28905.joao@matik.com.br> Message-ID: <48F34FA0.10503@samsco.org> JoaoBR wrote: > On Sunday 12 October 2008 14:10:36 Scott Long wrote: > >>>> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS >>>> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac >>>> driver) with a 5th generation RAID card with 8G of ram, both have no >>>> such corruption problems. Providing this as a counter-example just to >>>> document some evidence of which products seem to work fine. >>> Is your LSI SAS controller driven by mpt(4) or mfi(4)? >> I can personal vouch for MPT and MFI drivers working just fine with >4GB. >> > > > let narrow this a little bit, are you talking about AM2 sockets? > > because on AM2 the MPT drv is faulty as AHC, AHD and AACD with => 4Gigs > > > Sounds to me like this is a problem either with AM2 systems, or an infrastructure problem in the OS that is triggered by these AM2 systems. Either way, it's not a SCSI driver problem. Scott From koitsu at FreeBSD.org Mon Oct 13 13:57:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 13 13:57:21 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F34FA0.10503@samsco.org> References: <200810101429.37244.joao@matik.com.br> <20081011165250.GA67552@icarus.home.lan> <48F2217C.9010000@samsco.org> <200810130947.28905.joao@matik.com.br> <48F34FA0.10503@samsco.org> Message-ID: <20081013135704.GA20521@icarus.home.lan> On Mon, Oct 13, 2008 at 07:39:44AM -0600, Scott Long wrote: > JoaoBR wrote: >> On Sunday 12 October 2008 14:10:36 Scott Long wrote: >> >>>>> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS >>>>> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac >>>>> driver) with a 5th generation RAID card with 8G of ram, both have no >>>>> such corruption problems. Providing this as a counter-example just to >>>>> document some evidence of which products seem to work fine. >>>> Is your LSI SAS controller driven by mpt(4) or mfi(4)? >>> I can personal vouch for MPT and MFI drivers working just fine with >4GB. >>> >> >> >> let narrow this a little bit, are you talking about AM2 sockets? >> >> because on AM2 the MPT drv is faulty as AHC, AHD and AACD with => 4Gigs >> >> >> > > Sounds to me like this is a problem either with AM2 systems, or an > infrastructure problem in the OS that is triggered by these AM2 systems. > Either way, it's not a SCSI driver problem. Fully acknowledged. I'll add an entry to my Wiki describing this compatibility problem, but it *will not* fall under the SCSI subsection. It sounds as if there's an implementation/design problem either in FreeBSD's hardware compatibility support for AM2 (probably something very low-level) systems, or there is a bug with these Gigabyte boards; it could be either, or possibly both. It might work in Linux because, for all we know, Linux may have workarounds in place for whatever the problem may be. We simply do not know at this point. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From fabian at wenks.ch Mon Oct 13 14:10:41 2008 From: fabian at wenks.ch (Fabian Wenk) Date: Mon Oct 13 14:10:47 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810130943.22079.joao@matik.com.br> References: <200810101429.37244.joao@matik.com.br> <48F11FD6.7050007@wenks.ch> <20081012105711.33009734@ernst.jennejohn.org> <200810130943.22079.joao@matik.com.br> Message-ID: <48F356D7.2020603@wenks.ch> Hello Jo?o On 13.10.08 13:43, JoaoBR wrote: > On Sunday 12 October 2008 06:57:11 Gary Jennejohn wrote: >> On Sat, 11 Oct 2008 23:51:18 +0200 >> >> Fabian Wenk wrote: >> > I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM >> > and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape >> > drive connected. The disks are on an Areca RAID controller. Access >> > to the disks and the tape drive does work just fine without any >> > crashes. >> >> This is interesting because the 29160 is exactly the controller with >> which I had all my problems, but I was running it with disks only. > I guess his MB is not an AM2 socket Right, my system board is a Tyan Thunder i7520 (S5360) server board (with only one Xeon single core CPU). The Adaptec SCSI is a PCI and the Areca RAID a PCIe controller. I guess some more facts are needed to track this down. Does it make troubles with more then one CPU core and also more then 3.5 GB RAM running on FreeBSD/amd64? If yes, then I'm not surprised that only a few people see this behavior. I think the following informations would be needed to narrow down the affected environment: - FreeBSD version 6.x, 7.x or 8-CURRENT and i368 or amd64 - make and model of system board - make and model of SCSI controller and which driver - on board SCSI controller or PCI / PCI-X / PCIe - device types connected to the SCSI, eg. disk, tape - number of cpu cores - amount of memory So for my system which works fine, this would be: - FreeBSD/amd64 6.3-RELEASE - Tyan Thunder i7520 (S5360) - Adaptec 29160 Ultra160 SCSI adapter (ahc) - PCI - tape drive (DLT-8000) - 1 cpu core - 4 GB RAM bye Fabian From koitsu at FreeBSD.org Mon Oct 13 14:24:51 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Oct 13 14:25:00 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <48F356D7.2020603@wenks.ch> References: <200810101429.37244.joao@matik.com.br> <48F11FD6.7050007@wenks.ch> <20081012105711.33009734@ernst.jennejohn.org> <200810130943.22079.joao@matik.com.br> <48F356D7.2020603@wenks.ch> Message-ID: <20081013142447.GA21047@icarus.home.lan> On Mon, Oct 13, 2008 at 04:10:31PM +0200, Fabian Wenk wrote: > Hello Jo?o > > On 13.10.08 13:43, JoaoBR wrote: >> On Sunday 12 October 2008 06:57:11 Gary Jennejohn wrote: >>> On Sat, 11 Oct 2008 23:51:18 +0200 >>> >>> Fabian Wenk wrote: > >>> > I do have a system with FreeBSD/amd64 6.3-RELEASE with 4 GB RAM >>> > and an Adaptec 29160 Ultra160 SCSI adapter (ahc) with only a tape >>> > drive connected. The disks are on an Areca RAID controller. Access >>> > to the disks and the tape drive does work just fine without any >>> > crashes. >>> >>> This is interesting because the 29160 is exactly the controller with >>> which I had all my problems, but I was running it with disks only. > >> I guess his MB is not an AM2 socket > > Right, my system board is a Tyan Thunder i7520 (S5360) server board (with > only one Xeon single core CPU). The Adaptec SCSI is a PCI and the Areca > RAID a PCIe controller. > > I guess some more facts are needed to track this down. Does it make > troubles with more then one CPU core and also more then 3.5 GB RAM > running on FreeBSD/amd64? > > If yes, then I'm not surprised that only a few people see this behavior. > > I think the following informations would be needed to narrow down the > affected environment: > > - FreeBSD version 6.x, 7.x or 8-CURRENT and i368 or amd64 > - make and model of system board > - make and model of SCSI controller and which driver > - on board SCSI controller or PCI / PCI-X / PCIe > - device types connected to the SCSI, eg. disk, tape > - number of cpu cores > - amount of memory Two items which are missed (sort of implied though): motherboard BIOS version, and SCSI card BIOS version. Let's try to make an effort to get some hardware and software stats from other folks so we can determine what the commonality in all of this is. I can keep track of this stuff if need be. We know for sure at this point that some of the reported systems experiencing this problem work fine on Linux (all memory seen, and no data corruption), so that "sort of" clears the hardware of being bad or buggy. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From joao at matik.com.br Mon Oct 13 14:26:55 2008 From: joao at matik.com.br (JoaoBR) Date: Mon Oct 13 14:27:02 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081013135704.GA20521@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <48F34FA0.10503@samsco.org> <20081013135704.GA20521@icarus.home.lan> Message-ID: <200810131125.41343.joao@matik.com.br> On Monday 13 October 2008 11:57:04 Jeremy Chadwick wrote: > On Mon, Oct 13, 2008 at 07:39:44AM -0600, Scott Long wrote: > > JoaoBR wrote: > >> On Sunday 12 October 2008 14:10:36 Scott Long wrote: > >>>>> I am using some LSI (mpt driver) ultra4 (U320 scsi) and LSI SAS > >>>>> controllers in FreeBSD 7.x amd64 with 20G of ram, and Adaptec (aac > >>>>> driver) with a 5th generation RAID card with 8G of ram, both have no > >>>>> such corruption problems. Providing this as a counter-example just > >>>>> to document some evidence of which products seem to work fine. > >>>> > >>>> Is your LSI SAS controller driven by mpt(4) or mfi(4)? > >>> > >>> I can personal vouch for MPT and MFI drivers working just fine with > >>> >4GB. > >> > >> let narrow this a little bit, are you talking about AM2 sockets? > >> > >> because on AM2 the MPT drv is faulty as AHC, AHD and AACD with => 4Gigs > > > > Sounds to me like this is a problem either with AM2 systems, or an > > infrastructure problem in the OS that is triggered by these AM2 systems. > > Either way, it's not a SCSI driver problem. > > Fully acknowledged. I'll add an entry to my Wiki describing this > compatibility problem, but it *will not* fall under the SCSI subsection. > > It sounds as if there's an implementation/design problem either in > FreeBSD's hardware compatibility support for AM2 (probably something > very low-level) systems, or there is a bug with these Gigabyte boards; good, but it is not only gigabyte, I experienced it on Asus, Abit, Epox and MSI all this MBs have in common that when 4Gig is installed the full 4gig are avaliable to the Os, on former S939 arquitecture, depending on mem hole remapping setting in BIOS there was +/-3.5gig or 4.+Gig available for amd64, mostly the remapping feature was not existent and then there was always +/-3.5 Gig available > it could be either, or possibly both. It might work in Linux because, > for all we know, Linux may have workarounds in place for whatever the > problem may be. We simply do not know at this point. -- Jo?o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From mike at reifenberger.com Mon Oct 13 14:58:00 2008 From: mike at reifenberger.com (Michael Reifenberger) Date: Mon Oct 13 14:58:07 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081013152125.5558af36@ernst.jennejohn.org> References: <20081013125228.GA19035@icarus.home.lan> <20081013152125.5558af36@ernst.jennejohn.org> Message-ID: Hi, I have one ASUS M2N32 WS Pro with X2-Dualcore and 4GB ECC memory connected to an perc/5i controller (mfi). Its a NVidia chipset so parts of the mem gets remapped above 4GB. All is working file. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From fabian at wenks.ch Mon Oct 13 15:48:35 2008 From: fabian at wenks.ch (Fabian Wenk) Date: Mon Oct 13 15:48:47 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <20081013142447.GA21047@icarus.home.lan> References: <200810101429.37244.joao@matik.com.br> <48F11FD6.7050007@wenks.ch> <20081012105711.33009734@ernst.jennejohn.org> <200810130943.22079.joao@matik.com.br> <48F356D7.2020603@wenks.ch> <20081013142447.GA21047@icarus.home.lan> Message-ID: <48F36DCA.40006@wenks.ch> Hello Jeremy On 13.10.08 16:24, Jeremy Chadwick wrote: > Two items which are missed (sort of implied though): motherboard BIOS > version, and SCSI card BIOS version. Ok, for my system this would be: BIOS Information Vendor: Phoenix Technologies Ltd. Version: V1.06 Release Date: 08/01/2006 Adaptec SCSI BIOS v3.10.0 bye Fabian From jhb at freebsd.org Mon Oct 13 16:02:51 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Oct 13 16:02:56 2008 Subject: how does the kernel go about mapping memory for amd64? In-Reply-To: <20081013141556.7b7a0806@ernst.jennejohn.org> References: <20081013141556.7b7a0806@ernst.jennejohn.org> Message-ID: <200810131025.15570.jhb@freebsd.org> On Monday 13 October 2008 08:15:56 am Gary Jennejohn wrote: > This behavior leads me to believe that FreeBSD is only using the memory > mapping hints provided by the BIOS and is not sizing and mapping memory > itself. > > Is that correct? Yes, we depend on the BIOS SMAP (System Map) table. -- John Baldwin From freebsd at sopwith.solgatos.com Mon Oct 13 16:25:56 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Oct 13 16:26:02 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: Your message of "Mon, 13 Oct 2008 11:25:41 -0200." <200810131125.41343.joao@matik.com.br> Message-ID: <200810131622.QAA13636@sopwith.solgatos.com> > > It sounds as if there's an implementation/design problem either in > > FreeBSD's hardware compatibility support for AM2 (probably something > > very low-level) systems, or there is a bug with these Gigabyte boards; > > good, but it is not only gigabyte, I experienced it on Asus, Abit, Epox and= > =20 > MSI =20 Perhaps something common in the firmware/BIOS ? > all this MBs have in common that when 4Gig is installed the full 4gig are=20 > avaliable to the Os, on former S939 arquitecture, depending on mem hole=20 > remapping setting in BIOS there was +/-3.5gig or 4.+Gig available for amd6= > 4,=20 > mostly the remapping feature was not existent and then there was always=20 > +/-3.5 Gig available Is there some debugging flag to turn on that shows what the firmware/BIOS says about addresses, and the final address map (both RAM and I/O devices) as used by FreeBSD? > > it could be either, or possibly both. It might work in Linux because, > > for all we know, Linux may have workarounds in place for whatever the > > problem may be. We simply do not know at this point. IIUC, Linux uses the firmware/BIOS as little as possible and does everything itself. Which is why *BSD can't run on LinuxBIOS. From gary.jennejohn at freenet.de Mon Oct 13 16:43:33 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Mon Oct 13 16:43:40 2008 Subject: am2 MBs - 4g + SCSI wipes out root partition In-Reply-To: <200810131622.QAA13636@sopwith.solgatos.com> References: <200810131125.41343.joao@matik.com.br> <200810131622.QAA13636@sopwith.solgatos.com> Message-ID: <20081013184328.6815a67b@ernst.jennejohn.org> On Mon, 13 Oct 2008 09:22:42 +0100 Dieter wrote: > Is there some debugging flag to turn on that shows what the firmware/BIOS > says about addresses, and the final address map (both RAM and I/O devices) > as used by FreeBSD? > boot -v --- Gary Jennejohn From mhorsfall at dyn-inc.com Tue Oct 14 20:50:02 2008 From: mhorsfall at dyn-inc.com (Matthew Horsfall) Date: Tue Oct 14 22:05:29 2008 Subject: amd64/128101: IO::KQueue with pipes reliably causes kernel panic Message-ID: <200810142047.m9EKlGkk012288@www.freebsd.org> >Number: 128101 >Category: amd64 >Synopsis: IO::KQueue with pipes reliably causes kernel panic >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 14 20:50:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Matthew Horsfall >Release: FreeBSD 6.3-RELEASE-p2 >Organization: Dynamic Network Services Inc. >Environment: FreeBSD hostname 6.3-RELEASE-p2 FreeBSD 6.3-RELEASE-p2 #1: Thu Jun 26 15:21:30 UTC 2008 root@hostname:/usr/obj/usr/src/sys/DELL1950-MPT amd64 >Description: With a simple perl script using IO::KQueue, I'm able to (mostly) instantly cause a kernel panic every time. I've tested this on a Dell 1950 Quad-Core running FreeBSD 6.3-RELEASE-p2, as well as a Dell Optiplex 745 Dual-Core running 7.0-RELEASE-p4 and a Silicon Mechanics Quad-Core Rackform iServ R266 running 6.3-RELEASE-p2. I was originally having the same problem as http://lists.freebsd.org/pipermail/freebsd-current/2008-April/085017.html and so I began investigating and discovered that I could cause a crash reliably. However, the dump I get with this script is apparently incomplete and different from the other crash: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: 12 panic: page fault cpuid = 2 Uptime: 35m14s Dumping 4090 MB (3 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 3323MB (850512 pages) 3307 3291 3275 3259 3243 3227 3211 3195 3179 3163 3147 3131 3115 3099 3083 3067 3051 3035 3019 3003 2987 2971 2955 2939 2923 2907 2891 2875 2859 2843 2827 2811 2795 2779 2763 2747 2731 2715 2699 2683 2667 2651 2635 2619 2603 2587 2571 2555 2539 2523 2507 2491 2475 2459 2443 2427 2411 2395 2379 2363 2347 2331 2315 2299 2283 2267 2251 2235 2219 2203 2187 2171 2155 2139 2123 2107 2091 2075 2059 2043 2027 2011 1995 1979 1963 1947 1931 1915 1899 1883 1867 1851 1835 1819 1803 1787 1771 1755 1739 1723 1707 1691 1675 1659 1643 1627 1611 1595 1579 1563 1547 1531 1515 1499 1483 1467 1451 1435 1419 1403 1387 1371 1355 1339 1323 1307 1291 1275 1259 1243 1227 1211 1195 1179 1163 1147 1131 1115 1099 1083 1067 1051 1035 1019 1003 987 971 955 939 923 907 891 875 859 843 827 811 795 779 763 747 731 715 699 683 667 651 635 619 603 587 571 555 539 523 507 491 475 459 443 427 411 395 379 363 347 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 ... ok chunk 2: 768MB (196608 pages) 753 737 721 705 689 673 657 641 625 609 593 577 561 545 529 513 497 481 465 449 433 417 401 385 369 353 337 321 305 289 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff802486d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80248d71 in panic (fmt=0xffffff001f1a2980 "\b\nÕ\033\001ÿÿÿPç\026+") at /usr/src/sys/kern/kern_shutdown.c:565 #4 0xffffffff803e245f in trap_fatal (frame=0xffffff001f1a2980, eva=18446742978959837704) at /usr/src/sys/amd64/amd64/trap.c:669 #5 0xffffffff803e27dc in trap_pfault (frame=0xffffffffba630840, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:580 #6 0xffffffff803e2a93 in trap (frame= {tf_rdi = 0, tf_rsi = 4, tf_rdx = 1, tf_rcx = 1, tf_r8 = 0, tf_r9 = 0, tf_rax = -1098874572592, tf_rbx = 0, tf_rbp = -1098989819520, tf_r10 = -1098874572800, tf_r11 = -1098989819520, tf_r12 = -2141554528, tf_r13 = -1094763207168, tf_r14 = -1094638512976, tf_r15 = -1167914496, tf_trapno = 12, tf_addr = 0, tf_flags = 1108101562372, tf_err = 16, tf_rip = 0, tf_cs = 8, tf_rflags = 66178, tf_rsp = -1167914744, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:353 #7 0xffffffff803c9b0b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #8 0x0000000000000000 in ?? () #9 0xffffffff80224d71 in kqueue_register (kq=0xffffff011b072600, kev=0xffffffffba630a00, td=0xffffff001f1a2980, waitok=1) at /usr/src/sys/kern/kern_event.c:903 #10 0xffffffff80225225 in kern_kevent (td=0xffffff001f1a2980, fd=4, nchanges=1, nevents=0, k_ops=0xffffffffba630b40, timeout=0x0) at /usr/src/sys/kern/kern_event.c:637 #11 0xffffffff80225b60 in kevent (td=0xffffff001f1a2980, uap=0xffffffffba630bc0) at /usr/src/sys/kern/kern_event.c:571 #12 0xffffffff803e3351 in syscall (frame= {tf_rdi = 3, tf_rsi = 140737488349776, tf_rdx = 1, tf_rcx = 0, tf_r8 = 0, tf_r9 = 0, tf_rax = 363, tf_rbx = 1, tf_rbp = 7, tf_r10 = 6, tf_r11 = 514, tf_r12 = 6883336, tf_r13 = 0, tf_r14 = 33, tf_r15 = 65535, tf_trapno = 12, tf_addr = 6585448, tf_flags = 0, tf_err = 2, tf_rip = 34372507708, tf_cs = 43, tf_rflags = 582, tf_rsp = 140737488349752, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:807 #13 0xffffffff803c9d08 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:287 #14 0x0000000800c2d83c in ?? () Previous frame inner to this frame (corrupt stack?) >How-To-Repeat: Download the scripts at http://hiddenrealms.org/fbsd/ and run ./fbsdkill.pl Crash is usually instant or it may take a few seconds. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From cristobal41 at hotmail.com Tue Oct 14 20:50:02 2008 From: cristobal41 at hotmail.com (Cristobal Perez) Date: Tue Oct 14 22:05:36 2008 Subject: amd64/128102: AsusRock 939N68PV-GLAN Compatibility Message-ID: <200810142047.m9EKltlG012343@www.freebsd.org> >Number: 128102 >Category: amd64 >Synopsis: AsusRock 939N68PV-GLAN Compatibility >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Tue Oct 14 20:50:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Cristobal Perez >Release: FreeNas 0.696.4 >Organization: >Environment: Network capability not available >Description: Dear provider, When I try to align interfaces by the auto detection feature, a "No link up detected" message is displayed. It seems not to recognice the Asusrock 939N68PV-GLAN integrated lan card. Any solution? Regards. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From sgk at troutmask.apl.washington.edu Wed Oct 15 00:50:49 2008 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Wed Oct 15 00:50:56 2008 Subject: linux32 sysctl questions Message-ID: <20081015005048.GA4405@troutmask.apl.washington.edu> On amd64, the linux compatibility layer has the two sysctls compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 where maxssiz defaults to a value of 64MB and maxdsiz defaults to a value of 512MB. What are the maximum permissible values allowed for these sysctls? Is there a fixed ratio that maxdsiz must be larger than maxsdiz? I've installed Matlab on my system and any substantial increase in these values lead to a nonfunction matlab, ie segfaults. -- Steve From marcinkk at gmail.com Thu Oct 16 09:20:01 2008 From: marcinkk at gmail.com (Marcin Kucharczyk) Date: Thu Oct 16 11:13:16 2008 Subject: amd64/128143: NIC with Realtek 8139 (rl driver) doesn't work with RAM higher than 4GB Message-ID: <200810160913.m9G9DUGm096540@www.freebsd.org> >Number: 128143 >Category: amd64 >Synopsis: NIC with Realtek 8139 (rl driver) doesn't work with RAM higher than 4GB >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 16 09:20:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Marcin Kucharczyk >Release: 6.3-RELEASE-p5 >Organization: >Environment: FreeBSD main.mini.net.pl 6.3-RELEASE-p5 FreeBSD 6.3-RELEASE-p5 #11: Sat Oct 4 11:25:20 CEST 2008 marcinkk@main.mini.net.pl:/usr/obj/usr/src/sys/MAIN amd64 >Description: The system: Gigabyte GA-M55plus-S3G (NVIDIA® Geforce 6100 + nForce 430 chipset) + Athlon 64 X2 + 6GB RAM. The system has two NICs: 1. Integrated NVIDIA card (nve driver) 2. Realtek 8139 card (by Edimax or by Asmax) at PCI port (rl driver) Few days ago I've upgraded system memory to 6GB and I've noticed that network communication on rl0 was lost. I've tried: - ifconfig: works ok, autoselect recognize 100baseTX connection; - arp: also works, MAC addresses of connected devices are proprly discovered; - ping: - ping to IP address of rl0 works - ping to any external IP fails, any external communication doesn't work :( Next I've changed system memory size to 4GB. The communication was partialy restored - ping works with about 25% lost packet. After removing another 1GB, so with 3GB, everything works just fine. At the same time nve0 card works properly. >How-To-Repeat: Check other Realtek 8139 in similar configuration? >Fix: The fix ... I've bought Intel 1000 GT, the em driver and everything works ok with 6GB of RAM. >Release-Note: >Audit-Trail: >Unformatted: From gavin at FreeBSD.org Thu Oct 16 14:16:32 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Oct 16 14:16:38 2008 Subject: kern/128102: AsusRock 939N68PV-GLAN not recognized Message-ID: <200810161416.m9GEGV3Q041504@freefall.freebsd.org> Synopsis: AsusRock 939N68PV-GLAN not recognized State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Thu Oct 16 14:12:31 UTC 2008 State-Changed-Why: To submitter: could you please provide the output of: pciconf -l |grep "class=0x02" so that we can at least establish which network card you are using? http://www.freebsd.org/cgi/query-pr.cgi?pr=128102 From gavin at FreeBSD.org Thu Oct 16 14:31:26 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Oct 16 14:31:32 2008 Subject: kern/128143: [rl] NIC Realtek 8139 doesn't work with RAM higher than 4GB Message-ID: <200810161431.m9GEVQOO043183@freefall.freebsd.org> Synopsis: [rl] NIC Realtek 8139 doesn't work with RAM higher than 4GB State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Thu Oct 16 14:25:16 UTC 2008 State-Changed-Why: User has been asked for feeback Responsible-Changed-From-To: freebsd-amd64->freebsd-bin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Oct 16 14:25:16 UTC 2008 Responsible-Changed-Why: Probably not amd64 specific http://www.freebsd.org/cgi/query-pr.cgi?pr=128143 From kib at FreeBSD.org Thu Oct 16 19:54:25 2008 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Thu Oct 16 19:58:31 2008 Subject: kern/128101: [panic] IO::KQueue with pipes reliably causes kernel panic Message-ID: <200810161954.m9GJsOx1076979@freefall.freebsd.org> Synopsis: [panic] IO::KQueue with pipes reliably causes kernel panic State-Changed-From-To: open->closed State-Changed-By: kib State-Changed-When: Thu Oct 16 19:53:02 UTC 2008 State-Changed-Why: The problem is believed to be fixed in HEAD and RELENG_7. Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: kib Responsible-Changed-When: Thu Oct 16 19:53:02 UTC 2008 Responsible-Changed-Why: The problem is believed to be fixed in HEAD and RELENG_7. http://www.freebsd.org/cgi/query-pr.cgi?pr=128101 From philip at FreeBSD.org Fri Oct 17 13:36:25 2008 From: philip at FreeBSD.org (philip@FreeBSD.org) Date: Fri Oct 17 14:22:03 2008 Subject: amd64/125820: [k8temp] [patch] sysctl dev.k8temp.*.sensor1.* are invalid. Message-ID: <200810171336.m9HDaObU005964@freefall.freebsd.org> Synopsis: [k8temp] [patch] sysctl dev.k8temp.*.sensor1.* are invalid. Responsible-Changed-From-To: freebsd-amd64->philip Responsible-Changed-By: philip Responsible-Changed-When: Fri Oct 17 13:36:24 UTC 2008 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=125820 From Tom at ESEstudios.com Mon Oct 20 03:40:01 2008 From: Tom at ESEstudios.com (Tom Eagle) Date: Mon Oct 20 03:40:07 2008 Subject: amd64/128236: portsdb -Uu Indexing Message-ID: <200810200336.m9K3asAl072009@www.freebsd.org> >Number: 128236 >Category: amd64 >Synopsis: portsdb -Uu Indexing >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 20 03:40:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Tom Eagle >Release: FreeBSD 6.2 for AMD64 >Organization: Eagle Systems Engineering, Inc. >Environment: FreeBSD bsd.esestudios.com 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 08:43:30 UTC 2007 root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 >Description: Here is the output of portsdb -Uu. -----Original Message----- From: Charlie Root [mailto:root@bsd.esestudios.com] Sent: Friday, October 17, 2008 11:54 PM To: tom@bsd.esestudios.com Subject: Generating INDEX.tmp - please wait.."Makefile", line 56: Could not find bsd.port.options.mk make: fatal errors encountered -- cannot continue ===> sysutils/apcupsd failed *** Error code 1 ******************************************************************** Before reporting this error, verify that you are running a supported version of FreeBSD (see http://www.FreeBSD.org/ports/) and that you have a complete and up-to-date ports collection. (INDEX builds are not supported with partial or out-of-date ports collections -- in particular, if you are using cvsup, you must cvsup the "ports-all" collection, and have no "refuse" files.) If that is the case, then report the failure to ports@FreeBSD.org together with relevant details of your ports configuration (including FreeBSD version, your architecture, your environment, and your /etc/make.conf settings, especially compiler flags and WITH/WITHOUT settings). Note: the latest pre-generated version of INDEX may be fetched automatically with "make fetchindex". ******************************************************************** *** Error code 1 Stop in /usr/ports. *** Error code 1 Stop in /usr/ports. -- Here is the contents of /etc/make.conf # added by use.perl 2007-08-03 21:37:48 PERL_VER=5.8.8 PERL_VERSION=5.8.8 Here is the output from pkg_info 3ddesktop-0.2.9_1 3D Virtual Desktop Switcher 9box-0.2.1_1 9box can "pack" windows inside itself 9menu-1.8 A simple menu patterened after plan9 9term-1.6.3 An X11 program which emulates a plan9 window ORBit2-2.14.3 High-performance CORBA ORB with support for the C language OpenEXR-1.2.2_1 A high dynamic-range (HDR) image file format abclock-1.0d Clock for X that displays hours and minutes in an analog fa apache-2.2.9_5 Version 2.2.x of Apache web server with prefork MPM. arts-1.5.4,1 Audio system for the KDE integrated X11 desktop asclock-1.0 Afterstep clock with some language extensions aspell-0.60.4_4 Spelling checker with better suggestion logic than ispell atk-1.12.3 A GNOME accessibility toolkit (ATK) autoconf-2.59_2 Automatically configure source code on many Un*x platforms autoconf-2.61_2 Automatically configure source code on many Un*x platforms autoconf-2.62 Automatically configure source code on many Un*x platforms autoconf-wrapper-20071109 Wrapper script for GNU autoconf avahi-0.6.14 Service discovery on a local network bison-1.75_2,1 A parser generator from FSF, (mostly) compatible with Yacc bitstream-vera-1.10_2 Bitstream Vera TrueType font collection ca-roots-1.2 A list of SSL CA root certificates cairo-1.2.4 Vector graphics library with cross-device output support cclient-2006j_1,1 Mark Crispin's C-client mail access routines cdrtools-2.01_5 CD/CD-R[W] and ISO-9660 image creation and extraction tools cups-base-1.2.2 The Common UNIX Printing System curl-7.15.5 Non-interactive tool to get files from FTP, GOPHER, HTTP(S) cvsup-without-gui-16.1h_2 General network file distribution system optimized for CVS cvsup-without-gui-16.1h_4 File distribution system optimized for CVS (non-GUI version db41-4.1.25_3 The Berkeley DB package, revision 4.1 dbh-1.0.24_1 Disk Based Hashtables dbus-0.93_3 A message bus system for inter-application communication dbus-glib-0.71 GLib bindings for the D-BUS messaging system desktop-file-utils-0.11 A couple of command line utilities for working with desktop dmidecode-2.8 A tool for dumping DMI (SMBIOS) contents in human-readable docbook-sk-4.1.2_3 XML version of the DocBook DTD version controlled for Scrol docbook-xml-4.2_1 XML version of the DocBook DTD docbook-xml-4.3 DocBook/XML DTD V4.3, designed for technical documentation docbook-xml-4.4 DocBook/XML DTD V4.4, designed for technical documentation docbook-xsl-1.70.1 XSL DocBook stylesheets drupal-4.6.10 CMS that supports pgsql and mysql drupal5-5.7 A database driven web content management system (CMS) eel-2.16.0_1 Generally useful classes and extensions to GNOME esound-0.2.36_1 A sound library for enlightenment package evolution-data-server-1.8.1_1 The data backends for the Evolution integrated mail/PIM sui expat-2.0.0_1 XML 1.0 parser written in C ezm3-1.1_1 Easier, more portable Modula-3 distribution for building CV fetchmail-6.3.4_3 Batch mail retrieval utility for IMAP/POP2/POP3/ETRN/ODMR ffcall-1.10_1 Foreign function call libraries file-roller-2.16.1,1 An archive manager for zip files, tar, etc firefox-1.5.0.8,1 Web browser based on the browser portion of Mozilla flac-1.1.2_1 Free lossless audio codec fontconfig-2.3.2_6,1 An XML-based font configuration API for X Windows freetype2-2.2.1_1 A free and portable TrueType font rendering engine gail-1.9.3 An implementation of the ATK interfaces for GTK+ widgets gamin-0.1.7_2 A file and directory monitoring system gconf2-2.16.0 A configuration database system for GNOME gdbm-1.8.3_2 The GNU database manager gettext-0.14.5_2 GNU gettext package glib-1.2.10_12 Some useful routines of C programming (previous stable vers glib-2.12.4 Some useful routines of C programming (current stable versi gmake-3.81_1 GNU version of 'make' utility gnome-backgrounds-2.16.1 A collection of backgrounds for GNOME 2 gnome-desktop-2.16.1 Additional UI API for GNOME 2 gnome-doc-utils-0.7.2_1 GNOME doc utils gnome-icon-theme-2.16.0.1_1 A collection of icons for the GNOME 2 desktop gnome-keyring-0.6.0 A program that keeps passwords and other secrets gnome-menus-2.16.1 Implementation of the FreeDesktop Desktop Menu Spec gnome-mime-data-2.4.2_2 A MIME and Application database for GNOME gnome-panel-2.16.1 Panel component for the GNOME 2 Desktop gnome-themes-2.16.1.1 A collection of themes and icons for GNOME2 gnome-utils-2.16.1,1 GNOME 2 support utilities gnome-vfs-2.16.1 GNOME Virtual File System gnomehier-2.2 A utility port that creates the GNOME directory tree gnutls-1.4.4_1 GNU Transport Layer Security library gtar-1.15.1_2 GNU version of the traditional tar archiver gtk-2.10.6_2 Gimp Toolkit for X11 GUI (current stable version) gtk-engines2-2.8.1 Theme engine for the gtk+-2.0 toolkit hal-0.5.8.20060917_2 Hardware Abstraction Layer for simplifying device access help2man-1.36.4_1 Automatically generating simple manual pages from program o hicolor-icon-theme-0.9_2 A high-color icon theme shell from the FreeDesktop project imake-6.9.0 Imake and other utilities from X.Org imap-uw-2006j_3,1 University of Washington IMAP4rev1/POP2/POP3 mail servers imlib2-20060926,1 The next generation graphic library for enlightenment packa intltool-0.35.0 Tools to internationalize various kinds of data files ispell-3.2.06_15 An interactive spelling checker for multiple languages jackit-0.101.1_1 A low-latency audio server jasper-1.701.0_1 An implementation of the codec specified in the JPEG-2000 s joomla-1.0.13 A dynamic web content management system (CMS) jpeg-6b_4 IJG's jpeg compression utilities kdehier-1.0_11 Utility port which installs a hierarchy of shared KDE direc kdelibs-3.5.4_4 Base set of libraries needed by KDE programs kdetoys-3.5.4 Small applications for KDE lcms-1.15_1,1 Light Color Management System -- a color management library libIDL-0.8.7 A library for creating trees of CORBA IDL files libXft-2.1.7_1 A client-sided font API for X applications libart_lgpl-2.3.17_1 Library for high-performance 2D graphics libaudiofile-0.2.6 A sound library for SGI audio file libbonobo-2.16.0_1 A component and compound document system for GNOME2 libbonoboui-2.16.0 GUI frontend to the libbonobo component of GNOME 2 libcroco-0.6.1 CSS2 parsing library libdaemon-0.10_1 Lightweight C library that eases the writing of UNIX daemon libdrm-2.0.2 Userspace interface to kernel Direct Rendering Module servi libexif-0.6.13 Library to read digital camera file meta-data libexo-0.3.0_3 Terminal library, extensions to Xfce by os-cillation libgcrypt-1.2.3_1 "General purpose crypto library based on code used in GnuPG libglade2-2.6.0_2 GNOME glade library libglut-6.4.2 A graphics library similar to SGI's OpenGL libgnome-2.16.0 Libraries for GNOME, a GNU desktop environment libgnomecanvas-2.14.0_2 A graphics library for GNOME libgnomeprint-2.12.1_3 Gnome print support library libgnomeprintui-2.12.1_2 Gnome print support library libgnomeui-2.16.1 Libraries for the GNOME GUI, a GNU desktop environment libgpg-error-1.4 Common error values for all GnuPG components libgsf-1.14.2 An extensible i/o abstraction for dealing with structured f libgtop-2.14.4 GNOME 2 top library libiconv-1.9.2_2 A character set conversion library libid3tag-0.15.1b ID3 tags library (part of MAD project) libidn-0.6.7 Internationalized Domain Names command line tool libltdl-1.5.26 System independent dlopen wrapper libmad-0.15.1b_2 Libmad library (part of MAD project) libmcrypt-2.5.8 Multi-cipher cryptographic library (used in PHP) libmng-1.0.9 Multiple-image Network Graphics (MNG) reference library libogg-1.1.3,3 Ogg bitstream library librsvg2-2.16.0_1 Library for parsing and rendering SVG vector-graphic files libslang-1.4.9 Routines for rapid alpha-numeric terminal applications deve libsndfile-1.0.17 Reading and writing files containing sampled sound (like WA libsoup-2.2.96 A SOAP (Simple Object Access Protocol) implementation in C libtasn1-0.3.6 ASN.1 structure parser library libthai-0.1.5_1 Thai language support library libtool-1.5.22_2 Generic shared library support script libungif-4.1.4_1 Tools and library routines for working with GIF images libvorbis-1.1.2,3 Audio compression codec library libwnck-2.16.1 Library used for writing pagers and taskslists libxfce4gui-4.2.3_2 XFce 4 widget library required by xfce4 and xfwm4 libxfce4util-4.2.3.2_2 XFce 4 library with non-graphical helper functions libxml2-2.6.26 XML parser library for GNOME libxslt-1.1.17 The XSLT C library for GNOME linc-1.0.3_6 A library for writing networked servers & clients m4-1.4.4 GNU m4 mDNSResponder-108 Apple's mDNSResponder metacity-2.16.3 A window manager for the adult in you mhash-0.9.7.1 An easy-to-use library for strong hashes such as MD5 and SH mime-support-3.37.1 MIME Media Types list mutt-1.4.2.2 The Mongrel of Mail User Agents (part Elm, Pine, Mush, mh, mysql-client-5.0.27 Multithreaded SQL database (client) mysql-scripts-5.0.27 Multithreaded SQL database (scripts) mysql-server-5.0.27 Multithreaded SQL database (server) nas-1.8 Network Audio System nautilus-2.16.1 File manager for the GNOME desktop net-snmp-5.2.3_3 An extendable SNMP implementation nspr-4.6.3 A platform-neutral API for system level and libc like funct nss-3.11.3 Libraries to support development of security-enabled applic openldap-client-2.3.27 Open source LDAP client implementation p5-DBD-mysql50-3.0007 MySQL 5.0 driver for the Perl5 Database Interface (DBI) p5-DBI-1.52 The perl5 Database Interface. Required for DBD::* modules p5-Storable-2.15 Persistency for perl data structures p5-XML-Parser-2.34_2 Perl extension interface to James Clark's XML parser, expat p5-gettext-1.05_1 Message handling functions pango-1.14.7 An open-source framework for the layout and rendering of i1 pciids-20060929 Pci.ids database from pciutils pcre-6.7 Perl Compatible Regular Expressions library pear-1.4.11 PEAR framework for PHP pecl-PDO-1.0.3 PHP Data Objects Interface pecl-pdflib-2.1.0_1 A PECL extension to create PDF on the fly perl-5.8.8 Practical Extraction and Report Language php5-5.1.6_3 PHP Scripting Language (Apache Module and CLI) php5-bz2-5.2.6_2 The bz2 shared extension for php php5-calendar-5.1.6_3 The calendar shared extension for php php5-ctype-5.1.6_3 The ctype shared extension for php php5-curl-5.1.6_3 The curl shared extension for php php5-dom-5.1.6_3 The dom shared extension for php php5-ftp-5.1.6_3 The ftp shared extension for php php5-gd-5.1.6_3 The gd shared extension for php php5-gettext-5.1.6_3 The gettext shared extension for php php5-iconv-5.1.6_3 The iconv shared extension for php php5-imap-5.1.6_3 The imap shared extension for php php5-mbstring-5.1.6_3 The mbstring shared extension for php php5-mhash-5.1.6_3 The mhash shared extension for php php5-mysql-5.1.6_3 The mysql shared extension for php php5-mysqli-5.1.6_3 The mysqli shared extension for php php5-openssl-5.1.6_3 The openssl shared extension for php php5-pcre-5.1.6_3 The pcre shared extension for php php5-posix-5.1.6_3 The posix shared extension for php php5-session-5.1.6_3 The session shared extension for php php5-simplexml-5.1.6_3 The simplexml shared extension for php php5-soap-5.1.6_3 The soap shared extension for php php5-sqlite-5.1.6_3 The sqlite shared extension for php php5-tokenizer-5.1.6_3 The tokenizer shared extension for php php5-xml-5.1.6_3 The xml shared extension for php php5-xmlreader-5.1.6_3 The xmlreader shared extension for php php5-xmlwriter-5.1.6_3 The xmlwriter shared extension for php php5-zlib-5.1.6_3 The zlib shared extension for php phpbb-3.0.0_1 A PHP-based bulletin board / discussion forum system pilot-link-0.12.1_1,1 Suite of tools used to connect and sync your Palm handled pkg-config-0.21 A utility to retrieve information about installed libraries png-1.2.12_1 Library for manipulating PNG images policykit-0.1.20060514_2 Framework for controlling access to system-wide components popd-2.2.2a_4 Very fast, highly configurable POP3 server (fully RFC1939 c popt-1.7_1 A getopt(3) like library with a number of enhancements, fro portaudio-18.1_2 Portable cross-platform Audio API portmanager-0.4.1_9 FreeBSD installed ports status and safe update utility portupgrade-2.4.6,2 FreeBSD ports/packages administration and management tool s postfix-2.3.3,1 A secure alternative to widely-used Sendmail py24-libxml2-2.6.26 Python interface for XML parser library for GNOME python24-2.4.3_3 An interpreted object-oriented programming language qpopper-2.53_5 Berkeley POP 3 server (now maintained by Qualcomm) qpopper-4.0.9_2 Berkeley POP 3 server (now maintained by Qualcomm) qt-3.3.6_3 Multiplatform C++ application framework rsync-2.6.8_2 A network file distribution/synchronization utility ruby-1.8.5_3,1 An object-oriented interpreted scripting language ruby18-bdb-0.5.9_2 Ruby interface to Sleepycat's Berkeley DB revision 2 or lat samba-libsmbclient-3.0.23c Shared libs from the samba package scrollkeeper-0.3.14_5,1 An Open Document Cataloging Project sdocbook-xml-4.1.2.5_2 "Simplified" DocBook XML DTD shared-mime-info-0.19 A MIME type database from the FreeDesktop project squirrelmail-1.4.8 A webmail system which accesses mail over IMAP startup-notification-0.8_3 Library that supports startup notification spec from freede system-tools-backends-1.4.2_2 Backend system admin scripts for gnome-system-tools t1lib-5.1.0_1,1 A Type 1 Rasterizer Library for UNIX/X11 tiff-3.8.2 Tools and library routines for working with TIFF images unzip-5.52_2 List, test and extract compressed files in a ZIP archive urlview-0.9_2 URL extractor/launcher xmlcatmgr-2.2 SGML and XML catalog manager xorg-clients-6.9.0_3 X client programs and related files from X.Org xorg-documents-6.9.0 Documentation of X11 protocol and libraries from X.Org xorg-fonts-100dpi-6.9.0_1 X.Org 100dpi bitmap fonts xorg-fonts-75dpi-6.9.0_1 X.Org 75dpi bitmap fonts xorg-fonts-cyrillic-6.9.0_1 X.Org Cyrillic bitmap fonts xorg-fonts-encodings-6.9.0_1 X.Org font encoding files xorg-fonts-miscbitmaps-6.9.0_1 X.Org miscellaneous bitmap fonts xorg-fonts-truetype-6.9.0 X.Org TrueType fonts xorg-fonts-type1-6.9.0 X.Org Type1 fonts xorg-fontserver-6.9.0_1 X font server from X.Org xorg-libraries-6.9.0 X11 libraries and headers from X.Org xorg-manpages-6.9.0 X.Org library manual pages xorg-nestserver-6.9.0_1 Nesting X server from X.Org xorg-printserver-6.9.0_2 X Print server from X.Org xorg-server-6.9.0_5 X.Org X server and related programs xorg-vfbserver-6.9.0_2 X virtual framebuffer server from X.Org xterm-220 Terminal emulator for the X Window System I am running Lenovo with Intel Dual Core 64 using 6.2-RELEASE-amd64-disc?.iso dated 8/3/2007 How do I update my system to 7.0? If you need any other information, let me know. >How-To-Repeat: portsdb -Uu >Fix: Unknown How do I go from 6.2 to 7.0 (or7.1) without reloading the system? Will this help my problem >Release-Note: >Audit-Trail: >Unformatted: From bugmaster at FreeBSD.org Mon Oct 20 11:06:47 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 20 11:29:47 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200810201106.m9KB6lI1082581@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/128236 amd64 portsdb -Uu Indexing f kern/128102 amd64 AsusRock 939N68PV-GLAN not recognized o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on f amd64/116457 amd64 [install] can't install freebsd on dv9420us o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv f amd64/103259 amd64 [ar] Cannot use ataraid on nvidia nForce4+amd64 o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock called (by ata o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 79 problems total. From tinderbox at freebsd.org Mon Oct 20 22:41:06 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 20 22:41:13 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081020224102.7EF9373039@freebsd-current.sentex.ca> TB --- 2008-10-20 22:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-20 22:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-20 22:40:00 - cleaning the object tree TB --- 2008-10-20 22:40:55 - cvsupping the source tree TB --- 2008-10-20 22:40:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-20 22:41:01 - building world (CFLAGS=-O -pipe) TB --- 2008-10-20 22:41:01 - cd /src TB --- 2008-10-20 22:41:01 - /usr/bin/make -B buildworld TB --- 2008-10-20 22:41:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-20 22:41:01 - ERROR: failed to build world TB --- 2008-10-20 22:41:01 - tinderbox aborted TB --- 2.25 user 4.54 system 61.75 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From xxjack12xx at gmail.com Tue Oct 21 02:30:02 2008 From: xxjack12xx at gmail.com (Jack Low) Date: Tue Oct 21 02:30:08 2008 Subject: amd64/128259: "`" crashes csh Message-ID: <200810210222.m9L2MrN0078706@www.freebsd.org> >Number: 128259 >Category: amd64 >Synopsis: "`" crashes csh >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 21 02:30:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Jack Low >Release: FreeBSD 7.1-PRERELEASE >Organization: >Environment: FreeBSD jackcomp.campusbug.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Oct 14 04:14:09 PDT 2008 root@jackcomp.campusbug.com:/usr/obj/usr/src/sys/JACK amd64 >Description: If you type "`" in the csh shell, the shell crashes >How-To-Repeat: Type "`" and hit enter. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From neldredge at math.ucsd.edu Tue Oct 21 04:33:34 2008 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Tue Oct 21 04:33:41 2008 Subject: amd64/128259: "`" crashes csh In-Reply-To: <200810210222.m9L2MrN0078706@www.freebsd.org> References: <200810210222.m9L2MrN0078706@www.freebsd.org> Message-ID: On Tue, 21 Oct 2008, Jack Low wrote: >> Description: > If you type "`" in the csh shell, the shell crashes >> How-To-Repeat: > Type "`" and hit enter. >> Fix: Thanks for the report, Jack. I suspect this is related to bin/125185, which involved csh improperly messing with global state in a vfork'ed subshell. Note that for both the present bug and 125185, the crash does not occur if csh is run with -F to use fork() instead of vfork(). nate@vulcan:/usr/home/nate$ csh %"`" Unmatched `. Segmentation fault: 11 (core dumped) nate@vulcan:/usr/home/nate$ csh -F %"`" Unmatched `. % I'll repeat my recommendation from 125185 that -F be made the default, so that vfork() is not used. I doubt that this bug is amd64 specific but don't have another machine to make sure at the moment. Probably it should be reclassified as "bin". It's also present in 7.0-RELEASE, by the way. -- Nate Eldredge neldredge@math.ucsd.edu From neldredge at math.ucsd.edu Tue Oct 21 04:40:04 2008 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Tue Oct 21 04:40:09 2008 Subject: amd64/128259: "`" crashes csh Message-ID: <200810210440.m9L4e3Y1074248@freefall.freebsd.org> The following reply was made to PR amd64/128259; it has been noted by GNATS. From: Nate Eldredge To: Jack Low Cc: freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/128259: "`" crashes csh Date: Mon, 20 Oct 2008 21:16:09 -0700 (PDT) On Tue, 21 Oct 2008, Jack Low wrote: >> Description: > If you type "`" in the csh shell, the shell crashes >> How-To-Repeat: > Type "`" and hit enter. >> Fix: Thanks for the report, Jack. I suspect this is related to bin/125185, which involved csh improperly messing with global state in a vfork'ed subshell. Note that for both the present bug and 125185, the crash does not occur if csh is run with -F to use fork() instead of vfork(). nate@vulcan:/usr/home/nate$ csh %"`" Unmatched `. Segmentation fault: 11 (core dumped) nate@vulcan:/usr/home/nate$ csh -F %"`" Unmatched `. % I'll repeat my recommendation from 125185 that -F be made the default, so that vfork() is not used. I doubt that this bug is amd64 specific but don't have another machine to make sure at the moment. Probably it should be reclassified as "bin". It's also present in 7.0-RELEASE, by the way. -- Nate Eldredge neldredge@math.ucsd.edu From peterjeremy at optushome.com.au Tue Oct 21 08:42:39 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Oct 21 08:42:45 2008 Subject: amd64/128259: "`" crashes csh In-Reply-To: References: <200810210222.m9L2MrN0078706@www.freebsd.org> Message-ID: <20081021084235.GN25796@server.vk2pj.dyndns.org> On 2008-Oct-20 21:16:09 -0700, Nate Eldredge wrote: >I doubt that this bug is amd64 specific but don't have another machine to >make sure at the moment. Probably it should be reclassified as "bin". >It's also present in 7.0-RELEASE, by the way. It's also present in 7.1-PRERELEASE/i386 but not in 6.3/i386 -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20081021/607c75c0/attachment.pgp From martin.wikesjo at cypoint.se Tue Oct 21 08:10:01 2008 From: martin.wikesjo at cypoint.se (Martin W) Date: Tue Oct 21 11:23:42 2008 Subject: amd64/128263: 2 amd64 dl380 g5 with dual quadcore xeons, 8 and 16gb ram, crash and dump mem Message-ID: <200810210809.m9L89W2c033907@www.freebsd.org> >Number: 128263 >Category: amd64 >Synopsis: 2 amd64 dl380 g5 with dual quadcore xeons, 8 and 16gb ram, crash and dump mem >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 21 08:10:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Martin W >Release: 7.0 amd64 >Organization: Cypoint >Environment: FreeBSD db04 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Two HP DL 380 G5's with dual quadcore xeons, 8GB ram on one and 16GB ram on the other. They have recently been crashing and dumping mem. The 16GB one has crashed 3 times the last 1 1/2 month, twice yesterday. The 8GB one had its first crash yesterday. They are db-servers which run postgresql or mysql. They are both Running 7.0 amd64 RELEASE with GENERIC kernel, completely default installs except for some sysctl tweaks: kern.ipc.maxsockets=16424 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.recvspace=32768 net.inet.tcp.sendspace=65536 Below is the output from kgdb, which looks about the same on both of them. >How-To-Repeat: Random, so don't know. >Fix: >Release-Note: >Audit-Trail: >Unformatted: >kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: <2>NMI ISA b0, EISA ff <2>NMaINNr MMNNiNNItMMIIM M yIII ISeSr AIr ISS IA IbASIAbS Ao b0r0, I0Sb,0Ab ,0l,i k,A Ee ,IEE ElIybS IhAIaSS SE A0rI b,AAf 0dfwfS f E,aff< f 2< > R2 <>p <<><22<><22>>a2rA>> ifRI t2ARSM>yEAa fIff A Mi< 2p< <>S2 < e r<> R222rflof>>uAfa Mr ,prr >e f<

>2il>yk ree2rlrMor,i 2 tlyiRp>k>eaARl yh AryhaMa rirtadd wewyaapM rrarrer rei eoirf aftialrriupor,lye .ula triyek.elrr yi h,at rdyl eweierrarrrrkere ofaoiollrur,r e,y. r ,llh aliirkdikkeeelllwyyya rhhehaaa rrfdrdawdawirlaurrweaere e .fa i fflaauiirleu.lreu.re. F ata FFFaaa ttlaFl t alt arltt atrra apa tFprp aFtat a aa 1Flaa ttall ltrrt aapt p11prr99aa1p9::9 :n :o nn-o1nm9np- 11 o9n:m -nmaasaosnk-sakkabmlbeal baei snitkea1n99rblrlnee utpeitr r::inu o: tnttrenraprnno-puet prt m ansn rturwooahtpnk-ambtl-naimlper atpr a-im pwea sass kkiah wnhwihlkei bnatlaeki leelrei rn n er iekbilnetle brmeonuirpd nuterkn ecle rinpltept tlmrtereruo aian inptreuddpm e k=eo d ecr2t pn;tp euwilc da prr awrmpuiho=idiuheipltpl cee d ti wrni ak ehr=c1ipd u0i;= i;a pni 0 cd 2 = inlepl kw amioee 3dnps t=;i rhua pidnicertc c0nk i0iele oi enc priidi du inndellp o==i nnts0t 1r0 ei3nru kcet s =t rm=moonddee iior0nnx8 :u0cxpe l 5;sociftnm o itfetrrauofcf tfif=cdppuepf o0fnnxui i88 ppo0:o0iiddc =i7nx0nftfeftref 8f2=f fsft a0f =6ixrc8 :=0fcdp 8 0x7f f04f0fkxf ffp88f=; 2:fof08xi0nt70u;i0e rfs faa5piff cdp i=tf8a cf 2ff k i cn is it7sr uddc ;tf fa8 cp 0 o==t i ki n=t7 0ep0ofxrif nao t1 0e 8r2 : s0 xtp faf f c k =004i p o6nfi0fxfnc f1ftae=b0r : 0 x7f0fx 1 0 pi nisnt:9f 0fx isdr f=u f f5 fff=0 ff00ofxtircuntct7eiro ni nt=i p0oxs88 f0f1rfn:afaf7tof0a:mirn0tu cxeptrof0bex7f3f 98f0pffoffifnif oiff0tf 0enntfrr a=m e f a bp7 9 aoff irnfat0m0efxr e8 ep:=o r p=0fof r 0i anxf1 t 0m: efifn8e0 xt0 700xff8f:f0fxeffffrx pf 8f2f=f ff forf fi sff=f n0t exr0 010 ftf001 : 2 afc8k800 0 2xdf7a 0 0 0f = cf7xf8of 0d0 fxfpf:o08f18x f0 0e0=0: 01xs2 fef2f0fxgdf2f022 i0ms ne1000ft n:ct0otsa1cftfafcfke fk 20d rpx=e 2bfdasse f f 8poo0 7 ie6 g00x0finn0 ttmefefrr80f,e nlc i tmo d ef= i=t sf f0e0xgfb00fma0f1fs2 x21 6ee3 0 :=s0fx 0ftx =f1an,0 0cf0kf : fxt0f000pxfffxfafbf1f00t7:ofy p c=e,o 0lax0ifnxi1 bbamdiste e0 x f s fetfff gfm, ef=0anxfebftrf0 t ,y D=P Ll ibp04 feff7fa 9ff0f a m0,sifat ex0 b 1 pfr 7 a=m e0fxr190 :br es00x x af01f0f,,fm fex ffpl iofmflfoi t,= n ptg 0yx pfDefo0fifnf1f f,f PiLd0 xftnfearb 7 a 1fe0fb,e f 3,2 p t0yfft0 e pr , fr ee s g r= rra mae m 1 0aepDxPnL, o 1 bl1o0ng 1 ,, dp perrpo=f 3ceDsPeLs oi=in n 0tt xe1er=0 : 0 r 0 xx1 2s, loo0 f1 f 0 f f:n0,gr 0 1,p,r ege fd l fx = f=fraesagnfs f03 0x0f01x0f12, = 1lo n pir gonc0t0 ,1f1:02:e e1rgrsurpa,nts o r1 edeef f0flpnaarbgo3l2cx6003xff0 eess0d,8ff0ff0f 0f1= ,s i ogrfc0fnI rtaee2o6r03dcOfnl00e0 sr 1faf 1cugPsp tp Le n= r2ooe0c0g603a=e b0 slsemidonr,t e rre fIlOaPgLu s= =0 pitcn d4cut rere1e0netn0re 2ruarnrbte =s ecgbm6lu4epnt aosdeen2pter 0 0 od ,tc ep reosIncOe0s=Psasbsl e Le g=mc= oxbean=d ,1 186I O0(diP(Li c=udr drlel0ets0ee,n:t l0ix=0 cs ,m elibpceuu r2:r)pe raocscpe sunst0t)t r p r otcr=e isasa 1 7e g m0epp =nxn0t(miui,t mn1dub l i0 m=emrlb eer5 :=( i d=c ix1199pl e :fp uac1p)nui0 3ct)r:a p ft xnn ub mtobnr0e-ra mfaffxf pa,s =nks u1a9 bl temeb eirn t fyf0f=e pf1r9rxfef0f f u,pf, t t0lytx,ip1em i b0txrt 1aybpp0ex f f 0c xfp1fu f ib ,= =dt y=Dp P e2 L =0 D0P DLx,1U P 0pbp,Lrt 0iem ,psre :1p r ,7 e dl=so 1n51Dg,e hPs1L 2 ,0 ml 04o1,n ,gd1 pelsr1o,f eng 3d s2 e11 ,f,0 ,l og ndr3ega2 n f01 3,,1 2 dpegfr r30a2o ,n0c,e s ggs orrr1a ae nfpn rl 1ao1cge ps spr sro=ooc rcei nseetfsslseooarrgrr u esepfft l= la egianngatssbe l== er dirinun,t epIrttO ePreLunrarbup lptt=e eed0n,n a baIlbcluOeerPddr,,Le n tII= OO pPP0LLr == o c c00ue s rcsrcu eu nr=trr re 1e2nnt p t(p rirpodorclcoeeessscs e: s =c p s1u=63 ) ( 1=i d4t 1lr(1iae dpl(:e in d:uclm pbeuec:5p r)u c 4p =) tu1r 97)t arp at prn aupnm unbmuembrbee rr = = = 11 991P9 h y sical memory: 8178 MB Dumping 577 MB: 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff80477699 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80477a9d in panic (fmt=0x104

) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff8072ec94 in trap_fatal (frame=0xffffff00010f3000, eva=18446742974215641296) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff8072f7e5 in trap (frame=0xffffffffab795f40) at /usr/src/sys/amd64/amd64/trap.c:526 #6 0xffffffff8071596b in nmi_calltrap () at /usr/src/sys/amd64/amd64/exception.S:387 #7 0xffffffff8070ff82 in acpi_cpu_c1 () at /usr/src/sys/amd64/acpica/acpi_machdep.c:68 #8 0xffffffff801ca7ec in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:939 #9 0xffffffff80495028 in sched_idletd (dummy=Variable "dummy" is not available. ) at /usr/src/sys/kern/sched_4bsd.c:1377 #10 0xffffffff80458db3 in fork_exit (callout=0xffffffff80494f90 , arg=0x0, frame=0xffffffffac284c80) at /usr/src/sys/kern/kern_fork.c:781 #11 0xffffffff807159de in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:415 #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000001 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000cbd000 in ?? () #37 0xffffffff80494f90 in critical_enter () at kern_switch.c:167 #38 0x00000000fffffffb in ?? () #39 0xffffff00010e58d0 in ?? () #40 0xffffff0001105680 in ?? () #41 0xffffff00010f3000 in ?? () #42 0xffffffffac284b98 in ?? () #43 0xffffff00010f3000 in ?? () #44 0xffffffff80495359 in sched_switch (td=0x0, newtd=0xffffffff80494f90, flags=0) at /usr/src/sys/kern/sched_4bsd.c:905 #45 0x0000000000000000 in ?? () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffffac285000 From jkim at FreeBSD.org Tue Oct 21 16:28:41 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Oct 21 16:28:52 2008 Subject: Semi-working patch for amd64 suspend/resume Message-ID: <200810211228.31028.jkim@FreeBSD.org> I was working on suspend/resume support for amd64 and this is the result. It works with a modified QEMU (QEMU does not support S3) but real boxes that I have don't seem to like it (e.g., broken BIOSes). If there is someone interested in finishing it off or giving it a try, the patch is here: http://people.freebsd.org/~jkim/amd64_suspend.diff Please note this patch is heavily inspired by Takanori Watanabe's SMP patch for i386: http://docs.freebsd.org/cgi/mid.cgi?200805131125.m4DBPu1q092741 and large portion is shamlessly stolen from Peter Wemm's AP boot code for amd64. ;-) Cheers, Jung-uk Kim From peterjeremy at optushome.com.au Tue Oct 21 19:40:03 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Oct 21 19:40:09 2008 Subject: amd64/128259: "`" crashes csh Message-ID: <200810211940.m9LJe3Sp093077@freefall.freebsd.org> The following reply was made to PR amd64/128259; it has been noted by GNATS. From: Peter Jeremy To: Nate Eldredge Cc: Jack Low , freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/128259: "`" crashes csh Date: Tue, 21 Oct 2008 19:42:35 +1100 --LG0Ll82vYr46+VA1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Oct-20 21:16:09 -0700, Nate Eldredge wrot= e: >I doubt that this bug is amd64 specific but don't have another machine to= =20 >make sure at the moment. Probably it should be reclassified as "bin".=20 >It's also present in 7.0-RELEASE, by the way. It's also present in 7.1-PRERELEASE/i386 but not in 6.3/i386 --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --LG0Ll82vYr46+VA1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkj9lfsACgkQ/opHv/APuIcuuwCggh3O9M/Hom8um4xydXZjWOPz TBsAoIVlKsCqUhUHKmLfrK3tfPPty/DN =Ctf/ -----END PGP SIGNATURE----- --LG0Ll82vYr46+VA1-- From tinderbox at freebsd.org Wed Oct 22 02:25:54 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 02:26:00 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022022550.7172473039@freebsd-current.sentex.ca> TB --- 2008-10-22 00:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 00:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 00:40:00 - cleaning the object tree TB --- 2008-10-22 00:40:55 - cvsupping the source tree TB --- 2008-10-22 00:40:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 00:41:02 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 00:41:02 - cd /src TB --- 2008-10-22 00:41:02 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 00:41:04 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 02:19:20 UTC 2008 TB --- 2008-10-22 02:19:20 - generating LINT kernel config TB --- 2008-10-22 02:19:20 - cd /src/sys/amd64/conf TB --- 2008-10-22 02:19:20 - /usr/bin/make -B LINT TB --- 2008-10-22 02:19:20 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 02:19:20 - cd /src TB --- 2008-10-22 02:19:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 02:19:20 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/immio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpbb.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpt.c cc1: warnings being treated as errors /src/sys/dev/ppbus/lpt.c: In function 'lpt_attach': /src/sys/dev/ppbus/lpt.c:402: warning: assignment makes pointer from integer without a cast /src/sys/dev/ppbus/lpt.c: In function 'lptopen': /src/sys/dev/ppbus/lpt.c:479: warning: assignment makes integer from pointer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 02:25:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 02:25:50 - ERROR: failed to build lint kernel TB --- 2008-10-22 02:25:50 - tinderbox aborted TB --- 4713.57 user 598.76 system 6349.71 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Wed Oct 22 02:46:12 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 02:46:18 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022022550.7172473039@freebsd-current.sentex.ca> TB --- 2008-10-22 00:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 00:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 00:40:00 - cleaning the object tree TB --- 2008-10-22 00:40:55 - cvsupping the source tree TB --- 2008-10-22 00:40:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 00:41:02 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 00:41:02 - cd /src TB --- 2008-10-22 00:41:02 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 00:41:04 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 02:19:20 UTC 2008 TB --- 2008-10-22 02:19:20 - generating LINT kernel config TB --- 2008-10-22 02:19:20 - cd /src/sys/amd64/conf TB --- 2008-10-22 02:19:20 - /usr/bin/make -B LINT TB --- 2008-10-22 02:19:20 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 02:19:20 - cd /src TB --- 2008-10-22 02:19:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 02:19:20 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/immio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpbb.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpt.c cc1: warnings being treated as errors /src/sys/dev/ppbus/lpt.c: In function 'lpt_attach': /src/sys/dev/ppbus/lpt.c:402: warning: assignment makes pointer from integer without a cast /src/sys/dev/ppbus/lpt.c: In function 'lptopen': /src/sys/dev/ppbus/lpt.c:479: warning: assignment makes integer from pointer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 02:25:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 02:25:50 - ERROR: failed to build lint kernel TB --- 2008-10-22 02:25:50 - tinderbox aborted TB --- 4713.57 user 598.76 system 6349.71 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From tinderbox at freebsd.org Wed Oct 22 07:49:44 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 07:49:51 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022074941.8611873039@freebsd-current.sentex.ca> TB --- 2008-10-22 06:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 06:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 06:00:00 - cleaning the object tree TB --- 2008-10-22 06:00:40 - cvsupping the source tree TB --- 2008-10-22 06:00:40 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 06:00:45 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 06:00:45 - cd /src TB --- 2008-10-22 06:00:45 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 06:00:47 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 07:42:53 UTC 2008 TB --- 2008-10-22 07:42:53 - generating LINT kernel config TB --- 2008-10-22 07:42:53 - cd /src/sys/amd64/conf TB --- 2008-10-22 07:42:53 - /usr/bin/make -B LINT TB --- 2008-10-22 07:42:53 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 07:42:53 - cd /src TB --- 2008-10-22 07:42:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 07:42:53 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/immio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpbb.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpt.c cc1: warnings being treated as errors /src/sys/dev/ppbus/lpt.c: In function 'lpt_attach': /src/sys/dev/ppbus/lpt.c:402: warning: assignment makes pointer from integer without a cast /src/sys/dev/ppbus/lpt.c: In function 'lptopen': /src/sys/dev/ppbus/lpt.c:479: warning: assignment makes integer from pointer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 07:49:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 07:49:41 - ERROR: failed to build lint kernel TB --- 2008-10-22 07:49:41 - tinderbox aborted TB --- 4717.34 user 598.34 system 6580.62 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Wed Oct 22 07:50:41 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 07:50:48 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022074941.8611873039@freebsd-current.sentex.ca> TB --- 2008-10-22 06:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 06:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 06:00:00 - cleaning the object tree TB --- 2008-10-22 06:00:40 - cvsupping the source tree TB --- 2008-10-22 06:00:40 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 06:00:45 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 06:00:45 - cd /src TB --- 2008-10-22 06:00:45 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 06:00:47 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 07:42:53 UTC 2008 TB --- 2008-10-22 07:42:53 - generating LINT kernel config TB --- 2008-10-22 07:42:53 - cd /src/sys/amd64/conf TB --- 2008-10-22 07:42:53 - /usr/bin/make -B LINT TB --- 2008-10-22 07:42:53 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 07:42:53 - cd /src TB --- 2008-10-22 07:42:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 07:42:53 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/immio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpbb.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpt.c cc1: warnings being treated as errors /src/sys/dev/ppbus/lpt.c: In function 'lpt_attach': /src/sys/dev/ppbus/lpt.c:402: warning: assignment makes pointer from integer without a cast /src/sys/dev/ppbus/lpt.c: In function 'lptopen': /src/sys/dev/ppbus/lpt.c:479: warning: assignment makes integer from pointer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 07:49:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 07:49:41 - ERROR: failed to build lint kernel TB --- 2008-10-22 07:49:41 - tinderbox aborted TB --- 4717.34 user 598.34 system 6580.62 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From tinderbox at freebsd.org Wed Oct 22 13:25:46 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 13:25:59 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022132539.6ACE073039@freebsd-current.sentex.ca> TB --- 2008-10-22 11:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 11:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 11:40:00 - cleaning the object tree TB --- 2008-10-22 11:40:41 - cvsupping the source tree TB --- 2008-10-22 11:40:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 11:40:47 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 11:40:47 - cd /src TB --- 2008-10-22 11:40:47 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 11:40:49 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 13:19:08 UTC 2008 TB --- 2008-10-22 13:19:08 - generating LINT kernel config TB --- 2008-10-22 13:19:08 - cd /src/sys/amd64/conf TB --- 2008-10-22 13:19:08 - /usr/bin/make -B LINT TB --- 2008-10-22 13:19:09 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 13:19:09 - cd /src TB --- 2008-10-22 13:19:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 13:19:09 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/immio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpbb.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpt.c cc1: warnings being treated as errors /src/sys/dev/ppbus/lpt.c: In function 'lpt_attach': /src/sys/dev/ppbus/lpt.c:402: warning: assignment makes pointer from integer without a cast /src/sys/dev/ppbus/lpt.c: In function 'lptopen': /src/sys/dev/ppbus/lpt.c:479: warning: assignment makes integer from pointer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 13:25:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 13:25:39 - ERROR: failed to build lint kernel TB --- 2008-10-22 13:25:39 - tinderbox aborted TB --- 4714.03 user 596.98 system 6338.55 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Wed Oct 22 13:26:51 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 13:26:57 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022132539.6ACE073039@freebsd-current.sentex.ca> TB --- 2008-10-22 11:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 11:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 11:40:00 - cleaning the object tree TB --- 2008-10-22 11:40:41 - cvsupping the source tree TB --- 2008-10-22 11:40:41 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 11:40:47 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 11:40:47 - cd /src TB --- 2008-10-22 11:40:47 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 11:40:49 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 13:19:08 UTC 2008 TB --- 2008-10-22 13:19:08 - generating LINT kernel config TB --- 2008-10-22 13:19:08 - cd /src/sys/amd64/conf TB --- 2008-10-22 13:19:08 - /usr/bin/make -B LINT TB --- 2008-10-22 13:19:09 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 13:19:09 - cd /src TB --- 2008-10-22 13:19:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 13:19:09 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/immio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpbb.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/lpt.c cc1: warnings being treated as errors /src/sys/dev/ppbus/lpt.c: In function 'lpt_attach': /src/sys/dev/ppbus/lpt.c:402: warning: assignment makes pointer from integer without a cast /src/sys/dev/ppbus/lpt.c: In function 'lptopen': /src/sys/dev/ppbus/lpt.c:479: warning: assignment makes integer from pointer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 13:25:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 13:25:39 - ERROR: failed to build lint kernel TB --- 2008-10-22 13:25:39 - tinderbox aborted TB --- 4714.03 user 596.98 system 6338.55 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From tinderbox at freebsd.org Wed Oct 22 19:05:27 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 19:05:36 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022190523.8082773039@freebsd-current.sentex.ca> TB --- 2008-10-22 17:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 17:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 17:20:00 - cleaning the object tree TB --- 2008-10-22 17:20:42 - cvsupping the source tree TB --- 2008-10-22 17:20:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 17:20:48 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 17:20:48 - cd /src TB --- 2008-10-22 17:20:48 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 17:20:50 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 18:58:50 UTC 2008 TB --- 2008-10-22 18:58:50 - generating LINT kernel config TB --- 2008-10-22 18:58:50 - cd /src/sys/amd64/conf TB --- 2008-10-22 18:58:50 - /usr/bin/make -B LINT TB --- 2008-10-22 18:58:50 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 18:58:50 - cd /src TB --- 2008-10-22 18:58:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 18:58:50 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/vpoio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:754: error: 'dev' undeclared (first use in this function) /src/sys/dev/ppc/ppc.c:754: error: (Each undeclared identifier is reported only once /src/sys/dev/ppc/ppc.c:754: error: for each function it appears in.) /src/sys/dev/ppc/ppc.c: In function 'ppc_w83877f_detect': /src/sys/dev/ppc/ppc.c:1047: error: 'dev' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 19:05:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 19:05:23 - ERROR: failed to build lint kernel TB --- 2008-10-22 19:05:23 - tinderbox aborted TB --- 4714.66 user 596.60 system 6322.49 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Wed Oct 22 19:06:08 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Oct 22 19:06:15 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081022190523.8082773039@freebsd-current.sentex.ca> TB --- 2008-10-22 17:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-22 17:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-22 17:20:00 - cleaning the object tree TB --- 2008-10-22 17:20:42 - cvsupping the source tree TB --- 2008-10-22 17:20:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-22 17:20:48 - building world (CFLAGS=-O -pipe) TB --- 2008-10-22 17:20:48 - cd /src TB --- 2008-10-22 17:20:48 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 22 17:20:50 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Oct 22 18:58:50 UTC 2008 TB --- 2008-10-22 18:58:50 - generating LINT kernel config TB --- 2008-10-22 18:58:50 - cd /src/sys/amd64/conf TB --- 2008-10-22 18:58:50 - /usr/bin/make -B LINT TB --- 2008-10-22 18:58:50 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-22 18:58:50 - cd /src TB --- 2008-10-22 18:58:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 22 18:58:50 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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppbus/vpoio.c 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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ppc/ppc.c /src/sys/dev/ppc/ppc.c: In function 'ppc_smc37c66xgt_detect': /src/sys/dev/ppc/ppc.c:754: error: 'dev' undeclared (first use in this function) /src/sys/dev/ppc/ppc.c:754: error: (Each undeclared identifier is reported only once /src/sys/dev/ppc/ppc.c:754: error: for each function it appears in.) /src/sys/dev/ppc/ppc.c: In function 'ppc_w83877f_detect': /src/sys/dev/ppc/ppc.c:1047: error: 'dev' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-22 19:05:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-22 19:05:23 - ERROR: failed to build lint kernel TB --- 2008-10-22 19:05:23 - tinderbox aborted TB --- 4714.66 user 596.60 system 6322.49 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From jkim at FreeBSD.org Wed Oct 22 20:23:19 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Oct 22 20:23:25 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <48FF78F0.2090801@FreeBSD.org> References: <1224616985.00027652.1224606603@10.7.7.3> <48FF78F0.2090801@FreeBSD.org> Message-ID: <200810221623.09613.jkim@FreeBSD.org> On Wednesday 22 October 2008 03:03 pm, Alexander Motin wrote: > Hi. > > Jung-uk Kim wrote: > > I was working on suspend/resume support for amd64 and this is the > > result. It works with a modified QEMU (QEMU does not support S3) > > but real boxes that I have don't seem to like it (e.g., broken > > BIOSes). If there is someone interested in finishing it off or > > giving it a try, the patch is here: > > > > http://people.freebsd.org/~jkim/amd64_suspend.diff > > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 > system successfully got down, but on wakeup button, two seconds > after power up, even without video initialization, it shut down, > reset and then started usual boot. I have tried both original and > updated BIOS, without any difference. > > Can I give you any other help? When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', does it bounce back? If it does not, there are other problems, e.g., device drivers. On my desktop, for example, vga(4) tries to restore previous state while resuming but it hangs system. In fact, I believe ISA-era EGA/VGA save/restore routines do not work for modern graphics cards at all. :-( Jung-uk Kim From jhb at freebsd.org Wed Oct 22 22:33:52 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 22 22:34:04 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <48FF9AFA.3030201@root.org> References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> Message-ID: <200810221813.39270.jhb@freebsd.org> On Wednesday 22 October 2008 05:28:26 pm Nate Lawson wrote: > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', > >> does it bounce back? If it does not, there are other problems, e.g., > >> device drivers. On my desktop, for example, vga(4) tries to restore > >> previous state while resuming but it hangs system. In fact, I believe > >> ISA-era EGA/VGA save/restore routines do not work for modern graphics > >> cards at all. :-( > > > > Test passed from both console and XOrg. I have integrated i965GM video. > > > > Here is verbose messages from that trip "there and back again": > > > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > > > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video state > > Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from D0 to D3 > > Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition from D0 to D3 > > Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: Transition from D0 to D3 > > Oct 23 00:12:00 mavbook kernel: acpi: bad write to port 0x080 (32), val > > 0xbb > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 to D3 > > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D0 to D3 > > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: acpi: bad write to port 0x080 (32), val > > 0xaa > > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D3 to D0 > > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D3 to D0 > > That's kind of weird. The above devices were turned off (D3) then back > on again (D0). I'm wondering about that blocked write also. I think they were probably off before due to not having a driver and we turned them back on, noticed there wasn't a driver, and turned them back off again. If so, that should be fixable. -- John Baldwin From mav at FreeBSD.org Wed Oct 22 20:03:15 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 22 22:46:38 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <1224616985.00027652.1224606603@10.7.7.3> References: <1224616985.00027652.1224606603@10.7.7.3> Message-ID: <48FF78F0.2090801@FreeBSD.org> Hi. Jung-uk Kim wrote: > I was working on suspend/resume support for amd64 and this is the > result. It works with a modified QEMU (QEMU does not support S3) but > real boxes that I have don't seem to like it (e.g., broken BIOSes). > If there is someone interested in finishing it off or giving it a > try, the patch is here: > > http://people.freebsd.org/~jkim/amd64_suspend.diff I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 system successfully got down, but on wakeup button, two seconds after power up, even without video initialization, it shut down, reset and then started usual boot. I have tried both original and updated BIOS, without any difference. Can I give you any other help? -- Alexander Motin From mav at FreeBSD.org Wed Oct 22 21:20:40 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 22 22:59:23 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <200810221623.09613.jkim@FreeBSD.org> References: <1224616985.00027652.1224606603@10.7.7.3> <48FF78F0.2090801@FreeBSD.org> <200810221623.09613.jkim@FreeBSD.org> Message-ID: <48FF9925.4090007@FreeBSD.org> Jung-uk Kim wrote: > When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', > does it bounce back? If it does not, there are other problems, e.g., > device drivers. On my desktop, for example, vga(4) tries to restore > previous state while resuming but it hangs system. In fact, I > believe ISA-era EGA/VGA save/restore routines do not work for modern > graphics cards at all. :-( Test passed from both console and XOrg. I have integrated i965GM video. Here is verbose messages from that trip "there and back again": Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 Oct 23 00:11:59 mavbook kernel: bge0: Disabling fastboot Oct 23 00:11:59 mavbook kernel: bge0: link DOWN Oct 23 00:11:59 mavbook kernel: pci0:4:0:0: Transition from D0 to D3 Oct 23 00:11:59 mavbook kernel: iwn0: iwn_mem_lock: could not lock memory Oct 23 00:11:59 mavbook last message repeated 17 times Oct 23 00:11:59 mavbook kernel: pci0:5:0:0: Transition from D0 to D3 Oct 23 00:11:59 mavbook kernel: usb4: interrupt while not operating ignored Oct 23 00:11:59 mavbook last message repeated 3 times Oct 23 00:11:59 mavbook kernel: fwohci0: fwohci_pci_suspend Oct 23 00:11:59 mavbook kernel: pci0:10:9:0: Transition from D0 to D3 Oct 23 00:11:59 mavbook kernel: usb4: interrupt while not operating ignored Oct 23 00:11:59 mavbook last message repeated 3 times Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video state Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: acpi: bad write to port 0x080 (32), val 0xbb Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D0 to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: acpi: bad write to port 0x080 (32), val 0xaa Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: hdac0: GPIO init: data=0x00000000 mask=0x00000000 dir=0x00000000 Oct 23 00:12:06 mavbook kernel: hdac0: GPIO commit: data=0x00000001 mask=0x00000001 dir=0x00000001 Oct 23 00:12:06 mavbook kernel: hdac0: Enabling headphone/speaker audio routing switching: Oct 23 00:12:06 mavbook kernel: hdac0: as=0 sense nid=20 [UNSOL] Oct 23 00:12:06 mavbook kernel: hdac0: Pin sense: nid=20 res=0x80000000 Oct 23 00:12:06 mavbook kernel: pci0:4:0:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: bge0: link UP Oct 23 00:12:06 mavbook kernel: bge0: Disabling fastboot Oct 23 00:12:06 mavbook kernel: bge0: link DOWN Oct 23 00:12:06 mavbook kernel: bge0: Disabling fastboot Oct 23 00:12:06 mavbook kernel: pci0:5:0:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:10:9:0: Transition from D3 to D0 Oct 23 00:12:06 mavbook kernel: fwohci0: Phy 1394a available S400, 3 ports. Oct 23 00:12:06 mavbook kernel: fwohci0: Link S400, max_rec 2048 bytes. Oct 23 00:12:06 mavbook kernel: fwohci0: Initiate bus reset Oct 23 00:12:06 mavbook kernel: fwohci0: BUS reset Oct 23 00:12:06 mavbook kernel: fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode Oct 23 00:12:06 mavbook kernel: ata0: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata0: reset tp1 mask=03 ostat0=50 ostat1=00 Oct 23 00:12:06 mavbook kernel: ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb Oct 23 00:12:06 mavbook kernel: ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 Oct 23 00:12:06 mavbook kernel: ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 Oct 23 00:12:06 mavbook kernel: iwn0: RF switch: radio fdiisraebwlierde Oct 23 00:12:06 mavbook kernel: 0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Oct 23 00:12:06 mavbook kernel: firewire0: bus manager 0 (me) Oct 23 00:12:06 mavbook kernel: fwohci0: phy int Oct 23 00:12:06 mavbook kernel: ugen0: at uhub2 port 3 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: bge0: link UP Oct 23 00:12:06 mavbook kernel: bge0: 2 link states coalesced Oct 23 00:12:06 mavbook kernel: bge0: link state changed to UP Oct 23 00:12:06 mavbook kernel: ugen1: at uhub0 port 1 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: ugen1: detached Oct 23 00:12:06 mavbook kernel: ums0: at uhub3 port 2 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: acd0: setting PIO4 on ICH8M chip Oct 23 00:12:06 mavbook kernel: ugen0: detached Oct 23 00:12:06 mavbook kernel: ukbd0: at uhub4 port 1 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: ums0: detached Oct 23 00:12:06 mavbook kernel: ukbd0: detached Oct 23 00:12:06 mavbook kernel: uhid0: at uhub4 port 1 (addr 2) disconnected Oct 23 00:12:06 mavbook kernel: uhid0: detached Oct 23 00:12:06 mavbook kernel: acd0: setting UDMA33 on ICH8M chip Oct 23 00:12:06 mavbook kernel: ata0: reinit done .. Oct 23 00:12:06 mavbook kernel: ata2: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata2: SATA connect time=0ms Oct 23 00:12:06 mavbook kernel: ata2: BUSY wait time=1ms Oct 23 00:12:06 mavbook kernel: ata2: SIGNATURE: 00000101 Oct 23 00:12:06 mavbook kernel: ata2: ahci_reset devices=00000001 Oct 23 00:12:06 mavbook kernel: ata2: reinit done .. Oct 23 00:12:06 mavbook kernel: ata3: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata3: SATA connect status=00000004 Oct 23 00:12:06 mavbook kernel: ata3: phy reset found no device Oct 23 00:12:06 mavbook kernel: ata3: reinit done .. Oct 23 00:12:06 mavbook kernel: ata4: reiniting channel .. Oct 23 00:12:06 mavbook kernel: ata4: SATA connect status=00000000 Oct 23 00:12:06 mavbook kernel: ata4: phy reset found no device Oct 23 00:12:06 mavbook kernel: ata4: reinit done .. Oct 23 00:12:06 mavbook kernel: atkbd: the current kbd controller command byte 0047 Oct 23 00:12:06 mavbook kernel: atkbd: keyboard ID 0x41ab (2) Oct 23 00:12:06 mavbook kernel: kbdc: RESET_KBD return code:00fa Oct 23 00:12:06 mavbook kernel: kbdc: RESET_KBD status:00aa Oct 23 00:12:06 mavbook kernel: battery0: battery initialization start Oct 23 00:12:06 mavbook kernel: battery0: battery initialization done, tried 1 times Oct 23 00:12:07 mavbook kernel: drm0: [MPSAFE] Oct 23 00:12:07 mavbook kernel: drm0: [ITHREAD] Oct 23 00:12:07 mavbook kernel: ugen0: on uhub2 Oct 23 00:12:07 mavbook kernel: ugen1: on uhub0 Oct 23 00:12:07 mavbook kernel: ums0: on uhub3 Oct 23 00:12:07 mavbook kernel: ums0: 16 buttons and Z dir. Oct 23 00:12:07 mavbook acpi: resumed at 20081023 00:12:07 Oct 23 00:12:07 mavbook root: Unknown USB device: vendor 0x064e product 0xa101 bus uhub2 Oct 23 00:12:07 mavbook root: Unknown USB device: vendor 0x147e product 0x2016 bus uhub0 Oct 23 00:12:07 mavbook root: Unknown USB device: vendor 0x046d product 0xc50e bus uhub3 Oct 23 00:12:09 mavbook root: Unknown USB device: vendor 0x046d product 0xc313 bus uhub4 Oct 23 00:12:09 mavbook kernel: ukbd0: on uhub4 Oct 23 00:12:09 mavbook kernel: kbd2 at ukbd0 Oct 23 00:12:09 mavbook kernel: kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 Oct 23 00:12:09 mavbook kernel: uhid0: on uhub4 -- Alexander Motin From nate at root.org Wed Oct 22 22:42:36 2008 From: nate at root.org (Nate Lawson) Date: Wed Oct 22 23:00:03 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <48FF9925.4090007@FreeBSD.org> References: <1224616985.00027652.1224606603@10.7.7.3> <48FF78F0.2090801@FreeBSD.org> <200810221623.09613.jkim@FreeBSD.org> <48FF9925.4090007@FreeBSD.org> Message-ID: <48FF9AFA.3030201@root.org> Alexander Motin wrote: > Jung-uk Kim wrote: >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf -s 3', >> does it bounce back? If it does not, there are other problems, e.g., >> device drivers. On my desktop, for example, vga(4) tries to restore >> previous state while resuming but it hangs system. In fact, I believe >> ISA-era EGA/VGA save/restore routines do not work for modern graphics >> cards at all. :-( > > Test passed from both console and XOrg. I have integrated i965GM video. > > Here is verbose messages from that trip "there and back again": > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video state > Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from D0 to D3 > Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition from D0 to D3 > Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: Transition from D0 to D3 > Oct 23 00:12:00 mavbook kernel: acpi: bad write to port 0x080 (32), val > 0xbb > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 to D3 > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D0 to D3 > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: acpi: bad write to port 0x080 (32), val > 0xaa > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D3 to D0 > Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition from D3 to D0 That's kind of weird. The above devices were turned off (D3) then back on again (D0). I'm wondering about that blocked write also. -- Nate From jkim at FreeBSD.org Wed Oct 22 23:44:23 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Oct 22 23:44:29 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <48FF9AFA.3030201@root.org> References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> Message-ID: <200810221944.13406.jkim@FreeBSD.org> On Wednesday 22 October 2008 05:28 pm, Nate Lawson wrote: > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf > >> -s 3', does it bounce back? If it does not, there are other > >> problems, e.g., device drivers. On my desktop, for example, > >> vga(4) tries to restore previous state while resuming but it > >> hangs system. In fact, I believe ISA-era EGA/VGA save/restore > >> routines do not work for modern graphics cards at all. :-( > > > > Test passed from both console and XOrg. I have integrated i965GM > > video. > > > > Here is verbose messages from that trip "there and back again": > > > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > > > > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video > > state Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from > > D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition > > from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: > > Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: acpi: > > bad write to port 0x080 (32), val 0xbb > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 > > to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition > > from D0 to D3 > > > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to > > D0 Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 > > to D0 Oct 23 00:12:06 mavbook kernel: acpi: bad write to port > > 0x080 (32), val 0xaa > > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 > > to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition > > from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: > > Transition from D3 to D0 > > That's kind of weird. The above devices were turned off (D3) then > back on again (D0). I'm wondering about that blocked write also. The port 0x80 is usually used for BIOS debugging. http://www.coreboot.org/FAQ#POST_card Probably BIOS developer forgot to comment out the lines. :-) Jung-uk Kim From neldredge at math.ucsd.edu Thu Oct 23 00:24:43 2008 From: neldredge at math.ucsd.edu (Nate Eldredge) Date: Thu Oct 23 00:24:49 2008 Subject: Semi-working patch for amd64 suspend/resume In-Reply-To: <200810221944.13406.jkim@FreeBSD.org> References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> <200810221944.13406.jkim@FreeBSD.org> Message-ID: On Wed, 22 Oct 2008, Jung-uk Kim wrote: > The port 0x80 is usually used for BIOS debugging. > > http://www.coreboot.org/FAQ#POST_card > > Probably BIOS developer forgot to comment out the lines. :-) Or it's been left in as a diagnostic tool. My motherboard has a built-in LED display wired up to port 0x80, and it flashes various numbers as it passes different stages of booting. Useful for detecting various types of failure, nicer than the beep codes. It can also be handy for kernel debugging, when you can't use printf. A very thoughtful feature on the motherboard designer's part. Btw, I'm interested to test the patch, and I'll do so when I have a chance. This is a feature I've been awaiting for some time. -- Nate Eldredge neldredge@math.ucsd.edu From tinderbox at freebsd.org Fri Oct 24 01:42:53 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 24 01:42:59 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 Message-ID: <20081024014249.56BDC1B5078@freebsd-stable.sentex.ca> TB --- 2008-10-24 01:37:06 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-10-24 01:37:06 - starting RELENG_7_1 tinderbox run for amd64/amd64 TB --- 2008-10-24 01:37:06 - mkdir /tinderbox/RELENG_7_1 TB --- 2008-10-24 01:37:06 - mkdir /tinderbox/RELENG_7_1/amd64 TB --- 2008-10-24 01:37:06 - mkdir /tinderbox/RELENG_7_1/amd64/amd64 TB --- 2008-10-24 01:37:06 - cleaning the object tree TB --- 2008-10-24 01:37:06 - cvsupping the source tree TB --- 2008-10-24 01:37:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_1/amd64/amd64/supfile TB --- 2008-10-24 01:42:49 - building world (CFLAGS=-O2 -pipe) TB --- 2008-10-24 01:42:49 - cd /src TB --- 2008-10-24 01:42:49 - ERROR: /src: No such file or directory TB --- 2008-10-24 01:42:49 - tinderbox aborted TB --- 1.95 user 0.97 system 343.08 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_1-amd64-amd64.full From tinderbox at freebsd.org Fri Oct 24 02:04:02 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 24 02:04:09 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 Message-ID: <20081024014249.56BDC1B5078@freebsd-stable.sentex.ca> TB --- 2008-10-24 01:37:06 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-10-24 01:37:06 - starting RELENG_7_1 tinderbox run for amd64/amd64 TB --- 2008-10-24 01:37:06 - mkdir /tinderbox/RELENG_7_1 TB --- 2008-10-24 01:37:06 - mkdir /tinderbox/RELENG_7_1/amd64 TB --- 2008-10-24 01:37:06 - mkdir /tinderbox/RELENG_7_1/amd64/amd64 TB --- 2008-10-24 01:37:06 - cleaning the object tree TB --- 2008-10-24 01:37:06 - cvsupping the source tree TB --- 2008-10-24 01:37:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_1/amd64/amd64/supfile TB --- 2008-10-24 01:42:49 - building world (CFLAGS=-O2 -pipe) TB --- 2008-10-24 01:42:49 - cd /src TB --- 2008-10-24 01:42:49 - ERROR: /src: No such file or directory TB --- 2008-10-24 01:42:49 - tinderbox aborted TB --- 1.95 user 0.97 system 343.08 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_1-amd64-amd64.full _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From tinderbox at freebsd.org Fri Oct 24 13:57:18 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 24 13:57:24 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 Message-ID: <20081024135714.879FB1B5078@freebsd-stable.sentex.ca> TB --- 2008-10-24 13:57:07 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-10-24 13:57:07 - starting RELENG_7_1 tinderbox run for amd64/amd64 TB --- 2008-10-24 13:57:07 - cleaning the object tree TB --- 2008-10-24 13:57:07 - cvsupping the source tree TB --- 2008-10-24 13:57:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_1/amd64/amd64/supfile TB --- 2008-10-24 13:57:14 - building world (CFLAGS=-O2 -pipe) TB --- 2008-10-24 13:57:14 - cd /src TB --- 2008-10-24 13:57:14 - ERROR: /src: No such file or directory TB --- 2008-10-24 13:57:14 - tinderbox aborted TB --- 1.31 user 0.17 system 6.84 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_1-amd64-amd64.full From tinderbox at freebsd.org Sat Oct 25 02:17:10 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Oct 25 02:17:28 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 Message-ID: <20081025021707.6B7031B5078@freebsd-stable.sentex.ca> TB --- 2008-10-25 02:16:59 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-10-25 02:16:59 - starting RELENG_7_1 tinderbox run for amd64/amd64 TB --- 2008-10-25 02:16:59 - cleaning the object tree TB --- 2008-10-25 02:16:59 - cvsupping the source tree TB --- 2008-10-25 02:16:59 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_1/amd64/amd64/supfile TB --- 2008-10-25 02:17:07 - building world (CFLAGS=-O2 -pipe) TB --- 2008-10-25 02:17:07 - cd /src TB --- 2008-10-25 02:17:07 - ERROR: /src: No such file or directory TB --- 2008-10-25 02:17:07 - tinderbox aborted TB --- 1.40 user 0.09 system 7.36 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_1-amd64-amd64.full From des at des.no Sat Oct 25 11:39:33 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Oct 25 11:39:50 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 In-Reply-To: <20081025021707.6B7031B5078@freebsd-stable.sentex.ca> (FreeBSD Tinderbox's message of "Fri, 24 Oct 2008 22:17:07 -0400 (EDT)") References: <20081025021707.6B7031B5078@freebsd-stable.sentex.ca> Message-ID: <86prlodimc.fsf@ds4.des.no> Sorry about that. I got a little carried away; 6.4 has already been branched, but 7.1 hasn't. DES -- Dag-Erling Sm?rgrav - des@des.no From bugmaster at FreeBSD.org Mon Oct 27 11:07:08 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 27 11:21:18 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200810271107.m9RB77Zr001854@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/128236 amd64 portsdb -Uu Indexing error f kern/128102 amd64 AsusRock 939N68PV-GLAN not recognized o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on f amd64/116457 amd64 [install] can't install freebsd on dv9420us o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv f amd64/103259 amd64 [ar] Cannot use ataraid on nvidia nForce4+amd64 o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock called (by ata o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 81 problems total. From tinderbox at freebsd.org Mon Oct 27 11:27:27 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 27 11:27:35 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 Message-ID: <20081025021707.6B7031B5078@freebsd-stable.sentex.ca> TB --- 2008-10-25 02:16:59 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-10-25 02:16:59 - starting RELENG_7_1 tinderbox run for amd64/amd64 TB --- 2008-10-25 02:16:59 - cleaning the object tree TB --- 2008-10-25 02:16:59 - cvsupping the source tree TB --- 2008-10-25 02:16:59 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_1/amd64/amd64/supfile TB --- 2008-10-25 02:17:07 - building world (CFLAGS=-O2 -pipe) TB --- 2008-10-25 02:17:07 - cd /src TB --- 2008-10-25 02:17:07 - ERROR: /src: No such file or directory TB --- 2008-10-25 02:17:07 - tinderbox aborted TB --- 1.40 user 0.09 system 7.36 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_1-amd64-amd64.full _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From des at des.no Mon Oct 27 11:38:44 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 27 11:38:56 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 In-Reply-To: <20081025021707.6B7031B5078@freebsd-stable.sentex.ca> (FreeBSD Tinderbox's message of "Fri, 24 Oct 2008 22:17:07 -0400 (EDT)") References: <20081025021707.6B7031B5078@freebsd-stable.sentex.ca> Message-ID: <86prlodimc.fsf@ds4.des.no> Sorry about that. I got a little carried away; 6.4 has already been branched, but 7.1 hasn't. DES -- Dag-Erling Sm?rgrav - des@des.no _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From tinderbox at freebsd.org Mon Oct 27 12:03:13 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 27 12:03:52 2008 Subject: [releng_7_1 tinderbox] failure on amd64/amd64 Message-ID: <20081024135714.879FB1B5078@freebsd-stable.sentex.ca> TB --- 2008-10-24 13:57:07 - tinderbox 2.4 running on freebsd-stable.sentex.ca TB --- 2008-10-24 13:57:07 - starting RELENG_7_1 tinderbox run for amd64/amd64 TB --- 2008-10-24 13:57:07 - cleaning the object tree TB --- 2008-10-24 13:57:07 - cvsupping the source tree TB --- 2008-10-24 13:57:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_1/amd64/amd64/supfile TB --- 2008-10-24 13:57:14 - building world (CFLAGS=-O2 -pipe) TB --- 2008-10-24 13:57:14 - cd /src TB --- 2008-10-24 13:57:14 - ERROR: /src: No such file or directory TB --- 2008-10-24 13:57:14 - tinderbox aborted TB --- 1.31 user 0.17 system 6.84 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_1-amd64-amd64.full _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From tinderbox at freebsd.org Mon Oct 27 15:56:17 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 27 15:56:24 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081027155614.47F6373039@freebsd-current.sentex.ca> TB --- 2008-10-27 14:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-27 14:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-27 14:00:00 - cleaning the object tree TB --- 2008-10-27 14:00:54 - cvsupping the source tree TB --- 2008-10-27 14:00:54 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-27 14:01:01 - building world (CFLAGS=-O -pipe) TB --- 2008-10-27 14:01:01 - cd /src TB --- 2008-10-27 14:01:01 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 27 14:01:03 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Oct 27 15:45:28 UTC 2008 TB --- 2008-10-27 15:45:28 - generating LINT kernel config TB --- 2008-10-27 15:45:28 - cd /src/sys/amd64/conf TB --- 2008-10-27 15:45:28 - /usr/bin/make -B LINT TB --- 2008-10-27 15:45:28 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-27 15:45:28 - cd /src TB --- 2008-10-27 15:45:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 27 15:45:28 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 [...] mac_bsdextended.o(.data+0xac8): undefined reference to `ugidfw_check_setacl_vnode' mac_bsdextended.o(.data+0xad0): undefined reference to `ugidfw_vnode_check_setextattr' mac_bsdextended.o(.data+0xad8): undefined reference to `ugidfw_vnode_check_setflags' mac_bsdextended.o(.data+0xae0): undefined reference to `ugidfw_vnode_check_setmode' mac_bsdextended.o(.data+0xae8): undefined reference to `ugidfw_vnode_check_setowner' mac_bsdextended.o(.data+0xaf0): undefined reference to `ugidfw_vnode_check_setutimes' mac_bsdextended.o(.data+0xaf8): undefined reference to `ugidfw_vnode_check_stat' mac_bsdextended.o(.data+0xb00): undefined reference to `ugidfw_vnode_check_unlink' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-27 15:56:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-27 15:56:13 - ERROR: failed to build lint kernel TB --- 2008-10-27 15:56:13 - tinderbox aborted TB --- 4941.04 user 631.81 system 6973.65 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Tue Oct 28 04:53:55 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 28 04:54:06 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081028045351.1A7F173039@freebsd-current.sentex.ca> TB --- 2008-10-28 03:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-28 03:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-28 03:00:00 - cleaning the object tree TB --- 2008-10-28 03:00:56 - cvsupping the source tree TB --- 2008-10-28 03:00:56 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-28 03:01:02 - building world (CFLAGS=-O -pipe) TB --- 2008-10-28 03:01:02 - cd /src TB --- 2008-10-28 03:01:02 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 28 03:01:04 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Oct 28 04:46:05 UTC 2008 TB --- 2008-10-28 04:46:05 - generating LINT kernel config TB --- 2008-10-28 04:46:05 - cd /src/sys/amd64/conf TB --- 2008-10-28 04:46:05 - /usr/bin/make -B LINT TB --- 2008-10-28 04:46:05 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-28 04:46:05 - cd /src TB --- 2008-10-28 04:46:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 28 04:46:06 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 [...] /src/sys/dev/usb/u3g.c:495: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:502: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:509: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:457: warning: unused variable 'self' /src/sys/dev/usb/u3g.c: In function 'u3gstub_attach': /src/sys/dev/usb/u3g.c:587: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:591: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:595: error: 'struct u3gstub_softc' has no member named 'dev' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-28 04:53:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-28 04:53:50 - ERROR: failed to build lint kernel TB --- 2008-10-28 04:53:50 - tinderbox aborted TB --- 4800.39 user 618.59 system 6830.15 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Tue Oct 28 10:53:32 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 28 10:53:38 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20081028105324.2D46F73039@freebsd-current.sentex.ca> TB --- 2008-10-28 09:00:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-10-28 09:00:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-10-28 09:00:01 - cleaning the object tree TB --- 2008-10-28 09:00:45 - cvsupping the source tree TB --- 2008-10-28 09:00:45 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-10-28 09:00:51 - building world (CFLAGS=-O -pipe) TB --- 2008-10-28 09:00:51 - cd /src TB --- 2008-10-28 09:00:51 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 28 09:00:53 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Oct 28 10:45:45 UTC 2008 TB --- 2008-10-28 10:45:45 - generating LINT kernel config TB --- 2008-10-28 10:45:45 - cd /src/sys/amd64/conf TB --- 2008-10-28 10:45:45 - /usr/bin/make -B LINT TB --- 2008-10-28 10:45:45 - building LINT kernel (COPTFLAGS=) TB --- 2008-10-28 10:45:45 - cd /src TB --- 2008-10-28 10:45:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Oct 28 10:45:45 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 [...] /src/sys/dev/usb/u3g.c:495: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:502: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:509: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:457: warning: unused variable 'self' /src/sys/dev/usb/u3g.c: In function 'u3gstub_attach': /src/sys/dev/usb/u3g.c:587: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:591: error: 'struct u3gstub_softc' has no member named 'dev' /src/sys/dev/usb/u3g.c:595: error: 'struct u3gstub_softc' has no member named 'dev' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-10-28 10:53:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-10-28 10:53:23 - ERROR: failed to build lint kernel TB --- 2008-10-28 10:53:23 - tinderbox aborted TB --- 4804.03 user 610.58 system 6802.67 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From spry at anarchy.in.the.ph Fri Oct 31 05:30:06 2008 From: spry at anarchy.in.the.ph (Mars G Miro) Date: Fri Oct 31 05:49:04 2008 Subject: amd64/128263: [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 and 16gb ram, crash and dump mem Message-ID: <200810311230.m9VCU5XF042556@freefall.freebsd.org> The following reply was made to PR amd64/128263; it has been noted by GNATS. From: "Mars G Miro" To: bug-followup@freebsd.org, martin.wikesjo@cypoint.se Cc: Subject: Re: amd64/128263: [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 and 16gb ram, crash and dump mem Date: Fri, 31 Oct 2008 20:01:04 +0800 Hiya I have a 2 CPU Quad-Core Xeon HP DL380 w/ 8Gb of RAM: http://pastebin.com/f4a00a1f5 I've installed 7.0R, then built the world to 7.0Rp5, and now 7.1-PRERELEASE. It is one of the fastest boxens I've held my hands on, can build the world in just: 2772.643u 1392.701s 13:23.41 518.4% 6056+1294k 4423+8405io 2295pf+0w No problems whatsoever, it might be a component of your system? -- cheers mars