Re: ffs_valloc: dup alloc panics with stable/current

[Mike Smith]

 On Fri, Dec 08, 2000 at 03:44:28AM +0200, Tomi Vainio - Sun Finland - wrote:
 
   sense = 3 asc = 11 asq = 0
   This is not so bad but 5-30 minutes after this command system will
   always panic.
 
 Are you surprised?  The system is complaining that it's having intermittent
 difficulty accessing the disk, so it shouldn't be at all surprising that
 you'd have disk corruption problems as a result.

Actually, it's upstream from the RAID controller.  There don't appear to 
be any actual complaints from the controller about read errors, so I'm a 
little skeptical that this is actually the "real" problem.

 Start by checking your SCSI cabling and termination.  Almost all SCSI 
 problems boil down to that eventually.

The entire system; disks, controller, etc. is all pretty skanky by the 
sound of it.  It wouldn't surprise me too much if the system is suffering 
eg. multiple-master data corruption, or straight out memory/cache errors.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[Alexander Langer]

Thus spake The Hermit Hacker ([EMAIL PROTECTED]):

 
 Stripe'd file systems (or concat ones) ... what growfs allows is someone
 to add an n+1 drive to their RAID/Stripe and increase the size of the file

No, vinum can do this alone.

But you couldn't grow the _fs_ after that, so there was no use for
this vinum feature.

Now you can, not only on vinum volumes but also on usual harddisks and
ccd devices.

At least this is, what Christoph told me.

A shrinking utility would be VERY nice, too.
I would have use for this :)

Alex

-- 
cat: /home/alex/.sig: No such file or directory


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sys/mutex.h - compilation errors

[Christoph Kukulies]

I cvsuped src , built world and tried to compile a new kernel.
Presently compilation fails with error in ASM line 601 in ../../sys/mutex.h.

Any ideas? 

(that code seems to be used by i4b sppp routines)

-- 
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Current CVS kernel panic ...

[Igor Timkin]

The same with 2xPIII-800:
Booting [/boot/kernel/kernel]...   
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Fri Dec  8 00:46:58 MSK 2000
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSFEED
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (801.82-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
 [...]
da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled
da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)
SMP: AP CPU #1 Launched!
Using /entropy as an entropy file
vinum: loaded
 [*** system freeze and I try call ddb ***]
~[gw-msu]%break
panic: spin lock sched lock held by 0x0xdb8f4840 for  5 seconds
 [another reboot: panic: spin lock sched lock held by 0x0xdb8f4a60 for  5 seconds]
cpuid = 1; lapic.id = 
boot() called on cpu#1

syncing disks... 
done
Uptime: 50s

The Hermit Hacker writes:
 
 Just upgraded the kernel, rebooted and it hung/panic'd with:
 
 panic: spin lock sched lock held by 0x0xc02a73el for  5 seconds
 cpuid = 1; lapic.id = 0100
 Debugger("panic")
 
 I have DDB enabled, and ctl-alt-esc doesn't break to the debugger, so its
 totally hung here ...
 
 dual-cpu celeron, smp enabled ...
 
 Marc G. Fournier   ICQ#7615664   IRC Nick: Scrappy
 Systems Administrator @ hub.org 
 primary: [EMAIL PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sys/mutex.h - compilation errors

[Jake Burkholder]

 
 I cvsuped src , built world and tried to compile a new kernel.
 Presently compilation fails with error in ASM line 601 in ../../sys/mutex.h.
 
 Any ideas? 
 
 (that code seems to be used by i4b sppp routines)

This should be fixed, or at least worked around for a while.
Re-cvsup and try again.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sys/mutex.h - compilation errors

[Christoph Kukulies]

On Fri, Dec 08, 2000 at 03:37:46AM -0800, Jake Burkholder wrote:
  
  I cvsuped src , built world and tried to compile a new kernel.
  Presently compilation fails with error in ASM line 601 in ../../sys/mutex.h.
  
  Any ideas? 
  
  (that code seems to be used by i4b sppp routines)
 
 This should be fixed, or at least worked around for a while.
 Re-cvsup and try again.

Easier said than done with a broken isdn link (due to a system running an
old kernel with new system binaries :)

Could you tell me which files were related to that fix? mutex.h itself doesn't
seem to be upgraded since Dec 1, so it may be some other essential
header files?


-- 
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ffs_valloc: dup alloc panics with stable/current

[Mike Smith]

 We got old Mylex DAC960PD-Ultra-raid-adapter and have tried to use it
 with FreeBSD 4.2-stable and 5.0-current. Adapter is configured with
 three luns 5+5*9G, 8+8*9G (raid5) and 1+1*2G (mirrored boot disk).
 All 9G disks are quite old Seagate Barracuda 9 disks ST19171W.  System
 is working quite well but under heavier load we start to get scsi
 errors from luns.
 sense = 4 asc = 3 asq = 0
 sense = 1 asc = 3 asq = 0
 sense = 3 asc = 12 asq = 0
 sense = 3 asc = 11 asq = 0

Your disks just aren't up to this sort of workload.

 This is not so bad but 5-30 minutes after this command system will
 always panic.
 cd /uu ; dump 0buf 126 - /w | restore xbf 126 -
 
 mode = 0100644, inum = 720391, fs = /uu
 panic: ffs_valloc: dup alloc

This looks like memory or PCI data corruption.  You don't say how you're 
generating this load, or what the motherboard is, but I suspect that you 
may have hardware issues here.

One question - I assume you're not seeing any read error diagnostics from 
the Mylex driver (other than the disk errors?)

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sys/mutex.h - compilation errors

[Jake Burkholder]

 On Fri, Dec 08, 2000 at 03:37:46AM -0800, Jake Burkholder wrote:
   
   I cvsuped src , built world and tried to compile a new kernel.
   Presently compilation fails with error in ASM line 601 in ../../sys/mutex.h.
   
   Any ideas? 
   
   (that code seems to be used by i4b sppp routines)
  
  This should be fixed, or at least worked around for a while.
  Re-cvsup and try again.
 
 Easier said than done with a broken isdn link (due to a system running an
 old kernel with new system binaries :)

oh joy   :)

 
 Could you tell me which files were related to that fix? mutex.h itself doesn't
 seem to be upgraded since Dec 1, so it may be some other essential
 header files?

Yeah, its pretty simple.  We're having trouble with gcc generating bad
code for inline asm in the mutexes, the fix is to use the un-optimized
c versions of the mutex routines for now.

This should get things compiling again:

===
RCS file: /home/ncvs/src/sys/i386/include/mutex.h,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -p -r1.15 -r1.16
--- src/sys/i386/include/mutex.h2000/12/07 02:23:16 1.15
+++ src/sys/i386/include/mutex.h2000/12/08 05:03:34 1.16
@@ -26,7 +26,7 @@
  * SUCH DAMAGE.
  *
  * from BSDI $Id: mutex.h,v 2.7.2.35 2000/04/27 03:10:26 cp Exp $
- * $FreeBSD: src/sys/i386/include/mutex.h,v 1.15 2000/12/07 02:23:16 jhb Exp $
+ * $FreeBSD: src/sys/i386/include/mutex.h,v 1.16 2000/12/08 05:03:34 jhb Exp $
  */
 
 #ifndef _MACHINE_MUTEX_H_
@@ -69,7 +69,8 @@ extern char STR_SIEN[];
 
 #define_V(x)   __STRING(x)
 
