Re: read(1) garbage when input redirected from make incorrectly

Jan Mikkelsen janm-freebsd-hack...@transactionware.com writes: A redirection doesn't terminate the argument list. [...] Huh, you learn something every day... :) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list

Re: Sudden mbuf demand increase and shortage under the load (igb issue?)

Maxim Sobolev wrote: So it looks like kernel issue of a sort, which causes all userland activity to cease for 2 minutes when the system reaches certain load. You are not using ZFS, are you? :)) ___ freebsd-hackers@freebsd.org mailing list

Per core, per device interrupt counts

After reading though the kernel source I realise what I want isn't implemented at the moment but I wanted to discuss if this feature would be an useful addition. Basically I want to see counts of how many interrupts for a particular interrupt have fired on each core. Linux has provided this kind

linprocfs proc/pid/environ patch list question

Hi, I have a small patch (against 8.0-RELEASE-p2) that _should_ implement the /proc/pid/environ file under linprocfs. However, it seems it does not work properly but I don't know what I'm doing wrong. Is this list the place to ask for help? I tried in the forums[1] but got no answer. Don't we

Re: linprocfs proc/pid/environ patch list question

On Wed, Feb 17, 2010 at 07:51:06PM +0100, Fernando Apestegu?a wrote: Hi, I have a small patch (against 8.0-RELEASE-p2) that _should_ implement the /proc/pid/environ file under linprocfs. However, it seems it does not work properly but I don't know what I'm doing wrong. Is this list the

Re: Ktrace'ing kernel threads

On Monday 15 February 2010 6:21:40 am Shrikanth Kamath wrote: Can ktrace trace another kernel thread which has roughly the semantics as below, right now it does not hit any of the designated interesting points that ktrace is built for, but what if I could define those, will ktrace still allow

Re: Per core, per device interrupt counts

On Wednesday 17 February 2010 1:09:04 pm Andrew Brampton wrote: After reading though the kernel source I realise what I want isn't implemented at the moment but I wanted to discuss if this feature would be an useful addition. Basically I want to see counts of how many interrupts for a

Re: Per core, per device interrupt counts

- Original Message From: John Baldwin j...@freebsd.org To: freebsd-hackers@freebsd.org Cc: Andrew Brampton brampton+free...@gmail.com Sent: Wed, February 17, 2010 4:17:24 PM Subject: Re: Per core, per device interrupt counts The simplest method would probably be to make

tar tfv /dev/cd0 speedup patch

Hi! I recently wanted to quickly look at an optical disc without mounting it and since bsdtar/libarchive know iso9660 I just did the command in the Subject. It worked, but it was sloow... :( Apparently it read all of the disc without seeking. The following patch fixes this, is something like

Re: tar tfv /dev/cd0 speedup patch

Juergen Lock wrote: ... since bsdtar/libarchive know iso9660 I just did the command in the Subject. It worked, but it was sloow... :( Apparently it read all of the disc without seeking. The following patch fixes this, is something like this desired? If yes I could look how to do the same

unix socket: race on close?

Hi, Below is a simple test code with unix sockets: the client does connect()/close() in loop and the server -- accept()/close(). Sometimes close() fails with 'Socket is not connected' error: a.out: parent: close error: 57 or a.out: child: close error: 57 It looks for me like some race in