Re: Analysis of disk file block with ZFS checksum error

2008-05-30 Thread Pawel Jakub Dawidek
On Mon, Feb 11, 2008 at 12:39:08PM -0700, Joe Peterson wrote: Gavin Atkinson wrote: Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt block before or after the datestamp of the file it was found within? i.e. was the corrupt block on the disk before or after the mp3 was

Re: ZFS on root and disk write caching.

2008-05-30 Thread Pawel Jakub Dawidek
On Thu, May 29, 2008 at 01:58:21PM +0200, Arnaud Houdelette wrote: Pawel Jakub Dawidek a écrit : On Wed, May 21, 2008 at 03:00:41PM +0200, Arnaud Houdelette wrote: 3. I'd like to keep the storage pool (zraid1) separated from the system pool (just one disk). The wiki states that we may

RELENG_7 amd64; memory and vm.kmem_size

2008-05-30 Thread Jeremy Chadwick
As has been pointed out on wikis, mailing lists, and even on IRC, ZFS requires a bit of tuning -- specifically in regards to vm.kmem_size and vm.kmem_size_max. The opinion is: ZFS is memory-hungry. On my home RELENG_7 amd64 box (2GB RAM), I could panic the system with heavy I/O due to kmem_size

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Peter Jeremy
On 2008-May-29 18:11:56 -0400, Robert Blayzor [EMAIL PROTECTED] wrote: working. Only way to correct it seems to reboot the server... even under RELENG_7_0 so the upgrade from 4_11 did not fix the problem. Unfortunately, your issue is a bug in the client: The server is trying to send data

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Tod McQuillin
On Fri, 30 May 2008, Peter Jeremy wrote: As a work-around, you could write a cronjob that scans netstat and temporarily creates an ipfw 'reset' rule that matches each FIN_WAIT_1 socket In the past, I've used something like this: netstat -an | grep FIN_WAIT_1 | perl -pe

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Ian Smith
On Thu, 29 May 2008, Robert Blayzor wrote: On May 29, 2008, at 8:55 PM, Matthew Dillon wrote: It's got to a be a bug on the client(s) in question. I can't think of anything else. You may have to resort to injecting a TCP RST packet (e.g. via a TUN device) to clear the

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread David Malone
On Fri, May 30, 2008 at 06:11:43PM +1000, Peter Jeremy wrote: A real solution would require more thought. I suspect you need a mechanism similar to the keepalive timer that starts when there is data queued and is reset when (some) data is sent - this would catch your situation but I'm not

Re: broken re(4)

2008-05-30 Thread Dimitry Andric
On 2008-05-30 07:03, Pyun YongHyeon wrote: Since you're running this patch would you post dmesg output related with re(4)? Also please post the output of devinfo -rv | grep oui. dmesg -- Copyright (c) 1992-2008 The FreeBSD

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 29, 2008, at 11:07 PM, Doug Barton wrote: Hrrm, are you running ipfw ON the web server box? If so, I'd be curious as to why, and whether or not the problem goes away if you take IPFW out of the equation. If IPFW is running on another machine, never mind. Yes, IPFW is running on

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 30, 2008, at 4:41 AM, Ian Smith wrote: Without debating your stateful alternative - either should work fine for TCP applications - this allowed inbound icmp packets for types 0,3,8,11 but no outbound icmp at all (assuming your firewall defaults to deny). I didn't post all the

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 30, 2008, at 4:47 AM, David Malone wrote: There has been some talk about this sort of problem on the IETF TCP Maintainers list. I don't think any good conclusion was reached - whatever the solution was certainly needs to be tunable per-socket because this behaviour is perfectly valid in

JDK+libthr on STABLE

2008-05-30 Thread Huang wen hui
hi, I try to run java to call external program heavily on very recent STABLE. Somtimes java hang on calling external program. ps show some defunct process name. 11599 p9 RL+ 0:02.77 /usr/local/jdk1.5.0/bin/java -classpath . cn/org/gddsn/test/TestShell 12431 p9 R+ 0:00.00

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 30, 2008, at 4:18 AM, Tod McQuillin wrote: This relies on tcpdrop, included as /usr/sbin/tcpdrop on FreeBSD 6.x; you may need to install it from a port on FreeBSD 4.x. Thanks, that seems like a reasonable band aid for now. Worked perfectly. -- Robert Blayzor, BOFH INOC, LLC

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 30, 2008, at 4:41 AM, Ian Smith wrote: Without debating your stateful alternative - either should work fine for TCP applications - this allowed inbound icmp packets for types 0,3,8,11 but no outbound icmp at all (assuming your firewall defaults to deny). Switching the ipfw rules

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Peter Jeremy
On 2008-May-30 05:35:56 -0400, Robert Blayzor [EMAIL PROTECTED] wrote: A timeout value would be fine. The problem is selecting a sensible timeout - 30-60s might be reasonable for a webserver that serves static content but is a bit short for a shell session... On a side note, I could easily fix

