Build fails on usr.bin/uuencode/uuencode.c
Building -CURRENT just failed on my machine, on src/usr.bin/uuencode/uuencode.c Probalby due to the last change (1.8 to 1.9, 9 hours ago from now) which changed just the line that gives the error: FILE *output = stdout; Perhaps this change should be reversed? regards, Michel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Build fails on usr.bin/uuencode/uuencode.c
[EMAIL PROTECTED] (Michel Oosterhof) writes: Building -CURRENT just failed on my machine, on src/usr.bin/uuencode/uuencode.c Probalby due to the last change (1.8 to 1.9, 9 hours ago from now) which changed just the line that gives the error: Just ignore this post, it was fixed in the cvsup of a few minutes ago. michel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Invitation letter from the Organisation Committee of the First World Congress of Future Science and Culture
Dear Sir/Madam, Many of us who came to work in the sciences or similar areas did so because we wanted to explore the unknown and gain more knowledge and ultimately make this world a better place. It is undoubtedly true that modern science has brought immense benefits to humanity but also encountered many unsolved questions and problems including environmental pollution. Perhaps it is now time for a different approach: Falun Dafa takes a holistic view of life and the universe. It builds on the insights of modern science and combines them with the insights from ancient Chinese science and culture. We, scientists who understand Falun Dafa, invite you to participate in the First World Congress of Future Science and Culture that will be held at Cambridge on March 9th and 10th of 2002. This congress will see state of the art research in this field and serve as a forum for discussing how these new ideas could exert a profound influence on the future science and culture of humankind. Renowned specialists and professors in diverse academic disciplines from many different parts of the world will be participating. A schedule for March 9th is attached. On March 10 we will be holding an informal discussion session at which participants at the conference can raise issues with the speakers. We do hope that you will be able to find the time to attend. Please let us know if you have any questions. Yours sincerely, Dr Guihua Li Organisation Committee of First World Congress of Future Science and Culture [EMAIL PROTECTED] http://www.fsc-congress.org Invitation-Peter2.doc Description: MS-Word document
bktr now fails
I used to be able to use my Brooktree card with no problem. However, a month or so ago, I started getting this at boot: bktr0: BrookTree 878 mem 0xf500-0xf5000fff irq 9 at device 12.0 on pci2 bktr0: could not map memory device_probe_and_attach: bktr0 attach returned 6 pci2: multimedia at device 12.1 (no driver attached) Any ideas? -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota Times are bad. Children no longer obey their parents, and everyone is writing a book. -- Marcus Tullius Cicero To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: simplelock to lock_class?
On 04-Mar-02 ouyang kai wrote: Hi, eveyone, I found the FreeBSD4.x defined the simplelock in the sys/sys/lock.h. But, it doesn't exist in FreeBSD5.0, why? If I want use the FreeBSD4.x simplelock function, how and what can I use in FreeBSD5.0? 5.0 has different locking primitives than 4.x. What are you using a simplelock for on 4.x? That will help decide which locking primitive you would need to use in 5.0 to obtain similar semantics/behavior. -- 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: blockable sleep panic on Alpha / current
On 04-Mar-02 Wilko Bulte wrote: During a make release I just got a panic. The build progressed until: gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 imaxabs.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 imaxdiv.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 labs.3.gz The running system is a -current as of today. The panic: login: FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x7,a0=0x6 db db trace Debugger() at Debugger+0x34 panic() at panic+0x188 witness_lock() at witness_lock+0xb4 _mtx_lock_flags() at _mtx_lock_flags+0xd8 trap() at trap+0x4c8 XentMM() at XentMM+0x2c --- memory management fault (from ipl 7) --- statclock_process() at statclock_process+0x1d4 We did something stupid like dereference a NULL pointer here. Can you pull up gdb on kernel.debug and do 'l *statclock_process+0x1d4'? XentMM() at XentMM+0x2c --- memory management fault --- ithread_schedule() at ithread_schedule+0xa4 Eww, we have another one here. alpha_dispatch_intr() at alpha_dispatch_intr+0x130 interrupt() at interrupt+0x138 XentInt() at XentInt+0x28 --- interrupt (from ipl 0) --- critical_exit() at critical_exit+0x1c _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 vm_fault1() at vm_fault1+0x110c vm_fault() at vm_fault+0x64 trap() at trap+0x6d8 XentMM() at XentMM+0x2c --- memory management fault --- pmap_enter_quick() at pmap_enter_quick+0x1d4 Ugh, this is probably the real bug. :( Can you do a list on this address? pmap_object_init_pt() at pmap_object_init_pt+0x1a4 vm_map_insert() at vm_map_insert+0x35c elf_load_section() at elf_load_section+0x190 exec_elf_imgact() at exec_elf_imgact+0x278 execve() at execve+0x324 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (59, FreeBSD ELF, execve) --- --- user mode --- db -- | / o / /_ _[EMAIL PROTECTED] |/|/ / / /( (_) BulteArnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-alpha in the body of the message -- 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: Patch for critical_enter()/critical_exit() interrupt assem
On 01-Mar-02 Matthew Dillon wrote: : : :On 28-Feb-02 Matthew Dillon wrote: : Not to put too fine a point on it, but, I don't see how this can : possibly justify preventing me from committing my critical_*() stuff. : You've just stated publically that your preemption stuff is unusable : as it currently stands. Why am I supposed to wait an arbitrary period : of time for you to fix, test, and commit it? : : I would REALLY like to commit my critical_*() stuff, and for the record : this will also include the stage-2 stuff described in the original : commit : comments that will be made a few days after the current commit. : :Because the critical_* changes you are doing don't match up to the overall :design. See my mail to -arch for more on that though. At some point in the :future I think that this work can fit in rather well to the cpu_critical_foo :stuff (which can be split out from critical_enter/exit now). However, at :this :stage I would rather avoid complex optimizations of APIs that may change in :the :future. There is more to be gained from locking subsystems. :... :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ :Power Users Use the Power to Serve! - http://www.FreeBSD.org/ I strongly disagree. I have yet to see any technical description of this so-called overall design that shows any incompatibility, and what I decide to do with my time is my business. I don't really care whether you are ready for 'optimizations' or not. I seem to recall that you had similar objections when I started pushing Giant into the system calls, yet that work is in hind sight an obvious enabler for other work people have been doing and committing. No, I actually requested that Giant be pushed down into the syscalls and Maxime Henrion is working on finishing that work right now. I decided to address a serious issue that I've had with those routines for months because you consistently refused to even entertain the notion that you may have constructed the API wrong. Frankly, I feel that these changes both optimize and properly abstract the critical_*() code. I strongly believe that the abstraction you have in there now is improper. My patches have been tested, they work, and they ARE going to be committed as soon as I am able to do so. I believe you are overstepping your bounds as a committer by attempting to scrap them and I also believe that you do not fully understand the implications of the code, because you are blinded by the notion that I am making adjustments to your API. But I do, BDE does, Julian does, as do others. To me these changes are essential, and they must go in now before even more hacks are committed to the codebase to get around existing limitations. There are already hacks in the trampoline/fork_exit and ast code that seriously pollutes the MD/MI boundry, all of which you've flicked off your shoulder and explained away as being allowed by your API, and Peter added a third hack with his pmap commit (which got backed-out when he backed out the commit). These hacks make it crystal clear to me that you critical_*()/cpu_critical*() API is seriously flawed. I am addressing the issue and cleaning up the hacks to create a proper MD/MI separation of the code. Actually, I responded saying that I was willing to talk about how to properly abstract CRITICAL_FORK (which is gross I admit). If you will read the design doc, you will see that actually critical_foo and cpu_critical_foo can now be safely split up and made independent of each other. To this extent td_critnest would still stay MI, but td_savecrit could end up going away if the MD code fully handles the saving/restoring the state for whatever cpu_critical_* become. It makes no sense whatsoever to me to be told not to commit something due to stale code that may not be quite compatible sitting in P4 that you can't make work in any reasonable time frame. You should stop trying to screw over my work and instead look to your own. You have so many balls in the air constructed in a fine mesh that you can't seem to accept a single change to your perfectly meshing subsystems, half of which are going stale in P4. This is greatly restricting your ability to consider deviation. *sigh* The only reason I'm not spending my cycles tracking down the preemption bugs so that preemption can go in is that I have decided that at the moment there is more gain to be found by doing actual locking work. This means that preemption will eventually go in, just Not Right Now. To that extent, I don't think premature optimizations based on observations of a kernel locked entirely by Giant that alter the API's preemption will change (and that were originally introduced when I committed all the bits of the preemption code
aliases
Is there a known bug or particular reason I can't add network aliases in -current? -- Adam Webb To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep panic on Alpha / current
On Tue, Mar 05, 2002 at 10:51:53AM -0500, John Baldwin wrote: On 04-Mar-02 Wilko Bulte wrote: During a make release I just got a panic. The build progressed until: gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 imaxabs.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 imaxdiv.3.gz gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 labs.3.gz The running system is a -current as of today. The panic: login: FreeBSD/alpha (ds10.wbnet) (ttyd0) login: panic: blockable sleep lock (sleep mutex) Giant @ ../../../alpha/alpha/tr ap.c:482 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x7,a0=0x6 db db trace Debugger() at Debugger+0x34 panic() at panic+0x188 witness_lock() at witness_lock+0xb4 _mtx_lock_flags() at _mtx_lock_flags+0xd8 trap() at trap+0x4c8 XentMM() at XentMM+0x2c --- memory management fault (from ipl 7) --- statclock_process() at statclock_process+0x1d4 We did something stupid like dereference a NULL pointer here. Can you pull up gdb on kernel.debug and do 'l *statclock_process+0x1d4'? Is gdb broken on Alpha, or is it just me? ds10#gdb ^C ds10#gdb -k ^C ds10# In short, gdb just sits there (??). On x86/stable I get: wb ~: gdb 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. (gdb) wb ~: wb ~: etc I'll to reproduce the problem again. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aliases
On Tue, 5 Mar 2002, Adam Webb wrote: Is there a known bug or particular reason I can't add network aliases in -current? -- Adam Webb None that I know of, although there does seem to be at least one bug relating to removable interfaces and dhclient. It might be useful to include some sample output relating to adding aliases to demonstrate how it's not working for you. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep panic on Alpha / current
Wilko Bulte writes: Is gdb broken on Alpha, or is it just me? ds10#gdb ^C ds10#gdb -k ^C ds10# In short, gdb just sits there (??). Yes, David's new binutils import broke it. I have a workaround, but it causes buildworld breakage. Sigh. You can just use a /usr/libexec/elf/gdb from -stable. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Damn slow startup
Hi everybody I recently updated through cvsup a 4.5 stable FreeBSD running on Vmware. I followed the instructions from the handbook building both the world and the GENERIC kernel. When I finally rebooted, It takes almost 2-3 hours to boot being extremely slow. I never really let it finish booting and started doing it all over again. Does this have smth to do with the WITNESS kernel option? If no do you have any idea as to what might be wrong. George _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Damn slow startup
Run -stable. VMWare takes a very long time to emulate certain locking primitives, for some reason. -- Terry George V. Balis wrote: Hi everybody I recently updated through cvsup a 4.5 stable FreeBSD running on Vmware. I followed the instructions from the handbook building both the world and the GENERIC kernel. When I finally rebooted, It takes almost 2-3 hours to boot being extremely slow. I never really let it finish booting and started doing it all over again. Does this have smth to do with the WITNESS kernel option? If no do you have any idea as to what might be wrong. George _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 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: bktr now fails
In message: [EMAIL PROTECTED] Michael D. Harnois [EMAIL PROTECTED] writes: : I used to be able to use my Brooktree card with no problem. However, a : month or so ago, I started getting this at boot: : : bktr0: BrookTree 878 mem 0xf500-0xf5000fff irq 9 at device 12.0 on pci2 : bktr0: could not map memory : device_probe_and_attach: bktr0 attach returned 6 : pci2: multimedia at device 12.1 (no driver attached) : : Any ideas? Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Damn slow startup
or tell teh config it is a 386 cpu as well as a '686 that will force it to emulate those very slowly done instructins so that they are actually done faster :-) On Tue, 5 Mar 2002, Terry Lambert wrote: Run -stable. VMWare takes a very long time to emulate certain locking primitives, for some reason. -- Terry George V. Balis wrote: Hi everybody I recently updated through cvsup a 4.5 stable FreeBSD running on Vmware. I followed the instructions from the handbook building both the world and the GENERIC kernel. When I finally rebooted, It takes almost 2-3 hours to boot being extremely slow. I never really let it finish booting and started doing it all over again. Does this have smth to do with the WITNESS kernel option? If no do you have any idea as to what might be wrong. George _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep panic on Alpha / current
On Tue, Mar 05, 2002 at 10:51:53AM -0500, John Baldwin wrote:
Hi John,
On 04-Mar-02 Wilko Bulte wrote:
During a make release I just got a panic. The build progressed until:
gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 imaxabs.3.gz
gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 imaxdiv.3.gz
gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 labs.3.gz
The running system is a -current as of today.
The panic:
login:
FreeBSD/alpha (ds10.wbnet) (ttyd0)
login: panic: blockable sleep lock (sleep mutex) Giant @
../../../alpha/alpha/tr
ap.c:482
cpuid = 0; panic
Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x7,a0=0x6
db
db trace
Debugger() at Debugger+0x34
panic() at panic+0x188
witness_lock() at witness_lock+0xb4
_mtx_lock_flags() at _mtx_lock_flags+0xd8
trap() at trap+0x4c8
XentMM() at XentMM+0x2c
--- memory management fault (from ipl 7) ---
statclock_process() at statclock_process+0x1d4
We did something stupid like dereference a NULL pointer here. Can you pull up
gdb on kernel.debug and do 'l *statclock_process+0x1d4'?
Thanks to Drew for confirming that -current's gdb is hosed. Using the
-stable gdb I get better results.
Anyway:
(kgdb) l *statclock_process+0x1d4
0xfc3d1ed4 is in statclock_process (../../../kern/kern_clock.c:447).
442
443 /* Update resource usage integrals and maximums. */
444 if ((pstats = p-p_stats) != NULL
445 (ru = pstats-p_ru) != NULL
446 (vm = p-p_vmspace) != NULL) {
447 ru-ru_ixrss += pgtok(vm-vm_tsize);
448 ru-ru_idrss += pgtok(vm-vm_dsize);
449 ru-ru_isrss += pgtok(vm-vm_ssize);
450 rss = pgtok(vmspace_resident_count(vm));
451 if (ru-ru_maxrss rss)
(kgdb)
XentMM() at XentMM+0x2c
--- memory management fault ---
ithread_schedule() at ithread_schedule+0xa4
Eww, we have another one here.
(kgdb) l *ithread_schedule+0xa4
0xfc3e2924 is in ithread_schedule (../../../kern/kern_intr.c:375).
370 random_harvest(entropy, sizeof(entropy), 2, 0,
371 RANDOM_INTERRUPT);
372 }
373
374 td = ithread-it_td;
375 p = td-td_proc;
376 KASSERT(p != NULL, (ithread %s has no process,
ithread-it_name));
377 CTR4(KTR_INTR, %s: pid %d: (%s) need = %d, __func__,
p-p_pid, p-p_comm,
378 ithread-it_need);
379
(kgdb)
alpha_dispatch_intr() at alpha_dispatch_intr+0x130
interrupt() at interrupt+0x138
XentInt() at XentInt+0x28
--- interrupt (from ipl 0) ---
critical_exit() at critical_exit+0x1c
_mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4
vm_fault1() at vm_fault1+0x110c
vm_fault() at vm_fault+0x64
trap() at trap+0x6d8
XentMM() at XentMM+0x2c
--- memory management fault ---
pmap_enter_quick() at pmap_enter_quick+0x1d4
Ugh, this is probably the real bug. :( Can you do a list on this address?
(kgdb) l *pmap_enter_quick+0x1d4
0xfc52c314 is in pmap_enter_quick
(../../../alpha/alpha/pmap.c:2422).
2417pmap_insert_entry(pmap, va, mpte, m);
2418
2419/*
2420 * Increment counters
2421 */
2422pmap-pm_stats.resident_count++;
2423
2424/*
2425 * Now validate mapping with RO protection
2426 */
(kgdb)
I hope this makes sense. I still hope to catch a dump. Or
alternatively I hope it get's caught by ddb.
W/
--
| / o / /_ _ [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte Arnhem, the Netherlands
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
: It makes no sense whatsoever to me to be told not to commit something : due to stale code that may not be quite compatible sitting in P4 that : you can't make work in any reasonable time frame. You should stop : trying to screw over my work and instead look to your own. You have : so many balls in the air constructed in a fine mesh that you can't seem : to accept a single change to your perfectly meshing subsystems, half : of which are going stale in P4. This is greatly restricting your : ability to consider deviation. : :*sigh* The only reason I'm not spending my cycles tracking down the preemption :bugs so that preemption can go in is that I have decided that at the moment :there is more gain to be found by doing actual locking work. This means that :preemption will eventually go in, just Not Right Now. To that extent, I don't :think premature optimizations based on observations of a kernel locked entirely :by Giant that alter the API's preemption will change (and that were originally :introduced when I committed all the bits of the preemption code that I could :w/o breaking the kernel) should go in. Those are your cycles, not mine. Why should I be forced to sit on my heals for an unknown period of time (but so far 3 weeks waiting for the ucred changes and 2 weeks waiting for critical_*()), twiddling my thumbs wasting MY cycles just because of your own scheduling issues? That's really the crux of this whole situation. I don't think it is appropriate for you to impose your development methodology on me or anyone else, and I most especially do not think it is appropriate for you to arbitrarily hold off the hard work that I have done in order to fit it into your schedule. I have said very clearly what I intend these critical_*() patches to do. I have said, repeatedly, that I do not believe they would intefere with your work in any significant manner. You have yet to explain in any detail why you think they would. I have said, repeatedly, that I am perfectly willing to work with you later on when you ARE ready to move forward on your own work. That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have given so far. -Matt Matthew Dillon [EMAIL PROTECTED] :-- : :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ :Power Users Use the Power to Serve! - http://www.FreeBSD.org/ : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
In message [EMAIL PROTECTED], Matthew Dillon wri tes: That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have given so far. Why don't you for a change, just stop being so ego-centered and instead head to the page at http://www.freebsd.org/smp/ and find yourself a task which is free for grabs, rather than insist that you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. One could point at such a gem as: add locking to NFS which I am sure John and the rest of us would love to see you tackle... Give us peace Matt... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Tue, Mar 05, 2002 at 06:30:08PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon wri tes: That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have given so far. Why don't you for a change, just stop being so ego-centered and instead head to the page at http://www.freebsd.org/smp/ and find yourself a task which is free for grabs, rather than insist that you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. One could point at such a gem as: add locking to NFS which I am sure John and the rest of us would love to see you tackle... Hey, that's not fair. Instead of occasionally throwing in the do what John tells you argument, why don't you either present a real technical argument as to why Matt's stuff is bad (I'm not saying there isn't one) or, for that matter, add locking to NFS yourself? Give us peace Matt... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: blockable sleep panic on Alpha / current
On Tue, Mar 05, 2002 at 05:57:01PM +0100, Wilko Bulte wrote: Is gdb broken on Alpha, or is it just me? ds10#gdb ^C ds10#gdb -k Can you give the gdb51 port a try? We really need to see how usable that is on Alpha. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
On Mon, 4 Mar 2002, Julian Elischer wrote: On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: Julian, thank you very much for a such detailed answer :) [...] I just checked in some generic timeout routines into ng_base.c in -current. have a look and see if they make sense to you To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bktr now fails
On Tue, 2002-03-05 at 12:10, M. Warner Losh wrote: Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE You da man. Thanks! -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota If you want to follow Jesus, you better look good on wood. --Daniel Berrigan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bktr now fails
In message: [EMAIL PROTECTED] Michael D. Harnois [EMAIL PROTECTED] writes: : On Tue, 2002-03-05 at 12:10, M. Warner Losh wrote: : : Humor me and compile PCI_ALLOW_UNSUPPORTED_IO_RANGE : : You da man. Thanks! You should never need to define that option, so it means that the range clipping is (still) bogus :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Netgraph, device drivers and mutexes
Julian, On Mon, 4 Mar 2002, Julian Elischer wrote: On Mon, 4 Mar 2002, Maksim Yevmenkin wrote: Julian, thank you very much for a such detailed answer :) [...] I just checked in some generic timeout routines into ng_base.c in -current. have a look and see if they make sense to you than you, i just checked them via CVS web. looks mighty handy to me :) i will cvsup later and try them out. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problems with shutting machine now
Hi, I used portupgrade for the first time a few nights ago. I got through doing a few ports before having to shut the machine down. Now every time I issue the halt command I get the following message Synching discs.. 18 18 18 18 18 18 18 18 18 then something about giving up on the last two buffers (apologies for not being specific, am currently at work away from the machine) Since I have never seen this before I was wondering if one of the ports I upgraded could have broken it. I was going to try and finishing the portupgrade -ra then do a buildworld (will be my first attempt at one) to correct it. I was wondering though if anybody on the list had any other ideas? thanks, Michael Ross [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gtags? htags?
Are these supposed to be part of the base install of FreeBSD? I can't find them anywhere and they're not in ports. They're needed for the tags: target in the kernel makefiles and since I'd like to be able to browse code... Thanks for any pointers, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Won't boot after the commits to timecounter code
Hello. After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped booting just after the message: Timecounter i8254 frequency 1193182 Hz With some debugging printf()'s inserted, I found it was tc-tc_get_timecount() called from tco_delta() called just after the bcopy() in tc_windup(). So maybe the next place I have to look at is i8254_get_timecount(), which is in /sys/i386/isa/clock.c, but the last (effective) commit to this file is revision 1.180(at the end of January). I couldn't even drop into DDB; no response other than to power button. The last bootable(and stable so far) kernel is from 2002-02-24. I don't think this is caused by some leftover in the work directory since I always build kernels in a new empty directory under /usr/obj. Any (clue|fix)\? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Won't boot after the commits to timecounter code
The only thing I know off right now is this thing from BDE which I havn't been able to verify yet: From:Bruce Evans [EMAIL PROTECTED] Subject: dummy_timecounter broken; breaks booting with -d To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date:Tue, 05 Mar 2002 08:09:26 +1100 %%% Index: kern_tc.c === RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v retrieving revision 1.116 diff -u -2 -r1.116 kern_tc.c --- kern_tc.c 26 Feb 2002 09:16:27 - 1.116 +++ kern_tc.c 4 Mar 2002 21:08:03 - @@ -192,4 +252,14 @@ gen = tc-tc_generation; bintime2timeval(tc-tc_offset, tvp); + /* +* XXX dummy_timecounter is now broken. Its tc_get_timecount +* needs to be called before it works, and that doesn't +* always happen naturally. In particular, we spin forever +* here after booting with -d unless we do an unnatural call +* here, since the screen timeout code is always run on entry +* to ddb, and it calls here. +*/ + if (gen == 0 timecounter == dummy_timecounter) + (void)tc-tc_get_timecount(tc); } while (gen == 0 || gen != tc-tc_generation); } %%% Bruce In message 20020306054514.GA395@gzl, [EMAIL PROTECTED] writes: Hello. After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped booting just after the message: Timecounter i8254 frequency 1193182 Hz With some debugging printf()'s inserted, I found it was tc-tc_get_timecount() called from tco_delta() called just after the bcopy() in tc_windup(). So maybe the next place I have to look at is i8254_get_timecount(), which is in /sys/i386/isa/clock.c, but the last (effective) commit to this file is revision 1.180(at the end of January). I couldn't even drop into DDB; no response other than to power button. The last bootable(and stable so far) kernel is from 2002-02-24. I don't think this is caused by some leftover in the work directory since I always build kernels in a new empty directory under /usr/obj. Any (clue|fix)\? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Should 4.5-STABLE - 5.0-CURRENT work?
Hello. I have had a small problem last night going from a 4.5-STABLE system (FreeBSD wabbit.ldc.ro 4.5-STABLE FreeBSD 4.5-STABLE #0: Sun Feb 17 08:58:11 EET 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/WABBIT i386) to current. Last cvsup for current was Mar 5, 22:50 UTC, from cvsup5.freebsd.org. The fail seems to happen in one true awk. However, I seem to remember a 4.5-RELEASE to 5.0-CURRENT working perfectly around March 2nd. Attached are last 200 lines of buildworld output, and current supfile. Thank you Alex +-- Alex Popa, | Artificial Intelligence is [EMAIL PROTECTED]| no match for Natural Stupidity +-- It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here. cd /usr/src/secure/usr.bin/ssh; make _EXTRADEPEND echo ssh: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a /usr/obj/usr/src/i386/usr/lib/libutil.a /usr/obj/usr/src/i386/usr/lib/libz.a .depend === secure/usr.bin/ssh-add rm -f .depend mkdep -f .depend -a-DNO_IDEA /usr/src/secure/usr.bin/ssh-add/../../../crypto/openssh/ssh-add.c cd /usr/src/secure/usr.bin/ssh-add; make _EXTRADEPEND echo ssh-add: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a .depend === secure/usr.bin/ssh-agent rm -f .depend mkdep -f .depend -a-DNO_IDEA /usr/src/secure/usr.bin/ssh-agent/../../../crypto/openssh/ssh-agent.c cd /usr/src/secure/usr.bin/ssh-agent; make _EXTRADEPEND echo ssh-agent: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a .depend === secure/usr.bin/ssh-keygen rm -f .depend mkdep -f .depend -a-DNO_IDEA /usr/src/secure/usr.bin/ssh-keygen/../../../crypto/openssh/ssh-keygen.c cd /usr/src/secure/usr.bin/ssh-keygen; make _EXTRADEPEND echo ssh-keygen: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a .depend === secure/usr.bin/ssh-keyscan rm -f .depend mkdep -f .depend -a-DNO_IDEA /usr/src/secure/usr.bin/ssh-keyscan/../../../crypto/openssh/ssh-keyscan.c cd /usr/src/secure/usr.bin/ssh-keyscan; make _EXTRADEPEND echo ssh-keyscan: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a .depend === secure/usr.sbin === secure/usr.sbin/sshd rm -f .depend mkdep -f .depend -a-DLIBWRAP -DHAVE_LOGIN_CAP -DLOGIN_ACCESS -I/usr/src/secure/usr.sbin/sshd/../../../usr.bin/login -DUSE_PAM -DHAVE_PAM_GETENVLIST -DSKEY -DXAUTH_PATH=\/usr/X11R6/bin/xauth\ -DNO_IDEA /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshd.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-rhosts.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-passwd.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-rsa.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-rh-rsa.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshpty.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/sshlogin.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/servconf.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/serverloop.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth1.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth2.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-options.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/session.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-chall.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth2-chall.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/auth-pam.c /usr/src/secure/usr.sbin/sshd/../../../usr.bin/login/login_access.c /usr/src/secure/usr.sbin/sshd/../../../crypto/openssh/groupaccess.c cd /usr/src/secure/usr.sbin/sshd; make _EXTRADEPEND echo sshd: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libopie.a /usr/obj/usr/src/i386/usr/lib/libmd.a /usr/obj/usr/src/i386/usr/lib/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypt.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a /usr/obj/usr/src/i386/usr/lib/libutil.a /usr/obj/usr/src/i386/usr/lib/libz.a /usr/obj/usr/src/i386/usr/lib/libwrap.a /usr/obj/usr/src/i386/usr/lib/libpam.a .depend === share === share/colldef === share/dict === share/examples === share/man === share/man/man1 === share/man/man3 === share/man/man4 === share/man/man4/man4.i386 === share/man/man5 === share/man/man6 === share/man/man7 === share/man/man8 === share/man/man8/man8.i386 === share/man/man9 === share/me === share/misc === share/mk === share/mklocale === share/monetdef === share/msgdef === share/numericdef === share/skel === share/syscons ===
