can you report out the actual command line you're using and what release
it's from?
On 11/29/2010 12:08 PM, Denise H. G. wrote:
Hi,
I found that, while searching for empty directories, find(1) will not
continue if it encounters a dir it can't enter (e.g. no privilege). I
don't know if it's so
Actually, GENERIC is there to provide the most features for the most
uses. A large percentage of users don't config new kernels, and FreeBSD
has not elected the approach Digital Unix (aka "DUH") took about
installs which required a reconfig as one of the last steps of an
installation.
I can't
I don't think that this is a good idea for a number of reasons. IPMI is
not nearly as prevalent as one might think it is, it is not a true
standard (Intel only), and there are a variety of good toolsets that are
very easy to install. Finally, users of IPMI are sophisticated enough to
install it
At Panasas we were looking at using that for some background parity
calculation.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freeb
If there's really interest then perhaps I should get something together
that can actually be checked in?? Yes?
Yes please.
Since Sandybridge interest has been growing particularly where systems are
being put together with bridges (non-transparent) with a notion that IO/AT
could be used to m
Hi Russell!
Yes, I think it is. Solaris supports something like this and the idea here
is that with complicated I/O subsystems it's too hard to get them and
locks cleaned up in a crash, but you want to get all the forensics you
can, so doing a jump to a preloaded kernel that has a small and s
On Mon, 10 Oct 2011, elman wrote:
Dear all
I have plan to cluster server with freebsd 8.2 for mailserver. But I'm
confusing with the software for clustering. Do you have a reference for me, or
do you have blog and I can see your blog for reference to create clustering
with freebsd.
You
On 10/24/2011 5:21 PM, Chuck Tuffli wrote:
Is there an easy way to determine the amount of bus_dma memory
allocated by a driver? Something similar to vmstat -m
bus_dma memory allocations are platform specific. Looking at least amd64
you can see that the memory is carved out M_DEVBUF.
___
On 5/2/2012 1:39 PM, Trent Nelson wrote:
[Resending from non-broken MTA.]
Hi Matt,
isp(4) mentions the following sysctl options:
dev.isp.N.loop_down_limit
This value says how long to wait in seconds after loop has gone
down before giving up and expiring all
On 08/15/12 11:54, Poul-Henning Kamp wrote:
In message
, Adrian Chadd writes:
Holy. Crap. 17 seconds?
Can we please go back to having it take this long? please?
386BSD was even better, and I have a machine that boots it in less
than 15 seconds from power-on...
A Sun 3-50 with a 15.7MHz 68020
On 1/17/2013 8:03 PM, Dieter BSD wrote:
I think it is time to ask the driver wizards why TCQ isn't working, so
I'm cc-ing the authors listed on the mpt man page.
It is the MPT firmware that implements SATL, but there are probably
tweaks that the FreeBSD driver doesn't do that the Linux driver
This is all turning into a bikeshed discussion. As far as I can tell,
the basic original question was why a *SAS* (not a SATA) drive was not
performing as well as expected based upon experiences with Linux. I
still don't know whether reads or writes were being used for dd.
This morning, I ran
mpt0: port 0x1000-0x10ff mem
0x9991-0x99913fff,0x9990-0x9990 irq 28 at device 0.0 on pci11
mpt0: MPI Version=1.5.20.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (14 Max)
Ah. Historically IBM systems (the 335, for one)
On 1/23/2013 7:25 AM, John Baldwin wrote:
On Tuesday, January 22, 2013 5:40:55 pm Sushanth Rai wrote:
Hi,
Does freebsd have some functionality similar to Linux's NMI watchdog ? I'm
aware of ichwd driver, but that depends to WDT to be available in the
hardware. Even when it is available, BIOS
On 3/1/2013 5:50 AM, Andriy Gapon wrote:
I am trying to understand if it is possible to allow memory allocations
(M_NOWAIT,
of course) in a spinlock context.
There are mechanisms to do just this- essentially by creating private
pools that are organized in a way to allow for spinlock (and thus
On 4/9/2013 11:53 PM, Daniel Braniss wrote:
this host can run x11 apps! so 'Huge' is a relative matter, my first
PDP11/45 has 64K :-) danny
Bah. Real old farts ran munix on a 32k PDP 11/03- shell and apps in the
low 16k and the kernel in the upper. Or was it the other way around? At
Tektronix,
On 5/16/2013 1:51 PM, Zaphod Beeblebrox wrote:
...
[1:25:325]root@run:/home/foo> dd if=/dev/sa0 of=tape5
hmm. try tcopy. Can we see any complaints from /var/log/messages?
(this would be better discussed on freebsd-scsi)
___
freebsd-hackers@freebsd.
Seriously, the FreeBSD package system is in great need of a profound
overhaul, pretending it works well is complete denial of reality. I
hope that young people working on summer code projects will infuse
*new* ideas, and not spend their vacations polishing inadequate tools.
Hmm? Works fine f
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
Not if the items stored there are needed prior to being able
> > Mike Smith wrote:
> > >
> > > The loader will, at some stage in the future, grow a persistent data
> > > store in which items like this can be saved.
> >
> > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > data storage?
>
> There is little or no chance that the loader
> > > > Mike Smith wrote:
> > > > >
> > > > > The loader will, at some stage in the future, grow a persistent data
> > > > > store in which items like this can be saved.
> > > >
> > > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> > > > data storage?
> > >
> > > There is
Support exists for the Qlogic 2100 and 2200 FC-AL cards.
On Tue, 27 Jul 1999, Papezik Milon wrote:
> Hi all,
>
> only simple question :-)
>
> Does FreeBSD support any FibreChannel controller
> or does body somebody writing a drive?
> For which card card?
>
> Thanks in advance.
> M
Release and development of this driver has been delayed. It has been
impossible to get a stable -current platform to work with each time I've
tried to update my working -current tree over the last two weeks. I guess
I've picked the wrong days to update...
To Unsubscribe: send mail to majord
> In message <19990817230910.a6...@netmonger.net> Christopher Masto writes:
> : Do they still not allow you to release the specs? How is the code
> : going to become part of FreeBSD if they won't allow its release?
>
> I didn't sign an NDA to get my copy of the spec or the hardware...
Neither
Oh- to give my status for the SCSI version: I lost time because the day
and ahlf I had allocated to actually work on this got blown away by -current
instabilities. I'll try and get another shot at it Sunday (*my* work
schedule is such that right now that I don't have an employer I can stick
this w
I think very highly of the MindShare book
"PCI System Architecture"
Addison-Wesley, 1995
ISBN 0-201-40993-3
On Thu, 19 Aug 1999, Wilko Bulte wrote:
> I'm looking for background (reading) info on the PCI bus. Looking
> for the tech detail required for writing PCI device drivers.
>
> I invite su
> On Mon, 23 Aug 1999 11:28:20 -0400
> Dennis wrote:
>
> > I heard a rumor that freebsd runs on a sparc, but I dont see any backing
> > for that. Is it in the works?
>
> FreeBSD does not run on the SPARC. I think they've been talking about it
> for ... what, 5 years now... but it never mate
What are the advantages and disadvantages of partitions?
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
I have a filesystem stress tests that are worth incorporating. I also have
a raw disk pattern checker, but that's less of a test than analysis tool.
-matt
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
> On Thu, Aug 26, 1999 at 10:41:58AM -0700, Matthew Jacob wrote:
> >
> > I have a filesystem stress tests that are worth incorporating. I also have
> > a raw disk pattern checker, but that's less of a test than analysis tool.
>
> Does it check do things that s
> >I have at least one filesystem killer test.
>
> And it is?... Like I mentioned, we're trying to collect tests/code that will
> demonstrate bugs.
>
> >I'll try and figure out a good place to hang it in the source tree, but I
> >believe that it's usage is a mandatory "must use" for validating
!/bin/sh
#
# Copyright (c) 1999 Matthew Jacob
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this
'u' instantiations on the same partitition after an
initial 'c' test.
/*
* Copyright (c) 1999 Matthew Jacob
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditi
> Isn't all the work in CAM done at splsoftcam?
Not all. There's completions done at splcam. I've had some worries and
concerns about this, but (wince) I really have to admit that the ins and
outs of the cam code often escape me, and they're documented only in the
DNA of certain human subspecies
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be < 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
career on
> :I strongly doubt that this is a CAM isr problem- the error pattern isn't
> :entirely clear from what you said, but it looks more like a FIFO or CACHE
> :LINE sized type of problem- it looks to be < 16 bytes, but not a short
> :count. Because this isn't one of the wacky systems I spent most of my
> > > > Where sun are involved, I wouldn't get your hopes up until you actually
> > > > see source or something. And I wouldn't exactly call them quick,
> > > > either.
> > >
> > > This is wise counsel.
> >
> > Also, don't discount the possibility that Sun may be talking about this in
> > order
> On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote:
> > Growing up programming on a KL-10, I still think the correct place for
> > line-editing is in the driver. Hell - it's already doing basic
> > erase/kill line editing as it is. Then you don't have to hack every
> > command-line a
For some alternative perspective- DEVFS has been around in many systems
for a long time. Solaris attempted to go this way, but has taken a decade
to move out a year's worth of progress.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the me
> On Sat, Sep 18, 1999, Julian Elischer wrote:
> > DEVFS is an experimental idea.
>
>I must also say that DEVFS is an excellent idea.
It's a marvelous idea, and is going to be very necessary when large Fibre
fabrics become more common. The problems of making it stable and
meaningful are enor
On 05/03/2010 12:21 AM, Ed Schouten wrote:
Hello Matthew,
* Matthew Jacob wrote:
Any thoughts about this?
Looks good. Maybe we should make it a tunable only? Looking at the code,
once the consbuf has been allocated, there is no way you can ever resize
it.
You could, but on
On 5/25/2010 9:52 AM, Julian Elischer wrote:
On 5/25/10 8:33 AM, Eitan Adler wrote:
No. Do not remove groff or associated tools from /usr/src !
Roff has been in Unix /usr/src since '77 or earlier.
A lot of people use tools from that descendancy as production tools.
So? If it isn't a very commo
On 5/29/2010 9:17 AM, "C. Bergström" wrote:
Can someone in the FreeBSD community please talk with this guy. If
you're going to send a snotty email at least be brave enough to do it
publicly..
Sorry for his rudeness.
fwiw.. I never said free anywhere in my email.. It's assumed testing
h
All of these tests have been apples vs. oranges for years.
The following seems to be true, though:
a) FreeBSD sequential write performance in UFS has always been less than
optimal.
b) Linux sequential write performance in just about any filesystem has
always been "impressive". But that "impr
On 6/30/2010 2:01 AM, Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Is there anybody used the Supermicro's BIOS watchdog feature (reboot if
no OS activities)?
It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro
BIOS needs some special treatments which is
config(8) creates them I believe
line 523 of bus.h
tries to include the following files:
#include "device_if.h"
#include "bus_if.h"
however, I don't see them any where in my source tree. Are these
missing or am I suppose to create them or are they built as part of
the build process and if th
Is there truly no IDENTIFY information to determine the drive format?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Yes, that should be it!
After poking around some, it seems ATA/ATAPI-7 Identify
Device word 106 bit 13 is set to 1 and bits 0-3 are set to 3
(for 2^3 or 8 LBAs per sector) for a 4KB sector size (pin 7-8
jumper on a WD AF disks presumably changes this setting to
0,0). See page 121 of Atapi-7 vol
You can do it this way, but IMO, the best thing to do is to when
you're panicing stop all other CPUs.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hack
On 9/3/2010 9:17 AM, Andriy Gapon wrote:
on 03/09/2010 19:10 Matthew Jacob said the following:
You can do it this way, but IMO, the best thing to do is to when you're
panicing
stop all other CPUs.
Entirely agree, that's the way it should be handled.
Unfortunately, all I could co
Has anyone seen this scenario before? I am seeing it in RELENG_7, but
the code in question exists through to head.
Thread 1:
(kgdb) where
#0 sched_switch (td=0xff003a04ea80, newtd=0xff00210b4000,
flags=Variable "flags" is not available.
) at ../../../kern/sched_ule.c:1944
#1 0xfff
kostik, matthew- thanks mucho!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
What problem are you solving by this change?
any thoughts on this patch?
i noticed the "default" SCSI_DELAY value of 2000ms was only used in very few
places so i thought it would make more sense making 5000ms the default and
adding a few special cases where SCSI_DELAY can in fact be lowered do
ines and
leave the default at 2000ms?
On 10/19/2010 3:34 AM, Alexander Best wrote:
On Mon Oct 18 10, Matthew Jacob wrote:
What problem are you solving by this change?
code cleanup.
the scsi delay value currently defaults to 2000ms. however that doesn't make
sense, since on almost all p
I'd go for the gusto in -current, but it's ok to be conservative too.
On Tue Oct 19 10, Matthew Jacob wrote:
It would be an effective behavioral change for those of us who remove
that line.
Personally, I think 5 seconds is too long- even 2 seconds is more than
adequate even for
Oleg Sharoyko wrote:
Hi!
I
I've reproduced the problem and I think I know what's going on. I've
filed a PR which I'll put you on the CC list for as soon as I find it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
On 5/1/2010 3:35 PM, Alfred Perlstein wrote:
I notice this code sprinkled through the sources:
strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN);
This trips up coverity because it does not know for sure
that the string returned by cam_sim_name() is going to
be DEV_IDLEN-1 characters long.
Any thoughts about this?
diff -r 5308a7cebc7d sys/kern/kern_cons.c
--- a/sys/kern/kern_cons.c Thu Apr 29 19:55:46 2010 -0700
+++ b/sys/kern/kern_cons.c Sun May 02 15:32:24 2010 -0700
@@ -428,6 +428,7 @@
}
static int consmsgbuf_size = 8192;
+TUNABLE_INT("kern.consmsgbuf_size", &consms
On Mon, 10 May 1999, Matthew Dillon wrote:
> :> Any of them can change, but I excpect it to settle down in a year or
> two.
> :>
> :
> :It sounds like we might consider a DDI/DKI set of definitions.
>
> Yes, but not until things settle down in a year or two. Until
> then, trying
> > I was wondering if anyone has done any work on fsck and very large file
> > systems. We have a system that has 126 GB RAID Array. As you can imagine,
> > fsck chokes trying to alloc enough blocks to store it's internal data
> > structures (128 MB RAM, 128 MB Swap)
Huh- I reme
> >
> > I've been doing 120GB+ filesystems for FreeBSD for quite some time. The
> > real fun will be the 1TB filesystems.
>
> How much Swap disk space have you allocated on machines that you fsck'ed
> that were this large ?
Well, here's a current FreeBSD machine that has a couple 60GB raid bo
So do I. I would like them to make the source available. I have *lots* of
machines available that are sitting doing nothing. But they don't run
FreeBSD (yet). I have at least 3 alpha 8200s and 4 Alpha 4100s that are
running NetBSD now and mostly quiescent.
On Fri, 14 May 1999, Matthew Dillon wro
These may go away soon as currently constituted because they are properly
a per-device type value.
On 21 May 1999, Dag-Erling Smorgrav wrote:
> I want to convert these kernel options to sysctl variables. Where
> should they be inserted into the tree? I was thinking of creating a
> new 'cam' t
> > I want to convert these kernel options to sysctl variables. Where
> > should they be inserted into the tree? I was thinking of creating a
> > new 'cam' top-level category and put them there:
> >
> > cam.sa.space_timeout
> > cam.sa.rewind_timeout
> > cam.sa.erase_timeout
>
> These should
>
> MAXPHYS is ultimately a limitation on the size of the b_pages array in
> the struct buf structure. The default is 128 KBytes. Device Drivers are
> supposed to break up I/O's into manageable sections themselves.
>
> Maybe when the buffer I/O / VFS subsystem is rewritten late
>
> The biggest mistake that programmers working on a large project make is
> when they do *not* rewrite portions of the code that need to be rewritten.
> For a case in point you need look no further then the buffer cache and
> device I/O code. It's so messed up that even I could
> :Now I'm getting a bit torqued at this. Yes, there are problems here,
> :but rather than keeping it to yourself what the problems are, how about
> :being constructive in suggesting ways we can all improve things.
>
> A number of conversations and threads have already taken place on the
>
> > >I've been following this conversation with growing concern. It seems
> > >to me there is a fairly simple solution to this problem: create a
> > >branch for the ongoing VM work, enable commit privs on the branch for
> > >Matt and anyone else who's going to join in the fun, and then at times
> My point is that you very definitely cannot please everyone all of the
> time. Do it quick and some will scream. Do it slow and others will
> scream. Either way, you're getting screamed at.
Yes, keep this in mind, folks. This is why there is a high mortality rate
for core members of these or
Umm, recently I've noticed for both 3.2 && 4.0 that NFS seems to get
wedged on a directory that is mounted from a Solaris 2.6 (unpatched)
server- but this seems to only happen if the local mount point is a
directory just off of root.
The scenario is, e.g.:
bird:/export/home on /home
bird:/spac
Closer examination shows the possible problem:
Rev 1.29 added:
/*
* Insert the nfsnode in the hash queue for its new file handle
*/
for (np2 = nhpp->lh_first; np2 != 0; np2 = np2->n_hash.le_next) {
if (mntp != NFSTOV(np)->v_mount || np2->n_fhsize
> for (np2 = nhpp->lh_first; np2 != 0; np2 = np2->n_hash.le_next) {
> if (mntp != NFSTOV(np)->v_mount || np2->n_fhsize != fhsize ||
> bcmp((caddr_t)fhp, (caddr_t)np2->n_fhp, fhsize))
> continue;
> vrele(vp);
>
> :
>
> The problem is that peter is not releasing the nfs_node_hash_lock
> when he goes to retry, creating a deadlock with himself.
>
> Peter, looks like a quick fix & commit to me, I'd say just go ahead
> and do it.
>
> Heh, I just realized how funny that first stateme
> :>
> :> Heh, I just realized how funny that first statement was :-)
> :
> :
> :Yup, that's my take too waking up any waiters to re-contend seemed
> :correct to do too
> :...
> :
> :If peter doesn't respond by this afternoon, I'll commit it. I've tried it
> :on -current so far.
>
>
Yes, I looked at it. It's also true that we both (OpenBSD/FreeBSD) have a
small memory leak too in this case.
NetBSD has none of the problems.
-matt
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
The actual code of interest is:
FreeBSD:
* $Id: nfs_node.c,v 1.28.2.1 1999/06/07 00:04:05 peter Exp $
or
* $Id: nfs_node.c,v 1.29 1999/06/05 05:26:36 peter Exp $
...
/*
* Insert the nfsnode in the hash queue for its new file handle
*/
for (np2 = nhpp->lh_first
Umm, okay but I'm a little confused about how the zfree I'm adding to
nfs_nget falls under this. Am I being really stupid here?
On Tue, 15 Jun 1999, Matthew Dillon wrote:
> This is totally screwed up: The rules used to determine whether
> a path component buffer ( struct component
> > > We'd previously encountered problems with the Infortrend controller not
> > > at all liking the other disks we'd tried to talk to; a collection of
> > > Cheetahs with IBM and Compaq firmware simply wouldn't work. This time
> > > we had better luck with real Seagate firmware, and the arra
I've heard about something similar (a consistent crash in crfree during
cvsup), and don't know the reason, but an upgrade to 3.2 solved the
problem.
On Mon, 21 Jun 1999, Kevin Quinlan (UK) wrote:
> Hi,
>
> I asked this question on freebsd-questions a couple of weeks ago, got a
> couple of answ
I was talking about this on linux-kernel, but it also applies to *BSD...
What're folks' motions of a settable system unique identifier, available
prior to mountroot? This identifier has to be 64 bits or better and must
be persistent across reboots.
To Unsubscribe: send mail to majord...@free
> Some systems just take the IEEE MAC address from the motherboard, or
> that of the first interface it finds. Others use some algorithmic
> variation on that value, but it generally boils down to the same
> thing. For newer Intel boxes, you could just use the CPU chip...
> well, never m
On Thu, 24 Jun 1999, Jason Thorpe wrote:
> On Thu, 24 Jun 1999 15:02:25 -0700 (PDT)
> Matthew Jacob wrote:
>
> > I was talking about this on linux-kernel, but it also applies to *BSD...
> >
> > What're folks' motions of a settable system uniqu
> On Thu, 24 Jun 1999 23:41:34 -0700 (PDT)
> Matthew Jacob wrote:
>
> > More generally a system unique identifier available early (pre mountroot)
> > could be useful for a number of things. Why're you asking?
>
> The intended usage:
>
> (1) Co
> On Thu, 24 Jun 1999, Matthew Jacob wrote:
>
> > Specifically in this case a Node WWN for fibre channel fabrics that does
> > not depend upon an assigned WWN in any particular Fibre Channel card
> > (multipathing might make it desirable to have a synthetic Node WWN tha
>
> FYI: The Compaq HSG80 Fibrechannel RAID controllers have their
> WWN in NVRAM. One is supposed to get the WWN from a label on the *cabinet*
> into the HSG controller. This allows for easy hardware swap in case of
> hardware grief.
Yes, if you want the WWN to stay constant.
-matt
To Unsu
> >
> > Really? Couldn't the Port WWN change and the Node WWN stay constant? I
> > mean, yes, for FC controllers that have WWN in the 0x2 range,
> > the Node WWN is 0x20... and the Port is 0x22... but it seems like this is
> > a soft relationship- you *could* have Port && Node unique
ique value. All I'm asking for is a kernel function to help me
generate such a thing (despite what Eduardo says).
On Fri, 25 Jun 1999, Wilko Bulte wrote:
> As Matthew Jacob wrote ...
> > >
> > > FYI: The Compaq HSG80 Fibrechannel RAID controllers have their
> >
> >
> > I want it to persist until it's changed. Change doesn't mean a reboot.
> >
> > The Linux folks (mostly Ted) helped me clarify some thinking about this so
> > that the basic original source of the seeded WWN doesn't have to come from
> > first principles in hardware that can be read prio
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
Yes, but this kind of NVRAM isn't available on an Alpha, or a Sparc.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the mess
> Matthew Jacob wrote:
> >
> > > > Whose BIOS NVRAM?
> > >
> > > The host system BIOS NVRAM. I thought we were looking for a per-host
> > > ID here, right?
> >
> > Yes, but this kind of NVRAM isn't available on an Alpha, or a Sp
On Sat, 26 Jun 1999, Wilko Bulte wrote:
> As Matthew Jacob wrote ...
> >
> > Yes, you want the WWN to stay constant. That doesn't mean it should
> > necessarily be the same physical box. Nor does it mean it should be a
> > system that comes with a WWN
Umm- I've been running it for weeks on 3.2 with no problem.
On Sun, 27 Jun 1999, Thomas David Rivers wrote:
>
> I seem to recall seeing this someone (this may not be the
> right list.)
>
> But - I downloaded the 3.2 s...@home and starting running it
> on a left-over 75mhz laptop I have.
>
>
Reminds me of SCO. I personally don't much like it- it makes it harder
than hell to figure out what's gone wrong when it doesn't work.
On Thu, 1 Jul 1999, Steve Ames wrote:
>
> Everyone should take a peak at http://www.troll.no/announce/lizard.html
> if you haven't already. Definately take a lo
> if it gave me lots more diagnostics. Joe Average, on the other hand,
> likes a spiffy, clean interface. We try to accomodate both types by
> having a simplistic install and then some detail output on a seperate
> VTY. This could still be done with an even spiffier graphical installation
> on the
>OK, I'll add a few comments to this.
And I'll respond... The actual pros and cons of the current installer and
what a new one would look like is not the real question to answer here,...
I have to say that what we have isn't that bad- it fails only in some
areas where it violates the principle o
> > What actual marketing information do we actually have that says that in
> > order to go after the desktops we aren't currently installed on we have to
> > add a lot of engineering effort to the installer? Would it be better to
>
> Well, just to clear up what looks like a misunderstanding in t
> That being said... I've heard some of my ex-coworkers (who were all
> FreeBSD people when they worked here) come up to me in this impressed
> tone: "You wouldn't believe how much easier it is to install RedHat!'.
> *sigh* I'm not bitching... just being loyal :)
That's ridiculous. I've used both
I'm not sure what you mean by 'Busy' here, but it doesn't matter I
believe- the cam_periph_async called with
case AC_SENT_BDR:
case AC_BUS_RESET:
{
cam_periph_bus_settle(periph, SCSI_DELAY);
break;
}
should do bus settling for S
>
> We could have the ability to mark processes as being more or less
> preferable as kill candidates. I'm not sure I really care anymore,
> though... there is so much disk space available now that it is fairly
> difficult to run the system out of swap space. I don't think I've
> On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
> Matthew Dillon wrote:
>
> > You have to consider the probability of an event occuring, not just
> > the possibility that the event might occur. If the probability is
> > one in a million years, then it is not something you need to
1 - 100 of 372 matches
Mail list logo
