Re: HEADS-UP: await/asleep removal imminent
It seems Alfred Perlstein wrote: Now this is "interesting", I booted on your kernel, and it has run through make world 4 times in a row... So I felt lucky, checked out a new fresh src/sys tree, and made a new kernel from the config file you used, reboot, starts test, and *HANG* Hmm!! Now I have tried a sys tree from today (0800 CET) two days ago and a week ago, and all 3 of them produces the lockup. So the only thing I can think of is that you guys have something in your src trees that cvs I dont... Now what ? What are the compile flags you are using? Run of the mill std /etc/defaults/make.conf nothing else, just copied from /usr/src/defaults/make.conf... And a clean env also btw... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On 18-Jan-01 Alfred Perlstein wrote: * Soren Schmidt [EMAIL PROTECTED] [010118 00:03] wrote: It seems John Baldwin wrote: Anyhow, I have asked before to have you guys supply me with a kernel that has been compiled "the right way" and I'll test it out here just to make sure I dont do anything stupid.. Just a bare bones kernel, fxp ata drivers will do nicely for the serverworks thingy, give me an URL I can get it from or put it on ftp.freebsd.dk/incoming and give my a ping when its there... http://www.FreeBSD.org/~jhb/kernel.sos It was compiled wtih INCLUDE_CONFIG_FILE, so you can grab the config file from that. Now this is "interesting", I booted on your kernel, and it has run through make world 4 times in a row... So I felt lucky, checked out a new fresh src/sys tree, and made a new kernel from the config file you used, reboot, starts test, and *HANG* Hmm!! Now I have tried a sys tree from today (0800 CET) two days ago and a week ago, and all 3 of them produces the lockup. So the only thing I can think of is that you guys have something in your src trees that cvs I dont... Now what ? What are the compile flags you are using? I actually used this: CFLAGS ?= -O -pipe -mcpu=i686 -march=i686 COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686 All the diffs in sys/ on the box I built this kernel on are at http://www.FreeBSD.org/~jhb/patches/sys-mutex.patch. One possibly notable patch I had forgotten about is the fix to forward_signal() to lock with sched_lock. I've just committed that though. -- 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: HEADS-UP: await/asleep removal imminent
It seems John Baldwin wrote: So the only thing I can think of is that you guys have something in your src trees that cvs I dont... Now what ? What are the compile flags you are using? I actually used this: CFLAGS ?= -O -pipe -mcpu=i686 -march=i686 COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686 All the diffs in sys/ on the box I built this kernel on are at http://www.FreeBSD.org/~jhb/patches/sys-mutex.patch. One possibly notable patch I had forgotten about is the fix to forward_signal() to lock with sched_lock. I've just committed that though. OK, I have installed those patches and will try out a kernel build on that asap -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
[EMAIL PROTECTED] wrote: The enclosed patch implements a virtual NMI pushbutton by programming the IOAPIC to deliver an NMI when sio1 generates an interrupt. This would be a nice kernel option... :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "There is no spoon." -- Kiki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Soren Schmidt wrote: I actually used this: CFLAGS ?= -O -pipe -mcpu=i686 -march=i686 COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686 All the diffs in sys/ on the box I built this kernel on are at http://www.FreeBSD.org/~jhb/patches/sys-mutex.patch. One possibly notable patch I had forgotten about is the fix to forward_signal() to lock with sched_lock. I've just committed that though. OK, I have installed those patches and will try out a kernel build on that asap Hmm, now we are getting somewhere, it ran through a make world with that patch installed! I'll test some more, maybe you should get it all committed it seems to make a hell of a difference -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic breakage?
On Wed, 17 Jan 2001, Garrett Wollman wrote:
On Tue, 16 Jan 2001 19:10:10 -0800, Alfred Perlstein [EMAIL PROTECTED] said:
Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'?
add longword, add longword with carry? I know it would be pretty
ugly, but it should work, no?
The two bus cycles are independent, so there is a race condition.
OTOH, it's a fairly *unlikely* race condition, and the worst thing
that can happen is statistics that are obviously off by four billion.
(The race only occurs when there is a carry out of the low-order
longword, which is to say, once in every 2**32 operations.)
If they are obviously off by precisely four billion, then they can be
corrected :-).
I have thought of using special overflow handling methods to reduce the
cost of keeping statistics. E.g.:
---
uint32_t counter[2];
/* Low-level code increments only the lower 32 bits of counters. */
atomic_add_32(counter[0]), 1);
/*
* Counter daemon adjusts counters before they get anywhere near
* overflowing. It must run often enough to prevent overflow
* (not very often). This also make the race in the adjustment
* code harmless.
*/
KASSERT(counter[0] 0xC000, "counter got near overflowing");
if (counter[0] 0x8000) {
atomic_subtract_32(counter[0], 0x8000);
++counter[1];
}
/*
* Clients must use code like the following to convert counters
* to values. More locking is required to load counter[0] and
* counter[1] atomically, but this is not a new problem (e.g.,
* atomicity is mostly accidental for accesses via kmem).
*/
counter_value = ((uint64_t)counter[1] 31) | counter[0];
---
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Wed, Jan 17, 2001 at 11:34:09PM -0700, Warner Losh wrote: That's a red herring. The new features thing is what I mean. If I were creating a product, I'd want one that is supported. So even if I don't *NEED* a feature in 5.x, I might migrate my product to 5.x so that I can continue to get bug fixes and leverage more support than I can get with an older rev. One of the 5.x features might well be a new compiler. I don't see that sort of thing being back ported to 4.x at this point. I see. I guess that makes sense, although I don't see support for 4.x dropping until sometime in 2003 (speaking in terms of the FreeBSD Project, not necessarily commercial shops like BSDI). That's one of the big reasons that we're 4.x based right now rather than 3.x based, despite 4.x's slightly larger memory footprint. That and 4.x's much better c++ compiler. Well, Warner, I've never done embedded systems. So, tell me, do they actually use any C++ code in embedded systems? C++ has a rather high overhead as far as disk space memory goes. I would imagine that 99%+ of embedded systems do not use C++ code except perhaps for a very small amount of the code. -- wca #include std/disclaimer.h: Not speaking for FreeBSD, just myself. PGP signature
Re: HEADS-UP: await/asleep removal imminent
It seems Peter Wemm wrote: Hmm. with the mp_machdep.c fix committed, that leaves the only other significant difference being the re-enable of HLT when a cpu goes idle in i386/i386/machdep.c. That still lockups, tried a freshly checked out sys... The refcount.[ch] stuff is not relevant to this problem. The kern/subr_prf.c change doesn't *appear* to be a likely candidate, unless you are printing lots of console messages during the buildworld.. The kern/vfs_aio.c are not relevant as VFS_AIO is not in GENERIC. The rest are comments, mtx_assert()'s or DDB activation related. Soren, can you retest a buildworld with the currently committed kernel with no other changes? Let us see if the forward_signal() stuff is the culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT the idle CPU. (if *that* makes a difference then we have got trouble!) I'll try adding the forward_signal stuff see if that helps... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
Soren Schmidt wrote: It seems Peter Wemm wrote: Hmm. with the mp_machdep.c fix committed, that leaves the only other significant difference being the re-enable of HLT when a cpu goes idle in i386/i386/machdep.c. That still lockups, tried a freshly checked out sys... The refcount.[ch] stuff is not relevant to this problem. The kern/subr_prf.c change doesn't *appear* to be a likely candidate, unless you are printing lots of console messages during the buildworld.. The kern/vfs_aio.c are not relevant as VFS_AIO is not in GENERIC. The rest are comments, mtx_assert()'s or DDB activation related. Soren, can you retest a buildworld with the currently committed kernel with no other changes? Let us see if the forward_signal() stuff is the culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT the idle CPU. (if *that* makes a difference then we have got trouble!) I'll try adding the forward_signal stuff see if that helps... But John committed that! it should be in the fresh checkout you tried above Of course, that is assuming you cvsup'ed very recently.. -Søren Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: spin lock (null) held by 0x0 for 5 seconds on 486 w/ ISA
Hello! This is an old 486 of mine which never ran FreeBSD before. It has only ISA and VL bus. When booting a trimmed down GENEIRC kernel from today, it shows the copyright lines and then this: panic: spin lock (null) held by 0x0 for 5 seconds. This line repeats approx. every 30 seconds This is JFYI, I haven't tried a DDB kernel (since it has to fit on the floppy). The same kernel runs fine on a PIII and a K6-2, though. 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: HEADS-UP: await/asleep removal imminent
It seems Peter Wemm wrote:
I'll try adding the forward_signal stuff see if that helps...
But John committed that! it should be in the fresh checkout you tried
above Of course, that is assuming you cvsup'ed very recently..
Sorry that was not what I meant, I meant this patch to machdep.c
and so far it looks as thats the culprit it hasn't locked up yet
at least, but its not finished a world yet
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.429
diff -u -r1.429 machdep.c
--- machdep.c 2001/01/16 09:10:33 1.429
+++ machdep.c 2001/01/18 13:44:48
@@ -1005,6 +1005,10 @@
void
cpu_idle(void)
{
+#ifdef SMP
+ /* first candidate for an interrupt */
+ lapic.tpr = 0;
+#endif
#ifndef SMP
if (cpu_idle_hlt) {
disable_intr();
-Sren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
how about to have in a distribution two version of GENERIC kernel (and modules of course) and let sysinstall choose right set ? In article [EMAIL PROTECTED] you wrote: On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote: On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: Wont this make installing using sysinstall a bit hard? I know the generic kernel includes all the CPU lines, so that all cpu's are recognized... so are you going to just take this line out of the generic kernel, and have a special kern.flp disk with a generic kernel that only has the i386 support in it? I don't think it's worth the effort. By the time 5.0-RELEASE goes out, the 386 will have been around for over 10 years (actually I think it has already reached that point and gone beyond). There are not likely to be many more installs of FreeBSD on 386's, let alone 5.x installs. People who *really* want to install 5.x on a 386 can generate their own kernel and such. Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Greg -- Finger [EMAIL PROTECTED] for PGP public key 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- end of forwarded message -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
In message [EMAIL PROTECTED] Will Andrews writes: : Well, Warner, I've never done embedded systems. So, tell me, do they : actually use any C++ code in embedded systems? C++ has a rather high : overhead as far as disk space memory goes. I would imagine that 99%+ : of embedded systems do not use C++ code except perhaps for a very small : amount of the code. Yes, they do use C++. It doesn't matter what you imagine, c++ can and is used. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
Will Andrews [EMAIL PROTECTED] writes: Well, Warner, I've never done embedded systems. So, tell me, do they actually use any C++ code in embedded systems? C++ has a rather high overhead as far as disk space memory goes. That's a myth. I would imagine that 99%+ of embedded systems do not use C++ code except perhaps for a very small amount of the code. From experience, I would imagine the reverse. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic w/crash dump (looks like atomic.h problem)
Got a nice crash while running XMMS under X11 and running a 'make world -j
128 -DNOCLEAN' on ttyv0
Current was cvsupped on the 17th in the morning (Central European Time) IIRC.
Attached: script(1) output of gdb kernel trace
Kernel config file
dmesg(8) output
I'm not an expert on tracing panics, I just followed the instructions in
the FAQ, so feel free to ask me to look at stuff.
DocWilco
Script started on Thu Jan 18 16:09:58 2001
[ root@:/usr/src/sys/compile/VENUS ] # exitgdb -k[1Pls -lgdb -k
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".
(kgdb) symol bol0- -file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 5267456
initial pcb at 315ce0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x6c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01c057f
stack pointer = 0x10:0xc7ff1d54
frame pointer = 0x10:0xc7ff1d5c
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 = 427 (xmms)
panic: from debugger
panic: from debugger
Uptime: 5m51s
dumping to dev ad0s2b, offset 262144
dump ata0: 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 ../../kern/kern_shutdown.c:477
477 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:477
#1 0xc0186c2a in boot (howto=260) at ../../kern/kern_shutdown.c:320
#2 0xc0186ff9 in panic (fmt=0xc029c374 "from debugger")
at ../../kern/kern_shutdown.c:570
#3 0xc0142451 in db_panic (addr=-1071905409, have_addr=0, count=-1,
modif=0xc7ff1bc4 "") at ../../ddb/db_command.c:433
#4 0xc01423f1 in db_command (last_cmdp=0xc02dbe34, cmd_table=0xc02dbc94,
aux_cmd_tablep=0xc02ff6dc) at ../../ddb/db_command.c:333
#5 0xc01424b6 in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc0144683 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#7 0xc0272f72 in kdb_trap (type=12, code=0, regs=0xc7ff1d14)
at ../../i386/i386/db_interface.c:164
#8 0xc027ec0c in trap_fatal (frame=0xc7ff1d14, eva=108)
at ../../i386/i386/trap.c:948
#9 0xc027e975 in trap_pfault (frame=0xc7ff1d14, usermode=0, eva=108)
at ../../i386/i386/trap.c:867
#10 0xc027e12c in trap (frame={tf_fs = -939589608, tf_es = -1071972336,
tf_ds = -939786224, tf_edi = 0, tf_esi = 0, tf_ebp = -939582116,
tf_isp = -939582144, tf_ebx = 108, tf_edx = 8, tf_ecx = -940174016,
tf_eax = 8, tf_trapno = 12, tf_err = 2, tf_eip = -1071905409, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = -1057531392})
at ../../i386/i386/trap.c:442
#11 0xc01c057f in vref (vp=0x0) at machine/atomic.h:332
#12 0xc0f7aa82 in ?? ()
---Type return to continue, or q return to quit---
#13 0xc0f7b933 in ?? ()
#14 0xc0f7de1c in ?? ()
#15 0xc0f7abb5 in ?? ()
#16 0xc01c8acc in vn_read (fp=0xc105e9c0, uio=0xc7ff1ee4, cred=0xc1047600,
flags=0, p=0xc7f61540) at vnode_if.h:279
#17 0xc019b9ba in dofileread (p=0xc7f61540, fp=0xc105e9c0, fd=9,
buf=0x8223c00, nbyte=512, offset=-1, flags=0) at ../../sys/file.h:141
#18 0xc019b8c2 in read (p=0xc7f61540, uap=0xc7ff1f80)
at ../../kern/sys_generic.c:118
#19 0xc027f131 in syscall2 (frame={tf_fs = -1078001617, tf_es = -1078001617,
tf_ds = -1078001617, tf_edi = 9, tf_esi = 0, tf_ebp = -1079198116,
tf_isp = -939581484, tf_ebx = 674684816, tf_edx = 136476160,
tf_ecx = 674676832, tf_eax = 3, tf_trapno = 22, tf_err = 2,
tf_eip = 674396448, tf_cs = 31, tf_eflags = 659, tf_esp = -1079198160,
tf_ss = 47}) at ../../i386/i386/trap.c:1153
#20 0xc02738e3 in Xint0x80_syscall ()
#21 0x2835ddfe in ?? ()
#22 0x2834d66e in ?? ()
#23 0x28348bf9 in ?? ()
#24 0x285b08d6 in ?? ()
#25 0x0 in ?? ()
(kgdb) up 10
#10 0xc027e12c in trap (frame={tf_fs = -939589608, tf_es = -1071972336,
tf_ds = -939786224, tf_edi = 0, tf_esi = 0, tf_ebp = -939582116,
ACPI problem?
After enabling ACPI in my kernel I get these messages in dmesg: ---snip--- VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc03b82e2 (122) VESA: MagicGraph 256 AV 44K PRELIMINARY ACPI-0299: *** Warning: Invalid table signature found ACPI-0170: *** Error: AcpiLoadTables: Could not load RSDT: AE_BAD_SIGNATURE ACPI-0202: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE ACPI: table load failed: AE_BAD_SIGNATURE Using $PIR table, 6 entries at 0xc00f0f80 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 ---snip--- (Of course the VESA and apm messages were there before...) I have a Toshiba Tecra8000 as hardware and acpidump gives me: ---snip--- RSD PTR: Checksum=18, OEMID=TOSHIB, RsdtAddress=0x07ff acpidump: RSDT is corrupted ---snip--- Drop me a line if you want me to dig deeper at stuff. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
Will Andrews [EMAIL PROTECTED] writes: Well, Warner, I've never done embedded systems. So, tell me, do they actually use any C++ code in embedded systems? C++ has a rather high overhead as far as disk space memory goes. That's a myth. I would imagine that 99%+ of embedded systems do not use C++ code except perhaps for a very small amount of the code. From experience, I would imagine the reverse. OK, I'll pipe up. 1. I can't agree with you about the reverse, that 99% is C++ and 1% C, much more can and should be done in C++, and 2. When you know what you're doing there is no additional overhead in time and space using C++ versus C. Also, you won't be screwing around creating large amounts of messy "class code" housekeeping in C. I think the kernel could benefit from restricted C++ support. However, 3. Far too many people don't know at all what they're doing. One of the first things I noticed on a recent project was I couldn't compile and run it in simulation without running out of swap because objects representing the system memory map were being accidentally created but not referenced. C is much more forgiving of ignorance. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Peter Wemm wrote: Soren, can you retest a buildworld with the currently committed kernel with no other changes? Let us see if the forward_signal() stuff is the culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT the idle CPU. (if *that* makes a difference then we have got trouble!) It seems that the HLT thing is exactly the patch that makes it work! So we have trouble, I said that all along .5 :) -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
[EMAIL PROTECTED] wrote: Again I'll offer to run any and all code or patches to -current you guys can come up with, but I simply dont have the time to sit down and analyze into details what you have been doing... The enclosed patch implements a virtual NMI pushbutton by programming the IOAPIC to deliver an NMI when sio1 generates an interrupt. DDB should be defined in the kernel config file. getty should not run on ttyd1 when this patch is applied. A serial console on sio0 is recommended. If you still cannot break into the kernel debugger when the machine locks up then a rogue device is probably blocking the system (or the debugger is trying to obtain a mutex held by somebody else) - Tor Egge cool. What are the instructions for using this? should something have sio1 open? can a paperclip be used to generat the interupt by connecting pins 2 and 3? etc. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)
cool. What are the instructions for using this? should something have sio1 open? I use conserver conserver conserver hostnull-modem serial cables test machine label testport AA - sio0 serial console testnmi port BB - sio1 NMI I start two conserver sessions, one using test (for the console access) and one using port testnmi (for NMI). When I need an NMI, I just press return or space in the session using port BB. This only works when the test machine runs an SMP kernel with DDB and the virtual NMI pushbutton patch. No programs on the test machine should open sio1, since that could cause interrupts (which are now NMIs). can a paperclip be used to generat the interupt by connecting pins 2 and 3? I haven't tried that. - Tor Egge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
On 18-Jan-01 Soren Schmidt wrote: It seems Soren Schmidt wrote: I actually used this: CFLAGS ?= -O -pipe -mcpu=i686 -march=i686 COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686 All the diffs in sys/ on the box I built this kernel on are at http://www.FreeBSD.org/~jhb/patches/sys-mutex.patch. One possibly notable patch I had forgotten about is the fix to forward_signal() to lock with sched_lock. I've just committed that though. OK, I have installed those patches and will try out a kernel build on that asap Hmm, now we are getting somewhere, it ran through a make world with that patch installed! I'll test some more, maybe you should get it all committed it seems to make a hell of a difference The refcount.h stuff isn't used anywhere, and is still in a bikeshed mode. The rest of the patches are a bogus SMP HLT implementation that isnt' done yet, some proc lock fixes in svr4, some weird kernel printf patch I got from someone else at some point in time, and the forward_signal() patch I committed. -Søren -- 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: HEADS-UP: await/asleep removal imminent
On 18-Jan-01 Soren Schmidt wrote:
It seems Peter Wemm wrote:
I'll try adding the forward_signal stuff see if that helps...
But John committed that! it should be in the fresh checkout you tried
above Of course, that is assuming you cvsup'ed very recently..
Sorry that was not what I meant, I meant this patch to machdep.c
and so far it looks as thats the culprit it hasn't locked up yet
at least, but its not finished a world yet
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.429
diff -u -r1.429 machdep.c
--- machdep.c 2001/01/16 09:10:33 1.429
+++ machdep.c 2001/01/18 13:44:48
@@ -1005,6 +1005,10 @@
void
cpu_idle(void)
{
+#ifdef SMP
+ /* first candidate for an interrupt */
+ lapic.tpr = 0;
+#endif
#ifndef SMP
if (cpu_idle_hlt) {
disable_intr();
Hmm. Since cpl is dead, this is supposed to be a nop, since
the tpr is always at 0 now (AFAIK). I'll look at this today. Weird. Peter?
-Søren
--
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: HEADS-UP: await/asleep removal imminent
Soren Schmidt wrote: It seems Peter Wemm wrote: Soren, can you retest a buildworld with the currently committed kernel with no other changes? Let us see if the forward_signal() stuff is the culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT the idle CPU. (if *that* makes a difference then we have got trouble!) It seems that the HLT thing is exactly the patch that makes it work! So we have trouble, I said that all along .5 :) I don't know about your system but mine gets a LOT warmer when HALT is disabled. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Panic w/crash dump (looks like atomic.h problem)
On 18-Jan-01 Rogier Mulhuijzen wrote: Got a nice crash while running XMMS under X11 and running a 'make world -j 128 -DNOCLEAN' on ttyv0 Current was cvsupped on the 17th in the morning (Central European Time) IIRC. Attached: script(1) output of gdb kernel trace Kernel config file dmesg(8) output I'm not an expert on tracing panics, I just followed the instructions in the FAQ, so feel free to ask me to look at stuff. DocWilco If you look at the traceback, vref() was called with a NULL vnode as its parameter, so the panic is due to dereferencing a NULL pointer, not a bug in the atomic ops. :) As to why the kernel was vref()'ing a NULL pointer, I have no idea. -- 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: HEADS-UP: await/asleep removal imminent
On 18-Jan-01 Julian Elischer wrote: Soren Schmidt wrote: It seems Peter Wemm wrote: Soren, can you retest a buildworld with the currently committed kernel with no other changes? Let us see if the forward_signal() stuff is the culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT the idle CPU. (if *that* makes a difference then we have got trouble!) It seems that the HLT thing is exactly the patch that makes it work! So we have trouble, I said that all along .5 :) I don't know about your system but mine gets a LOT warmer when HALT is disabled. We don't IPI a hlt'd CPU in setrunqueue() right now, so once a CPU is HLT'd it stays idle until the I/O APIC sends it an interrupt to handle. I've watched top(1) during a buildworld with this enabled and have seen it with 8 processes in SRUN, but one CPU idle. :( Also, FWIW, the quad xeon doesn't use this patch and has run fine for several days now. -- 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 w/crash dump (looks like atomic.h problem)
If you look at the traceback, vref() was called with a NULL vnode as its parameter, so the panic is due to dereferencing a NULL pointer, not a bug in the atomic ops. :) As to why the kernel was vref()'ing a NULL pointer, I have no idea. #11 0xc01c057f in vref (vp=0x0) at machine/atomic.h:332 #12 0xc0f7aa82 in ?? () #13 0xc0f7b933 in ?? () #14 0xc0f7de1c in ?? () #15 0xc0f7abb5 in ?? () #16 0xc01c8acc in vn_read (fp=0xc105e9c0, uio=0xc7ff1ee4, cred=0xc1047600, flags=0, p=0xc7f61540) at vnode_if.h:279 #17 0xc019b9ba in dofileread (p=0xc7f61540, fp=0xc105e9c0, fd=9, buf=0x8223c00, nbyte=512, offset=-1, flags=0) at ../../sys/file.h:141 Yup, looks like you're right. Totally overlooked that. (Can you tell reading this is new to me? =) ) My next question is, where are those ??'s from in #12 - #15? Could they be addresses in kernel modules? If so, how do I readable output from that, save compiling everything into the kernel statically? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
That's one of the big reasons that we're 4.x based right now rather than 3.x based, despite 4.x's slightly larger memory footprint. That and 4.x's much better c++ compiler. Well, Warner, I've never done embedded systems. So, tell me, do they actually use any C++ code in embedded systems? C++ has a rather high overhead as far as disk space memory goes. I would imagine that 99%+ of embedded systems do not use C++ code except perhaps for a very small amount of the code. You have a very vivid imagination. Unfortunately, imagination isn't very helpful here; the whole idea is to do stuff that's actually useful, not just what we'd imagine might be useful. And in that regard, a *lot* of application programming (which includes programming for embedded systems) is done using c++ compilers. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On 18-Jan-01 Will Andrews wrote: Well, Warner, I've never done embedded systems. So, tell me, do they actually use any C++ code in embedded systems? C++ has a rather high overhead as far as disk space memory goes. I would imagine that 99%+ of embedded systems do not use C++ code except perhaps for a very small amount of the code. FYI, one of the first C++ applications to see the light of day outside of Bell Labs was DMDPI, a debugger for an intelligent graphic terminal ( DMD5620 ). I think that comes close to qualifying as an embedded application. When it is the right tool for the right job, C++ can be the most efficient tool around. When used incorrectly, it can be a nightmare, but then again, so can any language. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic w/crash dump (looks like atomic.h problem)
Rogier Mulhuijzen [EMAIL PROTECTED] writes: My next question is, where are those ??'s from in #12 - #15? Could they be addresses in kernel modules? Quite possibly. If so, how do I readable output from that, save compiling everything into the kernel statically? Read the handbook section on debugging kernel modules. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Thu, Jan 18, 2001 at 11:44:18AM -0800, Mike Smith wrote: You have a very vivid imagination. It's not easy to replace imagination with experience. This takes years, which I have yet to come upon. :-) Unfortunately, imagination isn't very helpful here; the whole idea is to do stuff that's actually useful, not just what we'd imagine might be useful. And in that regard, a *lot* of application programming (which includes programming for embedded systems) is done using c++ compilers. As Warner and Wes pointed out, this is certainly true. I guess I need a reality check on this. ; -- wca PGP signature
Internet Entertainment Solution
ccccccccccccccccccccccccc
@@@Cu`bgVXeĮ̀mç¹
ccccccccccccccccccccccccc
zÌïpª©©ÁÄ¢½®æÌVXeðA±Ìx
á¿iÅÌ·éÉÈèܵ½B
Cu`bgVXeÆÍEEE
PDX^WIðpÓµA»±ÉrfIJðÝuB
@@«ªX^oCµÜ·B
QDïõÌj«ÍAo[o^ð·Ü¹AIDÆPWð
@@ü͵A»Ì®æð{µÜ·B
RDj«ÍAu`bgvÆ¢¤VXeðg¢A
@@¶¾¯Å«ÆR~
jP[VðÆèÜ·B
SD»Ì¶ðX^WIÌÌqÍfBXv[Å
@@©ÈªçïbµÜ·BÌqÍrfIJÉ
@@ü©ÁÄbðµ½èAlXÈ®ìðµ½è·êÎ
@@¢¢¾¯Å·B»êªïõj«ÉC^[lbg
@@ðpµÄzM³êÜ·B
TDpµ½ÔªÌÛàªL^³êAêèÌÔÅ
@@¿[ðMµÜ·B
±ÌSÄÌVXeðpÓ·éÌÉlXÈCZX
â@ÞÈÇÝÅA1çãÌïpª©©èÜ·B
¡ñÍA±ÌêAÌVXeECZXE@ÞðA
ÜÆßÄá¿iÅÌvµÜ·BãÍAADSLÈÇÌ
o龯¬¢ñüÆXÌ@Þðpӷ龯ÅA
·®É±ÌuCu`bgVXevðp·é
ªoÜ·Boï¢TCgÅÚÊÌR~
jP[V
Ép·éÌàæµAA_gÖAÅp·éàæµA
±Ìá¿iÅpÓÅ«élÈVXeÅÍ èܹñB
¥ñ±Ì@ï𩦳¸AVrWlXÅׯĺ³¢B
ÁÉÇñÈWÅàu«Ì²BÉ¢çÈ¢vl
ÈÆÉÅà}b`µÄ¢Ü·B
VXe@ Windows NT
EReal Server
EDataBase(MSSQL)
EjvO¿vOiè®j
Eo[o^vO
E`bgvO
EDual CPU(PU400x2jNTT[o[
ErfIJ
EPCiNECj
z1çãÅ\\zµ½VXe@ð300~Å
̵ܷB
VXeA Redhat Linux 6.2
EReal Server
EDataBase(MYSQLAMSQL)
EjvO¿vOi©®j
Eo[o^vO
E`bgvO
Jïp500ãÅ\\zoéVXeAð300~Å
̵ܷB
A_gTCgÅuCu`bgvðs¤êA
ùÉÀÑÌ éRec¨÷è·éàoÜ·B
±ÌêAùÉ1löxÌÚqf[^à¨÷è·é
ªoÜ·Bweby[WàùÉm¼xÌàÌð»ÌÜ
ÜApÅ«Ü·µAeíT[`GWÈÇÉà
o^ÏÝÌhCª»ÌÜÜpÅ«Ü·Bv·éÉ
ÀÑÌ éTCgð»ÌÜÜVXeE@ÞA¨÷è
oéƾ¤±ÆÅ·BVKÌv[VÈÇÌ
KvàÈA éöxÌׯàñ©³êÄ¢éí¯Å·B
±¿çð²ó]ÌêÍA²kº³¢B
ܽAvOâT[o[ÈÇAPÌÅÌÌà
l¦Ä¨èÜ·BReal ServerÈÇÌCZXÍA
300öµÜ·ªAÐÅÍACZXAá¿iÅ
¨÷è·é±ÆªoÜ·ÌÅA²kº³¢B
ïÌIÉǤ¢Á½VXeÈ̩̱µ½¢ûÍA
A_gTCgÅ·ªAÀÛɲÉÈêÜ·ÌÅA
ºLURLðKâµÄÝľ³¢B
http://www.dreamroom.ws/
±Ì@ïð¦·èÍ èܹñBVKÆð¢ÌûA
¡·®A²Aº³¢B çäéÅAk³¹Ä
¸«Ü·B
ccccccccccccccccccccccccc
¨â¢¹Í±¿çÜÅ@¨@[EMAIL PROTECTED]
ccccccccccccccccccccccccc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Internet Entertainment Solution
ccccccccccccccccccccccccc
@@@Cu`bgVXeĮ̀mç¹
ccccccccccccccccccccccccc
zÌïpª©©ÁÄ¢½®æÌVXeðA±Ìx
á¿iÅÌ·éÉÈèܵ½B
Cu`bgVXeÆÍEEE
PDX^WIðpÓµA»±ÉrfIJðÝuB
@@«ªX^oCµÜ·B
QDïõÌj«ÍAo[o^ð·Ü¹AIDÆPWð
@@ü͵A»Ì®æð{µÜ·B
RDj«ÍAu`bgvÆ¢¤VXeðg¢A
@@¶¾¯Å«ÆR~
jP[VðÆèÜ·B
SD»Ì¶ðX^WIÌÌqÍfBXv[Å
@@©ÈªçïbµÜ·BÌqÍrfIJÉ
@@ü©ÁÄbðµ½èAlXÈ®ìðµ½è·êÎ
@@¢¢¾¯Å·B»êªïõj«ÉC^[lbg
@@ðpµÄzM³êÜ·B
TDpµ½ÔªÌÛàªL^³êAêèÌÔÅ
@@¿[ðMµÜ·B
±ÌSÄÌVXeðpÓ·éÌÉlXÈCZX
â@ÞÈÇÝÅA1çãÌïpª©©èÜ·B
¡ñÍA±ÌêAÌVXeECZXE@ÞðA
ÜÆßÄá¿iÅÌvµÜ·BãÍAADSLÈÇÌ
o龯¬¢ñüÆXÌ@Þðpӷ龯ÅA
·®É±ÌuCu`bgVXevðp·é
ªoÜ·Boï¢TCgÅÚÊÌR~
jP[V
Ép·éÌàæµAA_gÖAÅp·éàæµA
±Ìá¿iÅpÓÅ«élÈVXeÅÍ èܹñB
¥ñ±Ì@ï𩦳¸AVrWlXÅׯĺ³¢B
ÁÉÇñÈWÅàu«Ì²BÉ¢çÈ¢vl
ÈÆÉÅà}b`µÄ¢Ü·B
VXe@ Windows NT
EReal Server
EDataBase(MSSQL)
EjvO¿vOiè®j
Eo[o^vO
E`bgvO
EDual CPU(PU400x2jNTT[o[
ErfIJ
EPCiNECj
z1çãÅ\\zµ½VXe@ð300~Å
̵ܷB
VXeA Redhat Linux 6.2
EReal Server
EDataBase(MYSQLAMSQL)
EjvO¿vOi©®j
Eo[o^vO
? `bgvO
Jïp500ãÅ\\zoéVXeAð300~Å
̵ܷB
A_gTCgÅuCu`bgvðs¤êA
ùÉÀÑÌ éRec¨÷è·éàoÜ·B
±ÌêAùÉ1löxÌÚqf[^à¨÷è·é
ªoÜ·Bweby[WàùÉm¼xÌàÌð»ÌÜ
ÜApÅ«Ü·µAeíT[`GWÈÇÉà
o^ÏÝÌhCª»ÌÜÜpÅ«Ü·Bv·éÉ
ÀÑÌ éTCgð»ÌÜÜVXeE@ÞA¨÷è
oéƾ¤±ÆÅ·BVKÌv[VÈÇÌ
KvàÈA éöxÌׯàñ©³êÄ¢éí¯Å·B
±¿çð²ó]ÌêÍA²kº³¢B
ܽAvOâT[o[ÈÇAPÌÅÌÌà
l¦Ä¨èÜ·BReal ServerÈÇÌCZXÍA
300öµÜ·ªAÐÅÍACZXAá¿iÅ
¨÷è·é±ÆªoÜ·ÌÅA²kº³¢B
ïÌIÉǤ¢Á½VXeÈ̩̱µ½¢ûÍA
A_gTCgÅ·ªAÀÛɲÉÈêÜ·ÌÅA
ºLURLðKâµÄÝľ³¢B
http://www.dreamroom.ws/
±Ì@ïð¦·èÍ èܹñBVKÆð¢ÌûA
¡·®A²Aº³¢B çäéÅAk³¹Ä
¸«Ü·B
ccccccccccccccccccccccccc
¨â¢¹Í±¿çÜÅ@¨@[EMAIL PROTECTED]
ccccccccccccccccccccccccc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Panic w/crash dump (looks like atomic.h problem)
On 18-Jan-01 Rogier Mulhuijzen wrote: If you look at the traceback, vref() was called with a NULL vnode as its parameter, so the panic is due to dereferencing a NULL pointer, not a bug in the atomic ops. :) As to why the kernel was vref()'ing a NULL pointer, I have no idea. #11 0xc01c057f in vref (vp=0x0) at machine/atomic.h:332 #12 0xc0f7aa82 in ?? () #13 0xc0f7b933 in ?? () #14 0xc0f7de1c in ?? () #15 0xc0f7abb5 in ?? () #16 0xc01c8acc in vn_read (fp=0xc105e9c0, uio=0xc7ff1ee4, cred=0xc1047600, flags=0, p=0xc7f61540) at vnode_if.h:279 #17 0xc019b9ba in dofileread (p=0xc7f61540, fp=0xc105e9c0, fd=9, buf=0x8223c00, nbyte=512, offset=-1, flags=0) at ../../sys/file.h:141 Yup, looks like you're right. Totally overlooked that. (Can you tell reading this is new to me? =) ) My next question is, where are those ??'s from in #12 - #15? Could they be addresses in kernel modules? Yes. If so, how do I readable output from that, save compiling everything into the kernel statically? Static kernel is easiest, esp. if you can reproduce this. Otherwise you have to do other fun stuff to read in the symbols from the module. FWIW, if you are doing development or running -current, use a static kernel. If you are writing a specific device driver, then use a module for that, but make the rest of your kernel static. It's just easier that way. Also, for reading module symbols in, I think there is a relatiely easy way to do this now in gdb, but I don't know what it is. Of course, gdb -k is kind of broken right now because it hasn't caught up to the latest round of per-cpu changes.. DocWilco -- 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
syslogd(8) does not update hostname
Submitter-Id: current-users
Originator: Crist J. Clark
Organization:
Confidential: no
Synopsis: syslogd(8) does not update hostname
Severity: non-critical
Priority: medium
Category: bin
Release:FreeBSD 5.0-CURRENT i386
Class: sw-bug
Environment:
All standard FreeBSD distributions. The code discussed is from
5.0-CURRENT, but should trivially merge back to -STABLE.
Description:
Many tools and progams within FreeBSD date back to a time when
it was expected that a machines IP and hostname seldom, if ever,
changed. Even when a IP and hostname were received at boot, it rarely
changed until shutdown. With many users using protocols like DHCP
where IP and hostname change with time, many tools do not deal well
with this behavior.
One of these tools is syslogd(8). syslogd(8) is typically
started at boot time and runs until shutdown. However, syslogd(8)
loads the hostname at startup and syslogd(8)'s idea of the hostname
can never change while it is running.
One might expect that a SIGHUP would cause syslogd(8) to load
the new hostname since a SIGHUP can cause syslogd(8) to re-read its
configuration file and re-open the log files, but it does not.
The fact that the hostname does not change can cause confusion
in the log files. It could be especially troublesome when a machine is
logging to a central loghost. At any given time, the names in the log
files may not have any correspondence to the names the hosts currently
have. There are even issues on a host that gets its IP and hostname
via DHCP at boot and the name never changes. syslogd(8) is started
before any network services are initialized in /etc/rc.
I propose that syslogd(8) should reload the hostname with a
SIGHUP. I cannot think of any reason that one should not update the
hostname, but as I pointed out, there are reasons why one would want
that behavior.
How-To-Repeat:
# hostname -s
bubbles
# hostname bubbles-test.domain.org
# kill -HUP `cat /var/run/syslog.pid`
# logger -p user.notice "hostname test"
# tail -4 /var/log/messages
Jan 17 21:45:00 bubbles /boot/kernel/kernel: acd0: CDROM CD-532E-A at
ata0-slave using BIOSPIO
Jan 17 21:45:00 bubbles /boot/kernel/kernel: Mounting root from ufs:/dev/ad0s1a
Jan 18 00:41:14 bubbles su: cjc to root on /dev/ttyp0
Jan 18 00:58:34 bubbles cjc: hostname test
Fix:
I do not see any reason we cannot move the code that gets the
hostname from the main() function into init(). init() is called when
to "reload" settings. The hostname is never used in main() before
init() is called. The patch is against -CURRENT and my box has not
exploded yet.
Here is what the above test looks like with the change in
place.
# hostname -s
bubbles
# hostname bubbles-test.cjclark.org
# kill -HUP `cat /var/run/syslog.pid `
# logger -p user.notice "syslogd hostname test"
# hostname bubbles.cjclark.org
# kill -HUP `cat /var/run/syslog.pid `
# logger -p user.notice "syslogd hostname test"
# tail -4 /var/log/messages
Jan 18 13:36:58 bubbles su: BAD SU cjc to root on /dev/ttyp0
Jan 18 13:37:03 bubbles su: cjc to root on /dev/ttyp0
Jan 18 13:38:40 bubbles-test cjc: syslogd hostname test
Jan 18 13:39:11 bubbles cjc: syslogd hostname test
--- syslogd.c 2001/01/18 08:06:34
+++ syslogd.c 2001/01/18 08:09:23
@@ -395,12 +395,6 @@
consfile.f_type = F_CONSOLE;
(void)strcpy(consfile.f_un.f_fname, ctty + sizeof _PATH_DEV - 1);
- (void)gethostname(LocalHostName, sizeof(LocalHostName));
- if ((p = strchr(LocalHostName, '.')) != NULL) {
- *p++ = '\0';
- LocalDomain = p;
- } else
- LocalDomain = "";
(void)strcpy(bootfile, getbootfile());
(void)signal(SIGTERM, die);
(void)signal(SIGINT, Debug ? die : SIG_IGN);
@@ -1342,6 +1336,16 @@
char host[MAXHOSTNAMELEN+1];
dprintf("init\n");
+
+ /*
+* Load hostname (may have changed)
+*/
+ (void)gethostname(LocalHostName, sizeof(LocalHostName));
+ if ((p = strchr(LocalHostName, '.')) != NULL) {
+ *p++ = '\0';
+ LocalDomain = p;
+ } else
+ LocalDomain = "";
/*
* Close all open log files.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Small HEADS-UP
Hello, A few hours ago, this has been committed to -CURRENT: Commit log: [...] Log: Implement MTX_RECURSE flag for mtx_init(). All calls to mtx_init() for mutexes that recurse must now include the MTX_RECURSE bit in the flag argument variable. This change is in preparation for an upcoming (further) mutex API cleanup. The witness code will call panic() if a lock is found to recurse but the MTX_RECURSE bit was not set during the lock's initialization. The old MTX_RECURSE "state" bit (in mtx_lock) has been renamed to MTX_RECURSED, which is more appropriate given its meaning. The following locks have been made "recursive," thus far: eventhandler, Giant, callout, sched_lock, possibly some others declared in the architecture-specific code, all of the network card driver locks in pci/, as well as some other locks in dev/ stuff that I've found to be recursive. [...] This is a small HEADS-UP to let people who have WITNESS turned on that if they stumble into a panic() with a message such as: "[...] recursed on non-recursive mutex foo [...]" to take note of it and report it as soon as possible to the lists (feel free to CC me). I believe that I have covered the large majority of recursive mutexes in the patch, but it's difficult to go through all the surrounding code. So, if I happened to have missed some, it would be good to modify the required mtx_init()s immediately, before further cleanups are done. Thanks, Bosko. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall move and make release on FreeBSD-stable
Howdy,
Since the sysinstall move, make release on FreeBSD-stable (as of 3 hrs ago)
breaks when building sysinstall. The output is:
=== usr.sbin/sysinstall
cc -o rtermcap /usr/src/usr.sbin/sysinstall/rtermcap.c -ltermcap
rm -f makedevs.tmp
echo '#include sys/types.h' makedevs.tmp
./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25w | file2c 'const char termcap_cons25w[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25 | file2c 'const char termcap_cons25[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25-m | file2c 'const char termcap_cons25_m[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25r | file2c 'const char termcap_cons25r[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25r-m | file2c 'const char termcap_cons25r_m[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25l1 | file2c 'const char termcap_cons25l1[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap cons25l1-m | file2c 'const char termcap_cons25l1_m[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap vt100 | file2c 'const char termcap_vt100[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
./rtermcap xterm | file2c 'const char termcap_xterm[] = {' ',0};'
makedevs.tmp
/usr/libexec/ld-elf.so.1: Shared object "libc.so.5" not found
then:
cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I.
-I/usr/obj/usr/src/i386/usr/include -c makedevs.c
makedevs.c:4: syntax error before `,'
makedevs.c:7: syntax error before `,'
makedevs.c:10: syntax error before `,'
makedevs.c:13: syntax error before `,'
makedevs.c:16: syntax error before `,'
makedevs.c:19: syntax error before `,'
makedevs.c:22: syntax error before `,'
makedevs.c:25: syntax error before `,'
makedevs.c:28: syntax error before `,'
makedevs.c:31: syntax error before `,'
I did a local hack to copy libc.so.5 into ${CHROOTDIR}/usr/lib before the
chroot command, but this doesn't solve the problem properly. At the moment,
it seems that current snapshots can only be built with current, and I'm not
sure of the correct way to fix this for stable. I'm thinking the best way is
to change the linking command for rtermcap in
/usr/src/usr.sbin/sysinstall/Makefile relative to one of the environment
variables set for the make release process. Not foolproof, but better than
my hack :-)
Also, the following commands added to ${CHROOTDIR}/mk are now dependent on
where sysinstall in the release you're trying to build lives.
cd /usr/src/release/sysinstall
make obj
They've been removed from /usr/src/release/Makefile v1.589, but aren't they
still required if you're trying to build a 4.x release? Or am I missing the
point?
Regards,
Chris Knight
Systems Administrator
AIMS Independent Computer Professionals
Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795
Web: http://www.aims.com.au
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
Soren Schmidt wrote:
It seems Peter Wemm wrote:
Soren, can you retest a buildworld with the currently committed kernel
with no other changes? Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
the idle CPU. (if *that* makes a difference then we have got trouble!)
It seems that the HLT thing is exactly the patch that makes it work!
So we have trouble, I said that all along .5 :)
So, the difference between -current working for you or not is this:
+++ machdep.c 2001/01/18 13:44:48
@@ -1005,6 +1005,10 @@
void
cpu_idle(void)
{
+#ifdef SMP
+ /* first candidate for an interrupt */
+ lapic.tpr = 0;
+#endif
#ifndef SMP
if (cpu_idle_hlt) {
disable_intr();
?? No other changes?
This is bad news.. This means we have races somewhere, or some other badness.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: await/asleep removal imminent
It seems Peter Wemm wrote: Soren Schmidt wrote: It seems Peter Wemm wrote: Soren, can you retest a buildworld with the currently committed kernel with no other changes? Let us see if the forward_signal() stuff is the culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT the idle CPU. (if *that* makes a difference then we have got trouble!) It seems that the HLT thing is exactly the patch that makes it work! So we have trouble, I said that all along .5 :) So, the difference between -current working for you or not is this: [diff snipped] ?? No other changes? I need the FULL change to machdep.c and apparently the chagne to subr_prf.c is needed too, at least it hasnt broke yet with that in place too, not that I can see why it matters though. The new diff to machdep.c that jhb made yesterday also causes trouble. This is bad news.. This means we have races somewhere, or some other badness. That is what I've been harping about for months... What strikes me here as a very serious problem is that the SMPng developers has told me over and over that it works fine for them on -current, but when we get to the matter after months of frustration, it suddenly appears that they are not running the same -current as the rest of us. Now guys, excuse my language, but that *sucks* bigtime. However I'm still running tests here, and I'm offering to test every patch you can come up with to help locate the problem, just as always... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
