My colleague [EMAIL PROTECTED] and I have slapped together a quick and
dirty hardware watchdog driver for boards with the Winbond
W83697UF/UG SuperIO chip. Its a kld that ties into the existing
watchdog framework. Its version 1.0 but seems to work just fine. If
you have a board with such a c
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Koen Martens
> Sent: Thursday, September 01, 2005 3:11 PM
> To: Dimitry Andric
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: panic in propagate_priority w/ postgresql under
> heavy load
>
> Hi Dim,
Hi Dim,
Dimitry Andric wrote:
> On 2005-09-01 at 19:02:06 Koen Martens wrote:
>
>>Anyway, it seems the dump should've gone to the swap partition, but
>>i'm into multi-user mode again so i guess i'll have to wait for
>>another panic to obtain it?
>
> In RELENG_6, the dump device is chosen automa
John Baldwin wrote:
> On Thursday 01 September 2005 01:02 pm, Koen Martens wrote:
>
>>I've had a little chat with neologism on ircnet/#freebsd about this
>>already, and done as he suggested: compile a debug kernel to obtain
>>a stack trace.
>
> Can you reproduce it with a kernel that has INVARIAN
On 2005-09-01 at 19:02:06 Koen Martens wrote:
> Anyway, it seems the dump should've gone to the swap partition, but
> i'm into multi-user mode again so i guess i'll have to wait for
> another panic to obtain it?
Yes. By now, if any dump was ever written to your swap partition, it
will most proba
On Thursday 01 September 2005 01:02 pm, Koen Martens wrote:
> Hi Hackers,
>
> I've had a little chat with neologism on ircnet/#freebsd about this
> already, and done as he suggested: compile a debug kernel to obtain
> a stack trace.
Can you reproduce it with a kernel that has INVARIANTS and INVARI
Hi Hackers,
I've had a little chat with neologism on ircnet/#freebsd about this
already, and done as he suggested: compile a debug kernel to obtain
a stack trace.
Anyway, what is happening is that there is a crash when running
postgresql 8.0.3 with a very large database and doing heavy queries.
On Thursday 01 September 2005 11:37, Eygene A. Ryabinkin wrote:
> > If Scott's patch doesn't work, could you have tried to install the
> > following (compiles on FreeBSD 5/6/7):
>
> Yes, it also works and does even better work: FAT 32 and FAT 16
> permormance are just the same and there is no addi
On Thu, Sep 01, 2005 at 12:44:21PM +0400, Eygene A. Ryabinkin wrote:
> > Actually, I just peeked inside the Linux EHCI code and it does a dummy
> > read immediately after writing to the status register:
> >
> > /* clear (just) interrupts */
> > writel (status, &ehci->regs->status);
> Yes, it also works and does even better work: FAT 32 and FAT 16 permormance
> are just the same and there is no additional load as been with the Scott's
> patch.
> So I definitely would vote for this fix.
Oops, it seems that this patch also does not work as expected: after some time
of playing
On Tue, Aug 30, 2005 at 04:50:31PM +0400, Eygene A. Ryabinkin wrote:
> > FreeBSD 4.x had very low performance with FAT filesystem,
> > writing process spent lots of time in the wdrain state too.
> Yes, it has.
Did you try mtools? I get much better performance with mtools compared
to msdosfs.
On 9/1/05, Vladimir Yu. Stepanov <[EMAIL PROTECTED]> wrote:
[snip]
You can always control which traffic to sniff (ingress/egress)
using layer 2 filters (ether src/dst host <>).
--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there
> If Scott's patch doesn't work, could you have tried to install the following
> (compiles on FreeBSD 5/6/7):
Yes, it also works and does even better work: FAT 32 and FAT 16 permormance
are just the same and there is no additional load as been with the Scott's
patch.
So I definitely would vote f
Hello!
I made a modernization of bpf realization. It have a mind when we are
trying to use bpf to account network statistic. When packets is catching
by filter thereis imposible to determine the direction of packets flows.
Due to this problem statistic accounts two times when packets
> Actually, I just peeked inside the Linux EHCI code and it does a dummy
> read immediately after writing to the status register:
>
> /* clear (just) interrupts */
> writel (status, &ehci->regs->status);
> readl (&ehci->regs->command); /* unblock posted write */
>
> I wo
15 matches
Mail list logo
