On Tue, 27 Jul 2010, Anton Shterenlikht wrote:
On Tue, Jul 27, 2010 at 05:53:25PM +0100, Gavin Atkinson wrote:
On Tue, 2010-07-27 at 15:47 +0100, Anton Shterenlikht wrote:
db bt
Tracing pid 0 tid 10 td 0x80b40de0
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x17b
Hi,
On 3 Aug 2010, at 18:58, Jamie Gritton wrote:
I always understood that is was a style error *not* to have at least
some whitespace before a label, that only top-level objects should be
pushed all the way to the left column. Style(9) appears to be silent on
this issue.
Labels are special
In message 201008040347.o743leer046...@sana.init-main.com, wrote:
Quick review and hack:
1.How about attaching it as acpi child driver?
In some case, TPM may appear in ACPI namespace (with _HID) and
TPM spec defines ACPI method to handle TPM specific request.
2. Is identify method needed?
On Tue, 03.08.2010 at 17:21:45 -0700, Steve Kargl wrote:
On Tue, Aug 03, 2010 at 05:40:05PM -0400, Thomas Dickey wrote:
On Tue, Aug 03, 2010 at 11:22:36AM -0700, Julian Elischer wrote:
On 8/3/10 2:34 AM, pluknet wrote:
Hi.
I looked into sys/kern/* files to fix a bunch of common w/s
On 08/03/2010 14:21, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10 /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
otherterm$ jot 10 /tmp/1
[no output to
Hi,
I recently noticed that cv_wait_sig() will return -1
rather than EINTR when a SIGINT is delivered. This is
in contrast to CONDVAR(9) which states:
...
cv_wait_sig() and cv_timedwait_sig() return prematurely with a
value of EINTR or ERESTART if a signal is caught
...
To
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10 /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
otherterm$
On Wed, Aug 04, 2010 at 10:36:24AM -0400, Andrew Gallatin wrote:
Hi,
I recently noticed that cv_wait_sig() will return -1
rather than EINTR when a SIGINT is delivered. This is
in contrast to CONDVAR(9) which states:
...
cv_wait_sig() and cv_timedwait_sig() return prematurely with
On Wed, Aug 04, 2010 at 06:46:04PM +0300, Kostik Belousov wrote:
On Wed, Aug 04, 2010 at 10:36:24AM -0400, Andrew Gallatin wrote:
Hi,
I recently noticed that cv_wait_sig() will return -1
rather than EINTR when a SIGINT is delivered. This is
in contrast to CONDVAR(9) which states:
Kostik Belousov wrote:
BTW, -1 is ERESTART, so if you have SIGINT catched with SA_RESTART
flag in the process that initiated kldload(2) syscall, then -1
is the right return code for cv_wait_sig.
Ah, makes sense. I hadn't considered that a BSD kernel
error could be negative. I should have
On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote:
On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote:
On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does
On 4 August 2010 20:28, Lars Engels lars.eng...@0x20.net wrote:
On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does
On Tue, 3 Aug 2010, Gabor Kovesdan wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10 /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
otherterm$ jot 10 /tmp/1
[no output to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/08/03 11:21, Gabor Kovesdan wrote:
I've checked on 8.0 and GNU grep doesn't output anything either for me.
If you use tail -f, you will enter more lines and end it with EOF, won't
you? And then BSD grep will process the input and print
On Tue, 03 Aug 2010 20:21:56 +0200 Gabor Kovesdan ga...@freebsd.org wrote:
Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
term0$ jot 10 /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no
Hi,
On Wed, Aug 04, 2010 at 07:39:41PM +0900, Takanori Watanabe wrote:
In message 201008040347.o743leer046...@sana.init-main.com, wrote:
Quick review and hack:
1.How about attaching it as acpi child driver?
In some case, TPM may appear in ACPI namespace (with _HID) and
TPM spec defines
Em 2010.08.04. 20:06, Xin LI escreveu:
I'm able to reproduce the GNU behavior on 9.0-CURRENT which is IMO right.
I think we need to break at the line end to provide better interactivity
(the current code seems to do it (buffer is not full !eof), while
what we wanted is (buffer is not full
On 08/04/10 11:18, Bakul Shah wrote:
bsdgrep when used this way doesn't quit but doesn't do
anything either (including printing what tail -f spits out
from existing file data).
Does adding --line-buffered to the grep command line change the behavior
at all?
--
Improve the
20 matches
Mail list logo
