Re: wlan0 going UP/DOWN problem
On Sunday 05 December 2010 07:21:03 Steve Kargl wrote: It seems some recent change (as in the last 7-10 days) has caused an instability in wlan0. Just a small excerpt from /var/log/messages, Dec 4 18:54:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 19:37:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:37:01 laptop kernel: wlan0: link state changed to UP Dec 4 19:45:31 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:45:31 laptop kernel: wlan0: link state changed to UP Dec 4 19:54:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:54:01 laptop kernel: wlan0: link state changed to UP Dec 4 20:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:36:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:36:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:45:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:45:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:53:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:53:46 laptop kernel: wlan0: link state changed to UP So, every 18 minutes the devices is going DOWN/UP. :-/ More details please. Which driver? How is that stuff configured? wpa_supplicant involved? Try running it with debug messages enabled. We need to figure out what entity is causing the device to go down/up, this can either be wpa_supplicant or net80211 (or a cronjob calling ifconfig down/up every 18 minutes ;). The appropriate debug options enabled (wlandebug 0x or wpa_supplicant with -dd) should reveal that. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
In-kernel PPPoE
Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? From using it for a long time in OpenBSD I always found it quite stable and easy to use. -Pierre ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? Maybe because everyone who cares about in-kernel uses the FreeBSD in-kernel ng_pppoe via mpd? From using it for a long time in OpenBSD I always found it quite stable and easy to use. The same is true with mpd/ng_pppoe. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
Pierre Lamy pie...@userid.org wrote: Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? From using it for a long time in OpenBSD I always found it quite stable and easy to use. Have you tried netgraph-based mpd? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wlan0 going UP/DOWN problem
On Sun, Dec 05, 2010 at 09:34:46AM +0100, Bernhard Schmidt wrote: On Sunday 05 December 2010 07:21:03 Steve Kargl wrote: It seems some recent change (as in the last 7-10 days) has caused an instability in wlan0. Just a small excerpt from /var/log/messages, Dec 4 18:54:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 19:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 19:37:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:37:01 laptop kernel: wlan0: link state changed to UP Dec 4 19:45:31 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:45:31 laptop kernel: wlan0: link state changed to UP Dec 4 19:54:01 laptop kernel: wlan0: link state changed to DOWN Dec 4 19:54:01 laptop kernel: wlan0: link state changed to UP Dec 4 20:11:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:11:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:19:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:19:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:36:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:36:46 laptop kernel: wlan0: link state changed to UP Dec 4 20:45:16 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:45:16 laptop kernel: wlan0: link state changed to UP Dec 4 20:53:46 laptop kernel: wlan0: link state changed to DOWN Dec 4 20:53:46 laptop kernel: wlan0: link state changed to UP So, every 18 minutes the devices is going DOWN/UP. :-/ More details please. Which driver? wpi0. How is that stuff configured? laptop:root[204] ifconfig wpi0 wpi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:1c:bf:90:ab:44 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated laptop:root[205] ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:1c:bf:90:ab:44 inet 192.168.0.10 netmask 0xff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g status: associated ssid SpartanTeepee channel 6 (2437 MHz 11g) bssid 00:18:e7:d4:f2:1b country US authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit txpower 0 bmiss 7 scanvalid 60 protmode CTS wpa_supplicant involved? No. Try running it with debug messages enabled. We need to figure out what entity is causing the device to go down/up, this can either be wpa_supplicant or net80211 (or a cronjob calling ifconfig down/up every 18 minutes ;). The appropriate debug options enabled (wlandebug 0x or wpa_supplicant with -dd) should reveal that. laptop:root[209] wlandebug wlandebug: sysctl-get(net.wlan.0.debug): No such file or directory Looks like I need to rebuild the kernel. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
On 12/5/10 9:30 AM, Bernd Walter wrote: On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? Maybe because everyone who cares about in-kernel uses the FreeBSD in-kernel ng_pppoe via mpd? From using it for a long time in OpenBSD I always found it quite stable and easy to use. The same is true with mpd/ng_pppoe. while I like mpd, I should point out that the regular 'in source' ppp that comes with freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my gateway as I never got around to installing mpd and it did the job. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
On Sun, Dec 05, 2010 at 12:30:16PM -0800, Julian Elischer wrote: On 12/5/10 9:30 AM, Bernd Walter wrote: On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? Maybe because everyone who cares about in-kernel uses the FreeBSD in-kernel ng_pppoe via mpd? From using it for a long time in OpenBSD I always found it quite stable and easy to use. The same is true with mpd/ng_pppoe. while I like mpd, I should point out that the regular 'in source' ppp No surprise that you like it ;-) that comes with freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my gateway as I never got around to installing mpd and it did the job. Same for me if the machine's power is good enough, but my Router is a tiny FreeBSD/ARM, which has trouble to keep up with load if running traffic via userland. I use mpd together with ipfw nat to keep traffic in kernel. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Process accounting/timing has broken recently
Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
on 05/12/2010 22:30 Julian Elischer said the following: On 12/5/10 9:30 AM, Bernd Walter wrote: On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? Maybe because everyone who cares about in-kernel uses the FreeBSD in-kernel ng_pppoe via mpd? From using it for a long time in OpenBSD I always found it quite stable and easy to use. The same is true with mpd/ng_pppoe. while I like mpd, I should point out that the regular 'in source' ppp that comes with freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my gateway as I never got around to installing mpd and it did the job. BTW, there is a rumor that mpd may become an 'in source' program too. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On 12/5/10 3:18 PM, Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an old hand you can check out sources at different revisions.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
Andriy Gapon a...@freebsd.org wrote: as I never got around to installing mpd and it did the job. BTW, there is a rumor that mpd may become an 'in source' program too. Not to paraphrase the muppet show, but... 'the question is... who cares?' : -- This e-mail was sponsored by the letters 'please GTFO with bind from the base' and the number 1338 ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
On Sun, Dec 5, 2010 at 6:32 PM, Andriy Gapon a...@freebsd.org wrote: on 05/12/2010 22:30 Julian Elischer said the following: On 12/5/10 9:30 AM, Bernd Walter wrote: On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote: Just curious about why the in-kernel PPPoE interface was never ported from NetBSD or OpenBSD, to FreeBSD. Does anyone know why? Maybe because everyone who cares about in-kernel uses the FreeBSD in-kernel ng_pppoe via mpd? From using it for a long time in OpenBSD I always found it quite stable and easy to use. The same is true with mpd/ng_pppoe. while I like mpd, I should point out that the regular 'in source' ppp that comes with freebsd also uses the in-kernel netgraph pppoe module. I use it 24 x 7 on my gateway as I never got around to installing mpd and it did the job. BTW, there is a rumor that mpd may become an 'in source' program too. -- Andriy Gapon Does mpd work in -current ? Last tried I, netgraph had problems with mpd. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ts_to_ct messages; ntp: time correction of -1200 seconds exceeds sanity limit
FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2 23:20:14 CST 2010 r...@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64 I have been getting a lot of ts_to_ct for months: are we supposed to look for something or report anything about these? I just noticed an NTP error in /var/log/messages: ... Dec 4 02:52:18 gohorns kernel: ts_to_ct(1291431138.717914676) = [2010-12-04 02:52:18] Dec 4 03:09:05 gohorns ntpd[1934]: time reset +2.018106 s Dec 4 03:09:05 gohorns kernel: ts_to_ct(1291432145.779273676) = [2010-12-04 03:09:05] Dec 4 03:11:40 gohorns kernel: ts_to_ct(1291432301.024288164) = [2010-12-04 03:11:41] Dec 4 03:45:36 gohorns ntpd[1934]: time reset +1.976613 s Dec 4 03:45:36 gohorns kernel: ts_to_ct(1291434336.662385061) = [2010-12-04 03:45:36] Dec 4 03:45:36 gohorns ntpd[1934]: kernel time sync status change 6001 Dec 4 03:45:36 gohorns kernel: ts_to_ct(1291434336.712917848) = [2010-12-04 03:45:36] Dec 4 03:46:38 gohorns ntpd[1934]: time correction of -1200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Dec 4 04:15:36 gohorns kernel: ts_to_ct(1291436136.712892982) = [2010-12-04 04:15:36] Dec 4 04:45:36 gohorns kernel: ts_to_ct(1291437936.712891437) = [2010-12-04 04:45:36] Dec 4 05:15:36 gohorns kernel: ts_to_ct(1291439736.712890731) = [2010-12-04 05:15:36] ... At Sun Dec 5 19:56:19 CST 2010 according to other systems, this machine says the time is gohorns:/root# date Sun Dec 5 20:11:01 CST 2010 gohorns:/root# Has anyone seen anything like this? Suggestions on what to look for as a cause? The system is a Dell Zino HD, dmesg: CPU: AMD Athlon(tm) Neo X2 Dual Core Processor 6850e (1800.10-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x60fb2 Family = f Model = 6b Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x11fLAHF,CMP,SVM,ExtAPIC,CR8,Prefetch TSC: P-state invariant ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: On 12/5/10 3:18 PM, Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an old hand you can check out sources at different revisions.. I was hoping that someone (possibly the person responsible) would recognize the symptoms and recommend a revision or two to revert. Otherwise, doing a binary search will take some time in that it takes 4+ hours for a buildworld/kernel cycle on my laptop. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: On 12/5/10 3:18 PM, Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real 38.39 user 30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real 40.95 user 27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real 38.90 user 30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real 40.59 user 27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real 39.76 user 28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real 41.21 user 27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real 39.68 user 29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real 39.98 user 28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real 39.64 user 29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real 37.49 user 31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an old hand you can check out sources at different revisions.. I was hoping that someone (possibly the person responsible) would recognize the symptoms and recommend a revision or two to revert. Otherwise, doing a binary search will take some time in that it takes 4+ hours for a buildworld/kernel cycle on my laptop. If you can provide the source for the application you're running above and instructions on how to compile it, I can at least give you a bit of a head start :). Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On 12/5/10 10:19 PM, Garrett Cooper wrote: On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: On 12/5/10 3:18 PM, Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an old hand you can check out sources at different revisions.. I was hoping that someone (possibly the person responsible) would recognize the symptoms and recommend a revision or two to revert. Otherwise, doing a binary search will take some time in that it takes 4+ hours for a buildworld/kernel cycle on my laptop. If you can provide the source for the application you're running above and instructions on how to compile it, I can at least give you a bit of a head start :). Thanks, -Garrett plus which probably just `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel` would be enough... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Sun, Dec 5, 2010 at 10:22 PM, Julian Elischer jul...@freebsd.org wrote: On 12/5/10 10:19 PM, Garrett Cooper wrote: On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: On 12/5/10 3:18 PM, Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real 38.39 user 30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real 40.95 user 27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real 38.90 user 30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real 40.59 user 27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real 39.76 user 28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real 41.21 user 27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real 39.68 user 29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real 39.98 user 28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real 39.64 user 29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real 37.49 user 31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an old hand you can check out sources at different revisions.. I was hoping that someone (possibly the person responsible) would recognize the symptoms and recommend a revision or two to revert. Otherwise, doing a binary search will take some time in that it takes 4+ hours for a buildworld/kernel cycle on my laptop. If you can provide the source for the application you're running above and instructions on how to compile it, I can at least give you a bit of a head start :). Thanks, -Garrett plus which probably just `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel` would be enough... But couldn't it be libthr changes? There have been a handful of those that have been committed recently by davidxu. HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On 12/5/10 10:24 PM, Garrett Cooper wrote: On Sun, Dec 5, 2010 at 10:22 PM, Julian Elischerjul...@freebsd.org wrote: On 12/5/10 10:19 PM, Garrett Cooper wrote: On Sun, Dec 5, 2010 at 10:12 PM, Steve Kargl s...@troutmask.apl.washington.eduwrote: On Sun, Dec 05, 2010 at 04:00:32PM -0800, Julian Elischer wrote: On 12/5/10 3:18 PM, Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. I know it's a lot to ask but it may be something that you can help with if you had the time to triangulate in on the change that did it.. I presume that since you are an old hand you can check out sources at different revisions.. I was hoping that someone (possibly the person responsible) would recognize the symptoms and recommend a revision or two to revert. Otherwise, doing a binary search will take some time in that it takes 4+ hours for a buildworld/kernel cycle on my laptop. If you can provide the source for the application you're running above and instructions on how to compile it, I can at least give you a bit of a head start :). Thanks, -Garrett plus which probably just `cd /sys/amd64/conf config GENERIC;cd ../compile/GENERIC; make kernel` would be enough... But couldn't it be libthr changes? There have been a handful of those that have been committed recently by davidxu. Unlikely as there was no mention of there being any thread involvement. probably just replacing the kernel would be enough.. It'd be easy to find out.. see if one 2 weeks old fixes the problem :-) HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Sun, Dec 05, 2010 at 10:24:12PM -0800, Garrett Cooper wrote: But couldn't it be libthr changes? There have been a handful of those that have been committed recently by davidxu. HTH, There is no threading involved in the application. However, it was David's recent changes that caused me to upgrade from a 7-10 day old install. The recent libthr chnages have improved the stalling that I experience with firefox. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Sun, Dec 05, 2010 at 10:19:12PM -0800, Garrett Cooper wrote: If you can provide the source for the application you're running above and instructions on how to compile it, I can at least give you a bit of a head start :). Thanks, -Garrett The app is statically linked. I can give you the binary. Compiling the code would be a pain. You need mpfr and gmp from ports and you would need to patch libm with my expf implementation. Unfortunately, I have extensive libm patches that will take sometime to unravel for only my expf file. My give my a 1/2 hour. I recompile with standard libm expf. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