3Com NIC choking

2008-05-30 Thread Patrik Roos
Since getting my cable upgraded to 24Mbit down and 10Mbit up and getting excited with torrents, I've started experiencing weird errors with my 3Com NIC whenever it's being used at high speeds. It'll basically work fine for a while until it suddenly stops sending any packets and the connection to

Re: broken re(4)

2008-05-30 Thread Oliver Fromme
Gerrit Kühn wrote: As Oliver already suggested, I will take out the controller and see what happens then. Talking about this controller: This is also the only board I am using with PCI cards (and thus with a PCI riser) at all. I remember vaguely that I had a few problems getting the

Re: broken re(4)

2008-05-30 Thread Wilko Bulte
Quoting Oliver Fromme, who wrote on Fri, May 30, 2008 at 01:44:43PM +0200 .. Gerrit Kühn wrote: As Oliver already suggested, I will take out the controller and see what happens then. Talking about this controller: This is also the only board I am using with PCI cards (and thus

Re: RELENG_7 amd64; memory and vm.kmem_size

2008-05-30 Thread Oliver Fromme
Jeremy Chadwick wrote: [...] vm.kmem_size=3584M vm.kmem_size_max=3584M Upon reboot, the kernel immediately panic'd with the following message: kmem_suballoc(): bad status return of 3. I then chose smaller values (going with 2048M); same panic. I remember someone on the -fs

Re: broken re(4)

2008-05-30 Thread Gerrit Kühn
On Fri, 30 May 2008 13:44:43 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote about Re: broken re(4): OF Talking about this controller: This is also the only board I am OF using with PCI cards (and thus with a PCI riser) at all. I remember OF vaguely that I had a few problems getting the

Re: broken re(4)

2008-05-30 Thread Gerrit Kühn
On Fri, 30 May 2008 13:49:24 +0200 Wilko Bulte [EMAIL PROTECTED] wrote about Re: broken re(4): WB Typing pci riser card jumper in Google will give you WB many more pages with interesting (or frightening) stuff WB to read. WB Well, if you know how the PCI bus electrically works this kind of WB

Re: broken re(4)

2008-05-30 Thread Gerrit Kühn
On Fri, 30 May 2008 13:44:43 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote about Re: broken re(4): OF That rings a bell ... OF I remember reports of riser cards that apparently changed OF the timing on the PCI bus so they were only marginally OF compliant with the spec, or maybe not even

Re: broken re(4)

2008-05-30 Thread Gerrit Kühn
On Fri, 30 May 2008 14:03:08 +0900 Pyun YongHyeon [EMAIL PROTECTED] wrote about Re: broken re(4): PY Since you're running this patch would you post dmesg output related PY with re(4)? Also please post the output of devinfo -rv | grep PY oui. Here is my output with the latest (28th May) patch:

Re: broken re(4)

2008-05-30 Thread Wilko Bulte
Quoting Gerrit Khn, who wrote on Fri, May 30, 2008 at 02:47:59PM +0200 .. On Fri, 30 May 2008 13:49:24 +0200 Wilko Bulte [EMAIL PROTECTED] wrote about Re: broken re(4): WB Typing pci riser card jumper in Google will give you WB many more pages with interesting (or frightening) stuff WB

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Max Laier
On Friday 30 May 2008 11:35:56 Robert Blayzor wrote: On May 30, 2008, at 4:47 AM, David Malone wrote: There has been some talk about this sort of problem on the IETF TCP Maintainers list. I don't think any good conclusion was reached - whatever the solution was certainly needs to be tunable

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Matthew Dillon
:Yes, IPFW is running on the box. Why not? : :-- :Robert Blayzor, BOFH :INOC, LLC :[EMAIL PROTECTED] :http://www.inoc.net/~rblayzor/ There's nothing wrong with running IPFW on the same box :-) But, I think that rule change is masking the problem rather then solving it. The

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 30, 2008, at 12:43 PM, Matthew Dillon wrote: I would be very careful with any type of ruleset (IPFW or PF) which relies on keep-state. You can wind up causing legitimate connections to drop if it isn't carefully tuned. Thanks again Matt... I do agree on the firewall and

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Doug Barton
Robert Blayzor wrote: On May 29, 2008, at 11:07 PM, Doug Barton wrote: Hrrm, are you running ipfw ON the web server box? If so, I'd be curious as to why, and whether or not the problem goes away if you take IPFW out of the equation. If IPFW is running on another machine, never mind. Yes,

Re: Sockets stuck in FIN_WAIT_1

2008-05-30 Thread Robert Blayzor
On May 30, 2008, at 3:17 PM, Doug Barton wrote: I'm not sure why, but I sense hostility on your part. I'm not sure why, since that is an odd reaction to someone who is trying to help you. If I'm wrong about that, never mind. I'm not being hostile, geez. ;) I simply asked why not? Plenty