-#ifndef I386_CPU
+#if 0
+/* #ifndef I386_CPU */
 
 /*
  * For 486 and newer processors.

 
 
 -- 
 Chris Christoph P. U. Kukulies [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[The Hermit Hacker]

On Fri, 8 Dec 2000, Alexander Langer wrote:

 Thus spake The Hermit Hacker ([EMAIL PROTECTED]):
 
  
  Stripe'd file systems (or concat ones) ... what growfs allows is someone
  to add an n+1 drive to their RAID/Stripe and increase the size of the file
 
 No, vinum can do this alone.
 
 But you couldn't grow the _fs_ after that, so there was no use for
 this vinum feature.

Okay, that is what I said ... "add an n+1 drive to ... and increase the
size of the file system" ... 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Nothing on TV? Surf your way through 500 Channels!

[Martin]

FREE Satellite T.V. System and FREE Installation

For a limited time we'll give you this top of the line Digital
Satellite System for FREE!  We'll even include Free installation.

Enjoy over 500 Channels of crystal clear digital picture and
cd stereo sound on your FREE Satellite TV System.  Why pay
for these items in a retail store, when we're giving you the
same satellite package for free.


Call 888-514-6881 to be Guaranteed Your FREE Satellite Today


This Innovative 20" Satellite includes a stereo receiver and
an infrared remote.  With this FREE offer you will have both
Interactive Television Capability and an On Screen Program Guide.

This limited time FREE offer is much less than the monthly cost
of cable tv. All you have to do is call us to arrange delivery.   
If you call today, we'll throw in a second receiver for your
second T.V. free.


Call 888-514-6881 to Begin Surfing through 500 Channels Today!


To be removed send email to [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: write(2) returns error saying read only filesystem when trying to write to a partition

[Daniel C. Sobral]

Matthew Thyer wrote:
 
 
 In the grand tradition of being allowed to shoot yourself in the foot,
 I would like to be able to do such things as this is clearly what I
 intend.  Since we dont normally hold peoples hands for other things,
 why cant we allow big holes in my feet for this too ?
 
 Regardless /dev/da18s1 should work as for /dev/da18
 
 I know... send patches... unfortunately my day job hasn't seen the
 light yet so I cant work on FreeBSD at work.

No, and no. You misunderstand the problem.

A disk on IBM PC compatible computers has the following format:

| Partition table | Data|
  | Slice 1   | Slice 2 | Slice 3 | Slice 4 |
  | Disklabel | Data  |
  |   c   |
  |a|b|f|g|

The partition table divides the data in up to four slices. Each slice
may have, under FreeBSD, a disklabel and have the rest of it divided
into up to seven partitions, with one partition, c, representing the
total data space.

So da1 represents the whole disk, including partition table. da1s1 may
or may not represent the whole data part of the disk (ie, whole disk
minus partition table), because that's what da1s1 *is*, etc, etc, etc.

This has nothing to do with preventing the user from shooting himself in
the foot. This is just how the disk is, as a matter of fact, organized.

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"The bronze landed last, which canceled that method of impartial
choice."



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: write(2) returns error saying read only filesystem when trying to write to a partition

[Vallo Kallaste]

On Sat, Dec 09, 2000 at 12:02:21AM +0900, "Daniel C. Sobral" [EMAIL PROTECTED] wrote:

 No, and no. You misunderstand the problem.
 
 A disk on IBM PC compatible computers has the following format:
 
 | Partition table | Data|
   | Slice 1   | Slice 2 | Slice 3 | Slice 4 |
   | Disklabel | Data  |
   |   c   |
   |a|b|f|g|
[snip]

Nice graph. I haven't looked at handbook and FAQ documents for a
while, but I'll think it fits well into appropriate section. Any
-doc takers please?
-- 

Vallo Kallaste
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Lucent Orinoco Gold PCCard?

[Darryl Okahata]

Nick Sayer [EMAIL PROTECTED] wrote:

 Christopher Masto wrote:

  I am told that the Apple "AirPort Base Station", which is $399, works
  well and can be configured with the Java-based thing in the ports
  collection.  I am further told that the Lucent/ORiNOCO RG-1000 base
  station is virtually identical, although more expensive and somehow
  inferior, although I don't understand the exact inferiorities.
 
 It is inferior in two ways:

 Also, there are other alternatives to the AirPort (which is closer
to $299 than $399).  One is the Buffalo AirStation (around $280-$340,
depending on options -- see
http://www.melcoinc.com/english/network/air.html).  Other, cheaper,
access points have been mentioned here in earlier messages.  The
AirStation is sold in the US by TechWorks (http://www.techworks.com)
among possibly others.

 I've got an AirStation, and it's not bad.  Like most access points,
it has only 40-bit encryption, though.  It's configurable via a web
browser, using password-protected web pages.  However, because of this,
the configuration needs to be done via a secure, wired lan, as the web
passwords are transmitted in plain text.

-- 
Darryl Okahata
[EMAIL PROTECTED]

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Lucent Orinoco Gold PCCard?

[Darryl Okahata]

I wrote:

  Also, there are other alternatives to the AirPort (which is closer
 to $299 than $399).  One is the Buffalo AirStation (around $280-$340,

 I forgot to mention that the AirStation supposedly supports roaming 
between access points.  I haven't tried it, though.

-- 
Darryl Okahata
[EMAIL PROTECTED]

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: write(2) returns error saying read only filesystem when trying to write to a partition

[Bruce Evans]

On Fri, 8 Dec 2000, Matthew Thyer wrote:

 Mike Smith wrote:
   The program works on Compaq True64 UNIX v 4.0d
   It also works on Solaris 7 (only tested sparc).
  
   So it seems FreeBSD is broken here.
  
  FreeBSD just behaves differently.  If you want to write to the whole
  disk, open the whole-disk device, not the 'c' partition.
 
 Thanks Mike, /dev/da18 works fine for me although I notice that
 /dev/da18s1 does not.  There seems to be some inconcistencies
 in this area.
 
 Please tell me (and for the benefit of the list) as to why
 I cant use /dev/da18s1c ?

Because metadata (i.e,. label) write protection actually works on
/dev/da18s1c.

It is supposed to be possible to turn off write protection using the
DIOCWLABEL ioctl, but IIRC this only works if the data written over
the label area is a valid label (if there is already a label there,
as there must be for /dev/da18s1c to exist), so labels can't be
cleared by writing zeros to them (zeros don't give a valid label).

Labels can be cleared by zeroing them using the whole-disk device.
All subdevices of the device should be closed before starting, and none
except the whole-disk device should be opened before finishing, to
ensure that the old in-core copy of the label isn't used.

Someone broke dd(1) to always turn off write protection of labels, to
hack around a bug in the alpha disklabel code (someone broke the label
for the whole-disk device by making it a real label to hack around a
non-understood bug that is said to break sysinstall; real labels are
write protected, so the whole-disk device can't be used to bypass the
write protection).  Since overwriting labels doesn't work quite right
even when write protection is turned off, I'm not sure how the breakage
helps.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sys/dev/acpica acpi.c acpi_button.c acpi_ec.c acpi_isa.c acpi_lid.c acpi_pcib.c acpi_processor.c acpi_resource.c acpi_thermal.c acpi_timer.c acpiio.h acpivar.h

[Takanori Watanabe]

In message [EMAIL PROTECTED], Mike Smith $B$5$s$$(B
$B$o$/(B:
msmith  2000/12/08 01:16:21 PST

  Modified files:
sys/dev/acpica   acpi.c acpi_button.c acpi_ec.c acpi_isa.c 
 acpi_lid.c acpi_pcib.c acpi_processor.c 
 acpi_resource.c acpi_thermal.c 
 acpi_timer.c acpiio.h acpivar.h 
  Log:
   - Convert a lot of homebrew debugging output to use the ACPI CA debugging
 infrastructure.  It's not perfect, but it's a lot better than what
 we've been using so far.  The following rules apply to this:
  o BSD component names should be capitalised
  o Layer names should be taken from the non-CA set for now.  We
may elect to add some new BSD-specific layers later.

I don't think this "infrastructure" is useful. As far as I experienced,
the message is too noisy or too few infomation.

$BEOJUB:5*(B
$B?@8MBg3XBg3X1!+A32J3X85f2J(BD3$BpJs%a%G%#%"2J3X@l96(B
a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html"
Public Key/a
Key fingerprint =  2C 51 E2 78 2C E1 C5 2D  0F F1 20 A3 11 3A 62 2A 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Lucent Orinoco Gold PCCard?

[Andrew Gordon]

On Fri, 8 Dec 2000, Darryl Okahata wrote:

 I wrote:
 
   Also, there are other alternatives to the AirPort (which is closer
  to $299 than $399).  One is the Buffalo AirStation (around $280-$340,
 
  I forgot to mention that the AirStation supposedly supports roaming 
 between access points.  I haven't tried it, though.

Almost all APs support roaming, because they'd have to go out of their way
to prevent it: roaming is controlled from the client end.

Most clients seem to just implement the "wait until contact is lost with
the current AP then scan for a new one" scheme, though cleverer approaches
are possible.

Roaming between AirPort and AirStation APs certainly works.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Bootstrapping issues with groff(1)

[Ruslan Ermilov]

Hi!

I have recently upgraded groff(1) to the latest released version.

Groff(1) provides two kind of data files: device files (ones that
installed into /usr/share/groff_font), and macro package files
(ones that installed into /usr/share/tmac).  New groff(1) versions
are likely to supply new files of both types.

The typical world build uses groff(1) to build documentation
(which is later installed into /usr/share/doc).

The attached patches (p4 and p5) try to solve this bootstrapping
problem with groff(1).  I have lightly tested this on my -stable
box, and would appreciate a feedback on them.

The p5 patch is for -current, and p4 is for -stable.

PS
There is still at least one issue not resolved with this patch.
One can specify MANBUILDCAT=YES (does anyone have this?) to ask
the system to build preformatted manual pages (see bsd.man.mk
for details).  This will use mdoc(7) and man(7) macro packages
from /usr/share/tmac while they should be taken from
${WORLDTMP}/usr/share/tmac.
/PS


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.179
diff -u -r1.179 Makefile.inc1
--- Makefile.inc1   2000/12/03 20:29:31 1.179
+++ Makefile.inc1   2000/12/08 16:02:05
@@ -168,6 +168,7 @@
COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin \
LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib \
OBJFORMAT_PATH=${WORLDTMP}/usr/libexec \
+   TRFLAGS="-F${WORLDTMP}/usr/share/groff_font 
+-M${WORLDTMP}/usr/share/tmac" \
PERL5LIB=${WORLDTMP}/usr/libdata/perl/5.6.0
 
 # bootstrap-tool stage
@@ -200,16 +201,6 @@
PATH=${STRICTTMPPATH}:${INSTALLTMP}
 IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1
 
-USRDIRS=   usr/bin usr/lib/compat/aout usr/games usr/libdata/ldscripts \
-   usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc
-
-.if ${MACHINE_ARCH} == "i386"  ${MACHINE} == "pc98"
-USRDIRS+=  usr/libexec/aout
-.endif
-
-INCDIRS=   arpa g++/std objc protocols readline rpc rpcsvc openssl \
-   security ss
-
 #
 # buildworld
 #
@@ -224,7 +215,7 @@
 .if !defined(NOCLEAN)
rm -rf ${WORLDTMP}
 .else
-   for dir in bin games include lib sbin; do \
+   for dir in bin games include lib sbin share; do \
rm -rf ${WORLDTMP}/usr/$$dir; \
done
rm -f ${WORLDTMP}/sys
@@ -232,12 +223,7 @@
# This is beyond dirty...
rm -f ${OBJTREE}${.CURDIR}/gnu/usr.bin/cc/cc_tools/.depend
 .endif
-.for _dir in ${USRDIRS}
-   mkdir -p ${WORLDTMP}/${_dir}
-.endfor
-.for _dir in ${INCDIRS}
-   mkdir -p ${WORLDTMP}/usr/include/${_dir}
-.endfor
+   cd ${.CURDIR}; ${BMAKE} hierarchy
ln -sf ${.CURDIR}/sys ${WORLDTMP}/sys
@echo
@echo "--"
@@ -528,7 +514,7 @@
 
 bootstrap-tools:
 .for _tool in ${_strfile} usr.bin/yacc usr.bin/colldef usr.sbin/config \
-gnu/usr.bin/gperf gnu/usr.bin/texinfo
+gnu/usr.bin/gperf gnu/usr.bin/groff gnu/usr.bin/texinfo
cd ${.CURDIR}/${_tool}; \
${MAKE} obj; \
${MAKE} depend; \


Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.141.2.18
diff -u -r1.141.2.18 Makefile.inc1
--- Makefile.inc1   2000/12/01 21:58:09 1.141.2.18
+++ Makefile.inc1   2000/12/08 16:02:16
@@ -168,6 +168,7 @@
COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin \
LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib \
OBJFORMAT_PATH=${WORLDTMP}/usr/libexec \
+   TRFLAGS="-F${WORLDTMP}/usr/share/groff_font 
+-M${WORLDTMP}/usr/share/tmac" \
PERL5LIB=${WORLDTMP}/usr/libdata/perl/5.00503
 
 # bootstrap-tool stage
@@ -198,16 +199,6 @@
PATH=${STRICTTMPPATH}:${INSTALLTMP}
 IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1
 
-USRDIRS=   usr/bin usr/lib/compat/aout usr/games usr/libdata/ldscripts \
-   usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc
-
-.if ${MACHINE_ARCH} == "i386"  ${MACHINE} == "pc98"
-USRDIRS+=  usr/libexec/aout
-.endif
-
-INCDIRS=   arpa g++/std objc protocols readline rpc rpcsvc openssl \
-   security ss
-
 #
 # buildworld
 #
@@ -222,7 +213,7 @@
 .if !defined(NOCLEAN)
rm -rf ${WORLDTMP}
 .else
-   for dir in bin games include lib sbin; do \
+   for dir in bin games include lib sbin share; do \
rm -rf ${WORLDTMP}/usr/$$dir; \
done

$B:#Lk$O$3$A$i$G(B

[Delivery Boy]

$B$$$D$b$N7G<(HD!&=P2q$$!&%a!<%k%U%l%s%I%5%$%H$r$4MxMQBW$-(B
$BM-$jFq$&$4$6$$$^$9!#(B

$BK\F|$O?7$7$$%5%$%H$N$40FFb$r$5$;$FBW$-$^$9!#(B

http://homepage2.nifty.com/degedock/mori/


$B$b$7!"$4ITMW$G$7$?$i:o=|$7$F2<$5$$!#(B
$B:#8e!"$3$N$40FFb%a!<%k$4ITMW$N>l9g$O!"(B
$B$*!&$446A[$J$I!"$41sN8$J$/$3$A$i$^$G(B
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: possibly related data point - (was) Re: Current Broken!

[John Baldwin]

On 08-Dec-00 [EMAIL PROTECTED] wrote:
 
 John,
 
 I'm not a constraints expert either, but I noticed that when I try to
 build a kernel WITHOUT any optimization, I get a failure in
 
 /usr/src/sys/i386/atomic.h .

Compiling a kernel with anything but -O for optimization is not supported.  gcc
has produced buggy code for the -O0 case in the past.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Matt Dillon]

:I'm trying to write  some experimental mutex operations similar to those
:in -current, but to do differnt things (e.g. a read/write lock)
:however, I am having some problems with the __asm  stuff.
:
:What I want to do is to define some operations that will
:assemble down to:
:   pushfl
:   cli
:   [stuff]
:   popfl
:
:I can generate the code, but it seems to me that there should be 
:a way of telling gcc that you have just pushed an item onto the stack, 
:so that if you were to have some C code between the push and po 
:(of the flags reg) the compiler has a correct idea of where the 
:SP is. I can imagine that it doesn't matter so it may be that there 
:is no constaint for that purpose (I read the gcc asm info pages)
:but I wanted to make sure that that is the case because if it does turn
:out to be important, it may manifest itself as a wierd bug sometime 
:in 2002.
:
:The current pushfl code in the kernel has the following:
:__asm __volatile("pushfl; popl %0" : "=r" (ef));
:which has no long term effect on the stack pointer so I cannot 
:use it as a guide.
:
:-- 
:  __--_|\  Julian Elischer

I think all you can do is move the addresses and data used
by 'stuff' into registers prior to the push, then manipulate
the registers between the push and the pop.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

__asm help..

[Julian Elischer]

I'm trying to write  some experimental mutex operations similar to those
in -current, but to do differnt things (e.g. a read/write lock)
however, I am having some problems with the __asm  stuff.

What I want to do is to define some operations that will
assemble down to:
pushfl
cli
[stuff]
popfl

I can generate the code, but it seems to me that there should be 
a way of telling gcc that you have just pushed an item onto the stack, 
so that if you were to have some C code between the push and po 
(of the flags reg) the compiler has a correct idea of where the 
SP is. I can imagine that it doesn't matter so it may be that there 
is no constaint for that purpose (I read the gcc asm info pages)
but I wanted to make sure that that is the case because if it does turn
out to be important, it may manifest itself as a wierd bug sometime 
in 2002.

The current pushfl code in the kernel has the following:
__asm __volatile("pushfl; popl %0" : "=r" (ef));
which has no long term effect on the stack pointer so I cannot 
use it as a guide.

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Budapest
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[Rogier R. Mulhuijzen]

   Stripe'd file systems (or concat ones) ... what growfs allows is someone
   to add an n+1 drive to their RAID/Stripe and increase the size of the 
 file
 
  No, vinum can do this alone.
 
  But you couldn't grow the _fs_ after that, so there was no use for
  this vinum feature.

Okay, that is what I said ... "add an n+1 drive to ... and increase the
size of the file system" ...

I still don't see why growfs wouldn't work on a non-vinum volume. It's just 
a manipulation of the FS, not of the underlying device. But let's leave 
this for the makers of growfs to answer shall we =)

And yes I know about Vinum, and I know what it can do. =)

 DocWilco



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: possibly related data point - (was) Re: Current Broken!

[atrens]

I hit on it by accident (I normally compile with -O). That said, your
claim that gcc with no optimization generates incorrect code is
kind of counter-intuitive, wouldn't you say ?

I think you missed my point, I was just illustrating that optimizer seems
to affect (in my case apparently negate) the processing of constraints.

What you take from that is up to you - I was just trying to be helpful :)

Cheers,

A.

+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own,  not those of any employer. |
   --+
 Berkeley had what we called "copycenter", which is "take it down
 to the copy center and make as many copies as you want".
 -- Kirk McKusick
+----+






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: __asm help..

[John Baldwin]

On 08-Dec-00 Julian Elischer wrote:
 I'm trying to write  some experimental mutex operations similar to those
 in -current, but to do differnt things (e.g. a read/write lock)
 however, I am having some problems with the __asm  stuff.
 
 What I want to do is to define some operations that will
 assemble down to:
   pushfl
   cli
   [stuff]
   popfl
 
 I can generate the code, but it seems to me that there should be 
 a way of telling gcc that you have just pushed an item onto the stack, 
 so that if you were to have some C code between the push and po 
 (of the flags reg) the compiler has a correct idea of where the 
 SP is. I can imagine that it doesn't matter so it may be that there 
 is no constaint for that purpose (I read the gcc asm info pages)
 but I wanted to make sure that that is the case because if it does turn
 out to be important, it may manifest itself as a wierd bug sometime 
 in 2002.

As long as gcc uses %ebp to address local variables and functoin parameters
rather than %esp you should be fine.  %esp will be preserved, but if %esp is
for some odd reason used to address a variable during the C code, you are hosed.
Just use foo = save_intr(); disable_intr(); .. restore_intr() for now.  If you
want to save the 2 instructions so badly, then you should probably be writing
the whole chunk in assembly.  Getting it correct first and optimizing later is
more sane than getting correctness and optimization at the same time and not
knowing which one your bugs are coming from.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SkyStar driver

[Sergey Vishnevetskiy]

Hello!

There were rumors about such driver in CURRENT.
Is it true?

Please keep CC, cause I'm not subscribed to these lists.

Thanks in advance for an answer.

Sergiy.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Current Locking up... Re: possibly related data point - (was) Re: Current Broken!

[Steven E. Ames]

-CURRENT as of yesterday was still causing my system to lock (with
'make -j8 world'). Lock=no possibility of debugger.

I have two of these systems and they behave identically. If someone with
lots more debugging experience would benefit from borrowing one of the
machines I'd happily send it to you. I'd really like to be use SMP
stabily.

-Steve

- Original Message -
From: "John Baldwin" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; "Andrew
[SKY:ET95:EXCH]" [EMAIL PROTECTED]
Sent: Friday, December 08, 2000 1:49 PM
Subject: RE: possibly related data point - (was) Re: Current Broken!



 On 08-Dec-00 [EMAIL PROTECTED] wrote:
 
  I hit on it by accident (I normally compile with -O). That said,
your
  claim that gcc with no optimization generates incorrect code is
  kind of counter-intuitive, wouldn't you say ?

 I've seen it do weird things with -O0 (mostly with C++). :)  It's just
another
 program.  Nothing is keeping it from having bugs. :)

  I think you missed my point, I was just illustrating that optimizer
seems
  to affect (in my case apparently negate) the processing of
constraints.

 I am back now to thinking that it is a gcc bug in the -O case now as
well.  The
 constraings I removed were in fact valid, so I've put them back in,
but just
 disabled the macros for now until gcc is fixed.

  What you take from that is up to you - I was just trying to be
helpful :)

 Sorry if I came across as if I was biting your head off, that was not
the
 intent.

  Cheers,
 
  A.

 --

 John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
 PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
 "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: possibly related data point - (was) Re: Current Broken!

[John Baldwin]

On 08-Dec-00 [EMAIL PROTECTED] wrote:
 
 I hit on it by accident (I normally compile with -O). That said, your
 claim that gcc with no optimization generates incorrect code is
 kind of counter-intuitive, wouldn't you say ?

I've seen it do weird things with -O0 (mostly with C++). :)  It's just another
program.  Nothing is keeping it from having bugs. :)

 I think you missed my point, I was just illustrating that optimizer seems
 to affect (in my case apparently negate) the processing of constraints.

I am back now to thinking that it is a gcc bug in the -O case now as well.  The
constraings I removed were in fact valid, so I've put them back in, but just
disabled the macros for now until gcc is fixed.

 What you take from that is up to you - I was just trying to be helpful :)

Sorry if I came across as if I was biting your head off, that was not the
intent.

 Cheers,
 
 A.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Mike Smith]

 I'm trying to write  some experimental mutex operations similar to those
 in -current, but to do differnt things (e.g. a read/write lock)
 however, I am having some problems with the __asm  stuff.

Julian; Wheels were invented around 1500BC.  We don't need to go through 
all that again.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[Goblin]

I can certainly see where "cat /dev/1GBdevice  /dev/10GBdevice"
situations would make a growfs useful w/out vinum...

And, removing a failing disk from the end of a  a vinum concat volume
would make shrinkfs really nice.

On 12/08, Rogier R. Mulhuijzen rearranged the electrons to read:
 
Stripe'd file systems (or concat ones) ... what growfs allows is someone
to add an n+1 drive to their RAID/Stripe and increase the size of the 
  file
  
   No, vinum can do this alone.
  
   But you couldn't grow the _fs_ after that, so there was no use for
   this vinum feature.
 
 Okay, that is what I said ... "add an n+1 drive to ... and increase the
 size of the file system" ...
 
 I still don't see why growfs wouldn't work on a non-vinum volume. It's just 
 a manipulation of the FS, not of the underlying device. But let's leave 
 this for the makers of growfs to answer shall we =)
 
 And yes I know about Vinum, and I know what it can do. =)
 
  DocWilco
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 Your eyes are weary from staring at the CRT.  You feel sleepy.  Notice how
 restful it is to watch the cursor blink.  Close your eyes.  The opinions
 stated above are yours.  You cannot imagine why you ever felt otherwise.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sys/dev/acpica acpi.c acpi_button.c acpi_ec.c acpi_isa.c acpi_lid.c acpi_pcib.c acpi_processor.c acpi_resource.c acpi_thermal.c acpi_timer.c acpiio.h acpivar.h

[Mike Smith]

   Modified files:
 sys/dev/acpica   acpi.c acpi_button.c acpi_ec.c acpi_isa.c 
  acpi_lid.c acpi_pcib.c acpi_processor.c 
  acpi_resource.c acpi_thermal.c 
  acpi_timer.c acpiio.h acpivar.h 
   Log:
- Convert a lot of homebrew debugging output to use the ACPI CA debugging
  infrastructure.  It's not perfect, but it's a lot better than what
  we've been using so far.  The following rules apply to this:
   o BSD component names should be capitalised
   o Layer names should be taken from the non-CA set for now.  We
 may elect to add some new BSD-specific layers later.
 
 I don't think this "infrastructure" is useful. As far as I experienced,
 the message is too noisy or too few infomation.

I've been very slowly coming around to like it.  It's important to pick 
your debugging options carefully, and to be prepared to wade through 
thousands of lines of output (a serial console is mandatory).

However, I've been careful to keep the BSD parts separate from the ACPI 
CA parts, so you can just turn on the BSD-related debugging without 
getting the eleven bazillion mutex operations, etc logged.

I also added the ! support *specifically* so that I can turn lots of 
stuff on, and then turn the really noisy and useless stuff off again.

But most importantly, I didn't have anything better up my sleeve.  If 
you've got a better integrated debugging infrastructure, I'm all ears. 8)

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: RE: __asm help..

[Matt Dillon]

:As long as gcc uses %ebp to address local variables and functoin parameters
:rather than %esp you should be fine.  %esp will be preserved, but if %esp is
:for some odd reason used to address a variable during the C code, you are hosed.

I strongly recommend against making assumptions about GCC's use of %ebp vs
%esp... not if you want the __asm code to survive the GCC optimizer!

:Just use foo = save_intr(); disable_intr(); .. restore_intr() for now.  If you
:want to save the 2 instructions so badly, then you should probably be writing
:the whole chunk in assembly.  Getting it correct first and optimizing later is
:more sane than getting correctness and optimization at the same time and not
:knowing which one your bugs are coming from.
:
:John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/

Yah, gotta agree there.  The only thing that matters, Julian, are memory
accesses.  The number of instructions you use is irrelevant.

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Julian Elischer]

Mike Smith wrote:
 
  I'm trying to write  some experimental mutex operations similar to those
  in -current, but to do differnt things (e.g. a read/write lock)
  however, I am having some problems with the __asm  stuff.
 
 Julian; Wheels were invented around 1500BC.  We don't need to go through
 all that again.

I'm doing it not for inclusion but for education.
And in any case they may have been invented already but we don't HAVE 
suitable read/write locks in FreeBSD.. only the 'lock mangler'
which is certainly not going to su[[ly me with locks for netgraph.


 
 --
 ... every activity meets with opposition, everyone who acts has his
 rivals and unfortunately opponents also.  But not because people want
 to be opponents, rather because the tasks and relationships force
 people to take different points of view.  [Dr. Fritz Todt]
V I C T O R Y   N O T   V E N G E A N C E

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Budapest
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: write(2) returns error saying read only filesystem when tryingto write to a partition

[Brandon D. Valentine]

On Sat, 9 Dec 2000, Daniel C. Sobral wrote:

No, and no. You misunderstand the problem.

A disk on IBM PC compatible computers has the following format:

| Partition table | Data|
  | Slice 1   | Slice 2 | Slice 3 | Slice 4 |
  | Disklabel | Data  |
  |   c   |
  |a|b|f|g|

That is really an excellent diagram.  That should be in an FAQ
somewhere.  Doc committers?

-- 
Brandon D. Valentine [EMAIL PROTECTED]
"Few things are harder to put up with than the annoyance of a
good example."  --  Mark Twain, Pudd'nhead Wilson



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: write(2) returns error saying read only filesystem when trying to write to a partition

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], "Br
andon D. Valentine" writes:
On Sat, 9 Dec 2000, Daniel C. Sobral wrote:

No, and no. You misunderstand the problem.

A disk on IBM PC compatible computers has the following format:

| Partition table | Data|
  | Slice 1   | Slice 2 | Slice 3 | Slice 4 |
  | Disklabel | Data  |
  |   c   |
  |a|b|f|g|

That is really an excellent diagram.  That should be in an FAQ
somewhere.  Doc committers?

Except it is not actually correct.  The BSD disklabel is usually
inside the 'a' partition and certainly inside the 'c'

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ffs_valloc: dup alloc panics with stable/current

[Wilko Bulte]

On Fri, Dec 08, 2000 at 02:45:00AM -0800, Mike Smith wrote:
  We got old Mylex DAC960PD-Ultra-raid-adapter and have tried to use it
  with FreeBSD 4.2-stable and 5.0-current. Adapter is configured with
  three luns 5+5*9G, 8+8*9G (raid5) and 1+1*2G (mirrored boot disk).
  All 9G disks are quite old Seagate Barracuda 9 disks ST19171W.  System
  is working quite well but under heavier load we start to get scsi
  errors from luns.
  sense = 4 asc = 3 asq = 0
  sense = 1 asc = 3 asq = 0
  sense = 3 asc = 12 asq = 0
  sense = 3 asc = 11 asq = 0
 
 Your disks just aren't up to this sort of workload.
 
  This is not so bad but 5-30 minutes after this command system will
  always panic.
  cd /uu ; dump 0buf 126 - /w | restore xbf 126 -
  
  mode = 0100644, inum = 720391, fs = /uu
  panic: ffs_valloc: dup alloc
 
 This looks like memory or PCI data corruption.  You don't say how you're 
 generating this load, or what the motherboard is, but I suspect that you 
 may have hardware issues here.

PCI bus clock is at the nominal speed? Can be a source of interesting
effects.

-- 
Wilko Bulte Arnhem, the Netherlands
[EMAIL PROTECTED]   http://www.freebsd.org  http://www.nlfug.nl



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[Thomas]

Hi,

In an attempt to resolve that discussion:
   No, vinum can do this alone.
   But you couldn't grow the _fs_ after that, so there was no use for
   this vinum feature.
Exactly that was the motivation for writing that utility

 Okay, that is what I said ... "add an n+1 drive to ... and increase the
 size of the file system" ...
... which means basically the same :-)

 I still don't see why growfs wouldn't work on a non-vinum volume. It's just 
 a manipulation of the FS, not of the underlying device. But let's leave 
 this for the makers of growfs to answer shall we =)
again correct, technically it is possible to use growfs on ANY object which
has a ufs filesystem structure:
vinum volume, a partition on a disk, ccd device, even a flat file
provided, that there is some space on the end(!) of that medium which is
not yet taken by the ufs structures.

So you can use it either with hardware RAID controllers which allow for
non destructive extending of the size of existing volumes at the end(!).
As well you can use it for vinum volumes. Currently this is only possible for
mirrored plexes of any kind, or unmirrored concatenated plexes.
All other devices cant be changed without destroying the contents.
And you can just give some space in the partition table (disklabel) to an
existing partition (at its end) and let the filesystem grow within that bound.

A shrinkfs is NOT written. The design allows for writing it, but we currently
consider other features much more important, like
* growing a mounted filesystem
* handling file systems with active snapshots is in
* grow in a way that we are always safe to loose the power during the
  growing (softdep concept)
* handle byteorder correct on non intel platform (we don't have any alpha
hardware but think ufs on alpha is not ufs on intel)
* provide the current funktionality on FreeBSD-4 at least, maybe FreeBSD-3

Thomas


-- 
Th.-H.v.Kamptz
Die Netz-Werker GmbH


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ffs_valloc: dup alloc panics with stable/current

[Tomi Vainio - Sun Finland -]

Mike Smith writes:
   This is not so bad but 5-30 minutes after this command system will
   always panic.
   cd /uu ; dump 0buf 126 - /w | restore xbf 126 -
   
   mode = 0100644, inum = 720391, fs = /uu
   panic: ffs_valloc: dup alloc
  
  This looks like memory or PCI data corruption.  You don't say how you're 
  generating this load, or what the motherboard is, but I suspect that you 
  may have hardware issues here.
 
/w fs contains cvsupped FreeBSD source, objs and ports alltogether 1G
of data.  Load test is this simple "cd /uu ; dump 0buf 126 - /w |
restore xbf 126 -" between two partitions.

First motherboard we tried was Intel PPro 200Mhz (FX440 based I
think/Natoma?).  Second one is newer 633MHz Celeron system but I don't
know manufacturer.

  One question - I assume you're not seeing any read error diagnostics from 
  the Mylex driver (other than the disk errors?)
 
Sometimes we have got more those scsi errors before fs panic.

Wilko Bulte writes:
  
  PCI bus clock is at the nominal speed? Can be a source of interesting
  effects.
  
Both motherboards are used with standard settings and older Intel PPro
system don't support overclocking or other kludge stuff.

  Tomppa
-- 
SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland
Tomi Vainio (System Support Engineer) +358 9 52556300 hotline
email: [EMAIL PROTECTED]+358 9 52556252 fax


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[Mike Smith]

 So you can use it either with hardware RAID controllers which allow for
 non destructive extending of the size of existing volumes at the end(!).

Cool.  We support the FlexRAID Virtual Sizing stuff on the AMI 
controllers already, and I bet that the Mylex MORE stuff would work too.

   * handle byteorder correct on non intel platform (we don't have any
 alpha hardware but think ufs on alpha is not ufs on intel)

Actually, I believe they're the same; as long as you have used
explicitly-sized types everywhere, you should be fine.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Problem With Man Formatting

[Thomas D. Dean]

Since a 12/6 cvsup and 'make world', I notice a problem with the
output of man.  The output consists of one block of justified text.
The headers, etc., are missing.

Have I missed something?

tomdean


# man man
formats  and  displays  the  on-line  manual pages.  This version
knows about the and environment variables, so you can  have  your
own  set(s) of personal man pages and choose whatever program you
like to display the formatted pages.  If  section  is  specified,
man only looks in that section of the manual.  You may also spec-
ify the order to search the sections for entries and  which  pre-
processors to run on the source files via command line options or
...
sor  before  nroff.   If  is  set, its value is used to determine
which manual sections to search.  If is set, its value is used as
the  name  of  the  program  to  use to display the man page.  By
default, is used.  Normally, to  look  at  the  relevant  manpage
information for getopt, one would use: However, when referring to
a specific section of the manual, such  as  one  would  use:  The
option only works if a troff-like program is installed.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Problem With Man Formatting

[Brandon D. Valentine]

On Fri, 8 Dec 2000, Thomas D. Dean wrote:

Since a 12/6 cvsup and 'make world', I notice a problem with the
output of man.  The output consists of one block of justified text.
The headers, etc., are missing.

Could this be a result of the recent groff upgrade?  

-- 
Brandon D. Valentine [EMAIL PROTECTED]
"Few things are harder to put up with than the annoyance of a
good example."  --  Mark Twain, Pudd'nhead Wilson



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Problem With Man Formatting

[Donald J . Maddox]

I don't think so...  I am -current as of yesterday and my manpages
are displaying just fine, headers and all.

On Fri, Dec 08, 2000 at 06:05:01PM -0500, Brandon D. Valentine wrote:
 On Fri, 8 Dec 2000, Thomas D. Dean wrote:
 
 Since a 12/6 cvsup and 'make world', I notice a problem with the
 output of man.  The output consists of one block of justified text.
 The headers, etc., are missing.
 
 Could this be a result of the recent groff upgrade?  


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Julian Elischer]

Matt Dillon wrote:
 
 :As long as gcc uses %ebp to address local variables and functoin parameters
 :rather than %esp you should be fine.  %esp will be preserved, but if %esp is
 :for some odd reason used to address a variable during the C code, you are hosed.
 
 I strongly recommend against making assumptions about GCC's use of %ebp vs
 %esp... not if you want the __asm code to survive the GCC optimizer!
 
 :Just use foo = save_intr(); disable_intr(); .. restore_intr() for now.  If you
 :want to save the 2 instructions so badly, then you should probably be writing
 :the whole chunk in assembly.  Getting it correct first and optimizing later is
 :more sane than getting correctness and optimization at the same time and not
 :knowing which one your bugs are coming from.
 :
 :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
 
 Yah, gotta agree there.  The only thing that matters, Julian, are memory
 accesses.  The number of instructions you use is irrelevant.

foo = save_intr(); disable_intr(); .. restore_intr()
has 4 extra memory accesses.

pushf (the only way to save interrupt state) save to stack.
save_intr() reads it back off the stack 
(ok a cache hit I suppose)
and writes it to a memory location specied as an argument.
(Not a cache hit..)(though maybe defered)
After some processing, 
restore_intr() then reads it from the nominated address
(probably a cache hit) 
and puts it on the stack.
(not a cache hit). (though maybe defered)
it is then read off the stack by popf 
(a cache hit).

Since all I WANT to do is 
pushf
disable intr
fiddle
popf (chache hit)

I am annoyed by the fact that I have all those extra bus cycles going on.
I can live with it for development but it still annoys me.

 
 -Matt
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Budapest
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ffs_valloc: dup alloc panics with stable/current

[Mike Smith]

This is not so bad but 5-30 minutes after this command system will
always panic.
cd /uu ; dump 0buf 126 - /w | restore xbf 126 -

mode = 0100644, inum = 720391, fs = /uu
panic: ffs_valloc: dup alloc
   
   This looks like memory or PCI data corruption.  You don't say how you're 
   generating this load, or what the motherboard is, but I suspect that you 
   may have hardware issues here.
  
 /w fs contains cvsupped FreeBSD source, objs and ports alltogether 1G
 of data.  Load test is this simple "cd /uu ; dump 0buf 126 - /w |
 restore xbf 126 -" between two partitions.

Ok, so there's no major traffic anywhere else.  That's irritating.

 First motherboard we tried was Intel PPro 200Mhz (FX440 based I
 think/Natoma?).  Second one is newer 633MHz Celeron system but I don't
 know manufacturer.

But the same symptoms?  Have you tried replacing the controller (or even 
just the onboard RAM)?  

I don't currently have one of these old controllers that I can use in a 
PC; the only one I do have is working fine under heavy load in an Alpha.

   One question - I assume you're not seeing any read error diagnostics from 
   the Mylex driver (other than the disk errors?)
  
 Sometimes we have got more those scsi errors before fs panic.

But no other errors?  In particular, nothing that looks like a "real" I/O 
error?

The problem that you're seeing looks like filesystem metadata corruption. 
If it's not memory/system related, it has to be in the datapath from the 
disks through the driver.  I'm not aware of any bugs in the driver that 
could cause this. 8(

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Mike Smith]

 
 Since all I WANT to do is 
 pushf
 disable intr
 fiddle
 popf (chache hit)
 
 I am annoyed by the fact that I have all those extra bus cycles going on.
 I can live with it for development but it still annoys me.

You haven't yet explained how you plan to disable interrupts on the other 
CPUs...

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Matt Dillon]

:
: 
: Since all I WANT to do is 
: pushf
: disable intr
: fiddle
: popf (chache hit)
: 
: I am annoyed by the fact that I have all those extra bus cycles going on.
: I can live with it for development but it still annoys me.
:
:You haven't yet explained how you plan to disable interrupts on the other 
:CPUs...
:
:-- 
:... every activity meets with opposition, everyone who acts has his

Julian, I would recommend using the cmpxchgl instruction to implement
atomic operations.  Look at /usr/src/sys/i386/i386/mplock.s for
an example.  You will be in much better shape if you can avoid
cli/sti (as Mike points out, it doesn't work across cpu's).

mplock.s already has basic MP-compatible lock recursion and should
provide a ready example on how you need to do the locking.

There is a serious issue you need to consider when implementing
an SMP-capable lock, and that is cpu-cpu synchronization.

In order to synchronize an operation across multiple cpu's on IA32 you
have to use the 'lock;' instruction prefix.  Typically, the cmpxchgl
must be locked.  However, you only need to lock it when there is
possible contention.. when you are aquiring the lock.  You do not need
to lock it when you are releasing the lock.

If your assembly gets too complex, just make the assembly a subroutine
call.  Believe me, subroutine overhead is *nothing* compared to bus
locking overhead.  For that matter, the cli/sti alone will have more
overhead then a subroutine call.  Just write it in assembly and forget
about trying to use the C __asm() directive.  You'll be happier.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ffs_valloc: dup alloc panics with stable/current

[Tomi Vainio - Sun Finland -]

Mike Smith writes:
   First motherboard we tried was Intel PPro 200Mhz (FX440 based I
   think/Natoma?).  Second one is newer 633MHz Celeron system but I don't
   know manufacturer.
  
  But the same symptoms?  Have you tried replacing the controller (or even 
  just the onboard RAM)?  
 
All but raid controller was replaced (RAM, video, net).  We also have
another raid controller and we are going to test it also.  Also tried
with and without soft updates and async io.

  
  But no other errors?  In particular, nothing that looks like a "real" I/O 
  error?
 
This we have to double check because normally we don't stare at the
console when we test this system.

  The problem that you're seeing looks like filesystem metadata corruption. 
  If it's not memory/system related, it has to be in the datapath from the 
  disks through the driver.  I'm not aware of any bugs in the driver that 
  could cause this. 8(
  
I think old PPro system even supported ECC memory.  We are getting out
ideas.  Maybe small 3 disk raid5 with little newer disks than we use
now.

  Tomppa
-- 
SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland
Tomi Vainio (System Support Engineer) +358 9 52556300 hotline
email: [EMAIL PROTECTED]+358 9 52556252 fax


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: __asm help..

[Matt Dillon]

:
:foo = save_intr(); disable_intr(); .. restore_intr()
:has 4 extra memory accesses.

UGh.  I put my foot in it.  Let me qualify my remark... memory
accesses that cause an L1 cache miss are a problem.  Memory accesses
to locations written to by other cpu's are a problem.   Memory accesses
that are L1 cached are NOT a problem.

Memory accesses to the first few words of the stack are almost guarenteed
to be in the L1 cache.  Just don't worry about it.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Bootstrapping issues with groff(1)

[Marcel Moolenaar]

Ruslan Ermilov wrote:
 
 The attached patches (p4 and p5) try to solve this bootstrapping
 problem with groff(1).  I have lightly tested this on my -stable
 box, and would appreciate a feedback on them.

Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make
hierarchy). There's no need to duplicate the complete hierarchy inthe
object tree. Also, mtree fiddles with ownership and mods, which is not
appropriate when building.

Which additional directories do you need?

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Bootstrapping issues with groff(1)

[Marcel Moolenaar]

Ruslan Ermilov wrote:
 
 The attached patches (p4 and p5) try to solve this bootstrapping
 problem with groff(1).

Sorry, I missed this statement before. What exactly are the
bootstrapping problems you're seeing?

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

problems configuring cardbus card

[David Syphers]

I'm running a FreeBSD 5-CURRENT snapshot from Dec. 5, and trying to 
configure an AmbiCom Cardbus ethernet card (a DEC Tulip base).  I've 
included cardbus, pccbb, miibus, and dc in my kernel, and enabled use of 
DHCP.  Since I haven't tracked -current since 4.x split off from it, I had 
a great deal of FM to R before I realized things like there's a file called 
/boot/device.hints that's very important.  Putting

hint.dc.0.at="isa"
hint.dc.0.port="0x300"
hint.dc.0.irq="10"

into /boot/device.hints made the "watchdog timeout" errors I had been 
getting on boot go away, but the card still didn't work.  Do I need to 
specify drq or maddr, and how would I determine if 0x300 is the right 
port?  This may be due to the fact that it looks like my graphics card and 
my ethernet card are both assigned IRQ 11 (see clip from dmesg below).  But 
I really have no idea how to use device.hints or even how to set up an 
ethernet card under FreeBSD (I know, I should have picked something other 
than cardbus on -current for my first experience), so any help would be 
appreciated.  Thanks!

[part of dmesg output]

pci0: NeoMagic MagicGraph 128XD SVGA controller at 2.0 irq 11
...
pccbb0: TI1131 PCI-CardBus Bridge at device 10.0 on pci0
pccbb0: PCI Memory allocated: 1802
pci_cfgintr_unique: hard-routed to irq 11
pci_cfgintr: 0:10 INTA routed to irq 11
cardbus0: Cardbus bus (newcard) on pccbb0
pccbb0: WARNING: cannot attach pccard bus.
pccbb1: TI1131 PCI-CardBus Bridge at device 10.1 on pci0
pccbb1: PCI Memory allocated: 18021000
pci_cfgintr_unique: hard-routed to irq 11
pci_cfgintr: 0:10 INTB routed to irq 11
cardbus1: Cardbus bus (newcard) on pccbb1
pccbb1: WARNING: cannot attach pccard bus.
...
pccbb0: card inserted: event=0x0009, state=3b20
pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
pccbb0: bad Vcc request. ctrl=0x0, status=0x3b20
pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
pccbb0: pccbb_power: CARD_VCC_3V and CARD_VPP_VCC [11]
pccbb0: bad Vcc request. ctrl=0x33, status=0x3b20
pccbb_power: CARD_VCC_3V and CARD_VPP_VCC [11]
TUPLE: LINKTARGET [3]: 43 49 53
Product version: 5.0
Product name: AmbiCom, Inc. | AMB8100 | Fast Ethernet CardBus PC Card | 1.00 |
Manufacturer ID: 13958100
Functions: Network Adaptor, Multi-Functioned
Function Extension: 0102
Function Extension: 0280969800
Function Extension: 0200e1f505
Function Extension: 0301
cardbus0: Opening BAR: type=IO, bar=10, len=0080
TUPLE: CONFIG_CB [7]: 03 01 00 00 00 00 ff
TUPLE: CFTABLE_ENTRY_CB [5]: 41 80 fb 00 ff
dc1: Intel 21143 10/100BaseTX port 0x3000-0x307f mem 
0x1804-0x1807,0x18022000-0x180223ff irq 11 at device 0.0 on cardbus0
dc1: Ethernet address: 00:80:00:80:00:80
miibus0: MII bus on dc1
dcphy0: Intel 21143 NWAY media interface on miibus0
dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pccbb1: removal of nonexistant card!

Note:  "dc1" used to be "dc0" before I put the lines in device.hints, but 
then I got "watchdog timeout" errors.


-David Syphers
  [EMAIL PROTECTED]
  http://www.seektruth.org/

Cannibalism is a small price to pay for popularity.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Progress report: Multilingual sysinstall for -current

[Tatsumi Hosokawa]

At Wed, 6 Dec 2000 18:18:50 -0600,
Michael C . Wu [EMAIL PROTECTED] wrote:
 
 Do you have Alpha boot floppies? Does kons25/big5con/korean compile
 on Alpha?  Would this fit on our ever growing mfsroot.flp and kern.flp?

I don't have alpha machine and my knowledge about Alpha architecture
is very limited.  But kons25 currently can't be compiled on Alpha
machine, and is disabled if ARCH==alpha (perhaps
release/localization/kon2 should be release/localization/i386/kon2).

 I recall seeing the release engineers struggling with fitting the kernel.

I have committed to move *.ko modules to mfsroot.flp (and I think it's
easily extended to the third floppy or CD-ROM) last month.  This is
not enabled on Alpha currently, but I think it can be also used on
alpha architecture.  I've not put it to alpha floppy only because I
dont have alpha testbed.

If you copy release/i386/drivers.conf to release/alpha and edit it to
fit the alpha architecture, drivers will be moved to mfsroot.flp
easily.

 It would be hard to make OpenBOOT and SRM do what we do in kons25.
 (Doable, but someone has to do it.)  I also know that Alpha
 SRM+vidcontrol+sc0 can only have one video mode, 80x25.  Can
 Mr. Yokota clarify this for me?

Does vidcontrol on Alpha support loadable font option?  Russian
support uses only this function and does not use graphics console.
Other European languages can be supported in this way.

hosokawa

--
Tatsumi Hosokawa
[EMAIL PROTECTED]
http://www.sm.rim.or.jp/~hosokawa/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Bootstrapping issues with groff(1)

[Matt Dillon]

:Ruslan Ermilov wrote:
: 
: The attached patches (p4 and p5) try to solve this bootstrapping
: problem with groff(1).
:
:Sorry, I missed this statement before. What exactly are the
:bootstrapping problems you're seeing?
:
:-- 
:Marcel Moolenaar
:  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
:  tel:  (408) 447-4222

I just ran into this problem trying to build the world:

-Matt

/usr/src/gnu/usr.bin/groff# make

=== libgroff
=== libdriver
=== libbib
=== addftinfo
=== afmtodit
=== doc
=== eqn
c++  -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 
-DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void 
-DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 
-DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 
-DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 
-DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 
-I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/include 
-I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn -I. -fno-for-scope   
-fno-rtti -fno-exceptions -c 
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:22: eqn_tab.h: No 
such file or directory
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:57: `OVER' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:58: `SMALLOVER' 
was not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:59: `SQRT' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:60: `SUB' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:61: `SUP' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:62: `LPILE' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:63: `RPILE' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:64: `CPILE' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:65: `PILE' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:66: `LEFT' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:67: `RIGHT' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:68: `TO' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:69: `FROM' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:70: `SIZE' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:71: `FONT' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:72: `ROMAN' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:73: `BOLD' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:74: `ITALIC' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:75: `FAT' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:76: `BAR' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:77: `UNDER' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:78: `ACCENT' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:79: `UACCENT' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:80: `ABOVE' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:81: `FWD' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:82: `BACK' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:83: `DOWN' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:84: `UP' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:85: `MATRIX' was 
not declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:86: `COL' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:87: `LCOL' was not 
declared in this scope
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:88: `RCOL' was not 
declared in this scope

Re: Bootstrapping issues with groff(1)

[Marcel Moolenaar]

Matt Dillon wrote:
 
 /usr/src/gnu/usr.bin/groff# make
 
 === libgroff
 === libdriver
 === libbib
 === addftinfo
 === afmtodit
 === doc
 === eqn
 c++  -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 
-DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 
-DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 
-DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 
-DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 
-DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 
-I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/include 
-I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn -I. -fno-for-scope   
-fno-rtti -fno-exceptions -c 
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc
 /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:22: eqn_tab.h: 
No such file or directory
 /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:57: `OVER' was 
not declared in this scope

Hmmm... I don't see this. This is more a build problem than a
bootstrapping problem.

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Bootstrapping issues with groff(1)

[assar]

Matt Dillon [EMAIL PROTECTED] writes:
 c++  -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 
-DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 
-DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 
-DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 
-DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 
-DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 
-I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/include 
-I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn -I. -fno-for-scope   
-fno-rtti -fno-exceptions -c 
/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc
 /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:22: eqn_tab.h: 
No such file or directory

I got rid of that with 'rm *' in
/usr/obj/usr/src/gnu/usr.bin/groff/eqn.

/assar


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: growfs(8) for FreeBSD

[Warner Losh]

In message [EMAIL PROTECTED] Goblin writes:
: I can certainly see where "cat /dev/1GBdevice  /dev/10GBdevice"
: situations would make a growfs useful w/out vinum...
: 
: And, removing a failing disk from the end of a  a vinum concat volume
: would make shrinkfs really nice.

I recently did that to "upgrade" my laptop hard disk.  Execpt I had to
also do dump/restore for the FreeBSD partitions.  growfs would have
been sweet.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

mfs size limits?

[Ken \\]

Is there a reason I cannot create a ramdisk larger than 507627 1kB blocks? I
create them using the syntax of  mount_mfs -s [any numer] -T minimum /dev/null
/ramdisk

It never errors, but never creates anything larger than the 507627 blocks. My
computer has 768MB of RAM.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Lucent Orinoco Gold PCCard?

[Wes Peters]

Christopher Masto wrote:
 
 On Wed, Dec 06, 2000 at 07:23:40PM -0800, Charlie Root wrote:
  There is definately a trend to lower prices.  I just found this.  A
  new intel Intel PRO/Wireless 2011 LAN access point and two pcmcia
  cards for $699.  The access point sounds interesting.  I personally
  would like to use it as a repeater and network bridge.
 
 I am told that the Apple "AirPort Base Station", which is $399, works
 well and can be configured with the Java-based thing in the ports
 collection.  I am further told that the Lucent/ORiNOCO RG-1000 base
 station is virtually identical, although more expensive and somehow
 inferior, although I don't understand the exact inferiorities.

They're the same thing in different cases, it's hard to see how one can
be superior in any way other than price.

 I am thinking of getting one of these things, despite my strong desire
 to avoid owning such a stupid looking piece of hardware.

Wait for the LinkSys; the dual antennas and price differential will be
worth the wait.  If the plethora of 802.11b equipment at BSDCon 2k is
any indication, interoperability should be pretty good.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Lucent Orinoco Gold PCCard?

[Warner Losh]

In message [EMAIL PROTECTED] Wes Peters writes:
: worth the wait.  If the plethora of 802.11b equipment at BSDCon 2k is
: any indication, interoperability should be pretty good.

YAMAMOTO shigeru-san's collection of wireless cards was proof of that
I think :-)

Warner
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Lucent Orinoco Gold PCCard?

[Christopher Masto]

On Fri, Dec 08, 2000 at 11:23:00PM -0700, Wes Peters wrote:
  I am told that the Apple "AirPort Base Station", which is $399, works
  well and can be configured with the Java-based thing in the ports
  collection.  I am further told that the Lucent/ORiNOCO RG-1000 base
  station is virtually identical, although more expensive and somehow
  inferior, although I don't understand the exact inferiorities.
 
 They're the same thing in different cases, it's hard to see how one can
 be superior in any way other than price.

"The most stupid thing was that you couldn't set its network name to 
anything other than its serial number because on bootup, it copies its
serial number over the first five bytes of the network name.  It also
can't be fully configured without the Windows software -- which is a
bit misleading for me to say because even with the Windows software,
you can only set it up to use the modem or provide NAT routing via
Ethernet, and not set it up to do bridging."

  I am thinking of getting one of these things, despite my strong desire
  to avoid owning such a stupid looking piece of hardware.
 
 Wait for the LinkSys; the dual antennas and price differential will be
 worth the wait.  If the plethora of 802.11b equipment at BSDCon 2k is
 any indication, interoperability should be pretty good.

But will I be able to configure the LinkSys?  That's my primary
concern.  I only have FreeBSD, so if it requires any proprietary
software at all, I can't use it.  Besides that, I'll only be using
this 10 feet away from the base. :-)
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Hangs during 'make world -j4' on recent current

[Greg Lehey]

On Saturday,  9 December 2000 at  8:07:34 +0200, John Hay wrote:
 For over a week now, I have been unable to complete a 'make world' on
 my -CURRENT box if I specify -j4.  The system hangs and is completely
 unresponsive.  This is a dual Celeron and an Abit BP6 motherboard.  As
 far as I can tell, nobody knows what's causing this, nor even how to
 attack the problem.  I'd like to solicit feedback about the extent of
 the problem, the possible causes, and how to debug it.

 I have been building releases with WORLD_FLAGS=-j4 successfully on my
 SMP box with a Dec 1 kernel for the past week. Yesterday I upgraded the
 kernel and with the new kernel did a make world -j4 which completed with
 no problems. And afterwards a make release with WORLD_FLAGS=-j4 also
 finished with no problems. So -current isn't totally broken. It might
 be timing related. My machine is an old dual 266MHz PII.

How many processors does your machine have?

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Hangs during 'make world -j4' on recent current

[John Hay]

  For over a week now, I have been unable to complete a 'make world' on
  my -CURRENT box if I specify -j4.  The system hangs and is completely
  unresponsive.  This is a dual Celeron and an Abit BP6 motherboard.  As
  far as I can tell, nobody knows what's causing this, nor even how to
  attack the problem.  I'd like to solicit feedback about the extent of
  the problem, the possible causes, and how to debug it.
 
  I have been building releases with WORLD_FLAGS=-j4 successfully on my
  SMP box with a Dec 1 kernel for the past week. Yesterday I upgraded the
  kernel and with the new kernel did a make world -j4 which completed with
  no problems. And afterwards a make release with WORLD_FLAGS=-j4 also
  finished with no problems. So -current isn't totally broken. It might
  be timing related. My machine is an old dual 266MHz PII.

 
 How many processors does your machine have?

2

John
-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Hangs during 'make world -j4' on recent current

[John Hay]

 For over a week now, I have been unable to complete a 'make world' on
 my -CURRENT box if I specify -j4.  The system hangs and is completely
 unresponsive.  This is a dual Celeron and an Abit BP6 motherboard.  As
 far as I can tell, nobody knows what's causing this, nor even how to
 attack the problem.  I'd like to solicit feedback about the extent of
 the problem, the possible causes, and how to debug it.

I have been building releases with WORLD_FLAGS=-j4 successfully on my
SMP box with a Dec 1 kernel for the past week. Yesterday I upgraded the
kernel and with the new kernel did a make world -j4 which completed with
no problems. And afterwards a make release with WORLD_FLAGS=-j4 also
finished with no problems. So -current isn't totally broken. It might
be timing related. My machine is an old dual 266MHz PII.

John
-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message