Re: fun with if_re
On Thu, Feb 05, 2009 at 08:58:12AM +0100, Gerrit K?hn wrote: On Wed, 4 Feb 2009 19:46:55 +0900 Pyun YongHyeon pyu...@gmail.com wrote about Re: fun with if_re: PY Since you're using RTL8169SC it could be related with my commit PY r180519(cvs rev 1.95.2.22). It seems that RTL8169SC does not like PY memory mapped register access and I think jkim@ committed patch PY for the issue. Would you try re(4) in HEAD? PY (Just copying if_re.c, if_rlreg.h and if_rl.c from HEAD to PY stable would be enough to build re(4) on stable). Thanks for the advice. I did build new nanobsd images with these patches meanwhile and will start using them today. However, as it has worked without problems for weeks with the buggy version before, I will not be able to say if it is really working until next month or so. Or do you know any method to reliably That's fine. trigger such errors? Unfortunately no. Not all RTL8169SC controller shows the issue and I don't know whether you have problematic one. ___ 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
Ruby dumps core on 7.0-RELEASE-p7
Hi, I am using Ruby 1.8.6 (2008-08-11 patchlevel 287) on FreeBSD 7.0- RELEASE-p7. I have some code that -among other things- parses XML files and when it does in at least one case, it dumps core with the following error msg: -x-x-x- /usr/local/lib/ruby/1.8/rexml/parent.rb:19: [BUG] object allocation during garbage collection phase ruby 1.8.6 (2008-08-11) [i386-freebsd7] -x-x-x- At times, I get a different error msg: -x-x-x- /usr/local/lib/ruby/1.8/rexml/namespace.rb:16: [BUG] object allocation during garbage collection phase ruby 1.8.6 (2008-08-11) [i386-freebsd7] -x-x-x- I initially developed my code using Ruby 1.8.6 patchlevel 111 on the same platform and everything worked as expected. And when I upgraded to the latest stable version from ports, I started having these issues. Staying with 1.8.6 patchlevel 111 is not an option since this version is riddled with security vulnerabilities. Any ideas on how to fix this problem? TIA. -- Saad Kadhi We can't compete on price. We also can't compete on quality, features or service. That leaves fraud, which I'd like you to call marketing. -- Pointy-Haired Boss, Dilbert. ___ 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: Free memory after upgrade to 7.1
On Wed, 2009-02-04 at 18:42 +0100, Tomas Randa wrote: Yes, I do portupgrade -Rrfia after upgrade of course. I don`t think it is some new PHP bug, because my friend have same problem with memory and he do not upgraded ports. But his box do not free memory after apache reload, my yes Any other suggestions ? Thanks TR Tom Evans napsal(a): On Wed, 2009-02-04 at 17:08 +0100, Tomas Randa wrote: Hello, I have i386/PAE system (php, apache22, mysql) running on 7-STABLE and I can see strange behavior after upgrade from 7.0: Apache does not free memory, for example: CPU: 31.2% user, 0.0% nice, 12.8% system, 0.7% interrupt, 55.3% idle Mem: 3520M Active, 3705M Inact, 465M Wired, 314M Cache, 112M Buf, 12M Free Swap: 4096M Total, 105M Used, 3991M Free, 2% Inuse then apachectl graceful CPU: 28.3% user, 0.0% nice, 8.6% system, 0.0% interrupt, 63.1% idle Mem: 631M Active, 3126M Inact, 353M Wired, 213M Cache, 112M Buf, 3693M Free Swap: 4096M Total, 1844K Used, 4094M Free Some graph: http://max.af.czu.cz/memoryload.png I know before upgrade was memory using about 2,5GB, now much more, apache sometimes crash. Thanks for some help Tomas Randa What is apache doing to use so much memory? This looks more like a memory leak in PHP, which is reclaimed after apache restarts its children. When you upgraded the OS, did you also upgrade ports? Could a new version of PHP be at fault here? Cheers Tom Well, apache + its regular modules dont tend to leak memory, which is what is happening. Can you run tests, eg by running your application on apache with valgrind, to determine exactly where the leak occurs. Tom ___ 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: fun with if_re
On Thu, 5 Feb 2009 17:28:04 +0900 Pyun YongHyeon pyu...@gmail.com wrote about Re: fun with if_re: PY I did build new nanobsd images with these patches meanwhile and will PY start using them today. However, as it has worked without problems PY for weeks with the buggy version before, I will not be able to say PY if it is really working until next month or so. Or do you know any PY method to reliably PY That's fine. Sorry to be back so soon again, but I just noticed that I did in fact not produce new images yesterday. :-) Kernel build stopped with --- mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/tmp/usr/obj/usr/work/curren t/src/sys/FIREFLY /usr/work/current/src/sys/modules/mii/../../dev/mii/acphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/amphy.c /usr/ work/current/src/sys/modules/mii/../../dev/mii/atphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/bmtphy.c /usr/work/current/src/sys/m odules/mii/../../dev/mii/brgphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ciphy.c /usr/work/current/src/sys/modules/mii/../../dev/m ii/e1000phy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/exphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/gentbi.c /usr/wor k/current/src/sys/modules/mii/../../dev/mii/icsphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/inphy.c /usr/work/current/src/sys/modu les/mii/../../dev/mii/ip1000phy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/jmphy.c /usr/work/current/src/sys/modules/mii/../../dev/m ii/lxtphy.c miibus_if.c /usr/work/current/src/sys/modules/mii/../../dev/mii/mii.c /usr/work/current/src/sys/modules/mii/../../dev/mii/mii_physu br.c /usr/work/current/src/sys/modules/mii/../../dev/mii/mlphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/nsgphy.c /usr/work/current /src/sys/modules/mii/../../dev/mii/nsphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/nsphyter.c /usr/work/current/src/sys/modules/mii /../../dev/mii/pnaphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/qsphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/rgephy. c /usr/work/current/src/sys/modules/mii/../../dev/mii/rlphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ruephy.c /usr/work/current/sr c/sys/modules/mii/../../dev/mii/tdkphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/tlphy.c /usr/work/current/src/sys/modules/mii/../. ./dev/mii/truephy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ukphy.c /usr/work/current/src/sys/modules/mii/../../dev/mii/ukphy_subr. c /usr/work/current/src/sys/modules/mii/../../dev/mii/xmphy.c In file included from /usr/work/current/src/sys/modules/mii/../../dev/mii/rgephy.c:60: @/pci/if_rlreg.h:1509:28: error: token ; is not valid in preprocessor expressions @/pci/if_rlreg.h:1917:6: error: unterminated comment @/pci/if_rlreg.h:1509:1: error: unterminated #if In file included from /usr/work/current/src/sys/modules/mii/../../dev/mii/rlphy.c:56: @/pci/if_rlreg.h:1509:28: error: token ; is not valid in preprocessor expressions @/pci/if_rlreg.h:1917:6: error: unterminated comment @/pci/if_rlreg.h:1509:1: error: unterminated #if mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error --- Any hints? cu Gerrit ___ 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: fun with if_re
On Thu, 5 Feb 2009 12:05:46 +0100 Gerrit Kühn ger...@pmp.uni-hannover.de wrote about Re: fun with if_re: GK Sorry to be back so soon again, but I just noticed that I did in fact GK not produce new images yesterday. :-) GK Kernel build stopped with [...] Ignore me, my bad (downloaded the webpage instead of the code via webcvs :-). On my way now. cu Gerrit ___ 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: 7.1-RELEASE I/O hang
Kostik Belousov wrote: Compile ddb into the kernel, and do ps from the ddb prompt. If there are processes hung in the nbufkv state, then the patch below might help. The bonnie++ processes are in state newbuf and other hung processes (bash, newly forked sshds, etc) appear to be in the ufs state. The patch appears to have no effect, although at the last hang I did see one of the bonnie++ processes in nbufkv state. This could be coincidental. The problem also exhibits itself when running a parallel bonnie++ on a single array, both with the onboard PERC6/i and the PERC6/e. I have no access to other controllers. ___ 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: 7.1-RELEASE I/O hang
On Thu, Feb 05, 2009 at 11:26:58AM +, Matt Burke wrote: Kostik Belousov wrote: Compile ddb into the kernel, and do ps from the ddb prompt. If there are processes hung in the nbufkv state, then the patch below might help. The bonnie++ processes are in state newbuf and other hung processes (bash, newly forked sshds, etc) appear to be in the ufs state. What is the state of the bufdaemon process ? The patch appears to have no effect, although at the last hang I did see one of the bonnie++ processes in nbufkv state. This could be coincidental. The problem also exhibits itself when running a parallel bonnie++ on a single array, both with the onboard PERC6/i and the PERC6/e. I have no access to other controllers. pgprBwwjMdLSh.pgp Description: PGP signature
Re: 7.1-RELEASE I/O hang
Kostik Belousov wrote: Compile ddb into the kernel, and do ps from the ddb prompt. If there are processes hung in the nbufkv state, then the patch below might help. The bonnie++ processes are in state newbuf and other hung processes (bash, newly forked sshds, etc) appear to be in the ufs state. What is the state of the bufdaemon process ? qsleep -- ___ 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 umount soft hang
I have an NFS server and NFS client separated by a firewall. Both servers are FreeBSD 7.1. Server configuration: nfs_server_enable=YES nfs_server_flags=-t -n 4 rpcbind_enable=YES mountd_flags=-r -p 737 mountd_enable=YES The firewall allows tcp and udp to port 111, but only tcp to ports 2049 and 737 (configured for mountd, see above). On the client I use e.g. the following command for mounting: mount -t nfs -o nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768 :/export/usr/obj /usr/obj Mounting and subsequent fs operations work flawlessly. When I unmount umount command hangs but can be interrupted with ^C. Everything seems to be clean after that - the filesystem is unmounted, there are no post-effects on both client and server. I used ktrace and tcpdump to investigate this and it seems that umount command tries to send something to server's mountd via udp: ... 13181 umount CALL sendto(0x4,0x2823e354,0x70,0,0x2823c008,0x10) 13181 umount GIO fd 4 wrote 112 bytes ... 000477 IP (tos 0x0, ttl 64, id 19976, offset 0, flags [none], proto UDP (17), length 140) 10.99.15.160.960 10.99.10.87.737: UDP, length 112 If wonder if this is correct behavior of umount. Do I need to get mountd udp port allowed in the firewall? Or is there a way to configure everything to tcp only? -- Andriy Gapon ___ 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
To John Birrell: weird behaviors of DTrace on amd64
Hi John Birrell,
I am exploring DTrace on 7.1-STABLE FreeBSD amd64 and I found several
weird behaviors:
1) Not all kernel functions show up in fbt provider. Take isp(4) as example:
dtrace -l shows
static void isp_freeze_loopdown(ispsoftc_t *, int, char *);
___but not___
static void isp_handle_platform_atio2(ispsoftc_t *, at2_entry_t *);
Both are static functions. But one shows up in fbt, another not.
What's the rational behind it ? Any way to fix it ?
2) The symptom described below only shows in 64-bit platform (amd64).
Here is the D Code:
fbt::isp_handle_platform_atio2:entry
{
self-cdb =args[1]-at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
printf(%s(%x, %x, cdb_cmd %x)\n, probefunc, arg0, arg1, self-cdb);
}
It will never fire.
I have to add another 2 probes on top of it, then it
(fbt::isp_handle_platform_atio2:entry) will trace.
Even the 2 probes on top of it never fire.
---
dtrace:::BEGIN
{
tr = 0;
}
fbt:::entry
/tr == 1/
{
@a[probefunc] = count();
}
fbt::isp_handle_platform_atio2:entry
{
self-cdb =args[1]-at_cmnd.cdb_dl.sf.fcp_cmnd_cdb[0];
printf(%s(%x, %x, cdb_cmd %x)\n, probefunc, arg0, arg1, self-cdb);
}
Thanks,
K. Zhu
___
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
Announcement: PmcTools callchain capture for FreeBSD 7.1 and stable_7
Hello, I've created a new patch for all the pmc feature available on trunk (02/05). It has been tested on a core2duo in amd64 and i386 mode with success. Feel free to test and give your feedback. Thanks to Joseph Koshy for the hard work on pmc. Patch is linked on the PmcTools wiki page: http://wiki.freebsd.org/PmcTools . Fabien
Re: fun with if_re
As I don't own that server anymore, I'm afraid I can't tell you whether it's working now. :( On Thu, Feb 05, 2009 at 10:31:47AM +0900, Pyun YongHyeon wrote: On Wed, Feb 04, 2009 at 06:37:53PM +0100, Henrik Friedrichsen wrote: Hey. I have had similar symptoms on a dedicated server with the re driver. What I did was grab more recent drivers (which might be redundant now) and disable a set of features that weren't stable at the time. re(4) had several issues for PCIe based controllers on 7.0-RELEASE and I believe most issues were resolved in HEAD/stable so I think you can safely turn checksum offloading, VLAN hardware assistance features. You can also enable TSO(default off) but I remember some users reported issues for TSO, I didn't encounter TSO issues though. If you can still reproduce the issue please let me know. Please have a look at this PR that I submitted back then: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/125805 ___ 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
Fwd: aac0 issues, Controller is no longer running
Forwarding to list because mail to ema...@freebsd.org bounced at the
location it is apparently being forwarded to so I'm not sure if it
was received. I'll add that the problem seems to follow a pattern where
it happens only twice after a reboot (usually in the morning when rsync runs)
and then its fine until the next intentional reboot.
---BeginMessage---
Ed,
I've been having issues with the aac0 driver with a Sun STK raid card (
Adaptec 5805 ). After FBSD upgrades and a reboot,
it will lock up when rsync backups run at night. After doing this about 2-3
times over 2-3 days, it will stabilize and be rock
solid. If you could assist me in maybe debugging it somehow, I would greatly
appreciate it.
Info:
Controller Status: Optimal
Channel description : SAS/SATA
Controller Model : Sun STK RAID INT
Controller Serial Number : 00809AA0182
Physical Slot: 48
Temperature : 64 C/ 147 F (Normal)
Installed memory : 256 MB
BIOS : 5.2-0 (15583)
Firmware : 5.2-0 (15583)
Driver : 5.2-0 (15583)
Boot Flash : 5.2-0 (15583)
Raid5+HSP setup with 8 SAS disks.
Code here:
code = AAC_GET_FWSTATUS(sc);
if (code != AAC_UP_AND_RUNNING) {
device_printf(sc-aac_dev, WARNING! Controller is no
longer running! code= 0x%x\n, code);
And one that mentions: COMMAND %p TIMEOUT AFTER %d SECONDS\n,
TIA,
--
Bryan G. Seitz
---End Message---
___
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: Replace Cisco IOS/CBOS with freebsd - possible?
Chris H presented these words - circa 1/30/09 4:54 PM- Hello Patrick, and thank you for your reply. Quoting Patrick Mahan ma...@mahan.org: Chris H presented these words - circa 1/30/09 7:03 AM- Hello Bruce, and thank you for your reply. Quoting Bruce M. Simpson b...@freebsd.org: Chris H wrote: ... I know Peter Grehan was looking at getting FreeBSD onto the Cisco 827 a while back. That's good news. I'll have to see if I can get more info on that. I just purchased a lot of cisco *DSL/routers on ebay, in an effort to push this project forward (I can experiment on these with less concern). IMHO pfSense beats the pants off OpenWRT from a user/deployment point of view, and often that is ultimately what counts. I guess I'd have to agree, except if it weren't for the fact I always have a zillion things going simultaneously, I wouldn't even know what X was - I can't get enough VC's (virtual consoles), so I'm forced to use X. But, of course for most end users /convenience/ is everything, and most don't want to any more that how to turn it on. :) Thing is, it's only for x86-based PCs. I had the foresight to purchase some relatively quiet 1U boxes, but they're still too noisy to have in a room where people sleep live or socialise -- they belong to the computer nook at the front of the apartment (I have a very odd C-shaped apartment). Yes, the (older) cisco's CPU's were MIPS - aka - Motorola, and ran AUX. I've got the latest version of AUX, which is a newer version than they ran. In fact, it wouldn't be a bit surprised if I could load AIX on it. Yes, most of the core CPU's used by Cisco were MIPS, however, they were not made by Motorola Please take no offense. But as I look inside, the CPU does, in fact say Motorola. The documentation for it also confirms that most of (if not all) of the 800 series also used the Motorola RISC. None taken. I was never directly involved with any of the 800 series platforms, but do not doubt they might have Motorola RISC chips. My point was the where MIPs CPUs were used, they were (mostly) not built by Motorola. These were (are) probably some of the PPC platforms. I do know that some platforms used CPUs (e.g. Cavium Octeon) that are MIPs cores. and didn't run AUX (if by AUX you mean Apples Unix OS). I probably stand corrected on this. :) But I'll bet - given the CPU, it wouldn't be much of a streatch to run either AUX, or AIX on it. Maybe. I do know that some of the common stuff in the kernel (like pci) would probably not work. I distinctly recalled having to craft a UART driver when doing some early linux and FreeBSD investigations. Patrick Thanks again for your response. --Chris Instead they ran Cisco's own IOS kernel/software. Patrick Mahan I believe something that could really make pfSense fly, would be a viable port to mass-market, low-power consumer hardware. Then again, old Ciscos sort of fit the bill. Funny you bring that up. I was thinking the very same. As a matter of fact I have been contemplating whipping something up myself, and doing just that. While psSense initially seems appealing. The more I look into it, the more I find it's laking - where a simple roll-out is concerned. There isn't anything in the way of documentation. What's there is /horribly/ unorganized. It's scattered all over the place. What's more, the front page of the wiki suggests that reading the m0n0wall documentation would probabl;y be a better choice. Make no mistake, I know how daunting and hectic an opensource project can be, and am grateful to /anyone/ whom is willing to share the fruits of their labor at no cost. But I think I could do better, that's all. Repurposing old vendor hardware is just as subject to engineering process as anything else, in some cases, the varying Bill-of-Materials may make the economic cost too high to do things on a mass scale. I think I have a solution for that. I'll elaborate further when I can confirm that. If people would be reasonably expected to use such a system, they should not have to understand the mechanisms, in great detail, of how firmware is loaded onto a device. This is one of the main stumbling blocks behind mass uptake -- we can't just say fire up this tool and click this 1 button to extend/build new network infrastructure. Given the current economic and ecological situation, though, devising systems which allow people to do this might be something worth investigating, and funding to that effect may be available out there. I /quite/ agree, and intend to persue just that. I've already commissioned the artwork - and it looks GREAT. :) I'll elaborate further as things firm up. Thanks again Bruce, for taking the time to respond. --Chris cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
impossible packet length ...
Hi, on 2 different servers, running 7.1-stable + zfs, I get this error rather frequently: Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1936028704) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1869363744) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1667787057) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (976040755) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1953459488) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1348825156) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (0) from nfs server sunfire:/dist Feb 5 17:01:03 warhol-00 kernel: impossible packet length (1647208041) from nfs server sunfire:/dist in this case the server is running Freebsd-7.0-stable, but I also get it when the server is a netapp. is there a connection? thanks, danny ___ 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: impossible packet length ...
On 2009-Feb-06 08:32:27 +0200, Danny Braniss da...@cs.huji.ac.il wrote: on 2 different servers, running 7.1-stable + zfs, I get this error rather frequently: Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) from nfs server sunfire:/dist I gather warhol-00 is running 7.1-S+ZFS. How recent a 'stable' is it? Where does ZFS fit in? Is sunfire:/dist mountpoint in a local ZFS or is a local ZFS mountpoint inside the sunfire:/dist mount? Do you get the same problems without any ZFS mounts? Is this a TCP or UDP NFS mount? What happens if you switch protocols? What NIC are you using and are you seeing any network errors? Are you able to capture a protocol trace showing the transaction including erroneous packet? -- Peter Jeremy pgpu4kjVvzpv2.pgp Description: PGP signature
Re: impossible packet length ...
On 2009-Feb-06 08:32:27 +0200, Danny Braniss da...@cs.huji.ac.il wrote: on 2 different servers, running 7.1-stable + zfs, I get this error rather frequently: Feb 5 17:01:03 warhol-00 kernel: impossible packet length (543383918) fro= m=20 nfs server sunfire:/dist So many quetsions :-) I gather warhol-00 is running 7.1-S+ZFS. How recent a 'stable' is it? very: FreeBSD warhol-00 7.1-STABLE FreeBSD 7.1-STABLE #37: Fri Jan 23 10:41:54 IST 2009 and its amd64. Where does ZFS fit in? Is sunfire:/dist mountpoint in a local ZFS or is a local ZFS mountpoint inside the sunfire:/dist mount? warhole is a nfs server, the storage is a ZFS local raid, the errors occure on a nfs/tcp mounted file system on warhol. Do you get the same problems without any ZFS mounts? I have several hosts running 7.1-stable without nfs exported ZFS, non have this error That is why I think there is a connection, because on two, which have ZFS exported the problem appears. Is this a TCP or UDP NFS mount? What happens if you switch protocols? i'll try but not trivial. the other difference between the boxes is that one is dataless, while the other is stand-alone (well, / is on a local disk, but /usr/local home dirs are on the network/nfs). What NIC are you using and are you seeing any network errors? bce, the boxes are Dell-2950, but no visible errors. Are you able to capture a protocol trace showing the transaction including erroneous packet? I have started the capture, but since I don't know what triggers the problem, it will take some time. I will also start capturing packets at the router level, but that will have to wait till next week. thanks, danny --=20 Peter Jeremy --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmL4t8ACgkQ/opHv/APuIeXNQCgg68TMfH6zh1gRaKfhCkNQi+0 y10AoJcG7/7fiqL8oUpsWhIwhceWSFPo =MKeo -END PGP SIGNATURE- --gKMricLos+KVdGMg-- ___ 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
