kern/157418: em driver lockup during boot on Supermicro X9SCM-F
>Number: 157418 >Category: kern >Synopsis: em driver lockup during boot on Supermicro X9SCM-F >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 30 08:40:05 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Tomas Svensson >Release:9,0-CURRENT (2011 May 12) >Organization: >Environment: Copyright (c) 1992-2011 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 9.0-CURRENT #0: Thu May 12 11:28:09 UTC 2011 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E31230 @ 3.20GHz (3192.81-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff Features2=0x15bae3ff,XSAVE,> AMD Features=0x2810 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3131559936 (2986 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 1.1 on pci0 pci2: on pcib2 pcib3: mem 0xfbd0-0xfbd1 irq 17 at device 0.0 on pci2 pci3: on pcib3 pcib4: irq 18 at device 1.0 on pci3 pci4: on pcib4 igb0: port 0xd020-0xd03f mem 0xfbba-0xfbbb,0xfbb8-0xfbb9,0xfbc44000-0xfbc47fff irq 18 at device 0.0 on pci4 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:25:90:0c:18:48 igb1: port 0xd000-0xd01f mem 0xfbb4-0xfbb5,0xfbb2-0xfbb3,0xfbc4-0xfbc43fff irq 19 at device 0.1 on pci4 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 00:25:90:0c:18:49 pcib5: irq 19 at device 2.0 on pci3 pci6: on pcib5 igb2: port 0xc020-0xc03f mem 0xfb9a-0xfb9b,0xfb98-0xfb99,0xfba44000-0xfba47fff irq 19 at device 0.0 on pci6 igb2: Using MSIX interrupts with 9 vectors igb2: Ethernet address: 00:25:90:0c:18:4a igb3: port 0xc000-0xc01f mem 0xfb94-0xfb95,0xfb92-0xfb93,0xfba4-0xfba43fff irq 16 at device 0.1 on pci6 igb3: Using MSIX interrupts with 9 vectors igb3: Ethernet address: 00:25:90:0c:18:4b pcib6: irq 19 at device 6.0 on pci0 pci8: on pcib6 em0: port 0xf020-0xf03f mem 0xfbf0-0xfbf1,0xfbf24000-0xfbf24fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt acquiring duplicate lock of same type: "network driver" 1st &dev_spec->swflag_mutex @ /usr/src/sys/dev/e1000/e1000_ich8lan.c:785 2nd &dev_spec->nvm_mutex @ /usr/src/sys/dev/e1000/e1000_ich8lan.c:751 KDB: stack backtrace: db_trace_self_wrapper(c0e8047a,30303031,6863695f,6e616c38,373a632e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c09ddcdb,c0e83bf2,c0e1483a,c6561fd8,c14207fc,...) at kdb_backtrace+0x2a _witness_debugger(c0e83bf2,c0e14861,c0e1483a,2ef,0,...) at _witness_debugger+0x25 witness_checkorder(c6afe460,9,c0e1483a,2ef,0,...) at witness_checkorder+0x469 _mtx_lock_flags(c6afe460,0,c0e1483a,2ef,c1420868,...) at _mtx_lock_flags+0xc4 e1000_acquire_nvm_ich8lan(c6afa004,c14218f4,c06897eb,c6afa004,0,...) at e1000_acquire_nvm_ich8lan+0x2e e1000_read_nvm_ich8lan(c6afa004,50,1,c1420890,a004,...) at e1000_read_nvm_ich8lan+0x59 e1000_post_phy_reset_ich8lan(c6afa004,c6afe48c,0,c09af220,0,...) at e1000_post_phy_reset_ich8lan+0x7b4 e1000_reset_hw_ich8lan(c6afa004,c14209c0,c06600f2,c6afa004,0,...) at e1000_reset_hw_ich8lan+0x2c2 e1000_reset_hw(c6afa004,0,1,,,...) at e1000_reset_hw+0x1a em_attach(c690a000,c67db05c,c0f8b710,c0e510b9,8003,...) at em_attach+0x13b2 device_attach(c690a000,4,c0e7f69e,a55) at device_attach+0x36f device_probe_and_attach(c690a000,c67d3700,c1420a60,c04fb3e4,c690a280,...) at device_probe_and_attach+0x4e bus_generic_attach(c690a280,c68c4000,1,c04fad10,0,c690a280,0,c68c4000) at bus_generic_attach+0x19 acpi_pci_attach(c690a280,c680805c,c0f8b710,c0e510b9,8003,...) at acpi_pci_attach+0x194 device_attach(c690a280,4,c0e7f
Re: kern/157176: [kernel] [patch] Heartbeat crashes when clock_t (signed 32bit int) rolls over
The following reply was made to PR kern/157176; it has been noted by GNATS. From: Rudolf Polzer To: "bug-follo...@freebsd.org" Cc: Subject: Re: kern/157176: [kernel] [patch] Heartbeat crashes when clock_t (signed 32bit int) rolls over Date: Mon, 30 May 2011 10:33:32 +0200 This really needs reassigning to ports, or better, to the maintainer of the= sysutils/heartbeat port. This is no kernel issue at all, heartbeat has special logic to handle clock= _t rollover, but because of these bugs reported here it does not work. Best regards, Rudolf Polzer= ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/157424: inconsistent output from ldd
>Number: 157424 >Category: misc >Synopsis: inconsistent output from ldd >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 30 12:30:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Graham Bradley >Release:8.2-RELEASE >Organization: >Environment: FreeBSD mrtoad.net 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: symptom: various commands that work on the host failed on a jail (mrtoad). e.g. mrtoad# gmd5sum /libexec/ld-elf.so.1: /usr/local/lib/libintl.so.9: unsupported file layout Assuming this is a dependency issue, tried... ldd `which gmd5sum` /usr/local/bin/gmd5sum: libintl.so.9 => not found (0x0)mrtoad# ldd -a /usr/local/bin/bash libc.so.7 => /usr/lib32/libc.so.7 (0x2809a000) ok, except that the libintl.so.9 file is there, and if I try bash ` mrtoad# ldd `which bash` /usr/local/bin/bash: libncurses.so.8 => /lib/libncurses.so.8 (0x8006e3000) libintl.so.9 => /usr/local/lib/libintl.so.9 (0x80083) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800939000) libc.so.7 => /lib/libc.so.7 (0x800b33000) the library file libintl.so.9 is found and bash works ok. >How-To-Repeat: Install 8.2 from dvd onto empty disc. create a jail from scratch using the ezjail-admin. I have suspicion that I installed some items by storing the pkg files? (No bad dependencies reported on pkg_add.) >Fix: Fix: deinstall and reinstall of sysutils/coreutils by cd /usr/ports/sysutils/coreutils make install make deinstall make reinstall This is a fix, but I'd like to understand how ldd can find the lib for one installed command but not the other. Is this truly a bug (tables getting out of step) or have I overlooked something? >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/157418: [em] em driver lockup during boot on Supermicro X9SCM-F
Old Synopsis: em driver lockup during boot on Supermicro X9SCM-F New Synopsis: [em] em driver lockup during boot on Supermicro X9SCM-F Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 30 14:33:45 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=157418 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/157281: [ahci] [patch] Add support to ahci for Marvell 88SE9172 (patch included)
The following reply was made to PR kern/157281; it has been noted by GNATS. From: Mark Linimon To: bug-follo...@freebsd.org Cc: Subject: Re: kern/157281: [ahci] [patch] Add support to ahci for Marvell 88SE9172 (patch included) Date: Mon, 30 May 2011 09:36:31 -0500 - Forwarded message from Josh Carroll - Date: Sat, 28 May 2011 22:50:54 -0700 From: Josh Carroll To: m...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/157281: [ahci] [patch] Add support to ahci for Marvell 88SE9172 (patch included) Working fine with the same patch (well, the relevant line anyway) against 8.2-RELEASE's sys/dev/ahci/ahci.c, so far so good. Thanks again! Josh - End forwarded message - ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/157176: [patch] sysutils/heartbeat crashes when clock_t (signed 32bit int) rolls over
Old Synopsis: [kernel] [patch] Heartbeat crashes when clock_t (signed 32bit int) rolls over New Synopsis: [patch] sysutils/heartbeat crashes when clock_t (signed 32bit int) rolls over Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 30 14:39:04 UTC 2011 Responsible-Changed-Why: Apparently this really applies to the sysutils/heartbeat port. The PR confused me. http://www.freebsd.org/cgi/query-pr.cgi?pr=157176 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/157429: Realtek RTL8169 doesn't work with re(4)
>Number: 157429 >Category: kern >Synopsis: Realtek RTL8169 doesn't work with re(4) >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 30 15:30:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Sergey Gavrilov >Release:8.2-STABLE >Organization: >Environment: FreeBSD freebsd.gabell.net 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon May 30 18:20:12 MSD 2011 r...@freebsd.gabell.net:/usr/obj/usr/src/sys/MYKERNEL i386 >Description: Asus A6000 laptop. Cable connected to switch and tested with other devices. I removed "device re" from kernel config for experiment. Anyway it goes the same way with GENERIC. After kldload if_re I got: dmesg: re0: port 0xd800-0xd8ff mem 0xdf6ff000-0xdf6f irq 17 at device 0.0 on pci2 re0: Using 1 MSI message re0: Chip rev. 0x3800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:1a:92:f0:c1:53 re0: [ITHREAD] re0: link state changed to DOWN ifconfig: re0: flags=8802 metric 0 mtu 1500 options=389b ether 00:1a:92:f0:c1:53 media: Ethernet autoselect (10baseT/UTP ) status: no carrier After "dhclient re0": re0: no link ... After "ifconfig re0 up": dmesg: re0: link state changed to UP ifconfig: re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:1a:92:f0:c1:53 media: Ethernet autoselect (100baseTX ) status: active dhclient re0: DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 ^C While dhcpserver works well with 3 other hosts in the network and over wifi with this machine. >How-To-Repeat: Use this hardware >Fix: It worked on FreeBSD 7 >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/157429: [re] Realtek RTL8169 doesn't work with re(4)
Old Synopsis: Realtek RTL8169 doesn't work with re(4) New Synopsis: [re] Realtek RTL8169 doesn't work with re(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 30 20:21:29 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=157429 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/157444: re0 unknown hardware revision with onboard Realtek 8111E
>Number: 157444 >Category: kern >Synopsis: re0 unknown hardware revision with onboard Realtek 8111E >Confidential: no >Severity: non-critical >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 30 22:50:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Robert Wade >Release:8.2 Release >Organization: >Environment: fREEbsd 8.2-release fREEbsd 8.2-release #0: Thu Feb 1 02:41:51 utc 2011 r...@mason.cse.buffalo.edu:/USR/OBJ/usr/src/sys/GENERIC amd64 >Description: With the realtek 8111e network controller (on the Asus P8P67 motherboard), dmesg notes the following: re0: port 0xd000-0xd0ff mem 0xd2104000-0xd2104fff,0xd210-0xd2103fff irq 17 at device 0.0 on pci7 re0: Using 1 MSI messages re0: Chip rev. 0x2c80 re0: MAC rev. 0x re0: Unknown H/W revision: 0x2c80 device_attach: re0 attach returned 6 >How-To-Repeat: >Fix: I have done some searching and note that some folks had similar problems and were able to patch the if_rlreg.h file or others, but I'm not sure what to do about the 8111e. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/157446: base expat needs minor fixes from vendor cvs
>Number: 157446 >Category: misc >Synopsis: base expat needs minor fixes from vendor cvs >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 30 23:40:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Steve Wills >Release: >Organization: >Environment: >Description: While looking into PR ports/150968 I discovered some minor bugs in the base expat that also are not patched. In particular, there's a better fix for CVE-2009-3560. See: http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmlparse.c?view=log In particular rev 1.166 and there's another issue which was reported here: http://mail.libexpat.org/pipermail/expat-bugs/2010-February/002870.html which was fixed in 1.167. This patch might do the trick: http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmlparse.c?r1=1.164&r2=1.167&view=patch >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/157444: [re] re0 unknown hardware revision with onboard Realtek 8111E
Old Synopsis: re0 unknown hardware revision with onboard Realtek 8111E New Synopsis: [re] re0 unknown hardware revision with onboard Realtek 8111E Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 31 00:20:57 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=157444 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/157449: MAC address conflict causes system to freeze
>Number: 157449 >Category: kern >Synopsis: MAC address conflict causes system to freeze >Confidential: no >Severity: serious >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 31 01:10:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Yuri >Release:8.2-STABLE >Organization: n/a >Environment: >Description: I had a bug in my setup script that was setting the same MAC address to several computers. This situation of course is not normal and should not normally occur. But I noticed the side effect that causes me to worry: 8.2-STABLE host was periodically freezing in such situation. My understanding is that such situation will cause all packets sent to this MAC address be accepted by every host in conflict and for example many garbage TCP packets will arrive to each machine. But why should it freeze the system? It looks like there is some bug in the code rejecting garbage traffic and my setup exposed it. This could also be a security issue when some other host on the same network can cause FreeBSD to freeze by sending some rogue packets to it. I should also note that I am talking about the wireless device ath0 and passwordless WEP network. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/157449: [ath] MAC address conflict causes system to freeze
Old Synopsis: MAC address conflict causes system to freeze New Synopsis: [ath] MAC address conflict causes system to freeze Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 31 01:57:48 UTC 2011 Responsible-Changed-Why: reclassify and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=157449 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
