Re: 11.2-RC3 regression - networking igb driver
On 06/24/18 18:30, Jim Pingle wrote: On 6/23/2018 1:27 PM, David Samms wrote: There is a regression in 11.2-RC3 that effects the igb driver for Intels C2000 SoC I354 Quad GbE Controller Supermicro A1SRi-2558F http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm This server has run 10.x and 11.x fine up till 11.2-RC3. PROBLEM: with 11.2-RC3 the server boots and gets a network connection to the cable modem, but the interface (igb0) resets every 4-8 second. The reset time appears to be related to network load, but reset withing 10s with next to no traffic. I did try swapping cables, but with no effect. With each reset the interface successfully obtains an IP address via DHCP, works for a few seconds and resets. Restoring the server to 11.1-RELEASE-p10 resolves the problem. Any suggestions? Does your DHCP server send you an MTU, perhaps? Before the interface resets, what does its MTU show? You might try creating a dhclient.conf that sets "supersede interface-mtu 0;" and see if that helps. The MTU from DHCP feature is new (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 ) and e1000 interfaces will reset when applying the MTU. Jim P. Jim, Thank you for your kind reply. I believe you have correctly identified my issue. My ISP is Charter and the modem is a Arris TM822. Running off a live CD of both 11.2-RC3 and 12-CURRENT, I can see that DHCP receives a MTU of 576. In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 they mention that this is an invalid value, and running dhclient -d, I can see that dhclient considers the value invalid and does reset the interface and makes another request. Interestingly, the interface doesn't appear to actually reset until the new address is received. Manually setting the interface with ifconfig/route, I can ping 8.8.8.8 with MTU of 576, but I didn't try any data transfers. Using ifconfig to set MTU 1500 works fine too. All said, I think we have a rather poor DHCP client in 11.2 and a BREAKING change for many casual users. At the very least, dhclient should be complaining of invalid values being received, that would help the user recover quickly. As of now, all you see in the log is that the interface reset. Ideally dhclient would log the invalid MTU as an error but continue as it did in 11.1 with a valid MTU. Again, thank you for taking the time to help me figure out this puzzle. I am on holiday for the next 5 days and will not be on the internet so won't be able to reply for a while. -- David Samms ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted
Hi Tested both images in both modes on: Intel® Server Board S1200KP E3-1230 CPU BIOS/legacy mode work perfectly UEFI failed. Not surprising as I have never gotten FreeBSD UEFI to work on this motherboard. Console displayed: - /boot/kernel/kernel Booting... Start... EFI frame... addr, size... dimensions... stride... masks... _ Required power to be cycled -- David Samms ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fwd: 11.2-Beta3 fails to boot: legacy mode ZFS
All, My first response appears not to have made the list, so am reposting. The problem is SOLVED however. The system in question is an Intel s1200kb with Xeon processor but no COM port, only USB so console access is not available. Make debugging more difficult. On 06/04/18 13:59, Allan Jude wrote: When you say it "failed at ZFS", what do you mean? Sorry for the poor description. I get all the normal boot prompts and the system starts to boot then suddenly without any error message or output to the console, reboots. The last text I can see is... ZFS... This occurs very early in the boot cycle and way before mounting / or going into single user mode There will be multiple 'boot prompts' as well. The system starts up, and boot1/boot2 happen. This is where you'll get the first GELI password prompt. This will start the loader, which draws the beastie menu. After the menu, the kernel modules indicated in /boot/loader.conf are loaded, then the text 'booting' is displayed, and the screen is cleared, and the kernel starts loading. Reboots HERE. Before mount-root prompt. Later on you get the mount-root prompt if something goes wrong. Query: Do you happen to have VirtualBox or the nVidia driver kernel modules loaded? This was causing problems for some other people, where the system would boot up, but instantly panic once the VirtualBox networking driver was loaded, since the vbox driver module needs to be compiled against the 11.2 source code to work with an 11.2 kernel. If this doesn't seem to be the problem: Can you send the contents of /boot/loader.conf, /etc/rc.conf, 'zpool list' and 'zfs list' Allan, thank you so much for this suggestion. Commenting out all ports based kernel modules resolved the problem. In the past upgrades I have had ports based kernel modules fail to load or crash when used, but I have never seen the loading of a ports based kernel modules crash the boot process. Would suggest "we" make it clear in the upgrade instructions to disable ALL optional kernel modules. I expect Nvidia to fail and require a recompile before working with a new version of FreeBSD, but in the past I have always been able to boot to single user mode. Thank you guys for terrific support! On 2018-06-03 11:28 PM, Warner Losh wrote: I think this is on your side of the wall... Warner -- Forwarded message ----- From: David Samms mailto:dsa...@nw-ds.com>> Date: Sun, Jun 3, 2018, 7:08 PM Subject: 11.2-Beta3 fails to boot: legacy mode ZFS To: mailto:freebsd-stable@freebsd.org>> Hello, Background: - System was originally installed with an 11.0 CD. At the time I tried to get UEFI to work, but ended up booting in legacy/BIOS mode. Upgrading to 11.1 was uneventful. The system has a single SSD with full disk encryption and ZFS. Again, nothing special, just the user selectable install options from the 11.0 CD. Current Failure: -- After running "freebsd-update upgrade -r 11.2-BETA3" the system failed on reboot. Disk encryption keys can be entered, boot prompt appears, boot starts but fails at ZFS. Reboots with no info sent to the console. Luckily, selecting kernel.old at the boot prompt works fine. Any ideas? Need more info? What can I do to help track down the bug? Thank you -- David Samms ___ freebsd-stable@freebsd.org <mailto:freebsd-stable@freebsd.org> mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org <mailto:freebsd-stable-unsubscr...@freebsd.org>" -- David Samms ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
11.2-Beta3 fails to boot: legacy mode ZFS
Hello, Background: - System was originally installed with an 11.0 CD. At the time I tried to get UEFI to work, but ended up booting in legacy/BIOS mode. Upgrading to 11.1 was uneventful. The system has a single SSD with full disk encryption and ZFS. Again, nothing special, just the user selectable install options from the 11.0 CD. Current Failure: -- After running "freebsd-update upgrade -r 11.2-BETA3" the system failed on reboot. Disk encryption keys can be entered, boot prompt appears, boot starts but fails at ZFS. Reboots with no info sent to the console. Luckily, selecting kernel.old at the boot prompt works fine. Any ideas? Need more info? What can I do to help track down the bug? Thank you -- David Samms ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRE Throwing Traps Going Multiuser
On 07/05/10 16:29, Tim Daneliuk wrote: Is this a known problem (I've submitted a PR just in case it is not)? I am seeing this consistently when I try to do a build/installworld/kernel with daily sources from the master tree: http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyothumb=4 The system boots fine single-user. Problem is repeatable with both my kernel AND GENERIC. (My config file at end of this msg.) Attempting to enter multi-user causes the problem. This occurs whether or not anything is enabled in /etc/rc.conf. Falling back to my 6-18-2010 system image makes everything right again. MOBO is an Intel D946GZIS with a single SATA drive and one additional 3Com 3c905 NIC in addition to the onboard Intel NIC. My Kernel Config = include GENERIC ident MACHINENAME options IPFIREWALL options IPDIVERT options VESA # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines options SC_PIXEL_MODE # add support for the raster text mode # The following options will change the default colors of syscons. options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_RED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) By chance do you have any modules being loaded in /boot/loader.conf. I had similar issues and it was VirtualBox needing to be recompiled. ___ 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: MFC of r206686 r179870
On 05/09/10 04:25, Doug Barton wrote: On 05/08/10 23:07, jhell wrote: The following two commits to stable/7 may be responsible for dirtying the console with messages pertaining to setting values in rc.conf. I found the problem, and just committed r207811 which should fix it. The issue was only relevant to booting (which I did not test) as opposed to running rc.d scripts on the command line (which I did). Sorry for the hassle, and thanks for bringing this to my attention. Doug Doug, your the best! Thanks for all the work you do for FreeBSD. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
X11/rxvt: su fails to login and prints 'load: ...' on return
This morning I pulled up three rxvt terminals and ssh into a remote server. In each of the three ssh sessions I tried to su and failed with the following error message: %su root Password:load: 0.53 cmd: su 38176 [ttyin] 0.00u 0.00s 0% 1556k load: 0.53 cmd: su 38176 [ttyin] 0.00u 0.00s 0% 1556k Client is FreeBSD 8 stable (i386) Server is FreeBSD 7.2 Release An identical report was filed against aterm: http://www.freebsd.org/cgi/query-pr.cgi?pr=143786 Using a standard xterm, or XFCE Terminal I could su just fine. Also typing stty status '^M' before su, as suggested by Ruslan Ermilov solved the problem. -- David Samms New World Data Systems nw-ds.com ___ 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: X11/rxvt: su fails to login and prints 'load: ...' on return
Also, rebooting the client machine made no difference, using rxvt to su still fails. Client software hasn't been modified in a month. Server had been rebooted last night after 100+ days of uptime as I wanted to add the following to /boot/loader.conf kern.maxusers=512 vm.pmap.pg_ps_enabled=1 accf_data_load=YES aio_load=YES Prior to last nights reboot I have never seen the su problem. Immediately after the reboot su worked just fine, 9 hours later su fails. On 04/30/10 08:39, David Samms wrote: This morning I pulled up three rxvt terminals and ssh into a remote server. In each of the three ssh sessions I tried to su and failed with the following error message: %su root Password:load: 0.53 cmd: su 38176 [ttyin] 0.00u 0.00s 0% 1556k load: 0.53 cmd: su 38176 [ttyin] 0.00u 0.00s 0% 1556k Client is FreeBSD 8 stable (i386) Server is FreeBSD 7.2 Release An identical report was filed against aterm: http://www.freebsd.org/cgi/query-pr.cgi?pr=143786 Using a standard xterm, or XFCE Terminal I could su just fine. Also typing stty status '^M' before su, as suggested by Ruslan Ermilov solved the problem. ___ 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: May running megarc still cause memory corruption on 7.X?
Mikolaj Golub wrote:
Hi,
Previously sysutils/megarc port was marked as broken with the statement:
running megarc may cause memory corruption/system instability.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128082
But recently it has been re-enabled:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137938
Gerrit Beine (the maintainer) said that he verified on 7.2 and it worked.
But yesterday we had the panic on 7.1-RELEASE-p5 that looked like was caused
by megarc with bt identical to reported in ports/128082.
Unread portion of the kernel message buffer:
TPTE at 0xbfd20830 IS ZERO @ VA 4820c000
panic: bad pte
cpuid = 0
Uptime: 10h19m56s
Physical memory: 3059 MB
Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2
(kgdb) backtrace
#0 doadump () at pcpu.h:196
#1 0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0791379 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0aa37f6 in pmap_remove_pages (pmap=0xc69ae6e4) at
/usr/src/sys/i386/i386/pmap.c:3084
#4 0xc09cf79c in vmspace_exit (td=0xc64f68c0) at /usr/src/sys/vm/vm_map.c:404
#5 0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at
/usr/src/sys/kern/kern_exit.c:305
#6 0xc076ca0d in sys_exit (td=Could not find the frame base for sys_exit.
) at /usr/src/sys/kern/kern_exit.c:109
#7 0xc0aa81a5 in syscall (frame=0xe8d6ed38) at
/usr/src/sys/i386/i386/trap.c:1090
#8 0xc0a8e6e0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#9 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) allpcpu
cpuid= 3
curthread= 0xc6ae3d20: pid 48975 sh
curpcb = 0xe8ea1d90
fpcurthread = none
idlethread = 0xc633daf0: pid 11 idle: cpu3
switchticks = 37193321
cpuid= 2
curthread= 0xc633d8c0: pid 12 idle: cpu2
curpcb = 0xe4f10d90
fpcurthread = none
idlethread = 0xc633d8c0: pid 12 idle: cpu2
switchticks = 37193374
cpuid= 1
curthread= 0xc633d690: pid 13 idle: cpu1
curpcb = 0xe4f13d90
fpcurthread = none
idlethread = 0xc633d690: pid 13 idle: cpu1
switchticks = 37193374
cpuid= 0
curthread= 0xc64f68c0: pid 48980 sh
curpcb = 0xe8d6ed90
fpcurthread = none
idlethread = 0xc633d460: pid 14 idle: cpu0
switchticks = 37193321
(kgdb) ps
pid ppid pgrp uid state wmesg wchancmd
48980 48975 48975 0 RE CPU 0 sh
48978 48976 48976 0 R megarc
48976 48973 48976 0 Ss wait 0xc826e570 sh
48975 48972 48975 0 Rs CPU 3 sh
48973 705 705 0 S piperd 0xc8303318 cron
48972 705 705 0 S piperd 0xc674a18c cron
48267 18141 1814180 S lockf0xc83922c0 httpd
48266 18141 1814180 S lockf0xc7d62400 httpd
48265 18141 1814180 S select 0xc0c4ecb8 httpd
48264 18141 1814180 S lockf0xc7ceb240 httpd
...
At the moment of the crash megarc was run by cron (48973) at the same time
other cron job was started (we have the following script set up to run in the
same time:
if [ -x /usr/local/bin/vnstat ] [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ];
then /usr/local/bin/vnstat -u; fi)
and this sh process caused panic on its exit when kernel was trying to remove
its address space due to corrupted memory.
Should I add the comment to ports/137938 about this? I cc to Gerrit. Please
note, we are using 7.1-RELEASE-p5 while in ports/137938 it is said that it was
checked on 7.2. But it might be that Gerrit just did not test long enough? We
had megarc enabled on several 7.1 hosts for some times and saw only this one
panic (well, there was another one about a week ago, but it looked hardly
related, because megarc was not running at the moment of the crash and the
panic was when removing an entry from the namecache, I reported it to
hackers@).
Below some details from gdb session in case someone is interested to look at
this closer.
(kgdb) allchains
# no output
(kgdb) fr 5
#5 0xc076b6ad in exit1 (td=0xc64f68c0, rv=0) at
/usr/src/sys/kern/kern_exit.c:305
305 vmspace_exit(td);
(kgdb) p *td-td_proc
$1 = {p_list = {le_next = 0xc69a2570, le_prev = 0xc0c433f8}, p_threads = {tqh_first = 0xc64f68c0,
tqh_last = 0xc64f68c8}, p_upcalls = {tqh_first = 0x0, tqh_last = 0xc6502838}, p_slock = {
lock_object = {lo_name = 0xc0b3b5ae process slock, lo_type = 0xc0b3b5ae process slock,
lo_flags = 720896, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}},
mtx_lock = 4, mtx_recurse = 0}, p_ucred = 0xc708f700, p_fd = 0x0, p_fdtol = 0x0,
p_stats = 0xc64f8000, p_limit = 0xc7c60800, p_limco = {c_links = {sle = {sle_next = 0x0}, tqe = {
tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0xc65028b8,
c_flags = 0}, p_sigacts = 0xc7d0, p_flag = 268443648, p_state = PRS_NORMAL, p_pid = 48980,
p_hash = {le_next = 0x0, le_prev = 0xc632ad50}, p_pglist =
TCP differences in 7.2 vs 7.1
After upgrading to 7.2 (amd64) some customers complained of very poor bandwidth. Upon investigation all the effected customers were ATT DSL clients located all over the USA, not in a single city, nor were other ISPs effected. The server is a Supermicro with dual (quad core) processors with a single Intel fxp network card on a 100mbit connection. Kernel is GENERIC for both 7.1_release and 7.2_release. Normally a client can max out their download connection, but for ATT DSL customers the transfer rate would be about 5-10KB/s even though the server and client where both idle. Repeated tests were done, from multiple clients in different geographical locations. The problem manifested itself regardless of whether ftp, http, smtp, pop, or scp was used, and regardless of the OS of the client. Believing it to be a routing issue we changed the route and even changed the local router the server is connected to so that a different NIC port would be used to talk to ATT DSL customers, but no change in performance. Turns out it is somehow related to differences in FreeBSD 7.1 and 7.2. If I boot the same server with 7.1, all clients work as you would expect. But, if 7.2 is used all clients with the exception of ATT DSL clients would work normally, ATT customers would be limited to 5-10KB/s. I have no reason to believe there is anything wrong with the ATT DSL network, it just happen to be effected by whatever causes the problem. Any theories? A special thanks to cybercon.com tech support for being so helpful. If you need a data center, they have good tech support. ___ 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: TCP differences in 7.2 vs 7.1
Xin LI wrote: Hi David, David Samms wrote: After upgrading to 7.2 (amd64) some customers complained of very poor bandwidth. Upon investigation all the effected customers were ATT DSL clients located all over the USA, not in a single city, nor were other ISPs effected. The server is a Supermicro with dual (quad core) processors with a single Intel fxp network card on a 100mbit connection. Could you please try if this would help: sysctl net.inet.tcp.tso=0 Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! Xin LI, Thank you for your help. Setting sysctl net.inet.tcp.tso=0 resolved the issue completely. What does sysctl net.inet.tcp.tso=0 do? Where can I read more about the option? I captured tcpdumps of a single file transfer to 7.1, 7.2 and 7.2 with sysctl net.inet.tcp.tso=0, but they are to large to attach to this list. Let me know if you are interested in viewing the dump files. Thanks again for your assistance! ___ 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
FTP - Large file transfers (6.1)
I am having repeated FTP failures while transferring a 4G file across a LAN. Swapped out the switch, cables, and NIC's so don't believe hardware is involved. Have tried the default FTP server as well as vsftp and pure-ftp with the same results. NICs tested are em, sk, and rl. How to duplicate failure: Take two 6.1 machines with a 100M lan or x-talk cable and try to FTP a DVD image. The transfer fails around 90% of the time with 450 Error during write to data connection We have a similar problem when using samba. The failure is not as consistent but always occurs under heavy load. Here is the error: [2006/06/04 22:20:02, 0] lib/util_sock.c:write_data(557) write_data: write failure in writing to client 192.168.163.41. Error Host is down It appears, that the network connection on the server is being reset, but why? And where or how do I find more information? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP - Large file transfers (6.1)
On Tue, 2006-06-06 at 16:17 +0300, Iassen Anadoliev wrote: On Tue, June 6, 2006 2:51 pm, David Samms wrote: I am having repeated FTP failures while transferring a 4G file across a LAN. Swapped out the switch, cables, and NIC's so don't believe hardware is involved. Have tried the default FTP server as well as vsftp and pure-ftp with the same results. NICs tested are em, sk, and rl. How to duplicate failure: Take two 6.1 machines with a 100M lan or x-talk cable and try to FTP a DVD image. The transfer fails around 90% of the time with 450 Error during write to data connection We have a similar problem when using samba. The failure is not as consistent but always occurs under heavy load. Here is the error: [2006/06/04 22:20:02, 0] lib/util_sock.c:write_data(557) write_data: write failure in writing to client 192.168.163.41. Error Host is down It appears, that the network connection on the server is being reset, but why? And where or how do I find more information? Can you look here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=110247+0+archive/2006/freebsd-net/20060205.freebsd-net The attached patch solved my problem. A temporary workaround was to use ProFTPD. Thank you for your reply. I patched the two files and rebuild world, the kernel, and pureFTP. I have retested the default FTP and pureFTP with the same failure. Anyone know how I can get more debug info? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP - Large file transfers (6.1)
Can you look here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=110247+0+archive/2006/freebsd-net/20060205.freebsd-net The attached patch solved my problem. A temporary workaround was to use ProFTPD. Well, after testing SAMBA I would have to say the patch improved things. I can now successfully transfer a 4G file unless the client is performing multiple file downloads. FTP from WindowsXP can almost get a 4G file. Gets to 70-95% and dumps. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP - Large file transfers (6.1)
On Tue, 2006-06-06 at 14:19 -0400, Brian Tao wrote: On Tue, 6 Jun 2006, David Samms wrote: I patched the two files and rebuild world, the kernel, and pureFTP. I have retested the default FTP and pureFTP with the same failure. Anyone know how I can get more debug info? Have you attempted the same FTP test over loopback using local filesystems only, to eliminate external network factors and NIC driver faults? Ran four FTP transfers through lo0 without a failure. I am not sure how much that proves. Guess if conditions are perfect a ftp transfer can succeed. Has anyone tried to duplicate my problem on a LAN? Not sure how this could be related to hardware, but am setting up two other machines as client/server with a new x-talk cable. Also will run FreeBSD 5.4 on my original setup. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP - Large file transfers (6.1)
On Tue, 2006-06-06 at 14:19 -0400, Brian Tao wrote: On Tue, 6 Jun 2006, David Samms wrote: I patched the two files and rebuild world, the kernel, and pureFTP. I have retested the default FTP and pureFTP with the same failure. Anyone know how I can get more debug info? Have you attempted the same FTP test over loopback using local filesystems only, to eliminate external network factors and NIC driver faults? I brought in a new machine and built it with 6.1 i386 and tested then again with AMD64 and retested. FTP transfers from the new server are always successful even with the the same network card, switch, and cables. Thanks for your help. I am considering the issue resolved. Guess my test box is a bit flaky. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
