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 obvi
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 16:0
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 (
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 curr
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 here:
"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
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
detai
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 1.
> 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 Un
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]>
Se
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
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
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 ki
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
