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
unsubscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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 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
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
> 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
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.
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 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
"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
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:
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
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
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 (
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 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
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
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
19 matches
Mail list logo
