Followup- updated kernel, rebuilt, and the same thing that triggered this
before (^Z in vi) happened again, but this time with a different traceback:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x14
fault code = supervisor
On Wed, 21 Mar 2001, Stephen McKay wrote:
> On Tuesday, 20th March 2001, Ulf Zimmermann wrote:
>
> >On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote:
> >>
> >> On 20-Mar-01 Michael C . Wu wrote:
> >> > For all connections greater than 9600baud modems, we recommend
> >> > using CVSup
This commit broke telnet (or perhaps exposed brokenness that was
already present and never noticed):
$ cvs -R log -Nr1.6 main.c
RCS file: /opt/b/CVS/src/crypto/telnet/telnet/main.c,v
[...]
description:
revision 1.6
date: 2001/03/12 03:54:48; author: as
On Wed, 21 Mar 2001, David Malone wrote:
> On Mon, Mar 19, 2001 at 02:47:34PM +1100, Bruce Evans wrote:
> > > npx.c already has one "fix" for the overflow problem. The problem
> > > is may be that clocks don't work early any more.
> >
> > It must be that microtime() doesn't work early any more.
On Sunday, 11 March 2001 at 22:26:11 -0800, Alfred Perlstein wrote:
> * Greg Lehey <[EMAIL PROTECTED]> [010311 21:20] wrote:
>> On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote:
>>> * Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote:
On Sunday, 11 March 2001 at 3:27:02 -
On Wed, 21 Mar 2001, Ollivier Robert wrote:
> cvs diff: Diffing .
> Index: fsdbutil.c
> ===
> RCS file: /home/ncvs/src/sbin/fsdb/fsdbutil.c,v
> retrieving revision 1.10
> diff -u -2 -r1.10 fsdbutil.c
> --- fsdbutil.c 2000/05/01 20:0
Alfred Perlstein writes:
| What about the BABUG meeting on Thursday? There's gonna be a film
| crew from IBM-Linux there and a tutorial on netbooting.
|
| http://www.bafug.net/meetings/NextMeetingBerk.html
Including netbooting of an Airport base station?
run therboot or irport? >E
panic: getnewvnode: free vnode isn't
cpuid = 1; lapic.id = 0c00
Debugger("panic")
CPU1 stopping CPUs: 0x0001... stopped.
Stopped at Debugger+0x45: pushl %ebx
db> t
Debugger(c02e1241) at Debugger+0x45
panic(c02e5958,4,c1003800,c0ff5f00,c8f78620) at panic+0xd0
getnewvnode(1,c0ff100
On Wed, Mar 21, 2001 at 03:29:52PM -0500, Don Croyle scribbled:
| "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
|
| > I fully agree. wctype.h and isw*() must be implemented first instead of
| > hacking or using private interface (like runes) in userland program.
| > It will be easy to implement
Afer installworld in CURRENT, you'll have to run mergemaster ( or
install /etc/netconfig ) manually if you run any rpc-services.
Else you'll see strange errors like this:
- can't get net id for host/nfs: servname not supported for ai_socktype
- Protocol not supported
- rpcbind on server: RPC: U
On Mon, Mar 19, 2001 at 02:47:34PM +1100, Bruce Evans wrote:
> > npx.c already has one "fix" for the overflow problem. The problem
> > is may be that clocks don't work early any more.
>
> It must be that microtime() doesn't work early any more.
I did a quick check, and it does seem that i586_bz
On 21-Mar-01 Matthew Jacob wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id =
> fault virtual address = 0x14
NULL pointer deref..
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc019d7fa
> stack pointer
Get 100,000 Hits A Month -
Free!! Join The Special Report
Network Now and Easily Generate 100,000 Hot Leads a
Month for Anything You Sell
Check this site out
http://www.special-report-network.net/specialreports.cgi/NM52240
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc019d7fa
stack pointer = 0x10:0xc8f45ea4
frame pointer = 0x10:0xc8f45eb0
code
On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote:
> the way we code the standard utilities. That doesn't mean we
> shouldn't implement et al, but it does mean that we should
> use whichever facilities are cleanest, and easiest to code for and
> maintain, rather than those which are
On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote:
> < said:
>
> > This particular case is different from what you say. There is no strict
> > POSIX/ISO C equivalent of functionality you describe,
>
> Certainly there is. The daemon(3) function is implemented entirely on
> top of PO
< said:
> This particular case is different from what you say. There is no strict
> POSIX/ISO C equivalent of functionality you describe,
Certainly there is. The daemon(3) function is implemented entirely on
top of POSIX interfaces: fork(), setsid(), chdir(), open(), dup2(),
and close(). It i
On Wed, Mar 21, 2001 at 16:19:10 -0500, Garrett Wollman wrote:
> You would have to exclude most of the programs in 4.4BSD by that
> definition. There is a reason why interfaces like err(3) and
> daemon(3) are included in the standard C library, and the style guide
> strongly recommends their usag
< Sorry I'm not sure but rune API is slightly different
> between 4.4BSD and Plan9, isn't it?
Nobody runs Plan 9, whereas hundreds of thousands of machines run
*BSD.
> Sources of the standard commands are often used as a living
> textbook to other programmers. They should be as `good' as
> poss
On 21-Mar-01 Ollivier Robert wrote:
> cvs diff: Diffing .
> Index: fsdbutil.c
> ===
> RCS file: /home/ncvs/src/sbin/fsdb/fsdbutil.c,v
> retrieving revision 1.10
> diff -u -2 -r1.10 fsdbutil.c
> --- fsdbutil.c 2000/05/01 20:01:16
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> I fully agree. wctype.h and isw*() must be implemented first instead of
> hacking or using private interface (like runes) in userland program.
> It will be easy to implement them over existen ctype mechanism masking
> runes with wchar_t. Any taker
> Using cvsup to catch up to changes for 4.2-Stable, we ended up with
> 4.3-Beta. We used cvsup Nov-December, with (I thought) the attached
> cvsup file, to keep 4.2-Stable current. We ran cvsup yesterday. After
> `buildworld`, `buildkernel`, `uname` says:
>
> FreeBSD [host] 4.3-BETA FreeBSD 4.3
Hurf Sheldon wrote:
> Using cvsup to catch up to changes for 4.2-Stable, we ended up with
> 4.3-Beta.
This is perfectly alright. The -BETA just means that we are approaching
4.3-RELEASE after which it is called 4.3-STABLE and so on. It is the
same code:
.. -> 4.2-RELEASE -> 4.2-STABLE -> 4.3-BE
The Portmapper binary has been renamed from `portmap' to `rpcbind'.
The name change was taken care of in /etc/defaults/rc.conf and in the
auto-dependacy code in /etc/rc.
HOWEVER, you may need to edit your /etc/hosts.allow and make the name
change there.
--
-- David ([EMAIL PROTECTED])
On a positive note, both Pachell and Covad agree the localloop for
my new DSL is ready, so I hope to see a covad person with router
in the next few days, which would mean I should be up and running
again soon.
--
Regards, Ulf.
On Wed, Mar 21, 2001 at 09:44:00PM +1000, Stephen McKay wrote:
> On Tuesday, 20th March 2001, Ulf Zimmermann wrote:
>
> >On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote:
> >>
> >> On 20-Mar-01 Michael C . Wu wrote:
> >> > For all connections greater than 9600baud modems, we recommen
Darn,
Using cvsup to catch up to changes for 4.2-Stable, we ended up with
4.3-Beta. We used cvsup Nov-December, with (I thought) the attached
cvsup file, to keep 4.2-Stable current. We ran cvsup yesterday. After
`buildworld`, `buildkernel`, `uname` says:
FreeBSD [host] 4.3-BETA FreeBSD 4.3-BETA
portmap is dead, long live rpcbind!
This means you'll need to update /etc/hosts.allow probably like
revision 1.12 where I did a s/protmap/rpcbind/g.
And now that I have your attention...
Anyone want to add the tirpc stuff to our newsflash?
What about Kirk's background fsck?
What about the B
> >
> >Looks like I've got a similar problem only its aic7880/wide
> >I've got a Dell optiplex 450 with an Adaptec 2940uw controller which can
> >boot but can't "mountroot".
>
> Perhaps something happend recently that makes it difficult to get
> "largish" chuncks of contiguous memory? You'll ha
subscribe freebsd-current
subscribe cvs-all
-- Pascal Filipovicz ---
IUT 'A' Nancy-Verdun - S.C.I.
2ter, bd Charlemagne
CS 5227
54000 Nancy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
cvs diff: Diffing .
Index: fsdbutil.c
===
RCS file: /home/ncvs/src/sbin/fsdb/fsdbutil.c,v
retrieving revision 1.10
diff -u -2 -r1.10 fsdbutil.c
--- fsdbutil.c 2000/05/01 20:01:16 1.10
+++ fsdbutil.c 2001/03/21 13:42:01
@@ -35,4
===> sbin/fsdb
cc -O -pipe -march=pentiumpro -I/src/src/sbin/fsdb/../fsck_ffs
-I/usr/obj/src/src/i386/usr/include -c /src/src/sbin/fsdb/fsdb.c
cc -O -pipe -march=pentiumpro -I/src/src/sbin/fsdb/../fsck_ffs
-I/usr/obj/src/src/i386/usr/include -c /src/src/sbin/fsdb/fsdbutil.c
/src/src/sbin/fsd
> Just an idea:
>
> How about a CVSUP via HTTPS server (just as a means to tunnel CVSUP
> through a HTTPS proxy ...) ?
>
> Most probably a CVSUP daemon bound to port 443 would do (there are
> programs that tunnel arbitrary data through a HTTPS proxy, though
> I admit this is cheating ;-)
You s
On Tuesday, 20th March 2001, Ulf Zimmermann wrote:
>On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote:
>>
>> On 20-Mar-01 Michael C . Wu wrote:
>> > For all connections greater than 9600baud modems, we recommend
>> > using CVSup to get src-all and ports-all updated. At the worst case,
On Wed, Mar 21, 2001 at 12:58:05 +0900, MINOURA Makoto wrote:
>
> |> In <[EMAIL PROTECTED]>
> |> Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> wrote:
>
> > Which is still something which needs to be done yes.
>
> Hmmm, I didn't know that... FreeBSD lacks iswprint() etc...
>
> It's..., it's ok, M
On Tue, Mar 20, 2001 at 18:13:20 +, thinker wrote:
> + sz = mbtowc(&c, p, dc);
> + if (isprint(c)) {
As MINOURA correctly notes, you can't use isprint() with wchar_t type
(isprint() is for runes and single chars only, but runes are not widely
accepted standar
On Wed, Mar 21, 2001 at 03:13:42PM +1100, Bruce Evans wrote:
[...]
> Only the amd ones are broken. The bug is in ../Makefile.inc. It spams
> ${SRCS} with some nfs headers. This breaks 's automatic
> setting of ${SRCS} from ${PROG}. SRCS should be under the control of
> individual Makefiles exc
[EMAIL PROTECTED] writes:
> Trying to mount a music cd might cause the atapi code to try to read
> 9408 bytes into a 8192 bytes long buffer.
That's not it. There was a music CD in the drive, but no attempt was
made to mount it - I wasn't even there when it crashed.
DES
--
Dag-Erling Smørgrav -
On 2001-03-19 17:01 -0800, Ulf Zimmermann <[EMAIL PROTECTED]> wrote:
> I have been hosting the machine which ran ctm, unfortunatly my provider
> cut me off and I just got some access back, but not for the location
> the ctm machine is located at.
Ummm, that's bad ...
I had been hoping that CTM de
39 matches
Mail list logo
