Re: inetd needs discard service in /etc/services
I would like to commit the following patch. It changes the port from discard to syslog and documents the dependency. I choose syslog because it really does need to be in /etc/services on most machines since it starts before NIS. I'll also file a PR against inetd in hopes that someone gets board enough to fix it some day. getaddrinfo can also accept numeric service names (ie. port numbers in the case of UDP/TCP). I wonder if it would be better to just replace the service name with 1 or some such? I guess that would also fix your problem. David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off topic - disk crash
C. Kukulies wrote: Today an important (no backup of course) 46 GB IBM Deskstar IDE disk crashed. It has a FreeBSD 4.8 on it with important data and programs. Yes, shame on me that I didn't care about doing backups on it but it has happened. I evend tend to expend the bucks to get it recovered but a little prediagnosis I would not to be left untried. The disk boots into FreeBSD but already at power on time the disk does seek retries or some recalibration noise. The question is what else can I do to recover the data. Put it in the icebox? Turn the computer upside down? Any ideas would be welcome. I thought of getting a second identical disk to exchange electronics only but since it partially functions it looks more like surface corruption, doesn't it? Its most likely the dreaded deathstar syndrome and yes that means the magnetic surface of the platters is worn thin or in some of the worse cases completely worn off.. To put it short, there isn't much hope for your data :( -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP!!! USB MFC committed..
Hi akiyama san, unfortunately, It couldn't help me. With KMODDEPS, DDB said: Stopped at usbd_get_string+0x15: movl 0(%eax), %eax) db trace usbd_get_string(.) usbd_devinfo_vp(.) usbd_devinfo(.) ugen_attach(.) DEVICE_ATTACH(.) device_probe_and_attach(.) at ... usbd_probe_and_attach(.) at ... usbd_new_device(.) at ... (snip) Without KMODEPS, I had been seen: Stopped at usbd_get_interface_descriptor+0x6: movl 0x4(%eax),%eax db trace usbd_get_interface_descriptor(1,6,) at usbd_get_interface_descriptor+0x6 umodem_match(.) at umodem_match+0x24 DEVICE_PROBE(.) at DEVICE_PROBE+0x2e device_probe_child(.) at ... device_probe_and_attach(.) at ... usbd_probe_and_attach(.) at ... usbd_new_device(.) at ... (snip) I don't know what is different between two above situation. By the way, I found it would always panic with latter panic message when I load kernel-without-usb + usb.ko + ucom.ko + umodem.ko then boot although I didn't plugged any umodem devices. akiyama san wrote: Hi, Sarumaru-san. At Mon, 8 Mar 2004 01:38:07 +0900, Yoshihiko Sarumaru wrote: I report you about a USB problem that would be occur with my laptop after you MFC'ed USB stuff. With GENERIC kernel, it is fine and there are no changes from before, but with no usb kernel + usb.ko + umass.ko, it would be panic everytime on boot. It is not depend on umass. The panic would be happen when I didn't load umass.ko but ucom.ko + umodem.ko and plug USB modem (PHS phone). I reproduced this panic, and tracked this down. This is a kernel module dependency problem. Please try attached patch, and let me know the result. If this patch fix your problem, I'll commit this. -- Shunsuke Akiyama [EMAIL PROTECTED] [EMAIL PROTECTED] -- Yoshihiko Sarumaru mail: [EMAIL PROTECTED] web: http://www.imasy.or.jp/~mistral/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off topic - disk crash
Date: Wed, 10 Mar 2004 18:36:52 +0100 (CET) From: C. Kukulies [EMAIL PROTECTED] Subject: off topic - disk crash To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Today an important (no backup of course) 46 GB IBM Deskstar IDE disk crashed. It has a FreeBSD 4.8 on it with important data and programs. Yes, shame on me that I didn't care about doing backups on it but it has happened. This specific line of drives is infamous for a failure rate that's at least a full order of magnitude above the industry average for ATA drives. Google a bit for it. I just spent a weekend replacing that exact model of drive and trying to recover data for our babysitter's (WinMe) computer, without success. I evend tend to expend the bucks to get it recovered but a little prediagnosis I would not to be left untried. The disk boots into FreeBSD but already at power on time the disk does seek retries or some recalibration noise. The question is what else can I do to recover the data. Put it in the icebox? Yes, this might actually help, provided the read head is not yet too badly damaged or stuck to the platter. One of the several problems with the drive seems to relate to overheating. Turn the computer upside down? I'd remove the drive from its mounting and just hook it up loosely cabled into an open system while you try to recover. There's supposed to be some firmware update you can get from IBM to update the drive firmware, which can help reduce the chance of these errors and might help recover the data. If you can find the firmware update from IBM, boot a system in DOS with the drive hooked up, and run the flash utility, that might help with the following steps. Any ideas would be welcome. I thought of getting a second identical disk to exchange electronics only but since it partially functions it looks more like surface corruption, doesn't it? From what I've read online part of the failure mode may have to do with stray particles of crud inside the platter area from a bad manufacturing process (or coming loose from the drive surface over time) attaching to the read head and resulting in a head crash. The other problem was that the drive sometimes didn't park the head safely on powerdown. It's very unlikely to be an electronics problem. It all depends how bad the crash is and what the current condition of the head and surface is whether you will get anything back off again. In my case I couldn't get past 5% into the drive using the disk utilities I had, but working in FreeBSD with its known data structures you might be able to do better. You've been given good-sounding advice about what to try on the software side by a previous poster. I recommend following the suggestion given by that poster. On the hardware side, before you start trying to copy the data off, first try this firmware update if you can find it (Google for it) and then make sure the drive is extremely well cooled while you're trying to copy the data off. Either prechill it or have it in open air with a fan blowing on it, or both. If you can't get it to start reading at all and can't get anything off, the head may be stuck to the disk. ONLY if you can't seem to get anywhere at all with it, in that case (sensitive types may want to shield their eyes at this point) you could try picking up the drive and banging it on the table once or twice only. Sometimes this will free the head on a crashed hard drive and let you read it long enough to recover the contents, though it tends to rapidly destroy working drives. I have done this very very rarely in my career, but occasionally it's let me resuscitate a drive long enough to save some data. Good luck on getting your data back; the lady I was helping didn't have any. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: diff included in commit mail
On Fri, Mar 12, 2004 at 02:14:42AM +0100, Mark Santcroos wrote: Hi, I know it was discussed once somewhere, but I can't find the thread in question. What I would like to be able to do is see the actual commit included in the mail. I know it can't be done at the moment the message arrives, as that is before it arrives in my cvs tree. On my machine I have the cvs repo mirrored, so doing it in realtime is no problem. This won't help, since your local repo won't contain the commit that was just made. Fortunately, it's not required. Does anybody have scripts or whatever available to do this? Install the cvsmail port. Kris pgp0.pgp Description: PGP signature
Re: add cvs -W option to disable -R/CVSREADONLYFS
Norikatsu Shigemura writes: Although I am checkout-ing well by using cvs -R in ~/.cvsrc, when I want to commit, It is prevented by -R. So I wanted to disable this feature. Use the global -f option to ignore ~/.cvsrc. -Larry Jones Ever notice how tense grown-ups get when they're recreating? -- Calvin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make install (kernel) without /modules dir
Roman Kurakin wrote:
I forget to say that this problem is for 4. branch
Roman Kurakin wrote:
Hi,
It seems that I've found another problem. If /modules dir would be
removed,
make install (of kernel and kernel modules) will not create modules
dir and you'll
get /modules file with one of the modules inside.
One of the variants is to add flag -d to install or other to mkdir -p
explicitly:
--- Makefile.oldFri Mar 12 00:13:45 2004
+++ MakefileFri Mar 12 00:15:03 2004
@@ -626,6 +626,7 @@
cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old; \
fi;
.endif
+ mkdir -p ${DESTDIR}/modules
cd $S/modules ; env ${MKMODULESENV} ${MAKE} install
modules-reinstall modules-reinstall.debug:
An old problem. 5.x is only partly affected by this, because
of a side effect of kern.post.mk creating the necessary directory,
but if you attempt to install from src/sys/modules/ when
/boot/kernel doesn't exist, it exhibits the same behavior.
In RELENG_4 the situation is worse, as even make installkernel
can exhibit such behavior. I once had a patch locally that adds
make hierarchy to the installkernel path, similar to how this
is done for installworld.
The problem is not unique to just kernel modules; if you attempt
to install src/bin/ when /bin doesn't exist you'll see the same
behavior, that's why I think the below change is not quite
incorrect.
I believe there's a PR open on this (probably even assigned to
myself), but I just don't have a clever idea of how to fix it
properly, sorry -- generally, standard directories are created
with mtree(8), and not with mkdir(1).
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: off topic - disk crash
Clifton Royston [EMAIL PROTECTED] writes: Today an important (no backup of course) 46 GB IBM Deskstar IDE disk crashed. This specific line of drives is infamous for a failure rate that's at least a full order of magnitude above the industry average for ATA drives. Google a bit for it. Not the entire DeskStar line, just the 75GXP series. I still have several 16Gs and at least one 60GXP that have never given me any trouble, and they were fast and silent for their time, head and shoulders ahead of the competition. These days I mostly buy WD... The disk boots into FreeBSD but already at power on time the disk does seek retries or some recalibration noise. Also known as the click of death... DES -- Dag-Erling Smrgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make install (kernel) without /modules dir
Ruslan Ermilov wrote:
Roman Kurakin wrote:
I forget to say that this problem is for 4. branch
Roman Kurakin wrote:
Hi,
It seems that I've found another problem. If /modules dir would be
removed,
make install (of kernel and kernel modules) will not create modules
dir and you'll
get /modules file with one of the modules inside.
One of the variants is to add flag -d to install or other to mkdir -p
explicitly:
misprint: -d flag should be -D flag
I forgot to check that this is only linux's install behavior.
--- Makefile.oldFri Mar 12 00:13:45 2004
+++ MakefileFri Mar 12 00:15:03 2004
@@ -626,6 +626,7 @@
cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old; \
fi;
.endif
+ mkdir -p ${DESTDIR}/modules
cd $S/modules ; env ${MKMODULESENV} ${MAKE} install
modules-reinstall modules-reinstall.debug:
An old problem. 5.x is only partly affected by this, because
of a side effect of kern.post.mk creating the necessary directory,
but if you attempt to install from src/sys/modules/ when
/boot/kernel doesn't exist, it exhibits the same behavior.
In RELENG_4 the situation is worse, as even make installkernel
can exhibit such behavior. I once had a patch locally that adds
make hierarchy to the installkernel path, similar to how this
is done for installworld.
The problem is not unique to just kernel modules; if you attempt
to install src/bin/ when /bin doesn't exist you'll see the same
behavior, that's why I think the below change is not quite
incorrect.
I believe there's a PR open on this (probably even assigned to
myself), but I just don't have a clever idea of how to fix it
properly, sorry -- generally, standard directories are created
with mtree(8), and not with mkdir(1).
If our install was like linux one which have -D flag, we could solve our
problem
by setting it globaly to install in sys.mk:
-INSTALL ?= install -D
+INSTALL ?= install -D
This flag dictates to create all necessary dirs if needed.
It would be nice to have such option, not -D of course.
My FreeBSD 3.4 machine tolds me that -D is debug flag.
Roman
Cheers,
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make install (kernel) without /modules dir
On Fri, Mar 12, 2004 at 06:08:22PM +0300, Roman Kurakin wrote: [...] If our install was like linux one which have -D flag, we could solve our problem by setting it globaly to install in sys.mk: -INSTALL ?= install -D +INSTALL ?= install -D This flag dictates to create all necessary dirs if needed. It would be nice to have such option, not -D of course. $ install file foo/bar Should it install file as foo/bar or should it create the foo/bar directory and install it as foo/bar/file? ;) Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: make install (kernel) without /modules dir
Roman Kurakin [EMAIL PROTECTED] writes: If our install was like linux one which have -D flag, we could solve our problem by setting it globaly to install in sys.mk: [...] My FreeBSD 3.4 machine tolds me that -D is debug flag. install(1) no longer has a -D option (since May 2001), so there's nothing to stop someone from reusing it for this purpose. Why are you still running 3.4? DES -- Dag-Erling Smrgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using Kernel level mutex in FreeBSD 4.8
Hi Artis.. Thanks a lot for the information. I tried using the splimp(..) and splx(..) within my driver and it works for the fisrt go. But when i tried to do network activity like pinging another machine then my application using the driver crashes. The behavior is very erratic...in some cases it works even when doing theg network operation but in another sitautaion it just crashes.. can u help me why this is happening..is there anything else i need to do.. also any idea that in FreeBSD how does one determine the spl level at which a device's interrupt routines execute Thanks a lot for ur help Artis Caune [EMAIL PROTECTED] wrote: afaik 4.x use spl(9) int s; s = splimp(); ... critical code ... splx(s); On Thu, 11 Mar 2004 05:33:02 -0800 (PST), jitendra pande wrote: Hi, I am trying to use kernle level mutex in my driver for FreeBSD 4.8. I tried searching for kernel level mutex but couldn't find any information on the same. The kernel level mutex functions mtx_lock(..), mutex(..), mtx_init(..) and other mtx_ functions are available from FreeBSD 5.0 onwards and not in FreeBSD 4.8. Kindly adavice me how should i proceed. Also is there anything like Gaint lock in FreeBSD 4.8. If so then how can i use it. Any early reply will be of great help. Thanks in advance Jitendra - Do you Yahoo!? Yahoo! Search - Find what youâre looking for faster. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Artis ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: inetd needs discard service in /etc/services
On Fri, Mar 12, 2004 at 10:51:13AM +, David Malone wrote:
I would like to commit the following patch. It changes the port from
discard to syslog and documents the dependency. I choose syslog because
it really does need to be in /etc/services on most machines since it
starts before NIS. I'll also file a PR against inetd in hopes that
someone gets board enough to fix it some day.
getaddrinfo can also accept numeric service names (ie. port numbers
in the case of UDP/TCP). I wonder if it would be better to just
replace the service name with 1 or some such? I guess that would
also fix your problem.
Nope, I tried that. It turns out there's an annoying edge case that
makes it not work in this case (from line 496):
* check for special cases. (1) numeric servname is disallowed if
* socktype/protocol are left unspecified. (2) servname is disallowed
* for raw and other inet{,6} sockets.
The real problem is that we should either not use getaddrinfo to make
sockaddrs or we should do it on demand when we actually have what we
need (i.e. a service name and protocol).
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp0.pgp
Description: PGP signature
Re: Intel i8xx watchdog driver
On Thu, Mar 11, 2004 at 07:07:36PM -0600, Wm. Daryl Hawkins wrote: I would love to incorporate it in both source trees if possible. Before it goes into current, I need to make some changes so that it will work with Poul-Henning Kamp's new watchdog driver model. Hopefully, I'll get to work on that some tomorrow. I'll release a new version for current as soon as it's ready. Excellent, I was just going to suggest that. On the subject of 'bits and bobs that hang off buses', Stacy Millions wrote a driver for the FWH RNG, and Doug Ambrisko rolled some code to flash the FWH on an i845 chipset if memory serves... I am happy to look at your code once it fits better with what we currently have providing I have time. Good work BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make install (kernel) without /modules dir
Dag-Erling Smrgrav wrote: Roman Kurakin [EMAIL PROTECTED] writes: If our install was like linux one which have -D flag, we could solve our problem by setting it globaly to install in sys.mk: [...] My FreeBSD 3.4 machine tolds me that -D is debug flag. install(1) no longer has a -D option (since May 2001), so there's nothing to stop someone from reusing it for this purpose. Why are you still running 3.4? This is an old well configured server. New one will run 5.2.1 when I'll get enought time to configure it and test all applications. :-) This is an old good rule if it works do not touch it. rik DES ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make install (kernel) without /modules dir
Ruslan Ermilov wrote: On Fri, Mar 12, 2004 at 06:08:22PM +0300, Roman Kurakin wrote: [...] If our install was like linux one which have -D flag, we could solve our problem by setting it globaly to install in sys.mk: -INSTALL ?= install -D +INSTALL ?= install -D This flag dictates to create all necessary dirs if needed. It would be nice to have such option, not -D of course. $ install file foo/bar Should it install file as foo/bar or should it create the foo/bar directory and install it as foo/bar/file? ;) two variants 1. cp style (you can write foo/bar or foo/bar/ to get what you want) 2. linux's install -D style: foo - dirname, bar filename Cheers, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
IPSEC/NAT/Gateway Query
Hi all, I currently have an issue of how open the whole WiFi tends to be, so, as all good people should do, I've started implementing a IPSec encryption system rather than the rather disappointing WEP. I'm encrypting all data to and from the gateway, which isn't a problem. This was documented rather well all over the internet. What I'm having an issue, is if the client has a range of RFC 1918 addresses behind it, and I have to introduce NAT into the equation. I've best tracked it down to the order that the kernel looks at the packets to decide what to do with it. This is where I stand at the moment. x.y.z.11 - x.y.z.254 : works perfectly x.y.z.11 - x.y.z.254 - 0.0.0.0 : works perfectly rfc 1918 - x.y.z.11 - x.y.z.254 : Fails rfc 1918 - x.y.z.11 - x.y.z.254 - 0.0.0.0 : Fails The connection between x.y.z.11 and x.y.z.254 is there the IPSec takes place, and is the only part off the wire as it were. The issue presents itself as the packet, from an rfc 1918 address, goes to the client box, gets inspected by the VPN rules, which are currently set to match on the external address of the client machine, and is subsequently overlooked by the VPN. The packet then goes on, gets NATed, and goes out as a unencrypted packet, from x.y.z.11. Thats a generally undesired transport mode. On x.y.z.254, the packet goes back via the IPSec tunnel, but is then not un-NATed. All I believe should be required, is for the RFC 1918 packet to be NATed to the external IP address, BEFORE it is inspected by the IPSec system. So basically, all I'm really asking, is am I on the right line of thinking, or have I just gone off on a complete tangent to where I should be headed. Any ideas/input would be greatly appreciated. Regards Neil Fenemor Senior Systems Administrator ThePacific.net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
power mgmt woes on CURRENT with Dell Latitude C610
Hi. I just upgraded my laptop (Dell Latitude C610 A16 BIOS) to CURRENT and most things work dandy. However, I'm having trouble getting power management to work. Suspending the laptop is abig deal for me, so I'd like to get a decent workaround or fix and I'm happy to help. Here are the details. With ACPI enabled, sleeping to S1 leaves the LCD on and fan running, sleeping to S3 suspends the way apm did under 4.9, but immediately after suspend is complete (screen goes out, fan stops) the keyboard LEDs flash and the system reboots from power off. Not so good. I can't turn ACPI off, because I panic (page fault in supervisor mode) on boot up. It looks like pcib is expecting acpi to be there, though it isn't. Apm worked fine under 4.9, so I think if I could get ACPI out of the way, I could use apm again and be happy. I've tried many combinations of partially disabling ACPI and kernels with and without SMP and apic. This is really easy to reproduce with GENERIC, and I'm happy to experiment and pass on debugging results if someone's interested in the data. Let me know what you need. I'd love to get this working, so I can play with -CURRENT more. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgp0.pgp Description: PGP signature
NFS client side bug fixes that probably apply to FBsd-4 and 5.
I believe that #1 and #2 applies to FreeBSD-4.x and might apply to 5.x, and #3 probably applies to 5.x and might apply to 4.x. #1 and #2 may or may not apply to 5.x depending on how you handle software interrupts, but I expect they might due to thread switching in the mutex code and preemption. Generally the symptoms of these bugs are a locked up NFS mount but an otherwise working system. The window of opportunity is fairly small for these in 4.x and they seem to have been around for a long time, but I expect it should be possible to trip over them occassionally even in 4.x. I can trip them in DFly within an hour due to the larger window of opportunity in DFly (due in part to additional thread switches in the pru_send code). I don't know about 5.x. -Matt Matthew Dillon [EMAIL PROTECTED] dillon 2004/03/12 19:13:53 PST DragonFly src repository Modified files: sys/vfs/nfs nfs.h nfs_socket.c Log: Fix a bunch of NFS races. These races existed in FreeBSD 4.x but are more likely to occur now due to the additional thread switching that DragonFly performs when doing things like sending UDP packets. Three bugs are being fixed: * nfs_request() adds the request to the nfs_timer queue before doing initial processing (e.g. transmission) of the request. The initial transmission of the request will race between nfs_request and nfs_timer, potentially causing the congestion window calculation (nm_sent) to be bumped twice instead of once. This eventually closes the congestion window permanently and causes the NFS mount to freeze. (Additionally the request could be transmitted twice unnecessarily, also fixed). * Updates to rep-r_flags and nmp-nm_sent were not being properly protected against nfs_timer due to splsoftclock() being released too early. All such accesses are now protected. * nfs_reply() depends on nfs_rcvlock to do an interlock check to see if the request has already been replied, but nfs_rcvlock() only does this if it cannot immediately get the receiver lock. The problem is that the NFS code in between request transmission and nfs_reply() can block, potentially allowing a reply to be returned to another nfsiod. The NFS receiver winds up getting stuck waiting for a reply that has already been returned. nfs_rcvlock() now unconditionally checks to see if the reply has already occured before entering the loop. Revision ChangesPath 1.6 +9 -8 src/sys/vfs/nfs/nfs.h 1.14 +37 -14src/sys/vfs/nfs/nfs_socket.c http://www.dragonflybsd.org/cvsweb/src/sys/vfs/nfs/nfs.h.diff?r1=1.5r2=1.6f=h http://www.dragonflybsd.org/cvsweb/src/sys/vfs/nfs/nfs_socket.c.diff?r1=1.13r2=1.14f=h ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
