Re: Serial multiport error Oxford/Startech PEX2S952
On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: In message 20110822094756.gj92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. You could try hint.uart.2.baud=115200 in /boot/device.hints - making the relevant changes to port number and speed according to your needs. This does not help; speed remains set to 9600. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. It will be interesting to see if there is a difference between 8.x and 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. So, it appears that there is something wrong (or at least different) with 9.x Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. If I look at the 8.x .c files, they want #include sys/termios.h ... which appears to no longer be used. But adding either that, or #include termios.h ... produces errors: /usr/src/sys/dev/uart/uart_core.c:47:21: error: termios.h: No such file or directory /usr/src/sys/dev/uart/uart_tty.c:42:21: error: termios.h: No such file or directory mkdep: compile failed *** Error code 1 Though a fresh build of world seems to produce termios.h: # find /usr/obj/ |grep termios.h /usr/obj/usr/src/lib32/usr/include/sys/termios.h /usr/obj/usr/src/lib32/usr/include/sys/_termios.h /usr/obj/usr/src/lib32/usr/include/termios.h /usr/obj/usr/src/tmp/usr/include/termios.h /usr/obj/usr/src/tmp/usr/include/sys/termios.h /usr/obj/usr/src/tmp/usr/include/sys/_termios.h # But I may be completely confused here, as I don't pretend to be familiar with all of the details of the build process. Does this look like a bug with 9.x, or something that should be done differently? -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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
ports/sysutils/diskcheckd (Re: bad sector in gmirror HDD)
When the specified or calculated rate exceeds 64KB/sec, the
required sleep interval between 64KB chunks is less than one
second. Since diskcheckd calculates the interval in whole seconds
-- because it calls sleep() rather than usleep() or nanosleep()
-- an interval of less than one second is calculated as zero ...
I suspect the fix will be to calculate in microseconds, and call
usleep() instead of sleep().
I think I may have this fixed.
Could one of you try the attached patch? I'm especially interested
to see if this also clears up the issues reported as connected with
gmirror (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566),
since I haven't been able to reproduce that part here.
Summary of changes:
* Calculate delays in microseconds, so that delays of less than
one second between reads (needed to implement rates exceeding
64KB/sec) do not get rounded down to zero.
* Fix a reinitialization problem when handling SIGHUP.
* Additional debug messages (only with -d).
* Comment and manpage improvememts.
diff -ruN diskcheckd.old/files/diskcheckd.8 diskcheckd.new/files/diskcheckd.8
--- diskcheckd.old/files/diskcheckd.8 2001-08-28 22:16:22.0 -0700
+++ diskcheckd.new/files/diskcheckd.8 2011-08-24 07:09:16.0 -0700
@@ -58,15 +58,16 @@
The second format consists of four white space separated
fields,
which are the full pathname of the disk device,
-the size of that disk,
-the frequency in days at which to check that disk,
+the size of this disk,
+the frequency in days at which to check this disk,
and the rate in kilobytes per second at which to check this disk.
-Naturally,
-it would be contradictory to specify both the frequency and the rate,
-so only one of these should be specified.
-Additionally,
-the size of the disk should not be specified if the rate is specified,
-as this information is unnecessary.
+.Pp
+Either the frequency or the rate should be specified, not both,
+since a specified frequency will be internally converted to whatever
+rate will result in the disk being scanned at (approximately) that
+frequency.
+The size of the disk should not be specified if the rate is specified,
+since the size is used only to convert a specified frequency into a rate.
.Pp
If the disk is specified as
.Dq * ,
@@ -89,7 +90,7 @@
Note that
.Nm
always reads data from the disk in 64KB blocks,
-so the rate your specify may not be the exact rate at which the disk is
+so the rate you specify may not be the exact rate at which the disk is
actually checked.
Similarly,
if you specify the third field (days for complete scan) it is unlikely
@@ -132,8 +133,14 @@
If this flag is specified,
.Nm
will not fork into the background and detach from its controlling terminal
-to become a daemon.
-This flag is primarily used for debugging.
+to become a daemon,
+and it will duplicate its system log messages on its standard error output.
+.Pp
+This flag is primarily used for debugging,
+and may be specified more than once.
+Additional instances will result in additional
+debugging messages on standard error;
+these added messages will not be written to the system log.
.It Fl f
Specify the configuration file to use,
instead of the default
@@ -143,6 +150,13 @@
instead of the default
.Pa /var/db/diskcheckd.offsets .
.El
+.Sh PROGRESS REPORTING
+After every 5 minutes or so of sleep time between reads
+(not including time spent waiting for the reads themselves to complete),
+.Nm
+will update its command parameter space to show its progress
+in scanning each disk. This report can be viewed using
+.Xr ps 1 .
.Sh FILES
.Bl -tag -width /var/db/diskcheckd.offsets -compact
.It Pa /usr/local/etc/diskcheckd.conf
@@ -188,3 +202,6 @@
.Sh BUGS
.Nm
assumes all disks have 512 byte sectors.
+.Pp
+The code that attempts to identify and report which slice and partition
+contain a detected error does not understand GPT partitions.
diff -ruN diskcheckd.old/files/diskcheckd.c diskcheckd.new/files/diskcheckd.c
--- diskcheckd.old/files/diskcheckd.c 2004-10-27 22:18:33.0 -0700
+++ diskcheckd.new/files/diskcheckd.c 2011-08-24 07:05:00.0 -0700
@@ -63,10 +63,12 @@
char *device;
off_t size;
int secsize;
- int days, rate, errors, interval, next;
+ int days, rate, errors;
+ long long interval, next;
};
volatile sig_atomic_t got_sighup = 0, got_sigterm = 0;
+volatile int debug = 0;
char **getdisknames(char **, int);
off_t dseek(struct disk *, off_t, int);
@@ -85,9 +87,11 @@
main(int argc, char *argv[]) {
char *buf;
struct disk *disks, *dp;
- int ch, ok, minwait, nextwait;
+ int ch, ok;
+ long long minwait, nextwait;
struct sigaction sa;
- int counter, debug;
+ long long counter;
+ int initial_debug;
const char *conf_file, *save_file;
conf_file = _PATH_CONF;
@@ -97,7 +101,10 @@
while ((ch = getopt(argc, argv, df:o:)) != -1)
switch (ch)
CARP up at boot
I am trying to use a CARP/HAST setup for redundancy and reply on devd for the carp up/down events to trigger role switch for the nodes. What is interesting is that upon reboot, the CARP interface always first comes up, like this: carp0: link state changed to UP carp0: MASTER - BACKUP (more frequent advertisement received) carp0: link state changed to DOWN This causes devd to execute the event scripts as 'master' first, then shortly after execute the script as 'backup'. This may cause undesired writing to the hast providers and possibly split-brain condition. What is worse, on two hosts with the same advskew value if you reboot the BACKUP server, it would become MASTER. This results in all services teardown and starting them again on the new master. I understand that for routers, which is the original design goal for CARP it does not matter much if roles switch from time to time, but for high-latency startup systems, this is not desirable. It is best when a node becomes MASTER it stays MASTER until failure and not change state when the other node is rebooted. Perhaps CARP and devd are not the best tool, but it will help if at least the carp interface does not start as MASTER and if it waits longer, before requesting to become MASTER after reboot. ___ 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
xterm - truetype fonts and missing underscore
Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ 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: Serial multiport error Oxford/Startech PEX2S952
Hi Greg, In message 20110824070826.gk92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: In message 20110822094756.gj92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. You could try hint.uart.2.baud=115200 in /boot/device.hints - making the relevant changes to port number and speed according to your needs. This does not help; speed remains set to 9600. It was worth a go. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. It will be interesting to see if there is a difference between 8.x and 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. It could be that setting speed in /boot/device.hints only works with ports directly handled by uart(4), not ports that uart(4) handles via puc(4). As 8-STABLE works, the support code I wrote and contributed works for your card, which is encouraging. So, it appears that there is something wrong (or at least different) with 9.x The best course of action is likely to be bringing up this problem on freebsd-current (as 9.x is not yet -stable) and filing a PR, noting the regression between 8-STABLE and 9-BETA. I'm fairly sure that the problem is likely to be in uart(4) or in something on which uart(4) rests, such as the tty layer. Even in 9-BETA puc(4) appears to be doing its job of identifying and configuring the ports before invoking uart(4) - so puc(4) doesn't appear to be to blame. Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. The commit logs for HEAD show that the inclusion of termios headers was removed as unnecessary (see r199872). I doubt that the problem is merely a missing header, not least as missing headers normally result in compilation failure. The isn't a terminal error you are getting indicates that the attempt to call tcgetaddr(3) on a file descriptor opened on the device is failing. Unfortunately, I am not familiar enough with the tty code to understand why that call is failing on 9.x. If posting on freebsd-current and filing a PR don't produce an answer, ed@ or kib@ may be able to throw some light. Those two committers are responsible for most of the relevant code, especially the tty layer. It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up isn't a terminal errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. With best wishes, David -- David Wood da...@wood2.org.uk ___ 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: Serial multiport error Oxford/Startech PEX2S952
On Wed, Aug 24, 2011 at 12:13:08PM +0100, David Wood wrote: Hi Greg, In message 20110824070826.gk92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: In message 20110822094756.gj92...@core.byshenk.net, Greg Byshenk free...@byshenk.net writes It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. You could try hint.uart.2.baud=115200 in /boot/device.hints - making the relevant changes to port number and speed according to your needs. This does not help; speed remains set to 9600. It was worth a go. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. It will be interesting to see if there is a difference between 8.x and 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. It could be that setting speed in /boot/device.hints only works with ports directly handled by uart(4), not ports that uart(4) handles via puc(4). As 8-STABLE works, the support code I wrote and contributed works for your card, which is encouraging. So, it appears that there is something wrong (or at least different) with 9.x The best course of action is likely to be bringing up this problem on freebsd-current (as 9.x is not yet -stable) and filing a PR, noting the regression between 8-STABLE and 9-BETA. I'm fairly sure that the problem is likely to be in uart(4) or in something on which uart(4) rests, such as the tty layer. Even in 9-BETA puc(4) appears to be doing its job of identifying and configuring the ports before invoking uart(4) - so puc(4) doesn't appear to be to blame. Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. The commit logs for HEAD show that the inclusion of termios headers was removed as unnecessary (see r199872). I doubt that the problem is merely a missing header, not least as missing headers normally result in compilation failure. The isn't a terminal error you are getting indicates that the attempt to call tcgetaddr(3) on a file descriptor opened on the device is failing. Unfortunately, I am not familiar enough with the tty code to understand why that call is failing on 9.x. If posting on freebsd-current and filing a PR don't produce an answer, ed@ or kib@ may be able to throw some light. Those two committers are responsible for most of the relevant code, especially the tty layer. It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up isn't a terminal errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help assist in this matter and shed some light on the above comments. If there's a quirk or bug there, I'm certain he'll assist in helping. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: -m32 on freeBSD 8.2r amd64
Maybe off topic?
1: echo int main(void) { return 0; } t.c
2: setenv LDEMULATION elf_i386_fbsd
3: gcc -c -m32 -o t.o t.c
4: gcc -nostartfiles -o a.out
t.o -L/usr/lib32 /usr/lib32/crt1.o /usr/lib32/crti.o
5: file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped
6: uname -m
amd64
2: q.v. info binutils - Selecting The Target System
Maybe there is a more comfortable way.
Michael
Am Tuesday 23 August 2011 09:46:11 schrieb Edho Arief:
On Tue, Aug 23, 2011 at 2:26 PM, noel beck nb...@hobsoft.com.mt wrote:
We are trying to compile i386 on a FreeBSD 8.2r amd64.
we are getting an error stating that libstdc++.so.6, is missing.
COMPACT6x and COMPACT7x have been installed. But this does not solve the
problem.
Is it possible to compile i386 on and amd64 system?
I believe compiler flags to /lib32 is required (-L/usr/lib32 or something)
___
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
Re: -m32 on freeBSD 8.2r amd64
On Wed, Aug 24, 2011 at 12:11 PM, Michael Hoffmann benz...@arcor.de wrote:
Maybe off topic?
1: echo int main(void) { return 0; } t.c
2: setenv LDEMULATION elf_i386_fbsd
3: gcc -c -m32 -o t.o t.c
4: gcc -nostartfiles -o a.out
t.o -L/usr/lib32 /usr/lib32/crt1.o /usr/lib32/crti.o
5: file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped
6: uname -m
amd64
2: q.v. info binutils - Selecting The Target System
Maybe there is a more comfortable way.
Michael
You don't need to go to all that effort:
$ uname -m
amd64
$ echo int main(void) { return 0; } t.c
$ gcc -c -m32 -o t.o t.c
$ gcc -m32 -o t t.o -B/usr/lib32
$ file t
t: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 8.2 (802510), not
stripped
Cheers
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: -m32 on freeBSD 8.2r amd64
On Wed, Aug 24, 2011 at 01:57:02PM +0100, Tom Evans wrote:
On Wed, Aug 24, 2011 at 12:11 PM, Michael Hoffmann benz...@arcor.de wrote:
Maybe off topic?
1: echo int main(void) { return 0; } t.c
2: setenv LDEMULATION elf_i386_fbsd
3: gcc -c -m32 -o t.o t.c
4: gcc -nostartfiles -o a.out
t.o -L/usr/lib32 /usr/lib32/crt1.o /usr/lib32/crti.o
5: file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped
6: uname -m
amd64
2: q.v. info binutils - Selecting The Target System
Maybe there is a more comfortable way.
Michael
You don't need to go to all that effort:
$ uname -m
amd64
$ echo int main(void) { return 0; } t.c
$ gcc -c -m32 -o t.o t.c
$ gcc -m32 -o t t.o -B/usr/lib32
$ file t
t: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 8.2 (802510), not
stripped
Well-known problem is that /usr/include/machine/*.h still contains
amd64 arch definitions. The resulting binary is broken in the quite
subtle ways.
pgp1knQx89Ipg.pgp
Description: PGP signature
Re: xterm - truetype fonts and missing underscore
24.08.2011 12:01, Tony Maher wrote: Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? +1 from me http://lists.nongnu.org/archive/html/freetype/2011-08/msg00020.html -- Sphinx of black quartz judge my vow. ___ 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: xterm - truetype fonts and missing underscore
Tony nbsp;nbsp;What else is in you .Xresources file . Also have you tried using xft formated font names . Ie xft:luxi mono:size=10 ? -- Mark Saad Mark.saad@longcount.orgOn Aug 24, 2011 7:08 AM, Tony Maher lt;tonyma...@optusnet.com.augt; wrote: Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ 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
Re: CARP up at boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/24/11 02:02, Daniel Kalchev wrote: I am trying to use a CARP/HAST setup for redundancy and reply on devd for the carp up/down events to trigger role switch for the nodes. Is this something at least at, or newer than 8.2-RELEASE? I think it's actually important for the devd script to make sure (wait, then check) that the state is stabilized before doing any action for use with HAST by the way. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOVTViAAoJEATO+BI/yjfB4ekIANBDTmvCgh+I60ZSXmf0ut+/ OPcZfgKwGrp66QQQdp9t6uePRnmYDYcqsjvGj2FeihB33sKgIMz+Jrw2cgoTlPDs VClE8kDkrxt3CH6B99SOnEY4oNI7Hepq+83PkQ5JDAqnqYCUq1ciWVbRLk8xXGZP tnlo6fGRc9grZWbSFPE+zbqPw74q3yQ1H9kjU87pu61xR5Bmt+5CIRy9yRHXTmrg O8fOIAlRoyqsTJhsV4acffD67llXlHeTv1wKFnvuuZ84ZIqMNmbuurlMYXBSrfxv QmwJcSkLTFOqFUzQ7ZJTZi8R6+vIYaAAIrNRCW8hxoL6lrebs09SJ5VZIt5h6go= =JqLT -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: stable/7/lib/msun/src/e_log2.c missing
On Wed, Jul 13, 2011, Dr. A. Haakh wrote: Oliver Pinter schrieb: On 7/12/11, Dr. A. Haakhbugrepor...@haakh.de wrote: log2() log2f have been MFCd to 8-STABLE (r216210 and r216210) but are still missing in 7-STABLE. See http://www.freebsd.org/cgi/getmsg.cgi?fetch=24955+47747+/usr/local/www/db/text/2011/freebsd-ports/20110612.freebsd-ports This breaks several ports. Any plans? [...] would be nice if it could be done. Given that 9.0-RELEASE is imminent and no further 7.X releases are expected, I wasn't planning on MFCing new functionality to 7-STABLE. But if it makes life easier for porters, I can look into it. ___ 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
sigwait return 4
System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... ___ 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: sigwait return 4
On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set pgpWlJF1UhSzz.pgp Description: PGP signature
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. ___ 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: sigwait return 4
On Wed, Aug 24, 2011 at 11:24:46PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? pgpgqCL1Hl1XD.pgp Description: PGP signature
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter HUP -B 1395 100199 kas-milter INT -B 1395 100199 kas-milter QUIT -- 1395 100199 kas-milter ILL -- 1395 100199 kas-milter TRAP -- 1395 100199 kas-milter ABRT -- 1395 100199 kas-milter EMT -- 1395 100199 kas-milter FPE -- 1395 100199 kas-milter KILL -- 1395 100199 kas-milter BUS -- 1395 100199 kas-milter SEGV -- 1395 100199 kas-milter SYS -- 1395 100199 kas-milter PIPE -- 1395 100199 kas-milter ALRM -- 1395 100199 kas-milter TERM -B 1395 100199 kas-milter URG -- 1395 100199 kas-milter STOP -- 1395 100199 kas-milter TSTP -- 1395 100199 kas-milter CONT -- 1395 100199 kas-milter CHLD -- 1395 100199 kas-milter TTIN -- 1395 100199 kas-milter TTOU -- 1395 100199 kas-milter IO -- 1395 100199 kas-milter XCPU -- 1395 100199 kas-milter XFSZ -- 1395 100199 kas-milter VTALRM -- 1395 100199 kas-milter PROF -- 1395 100199 kas-milter WINCH-- 1395 100199 kas-milter INFO -- 1395 100199 kas-milter USR1 -- 1395 100199 kas-milter USR2 -- 1395 100199 kas-milter 32 -- 1395 100199 kas-milter 33 -- 1395 100199 kas-milter 34 -- 1395 100199 kas-milter 35 -- 1395 100199 kas-milter 36 -- 1395 100199 kas-milter 37 -- 1395 100199 kas-milter 38 -- 1395 100199 kas-milter 39 -- 1395 100199 kas-milter 40 -- 1395 100199 kas-milter 41 -- 1395 100199 kas-milter 42 -- 1395 100199 kas-milter 43 -- 1395 100199 kas-milter 44 -- 1395 100199 kas-milter 45 -- 1395 100199 kas-milter 46 -- 1395 100199 kas-milter 47 -- 1395 100199 kas-milter 48 -- 1395 100199 kas-milter 49 -- 1395 100199 kas-milter 50 -- 1395 100199 kas-milter 51 -- 1395 100199 kas-milter 52 -- 1395 100199 kas-milter 53 -- 1395 100199 kas-milter 54 -- 1395 100199 kas-milter 55 -- 1395 100199 kas-milter 56 -- 1395 100199 kas-milter 57 -- 1395 100199 kas-milter 58 -- 1395 100199 kas-milter 59 -- 1395 100199 kas-milter 60 -- 1395 100199 kas-milter 61 -- 1395 100199 kas-milter 62 -- 1395 100199 kas-milter 63 -- 1395 100199 kas-milter 64 -- 1395 100199 kas-milter 65 -- 1395 100199 kas-milter 66 -- 1395 100199 kas-milter 67 -- 1395 100199 kas-milter 68 -- 1395 100199 kas-milter 69 -- 1395 100199 kas-milter 70 -- 1395 100199 kas-milter 71 -- 1395 100199 kas-milter 72 -- 1395 100199 kas-milter 73 -- 1395 100199 kas-milter 74 -- 1395 100199 kas-milter 75 -- 1395 100199 kas-milter 76 -- 1395 100199 kas-milter 77 -- 1395 100199 kas-milter 78 -- 1395 100199 kas-milter 79 -- 1395 100199 kas-milter 80 -- 1395 100199 kas-milter 81 -- 1395 100199 kas-milter 82 -- 1395 100199 kas-milter 83 -- 1395 100199 kas-milter 84 -- 1395 100199 kas-milter 85 -- 1395 100199 kas-milter 86 -- 1395 100199 kas-milter 87 -- 1395 100199 kas-milter 88 -- 1395 100199 kas-milter 89 -- 1395 100199 kas-milter 90 -- 1395 100199 kas-milter 91 -- 1395 100199 kas-milter 92 -- 1395 100199 kas-milter 93 -- 1395 100199 kas-milter 94 -- 1395 100199 kas-milter 95 --
Re: sigwait return 4
On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. How is this statement related to the creation of the standalone test case ? # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter USR2 -- 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined. pgpOjMqGVVeyP.pgp Description: PGP signature
Re: sigwait return 4
On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter HUP -B 1395 100199 kas-milter INT -B 1395 100199 kas-milter QUIT -- 1395 100199 kas-milter ILL -- 1395 100199 kas-milter TRAP -- 1395 100199 kas-milter ABRT -- 1395 100199 kas-milter EMT -- 1395 100199 kas-milter FPE -- 1395 100199 kas-milter KILL -- 1395 100199 kas-milter BUS -- 1395 100199 kas-milter SEGV -- 1395 100199 kas-milter SYS -- 1395 100199 kas-milter PIPE -- 1395 100199 kas-milter ALRM -- 1395 100199 kas-milter TERM -B 1395 100199 kas-milter URG -- 1395 100199 kas-milter STOP -- 1395 100199 kas-milter TSTP -- 1395 100199 kas-milter CONT -- 1395 100199 kas-milter CHLD -- 1395 100199 kas-milter TTIN -- 1395 100199 kas-milter TTOU -- 1395 100199 kas-milter IO -- 1395 100199 kas-milter XCPU -- 1395 100199 kas-milter XFSZ -- 1395 100199 kas-milter VTALRM -- 1395 100199 kas-milter PROF -- 1395 100199 kas-milter WINCH-- 1395 100199 kas-milter INFO -- 1395 100199 kas-milter USR1 -- 1395 100199 kas-milter USR2 -- 1395 100199 kas-milter 32 -- 1395 100199 kas-milter 33 -- 1395 100199 kas-milter 34 -- 1395 100199 kas-milter 35 -- 1395 100199 kas-milter 36 -- 1395 100199 kas-milter 37 -- 1395 100199 kas-milter 38 -- 1395 100199 kas-milter 39 -- 1395 100199 kas-milter 40 -- 1395 100199 kas-milter 41 -- 1395 100199 kas-milter 42 -- 1395 100199 kas-milter 43 -- 1395 100199 kas-milter 44 -- 1395 100199 kas-milter 45 -- 1395 100199 kas-milter 46 -- 1395 100199 kas-milter 47 -- 1395 100199 kas-milter 48 -- 1395 100199 kas-milter 49 -- 1395 100199 kas-milter 50 -- 1395 100199 kas-milter 51 -- 1395 100199 kas-milter 52 -- 1395 100199 kas-milter 53 -- 1395 100199 kas-milter 54 -- 1395 100199 kas-milter 55 -- 1395 100199 kas-milter 56 -- 1395 100199 kas-milter 57 -- 1395 100199 kas-milter 58 -- 1395 100199 kas-milter 59 -- 1395 100199 kas-milter 60 -- 1395 100199 kas-milter 61 -- 1395 100199 kas-milter 62 -- 1395 100199 kas-milter 63 -- 1395 100199 kas-milter 64 -- 1395 100199 kas-milter 65 -- 1395 100199 kas-milter 66 -- 1395 100199 kas-milter 67 -- 1395 100199 kas-milter 68 -- 1395 100199 kas-milter 69 -- 1395 100199 kas-milter 70 -- 1395 100199 kas-milter 71 -- 1395 100199 kas-milter 72 -- 1395 100199 kas-milter 73 -- 1395 100199 kas-milter 74 -- 1395 100199 kas-milter 75 -- 1395 100199 kas-milter 76 -- 1395 100199 kas-milter 77 -- 1395 100199 kas-milter 78 -- 1395 100199 kas-milter 79 -- 1395 100199 kas-milter 80 -- 1395 100199 kas-milter 81 -- 1395 100199 kas-milter 82 -- 1395 100199 kas-milter 83 -- 1395 100199 kas-milter 84 -- 1395 100199 kas-milter 85 -- 1395 100199 kas-milter 86 -- 1395 100199 kas-milter 87 -- 1395 100199 kas-milter 88 -- 1395 100199 kas-milter 89 -- 1395 100199 kas-milter 90 -- 1395 100199
Re: Serial multiport error Oxford/Startech PEX2S952
On Aug 24, 2011, at 4:59 AM, Jeremy Chadwick wrote: It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up isn't a terminal errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help assist in this matter and shed some light on the above comments. If there's a quirk or bug there, I'm certain he'll assist in helping. There's no obvious problem in uart(4). The handling of *.init and *.lock is all unified in the TTY layer. Note that the typical scenario for uart(4) to not respect the baud rate setting is when the UART port is a system device (i.e. serial console or debug port). Make sure there's no difference between 8.x and 9.x with respect to which ports are declared as system ports. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ 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: sigwait return 4
On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. How is this statement related to the creation of the standalone test case ? I don't know what testing. # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter USR2 -- 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined. This is not suitable to return '4'. And where root of this '4'? In /sys/kern/kern_sig.c:sigwait we call error = kern_sigtimedwait(td, set, ksi, NULL); --- no timeout. ___ 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: sigwait return 4
On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. How is this statement related to the creation of the standalone test case ? # procstat -j PIDTID COMM SIG FLAGS 1395 100199 kas-milter USR2 -- 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined. I see some strange in debug: # kdump -H -f /ktrace.out | grep sigw 1396 100228 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) # ktrdump | grep sigw 738 syscall: td=0xff002549d900 pid 1396 sigwait (0xffdfdf80, 0xffdfdf7c, 0xff8117827bf0) 666 syscall: td=0xff000c3d9900 pid 1286 sigwait (0x7fbfef70, 0x7fbfef8c, 0) 660 syscall: td=0xff00251ed900 pid 1277 sigwait (0x7ddeff70, 0x7ddeff8c, 0) 51 syscall: td=0xff0004ac5000 pid 787 sigwait (0x7fffebb0, 0x7fffebdc, 0) now I see 3'th non-zero argument from pid 1396. ___ 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: sigwait return 4
On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set This patch would be wrong, except to document existing behaviour in -stable branches. sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker ___ 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: sigwait return 4
On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html As I see this revisions not MFCed. No plans to fix this in 8-STABLE? Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker ___ 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
Re: sigwait return 4
On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set This patch would be wrong, except to document existing behaviour in -stable branches. sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Can you, please, describe why do you consider the behaviour prohibiting return of EINTR reasonable ? I do consider that the Solaris behaviour is useful. Since we went the other route, the addition to sigwait(2) manpage that clarifies this looks useful. And, sigwait(2) shall be sigwait(3). Also, the sentence the sigwaitinfo() function is equivalent to sigwait() ... in the sigwaitinfo(2) is not complete, due to EINTR. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker pgpyJTXjtKSeq.pgp Description: PGP signature
Re: sigwait return 4
On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Can you, please, describe why do you consider the behaviour prohibiting return of EINTR reasonable ? I do consider that the Solaris behaviour is useful. Since we went the other route, the addition to sigwait(2) manpage that clarifies this looks useful. And, sigwait(2) shall be sigwait(3). Also, the sentence the sigwaitinfo() function is equivalent to sigwait() ... in the sigwaitinfo(2) is not complete, due to EINTR. Like this (svn cp to be applied). diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..a9e605c 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -82,6 +82,14 @@ selected, it will be the lowest numbered one. The selection order between realtime and non-realtime signals, or between multiple pending non-realtime signals, is unspecified. +.Sh IMPLEMENTATION NOTES +The +.Fn sigwait +function is implemented as a wrapper around the +.Fn __sys_sigwait +system call, which retries the call on +.Er EINTR +error. .Sh RETURN VALUES If successful, .Fn sigwait diff --git a/lib/libc/sys/sigwaitinfo.2 b/lib/libc/sys/sigwaitinfo.2 index 41be9e2..a83de06 100644 --- a/lib/libc/sys/sigwaitinfo.2 +++ b/lib/libc/sys/sigwaitinfo.2 @@ -27,7 +27,7 @@ .\ .\ $FreeBSD$ .\ -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGTIMEDWAIT 2 .Os .Sh NAME @@ -116,6 +116,16 @@ except that the selected signal number shall be stored in the member, and the cause of the signal shall be stored in the .Va si_code member. +Besides this, the +.Fn sigwaitinfo +and +.Fn sigtimedwait +system calls may return +.Er EINTR +if interrupted by signal, which is not allowed for the +.Fn sigwait +function. +.Pp If any value is queued to the selected signal, the first such queued value is dequeued and, if the info argument is .Pf non- Dv NULL , pgppSwqcBJsag.pgp Description: PGP signature
