as i accidentally deleted my libc.so.3 i thought it would be a good time
to rebuild xfree, but i came in a preprocessor hell due to siginfo_t
_POSIX_SOURCE or not ... definition at the stage of building makedepend.
In file included from main.c:41:
/usr/include/signal.h:72: warning: `union
Fritz Heinrichmeyer wrote:
as i accidentally deleted my libc.so.3 i thought it would be a good time
to rebuild xfree, but i came in a preprocessor hell due to siginfo_t
_POSIX_SOURCE or not ... definition at the stage of building makedepend.
In file included from main.c:41:
On Tue, 5 Oct 1999, Kevin Day wrote:
Afaik all 3C509B's are PnP. At least here in the UK there is not
shortage of those cards.
If I can get a difinitive statement to this effect then I'll grab a
3c509B. There was some question as to them actually being PnP though.
Yes, the
I am still having problems with the ATA driver.
I am seeing the same error messages as has been reported on the lists during
the last few weeks, both on i386 and alpha platforms.
On the i386, the problem is just an irritating itch, but it seems to be
far more serious on the alpha, where the
It seems Erik H. Bakke wrote:
I am still having problems with the ATA driver.
I am seeing the same error messages as has been reported on the lists during
the last few weeks, both on i386 and alpha platforms.
On the i386, the problem is just an irritating itch, but it seems to be
far more
On Wed, 6 Oct 1999 12:22:47 +0200, Brad Knowles [EMAIL PROTECTED] said:
Forgive me if I'm misunderstanding something here, but isn't
having /tmp on the root filesystem just inviting a denial-of-service
attack on yourself?
Only if you let random lusers log in to your machine.
According to Nate Williams:
So, are you suggesting make /tmp it's own disk, otherwise anytime you do
development alot of writes are done to /.
Of course /tmp should NOT be on /. Either in its separate FS or on another
partition through a symlink.
/ should be as small and as write-free as
John Polstra wrote:
...
One common misconception is that cvsup(N+1).FreeBSD.org is somehow
less up-to-date than or not as good as cvsup(N).FreeBSD.org. That's
not the case at all -- the numbers mean nothing. For example, all 7
of the US mirror sites get their updates hourly from the same
On Wed, Oct 06, 1999 at 02:57:23PM +1000, a little birdie told me
that Peter Jeremy remarked
I guess we disagree on this. My feeling is that write activity on
root should be minimised to minimise the risk that root will be
inconsistent following a crash.
Indeed.
Thus:
On Wed, Oct 06, 1999 at 04:18:15PM -0500, a little birdie told me
that Kevin Day remarked
/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100)
My understanding was that that was just a indication of writes that were
able to be done asynchronously without any risk, so they
:Indeed.
:Thus:
:/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100)
: ^^^
:
:Though I'm still waiting for an explanation of WHY exactly I have async
:writes on a sync partition. Nobody yet has said anything but 'that's
:interesting...'. A
On 1999-Oct-06 16:14:19 +1000, Brian Somers wrote:
On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote:
I've seen softupdates nearly eliminate disk io for systems that used
an abmornal amount of temp files, but the fact that it can destabilize
a system worries me greatly.
What do you
I'm getting this with a recent current (6. october):
(da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25.
(da2:ahc2:0:2:0): Have seen Data Phase. Length = 0. NumSGs = 1.
(da2:ahc2:0:2:0): data overrun detected in Data-Out phase. Tag == 0x25.
(da2:ahc2:0:2:0): Have seen
/dev/da0s1a on / (local, synchronous, writes: sync 32 async 15100)
^^^
Though I'm still waiting for an explanation of WHY exactly I have async
writes on a sync partition. Nobody yet has said anything but 'that's
interesting...'. A direction to look would
:mount(8):
: syncAll I/O to the file system should be done synchronously.
:
:On the gripping hand, you can say, 'this is an ATIME update, there's no
:way its presence or lack thereof can do anything bad to the filesystem,
:so let it be async since it takes extra work to make it
On 1999-Oct-07 09:15:42 +1000, Matthew D. Fuller wrote:
Is this good, bad, ugly, or just inconsistent? On the one hand, you can
argue that 'sync should be sync should be sync, I don't bloody care, just
don't do anything async at all', since that's what it's supposed to do:
mount(8):
sync
Figuring one of the things a friend of mine raves about Linux for is their
kld's, I'd start playing with ours...
Looking in /modules, I saw 'procfs', so, cool, a place to start...remove
"options PROCFS" from kernel config, rebuild, install and reboot ...
crashes...
so, I figure that I somehow
On 07-Oct-99 The Hermit Hacker wrote:
Looking in /modules, I saw 'procfs', so, cool, a place to start...remove
"options PROCFS" from kernel config, rebuild, install and reboot ...
so, I figure that I somehow have to tell the kernel to load that module?
Well its a kld.. You don't have to
On Thursday, 7 October 1999 at 3:00:52 -0300, The Hermit Hacker wrote:
Figuring one of the things a friend of mine raves about Linux for is their
kld's, I'd start playing with ours...
Yes, it's funny how the Linuxers rave about loadable modules. It's a
good idea, but I don't see anything
Well, the standard way to load a kld is with kldload(1) or kldload(2).
I don't know if procfs works properly like this, though.
Procfs works just fine:
[groovy] /usr/src.With_secure_NFS # kldstat
Id Refs AddressSize Name
17 0xc010 1a10cc kernel.debug
21 0xc09c1000 3000
On 07-Oct-99 Greg Lehey wrote:
Well, the standard way to load a kld is with kldload(1) or kldload(2).
I don't know if procfs works properly like this, though.
Well I would assume (aha) that when mount cannot find procfs in the list of
FS's the kernel knows about it would try and load it
hi again,
On Tue, 5 Oct 1999, Matthew Dillon wrote:
: The problem is that the machine is completely locked, I can't get into
:the debugger with CTR-ALT-ESC; no panics so there are no coredumps
:catched. Any advise ? Could you escape in the debugger when you were hit
:by these bugs ?
22 matches
Mail list logo
