Re: libc size
In message: <[EMAIL PROTECTED]> Wesley Morgan <[EMAIL PROTECTED]> writes: : And of course the "answer" to that is to create a /lib. Something that I : would *never ever* want to see. Sure, a few people might throw around the : idea of an extremely light-weight set of libraries to go into /lib blah : blah. But I just don't like the idea. Why not create a minimalist C : library, build with -nostdlib and staticly link against exactly what you : need. : : I usually create a 128 or 64mb root, and the only time this gets "tight" : is when I keep too many kernels around in /boot. I seem to recall other : arguments being settled by the "disk space is extremely cheap" issue. : : Call me crazy, but FreeBSD just has this "zen" feeling to it, and making : this kind of change doesnt feel very zennish. I'm sure there are greater : minds than mine working over this issue, but thats my $0.02. Actually, NetBSD has done exactly that (created a /lib). They found that putting only the libraries necessary for boot in there that they were able to save aboue 10M on the size of /, even after one creates a few static binaries in /something-like-recover. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: another include failure to find in buildworld
On Fri, Nov 01, 2002 at 07:23:04AM +, Daniel Flickinger wrote:
>
> from cvsup *default date=2002.11.01.06.00.00:
>
> rm -rf /usr/obj/usr
> make -j 4 -k -s buildworld ...
>
> crashed in libc. v1.19 is in /usr/include; v1.20 is in
> the /usr/obj/ tree where it should be read by infinity.c
>
> /usr/src/lib/libc/i386/gen/infinity.c:11: storage size of `__infinity' isn't known
> *** Error code 1
>
> < * $FreeBSD: src/lib/msun/src/math.h,v 1.19 2002/10/23 17:35:11 markm Exp $
> ---
> > * $FreeBSD: src/lib/msun/src/math.h,v 1.20 2002/10/31 23:05:20 archie Exp $
> 23,24c23,27
> < extern char __infinity[];
> < #define HUGE_VAL (*(double *) __infinity)
> ---
> > extern const union __infinity_un {
> > unsigned char __uc[8];
> > double __ud;
> > } __infinity;
> > #define HUGE_VAL (__infinity.__ud)
>
> This is another instance where the build is not reading
> from the /usr/obj tree, reading from /usr/include first.
>
> a 'make buildincludes installincludes' cures the problem
>
> This is no problem in the development track; costs me a
> few minutes to update /usr/include and 34 minutes on the
> machine to do a new buildworld. I just deleted the 'make
> installincludes' step from my build scripts --maybe I
> should restore it?
>
> However, is it not the intent not to require an
> installincludes prior to buildworld?
>
Of course not, because installincludes are essential part of the
buildworld, and everything that is bootstrapped, should be buildable
in a host environment.
> ... too much insider knowledge and nothing documented
> other than read the makefiles?
>
I'm not seeing this breakage. At what stage of buildworld do you
see it? (buildworld builds special versions of compiler and cross
tools that honour the TOOLS_PREFIX which is set to WORLDTMP during
world-related stages of buildworld: includes, libraries, depend,
and all.
Cheers,
--
Ruslan Ermilov Sysadmin and 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
msg45846/pgp0.pgp
Description: PGP signature
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 1 03:06:40 PST 2002 -- >>> Kernel build for GENERIC completed on Fri Nov 1 03:35:36 PST 2002 -- >>> Kernel build for LINT started on Fri Nov 1 03:35:36 PST 2002 -- ===> vinum "Makefile", line 4517: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"... could sleep with "pcm0" locked from ..."
Hi, I've enabled sound using "device pcm". Now at boot and each time I'm trying to play a sound I got a lot of messages like: pcm0: port 0x1430-0x1433,0x1434-0x1437,0x1000-0x10ff irq 9 at de vice 7.5 on pci0 ../../../vm/uma_core.c:1311: could sleep with "pcm0" locked from ../../../dev/so und/pcm/sound.c:134 ../../../vm/uma_core.c:1311: could sleep with "pcm0" locked from ../../../dev/so und/pcm/sound.c:134 ../../../vm/uma_core.c:1311: could sleep with "pcm0" locked from ../../../dev/so und/pcm/sound.c:134 ../../../vm/uma_core.c:1311: could sleep with "pcm0:fake" locked from ../../../d ev/sound/pcm/channel.c:677 ../../../vm/uma_core.c:1311: could sleep with "pcm0" locked from ../../../dev/so und/pcm/sound.c:134 ../../../vm/uma_core.c:1311: could sleep with "pcm0:fake" locked from ../../../d ev/sound/pcm/channel.c:677 ../../../vm/uma_core.c:1311: could sleep with "pcm0" locked from ../../../dev/so und/pcm/sound.c:134 [...] Anyone knows why / what to do ? -- Aurélien msg45848/pgp0.pgp Description: PGP signature
Re: A few questions
On 2002-10-31 18:39, Conrad Sabatier <[EMAIL PROTECTED]> wrote: > I just upgraded a 4.7-STABLE box to current over the weekend. Went off > very well, thanks to the great documentation in UPDATING. > [...] > And finally, is there a simple way to ensure that none of the debugging > code (including INVARIANTS stuff) is included during a buildworld? INVARIANTS and WITNESS are kernel-only stuff. They shouldn't affect your userland programs. If they do, it's probably a bug. Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current install on large disk in non-LBA mode
John Baldwin wrote: Sectors more than 63 are not allowed for IDE drives at all. What happens when you use the LBA geometry? Does the drive not boot properly after being installed? Well, I did try LBA as well, but couldn't boot at all. boot2 did let me look at the root directory, but any further investigation (like trying 0:da(0,a)/boot/? ) produced junk and/or killed boot2. The Windows partition also didn't boot. Btw. according to http://www.pcguide.com/ref/hdd/bios/modesECHS-c.html the CHS parameters *are* within limits of the IDE/ATA standard; the "Large" mode is off limits since it can't get the Cylinder cound below 1024 without exceeding the max Heads. *sigh* what a mess :-) /step -- stephan mantler reality is in fact virtual. [EMAIL PROTECTED]http://step.schmelzweb.at/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current install on large disk in non-LBA mode
On 01-Nov-2002 stephan mantler wrote: > John Baldwin wrote: >> Sectors more than 63 are not allowed for IDE drives at all. >> What happens when you use the LBA geometry? Does the drive >> not boot properly after being installed? > > Well, I did try LBA as well, but couldn't boot at all. boot2 did > let me look at the root directory, but any further investigation > (like trying 0:da(0,a)/boot/? ) produced junk and/or killed boot2. > The Windows partition also didn't boot. > > Btw. according to http://www.pcguide.com/ref/hdd/bios/modesECHS-c.html > the CHS parameters *are* within limits of the IDE/ATA standard; > the "Large" mode is off limits since it can't get the Cylinder > cound below 1024 without exceeding the max Heads. > > *sigh* what a mess :-) The problem is that the _BIOS_ restricts to 63 sectors per head. :) Not ATA. If windows is the first slice on the disk then it might seem to work ok by accident. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "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
crash with network load (in tcp syncache ?)
I'm getting panics on SMP -CURRENT while running apachebench (binary ab from apache distribution, not the Perl one) against httpd on the machine. The panics don't occur when I have WITNESS and INVARIANTS turned on. I'm running apache server from ports with no special configuration. I'm running (on different machine) ./ab -c 10 http://host/index.html. The panics occur after bit more than the number of connections I have set as kern.ipc.maxsockets (17000 by default, 3 incresed) - probably because the first ones expire (when I set net.inet.tcp.msl to 5000 I can't make it panic - the number of tcpcb in vm.zone doesn't grow past about 6500 - it doesn't go much down even long after the benchmark run finishes but that's ok I suppose). I had while 1; sysctl -a |grep tcpcb sleep 1 end running and the output was like this tcpcb: 604,3, 28551, 57,28354 tcpcb: 604,3, 29301, 57,29104 tcpcb: 604,3, 29926, 56,29729 - and then panic into ddb with backtrace below (the one posted here is actually from kern.ipc.maxsockets being 17000) My kernel config is basically GENERIC with stripped HW the machine doesn't dontain. - verbose booting - /boot/kernel/kernel text=0x209c10 data=0x2ae18+0x3d54c syms=[0x4+0x2da40+0x4+0x37495] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x380ec data=0x1a38+0xae8 syms=[0x4+0x56e0+0x4+0x733b] SMAP type=01 base= len= 0009f000 SMAP type=02 base= 0009f000 len= 1000 SMAP type=02 base= 000f len= 0001 SMAP type=01 base= 0010 len= 1fefd000 SMAP type=03 base= 1fffd000 len= 2000 SMAP type=04 base= 1000 len= 1000 SMAP type=02 base= fec0 len= 1000 SMAP type=02 base= fee0 len= 1000 SMAP type=02 base= len= 0001 Copyright (c) 1992-2002 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: Thu Oct 31 15:34:37 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TESTIK Preloaded elf kernel "/boot/kernel/kernel" at 0xc0422000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04220a8. Calibrating clock(s) ... TSC clock: 751634930 Hz, i8254 clock: 1193071 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (751.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 536858624 (524276K bytes) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0044c000 - 0x1ffbcfff, 532090880 bytes (129905 pages) avail memory = 515866624 (503776K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00f9e20 bios32: Entry = 0xf0530 (c00f0530) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x730 pnpbios: Found PnP BIOS data at 0xc00fd270 pnpbios: Entry = f:d2a0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Initializing GEOMetry subsystem null: random: mem: Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x80002358 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 6 entries at 0xc00f0d20 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 1 0 12A 0x60 3 4 5 7 9 10 11 12 slot 1 0 12B 0x61 3 4 5 7 9 10 11 12 slot 1 0 12C 0x62 3 4 5 7 9 10 11 12 slot 1 0 12D 0x63 3 4 5 7 9 10 11 12 slot 2 0 11A 0x61 3 4 5 7 9 10 11 12 slot 2 0 11B 0x62 3 4 5 7 9 10 11 12 slot 2 0 11C 0x63 3 4 5 7 9 10 11 12 slot 2 0 11D 0x60 3 4 5 7 9 10 11 12 slot 3 0 10A 0x62 3 4 5 7 9 10 11 12 slot 3 0 10B 0x63 3 4 5 7 9 10 11 12 slot 3 0 10C 0x60 3 4 5 7 9 10 11 12 slot 3 0 10D 0x61 3 4 5 7 9 10 11 12 slot 4 09A 0x63 3 4 5 7 9 10 11 12 slot 4 09B 0x60 3 4 5 7 9 10 11 12 slot 4 09C 0x61 3 4 5 7 9 10 11 12 slot 4 09D 0x62 3 4 5 7 9 10 11
Re: cvs commit: src/sys/fs/specfs spec_vnops.c
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2002/11/01 07:32:12 PST
>
> Modified files:
>sys/fs/specfsspec_vnops.c
> Log:
> Put a KASSERT in specfs::strategy() to check that the incoming buffer
> has a valid b_iocmd. Valid is any one of BIO_{READ,WRITE,DELETE}.
>
> I have seen at least one case where the bio_cmd field was zero once the
> request made it into GEOM. Putting the KASSERT here allows us to spot
> the culprit in the backtrace.
If any of you encounter this panic ("Wrong b_iocmd buf...") please
try to capture a traceback and mail it to me.
This is likely connected to the problems Kirk are debugging right now
and may be responsible for some of the weirder Heisenbugs people have
reported.
Worst case, (before this commit) it could result in a read request
being carried out as a write request by a disk device driver.
--
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: fsck / and remount failure
On Sun, 27 Oct 2002, Sean Kelly wrote: > On Sun, Oct 27, 2002 at 05:17:44PM -0500, Robert Watson wrote: > > Are you using UFS1 extended attributes on that box? > > Yes. > (290) smkelly@edgemaster:~$ grep UFS /usr/src/sys/i386/conf/EDGEMASTER > options UFS_DIRHASH > options UFS_EXTATTR > options UFS_EXTATTR_AUTOSTART > options UFS_ACL > > > I suspect there might > > be a bug involving the open flags passed to extended attribute backing > > vnodes such that a remount is refused because there are existing vnodes > > opened writable. I.e., the extended attribute backing files are opened > > FREAD|FWRITE, and since the file system is mounted read-only, remount > > refuses to upgrade to a rw mount until they are closed. My guess is that, > > in fact, this should be permitted, or we should re-open the backing files > > on a remount. I'd like to get this bug fixed, but it is another reason to > > recommend UFS2 over UFS1. > > That would make sense. I had never considered the backing files being > the cause of it. If necessary, I can rebuild my kernel without ACLs and > EXTATTRs to see if that cures the problem. I suspect it will cure the problem, and I suspect the real solution is that we need to open the backing files with flags based on the mount flags (read-only or not), and restart EAs on a remount, allowing the files to be re-opened with the write flag if needed. > I haven't switched to UFS2 for a few reasons: > * I don't know what state it is in (can I boot from it on x86?) This is probably a question for phk -- my understanding is that we're either there, or we're very close on the boot issue for i386. I'm using it in several places on i386 as non-boot, and on sparc64 as the boot file system pretty successfully. > * I don't know how stable it is now It seems to be pretty stable, and if it's not, we'd really like to find out. Because it largely relies on existing UFS1 logic, the chances of it being stable are a lot higher than if it was a "from scratch" implementation. > * I don't really want to have to go through the hassle of backing up and > restoring all my data right now. Oh what I'd give for a conversion tool. > Hello? Partition Magic people? *shakes wallet* We talked about implementing a conversion tool from UFS1->UFS2, and decided it would take more resources than we had easily available, and that the risks associated with a tool would be high. The backup/restore solution is a pain, but the one that is most likely to be successful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "... could sleep with "pcm0" locked from ..."
> > > > [...] > > > > Anyone knows why / what to do ? > > > > -- Aurélien > > It does the same thing on my machine, but sound still works :) > > I don't know how to fix it...I look forward to somebody hopefully > enlightening us :) > > Bon FreeBSD, > > Mike Yep, sound still works but the box takes heavy loads each time :/ -- Aurélien msg45855/pgp0.pgp Description: PGP signature
ypbind doesn't work right on freshly installed machines
I installed two machines with fresh current snapshots last night and this morning. One was an i386 box the other a sparc64 box. Both machines are NIS clients from the same server. I do have other 5.x and 4.x boxes on the same LAN at home that also are NIS clients of the same server (the server is 4.7 box). All my other machines work fine. However, for the two freshly installed test boxs, ypbind doesn't find a server the first time it is run during /etc/rc startup. If I login as root and run 'ypbind' again then it works fine. All my other 5.x boxes which are not fresh installs do not have this problem. Anyone have any ideas? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "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
sysinstall alpha problems...
I updated to 5.0-current using the "." tag because I wanted SMP support for our development AlphaServer 1200 that was otherwise gathering dust. I added some new disks and wanted to do a sysinstall to label and newfs them. So running /usr/sbin/sysinstall built from the sources of today sysinstall simply core dumps on the device probe section. I tried adding a -g to cflags in its makefile but couldn't coax gdb into spitting out anything more useful. Here is what I get: Probing devices, please wait (this can take a while)...Segmentation fault (core dumped) Based on the fact it seems to be dying inside a call to strtoul I'm guessing its integer size related so it probably won't show on ix86. If someone can direct me further I can do more to help in debugging this... alpha# gdb /usr/sbin/sysinstall -c sysinstall.core GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-undermydesk-freebsd"...(no debugging symbols found)... Core was generated by `sysinstall'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libdialog.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdialog.so.4 Reading symbols from /usr/lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libncurses.so.5 Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libutil.so.3 Reading symbols from /usr/lib/libftpio.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libftpio.so.5 Reading symbols from /usr/lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x160242644 in strtoul () from /usr/lib/libc.so.5 (gdb) bt #0 0x160242644 in strtoul () from /usr/lib/libc.so.5 (gdb) Here is a little system info: FreeBSD alpha.interchange.ca 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 31 01:54:22 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOATANCHOR alpha alpha# gcc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) This system was installed as a 4.7-alpha and then upgraded via a cvsup and makeworld/installworld. -Michael _ http://fastmail.ca/ - Fast Secure Web Email for Canadians
Re: sysinstall alpha problems...
In message <[EMAIL PROTECTED]>, "Michael Richards" writes : > >--Boundary-00=_R7WWAEEZ5BZNTT4D7TH0 >Content-Type: Text/Plain >Content-Transfer-Encoding: 7bit > >I updated to 5.0-current using the "." tag because I wanted SMP >support for our development AlphaServer 1200 that was otherwise >gathering dust. > >I added some new disks and wanted to do a sysinstall to label and >newfs them. So running /usr/sbin/sysinstall built from the sources of >today sysinstall simply core dumps on the device probe section. I >tried adding a -g to cflags in its makefile but couldn't coax gdb >into spitting out anything more useful. > >Here is what I get: >Probing devices, please wait (this can take a while)...Segmentation >fault (core dumped) Ok, first make sure that your machine is running a -current kernel. If it does that, then: add to the src/lib/libdisk/Makefile: CFLAGS += -g in src/lib/libdisk: make obj make depend make clean make all install add to src/usr.sbin/sysinstall/Makefile CFLAGS += -static -g in src/usr.sbin/sysinstall: make obj make depend make clean make all install Now, try again and see if you don't get a more useful core file. (I'm very interested in this because we have not yet validated libdisk/sysinstall on alpha machines after the last changes.) -- 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: sysinstall alpha problems...
> Ok, first make sure that your machine is running a -current > kernel. FreeBSD 5.0-CURRENT #0: Thu Oct 31 01:54:22 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOATANCHOR Preloaded elf kernel "/boot/kernel/kernel" at 0xfc69a000. AlphaServer 4100 AlphaServer 1200 5/533 4MB, 531MHz 8192 byte page size, 2 processors. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x4000200020117 real memory = 266330112 (260088K bytes) avail memory = 252575744 (246656K bytes) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > If it does that, then: > > add to the src/lib/libdisk/Makefile: > CFLAGS += -g > in src/lib/libdisk: > make obj > make depend > make clean > make all install > add to src/usr.sbin/sysinstall/Makefile > CFLAGS += -static -g > in src/usr.sbin/sysinstall: > make obj > make depend > make clean > make all install > > Now, try again and see if you don't get a more useful core file. I did all the steps above. The results are probably less helpful but I'm still game to more instructions. GDB was hitting its heuristic fence-post trying to load the core file so I ran the sysinstall in the obj directory since it wasn't stripped. This may be a bug in gdb that's hiding. Here is what I get running the non-stripped version. alpha# gdb -c sysinstall.core /usr/obj/usr/src/usr.sbin/sysinstall/sysinstall GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-undermydesk-freebsd"... Core was generated by `sysinstall'. Program terminated with signal 11, Segmentation fault. #0 0x12008f764 in strtoul () (gdb) bt #0 0x12008f764 in strtoul () #1 0x1200aa000 in tcflow () #2 0x120084e40 in strdup () #3 0x1200aa000 in tcflow () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x1201d6000 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. I did a quick search for tcflow but I think it's in some other library that got linked in there. -Michael _ http://fastmail.ca/ - Fast Secure Web Email for Canadians
Re: sysinstall alpha problems...
In message <[EMAIL PROTECTED]>, "Michael Richards" writes : > >--Boundary-00=_GTXW0ZNZ5BZNTT4D7TH0 >Content-Type: Text/Plain >Content-Transfer-Encoding: 7bit > >> Ok, first make sure that your machine is running a -current >> kernel. 1st thing: Make sure you have removed the NO_GEOM option from your kernel config, sysinstall/libdisk only works with GEOM kernels. if that is not it: 2nd OK, now we'll get tough :-) cd /usr/src/lib/libdisk make tst01 echo quit | /usr/obj/`pwd`/tst01 $DISK where $DISK is the name of your disks (ie: "ad0", "da0" etc etc) This will show you what the libdisk library thinks about your disks. I'd like to see the output, along with the output from: sysctl -n kern.geom.conftxt -- 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: ypbind doesn't work right on freshly installed machines
Per our discussion out-of-band, and just for the reference of others who might have the same question, forced dependencies for rpcbind from ypserv and ypbind aren't present right now, you can work around by explicitly enabling rpcbind in rc.conf. You might actually see rpcbind running later in boot, but it's from another forced dependency that is present. The symptom of this is that ypbind silently fails if the RPC port mapper isn't present :-(. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Fri, 1 Nov 2002, John Baldwin wrote: > I installed two machines with fresh current snapshots last night > and this morning. One was an i386 box the other a sparc64 box. > Both machines are NIS clients from the same server. I do have > other 5.x and 4.x boxes on the same LAN at home that also are NIS > clients of the same server (the server is 4.7 box). All my other > machines work fine. However, for the two freshly installed > test boxs, ypbind doesn't find a server the first time it is run > during /etc/rc startup. If I login as root and run 'ypbind' again > then it works fine. All my other 5.x boxes which are not fresh > installs do not have this problem. Anyone have any ideas? > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "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: another include failure to find in buildworld
On Fri, Nov 01, 2002 at 07:23:04AM +, Daniel Flickinger wrote: > > This is another instance where the build is not reading > from the /usr/obj tree, reading from /usr/include first. I don't think so. You cannot do cross-builds if you're messing up the include searches. I would suggest you check out a clean source tree, revert /usr/include to a state where you know it failed before (ie remove /usr/include/uuid.h for example) and start a *non-parallel* build without any options like -k or -s for target buildworld *AFTER* validating and preferrably nuking /etc/make/.conf. There's really no point complaining on the list about breakages that you only see. If the failure is real, we at least need to be able to reproduce it before we can fix it and so far you're the only one with problems. I'll do the same to make sure my claim that you're the only one who sees this has been verified for me for the latest sources... -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hi there. I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G harddrive, which is the second one on the system. Sysinstall failed to get the right geometry of the disk, even though the BIOS was in LBA mode. My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. The DOS partition (ad1s2) on the harddrive was just right, and nothing wrong it, but only the FreeBSD partitions messed up. I made a 8G partition on the front of the disk (ad1s1), in which I was planning to install FreeBSD. Now, I am not sure what the real cause is, i.e. why are we not allowed to install on an 8G partition on a 120G disk? It could be that I am doing something very wrong, but I would like to get to the bottom of this, as I lost about 15G worth of data, i.e. fdisk still shows that the partition is there, but fsck_ffs is not proceeding. This could be because of GEOM or something, but I am not sure, as I cannot try a non-GEOM sysinstall anyway. Also, is there a way I can get that 15G worth of data back, somehow, or do I just have to say bye-bye to it? All help will be appreciated. Cheers. -- Hiten [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: another include failure to find in buildworld
On Fri, Nov 01, 2002 at 12:50:38PM -0800, Marcel Moolenaar wrote: > On Fri, Nov 01, 2002 at 07:23:04AM +, Daniel Flickinger wrote: > > > > This is another instance where the build is not reading > > from the /usr/obj tree, reading from /usr/include first. > > I don't think so. You cannot do cross-builds if you're messing > up the include searches. I would suggest you check out a clean > source tree, revert /usr/include to a state where you know it > failed before (ie remove /usr/include/uuid.h for example) and > start a *non-parallel* build without any options like -k or -s > for target buildworld *AFTER* validating and preferrably nuking > /etc/make/.conf. There's really no point complaining on the list > about breakages that you only see. If the failure is real, we at > least need to be able to reproduce it before we can fix it and > so far you're the only one with problems. > > I'll do the same to make sure my claim that you're the only one > who sees this has been verified for me for the latest sources... > Don't waste your time, Marcel. Unless Daniel has changed his build procedure, he uses a custom script to do the builds. See http://www.freebsd.org/cgi/getmsg.cgi?fetch=491021+500131+/usr/local/www/db/text/2002/freebsd-current/20021020.freebsd-current -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH]Re: crash with network load (in tcp syncache ?)
Michal Mertl wrote:
> I'm getting panics on SMP -CURRENT while running apachebench (binary ab
> from apache distribution, not the Perl one) against httpd on the machine.
>
> The panics don't occur when I have WITNESS and INVARIANTS turned on.
[ ... ]
> #10 0xc01bd46f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
> #11 0xc01f7e1e in sofree (so=0xc58f05d0) at
> /usr/src/sys/kern/uipc_socket.c:312
> #12 0xc01fa508 in sonewconn (head=0xc43874d8, connstatus=2)
> at /usr/src/sys/kern/uipc_socket2.c:208
> #13 0xc023f42f in syncache_socket (sc=0x2, lso=0xc43874d8, m=0xc1662200)
> at /usr/src/sys/netinet/tcp_syncache.c:564
> #14 0xc023f748 in syncache_expand (inc=0xd6a62b3c, th=0xc1f6c834,
> sop=0xd6a62b10, m=0xc1662200)
> /usr/src/sys/netinet/tcp_syncache.c:783
> #15 0xc0239978 in tcp_input (m=0xc1f6c834, off0=20)
> at /usr/src/sys/netinet/tcp_input.c:713
soreserve is called to get mbufs reserved to the socket, and
sbreserve is called, and this fails, because you have too few
mbufs in your system for the number of connections you have
configured.
This is a problem because the sotryfree() in sonewconn() (see
the definition in sys/socketvar.h) sees a so_count of zero, and
calls sofree() directly.
The sofree() fails because the socket is not enqueued as being
an incomplete connection, and not enqueued as being a complete
connection (not on a queue, and so_state does not have SS_INCOMP
or SS_COMP flags set).
Basically, this code dies not expect to be called in this case,
and the call occurs because the SYN cache code runs at NETISR.
Personally, I do not understand why a prereservation for mbufs
is necessary in this particular case: if you are out of mbufs,
the packets should end up dropped, in any case, so it should not
matter. I guess it's an attempt to "protect you" from massive
connection attempts acting as a denial of service attack.
One "fix" would be to reference the socket before making the
call, in syncache_socket(). The basically correct way to do
this would be to invert the order of the "if" test in sonewconn()
(see attached patch).
This can also fail, though: if the protocol attach fails, then
it will still panic. Also, if the protocol attach doesn't fail,
and there's an soabort(), if the protocol detach fails, it will
still call sotryfree() in the abort... and, once again, panic.
My suggestion:
1) Try the attached patch; it will probably cover up the
problem for you.
2) Make sure you don't put the number of connections you
allow to be larger than the number of mbufs, divided
by 2, divided by the number of mbufs you have set in
the net.inet.tcp.recvspace (i.e.: Do Not Overcommit
Mbufs).
3) Disable the use of "SYN cookies", e.g.:
sysctl net.inet.tcp.syncookies=0
SYN cookies are incredibly evil, and will put pressure
on your resources by drastically increasing pool retention
time, if they end up being invoked.
-- Terry
Index: uipc_socket2.c
===
RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.104
diff -c -r1.104 uipc_socket2.c
*** uipc_socket2.c 18 Sep 2002 19:44:11 - 1.104
--- uipc_socket2.c 1 Nov 2002 17:16:39 -
***
*** 203,210
#ifdef MAC
mac_create_socket_from_socket(head, so);
#endif
! if (soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat) ||
! (*so->so_proto->pr_usrreqs->pru_attach)(so, 0, NULL)) {
sotryfree(so);
return ((struct socket *)0);
}
--- 203,210
#ifdef MAC
mac_create_socket_from_socket(head, so);
#endif
! if ((*so->so_proto->pr_usrreqs->pru_attach)(so, 0, NULL) ||
! soreserve(so, head->so_snd.sb_hiwat, head->so_rcv.sb_hiwat)) {
sotryfree(so);
return ((struct socket *)0);
}
Re: another include failure to find in buildworld
On Fri, Nov 01, 2002 at 12:59:33PM -0800, Steve Kargl wrote: > On Fri, Nov 01, 2002 at 12:50:38PM -0800, Marcel Moolenaar wrote: > > On Fri, Nov 01, 2002 at 07:23:04AM +, Daniel Flickinger wrote: > > > > > > This is another instance where the build is not reading > > > from the /usr/obj tree, reading from /usr/include first. > > > > I don't think so. You cannot do cross-builds if you're messing > > up the include searches. I would suggest you check out a clean > > source tree, revert /usr/include to a state where you know it > > failed before (ie remove /usr/include/uuid.h for example) and > > start a *non-parallel* build without any options like -k or -s > > for target buildworld *AFTER* validating and preferrably nuking > > /etc/make/.conf. There's really no point complaining on the list > > about breakages that you only see. If the failure is real, we at > > least need to be able to reproduce it before we can fix it and > > so far you're the only one with problems. > > > > I'll do the same to make sure my claim that you're the only one > > who sees this has been verified for me for the latest sources... > > > > Don't waste your time, Marcel. Unless Daniel has changed his > build procedure, he uses a custom script to do the builds. See > > >http://www.freebsd.org/cgi/getmsg.cgi?fetch=491021+500131+/usr/local/www/db/text/2002/freebsd-current/20021020.freebsd-current Thanks Steve! That's vital information... The buildworld script is broken on two accounts: 1. it does an installincludes after completely cleaning the object tree and thus is very likely failing because buildincludes is not run. This may be hidden by -k. 2. it's obviously not delivering on its primary objective of reducing the marging of error. In fact, it may even contribute to the error because of the excessive use of -k and redirecting to /dev/null. Adding NO_WERROR by default seems to defeat the purpose as well. In any event, one would want two successive 'make cleandir' runs if one wants to be sure everything is as clean as possible. Other than that, I don't see why the script itself is causing the make buildworld to fail. It increases the chance that the source tree is borked or deliberately modified (which may be equivalent statements :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
On Fri, Nov 01, 2002 at 08:56:44PM +, Hiten Pandya wrote the words in effect of: > Hi there. > > I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G > harddrive, which is the second one on the system. Sysinstall failed to get > the right geometry of the disk, even though the BIOS was in LBA mode. > > My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. > The DOS partition (ad1s2) on the harddrive was just right, and nothing > wrong it, but only the FreeBSD partitions messed up. > > I made a 8G partition on the front of the disk (ad1s1), in which I was > planning to install FreeBSD. Now, I am not sure what the real cause is, > i.e. why are we not allowed to install on an 8G partition on a 120G disk? > > It could be that I am doing something very wrong, but I would like to get > to the bottom of this, as I lost about 15G worth of data, i.e. fdisk still > shows that the partition is there, but fsck_ffs is not proceeding. This > could be because of GEOM or something, but I am not sure, as I cannot try a > non-GEOM sysinstall anyway. > > Also, is there a way I can get that 15G worth of data back, somehow, or do > I just have to say bye-bye to it? > > All help will be appreciated. > Cheers. > Please let me know what type of information is needed for debugging this problem. Cheers. -- Hiten Pandya [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A few questions
On Thu, Oct 31, 2002 at 06:39:00PM -0600, Conrad Sabatier wrote: > I just upgraded a 4.7-STABLE box to current over the weekend. Went off > very well, thanks to the great documentation in UPDATING. > > It's odd, though, that after upgrading again just a few days later, > suddenly X (or perhaps just xdm) failed to start due to an unresolved > symbol. I had already upgraded X, as well as many other ports, after > upgrading to -current, btw. What symbol? > It seems very peculiar that a cvsup just a few days apart from the previous > one would require X to be rebuilt. What dates? Kris msg45868/pgp0.pgp Description: PGP signature
-current marcketting name?
SO ok, we need a good marketting name for 5.0.. Off the top of my head FreeBSD 5.0 "banana" :-) slug, monkey, heffalump, peach, blender... :-) blackjack (It's a gamble) tahoe, reno amd vegas are gone, but "silver city" is up for grabs :-) p.s. while the names suggested are humourous I am very serious about needing some name upon which we can hang some hoopla. Jaguar.. uh rats... wolfpack, scout, vanguard.. I dunno.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash with network load (in tcp syncache ?)
sonewconn() hands sofree() a self-inconsistent socket -- so->so_head is
set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet.
Please try this patch.
Bill
Index: uipc_socket2.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.104
diff -u -r1.104 uipc_socket2.c
--- uipc_socket2.c 18 Sep 2002 19:44:11 - 1.104
+++ uipc_socket2.c 1 Nov 2002 22:40:52 -
@@ -192,7 +192,7 @@
return ((struct socket *)0);
if ((head->so_options & SO_ACCEPTFILTER) != 0)
connstatus = 0;
- so->so_head = head;
+ so->so_head = NULL;
so->so_type = head->so_type;
so->so_options = head->so_options &~ SO_ACCEPTCONN;
so->so_linger = head->so_linger;
@@ -209,6 +209,7 @@
return ((struct socket *)0);
}
+ so->so_head = head;
if (connstatus) {
TAILQ_INSERT_TAIL(&head->so_comp, so, so_list);
so->so_state |= SS_COMP;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ypbind doesn't work right on freshly installed machines
This is fixed in my WIP on rc.d . I'm more or less ready for wider review; I especially need review of the atm and diskless changes. Bill http://people.freebsd.org/~fenner/rc.d.diff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 1 15:10:57 PST 2002 -- >>> Kernel build for GENERIC completed on Fri Nov 1 15:43:05 PST 2002 -- >>> Kernel build for LINT started on Fri Nov 1 15:43:05 PST 2002 -- ===> vinum "Makefile", line 4517: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ypbind doesn't work right on freshly installed machines
BTW, /etc/rc.network never tried to save you from rpcbind_enable=NO nis_client_enable=YES so it may be a mistake for /etc/rc.d/* to try to. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ypbind doesn't work right on freshly installed machines
On Fri, Nov 01, 2002 at 04:23:02PM -0800, Bill Fenner wrote: > > BTW, /etc/rc.network never tried to save you from > > rpcbind_enable=NO > nis_client_enable=YES > > so it may be a mistake for /etc/rc.d/* to try to. /etc/rc does though: chkdepend amd amd_enablerpcbind rpcbind_enable chkdepend amd amd_enableNFS nfs_client_enable chkdepend NFS nfs_server_enable rpcbind rpcbind_enable chkdepend NIS nis_server_enable rpcbind rpcbind_enable chkdepend NIS nis_client_enable rpcbind rpcbind_enable -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg45874/pgp0.pgp Description: PGP signature
Re: ypbind doesn't work right on freshly installed machines
Oops, you're right, I was looking too closely =) Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash with network load (in tcp syncache ?)
Bill Fenner wrote: > sonewconn() hands sofree() a self-inconsistent socket -- so->so_head is > set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet. > Please try this patch. I think this can still crash (just like my patch); the problem is in what happens when it fails to allocate memory. Unless you set one of the flags, it's still going to panic in the same place, I think, when you run out of memory. The code that the SYN-cache uses really needs to be refactored, and seperated out. The problem is that the delay in allocation is intentional, to permit the cache to deal with lighter weight instances, until it decides to actually create a connection. There's not a clean way to do this, really, without passing the address of the socket pointer down, and having lower level code fill it out, I think. 8-(. The problem is definitely based on what happens in the allocation or protocol attach failure cases. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash with network load (in tcp syncache ?)
>I think this can still crash (just like my patch); the problem is in >what happens when it fails to allocate memory. Unless you set one of >the flags, it's still going to panic in the same place, I think, when >you run out of memory. No. The flags are only checked when so_head is not NULL. sonewconn() was handing sofree() an inconsistent struct so (so_head was set without being on either queue), i.e. sonewconn() was creating an invalid data structure. The call in sonewconn() used to be to sodealloc(), which didn't care about whether or not the data structure was self-consistent. The code was refactored to do reference counting, but the fact that the socket was inconsistent at that point wasn't noticed until now. The problem is not at all based on what happens in the allocation or protocol attach failure cases. The SYN cache is not involved, this is a bug in sonewconn(), plain and simple. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-20021101-CURRENT snap & iso
For all you weekend install warriors out there... There is a new 5.0 snap & iso available via anonymous ftp at: usw2.FreeBSD.Org /pub/FreeBSD/snapshots/i386/5.0-20021101-CURRENT and the iso: /pub/FreeBSD/snapshots/i386/5.0-20021101-CURRENT.iso I have verified that this iso boots and can reference itself for a CD/DVD install. The only (non-critical) problem I've seen so far is refresh problems within sysinstall. Many thanks to those who downloaded and tested the previous (not exactly working) iso and provided feedback. -John ps: This iso does not contain the ports tree. Cvsup it at your leisure. Pkg_add is your friend. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crash with network load (in tcp syncache ?)
Bill Fenner wrote: > >I think this can still crash (just like my patch); the problem is in > >what happens when it fails to allocate memory. Unless you set one of > >the flags, it's still going to panic in the same place, I think, when > >you run out of memory. > > No. The flags are only checked when so_head is not NULL. sonewconn() > was handing sofree() an inconsistent struct so (so_head was set without > being on either queue), i.e. sonewconn() was creating an invalid data > structure. You're right... I missed that; I was thinking too hard on the other situations (e.g. soabort()) that could trigger that code, and no enough on the code itself. > The call in sonewconn() used to be to sodealloc(), which didn't care > about whether or not the data structure was self-consistent. The code > was refactored to do reference counting, but the fact that the socket > was inconsistent at that point wasn't noticed until now. Yeah; I looked at doing a ref() of the thing as a partial fix, but the unref() did the sotryfree() anyway. > The problem is not at all based on what happens in the allocation or > protocol attach failure cases. The SYN cache is not involved, this is > a bug in sonewconn(), plain and simple. I still think there is a potential failure case, but the amount of code you'd have to read through to follow it is immense. It has to do with the conection completing at NETISR, instead of in a process context, in the allocation failure case. I ran into the same issue when trying to run connections to completion up to the accept() at interrupt, in the LRP case. The SYN cache case is very similar, in the case of a cookie that hits when there are no resources remaining. He might be able to trigger it with his setup, by setting the cache size way, way don, and thus relying on cookies, and then flooding it with conection requests until he runs it out of resources. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hiten Pandya wrote: Hi there. I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G harddrive, which is the second one on the system. Sysinstall failed to get the right geometry of the disk, even though the BIOS was in LBA mode. My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. Sorry, I'm not understanding that sentence. Is there a typographical error in there somewhere, perhaps? 1000MB + 128MB <> 50GB The DOS partition (ad1s2) on the harddrive was just right, and nothing wrong it, but only the FreeBSD partitions messed up. Sorry, I'm still confused. You have two different FBSD partitions on the same disk (s3 and s1)? I made a 8G partition on the front of the disk (ad1s1), in which I was planning to install FreeBSD. Now, I am not sure what the real cause is, i.e. why are we not allowed to install on an 8G partition on a 120G disk? No reason. It should work. Is the install failing at some point with error messages? Did the install finish but now you can't boot the new system? It could be that I am doing something very wrong, but I would like to get to the bottom of this, as I lost about 15G worth of data, I'm confused again. Data on the FreeBSD partition? Which FBSD partition? How did the data get there and in what way is it lost now, exactly? i.e. fdisk still shows that the partition is there, but fsck_ffs is not proceeding. You mean when you try to boot the 8GB partition, or the 50GB partition? Is fsck complaining about something? What is it saying? Please be very specific about error messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall alpha problems...
> 1st thing: > Make sure you have removed the NO_GEOM option from your > kernel config, sysinstall/libdisk only works with GEOM > kernels. This was the problem. I think sysinstall should have a graceful way to detect this and return a complaint to the user rather than return a corefile. Now, more bugs... Maybe sysinstall has changed, but I can't seem to find any way to partition these drives. One was previously partitioned on an i386 box so I've at least been able to fool with it. 1) With try creating a filesystem C, for the size enter 1M. The error says "The minimum filesystem size is 1MB) 2) If you hit "A" for auto defaults all it will create the following for me: da2a / 128MB UFS Y da2b swap 507MB SWAP da2d /var 256MB UFS+S Y da2e /tmp 256MB UFS+S Y da2f /usr 7535MB UFS+S Y Recreating them manually works if and only if the mount points are copied. That is to say, if I'm trying to make a copy from a live system, I can't create a da2a by specifying the mount point as /mnt/temproot in order to copy the files from it. I think this is more of an oversight than a bug since it chooses the device name based on the mount point. 3) once I've finally specified my filesystem. In this case it's: da2d /dr/dr02 8683MB UFS+S Y I hit "W" and it flashes some errors up on the screen and pops an error dialog box saying: ERROR: Unable to write data to disk da2! After that you can't touch the disk because it complains it was already written. The only way is of you exit sysinstall. I think that little flag in the software should only get set if it was written successfully. As for why it's not writing, I don't know. I tried finding MAKEDEV and running it on da2. crw-r- 1 root operator4, 2 Nov 1 17:54 /dev/da2 crw-r- 1 root operator4, 14 Nov 1 17:54 /dev/da2b crw-r- 1 root operator4, 15 Nov 1 17:54 /dev/da2c crw-r- 1 root operator4, 16 Nov 1 17:54 /dev/da2e crw-r- 1 root operator4, 17 Nov 1 17:54 /dev/da2f crw-r- 1 root operator4, 18 Nov 1 17:54 /dev/da2g So the devices exist. I think the 2 disks are set up properly but I'll have to watch it boot just to make 100% sure they didn't end up on the same ID. da1 at ahc0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da2 at ahc0 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) That's all I can come up with so far. My apologies if I'm not doing anything right... After all it's Friday and I should be off drinking beer. -Michael _ http://fastmail.ca/ - Fast Secure Web Email for Canadians
boot0 problem?
OK, I've installed 20021102-JPSNAP to fresh 80GB disk on my P-III x 2 box from floppy and ftp and finishes fine. But I cannot boot it. I used "BootMgr" in sysinstall. When I booted after install, it stopped at: - F1 FreeBSD Default: F1 - At this, pushing [F1] or [Enter] causes beeping but not go to next stage. Is there someone who has successfully installed recent -current with BootMgr? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic from dd to ATA disk
I'm getting the following panic on one of the bento cluster machines. The machine has a single drive: ad0: 29314MB [59560/16/63] at ata0-master UDMA66 and I have it set up to zero the disk at boot-time (the machine boots "diskless" via NFS): dd if=/dev/zero of=/dev/ad0 bs=64k load: 0.02 cmd: dd 413 [physstr] 0.01u 4.50s 0% 248k 31296+0 records in 31295+0 records out 2050949120 bytes transferred in 198.151980 secs (10350384 bytes/sec) ad0: WRITE command timeout tag=0 serv=0 - resetting ata0: resetting devices .. ad0: removed from configuration Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc01966e0 stack pointer = 0x10:0xcd235c48 frame pointer = 0x10:0xcd235c70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: tty:sio clock) kernel: type 12 trap, code=0 Stopped at ad_detach+0x50: cmpl%esi,0(%ebx) db> Context switches not allowed in the debugger. db> trace ad_detach(c0f18430,0,c03e028b,c2718cc0,c26dfa00) at ad_detach+0x50 ata_reinit(c0f18400,c2718cc0,c03e2333,0,0) at ata_reinit+0x9b ad_timeout(c2718cc0,0,c03fe6cb,bf,9f43) at ad_timeout+0x158 softclock(0,0,c03fb39c,230,c0f24a80) at softclock+0x19c ithread_loop(c0f17a00,cd235d48,c03fb0ed,354,ac64) at ithread_loop+0x182 fork_exit(c0238ab0,c0f17a00,cd235d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd235d7c, ebp = 0 --- msg45883/pgp0.pgp Description: PGP signature
Re: boot0 problem?
At Sat, 2 Nov 2002 02:03:48 + (UTC), kuriyama wrote: > I used "BootMgr" in sysinstall. When I booted after install, it > stopped at: > > - > F1 FreeBSD > > Default: F1 > - Oops, I set "LBA" in BIOS explicitly, it booted fine. Hmm, it's my bad to believe BISO "Auto" setting... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A few questions
On 01-Nov-2002 Conrad Sabatier wrote: > I just upgraded a 4.7-STABLE box to current over the weekend. Went off > very well, thanks to the great documentation in UPDATING. > > It's odd, though, that after upgrading again just a few days later, > suddenly X (or perhaps just xdm) failed to start due to an unresolved > symbol. I had already upgraded X, as well as many other ports, after > upgrading to -current, btw. > > It seems very peculiar that a cvsup just a few days apart from the > previous one would require X to be rebuilt. OK, turned out it was a mismatched gtk/glib combination. > On another note, can someone clue me in as to why I'm getting all these > "duplicate script" errors when building both ports and world? I've > looked high and low and can't find the reason for this. Seems harmless > enough, but it *is* just slightly annoying. And these seem to have pretty much disappeared as well. Still no idea what was causing them. > And finally, is there a simple way to ensure that none of the debugging > code (including INVARIANTS stuff) is included during a buildworld? > It would be nice if there were a simple switch or environment variable to > control this. Now *this* I would still be interested to know about. -- Conrad Sabatier <[EMAIL PROTECTED]> Liar, n.: A lawyer with a roving commission. -- Ambrose Bierce, "The Devil's Dictionary" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent panics in -current
I recently came across a dual MP 2000 and installed a snapshot of
10/29, then did a few buildworlds to check out the speed. I then
upgraded to -current as of day and various times of today and started
getting this. Does anyone have any clues. It usually happens during
periods of high cpu and disk activity, like make -j25 buildworld.
Does anyone have any clue what is going on here? Let me know if I need
to provide any more details(which I am sure I do).
panic: vrele:negative ref cnt
cpuid=0;lapic.id=0100
Debugger("panic")
stopped at Debugger+0x4e: xchgl %ebx,in_debugger.0
Timecounter "i8254" frequency 1193182 Hz
CPU: AMD Athlon(tm) MP 2000+ (1659.27-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x662 Stepping = 2
Features=0x383fbff
AMD Features=0xc048
real memory = 1073676288 (1048512K bytes)
avail memory = 1036312576 (1012024K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee0
cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
--
David W. Chapman Jr.
[EMAIL PROTECTED] Raintree Network Services, Inc.
[EMAIL PROTECTED] FreeBSD Committer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic from dd to ATA disk
> 2050949120 bytes transferred in 198.151980 secs (10350384 bytes/sec) > ad0: WRITE command timeout tag=0 serv=0 - resetting > ata0: resetting devices .. > ad0: removed from configuration While I don't remember if my panic was the same, the above message is what I have been seeing recently as well in times of high disk activity. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
What is user uucp good for?
Now that uucp is no longer in the base system, is there any reason to keep user uucp in /usr/src/etc/master.passwd? Greg -- 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: A few questions
On 01-Nov-2002 Kris Kennaway wrote: > On Thu, Oct 31, 2002 at 06:39:00PM -0600, Conrad Sabatier wrote: >> I just upgraded a 4.7-STABLE box to current over the weekend. Went off >> very well, thanks to the great documentation in UPDATING. >> >> It's odd, though, that after upgrading again just a few days later, >> suddenly X (or perhaps just xdm) failed to start due to an unresolved >> symbol. I had already upgraded X, as well as many other ports, after >> upgrading to -current, btw. > > What symbol? The symbol was __sF, if I remember correctly. Turned out to be ports-related (out of sync port upgrades). >> It seems very peculiar that a cvsup just a few days apart from the >> previous one would require X to be rebuilt. > > What dates? OK, OK, I know. I could have provided more details. :-) Sorry for the noise. -- Conrad Sabatier <[EMAIL PROTECTED]> "At least they're __EXPERIENCED incompetents" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A few questions
On 01-Nov-2002 Giorgos Keramidas wrote: > On 2002-10-31 18:39, Conrad Sabatier <[EMAIL PROTECTED]> wrote: >> [...] >> And finally, is there a simple way to ensure that none of the debugging >> code (including INVARIANTS stuff) is included during a buildworld? > > INVARIANTS and WITNESS are kernel-only stuff. They shouldn't affect > your userland programs. If they do, it's probably a bug. I just happened to notice this: $ grep -r 'CFLAGS.*INVARIANTS' /usr/src /usr/src/gnu/usr.bin/cc/Makefile.inc:#CFLAGS+= -DWANT_COMPILER_INVARIANTS /usr/src/lib/libc_r/Makefile:CFLAGS+=-D_PTHREADS_INVARIANTS /usr/src/lib/libpthread/Makefile:CFLAGS+=-D_PTHREADS_INVARIANTS Granted, the first one is commented out (and I've already built world after commenting the other two with no ill effects). -- Conrad Sabatier <[EMAIL PROTECTED]> He played the king as if afraid someone else would play the ace. -- John Mason Brown, drama critic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
