Ah!... ok, it is an NFS bug. I've been trying to track this down
for a while ever since you reported the 3.4 lockup bug. This is probably
related to a similar problem.
There is a bug somewhere related to NFS locking up while doing a
pagein from the executable image. It ca
> Ah!... ok, it is an NFS bug. I've been trying to track this down
> for a while ever since you reported the 3.4 lockup bug. This is probably
> related to a similar problem.
>
> There is a bug somewhere related to NFS locking up while doing a
> pagein from the executable im
I just ran a tcpdump -s1500 for 5 minutes, gathered ~21k of data over that
time, no mentions of stale NFS handles from the NFS server... it would
appear the NFS client is not asking for those pages (it makes sense, since if
it asked and got the 'stale' error one would expect the SEGV).
--
David
Solaris has this nifty little tool for querying the bootparam server on a
booting system. Handy little gadget for getting various system configuration
at boot time. Neither OpenBSD nor FreeBSD have it (FreeBSD has callbootd,
but I cannot get it to work easily), so I wrote a simple 'bpgetfile' fo
History:
I had a device driver for a BDM (Background Debug Module for
Motorola 683xx CPUs) that worked fine as a kernel device and a LKM. It
was based upon the LPT driver, because it attached to the parallel port,
and the JOY LKM, cause it was simple.
Present:
I have updated the driver,
If you want you may see my KLD drivers. Two of them for ISA and one for
PCI
bus.
http://www.cronyx.ru/software/#sigma
(version 3.2)
Kurakin Roman
PS I am not in the list.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Patryk Zadarnowski wrote:
>
> You're being just plain silly. It takes about 5 minutes with the
> manuals to realize just how little AXP and IA-64 have in common: one
> is a classic superscalar out-of-order design, the other is just about
> the opposite: a typical explicit-ILP architecture. What
"David E. Cross" wrote:
>
> Solaris has this nifty little tool for querying the bootparam server on a
> booting system. Handy little gadget for getting various system configuration
> at boot time. Neither OpenBSD nor FreeBSD have it (FreeBSD has callbootd,
> but I cannot get it to work easily),
I recently installed FreeBSD on my daughter's machine, remotely.
She'd been on Windows3 since growing up and moving away from my
NeXT, so "UNIX" wasn't a scary word to her, and she was getting
tired of "Windows95 or better" on anything she was interested in,
and certainly wanted "better" if she w
> If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we
> can talk. Let's see how it does Quake, then we can talk.
Alpha does quake? :-)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, 18 Feb 2000, Bruce Gingery wrote:
> I can't praise highly enough, two software packages:
>
> http://reality.sgi.com/cbrady_denver/memtest86/
>
> and
>
> http://www.qcc.sk.ca/~charlesc/software/memtester/
Sweet! I never knew that I've wanted one for all of these years unti
: Alpha does quake? :-)
It supposedly does under Linux, at least (and if you're talking about
Quake I). Sources at:
http://www.idsoftware.com/q1source/
These sources might need a bit of work, even for Linux, though there
are folks out there who have it running under Linux/Alpha. I'd a
The situation here, I hate to say, is that you were simply very lucky
in having a software memory tester show you anything at all.
If your experience had been more typical, you would have run memtest86
and it would have declared your memory to be free of errors. Then
you'd have gone right on hav
"Jordan K. Hubbard" <[EMAIL PROTECTED]> wrote:
> I've used all kinds of software memory checkers, from "CheckIt" to
> highly proprietary packages that cost even more money, and the only
> thing they managed to convince me of is that swapping in known-good
> memory is the best and fastest way out
On 18-Feb-00 Darryl Okahata wrote:
> "Jordan K. Hubbard" <[EMAIL PROTECTED]> wrote:
>
>> I've used all kinds of software memory checkers, from "CheckIt" to
>> highly proprietary packages that cost even more money, and the only
>> thing they managed to convince me of is that swapping in known-goo
On 18 Feb 2000, Jordan K. Hubbard <[EMAIL PROTECTED]>
issued forth a missive of approximately 3647 bytes,
entitled "Re: Recommended addition to FAQ (Troubleshooting) ",
the text of which in full or in part is quoted here:
-} The situation here, I hate to say, is that you were simply very lucky
-
[Only on -hackers]
With care and a lot of patience, you can build Immunix StackGuard for
FreeBSD. I did this on 3.3-R. If there's interest, I can post build
instructions (I probably don't have time to put together a port).
Charles
-Original Message-
From: Ronald F. Guilmette [mailto:[EM
My attention has just been called to:
http://immunix.org/StackGuard/mechanism.html
Given all of the buffer overrun vulnerabilities that have been found in
various network daemons over time, this seems like a worthwhile sort of
technique to apply when compiling, in particular, network daemons
[ My apologies if this is a repeat - my earlier mail didn't seem to make it ]
On Fri, 18 Feb 2000 12:03:37 +1100, Patryk Zadarnowski <[EMAIL PROTECTED]> wrote:
> On the other hand, IA-64 is a very exotic architecture from the OS's
> point of view, and anyone planning to port *BSD to it should pr
:...
:and Linux essentially treats hardware page tables as TLBs.
:
:The problem with the above approach is duplication of information between
:Linux page tables and hardware page tables and inefficient use of memory
:for page tables.
:
:I think OSes like FreeBSD which don't have a concept of machi
On Tuesday, 15 February 2000 at 20:25:50 -0800, John Milford wrote:
> Joe Greco <[EMAIL PROTECTED]> wrote:
>
>>>
>>> Joe seem to want one. This size is certaintly within the reach of an
>>> ISP now, and disks just keep getting bigger. My administrative bias is
>>> that partitioning for a reason
> > You're being just plain silly. It takes about 5 minutes with the
> > manuals to realize just how little AXP and IA-64 have in common: one
> > is a classic superscalar out-of-order design, the other is just about
> > the opposite: a typical explicit-ILP architecture. What makes IA-64
> > grea
Olaf Hoyer wrote:
>
> >a. settings on the controller card (e.g. scsi id, termination)
> >b. freebsd configuration on the initiator and target PCs.
> > (e.g. do we use scsi_pt.c, scsi_target.c, etc).
> >
> >here's a diagram depicting what we want to do. we're trying to setup
> >a PC (PC2 below)
On Fri, Feb 18, 2000 at 04:06:55PM -0800, Matthew Dillon wrote:
> If I understand the hardware hash table method correctly, then
> I think the absolute best choice for FreeBSD is to use that method
> as it will allow us to get rid of the scaleability problems we have
> with the pv_
Wilko Bulte wrote:
>
> On Tue, Feb 15, 2000 at 04:00:28PM -0600, David Scheidt wrote:
>
> > > Generally speaking 'joining' machines into cluster(like) you want to
> > > use differential SCSI buses.
> >
> > Yes. Of course, I think that you want to use differential SCSI for
> > everything. Cable
> :...
> :and Linux essentially treats hardware page tables as TLBs.
> :
> :The problem with the above approach is duplication of information between
> :Linux page tables and hardware page tables and inefficient use of memory
> :for page tables.
> :
> :I think OSes like FreeBSD which don't have a
On Sat, 19 Feb 2000 12:10:14 +1100, Patryk Zadarnowski
<[EMAIL PROTECTED]> wrote:
>
> Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
> and it turns out that hash tables perform quite poorly. I'd suggest GPTs
> instead, or maybe LPCtrie that Chris Szmajda has been
27 matches
Mail list logo
