Re: bin/176713: [patch] nc(1) closes network socket too soon

2013-07-22 Thread Adrian Chadd
Right. Yes, I had a typo. I meant that it shouldn't die on seeing a read EOF after closing the write side of the socket. So, what you're saying is: * nc sees EOF on stdin * nc decides to abort before seeing the rest of the data come in from the remote socket (and then trying to write it, and

Re: Kernel crashes after sleep: how to debug?

2013-07-22 Thread John Baldwin
On Friday, July 19, 2013 10:16:15 pm Yuri wrote: On 07/19/2013 14:04, John Baldwin wrote: Hmm, that definitely looks like garbage. How are you with gdb scripting? You could write a script that walks the PQ_ACTIVE queue and see if this pointers ends up in there. It would then be

Re: UFS related panic (daily - find)

2013-07-22 Thread John Baldwin
On Friday, July 19, 2013 1:45:11 pm rank1see...@gmail.com wrote: I had 2 panics: (Both occured at 3 AM, so had to be daily task) First (Jul 2 03:06:50 2013): -- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x19 fault code = supervisor read, page

Re: bin/176713: [patch] nc(1) closes network socket too soon

2013-07-22 Thread Ronald F. Guilmette
In message caj-vmokahe+uy4-3qaw6mk__sgw+l2_y6m29o_+x+ak5hoa...@mail.gmail.com Adrian Chadd adr...@freebsd.org wrote: Right. Yes, I had a typo. I meant that it shouldn't die on seeing a read EOF after closing the write side of the socket. So, what you're saying is: * nc sees EOF on stdin Yes.

Re: bin/176713: [patch] nc(1) closes network socket too soon

2013-07-22 Thread Adrian Chadd
Right, and your patch just stops the shutdown(), right? Rather than teaching nc to correctly check BOTH socket states before deciding to close things. I'd personally rather see nc taught to check to see whether it can possibly make ANY more progress before deciding to shut things down. -adrian