Re: System crash on vinum start
On Monday, 27 September 1999 at 13:05:35 -0400, Brad Chisholm wrote: I'm having a problem where the "vinum start" command crashes my system. This happens regardless of whether it's being issued during bootup via /etc/rc or from the command line on a running system. Interestingly, however, if I issue the start command from the vinum interactive prompt, it works properly with no crash. I'm currently running on a snap built this morning (0924), but it was also happening on a snap from 0914. Crash info, vinum config, and disk info are below. Let me know if I can provide any additional information. Yes. Please read the instructions in vinum(4) about debugging panic dumps. I found a minor bug in 'vinum start' recently, but I doubt it's causing your problem. I'll commit it Real Soon Now. Well, I believe I discovered the source of my problem. It turns out that I did not have the correct devices configured in /dev for the component drives. I had da[0-3]e, but not da[0-3]s1e. The documentation seemed to indicate that the da?s1? devices were not required, but once I made them, the crashes stopped. Thanks. This was the clue that helped me find the bug. It's fixed in 3.3-STABLE now. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: just found this
Warner Losh [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] Kenneth Culver writes: : Check this out, if anyone is intrested. : : I found this on packetstorm.securify.com tonight. Any ideas?? Mycroft sent this out after we had fixed this before the 3.3R release. At least it appeared in bugtraq after it had been fixed in FreeBSD, as far as I can tell. It isn't in -current, does this mean that it wasn't considered an acceptable long-term solution? Really large numbers of hardlinks are probably rare enough, but the default limit of 4 seems a bit low, it should probably be at least as high as the maximum link count encountered on a normal installation. There are other ways to hold down at least as much memory per file you can keep open as with the limit of 4. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ESS1869 logical ID
On 29 Sep 1999, John Saunders wrote: unknown0: ESS ES1869 Plug and Play AudioDrive on isa0 pcm0: ESS1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 unknown1: ESS ES1869 Plug and Play AudioDrive at port 0x201 on isa0 unknown2: ESS ES1869 Plug and Play AudioDrive at port 0x168-0x16f,0x36e-0x36f irq 9 on isa0 Interestingly, that last device "unknown2:" looks to be an IDE interface for a CDROM drive. Any plans, ideas, thoughts on the PnP system assigning the ATA driver to this device? The IDs are there in the ata driver but I haven't actually tried it. The middle device could possibly be a game port, although the port looks strange as game ports are normally port 0x200. I have a patch for pnp joystick support which I haven't got around to testing yet. I expect to commit that fairly soon, hopefully after making it work on alpha. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
C++ compiler not working in yesterdays current.
I'm having problem compiling programs with the c++ compiler in current as of yesterday. kdelibs-1.1.2 fails in configure, cc1plus coredumps when trying to compile a STL test. mysql-3.23.3 cc1plus reports out of swap space and exits when compiling sql_yacc.cc Have anybody else experienced this or is it my computer/installation that is to blame. Dual PPro 200-512KB Intel PR440FX 128MB RAM 256Swap. I can compile the above on 3.3 and 2.8 so it must be either current or my machine that is at fault. /Martin -- _ | o | +---+ +---+ | o | | | | Martin Nilsson M.Sc. CSE | |Internet Intranet| | | | o | | FILEX AB, Lund SWEDEN | | Applications shopping. | | o | | | | email: [EMAIL PROTECTED]| | UNIX, TCP/IP, Perl, C/C++ | | | | | | Phone: +46-46-304130 | | SQL dev. consulting | | | | o | +---+ +---+ | o | | | Those who do not understand Unix are condemned| | | o | to reinvent it, poorly. -- Henry Spencer| o | ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Repeatable panic in current, cause Netscape
Hello The latest -current system crashes while starting up Netscape, mine version is 4.61, Linux one. It's fully repeatable in my case. I got crash dump and here's my dmesg and gdb trace: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Wed Sep 29 09:53:08 EEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/Myhakas Timecounter "i8254" frequency 1193038 Hz CPU: Pentium III (501.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 134217728 (131072K bytes) avail memory = 126898176 (123924K bytes) Programming 24 pins in IOAPIC #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: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc02fe000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02fe09c. VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc00c6954 (c0006954) VESA: Matrox Graphics Inc. Pentium Pro MTRR support enabled devclass_alloc_unit: pcib0 already exists, using next available unit number npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443GX host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib2: Intel 82443GX (440 GX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib2 vga-pci0: Matrox model 0525 graphics accelerator irq 2 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 chip1: Intel PIIX4 IDE controller at device 7.1 on pci0 chip2: UHCI USB controller at device 7.2 on pci0 Timecounter "PIIX" frequency 3579545 Hz chip3: Intel 82371AB Power management controller at device 7.3 on pci0 ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter irq 16 at device 11.0 on pci0 ahc0: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7896/97 Ultra2 SCSI adapter irq 16 at device 11.1 on pci0 ahc1: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 19 at device 13.0 on pci0 fxp0: Ethernet address 00:e0:81:10:50:32 ncr0: ncr 53c875 fast20 wide scsi irq 16 at device 14.0 on pci0 fxp1: Intel EtherExpress Pro 10/100B Ethernet irq 17 at device 15.0 on pci0 fxp1: Ethernet address 00:90:27:54:57:26 devclass_alloc_unit: pci1 already exists, using next available unit number pcib1: Intel 82443GX host to AGP bridge on motherboard pci2: PCI bus on pcib1 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 8 virtual consoles, flags=0x200 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 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 unknown0: Disabled Device on isa0 unknown1: Disabled Device on isa0 unknown2: Disabled Device on isa0 pcm0: GusPnP at port 0x220-0x22f,0x320-0x327,0x32c-0x32f irq 11 drq 5,7 on isa0 unknown3: Disabled Device on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 BRIDGE 981214, have 3 interfaces -- index 1 fxp0 type 6 phy 0 addrl 6 addr 00.e0.81.10.50.32 -- index 2 fxp1 type 6 phy 0 addrl 6 addr 00.90.27.54.57.26 Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ahc0 bus 0 target 5 lun 0 da0: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ahc0 bus 0 target 6 lun 0 da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) cd0 at ncr0 bus 0 target 0 lun 0 cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: / was not properly dismounted called sysctl for bridge name bridge arg2 0 val 0-0 called sysctl for bridge name bridge arg2 0 val 0-0 called sysctl for bridge name bridge arg2 0 val 0-1 called sysctl for bridge name bridge arg2 0 val 1-1 called sysctl for bridge name bridge arg2 0 val 1-1 fxp0: promiscuous mode enabled now fxp0 flags 0x8943 promisc 0 fxp1: promiscuous mode enabled now fxp1 flags 0x8943 promisc 0 Script started on Wed Sep 29 11:07:23 1999
Re: C++ compiler not working in yesterdays current.
On Wed, 29 Sep 1999, Martin Nilsson wrote: mysql-3.23.3 cc1plus reports out of swap space and exits when compiling sql_yacc.cc add mode swap space using swapfile parameter in /etc/rc.conf or manually, with vnconfig/swapon commands. mysql will normally compile. sincerely, ilya naumov (at work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
"Rodney W. Grimes" wrote: I also know that we are a lot better off with CAM, and could care less that the old ancient AIC drivers are dead, but some how I am also pretty Let me chime in here. We *DO* care about ancient AIC drivers as long as no PCMCIA alternative exists. sure we won't be reverting back on newpcm, even if some old sound cards don't work. It'll take the same arguement path that CAM did. ``This is so much better, someone is working on getting that done, etc, etc..'' Alas, the fuctionality lost in this case is one of newer cards. We lost the cutting edge stuff, and kept just the old technology. :-) That this is the reverse of the driver situation is a fine irony. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it do unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
On Wed, Sep 29, 1999 at 12:02:09PM +0200, Mark Murray wrote: There is breakage in the new FICL. This fixes it... [awk diff] I remember a long time ago someone asked me to make some modifications to softcore.awk to compress the textual ficl keywords by eliminating double-spaces and newlines, and that kind of thing. I don't believe I ever got around to doing it at the time, but I'd be more than happy to implement the changes now if (a) someone could remind me what the compression logic should be, and (b) someone could confirm that these changes haven't already been made :) If I sound vague, it's because I am without a FreeBSD box right now, and do not have an easy way to check the source tree. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
Mark Murray wrote:
Hi
There is breakage in the new FICL. This fixes it...
diff -u -d -r1.2 softcore.awk
--- softcore.awk1999/01/22 23:52:57 1.2
+++ softcore.awk1999/09/29 09:47:30
@@ -91,6 +91,6 @@
printf "\"quit \";\n";
printf "\n\nvoid ficlCompileSoftCore(FICL_VM *pVM)\n";
printf "{\n";
- printf "assert(ficlExec(pVM, softWords, -1) != VM_ERREXIT);\n";
+ printf "assert(ficlExec(pVM, softWords) != VM_ERREXIT);\n";
printf "}\n";
}
/me wonders how did this got to _not_ be committed.
Well, that's why I wanted some disk space to make a test compilation
of the changes I was about to commit...
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Rule 69: Do unto other's code as you'd have it do unto yours
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: just found this
In message [EMAIL PROTECTED] Ville-Pertti Keinonen writes: : It isn't in -current, does this mean that it wasn't considered an : acceptable long-term solution? It wasn't a problem in -current due to a different way that things were done there. : Really large numbers of hardlinks are probably rare enough, but the : default limit of 4 seems a bit low, it should probably be at least as : high as the maximum link count encountered on a normal installation. : There are other ways to hold down at least as much memory per file you : can keep open as with the limit of 4. I think phk's idea in this area are likely the best way to deal. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: sigset_t changes committed
I just finished committing the sigset_t changes I worked on for the last 5 weeks. Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. Alpha users are invited to test the changes since I've not been able to do that myself. I've done all I possibly could do to make this a success. I've attached the commit logs for everyone to see. Please report problems as soon as possible. Thanks, sigset_t change (part 1 of 5) - Rename sigaction, sigprocmask, sigpending and sigsuspend to osigaction, osigprocmask, osigpending and osigsuspend (resp) and add new syscalls for them to support the new sisgset_t without breaking existing binaries. Change the prototype of sigaltstack to use the typedef stack_t instead of struct sigaltstack to reflect that it is SUSv2 compliant. Also, rename sigreturn to osigreturn and add a new syscall to support the modified stackframe. The change is caused by sigreturn operating on ucontext_t now and the fact that siginfo_t has been updated to conform to SUSv2. sigset_t change (part 2 of 5) - The core of the signalling code has been rewritten to operate on the new sigset_t. No methodological changes have been made. Most references to a sigset_t object are through macros (see signalvar.h) to create a level of abstraction and to provide a basis for further improvements. The NSIG constant has not been changed to reflect the maximum number of signals possible. The reason is that it breaks programs (especially shells) which assume that all signals have a non-null name in sys_signame. See src/bin/sh/trap.c for an example. Instead _SIG_MAXSIG has been introduced to hold the maximum signal possible with the new sigset_t. struct sigprop has been moved from signalvar.h to kern_sig.c because a) it is only used there, and b) access must be done though function sigprop(). The latter because the table doesn't holds properties for all signals, but only for the first NSIG signals. signal.h has been reorganized to make reading easier and to add the new and/or modified structures. The "old" structures are moved to signalvar.h to prevent namespace polution. Especially the coda filesystem suffers from the change, because it contained lines like (p-p_sigmask == SIGIO), which is easy to do for integral types, but not for compound types. NOTE: kdump (and port linux_kdump) must be recompiled. Thanks to Garrett Wollman and Daniel Eischen for pressing the importance of changing sigreturn as well. sigset_t change (part 3 of 5) - By introducing a new sigframe so that the signal handler operates on the new siginfo_t and on ucontext_t instead of sigcontext, we now need two version of sendsig and sigreturn. A flag in struct proc determines whether the process expects an old sigframe or a new sigframe. The signal trampoline handles which sigreturn to call. It does this by testing for a magic cookie in the frame. The alpha uses osigreturn to implement longjmp. This means that osigreturn is not only used for compatibility with existing binaries. To handle the new sigset_t, setjmp saves it in sc_reserved (see NOTE). the struct sigframe has been moved from frame.h to sigframe.h to handle the complex header dependencies that was caused by the new sigframe. NOTE: For the i386, the size of jmp_buf has been increased to hold the new sigset_t. On the alpha this has been prevented by using sc_reserved in sigcontext. sigset_t change (part 4 of 5) - The compatibility code and/or emulators have been updated: iBCS2 now mostly uses the older syscalls. SVR4 now properly handles all signals. This has been achieved by using the new sigset_t throughout the emulator. The Linuxulator has been severely updated. Internally the new Linux sigset_t is made the default. These are then mapped to and from the new FreeBSD sigset_t. Also, rt_sigsuspend has been implemented in the Linuxulator. Implementing this syscall basicly caused all this sigset_t changing in the first place and the syscall has been used throughout the change as a means for testing. It basicly is too much work to undo the implementation so that it can later be added again. A special note on the use of sv_sigtbl and sv_sigsize in struct sysentvec: Every signal larger than sv_sigsize is not translated and is passed on to the signal handler unmodified. Signals in the range 1 upto and including sv_sigsize are translated. The rationale is that only the system defined signals need to be translated. The emulators also have been updated so that the translation tables are only indexed for valid (system defined) signals. This change also fixes the translation bug already in the SVR4 emulator. sigset_t change (part 5 of 5) - Most of the userland changes
my repository is broken (more)
Hi, I wrote: === usr.sbin/lpr/filters.ru === usr.sbin/lpr/filters.ru/koi2alt make: don't know how to make koi2alt.c. Stop Apparently because... ache1999/09/22 19:54:45 PDT Removed files: usr.sbin/lpr/filters.ru koi2alt.c Log: moved to koi2alt ...never made it here. What's the easiest way to get back in step? TIA I now suspect that cvsup.uk.freebsd.org isn't up-to-date. Anyone know anything? -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic in current, cause Netscape
On Wed, Sep 29, 1999 at 09:51:49AM -0700, Alfred Perlstein [EMAIL PROTECTED]
wrote:
excellent, using kgbd, can you please type "up" until you hit
frame 5 and print the value of the ndp and some of the other
variables? A listing of the code at that location would also
be great. ('list')
Sorry I don't know anything about debugging, so I did some
trial-and-error game and used print on something which seemed emit
useful information. Useful from my point of view ;-) Hope it's really
useful. Otherwise please give exact guidelines or I can try limit memory
and get 32MB dump or so suitable for downloading.
Script started on Wed Sep 29 20:42:14 1999
myhakas# gdb -k /sys/compile/Myhakas/kernel.debug vmcore.1
GNU gdb 4.18
Copyright 1998 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 "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD 3211264
initial pcb at 298e00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0100
fault virtual address = 0x17
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc017ad2c
stack pointer = 0x10:0xc8e5fca0
frame pointer = 0x10:0xc8e5fcf0
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 = 666 (netscape)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... 19 5 1 done
dumping to dev #da/0x20001, offset 0
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
281 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
#1 0xc0155349 in panic (fmt=0xc026de2f "page fault")
at ../../kern/kern_shutdown.c:531
#2 0xc0236400 in trap_fatal (frame=0xc8e5fc60, eva=23)
at ../../i386/i386/trap.c:907
#3 0xc0236071 in trap_pfault (frame=0xc8e5fc60, usermode=0, eva=23)
at ../../i386/i386/trap.c:800
#4 0xc0235ce7 in trap (frame={tf_fs = 1048600, tf_es = 16, tf_ds = 16,
tf_edi = -924451276, tf_esi = -924451236, tf_ebp = -924451600,
tf_isp = -924451700, tf_ebx = -1061078179, tf_edx = -924572480,
tf_ecx = 7, tf_eax = 7, tf_trapno = 12, tf_err = 0,
tf_eip = -1072190164, tf_cs = 8, tf_eflags = 66198,
tf_esp = -1061078179, tf_ss = 0}) at ../../i386/i386/trap.c:426
#5 0xc017ad2c in namei (ndp=0xc8e5fe34) at ../../kern/vfs_lookup.c:91
#6 0xc0c12eb5 in ?? ()
#7 0xc0c11c55 in ?? ()
#8 0xc0236642 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 677678720, tf_esi = 677674201, tf_ebp = -1077946400,
tf_isp = -924450860, tf_ebx = 677674201, tf_edx = -1077946464,
tf_ecx = -1077946464, tf_eax = 106, tf_trapno = 12, tf_err = 2,
tf_eip = 677666503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077946504,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#9 0xc02241b1 in Xint0x80_syscall ()
#10 0x28644564 in ?? ()
(kgdb) up 5
#5 0xc017ad2c in namei (ndp=0xc8e5fe34) at ../../kern/vfs_lookup.c:91
91 ndp-ni_cnd.cn_cred = ndp-ni_cnd.cn_proc-p_ucred;
(kgdb) list
86 struct uio auio;
87 int error, linklen;
88 struct componentname *cnp = ndp-ni_cnd;
89 struct proc *p = cnp-cn_proc;
90
91 ndp-ni_cnd.cn_cred = ndp-ni_cnd.cn_proc-p_ucred;
92 KASSERT(cnp-cn_cred cnp-cn_proc, ("namei: bad cred/proc"));
93 KASSERT((cnp-cn_nameiop (~OPMASK)) == 0,
94 ("namei: nameiop contaminated with flags"));
95 KASSERT((cnp-cn_flags OPMASK) == 0,
(kgdb) print ndp
$1 = (struct nameidata *) 0xc8e5fe34
(kgdb) print *ndp
$2 = {ni_dirp = 0xc0d2b000 "/compat/linux/etc/ld.so.cache",
ni_segflg = UIO_SYSSPACE, ni_startdir = 0xc046d730, ni_rootdir = 0xc0462000,
ni_topdir = 0x871c000, ni_vp = 0xc8e5fe8c, ni_dvp = 0xc0233db8,
ni_pathlen = 3370408552,
ni_next = 0x871c000
"KeyBackSpace\nosfDelete:KeyDelete\nosfInsert:KeyInsert\nosfAddMode:Shift
KeyF8\nosfHelp:KeyF1\nosfMenu:ShiftKeyF10\nosfMenuBar:KeyF10", ni_loopcnt = 0,
ni_cnd = {cn_nameiop = 64,
Re: ep0 etherlink III breakage
Mark Hittinger wrote: Hey per request I'm reporting some ep0 breakage in today's -current. I have an etherlink III 3c509B and the probing appears correct. Sequence of events boot -s # ifconfig ep0 inet 192.168.18.200 (PC hangs) More later... Was there ever a conclusion as to how to get around this problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic in current, cause Netscape
Vallo Kallaste wrote: The latest -current system crashes while starting up Netscape, mine version is 4.61, Linux one. It's fully repeatable in my case. I got crash dump and here's my dmesg and gdb trace: Make sure that the linux module is as uptodate as the kernel is. As a rule of thumb: rebuild the modules you use when you rebuild the kernel. If that doesn't help in this case, continue debugging :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic in current, cause Netscape
On Wed, Sep 29, 1999 at 07:42:50PM +0200, Marcel Moolenaar [EMAIL PROTECTED] wrote: The latest -current system crashes while starting up Netscape, mine version is 4.61, Linux one. It's fully repeatable in my case. I got crash dump and here's my dmesg and gdb trace: Make sure that the linux module is as uptodate as the kernel is. As a rule of thumb: rebuild the modules you use when you rebuild the kernel. If that doesn't help in this case, continue debugging :-) Thankyou for tip, discovered that my modules are from Sept 17 and I know I've compiled the kernel several times in between 17 to date. Quick look at /usr/sup/src-all/checkouts.cvs:. gives me the 26'th. I must have done cvsup for src-all by accident. Sorry for false alert, my Netscape works now as usual. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: These libraries either a) have one of the modified structures visible in the interface, or b) use sigset_t internally and may cause breakage if new binaries are used against libraries that don't have the sigset_t change. This not an immediate issue, but will be as soon as applications start using the new range to its fullest. Without really wanting to get into this discussion, the version bumps if an old binary cannot use a new library, not the other way around. Alas, this is all I'll be saying. Interested parties can refer to the recent discussion+flame war on the subject. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it do unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
In article [EMAIL PROTECTED], Marcel Moolenaar [EMAIL PROTECTED] wrote:
Alpha users are invited to test the changes since I've not been able to
do that myself. I've done all I possibly could do to make this a
success.
It looks like real bad news for the Alpha. :-( I built and
installed the kernel as instructed, and then started a make
buildworld. That died soon with this:
=== usr.bin
"/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop
"/a/src/usr.bin/Makefile", line 223: Unclosed conditional/for loop
"/a/src/usr.bin/Makefile", line 223: 1 open conditional
"/a/src/usr.bin/Makefile", line 223: 1 open conditional
make: fatal errors encountered -- cannot continue
make: fatal errors encountered -- cannot continue
*** Error code 1
*** Error code 1
I suspect it's caused by the trailing backslash in the "doscmd" line
near the end:
.if ${MACHINE_ARCH} == "i386"
# Things that don't compile on alpha or are aout specific:
SUBDIR+=ar \
brandelf \
gcore \
gprof4 \
nm \
ranlib \
sasc \
size \
strings \
strip
# doscmd \
.endif
Anyway, when the make buildworld failed, I tried to do a "cvs
status" or some such thing, which caused amd to attempt to mount the
repository from a different machine. Wham, instant panic, and it
trashed out one of my filesystems _thoroughly_ -- 1000 files and 10
MB in lost+found. :-(
Once I got things patched up again with a little chewing gum, I was
able to get a core dump. It overflowed the kernel stack with
zillions of recursive calls to nfs_sigintr:
#37 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#38 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#39 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#40 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#41 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#42 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#43 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
#44 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0)
at ../../nfs/nfs_socket.c:1504
I haven't found the bottom of the stack yet (11000 frames and
counting ...). Let me know if you'd like some additional info.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Marcel Moolenaar wrote: I just finished committing the sigset_t changes I worked on for the last 5 weeks. Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. Is there any way at all that we can change this process so that building the kernel first is not required? Those of us involved in educating users about the make world process spend a lot of time telling them not to do this. It's amazing how long and how tenaciously "one-time" exceptions like this stick in their minds. That said, I think that your commit messages were models of excellence, and this work looks like something that will benefit the project for a long time down the road. Thanks, Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote: I suspect it's caused by the trailing backslash in the "doscmd" line near the end: strip # doscmd \ .endif It doesn't give me any problems... Anyway, when the make buildworld failed, I tried to do a "cvs status" or some such thing, which caused amd to attempt to mount the repository from a different machine. Wham, instant panic, and it trashed out one of my filesystems _thoroughly_ -- 1000 files and 10 MB in lost+found. :-( speechless Once I got things patched up again with a little chewing gum, I was able to get a core dump. It overflowed the kernel stack with zillions of recursive calls to nfs_sigintr: #37 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #38 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #39 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #40 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #41 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #42 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #43 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 #44 0xfc409404 in nfs_sigintr (nmp=0x0, rep=0x0, p=0x0) at ../../nfs/nfs_socket.c:1504 I haven't found the bottom of the stack yet (11000 frames and counting ...). Let me know if you'd like some additional info. Yes please. Looking at the code, it seems to me that nmp shouldn't be 0. What I like to know is, if sendsig/sigreturn is somehow involved. A bad stack can do all sorts of nasty things. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote:
Marcel Moolenaar wrote:
John Polstra wrote:
strip
# doscmd \
.endif
It doesn't give me any problems...
Weird! It doesn't seem like the Alpha make should be different.
As a first "guess": Either sendsig/sigreturn or setjmp/longjmp caused
this...
Yes, I agree. The old code also assumed it wouldn't be 0.
Ok, this should do it. If it looks good to you, I'll commit this...
Index: nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_socket.c,v
retrieving revision 1.55
diff -u -r1.55 nfs_socket.c
--- nfs_socket.c1999/09/29 15:03:47 1.55
+++ nfs_socket.c1999/09/29 18:58:13
@@ -1504,15 +1504,19 @@
{
sigset_t tmpset;
- tmpset = p-p_siglist;
- SIGSETNAND(tmpset, p-p_sigmask);
- SIGSETNAND(tmpset, p-p_sigignore);
if (rep (rep-r_flags R_SOFTTERM))
return (EINTR);
if (!(nmp-nm_flag NFSMNT_INT))
+ return (0);
+ if (p == NULL)
return (0);
- if (p SIGNOTEMPTY(p-p_siglist) NFSINT_SIGMASK(tmpset))
+
+ tmpset = p-p_siglist;
+ SIGSETNAND(tmpset, p-p_sigmask);
+ SIGSETNAND(tmpset, p-p_sigignore);
+ if (SIGNOTEMPTY(p-p_siglist) NFSINT_SIGMASK(tmpset))
return (EINTR);
+
return (0);
}
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: John Polstra wrote: strip # doscmd \ .endif It doesn't give me any problems... Weird! It doesn't seem like the Alpha make should be different. I haven't found the bottom of the stack yet (11000 frames and counting ...). Let me know if you'd like some additional info. Yes please. Looking at the code, it seems to me that nmp shouldn't be 0. Yes, I agree. The old code also assumed it wouldn't be 0. What I like to know is, if sendsig/sigreturn is somehow involved. A bad stack can do all sorts of nasty things. GDB is still looking for the bottom of the stack. :-( I did a "bt -30" to try to find it. Do any of you know the address of the outermost frame of the kernel stack on the Alpha? If I knew that then I could probably find the region of interest faster than GDB. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Following up on my previous mail regarding the panic on the Alpha,
I've been looking at the diff for the code in question, in
"src/sys/nfs/nfs_socket.c":
@@ -1501,14 +1502,16 @@
struct nfsreq *rep;
register struct proc *p;
{
+ sigset_t tmpset;
+ tmpset = p-p_siglist;
+ SIGSETNAND(tmpset, p-p_sigmask);
+ SIGSETNAND(tmpset, p-p_sigignore);
if (rep (rep-r_flags R_SOFTTERM))
return (EINTR);
if (!(nmp-nm_flag NFSMNT_INT))
return (0);
- if (p p-p_siglist
- (((p-p_siglist ~p-p_sigmask) ~p-p_sigignore)
- NFSINT_SIGMASK))
+ if (p SIGNOTEMPTY(p-p_siglist) NFSINT_SIGMASK(tmpset))
return (EINTR);
return (0);
}
It looks like the old code was prepared for "p" to be NULL, but the
new code assumes it is non-NULL.
GDB is _still_ looking for the bottom of the stack. If it ever
finds it, I'll send that part of the backtrace. :-)
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: Ok, this should do it. If it looks good to you, I'll commit this... I'm running it now, and so far it seems to have solved the problem. Could you also please get rid of that "# doscmd \" line from usr.bin/Makefile? Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Following up on my previous mail regarding the panic on the Alpha,
I've been looking at the diff for the code in question, in
"src/sys/nfs/nfs_socket.c":
@@ -1501,14 +1502,16 @@
struct nfsreq *rep;
register struct proc *p;
{
+ sigset_t tmpset;
+ tmpset = p-p_siglist;
+ SIGSETNAND(tmpset, p-p_sigmask);
+ SIGSETNAND(tmpset, p-p_sigignore);
if (rep (rep-r_flags R_SOFTTERM))
return (EINTR);
if (!(nmp-nm_flag NFSMNT_INT))
return (0);
- if (p p-p_siglist
- (((p-p_siglist ~p-p_sigmask) ~p-p_sigignore)
- NFSINT_SIGMASK))
+ if (p SIGNOTEMPTY(p-p_siglist) NFSINT_SIGMASK(tmpset))
return (EINTR);
return (0);
}
It looks like the old code was prepared for "p" to be NULL, but the
new code assumes it is non-NULL.
Am I missing something?
- if (p p-p_siglist
- (((p-p_siglist ~p-p_sigmask) ~p-p_sigignore)
- NFSINT_SIGMASK))
+ if (p SIGNOTEMPTY(p-p_siglist) NFSINT_SIGMASK(tmpset))
The
if (p
in both cases checks for an null p. Or, am I missing something?
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Doug wrote: On Wed, 29 Sep 1999, Marcel Moolenaar wrote: Is there any way at all that we can change this process so that building the kernel first is not required? IIRC, you can use -DNOTOOLS. In that case the current tools are assumed to be sufficient for building world. But, you can't do an installworld as part of that, because eventually the new binaries that are installed get used by the install process (/bin/sh for example). In short: you need a new kernel for the newly compiled binaries to run. Those of us involved in educating users about the make world process spend a lot of time telling them not to do this. It's amazing how long and how tenaciously "one-time" exceptions like this stick in their minds. I understand, but the new syscalls simply need to be in the kernel before you can run the binaries that use them. Using -DNOTOOLS you can delay that moment until just before doing the installworld, but you can't avoid it. I hope and trust that users understand that this is an exception... That said, I think that your commit messages were models of excellence, and this work looks like something that will benefit the project for a long time down the road. Thanks! -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
John Polstra wrote:
Following up on my previous mail regarding the panic on the Alpha,
I've been looking at the diff for the code in question, in
"src/sys/nfs/nfs_socket.c":
@@ -1501,14 +1502,16 @@
struct nfsreq *rep;
register struct proc *p;
{
+ sigset_t tmpset;
+ tmpset = p-p_siglist;
+ SIGSETNAND(tmpset, p-p_sigmask);
+ SIGSETNAND(tmpset, p-p_sigignore);
if (rep (rep-r_flags R_SOFTTERM))
return (EINTR);
if (!(nmp-nm_flag NFSMNT_INT))
return (0);
- if (p p-p_siglist
- (((p-p_siglist ~p-p_sigmask) ~p-p_sigignore)
- NFSINT_SIGMASK))
+ if (p SIGNOTEMPTY(p-p_siglist) NFSINT_SIGMASK(tmpset))
return (EINTR);
return (0);
}
It looks like the old code was prepared for "p" to be NULL, but the
new code assumes it is non-NULL.
Thanks, I overlooked that one. I'll fix it right away.
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Marcel Moolenaar wrote: Ok, this should do it. If it looks good to you, I'll commit this... Yes, it looks fine to me. You may not be able to commit it right away, though. It looks like freefall is down. Maybe they're putting in the new disk. I'll try the patch a little bit later today, after I finish some other things I have to do. I'm also going to add a panic if nmp==NULL in my local version, so that if it still fails I can get a reasonable stack trace. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: my repository is broken (more)
On Wed, Sep 29, 1999 at 04:58:34PM +, Bob Bishop wrote: Hi, I wrote: === usr.sbin/lpr/filters.ru === usr.sbin/lpr/filters.ru/koi2alt make: don't know how to make koi2alt.c. Stop Apparently because... ache1999/09/22 19:54:45 PDT Removed files: usr.sbin/lpr/filters.ru koi2alt.c Log: moved to koi2alt ...never made it here. What's the easiest way to get back in step? TIA I now suspect that cvsup.uk.freebsd.org isn't up-to-date. Anyone know anything? Oops, it's public now. (bows head in shame.) Yes, there was a problem with the main UK cvsup server, from about the 19th. I updated the machine to 3.3, and reinstalled all the ports. Unfortunately the cvsup-mirror port hadn't been updated (John did it today) to reflect the changes made earlier in the year. We now pull from cvsup-master, not freefall! Thus, since the 19th we've been failing authentication and I didn't notice, cause the internat stuff, which happens first, was working, and secondly, my home machine doesn't currently have an internet connection because the I4B code hasn't been ported to Stable and thus PPPoISDN doesn't work anymore. I say anymore because the other machine that it _was_ working on was running Brian's development copy and the harddrive went *bang* for reasons of old age! In summary - sorry, try again. 'Tis working now :) Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, Sep 29, 1999 at 11:55:23AM -0700, Doug wrote: On Wed, 29 Sep 1999, Marcel Moolenaar wrote: I just finished committing the sigset_t changes I worked on for the last 5 weeks. Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. Is there any way at all that we can change this process so that building the kernel first is not required? Those of us involved in educating users about the make world process spend a lot of time telling them not to do this. It's amazing how long and how tenaciously "one-time" exceptions like this stick in their minds. Those users shouldn't track (or run) -CURRENT. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weird sockname errors with -current and apache
Greetings, I'm using -current on some web server/CGI processing machines. Yes I know all about using -current on production stuff, but we need the NFS, et al fixes due to the heavy NFS client activity on these systems, and I'm willing to take the good with the bad. I cvsup'ed and built world and kernel on or about 8/26 and these boxes ran fine for about 26 days. On 9/22 (Wednesday) I cvsup'ed and built world and kernel on one machine in order to take advantage of Matt's latest round of NFS, etc. fixes. That box ran well for two days so I updated the rest of them on Friday (9/24) and took off for a happy weekend. Well, you know what happened, one box locked up on saturday, I came in and rebooted it, then the other 4 boxes locked up on sunday. *sigh* The really annoying thing here is that there isn't ONE clear problem that I can point to. Also, when the boxes die they wedge solid. No console, serial or otherwise, and no DDB so I can't find out exactly what they are doing when they die. I have the DDB_UNATTENDED option in the kernel because I have the boxes set up to recover themselves on boot and go back into service (previous to the 26 day uptime panics were common). I'm starting to think I should disable that, however as far as I can see they aren't panic'ing, they are just freezing up; although they are ping'able. We started out this project with Apache 1.3.6, and on Sept. 7 we moved to 1.3.9. These are dual PIII 500 machines with a half gig of ram each. The other annoying thing is that while I was checking the kernel, etc. logs for signs of problems, it hadn't occured to me to check the apache error log. Once I did I noticed that at least some of the symptoms I'm seeing go back as far as I have logs, even before the blessed 26 day uptime period. Here is what I've seen. The first errror I can find in any of the logs I have that seems related to the problem is this from apache's error log: [Fri Aug 20 10:59:34 1999] [error] (22)Invalid argument: getsockname consequently I've noticed that we get this error a LOT, usually coinciding with a period of time where the machine is wedged, after which it sometimes comes back, and sometimes doesn't (i.e., it stays wedged). When this happens it usually repeats about 15-20 times, followed by: Virtual memory exceeded in `new' then a NULL character (^@) in the apache log. Those errors are usually accompanied by a slew of "Premature end of script headers" messages, apparently related to CGI process that these web servers run dying off before it finishes writing out its data. We also have a slew of these errors in the apache logs at various times (doesn't *seem* to be a correlation with the others, but I'm not sure) that look like: [Mon Sep 13 12:51:03 1999] [warn] child process 82600 still did not exit, sending a SIGTERM [Mon Sep 13 12:51:03 1999] [warn] child process 83437 still did not exit, sending a SIGTERM [Mon Sep 13 12:51:03 1999] [warn] child process 84136 still did not exit, sending a SIGTERM [Mon Sep 13 12:51:03 1999] [warn] child process 83698 still did not exit, sending a SIGTERM [Mon Sep 13 12:51:03 1999] [warn] child process 83703 still did not exit, sending a SIGTERM Sometimes these happen at the same time, sometimes they don't. When this one happens we get about 40 of them in a row. In the system logs the only unusual thing I've seen (and I enable a LOT of logging) are these messages, which started over this past weekend. /kernel: calcru: negative time of 4347162 usec for pid 6806 (httpd) Once again, when these come they come in bunches, sometimes with a positive time value like this one, sometimes with a negative one. I'm used to seeing calcru messages related to the kernel misjudging the speed of the processor, but the recently added code that tells you the speed on SMP systems says that I have CPU: Pentium III (498.75-MHz 686-class CPU), which looks right to me. Now, as if the above were not annoying enough, all of these problems could very well be related to the third party CGI processing engine (a program called Miva) which we have tracked down some bugs in before. Of course the machines freezing up is my main concern at this point, but the errors themselves could be coming from miva. Any suggestions on how to debug this problem further would be greatly appreciated. I'm going to start up some boxes today that don't have the DDB_UNATTENDED option enabled to see if they will in fact panic and drop to the debugger. Beyond that, I'm at a bit of a loss here. TIA, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
In message [EMAIL PROTECTED] "Daniel C. Sobral" writes: : Let me chime in here. We *DO* care about ancient AIC drivers as long : as no PCMCIA alternative exists. Justin has said that porting old scsi aic to cam wouldn't be too hard, but would still provide a level of buginess that is too high.. Otherwise, i'd have done that a long time ago... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Harold Gutch wrote: Uhm, that's the way I see it being _right now_ as well. What I was thinking of, was that things would go smoother if you wouldn't upgrade _right now_, but in [insert some time in the near future here], as things would perhaps be "fixed" by then. There is no fix to make. If the binaries built by the current sources cannot run unless the sigset_t stuff is in the kernel of the machine that they are running on this problem will never be "fixed." Then the tools target is broken. The intent of the tools target it to build a running on the current system set of binaries that can build the FreeBSD tree, it the binaries in obj/tmp won't run on the current system something is broken. If it is broken, please back out the signal changes or fix the tools target. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999, Ben Rosengart wrote: On Wed, 29 Sep 1999, Harold Gutch wrote: I interpreted the way of currently handling things (build the kernel first, then the userland) to be a _temporary_ solution, that Marcel was working on being fixed. If this is not the case, then I agree with you. If I understand correctly, it only needs to be done once per system, but it makes no difference whether it happens on a given system now or six months from now. Yes, if I understand Marcel correctly from this moment forward everyone who upgrades from any version of freebsd prior to today's -current will have to build the kernel first. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, 30 Sep 1999, Harold Gutch wrote: Uhm, that's the way I see it being _right now_ as well. What I was thinking of, was that things would go smoother if you wouldn't upgrade _right now_, but in [insert some time in the near future here], as things would perhaps be "fixed" by then. There is no fix to make. If the binaries built by the current sources cannot run unless the sigset_t stuff is in the kernel of the machine that they are running on this problem will never be "fixed." Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999 21:17:48 -0400, Jim Bloom [EMAIL PROTECTED] said: I believe this must be fixed. There is no way it can be ``fixed''. That's Just The Way It Is. I'm sorry that you're having a problem with this. Nobody ever said keeping -current would be easy. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is the wb driver broken?
Of all the gin joints in all the towns in all the world, John Polstra had to walk into mine and say: cvsup-master# ifconfig wb0 inet 204.216.27.25 netmask 255.255.255.240 media 100baseTX mediaopt half-duplex ifconfig: SIOCSIFMEDIA: Device not configured You don't need to explicitly specify mediaopt half-duplex anymore. Specifying media 100baseTX without mediaopt full-duplex implies half-duplex. Leave off the mediaopt half-duplex part and it will work. OK, I did that and it made the SIOCSIFMEDIA message go away. But now it's not showing carrier: Doing initial network setup: hostname domain. wb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 204.216.27.25 netmask 0xfff0 broadcast 204.216.27.31 ether 00:00:e8:18:5b:1d media: 100baseTX status: no carrier supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP none Any other ideas? Is there any reason why you're not letting it autodetect (which is what it does by default, or with media autoselect). Make sure it's plugged in, make sure the link light is lit. Try to ping somebody on the network (or run tcpdump on the interface). You can't just sit there and look at it: you have to experiment. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is the wb driver broken?
Bill Paul wrote: I converted the wb driver to miibus ages ago. Your description makes it sound like the problem just magically appeared yesterday. That's a no-no, m'kay? Thanks for the quick reply. I didn't mean to imply anything. I have one machine with a Winbond running current a week old, and never saw the problem there. I also notice that there have been commits to a lot of the network interfaces recently, including wb. In any case, I'm a bit stressed out over having broken cvsup-master, so please forgive me if I clumsily gave offense. cvsup-master# ifconfig wb0 inet 204.216.27.25 netmask 255.255.255.240 media 100baseTX mediaopt half-duplex ifconfig: SIOCSIFMEDIA: Device not configured You don't need to explicitly specify mediaopt half-duplex anymore. Specifying media 100baseTX without mediaopt full-duplex implies half-duplex. Leave off the mediaopt half-duplex part and it will work. OK, I did that and it made the SIOCSIFMEDIA message go away. But now it's not showing carrier: Doing initial network setup: hostname domain. wb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 204.216.27.25 netmask 0xfff0 broadcast 204.216.27.31 ether 00:00:e8:18:5b:1d media: 100baseTX status: no carrier supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP none Any other ideas? Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is the wb driver broken?
Bill Paul wrote: You know, I have a rule about not doing software upgrades on equipment that I can't actually get my hands on. Me too. That's why it's stressing me out. :-) I do have access to the serial console, and there are people on-site who can give the box a kick if I need them to. I trust this means it's actually passing traffic. Yep. Things are looking pretty reasonable now. Thanks again. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
www.curriculum.com.br faz 6 meses de muito sucesso !
Esta contente com seu emprego atual? Já imaginou que poderia neste instante estar sendo chamado para uma entrevista em uma grande empresa, algo que poderia estar mudando completamente o seu futuro? Porque se privar desta possível oportunidade? Saia do anonimato! Independente se está ou não empregado, coloque-se a disposição do mercado de trabalho. Este é o futuro. Deixe as portas abertas para novas oportunidades. Utilize a força da Internet e deixe ela trabalhar por você. www.curriculum.com.br está completando seu 6º mês de vida e tem auxiliado muitos a conseguirem um emprego ou uma melhor colocação. Cadastre-se gratuitamente em nosso site e faça parte da maior vitrine de profissionais do Brasil que hoje conta com mais de 36.000 currículos cadastrados, além de muitas vagas de empregos. Usufrua de todos os benefícios que um site inteligente e bem planejado tem a lhe oferecer. Tenha o seu próprio UCN juntamente com um e-mail inteiramente grátis. Se você ainda não nos conhece, venha nos fazer uma visita. Se você já nos conhece, venha ver o novo design e as novidades do site. É http://www.curriculum.com.br trabalhando por você hoje e sempre!
Re: HEADS UP: sigset_t changes committed
On Wed, 29 Sep 1999 16:51:37 -0700 (PDT), "Rodney W. Grimes" [EMAIL PROTECTED] said: If it is broken, please back out the signal changes or fix the tools target. No, Rod, just Deal With It(tm). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 08:17:16AM +1000, Adam Strohl wrote: On Wed, 29 Sep 1999, Jim Bloom wrote: I believe this must be fixed. At some point in time, there is going to be another change to the kernel such that some older version of the code cannot run on a new kernel. FTPing a GENERIC kernel from somewhere would solve this, then just single user the box, make world. Build your kernel. Reboot. This assumes that your old world can work correctly with your new kernel (remembering that `make world' is seen as our standard system stress test). The whole justification for the `install the world then upgrade the kernel' approach has been that we _do_not_ guarantee this. Furthermore, for when 4.0 becomes a -R or -S, ftping in a compiled kernel shouldn't be that hard of a price to pay for going from 3.2. We've never required this before. I managed to convert from 2.2.6 to -current using `make upgrade'. Why should I need to FTP a kernel from another machine to go from 3.x to 4.x? Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 01:29:40AM +1000, Marcel Moolenaar wrote: Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. I'd like to voice my concerns with this change as well. The `normal' upgrade procedure has always been to build and install a new world before the new kernel. The only exception I'm aware of has been the aout-elf transition (where a special build procedure was provided). This commit seems to create the same upgrade hurdle as existed with the conversion to ELF[1]. That conversion came with an extensive description of how to upgrade the system, as well as clear CVS tags delimiting it. This change has no tags and a single paragraph warning us to install a new kernel before building world. I can't configure or compile a -current kernel on a -stable system (and I have no idea whether I can run a -current kernel with a -stable world, but I suspect I can't). This makes it very difficult to convert a -stable system to -current. Whilst -current is for people who like battering their way around such hurdles, it's also the testbed for 4.0-RELEASE, and we will need a tested and documented upgrade procedure in place before then. That said, I think that backing out the changes at this stage will only make things worse. I would like to see a clear upgrade procedure that will enable someone to cross this hurdle when their running system can't build or run a current kernel. [1] Actually, in many ways this change is worse. Recent 2.2 kernels will happily execute many 3.x ELF programs as long as the shared libraries are present. This change makes any program that uses signals not backward compatible. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
how to avoid bullets in the feet (was Re: HEADS UP: sigset_t changescommitted)
What's really needed is some warning sort of like what we did when the AOUT-ELF convertion happened, there has to be a simple way to test this as part of installworld. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] On Thu, 30 Sep 1999, Harold Gutch wrote: On Wed, Sep 29, 1999 at 04:17:29PM -0700, Doug wrote: On Wed, 29 Sep 1999, Ben Rosengart wrote: On Wed, 29 Sep 1999, Harold Gutch wrote: I interpreted the way of currently handling things (build the kernel first, then the userland) to be a _temporary_ solution, that Marcel was working on being fixed. If this is not the case, then I agree with you. If I understand correctly, it only needs to be done once per system, but it makes no difference whether it happens on a given system now or six months from now. Yes, if I understand Marcel correctly from this moment forward everyone who upgrades from any version of freebsd prior to today's -current will have to build the kernel first. Uhm, that's the way I see it being _right now_ as well. What I was thinking of, was that things would go smoother if you wouldn't upgrade _right now_, but in [insert some time in the near future here], as things would perhaps be "fixed" by then. And yes, I'm thinking of an upgrade from the "classical kernel/userland" to the "new one", e.g. an upgrade from last week's kernel and userland to the one in two months time. Perhaps I silently just expected too much :). bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet 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: HEADS UP: sigset_t changes committed
On Thu, Sep 30, 1999 at 02:37:45PM +1000, Warner Losh wrote: In keeping notes, what would need to happen would be that you'd have to build config as well as all the tools to build binaries. We might be able to get away with temporarily replacing the i386/include/atomic.h[1] with the one from -stable and using gcc 2.7. At some stage, we need to confirm that a -current kernel will work with a -stable world - or add the incompatible bits to the list of things to build first. The current Makefile.upgrade would have to be massively gutted and rewritten since it deals with the aout - elf transition, but it shouldn't be too horrible. At least, no more horrible than the aout-elf procedure :-). I think that we need to do this upgrade proceedure. I wish I had more time than to just sketch out this outline... I think that a suitable upgrade procedure should have been thought through and implemented before the changes were committed. It would also have been nice to have a CVS tag. It's a bit late now though. [1] It's just occurred to me that the solution for atomic.h is to make the asm constraints dependent on the gcc version. Anyone willing to commit a change if I submit patches? Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
Hi, On Wed, Sep 29, 1999 at 10:07:07PM -0700, John-Mark Gurney wrote: Garrett Wollman scribbled this message on Sep 29: On Wed, 29 Sep 1999 16:51:37 -0700 (PDT), "Rodney W. Grimes" [EMAIL PROTECTED] said: If it is broken, please back out the signal changes or fix the tools target. No, Rod, just Deal With It(tm). actually, no, I would like this fixed... I will be unable to develope FreeBSD if the tools target doesn't work!! I do all of my compiles on a 3.0-R box (yes, that's right, 3.0-R) and it will basicly stop me from doing any of that... this is a VERY bad thing to happen to FreeBSD... Is there no way for a new tool (especially through libc) to detect it is running on an old kernel, and do things the old way? The test would need to be done once per application, and could be conditionised so that it was only included in the tools built during a make world... Regards, -Jeremy (who hasn't looked at the code) -- | "Come home my prodigal son, come home and lets be one, --+-- don't want to see you cry, don't make me tell you why, |you've lived in a house with me, my blood has set you free, |in the world you'll surely die, nothing else will satisfy." -MIC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
