Note that you have to be careful to avoid the value of VNOVAL (-1) for a
uid or a gid, or you'll run into trouble with the VFS layer; this is
arguably due to poor design of VFS. NFSv2 also had problems with reserved
values (as the NFSv2 interface greatly resembles the VFS interface, for
the
I notice that my /var/log/wtmp has strange renewal times. I don't
know when it was not like this. newsyslog.conf is set to renew this
once per week. What is causing this?
# ls -l /var/log/wtmp*
-rw-rw-r-- 1 root wheel0 Apr 29 12:00 /var/log/wtmp
-rw-rw-r-- 1 root wheel 27 Apr 27
On Mon, Apr 30, 2001 at 21:22:01 +0300, Tomi Vainio - Sun Finland - wrote:
Kenneth D. Merry writes:
This should be fixed as of rev 1.22 of scsi_all.c. There was an errant
search and replace that caused the 'start' bit in the start/stop unit to
always be set to 0 (stop). So
Kenneth D. Merry writes:
Hmm. Well, I definitely haven't seen this before. The only thing I can
figure is that we got into some sort of infinite rescan loop. I don't know
how spinning up the disk (or trying to) would trigger a rescan.
My system has been up and running 21 hours
On Tue, May 01, 2001 at 22:03:37 +0300, Tomi Vainio - Sun Finland - wrote:
Kenneth D. Merry writes:
Hmm. Well, I definitely haven't seen this before. The only thing I can
figure is that we got into some sort of infinite rescan loop. I don't know
how spinning up the disk (or
Any -current kernel built over the weekend is a likely victim of this bug.
In a nutshell, it will eat your root filesystem at the very least, leaving
you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156
is should be avoided at all costs.
BEWARE: there are some snapshots on
In message [EMAIL PROTECTED], Thomas D. Dean write
s:
I notice that my /var/log/wtmp has strange renewal times. I don't
know when it was not like this. newsyslog.conf is set to renew this
once per week. What is causing this?
-rw-rw-r-- 1 root wheel 27 Apr 15 12:00 /var/log/wtmp.3.gz
I'm updating a machine (Pentium II 350, 128MB RAM) to -current, and ran
into this panic in the fxp driver. Sources are from today (5/1/2001).
I believe the chip is an 82557.
I compiled and installed a kernel, rebooted and started running an
installworld over NFS. The installworld stopped
Kenneth D. Merry wrote:
It looks like the mbuf pointer is bogus:
(kgdb) print m
$2 = (struct mbuf *) 0xf0006b00
(kgdb) print *m
Cannot access memory at address 0xf0006b00.
Although in the next frame up the stack, the mbuf pointer looks okay:
(kgdb) up
#1 0xc018ef76 in fxp_intr
On Tue, May 01, 2001 at 02:16:33PM -0700, Peter Wemm wrote:
On the other hand,
you might try using dwarf2 debugging, that is pretty complete.
And what we'll be using when GCC 3.0 is imported.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Why are %fs and %gs set back to default (_udata_sel) when posting
signals?
I am planning on using %fs for TSD/KSD and want it to be valid
in signal handlers.
A test program is at:
http://people.freebsd.org/~deischen/test_tsd.c
Compile it with -DDEBUG on an unpatched kernel to show more
On Tue, May 01, 2001 at 12:15:34PM -0700, some SMTP stream spewed forth:
Any -current kernel built over the weekend is a likely victim of this bug.
In a nutshell, it will eat your root filesystem at the very least, leaving
you with maybe one or two files in /lost+found. spec_vnops.c rev
Say, FreeBSD is usually pretty safe, even in CURRENT.
Has something near this magnitude of Really Bad Stuffage snuck into the
codebase before?
No, it's not common, and it generally takes a Dane swinging something
sharp to inflict quite this much damage on our user base. ;-)
- Jordan
To
It was almost like that dirpref problem I ran into a few weeks ago, I
upgraded from -stable to -current and I had to reinstall because of it, but
this usually doesn't happen.
- Original Message -
From: Jordan Hubbard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent:
On 01-May-01 Jordan Hubbard wrote:
Say, FreeBSD is usually pretty safe, even in CURRENT.
Has something near this magnitude of Really Bad Stuffage snuck into the
codebase before?
No, it's not common, and it generally takes a Dane swinging something
sharp to inflict quite this much damage
On Tue, May 01, 2001 at 06:23:59PM -0500, GH wrote:
On Tue, May 01, 2001 at 12:15:34PM -0700, some SMTP stream spewed forth:
Any -current kernel built over the weekend is a likely victim of this bug.
In a nutshell, it will eat your root filesystem at the very least, leaving
you with maybe
On Sun, Apr 29, 2001 at 12:50:08AM -0300, Rik van Riel wrote:
For the people wanting to turn on write caching ... it WILL break
the write ordering needed by softupdates and journaling filesystems,
so don't do it unless you know what you're doing.
I guess it would be better to do this kind
unsubscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Tue, 1 May 2001, Daniel Eischen wrote:
Why are %fs and %gs set back to default (_udata_sel) when posting
signals?
All segment registers are set to a default state so that signal handlers
have some chance of running when they interrupt code that has changed
the segment registers to unusual
19 matches
Mail list logo
