Re: Size of / partition?
This is almost an FAQ ! the answers are : 1/ use whatever (A)uto partitioning does when sysinstall-ing your OS 2/ allocate at least 100MB (or even 200MB) to your / (and /var ?) partitions TfH David Reid wrote: > > Just cvsup'd to stable and I've almost run out of room on /! How big should > I create it when I reinstall as I now don't have enough to do another build. > > bash-2.04$ df -k > Filesystem 1K-blocks UsedAvail Capacity Mounted on > /dev/ad0s2a 4958344564 105398%/ > /dev/ad0s2f 2646093 1830324 60408275%/usr > /dev/ad0s2e 19815 82121001845%/var > procfs 440 100%/proc > > david > -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Size of / partition?
Just cvsup'd to stable and I've almost run out of room on /! How big should I create it when I reinstall as I now don't have enough to do another build. bash-2.04$ df -k Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 4958344564 105398%/ /dev/ad0s2f 2646093 1830324 60408275%/usr /dev/ad0s2e 19815 82121001845%/var procfs 440 100%/proc david To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
Matthew Dillon wrote: > > :... > :> > > :> > There is also the "only supports 16MxN RAM" feature. > :> > :> Maybe I should toss in that I've had spontaneous reboots during heavy > :> IDE activity both on my desktop (VIA 82C686) and my laptop (Intel > :> 82443BX). And before that, random disk corruption during heavy SCSI > :> activity on my old desktop machine (seen with Tekram and Acer > :> 83C575-based host adapters and a borrowed Adaptec 2940). > : > :Guys guys, we are talking about known HW issues that causes known > :bad behavior, having a system that is flaky can have all kinds of > :reasons, I'd risk saying that genuine HW bugs like the 686B bug > :is one of the least likely problems... > : > :The most likely reasons are probably bad/subspec'd RAM, lousy PSU, > :bad/subspec'd cabeling, too many "performance features" enabled, > :generally crappy hardware (there are *tons* of that out there), > :bad/insufficient cooling, overclocking (even the motherboard makers > :overclock pr default nowadays to gain a litte over the competition), > : > :And do *not* forget bugs/bogons/mistakes in your favorite OS :) > : > :-Søren > > Ok, I have more information on Nils problem. First of all, Soren's > patch greatly reduced the rate of corruption. It took 25 loops of > Nils 'cp' test to generate the corruption. > > However, Soren's patch did not fiix the corruption. The same exact > corruption is occuring. In Nils case it is always the same exact > location in VM -- a certain bit (or byte) in the middle of the nfsnode > hash table. Hardware watch points indicate that the cpu is NOT modifying > this location, so I really doubt that it is a kernel bug. > > From this and from reading a number of other postings about VIA chipsets > I believe that Soren's original patch (which I guess is the official > VIA chipset patch) does not completely solve the VIA chipset's problems. > I also believe, from reading some of the reference material that has > been posted, that this corruption is not limited to the 686[A/B] but > may also occur in earlier VIA chipsets. > > What I would like to do is try forcing the DMA transfer rate to 66 MHz, > i.e. UDMA66 or UDMA33, to see if that solves the problem. Soren, > could you supply a patch that universally turns off higher UDMA modes? > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message I'm out of the loop on this one. I have been unable to reproduce the error for two weeks. I'll try backtracking to see if I can break it again. Summary: System VIA ATA33 (82C586) with UDMA66 drives. 4 disks RAID10 (vinum). Softupdates ON, DMA ON. 1 Upgraded BIOS. Side effect - factory default (safe) settings. 2 This revealed the memory addressing feature, so I swapped the 8chip X 1side SDRAM for an 8cX2s to match the other RAM present. This will wrap - sorry. http://www.azza.com.tw/ftp/specs/MTB-0109-01-00%20'Using%20more%20then%2064Mb%20memory%20with%20VIA%20MVP3%20chipset%20boards'.htm 3 The new BIOS doesn't like the ISA SCSI card and I get a panic on boot. BIOS settings which work put the SB128 on the same IRQ as the network card (rl). 4 Swapped the ISA SCSI card (adv) for a PCI (sym) one. [Only a CDRW on this] 5 Full build (Dec 11). I've thrashed the living daylights out of the drives without so much as a twitch. I enabled the memory performance features - still okay. If I can force an IRQ conflict I'll try that next, followed by the old SCSI card. I'd have to downgrade the BIOS to try the old memory, and anyway it's in another M/C. -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: swap_pager problem [was Re: 4.5 PRERELEASE - Call for testing]
Hello, Le 27 Dec 01 à 22:06:56 +, Matthew Dillon écrivait : > That's a fairly heavy-weight combination. Probably one of the > programs went on an infinite memory-allocation loop or something > like that. > > One solution is to set a datasize limit in your .xinitrc or .xsession > (whichever one you use to start up KDE), for example set a 128m limit, > so the runaway program doesn't take the rest of the system down > with it. Thanks. [Un-?]fortunately, I was unable to reproduce this problem. Since it does not seem to be related to a specific release of FreeBSD, perhaps could we close http://www.freebsd.org/cgi/query-pr.cgi?pr=30164> it surely was the same problem. -- Th. Thomas. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: buildworld fails on -stable
-questions and second -stable removed from cc. Try this too, taken from the handbook and may help. # chflags -R noschg /usr/obj/usr # rm -rf /usr/obj/usr # cd /usr/src # make cleandir # make cleandir Then make your world. At 02:11 PM 12/28/2001 -0800, Kent Stewart wrote: >P. U. (Uli) Kruppa wrote: > >>Hi, >>today I cvsup'ed three times. >>The latest result of >># make buildworld >>was >> >>-- >> >Rebuilding the temporary build tree >>-- >>rm -rf /usr/obj/usr/src/i386 >>mkdir -p /usr/obj/usr/src/i386/usr/bin >>mkdir -p /usr/obj/usr/src/i386/usr/lib/compat/aout >>mkdir -p /usr/obj/usr/src/i386/usr/games >>mkdir -p /usr/obj/usr/src/i386/usr/libdata/ldscripts >>mkdir -p /usr/obj/usr/src/i386/usr/libexec/elf >>mkdir -p /usr/obj/usr/src/i386/usr/sbin >>mkdir -p /usr/obj/usr/src/i386/usr/share/misc >>mkdir -p /usr/obj/usr/src/i386/usr/share/dict >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100-12 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75-12 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devascii >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devcp1047 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devdvi >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devhtml >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devkoi8-r >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlatin1 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlbp >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlj4 >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devps >>mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devutf8 >>mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mdoc >>mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mm >>mkdir -p /usr/obj/usr/src/i386/usr/include/arpa >>mkdir -p /usr/obj/usr/src/i386/usr/include/g++/std >>mkdir -p /usr/obj/usr/src/i386/usr/include/isc >>mkdir -p /usr/obj/usr/src/i386/usr/include/objc >>mkdir -p /usr/obj/usr/src/i386/usr/include/protocols >>mkdir -p /usr/obj/usr/src/i386/usr/include/readline >>mkdir -p /usr/obj/usr/src/i386/usr/include/rpc >>mkdir -p /usr/obj/usr/src/i386/usr/include/rpcsvc >>mkdir -p /usr/obj/usr/src/i386/usr/include/openssl >>mkdir -p /usr/obj/usr/src/i386/usr/include/security >>mkdir -p /usr/obj/usr/src/i386/usr/include/ss >>ln -sf /usr/src/sys /usr/obj/usr/src/i386 >>-- >> >stage 1: bootstrap tools >>-- >>cd /usr/src; >>MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR=/usr/obj/usr/src/i386 >>INSTALL="sh >>/usr/src/tools/install.sh" MACHINE_ARCH=i386 >>TOOLS_PREFIX=/usr/obj/usr/src/i386 >>PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > >>make -f Makefile.inc1 -DBOOTSTRAPPING -DNOHTML -DNOINFO -DNOMAN -DNOPIC >>-DNOPROFILE -DNOSHARED bootstrap-tools >>cd /usr/src/games/fortune/strfile; make obj; make depend; make >>all; make install >>/usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for >>/usr/src/games/fortune/strfile >>rm -f .depend >>mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c >>cd /usr/src/games/fortune/strfile; make _EXTRADEPEND >>echo strfile: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend >>cc -O -pipe -Wall-c /usr/src/games/fortune/strfile/strfile.c >>cc -O -pipe -Wall -static -o strfile strfile.o >>sh /usr/src/tools/install.sh -c -s -o root -g games -m 555 strfile >>/usr/obj/usr/src/i386/usr/games >>cd /usr/src/usr.bin/yacc; make obj; make depend; make all; make install >>/usr/obj/usr/src/i386/usr/src/usr.bin/yacc created for /usr/src/usr.bin/yacc >>rm -f .depend >>mkdep -f .depend -a /usr/src/usr.bin/yacc/closure.c >>/usr/src/usr.bin/yacc/error.c /usr/src/usr.bin/yacc/lalr.c >>/usr/src/usr.bin/yacc/lr0.c /usr/src/usr.bin/yacc/main.c >>/usr/src/usr.bin/yacc/mkpar.c /usr/src/usr.bin/yacc/output.c >>/usr/src/usr.bin/yacc/reader.c /usr/src/usr.bin/yacc/skeleton.c >>/usr/src/usr.bin/yacc/symtab.c /usr/src/usr.bin/yacc/verbose.c >>/usr/src/usr.bin/yacc/warshall.c >>cd /usr/src/usr.bin/yacc; make _EXTRADEPEND >>echo yacc: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend >>cc -O -pipe -c /usr/src/usr.bin/yacc/closure.c >>cc -O -pipe -c /usr/src/usr.bin/yacc/error.c >>cc -O -pipe -c /usr/src/usr.bin/yacc/lalr.c >>cc -O -pipe -c /usr/src/usr.bin/yacc/lr0.c >>cc -O -pipe -c /usr/src/usr.bin/yacc/main.c >>cc -O -pipe -c /usr/src/usr.bin/yacc/mkpar.c >>cc -O -pipe -c /usr/src/usr.bin/yacc/output.c >>*** Error code 1 >>Stop in /usr/src/usr.bin/yacc. >>*** Error code 1 >>Stop in /usr/src. >>*** Error code 1 >>Stop in /usr/src. >>*** Error code 1 >>St
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
On Fri, 28 Dec 2001, Søren Schmidt wrote: > I know that change as well, but so far I havn't been able to verify > that it does what it intends to do, VIA's docs are very vague on this. > > There is alot about this on the net, but *lots* of it are just notes > scribbled together by nerds^H^H^H^H^Hpeople that has no idea what > they are doing, they just change random bits that other talk about > and hope it works... > > I'll try to get this veryfied and tested here... > > -Søren True, true. I trust your judgement, I just wasn't sure if you had seen those patches yet. On a related note, would it be possible to modify ata_via686b so that it looks at what it reads from the register and only does the write and print if the bits are set incorrectly? Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
Note that we aren't complaining about your patch or anything, you are simply the closest thing we have to a VIA chip expert right now :-) -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
It seems Mike Silbersack wrote: > Agreed, it looks like the "MWQ bug" isn't addressed by soren's patch. The > decription at > http://www.networking.tzo.com/net/software/readme/faqvl019.htm > doesn't give enough info to patch it, but this post to the linux-kernel > mailing list seems to shed more light on what needs to be done: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.0/1421.html I know that change as well, but so far I havn't been able to verify that it does what it intends to do, VIA's docs are very vague on this. There is alot about this on the net, but *lots* of it are just notes scribbled together by nerds^H^H^H^H^Hpeople that has no idea what they are doing, they just change random bits that other talk about and hope it works... I'll try to get this veryfied and tested here... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
On Fri, 28 Dec 2001, Matthew Dillon wrote: > Ok, I have more information on Nils problem. First of all, Soren's > patch greatly reduced the rate of corruption. It took 25 loops of > Nils 'cp' test to generate the corruption. > > However, Soren's patch did not fiix the corruption. The same exact > corruption is occuring. In Nils case it is always the same exact > location in VM -- a certain bit (or byte) in the middle of the nfsnode > hash table. Hardware watch points indicate that the cpu is NOT modifying > this location, so I really doubt that it is a kernel bug. > > From this and from reading a number of other postings about VIA chipsets > I believe that Soren's original patch (which I guess is the official > VIA chipset patch) does not completely solve the VIA chipset's problems. > I also believe, from reading some of the reference material that has > been posted, that this corruption is not limited to the 686[A/B] but > may also occur in earlier VIA chipsets. Agreed, it looks like the "MWQ bug" isn't addressed by soren's patch. The decription at http://www.networking.tzo.com/net/software/readme/faqvl019.htm doesn't give enough info to patch it, but this post to the linux-kernel mailing list seems to shed more light on what needs to be done: http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.0/1421.html Perhaps someone on a faster connection than I can snag a copy of whatever version of linux is current and see the exact patch that went in. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
It seems Matthew Dillon wrote:
> Ok, I have more information on Nils problem. First of all, Soren's
> patch greatly reduced the rate of corruption. It took 25 loops of
> Nils 'cp' test to generate the corruption.
Hmm, did the second change I posted change anything ?
> However, Soren's patch did not fiix the corruption. The same exact
> corruption is occuring. In Nils case it is always the same exact
> location in VM -- a certain bit (or byte) in the middle of the nfsnode
> hash table. Hardware watch points indicate that the cpu is NOT modifying
> this location, so I really doubt that it is a kernel bug.
If the BIOS has the option to disable "page mode" access to RAM try
to switch that off, it has shown problems here (as I mentioned in
another mail)
> From this and from reading a number of other postings about VIA chipsets
> I believe that Soren's original patch (which I guess is the official
> VIA chipset patch) does not completely solve the VIA chipset's problems.
My patch is based on the info from VIA and from various other sources
plus lots of testing here in the lab.
> I also believe, from reading some of the reference material that has
> been posted, that this corruption is not limited to the 686[A/B] but
> may also occur in earlier VIA chipsets.
The 686B data corruption bug is isolated to that chip *only*, the older
686A doesn't have that problem, the even older 686 has problems with
the ATA66 clock generation but luckily only few of those exist.
There is no offcial problems with the older chips of this sort, but some
has varius minor problems/"features", which is unrelated here...
> What I would like to do is try forcing the DMA transfer rate to 66 MHz,
> i.e. UDMA66 or UDMA33, to see if that solves the problem. Soren,
> could you supply a patch that universally turns off higher UDMA modes?
Sure, this one turns off ATA100 support (note its for -current, but
should be easily applied to -stable) in the same fashion ATA66 can
be turned off etc. However under -current you can just use atacontrol
to set the wanted transfermode, no patch is needed there.
--- ata-dma.c 25 Dec 2001 14:44:26 - 1.80
+++ ata-dma.c 28 Dec 2001 22:14:01 -
@@ -407,6 +407,7 @@
if (ata_find_dev(parent, 0x06861106, 0x40) ||
ata_find_dev(parent, 0x82311106, 0) ||
ata_find_dev(parent, 0x30741106, 0)) { /* 82C686b */
+#if 0
if (udmamode >= 5) {
error = ata_command(scp, device, ATA_C_SETFEATURES, 0,
ATA_UDMA5, ATA_C_F_SETXFER, ATA_WAIT_READY);
@@ -419,6 +420,7 @@
return;
}
}
+#endif
if (udmamode >= 4) {
error = ata_command(scp, device, ATA_C_SETFEATURES, 0,
ATA_UDMA4, ATA_C_F_SETXFER, ATA_WAIT_READY);
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: buildworld fails on -stable
P. U. (Uli) Kruppa wrote: > Hi, > > today I cvsup'ed three times. > The latest result of > # make buildworld > was > > > > -- > Rebuilding the temporary build tree > -- > rm -rf /usr/obj/usr/src/i386 > mkdir -p /usr/obj/usr/src/i386/usr/bin > mkdir -p /usr/obj/usr/src/i386/usr/lib/compat/aout > mkdir -p /usr/obj/usr/src/i386/usr/games > mkdir -p /usr/obj/usr/src/i386/usr/libdata/ldscripts > mkdir -p /usr/obj/usr/src/i386/usr/libexec/elf > mkdir -p /usr/obj/usr/src/i386/usr/sbin > mkdir -p /usr/obj/usr/src/i386/usr/share/misc > mkdir -p /usr/obj/usr/src/i386/usr/share/dict > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100-12 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75-12 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devascii > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devcp1047 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devdvi > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devhtml > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devkoi8-r > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlatin1 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlbp > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlj4 > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devps > mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devutf8 > mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mdoc > mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mm > mkdir -p /usr/obj/usr/src/i386/usr/include/arpa > mkdir -p /usr/obj/usr/src/i386/usr/include/g++/std > mkdir -p /usr/obj/usr/src/i386/usr/include/isc > mkdir -p /usr/obj/usr/src/i386/usr/include/objc > mkdir -p /usr/obj/usr/src/i386/usr/include/protocols > mkdir -p /usr/obj/usr/src/i386/usr/include/readline > mkdir -p /usr/obj/usr/src/i386/usr/include/rpc > mkdir -p /usr/obj/usr/src/i386/usr/include/rpcsvc > mkdir -p /usr/obj/usr/src/i386/usr/include/openssl > mkdir -p /usr/obj/usr/src/i386/usr/include/security > mkdir -p /usr/obj/usr/src/i386/usr/include/ss > ln -sf /usr/src/sys /usr/obj/usr/src/i386 > > -- > stage 1: bootstrap tools > -- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR=/usr/obj/usr/src/i386 >INSTALL="sh /usr/src/tools/install.sh" MACHINE_ARCH=i386 >TOOLS_PREFIX=/usr/obj/usr/src/i386 >PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > make -f Makefile.inc1 -DBOOTSTRAPPING -DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE >-DNOSHARED bootstrap-tools > cd /usr/src/games/fortune/strfile; make obj; make depend; make all; make install > /usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for >/usr/src/games/fortune/strfile > rm -f .depend > mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c > cd /usr/src/games/fortune/strfile; make _EXTRADEPEND > echo strfile: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend > cc -O -pipe -Wall-c /usr/src/games/fortune/strfile/strfile.c > cc -O -pipe -Wall -static -o strfile strfile.o > sh /usr/src/tools/install.sh -c -s -o root -g games -m 555 strfile >/usr/obj/usr/src/i386/usr/games > cd /usr/src/usr.bin/yacc; make obj; make depend; make all; make install > /usr/obj/usr/src/i386/usr/src/usr.bin/yacc created for /usr/src/usr.bin/yacc > rm -f .depend > mkdep -f .depend -a /usr/src/usr.bin/yacc/closure.c >/usr/src/usr.bin/yacc/error.c /usr/src/usr.bin/yacc/lalr.c >/usr/src/usr.bin/yacc/lr0.c /usr/src/usr.bin/yacc/main.c >/usr/src/usr.bin/yacc/mkpar.c /usr/src/usr.bin/yacc/output.c >/usr/src/usr.bin/yacc/reader.c /usr/src/usr.bin/yacc/skeleton.c >/usr/src/usr.bin/yacc/symtab.c /usr/src/usr.bin/yacc/verbose.c >/usr/src/usr.bin/yacc/warshall.c > cd /usr/src/usr.bin/yacc; make _EXTRADEPEND > echo yacc: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend > cc -O -pipe -c /usr/src/usr.bin/yacc/closure.c > cc -O -pipe -c /usr/src/usr.bin/yacc/error.c > cc -O -pipe -c /usr/src/usr.bin/yacc/lalr.c > cc -O -pipe -c /usr/src/usr.bin/yacc/lr0.c > cc -O -pipe -c /usr/src/usr.bin/yacc/main.c > cc -O -pipe -c /usr/src/usr.bin/yacc/mkpar.c > cc -O -pipe -c /usr/src/usr.bin/yacc/output.c > *** Error code 1 > > Stop in /usr/src/usr.bin/yacc. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > > Any ideas? I just cvsup'ed RELENG_4 and rebuilt my system with out any problem. You have something messed up on your end. Sometimes, weird stuff like this can be caused by a system clock that is way off. If it is off, set it to the p
buildworld fails on -stable
Hi, today I cvsup'ed three times. The latest result of # make buildworld was -- >>> Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/i386 mkdir -p /usr/obj/usr/src/i386/usr/bin mkdir -p /usr/obj/usr/src/i386/usr/lib/compat/aout mkdir -p /usr/obj/usr/src/i386/usr/games mkdir -p /usr/obj/usr/src/i386/usr/libdata/ldscripts mkdir -p /usr/obj/usr/src/i386/usr/libexec/elf mkdir -p /usr/obj/usr/src/i386/usr/sbin mkdir -p /usr/obj/usr/src/i386/usr/share/misc mkdir -p /usr/obj/usr/src/i386/usr/share/dict mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX100-12 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devX75-12 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devascii mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devcp1047 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devdvi mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devhtml mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devkoi8-r mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlatin1 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlbp mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devlj4 mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devps mkdir -p /usr/obj/usr/src/i386/usr/share/groff_font/devutf8 mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mdoc mkdir -p /usr/obj/usr/src/i386/usr/share/tmac/mm mkdir -p /usr/obj/usr/src/i386/usr/include/arpa mkdir -p /usr/obj/usr/src/i386/usr/include/g++/std mkdir -p /usr/obj/usr/src/i386/usr/include/isc mkdir -p /usr/obj/usr/src/i386/usr/include/objc mkdir -p /usr/obj/usr/src/i386/usr/include/protocols mkdir -p /usr/obj/usr/src/i386/usr/include/readline mkdir -p /usr/obj/usr/src/i386/usr/include/rpc mkdir -p /usr/obj/usr/src/i386/usr/include/rpcsvc mkdir -p /usr/obj/usr/src/i386/usr/include/openssl mkdir -p /usr/obj/usr/src/i386/usr/include/security mkdir -p /usr/obj/usr/src/i386/usr/include/ss ln -sf /usr/src/sys /usr/obj/usr/src/i386 -- >>> stage 1: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" MACHINE_ARCH=i386 TOOLS_PREFIX=/usr/obj/usr/src/i386 PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DBOOTSTRAPPING -DNOHTML -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED bootstrap-tools cd /usr/src/games/fortune/strfile; make obj; make depend; make all; make install /usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for /usr/src/games/fortune/strfile rm -f .depend mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c cd /usr/src/games/fortune/strfile; make _EXTRADEPEND echo strfile: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -Wall-c /usr/src/games/fortune/strfile/strfile.c cc -O -pipe -Wall -static -o strfile strfile.o sh /usr/src/tools/install.sh -c -s -o root -g games -m 555 strfile /usr/obj/usr/src/i386/usr/games cd /usr/src/usr.bin/yacc; make obj; make depend; make all; make install /usr/obj/usr/src/i386/usr/src/usr.bin/yacc created for /usr/src/usr.bin/yacc rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/yacc/closure.c /usr/src/usr.bin/yacc/error.c /usr/src/usr.bin/yacc/lalr.c /usr/src/usr.bin/yacc/lr0.c /usr/src/usr.bin/yacc/main.c /usr/src/usr.bin/yacc/mkpar.c /usr/src/usr.bin/yacc/output.c /usr/src/usr.bin/yacc/reader.c /usr/src/usr.bin/yacc/skeleton.c /usr/src/usr.bin/yacc/symtab.c /usr/src/usr.bin/yacc/verbose.c /usr/src/usr.bin/yacc/warshall.c cd /usr/src/usr.bin/yacc; make _EXTRADEPEND echo yacc: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend cc -O -pipe -c /usr/src/usr.bin/yacc/closure.c cc -O -pipe -c /usr/src/usr.bin/yacc/error.c cc -O -pipe -c /usr/src/usr.bin/yacc/lalr.c cc -O -pipe -c /usr/src/usr.bin/yacc/lr0.c cc -O -pipe -c /usr/src/usr.bin/yacc/main.c cc -O -pipe -c /usr/src/usr.bin/yacc/mkpar.c cc -O -pipe -c /usr/src/usr.bin/yacc/output.c *** Error code 1 Stop in /usr/src/usr.bin/yacc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any ideas? Thanks and regards, Uli. *P. U. Kruppa - Wuppertal* * Germany* * www.pukruppa.de www.2000d.de * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers
:... :> > :> > There is also the "only supports 16MxN RAM" feature. :> :> Maybe I should toss in that I've had spontaneous reboots during heavy :> IDE activity both on my desktop (VIA 82C686) and my laptop (Intel :> 82443BX). And before that, random disk corruption during heavy SCSI :> activity on my old desktop machine (seen with Tekram and Acer :> 83C575-based host adapters and a borrowed Adaptec 2940). : :Guys guys, we are talking about known HW issues that causes known :bad behavior, having a system that is flaky can have all kinds of :reasons, I'd risk saying that genuine HW bugs like the 686B bug :is one of the least likely problems... : :The most likely reasons are probably bad/subspec'd RAM, lousy PSU, :bad/subspec'd cabeling, too many "performance features" enabled, :generally crappy hardware (there are *tons* of that out there), :bad/insufficient cooling, overclocking (even the motherboard makers :overclock pr default nowadays to gain a litte over the competition), : :And do *not* forget bugs/bogons/mistakes in your favorite OS :) : :-Søren Ok, I have more information on Nils problem. First of all, Soren's patch greatly reduced the rate of corruption. It took 25 loops of Nils 'cp' test to generate the corruption. However, Soren's patch did not fiix the corruption. The same exact corruption is occuring. In Nils case it is always the same exact location in VM -- a certain bit (or byte) in the middle of the nfsnode hash table. Hardware watch points indicate that the cpu is NOT modifying this location, so I really doubt that it is a kernel bug. From this and from reading a number of other postings about VIA chipsets I believe that Soren's original patch (which I guess is the official VIA chipset patch) does not completely solve the VIA chipset's problems. I also believe, from reading some of the reference material that has been posted, that this corruption is not limited to the 686[A/B] but may also occur in earlier VIA chipsets. What I would like to do is try forcing the DMA transfer rate to 66 MHz, i.e. UDMA66 or UDMA33, to see if that solves the problem. Soren, could you supply a patch that universally turns off higher UDMA modes? -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: buildworld 4.4 stable fails
Alex Obradovic wrote: > For some reason I can not do buildworld for several days now. I last > rebuilt the system over a month ago without any problems. I checked > out UPDATING, and everything seems to be fine. > The error I get is listed below. I wiped out my /usr/src and rebuilt > it with cvsup but I had no success. Any ideas? One, set your clock to the proper time. You email showed up as being generated in 2000. Kent > > Thanks, > > Alex > > > ""2.11.2 20010719 [FreeBSD]"\" -DBFD_VERSION=\""2.11.2 20010719 > [FreeBSD]"\"-c ldgram.c > yacc -d -o ldgram.c > /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldgram.y > cc -O -pipe -D_GNU_SOURCE -I- -I. > -I/usr/src/gnu/usr.bin/binutils/ld/i386 > -I/usr/src/gnu/usr.bin/binutils/ld > -I/usr/src/gnu/usr.bin/binutils/ld/../libbfd/i386 > -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include > -DDEFAULT_EMULATION=\"elf_i386\" -DTARGET=\"i386-unknown-freebsd\" > -DSCRIPTDIR=\"/usr/obj/usr/src/i386/usr/libdata\" > -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld > -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd > -DVERSION=\""2.11.2 20010719 [FreeBSD]"\" -DBFD_VERSION=\""2.11.2 > 20010719 [FreeBSD]"\"-c > /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldctor.c > cc -O -pipe -D_GNU_SOURCE -I- -I. > -I/usr/src/gnu/usr.bin/binutils/ld/i386 > -I/usr/src/gnu/usr.bin/binutils/ld > -I/usr/src/gnu/usr.bin/binutils/ld/../libbfd/i386 > -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include > -DDEFAULT_EMULATION=\"elf_i386\" -DTARGET=\"i386-unknown-freebsd\" > -DSCRIPTDIR=\"/usr/obj/usr/src/i386/usr/libdata\" > -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld > -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/bfd > -DVERSION=\""2.11.2 20010719 [FreeBSD]"\" -DBFD_VERSION=\""2.11.2 > 20010719 [FreeBSD]"\"-c > /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldexp.c > ldgram.c:939: syntax error at end of input > ldgram.c:736: warning: array `yycheck' assumed to have one element > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > > . > > -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://users.owt.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
