Re: CD-ROM troubles on i815EP based MB
Igor Roboul wrote: > I have tracked external source of problem. > FreeBSD-CURRENT (at least 5.0-CURRENT-20020917-JPSNAP) could not find > CD-ROM (at least IDE Sony 52sp) if it set to "MASTER" mode. If I set > CD-ROM to "SLAVE" on both pprimary and secondary ATA controllers, > FreeBSD sees it. > I'll send dmesg of both cases later. Always nice to know that it's not a FreeBSD problem; thanks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
latest FFS panic...
Oct 13 20:00 PDT sources: Script started on Thu Oct 17 21:38:23 2002 Not loading printing treats... /var/crash> gdb -k kernel.ko.debug 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 "i386-undermydesk-freebsd"... (kgdb) core-file vmcore.1 panic: handle_workitem_freefile: inodedep survived panic messages: --- panic: handle_workitem_freefile: inodedep survived cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Uptime: 8m25s Dumping 1023 MB ata0: resetting devices .. done [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 --- #0 doadump () at ../../../kern/kern_shutdown.c:223 223 dumping++; (kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:223 #1 0xc01e08d5 in boot (howto=260) at ../../../kern/kern_shutdown.c:355 #2 0xc01e0b69 in panic () at ../../../kern/kern_shutdown.c:508 #3 0xc02b84f0 in handle_workitem_freefile (freefile=0xc6bb5e60) at ../../../ufs/ffs/ffs_softdep.c:3379 #4 0xc02b41ba in process_worklist_item (matchmnt=0x0, flags=0) at ../../../ufs/ffs/ffs_softdep.c:760 #5 0xc02b3eb0 in softdep_process_worklist (matchmnt=0x0) at ../../../ufs/ffs/ffs_softdep.c:624 #6 0xc022e474 in sched_sync () at ../../../kern/vfs_subr.c:1737 #7 0xc01cd3c7 in fork_exit (callout=0xc022e190 , arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:852 (kgdb) quit /var/crash> exit exit Script done on Thu Oct 17 21:38:52 2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: any recent changes related to MD_ROOT ?
Luigi Rizzo wrote: > at which point you can proceed by specifying "ufs:md0" as the root > path, and everything works fine. > It certainly used to work (though i do not remember if the root path > came out as md0c or just md0) up to a couple of months ago, roughly. > > Does this ring any bell on what might have changed more or less recently > that affects this ? Who builds up the '/dev/md0c' name for the root > filesystem ? GEOM. "Live FS" images are broken, too (acd0c vs. acd0). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CD-ROM troubles on i815EP based MB
I have tracked external source of problem. FreeBSD-CURRENT (at least 5.0-CURRENT-20020917-JPSNAP) could not find CD-ROM (at least IDE Sony 52sp) if it set to "MASTER" mode. If I set CD-ROM to "SLAVE" on both pprimary and secondary ATA controllers, FreeBSD sees it. I'll send dmesg of both cases later. -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kthread.9 out of date
I have just discovered the hard way that the kthread.9 manual page is slightly out of date. Having never done man page work before, I've attached a diff of the proposed change and if someone could give this a once-over and fix and/or commit it, that'd rock. Thanks. =) -- Benno Rice [EMAIL PROTECTED] Index: kthread.9 === RCS file: /home/ncvs/src/share/man/man9/kthread.9,v retrieving revision 1.11 diff -u -r1.11 kthread.9 --- kthread.9 10 Oct 2002 00:29:22 - 1.11 +++ kthread.9 18 Oct 2002 09:36:21 - @@ -44,7 +44,7 @@ .Ft void .Fn kproc_shutdown "void *arg" "int howto" .Ft int -.Fn kthread_create "void (*func)(void *)" "void *arg" "struct proc **newpp" "int flags" "const char *fmt" "..." +.Fn kthread_create "void (*func)(void *)" "void *arg" "struct proc **newpp" "int flags" "int pages" "const char *fmt" "..." .Ft void .Fn kthread_exit "int ecode" .Ft int @@ -121,6 +121,10 @@ .Fa flags argument specifies a set of flags as described in .Xr rfork 2 . +The +.Fa pages +argument specifies the size of the new kthread's kernel stack in pages. +If 0 is used, the default kernel stack size is allocated. The rest of the arguments form a .Xr printf 9 argument list that is used to build the name of the new thread and is stored signature.asc Description: This is a digitally signed message part
page fault while in vm86 mode
Hi,
this is -current as of Oct 8.
Fatal trap 12: page fault while in vm86 mode
fault virtual address = 0xc4182
fault code = user read, page not present
instruction pointer = 0xc000:0x4182
stack pointer = 0x0:0xfc0
frame pointer = 0x0:0x0
code segment= base 0x0, limit 0x0, type 0x0
= DPL 0, pres 0, def32 0, gran 0
processor eflags= interrupt enabled, resume, vm86, IOPL = 0
current process = 22592 (XFree86)
trap number = 12
panic: page fault
Uptime: 2d5h9m25s
Dumping 639 MB
[...]
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:224
#1 0xc019a9c4 in boot (howto=260) at ../../../kern/kern_shutdown.c:356
#2 0xc019ade2 in panic (fmt=0xc029a1f1 "panic: %s\n")
at ../../../kern/kern_shutdown.c:509
#3 0xc02652a2 in trap_fatal (frame=0xc0545fa8, eva=803202)
at ../../../i386/i386/trap.c:847
#4 0xc0265055 in trap_pfault (frame=0xc0545fa8, usermode=0, eva=803202)
at ../../../i386/i386/trap.c:761
#5 0xc0264c83 in trap (frame=
{tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 19158, tf_esi = 19170, tf_ebp = 0,
tf_isp = -1068212268, tf_ebx = 1, tf_edx = 980, tf_ecx = 24, tf_eax = 33537, tf_trapno
= 12, tf_err = 4, tf_eip = 16770, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4032,
tf_ss = 0}) at ../../../i386/i386/trap.c:447
This doesn't look much to me. I'm used to see more frames here. What can I do
do debug this further?
Bye,
Alexander.
--
Give a man a fish and you feed him for a day;
teach him to use the Net and he won't bother you for weeks.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
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 Oct 18 03:08:49 PDT 2002 -- >>> Kernel build for GENERIC completed on Fri Oct 18 03:36:41 PDT 2002 -- >>> Kernel build for LINT started on Fri Oct 18 03:36:41 PDT 2002 -- ===> vinum "Makefile", line 4244: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/ahd_pci.c: In function `ahd_pci_map_registers': /h/des/src/sys/dev/aic7xxx/ahd_pci.c:173: warning: implicit declaration of function `bus_space_subregion' *** 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: [Ugly PATCH] Again: panic kmem_malloc()
This is a repost. Forgive me if you see it twice, but it didn't turn up in the -current list. Hi, Just had another panic, same kmem_malloc(). I did a trace but forgot to write the traceback down. In any case, there was a semop() call in the traceback. Furthermore, this might be interesting: the last vmstat -m log before the panic. Maybe someone can check if these values are reasonable? The system has 64 MB memory and has been up for about 24 hrs with almost no load. [terminus.stuyts.nl ben/bin]4: cat vmstatlog.4 Type InUse MemUse HighUse Requests Size(s) atkbddev 2 1K 1K2 32 pfs_fileno 132K 32K1 32768 nexusdev 2 1K 1K2 16 memdesc 1 4K 4K1 4096 legacydrv 3 1K 1K3 16 VM pgdata 1 4K 4K1 4096 pfs_nodes20 3K 3K 20 128 MSDOSFS mount 1 8K 8K1 8192 UFS mount1223K 39K 14 256,2048,4096,16384 UFS ihash 116K 16K1 16384 UFS dirhash 18936K 52K 1695 16,32,64,128,256,512 FFS node 11086 2079K 2096K 1000908 128,256 newdirblk 0 0K 1K5 16 dirrem 5 1K 34K18098 32 mkdir 0 0K 3K 524 32 diradd 0 0K 9K18045 32 freefile 5 1K 31K12022 32 freeblks 7 2K247K10187 256 freefrag 2 1K 2K36405 32 allocindir 4 1K204K 257072 64 indirdep 2 1K876K 2172 32,8192 allocdirect 1 1K 33K51562 128 bmsafemap 8 1K 3K 6606 32 newblk 1 1K 1K 308635 64,256 inodedep1218K168K31012 128,16384 pagedep10 3K 7K 6114 64,2048 p1003.1b 1 1K 1K1 16 NFS daemon 5 3K 3K5 256,512 NFS srvsock 2 1K 1K2 128 ip6_moptions 1 1K 1K1 16 in6_multi10 1K 1K 10 16,64 syncache 1 8K 8K1 8192 IpFw/IpAcct30 4K 4K 30 64,128 in_multi 2 1K 1K2 32 routetbl41 6K 6K 78 16,32,64,128,256 lo 1 1K 1K1 512 clone 312K 12K3 4096 ether_multi35 2K 2K 35 16,32,64 ifaddr22 7K 7K 22 32,256,512,2048 BPF 6 9K 9K6 128,256,4096 mount20 4K 4K 24 16,32,128,512 vnodes23 6K 6K 137 16,32,64,128,256 cluster_save buffer 0 0K 1K 9793 32,64 vfscache 5226 381K436K 534189 64,128,256,32768 BIO buffer 810K317K 4611 512,1024,2048 DEVFS 12122K 22K 121 16,32,128,8192 pcb38 5K 6K 1913 16,32,64,2048 soname 4 1K 1K39624 16,32,128 ptys 2 1K 1K2 512 ttys 48865K 85K 6431 128,512 shm 318K 19K9 16,1024,16384 sem344456 5390K 5390K 344456 16,1024,4096 msg 425K 25K4 512,4096,16384 ioctlops 0 0K 1K 22 512,1024 USBdev 1 1K 2K4 128,512 USB1521K 22K 701353 16,32,128,256,4096 taskqueue 1 1K 1K1 128 sbuf 0 0K 5K 34 32,64,4096 rman99 7K 7K 496 16,64,128 mbufmgr 11616K 16K 116 32,64,128,2048,8192 kobj 127 508K508K 127 4096 eventhandler22 2K 2K 22 32,128 bus 47039K 40K 1363 16,32,64,128,256,512,2048,4096,8192 SWAP 273K 73K2 64 sysctltmp 0 0K 4K 802428 16,32,64,128,256,512,1024,4096 sysctl 0 0K 1K19359 16,32,64 uidinfo 7 1K 1K 7121 32,128 cred38 5K 9K 142297 128 subproc 10511K 15K52100 64,256 proc 2 1K 1K2 512 session33 5K 6K 2102 128 pgrp39 5K 6K 2278 128 module 17111K 11K 171 64 ip6ndp 3 1K 1K4 64,128,512 temp 954K286K 156410 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 devbuf 474 965K997K 2333 16,32,64,128,256,512,1024,2048,4096,8192,32768 lockf 6 1K 1K29935 64 feeder48 1K 1K 48 16 linker6513K 18K 85 16,32,256,1024,4096,8192 KTRACE 10013K 13K 100 128 ithread40 7K 7K 41
Re: kthread.9 out of date
On (2002/10/18 19:38), Benno Rice wrote: > I have just discovered the hard way that the kthread.9 manual page is > slightly out of date. > > Having never done man page work before, I've attached a diff of the > proposed change and if someone could give this a once-over and fix > and/or commit it, that'd rock. Looks good from a style point of view. Just one nit I spotted: +The +.Fa pages +argument specifies the size of the new kthread's kernel stack in pages. +If 0 is used, the default kernel stack size is allocated. This is the first use of the word "kthread". Consider replacing it with "kernel thread" as used elsewhere in the page. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Help with first build of current
Lo ppl, yesterday i tried to build current with files i sucked 2 or 3 days ago via cvsup. I followed the instructions of the handbook precisely, and got successfully to the step "make buildkernel". After that, i dropped into single user mode and started "make installworld". It failed at some place within the directory "chat" with signal 12 (i don't remember the exact error). What went wrong? Is current broken? If yes, where do i look first for the information whether a current is OK? And will the 4.7 live CD work to fix a broken current? I'd like to retry the build today. If you have additional hints not mentioned in the handbook, please tell me! The version before the build was 4.5-RELEASE. It's running on a C3 800 MHz with 256 MB RAM and 40 GB HDD. Quick help would be very nice, as i can't go online at home. =) TIA -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Help with first build of current
Hi, - you have to build and install the new kernel - reboot into single user mode. - and continue with make installworld bye, Pascal Giannakakis schrieb: Lo ppl, yesterday i tried to build current with files i sucked 2 or 3 days ago via cvsup. I followed the instructions of the handbook precisely, and got successfully to the step "make buildkernel". After that, i dropped into single user mode and started "make installworld". It failed at some place within the directory "chat" with signal 12 (i don't remember the exact error). What went wrong? Is current broken? If yes, where do i look first for the information whether a current is OK? And will the 4.7 live CD work to fix a broken current? I'd like to retry the build today. If you have additional hints not mentioned in the handbook, please tell me! The version before the build was 4.5-RELEASE. It's running on a C3 800 MHz with 256 MB RAM and 40 GB HDD. Quick help would be very nice, as i can't go online at home. =) TIA -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
emacs problems?
I'm having problems with emacs 20.7 running under X: #emacs Fatal error (11).Segmentation fault (core dumped) but emacs -nw works fine (i.e. without X). This started after doing a portupgrade -fa to solve the _sF symbol problem. I've recompiled every package that emacs depends on and still no change. The backtrace isn't very helpful. I suppose I need to build emacs with debugging enabled? Any hints how to do that? Anyone else seeing this problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs problems?
On Fri, 18 Oct 2002 08:00:19 -0700 walt <[EMAIL PROTECTED]> wrote: > > I suppose I need to build emacs with debugging enabled? > Any hints how to do that? > > Anyone else seeing this problem? xemacs dies here. Global variables are getting corrupted somehow during startup. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Does this happen on a current with this patch applied too? Index: usb_port.h === RCS file: /home/ncvs/src/sys/dev/usb/usb_port.h,v retrieving revision 1.58 diff -u -r1.58 usb_port.h --- usb_port.h 2 Oct 2002 07:44:20 - 1.58 +++ usb_port.h 18 Oct 2002 15:14:23 - @@ -339,10 +339,7 @@ #define USBVERBOSE -/* We don't use the soft interrupt code in FreeBSD. */ -#if 0 #define USB_USE_SOFTINTR -#endif #define Static static Joe On Sun, Oct 06, 2002 at 07:42:18PM -0400, Brian Fundakowski Feldman wrote: > I can't get more info because crash dumps don't work when this happens, but > for what it's worth, here's a traceback which shows what happens when I > attempt to use my da0: Removable Direct Access > SCSI-2 device on an OHCI-based controller. This was working just a few days > ago with a UHCI controller, so ... > > The crash is from an invalid read at 0xbff3e000, which is PTmap plus some > offset. The trace as far as I can get it, from a kernel with USB but no > "options" > enabled, would be: > > ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) > ohci_device_bulk_start+0x0d > ohci_device_bulk_transfer+0x27 > usbd_transfer+0xc0 > umass_setup_transfer+0x4f > umass_bbb_state > usb_transfer_complete > ohci_softintr > > Can anyone confirm if this is normal or I have an exceptional system? I > have two completely unrelated OHCI-based controllers in my system and > neither works. > > -- > Brian Fundakowski Feldman \'[ FreeBSD ]''\ > <> [EMAIL PROTECTED] <> [EMAIL PROTECTED] \ The Power to Serve! \ > Opinions expressed are my own. \,,\ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- "As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality." - Albert Einstein, 1921 msg44888/pgp0.pgp Description: PGP signature
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser <[EMAIL PROTECTED]> wrote: > Does this happen on a current with this patch applied too? I'm certain I tried this already :( -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: panic: mtx_lock() of spin mutex
On 17-Oct-2002 Lars Eggert wrote:
> Hi,
>
> I'm tracking down a lock order reversal for hsu@, and just came across
> this other locking panic twice in the last few hours. I run with WITNESS
> and WITNESS_SKIPSPIN, and have never seen this happen unless I set
> debug.witness_ddb=1. The name of the mutex looks definitly fishy.
>
> Let me knowif I can provide more information (tried to get a core dump,
> but machine hung hard after typing "panic".)
>
> panic: mtx_lock() of spin mutex $,J@4(J@^@^GN@^D @
> /usr/src/sys/kern/kern_descrip.c:488
> cpuid = 1; lapic.id = 0200
> Debugger("panic")
> Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c043d4b2,200,c043c6ef,eb519c70,1) at Debugger+0x5a
> panic(c043c6ef,c04a2a74,c043a64f,1e8,eb519cb4) at panic+0x12f
> _mtx_lock_flags(c04a2c34,0,c043a64f,1e8,c7238c00) at _mtx_lock_flags+0xa7
> do_dup(c69fb9c0,1,,4,c69fba54) at do_dup+0xe6
> dup2(c69fb9c0,eb519d10,c046443d,42d,c69fa3e8) at dup2+0x33
> syscall(2f,2f,2f,4,815aa00) at syscall+0x406
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (90, FreeBSD ELF32, dup2), eip = 0x80986cf, esp =
> 0xbfbe74bc, ebp = 0xbfbe7988 ---
> db> panic
> panic: from debugger
> cpuid = 1; lapic.id = 0200
> boot() called on cpu#1
What is line 488 of src/sys/kern/kern_descrip.c?
--
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
RE: Page fault in swapout_procs
On 17-Oct-2002 Kris Kennaway wrote:
> I just got the following panic on one of the gohan machines, running a
> somewhat recent -current:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xa0
> fault code = supervisor write, page not present
> instruction pointer = 0x8:0xc035d0ab
> stack pointer = 0x10:0xcd25ccc0
> frame pointer = 0x10:0xcd25cce0
> 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 = 3 (vmdaemon)
> kernel: type 12 trap, code=0
> Stopped at swapout_procs+0x6b: incl0xa0(%esi)
> db> Context switches not allowed in the debugger.
> db> trace
> swapout_procs(1,0,68,c0411018,0) at swapout_procs+0x6b
> vm_daemon(0,cd25cd48,c03f1300,34b,0) at vm_daemon+0x6e
> fork_exit(c036b560,0,cd25cd48) at fork_exit+0xaf
> fork_trampoline() at fork_trampoline+0x17
Null pointer dereference.
(gdb) l *swapout_procs+0x6b
0xc036ad1b is in swapout_procs (../../../vm/vm_glue.c:683).
678 * An aio daemon switches its
679 * address space while running.
680 * Perform a quick check whether
681 * a process has P_SYSTEM.
682 */
683 PROC_LOCK(p);
684 if ((p->p_flag & P_SYSTEM) != 0) {
685 PROC_UNLOCK(p);
686 continue;
687 }
Hmm, if the process is very brand new, it might not have it's
lock setup yet. Try the patch at
http://www.freebsd.org/~jhb/patches/swapout.patch.
Index: vm_glue.c
===
RCS file: /usr/cvs/src/sys/vm/vm_glue.c,v
retrieving revision 1.158
diff -u -r1.158 vm_glue.c
--- vm_glue.c 14 Oct 2002 20:31:54 - 1.158
+++ vm_glue.c 18 Oct 2002 15:35:08 -
@@ -653,28 +653,25 @@
outp = outp2 = NULL;
outpri = outpri2 = INT_MIN;
retry:
sx_slock(&allproc_lock);
FOREACH_PROC_IN_SYSTEM(p) {
struct vmspace *vm;
int minslptime = 10;
/*
-* Do not swapout a process that
-* is waiting for VM data
-* structures there is a possible
-* deadlock. Test this first as
-* this may block.
-*
-* Lock the map until swapout
-* finishes, or a thread of this
-* process may attempt to alter
-* the map.
-*
* Watch out for a process in
* creation. It may have no
-* address space yet.
-*
+* address space or lock yet.
+*/
+ mtx_lock_spin(&sched_lock);
+ if (p->p_state == PRS_NEW) {
+ mtx_unlock_spin(&sched_lock);
+ continue;
+ }
+ mtx_unlock_spin(&sched_lock);
+
+ /*
* An aio daemon switches its
* address space while running.
* Perform a quick check whether
@@ -685,17 +682,23 @@
PROC_UNLOCK(p);
continue;
}
- mtx_lock_spin(&sched_lock);
- if (p->p_state == PRS_NEW) {
- mtx_unlock_spin(&sched_lock);
- PROC_UNLOCK(p);
- continue;
- }
+
+ /*
+* Do not swapout a process that
+* is waiting for VM data
+* structures as there is a possible
+* deadlock. Test this first as
+* this may block.
+*
+* Lock the map until swapout
+* finishes, or a thread of this
+* process may attempt to alter
+* the map.
+*/
vm = p->p_vmspace;
KASSERT(vm != NULL,
("swapout_procs: a process has no address space"));
++vm->vm_refcnt;
- mtx_unlock_spin(&sched_lock);
PROC_UNLOCK(p);
if (!vm_map_trylock(&vm->vm_map))
goto nextproc1;
--
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
RE: emacs problems?
On 18-Oct-2002 walt wrote: > I'm having problems with emacs 20.7 running under X: > >#emacs > Fatal error (11).Segmentation fault (core dumped) > > but emacs -nw works fine (i.e. without X). > > This started after doing a portupgrade -fa to solve > the _sF symbol problem. > > I've recompiled every package that emacs depends on > and still no change. The backtrace isn't very helpful. > > I suppose I need to build emacs with debugging enabled? > Any hints how to do that? > > Anyone else seeing this problem? Same exact problem with xemacs. -- 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
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote: What is line 488 of src/sys/kern/kern_descrip.c? fhold(fp) in do_dup(). Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
On 18-Oct-2002 Lars Eggert wrote: > John Baldwin wrote: > >> >> What is line 488 of src/sys/kern/kern_descrip.c? > > fhold(fp) in do_dup(). Hrm. You can try adding some KASSERT()'s that the reference count of that struct file isn't zero or negative. -- 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
Re: any recent changes related to MD_ROOT ?
On Thu, 17 Oct 2002, Luigi Rizzo wrote: > Hi, > > on a freshly cvsupped source tree, i notice that picobsd images > with a preloaded MD_ROOT cannot boot anymore: the kernel goes up > to this stage: > > Mounting root from ufs:/dev/md0c > setrootbyname failed > ffs_mountroot: can't find rootvp > Root mount failed: 6 > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices >Abort manual input > > mountroot> > > at which point you can proceed by specifying "ufs:md0" as the root > path, and everything works fine. > It certainly used to work (though i do not remember if the root path > came out as md0c or just md0) up to a couple of months ago, roughly. > > Does this ring any bell on what might have changed more or less recently > that affects this ? Who builds up the '/dev/md0c' name for the root > filesystem ? phk@ removed old BSD partition compatibility (md0a,b,c) a while back and then added it in for the devfs case. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrtools doesn't build on -current (pkg_add -r segfault)
On Fri, 18 Oct 2002, Scott Long wrote: > [...] > **Warning, rant** > The ports collection is one of the crown jewels of FreeBSD. > Unfortunately, even as more ports committers are added, more and > more ports break or become harder to build. On top of that, > pkg_add has become close to worthless now that the -r feature > is so fragile. I found a bug in libfetch a while back that causes pkg_add -r to seg fault on the 2nd package. This was also reported by numerous people. See thread: <[EMAIL PROTECTED]> I received NO replies but am not the maintainer of libfetch. So this message will serve as a warning -- if someone more familiar with the code does not fix it the "right" way, I will fix it and you may not like it. http://www.dlc.fi/~frog/wavs/failure2.wav -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: cdrtools doesn't build on -current (pkg_add -r segfault)
> > On Fri, 18 Oct 2002, Scott Long wrote: > > [...] > > **Warning, rant** > > The ports collection is one of the crown jewels of FreeBSD. > > Unfortunately, even as more ports committers are added, more and > > more ports break or become harder to build. On top of that, > > pkg_add has become close to worthless now that the -r feature > > is so fragile. > > I found a bug in libfetch a while back that causes pkg_add -r > to seg fault > on the 2nd package. This was also reported by numerous people. See > thread: ><[EMAIL PROTECTED]> > > I received NO replies but am not the maintainer of libfetch. So this > message will serve as a warning -- if someone more familiar > with the code > does not fix it the "right" way, I will fix it and you may > not like it. If you have a fix and the maintainer has not replied, then please do commit your fix as soon as possible. The worst that could happen is that the maintainer wakes up. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs problems?
On Fri, Oct 18, 2002 at 08:00:19AM -0700, walt wrote: > Anyone else seeing this problem? The only issue I have with emacs (I'm using xemacs 21.1.14) is that it hangs quite often. Usually when I do a lot of mouse scrolling. This seems to be a recent thing. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: kthread.9 out of date
> > I have just discovered the hard way that the kthread.9 manual page is > slightly out of date. > > Having never done man page work before, I've attached a diff of the > proposed change and if someone could give this a once-over and fix > and/or commit it, that'd rock. > > Thanks. =) Thanks. I knew I forgot to do something Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: cdrtools doesn't build on -current (pkg_add -r segfault)
On Fri, 18 Oct 2002, Long, Scott wrote: > Nate Lawson wrote: > > On Fri, 18 Oct 2002, Scott Long wrote: > > > [...] > > > **Warning, rant** > > > The ports collection is one of the crown jewels of FreeBSD. > > > Unfortunately, even as more ports committers are added, more and > > > more ports break or become harder to build. On top of that, > > > pkg_add has become close to worthless now that the -r feature > > > is so fragile. > > > > I found a bug in libfetch a while back that causes pkg_add -r > > to seg fault > > on the 2nd package. This was also reported by numerous people. See > > thread: > ><[EMAIL PROTECTED]> > > > > I received NO replies but am not the maintainer of libfetch. So this > > message will serve as a warning -- if someone more familiar > > with the code > > does not fix it the "right" way, I will fix it and you may > > not like it. > > If you have a fix and the maintainer has not replied, then please do > commit your fix as soon as possible. The worst that could happen is > that the maintainer wakes up. > > Scott If you check the email, it's not a simple fix and there are two widely divergent paths to take regarding who owns the cached connection. That's why I was waiting on the author. But since this has been around for too long and I think I know the right answer, I'll build a fix for the first path and commit it. Ping me next Friday if I haven't done it by then. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs problems?
On 18-Oct-2002 Alex Zepeda wrote: > On Fri, Oct 18, 2002 at 08:00:19AM -0700, walt wrote: > >> Anyone else seeing this problem? > > The only issue I have with emacs (I'm using xemacs 21.1.14) is that it > hangs quite often. Usually when I do a lot of mouse scrolling. This > seems to be a recent thing. This is due to the ucontext_t/FPU breakage in current. If you recompile a new xemacs though then xemacs won't even start w/o getting a sig 11 in graphical mode. -- 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
Re: [Ugly PATCH] Again: panic kmem_malloc()
Terry, At 23:07 18/10/2002, you wrote: Ben Stuyts wrote: > Furthermore, this might be interesting: the last vmstat -m log > before the panic. Maybe someone can check if these values are reasonable? > The system has 64 MB memory and has been up for about 24 hrs with almost no > load. >sem344456 5390K 5390K 344456 16,1024,4096 Almost 5.3M of unswappable physical memory dedicated to semaphores seems like a bit much. Yes, and it increases continuously, for example when I fetch new mail (over pop) from my windows pc. The pc stores this again on a network drive, so both qpopper and smbd are involved. For example, vmstat -m says: vmstat -m | grep sem sem155886 2443K 2443K 155886 16,1024,4096 Now when I do a fetch-mail with Eudora on my pc, the same command says. vmstat -m | grep sem sem156178 2448K 2448K 156178 16,1024,4096 I can repeat this at will, and each time I loose 4-5 KB. qpopper is started from inetd, and smbd runs as a daemon. I tried stopping smbd: [terminus.stuyts.nl etc/rc.d]90: sudo /usr/local/etc/rc.d/samba.sh stop [terminus.stuyts.nl etc/rc.d]91: !vm vmstat -m | grep sem sem156524 2453K 2453K 156524 16,1024,4096 It doesn't free the sem allocated memory. But without knowing what software you are running, it's hard to say if the number is unreasonable, or not. Well, it is really a lightly loaded server, just serving one windows pc here at home. Here is a ps, and the only thing that's missing from it is the occasional pop session. Also note that this system is not connected to the internet, so the http that's running is mostly for my own pleasure (and proxy/cache). I do run ppp and uucp every now and then. USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND dnetc 503 94.2 0.8 960 460 ?? RNs Thu09PM 1529:56.87 /usr/local/distributed.net/dnetc -quiet root 10 0.0 0.0 0 12 ?? DL1Jan70 0:00.00 (ktrace) root 1 0.0 0.3 700 184 ?? ILs 1Jan70 0:01.26 /sbin/init -- root 11 0.0 0.0 0 12 ?? RL1Jan70 1:24.27 (idle) root 12 0.0 0.0 0 12 ?? WL1Jan70 1:01.85 (swi1: net) root 13 0.0 0.0 0 12 ?? WL1Jan70 7:49.87 (swi6: tty:sio clock) root 15 0.0 0.0 0 12 ?? DL1Jan70 0:17.51 (random) root 18 0.0 0.0 0 12 ?? WL1Jan70 0:35.60 (swi3: cambio) root 23 0.0 0.0 0 12 ?? DL1Jan70 0:33.97 (usb0) root 24 0.0 0.0 0 12 ?? DL1Jan70 0:00.00 (usbtask) root 25 0.0 0.0 0 12 ?? WL1Jan70 0:15.98 (irq12: sym0) root 26 0.0 0.0 0 12 ?? WL1Jan70 0:33.34 (irq9: xl0) root 27 0.0 0.0 0 12 ?? WL1Jan70 0:00.04 (irq1: atkbd0) root 28 0.0 0.0 0 12 ?? WL1Jan70 0:00.00 (irq6: fdc0) root 30 0.0 0.0 0 12 ?? WL1Jan70 0:00.25 (swi0: tty:sio) root 2 0.0 0.0 0 12 ?? DL1Jan70 0:51.73 (pagedaemon) root 3 0.0 0.0 0 12 ?? DL1Jan70 0:00.42 (vmdaemon) root 4 0.0 0.0 0 12 ?? RL1Jan70 0:01.95 (pagezero) root 5 0.0 0.0 0 12 ?? DL1Jan70 0:05.29 (bufdaemon) root 6 0.0 0.0 0 12 ?? DL1Jan70 1:26.74 (syncer) root 7 0.0 0.0 0 12 ?? DL1Jan70 0:04.12 (vnlru) root123 0.0 0.0 2208 ?? IWs - 0:00.00 adjkerntz -i root194 0.0 0.4 628 244 ?? Is Thu09PM 0:09.18 /sbin/natd -dynamic -log -n tun0 root241 0.0 0.7 1180 420 ?? Ss Thu09PM 0:04.76 /usr/sbin/syslogd -s -v root255 0.0 2.6 2856 1580 ?? Is Thu09PM 0:23.02 /usr/sbin/named -d 1 root263 0.0 0.0 1332 12 ?? Is Thu09PM 0:00.06 /usr/sbin/rpcbind root340 0.0 0.0 1204 12 ?? Is Thu09PM 0:00.03 /usr/sbin/mountd -r root342 0.0 0.0 1164 12 ?? Is Thu09PM 0:00.30 nfsd: master (nfsd) root343 0.0 0.0 11168 ?? IW - 0:00.00 nfsd: server (nfsd) root344 0.0 0.0 11168 ?? IW - 0:00.00 nfsd: server (nfsd) root345 0.0 0.0 11168 ?? IW - 0:00.00 nfsd: server (nfsd) root347 0.0 0.0 11168 ?? IW - 0:00.00 nfsd: server (nfsd) root376 0.0 0.0 1188 12 ?? Is Thu09PM 0:00.05 /usr/sbin/lpd root380 0.0 0.3 1188 168 ?? SThu09PM 0:02.57 /usr/sbin/lpd root396 0.0 1.3 1552 804 ?? Ss Thu09PM 0:26.59 /usr/sbin/ntpd -p /var/run/ntpd.pid root418 0.0 0.1 1132 64 ?? Is Thu09PM 0:00.97 /usr/sbin/usbd root437 0.0 1.4 3036 820 ?? Ss Thu09PM 0:19.39 sendmail: accepting connections (sendmail) smmsp 440 0.0 0.9 3012 528 ?? Is Thu09PM 0:00.38 sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) root467 0.0 1.5 2332 908 ?? Ss Thu09PM 0:25.86 /usr/local/sbin/httpd www 485 0.0 0.0 2356 12 ?? IThu09PM 0:00.01 /us
Re: cdrtools doesn't build on -current
On Fri, Oct 18, 2002 at 05:37:22PM -0400, Long, Scott wrote: > No, the systems people do do stuff wrong. It's been plainly pointed > out many times recently when someone does something wrong. However, > what's wrong with a little cooperation? If a port breaks because of > a system change, the maintainer of the port is certainly welcome to > raise a stink over it. All I'm asking is that ports maintainers make > an effort to maintain their ports. Will's accertation that it's an > all or nothing issue is certainly not productive, and neither is the > 'us versus them' inuendo here. You need to re-read my message. I merely said it shouldn't be a total effort on the part of ports developers, as you imply. That is counter-productive (since it's unfair to assume they all know exactly what the change results in). All I'm asking for is a little foresight on the part of those that break things in -CURRENT. It's much easier just to leave (a) port(s) broken for a couple months while the dust settles in -CURRENT, as developers there continue to leave ports people in the dark on the effects of their changes and common approaches to fixing the problems. Only when that is resolved is it reasonable to expect *all* ports maintainers to keep up. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: uma_zalloc_arg: Returning an empty bucket.
I just saw a strange panic on a dual CPU x86:
(kernel from Tuesday)
panic: uma_zalloc_arg: Returning an empty bucket.
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> tr
Debugger(c03477a6,0,c035a2ba,d69b6bc0,1) at Debugger+0x55
panic(c035a2ba,0,c035a07d,54c,0) at panic+0x11f
uma_zalloc_arg(c082da00,0,5,4b,c082da00) at uma_zalloc_arg+0x241
malloc(78,c0376da0,5,4,d69b6c48) at malloc+0x75
g_new_bio(4b,d69b6c5c,c01e,c03aae88,4) at g_new_bio+0x37
g_clone_bio(c4559980,c03aae80,d69b6cb0,d69b6c74,c01b794c) at g_clone_bio+0x14
g_slice_start(c4559980,d69b6d0c,c01b8278,c1581c30,d69b6cb0) at g_slice_start+0x6f
g_io_schedule_down(c1581c30,d69b6cb0,4c,c0342e7a,a) at g_io_schedule_down+0x2e
g_down_procbody(0,d69b6d48,c0344f96,34c,90140004) at g_down_procbody+0x88
fork_exit(c01b81f0,0,d69b6d48) at fork_exit+0xa5
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd69b6d7c, ebp = 0 ---
db> show locks
exclusive sleep mutex 128 (UMA zone) r = 0 (0xc082da24) locked @
../../../vm/uma_core.c:1356
exclusive sleep mutex PCPU 128 (UMA cpu) r = 0 (0xc082dae8) locked @
../../../vm/uma_core.c:1312
exclusive sleep mutex g_down r = 0 (0xd69b6cb0) locked @ ../../../geom/geom_kern.c:113
db> sho pcpu
cpuid= 0
curthread= 0xc1581c30: pid 4 "g_down"
curpcb = 0xd69b6da0
fpcurthread = none
idlethread = 0xc1580a90: pid 12 "idle: cpu0"
currentldt = 0x28
spin locks held:
db> c
boot() called on cpu#1
syncing disks... panic: KSE not on run queue
cpuid = 0; lapic.id =
Debugger("panic")
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cdrtools doesn't build on -current
On Fri, Oct 18, 2002 at 02:20:59PM -0700, Kent Stewart wrote: > In 40 years of using computers, nothing has changed. The system's > people are still primadona's and do nothing wrong. > > Get used to it :). Unfortunately!! People don't install OSes because > of the OS as much as the codes they can run on it. The importance tree > is inverted. The people that think they are the most important are > only there to provide improved tools to the people that users depend on. Whatever you say, dude. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrtools doesn't build on -current
On Fri, Oct 18, 2002 at 01:37:02AM -0600, Scott Long wrote: > The ports collection is one of the crown jewels of FreeBSD. > Unfortunately, even as more ports committers are added, more and > more ports break or become harder to build. On top of that, > pkg_add has become close to worthless now that the -r feature > is so fragile. If 5.0 goes out and popular ports don't build, > it will hurt the image of FreeBSD. Please, take a break from > adding new ports and/or maintaining your pet ports and fix some > of the broken-ness. So, just to make sure I get this straight: 1) Somebody commits a patch to -CURRENT without doing the slightest bit of analysis of its damage to ports, discussing it with the ports list, or even a HEADS UP or patch suggestions. 2) Tons of ports break. 3) Therefore, ports people should fix the breakage. Yah, right. Exactly why I don't use -CURRENT for much of anything nowadays. Too many people breaking stuff without bothering to fix it themselves in any way. So, why don't you encourage -CURRENT developers to treat ports like the crown jewel it is instead of pestering ports developers to fix their breakage? Regards, -- wca 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 Oct 18 15:10:42 PDT 2002 -- >>> Kernel build for GENERIC completed on Fri Oct 18 15:41:27 PDT 2002 -- >>> Kernel build for LINT started on Fri Oct 18 15:41:28 PDT 2002 -- ===> vinum "Makefile", line 4244: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/ahd_pci.c: In function `ahd_pci_map_registers': /h/des/src/sys/dev/aic7xxx/ahd_pci.c:173: warning: implicit declaration of function `bus_space_subregion' *** 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: cdrtools doesn't build on -current
"Long, Scott" wrote: > Yes, I'm sorry if it sounded like I was picking on the ports committers. > Changes due to standards compliance, architecture changes, etc, all > wreak havoc on ports, and hopefully the pace of that will slow down. > Unfortunately, the direction of FreeBSD is what it is, and the onus is > on the ports maintainers to keep their ports up to date and working. Actually, the onus is on the people who changed the code on which the port depended to hide behind something large, while everyone who used the port throws large and very pointy rocks. Standards compliance is a marginally valid argument for change; architectural changes which do not maintain backward compatability are much less so -- particularly if the failure to maintain the compatability was not an unavoidable consequence of the change: it's not fair to deprecate interfaces without a compatability period, or at least some warning other than "Hey! Everyone should be running my experimental code to shake at any bugs, 'cause I'm too lazy!". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrtools doesn't build on -current
Terry Lambert wrote: Kent Stewart wrote: In 40 years of using computers, nothing has changed. The system's people are still primadona's and do nothing wrong. Get used to it :). Unfortunately!! People don't install OSes because of the OS as much as the codes they can run on it. The importance tree is inverted. The people that think they are the most important are only there to provide improved tools to the people that users depend on. Standards compliance changes, in theory, are for the benefit to "the people that users depend upon". All other systems changes are pretty much gratuitous, unless they are to support hardware and/org add features. When Mike Smith first implemented ACPI, he got enough shit to push him out of the project; but it's damn cool that, on systems where it works, I can hit the power button, and the machine will gracefully shut itself down. If it's unfair to make certain changes (it is), then it's also unfair to bitch about certain changes (it is). Moving towards standards compliance will break all the places there are workarounds to standards non-compliance. You could therefore equally argue that these should be seperated out in the patches in ports, to ensure that "sudden compliance with standards" never broke anything. Yeah, there has been some primadona behaviour with architectural changes whose only compatability was whether or not the change was enabled with a kernel option. But the glove fits both parties, too. I think that is absolutely true. When I worked in a programming group for Siemens, I made a comment that I had never met a humble, good programmer. My department manager laughed so hard, that he snorted and had tears in his eyes. I sort of think about the two sides like Patton did about Montgomery in WWII. The way I see it, if the systems people didn't think the way they do, we would not see the progress we see. I have always been involved with diagnosing problems on the user side. So I got to see the primadona behaviour on both sides. The systems people never made mistakes and the application programmers never did either. It was only the people that worked between them that got to see the truth :). Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Stupid UFS2 questions...
Date: Fri, 18 Oct 2002 23:06:53 +0200 (CEST) From: BOUWSMA Beery <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Stupid UFS2 questions... [IPv6-only address above; strip the obvious for IPv4-only mail replies] In trying to track down a panic I had while mounting a newly-created UFS2 filesystem, I noted that the `newfs' k0de had changed somewhat from -stable to -current. Specifically, that which determines the value of `sbsize' which I'm guessing should be no larger than 8192 else mounts cause panics. Here are the relevant lines from the last time I built -stable (mkfs.c): 547 sblock.fs_sbsize = fragroundup(&sblock, sizeof(struct fs)); 548 if (sblock.fs_sbsize > SBSIZE) 549 sblock.fs_sbsize = SBSIZE; If I'm not mistaken, this will give an upper limit of effectively 8192 to fs_sbsize, which does not appear to be the case with -current: As seen in the RCS file just CVSup'ed (sbin/newfs/mkfs.c,v): 840 errx(31, "calloc failed"); 841 sblock.fs_sbsize = fragroundup(&sblock, sizeof(struct fs)); 842 sblock.fs_minfree = minfree; 843 sblock.fs_maxbpg = maxbpg; There is no other reference to sbsize in the HEAD branch. Now, as soon as I patched the build I did half a month ago as follows: 386 if (fscs == NULL) 387 errx(31, "calloc failed"); 388 sblock.fs_sbsize = fragroundup(&sblock, sizeof(struct fs)); 389 /* XXX HACKHACKHACK */ 390 if (sblock.fs_sbsize > SBLOCKSIZE) 391 sblock.fs_sbsize = SBLOCKSIZE; 392 sblock.fs_minfree = minfree; that is, to match how -stable does this, I can create a filesystem with fragment sizes larger than 8192 bytes (UFS2) which I can successfully mount under -current, which, without this hack, would panic my machine. `dumpfs' shows the value for sbsize no larger than 8192, while for the problem filesystems it was >8192, as large as the fragment size. Thus the question: Is this the Right Thing[tm] to do? Your fix is exactly the right thing to do. I have put it into -current. Second question: I have a drive where I first tried to create an ill- fated UFS2 filesystem, because of the above panic which I had not yet researched, so I gave up and created a UFS1 filesystem thereupon, and filled it up. It *seems* that I can mount this disk under -current and probably access the UFS1 files within, but what was really weird was the `df' output from this disk. Said disk is 100% full under -stable, but -current claims it is 0% full. Sorry I don't have the actual outputs from this command, but is it possible that the presence of the UFS2 superblock is confusing -current when there's a UFS1 superblock and filesystem present, and if -current is looking first for a UFS2 superblock and finding one, is it possible to tell `mount' that I really want a UFS1 filesystem mount, and any remnants of UFS2 should be ignored? According to ufs/ffs/fs.h, the UFS1 superblock is at 8k while UFS2 is 64k from the front, so apparently the UFS2 superblock that I initially created still remains and confuses `df' and perhaps other things that I haven't tried yet, as it didn't get wiped when I created the UFS1 filesystem. So it seems. Which makes one to wonder, if there are three superblocks at three locations present, which to believe? And how to nuke the unwanted one(s)? Insight appreciated. Thanks. barry bouwsma In general you can move UFS1 filesystems back and forth between -stable and -current. However, you must run an `fsck -f -p' using the local version (e.g., the -stable fsck on a -stable systems, and the -current fsck on a -current system) before using the UFS1 filesystem. The reason is that -stable and -current record free block information in different parts of the superblock (32-bit counters for -stable and 64-bit counters for -current) and do not maintain the alternate counter locations. The local fsck will recalculate and correct the counters that the local system uses. Unless your blocksize was bigger than 64K, you would have overwritten the UFS2 superblock with UFS1 inode blocks when you created the UFS1 filesystem. I had originally put code in to stomp out all other possible superblock locations when creating a filesystem in newfs, but got in trouble as I ended up stomping on boot block information that UFS2 filesystems place where the UFS1 superblock used to reside. So, I deleted that code. Hope this helps. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrtools doesn't build on -current
Will Andrews wrote: On Fri, Oct 18, 2002 at 01:37:02AM -0600, Scott Long wrote: The ports collection is one of the crown jewels of FreeBSD. Unfortunately, even as more ports committers are added, more and more ports break or become harder to build. On top of that, pkg_add has become close to worthless now that the -r feature is so fragile. If 5.0 goes out and popular ports don't build, it will hurt the image of FreeBSD. Please, take a break from adding new ports and/or maintaining your pet ports and fix some of the broken-ness. So, just to make sure I get this straight: 1) Somebody commits a patch to -CURRENT without doing the slightest bit of analysis of its damage to ports, discussing it with the ports list, or even a HEADS UP or patch suggestions. 2) Tons of ports break. 3) Therefore, ports people should fix the breakage. Yah, right. Exactly why I don't use -CURRENT for much of anything nowadays. Too many people breaking stuff without bothering to fix it themselves in any way. So, why don't you encourage -CURRENT developers to treat ports like the crown jewel it is instead of pestering ports developers to fix their breakage? In 40 years of using computers, nothing has changed. The system's people are still primadona's and do nothing wrong. Get used to it :). Unfortunately!! People don't install OSes because of the OS as much as the codes they can run on it. The importance tree is inverted. The people that think they are the most important are only there to provide improved tools to the people that users depend on. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Ugly PATCH] Again: panic kmem_malloc()
Ben Stuyts wrote: > >Almost 5.3M of unswappable physical memory dedicated to semaphores > >seems like a bit much. > > Yes, and it increases continuously, for example when I fetch new mail (over > pop) from my windows pc. The pc stores this again on a network drive, so > both qpopper and smbd are involved. For example, vmstat -m says: > > vmstat -m | grep sem >sem155886 2443K 2443K 155886 16,1024,4096 > > Now when I do a fetch-mail with Eudora on my pc, the same command says. > > vmstat -m | grep sem >sem156178 2448K 2448K 156178 16,1024,4096 > > I can repeat this at will, and each time I loose 4-5 KB. qpopper is started > from inetd, and smbd runs as a daemon. I tried stopping smbd: None of us have been able to repeat your problem, up to now. I suppose now that we know you are running qpopper on -current, we could repeat the problem, but, frankly, you already have a test environment set up, and it would be a lot of work for us to duplicate it, and even so, we won't know for sure if we could repeat the problem. Have you checked out your source tree with a date tag, so that it's possible for everyone else to check out and get the same source files? Line number references in tracebacks are pretty useless, if the lines don't match. Unless you can identify the exact number of bytes being consumed, and then identify a kernel structure used in the semaphore code that is equal to that size, or for which that size is a least common multiple, and there are a number of evets equal to the size of the divisor, then that's no good. This is why everyone keeps asking you to run the kernel debugger, so that you can tell us exactly the code that's failing, and why, and why a stack backtrace, more detailed than "it contained a call to sem" is important. This problem is evidently a memory leak in the semaphore code; but that does not mean that the crash that results will be in any way related to where the leak occurs. In other words, the crash is a secondary effect. Only by fully understanding the crash will anyone be able to help you with the root cause. I understand that it's frustrating to go step by step, when you think you have isolated the problem to a smaller area, but the information you gather from outside that area will tell you about the inside much more clearly than staring at the outside of a black box where we know the problem lives. The only alternative to rewriting the black box from scratch, or grovelling through it with a line-by-line code review (I'm not interested in doing that; perhaps you could interest the author of the changes that resulted in the problem) is to find a smoking gun, and work from that, instead. If this problem is in the way of you getting work done (one wonders why you are using -current, if you need to get work done), then my best suggestion to you is to back out the changes Alfred made, one by one, and when it stops having the problem, you will have identified a very small patch that causes the problem. > >But without knowing what software you are running, it's hard to say > >if the number is unreasonable, or not. > > Well, it is really a lightly loaded server, just serving one windows pc > here at home. Here is a ps, and the only thing that's missing from it is > the occasional pop session. Also note that this system is not connected to > the internet, so the http that's running is mostly for my own pleasure (and > proxy/cache). I do run ppp and uucp every now and then. Perhaps I wasn't clear. Not knowing what calls your software makes that cause the problem to occur, it is not possible for us to create a cut-down test case in less than 30 lines of C source code, so that we can repeat the problem at will, without secondary effects. As it is, you only *suppose* that the qpopper usage alone is sufficient to cause the problem; even if you are correct, that's insufficient to identify where the problem is... it may not even really be in the semaphore source code at all.. maybe it's in kevent code, for unfreed events, etc.. I think you need to go back one email: | > Just had another panic, same kmem_malloc(). I did a trace but forgot to | > write the traceback down. | | Wait until the next one, and remember to write it down; preferrably, | obtain a system dump image, so you can examine it with the debugger, | and make sure that the kernel you are running has a debuggable | counterpart already there (i.e. you used "config -g" to create the | kernel you are running). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New 5.0 ports uploaded
A new set of 5.0 packages has been uploaded and is making its way out to mirror sites. I will soon be sending out mail to all maintainers of broken ports asking for submissions of fixes (or at least reporting the breakage to the relevant vendors). In the meantime, please visit http://bento.freebsd.org/errorlogs/5-latest/index-maintainer.html and check for your name for any broken ports you maintain. I have had a complaint that the "new-style" bento pages do not render on Netscape 4..I hope to take a look at this over the weekend, but in the meantime you can use any browser written in the last 5 years to read it :-) At some point before 5.0-RELEASE I will go through and mark all ports listed on bento as BROKEN (consider this fair warning: I will not entertain any complaints from port maintainers who take offense on the basis of ignorance of any build problems). Kris msg44913/pgp0.pgp Description: PGP signature
Re: [Ugly PATCH] Again: panic kmem_malloc()
Apparently, On Sat, Oct 19, 2002 at 12:19:57AM +0200, Ben Stuyts said words to the effect of; > Terry, > > At 23:07 18/10/2002, you wrote: > >Ben Stuyts wrote: > > > Furthermore, this might be interesting: the last vmstat -m log > > > before the panic. Maybe someone can check if these values are reasonable? > > > The system has 64 MB memory and has been up for about 24 hrs with almost no > > > load. > > >sem344456 5390K 5390K 344456 16,1024,4096 > > > >Almost 5.3M of unswappable physical memory dedicated to semaphores > >seems like a bit much. > > Yes, and it increases continuously, for example when I fetch new mail (over > pop) from my windows pc. The pc stores this again on a network drive, so > both qpopper and smbd are involved. For example, vmstat -m says: > semop() leaks memory. An important free() was removed by alfred in rev 1.55. Try this. Jake Index: sysv_sem.c === RCS file: /home/ncvs/src/sys/kern/sysv_sem.c,v retrieving revision 1.55 diff -u -r1.55 sysv_sem.c --- sysv_sem.c 13 Aug 2002 08:47:17 - 1.55 +++ sysv_sem.c 19 Oct 2002 01:20:35 - @@ -1128,6 +1128,8 @@ td->td_retval[0] = 0; done2: mtx_unlock(sema_mtxp); + if (sops) + free(sops, M_SEM); return (error); } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdrtools doesn't build on -current
Kent Stewart wrote: > In 40 years of using computers, nothing has changed. The system's > people are still primadona's and do nothing wrong. > > Get used to it :). Unfortunately!! People don't install OSes because > of the OS as much as the codes they can run on it. The importance tree > is inverted. The people that think they are the most important are > only there to provide improved tools to the people that users depend on. Standards compliance changes, in theory, are for the benefit to "the people that users depend upon". All other systems changes are pretty much gratuitous, unless they are to support hardware and/org add features. When Mike Smith first implemented ACPI, he got enough shit to push him out of the project; but it's damn cool that, on systems where it works, I can hit the power button, and the machine will gracefully shut itself down. If it's unfair to make certain changes (it is), then it's also unfair to bitch about certain changes (it is). Moving towards standards compliance will break all the places there are workarounds to standards non-compliance. You could therefore equally argue that these should be seperated out in the patches in ports, to ensure that "sudden compliance with standards" never broke anything. Yeah, there has been some primadona behaviour with architectural changes whose only compatability was whether or not the change was enabled with a kernel option. But the glove fits both parties, too. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Ugly PATCH] Again: panic kmem_malloc()
* Jake Burkholder <[EMAIL PROTECTED]> [021018 18:26] wrote: > semop() leaks memory. An important free() was removed by alfred in > rev 1.55. Try this. Oh' c'mon, isn't MP-safeness a bit more important than a some little memory leak, ram is cheap! processors aren't! Seriously, I just checked in slightly different fix (based on jake's sleuthing)... please let me know if works for you guys. thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
X problem,Undefined symbol "__sF"
after rebuild everything today. get the errro messages,when running nautilus etc what can i do? Regards /usr/libexec/ld-elf.so.1: /usr/local/lib/libjpeg.so.9: Undefined symbol "__sF" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
open-motif compilation problem
While compiling the open-motif port on -CURRENT I see this
error during the 'configure' phase. Anyone else seeing this?
checking for vprintf... yes
checking whether sprintf returns void... Bus error (core dumped)
yes
checking for wcslen... yes
===
This seems to be the code that causes the error:
===
echo $ac_n "checking whether sprintf returns void""... $ac_c" 1>&6
echo "configure:8121: checking whether sprintf returns void" >&5
if eval "test \"`echo '$''{'ac_cv_func_void_sprintf'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6
else
if test "$cross_compiling" = yes; then
ac_cv_func_void_sprintf=yes
else
cat > conftest.$ac_ext <
#line 8129 "configure"
#include "confdefs.h"
#include
int sprintf(); main() { exit(sprintf(".")); }
EOF
if { (eval echo configure:8134: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s
conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
then
ac_cv_func_void_sprintf=no
else
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
rm -fr conftest*
ac_cv_func_void_sprintf=yes
fi
rm -fr conftest*
fi
fi
echo "$ac_t""$ac_cv_func_void_sprintf" 1>&6
if test $ac_cv_func_void_sprintf = no; then
cat >> confdefs.h <<\EOF
#define VOID_SPRINTF 1
EOF
fi
=
From config.log:
=
configure:8121: checking whether sprintf returns void
configure:8134: cc -o conftest -O -pipe -mcpu=pentiumpro -DCSRG_BASED -DXUSE_MTSAFE_API
-DXNO_MTSAFE_PWDAPI conftest.c 1>&5
configure: failed program was:
#line 8129 "configure"
#include "confdefs.h"
#include
int sprintf(); main() { exit(sprintf(".")); }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: open-motif compilation problem
walt wrote: While compiling the open-motif port on -CURRENT I see this error during the 'configure' phase. Anyone else seeing this? checking for vprintf... yes checking whether sprintf returns void... Bus error (core dumped) yes checking for wcslen... yes Sorry, this is not a -CURRENT problem, I see the same error in -STABLE as well, now that I've bothered to look. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X problem,Undefined symbol "__sF"
Unfortunaly you need to replace almost all X11 stuff.. I wish whoever broke this would fix it. So much for compatibility. On Sat, 19 Oct 2002, suken woo wrote: > after rebuild everything today. get the errro messages,when running > nautilus etc > what can i do? Regards > /usr/libexec/ld-elf.so.1: /usr/local/lib/libjpeg.so.9: Undefined symbol > "__sF" > > > 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
