Re: 4.4-RC2 is now available
On Tue, Aug 28, 2001 at 10:54:42PM -0500, David Kelly wrote: Is still not there 8 hours later: Argh.. The ISO has been sitting on ftp-master since this morning and the FTP-release has been there since last night. There are multiple entries from ftp.freebsd.org in the rsync log but for some reason the ISO isn't being transfered. I've emailed the ftp.FreeBSD.org admins so hopefully we can get this resolved soon. In the meantime I'm copying the release over to releng4.freebsd.org In 28 minutes you should be able to get the ISO from : ftp://releng4.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES Thanks, - Murray PGP signature
Re: Failure to attach SCSI CD burner
Le 2001-08-29, Kenneth D. Merry écrivait : Apply the attached patch in place of the one I gave you before and send the output when you boot. This will print out the SCSI status byte. Thanks, applied, I'll let you know as soon as I get a chance to reboot. This problem is happening with a bad CD-R, right? Yes. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Freezes in 4.4 RC on SMP kernel
I have been getting unexplicable freezes on my SMP server machine. It is an Abit VP6 with 1G Micron memory and 2 Intel P3/800 cpus. It runs fine with a RELENG_4_3 kernel. It runs fine with a non smp 4.4 RC kernel. It freezes after some time with a 4.4 RC smp kernel but apparently only when I start up an X server on my workstation (other machine) and some x-clients on the smp machine. The workstation is running 4.4 RC (non smp). My homedir is on the smp machine, mounted over NFS on the workstation and I am using NIS and I'm running i4b. Attached is various dmesg output and the kernel config. Jos Copyright (c) 1992-2001 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 4.4-RC #0: Tue Aug 28 00:03:29 CEST 2001 [EMAIL PROTECTED]:/a/vol/obj/a/vol/src/FreeBSD-4-STABLE/src/sys/islay Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (798.69-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1048512K bytes) avail memory = 1040818176 (1016424K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Preloaded elf kernel kernel-4.4.smp at 0xc04a7000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 8 entries at 0xc00fdc60 apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: VIA 82C686 PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0x9000-0x900f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 uhci0: VIA 83C572 USB controller port 0x9400-0x941f irq 5 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0x9800-0x981f irq 5 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered chip1: VIA 82C686 ACPI interface at device 7.4 on pci0 ahc0: Adaptec 29160 Ultra160 SCSI adapter port 0x9c00-0x9cff mem 0xd610-0xd6100fff irq 11 at device 9.0 on pci0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xa000-0xa01f mem 0xd600-0xd60f,0xd6101000-0xd6101fff irq 12 at device 10.0 on pci0 fxp0: Ethernet address 00:a0:c9:a5:38:7d inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative CT5880-C port 0xa400-0xa43f irq 12 at device 11.0 on pci0 pci0: ATI Mach64-GV graphics accelerator at 12.0 irq 5 ifpi0: AVM Fritz!Card PCI port 0xac00-0xac1f mem 0xd6103000-0xd610301f irq 10 at device 13.0 on pci0 ifpi0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) ifpi0: passive stack unit 0 atapci1: HighPoint HPT370 ATA100 controller port 0xc000-0xc0ff,0xbc00-0xbc03,0xb800-0xb807,0xb400-0xb403,0xb000-0xb007 irq 10 at device 14.0 on pci0 ata2: at 0xb000 on atapci1 ata3: at 0xb800 on atapci1 orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xcb7ff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: Hewlett-Packard HP LaserJet 2100 Series PJL,MLC,PCL,PCLXL,POSTSCRIPT lpt0: Printer on ppbus0 lpt0: Interrupt-driven port pcfclock0: PCF-1.0 on ppbus0 unknown: PNP0303 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0400 can't assign resources i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) DUMMYNET initialized (010124) i4bctl: ISDN system control port
/sys/crypto not getting check out with src-all
Hi! It seems that there's a problem with 4.4-RC. I have src-all specified in my stable-supfile, stiff, crypto (and sys-crypto) is not check out. There is simply no such directory as /usr/src/sys/crypto (though it is in CVS and I can get all the files). I've notice this when trying to build my kernel with NETSMBCRYPTO (or likewise) option. Could I hope this is my fault, or if it's not, for this to be fixed?? This is kinda weird (not to mention that is' annoys me) since it's stated in /usr/share/examples/cvsup/stable-supfile that all those used-to-be USA-restrivted distributions (des, and stuff) are now part of src-all distro. Thank you. -- ëÏÎËÕÒÓ $1000 ÚÁ ÉÄÅÀ! http://ngs.ru/konkurs1000 -- òÁÓÐÉÓÁÎÉÅ ÔÒÁÎÓÐÏÒÔÁ × îÏ×ÏÓÉÂÉÒÓËÅ http://ngs.ru/transport To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Building Ports
I just heard a most interest tale of woe. A new user installing 4.3-Release wanted some ports. I gave him specific instructions, in writing, on how to build those ports. For some reason he ignored the step to cd to the specific port and did essentially: cd /usr/ports make The system dutifully started making all the ports in alphabetical order for quite a few hours until he finally ran out of disk space. Is this feature really useful or something that is a byproduct of useful features? I ask to be sure that there was a delebriate decision for this to happen. -- -- Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: /sys/crypto not getting check out with src-all
In article [EMAIL PROTECTED], Eugene Panchenko [EMAIL PROTECTED] wrote: Hi! It seems that there's a problem with 4.4-RC. I have src-all specified in my stable-supfile, stiff, crypto (and sys-crypto) is not check out. There is simply no such directory as /usr/src/sys/crypto (though it is in CVS and I can get all the files). I've notice this when trying to build my kernel with NETSMBCRYPTO (or likewise) option. Could I hope this is my fault, or if it's not, for this to be fixed?? This is kinda weird (not to mention that is' annoys me) since it's stated in /usr/share/examples/cvsup/stable-supfile that all those used-to-be USA-restrivted distributions (des, and stuff) are now part of src-all distro. That's correct. Do you have a refuse file? (See the section REFUSE FILES in cvsup(1).) If so, please post it. Also please post your supfile. I'm sure there's a simple explanation for the problem. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: CPUTYPE and ports
On Wed, 29 Aug 2001, Kris Kennaway wrote: On Thu, Aug 30, 2001 at 02:20:13AM +0200, clemensF wrote: Kris Kennaway: I understand gcc 3.x supports optimization for the newer AMD chips; it will be imported into 5.0-CURRENT at some point, but may not make it back into 4.x because of the disruption involved. on my machine `gcc -v' outputs `gcc version 2.95.3 [FreeBSD] 20010315 (release)'. i'd like to read a rundown about this compiler, about how well it's doing on different platforms, what the differences between it and egc are, if i can compile fortran with it, how this would be done, that kind of thing. GCC 2.95.3 == EGCS 2.95.3. Some time ago, the GCC folks decided to rename themselves EGCS, the Extended GNU Compiler Suite, and then they decided they liked GCC better. GCC now stands for GNU Compiler Collection, currently handling C, C++, Java, and FORTRAN. Chill support has been dropped because no one stepped forward to maintain it. Version 2.95.3 was the last stable version before 3.0 came out. There was an interim 2.96 release that contained experimental support for generating 64-bit code on SPARCs, but it was not blessed as a stable release, IIUC. i've never found a document of this type, a few sentences would suffice, because i am everything _but_ a compiler bauer. maybe the right url would do. http://gcc.gnu.org/ , which includes a doxygen run on the GNU STL. Note that STLport (a port of SGI's STL, see http://www.stlport.org ) compiles fine under GCC, and appears to be more stable when used with threads. What I'd like to know is if anyone has figured out a way to do a g++ equivalent to Microsoft's precompiled headers. If so, please clue me in: they really speed up a build on a big project. -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: CPUTYPE and ports
What I'd like to know is if anyone has figured out a way to do a g++ equivalent to Microsoft's precompiled headers. Not really needed for gcc. The preprocessor has special-case logic to recognise header files of the form /* optional comments */ #ifndef SYMBOL #define SYMBOL /* Stuff */ #endif (i.e. almost any normal C/C++ header) and not bother to even open the file next time it is referenced. This gives most of the speedup that precompiled headers would give. (The remaining bit is avoiding lexing the include file text, but that's not such a huge burden). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
microuptime() went backwards
the clock skew on my k2-6 pc is indicated, usually between the third and forth decimal after the dot, and i can't get it right. the problem is worst with freebsd, i did not see it with openbsd. i tried: sysctl -w kern.timecounter.method=1, which is the standard setting now, no success. i even fiddled with options NTIMECOUNTER=20 entries in my kernel config, this also did not help. i had the counter from 5 up to a few thousand(!), to no avail. doesn't this look like interrupts beeing masked for too long? clemens ps: typical entries in `dmesg -a` look like: Wed Aug 29 16:12:25 CEST 2001 microuptime() went backwards (7633.019507 - 7633.019407) pid 16331 (vile), uid 65534: exited on signal 6 (core dumped) cd9660: RockRidge Extension microuptime() went backwards (27387.137508 - 27387.137407) microuptime() went backwards (27888.555071 - 27888.554971) microuptime() went backwards (37977.157270 - 37977.156967) happens from thrice up to a few dozen times, depending on load. the board is a gigabyte GA-5AA, super7 mainboard with a k6-2 550Mhz, the graphics are a bulk Xpert@play, agp interfaced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Freezes in 4.4RC on SMP Kernel and gkrellm
Alex Varju [EMAIL PROTECTED] types:
Considering that you've seen problems with this, it seems worth mentioning
that I also have gkrellm running all the time. I have the following
monitors enabled: Clock, CPU, Disk (composite), Network (xl0), Mailcheck,
and Uptime.
Turns out that gkrellm can be *very* hazardous to your system. I've
got a situation where the system panics every time I start gkrellm. I
believe this is a bug in gkrellm, not in the system.
What I did was enable smb in the kernel, to see if gkrellm behaved
differently using smb rather than isa for io. I've got two smb devices
in the system:
smbus0: System Management Bus on intsmb0
smb0: SMBus general purpose I/O on smbus0
and
smbus1: System Management Bus on bti2c0
smb1: SMBus general purpose I/O on smbus1
gkrellm opens the first one with no problem. It finds the second one,
and the system panics. The relevant part of the traceback seems to be:
#6 0xc027e05f in trap (frame={tf_fs = -107238, tf_es = -1056047088,
tf_ds = 16777232, tf_edi = 0, tf_esi = -1059648000, tf_ebp = -863265464,
tf_isp = -863265484, tf_ebx = -1063046432, tf_edx = -1071663704,
tf_ecx = -1059648000, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072240230, tf_cs = 8, tf_eflags = 66118, tf_esp = -863265440,
tf_ss = -1072362873}) at ../../i386/i386/trap.c:458
#7 0xc016e99a in device_set_softc (dev=0x0, softc=0xc0a332e0)
at ../../kern/subr_bus.c:986
#8 0xc0150a87 in iicbus_request_bus (bus=0x0, dev=0xc0d70e00, how=0)
at ../../dev/iicbus/iiconf.c:108
#9 0xc01fb5e6 in bti2c_smb_callback (dev=0xc0d70e00, index=1, data=0xcc8b9dc4)
at ../../dev/bktr/bktr_i2c.c:248
From looking over gkrellm's code, it assumes that any smb device it
finds is the one it knows about - and proceeds to try and extract data
from it. This seems like a bad idea - at least in this case.
gkrellm also has the problem that it initializes every monitor it
knows about, even if that one isn't being displayed. Without the smb
devices, it uses /dev/io, and that's left open so that gkrellm can
lower it's privileges after opening the file. This means bugs in other
modules could stroke /dev/io in some strange way - and I believe
that's the root cause of the freezes I'm seeing.
I've installed gkrellm WITHOUT_SENSOR=yes - which sgid instead of suid
- and enabled all the things that I had on when the system was
freezing before, except the sensors.
If anyone is interested in the smb panics, I've still got all the
relevant files if you need them, or information from them.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: 4.4 prerelease error message
Juha Saarinen wrote: :: Aug 29 06:00:00 mysyst syslogd: /dev/console: Too many :: open files in system: Too many open files in system :: Aug 29 06:00:00 mysyst syslogd: /var/run/utmp: Too :: many open files in system You have a www and database server? So you have to raise a limit with sysctl(8) (kern.maxfiles) or compile a kernel with a large MAXUSER constant. -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: CPUTYPE and ports
Gregory Bond [EMAIL PROTECTED] writes:
What I'd like to know is if anyone has figured out a way to do a
g++ equivalent to Microsoft's precompiled headers.
Not really needed for gcc. The preprocessor has special-case logic to
recognise header files of the form
/* optional comments */
#ifndef SYMBOL
#define SYMBOL
/* Stuff */
#endif
(i.e. almost any normal C/C++ header) and not bother to even open the file next
time it is referenced. This gives most of the speedup that precompiled headers
would give. (The remaining bit is avoiding lexing the include file text, but
that's not such a huge burden).
Actually, the primary reason for using that construct is to avoid
compile-time errors caused by the same header file being included twice in the
same g++ run.
The real rationale behind MS-style precompiled headers is to speed up
compilation of separate source modules belonging to the same project,
including one or more of the same headers and that are compiled in successive
runs of the compiler. This sometimes may make quite a difference, especially
on slow machines and with the STL headers. Try passing this code:
#include iostream
#include map
main(){}
to g++ -E and see what you end up with ;)
-- Danilo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: kernel panic when bringing up a VLAN interface (netgraph?)
Yar Tikhiy writes: Why does gdb report the values of ifp and mp inconsistently? The kernel crashed at the first line of ng_ether_output(), so the arguments couldn't be modified... I'm confused. Optimization.. it's probably reusing the same variable/register for both 'ifp' and 'node'. So 'node' is NULL, which indicates that ether_ifattach() was probably never called on this interface. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
