Re: UDP Lite support
On 2014/03/26 23:22, John Baldwin wrote: On Friday, March 21, 2014 3:38:19 am Kevin Lo wrote: On 2014/03/03 04:08, Xin Li wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 3/2/14, 10:42 AM, Joe Nosay wrote: On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com wrote: On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net wrote: On 02/26/14 18:52, Joe Nosay wrote: On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis bro...@freebsd.org wrote: On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay wrote: The last thread on this was in 2006. Has it ever been reconsidered or is the likelihood of too many damaged packets the reason for not supporting? I'm not sure where to put this question. Apologies for the noise. You've provided next to no context. What is the question? What thread are you referring to? If this is the usual UDP then freebsd-net would be vastly more appropriate than -current. -- Brooks Thanks. I will ask kevlo and maybe bring it up on freebsd-net. It has to do with an implementation of the JACK server using UDP Lite for transferring data. http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html Looks like nobody proposed a patch? I think the concern was that this is not very useful in real-world scenarios due to link layer error detection mechanism but that doesn't raise a red flag to me assuming this is sufficiently self contained feature as it would improve compatibility with other operating systems. Cheers, https://github.com/torelizer/jack_trauma Not my project; but, I want to port it to FreeBSD. First is to get it to build from source. Use your raspberry pi with FreeBSD to broadcast your tunes and all. Thanks for all of the input. The project is being reworked to improve the code. Kevin Lo have a patchset but needs someone to do performance testing (its impact on non-UDPLite applications), test with vimage, etc: http://people.freebsd.org/~kevlo/udplite.diff http://people.freebsd.org/~kevlo/udp-v.diff Are you interested in working on these and report back? The revised patch is available at: http://people.freebsd.org/~kevlo/udplite.diff Thank you for your suggestions. A few suggestions: - I would just drop the INP lock and return EOPNOTSUPP directly rather than using goto's to 'bad_setoptname' and 'bad_getoptname' so the UDP-lite options are self-contained. Fixed. - I'm not a super big fan of all the udp_common_* macros only because I think it obfuscates things. At the very least, please move these things out of the header and into udp_usrreq.c so they are closer to the implementation. I would even suggest making them inline functions instead of macros. Okay, I removed two udp_common_* macros. I also renamed udp_common_init() to udp_udplite_init() and moved it into udp_usrreq.c. Using a macro here to follow the style used in SCTP (sctp_os_bsd.h). Here's a third version of the udp-lite patch: http://people.freebsd.org/~kevlo/udplite.diff However, I think the patch generally looks ok. Cool! Thanks again for your review of udp-lite's patch :-) Kevin ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2014-03-27 12:04:04 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-03-27 12:04:04 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-27 12:04:04 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-03-27 12:04:04 - cleaning the object tree TB --- 2014-03-27 12:04:04 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-27 12:04:29 - At svn revision 263795 TB --- 2014-03-27 12:04:30 - building world TB --- 2014-03-27 12:04:30 - CROSS_BUILD_TESTING=YES TB --- 2014-03-27 12:04:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-27 12:04:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-27 12:04:30 - SRCCONF=/dev/null TB --- 2014-03-27 12:04:30 - TARGET=pc98 TB --- 2014-03-27 12:04:30 - TARGET_ARCH=i386 TB --- 2014-03-27 12:04:30 - TZ=UTC TB --- 2014-03-27 12:04:30 - __MAKE_CONF=/dev/null TB --- 2014-03-27 12:04:30 - cd /src TB --- 2014-03-27 12:04:30 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Mar 27 12:04:39 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips/MipsFrameLowering.cpp -o MipsFrameLowering.o c++ -O2 -pipe -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips/MipsISelDAGToDAG.cpp -o MipsISelDAGToDAG.o c++ -O2 -pipe -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/include -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips -I. -I/src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\x86_64-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\/obj/pc98.i386/src/tmp\ -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips/MipsISelLowering.cpp -o MipsISelLowering.o /src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips/MipsISelLowering.cpp: In member function 'llvm::MachineBasicBlock* llvm::MipsTargetLowering::emitAtomicBinaryPartword(llvm::MachineInstr*, llvm::MachineBasicBlock*, unsigned int, unsigned int, bool) const': /src/lib/clang/libllvmmipscodegen/../../../contrib/llvm/lib/Target/Mips/MipsISelLowering.cpp:963: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libllvmmipscodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-03-27 13:10:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-27 13:10:51 - ERROR: failed to build world TB --- 2014-03-27 13:10:51 - 3600.09 user 271.84 system 4007.03 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
Re: sendmail Broken Pipe Error
Hello John-Mark and FreeBSD friends, On Wed, Mar 26, 2014 at 04:04:27PM -0700, John-Mark Gurney wrote: Willy Offermans wrote this message on Wed, Mar 26, 2014 at 18:22 +0100: Hello John-Mark and FreeBSD friends, On Wed, Mar 26, 2014 at 09:20:35AM -0700, John-Mark Gurney wrote: Willy Offermans wrote this message on Wed, Mar 26, 2014 at 12:17 +0100: On Tue, Mar 25, 2014 at 09:43:16AM -0700, John-Mark Gurney wrote: Willy Offermans wrote this message on Tue, Mar 25, 2014 at 11:39 +0100: I'm not an expert in tcpdump. Can anyone make sense out of the messages? If you dumped the contents, using -s 0 -X, and look at that last packet you should see 0d 0a 2e 0d 0a at the end.. which is CR/LF/./CR/LF.. If you don't see that, then for some reason sendmail/FreeBSD isn't telling the server that it's done sending which would prevent the receiving side from ack'ing the email causing the timeout... I followed your suggestions. However I'm not able to distinguish the last packet. Is there a way to find this with help of the Flags? The following is the output of tcpdump -r /root/tmp/tcpdump -X | grep Flags 11:57:56.539788 IP MyServer.com.41115 Smarthost.com.smtp: Flags [S], seq 1001452351, win 65535, options [mss 1448,nop,wscale 6,sackOK,TS val 407239960 ecr 0], length 0 11:57:56.555262 IP Smarthost.com.smtp MyServer.com.41115: Flags [S.], seq 1277075046, ack 1001452352, win 8192, options [mss 1452], length 0 It should look something like: 09:18:34.723280 IP jmgmac.funkthat.com.64724 h2.funkthat.com.ssh: Flags [.], ack 177, win 33280, options [nop,nop,TS val 1854905469 ecr 3482476972], length 0 0x: 4510 0034 d7ac 4000 4006 e1af c0a8 0003 E..4..@.@... 0x0010: c0a8 0004 fcd4 0016 7e48 238e d872 43dc ~H#..rC. 0x0020: 8010 8200 7c08 0101 080a 6e8f 9c7d |...n..} 0x0030: cf92 61ac..a. Notice the hex output... I didn't see any of that in your output... The last packet I was talking about is the last one that had length 1448 that your server sent... I sent two e-mails consecutively: the first without an attachment, the second with attachment. I dumped tcp of the NIC for port smtp. I got the following: 12:20:55.988622 IP MyServer.com.37191 Smarthost.com.smtp: Flags [P.], seq 18943:19104, ack 412, win 65535, length 161 0x: 4500 00c9 eebd 4000 4006 c0a8 0004 E.@.@... 0x0010: d54b 3f0d 9147 0019 4ea0 36dd 15a7 38a0 .K?..G..N.6...8. 0x0020: 5018 4481 2020 2020 2020 2020 P...D... 0x0030: 2020 2020 2020 2020 2020 2020 2020 2020 0x0040: 2020 2020 2020 2020 2020 2020 2020 205c ...\ 0x0050: 2f20 205c 205e 0d0a 2020 2020 2020 2020 /..\.^.. 0x0060: 2020 2020 2020 2020 2020 2020 2020 2020 0x0070: 2020 2020 2020 2020 2020 2020 2020 2020 0x0080: 2020 202e 5c2e 5f2f 5f29 0d0a 0d0a 2020 \._/_).. 0x0090: 2020 2020 2020 2020 2020 2020 2020 2020 0x00a0: 2020 2020 2020 2020 2020 2020 2020 2020 0x00b0: 2020 2020 2077 2e46 7265 6542 5344 .www.FreeBSD 0x00c0: 2e6f 7267 0d0a 2e0d 0a .org. As predicted by John-Mark, the first ended with 0d0a 2e0d 0a. However it was not the last packet with length 1448. I hope that this will not spoil the party. Is the Flag [P.] more indicative? It looks like to me, but I'm just learning. Anyway the second mail ended with: 12:22:17.960896 IP MyServer.com.37191 Smarthost.com.smtp: Flags [.], seq 35127:36575, ack 638, win 65535, length 1448 0x: 4500 05d0 fe9d 4000 4006 c0a8 0004 E.@.@... snip /snip 0x0560: 5670 6876 4a67 5a5a 5a50 4b2f 4b78 3774 VphvJgZZZPK/Kx7t 0x0570: 382f 4230 594f 6b78 3449 0d0a 4a76 6551 8/B0YOkx4I..JveQ 0x0580: 2b6e 7765 5647 2f33 6e79 6231 6133 496f +nweVG/3nyb1a3Io 0x0590: 5474 554f 4d61 4374 696b 714b 436b 4959 TtUOMaCtikqKCkIY 0x05a0: 704a 7668 3055 416d 6c33 4754 4f4c 6455 pJvh0UAml3GTOLdU 0x05b0: 774b 4145 7151 5741 7841 4141 5a66 7647 wKAEqQWAxAAAZfvG 0x05c0: 706b 6c36 0d0a 7a4e 6234 745a 6633 5a6c pkl6..zNb4tZf3Zl Being packet with length 1448 and sent from my side. The code 0d0a 2e0d 0a is missing. Immediately thereafter the following packets: We clearly haven't gotten the last mime-boundary, we are still in the base64 encoded data of the attachment... 12:22:18.003557 IP Smarthost.com.smtp MyServer.com.37191: Flags [.], ack 36575, win 65160, length 0 0x: 4500 0028 11fb 4000 7a06 19d0 d54b
Re: (more) screen distortion with intel GPU / xorg on recent -HEAD?
On Sun, 23 Mar 2014 13:36:29 -0700 Adrian Chadd adr...@freebsd.org wrote: Less information-poor response: * when it happens, the FB will resume correctly for a little bit, then once everything comes back, it flips to being distorted. So, it's likely something is misconfiguring stuff during resume. * I can flip to VTs fine; I can login and do things fine; * When I flip back to xorg, things still remain distorted; * If I ctrl-C xorg and start it again, it starts back up correctly. So hm, maybe the vt save/resume code learnt something buggy? No, vt(9) and syscons have nothing to do with FB used by Xorg. With new DRM Xorg allocate own FB and only Xorg and DRM know about it. It seems Xorg's PM events handling is works wrong. Or maybe drm2 should care better about that FB objects. -a On 23 March 2014 01:27, Adrian Chadd adr...@freebsd.org wrote: Hi, I know this is an information-poor message. The last time i updated my two test laptops was around the middle of last month. Back then, xorg would occasionally get distorted, but typically would come back from suspend fine. Lately, it seems a 50% chance that coming back from suspend that xorg will be not only distorted, but further screen redraws are wrong. It's like the framebuffer configuration is wrong and persists to be wrong. I have to exit out of xorg and restart it. Has anyone else seen this? -a -- Aleksandr Rybalko r...@freebsd.org ___ 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: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
Hello, I have the same problem on a HP Microserver N54L with FreeBSD 10 release. If a jail is running and the jail executes /etc/periodic/daily/450.status-security the server crashes. This happens every night at 4:03 CET. If I run /etc/periodic/daily/450.status-security manually in the jail, the server also crashes immediately. Now I wanted to try to same as Anton and run each script in /etc/periodic/security manually, but I also get: ASSERTION FAILED: Unexpected value for $PERIODIC: ‘' I then ran: setenv PERIODIC security daily” which allowed me to run each security script separately. If I run: root@jail:/etc/periodic/security # ./520.pfdenied the machine immediately reboots. Looking at 520.pfdenied I tried running the command: root@jail:~ # pfctl -sr -v directly, which also crashes the host immediately. All the best, Philipp PS: I have a custom kernel with VIMAGE which I use with the jail --- OpenResearch Software Development OG Geschäftsführer (CEO) Co-Founder Gumpendorfer Straße 132/9 1060 Vienna, Austria +43 699 17246437 philipp.sch...@openresearch.com http://www.openresearch.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
Hello, the problem seems to exist for a few years now: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160496 All the best, Philipp --- OpenResearch Software Development OG Geschäftsführer (CEO) Co-Founder Gumpendorfer Straße 132/9 1060 Vienna, Austria +43 699 17246437 philipp.sch...@openresearch.com http://www.openresearch.com On 27 Mar 2014, at 16:08, Philipp Schmid li...@schmidp.com wrote: Hello, I have the same problem on a HP Microserver N54L with FreeBSD 10 release. If a jail is running and the jail executes /etc/periodic/daily/450.status-security the server crashes. This happens every night at 4:03 CET. If I run /etc/periodic/daily/450.status-security manually in the jail, the server also crashes immediately. Now I wanted to try to same as Anton and run each script in /etc/periodic/security manually, but I also get: ASSERTION FAILED: Unexpected value for $PERIODIC: ‘' I then ran: setenv PERIODIC security daily” which allowed me to run each security script separately. If I run: root@jail:/etc/periodic/security # ./520.pfdenied the machine immediately reboots. Looking at 520.pfdenied I tried running the command: root@jail:~ # pfctl -sr -v directly, which also crashes the host immediately. All the best, Philipp PS: I have a custom kernel with VIMAGE which I use with the jail --- OpenResearch Software Development OG Geschäftsführer (CEO) Co-Founder Gumpendorfer Straße 132/9 1060 Vienna, Austria +43 699 17246437 philipp.sch...@openresearch.com http://www.openresearch.com signature.asc Description: Message signed with OpenPGP using GPGMail
Re: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
On Thursday, March 27, 2014 11:08:10 am Philipp Schmid wrote: Hello, I have the same problem on a HP Microserver N54L with FreeBSD 10 release. If a jail is running and the jail executes /etc/periodic/daily/450.status-security the server crashes. This happens every night at 4:03 CET. If I run /etc/periodic/daily/450.status-security manually in the jail, the server also crashes immediately. Now I wanted to try to same as Anton and run each script in /etc/periodic/security manually, but I also get: ASSERTION FAILED: Unexpected value for $PERIODIC: ‘' I then ran: setenv PERIODIC security daily” which allowed me to run each security script separately. If I run: root@jail:/etc/periodic/security # ./520.pfdenied the machine immediately reboots. Looking at 520.pfdenied I tried running the command: root@jail:~ # pfctl -sr -v directly, which also crashes the host immediately. All the best, Philipp PS: I have a custom kernel with VIMAGE which I use with the jail Can you get a crashdump when it crashes? Also, I thought that VIMAGE + pf is known to be unstable? -- John Baldwin ___ 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: UDP Lite support
On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote: Are you interested in working on these and report back? The revised patch is available at: http://people.freebsd.org/~kevlo/udplite.diff Thank you for your suggestions. A few suggestions: - I would just drop the INP lock and return EOPNOTSUPP directly rather than using goto's to 'bad_setoptname' and 'bad_getoptname' so the UDP-lite options are self-contained. Fixed. Thanks. - I'm not a super big fan of all the udp_common_* macros only because I think it obfuscates things. At the very least, please move these things out of the header and into udp_usrreq.c so they are closer to the implementation. I would even suggest making them inline functions instead of macros. Okay, I removed two udp_common_* macros. I also renamed udp_common_init() to udp_udplite_init() and moved it into udp_usrreq.c. Using a macro here to follow the style used in SCTP (sctp_os_bsd.h). Here's a third version of the udp-lite patch: http://people.freebsd.org/~kevlo/udplite.diff Ok, I would say that udp_common_init() is actually a better name if you keep the macro (which I think is fine) rather than udp_udplite_init() as the macro is not specific to UDP Lite. However, thanks for moving the macros out of the header. -- John Baldwin ___ 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: WITHOUT_XXX leftovers.
On Mar 25, 2014, at 7:05 AM, Lev Serebryakov l...@freebsd.org wrote: Hello, Freebsd-current. I try to trim my NanoBSD install as much as possible without going to add rm /usr/bin/as to customization steps (ok, I remove /usr/include and /usr/lib/*.a, but it I don't want cherry-pick binaries). So, I have WITHOUT_BINUTILS, WITHOUT_CLANG, WITHOUT_MAN (among others) but I have: /usr/bin/ar /usr/bin/c89 /usr/bin/c99 /usr/bin/flex /usr/bin/flex++ /usr/bin/lex /usr/bin/lex++ (all 4 is the same. of course) /usr/bin/byacc /usr/bin/yacc (again, hardlinks) /usr/bin/mandoc /usr/bin/ranlib (same as ar) WITHOUT_TOOLCHAIN will turn off all of these (and others). Also, IMHO, it will be nice to have knob for vi, which is rather huge and another one for all bhyve stuff and one more for openssl _binary_. Patches? :) Warner ___ 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: sendmail Broken Pipe Error
Willy Offermans wrote this message on Thu, Mar 27, 2014 at 15:46 +0100: Hello John-Mark and FreeBSD friends, On Wed, Mar 26, 2014 at 04:04:27PM -0700, John-Mark Gurney wrote: Willy Offermans wrote this message on Wed, Mar 26, 2014 at 18:22 +0100: Hello John-Mark and FreeBSD friends, On Wed, Mar 26, 2014 at 09:20:35AM -0700, John-Mark Gurney wrote: Willy Offermans wrote this message on Wed, Mar 26, 2014 at 12:17 +0100: On Tue, Mar 25, 2014 at 09:43:16AM -0700, John-Mark Gurney wrote: Willy Offermans wrote this message on Tue, Mar 25, 2014 at 11:39 +0100: I'm not an expert in tcpdump. Can anyone make sense out of the messages? If you dumped the contents, using -s 0 -X, and look at that last packet you should see 0d 0a 2e 0d 0a at the end.. which is CR/LF/./CR/LF.. If you don't see that, then for some reason sendmail/FreeBSD isn't telling the server that it's done sending which would prevent the receiving side from ack'ing the email causing the timeout... I followed your suggestions. However I'm not able to distinguish the last packet. Is there a way to find this with help of the Flags? The following is the output of tcpdump -r /root/tmp/tcpdump -X | grep Flags 11:57:56.539788 IP MyServer.com.41115 Smarthost.com.smtp: Flags [S], seq 1001452351, win 65535, options [mss 1448,nop,wscale 6,sackOK,TS val 407239960 ecr 0], length 0 11:57:56.555262 IP Smarthost.com.smtp MyServer.com.41115: Flags [S.], seq 1277075046, ack 1001452352, win 8192, options [mss 1452], length 0 It should look something like: 09:18:34.723280 IP jmgmac.funkthat.com.64724 h2.funkthat.com.ssh: Flags [.], ack 177, win 33280, options [nop,nop,TS val 1854905469 ecr 3482476972], length 0 0x: 4510 0034 d7ac 4000 4006 e1af c0a8 0003 E..4..@.@... 0x0010: c0a8 0004 fcd4 0016 7e48 238e d872 43dc ~H#..rC. 0x0020: 8010 8200 7c08 0101 080a 6e8f 9c7d |...n..} 0x0030: cf92 61ac..a. Notice the hex output... I didn't see any of that in your output... The last packet I was talking about is the last one that had length 1448 that your server sent... I sent two e-mails consecutively: the first without an attachment, the second with attachment. I dumped tcp of the NIC for port smtp. I got the following: 12:20:55.988622 IP MyServer.com.37191 Smarthost.com.smtp: Flags [P.], seq 18943:19104, ack 412, win 65535, length 161 0x: 4500 00c9 eebd 4000 4006 c0a8 0004 E.@.@... 0x0010: d54b 3f0d 9147 0019 4ea0 36dd 15a7 38a0 .K?..G..N.6...8. 0x0020: 5018 4481 2020 2020 2020 2020 P...D... 0x0030: 2020 2020 2020 2020 2020 2020 2020 2020 0x0040: 2020 2020 2020 2020 2020 2020 2020 205c ...\ 0x0050: 2f20 205c 205e 0d0a 2020 2020 2020 2020 /..\.^.. 0x0060: 2020 2020 2020 2020 2020 2020 2020 2020 0x0070: 2020 2020 2020 2020 2020 2020 2020 2020 0x0080: 2020 202e 5c2e 5f2f 5f29 0d0a 0d0a 2020 \._/_).. 0x0090: 2020 2020 2020 2020 2020 2020 2020 2020 0x00a0: 2020 2020 2020 2020 2020 2020 2020 2020 0x00b0: 2020 2020 2077 2e46 7265 6542 5344 .www.FreeBSD 0x00c0: 2e6f 7267 0d0a 2e0d 0a .org. As predicted by John-Mark, the first ended with 0d0a 2e0d 0a. However it was not the last packet with length 1448. I hope that this will not spoil the party. Is the Flag [P.] more indicative? It looks like to me, but I'm just learning. Anyway the second mail ended with: 12:22:17.960896 IP MyServer.com.37191 Smarthost.com.smtp: Flags [.], seq 35127:36575, ack 638, win 65535, length 1448 0x: 4500 05d0 fe9d 4000 4006 c0a8 0004 E.@.@... snip /snip 0x0560: 5670 6876 4a67 5a5a 5a50 4b2f 4b78 3774 VphvJgZZZPK/Kx7t 0x0570: 382f 4230 594f 6b78 3449 0d0a 4a76 6551 8/B0YOkx4I..JveQ 0x0580: 2b6e 7765 5647 2f33 6e79 6231 6133 496f +nweVG/3nyb1a3Io 0x0590: 5474 554f 4d61 4374 696b 714b 436b 4959 TtUOMaCtikqKCkIY 0x05a0: 704a 7668 3055 416d 6c33 4754 4f4c 6455 pJvh0UAml3GTOLdU 0x05b0: 774b 4145 7151 5741 7841 4141 5a66 7647 wKAEqQWAxAAAZfvG 0x05c0: 706b 6c36 0d0a 7a4e 6234 745a 6633 5a6c pkl6..zNb4tZf3Zl Being packet with length 1448 and sent from my side. The code 0d0a 2e0d 0a is missing. Immediately thereafter the following packets: We clearly haven't gotten the last mime-boundary, we are still in the base64 encoded
[head tinderbox] failure on ia64/ia64
TB --- 2014-03-28 01:50:22 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-03-28 01:50:22 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-03-28 01:50:22 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-03-28 01:50:22 - cleaning the object tree TB --- 2014-03-28 01:50:22 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-03-28 01:50:25 - At svn revision 263825 TB --- 2014-03-28 01:50:26 - building world TB --- 2014-03-28 01:50:26 - CROSS_BUILD_TESTING=YES TB --- 2014-03-28 01:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-28 01:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-28 01:50:26 - SRCCONF=/dev/null TB --- 2014-03-28 01:50:26 - TARGET=ia64 TB --- 2014-03-28 01:50:26 - TARGET_ARCH=ia64 TB --- 2014-03-28 01:50:26 - TZ=UTC TB --- 2014-03-28 01:50:26 - __MAKE_CONF=/dev/null TB --- 2014-03-28 01:50:26 - cd /src TB --- 2014-03-28 01:50:26 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Mar 28 01:50:34 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri Mar 28 03:25:33 UTC 2014 TB --- 2014-03-28 03:25:33 - generating LINT kernel config TB --- 2014-03-28 03:25:33 - cd /src/sys/ia64/conf TB --- 2014-03-28 03:25:33 - /usr/bin/make -B LINT TB --- 2014-03-28 03:25:33 - cd /src/sys/ia64/conf TB --- 2014-03-28 03:25:33 - /obj/ia64.ia64/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-03-28 03:25:34 - building LINT kernel TB --- 2014-03-28 03:25:34 - CROSS_BUILD_TESTING=YES TB --- 2014-03-28 03:25:34 - MAKEOBJDIRPREFIX=/obj TB --- 2014-03-28 03:25:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-03-28 03:25:34 - SRCCONF=/dev/null TB --- 2014-03-28 03:25:34 - TARGET=ia64 TB --- 2014-03-28 03:25:34 - TARGET_ARCH=ia64 TB --- 2014-03-28 03:25:34 - TZ=UTC TB --- 2014-03-28 03:25:34 - __MAKE_CONF=/dev/null TB --- 2014-03-28 03:25:34 - cd /src TB --- 2014-03-28 03:25:34 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Mar 28 03:25:34 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kgssapi/kgss_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /obj/src/make.amd64/bmake -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/ia64/ia64/mem.c:54:25: error: machine/efi.h: No such file or directory mkdep: compile failed *** Error code 1 Stop. bmake[1]: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-03-28 03:26:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-03-28 03:26:56 - ERROR: failed to build LINT kernel TB --- 2014-03-28 03:26:56 - 4722.90 user 724.76 system 5794.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ 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
Error with make installworld
Item is attached.
mkdir -p /tmp/install.cu8W9XZK
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep
find grep id install install-info ln lockf make mkdir mtree mv pwd_mkdb rm
sed services_mkdb sh sysctl test true uname wc zic tzsetup; do if
progpath=`which $prog`; then echo $progpath; else echo Required tool $prog
not found in PATH. 2; exit 1; fi; done); libs=$(ldd -f %o %p\n -f %o
%p\n $progs 2/dev/null | sort -u | while read line; do set -- $line; if [
$2 $3 != not found ]; then echo $2; else echo Required library $1 not
found. 2; exit 1; fi; done); cp $libs $progs /tmp/install.cu8W9XZK
cp -R ${PATH_LOCALE:-/usr/share/locale} /tmp/install.cu8W9XZK/locale
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.cu8W9XZK
LD_LIBRARY_PATH=/tmp/install.cu8W9XZK
PATH_LOCALE=/tmp/install.cu8W9XZK/locale make -f Makefile.inc1
COMPILER_TYPE=clang __MAKE_SHELL=/tmp/install.cu8W9XZK/sh reinstall;
MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.cu8W9XZK
LD_LIBRARY_PATH=/tmp/install.cu8W9XZK
PATH_LOCALE=/tmp/install.cu8W9XZK/locale rm -rf /tmp/install.cu8W9XZK
--
Making hierarchy
--
cd /usr/src; make -f Makefile.inc1 LOCAL_MTREE= hierarchy
cd /usr/src/etc
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.cu8W9XZK
make LOCAL_MTREE= distrib-dirs
mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /
mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /var
empty: flags (schg is not nonemtree -deU -f
/usr/src/etc/mtree/BSD.usr.dist -p /usr
mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include
mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr
mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /
install -l s usr/src/sys /sys
cd /usr/share/man; for mandir in man*; do install -l s ../$mandir
/usr/share/man/en.ISO8859-1/; install -l s ../$mandir
/usr/share/man/en.UTF-8/; done
cd /usr/share/openssl/man; for mandir in man*; do install -l s ../$mandir
/usr/share/openssl/man/en.ISO8859-1/; done
set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do
install -l s $2 /usr/share/man/$1; install -l s $2
/usr/share/openssl/man/$1; shift; shift; done
set - `grep ^[a-zA-Z] /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do
install -l s $2 /usr/share/nls/$1; shift; shift; done
--
Installing everything
--
cd /usr/src; make -f Makefile.inc1 install
=== share/info (install)
=== lib (install)
=== lib/csu/amd64 (install)
install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o /usr/lib
=== lib/libc (install)
install -C -o root -g wheel -m 444 libc.a /usr/lib
install: libc.a: No such file or directory
*** Error code 71
Stop.
make[5]: stopped in /usr/src/lib/libc
*** Error code 1
Stop.
make[4]: stopped in /usr/src/lib
*** Error code 1
Stop.
make[3]: stopped in /usr/src
*** Error code 1
Stop.
make[2]: stopped in /usr/src
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
___
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: Error with make installworld
On Fri, Mar 28, 2014 at 01:02:40AM -0400, Joe Nosay wrote: Item is attached. Which svn revision? Glen pgpDG7tRgllUC.pgp Description: PGP signature
