On Wed, Mar 07, 2007 at 06:07:31PM -0500, Ed Maste wrote:
> Nightly tests on our 6.1-based installation using pgsql have resulted in
> a number of kernel hangs, due to a corrupt semu_list (the list ended up
> with a loop).
>
> It seems there are a few holes in the locking in the semaphore code. T
If I had say a 15k rpm drive, would it be possible to configure the
FreeBSD kernel to not use system memory and ONLY the hard drive for
caching instructions and executing operations?
Can FreeBSD be built to run on a system memory free system (can we
also circumvent the system cache for
2007/3/8, Rudy Rockstar <[EMAIL PROTECTED]>:
If I had say a 15k rpm drive, would it be possible to configure the
FreeBSD kernel to not use system memory and ONLY the hard drive for
caching instructions and executing operations?
No, probably not. Also, a 15K RPM drive still isn't very
Mike Meyer wrote:
No, it will fail immediately (as seen above) if it can't resolve the
server name. The only way to fix this is to modify mount_nfs to
sleep and retry in such cases. The *current* sleep-and-retry code
is in the NFS mount code in the kernel, which doesn't come into play
until aft
On Thu, Mar 08, 2007 at 10:55:22AM +0100, Divacky Roman wrote:
> this is wrong.. you cannot remove element from a *LIST when its iterated
> using *LIST_FOREACH.
> Use *LIST_FOREACH_SAFE instead...
We're not freeing the item in the loop so it would work unless
QUEUE_MACRO_DEBUG is turned on to i
Hi!
Apart from wondering how you're getting the motherboard to get past
POST without RAM, I'm wondering how you'd get the bootloader and
[...]
The guys at Linux/OpenBIOS did some Cache-as-RAM stuff. Maybe you can
also put (burn) the kernel directly into the BIOS chip and bott with
that k
Markus Boelter wrote:
Hi!
Apart from wondering how you're getting the motherboard to get past
POST without RAM, I'm wondering how you'd get the bootloader and
[...]
The guys at Linux/OpenBIOS did some Cache-as-RAM stuff. Maybe you can
also put (burn) the kernel directly into the BIOS chip
Marcus,
Thanks!
A chip level loading of the core kernel would be the only way.
So its not possible todo without a completly new hardware
infrastructre design.
- I'm wanting todo this because computers are too slow.
regardz,
~Rudy
__
In <[EMAIL PROTECTED]>, Rudy wrote:
>
> A chip level loading of the core kernel would be the only way.
>
> So its not possible todo without a completly new hardware
> infrastructre design.
>
> - I'm wanting todo this because computers are too slow.
You need to learn a little more about
Steven Hartland wrote:
Given that it sounds like a potential workaround is to use the machines
IP instead of name until this is fixed, thanks for the info guys.
For as long as I can remember, it's been a Best Practice to have
entries for critical NFS servers in /etc/hosts.
Doug
--
Thi
Doug Barton wrote:
Steven Hartland wrote:
Given that it sounds like a potential workaround is to use the
machines IP instead of name until this is fixed, thanks for the info
guys.
For as long as I can remember, it's been a Best Practice to have
entries for critical NFS servers in /etc/hosts.
11 matches
Mail list logo