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 abor

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 inte

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, p

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

2013-07-22 Thread Ronald F. Guilmette
In message Adrian Chadd 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. >* nc decides to abort before seeing the rest of the data come in from >the re

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