Re: FreeBSD 8.1-Release NFSD hang in rc_lo state
--- On Tue, 8/10/10, Rick Macklem rmack...@uoguelph.ca wrote:
From: Rick Macklem rmack...@uoguelph.ca
Subject: Re: FreeBSD 8.1-Release NFSD hang in rc_lo state
To: alan bryan alan.br...@yahoo.com
Cc: freebsd-stable@freebsd.org
Date: Tuesday, August 10, 2010, 7:35 PM
I'm doing some testing with
loading up a new storage server. I have
couple ZFS filesystems exported via NFS over UDP.
I have a client machine (8.1 also) that has mounted
those filesystems
along with some test PHP scripts that are doing a ton
of
read/write/fstat operations to load it up.
If I ctrl-C to kill the scripts on the client I found
that I can end
up with nfsd on the server stuck at 100% CPU and in
the rc_lo state.
/etc/rc.d/nfsd restart does nothing.
# nfsstat -s -w 1 -W
GtAttr Lookup Rdlink Read Write Rename Access Rddir
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Client complaining with:
kernel: nfs server 192.168.1.2:/tank/alantest2: not
responding
Top on the server:
last pid: 4776; load averages: 1.24, 1.15, 1.15 up
0+23:04:46 18:25:26
53 processes: 2 running, 35 sleeping, 16 lock
CPU: 0.0% user, 0.0% nice, 25.0% system, 0.0%
interrupt, 75.0% idle
Mem: 21M Active, 5812K Inact, 2029M Wired, 88K Cache,
8592K Buf, 5857M
Free
Swap: 3942M Total, 3942M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU
COMMAND
922 root 44 0 5804K 1820K CPU2 2 63:52 100.00% {nfsd:
service}
922 root 45 0 5804K 1820K *rc_lo 1 30:23 0.00% {nfsd:
service}
922 root 48 0 5804K 1820K rpcsvc 1 30:20 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 1 30:17 0.00% {nfsd:
service}
922 root 48 0 5804K 1820K rpcsvc 1 30:17 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K rpcsvc 1 30:13 0.00% {nfsd:
service}
922 root 45 0 5804K 1820K *rc_lo 2 30:13 0.00% {nfsd:
service}
922 root 45 0 5804K 1820K *rc_lo 3 30:12 0.00% {nfsd:
service}
922 root 44 0 5804K 1820K *rc_lo 0 30:10 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 2 30:07 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 0 30:03 0.00% {nfsd:
service}
922 root 45 0 5804K 1820K *rc_lo 1 30:03 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 2 30:03 0.00% {nfsd:
service}
922 root 45 0 5804K 1820K *rc_lo 2 30:02 0.00% {nfsd:
service}
922 root 45 0 5804K 1820K *rc_lo 1 29:59 0.00% {nfsd:
master}
922 root 45 0 5804K 1820K *rc_lo 2 29:54 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 0 29:54 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 0 29:52 0.00% {nfsd:
service}
922 root 47 0 5804K 1820K *rc_lo 2 29:46 0.00% {nfsd:
service}
922 root 46 0 5804K 1820K *rc_lo 1 29:44 0.00% {nfsd:
service}
I have a patch that I think might fix this. (Essentially
the same
bug was posted on another list recently.) I'll post it to
Alan
separately, but if anyone else wants to try it, it will be
at
http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch
in a few minutes.
rick
___
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
I applied this patch and have been unable to reproduce the hang since.
Rick, Thanks for an awesomely quick response!
This will go into 8-Stable at some point?
--Alan
___
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
FreeBSD 8.1-Release NFSD hang in rc_lo state
I'm doing some testing with loading up a new storage server. I have couple ZFS
filesystems exported via NFS over UDP.
I have a client machine (8.1 also) that has mounted those filesystems along
with some test PHP scripts that are doing a ton of read/write/fstat operations
to load it up.
If I ctrl-C to kill the scripts on the client I found that I can end up with
nfsd on the server stuck at 100% CPU and in the rc_lo state. /etc/rc.d/nfsd
restart does nothing.
# nfsstat -s -w 1 -W
GtAttr Lookup Rdlink Read Write Rename Access Rddir
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
Client complaining with:
kernel: nfs server 192.168.1.2:/tank/alantest2: not responding
Top on the server:
last pid: 4776; load averages: 1.24, 1.15, 1.15
up 0+23:04:46 18:25:26
53 processes: 2 running, 35 sleeping, 16 lock
CPU: 0.0% user, 0.0% nice, 25.0% system, 0.0% interrupt, 75.0% idle
Mem: 21M Active, 5812K Inact, 2029M Wired, 88K Cache, 8592K Buf, 5857M Free
Swap: 3942M Total, 3942M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
922 root 440 5804K 1820K CPU22 63:52 100.00% {nfsd: service}
922 root 450 5804K 1820K *rc_lo 1 30:23 0.00% {nfsd: service}
922 root 480 5804K 1820K rpcsvc 1 30:20 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 1 30:17 0.00% {nfsd: service}
922 root 480 5804K 1820K rpcsvc 1 30:17 0.00% {nfsd: service}
922 root 460 5804K 1820K rpcsvc 1 30:13 0.00% {nfsd: service}
922 root 450 5804K 1820K *rc_lo 2 30:13 0.00% {nfsd: service}
922 root 450 5804K 1820K *rc_lo 3 30:12 0.00% {nfsd: service}
922 root 440 5804K 1820K *rc_lo 0 30:10 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 2 30:07 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 0 30:03 0.00% {nfsd: service}
922 root 450 5804K 1820K *rc_lo 1 30:03 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 2 30:03 0.00% {nfsd: service}
922 root 450 5804K 1820K *rc_lo 2 30:02 0.00% {nfsd: service}
922 root 450 5804K 1820K *rc_lo 1 29:59 0.00% {nfsd: master}
922 root 450 5804K 1820K *rc_lo 2 29:54 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 0 29:54 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 0 29:52 0.00% {nfsd: service}
922 root 470 5804K 1820K *rc_lo 2 29:46 0.00% {nfsd: service}
922 root 460 5804K 1820K *rc_lo 1 29:44 0.00% {nfsd: service}
___
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: Problems replacing failing drive in ZFS pool
--- On Mon, 7/19/10, Dan Langille d...@langille.org wrote: From: Dan Langille d...@langille.org Subject: Re: Problems replacing failing drive in ZFS pool To: Freddie Cash fjwc...@gmail.com Cc: freebsd-stable freebsd-stable@freebsd.org Date: Monday, July 19, 2010, 7:07 PM On 7/19/2010 12:15 PM, Freddie Cash wrote: On Mon, Jul 19, 2010 at 8:56 AM, Garrett Mooregarrettmo...@gmail.com wrote: So you think it's because when I switch from the old disk to the new disk, ZFS doesn't realize the disk has changed, and thinks the data is just corrupt now? Even if that happens, shouldn't the pool still be available, since it's RAIDZ1 and only one disk has gone away? I think it's because you pull the old drive, boot with the new drive, the controller re-numbers all the devices (ie da3 is now da2, da2 is now da1, da1 is now da0, da0 is now da6, etc), and ZFS thinks that all the drives have changed, thus corrupting the pool. I've had this happen on our storage servers a couple of times before I started using glabel(8) on all our drives (dead drive on RAID controller, remove drive, reboot for whatever reason, all device nodes are renumbered, everything goes kablooey). Can you explain a bit about how you use glabel(8) in conjunction with ZFS? If I can retrofit this into an exist ZFS array to make things easier in the future... 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 ]# zpool status pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad16 ONLINE 0 0 0 Of course, always have good backups. ;) In my case, this ZFS array is the backup. ;) But I'm setting up a tape library, real soon now -- Dan Langille - http://langille.org/ ___ 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 Dan, Here's how to do it after the fact: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html --Alan Bryan ___ 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
NFS 75 second stall
Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an ls -l on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. # nfsstat -s -W -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 0 0 222 257 0 0 0 0 0 0 178 135 0 0 0 0 0 0 85 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... for 75 rows of all zeros 0 0 0 272 266 0 0 0 0 0 0 167 165 0 0 0 I also tried runs with 15 simultaneous processes and 25. 15 processes gave only about a 5 second stall but 25 gave again the same 75 second stall. Further, I tested with 2 mounts to the same server but from ZFS filesytems with the exact same stall/timeout periods. So, it doesn't appear to matter what the underlying filesystem is - it's something in NFS or networking code. Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? Thanks for any and all help/ideas. --Alan ___ 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: NFS 75 second stall
--- On Thu, 7/1/10, Garrett Cooper yanef...@gmail.com wrote: From: Garrett Cooper yanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 11:13 AM On Thu, Jul 1, 2010 at 11:01 AM, alan bryan alan.br...@yahoo.com wrote: Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an ls -l on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. # nfsstat -s -W -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 0 0 222 257 0 0 0 0 0 0 178 135 0 0 0 0 0 0 85 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... for 75 rows of all zeros 0 0 0 272 266 0 0 0 0 0 0 167 165 0 0 0 I also tried runs with 15 simultaneous processes and 25. 15 processes gave only about a 5 second stall but 25 gave again the same 75 second stall. Further, I tested with 2 mounts to the same server but from ZFS filesytems with the exact same stall/timeout periods. So, it doesn't appear to matter what the underlying filesystem is - it's something in NFS or networking code. Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? Thanks for any and all help/ideas. What network driver are you using? Have you tried tcpdumping the packets? -Garrett I'm using igb currently but have also used em. I have not tried tcpdumping the packets yet on this test. Any suggestions on things to look out for (I'm not that familiar with that whole process). Which brings up another point - I'm using TCP connections for NFS, not UDP. --Alan ___ 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: NFS 75 second stall
--- On Thu, 7/1/10, Garrett Cooper yanef...@gmail.com wrote: From: Garrett Cooper yanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 12:23 PM On Thu, Jul 1, 2010 at 11:51 AM, alan bryan alan.br...@yahoo.com wrote: --- On Thu, 7/1/10, Garrett Cooper yanef...@gmail.com wrote: From: Garrett Cooper yanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 11:13 AM On Thu, Jul 1, 2010 at 11:01 AM, alan bryan alan.br...@yahoo.com wrote: Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an ls -l on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. # nfsstat -s -W -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 0 0 222 257 0 0 0 0 0 0 178 135 0 0 0 0 0 0 85 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... for 75 rows of all zeros 0 0 0 272 266 0 0 0 0 0 0 167 165 0 0 0 I also tried runs with 15 simultaneous processes and 25. 15 processes gave only about a 5 second stall but 25 gave again the same 75 second stall. Further, I tested with 2 mounts to the same server but from ZFS filesytems with the exact same stall/timeout periods. So, it doesn't appear to matter what the underlying filesystem is - it's something in NFS or networking code. Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? Thanks for any and all help/ideas. What network driver are you using? Have you tried tcpdumping the packets? -Garrett I'm using igb currently but have also used em. I have not tried tcpdumping the packets yet on this test. Any suggestions on things to look out for (I'm not that familiar with that whole process). Which brings up another point - I'm using TCP connections for NFS, not UDP. Is the net.inet.tcp.tso sysctl enabled or not? What about rxcsum and txcsum? Thanks, -Garrett I haven't intentionally/explicitly set any of this so it's default: # sysctl net.inet.tcp.tso net.inet.tcp.tso: 1 igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=13bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4 ether 00:30:48:c3:26:94 inet 192.168.10.133 netmask 0xff00 broadcast 192.168.10.255 media: Ethernet autoselect (1000baseT full-duplex) status: active Thanks, Alan ___ 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: NFS 75 second stall
--- On Thu, 7/1/10, Garrett Cooper yanef...@gmail.com wrote: From: Garrett Cooper yanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 1:28 PM On Thu, Jul 1, 2010 at 1:18 PM, alan bryan alan.br...@yahoo.com wrote: --- On Thu, 7/1/10, Garrett Cooper yanef...@gmail.com wrote: From: Garrett Cooper yanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 12:23 PM On Thu, Jul 1, 2010 at 11:51 AM, alan bryan alan.br...@yahoo.com wrote: --- On Thu, 7/1/10, Garrett Cooper yanef...@gmail.com wrote: From: Garrett Cooper yanef...@gmail.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 11:13 AM On Thu, Jul 1, 2010 at 11:01 AM, alan bryan alan.br...@yahoo.com wrote: Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an ls -l on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. # nfsstat -s -W -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 0 0 222 257 0 0 0 0 0 0 178 135 0 0 0 0 0 0 85 127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... for 75 rows of all zeros 0 0 0 272 266 0 0 0 0 0 0 167 165 0 0 0 I also tried runs with 15 simultaneous processes and 25. 15 processes gave only about a 5 second stall but 25 gave again the same 75 second stall. Further, I tested with 2 mounts to the same server but from ZFS filesytems with the exact same stall/timeout periods. So, it doesn't appear to matter what the underlying filesystem is - it's something in NFS or networking code. Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? Thanks for any and all help/ideas. What network driver are you using? Have you tried tcpdumping the packets? -Garrett I'm using igb currently but have also used em. I have not tried tcpdumping the packets yet on this test. Any suggestions on things to look out for (I'm not that familiar with that whole process). Which brings up another point - I'm using TCP connections for NFS, not UDP. Is the net.inet.tcp.tso sysctl enabled or not? What about rxcsum and txcsum? Thanks, -Garrett I haven't intentionally/explicitly set any of this so it's default: # sysctl net.inet.tcp.tso net.inet.tcp.tso: 1 igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=13bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4 ether 00:30:48:c3:26:94 inet 192.168.10.133 netmask 0xff00 broadcast 192.168.10.255 media: Ethernet autoselect (1000baseT full-duplex) status: active Devise all of the available permutations that you need to use to test this out; there are a total of 3 variables, so 9 permutations, but you've already `tested one', so that makes the permutation count 8. Example: TXCSUM=off, RXCSUM=on, TSO=on TXCSUM=on, RXCSUM=off, TSO=on TXCSUM=on, RXCSUM=off, TSO=off ... Try executing the permutations on the client first, keeping the server constant, then make the client constant and make the server variable, and finally do both to the server and client
Re: NFS 75 second stall
--- On Thu, 7/1/10, Jeremy Chadwick free...@jdc.parodius.com wrote: From: Jeremy Chadwick free...@jdc.parodius.com Subject: Re: NFS 75 second stall To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 1:53 PM On Thu, Jul 01, 2010 at 11:01:04AM -0700, alan bryan wrote: Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an ls -l on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. ... Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? One thing worth asking: are there any firewall stacks (ipfw, ipfilter, or pf) in use on either the client or server? -- | Jeremy Chadwick ...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | Nope, no firewalls - just 2 machines connected directly to a Dell 2716 Gbit switch. Thanks, Alan ___ 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: NFS write corruption on 8.0-RELEASE
--- On Fri, 2/12/10, Rick Macklem rmack...@uoguelph.ca wrote: From: Rick Macklem rmack...@uoguelph.ca Subject: Re: NFS write corruption on 8.0-RELEASE To: Dmitry Marakasov amd...@amdmi3.ru Cc: freebsd-hack...@freebsd.org, freebsd-stable@freebsd.org, John Baldwin j...@freebsd.org Date: Friday, February 12, 2010, 11:12 AM On Fri, 12 Feb 2010, Dmitry Marakasov wrote: I'm planning a massive testing for this weekend, including removing soft mount option and trying linux client/server. Btw, I forgot to mention that I'm experiencing other NFS problems from time to time, including death of a mount (that is, all processes that try to access it freeze; this cures itself in some time with a message server is alive again). Also I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Last time I've seen it quite a while ago, so I don't remember the circumstances and direction of the traffic. There are some patches at: http://people.freebsd.org/~rmacklem that may be relevant if you are using vanilla FreeBSD-8.0. (They're all now in stable/8, but are post-release of 8.0.) rick ___ 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 This is interesting: I've seen another strange thing - not only the mount dies but the network is flooded with NFS traffic. Rick - this sounds very similar to the issues I was seeing (and reported in the thread on freebsd-stable Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS. For the record - I updated to the latest 8-Stable and that still didn't cure my issues. I was originally on hard mounts on udp, tried soft and TCP too, nothing solved it. So, a few days ago I switched to using samba and mount_smbfs instead and am now running 3 days without a crash or any network traffic/load issues. (same machine, same ZFS disks, etc...) Luckily it wasn't too painful to make the change. When I have more time I'd like to retry NFS. --Alan ___ 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: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS
--- On Wed, 2/3/10, Rick Macklem rmack...@uoguelph.ca wrote: From: Rick Macklem rmack...@uoguelph.ca Subject: Re: Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS To: alan bryan alan.br...@yahoo.com Date: Wednesday, February 3, 2010, 8:02 AM On Tue, 2 Feb 2010, alan bryan wrote: I've tried different network driver igb-em, UDP-TCP for NFS, enabling NFS locking on the server/clients (lockd, statd). I'm out of ideas so hoping this tcpdump sheds light on how it's getting stuck in this loop. You could try the experimental server, just to see if that has any effect. Either set nfsv4_server_enable=YES or add -e to both nfs_server_flags and mountd_flags. Note that the server will handle NFSv3, so you don't need to use NFSv4 mounts. rick Thanks - I might give that a try. This was only initially happening on our production stack which made it difficult to try things to troubleshoot. I've since been able to get it to happen on our dev stack too. Basically - I have about 70 mounts from the clients. 70 or so separate ZFS filesystems each exported via sharenfs. This appears to work well at first. After some traffic and some time (less than a day) the zombie writes start occuring. So, on dev we enabled dtrace (not at all familiar with it unfortunately) and tried to get this to happen. When it did happen we could see some patterns to the calls which matches up to the repeating conversations witnessed in the tcpdumps. zpool iostat when this is occuring is showing nothing being written to the disks. So, it appears that the client is requesting a write, NFS takes the request, asks ZFS which is replying with some error (from it's cache?) and then back to the client again. So, I'm starting to lean to this being more of a ZFS issue than an NFS one but I'm still not sure. We've read the recommendations about disabling the ZIL for ZFS/NFS and that sounds a bit scary. We've bought some Intel X25-E SSDs to mirror for a log device to add to the pool instead to see if that makes any sort of difference. (the thinking here is that this is now appearing like it might be a ZFS issue and that the speed of the SSDs plus the different code path in dealing with a dedicated log device might help us avoid the issue). So, if the SSDs don't change the behavior I may give the experimental NFS server a try to see if it helps. Thanks, Alan ___ 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
General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
I just read a different thread about problems with checksums on vge (and nfe in the replies). I'll just chime in here with some more information - I have a couple other message threads going about some weird high packet volumes on my new FreeBSD 8.0-Release NFS server. I thought it might be an issue with the igb driver so I put in a new card using em instead and got the exact same behavior. I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. This is for communications between this client machine (FreeBSD 7.0-Release) and any of the 8.0 machines I have. The packets going to non-8.0 machines (at least so far) appear to be fine. I'll defer to those who know more than I about the networking code, but is there perhaps an issue in general with the checksuming and not specific to one card or driver - is that even possible? That's now 4 different drivers all with various checksum problem reports. I'm going to be working on this all day today (and likely over the weekend) so if I can help by supplying information please let me know what you need. ___ 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: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
--- On Fri, 1/15/10, Chuck Swiger cswi...@mac.com wrote: From: Chuck Swiger cswi...@mac.com Subject: Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0? To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Friday, January 15, 2010, 11:21 AM Hi-- On Jan 15, 2010, at 11:12 AM, alan bryan wrote: [ ... ] I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. If you run tcpdump on a machine, it normally will receive the traffic being sent from that machine before the checksums are computed, especially if HW checksumming is being used. For reliable detection of these problems, you need to look at the traffic either on a hub or via the monitoring or span port of a smart switch, although simply glancing at the checksum stats from netstat -s on both sides should indicate whether significant error rates are happening. Regards, -- -Chuck Ah - thanks for the explanation as I'm new to tcpdump/wireshark. Need to learn more about those tools still. Watching systat -ip 1 gives results like: /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average | IP Input IP Output 4534 total packets received4395 total packets sent 0 - with bad checksums 4395 - generated locally 0 - too short for header 0 - output drops 0 - too short for data42 output fragments generated 0 - with invalid hlen 0 - fragmentation failed 0 - with invalid length0 destinations unreachable 0 - with invalid version 0 packets output via raw IP 0 - jumbograms 84 total fragments received UDP Statistics 0 - fragments dropped 3989 total input packets 0 - fragments timed out0 - too short for header 14 - packets reassembled ok 0 - invalid checksum 0 packets forwarded0 - no checksum 0 - unreachable dests 0 - invalid length 0 - redirects generated0 - no socket for dest port 0 option errors0 - no socket for broadcast 0 unwanted multicasts 0 - socket buffer full 4464 delivered to upper layer 3989 total output packets The total IP packets for this box should normally be in the hundreds per second - it stays constant at this 4K level. And the matching netstat -s: tcp: 47312791 packets sent 28828783 data packets (26317159806 bytes) 206 data packets (633246 bytes) retransmitted 11 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 12364262 ack-only packets (944193 delayed) 0 URG only packets 2518 window probe packets 3212717 window update packets 2903587 control packets 59176152 packets received 34785356 acks (for 26320662084 bytes) 1849829 duplicate acks 0 acks for unsent data 39787782 packets (24426616075 bytes) received in-sequence 601 completely duplicate packets (14975 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 101 out-of-order packets (114828 bytes) 2 packets (0 bytes) of data after window 0 window probes 4411949 window update packets 76 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 905931 connection requests 1098039 connection accepts 0 bad connection attempts 0 listen queue overflows 523 ignored RSTs in the windows 2003969 connections established (including accepts) 2002786 connections closed (including 4056 drops) 1187984 connections updated cached RTT on close 1191288 connections updated cached RTT variance on close 294899 connections updated cached ssthresh on close 0 embryonic connections dropped 34785321 segments updated rtt (of 29019225 attempts) 42636 retransmit timeouts 3512 connections dropped by rexmit timeout 2554 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 23 keepalive timeouts 23 keepalive probes sent 0 connections dropped by keepalive 79387 correct ACK header predictions 16380715 correct data
Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
--- On Fri, 1/15/10, Pyun YongHyeon pyu...@gmail.com wrote: From: Pyun YongHyeon pyu...@gmail.com Subject: Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0? To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Friday, January 15, 2010, 11:32 AM On Fri, Jan 15, 2010 at 11:12:43AM -0800, alan bryan wrote: I just read a different thread about problems with checksums on vge (and nfe in the replies). I'll just chime in here with some more information - I have a couple other message threads going about some weird high packet volumes on my new FreeBSD 8.0-Release NFS server. I thought it might be an issue with the igb driver so I put in a new card using em instead and got the exact same behavior. I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. This is for communications between this client machine (FreeBSD 7.0-Release) and any of the 8.0 machines I have. The packets going to non-8.0 machines (at least so far) appear to be fine. I'll defer to those who know more than I about the networking code, but is there perhaps an issue in general with the checksuming and not specific to one card or driver - is that even possible? That's now 4 different drivers all with various checksum problem reports. I'm going to be working on this all day today (and likely over the weekend) so if I can help by supplying information please let me know what you need. If you are seeing bad checksum reported by tcpdump/wireshark for TX frames on checksum capable controller, it's normal. bpf(4) just sees TX frames before inserting checksum computed by hardware so tcpdump/wireshark reports invalid checksum. You can safely ignore that. If you want to verify whether sending host generated correct checksum, you should capture the frame on receive side. If tcpdump/ wireshark reports bad checksummed frame on received frames it's real bad checksummed frame. Thanks for the help. After looking deeper into this issue today I'm now sure that I'm stuck in some NFS write/fail/retry loop. I'm still not sure if the trigger to get to that state is NFS, ZFS, or networking code. To try to get more information to act on, I'm going to change my client mount options and see what happens. Thanks everyone. ___ 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
State of igb on FreeBSD 8 stable?
I did some searching last night and found others using igb on Intel Cards having high interrupts and other strange issues and some comments to the effect that igb is soon going to have a lot of work done to it (I believe Jack Vogel is working on it). So, can someone give an estimation as to how soon that may be and how soon it may make it to 8-stable? If it's going to be a while I may look into adding a card using a different driver to test. My network device is: i...@pci0:8:0:0:class=0x02 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet Thanks, Alan ___ 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
Zombie NFS writing from FreeBSD clients to FreeBSD 8.0 server with ZFS
I have a AMD64 FreeBSD 8.0 server with ZFS filesystem being shared via NFS. These are being accessed by the clients. The clients are a mix of FreeBSD 6.2 32bit and FreeBSD 7.0 64bit. I have seen similar behavior from both versions of FreeBSD as clients. The behavior that I'm seeing is that everything is fine for a period of time and then the client starts writing large amounts of data to the NFS server. Writing is in quotes as nothing is actually being written to disk - this can go on for 12+ hrs or more - until the client is rebooted. It appears to cap out at around the 10-20Mbps rate and just sit there. Other clients are fine during this time. On the server: # nfsstat -s -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 25 2 38 7661 0 48 0 0 16 0 6 7601 0 14 0 0 21 0 13 7541 0 19 0 (client apache is stopped - nfsstat on client shows no activity) (server writes still continue) 0 13 0 1 7331 0 5 0 0 19 0 25 7479 0 59 0 0 9 0 9 0 23 0 0 14 0 51 7640 0 33 0 0 8 0 40 4476 0 25 0 (Right here is when the bad client is rebooted) (everything is good again) 4 26 1 66 21 0 31 0 0 6 0 50 19 0 4 0 0 15 0 86 23 0 32 0 On the clients (webservers) I killed apache and it appears that nothing is then writing any longer. The same nfsstat -c -w 1 then shows zero activity. However, the high write volume continues at the server until this broken client machine is rebooted - and then the large drop in writes as you see above. At that point everything is now normal again. Looking in /var/log/messages on the client and server in these time periods hasn't shown any errors. Client mounts in /etc/fstab look like: 192.168.1.33:/tank/share /usr/local/www/share nfs rw,-b,-i,-U,-3 0 0 Any ideas on what to try, where to look for more insight, etc...?? Thanks, Alan ___ 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: em0 no longer working after upgrading from 7.0 Release to Stable
--- On Mon, 7/7/08, Jack Vogel [EMAIL PROTECTED] wrote: As for that failure on igb1, try building in the kernel and see if that still happens, that one I have not seen. I rebuilt the kernel and there is now no igb1 failure. So, that only happened when loading the module after bootup. I'll also add that I am using ZFS on this machine in case that has any influence to what's going on. Thanks everyone, Alan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0 no longer working after upgrading from 7.0 Release to Stable
--- On Tue, 7/8/08, alan bryan [EMAIL PROTECTED] wrote: I rebuilt the kernel and there is now no igb1 failure. So, that only happened when loading the module after bootup. I'll also add that I am using ZFS on this machine in case that has any influence to what's going on. Well, maybe I celebrated too soon. After recompiling the kernel with device igb it shows no errors in the dmesg and I did ifconfig and igb0 and igb1 both showed up. But, it wasn't actually usable. I tried to ping the gateway and got this on the console: vm_thread_new: kstack allocation failed No more processes. and the pings were unsuccessful. I tried doing ifconfig igb0 down and then up again and same thing. Ideas? Thanks, Alan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
em0 no longer working after upgrading from 7.0 Release to Stable
I have a brand new Supermicro server that seems to be having issues with the em devices. I installed FreeBSD 7.0-Release from CDs and everything was working fine and then decided to cvsup to 7 stable and then I lost my em devices and thus networking. Reboots/power cycling didn't change it - no em at all since the upgrade to 7-Stable. I stuck in a USB to Ethernet stick (axe0) so I could get the server online to get this info. This is the Motherboard: http://www.supermicro.com/products/motherboard/Xeon1333/5400/X7DWN+.cfm Here's some more info: kenv | grep smbios smbios.bios.reldate=04/30/2008 smbios.bios.vendor=Phoenix Technologies LTD smbios.bios.version= 1.1 smbios.chassis.maker=Supermicro smbios.chassis.serial=0123456789 smbios.chassis.tag= smbios.chassis.version=0123456789 smbios.planar.maker=Supermicro smbios.planar.product=X7DWN+ smbios.planar.serial=0123456789 smbios.planar.version=PCB Version smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=Supermicro smbios.system.product=X7DW3 smbios.system.serial=0123456789 smbios.system.uuid=53d19f64-d663-a017-8922-003048c32782 smbios.system.version=0123456789 pciconf -lv [EMAIL PROTECTED]:0:0:0:class=0x06 card=0xa28015d9 chip=0x40038086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 rev=0x20 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe Port 1' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 rev=0x20 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe Port 3' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 rev=0x20 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe Port 5' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 rev=0x20 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe Port 7' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 rev=0x20 hdr=0x01 vendor = 'Intel Corporation' device = '(??) PCIe Port 9' class = bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:15:0:class=0x088000 card=0xa28015d9 chip=0x402f8086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) DMA/DCA Engine' class = base peripheral [EMAIL PROTECTED]:0:16:0: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FSB Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:16:1: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FSB Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:16:2: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FSB Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:16:3: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FSB Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:16:4: class=0x06 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FSB Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:17:0: class=0x06 card=0xa28015d9 chip=0x40318086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:21:0: class=0x06 card=0xa28015d9 chip=0x40358086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FBD Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:21:1: class=0x06 card=0xa28015d9 chip=0x40358086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FBD Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:22:0: class=0x06 card=0xa28015d9 chip=0x40368086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FBD Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:22:1: class=0x06 card=0xa28015d9 chip=0x40368086 rev=0x20 hdr=0x00 vendor = 'Intel Corporation' device = '(??) FBD Registers' class = bridge subclass = HOST-PCI [EMAIL PROTECTED]:0:28:0:class=0x060400 card=0xa28015d9 chip=0x26908086 rev=0x09 hdr=0x01
Re: em0 no longer working after upgrading from 7.0 Release to Stable
Should igb be in the GENERIC config file? pwd /usr/src/sys/amd64/conf cat GENERIC | grep igb I did a kldload if_igb and that seemed to work and I now have a igb0 device. I get an error though on the other (unused igb1) network port: igb0: Intel(R) PRO/1000 Network Connection version - 1.1.9 port 0x3000-0x301f mem 0xda02-0xda03,0xda00-0xda01,0xda08-0xda083fff irq 56 at device 0.0 on pci8 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:c3:27:82 igb1: Intel(R) PRO/1000 Network Connection version - 1.1.9 port 0x3020-0x303f mem 0xda06-0xda07,0xda04-0xda05,0xda084000-0xda087fff irq 70 at device 0.1 on pci8 igb1: Using MSIX interrupts with 3 vectors igb1: igb_allocate_receive_buffers: bus_dmamap_create failed: 12 igb1: Critical Failure setting up receive buffers device_attach: igb1 attach returned 12 igb0: link state changed to UP Thanks, Alan --- On Mon, 7/7/08, Xin LI [EMAIL PROTECTED] wrote: From: Xin LI [EMAIL PROTECTED] Subject: Re: em0 no longer working after upgrading from 7.0 Release to Stable To: alan bryan [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Date: Monday, July 7, 2008, 2:22 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Alan, alan bryan wrote: | I have a brand new Supermicro server that seems to be having issues with the em devices. I installed FreeBSD 7.0-Release from CDs and everything was working fine and then decided to cvsup to 7 stable and then I lost my em devices and thus networking. Reboots/power cycling didn't change it - no em at all since the upgrade to 7-Stable. I stuck in a USB to Ethernet stick (axe0) so I could get the server online to get this info. | | This is the Motherboard: | http://www.supermicro.com/products/motherboard/Xeon1333/5400/X7DWN+.cfm | | Here's some more info: [...] | [EMAIL PROTECTED]:8:0:0: class=0x02 card=0x10a715d9 chip=0x10a78086 | rev=0x02 hdr=0x00 | vendor = 'Intel Corporation' | class = network | subclass = ethernet | [EMAIL PROTECTED]:8:0:1: class=0x02 card=0x10a715d9 chip=0x10a78086 | rev=0x02 hdr=0x00 | vendor = 'Intel Corporation' | class = network | subclass = ethernet Looks like you are using 82575EB, which is now using igb(4) driver. Are you running a customized kernel which does not have igb in it? Cheers, - -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhyiRMACgkQi+vbBBjt66CzEQCgtDetU3LVkUYxgArq6ljPpuph JJMAnjs70h2/QCkzYqqBZseyR4ibwklG =TRPV -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7.0-Release and 3ware 9550SXU w/BBU - horrible write performance
Hi, I've got a new server with a 3ware 9550SXU with the Battery. I am using FreeBSD 7.0-Release (tried both 4BSD and ULE) using AMD64 and the 3ware performance for writes is just plain horrible. Something is obviously wrong but I'm not sure what. I've got a 4 disk RAID 10 array. According to 3dm2 the cache is on. I even tried setting The StorSave preference to Performance with no real benefit. There seems to be something really wrong with disk performance. Here's the results from bonnie: File './Bonnie.2551', size: 104857600 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 9989 4.8 6739 1.0 18900 7.8 225973 98.5 1914662 99.9 177210.7 259.7 Any ideas? Anybody have one of these that's working with FreeBSD 7? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] nve(4) locking cleanup
--- John Baldwin [EMAIL PROTECTED] wrote: I have a patch for nve(4) which fixes at least one known LOR in the driver and generally fixes up the locking. If you have an nve(4) card that currently works, please test this patch to make sure it doesn't break anything. If you have an nve(4) card that doesn't work, this patch probably won't help. Is this supposed to solve the device timeout (64) messages? My nve (builtin on Shuttle SN25P - FreeBSD 6.0 i386) works for a while but then eventually gives device timeout (64) messages. They sort of count up in number until hitting 64 although it's sometimes jumps straight up to 64. For example, 1,2,3,34,64 and then it stops working. I've found that it's triggered a lot faster when I have Kmail running and goes straight to 64 when my internet access drops out. Thanks, Alan __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nve0 nvidia onboard ethernet dies daily on 6.0 beta1
I'm still having problems with my onboard ethernet. It usually runs for a day or two and then I see this in the dmesg: ... nve0: device timeout (63) nve0: link state changed to DOWN nve0: link state changed to UP nve0: device timeout (63) nve0: link state changed to DOWN nve0: link state changed to UP nve0: device timeout (64) nve0: link state changed to DOWN nve0: link state changed to UP ... It seems that once it counts up to 64 that it then dies. What does that number count stand for? Is there a way to prevent this? Why does the link state keep going up/down (although I haven't noticed any problems and web/shh seem to work fine until it dies) This is on a Shuttle XPC SN25P system running 6.0 beta1. Thanks, Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nve0 nvidia onboard ethernet dies daily on 6.0 beta1
Forgot to also add the details of the Ethernet as it's being detected if that helps: nve0: NVIDIA nForce MCP9 Networking Adapter port 0xb000-0xb007 mem 0xd810-0xd8100fff irq 5 at device 10.0 on pci0 nve0: Ethernet address 00:30:1b:b8:86:dc miibus0: MII bus on nve0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nve0: Ethernet address: 00:30:1b:b8:86:dc nve0: [GIANT-LOCKED] Thanks for any help. --Alan --- alan bryan [EMAIL PROTECTED] wrote: I'm still having problems with my onboard ethernet. It usually runs for a day or two and then I see this in the dmesg: ... nve0: device timeout (63) nve0: link state changed to DOWN nve0: link state changed to UP nve0: device timeout (63) nve0: link state changed to DOWN nve0: link state changed to UP nve0: device timeout (64) nve0: link state changed to DOWN nve0: link state changed to UP ... It seems that once it counts up to 64 that it then dies. What does that number count stand for? Is there a way to prevent this? Why does the link state keep going up/down (although I haven't noticed any problems and web/shh seem to work fine until it dies) This is on a Shuttle XPC SN25P system running 6.0 beta1. Thanks, Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nve0 nvidia onboard ethernet dies daily on 6.0 beta1
--- Kövesdán Gábor [EMAIL PROTECTED] wrote: The nve driver has a lot of problems. You experienced just device timeouts, but other people - including me - experiences system crashes. As for me, I've had two kind of kernel panics, and device timeouts too. Cheers, Gabor Kovesdan Do you (or does anyone else here) have any recommendations then on a good PCI express (no plain PCI slots) ethernet card that doesn't use the nve driver? Maybe an Intel card? Gigabit speeds preferably. I could then use that until the nve driver gets fixed (Is somebody even working on fixing it?). Thanks, Alan Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Summary about nve network interface driver
--- Kövesdán Gábor [EMAIL PROTECTED] wrote: Hi, I've experineced serious errors with the nve driver and I've seen quite many people would like to use it, but they also experiences these error. I too would love it if this can be solved. I'm also willing to test and help wherever I can. In my case I get device timeouts and have just gotten used to rebooting about once per day when it runs out of buffer space and ceases to function. (If there's a way to re-initialize without a reboot that would help too). Thanks, Alan Bryan Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
--- Søren Schmidt [EMAIL PROTECTED] wrote: Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII n patches? Yes, I've done quite a bit of changes that affects this on -current. However its done blindfolded since I dont have a nForce4 based system here yet (but should soon). - Søren How soon is soon? I may be able to send you some hardware too if that would be helpful. I tried a -CURRENT kernel today but didn't build/install world or anything else as I don't want to mess up this machines 5.4 installation. The result was that it now seems to identify all the atapici0 - atapici3 controllers and doesn't do the repeated DISCONNECTED/CONNECTED messages but it still panicked near the end of the bootup process, around the USB area. I called a friend today who has a spare SATA drive I can borrow so I'll be picking that up tomorrow and I'll swap out drives and do a fresh -CURRENT install tomorrow on that new drive to see if I can get it any further along towards a successful boot. I'll report back with my findings. Thanks for the help! --Alan Bryan __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
--- Doug White [EMAIL PROTECTED] wrote: I guess turning off the RAID converts the chips into standard SATA controllers. I'll have to look into that. An nForce 4 machine recently appeared at work, so I'll see what I can get it to do. That's my understanding. FYI: I also tried turning on RAID in the bios and not actually assigning any of the disks to any RAID sets and everthing behaved just the same so it does't seem to matter whether it's on or off in the bios (assuming no disks actually used in an array). It looks like sos added support for atapci1 and 2 in this listing in the ATAmkIII patchset. While that patchset is in -CURRENT you'll have to apply the -stable patches yourself. Search the list archives for the location, soren posts it now and again. I upgraded my source from 5.4-RELEASE to 5-STABLE and applied the patchset, compiled a new kernel, installed it and rebooted. (This was the n version of ATAmkIII which I think is the latest.) It booted, I saw something about ATAPI2 and 3 and SATA and I got all excited for a second as I thought it was going to work. Then, a bunch of stuff flies by real fast and it ends with the following and then hard locks up. (manually retyped as the machine locks) ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those) subdisk6: detached ad6: detached ata2: SATA connect status= ata3: SATA connect ready time=0ms Any ideas? I'm confused about the attach/detach stuff as I'm not using any RAID, it's turned off in the bios. Just trying to get a single SATA drive to work. To further probe and test I tried physically moving the drive to other SATA sockets on the MB. When I did this I can get the system to boot up but it can't find the file systems. I manually told it where the root filesystem was. (it was now on ata5: so I told it ad10s1a, it then completed loading root filesystem) From this point I thought, well, at least now I can try atacontrol to see what's up. atacontrol mode 5 showed the disk still at UDMA33! I gave the command atacontrol mode 5 UDMA133 BIOSIO to try to set it higher but it didn't change anything. So, I'm now out of ideas. Anybody else have any? I could try -CURRENT but my understanding is that with the 5-STABLE and the patchset I'm pretty much the same ATA-wise, correct? Thanks for all the help thus far! --Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
(manually retyped as the machine locks) ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those) subdisk6: detached ad6: detached ata2: SATA connect status= ata3: SATA connect ready time=0ms OK, it may not be so much a lock up as I was just a bit impatient. After a while it panics with: Fatal trap 12 Page fault while in kernel mode fault virtual address 0x20c There's a bunch more that I can write down if that helps. Maybe I need to take a digital picture of the screen before it reboots as I'm a slow writer. Thanks for the help, I'd love to have this thing running at it's capable speed potential. This is my main workstation/desktop. I could update to -CURRENT if anyone thinks that will solve the disk speed problem without causing too many more. (Just do average desktop stuff like KDE3) If -CURRENT is in too much flux right now though maybe I'm better off with working but slow. --Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
Here's a recap of all the things I've tried and discovered in a bunch of testing today. Tried mkIII m patches and that doesn't show atapici1 or atapici2 - they just show as GENERIC with drives as UDMA33 Tried mkIII n patches and then atapici1 shows as nForce4 with SATA drives but has further problems detailed below. atapici2 always shows up in dmesg as GENERIC no matter what. Tried custom kernel, disabling all other parts of ATA with no difference. # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering Tried disabling the standard IDE ports in bios, turning off DMA on SATA, and other bios tweaks with no changes. With the n patches I get randomly alternating: lockup, Fatal trap 12 panic, or full boot but then it can't find the root filesystem as the disk is showing as detached. If I get lucky and it goes most of the way I get results like the following: ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those!) ad6: 70911MB WDC WD740GD-00FLA2 31.08F31 at ata3-master SATA 150 ad6: detached ata3: DISCONNECTED ata2: CONNECTED ata2: SATA connect status= ata2: DISCONNECTED ata3: CONNECTED ata3: SATA connect ready time=0ms ... Mounting root from ufs:/dev/ad6s1a setrootbyname failed ffs_mountroot: can't find rootvp root mount failed:6 Is there something else I should try to help in debugging this further? Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII n patches? Thanks for all the help! --Alan Bryan --- Doug White [EMAIL PROTECTED] wrote: On Fri, 20 May 2005, alan bryan wrote: --- Doug White [EMAIL PROTECTED] wrote: Can you post the output of pciconf -lv? The nForce IDE controller is properly detected, but it looks like there's another one in the system. Looking at the spec for the system it may be the proprietary nVidia RAID controller. The pciconf output should help us identify if thats the issue. FYI: RAID features are disabled in the BIOS, I'm just trying to get a single SATA drive to work at full speed. The other drive in this system is IDE and that seems to be working at proper speed. Thanks for the help! I guess turning off the RAID converts the chips into standard SATA controllers. I'll have to look into that. An nForce 4 machine recently appeared at work, so I'll see what I can get it to do. [EMAIL PROTECTED]:6:0: class=0x01018a card=0x50361297 chip=0x005310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:7:0: class=0x010185 card=0x50361297 chip=0x005410de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:8:0: class=0x010185 card=0xcb8410de chip=0x005510de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA It looks like sos added support for atapci1 and 2 in this listing in the ATAmkIII patchset. While that patchset is in -CURRENT you'll have to apply the -stable patches yourself. Search the list archives for the location, soren posts it now and again. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
--- Doug White [EMAIL PROTECTED] wrote: Can you post the output of pciconf -lv? The nForce IDE controller is properly detected, but it looks like there's another one in the system. Looking at the spec for the system it may be the proprietary nVidia RAID controller. The pciconf output should help us identify if thats the issue. FYI: RAID features are disabled in the BIOS, I'm just trying to get a single SATA drive to work at full speed. The other drive in this system is IDE and that seems to be working at proper speed. Thanks for the help! Here you go: # pciconf -l -v [EMAIL PROTECTED]:0:0: class=0x058000 card=0x50361297 chip=0x005e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= memory [EMAIL PROTECTED]:1:0: class=0x060100 card=0x50361297 chip=0x005010de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:1:1: class=0x0c0500 card=0x50361297 chip=0x005210de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= serial bus subclass = SMBus [EMAIL PROTECTED]:2:0: class=0x0c0310 card=0x50361297 chip=0x005a10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= serial bus subclass = USB [EMAIL PROTECTED]:2:1: class=0x0c0320 card=0x50361297 chip=0x005b10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= serial bus subclass = USB [EMAIL PROTECTED]:6:0: class=0x01018a card=0x50361297 chip=0x005310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:7:0: class=0x010185 card=0x50361297 chip=0x005410de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:8:0: class=0x010185 card=0xcb8410de chip=0x005510de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= mass storage subclass = ATA [EMAIL PROTECTED]:9:0: class=0x060401 card=0x chip=0x005c10de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:10:0:class=0x068000 card=0x50361297 chip=0x005710de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= bridge [EMAIL PROTECTED]:11:0:class=0x060400 card=0x0040 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:12:0:class=0x060400 card=0x0040 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:13:0:class=0x060400 card=0x0040 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:14:0:class=0x060400 card=0x0040 chip=0x005d10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:24:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:24:1: class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:24:2: class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:24:3: class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:6:0: class=0x040100 card=0x50361297 chip=0x17241412 rev=0x01 hdr=0x00 vendor = 'VIA Technologies Inc (Was: IC Ensemble Inc)' device = 'VT1720/24 Envy24PT/HT PCI Multi-Channel Audio Controller' class= multimedia subclass = audio [EMAIL PROTECTED]:7:0: class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6306 VIA Fire II IEEE-1394 OHCI Link Layer Controller' class= serial bus subclass = FireWire [EMAIL PROTECTED]:0:0: class=0x03 card=0x21181682 chip=0x014010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class= display subclass = VGA The only thing in this machine (add in cards) is the Shuttle SN25P motherboard and a nVidia PCIe 6600GT video card. Thanks for any help anyone can give. --Alan Bryan __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
nForce 4, SATA Drive only runs at UDMA33?
Hi, I've got a new machine and don't think I'm getting all the speed out of it that I should be. Any hints/ideas for what I can do to make the most of my new hardware? FreeBSD 5.4-Release Shuttle SN25P Nvidia NForce 4 with SATA 150 WD Raptor HD I ran atacontrol and it reports: # atacontrol list ATA channel 0: Master: ad0 Maxtor 6Y160P0/YAR41BW0 ATA/ATAPI revision 7 Slave: acd0 SONY DVD RW DRU-510A/1.0c ATA/ATAPI revision 6 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: no device present Slave: no device present ATA channel 3: Master: ad6 WDC WD740GD-00FLA2/31.08F31 Serial ATA v1.0 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present # atacontrol mode 3 Master = UDMA33 Slave = BIOSPIO It looks like the standard IDE port is being detected as the nForce4 but the SATA controllers aren't - they just get labelled GENERIC. Check it out below. A verbose dmesg reports: atapci0: nVidia nForce4 UDMA133 controller port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9ATAPI_SLAVE,ATA_MASTER ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ata1: [MPSAFE] atapci1: GENERIC ATA controller port 0xd800-0xd80f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 20 at device 7.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd800 atapci1: [MPSAFE] ata2: channel #0 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9f0 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf0 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata3: channel #1 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x970 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb70 ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata3-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1ATA_MASTER ata3: [MPSAFE] atapci2: GENERIC ATA controller port 0xc400-0xc40f,0xb60-0xb63,0x960-0x967,0xbe0-0xbe3,0x9e0-0x9e7 irq 22 at device 8.0 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc400 atapci2: [MPSAFE] ata4: channel #0 on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9e0 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe0 ata4: reset tp1 mask=03 ostat0=7f ostat1=7f ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata4-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata4: reset tp2 stat0=ff stat1=ff devices=0x0 ata4: [MPSAFE] ata5: channel #1 on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x960 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0xb60 ata5: reset tp1 mask=03 ostat0=7f ostat1=7f ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata5-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata5: reset tp2 stat0=ff stat1=ff devices=0x0 ata5: [MPSAFE] Any hints/ideas for what I can do to make the most of my new hardware? Thanks, Alan Bryan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
