Re: FreeBSD 9.1 ix driver vlan problem
On 09/25/2013 20:03, Daniel Corbe wrote: Why would disabling STP on the switch *shorten* the amount of time it takes for the port to come up? At least on Cisco switches, it takes ~45 seconds for the switching topology to converge with STP disabled. Shorter periods if you enable portfast or uplinkfast. What is meant, I believe, is that the port should be configured as an edge port (spanning-tree portfast [trunk] in cisco lingo, set edge for junipers). You don't ever want to disable STP anywhere - that's just a recipe for disaster. Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Le Wed, 25 Sep 2013 11:06:33 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. Testing looks good with your latest patch. I was able to run a complete poudriere bulk (870 packages). I'm running another bulk to see.. I've made another bulk without problem (with complete patch) If you have other patches to test just ask, I have not updated my packages because there was a change to make gvfsd to ignore some poudriere activity. So I guess it will be harder to see this problem. Could you, please, test with the only patch http://people.freebsd.org/~kib/misc/vnode_filter.1.patch applied ? I wonder would it be enough. Looks good with this single patch too, one poudriere bulk is completed and I'm doing another just in case (but I think it would have already paniced, that's quite reproductible). Thanks, regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard
I rebuilt the kernel while keeping the existing kernel, installing to /boot/kernelre on the USB stick. Unfortunately all the modules were redundantly rebuilt. Maybe I should have had -D NO_MODULES instead of -DNO_MODULES? I typed unload at the loader prompt, then boot /boot/kernelre/kernel. I had the same problem as before with dhclient, looked like nothing different. Lines in /var/run/dmesg.boot relating to re0 were: re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d0-0xf7d03fff irq 17 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c80 re0: MAC rev. 0x0010 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 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: d4:3d:7e:97:17:e2 Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard
On Thu, Sep 26, 2013 at 08:09:36AM +, Thomas Mueller wrote: I rebuilt the kernel while keeping the existing kernel, installing to /boot/kernelre on the USB stick. Unfortunately all the modules were redundantly rebuilt. Maybe I should have had -D NO_MODULES instead of -DNO_MODULES? I typed unload at the loader prompt, then boot /boot/kernelre/kernel. I had the same problem as before with dhclient, looked like nothing different. The patch was not intended to address your issue. It was for getting correct MAC revision number. So seeing no behavioral change is normal. The MAC revision number now indicates 0x0010 which means you have slightly different variant. I'll let you know if I happen to find more clue on that MAC revision. Lines in /var/run/dmesg.boot relating to re0 were: re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xf7d04000-0xf7d04fff,0xf7d0-0xf7d03fff irq 17 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x2c80 re0: MAC rev. 0x0010 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 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: d4:3d:7e:97:17:e2 Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Package build out to FTP distribution process
grarpamp grarp...@gmail.com writes: Is this all wiki'd somewhere? There's plenty of information on the FreeBSD wiki, but you need to read the portbuild article from the documentation set first. But bear in mind that a lot of work continues to go into this area, so documentation tends to larg behind reality a bit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 ix driver vlan problem
Hello everyone, Here are the final results of my tests: 1. I reinstalled the router with vanilla 9.2-RC4 and performed the same tests - the results were exactly the same. The problem persisted. 2. Then I applied the patch provided by Oleg and recompiled kernel. This indeed did *fix* the problem and now creating/destroying vlans does NOT cause the interface to flap at all. All the symptoms that I was experiencing seem to be gone. Thank you so very much Oleg and Dmitry! Appreciated. Jack, at this point I am wondering what your opinion on the patch is? Do you approve it for production use yourself or do you think it needs to reworked? Also any plans of incorporating this in -STABLE ? Again, I'd like to thank everyone who helped here and especially Oleg, Dmitry and Jack. Thanks guys! Cheers, Rumen Telbizov On Wed, Sep 25, 2013 at 2:10 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Wed, 25 Sep 2013, Rumen Telbizov wrote: Thanks for the heads-up Oleg, although not the news that I was hoping for. So what I am going to do right now is reinstall with 9.2 and recompile the driver with your patch. I'll come back to the list with my results. FWIW, we're (with oleg@, yeah) using this patch on stable/9, so you're welcome to test this on your 9 It's supposedly way too late to try to include this fix into 9.2-R, but maybe it's worth the errata notice... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** -- Rumen Telbizov Unix Systems Administrator http://telbizov.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dhclient failure with Realtek 8111E Ethernet on new MSI
One last shot in the dark: what if you reboot the router in front of the node in question? Sometimes it was surprised, when managing different mac addresses on the same adapter. I might be missing some parts, but did the mobo work before? Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
nanobsd on RELENG9
I am getting an odd error on a recent i386 releng9 while trying to build
a nanobsd image.
It dies during installworld in
cd /usr/src/etc/../share/man;
/usr/obj/nanobsd.full//usr/src/make.i386/make makedb
makewhatis /usr/obj/nanobsd.full//_.w/usr/share/man
makewhatis /usr/obj/nanobsd.full//_.w/usr/share/openssl/man
rm: /tmp/install.bqKyLzJg: Directory not empty
*** [installworld] Error code 1
1 error
*** [installworld] Error code 2
1 error
The only thing special about the environment is that its netbooted and
root is mounted via nfs and
The error seems to be in
/usr/src/Makefile.inc1
${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \
${IMAKEENV} rm -rf ${INSTALLTMP}
if I get rid of the rm -rf it works/completes
0{mdttestbox}# mount
10.255.255.1:/home/pxe9alix on / (nfs)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /etc (ufs, local)
/dev/md1 on /var (ufs, local)
/dev/da0a on /usr/obj (ufs, local, soft-updates)
0{mdttestbox}#
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada http://www.tancsa.com/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard
The patch was not intended to address your issue. It was for getting correct MAC revision number. So seeing no behavioral change is normal. The MAC revision number now indicates 0x0010 which means you have slightly different variant. I'll let you know if I happen to find more clue on that MAC revision. So now there is no advantage in building that kernel for my i386 USB-stick installation. Do I need to file a send-pr? One last shot in the dark: what if you reboot the router in front of the node in question? Sometimes it was surprised, when managing different mac addresses on the same adapter. I might be missing some parts, but did the mobo work before? Best regards Zoran I believe I can power off the router, and after a minute or two, power back on. Sure the mobo works, even the Ethernet chip works, but not with FreeBSD. I could boot NetBSD-HEAD amd64, dhclient ran ok, and I was able to checkout the system source tree and pkgsrc tree with cvs. So if I can get past the snag in pkg-config, which was dropped by FreeBSD in favor of pkgconf, I could build subversion and checkout the FreeBSD-HEAD source tree. I wonder if my Ethernet chip is better supported in the upcoming FreeBSD-10.0. I also have the on-motherboard quasi-USB WiFi Atheros AR9271 and the Hiro USB-stick-type WiFi adapter, Realtek RTL8191SU chip. I could also try to boot my OpenBSD 5.3 live USB 8 GB, see if Ethernet chip or Wi-Fi works, but OpenBSD can't access my hard drive or GPT-partitioned USB sticks, since OpenBSD does not support GPT, or USB 3.0. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.2-RC4 amd64 panic: vm_page_unwire
I'm running 9.2-RC4 on a handful of desktop and server machines (both i386 and amd64). I have seen three panics (all vm_page_unwire) on one of those systems only (amd64 server) during the past week. The first two panics were triggered when shutting down the ntpd daemon (a recent development snapshot version of ntpd: 4.2.7p387). Exiting a later release (p388) has not triggered the panic. The system panicked again overnight, this time while acting as an sftp server receiving large (GB) files from another system. Fri Sep 20 16:48:34 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.0 ... panic: vm_page_unwire: page 0xfe0233510578's wire count is zero cpuid = 3 KDB: stack backtrace: #0 0x80490268 at kdb_backtrace+0x68 #1 0x8045630a at panic+0x21a #2 0x8068bbc2 at vm_page_unwire+0x102 #3 0x80678702 at vm_fault_unwire+0xd2 #4 0x80680841 at vm_map_delete+0x171 #5 0x80680abf at vm_map_remove+0x5f #6 0x80683ee9 at vmspace_exit+0xc9 #7 0x8041f3ad at exit1+0x72d #8 0x804203ae at sys_sys_exit+0xe #9 0x806afd6f at amd64_syscall+0x3bf #10 0x8069a817 at Xfast_syscall+0xf7 Uptime: 2d0h35m3s Fri Sep 20 17:49:57 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.1 ... panic: vm_page_unwire: page 0xfe022f5fc238's wire count is zero cpuid = 2 KDB: stack backtrace: #0 0x80490268 at kdb_backtrace+0x68 #1 0x8045630a at panic+0x21a #2 0x8068bbc2 at vm_page_unwire+0x102 #3 0x80678702 at vm_fault_unwire+0xd2 #4 0x80680841 at vm_map_delete+0x171 #5 0x80680abf at vm_map_remove+0x5f #6 0x80683ee9 at vmspace_exit+0xc9 #7 0x8041f3ad at exit1+0x72d #8 0x804203ae at sys_sys_exit+0xe #9 0x806afd6f at amd64_syscall+0x3bf #10 0x8069a817 at Xfast_syscall+0xf7 Uptime: 59m51s Fri Sep 27 01:51:44 2013 +1000 ozsrv04# kgdb kernel.debug /var/crash/vmcore.2 ... panic: vm_page_unwire: page 0xfe0239ecfc48's wire count is zero cpuid = 5 KDB: stack backtrace: #0 0x80490268 at kdb_backtrace+0x68 #1 0x8045630a at panic+0x21a #2 0x8068bbc2 at vm_page_unwire+0x102 #3 0x804d857e at vfs_vmio_release+0x10e #4 0x804dadc8 at getnewbuf+0x468 #5 0x804dbb2f at getblk+0x5df #6 0x80632bb1 at ffs_balloc_ufs2+0x15c1 #7 0x8065a8d6 at ffs_write+0x246 #8 0x8070a18f at VOP_WRITE_APV+0x11f #9 0x80505e77 at vn_write+0x1f7 #10 0x80503b51 at vn_io_fault+0xb1 #11 0x804a387c at dofilewrite+0x9c #12 0x804a3b54 at kern_writev+0x54 #13 0x804a3bf5 at sys_write+0x65 #14 0x806afd6f at amd64_syscall+0x3bf #15 0x8069a817 at Xfast_syscall+0xf7 Uptime: 6d7h46m14s Is this a known problem? Should I file a PR? What additional information should I provide? I have made the core.txt.[0-2] files available in the following directory. The directory is not browsable. http://www.riverwillow.net.au/~john/92rc4/ -- John Marshall pgpmZwGKbJWGM.pgp Description: PGP signature
lock order reversal in 10-alpha2
After booting from a 10-alpha2 disk I am seeing lock order reversal messages show up from time to time. Current logs have 35 entries. The machine normally is running 9.1 from zfs root and I have setup a separate disk (eSATA case connected through backplane port to onboard SATA port) that I have installed 10-alpha amd64 onto a ufs partition to test port building with. I started by building 10 alpha1 and installing onto the new disk. I have since done svn up (last revision is 255868) then rebuilt and installed kernel and world while running 10 and still see these messages. I mentioned the existing 9.1 on zfs which I am not importing while running 10 from ufs as I noticed zfs mentioned in one of the entries. Initially I built with an empty src.conf but the last build I used the following - WITH_BSD_GREP=yes WITH_CLANG_EXTRAS=yes WITH_CTF=yes WITHOUT_LIB32=yes WITH_LLDB=yes Hardware is ASUS P8H61-M LE/USB3 corei5 8GB RAM nvidia GT520 I can provide full copy of log/messages or dmesg if required. A few samples -- messages:Sep 26 02:01:27 leader kernel: lock order reversal: messages-Sep 26 02:01:27 leader kernel: 1st 0xfe01eebd07f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 messages-Sep 26 02:01:27 leader kernel: 2nd 0xf800122f8200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 messages-Sep 26 02:01:27 leader kernel: KDB: stack backtrace: messages-Sep 26 02:01:27 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238a8f270 messages-Sep 26 02:01:27 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238a8f320 messages-Sep 26 02:01:27 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfe0238a8f3b0 messages-Sep 26 02:01:27 leader kernel: _sx_xlock() at _sx_xlock+0x75/frame 0xfe0238a8f3f0 messages-Sep 26 02:01:27 leader kernel: ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfe0238a8f430 messages-Sep 26 02:01:27 leader kernel: ufs_direnter() at ufs_direnter+0x688/frame 0xfe0238a8f4f0 messages-Sep 26 02:01:27 leader kernel: ufs_makeinode() at ufs_makeinode+0x573/frame 0xfe0238a8f6b0 messages-Sep 26 02:01:27 leader kernel: VOP_CREATE_APV() at VOP_CREATE_APV+0xea/frame 0xfe0238a8f6e0 messages-Sep 26 02:01:27 leader kernel: vn_open_cred() at vn_open_cred+0x300/frame 0xfe0238a8f830 messages-Sep 26 02:01:27 leader kernel: kern_openat() at kern_openat+0x261/frame 0xfe0238a8f9a0 messages-Sep 26 02:01:27 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe0238a8fab0 messages-Sep 26 02:01:27 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0238a8fab0 messages-Sep 26 02:01:27 leader kernel: --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80185baca, rsp = 0x7fffd168, rbp = 0x7fffd1a0 --- messages.0:Sep 23 10:08:11 leader kernel: lock order reversal: messages.0-Sep 23 10:08:11 leader kernel: 1st 0xf801ba2e65f0 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3435 messages.0-Sep 23 10:08:11 leader kernel: 2nd 0xfe01ef93c1c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 messages.0-Sep 23 10:08:11 leader kernel: 3rd 0xf801ba2e6240 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 messages.0-Sep 23 10:08:11 leader kernel: KDB: stack backtrace: messages.0-Sep 23 10:08:11 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe02397c2300 messages.0-Sep 23 10:08:11 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe02397c23b0 messages.0-Sep 23 10:08:11 leader kernel: witness_checkorder() at witness_checkorder+0xd23/frame 0xfe02397c2440 messages.0-Sep 23 10:08:11 leader kernel: __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfe02397c2570 messages.0-Sep 23 10:08:11 leader kernel: ffs_lock() at ffs_lock+0x84/frame 0xfe02397c25c0 messages.0-Sep 23 10:08:11 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe02397c25f0 messages.0-Sep 23 10:08:11 leader kernel: _vn_lock() at _vn_lock+0xab/frame 0xfe02397c2660 messages.0-Sep 23 10:08:11 leader kernel: vget() at vget+0x70/frame 0xfe02397c26b0 messages.0-Sep 23 10:08:11 leader kernel: vfs_hash_get() at vfs_hash_get+0xf5/frame 0xfe02397c2700 messages.0-Sep 23 10:08:11 leader kernel: ffs_vgetf() at ffs_vgetf+0x41/frame 0xfe02397c2790 messages.0-Sep 23 10:08:11 leader kernel: softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xfe02397c2840 messages.0-Sep 23 10:08:11 leader kernel: ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xfe02397c28c0 messages.0-Sep 23 10:08:11 leader kernel: ffs_fsync() at ffs_fsync+0x20/frame 0xfe02397c28f0 messages.0-Sep 23 10:08:11 leader kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf0/frame 0xfe02397c2920 messages.0-Sep 23 10:08:11 leader kernel: sys_fsync() at sys_fsync+0x156/frame 0xfe02397c29a0 messages.0-Sep 23 10:08:11 leader kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe02397c2ab0 messages.0-Sep 23
