Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, 31 May 2001 16:31:21 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo Lock of struct filedesc, file, pgrp, session and sigio is now ready Seigo for testing. Seigo The patch is at Seigo http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz WARNING: rebuild any modules that provide filesystems if you are using them. getpid(2) should now be *really* mpsafe. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB Ethernet hang on eject
Of course not. I never do that with pccards :-) That's why I asked it :-) It shouldn't be necessary. When I do that, as a work around, I find that I can pull the plug. How hard is it to fix the way that the ethernet driver reads the MII registers in the interrupt context? Hard, but probably not impossible. Especially with threads in interrupts or worker threads, it should be possible. Task queue might be a solution as well, although I guess the problem is that the action is blocking, and task queue might not handle that very well. A worker thread for the ethernet drivers is probably the simplest solution. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic (with dump!): mutex vm owned at /usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c:2990
Hi!
I get this about 20 seconds after boot completed (and fsck went into
background):
(I saw a similar message yesterday IIRC):
root@zerogravity ~dir $ gdb -k
/usr/obj/usr/home/alex/work/HEAD/src/sys/CICHLIDS/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...
IdlePTD 5033984
initial pcb at 3da620
panicstr: mutex vm owned at
/usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c:2990
panic messages:
---
panic: recurse
syncing disks... panic: mutex vm owned at
/usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c:2990
Uptime: 1m48s
/dev/vmmon: Module vmmon: unloaded
dumping to dev ad2b, offset 761856
dump ata1: resetting devices .. done
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 dumpsys () at
/usr/home/alex/work/HEAD/src/sys/kern/kern_shutdown.c:478
478 if (dumping++) {
(kgdb) bt
#0 dumpsys () at
/usr/home/alex/work/HEAD/src/sys/kern/kern_shutdown.c:478
#1 0xc01ca20f in boot (howto=260)
at /usr/home/alex/work/HEAD/src/sys/kern/kern_shutdown.c:321
#2 0xc01ca629 in panic (fmt=0xc034dd7c mutex %s owned at %s:%d)
at /usr/home/alex/work/HEAD/src/sys/kern/kern_shutdown.c:600
#3 0xc01c2bdf in _mtx_assert (m=0xc041ace0, what=2,
file=0xc0355780 /usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c,
line=2990) at
/usr/home/alex/work/HEAD/src/sys/kern/kern_mutex.c:580
#4 0xc020b7a7 in vfs_busy_pages (bp=0xc41e0630, clear_modify=1)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c:2990
#5 0xc020787f in bwrite (bp=0xc41e0630)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c:695
#6 0xc0208f81 in vfs_bio_awrite (bp=0xc41e0630)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_bio.c:1496
#7 0xc02d38c0 in ffs_fsync (ap=0xcbda8b94)
at /usr/home/alex/work/HEAD/src/sys/ufs/ffs/ffs_vnops.c:239
#8 0xc02d0cda in ffs_sync (mp=0xc19c9800, waitfor=2, cred=0xc0b34400,
p=0xc04151a0) at vnode_if.h:441
#9 0xc0218953 in sync (p=0xc04151a0, uap=0x0)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_syscalls.c:620
#10 0xc01c9c8f in boot (howto=256)
at /usr/home/alex/work/HEAD/src/sys/kern/kern_shutdown.c:231
#11 0xc01ca629 in panic (fmt=0xc0351c88 recurse)
#12 0xc01e49d4 in witness_lock (lock=0xc041ace0, flags=8,
file=0xc0365de0
/usr/home/alex/work/HEAD/src/sys/ufs/ufs/ufs_readwrite.c, line=420)
at /usr/home/alex/work/HEAD/src/sys/kern/subr_witness.c:539
#13 0xc02d2272 in ffs_write (ap=0xcbda8cdc)
at /usr/home/alex/work/HEAD/src/sys/ufs/ufs/ufs_readwrite.c:420
#14 0xc02f88e8 in vnode_pager_generic_putpages (vp=0xcc751060,
m=0xcbda8ddc,
bytecount=8192, flags=0, rtvals=0xcbda8dac) at vnode_if.h:303
#15 0xc02100e6 in vop_stdputpages (ap=0xcbda8d60)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_default.c:676
#16 0xc020f6a5 in vop_defaultop (ap=0xcbda8d60)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_default.c:154
#17 0xc02dad89 in ufs_vnoperate (ap=0xcbda8d60)
at /usr/home/alex/work/HEAD/src/sys/ufs/ufs/ufs_vnops.c:2587
#18 0xc02f8621 in vnode_pager_putpages (object=0xcc82b720,
m=0xcbda8ddc,
count=2, sync=0, rtvals=0xcbda8dac) at vnode_if.h:918
#19 0xc02f1b56 in vm_pageout_flush (mc=0xcbda8ddc, count=2, flags=0)
at /usr/home/alex/work/HEAD/src/sys/vm/vm_pager.h:146
#20 0xc02edfd4 in vm_object_page_clean (object=0xcc82b720, start=0,
end=0,
flags=4) at /usr/home/alex/work/HEAD/src/sys/vm/vm_object.c:703
#21 0xc02165e5 in vfs_msync (mp=0xc19c9800, flags=2)
at /usr/home/alex/work/HEAD/src/sys/kern/vfs_subr.c:2393
#22 0xc0217133 in sync_fsync (ap=0xcbda8f5c)
#23 0xc0213714 in sched_sync () at vnode_if.h:441
#24 0xc01ba094 in fork_exit (callout=0xc02135a8 sched_sync, arg=0x0,
frame=0xcbda8fa8) at
/usr/home/alex/work/HEAD/src/sys/kern/kern_fork.c:727
FreeBSD zerogravity.kawo2.rwth-aachen.de 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri Apr
27 19:01:12 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/cichlids
i386
I have the dump, if anyone wants to assist me here, I'd like to help.
Maybe it's even fixed already (I don't know).
Alex
--
cat: /home/alex/.sig: No such file or directory
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Possible Install bug for the following hardware in FreeBSD Stable (4.3)
I had this problem after I enabled the '4092-cylinder limit' jumper on my Maxtor drive, because my BIOS (at that point) hung with a drive over 4092 cylinders. I flashed the BIOS afterwards, but forgot about the jumper, because windows/linux both (somehow) saw the full geometry of the drive. FreeBSD only saw 2014MB until I removed the jumper. Perhaps your drive has a similar jumper? check the manual. Thank you David for the tip. None the less, has this issue witht he driver been addressed? The driver should not bother about that, because the Hard disk reporst the correct size back. On the other, my drive does not have such a jumper, I just checked, so I am really at my wits ends. Thank you _very_ much for your help though, after about238623946 flames and 23862394 stupid replys yours is very nicely detailed...thank you. ad2 29314 MB IBM DTLA-307030 [5956/16/63 at at-1-master UDMA100 29314 * 1024 * 1024 bytes (i.e. 2914 megabytes) == 30736 * 1000 * 1000 bytes (i.e. 2914 million bytes) Its something harddrive manufacturers do to make their drives look bigger... YEs, I just realized that after doing the right calculation: 3736 cylinders of 16065 * 512 bytes I am not a hardware guru ;) Thank you. Content-Type: application/pgp-signature; charset=us-ascii; name=Attachment: 1 Content-Transfer-Encoding: 7bit Content-Description: -- si vis pacem, para bellum 'Doubt thou the stars are fire; Doubt that the sun doth move; Doubt truth to be a liar; But never doubt I love. - Hamelt, Shakespear To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' panic
On Wed, 30 May 2001, David Taylor wrote: When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm madness version first, then tried a version cvsuped today), I reliably get lots of: kernel trap 12 with interrupts disabled messages on the console (one every 5-10 seconds, when the ircd is reasonably loaded). This is because ast() calls addupc_task() with sched_lock held. addupc_task() calls copyin() and copyin() sometimes traps to fault in the profiling buffer. This seems to be just a bug in ast(). userret() is missing the bug. Untested fix: --- Index: trap.c === RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.189 diff -u -1 -r1.189 trap.c --- trap.c 2001/05/23 22:58:09 1.189 +++ trap.c 2001/05/31 13:09:02 @@ -1285,5 +1341,6 @@ mtx_lock(Giant); - mtx_lock_spin(sched_lock); addupc_task(p, p-p_stats-p_prof.pr_addr, p-p_stats-p_prof.pr_ticks); + mtx_lock_spin(sched_lock); + /* XXX why not unlock Giant? */ } --- One thing I got with ircd-hybrid-7 (when very heavily loaded with lots of clones), which I _couldnt_ replicate with the test program (probably because it wasn't very heavily loaded) was a panic: ... kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at /usr/src/sys/kern/kern_sync.c:858 Debugger(panic) Stopped atDebugger+0x45: pushl %ebx db t Debugger(c02fa51b) at Debugger+0x45 panic(c02f9684,c031d2a9,c02fad20,35a,282) at panic+0x70 _mtx_assert(c03a7120,9,c02fad20,35a,282) at _mtx_assert+0x6c mi_switch(d1748420,38,d1748420,e,d17c9e90) at mi_switch+0x25 ithread_schedule(c26e3180,1) at ithread_schedule+0x165 sched_ithd(e) at sched_ithd+0x3d Xresume14() at Xresume14+0x7 -- interrupt, eip = 0xc02c8a18, esp = 0xd17c9ed8, ebp = 0xd17c9f04 -- trap(d1740018,d1740010,8080010,d17c9f72,85d02ec) at trap+0x94 calltrap() at calltrap+0x5 -- trap 0xc, eip = 0xc02c71f5, esp = 0xd17c9f4c, ebp = 0xd17c9f74 -- generic_copyin(d1748420,809073d,1) at generic_copyin+0x39 ast(d17c9fa8) at ast+0x318 doreti_ast() at doreti_ast+0x6 I think this is caused by the same bug. kernel trap almost any with interrupts disabled should be fatal (the case of trap 12 (only) _is_ fatal in my version), but the kernel attempts to fix the problem and continue. This sort of worked when things were locked by disabling interrupts. Now, things may be locked by a spinlock as well as by disabling interrupts, and the corresponding fixup would be to release the spinlock. But this is more obviously wrong. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: freelist corruption: more info
I wrote: Trying to fix some make release problems, I've kept running into the same freelist corruption problems that kris and dougb experienced earlier this week. Main difference is that I notice when the box (-CURRENT from 29 May, GENERIC kernel, UP) crashes. :-p At dougb's urging, I applied Tor's patch to ffs_softdep.c. I *think* the results were positive; my machine made it through a make release apparently successfully. Got the following entries in /var/log/messages though: May 30 20:10:10 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active pagedep May 31 02:18:30 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active pagedep May 31 02:18:30 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active pagedep I guess it should be obvious by now but I have softupdates enabled for all filesystems except for /. Thanks, Bruce. PGP signature
Re: gcc -pg causes 'kernel trap 12 with interrupts disabled' p
On 31-May-01 Bruce Evans wrote: On Wed, 30 May 2001, David Taylor wrote: When trying to profile ircd-hybrid-7 on -CURRENT (I tried using a pre-vm madness version first, then tried a version cvsuped today), I reliably get lots of: kernel trap 12 with interrupts disabled messages on the console (one every 5-10 seconds, when the ircd is reasonably loaded). This is because ast() calls addupc_task() with sched_lock held. addupc_task() calls copyin() and copyin() sometimes traps to fault in the profiling buffer. This seems to be just a bug in ast(). userret() is missing the bug. Untested fix: I think I have some comments in my local code about that sched_lock being bogus. :-/ I'll commit a fix for all platforms today. --- Index: trap.c === RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.189 diff -u -1 -r1.189 trap.c --- trap.c2001/05/23 22:58:09 1.189 +++ trap.c2001/05/31 13:09:02 @@ -1285,5 +1341,6 @@ mtx_lock(Giant); - mtx_lock_spin(sched_lock); addupc_task(p, p-p_stats-p_prof.pr_addr, p-p_stats-p_prof.pr_ticks); + mtx_lock_spin(sched_lock); + /* XXX why not unlock Giant? */ To avoid releasing it just to possibly grab it again afterwards I think, but I'll have to look at this again. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc 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: vmware2 and mutex changes
On 31-May-01 Michael Harnois wrote: I figured out how to get vmware2 to build, but not to run ;( Argh. Do you have the source to host_lock_ppn()? If so can you get me a copy of it that I can give you a patch for? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Possible Install bug for the following hardware in FreeBSD Stable (4.3)
On Thu, 31 May 2001, Darian Lanx wrote: I had this problem after I enabled the '4092-cylinder limit' jumper on my Maxtor drive, because my BIOS (at that point) hung with a drive over 4092 cylinders. I flashed the BIOS afterwards, but forgot about the jumper, because windows/linux both (somehow) saw the full geometry of the drive. FreeBSD only saw 2014MB until I removed the jumper. Perhaps your drive has a similar jumper? check the manual. Thank you David for the tip. None the less, has this issue witht he driver been addressed? The driver should not bother about that, because the Hard disk reporst the correct size back. On the other, my drive does not have such a jumper, I just checked, so I am really at my wits ends. I'm not a hardware guru either, and I know very little about the internals of FreeBSD's IDE drivers, so I'm not sure how windows/linux are detecting the correct geometry, and FreeBSD isn't... Unfortunately, if your drive doesn't have a jumper like that, I've no idea what could be wrong... -- David Taylor [EMAIL PROTECTED] PGP signature
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 04:31:21PM +0900, Seigo Tanimura wrote: Lock of struct filedesc, file, pgrp, session and sigio is now ready for testing. The patch is at http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Compiled on Alpha? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On 31-May-01 David O'Brien wrote: On Thu, May 31, 2001 at 04:31:21PM +0900, Seigo Tanimura wrote: Lock of struct filedesc, file, pgrp, session and sigio is now ready for testing. The patch is at http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Compiled on Alpha? I think that's what he means by testing. :) I.e., he's ready for people to compile it and report problems, etc. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 12:54:26PM -0700, John Baldwin wrote: Lock of struct filedesc, file, pgrp, session and sigio is now ready for testing. The patch is at http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Compiled on Alpha? I think that's what he means by testing. :) I.e., he's ready for people to compile it and report problems, etc. Committers do not need Alpha users to verify that a patch compiles, Beast.freebsd.org can be used for that. Testing on a running system is of course a different matter. It would also be nice to get a timeline on the commit schedule for this. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On 31-May-01 David O'Brien wrote: On Thu, May 31, 2001 at 12:54:26PM -0700, John Baldwin wrote: Lock of struct filedesc, file, pgrp, session and sigio is now ready for testing. The patch is at http://people.FreeBSD.org/~tanimura/patches/fd_pgrp.diff.gz Compiled on Alpha? I think that's what he means by testing. :) I.e., he's ready for people to compile it and report problems, etc. Committers do not need Alpha users to verify that a patch compiles, Beast.freebsd.org can be used for that. Testing on a running system is of course a different matter. It doesn't hurt to help distribute the load some, though. Requiring each person who makes a change to compile it on every possible arch is not something that will scale as more and more archs are added. If a committer can get someone else to perform some of these test compiles and fix any brokenness that comes up I think that is adequate. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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 (witness_destroy+0x237) after booting today's -CURRENT
On 31-May-01 David Wolfskill wrote: Once I saw that I had a real hostname, I hit ^D at the shell prompt, put my fingers in position to hit Alt+F9, and kernel: type 12 trap, code=0 Stopped at witness_destroy+0x237: cmpl%esi,0xc(%edx) db trace witness_destroy(ce7e211c,ce7e211c,ce894f3c,c01ce297,ce7e211c) at witness_destroy+0x237 mtx_destroy(ce7e211c,ce7e2000,ce7e277c,ce7e2660,4) at mtx_destroy+0x73 wait1(ce7e2660,ce894f80,0,ce894fa0,c036e899) at wait1+0x897 wait4(ce7e2660,ce894f80,bfbfb8dc,2,2)) at wait4+0x10 syscall(2f,2f,2f,2,2) at syscall+0x71d syscall_with_err_pushed() at syscall_with_err_pushed+0x1b db Did you get any other messages, such as a faulting virtual address, etc.? Is %edx 0? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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 (witness_destroy+0x237) after booting today's -CURRENT
Date: Thu, 31 May 2001 13:46:01 -0700 (PDT) From: John Baldwin [EMAIL PROTECTED] Did you get any other messages, such as a faulting virtual address, etc.? I had been using vty1; when the panic ocurred, I was (forcibly) switched to vty0. There are no faulting virtual address-flavored messages on vty0. If there were on vty1, I didn't see them quickly enough. Is %edx 0? [Checks man ddb...] Yes, it is. Anything else that might be of interest? I'm about to head into a meeting, but I'll leave the crashed system crashed as long as I can if it might be useful to poke around in there. Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic (witness_destroy+0x237) after booting today's -CURRENT
On 31-May-01 David Wolfskill wrote: Date: Thu, 31 May 2001 13:46:01 -0700 (PDT) From: John Baldwin [EMAIL PROTECTED] Did you get any other messages, such as a faulting virtual address, etc.? I had been using vty1; when the panic ocurred, I was (forcibly) switched to vty0. There are no faulting virtual address-flavored messages on vty0. If there were on vty1, I didn't see them quickly enough. Is %edx 0? [Checks man ddb...] Yes, it is. Anything else that might be of interest? I'm about to head into a meeting, but I'll leave the crashed system crashed as long as I can if it might be useful to poke around in there. Hmm, not that I can think of atm. It looks like the SLIST of all lock in the system got corrupted somehow. :( -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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
OpenBSD dirpref/softupdates code
I have been told that the OpenBSD code that is supposed to speed up some types of file system access up to 60x, has been committed to -current on 4/30. I'm wondering if there's any idea when it will be committed to -stable? Are their any stability issues with the code? ___ Jeremiah Gowdy - IT Manager Sherline Products Inc 3235 Executive Ridge Vista CA 92083-8527 Sales: 1-800-541-0735 International: (760) 727-5857 Fax: (760) 727-7857 ___ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 01:46:00PM -0700, John Baldwin wrote: It doesn't hurt to help distribute the load some, though. Requiring each person who makes a change to compile it on every possible arch is not something that will scale as more and more archs are added. It isn't that hard to put the bits on Freefall and test on all arches. Especially for a _KERNEL_ patch that touches this many files -- some Alpha specific. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock of struct filedesc, file, pgrp, session and sigio
On Thu, May 31, 2001 at 01:46:00PM -0700, John Baldwin wrote: It doesn't hurt to help distribute the load some, though. Requiring each person who makes a change to compile it on every possible arch is not something that will scale as more and more archs are added. If a committer can get someone else to perform some of these test compiles and fix any brokenness that comes up I think that is adequate. Forgot to add, if others use the Alpha owners as simple test-compile resources, (1) the Alpha owners will not get any other work done, (2) will get quite tired of testing things that the patch author could easily test himself. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The FreeBSD core team needs your help
Those of you who have been following the mailing lists will have noticed (or participated in) a thread bemoaning the continued lack of feedback from the core team. That thread is still very active, but one suggestion (made by phk) was to send out a message asking for help getting things done. It's easy to claim that this would work, but first we need to know if anybody would be interested. Here's phk's text: HELP WANTED The FreeBSD core team is looking for an assistant to help with tracking and recording the issues being worked by core. Responsibilities: When a request or question is sent to core@ you reply with an acknowledgement that it has been received, and nag the core team until it has been decided on and replied to. It is also your responsibility to prepare a summary of core@'s businnes once per month and after cores approval of the text, to send this to developers@. This summary should be detailed enough to show the committers which core members participate in the core business and which don't. You will obviously gain insight into the work of and communications of the core team, but apart from the above mentioned summary, this information is of course strictly confidential. Working hours: All. Benefits: The FreeBSD project has a comprehensive benefits plan which you will take full advantage off. The benefits include: Lots and lots of email. birth control (you wont have time to spend with your SO), sunburn protection (you wont have time to spend away from the computer). Despite the appearances, this is not an official request for applicants. We just want to know who would be interested in doing such a thankless task, and whether it's worth core's time to discuss the exact terms of reference (does the person get elected, for example, or appointed?). If you're interested, it's your choice whether you copy -developers, though personally I'd prefer if you just replied to core@. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
