Re: WOL question
On 10/04/07, Jack Vogel <[EMAIL PROTECTED]> wrote: I am hoping someone here who has more familiarity with the ACPI code can enlighten me I have an internal bug filed complaining that FreeBSD disables wake-on-lan on the hardware. This means that if you boot, say, Linux, even Knoppix as a quickie, and then shutdown, if the hardware supports it, it will be left in a state where a magic-packet wakeup will work. However, even if I boot up a FreeBSD kernel with NO em driver, and then shutdown, it undoes the WOL setup. Now, I would like to have explicit WOL support added into the em driver, but before I even worry about that I need to understand where the kernel turns this off without the driver even needed. I've looked around at the dev/acpi and arch/acpi code and at least so far I'm having a hard time getting an adequate picture to know how it happens. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" This isnt specific to em, it also happens on other ethernet cards (rl(8) fxp(8)) that support WOL/MagicPacket. Might be idea to check PR database see if someone has same problem, maybe fix? it was nice installing ports/net/wol and getting a computer to fire up remotely, but as soon as it rebooted from FreeBSD, WOL stopped :( -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Poor NFS performance after recent update
Ok just to finish this thread off: After taking the power away from my switch for 30 seconds and powering it up again - everything automagically works back to normals. Merry Christmas & a Happy new Year. -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Poor NFS performance after recent update
Okay, this is getting stranger. transferring data between 8 machines on my network which are all running FreeBSD as having this problem, yet I cans download iso file off the internet at over 100KB/s. -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Poor NFS performance after recent update
On 16/12/06, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: Your problem might be duplex-related. Can you provide some netstat -in output (after you've scp'd stuff, etc.), as well as ifconfig -a output? nxclient-1.4.0-91.i386.tar.gz 100% 3423KB 23.1KB/s 02:28 NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll fxp0 1500 00:90:27:a4:0f:2c 3940 0 3855 0 0 fxp0 1500 192.168.0./24 192.168.0.2203962 - 3875 - - lo0 163840 00 0 0 lo0 16384 (28)00:00:00:00:00:00:fe:80:00:02:00:00:00:00:00:00:00:00:00:00:00:01 0 00 0 0 lo0 16384 (28)00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01 0 00 0 0 lo0 16384 127 127.0.0.10 -0 - - fxp0: flags=8843 mtu 1500 options=8 inet 192.168.0.220 netmask 0xff00 broadcast 192.168.0.255 ether 00:90:27:a4:0f:2c media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 looks like a normal day to me besides the 23.1KB/s 02:28 :( -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Poor NFS performance after recent update
Looks like I was wrong, as SCP is also just as slow as NFS I'm lost. I'm going to install 6.1-RELEASE to see if that "fixes" my problem. thanks! all!! -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Poor NFS performance after recent update
On 15/12/06, Jay Chandler <[EMAIL PROTECTED]> wrote: I do run statd and lockd, but let's keep it simple for now at first. My settings are similar, only the sole flag I have is rw-- if you remove those flags, does the speed change at all? no, still the same 20-60KBps that hovers about 30KBps. Doing a tcpdump did not reveal much: 04:06:02.160304 IP (tos 0x0, ttl 64, id 23123, offset 0, flags [none], proto: UDP (17), length: 152) client.2131922575 > fserver.nfs: 124 access fh 1107,752457/8932452 003f 04:06:02.160506 IP (tos 0x0, ttl 64, id 15711, offset 0, flags [none], proto: UDP (17), length: 148) fserver.nfs > client.2131922575: reply ok 120 access attr: REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166154965.00 1166039237.00 1137328342.00 c 001f 04:06:02.160540 IP (tos 0x0, ttl 64, id 23124, offset 0, flags [none], proto: UDP (17), length: 152) client.2131922576 > fserver.nfs: 124 access fh 1107,752457/8932452 003f 04:06:02.160660 IP (tos 0x0, ttl 64, id 15712, offset 0, flags [none], proto: UDP (17), length: 148) fserver.nfs > client.2131922576: reply ok 120 access attr: REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166154965.00 1166039237.00 1137328342.00 c 001f 04:06:02.160760 IP (tos 0x0, ttl 64, id 23125, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922577 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 0 04:06:02.160781 IP (tos 0x0, ttl 64, id 23126, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922578 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 8192 04:06:02.161204 IP (tos 0x0, ttl 64, id 15713, offset 0, flags [+], proto: UDP (17), length: 1500) fserver.nfs > client.2131922577: reply ok 1472 read REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166154998.00 1166039237.00 1137328342.00 8192 bytes 04:06:03.180538 IP (tos 0x0, ttl 64, id 23127, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922577 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 0 04:06:03.180985 IP (tos 0x0, ttl 64, id 15715, offset 0, flags [+], proto: UDP (17), length: 1500) fserver.nfs > client.2131922577: reply ok 1472 read REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166154999.00 1166039237.00 1137328342.00 8192 bytes 04:06:04.188613 IP (tos 0x0, ttl 64, id 23128, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922578 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 8192 04:06:04.189048 IP (tos 0x0, ttl 64, id 15716, offset 0, flags [+], proto: UDP (17), length: 1500) fserver.nfs > client.2131922578: reply ok 1472 read REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166155000.00 1166039237.00 1137328342.00 8192 bytes 04:06:07.224834 IP (tos 0x0, ttl 64, id 23129, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922577 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 0 04:06:07.225297 IP (tos 0x0, ttl 64, id 15717, offset 0, flags [+], proto: UDP (17), length: 1500) fserver.nfs > client.2131922577: reply ok 1472 read REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166155003.00 1166039237.00 1137328342.00 8192 bytes 04:06:12.265223 IP (tos 0x0, ttl 64, id 23130, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922578 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 8192 04:06:12.265665 IP (tos 0x0, ttl 64, id 15718, offset 0, flags [+], proto: UDP (17), length: 1500) fserver.nfs > client.2131922578: reply ok 1472 read REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166155008.00 1166039237.00 1137328342.00 8192 bytes 04:06:23.366067 IP (tos 0x0, ttl 64, id 23131, offset 0, flags [none], proto: UDP (17), length: 160) client.2131922577 > fserver.nfs: 132 read fh 1107,752457/8932452 8192 bytes @ 0 04:06:23.366554 IP (tos 0x0, ttl 64, id 15719, offset 0, flags [+], proto: UDP (17), length: 1500) fserver.nfs > client.2131922577: reply ok 1472 read REG 644 ids 1001/0 sz 9083425 nlink 1 rdev 45/35717136 fsid 59 fileid 884c64 a/m/ctime 1166155019.00 1166039237.00 1137328342.00 8192 bytes I even tried TCP NFS and nothing. Here is a dmesg: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #0: Thu Dec 14 13:55:53 GMT 2006 [EMAIL PROTECTED]:/data/freebsd/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) Processor 2800+ (1607.34-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x2
Re: Poor NFS performance after recent update
Hi, On 15/12/06, Jay Chandler <[EMAIL PROTECTED]> wrote: What's the entry for the NFS share in /etc/fstab? fserver:/data /media/datanfs rw,-b,-i,-s,-L,noauto I don't run clients with rpc.statd(8) rpc.lockd(8) -- Jay Chandler Network Administrator, Chapman University 714.628.7249 / [EMAIL PROTECTED] Today's Excuse: Processes running slowly due to weak power supply -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Poor NFS performance after recent update
I am have a realy big issue with NFS. I updated my fileserver to -STABLE as of 13th December and suffering poor NFS performance. before I was transferring data at around 6-8MBps now it is 30KBps - yes 30KBps!!. also cause some mounted shares to lock up. I thought it was the nve0 interface and swapped it for an fxp0. no change. checked cables. no change. What can I do to debug this further? I feel as though I could take the binary bits and transfer them quicker myself :( -- Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
