:On the server I downgraded vfs_bio.c to rev 1.187 & rebooted; no luck. I
:then installed the same kernel (with the downgraded vfs_bio.c) to the
:client. Bingo. With both NFS client & server machine running rev 1.187,
:the problem so far as building XFree86-contrib from an NFS mounted
:/usr/port
Hello,
I tried to make world (src-cur.3710) todya and found the following error.
Can anyone tell me how to solve it. thanks.
Clarence
=== Error ===
In file included from /usr/obj/usr/src/gnu/usr.bin/perl/perl/perl.h:2081,
from DynaLoader.xs:107:
/usr/obj/usr/src/gnu/usr
Hello,
I have two system. One is P233 (master) and the other is a dual P90.
How can I update the dual P90 system from the P233 (master) system.
Is there anyone can share your experience with me. Thanks.
clarence
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-curr
At 16.22 18/01/99 +0800, you wrote:
>Hello,
>
>I have two system. One is P233 (master) and the other is a dual P90.
>How can I update the dual P90 system from the P233 (master) system.
>Is there anyone can share your experience with me. Thanks.
>
>clarence
I usually have a box ("server") which
With sources as of about 10 p.m. PST, I got an error in
/usr/src/usr.bin/netstat/mbuf.c:71, which was easy to fix.
But I still got an error much later with texinfo, so apparently
this is only partly fixed.
Annelise
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-cur
At 09.44 18/01/99 +0100, Gianmarco Giovannelli wrote:
>At 16.22 18/01/99 +0800, you wrote:
>I usually have a box ("server") which make the make world process, the
>others ("clients") only install what the server did :-)
>
>Let's say in advance that I do it _only_ if server and clients run the same
Andrew Atrens wrote:
>
> On Sun, 17 Jan 1999, Karl Pielorz wrote:
>
> Karl,
>
> Let's see your (dmesg) probe messages ... :) they may shed some light on
> what's happening. I don't claim to be an expert on wd.c but from what I
> can tell it seems that controller and drive capabilities are pro
Hi folks,
Is the following behaviour from netstat expected under CURRENT?
input (xl0) output
packets errs bytespackets errs bytes colls
2 0390 0 0 0 0
4 0264 0 0
Dear friend,
Do you ever wonder where to find information about China? Well, wonder no
more. Come check out SurfChina.com (http://www.surfchina.com), the BEST
SEARCH ENGINE for China. SurfChina.com's database consists of thousands
of China, Chinese related web sites, all sites are carefully cate
[snip]
> Dear friend,
>
> Do you ever wonder where to find information about China?
> Well, wonder no
> more. Come check out SurfChina.com
[snap]
just wondering if anyone else receives this post about 10 times...?
--
Markus Doehr
IT Admin
AUBI Bau
The removal of MT_RTABLE by fenner in rev 1.32 of /sys/sys/mbuf.h has
broken the build of the tree in netstat. It may have broken other net
apps that I haven't hit yet.
There's also a new coding style that I've not come across before being
used in this file, it's based on commenting out lines by c
::On the server I downgraded vfs_bio.c to rev 1.187 & rebooted; no luck. I
::then installed the same kernel (with the downgraded vfs_bio.c) to the
::client. Bingo. With both NFS client & server machine running rev 1.187,
::...
::-Chris
:
:Hmm. r1.88 are Luoqi's fixes to the handling of misa
I got the following when trying a new make world (1-17-99):
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/netstat/if.c
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/netstat/inet.c
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/
Good work! I have to run at the moment but it looks like you nailed this
one. Your explanation coincides perfectly with the symptoms.
Thanks!
-Chris
On Mon, 18 Jan 1999, Matthew Dillon wrote:
> Ok, I believe I have found the bug. Please test the patch included below.
> I was able t
The check is correct and should be there, the B_CACHE bit was cleared because
I made a mistake when setting the valid bit in the vm page.
Index: vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.192
dif
We're having trouble using the new boot loader code and '-h' in
boot.config. It appears that unless the terminal is connected to
the serial port a machine doesn't reboot properly. My guess is
that the new boot serial code is defaulting to hardware handshaking
on the serial terminal line, whereas
Unfortunately in practice at the desktop level there are a mix of hosts that
run on ATM or ethernet. As is the case here where we use LANE to integrate
both in to a single network.
Chris
>ATM LANE is evil. Why do you want it?
>
>On Sun, Jan 17, 1999 at 06:58:24PM -0500, Chris Steva wrote:
>> I
Josef Karthauser wrote:
> We're having trouble using the new boot loader code and '-h' in
> boot.config. It appears that unless the terminal is connected to
> the serial port a machine doesn't reboot properly. My guess is
> that the new boot serial code is defaulting to hardware handshaking
> on
A. Yes, I see. I will unapply my patch and apply this one and test
it.
I'm not sure what the use of having m->valid and m->clean bits are at all
if we have to munge them like this. Perhaps we should change these
vm_page_t to a byte range in -4.0.
I think we also nee
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/netstat/uni
x.c
/usr/src/usr.bin/netstat/mbuf.c:71: `MT_RTABLE' undeclared here (not in a
functi
on)
/usr/src/usr.bin/netstat/mbuf.c:71: initializer element for
`mbtypes[4].mt_type'
is not constant
Gary
--
Gary Palmer
Hey gang:
Should I worry about these messages on the console when doing a make release?
vn0: raw partition size != slice size
vn0: start 0, end 2879, size 2880
vn0: start 0, end 5759, size 5760
vn0: truncating raw partition
vn0: rejecting partition in BSD label: it isn't entirely within the slic
Hello,
When CAM was integrated someone reported that the aic driver was not
ready yet for CAM, but that "Brian Beattie is
working on it".
At the moment, looking in LINT, it looks like aic still isn't
supported. Is that true? Does anyone know whether it will be?
Thanks,
--
Peter Mutsaers | Ab
Here at whistle we are trying to remember about a conversation
regarding malloc that occured recently. Maybe others can help.
There was some talk about the fact that malloc(..M_CANWAIT)
can now return with a failure. Is that true?
who has their finger on that particular button?
julian
(p.s. sti
Of course I meant M_WAITOK not M_CANWAIT
julian
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
In /usr/src/release/texts/RELNOTES.TXT it lists the following for
supported adaptec controllers:
Adaptec 1535 ISA SCSI controllers
Adaptec 154x series ISA SCSI controllers
Adaptec 174x series EISA SCSI controller in standard and enhanced mode.
Adaptec 274X/284X/2920/2940/2950/3940/3950 (Narrow/Wi
>
> Here at whistle we are trying to remember about a conversation
> regarding malloc that occured recently. Maybe others can help.
>
> There was some talk about the fact that malloc(..M_CANWAIT)
> can now return with a failure. Is that true?
Yes; it's necessary to do this to allow some chance o
On Mon, 18 Jan 1999, Mike Smith wrote:
> >
> > Here at whistle we are trying to remember about a conversation
> > regarding malloc that occured recently. Maybe others can help.
> >
> > There was some talk about the fact that malloc(..M_CANWAIT)
> > can now return with a failure. Is that true?
>
> On Mon, 18 Jan 1999, Mike Smith wrote:
>
> > >
> > > Here at whistle we are trying to remember about a conversation
> > > regarding malloc that occured recently. Maybe others can help.
> > >
> > > There was some talk about the fact that malloc(..M_CANWAIT)
> > > can now return with a failure.
On Mon, 18 Jan 1999, Mike Smith wrote:
> > On Mon, 18 Jan 1999, Mike Smith wrote:
> >
> > > >
> > > > Here at whistle we are trying to remember about a conversation
> > > > regarding malloc that occured recently. Maybe others can help.
> > > >
> > > > There was some talk about the fact that mal
:> > There was some talk about the fact that malloc(..M_CANWAIT)
:> > can now return with a failure. Is that true?
:>
:> Yes; it's necessary to do this to allow some chance of avoiding
:> deadlock.
:
:Ouch! Is everything in src-sys already checking the return value of an
M_WAITOK?
:
: Brian Feld
On Mon, 18 Jan 1999, Mike Smith wrote:
> >
> > Here at whistle we are trying to remember about a conversation
> > regarding malloc that occured recently. Maybe others can help.
> >
> > There was some talk about the fact that malloc(..M_CANWAIT)
oops M_WAITOK..
> > can now return with a failur
On Mon, 18 Jan 1999, Matthew Dillon wrote:
> :> > There was some talk about the fact that malloc(..M_CANWAIT)
> :> > can now return with a failure. Is that true?
> :>
> :> Yes; it's necessary to do this to allow some chance of avoiding
> :> deadlock.
> :
> :Ouch! Is everything in src-sys already
> > > There was some talk about the fact that malloc(..M_CANWAIT)
> oops M_WAITOK..
>
> > > can now return with a failure. Is that true?
> >
> > Yes; it's necessary to do this to allow some chance of avoiding
> > deadlock.
>
> I can't find this in the archives.. can you remember
> a keyword th
> > So malloc() will generally not return NULL even in low memory situations
> > unless the KVM map fills up, which isn't supposed to happen but can in
> > certain severe circumstances. Callers should therefore check for NULL.
>
> why not just put it in a loop and block on lbolt?
> (o
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
>There was some talk about the fact that malloc(..M_CANWAIT)
>can now return with a failure.
You mean M_WAITOK.
>Is that true?
Of course not. It is fundamental that malloc(..., M_WAITOK) either
succeeds or panics. Most callers depend on this and don't check for
success. The others are bogus.
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
Whistle is preparing to submit it's synchronous protocols suppoort
framework, but to make it usable
we'd like to be able to release it with support for the sr and ar sync
cards (and maybe even the third (cx) if I can get to it).
However as we have NONE of those cards I'll need people to help test
> > why not just put it in a loop and block on lbolt?
> > (or call panic)
>
> Because you shouldn't panic unless there's no alternative. Panicking
> on resource starvation is just totally lame.
We haven't used up the kernel name space yet. This sort of
fundamental change should be enabled by a
On Tue, 19 Jan 1999, Bruce Evans wrote:
> >There was some talk about the fact that malloc(..M_CANWAIT)
> >can now return with a failure.
>
> You mean M_WAITOK.
yes.. a braino..
(I corrected in later mail)
>
> >Is that true?
>
> Of course not. It is fundamental that malloc(..., M_WAITOK) eit
>It looks like malloc() can return NULL if the kmem_malloc() fails.
Not for the M_WAITOK case.
>kmem_malloc() can only fail in the M_WAITOK case if the KVM map is full.
kmem_malloc() panics in this case (except for map == mb_map; the mbuf
allocator has special handling for this problem).
>> Of course not. It is fundamental that malloc(..., M_WAITOK) either
>> succeeds or panics. Most callers depend on this and don't check for
>> success. The others are bogus.
>
>actually it turns out to be true..
Actually not.
>see other email from matt.
See my corrections to that mail.
Bruc
> On Mon, 18 Jan 1999, Mike Smith wrote:
>
> > > > So malloc() will generally not return NULL even in low memory
> > > > situations
> > > > unless the KVM map fills up, which isn't supposed to happen but can
> > > > in
> > > > certain severe circumstances. Callers should therefore c
>Look at the void () functions that call malloc/MALLOC. Also, commit the
>attached patch; it was OKed by Bruce to disallow this, but he seems to forget
>to commit it.
It is queued behind 10-100 other patches.
>--- src/sys/kern/vfs_syscalls.c.orig Fri Dec 25 22:27:21 1998
>+++ src/sys/kern/vfs_s
> > Because you shouldn't panic unless there's no alternative. Panicking
> > on resource starvation is just totally lame.
>
> Ahem:
> uipc_mbuf.c: unmodified, readonly: line 268 of 945 [28%]
> panic("Out of mbuf clusters");
> uipc_mbuf.c: unmodified, readonly: line 296 of
> >If the system is simply low on memory, kmem_malloc() will block.
> >
> >So malloc() will generally not return NULL even in low memory situations
> >unless the KVM map fills up, which isn't supposed to happen but can in
> >certain severe circumstances. Callers should therefore ch
Making use of a hint from Mike Smith (re: "two-floppy boot"), I tried
upgrading a box here that had been running an older level of -CURRENT to
the 19990112-SNAP. Died while copying data (I think it was ports) with
a SIGSEGV; no recent corefiles were on the system, and I didn't think it
was worthwh
On Tue, 19 Jan 1999, Bruce Evans wrote:
> >Look at the void () functions that call malloc/MALLOC. Also, commit the
> >attached patch; it was OKed by Bruce to disallow this, but he seems to forget
> >to commit it.
>
> It is queued behind 10-100 other patches.
>
> >--- src/sys/kern/vfs_syscalls.c.
On Mon, 18 Jan 1999, Mike Smith wrote:
> > >If the system is simply low on memory, kmem_malloc() will block.
> > >
> > >So malloc() will generally not return NULL even in low memory
> > > situations
> > >unless the KVM map fills up, which isn't supposed to happen but can in
> > >c
On Mon, 18 Jan 1999, Chan Yiu Wah wrote:
> Hello,
>
> I have two system. One is P233 (master) and the other is a dual P90.
> How can I update the dual P90 system from the P233 (master) system.
> Is there anyone can share your experience with me. Thanks.
>
> clarence
I have used dump and re
I running gimp -unstable (CVS 1/17/1998) and FreeBSD -current
(1/17/1998) with
CFLAGS= -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK
COPTFLAGS= -O -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK
and linuxthreads port from http://lt.tar.com.
recompiled glib, gtk+ and gimp which works fine reasonably
On Mon, 18 Jan 1999 br...@worldcontrol.com wrote:
> I running gimp -unstable (CVS 1/17/1998) and FreeBSD -current
> (1/17/1998) with
>
> CFLAGS= -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK
> COPTFLAGS= -O -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK
>
> and linuxthreads port from http://lt.tar.
According to p...@originative.co.uk:
> The removal of MT_RTABLE by fenner in rev 1.32 of /sys/sys/mbuf.h has
> broken the build of the tree in netstat. It may have broken other net
> apps that I haven't hit yet.
Already fixed. If you're not subscribed to cvs-all, please do...
--
Ollivier ROBERT -
According to Annelise Anderson:
> But I still got an error much later with texinfo, so apparently
> this is only partly fixed.
Weird. After fixing netstat, my "make buildworld" succeeded w/o any
problem...
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD k
For what it's worth, the FP security issues are very well documented
by ReadyToRun Software's site (these are the folks who do the UNIX
ports for Microsoft).
They also keep both BSDI 2.1 and 3.0 binaries available, and they
know about FreeBSD (it's mentioned in the FAQ as an unsupported
platform;
Peter Mutsaers wrote...
> Hello,
>
> When CAM was integrated someone reported that the aic driver was not
> ready yet for CAM, but that "Brian Beattie is
> working on it".
Right.
> At the moment, looking in LINT, it looks like aic still isn't
> supported. Is that true? Does anyone know whether
> As far as I know, I don't think the 2920 is supported since it's not a
> standard adaptec card (it was bought from another company)
Old 2920, AHA-2920A is using Future Domain chip. Newer 2920,
AHA-2920C? is using adaptec chip. But I don't test yet.
And, 2910 is using adaptec chip, too. This car
Ken Krebs wrote...
>
> In /usr/src/release/texts/RELNOTES.TXT it lists the following for
> supported adaptec controllers:
>
> Adaptec 1535 ISA SCSI controllers
> Adaptec 154x series ISA SCSI controllers
> Adaptec 174x series EISA SCSI controller in standard and enhanced mode.
> Adaptec 274X/284X/
Hi ! Bad news, make release still produces non bootable floppies.
I cvsupped yesterday evening at 8pm and did a make world and
make release
Now I tried the boot.flp image from the ftp subdir in /R/
First error message
No /boot/loader
Then the typical "boot banner"
2nd error messa
> Hi ! Bad news, make release still produces non bootable floppies.
> I cvsupped yesterday evening at 8pm and did a make world and
> make release
>
> Now I tried the boot.flp image from the ftp subdir in /R/
>
> First error message
> No /boot/loader
> Then the typical "boot banner"
As I now have upgraded at last, I tested the 3.0
version of the patch. It does appear to make the
system recognize the proper disk geometry where the
standard wd.c does not report the proper size.
Attached is the diff and 2 dmesgs, before and after.
(Sorry for the length of the dmesg, haven't com
Appears the diff didn't get attached.
Here it is.
Sorry!
---Andrew Sherrod wrote:
>
>
> As I now have upgraded at last, I tested the 3.0
> version of the patch. It does appear to make the
> system recognize the proper disk geometry where the
> standard wd.c does not report the proper size.
>
> If you want SCSI support any time soon, I would suggest getting a supported
> card. An ISA Advansys card might be a good, cheap substitute for your
> 6360/6260 board.
Adaptec SlimSCSI is major PC-Card SCSI-IF, it is based on
aic6360. Now, aic not supported yet, so Note-PC user can't use any
PC
On Mon, Jan 18, 1999 at 09:52:26PM -0800, Mike Smith wrote:
> > Hi ! Bad news, make release still produces non bootable floppies.
> > I cvsupped yesterday evening at 8pm and did a make world and
> > make release
> >
> > Now I tried the boot.flp image from the ftp subdir in /R/
> >
> > Fi
> On Mon, Jan 18, 1999 at 09:52:26PM -0800, Mike Smith wrote:
> > > Hi ! Bad news, make release still produces non bootable floppies.
> > > I cvsupped yesterday evening at 8pm and did a make world and
> > > make release
> > >
> > > Now I tried the boot.flp image from the ftp subdir in /R/
In message <199901190613.paa06...@chandra.eatell.msr.prug.or.jp> NAKAGAWA
Yoshihisa writes:
: Adaptec SlimSCSI is major PC-Card SCSI-IF, it is based on
: aic6360. Now, aic not supported yet, so Note-PC user can't use any
: PC-Card SCSI-IF.
I'd love to see the aic supported, mostly for my notebo
66 matches
Mail list logo
