When running HylaFAX processes (faxq and faxgetty) both processes will eventually consume near or exactly 100% WCPU (as reported by top) after less than a minute. Attaching truss to the appropriate faxq process ID, the following is reported: select(7,{6},{},{},0x0) = 1 (0x1) read(6,0x7fffffffcf40,2047) = 0 (0x0) [repeated until process is terminated] Attaching truss to the appropriate faxgetty process ID, the following is reported: read(4,0x7fffffffcf20,2047) = 0 (0x0) gettimeofday({1329983307.368083 },0x0) = 0 (0x0) gettimeofday({1329983307.368114 },0x0) = 0 (0x0) select(9,{4 8},{},{8},{6.102623 }) = 1 (0x1) gettimeofday({1329983307.368192 },0x0) = 0 (0x0) read(4,0x7fffffffcf20,2047) = 0 (0x0) gettimeofday({1329983307.368267 },0x0) = 0 (0x0) gettimeofday({1329983307.368299 },0x0) = 0 (0x0) select(9,{4 8},{},{8},{6.102438 }) = 1 (0x1) [repeats until the process is terminated] How-To-Repeat: Start the HylaFAX processes. Occurs with both MultiTech ZBA (serial and USB) and USR Courier (serial) modems. HylaFAX operated normally under FreeBSD 8.2-p6 i386.
----- Forwarded message from Ryan Noll <rnoll.bsd@gmail.com> ----- Date: Mon, 19 Mar 2012 18:18:00 -0700 From: Ryan Noll <rnoll.bsd@gmail.com> To: freebsd-bugs@freebsd.org Subject: Re: kern/166071: High CPU Utilization on HylaFAX processes The PR is available at: http://www.freebsd.org/cgi/query-pr.cgi?pr=166071. Below is some more information about this particular bug. I thought this could be a kernel bug, but maybe it could be a bug in the program that the 9.0-RELEASE kernel exposed. If the faxq and hfaxd processes are started (via their startup script) and then faxgetty is started all appears fine. However, while sending a fax the faxgetty process is again at 100%. The truss output for faxgetty is not included because it is the same as stated earlier. After the fax has completed, faxgetty remains at 100%. Should this still be considered a kernel bug or should I try contacting the HylaFAX maintainers? Note that the configuration is run in a jail with a USB (cuaU0, MultiTech MultiModem MT9234ZBA-USB-CDC) and serial modem (cuau0, MultiTech MultiModem MT9234ZBA-NAM). This configuration did work under 8.2-RELEASE-p6. Also, this message is shown during the initial setup probe: stty: stdout appears redirected, but stdin is the control descriptor. Thank you for your time. v/r, Ryan ----- End forwarded message -----
Hello, I have recently upgraded my FreeBSD system from 8.3p4 to 9.1p4, and I no longer experience the problem that I reported described in kern/166071. I am uncertain about what was the problem, but since it no longer manifests with 9.1p4 and HylaFAX 6.0.6 I think this ticket could be closed. Thank you for your time, Ryan
State Changed From-To: open->closed Closed at submitter's request.
Dear, I think the bug is not resovled. In my stable/10 amd64 , faxgetty and faxq cost too may cpu load. The problem is the same as Ryan Noll described. $uanem -a FreeBSD dev.***.com 10.0-BETA2 FreeBSD 10.0-BETA2 #0 r257377: Thu Oct 31 07:47:49 CST 2013 root@dev.***.com:/usr/obj/usr/src/sys/GENERIC_PF_ALTQ amd64 $ pkg info|grep hylafax hylafax-6.0.6 Fax software $ ps -auxww|grep faxq uucp 63466 63.1 0.1 35224 2836 - Rs 2:55PM 25:19.28 /usr/local/sbin/faxq $ sudo ktrace -t c -p 63466 $ sudo ktrace -C $ sudo kdump -R 63466 faxq 1383636856.659275 CALL read(0x4,0x7fffffffcfa0,0x7ff) 63466 faxq 0.000257 RET read 0 63466 faxq 0.000055 CALL select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) 63466 faxq 0.000031 RET select 1 63466 faxq 0.000026 CALL read(0x4,0x7fffffffcfa0,0x7ff) 63466 faxq 0.000024 RET read 0 63466 faxq 0.000041 CALL select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) 63466 faxq 0.000027 RET select 1 63466 faxq 0.000025 CALL read(0x4,0x7fffffffcfa0,0x7ff) 63466 faxq 0.000024 RET read 0 63466 faxq 0.000022 CALL select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) 63466 faxq 0.000023 RET select 1 63466 faxq 0.000037 CALL read(0x4,0x7fffffffcfa0,0x7ff) 63466 faxq 0.000025 RET read 0 63466 faxq 0.000024 CALL select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) 63466 faxq 0.000024 RET select 1 63466 faxq 0.000023 CALL read(0x4,0x7fffffffcfa0,0x7ff) 63466 faxq 0.000023 RET read 0 ========== more =========== and , the /var/spool/hylafax/ is on zfs $ mount zroot on / (zfs, local, nfsv4acls) devfs on /dev (devfs, local, multilabel) zroot/data on /data (zfs, NFS exported, local, nfsv4acls) zroot/data/ftp on /data/ftp (zfs, NFS exported, local, noatime, nfsv4acls) zroot/data/mysql on /data/mysql (zfs, local, nfsv4acls) zroot/home on /home (zfs, local, nfsv4acls) zroot/tmp on /tmp (zfs, local, nfsv4acls) zroot/usr on /usr (zfs, local, nfsv4acls) zroot/var on /var (zfs, local, nfsv4acls) $ zfs get all zroot/var NAME PROPERTY VALUE SOURCE zroot/var type filesystem - zroot/var creation Wed Oct 30 22:42 2013 - zroot/var used 2.16G - zroot/var available 410G - zroot/var referenced 1.84G - zroot/var compressratio 1.00x - zroot/var mounted yes - zroot/var quota none default zroot/var reservation none default zroot/var recordsize 128K default zroot/var mountpoint /var local zroot/var sharenfs off default zroot/var checksum on default zroot/var compression off default zroot/var atime on default zroot/var devices on default zroot/var exec on default zroot/var setuid on default zroot/var readonly off default zroot/var jailed off default zroot/var snapdir hidden default zroot/var aclmode discard default zroot/var aclinherit restricted default zroot/var canmount on default zroot/var xattr off temporary zroot/var copies 1 default zroot/var version 5 - zroot/var utf8only off - zroot/var normalization none - zroot/var casesensitivity sensitive - zroot/var vscan off default zroot/var nbmand off default zroot/var sharesmb off default zroot/var refquota none default zroot/var refreservation none default zroot/var primarycache all default zroot/var secondarycache all default zroot/var usedbysnapshots 329M - zroot/var usedbydataset 1.84G - zroot/var usedbychildren 0 - zroot/var usedbyrefreservation 0 - zroot/var logbias latency default zroot/var dedup off default zroot/var mlslabel - zroot/var sync standard default zroot/var refcompressratio 1.00x - zroot/var written 39.2M - zroot/var logicalused 2.05G - zroot/var logicalreferenced 1.80G -
more info here: $ sudo fstat -v -p 63466 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W uucp faxq 63466 text /usr 1630604 -r-sr-xr-x 274064 r uucp faxq 63466 wd /var 1381 drwxr-xr-x 20 r uucp faxq 63466 root / 4 drwxr-xr-x 26 r uucp faxq 63466 0 /dev 7 crw-rw-rw- null rw uucp faxq 63466 1 /dev 7 crw-rw-rw- null rw uucp faxq 63466 2 /dev 7 crw-rw-rw- null rw uucp faxq 63466 3 /dev 7 crw-rw-rw- null rw uucp faxq 63466 4 /var 50545 prw------- 0 r uucp faxq 63466 5* local dgram fffff80039013d20 <-> fffff80004ef7a50 FD 4, it's inode is 50545 $ ls -i /var/spool/hylafax/FIFO 50545 /var/spool/hylafax/FIFO $ file /var/spool/hylafax/FIFO /var/spool/hylafax/FIFO: fifo (named pipe) so ,is it a bug about /usr/src/sys/fs/fifofs/fifo_vnops.c ? On Tue, Nov 5, 2013 at 3:39 PM, Ruan Chunping <ruanchunping@gmail.com>wrote: > Dear, > > I think the bug is not resovled. > > In my stable/10 amd64 , faxgetty and faxq cost too may cpu load. > > The problem is the same as Ryan Noll described. > > $uanem -a > FreeBSD dev.***.com 10.0-BETA2 FreeBSD 10.0-BETA2 #0 r257377: Thu Oct 31 > 07:47:49 CST 2013 root@dev.***.com:/usr/obj/usr/src/sys/GENERIC_PF_ALTQ > amd64 > > $ pkg info|grep hylafax > hylafax-6.0.6 Fax software > > > > $ ps -auxww|grep faxq > uucp 63466 63.1 0.1 35224 2836 - Rs 2:55PM 25:19.28 > /usr/local/sbin/faxq > $ sudo ktrace -t c -p 63466 > $ sudo ktrace -C > $ sudo kdump -R > 63466 faxq 1383636856.659275 CALL read(0x4,0x7fffffffcfa0,0x7ff) > 63466 faxq 0.000257 RET read 0 > 63466 faxq 0.000055 CALL > select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) > 63466 faxq 0.000031 RET select 1 > 63466 faxq 0.000026 CALL read(0x4,0x7fffffffcfa0,0x7ff) > 63466 faxq 0.000024 RET read 0 > 63466 faxq 0.000041 CALL > select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) > 63466 faxq 0.000027 RET select 1 > 63466 faxq 0.000025 CALL read(0x4,0x7fffffffcfa0,0x7ff) > 63466 faxq 0.000024 RET read 0 > 63466 faxq 0.000022 CALL > select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) > 63466 faxq 0.000023 RET select 1 > 63466 faxq 0.000037 CALL read(0x4,0x7fffffffcfa0,0x7ff) > 63466 faxq 0.000025 RET read 0 > 63466 faxq 0.000024 CALL > select(0x5,0x7fffffffd950,0x7fffffffd8d0,0x7fffffffd850,0) > 63466 faxq 0.000024 RET select 1 > 63466 faxq 0.000023 CALL read(0x4,0x7fffffffcfa0,0x7ff) > 63466 faxq 0.000023 RET read 0 > ========== more =========== > > > and , the /var/spool/hylafax/ is on zfs > $ mount > zroot on / (zfs, local, nfsv4acls) > devfs on /dev (devfs, local, multilabel) > zroot/data on /data (zfs, NFS exported, local, nfsv4acls) > zroot/data/ftp on /data/ftp (zfs, NFS exported, local, noatime, nfsv4acls) > zroot/data/mysql on /data/mysql (zfs, local, nfsv4acls) > zroot/home on /home (zfs, local, nfsv4acls) > zroot/tmp on /tmp (zfs, local, nfsv4acls) > zroot/usr on /usr (zfs, local, nfsv4acls) > zroot/var on /var (zfs, local, nfsv4acls) > > $ zfs get all zroot/var > NAME PROPERTY VALUE SOURCE > zroot/var type filesystem - > zroot/var creation Wed Oct 30 22:42 2013 - > zroot/var used 2.16G - > zroot/var available 410G - > zroot/var referenced 1.84G - > zroot/var compressratio 1.00x - > zroot/var mounted yes - > zroot/var quota none default > zroot/var reservation none default > zroot/var recordsize 128K default > zroot/var mountpoint /var local > zroot/var sharenfs off default > zroot/var checksum on default > zroot/var compression off default > zroot/var atime on default > zroot/var devices on default > zroot/var exec on default > zroot/var setuid on default > zroot/var readonly off default > zroot/var jailed off default > zroot/var snapdir hidden default > zroot/var aclmode discard default > zroot/var aclinherit restricted default > zroot/var canmount on default > zroot/var xattr off temporary > zroot/var copies 1 default > zroot/var version 5 - > zroot/var utf8only off - > zroot/var normalization none - > zroot/var casesensitivity sensitive - > zroot/var vscan off default > zroot/var nbmand off default > zroot/var sharesmb off default > zroot/var refquota none default > zroot/var refreservation none default > zroot/var primarycache all default > zroot/var secondarycache all default > zroot/var usedbysnapshots 329M - > zroot/var usedbydataset 1.84G - > zroot/var usedbychildren 0 - > zroot/var usedbyrefreservation 0 - > zroot/var logbias latency default > zroot/var dedup off default > zroot/var mlslabel - > zroot/var sync standard default > zroot/var refcompressratio 1.00x - > zroot/var written 39.2M - > zroot/var logicalused 2.05G - > zroot/var logicalreferenced 1.80G - > > >
I noticed still this problem after upgrading to 10.0-RELEASE from a 8.4-STABLE on an HP DL380G5 and USRobotics USB modem. Upgraded all from binaries with freebsd-update and portupgrade. The problem is that /usr/local/sbin/faxgetty on /dev/cuaU0 is looping on a select() and consumes 100% of CPU when in idle. # uname -a FreeBSD xxx.local 10.0-RELEASE-p1 FreeBSD 10.0-RELEASE-p1 #0: Tue Apr 8 06:43:36 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 # pkg info | grep hylafax hylafax-6.0.6_1 Fax software # ps -aux | grep getty uucp 1366 100.0 0.1 12480 3876 - R 3:32PM 90:07.56 /usr/local/sbin/faxgetty cuaU0 # top ... PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1366 root 1 103 0 12480K 3876K CPU1 1 105:27 100.00% faxgetty ... ktrace shows a loop on select() ... 1366 faxgetty 0.000003 CALL select(0x8,0xbfbfdce8,0xbfbfdc68,0xbfbfdbe8,0x80daf08) 1366 faxgetty 0.000004 RET select 1 1366 faxgetty 0.000003 CALL read(0x4,0xbfbfd36c,0x7ff) 1366 faxgetty 0.000003 RET read 0 1366 faxgetty 0.000003 CALL select(0x8,0xbfbfdce8,0xbfbfdc68,0xbfbfdbe8,0x80daf08) 1366 faxgetty 0.000004 RET select 1 1366 faxgetty 0.000003 CALL read(0x4,0xbfbfd36c,0x7ff) 1366 faxgetty 0.000003 RET read 0 1366 faxgetty 0.000004 CALL select(0x8,0xbfbfdce8,0xbfbfdc68,0xbfbfdbe8,0x80daf08) 1366 faxgetty 0.000004 RET select 1 1366 faxgetty 0.000003 CALL read(0x4,0xbfbfd36c,0x7ff) 1366 faxgetty 0.000003 RET read 0 1366 faxgetty 0.000004 CALL select(0x8,0xbfbfdce8,0xbfbfdc68,0xbfbfdbe8,0x80daf08) 1366 faxgetty 0.000003 RET select 1 ... Tried to recompile from ports but identical behaviour. -- E.Richiardone http://richiardone.eu
Had exactly same problem with 10-p2 and 10-p3 release. Mounting linux proc filesystem solved issue. Regards, Denis
One more thing. Hylafax was built with CONFIG_OPENFIFO="O_RDWR" and CONFIG_FIFOBUG="yes" options set in config.state file Regards, Denis
I recently needed to reconfigure my system, and I ran in to this same problem in FreeBSD 10.2-p7. The configuration changed to FreeSwitch acting as the soft modem instead of a USB or serial modem (MultiTech). However, I ran in to same difficulties with a HylaFax process utilizing 100% CPU. The solution I found that was easiest is to use HylaFax+ instead of HylaFax from ports. HylaFax+ does not require the use of CONFIG_OPENFIFO="O_RDWR" and CONFIG_FIFOBUG="yes" compile flags. If installing on system where GCC is not the default compiler, install GCC from ports before running configure for HylaFax+. Further, maybe a HylaFax+ port might be a good idea.
See bug #220763 for a port of HylaFAX+. -- Martin