Re: 10.1-STABLE bce: Watchdog timeout occurred
On 04/21/2015 06:17 AM, Chris Ross wrote: I got a new [to me] system recently, a Dell PE 1950. It has two bce parts on the motherboard that identify as: bce#: QLogic NetXtreme II BCM5708 1000Base-T (B2) The OS I installed and kernel I'm running are from a download of a 10.1 STABLE ISO, r281235, April 7, 2015. I had gone on to check out a newer stable from subversion, and build a custom kernel, but when I booted that one I got a bce0 that didn't seem to work, and kept emitting: bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! bce0: link state changed to DOWN bce0: link state changed to UP So, I fell back. But I've since noticed that even the original kernel seems to do this after booting. I'm not yet running any notable amount of traffic through the system, but intend to make it an edge router, so certainly will be. Is there any sort of issue noted in the bce driver in recent days/weeks/months? Are other folks seeing this diagnostic/error? I'll do a little more testing and see if I'm seeing it more or less often, but I know that in at least some cases the interface has flapped like this after boot for long enough that I was unable to get connected remotely, and resorted to a console login to reboot. - Chris There are Watchdog timeout errors with some msk NICs. Both msk and bce are dependent on MII bus code (see /usr/src/sys/amd64/conf/GENERIC) -Alnis ___ 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
AUTOFS (automount) and NFS server not playing together nicely
At the risk of being dubbed insane, here goes: On five FreeBSD 10.1-RELEASE-p9 production servers autofs(5) is enabled and working as advertised. On the same servers nfs v3 clients are also fat, dumb and happy. On a test server where autofs(5) is also enabled and working well, I am testing nfs v3 (later v4) server. Strange things are happening. When nfs mountd(8) is running, the autofs(5) auto-mount (via automountd) function seems to work, but the autofs(5) auto-unmount (via autounmountd) never occurs. Without nfs mountd(8), when the filesystem /disc is auto-mounted (via autoumountd), the mount(8) command shows status of (ufs, local, journaled soft-updates, auto-mounted) for the auto-mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted (via autounmountd). No problem. With nfs mountd(8) the mount(8) command shows (ufs, local, journaled soft-updates). The auto-mounted filesystem is never (a long, long time) unmounted. Big problem. Without nfs mountd(8) running, the mount(8) command mount -o automounted /dev/ada0p8 /disc mounts the filesystem and the mount(8) command shows (ufs, local, journaled soft-updates, automounted) for the manually mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted even though it was not mounted automatically. No problem. With nfs mountd(8), the mount(8) command mount -o automounted /dev/ada0p8 /disc mounts the filesystem but the mount(8) command shows (ufs, local, journaled soft-updates) and after the timeout period (600 seconds) the filesystem is remains mounted. Big problem. It appears that nfs mountd(8) is interferring with the mount(8) command's -o option processing but admittedly that is just a very weak SWAG. I have adequate hardware (real and virtual) to do any testing that may be suggested. Most days there is no time constraint either. The /etc/auto_master file is two lines: 1:/net -hosts -nobrowse,nosuid(original) 2:/-/etc/autofs/auto_disc The /etc/autofs/auto_disc file is one line: 1:/disc -fstype=ufs :/dev/ada0p8 Once again, everything works well when nfs mountd(8) is not present in the system. Thanks for any assistance that you may be able to supply. David Boyd. ___ 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: 10.1-STABLE bce: Watchdog timeout occurred
This may be caused by DMA alignment problems. See https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145859+0+archive/2015/freebsd-stable/20150419.freebsd-stable for a recent thread about the msk driver. The msk maintainer Yonghyeon Pyun has opted for super safe options of 32K alignment! It's a long shot, but you could try increasing BCE_DMA_ALIGN and/or BCE_RX_BUF_ALIGN in the include file if_bcereg.h, say up to 4096, to see whether it makes any difference. - Gareth. On 21/04/2015 10:52, Alnis Morics wrote: On 04/21/2015 06:17 AM, Chris Ross wrote: I got a new [to me] system recently, a Dell PE 1950. It has two bce parts on the motherboard that identify as: bce#: QLogic NetXtreme II BCM5708 1000Base-T (B2) The OS I installed and kernel I'm running are from a download of a 10.1 STABLE ISO, r281235, April 7, 2015. I had gone on to check out a newer stable from subversion, and build a custom kernel, but when I booted that one I got a bce0 that didn't seem to work, and kept emitting: bce0: /usr/src/sys/dev/bce/if_bce.c(7869): Watchdog timeout occurred, resetting! bce0: link state changed to DOWN bce0: link state changed to UP So, I fell back. But I've since noticed that even the original kernel seems to do this after booting. I'm not yet running any notable amount of traffic through the system, but intend to make it an edge router, so certainly will be. Is there any sort of issue noted in the bce driver in recent days/weeks/months? Are other folks seeing this diagnostic/error? I'll do a little more testing and see if I'm seeing it more or less often, but I know that in at least some cases the interface has flapped like this after boot for long enough that I was unable to get connected remotely, and resorted to a console login to reboot. - Chris There are Watchdog timeout errors with some msk NICs. Both msk and bce are dependent on MII bus code (see /usr/src/sys/amd64/conf/GENERIC) -Alnis ___ 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 ___ 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
File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)
Hello, I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause a kernel panic. For example a simple command like the following causes a panic: zpool create /tmp/zfstut/disk1 This issue was identified in PR 195061: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 And fixed in r274619 (2014-11-17): https://svnweb.freebsd.org/base?view=revisionrevision=274619 However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t on 11-CURRENT). Are there any plans to patch this in 10.1? I note it’s not in the errata. My tutorials are not the only ones that use file-backed ZFS: new users experimenting with ZFS on FreeBSD are likely to encounter this issue. Thanks, Will ___ 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: 10.1-STABLE bce: Watchdog timeout occurred
On Apr 21, 2015, at 10:10 , Gareth Wyn Roberts g.w.robe...@glyndwr.ac.uk wrote: This may be caused by DMA alignment problems. See https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145859+0+archive/2015/freebsd-stable/20150419.freebsd-stable for a recent thread about the msk driver. The msk maintainer Yonghyeon Pyun has opted for super safe options of 32K alignment! It's a long shot, but you could try increasing BCE_DMA_ALIGN and/or BCE_RX_BUF_ALIGN in the include file if_bcereg.h, say up to 4096, to see whether it makes any difference. Well, after making that change, I was able to confirm that the problem doesn't seem to occur. However, in trying to verify the problem on an unmodified kernel, I've rebooted a GENERIC from r281672 without that change, and am also not seeing the problem. :-/ I'm not sure whether the gremlins have fixed something, or if I was just too critical in my initial analysis. For now I'll take that change out of my tree and run without it. If I see the flapping again, I'll confirm that it's repeatable, then change the alignments as suggested and see if I see a change. Thanks all... - Chris signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 10.1-STABLE bce: Watchdog timeout occurred
On Wed, Apr 22, 2015 at 12:39:16AM -0400, Chris Ross wrote: On Apr 21, 2015, at 10:10 , Gareth Wyn Roberts g.w.robe...@glyndwr.ac.uk wrote: This may be caused by DMA alignment problems. See https://docs.freebsd.org/cgi/getmsg.cgi?fetch=145859+0+archive/2015/freebsd-stable/20150419.freebsd-stable for a recent thread about the msk driver. The msk maintainer Yonghyeon Pyun has opted for super safe options of 32K alignment! It's a long shot, but you could try increasing BCE_DMA_ALIGN and/or BCE_RX_BUF_ALIGN in the include file if_bcereg.h, say up to 4096, to see whether it makes any difference. Well, after making that change, I was able to confirm that the problem doesn't seem to occur. However, in trying to verify the problem on an unmodified kernel, I've rebooted a GENERIC from r281672 without that change, and am also not seeing the problem. :-/ I'm not sure whether the gremlins have fixed something, or if I was just too critical in my initial analysis. For now I'll take that change out of my tree and run without it. If I see the flapping again, I'll confirm that it's repeatable, then change the alignments as suggested and see if I see a change. I guess the alignment issue of msk(4) has nothing to do with bce(4) watchdog timeouts. It would be more helpful to know details of your controller(bce(4)/brgphy(4) related dmesg output, pciconf output etc) and network setup. If you know a reliable way that triggers the watchdog timeouts, please share that info too. I would have tried to disable all hardware offloading features(TSO, checksum, VLAN H/W tagging etc) and see whether that makes any differences in the first step to narrow down the issue. Thanks. ___ 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: pkg 1.5.0 is out
On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: Hi all, Final pkg 1.5.0 has been released. pkg 1.5.1 at 'pkg upgrade' propose === New packages to be INSTALLED: nvidia-driver: 346.47 linux-c6-libGLU: 10.1 === I am use nvidia-driver-340: # pkg info nvidia-driver-340-340.76 nvidia-driver-340-340.76 Name : nvidia-driver-340 Version: 340.76 Installed on : Tue Mar 10 16:15:59 MSK 2015 Origin : x11/nvidia-driver-340 Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : x11 kld Licenses : NVIDIA Maintainer : da...@freebsd.org WWW: http://www.nvidia.com/object/unix.html Comment: NVidia graphics card binary drivers for hardware OpenGL rendering Options: ACPI_PM: on DOCS : on LINUX : on WBINVD : off Shared Libs required: libXext.so.6 libX11.so.6 Shared Libs provided: libvdpau_nvidia.so.1 libnvidia-glsi.so.1 libnvidia-glcore.so.1 libnvidia-eglcore.so.1 libnvidia-cfg.so.1 libglx.so.1 libGLESv2.so.2 libGLESv1_CM.so.1 libGL.so.1 libEGL.so.1 Annotations: repo_type : binary repository : ivs Flat size : 209MiB ___ 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: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)
I did actually request this back in November, but I don't seem to have had a reply so I'll chase. On 21/04/2015 16:23, Will Green wrote: Hello, I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause a kernel panic. For example a simple command like the following causes a panic: zpool create /tmp/zfstut/disk1 This issue was identified in PR 195061: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 And fixed in r274619 (2014-11-17): https://svnweb.freebsd.org/base?view=revisionrevision=274619 However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t on 11-CURRENT). Are there any plans to patch this in 10.1? I note it’s not in the errata. My tutorials are not the only ones that use file-backed ZFS: new users experimenting with ZFS on FreeBSD are likely to encounter this issue. Thanks, Will ___ 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 ___ 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
