From bugmaster at FreeBSD.org Mon Sep 1 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Tue Sep 2 02:34:16 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200809011106.m81B6pSi068359@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/76136 amd64 [hang] system halts before reboot o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87977 amd64 [busdma] [panic] amd64 busdma dflt_lock called (by ata o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 f amd64/91492 amd64 [boot] BTX halted o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled f amd64/105514 amd64 [boot] [btx] FreeBSD/amd64 - Fails to boot on HP Pavil f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work a amd64/109584 amd64 zdump(8) doesn't work o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/116159 amd64 [panic] Panic while debugging on CURRENT o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa 52 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV f amd64/103259 amd64 [ar] Cannot use ataraid on nvidia nForce4+amd64 o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect f amd64/116457 amd64 [install] can't install freebsd on dv9420us f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for s amd64/116689 amd64 [request] support for MSI K9MM-V a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/125820 amd64 [k8temp] [patch] sysctl dev.k8temp.*.sensor1.* are inv f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd 18 problems total. From figyshki at gmail.com Fri Sep 5 03:00:12 2008 From: figyshki at gmail.com (Pavel) Date: Fri Sep 5 03:15:14 2008 Subject: amd64/127102: Intel 3945ABG (wpi) low throughput Message-ID: <200809050255.m852tPbM010516@www.freebsd.org> >Number: 127102 >Category: amd64 >Synopsis: Intel 3945ABG (wpi) low throughput >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: Fri Sep 05 03:00:11 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Pavel >Release: 7.1-PRERELEASE (RELENG_7) >Organization: >Environment: FreeBSD lapa-tyapa.domain 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Thu Sep 4 22:02:10 EDT 2008 root@lapa-tyapa.domain:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Environment: Hardware: Clevo M570TU, integrated WiFi CVSup'ed 03 Sept 2008 against RELENG_7 branch. Same behavior seen in 7-STABLE. Cablevision's cable modem to PFsense 1.2-RELEASE access point. WPA-PSK in use. 30-char WPA passphrase. /etc/wpa_supplicant.conf (sanitized): ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 ap_scan=1 fast_reauth=1 eapol_version=1 # # WPA2 auth for here. # network={ ssid="Moria" scan_ssid=1 proto=WPA2 key_mgmt=WPA-PSK psk= } wpi0: flags=8843 metric 0 mtu 1500 ether 00:1c:bf:6c:39:f5 inet 10.0.0.21 netmask 0xffffff00 broadcast 10.0.0.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid Moria channel 36 (5180 Mhz 11a) bssid 00:02:6f:4b:c6:ec authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 7 scanvalid 60 roaming MANUAL /etc/rc.conf has: 'fconfig_wpi0="WPA DHCP"' Transfers crawl at speeds measured in bps, ~900 bps. >How-To-Repeat: Uncertain. Above-listed environment seems to do it, though. >Fix: Patch attached with submission follows: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Thu Sep 4 22:02:10 EDT 2008 root@lapa-tyapa.domain:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fa Stepping = 10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2132475904 (2033 MB) avail memory = 2057699328 (1962 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x207f mem 0xce000000-0xceffffff,0xd0000000-0xdfffffff,0xcc000000-0xcdffffff irq 16 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf0f04000-0xf0f043ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered ugen0: on uhub2 pcm0: mem 0xf0f00000-0xf0f03fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci4: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci6: on pcib4 wpi0: mem 0xf0800000-0xf0800fff irq 18 at device 0.0 on pci6 wpi0: Ethernet address: 00:1c:bf:6c:39:f5 wpi0: [ITHREAD] pcib5: irq 19 at device 28.3 on pci0 pci8: on pcib5 re0: port 0x5000-0x50ff mem 0xf0a00000-0xf0a00fff irq 19 at device 0.0 on pci8 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:90:f5:66:db:70 re0: [FILTER] pcib6: irq 17 at device 28.4 on pci0 pci10: on pcib6 pcib7: irq 16 at device 28.5 on pci0 pci11: on pcib7 uhci2: port 0x1840-0x185f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x1880-0x189f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xf0f04400-0xf0f047ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib8: at device 30.0 on pci0 pci12: on pcib8 pci12: at device 7.0 (no driver attached) pci12: at device 7.1 (no driver attached) pci12: at device 7.3 (no driver attached) fwohci0: port 0x6000-0x607f mem 0xf0c00000-0xf0c007ff irq 19 at device 9.0 on pci12 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:06:66:00:00:00:2d fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x112c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:06:00:00:2d fwe0: Ethernet address: 02:11:06:00:00:2d fwip0: on firewire0 fwip0: Firewire address: 00:11:06:66:00:00:00:2d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18e0-0x18ef,0x18d0-0x18df at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 battery0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: port 0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A sio1: [FILTER] orm0: at iomem 0xce000-0xcefff,0xe0000-0xe17ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen1: on uhub1 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 114473MB at ata0-master SATA150 GEOM_LABEL: Label for provider ad0s1 is msdosfs/grub. acd0: DVDR at ata1-master UDMA33 pcm0: pcm0: GEOM_LABEL: Label for provider ad0s5 is ntfs/XP_DATA. GEOM_LABEL: Label for provider ad0s6 is msdosfs/Shared_Data. GEOM_LABEL: Label for provider acd0 is iso9660/GTA_SAN_ANDREAS. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s3a GEOM_LABEL: Label msdosfs/grub removed. GEOM_LABEL: Label msdosfs/Shared_Data removed. wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 wpi0: fatal firmware error wpi0: timeout resetting Rx ring fire_saver: the console does not support M_VGA_CG320 module_register_init: MOD_LOAD (fire_saver, 0xffffffffae7cd000, 0) error 19 **************************** pfsense's dmesg: $ dmesg Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE-p11 #0: Sun Feb 24 17:36:53 EST 2008 sullrich@builder6.pfsense.com:/usr/obj.pfSense/usr/src/sys/pfSense_wrap.6 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 268435456 (256 MB) avail memory = 253272064 (241 MB) pnpbios: Bad PnP BIOS data checksum wlan: mac acl policy registered K6-family MTRR support enabled (2 registers) ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 MFGPT bar: f00100006200 pci0: at device 1.2 (no driver attached) vr0: port 0x1000-0x10ff mem 0xe0000000-0xe00000ff irq 10 at device 9.0 on pci0 miibus0: on vr0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0d:b9:13:ae:04 vr1: port 0x1400-0x14ff mem 0xe0040000-0xe00400ff irq 12 at device 11.0 on pci0 miibus1: on vr1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: Ethernet address: 00:0d:b9:13:ae:05 ath0: mem 0xe0080000-0xe008ffff irq 11 at device 14.0 on pci0 ath0: Ethernet address: 00:02:6f:4b:c6:ec ath0: mac 10.4 phy 6.1 radio 6.3 isab0: port 0x6000-0x6007,0x6100-0x61ff,0x6200-0x623f,0x9d00-0x9d7f,0x9c00-0x9c3f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 15.2 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xefffe000-0xefffefff irq 15 at device 15.4 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ehci0: mem 0xefffd000-0xefffdfff irq 15 at device 15.5 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: AMD EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered orm0: at iomem 0xe0000-0xea7ff on isa0 ppc0: parallel port not found. sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 sio0: type 16550A, console sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled RTC BIOS diagnostic error 80 Timecounter "TSC" frequency 498052719 Hz quality 800 Timecounters tick every 10.000 msec Fast IPsec: Initialized Security Association Processing. ad0: 1953MB at ata0-master PIO4 GEOM_LABEL: Label for provider ad0a is ufs/pfSense. GEOM_LABEL: Label for provider ad0d is ufs/pfSenseCfg. Trying to mount root from ufs:/dev/ufs/pfSense >Release-Note: >Audit-Trail: >Unformatted: From linimon at FreeBSD.org Fri Sep 5 03:16:48 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Sep 5 10:59:57 2008 Subject: kern/127102: [wpi] Intel 3945ABG low throughput Message-ID: <200809050316.m853GmOf087287@freefall.freebsd.org> Old Synopsis: Intel 3945ABG (wpi) low throughput New Synopsis: [wpi] Intel 3945ABG low throughput Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Sep 5 03:16:19 UTC 2008 Responsible-Changed-Why: Probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=127102 From hakcenter at gmail.com Sat Sep 6 01:10:01 2008 From: hakcenter at gmail.com (Curtis Hacker) Date: Sat Sep 6 01:12:09 2008 Subject: amd64/127129: mdconfig is core dumping with Segmentation Fault 11 Message-ID: <200809060106.m8616VKl053605@www.freebsd.org> >Number: 127129 >Category: amd64 >Synopsis: mdconfig is core dumping with Segmentation Fault 11 >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Sep 06 01:10:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Curtis Hacker >Release: 7.1 pre-release >Organization: >Environment: FreeBSD hcc-fs.hcc-experts.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #15: Wed Sep 3 17:21:12 PDT 2008 root@hcc-fs.hcc-experts.com:/usr/obj/usr/src/sys/CUSTOM amd64 >Description: I can't get mdconfig to do anything on my amd64 box. I have an identical machine on i386 running off a vmware machine, same exact kernel specs / makefile, and no problems on mdconfig. Decided to cvsup from the stable file provided in the /usr/share/examples/cvsup/stable-supfile, rebuilt world, and now issues with mdconfig. >How-To-Repeat: >Fix: run anything but amd64,:( >Release-Note: >Audit-Trail: >Unformatted: From bugmaster at FreeBSD.org Mon Sep 8 02:22:17 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 8 04:03:04 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200809080222.m882MGat006606@freefall.freebsd.org> 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/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 a amd64/109584 amd64 zdump(8) doesn't work 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] [btx] FreeBSD/amd64 - Fails to boot on HP Pavil 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 72 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. From tinderbox at freebsd.org Mon Sep 8 14:08:32 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 8 14:08:39 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20080908140825.1B5EF73039@freebsd-current.sentex.ca> TB --- 2008-09-08 12:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-08 12:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-09-08 12:20:00 - cleaning the object tree TB --- 2008-09-08 12:20:51 - cvsupping the source tree TB --- 2008-09-08 12:20:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-09-08 12:20:57 - building world (CFLAGS=-O -pipe) TB --- 2008-09-08 12:20:57 - cd /src TB --- 2008-09-08 12:20:57 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 8 12:21:00 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Sep 8 14:05:49 UTC 2008 TB --- 2008-09-08 14:05:49 - generating LINT kernel config TB --- 2008-09-08 14:05:49 - cd /src/sys/amd64/conf TB --- 2008-09-08 14:05:49 - /usr/bin/make -B LINT TB --- 2008-09-08 14:05:50 - building LINT kernel (COPTFLAGS=) TB --- 2008-09-08 14:05:50 - cd /src TB --- 2008-09-08 14:05:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 8 14:05: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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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 -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -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-prote ctor /src/sys/dev/iicbus/ds133x.c:48:26: error: machine/intr.h: No such file or directory /src/sys/dev/iicbus/ds1672.c:45:26: error: machine/intr.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-08 14:08:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-08 14:08:24 - ERROR: failed to build lint kernel TB --- 2008-09-08 14:08:24 - tinderbox aborted TB --- 4576.30 user 581.12 system 6504.46 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From kamikaze at bsdforen.de Wed Sep 10 17:40:03 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Wed Sep 10 17:42:15 2008 Subject: amd64/127275: ldd produces uncatchable output Message-ID: <200809101737.m8AHbpRo052273@www.freebsd.org> >Number: 127275 >Category: amd64 >Synopsis: ldd produces uncatchable output >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: Wed Sep 10 17:40:03 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Dominic Fandrey >Release: RELENG_7 >Organization: private >Environment: FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug 29 23:22:22 CEST 2008 root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 >Description: Ldd produces the output 'ELF binary type "0" not known.' upon encountering binaries that are listed as 'Unix - System V' by readelf -e. >How-To-Repeat: tcsh: # ldd /usr/local/Adobe/Reader8/ENU/Adobe/HelpViewer/1.0/intellinux/bin/ahv-binary >& /dev/null sh: # ldd /usr/local/Adobe/Reader8/ENU/Adobe/HelpViewer/1.0/intellinux/bin/ahv-binary > /dev/null 2>&1 >Fix: >Release-Note: >Audit-Trail: >Unformatted: From kamikaze at bsdforen.de Wed Sep 10 17:50:02 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Wed Sep 10 20:04:55 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809101744.m8AHiaQq053643@www.freebsd.org> >Number: 127276 >Category: amd64 >Synopsis: ldd invokes linux yes >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Dominic Fandrey >Release: RELENG_7 >Organization: private >Environment: FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug 29 23:22:22 CEST 2008 root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 >Description: When ldd is used on linux yes it invokes it instead of producing the usual output. # pkg_info -W /compat/linux/usr/bin/yes /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 # sysctl compat.linux.osrelease compat.linux.osrelease: 2.6.16 This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. >How-To-Repeat: # ldd /compat/linux/usr/bin/yes >Fix: >Release-Note: >Audit-Trail: >Unformatted: From jhb at FreeBSD.org Wed Sep 10 20:13:58 2008 From: jhb at FreeBSD.org (John Baldwin) Date: Wed Sep 10 20:14:04 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <200809101744.m8AHiaQq053643@www.freebsd.org> References: <200809101744.m8AHiaQq053643@www.freebsd.org> Message-ID: <200809101610.13951.jhb@freebsd.org> On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: > > >Number: 127276 > >Category: amd64 > >Synopsis: ldd invokes linux yes > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-amd64 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Dominic Fandrey > >Release: RELENG_7 > >Organization: > private > >Environment: > FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug 29 23:22:22 CEST 2008 root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 > >Description: > When ldd is used on linux yes it invokes it instead of producing the usual output. > > # pkg_info -W /compat/linux/usr/bin/yes > /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 > # sysctl compat.linux.osrelease > compat.linux.osrelease: 2.6.16 > > This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. > >How-To-Repeat: > # ldd /compat/linux/usr/bin/yes ldd is not going to work for Linux binaries. The Linux ldd should be used for Linux binaries. -- John Baldwin From jhb at FreeBSD.org Wed Sep 10 20:20:04 2008 From: jhb at FreeBSD.org (John Baldwin) Date: Wed Sep 10 20:20:09 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809102020.m8AKK3Xm068622@freefall.freebsd.org> The following reply was made to PR amd64/127276; it has been noted by GNATS. From: John Baldwin To: freebsd-amd64@FreeBSD.org Cc: Dominic Fandrey , freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/127276: ldd invokes linux yes Date: Wed, 10 Sep 2008 16:10:13 -0400 On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: > > >Number: 127276 > >Category: amd64 > >Synopsis: ldd invokes linux yes > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-amd64 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Dominic Fandrey > >Release: RELENG_7 > >Organization: > private > >Environment: > FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri Aug 29 23:22:22 CEST 2008 root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 > >Description: > When ldd is used on linux yes it invokes it instead of producing the usual output. > > # pkg_info -W /compat/linux/usr/bin/yes > /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 > # sysctl compat.linux.osrelease > compat.linux.osrelease: 2.6.16 > > This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. > >How-To-Repeat: > # ldd /compat/linux/usr/bin/yes ldd is not going to work for Linux binaries. The Linux ldd should be used for Linux binaries. -- John Baldwin From kamikaze at bsdforen.de Thu Sep 11 05:33:28 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Thu Sep 11 11:12:18 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <200809101610.13951.jhb@freebsd.org> References: <200809101744.m8AHiaQq053643@www.freebsd.org> <200809101610.13951.jhb@freebsd.org> Message-ID: <48C8A615.7070800@bsdforen.de> John Baldwin wrote: > On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: >>> Number: 127276 >>> Category: amd64 >>> Synopsis: ldd invokes linux yes >>> Confidential: no >>> Severity: serious >>> Priority: medium >>> Responsible: freebsd-amd64 >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 >>> Closed-Date: >>> Last-Modified: >>> Originator: Dominic Fandrey >>> Release: RELENG_7 >>> Organization: >> private >>> Environment: >> FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri > Aug 29 23:22:22 CEST 2008 > root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 >>> Description: >> When ldd is used on linux yes it invokes it instead of producing the usual > output. >> # pkg_info -W /compat/linux/usr/bin/yes >> /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 >> # sysctl compat.linux.osrelease >> compat.linux.osrelease: 2.6.16 >> >> This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. >>> How-To-Repeat: >> # ldd /compat/linux/usr/bin/yes > > ldd is not going to work for Linux binaries. The Linux ldd should be used for > Linux binaries. > I don't need it to work, I just need it not to invoke linux binaries. I'm using ldd in a script and by ldd not returning 0 the script should know that it hasn't encountered a valid binary. Instead ldd opens a linux binary like yes and the script spills out ys (yes) or waits for input from stdin (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. From kamikaze at bsdforen.de Thu Sep 11 05:40:04 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Thu Sep 11 11:20:05 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809110540.m8B5e4gN024965@freefall.freebsd.org> The following reply was made to PR amd64/127276; it has been noted by GNATS. From: Dominic Fandrey To: John Baldwin Cc: freebsd-amd64@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: amd64/127276: ldd invokes linux yes Date: Thu, 11 Sep 2008 07:01:09 +0200 John Baldwin wrote: > On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: >>> Number: 127276 >>> Category: amd64 >>> Synopsis: ldd invokes linux yes >>> Confidential: no >>> Severity: serious >>> Priority: medium >>> Responsible: freebsd-amd64 >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 >>> Closed-Date: >>> Last-Modified: >>> Originator: Dominic Fandrey >>> Release: RELENG_7 >>> Organization: >> private >>> Environment: >> FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri > Aug 29 23:22:22 CEST 2008 > root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 >>> Description: >> When ldd is used on linux yes it invokes it instead of producing the usual > output. >> # pkg_info -W /compat/linux/usr/bin/yes >> /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 >> # sysctl compat.linux.osrelease >> compat.linux.osrelease: 2.6.16 >> >> This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. >>> How-To-Repeat: >> # ldd /compat/linux/usr/bin/yes > > ldd is not going to work for Linux binaries. The Linux ldd should be used for > Linux binaries. > I don't need it to work, I just need it not to invoke linux binaries. I'm using ldd in a script and by ldd not returning 0 the script should know that it hasn't encountered a valid binary. Instead ldd opens a linux binary like yes and the script spills out ys (yes) or waits for input from stdin (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. From rpaulo at FreeBSD.org Thu Sep 11 12:41:41 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Sep 11 12:41:48 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <48C8A615.7070800@bsdforen.de> References: <200809101744.m8AHiaQq053643@www.freebsd.org> <200809101610.13951.jhb@freebsd.org> <48C8A615.7070800@bsdforen.de> Message-ID: <20080911121058.GA69162@alpha.local> On Thu, Sep 11, 2008 at 07:01:09AM +0200, Dominic Fandrey wrote: > I don't need it to work, I just need it not to invoke linux binaries. I'm > using ldd in a script and by ldd not returning 0 the script should know that > it hasn't encountered a valid binary. Instead ldd opens a linux binary like > yes and the script spills out ys (yes) or waits for input from stdin > (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. I chatted briefly with John about this. The way our ldd works is by setting the environment variable TRACE_LOADED_OBJECTS and after some dlopen() magic it exec()'s the binary. FreeBSD rtld detects the environmental variable, prints the list of shared objects and quits. Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will just run the Linux binary (Linux rtld will ignore the rest). Also, ldd wil return 1 on static binaries. Your best bet is to use file(1) to detect FreeBSD binaries. Something like `file $binary | grep FreeBSD-style` does the trick. Regards, -- Rui Paulo From rpaulo at FreeBSD.org Thu Sep 11 12:50:03 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Sep 11 12:50:10 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809111250.m8BCo3Vu090473@freefall.freebsd.org> The following reply was made to PR amd64/127276; it has been noted by GNATS. From: Rui Paulo To: Dominic Fandrey Cc: John Baldwin , freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/127276: ldd invokes linux yes Date: Thu, 11 Sep 2008 13:10:58 +0100 On Thu, Sep 11, 2008 at 07:01:09AM +0200, Dominic Fandrey wrote: > I don't need it to work, I just need it not to invoke linux binaries. I'm > using ldd in a script and by ldd not returning 0 the script should know that > it hasn't encountered a valid binary. Instead ldd opens a linux binary like > yes and the script spills out ys (yes) or waits for input from stdin > (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. I chatted briefly with John about this. The way our ldd works is by setting the environment variable TRACE_LOADED_OBJECTS and after some dlopen() magic it exec()'s the binary. FreeBSD rtld detects the environmental variable, prints the list of shared objects and quits. Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will just run the Linux binary (Linux rtld will ignore the rest). Also, ldd wil return 1 on static binaries. Your best bet is to use file(1) to detect FreeBSD binaries. Something like `file $binary | grep FreeBSD-style` does the trick. Regards, -- Rui Paulo From kamikaze at bsdforen.de Thu Sep 11 16:38:20 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Thu Sep 11 17:29:40 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <20080911121058.GA69162@alpha.local> References: <200809101744.m8AHiaQq053643@www.freebsd.org> <200809101610.13951.jhb@freebsd.org> <48C8A615.7070800@bsdforen.de> <20080911121058.GA69162@alpha.local> Message-ID: <48C94943.7010802@bsdforen.de> Rui Paulo wrote: > On Thu, Sep 11, 2008 at 07:01:09AM +0200, Dominic Fandrey wrote: >> I don't need it to work, I just need it not to invoke linux binaries. I'm >> using ldd in a script and by ldd not returning 0 the script should know that >> it hasn't encountered a valid binary. Instead ldd opens a linux binary like >> yes and the script spills out ys (yes) or waits for input from stdin >> (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. > > I chatted briefly with John about this. The way our ldd works is by > setting the environment variable TRACE_LOADED_OBJECTS and after some > dlopen() magic it exec()'s the binary. FreeBSD rtld detects the environmental > variable, prints the list of shared objects and quits. > > Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will > just run the Linux binary (Linux rtld will ignore the rest). > > Also, ldd wil return 1 on static binaries. Your best bet is to use > file(1) to detect FreeBSD binaries. Something like `file $binary | grep > FreeBSD-style` does the trick. > > Regards, Ok, thanks. I have already created a workaround with readelf, but I'd still consider this a bug in ldd. Shouldn't it check the elf brand if it only works for a single one? Regards From kamikaze at bsdforen.de Thu Sep 11 16:40:04 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Thu Sep 11 17:29:45 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809111640.m8BGe4PX012172@freefall.freebsd.org> The following reply was made to PR amd64/127276; it has been noted by GNATS. From: Dominic Fandrey To: Rui Paulo Cc: John Baldwin , freebsd-gnats-submit@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/127276: ldd invokes linux yes Date: Thu, 11 Sep 2008 18:37:23 +0200 Rui Paulo wrote: > On Thu, Sep 11, 2008 at 07:01:09AM +0200, Dominic Fandrey wrote: >> I don't need it to work, I just need it not to invoke linux binaries. I'm >> using ldd in a script and by ldd not returning 0 the script should know that >> it hasn't encountered a valid binary. Instead ldd opens a linux binary like >> yes and the script spills out ys (yes) or waits for input from stdin >> (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. > > I chatted briefly with John about this. The way our ldd works is by > setting the environment variable TRACE_LOADED_OBJECTS and after some > dlopen() magic it exec()'s the binary. FreeBSD rtld detects the environmental > variable, prints the list of shared objects and quits. > > Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will > just run the Linux binary (Linux rtld will ignore the rest). > > Also, ldd wil return 1 on static binaries. Your best bet is to use > file(1) to detect FreeBSD binaries. Something like `file $binary | grep > FreeBSD-style` does the trick. > > Regards, Ok, thanks. I have already created a workaround with readelf, but I'd still consider this a bug in ldd. Shouldn't it check the elf brand if it only works for a single one? Regards From jhb at freebsd.org Thu Sep 11 17:57:03 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 11 17:57:10 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <48C8A615.7070800@bsdforen.de> References: <200809101744.m8AHiaQq053643@www.freebsd.org> <200809101610.13951.jhb@freebsd.org> <48C8A615.7070800@bsdforen.de> Message-ID: <200809111038.32311.jhb@freebsd.org> On Thursday 11 September 2008 01:01:09 am Dominic Fandrey wrote: > John Baldwin wrote: > > On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: > >>> Number: 127276 > >>> Category: amd64 > >>> Synopsis: ldd invokes linux yes > >>> Confidential: no > >>> Severity: serious > >>> Priority: medium > >>> Responsible: freebsd-amd64 > >>> State: open > >>> Quarter: > >>> Keywords: > >>> Date-Required: > >>> Class: sw-bug > >>> Submitter-Id: current-users > >>> Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 > >>> Closed-Date: > >>> Last-Modified: > >>> Originator: Dominic Fandrey > >>> Release: RELENG_7 > >>> Organization: > >> private > >>> Environment: > >> FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri > > Aug 29 23:22:22 CEST 2008 > > root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 > >>> Description: > >> When ldd is used on linux yes it invokes it instead of producing the usual > > output. > >> # pkg_info -W /compat/linux/usr/bin/yes > >> /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 > >> # sysctl compat.linux.osrelease > >> compat.linux.osrelease: 2.6.16 > >> > >> This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. > >>> How-To-Repeat: > >> # ldd /compat/linux/usr/bin/yes > > > > ldd is not going to work for Linux binaries. The Linux ldd should be used for > > Linux binaries. > > > > I don't need it to work, I just need it not to invoke linux binaries. I'm > using ldd in a script and by ldd not returning 0 the script should know that > it hasn't encountered a valid binary. Instead ldd opens a linux binary like > yes and the script spills out ys (yes) or waits for input from stdin > (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. As Rui indicated, ldd always execs binaries. It just sets environment variables that the FreeBSD runtime linker checks for. If the runtime linker sees them, it will modify it's behavior. You can achieve the same thing using env: % ldd /bin/ls /bin/ls: libutil.so.7 => /lib/libutil.so.7 (0x2808b000) libncurses.so.7 => /lib/libncurses.so.7 (0x28099000) libc.so.7 => /lib/libc.so.7 (0x280d8000) % env LD_TRACE_LOADED_OBJECTS=yes /bin/ls libutil.so.7 => /lib/libutil.so.7 (0x2808b000) libncurses.so.7 => /lib/libncurses.so.7 (0x28099000) libc.so.7 => /lib/libc.so.7 (0x280d8000) All the "ldd" printfs, etc. are actually from the runtime linker, not ldd itself. The Linux runtime linker doesn't modify it's behavior for LD_TRACE_LOADED_OBJECTS, so Linux apps just run normally when invoked by ldd. -- John Baldwin From jhb at freebsd.org Thu Sep 11 18:00:15 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 11 18:00:22 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809111800.m8BI0FbU024143@freefall.freebsd.org> The following reply was made to PR amd64/127276; it has been noted by GNATS. From: John Baldwin To: Dominic Fandrey Cc: freebsd-amd64@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: amd64/127276: ldd invokes linux yes Date: Thu, 11 Sep 2008 10:38:32 -0400 On Thursday 11 September 2008 01:01:09 am Dominic Fandrey wrote: > John Baldwin wrote: > > On Wednesday 10 September 2008 01:44:36 pm Dominic Fandrey wrote: > >>> Number: 127276 > >>> Category: amd64 > >>> Synopsis: ldd invokes linux yes > >>> Confidential: no > >>> Severity: serious > >>> Priority: medium > >>> Responsible: freebsd-amd64 > >>> State: open > >>> Quarter: > >>> Keywords: > >>> Date-Required: > >>> Class: sw-bug > >>> Submitter-Id: current-users > >>> Arrival-Date: Wed Sep 10 17:50:01 UTC 2008 > >>> Closed-Date: > >>> Last-Modified: > >>> Originator: Dominic Fandrey > >>> Release: RELENG_7 > >>> Organization: > >> private > >>> Environment: > >> FreeBSD mobileKamikaze.norad 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Fri > > Aug 29 23:22:22 CEST 2008 > > root@mobileKamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 > >>> Description: > >> When ldd is used on linux yes it invokes it instead of producing the usual > > output. > >> # pkg_info -W /compat/linux/usr/bin/yes > >> /compat/linux/usr/bin/yes was installed by package linux_base-f8-8_4 > >> # sysctl compat.linux.osrelease > >> compat.linux.osrelease: 2.6.16 > >> > >> This behaviour breaks pkg_libchk from the sysutils/bsdadminscripts port. > >>> How-To-Repeat: > >> # ldd /compat/linux/usr/bin/yes > > > > ldd is not going to work for Linux binaries. The Linux ldd should be used for > > Linux binaries. > > > > I don't need it to work, I just need it not to invoke linux binaries. I'm > using ldd in a script and by ldd not returning 0 the script should know that > it hasn't encountered a valid binary. Instead ldd opens a linux binary like > yes and the script spills out ys (yes) or waits for input from stdin > (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. As Rui indicated, ldd always execs binaries. It just sets environment variables that the FreeBSD runtime linker checks for. If the runtime linker sees them, it will modify it's behavior. You can achieve the same thing using env: % ldd /bin/ls /bin/ls: libutil.so.7 => /lib/libutil.so.7 (0x2808b000) libncurses.so.7 => /lib/libncurses.so.7 (0x28099000) libc.so.7 => /lib/libc.so.7 (0x280d8000) % env LD_TRACE_LOADED_OBJECTS=yes /bin/ls libutil.so.7 => /lib/libutil.so.7 (0x2808b000) libncurses.so.7 => /lib/libncurses.so.7 (0x28099000) libc.so.7 => /lib/libc.so.7 (0x280d8000) All the "ldd" printfs, etc. are actually from the runtime linker, not ldd itself. The Linux runtime linker doesn't modify it's behavior for LD_TRACE_LOADED_OBJECTS, so Linux apps just run normally when invoked by ldd. -- John Baldwin From jhb at freebsd.org Thu Sep 11 21:43:56 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 11 21:44:05 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <200809111640.m8BGe4PX012172@freefall.freebsd.org> References: <200809111640.m8BGe4PX012172@freefall.freebsd.org> Message-ID: <200809111637.54863.jhb@freebsd.org> On Thursday 11 September 2008 12:40:04 pm Dominic Fandrey wrote: > The following reply was made to PR amd64/127276; it has been noted by GNATS. > > From: Dominic Fandrey > To: Rui Paulo > Cc: John Baldwin , freebsd-gnats-submit@freebsd.org, > freebsd-amd64@freebsd.org > Subject: Re: amd64/127276: ldd invokes linux yes > Date: Thu, 11 Sep 2008 18:37:23 +0200 > > Rui Paulo wrote: > > On Thu, Sep 11, 2008 at 07:01:09AM +0200, Dominic Fandrey wrote: > >> I don't need it to work, I just need it not to invoke linux binaries. I'm > >> using ldd in a script and by ldd not returning 0 the script should know that > >> it hasn't encountered a valid binary. Instead ldd opens a linux binary like > >> yes and the script spills out ys (yes) or waits for input from stdin > >> (md5sum). I'm pretty certain ldd is in no way meant to invoke programs. > > > > I chatted briefly with John about this. The way our ldd works is by > > setting the environment variable TRACE_LOADED_OBJECTS and after some > > dlopen() magic it exec()'s the binary. FreeBSD rtld detects the environmental > > variable, prints the list of shared objects and quits. > > > > Linux rtld doesn't work this way, so FreeBSD ldd on a Linux binary will > > just run the Linux binary (Linux rtld will ignore the rest). > > > > Also, ldd wil return 1 on static binaries. Your best bet is to use > > file(1) to detect FreeBSD binaries. Something like `file $binary | grep > > FreeBSD-style` does the trick. > > > > Regards, > > Ok, thanks. I have already created a workaround with readelf, but I'd still > consider this a bug in ldd. Shouldn't it check the elf brand if it only > works for a single one? FreeBSD binaries from various releases have been branded in different ways. I would consider it more of a user error to run ldd on a Linux binary. :) You could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains how it works and why it will execute any binary using a different runtime linker. -- John Baldwin From linimon at lonesome.com Thu Sep 11 23:30:11 2008 From: linimon at lonesome.com (Mark Linimon) Date: Thu Sep 11 23:59:22 2008 Subject: amd64/127276: ldd invokes linux yes Message-ID: <200809112330.m8BNUA76059842@freefall.freebsd.org> The following reply was made to PR amd64/127276; it has been noted by GNATS. From: linimon@lonesome.com (Mark Linimon) To: bug-followup@FreeBSD.org Cc: Subject: Re: amd64/127276: ldd invokes linux yes Date: Thu, 11 Sep 2008 18:29:24 -0500 ----- Forwarded message from John Baldwin ----- FreeBSD binaries from various releases have been branded in different ways. I would consider it more of a user error to run ldd on a Linux binary. :) You could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains how it works and why it will execute any binary using a different runtime linker. -- John Baldwin ----- End forwarded message ----- From kamikaze at bsdforen.de Sun Sep 14 14:34:22 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Sep 14 14:53:06 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <200809111637.54863.jhb@freebsd.org> References: <200809111640.m8BGe4PX012172@freefall.freebsd.org> <200809111637.54863.jhb@freebsd.org> Message-ID: <48CD20CB.3040706@bsdforen.de> John Baldwin wrote: > FreeBSD binaries from various releases have been branded in different ways. I > would consider it more of a user error to run ldd on a Linux binary. :) You > could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains > how it works and why it will execute any binary using a different runtime > linker. > Well, documenting it is much better than the current state. Though in my opinion it doesn't matter to the user how it works, but what one expects the program to do. And the current behaviour is not what I expected. Would you instead accept a patch from me that does a compatibility check and bails out if the binary does not use the FreeBSD linker? The "IMPLEMENTATION NOTES" would still be nice to have, though. It's always a nice read to get an idea on how something works. And I find code much easier to decipher if I already know how it's supposed to do something. At least much easier than the opposite way, trying to glimpse how something works from the code. Regards From freebsd at abv.bg Sun Sep 14 15:56:28 2008 From: freebsd at abv.bg (Mario Pavlov) Date: Sun Sep 14 15:56:36 2008 Subject: g_vfs_done() error = 6 Message-ID: <1947694103.82294.1221406829431.JavaMail.apache@mail51.abv.bg> Hi list, I was running my FreeBSD-amd64 7 stable for quite some time without any problems until suddenly it started to spit out those: ad10: detached g_vfs_done(): ad10s2a[READ(offset=412188672, length=16384)]error = 6 g_vfs_done(): ad10s2a[READ(offset=412188672, length=16384)]error = 6 vm_fault: pager read error, pid 698 (devd) g_vfs_done(): ad10s2a[READ(offset=98304, length=16384)]error = 6 g_vfs_done(): ad10s2a[READ(offset=578027520, length=16384)]error = 6 g_vfs_done(): ad10s2a[READ(offset=1348599808, length=16384)]error = 6 ... ... ... panic: vinvalbuf: dirty bufs cpuid = 0 KDB: enter: panic [thread pid 960 tid 100057] Stopped at kdb_enter+0x3d: movq $0,0x431b24(%rip) then I'm in the db> "prompt" and after a few minutes I get this: panic: knlist not locked, but should be cpuid = 0 Cannot dump, no dump device defined Automatic reboot in 15 seconds... what I want to find out is whether this is caused by hardware failure or it's software problem I upgraded to 8-CURRENT just to try if it will be the same and it is do you think this is hardware problem or not ? thank you Regards MGP From xxjack12xx at gmail.com Mon Sep 15 04:25:08 2008 From: xxjack12xx at gmail.com (Jack L.) Date: Mon Sep 15 04:25:15 2008 Subject: g_vfs_done() error = 6 In-Reply-To: <1947694103.82294.1221406829431.JavaMail.apache@mail51.abv.bg> References: <1947694103.82294.1221406829431.JavaMail.apache@mail51.abv.bg> Message-ID: On Sun, Sep 14, 2008 at 8:40 AM, Mario Pavlov wrote: > Hi list, > I was running my FreeBSD-amd64 7 stable for quite some time without any problems until suddenly it started to spit out those: > > ad10: detached > g_vfs_done(): ad10s2a[READ(offset=412188672, length=16384)]error = 6 > g_vfs_done(): ad10s2a[READ(offset=412188672, length=16384)]error = 6 > vm_fault: pager read error, pid 698 (devd) > g_vfs_done(): ad10s2a[READ(offset=98304, length=16384)]error = 6 > g_vfs_done(): ad10s2a[READ(offset=578027520, length=16384)]error = 6 > g_vfs_done(): ad10s2a[READ(offset=1348599808, length=16384)]error = 6 > ... > ... > ... > panic: vinvalbuf: dirty bufs > cpuid = 0 > KDB: enter: panic > [thread pid 960 tid 100057] > Stopped at kdb_enter+0x3d: movq $0,0x431b24(%rip) > > then I'm in the db> "prompt" > and after a few minutes I get this: > > panic: knlist not locked, but should be > cpuid = 0 > Cannot dump, no dump device defined > Automatic reboot in 15 seconds... > > what I want to find out is whether this is caused by hardware failure or it's software problem > I upgraded to 8-CURRENT just to try if it will be the same and it is > > do you think this is hardware problem or not ? > thank you > Sounds like a dead hard drive or a drive going bad. From freebsd at abv.bg Mon Sep 15 05:19:24 2008 From: freebsd at abv.bg (Mario Pavlov) Date: Mon Sep 15 05:19:30 2008 Subject: g_vfs_done() error = 6 Message-ID: <1616142420.85642.1221455962133.JavaMail.apache@mail52.abv.bg> >> Hi list, >> I was running my FreeBSD-amd64 7 stable for quite some time without any problems until suddenly it started to spit out those: >> >> ad10: detached >> g_vfs_done(): ad10s2a[READ(offset=412188672, length=16384)]error = 6 >> g_vfs_done(): ad10s2a[READ(offset=412188672, length=16384)]error = 6 >> vm_fault: pager read error, pid 698 (devd) >> g_vfs_done(): ad10s2a[READ(offset=98304, length=16384)]error = 6 >> g_vfs_done(): ad10s2a[READ(offset=578027520, length=16384)]error = 6 >> g_vfs_done(): ad10s2a[READ(offset=1348599808, length=16384)]error = 6 >> ... >> ... >> ... >> panic: vinvalbuf: dirty bufs >> cpuid = 0 >> KDB: enter: panic >> [thread pid 960 tid 100057] >> Stopped at kdb_enter+0x3d: movq $0,0x431b24(%rip) >> >> then I'm in the db> "prompt" >> and after a few minutes I get this: >> >> panic: knlist not locked, but should be >> cpuid = 0 >> Cannot dump, no dump device defined >> Automatic reboot in 15 seconds... >> >> what I want to find out is whether this is caused by hardware failure or it's software problem >> I upgraded to 8-CURRENT just to try if it will be the same and it is >> >> do you think this is hardware problem or not ? >> thank you >> >Sounds like a dead hard drive or a drive going bad. Hi I was thinking the same and I decided to try with another OS just in case I'm running windows xp for almost all day and it works...no HDD failure... my HDD is 500GB Seagate ST3500320AS SATA2 and I was running it in AHCI mode but I had to set it to IDE mode in order to run windows since windows can't run on AHCI so I'm a little bit confused...it works ok with windows and IDE but crashes on FreeBSD and AHCI... I'll stay with the windows several more hours and try FreeBSD and IDE thank you regards MGP From bugmaster at FreeBSD.org Mon Sep 15 15:18:44 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 15 15:35:57 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200809151518.m8FFIh1N018801@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/127276 amd64 ldd(1) invokes linux yes o amd64/127275 amd64 ldd(1) produces uncatchable output 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 a amd64/109584 amd64 zdump(8) doesn't work 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 74 problems total. From kamikaze at bsdforen.de Mon Sep 15 18:00:08 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Sep 15 18:03:56 2008 Subject: amd64/127275: ldd(1) produces uncatchable output Message-ID: <200809151800.m8FI08uS034678@freefall.freebsd.org> The following reply was made to PR amd64/127275; it has been noted by GNATS. From: Dominic Fandrey To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de Cc: Subject: Re: amd64/127275: ldd(1) produces uncatchable output Date: Mon, 15 Sep 2008 19:51:14 +0200 This can be closed, because what I thought were two distinct problems has turned out to have the same cause. So this can be considered a duplicate of amd64/127276. Ldd invokes the binary and in case of a nonsensical elf-brand the kernel (at least that is my suspect) posts a message on the terminal. The workaround is to only run ldd on FreeBSD binaries. The safe solution, would in my opinion, be a check weather the binary uses the FreeBSD linker, but this discussion can remain in amd64/127276. From jhb at freebsd.org Mon Sep 15 19:28:07 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 19:28:13 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <48CD20CB.3040706@bsdforen.de> References: <200809111640.m8BGe4PX012172@freefall.freebsd.org> <200809111637.54863.jhb@freebsd.org> <48CD20CB.3040706@bsdforen.de> Message-ID: <200809151047.12396.jhb@freebsd.org> On Sunday 14 September 2008 10:33:47 am Dominic Fandrey wrote: > John Baldwin wrote: > > FreeBSD binaries from various releases have been branded in different ways. I > > would consider it more of a user error to run ldd on a Linux binary. :) You > > could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains > > how it works and why it will execute any binary using a different runtime > > linker. > > > > Well, documenting it is much better than the current state. Though in my > opinion it doesn't matter to the user how it works, but what one expects the > program to do. And the current behaviour is not what I expected. > > Would you instead accept a patch from me that does a compatibility check and > bails out if the binary does not use the FreeBSD linker? It can be hard to determine that. What happens is that each ELF binary includes a path to its interpreter (i.e. the runtime linker). For FreeBSD binaries this can be either /usr/libexec/ld-elf.so.1 or /libexec/ld-elf.so.1 or the a.out paths (/usr/libexec/ld.so.1 I think). In the kernel, ABI modules hook into exec and when they see a binary they can handle, they can choose to overwrite the interpreter path to point it to somewhere else (e.g. the Linux ABI uses a path under /compat/linux instead, and the 'freebsd32' ABI on amd64 uses /libexec/ld-elf32.so.1). Any ELF binary that uses one of the two ld-elf.so.1 (or ld-elf32.so.1) paths will use the FreeBSD runtime linker, regardless of which "OS" the binary is targeted for. You could maybe hardcode the list of interpreter strings to check for, but that wouldn't be completely foolproof. You could have an ABI that is fine with using the FreeBSD linker even though its native "OS" uses a different interpreter path (though that is unlikely). In that case the kernel module would be rewriting the interpreter path to be the FreeBSD ld-elf, but ldd would have no clue. > The "IMPLEMENTATION NOTES" would still be nice to have, though. It's always > a nice read to get an idea on how something works. And I find code much > easier to decipher if I already know how it's supposed to do something. At > least much easier than the opposite way, trying to glimpse how something > works from the code. > > Regards > -- John Baldwin From kamikaze at bsdforen.de Mon Sep 15 19:52:36 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Sep 15 20:09:56 2008 Subject: amd64/127276: ldd invokes linux yes In-Reply-To: <200809151047.12396.jhb@freebsd.org> References: <200809111640.m8BGe4PX012172@freefall.freebsd.org> <200809111637.54863.jhb@freebsd.org> <48CD20CB.3040706@bsdforen.de> <200809151047.12396.jhb@freebsd.org> Message-ID: <48CEBCE4.5070204@bsdforen.de> John Baldwin wrote: > On Sunday 14 September 2008 10:33:47 am Dominic Fandrey wrote: >> John Baldwin wrote: >>> FreeBSD binaries from various releases have been branded in different > ways. I >>> would consider it more of a user error to run ldd on a Linux binary. :) > You >>> could maybe add a "IMPLEMENTATION NOTES" section to the manpage that > explains >>> how it works and why it will execute any binary using a different runtime >>> linker. >>> >> Well, documenting it is much better than the current state. Though in my >> opinion it doesn't matter to the user how it works, but what one expects the >> program to do. And the current behaviour is not what I expected. >> >> Would you instead accept a patch from me that does a compatibility check and >> bails out if the binary does not use the FreeBSD linker? > > It can be hard to determine that. What happens is that each ELF binary > includes a path to its interpreter (i.e. the runtime linker). For FreeBSD > binaries this can be either /usr/libexec/ld-elf.so.1 or /libexec/ld-elf.so.1 > or the a.out paths (/usr/libexec/ld.so.1 I think). In the kernel, ABI > modules hook into exec and when they see a binary they can handle, they can > choose to overwrite the interpreter path to point it to somewhere else (e.g. > the Linux ABI uses a path under /compat/linux instead, and the 'freebsd32' > ABI on amd64 uses /libexec/ld-elf32.so.1). Any ELF binary that uses one of > the two ld-elf.so.1 (or ld-elf32.so.1) paths will use the FreeBSD runtime > linker, regardless of which "OS" the binary is targeted for. You could maybe > hardcode the list of interpreter strings to check for, but that wouldn't be > completely foolproof. You could have an ABI that is fine with using the > FreeBSD linker even though its native "OS" uses a different interpreter path > (though that is unlikely). In that case the kernel module would be rewriting > the interpreter path to be the FreeBSD ld-elf, but ldd would have no clue. > I wanted to look into the file and readelf tools to check how they do it. I'm using readelf to avoid calling ldd when inappropriate and I think it's reliable, so there aught to be a way. I'm kinda stressed, but I'm going to look into it in a couple of weeks. If it doesn't pay off. Well, I'm all for the implementation notes. From linimon at FreeBSD.org Mon Sep 15 21:45:20 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 15 22:33:04 2008 Subject: amd64/127275: ldd(1) produces uncatchable output Message-ID: <200809152145.m8FLjKek078377@freefall.freebsd.org> Synopsis: ldd(1) produces uncatchable output State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Mon Sep 15 21:45:01 UTC 2008 State-Changed-Why: See amd64/127276. http://www.freebsd.org/cgi/query-pr.cgi?pr=127275 From linimon at FreeBSD.org Tue Sep 16 02:54:16 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 16 03:00:04 2008 Subject: amd64/127397: [amd64] 32bit application on FreeBSD-6.3 amd64 gets SIGBUS Message-ID: <200809160254.m8G2sGnk006774@freefall.freebsd.org> Old Synopsis: 32bit application on FreeBSD-6.3 amd64 gets SIGBUS New Synopsis: [amd64] 32bit application on FreeBSD-6.3 amd64 gets SIGBUS Responsible-Changed-From-To: freebsd-bugs->freebsd-amd64 Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 16 02:53:06 UTC 2008 Responsible-Changed-Why: With a little bit of hesitation, move this one over to the amd64 category, in hopes that it will be a little more high-profile there. http://www.freebsd.org/cgi/query-pr.cgi?pr=127397 From linimon at FreeBSD.org Tue Sep 16 02:56:38 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Sep 16 03:13:11 2008 Subject: amd64/127276: ldd(1) invokes linux yes Message-ID: <200809160256.m8G2ub2b006848@freefall.freebsd.org> Synopsis: ldd(1) invokes linux yes State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Tue Sep 16 02:55:49 UTC 2008 State-Changed-Why: As noted in the feedback trail, the fix is not as obvious as it first might appear. Mark this as 'suspended' for now to note that although we understand the problem, it is going to need more research. http://www.freebsd.org/cgi/query-pr.cgi?pr=127276 From scott.gasch at gmail.com Tue Sep 16 06:23:15 2008 From: scott.gasch at gmail.com (Scott Gasch) Date: Tue Sep 16 11:29:58 2008 Subject: irq19 interrupt storm? Message-ID: Hi, I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. Nearly 100% of 1 cpu is constantly being used handling irq19: uhci4 interrupts. This seems to happen both with and without any USB devices plugged in: vmstat -i interrupt total rate irq1: atkbd0 5 0 irq6: fdc0 1 0 irq17: mskc0 dc0 1180547 18 irq18: skc0 uhci2* 163250699 2512 irq19: uhci4++ 3187989508 49072 irq23: uhci3 ehci1 31 0 cpu0: timer 129208570 1988 cpu1: timer 129208457 1988 cpu2: timer 125750147 1935 cpu3: timer 125750122 1935 Total 3862338087 59452 dmesg uhci4: port 0xa400-0xa41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] The box runs my own kernel... but a very similar problem happens with GENERIC. The same irq (19) is firing too often and consuming nearly all of one core. But the driver that is associated with the interrupt is different -- it's fwohci0 this time: vmstat -i interrupt total rate irq6: fdc0 1 0 irq17: mskc0 dc0 313242 13 irq18: skc0 uhci2* 124475451 5540 irq19: fwohci0+++ 957875379 42638 irq23: uhci3 ehci1 1145 0 cpu0: timer 44458513 1979 cpu1: timer 44448875 1978 cpu3: timer 43393901 1931 cpu2: timer 43393921 1931 Total 1258360428 56014 This makes me start to wonder if this is not a problem with irq19 (the PIC?) and not one particular device / driver. I'm not sure how to make dig deeper here, any help greatly appreciated. I posted this to questions a while back and no one replied ;) Thx, Scott From gary.jennejohn at freenet.de Tue Sep 16 14:12:26 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Sep 16 14:12:59 2008 Subject: irq19 interrupt storm? In-Reply-To: References: Message-ID: <20080916161222.125d15f5@peedub.jennejohn.org> On Mon, 15 Sep 2008 22:57:38 -0700 "Scott Gasch" wrote: > Hi, > > I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. Nearly 100% of > 1 cpu is constantly being used handling irq19: uhci4 interrupts. This > seems to happen both with and without any USB devices plugged in: > > vmstat -i > interrupt total rate > irq1: atkbd0 5 0 > irq6: fdc0 1 0 > irq17: mskc0 dc0 1180547 18 > irq18: skc0 uhci2* 163250699 2512 > irq19: uhci4++ 3187989508 49072 I think the ++ here indicates that two or more devices are sharing this interrupt. Try doing "grep irq.*19 /var/run/dmesg.boot" to see which ones. One of these devices could be the culprit. --- Gary Jennejohn From pfgshield-freebsd at yahoo.com Tue Sep 16 15:04:41 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Tue Sep 16 16:16:31 2008 Subject: Why VESA and DPMS are available only for i386? In-Reply-To: <20080916074657.GF15376@server.vk2pj.dyndns.org> Message-ID: <790198.8149.qm@web32708.mail.mud.yahoo.com> (moved from -current to -amd64) --- Mar 16/9/08, Peter Jeremy ha scritto: ... > On 2008-Sep-15 13:43:31 -0700, Pedro Giffuni > wrote: > >I can't find any reference, but according to the > Wikipedia, even in long mode AMD64 is able to run 16-bit (or > 80286) protected mode applications: > > AMD64 Architecture Programmer's Manual, Volume 1: > Application > Programming - No. 24592 states: > "Compatibility mode - the second submode of long mode > - allows 64-bit > operating systems to run existing 16-bit and 32-bit x86 > applications. These legacy applications run in > compatibility mode > without recompilation." > Thanks! The precise link is here (sorry for the broken link): http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf in section 1.2.3. I guess having bios16() and bios32() would be useful for virtualized environments too. Pedro. __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From peterjeremy at optushome.com.au Tue Sep 16 17:39:25 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Sep 16 17:43:27 2008 Subject: amd64/127397: [amd64] 32bit application on FreeBSD-6.3 amd64 gets SIGBUS In-Reply-To: <200809160254.m8G2sGnk006774@freefall.freebsd.org> References: <200809160254.m8G2sGnk006774@freefall.freebsd.org> Message-ID: <20080916082039.GX15376@server.vk2pj.dyndns.org> I can't quickly reproduce this on a roughly week old 6.4-PRERELEASE with a Turion64x2, though that system has been up for nearly 4 days. What else, if anything, is running on the system when it fails or doesn't fail? Does running lots of (especially large) processes before running your test reduce the likelihood of the failure occurring? Off the top of my head this looks like a race condition in the code that migrates i386 processes between CPUs - possibly a missing or misplaced memory barrier. Actually tracking this down is likely to be difficult. -- 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/20080916/4d301e2b/attachment.pgp From artur at ebasoft.com.pl Tue Sep 16 23:05:04 2008 From: artur at ebasoft.com.pl (Artur Bac) Date: Tue Sep 16 23:40:03 2008 Subject: BSD7 MCP55 SATA AMD64 Data Corruption Message-ID: Hello since first prerelease of BSD7 i got on disks atached to MCP55 SATA controler data corruption. One thing that is strange is that this controller works ok with 6.3 but not with 7.0 PRE, 7.0 STAB. or 7.1 PRE I tryed both schedulers without success. I got AMD64 X2 6000+ 6GB RAM and ATA and SATA 150 and 300 discs. Can anyone help ? A. From edwin at freebsd.org Wed Sep 17 07:00:06 2008 From: edwin at freebsd.org (Edwin Groothuis) Date: Wed Sep 17 11:22:10 2008 Subject: amd64/109584: zdump(8) doesn't work Message-ID: <200809170700.m8H705Sk023583@freefall.freebsd.org> The following reply was made to PR amd64/109584; it has been noted by GNATS. From: Edwin Groothuis To: bug-followup@FreeBSD.org, dcrandall@simplestar.com Cc: Subject: Re: amd64/109584: zdump(8) doesn't work Date: Wed, 17 Sep 2008 16:53:17 +1000 Try Index: zdump.c =================================================================== --- zdump.c (revision 183065) +++ zdump.c (working copy) @@ -151,7 +151,9 @@ time_t hibit; struct tm tm; struct tm newtm; + int cpu32; + cpu32 = (sizeof(NULL) == 4); INITIALIZE(cuttime); #if HAVE_GETTEXT - 0 (void) setlocale(LC_MESSAGES, ""); @@ -222,9 +224,16 @@ /* ** Get lowest value of t. */ - t = hibit; - if (t > 0) /* time_t is unsigned */ - t = 0; + if (cpu32) { + t = hibit; + if (t > 0) /* time_t is unsigned */ + t = 0; + } else { + t = -2209024800; /* 1 January 1900 00:00:00 */ + cuttime = 4000000000; + cutoff = "2099"; + } + show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); It won't resolve the issue, only mask it for now. The problem is that the time after 2037 is still not shown . -- Edwin Groothuis edwin@freebsd.org http://www.mavetju.org From edwin at mavetju.org Wed Sep 17 13:10:06 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Wed Sep 17 14:02:53 2008 Subject: amd64/109584: [patch] zdump(8) doesn't work Message-ID: <200809171310.m8HDA6qh077420@freefall.freebsd.org> The following reply was made to PR amd64/109584; it has been noted by GNATS. From: Edwin Groothuis To: bug-followup@FreeBSD.org, dcrandall@simplestar.com Cc: Subject: Re: amd64/109584: [patch] zdump(8) doesn't work Date: Wed, 17 Sep 2008 23:01:55 +1000 Forgot the last data to be displayed. Index: zdump.c =================================================================== --- zdump.c (revision 183065) +++ zdump.c (working copy) @@ -96,6 +96,10 @@ #endif /* !defined GNUC_or_lint */ #endif /* !defined INITIALIZE */ +/* For architectures >32 bit, start at 1900 and go to 2100 */ +#define EPOCH1900 -2209024800 /* Mon Jan 1 00:00:00 EST 1900 */ +#define EPOCH2100 4102405200 /* Fri Jan 1 00:00:00 EST 2100 */ + /* ** For the benefit of GNU folk... ** `_(MSGID)' uses the current locale's message library string for MSGID. @@ -151,7 +155,9 @@ time_t hibit; struct tm tm; struct tm newtm; + int cpu32; + cpu32 = (sizeof(NULL) == 4); INITIALIZE(cuttime); #if HAVE_GETTEXT - 0 (void) setlocale(LC_MESSAGES, ""); @@ -222,9 +228,18 @@ /* ** Get lowest value of t. */ - t = hibit; - if (t > 0) /* time_t is unsigned */ - t = 0; + if (cpu32) { + t = hibit; + if (t > 0) /* time_t is unsigned */ + t = 0; + } else { + t = EPOCH1900; /* 1 January 1900 00:00:00 */ + if (cutoff == NULL) { + cuttime = EPOCH2100; + cutoff = "2099"; + } + } + show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); @@ -253,9 +268,13 @@ /* ** Get highest value of t. */ - t = ~((time_t) 0); - if (t < 0) /* time_t is signed */ - t &= ~hibit; + if (cpu32) { + t = ~((time_t) 0); + if (t < 0) /* time_t is signed */ + t &= ~hibit; + } else { + t = EPOCH2100 - 1; + } t -= SECSPERHOUR * HOURSPERDAY; show(argv[i], t, TRUE); t += SECSPERHOUR * HOURSPERDAY; -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From scott.gasch at gmail.com Wed Sep 17 15:00:27 2008 From: scott.gasch at gmail.com (Scott Gasch) Date: Wed Sep 17 15:27:25 2008 Subject: irq19 interrupt storm? In-Reply-To: <20080916161222.125d15f5@peedub.jennejohn.org> References: <20080916161222.125d15f5@peedub.jennejohn.org> Message-ID: You're right: atapci1, atapci2, fwohci0 and uhci4 are all sharing the same irq (19) while irqs 20, 21, 22 at least seem completely unused. Here's a dumb question: how do I fix it? I tried setting "plug and play OS" in the BIOS and then using device.hints to push different devices to different irqs. But every time I tried a new hint it seemed to be ignored. I was trying stuff like: set hint.atapci.1.irq="20" set hint ata.4.irq="20" (ata4 is a channel on atapci1) set hint fwhco.0.irq="20" etc... I also tried to move the dc driver to a new irq as a test. This was also seemingly ignored. I then tried turning "plug and play OS" off in the BIOS but I don't see anywhere to set the IRQs of the onboard SATA controllers via the menus. I'm looking for a BIOS upgrade now... any other advice? Thx, Scott On Tue, Sep 16, 2008 at 7:12 AM, Gary Jennejohn wrote: > On Mon, 15 Sep 2008 22:57:38 -0700 > "Scott Gasch" wrote: > > > Hi, > > > > I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. Nearly 100% of > > 1 cpu is constantly being used handling irq19: uhci4 interrupts. This > > seems to happen both with and without any USB devices plugged in: > > > > vmstat -i > > interrupt total rate > > irq1: atkbd0 5 0 > > irq6: fdc0 1 0 > > irq17: mskc0 dc0 1180547 18 > > irq18: skc0 uhci2* 163250699 2512 > > irq19: uhci4++ 3187989508 49072 > > I think the ++ here indicates that two or more devices are sharing this > interrupt. Try doing "grep irq.*19 /var/run/dmesg.boot" to see which > ones. One of these devices could be the culprit. > > --- > Gary Jennejohn > From jhb at freebsd.org Wed Sep 17 21:18:51 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 21:19:03 2008 Subject: irq19 interrupt storm? In-Reply-To: References: <20080916161222.125d15f5@peedub.jennejohn.org> Message-ID: <200809171717.27570.jhb@freebsd.org> On Wednesday 17 September 2008 11:00:24 am Scott Gasch wrote: > You're right: atapci1, atapci2, fwohci0 and uhci4 are all sharing the same > irq (19) while irqs 20, 21, 22 at least seem completely unused. Here's a > dumb question: how do I fix it? I tried setting "plug and play OS" in the > BIOS and then using device.hints to push different devices to different > irqs. But every time I tried a new hint it seemed to be ignored. I was > trying stuff like: > > set hint.atapci.1.irq="20" > set hint ata.4.irq="20" (ata4 is a channel on atapci1) > set hint fwhco.0.irq="20" > etc... > > > I also tried to move the dc driver to a new irq as a test. This was also > seemingly ignored. > > I then tried turning "plug and play OS" off in the BIOS but I don't see > anywhere to set the IRQs of the onboard SATA controllers via the menus. I'm > looking for a BIOS upgrade now... any other advice? Unfortunately you can't really move PCI IRQs around. You can read about more of the gritty details here: http://people.freebsd.org/~jhb/papers/bsdcan/2007/ You might be able to shuffle some IRQs around using 'hw.pciX.Y.INTA.irq' tunables. Probably you have a device driver whose interrupt handler isn't handling some condition. I would suspect ata as it's interrupt handler is rather simplistic with no chipset-specific hooks, and I've seen several reports of interrupt storms with ata(4) recently. > Thx, > Scott > > > On Tue, Sep 16, 2008 at 7:12 AM, Gary Jennejohn > wrote: > > > On Mon, 15 Sep 2008 22:57:38 -0700 > > "Scott Gasch" wrote: > > > > > Hi, > > > > > > I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. Nearly 100% of > > > 1 cpu is constantly being used handling irq19: uhci4 interrupts. This > > > seems to happen both with and without any USB devices plugged in: > > > > > > vmstat -i > > > interrupt total rate > > > irq1: atkbd0 5 0 > > > irq6: fdc0 1 0 > > > irq17: mskc0 dc0 1180547 18 > > > irq18: skc0 uhci2* 163250699 2512 > > > irq19: uhci4++ 3187989508 49072 > > > > I think the ++ here indicates that two or more devices are sharing this > > interrupt. Try doing "grep irq.*19 /var/run/dmesg.boot" to see which > > ones. One of these devices could be the culprit. > > > > --- > > Gary Jennejohn > > > _______________________________________________ > 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" > -- John Baldwin From miks at skynet.lv Wed Sep 17 21:50:02 2008 From: miks at skynet.lv (Miks) Date: Wed Sep 17 23:08:53 2008 Subject: amd64/127451: incorrect load on quad core Message-ID: <200809172146.m8HLkPmJ049541@www.freebsd.org> >Number: 127451 >Category: amd64 >Synopsis: incorrect load on quad core >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 17 21:50:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Miks >Release: 7.0 release amd64 >Organization: skynet >Environment: FreeBSD sun 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #4: Thu Sep 11 22:08:16 EEST 2008 miks@sun:/usr/obj/usr/src/sys/SUN amd64 >Description: 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 >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From miks at skynet.lv Thu Sep 18 19:10:06 2008 From: miks at skynet.lv (miks@skynet.lv) Date: Thu Sep 18 19:38:44 2008 Subject: amd64/127451: top(1): incorrect load shown on quad core Message-ID: <200809181910.m8IJA4OQ059243@freefall.freebsd.org> The following reply was made to PR amd64/127451; it has been noted by GNATS. 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 problem name is not correct - "top(1): incorrect load shown on quad core" I believe with top command there everything is ok. Problem is that after 2 or 3 minutes system suddenly got ~60 running proceses, ~40 locks and cpu is ~90% busy system, not user. system is unusable. old dual core system was faster and more stable than brand new dual quad-core cpu with 16gb ram. So problem by the fact is totally different, and I can't figure where and what is responsible for new, powerful server acting as low-budget desktop computer. From miks at skynet.lv Thu Sep 18 19:30:04 2008 From: miks at skynet.lv (miks@skynet.lv) Date: Thu Sep 18 19:44:02 2008 Subject: amd64/127451: top(1): incorrect load shown on quad core Message-ID: <200809181930.m8IJU3vm061196@freefall.freebsd.org> The following reply was made to PR amd64/127451; it has been noted by GNATS. 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 22:22:56 +0300 to understand better, this happen once in 2-3 minutes: " last pid: 98618; load averages: 29.81, 17.28, 15.03 up 6+23:13:22 22:15:50 1234 processes:159 running, 986 sleeping, 64 zombie, 25 lock CPU states: 1.1% user, 0.0% nice, 98.8% system, 0.0% interrupt, 0.0% idle " before 3 sec in this situation there was only 1 process running and load average was around 1. is it somehow related with lockmgr? From tg.at.swox.com at FreeBSD.org Thu Sep 18 21:40:02 2008 From: tg.at.swox.com at FreeBSD.org (Torbjorn Granlund) Date: Thu Sep 18 21:45:12 2008 Subject: amd64/127484: Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Message-ID: <200809182138.m8ILc75d083868@www.freebsd.org> >Number: 127484 >Category: amd64 >Synopsis: Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 18 21:40:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Torbjorn Granlund >Release: 7.0, 7.1 PRERELEASE >Organization: >Environment: FreeBSD carlos.gmplib.org 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Sep 16 22:32:59 CEST 2008 root@carlos.gmplib.org:/usr/src/sys/amd64/compile/GENERIC amd64 >Description: The clock on this system goes several percent too slowly. I have tried all available timecounters (the default HPET, as well as ACPI-safe and i8254. TSC strangely says (-100) which might suggest it is not reliable on this system. The clock drift problem seems to be exactly the same with all timecounters. I have also tried setting kern.hz to 100 (in /boot/loader.conf) without any improvements. kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) Motherboard: ASUS M3A78-EMH HDMI CPU: AMD Phenom 9750 (2.4 GHz x 4) I have run FreeBSD for 13 years on countless systems and have never experienced clock drift problems with it. Could this be a hardware problem? >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From jhb at freebsd.org Thu Sep 18 22:36:26 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 18 22:36:33 2008 Subject: irq19 interrupt storm? In-Reply-To: <200809171717.27570.jhb@freebsd.org> References: <200809171717.27570.jhb@freebsd.org> Message-ID: <200809181748.40142.jhb@freebsd.org> On Wednesday 17 September 2008 05:17:27 pm John Baldwin wrote: > On Wednesday 17 September 2008 11:00:24 am Scott Gasch wrote: > > You're right: atapci1, atapci2, fwohci0 and uhci4 are all sharing the same > > irq (19) while irqs 20, 21, 22 at least seem completely unused. Here's a > > dumb question: how do I fix it? I tried setting "plug and play OS" in the > > BIOS and then using device.hints to push different devices to different > > irqs. But every time I tried a new hint it seemed to be ignored. I was > > trying stuff like: > > > > set hint.atapci.1.irq="20" > > set hint ata.4.irq="20" (ata4 is a channel on atapci1) > > set hint fwhco.0.irq="20" > > etc... > > > > > > I also tried to move the dc driver to a new irq as a test. This was also > > seemingly ignored. > > > > I then tried turning "plug and play OS" off in the BIOS but I don't see > > anywhere to set the IRQs of the onboard SATA controllers via the menus. I'm > > looking for a BIOS upgrade now... any other advice? > > Unfortunately you can't really move PCI IRQs around. You can read about more > of the gritty details here: > > http://people.freebsd.org/~jhb/papers/bsdcan/2007/ > > You might be able to shuffle some IRQs around using 'hw.pciX.Y.INTA.irq' > tunables. Gah, wrong tunables. These devices are on PCI link devices, so you'd need to do something like 'hw.pci.LNKA.irq' (where LNKA is the name of the link device in the ACPI namespace). Verbose boot messages (boot -v) can tell you which link device you PCI devices are using. -- John Baldwin From edwin at FreeBSD.org Fri Sep 19 01:58:52 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Fri Sep 19 05:07:41 2008 Subject: amd64/109584: [patch] zdump(8) doesn't work Message-ID: <200809190158.m8J1wqon092583@freefall.freebsd.org> Synopsis: [patch] zdump(8) doesn't work Responsible-Changed-From-To: freebsd-amd64->edwin Responsible-Changed-By: edwin Responsible-Changed-When: Fri Sep 19 01:58:38 UTC 2008 Responsible-Changed-Why: Grab for handling with mentor. http://www.freebsd.org/cgi/query-pr.cgi?pr=109584 From titov-av at ptt.spb.ru Fri Sep 19 06:30:01 2008 From: titov-av at ptt.spb.ru (Alex) Date: Fri Sep 19 11:21:29 2008 Subject: amd64/127492: System hang on ZFS input-output Message-ID: <200809190626.m8J6QGfp020602@www.freebsd.org> >Number: 127492 >Category: amd64 >Synopsis: System hang on ZFS input-output >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 19 06:30:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Alex >Release: 7.1 >Organization: JSC "P.T.T." >Environment: FreeBSD x6.line1.ru 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Mon Sep 15 11:27:50 MSD 2008 root@x6.line1.ru:/usr/obj/usr/src/sys/KMIST amd64 >Description: We use RAID controller Smart Array P400 (driver ciss)in our system. Five hardware stripe arrays was combined into raidz (zfs). #df -h coolpool 6.7T 1.7T 5.0T 25% /www /www - used by proftpd and httpd daemons System is working properly during some period of time(day-week), but processes which are accessing to the ZFS volume turn into "D uninterruptible wait" state and hang on. www 86576 0.0 0.5 121560 19556 ?? D 7:37AM 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT www 86577 0.0 0.5 121560 19556 ?? D 7:37AM 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT www 86578 0.0 0.5 121560 19556 ?? D 7:38AM 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT Any requests to the ZFS volume cause the process hang. "Reboot"-command is executed normally up to the moment when the system produce "syncing disks" and hang also. P.S. 7.0 - release is working in the same way. >How-To-Repeat: We don't know. Possible high disc load. >Fix: Hardware reset. O_o >Release-Note: >Audit-Trail: >Unformatted: From tinderbox at freebsd.org Sun Sep 21 00:01:18 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:01:29 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20080921000115.9BD507303E@freebsd-current.sentex.ca> TB --- 2008-09-21 00:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-09-21 00:00:00 - cleaning the object tree TB --- 2008-09-21 00:00:39 - cvsupping the source tree TB --- 2008-09-21 00:00:39 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-09-21 00:00:44 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:00:44 - cd /src TB --- 2008-09-21 00:00:44 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:00:46 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:01:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:01:15 - ERROR: failed to build world TB --- 2008-09-21 00:01:15 - tinderbox aborted TB --- 18.53 user 6.70 system 75.11 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Sun Sep 21 00:20:33 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:20:37 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20080921002030.CC79B73039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-09-21 00:20:00 - cleaning the object tree TB --- 2008-09-21 00:20:02 - cvsupping the source tree TB --- 2008-09-21 00:20:02 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-09-21 00:20:08 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:20:08 - cd /src TB --- 2008-09-21 00:20:08 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:20:09 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:20:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:20:30 - ERROR: failed to build world TB --- 2008-09-21 00:20:30 - tinderbox aborted TB --- 17.29 user 2.61 system 30.45 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Sun Sep 21 00:40:33 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Sep 21 00:40:37 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20080921004031.6477E73039@freebsd-current.sentex.ca> TB --- 2008-09-21 00:40:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 00:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-09-21 00:40:00 - cleaning the object tree TB --- 2008-09-21 00:40:03 - cvsupping the source tree TB --- 2008-09-21 00:40:03 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-09-21 00:40:08 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 00:40:08 - cd /src TB --- 2008-09-21 00:40:08 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 00:40:09 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools [...] /src/usr.bin/ar/acpyacc.y:505: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_mlist2argv': /src/usr.bin/ar/acpyacc.y:621: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:622: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y: In function 'arscp_free_argv': /src/usr.bin/ar/acpyacc.y:631: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:632: error: dereferencing pointer to incomplete type /src/usr.bin/ar/acpyacc.y:634: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/ar. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-21 00:40:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-21 00:40:31 - ERROR: failed to build world TB --- 2008-09-21 00:40:31 - tinderbox aborted TB --- 17.20 user 2.73 system 30.90 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Mon Sep 22 00:03:33 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 22 00:03:38 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20080922000330.585C773039@freebsd-current.sentex.ca> TB --- 2008-09-21 23:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-21 23:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-09-21 23:00:00 - cleaning the object tree TB --- 2008-09-21 23:00:53 - cvsupping the source tree TB --- 2008-09-21 23:00:53 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-09-21 23:01:00 - building world (CFLAGS=-O -pipe) TB --- 2008-09-21 23:01:00 - cd /src TB --- 2008-09-21 23:01:00 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 21 23:01:02 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 [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/amd64/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -fstack-protector -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-22 00:03:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-22 00:03:30 - ERROR: failed to build world TB --- 2008-09-22 00:03:30 - tinderbox aborted TB --- 2705.29 user 334.16 system 3809.83 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Mon Sep 22 04:23:09 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 22 04:23:16 2008 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20080922042307.2ECB673039@freebsd-current.sentex.ca> TB --- 2008-09-22 03:20:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-09-22 03:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-09-22 03:20:00 - cleaning the object tree TB --- 2008-09-22 03:20:28 - cvsupping the source tree TB --- 2008-09-22 03:20:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-09-22 03:20:36 - building world (CFLAGS=-O -pipe) TB --- 2008-09-22 03:20:36 - cd /src TB --- 2008-09-22 03:20:36 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 22 03:20:39 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 [...] cc -O -pipe -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter -I/src/sbin/ipf/ipresend/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipresend/../../../sys -I/src/sbin/ipf/ipresend/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ipresend ipresend.o ip.o resend.o sbpf.o sock.o 44arp.o /obj/amd64/src/sbin/ipf/ipresend/../libipf/libipf.a -lkvm gzip -cn /src/sbin/ipf/ipresend/../../../contrib/ipfilter/ipsend/ipresend.1 > ipresend.1.gz ===> sbin/ipfw (all) cc -O -pipe -fstack-protector -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c /src/sbin/ipfw/ipfw2.c: In function 'table_handler': /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ipfw. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-22 04:23:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-22 04:23:07 - ERROR: failed to build world TB --- 2008-09-22 04:23:07 - tinderbox aborted TB --- 2707.03 user 330.81 system 3786.29 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From keramida at ceid.upatras.gr Mon Sep 22 05:41:16 2008 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Mon Sep 22 11:19:15 2008 Subject: [head tinderbox] failure on amd64/amd64 In-Reply-To: <20080922042307.2ECB673039@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Mon, 22 Sep 2008 00:23:07 -0400 (EDT)") References: <20080922042307.2ECB673039@freebsd-current.sentex.ca> Message-ID: <877i94n4cd.fsf@kobe.laptop> On Mon, 22 Sep 2008 00:23:07 -0400 (EDT), FreeBSD Tinderbox wrote: > ===> sbin/ipfw (all) > cc -O -pipe -fstack-protector -Wno-pointer-sign -c /src/sbin/ipfw/ipfw2.c > /src/sbin/ipfw/ipfw2.c: In function 'table_handler': > /src/sbin/ipfw/ipfw2.c:5877: error: 'a' undeclared (first use in this function) > /src/sbin/ipfw/ipfw2.c:5877: error: (Each undeclared identifier is reported only once > /src/sbin/ipfw/ipfw2.c:5877: error: for each function it appears in.) > *** Error code 1 Should be fixed in revision /head@183263 ... From edwin at FreeBSD.org Mon Sep 22 06:43:29 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Mon Sep 22 11:25:15 2008 Subject: amd64/127129: mdconfig(8) is core dumping with Segmentation Fault 11 Message-ID: <200809220643.m8M6hT54068779@freefall.freebsd.org> Synopsis: mdconfig(8) is core dumping with Segmentation Fault 11 State-Changed-From-To: open->feedback State-Changed-By: edwin State-Changed-When: Mon Sep 22 06:37:15 UTC 2008 State-Changed-Why: This sounds more like a upgrade which went wrong than a problem with mdconfig(8) since I have a lot of people saying that it works for them. Can you give the output of "ident `which mdconfig`" ? http://www.freebsd.org/cgi/query-pr.cgi?pr=127129 From bugmaster at FreeBSD.org Mon Sep 22 11:06:49 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 22 11:25:29 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200809221106.m8MB6m8R015289@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/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 f 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 76 problems total. From edwin at FreeBSD.org Mon Sep 22 22:06:35 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Mon Sep 22 22:14:24 2008 Subject: amd64/127129: mdconfig(8) is core dumping with Segmentation Fault 11 Message-ID: <200809222206.m8MM6Y60020592@freefall.freebsd.org> Synopsis: mdconfig(8) is core dumping with Segmentation Fault 11 State-Changed-From-To: feedback->open State-Changed-By: edwin State-Changed-When: Mon Sep 22 22:05:57 UTC 2008 State-Changed-Why: Feedback received http://www.freebsd.org/cgi/query-pr.cgi?pr=127129 From hakcenter at gmail.com Mon Sep 22 22:10:04 2008 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon Sep 22 22:38:36 2008 Subject: amd64/127129: mdconfig(8) is core dumping with Segmentation Fault 11 Message-ID: <200809222210.m8MMA3xE020673@freefall.freebsd.org> The following reply was made to PR amd64/127129; it has been noted by GNATS. From: Curtis Hacker To: edwin@FreeBSD.org Cc: Subject: Re: amd64/127129: mdconfig(8) is core dumping with Segmentation Fault 11 Date: Mon, 22 Sep 2008 13:37:50 -0700 amd64 box ident /sbin/mdconfig /sbin/mdconfig: $FreeBSD: src/lib/csu/amd64/crti.S,v 1.7 2004/03/21 01:39:01 peter Exp $ $FreeBSD: src/lib/csu/amd64/crtn.S,v 1.6 2004/03/21 01:39:01 peter Exp $ $FreeBSD: src/lib/csu/common/crtbrand.c,v 1.4.20.1 2007/12/06 13:43:43 kib Exp $ $FreeBSD: src/lib/csu/amd64/crt1.c,v 1.15 2005/10/07 22:13:17 bde Exp $ i386 box ident /sbin/mdconfig /sbin/mdconfig: $FreeBSD: src/lib/csu/i386-elf/crti.S,v 1.7 2005/05/19 07:31:06 dfr Exp $ $FreeBSD: src/lib/csu/i386-elf/crtn.S,v 1.6 2005/05/19 07:31:06 dfr Exp $ $FreeBSD: src/lib/csu/common/crtbrand.c,v 1.4.20.1 2007/12/06 13:43:43 kib Exp $ $FreeBSD: src/lib/csu/i386-elf/crt1.c,v 1.15 2005/10/07 22:13:17 bde Exp $ ive got 3 total bsd boxes, on the latest stable sup (7.1 pre-release) and only amd64 is giving me problems with mdconfig. I guess I could nuke my make.conf and rebuild just mdconfig edwin@FreeBSD.org wrote: > Synopsis: mdconfig(8) is core dumping with Segmentation Fault 11 > > State-Changed-From-To: open->feedback > State-Changed-By: edwin > State-Changed-When: Mon Sep 22 06:37:15 UTC 2008 > State-Changed-Why: > This sounds more like a upgrade which went wrong than a problem > with mdconfig(8) since I have a lot of people saying that it works > for them. > > Can you give the output of "ident `which mdconfig`" ? > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=127129 > > From zlynx at acm.org Thu Sep 25 21:00:04 2008 From: zlynx at acm.org (Jonathan Briggs) Date: Thu Sep 25 22:46:18 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 Message-ID: <200809252050.m8PKohFr095842@www.freebsd.org> >Number: 127640 >Category: amd64 >Synopsis: GCC will not build shared libraries with -fprofile-generate on amd64 >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 Sep 25 21:00:03 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Jonathan Briggs >Release: 7.0-RELEASE >Organization: >Environment: FreeBSD freebsd64 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: I was porting a specialized database library to FreeBSD and the build failed with this error: /usr/bin/ld: /usr/lib/libgcov.a(_gcov_merge_add.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/libgcov.a: could not read symbols: Bad value The library uses -fprofile-generate, runs a test set, then rebuilds with -fprofile-use. It's worth a few ms per lookup. Also, this builds very well on i386 FreeBSD 7.0 and on many varieties of Linux and their GCC builds (Debian ia64, Gentoo amd64, CentOS 5.2, Fedora 5, 8, 9). I can work around the problem by just not doing a profile build. >How-To-Repeat: Put the following in a shell script: #!/bin/sh cat < int counter(int count) { int i; for(i=0; iFix: >Release-Note: >Audit-Trail: >Unformatted: From jhb at freebsd.org Fri Sep 26 14:05:20 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Sep 26 14:05:41 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <200809252050.m8PKohFr095842@www.freebsd.org> References: <200809252050.m8PKohFr095842@www.freebsd.org> Message-ID: <200809261001.44340.jhb@freebsd.org> On Thursday 25 September 2008 04:50:43 pm Jonathan Briggs wrote: > > >Number: 127640 > >Category: amd64 > >Synopsis: GCC will not build shared libraries with -fprofile-generate on amd64 > >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 Sep 25 21:00:03 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Jonathan Briggs > >Release: 7.0-RELEASE > >Organization: > >Environment: > FreeBSD freebsd64 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: > I was porting a specialized database library to FreeBSD and the build failed with this error: > > /usr/bin/ld: /usr/lib/libgcov.a(_gcov_merge_add.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC > /usr/lib/libgcov.a: could not read symbols: Bad value > > The library uses -fprofile-generate, runs a test set, then rebuilds with -fprofile-use. It's worth a few ms per lookup. > > Also, this builds very well on i386 FreeBSD 7.0 and on many varieties of Linux and their GCC builds (Debian ia64, Gentoo amd64, CentOS 5.2, Fedora 5, 8, 9). > > I can work around the problem by just not doing a profile build. > >How-To-Repeat: > Put the following in a shell script: > > #!/bin/sh > cat < #include > > int counter(int count) > { > int i; > > for(i=0; i printf("loop %d\n", i); > } > return i; > } > EOF > gcc -O2 -shared -fprofile-generate -fPIC -o t1.so -x c - What if you add -fPIC as the message suggests? -- John Baldwin From jhb at freebsd.org Fri Sep 26 14:10:05 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Sep 26 14:10:12 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 Message-ID: <200809261410.m8QEA5YX035451@freefall.freebsd.org> The following reply was made to PR amd64/127640; it has been noted by GNATS. From: John Baldwin To: freebsd-amd64@freebsd.org Cc: Jonathan Briggs , freebsd-gnats-submit@freebsd.org Subject: Re: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 Date: Fri, 26 Sep 2008 10:01:43 -0400 On Thursday 25 September 2008 04:50:43 pm Jonathan Briggs wrote: > > >Number: 127640 > >Category: amd64 > >Synopsis: GCC will not build shared libraries with -fprofile-generate on amd64 > >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 Sep 25 21:00:03 UTC 2008 > >Closed-Date: > >Last-Modified: > >Originator: Jonathan Briggs > >Release: 7.0-RELEASE > >Organization: > >Environment: > FreeBSD freebsd64 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: > I was porting a specialized database library to FreeBSD and the build failed with this error: > > /usr/bin/ld: /usr/lib/libgcov.a(_gcov_merge_add.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC > /usr/lib/libgcov.a: could not read symbols: Bad value > > The library uses -fprofile-generate, runs a test set, then rebuilds with -fprofile-use. It's worth a few ms per lookup. > > Also, this builds very well on i386 FreeBSD 7.0 and on many varieties of Linux and their GCC builds (Debian ia64, Gentoo amd64, CentOS 5.2, Fedora 5, 8, 9). > > I can work around the problem by just not doing a profile build. > >How-To-Repeat: > Put the following in a shell script: > > #!/bin/sh > cat < #include > > int counter(int count) > { > int i; > > for(i=0; i printf("loop %d\n", i); > } > return i; > } > EOF > gcc -O2 -shared -fprofile-generate -fPIC -o t1.so -x c - What if you add -fPIC as the message suggests? -- John Baldwin From kostikbel at gmail.com Fri Sep 26 14:14:42 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 26 14:14:49 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <200809261001.44340.jhb@freebsd.org> References: <200809252050.m8PKohFr095842@www.freebsd.org> <200809261001.44340.jhb@freebsd.org> Message-ID: <20080926141429.GW47828@deviant.kiev.zoral.com.ua> On Fri, Sep 26, 2008 at 10:01:43AM -0400, John Baldwin wrote: > On Thursday 25 September 2008 04:50:43 pm Jonathan Briggs wrote: > > > > >Number: 127640 > > >Category: amd64 > > >Synopsis: GCC will not build shared libraries with -fprofile-generate > on amd64 > > >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 Sep 25 21:00:03 UTC 2008 > > >Closed-Date: > > >Last-Modified: > > >Originator: Jonathan Briggs > > >Release: 7.0-RELEASE > > >Organization: > > >Environment: > > FreeBSD freebsd64 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: > > I was porting a specialized database library to FreeBSD and the build failed > with this error: > > > > /usr/bin/ld: /usr/lib/libgcov.a(_gcov_merge_add.o): relocation R_X86_64_32 > can not be used when making a shared object; recompile with -fPIC > > /usr/lib/libgcov.a: could not read symbols: Bad value > > > > The library uses -fprofile-generate, runs a test set, then rebuilds > with -fprofile-use. It's worth a few ms per lookup. > > > > Also, this builds very well on i386 FreeBSD 7.0 and on many varieties of > Linux and their GCC builds (Debian ia64, Gentoo amd64, CentOS 5.2, Fedora 5, > 8, 9). > > > > I can work around the problem by just not doing a profile build. > > >How-To-Repeat: > > Put the following in a shell script: > > > > #!/bin/sh > > cat < > #include > > > > int counter(int count) > > { > > int i; > > > > for(i=0; i > printf("loop %d\n", i); > > } > > return i; > > } > > EOF > > gcc -O2 -shared -fprofile-generate -fPIC -o t1.so -x c - > > What if you add -fPIC as the message suggests? 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. -------------- 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/20080926/3cd0ee20/attachment.pgp From freebsd at sopwith.solgatos.com Fri Sep 26 15:17:13 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Sep 26 15:17:21 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 17:14:29 +0300." <20080926141429.GW47828@deviant.kiev.zoral.com.ua> Message-ID: <200809261513.PAA12380@sopwith.solgatos.com> > 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. So shouldn't the system come with both static and shared versions of all the libraries? From zlynx at acm.org Fri Sep 26 15:37:29 2008 From: zlynx at acm.org (Zan Lynx) Date: Fri Sep 26 16:05:15 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <20080926141429.GW47828@deviant.kiev.zoral.com.ua> References: <200809252050.m8PKohFr095842@www.freebsd.org> <200809261001.44340.jhb@freebsd.org> <20080926141429.GW47828@deviant.kiev.zoral.com.ua> Message-ID: <48DCFE02.90502@acm.org> Kostik Belousov wrote: > On Fri, Sep 26, 2008 at 10:01:43AM -0400, John Baldwin wrote: >> On Thursday 25 September 2008 04:50:43 pm Jonathan Briggs wrote: >>>> Number: 127640 >>>> Category: amd64 >>>> Synopsis: GCC will not build shared libraries with -fprofile-generate >> on amd64 >>>> 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 Sep 25 21:00:03 UTC 2008 >>>> Closed-Date: >>>> Last-Modified: >>>> Originator: Jonathan Briggs >>>> Release: 7.0-RELEASE >>>> Organization: >>>> Environment: >>> FreeBSD freebsd64 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: >>> I was porting a specialized database library to FreeBSD and the build failed >> with this error: >>> /usr/bin/ld: /usr/lib/libgcov.a(_gcov_merge_add.o): relocation R_X86_64_32 >> can not be used when making a shared object; recompile with -fPIC >>> /usr/lib/libgcov.a: could not read symbols: Bad value >>> >>> The library uses -fprofile-generate, runs a test set, then rebuilds >> with -fprofile-use. It's worth a few ms per lookup. >>> Also, this builds very well on i386 FreeBSD 7.0 and on many varieties of >> Linux and their GCC builds (Debian ia64, Gentoo amd64, CentOS 5.2, Fedora 5, >> 8, 9). >>> I can work around the problem by just not doing a profile build. >>>> How-To-Repeat: >>> Put the following in a shell script: >>> >>> #!/bin/sh >>> cat <>> #include >>> >>> int counter(int count) >>> { >>> int i; >>> >>> for(i=0; i>> printf("loop %d\n", i); >>> } >>> return i; >>> } >>> EOF >>> gcc -O2 -shared -fprofile-generate -fPIC -o t1.so -x c - >> What if you add -fPIC as the message suggests? > > 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. I was using only pre-built binary packages from 7.0-RELEASE. Rebuilding from source using ports would probably solve the problem but I believe that the binaries should still be fixed, eventually. From kostikbel at gmail.com Fri Sep 26 17:10:25 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 26 17:10:32 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <200809261513.PAA12380@sopwith.solgatos.com> References: <20080926141429.GW47828@deviant.kiev.zoral.com.ua> <200809261513.PAA12380@sopwith.solgatos.com> Message-ID: <20080926171018.GX47828@deviant.kiev.zoral.com.ua> On Fri, Sep 26, 2008 at 08:13:20AM +0100, Dieter wrote: > > 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. > > So shouldn't the system come with both static and shared versions > of all the libraries? The system does. OP linked system supplied libgcov.a into .so. Should /usr/lib/libgcov.a be built with -fPIC, is debatable. I think it is overkill for most other static libs from /usr/lib. Note that there are reasonable arguments against supplying static system libraries like libc and libpthread. -------------- 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/20080926/e808a4f0/attachment.pgp From freebsd at sopwith.solgatos.com Fri Sep 26 18:14:52 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Fri Sep 26 18:14:58 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: <200809261812.SAA00764@sopwith.solgatos.com> > > > 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. > >=20 > > So shouldn't the system come with both static and shared versions > > of all the libraries? > > The system does. OP linked system supplied libgcov.a into .so. > Should /usr/lib/libgcov.a be built with -fPIC, is debatable. I think it > is overkill for most other static libs from /usr/lib. Note that there > are reasonable arguments against supplying static system libraries like > libc and libpthread. The thread started with "porting a specialized database library to FreeBSD". One can expect problems when porting new code. But the PIC problem is bigger than that. Ports don't compile due to this problem. Ports should compile cleanly out of the box, on all archs, with no problems. Example: On amd64, 7.0, try to build python25. I get: /usr/bin/ld: /usr/lib/crtbeginT.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/crtbeginT.o: could not read symbols: Bad value *** Error code 1 Stop in /usr/ports/lang/python25/work/Python-2.5.1/portbld.shared. From kostikbel at gmail.com Fri Sep 26 20:09:19 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 26 20:09:36 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <200809261812.SAA00764@sopwith.solgatos.com> References: <20080926171018.GX47828@deviant.kiev.zoral.com.ua> <200809261812.SAA00764@sopwith.solgatos.com> Message-ID: <20080926200911.GY47828@deviant.kiev.zoral.com.ua> On Fri, Sep 26, 2008 at 11:12:31AM +0100, Dieter wrote: > > > > 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. > > >=20 > > > So shouldn't the system come with both static and shared versions > > > of all the libraries? > > > > The system does. OP linked system supplied libgcov.a into .so. > > Should /usr/lib/libgcov.a be built with -fPIC, is debatable. I think it > > is overkill for most other static libs from /usr/lib. Note that there > > are reasonable arguments against supplying static system libraries like > > libc and libpthread. > > The thread started with "porting a specialized database library to FreeBSD". > One can expect problems when porting new code. But the PIC problem is > bigger than that. Ports don't compile due to this problem. Ports should > compile cleanly out of the box, on all archs, with no problems. > > Example: On amd64, 7.0, try to build python25. I get: > > /usr/bin/ld: /usr/lib/crtbeginT.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC > /usr/lib/crtbeginT.o: could not read symbols: Bad value > *** Error code 1 > > Stop in /usr/ports/lang/python25/work/Python-2.5.1/portbld.shared. You are mixing unrelated issues. -------------- 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/20080926/63aad8fb/attachment.pgp From linimon at lonesome.com Fri Sep 26 20:04:13 2008 From: linimon at lonesome.com (Mark Linimon) Date: Fri Sep 26 20:59:45 2008 Subject: amd64/127640: GCC will not build shared libraries with -fprofile-generate on amd64 In-Reply-To: <200809261812.SAA00764@sopwith.solgatos.com> References: <20080926171018.GX47828@deviant.kiev.zoral.com.ua> <200809261812.SAA00764@sopwith.solgatos.com> Message-ID: <20080926193600.GA25444@soaustin.net> On Fri, Sep 26, 2008 at 11:12:31AM +0100, Dieter wrote: > 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. mcl From pvanberlo at fastmail.fm Sat Sep 27 08:20:04 2008 From: pvanberlo at fastmail.fm (Paul van Berlo) Date: Sat Sep 27 11:36:38 2008 Subject: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Message-ID: <200809270820.m8R8K4Te085359@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.at.swox.com@FreeBSD.org Cc: Subject: Re: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Date: Sat, 27 Sep 2008 09:52:00 +0200 Hello, I'm experiencing the exact same issue on 7.0/amd64. I have an Asrock A780FullDisplayPort mainboard (with an AMD Athlon64 X2 CPU, CnQ disabled, so the CPU doesn't throttle and always runs at 2.0Ghz, tested with both ACPI HPET enabled and disabled in bios), and looking at NTP it appears my clock is between 1-3 seconds slow each time it synchronizes. kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) I tried setting kern.timecounter.hardware to HPET (default), ACPI-safe and i8254. Neither of these solved the issue. I also set kern.hz=100 which didn't solve the issue either. 27 Sep 08:52:07 ntpd[761]: ntpd exiting on signal 15 27 Sep 08:53:25 ntpd[761]: synchronized to 194.171.167.130, stratum=1 27 Sep 08:53:27 ntpd[761]: time reset +1.365546 s 27 Sep 08:54:38 ntpd[761]: synchronized to 194.171.167.130, stratum=1 27 Sep 09:08:46 ntpd[761]: synchronized to 194.109.153.91, stratum=3 27 Sep 09:08:48 ntpd[761]: synchronized to 194.171.167.130, stratum=1 27 Sep 09:16:20 ntpd[761]: time reset +2.359489 s 27 Sep 09:16:20 ntpd[761]: kernel time sync enabled 2001 27 Sep 09:17:32 ntpd[761]: synchronized to 194.109.153.91, stratum=3 27 Sep 09:17:32 ntpd[761]: synchronized to 194.171.167.130, stratum=1 27 Sep 09:30:40 ntpd[761]: synchronized to 194.171.167.130, stratum=1 27 Sep 09:38:10 ntpd[761]: time reset +2.907558 s 27 Sep 09:39:21 ntpd[761]: synchronized to 194.171.167.130, stratum=1 Best regards, Paul van Berlo From bugmaster at FreeBSD.org Mon Sep 29 11:06:47 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 29 11:30:14 2008 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200809291106.m8TB6kM6040718@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/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 77 problems total.