poll()-ing a pipe descriptor, watching for POLLHUP
Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? Thanks, Vlad poll.cpp Description: Binary data ___ 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: poll()-ing a pipe descriptor, watching for POLLHUP
Hm, according to the code at http://www.greenend.org.uk/rjk/2001/06/poll.html, it seems to work as expected (returning both POLLIN and POLLHUP), when closing the write end of the pipe from within the same process. On Wed, Jun 3, 2009 at 3:15 PM, Vlad Galu d...@dudu.ro wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? Thanks, Vlad ___ 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: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. pgpztAkKQhW1z.pgp Description: PGP signature
Re: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov kostik...@gmail.com wrote: On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. Aaarhg! You're right! Sorry for the noise! ___ 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: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 3, 2009 at 3:35 PM, Vlad Galu d...@dudu.ro wrote: On Wed, Jun 3, 2009 at 3:32 PM, Kostik Belousov kostik...@gmail.com wrote: On Wed, Jun 03, 2009 at 03:15:32PM +0300, Vlad Galu wrote: Hello, Please take a look at the attached code. Shouldn't poll() get a POLLHUP event when the child process exits, closing the write end of the pipe? It seems that you code forgot to close the write end of the pipe in parent. Thus, pipe is referenced by another file descriptor from the parent process, and you do not get close event. Aaarhg! You're right! Sorry for the noise! Hm, I was having an issue with an internal piece of software, but never checked what kind of pipe caused the problem. Turns out it was a FIFO, and I got bitten by the same bug described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html The problem is that the reader process isn't notified when the writer process exits or closes the FIFO fd... ___ 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: ZFS booting without partitions
OK, so I've got my next little adventure here to share :-) ... after reading Your posts I was very eager to give the whole boot-zfs-without-partitions thing a new try. My starting situation was a ZFS mirror made up, as I wrote, of two GPT partitions, so my pool looked like: phaedrus# zpool status pool: tank state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM tank ONLINE 0 0 0 ad6p4 ONLINE 0 0 0 ad4p4 ONLINE 0 0 0 it was root-mounted and everything was seemingly working fine, with the machine surviving several bonnie++'s, sysbenches, and supersmacks concurrently for many hours (cool!). So to give it another try my plan was to detach one partition, clear the gmirror on the UFS boot partition, make a new pool made out of the free disk and start the experiment over. it looked almost like this: zpool offline tank ad4p4 zpool detach tank ad4p4 gmirror stop gmboot (made out of ad6p2 and ad4p2) gmirror remove gmboot ad4p2 then I had to reboot cause it wouldn't give up on the swap partition on the zpool. That's where the first problem began: it wouldn't boot anymore... just because I removed a device? In this case I was stuck at the mountroot: stage. It wouldn't find the root filesystem on zfs. (this happened also when physically detaching ad4). So I booted off a recent 8-CURRENT iso DVD, and although the mounroot stage is, iirc, at a later stage than the loader, I smelled it could have something to do with it and downloaded Adam's CURRENT/ZFS loader, put it in the appropriate place on my UFS boot partition... note: From the CD, I had to import the pool with zpool import -o altroot=/somewhere tank to avoid having problems with the datasets being mounted on top of the 8-fixit environment's /usr ... Ok, rebooted, and whoops it would boot again in the previous environment. So... from there I started over with the creation of a ZFS-bootonly situation on ad4 (with the intention of zpool-attaching ad6 later on) dd if=/dev/zero bs=1m of=/dev/ad4 count=200 (just to be safe, some 'whitespace'..) zpool create esso da4 zfs snapshot -r t...@night zfs send -R t...@night | zfs recv -d -F esso (it did what it had to do - cool new v13 feature BTW!) zpool export esso dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1 dd if=/boot/zfsboot of=/dev/ad4 bs=512 skip=1 seek=1024 zpool import esso zpool set bootfs=esso esso the mountpoints (legacy on the poolfs, esso, and the corresponding ones) had been correctly copied by the send -R. Just shortly mounted esso somewhere else, edited loader.conf and fstab, and put it back to legacy. shutdown -r now. Upon boot, it would wait a while, not present any F1/F5, and booted into the old environment (ad6p2 boot partition and then mounted tank as root). From there, a zfs list or zpool status just showed the root pool (tank), but the new one (esso) was not present. A zpool import showed: heidegger# zpool import pool: esso id: 865609520845688328 state: UNAVAIL status: One or more devices are missing from the system. action: The pool cannot be imported. Attach the missing devices and try again. see: http://www.sun.com/msg/ZFS-8000-3C config: essoUNAVAIL insufficient replicas ad4 UNAVAIL cannot open zpool import -f esso did not succeed, instead, looking on the console, I found ZFS: WARNING: could not open ad4 for writing I repeated the steps above two more times, making sure I had wiped everyhing off ad4 before trying... but it would always come up with that message. The disk is OK, the cables too, I triple-checked it. Besides, writing to the disk with other means (such as dd or creating a new pool) succeeded... (albeit after the usual sysctl kern.geom.debugflags=16 ...) well for now I think I'll stick to the GPT + UFS Root + ZFS Root solution (I'm so happy this works seemlessly, so this is a big THANX and not a complaint!), but I thought I'd share the latest hickups... I won't be getting to that machine for a few days before restoring to the gpt-ufs-based mirror, so if someone would like me to provide other info I'll be happy to contribute it. Big Regards! Lorenzo On 01.06.2009, at 19:09, Lorenzo Perone wrote: On 31.05.2009, at 09:18, Adam McDougall wrote: I encountered the same symptoms today on both a 32bit and 64bit brand new install using gptzfsboot. It works for me when I use a copy of loader from an 8-current box with zfs support compiled in. I haven't looked into it much yet but it might help you. If you want, you can try the loader I am using from: http://www.egr.msu.edu/~mcdouga9/loader Thanx for posting me your loader, I'll try with this tomorrow night! (any hint, btw, on why the one in -STABLE seems to be broken, or whether it has actually been fixed by now?) ___ freebsd-stable@freebsd.org mailing list
Re: Do you use a value other than AUTO for network_interfaces?
On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? Do you actually do this? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! The deprecation is a change relative to 7.0, but was in 7.1. -- Brooks pgpuOce7pt6kS.pgp Description: PGP signature
Re: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote: Hm, I was having an issue with an internal piece of software, but never checked what kind of pipe caused the problem. Turns out it was a FIFO, and I got bitten by the same bug described here: http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html The problem is that the reader process isn't notified when the writer process exits or closes the FIFO fd... So you did found the relevant PR with long audit trail and patches attached. You obviously should contact the author of the patches, Oliver Fromme, who is FreeBSD committer for some time (CCed). I agree that the thing shall be fixed finally. Skimming over the patches in kern/94772, I have some doubts about removal of POLLINIGNEOF flag. The reason is that we are generally do not remove exposed user interfaces. pgpHiZR2gixgh.pgp Description: PGP signature
Re: ZFS NAS configuration question
Dan Naumov wrote: Reading that made me pause for a second and made me go WOW, this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) I wrote a script implementing the most useful features of the solaris live upgrade, the only thing missing is selecting a boot-environment from the loader and freebsd-update support as I write the script on a system running current. I use this on all my freebsd-zfs boxes and it is extremely useful! http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE greetings, philipp ___ 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
On the topic of network_interfaces, optional full automatic renaming of interfaces
Hi lists, Now the topic of network_interfaces has been mentioned, and the freeze for 8-stable is near I wonder if there is enough interest in the following feature to be included: http://ruben.is.verweg.com/stuff/freebsd/ifrename/ There is some dust there in that directory (It works, but is nowhere finished yet), but basically this early rc.d script takes the functionality of ifconfig_XXX_name a step further and enables optional automatic renaming of all ethernet capable interfaces, and enumerate them in the order probed by the kernel. A possible usage scenario is where you do massive imaging of a freebsd installation in where you don't know beforehand it will end up on hardware that has Broadcom or Intel NICs but it is for certain the cable will be connected to the first interface available and the same interface name can be referenced throughout all configuration files that need it (pf.conf, rc.conf(.local), /etc/rc.conf.d/network ) An other application usage is nailing down interface names using ethernet address, either because of correcting mistakes in the hardware (e.g. some Dell PowerEdges have the port labelled first to be probed as second and vice versa) or the necessity to only allow that interface to exist if it's MAC is the one that was configured (because of switch port ACL's) Regards, Ruben ___ 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: ZFS NAS configuration question
Anyone else think that this combined with freebsd-update integration and a simplistic menu GUI for choosing the preferred boot environment would make an _awesome_ addition to the base system? :) - Dan Naumov On Wed, Jun 3, 2009 at 5:42 PM, Philipp Wuenschecryx-free...@h3q.com wrote: I wrote a script implementing the most useful features of the solaris live upgrade, the only thing missing is selecting a boot-environment from the loader and freebsd-update support as I write the script on a system running current. I use this on all my freebsd-zfs boxes and it is extremely useful! http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE greetings, philipp ___ 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: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote:
On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote:
Hm, I was having an issue with an internal piece of software, but
never checked what kind of pipe caused the problem. Turns out it was a
FIFO, and I got bitten by the same bug described here:
http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html
The problem is that the reader process isn't notified when the writer
process exits or closes the FIFO fd...
So you did found the relevant PR with long audit trail and patches
attached. You obviously should contact the author of the patches,
Oliver Fromme, who is FreeBSD committer for some time (CCed).
I agree that the thing shall be fixed finally. Skimming over the
patches in kern/94772, I have some doubts about removal of
POLLINIGNEOF flag. The reason is that we are generally do not
remove exposed user interfaces.
I forward-ported Bruce' patch to the CURRENT. It passes the tests
from tools/regression/fifo and a test from kern/94772.
For my liking, I did not removed POLLINIGNEOF.
diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c
index 66963bc..7e279ca 100644
--- a/sys/fs/fifofs/fifo_vnops.c
+++ b/sys/fs/fifofs/fifo_vnops.c
@@ -226,11 +226,47 @@ fail1:
if (ap-a_mode FREAD) {
fip-fi_readers++;
if (fip-fi_readers == 1) {
+ SOCKBUF_LOCK(fip-fi_readsock-so_rcv);
+ if (fip-fi_writers 0)
+ fip-fi_readsock-so_rcv.sb_state |=
+ SBS_COULDRCV;
+ else
+ /*
+* Sloppy? Might be necessary to clear it
+* in all the places where fi_readers is
+* decremented to 0. I think only writers
+* polling for input could be confused by
+* having it not set, and there is a problem
+* with these anyway now that we have
+* reversed the sense of the flag -- they
+* now block (?), but shouldn't.
+*/
+ fip-fi_readsock-so_rcv.sb_state =
+ ~SBS_COULDRCV;
+ SOCKBUF_UNLOCK(fip-fi_readsock-so_rcv);
SOCKBUF_LOCK(fip-fi_writesock-so_snd);
fip-fi_writesock-so_snd.sb_state = ~SBS_CANTSENDMORE;
SOCKBUF_UNLOCK(fip-fi_writesock-so_snd);
if (fip-fi_writers 0) {
wakeup(fip-fi_writers);
+ SOCKBUF_LOCK(fip-fi_readsock-so_rcv);
+ if (fip-fi_writers 0)
+ fip-fi_readsock-so_rcv.sb_state |=
+ SBS_COULDRCV;
+ else
+ /*
+* Sloppy? Might be necessary to clear it
+* in all the places where fi_readers is
+* decremented to 0. I think only writers
+* polling for input could be confused by
+* having it not set, and there is a problem
+* with these anyway now that we have
+* reversed the sense of the flag -- they
+* now block (?), but shouldn't.
+*/
+ fip-fi_readsock-so_rcv.sb_state =
+ ~SBS_COULDRCV;
+ SOCKBUF_UNLOCK(fip-fi_readsock-so_rcv);
sowwakeup(fip-fi_writesock);
}
}
@@ -244,6 +280,7 @@ fail1:
if (fip-fi_writers == 1) {
SOCKBUF_LOCK(fip-fi_readsock-so_rcv);
fip-fi_readsock-so_rcv.sb_state = ~SBS_CANTRCVMORE;
+ fip-fi_readsock-so_rcv.sb_state |= SBS_COULDRCV;
SOCKBUF_UNLOCK(fip-fi_readsock-so_rcv);
if (fip-fi_readers 0) {
wakeup(fip-fi_readers);
@@ -672,28 +709,10 @@ fifo_poll_f(struct file *fp, int events, struct ucred
*cred, struct thread *td)
levents = events
(POLLIN | POLLINIGNEOF | POLLPRI | POLLRDNORM | POLLRDBAND);
if ((fp-f_flag FREAD) levents) {
- /*
-* If POLLIN or POLLRDNORM is requested and POLLINIGNEOF is
-* not, then convert the first two to the last one. This
-* tells the socket poll function to ignore EOF so that we
-* block if there is no writer (and no
Re: Do you use a value other than AUTO for network_interfaces?
Doug Barton wrote: If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Maybe I am wrong, setting network_interfaces is the way I found I had to use to be able to rename cloned interfaces. eg: network_interfaces=lo0 em0 dmz ifconfig_em0=up cloned_interfaces=vlan0 ifconfig_vlan0_name=dmz ifconfig_dmz=192.168.34.129/24 vlan 2 vlandev em0 I seem to remember I had to put that 'dmz' in network_interfaces, to make everything happy at boot. I can do more tests if needed. Ciao, Angelo. ___ 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: Do you use a value other than AUTO for network_interfaces?
On Wed, Jun 03, 2009 at 06:18:01PM +0200, Angelo Turetta wrote: Doug Barton wrote: If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Maybe I am wrong, setting network_interfaces is the way I found I had to use to be able to rename cloned interfaces. eg: network_interfaces=lo0 em0 dmz ifconfig_em0=up cloned_interfaces=vlan0 ifconfig_vlan0_name=dmz ifconfig_dmz=192.168.34.129/24 vlan 2 vlandev em0 I seem to remember I had to put that 'dmz' in network_interfaces, to make everything happy at boot. I can do more tests if needed. Hmm, there might be a bug related to cloned interfaces and renaming. That should be easy to fix. -- Brooks pgpkLjbT4ZI0N.pgp Description: PGP signature
Re: Do you use a value other than AUTO for network_interfaces?
On Wed, Jun 03, 2009 at 09:13:21AM -0500, Brooks Davis wrote: On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? Do you actually do this? We do use modules for a number of machines instead of leaving the NIC driver compiled into the kernel. I think that the impetus for doing this involved a driver bug back in 6.1 which crashed the machine if it passed too much traffic. The thinking was that for future bugs, it would be easier and faster to ship off the kernel module, unload the old one, load the new one, and reconfigure the interface than to ship over a whole new kernel and reboot. We also used to have a couple of machines for which the vendor supplied NIC kernel modules, but I don't think that they're in use anymore. And yes, the machines use network_interfaces to load the modules, though I'm not arrogant enough to assume that this is the best way. Maybe it is worth considering changing ifconfig_$DRIVER to load the driver? Erik ___ 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: poll()-ing a pipe descriptor, watching for POLLHUP
On Wed, 3 Jun 2009, Kostik Belousov wrote:
On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote:
On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote:
Hm, I was having an issue with an internal piece of software, but
never checked what kind of pipe caused the problem. Turns out it was a
FIFO, and I got bitten by the same bug described here:
http://lists.freebsd.org/pipermail/freebsd-bugs/2006-March/017591.html
The problem is that the reader process isn't notified when the writer
G process exits or closes the FIFO fd...
So you did found the relevant PR with long audit trail and patches
attached. You obviously should contact the author of the patches,
Oliver Fromme, who is FreeBSD committer for some time (CCed).
I agree that the thing shall be fixed finally. Skimming over the
patches in kern/94772, I have some doubts about removal of
POLLINIGNEOF flag. The reason is that we are generally do not
remove exposed user interfaces.
Maybe, but this flag was not a documented interface, and too much
ugliness might be required to preserve its behaviour bug-for-bug
compatibly (the old buggy behaviour would probably be more wanted
for compatibility than the strange behaviour given by this flag!
I forward-ported Bruce' patch to the CURRENT. It passes the tests
from tools/regression/fifo and a test from kern/94772.
Thanks. I won't be committing it any time soon, so you should.
I rewrote the test programs extensively (enclosed at the end) in Oct
2007 and updated the kernel patches to match. Please run the new tests
to see if you are missing anything important in the kernel part. If
so, I will search for the kernel patches later (actually, now --
enclosed in the middle). I just ran them under RELENG_7 and unpatched
-current and found no differences with the Oct 2007 version for RELENG_7
in the old test output.
The old test output is in the following subdirectories:
4: FreeBSD-4
7: FreeBSD-7
l: Linux-2.6.10
m: my version of FreeBSD-5.2 including patches for this problem.
AFAIR, the FreeBSD output in m is the same as the Linux output in
all except a couple of cases where Linux select is inconsistent with
itself and/or with Linux poll. However, the differences in the saved
output are that the Linux output is mysteriously missing results for
tests 5-8. The tests attempt to test certain race possibilities in a
non-racy way. This is not easy and the differences might be due to
some races/states not occurring under Linux.
POSIX finally specified the behaviour strictly enough for it to be possible
to test it a couple of years ago. I didn't follow all the developments
and forget the details, but it was close to the Linux behaviour.
For my liking, I did not removed POLLINIGNEOF.
diff --git a/sys/fs/fifofs/fifo_vnops.c b/sys/fs/fifofs/fifo_vnops.c
index 66963bc..7e279ca 100644
--- a/sys/fs/fifofs/fifo_vnops.c
+++ b/sys/fs/fifofs/fifo_vnops.c
@@ -226,11 +226,47 @@ fail1:
if (ap-a_mode FREAD) {
fip-fi_readers++;
if (fip-fi_readers == 1) {
+ SOCKBUF_LOCK(fip-fi_readsock-so_rcv);
+ if (fip-fi_writers 0)
+ fip-fi_readsock-so_rcv.sb_state |=
+ SBS_COULDRCV;
My current version is in fact completely different. It doesn't have
SBS_COULDRCV, but uses a generation count. IIRC, this is the same
method as is used in Linux, and is needed for the same reasons
(something to do with keeping new connections separate from old ones).
So I will try to enclose the components of the patch in the order of
your diff (might miss some). First one:
% Index: fifo_vnops.c
% ===
% RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
% retrieving revision 1.100
% diff -u -2 -r1.100 fifo_vnops.c
% --- fifo_vnops.c 23 Jun 2004 00:35:50 - 1.100
% +++ fifo_vnops.c 17 Oct 2007 11:36:23 -
% @@ -36,4 +36,5 @@
% #include sys/fcntl.h
% #include sys/file.h
% +#include sys/filedesc.h
% #include sys/kernel.h
% #include sys/lock.h
% @@ -61,4 +62,5 @@
% longfi_readers;
% longfi_writers;
% + int fi_wgen;
% };
%
% @@ -182,8 +184,11 @@
% struct ucred *a_cred;
% struct thread *a_td;
% + int a_fdidx;
% } */ *ap;
% {
% struct vnode *vp = ap-a_vp;
% struct fifoinfo *fip;
% + struct file *fp;
% + struct filedesc *fdp;
% struct thread *td = ap-a_td;
% struct ucred *cred = ap-a_cred;
% @@ -240,4 +245,10 @@
% }
% }
% + fdp = td-td_proc-p_fd;
% + FILEDESC_LOCK(fdp);
% + fp = fget_locked(fdp, ap-a_fdidx);
% + /* Abuse f_msgcount as a generation count. */
% + fp-f_msgcount = fip-fi_wgen - fip-fi_writers;
% + FILEDESC_UNLOCK(fdp);
% }
% if
mini-HEADSUP bce owners: please test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, David and I have committed some fixes to 7-STABLE tree, and I think all important bce(4) fixes has been merged now. If you have bce(4) interfaces PLEASE help us to test them, the simplest way of doing this is to sync your code with RELENG_7 and rebuild kernel. [1] For those who can't test this under 7-STABLE environment, I have extracted corresponding files here: http://people.freebsd.org/~delphij/misc/193358.tar.bz2 Once can extract the tarball over /usr/src/ in order to overwrite your files, this should be applicable for a 7.2-RELEASE system. Known issues that this should have resolved: - PHY write timeout! when you can find ukphy in your dmesg output, some blade servers [Dell T610?] may have this, in particular; - incorrect input traffic accounting. (netstat 1 would show larger input traffic); - under heavy load there might be some data corruption; Please let us know if these changes would bring any regressions, thanks a lot! [1] Please note that, because bce(4) is part of GENERIC kernel so you may need to do a full make kernel instead of just rebuilding/installing corresponding kernel module. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkom/0QACgkQi+vbBBjt66DPzwCfSpPZ+nCJcyjcrFwfZuWSCcyl anIAoKQN/jpn45pjS/jG2jR6dsjIWbhs =Eng2 -END PGP SIGNATURE- ___ 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: mini-HEADSUP bce owners: please test
David and I have committed some fixes to 7-STABLE tree, and I think all important bce(4) fixes has been merged now. If you have bce(4) interfaces PLEASE help us to test them, the simplest way of doing this is to sync your code with RELENG_7 and rebuild kernel. [1] I won't have timer to try this until friday at the earliest, but one question... is this likely to fix my infamous lagg/lacp issue ? I notice it isn't in the list of known issues. I will test anyway, but if you happen to be in that bit of code *does best winning smile* :-) -pete. ___ 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: mini-HEADSUP bce owners: please test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pete French wrote: David and I have committed some fixes to 7-STABLE tree, and I think all important bce(4) fixes has been merged now. If you have bce(4) interfaces PLEASE help us to test them, the simplest way of doing this is to sync your code with RELENG_7 and rebuild kernel. [1] I won't have timer to try this until friday at the earliest, but one question... is this likely to fix my infamous lagg/lacp issue ? I notice it isn't in the list of known issues. I will test anyway, but s/known issue/known and fixed issue/ ... if you happen to be in that bit of code *does best winning smile* :-) I am not quite sure about the lagg/lacp issue, perhaps we need more clue like tcpdump compare between old code and new code, as I don't have a switch capable for lacp setup at hand at this moment :( Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkonBJ4ACgkQi+vbBBjt66DXLwCdGAw0UFfrVYmNDTlwpbCnfMsm clMAoLrv0APr2//LiWCbTuS31qbzpsBz =Om0W -END PGP SIGNATURE- ___ 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: mini-HEADSUP bce owners: please test
David and I have committed some fixes to 7-STABLE tree, and I think all important bce(4) fixes has been merged now. If you have bce(4) interfaces PLEASE help us to test them, the simplest way of doing this is to sync your code with RELENG_7 and rebuild kernel. [1] I won't have timer to try this until friday at the earliest, but one question... is this likely to fix my infamous lagg/lacp issue ? I notice it isn't in the list of known issues. I will test anyway, but if you happen to be in that bit of code *does best winning smile* :-) That should be the packet length fix at line 5973 of if_bce.c. I did not test the teaming fix myself but another user provided a similar packet length fix which he claimed did fix the issue so I'm hopeful that this should work for you too. Dave ___ 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
Update Account.
** THIS IS AN AUTOMATED EMAIL - . ** Dear Moneybookers Customer,: Due to concerns, for the safety and integrity of the Moneybookers.com account we have issued this warning message. It has come to our attention that your Moneybookers.com account information needs to be updated as part of our continuing commitment to protect your account and to reduce the instance of fraud on our website. If you could please take 5-10 minutes out of your online experience and update your personal records you will not run into any future problems with the online service. Once you have updated your account records your Moneybookers.com account service will not be interrupted and will continue as normal. To update your Moneybookers.com records click on the following link: [1]http://Moneybookers.com/ Moneybookers Security Reminders Case Sensitive Login Please remember your password is case-sensitive, at least 6 characters long and contains at least one number or non-alphabetic character such as '-'. *** Moneybookers Ltd., London, Registered in England and Wales no 4260907. Registered office: Welken House, 10-11 Charterhouse Square, London, EC1M 6EH, United Kingdom. Authorised and regulated by the Financial Services Authority of the United Kingdom (FSA). References 1. http://www.protocolinfogate.com/moneybookers/directory.php?app=login.pl ___ 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
latest stable version of FreeBSD?
Where can I download the latest stable version of FreeBSD? ___ 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: latest stable version of FreeBSD?
On Wed, Jun 3, 2009 at 11:24 PM, AES allnetgr...@yahoo.com wrote: Where can I download the latest stable version of FreeBSD? http://www.freebsd.org/where.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ -- Glen Barber http://www.dev-urandom.com http://www.linkedin.com/in/glenjbarber ___ 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
