Re: nfs umount soft hang
on 05/02/2009 16:34 Andriy Gapon said the following:
> I have an NFS server and NFS client separated by a firewall. Both
> servers are FreeBSD 7.1.
>
> Server configuration:
> nfs_server_enable="YES"
> nfs_server_flags="-t -n 4"
> rpcbind_enable="YES"
> mountd_flags="-r -p 737"
> mountd_enable="YES"
>
> The firewall allows tcp and udp to port 111, but only tcp to ports 2049
> and 737 (configured for mountd, see above).
>
> On the client I use e.g. the following command for mounting:
> mount -t nfs -o nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768
> :/export/usr/obj /usr/obj
>
> Mounting and subsequent fs operations work flawlessly.
>
> When I unmount umount command hangs but can be interrupted with ^C.
> Everything seems to be clean after that - the filesystem is unmounted,
> there are no post-effects on both client and server.
I think this is it:
377 /*
378 * Report to mountd-server which nfsname
379 * has been unmounted.
380 */
381 if (ai != NULL && !(fflag & MNT_FORCE) && do_rpc) {
382 clp = clnt_create(hostp, RPCPROG_MNT, RPCMNT_VER1,
"udp");
I wonder if umount could be smarter as to whether use udp or tcp here.
--
Andriy Gapon
___
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: Unhappy Xorg upgrade
Robert, First, thanks for all your dedicated work so far on the Xorg ports. I realize this upgrade has been somewhat fraught with unexpected issues. FWIW, things are not greener on the Linux side of the fence; many Ubuntu and Debian users have reported issues with the newer Xorg and in particular hald. Robert Noland wrote: ... I still see the USB symptoms with xorg-server port as of today -- forced rebuild with libpciaccess also. So amd64 is still regressed -- USB is totally unusable there after X is started. My theory was that somehow Xorg was stomping on the USB controller registers on this machine. The USB controller on this box is ALi, card=0x81561043. Is your usb sharing interrupts with the video card? Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box w/ioapic enabled from devinfo -r (abbreviated): ohci0 17 ohci1 18 ohci2 19 ehci0 23 lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the secondary IRQ 255. It appears msk0 is also sharing IRQ 18, though I haven't seen any problems with networking; mskc0, however, is then configured to use MSI (pseudo IRQ 256, 258), it is a PCI-e device. When the system starts, the drm module has not been loaded, so the Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD. After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko and radeon.ko got loaded by X as I would expect. I still see no IRQ allocated for the radeon, either in dmesg output or in devinfo -r, however, vmstat -i does show drm0 as sharing IRQ 18. At this point, I rebooted and tried manually resetting the BIOS ESCD table, unfortunately the BIOS on this machine won't let me tie IRQs down to particular devices. Does the issue occur if you aren't using a usb mouse? I see the USB problems regardless of the kind of USB devices plugged in, I continue to use a PS/2 mouse on the desktop as a workaround. I see the bump on devel/libpciaccess re typo of rombase, and forced a rebuild of xorg-server against the patched libpciaccess library (probably not needed, as the .so ABI didn't change). The USB problem is still present, unfortunately. thanks, BMS ___ 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: Unhappy Xorg upgrade
On Mon, 2009-02-09 at 19:26 +, Bruce M. Simpson wrote: > Robert, > > First, thanks for all your dedicated work so far on the Xorg ports. > > I realize this upgrade has been somewhat fraught with unexpected issues. > > FWIW, things are not greener on the Linux side of the fence; many Ubuntu > and Debian users have reported issues with the newer Xorg and in > particular hald. > > Robert Noland wrote: > > ... > >> I still see the USB symptoms with xorg-server port as of today -- forced > >> rebuild with libpciaccess also. So amd64 is still regressed -- USB is > >> totally unusable there after X is started. My theory was that somehow > >> Xorg was stomping on the USB controller registers on this machine. The > >> USB controller on this box is ALi, card=0x81561043. > >> > > > > Is your usb sharing interrupts with the video card? > > > > Yes, it appears so. This is an ASUS Vintage AH-1, uniprocessor amd64 box > w/ioapic enabled > > from devinfo -r (abbreviated): > ohci0 17 > ohci1 18 > ohci2 19 > ehci0 23 > > lspci -v jibes with devinfo -r -- the primary head got IRQ 18, the > secondary IRQ 255. > > It appears msk0 is also sharing IRQ 18, though I haven't seen any > problems with networking; mskc0, however, is then configured to use MSI > (pseudo IRQ 256, 258), it is a PCI-e device. > > When the system starts, the drm module has not been loaded, so the > Radeon (Sapphire X550) card hasn't been allocated its IRQ by FreeBSD. > > After X starts, glxinfo and glxgers work fine. kldstat reports drm.ko > and radeon.ko got loaded by X as I would expect. I still see no IRQ > allocated for the radeon, either in dmesg output or in devinfo -r, > however, vmstat -i does show drm0 as sharing IRQ 18. Ok, that is odd... Once drm is loaded and X opens it, the ddx driver should request that the irq handler be installed. At that point, dmesg should show something resembling the following. vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] I have code to enable msi for drm, which has been at least minimally tested on intel and ati. FWIW, linux does not support msi on radeon yet, so I got the jump on them there... The outstanding issue with that code is that I still need to implement a blacklist for certain devices that report msi capability, but don't (intel 945gm, is the only known chip atm). Does the issue still occur if drm is disabled? robert. > At this point, I rebooted and tried manually resetting the BIOS ESCD > table, unfortunately the BIOS on this machine won't let me tie IRQs down > to particular devices. > > > > Does the issue occur if you aren't using a usb mouse? > > > > I see the USB problems regardless of the kind of USB devices plugged in, > I continue to use a PS/2 mouse on the desktop as a workaround. > > I see the bump on devel/libpciaccess re typo of rombase, and forced a > rebuild of xorg-server against the patched libpciaccess library > (probably not needed, as the .so ABI didn't change). > > The USB problem is still present, unfortunately. > > thanks, > BMS > > ___ > 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" -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: Unhappy Xorg upgrade
09.02.09, 09:00, "Robert Noland" : > On Mon, 2009-02-09 at 02:08 +, Bruce M. Simpson wrote: > > Bruce M. Simpson wrote: > > > S.N.Grigoriev wrote: > > >> I thank you for your response. I've applied the patch to pci.c from > > >> kern/130957. Unfortunately there are no positive results. USB is still > > >> unreachable with X. > > > > > > Just following up to confirm that you are seeing exactly the same > > > symptoms with USB and Xorg 7.4 as I see on my amd64 desktop running > > > 7-STABLE from 00:00 UTC on this Wednesday. > > > > I still see the USB symptoms with xorg-server port as of today -- forced > > rebuild with libpciaccess also. So amd64 is still regressed -- USB is > > totally unusable there after X is started. My theory was that somehow > > Xorg was stomping on the USB controller registers on this machine. The > > USB controller on this box is ALi, card=0x81561043. > Is your usb sharing interrupts with the video card? Yes, it is. This is from dmesg output: ohci2: mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0 vgapci0: port 0xde00-0xdeff mem 0xd000-0xdfff, 0xfdee-0xfdee irq 18 at device 0.0 on pci1 > Does the issue occur if you aren't using a usb mouse? I'm not using a USB mouse. My mouse is PS/2. -- Regards, S.Grigoriev. ___ 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: sysctl lock in RELENG_6
On Mon, Feb 09, 2009 at 10:59:38AM +0700, Eugene Grosbein wrote: > Hi! > > I've RELENG_6 system controlling local PBX through RS-232 port, sio(4). > It also runs syslogd, cron, sshd, bsnmpd and sendmail for outgoing reports. > > It locks very often: it answers to pings but PBX controlling software stops > responding, local and remote login attempts hang due to 'login' process > stuck in 'sysctl lock' state. Local consoles do switch with 'Alt-Fn' > and DDB works. It shows that sendmail is in 'sysctl lock' state too. > > This is NanoBSD installation running from IDE flash, it's swapless > but I think I could manage to obtain crashdump if there is an interest of it. > > I've digged commit logs a bit and found this change MFC'd to RELENG_7 > but not RELENG_6: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2 > > It seems RELENG_6 needs this too, doesn't it? > I'm going to merge the change to RELENG_6 and give it a try. Yes, please give it a try. In fact, it was quite specific situation that I observed and produced a fix for. You need execing process that needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and simultaneous sysctl issued that inspects this process. pgp9n4DBvY2E3.pgp Description: PGP signature
Re: Unhappy Xorg upgrade
Robert Noland wrote: ... Ok, that is odd... Once drm is loaded and X opens it, the ddx driver should request that the irq handler be installed. At that point, dmesg should show something resembling the following. vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xc000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] Yes, I normally see output similar to this when X is started. ... Does the issue still occur if drm is disabled? Just tried disabling DRM w/ 'Options "DRI" "off"' in Section "Device". DRM is indeed disabled -- no dmesg output and not loaded by X. However the problem is still there. BTW: This Radeon card does have MSI capabilities according to lspci, however they do not appear to be enabled either by FreeBSD or by X. I was about to point the finger at interrupt filters, however that blows that theory out of the water. FWIW the IBM T43 here has an i915GM, and USB is working just fine and dandy. The main data point which sticks out is the fact that the affected machine is amd64. Now that DRM has been disabled on my box, this would point the finger at the X userland. I don't see any obvious nasties in my Section "Device", although I do pass a BusID and BusType to prevent X from trying to use the second head with RandR (lots of pain with fubar DVI cables when I first purchased the monitor). I skimmed pci_user.c, thinking libpciaccess just thunks to it via /dev/pci, it appears there's no instrumentation there I can turn on to see what userland is actually frobbing. thanks, BMS ___ 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"
http://www.freebsd.org/doc/handbook/desktop-browsers.html
Can the instructions for adding a java pluging please be updated to something that works as what's there doesn't work for Firefox 3. javavmwrapper-2.3.2 is installed. % ls -l /usr/local/lib/browser_plugins/ total 0 lrwxr-xr-x 1 root wheel 67 Feb 8 10:38 libjavaplugin_oji.so -> /usr/local/diablo-jdk1.6.0/jre/plugin/i386/ns7/libjavaplugin_oji.so % ls -lL /usr/local/lib/browser_plugins/ total 188 -rwxr-xr-x 1 root wheel 191059 Jun 18 2008 libjavaplugin_oji.so % Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.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"
Re: sysctl lock in RELENG_6
On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote: > > I've digged commit logs a bit and found this change MFC'd to RELENG_7 > > but not RELENG_6: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2 > > > > It seems RELENG_6 needs this too, doesn't it? > > I'm going to merge the change to RELENG_6 and give it a try. > > Yes, please give it a try. In fact, it was quite specific situation > that I observed and produced a fix for. You need execing process that > needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and > simultaneous sysctl issued that inspects this process. Well, my 6.3-STABLE locked very often (sometimes every hour). Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file to sources, rebuilt NanoBSD image and ran it. It has not locked yet. Btw, root filesystem here is UFS2 without softupdates mounted read-only but /etc and /var are md(4) (devfs is mounted too). Eugene Grosbein ___ 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"
ADMtek USB To LAN Converter
hail, I have two of these and cant make them ping. module loads ok, ifconfig sees ok, but cant send any data. tcpdump can get info though. aue0: on uhub1 miibus3: on aue0 ukphy1: PHY 1 on miibus3 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aue0: Ethernet address: 00:60:6e:00:05:d2 aue0: link state changed to DOWN aue0: link state changed to UP aue0: usb error on rx: IOERROR FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 30 00:41:39 BRT 2008 r...@xxx:/usr/obj/usr/src/sys/xxx i386 if anyone has any clues, thanks, matheus ps: sorry for posting to usb@ and stable@, but I saw no message in u...@. -- We will call you cygnus, The God of balance you shall be ___ 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: Unhappy Xorg upgrade
On Mon, 2009-02-09 at 23:30 +, Bruce M. Simpson wrote: > Robert Noland wrote: > > ... > > Ok, that is odd... Once drm is loaded and X opens it, the ddx driver > > should request that the irq handler be installed. At that point, dmesg > > should show something resembling the following. > > > > vgapci0: child drm0 requested pci_enable_busmaster > > info: [drm] AGP at 0xc000 256MB > > info: [drm] Initialized i915 1.6.0 20080730 > > drm0: [ITHREAD] > > > > Yes, I normally see output similar to this when X is started. > > > ... > > > > Does the issue still occur if drm is disabled? > > > > Just tried disabling DRM w/ 'Options "DRI" "off"' in Section "Device". > DRM is indeed disabled -- no dmesg output and not loaded by X. > > However the problem is still there. > > BTW: This Radeon card does have MSI capabilities according to lspci, > however they do not appear to be enabled either by FreeBSD or by X. I > was about to point the finger at interrupt filters, however that blows > that theory out of the water. > > FWIW the IBM T43 here has an i915GM, and USB is working just fine and > dandy. The main data point which sticks out is the fact that the > affected machine is amd64. > > Now that DRM has been disabled on my box, this would point the finger at > the X userland. > > I don't see any obvious nasties in my Section "Device", although I do > pass a BusID and BusType to prevent X from trying to use the second head > with RandR (lots of pain with fubar DVI cables when I first purchased > the monitor). > > I skimmed pci_user.c, thinking libpciaccess just thunks to it via > /dev/pci, it appears there's no instrumentation there I can turn on to > see what userland is actually frobbing. Ok, lets try another test... There is a scanpci util in the libpciaccess port. We don't install it, but it does get built. Build the port and run scanpci -v as root from the console. That should poke all the pci devices on the box and tell you about them. See if that is able to trigger the issue. robert. > thanks, > BMS > ___ > 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" -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: sysctl lock in RELENG_6
On Tue, Feb 10, 2009 at 11:01:25AM +0700, Eugene Grosbein wrote: > On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote: > > > > I've digged commit logs a bit and found this change MFC'd to RELENG_7 > > > but not RELENG_6: > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2 > > > > > > It seems RELENG_6 needs this too, doesn't it? > > > I'm going to merge the change to RELENG_6 and give it a try. > > > > Yes, please give it a try. In fact, it was quite specific situation > > that I observed and produced a fix for. You need execing process that > > needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and > > simultaneous sysctl issued that inspects this process. > > Well, my 6.3-STABLE locked very often (sometimes every hour). > Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file > to sources, rebuilt NanoBSD image and ran it. It has not locked yet. Can you be slightly more scientific in your tests ? Try RELENG_6 without my patch to see whether it is needed at all. > > Btw, root filesystem here is UFS2 without softupdates mounted read-only > but /etc and /var are md(4) (devfs is mounted too). > > Eugene Grosbein pgp6QEtrn4KuZ.pgp Description: PGP signature
