Re: kern_linker.c rev. 1.75 and newer cause loading problem
On Sat, Mar 09, 2002 at 10:13:25AM -0800, Steve Kargl wrote: Well, I finally have narrowed the problem down to Revision 1.75 Fri Feb 22 04:14:49 2002 UTC (2 weeks, 1 day ago) by arr Branch: MAIN Changes since 1.74: +1295 -1271 lines Diff to previous 1.74 (colored) - Massive style fixup. Reviewed by: mike Approved by: dfr To recap: root[202] cat /boot/loader.conf miibus_load=YES if_rl_load=YES snd_pcm_load=YES snd_maestro3_load=YES linux_load=YES agp_load=YES hint.acpi.0.disable=1 root[203] kldstat Id Refs AddressSize Name 1 12 0xc010 262e40 kernel 21 0xc0363000 18330linux.ko ^ 32 0xc037c000 15480miibus.ko 41 0xc0392000 7798 if_rl.ko 52 0xc039a000 1a14csnd_pcm.ko 61 0xc03b5000 9538 snd_maestro3.ko 71 0xc03bf000 c860 agp.ko 81 0xcb052000 2000 blank_saver.ko root[204] kldload linprocfs kldload: can't load linprocfs: Exec format error root[206] tail -1 /var/log/messages Mar 9 10:00:27 kernel: KLD linprocfs.ko: depends on \ linux - not available root[209] kldunload linux root[210] kldload linux root[211] kldload linprocfs root[213] kldstat Id Refs AddressSize Name 1 15 0xc010 262e40 kernel 32 0xc037c000 15480miibus.ko 41 0xc0392000 7798 if_rl.ko 52 0xc039a000 1a14csnd_pcm.ko 61 0xc03b5000 9538 snd_maestro3.ko 71 0xc03bf000 c860 agp.ko 81 0xcb052000 2000 blank_saver.ko 92 0xcb425000 14000linux.ko ^ 101 0xcab88000 5000 linprocfs.ko Are you sure the same module is being loaded? $ find -x / -name linux.ko -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Serial break into debugger broken from 'cu' on -CURRENT?
For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT (2) Is serial break currently broken in 'cu'? I have't had a chance to follow up on either, but was wondering if anyone else had experienced this? Essentially, hitting ~# in cu no longer results in boxes dropping to the debugger. Enabling the alternative break and using ~^B works fine, and Ctrl-Alt-Escape works fine on the real console. 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: Serial break into debugger broken from 'cu' on -CURRENT?
On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson wrote: For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT (2) Is serial break currently broken in 'cu'? I had similar experiences with tip trying to break into ddb on the AlphaStation DS10 with -current. I thought it was just me ;-) -- | / 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: Serial break into debugger broken from 'cu' on -CURRENT?
On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson [EMAIL PROTECTED] wrote: (1) Is serial break currently broken in -CURRENT (2) Is serial break currently broken in 'cu'? I have't had a chance to follow up on either, but was wondering if anyone else had experienced this? Essentially, hitting ~# in cu no longer results in boxes dropping to the debugger. Enabling the alternative break and using ~^B works fine, and Ctrl-Alt-Escape works fine on the real console. I've been unable to send break using -current cu to some Cisco's which I had to configure recently. Ecu from ports did work however. As I was -stable user some weeks ago I know that cu in -stable did work. The other thing I noticed was that -current cu handles speed switch differently, e.g.: stable: cu -l /dev/cuaa1 -9600 works well current: cu -l /dev/cuaa1 -9600 will connect to cuaa0 not cuaa1.. -s 9600 will work however. What I recall is that some time back uucp was shaken out of base system and cu also, cu's functionality was folded back to tip. Stable indeed has different tip and cu binaries, in -current there's hard link. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
At 4:11 PM +0100 3/10/02, Wilko Bulte wrote: On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson wrote: For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT (2) Is serial break currently broken in 'cu'? I had similar experiences with tip trying to break into ddb on the AlphaStation DS10 with -current. I thought it was just me ;-) Hitting ~# in tip worked fine for me with a -current CVSup'd from yesterday. However, it did stump me for a second until I realized I was initially escaping into SSH and not tip. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
FreeBSD stash.attlabs.att.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Fri Mar 8 18:16:53 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STASHNOV6 i386 responds to a break from a Cisco terminal server, invoked by /usr/ports/comms/conserver: FreeBSD/i386 (stash.attlabs.att.com) (ttyd0) login: Mar 9 21:35:57 stash savecore: reboot after panic: from debugger Mar 9 21:36:02 stash savecore: reboot after panic: from debugger lock order reversal 1st 0xc0468a40 allproc @ /usr/src/sys/kern/vfs_syscalls.c:452 2nd 0xc1423734 filedesc structure @ /usr/src/sys/kern/vfs_syscalls.c:457 [halt sent] Stopped at siointr1+0xb1: jmp siointr1+0x1b7 db I don't have any directly connected ports, so can't coment on cu. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
On Sun, Mar 10, 2002 at 08:49:16AM -0800, Mark Peek wrote: At 4:11 PM +0100 3/10/02, Wilko Bulte wrote: On Sun, Mar 10, 2002 at 10:07:07AM -0500, Robert Watson wrote: For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT (2) Is serial break currently broken in 'cu'? I had similar experiences with tip trying to break into ddb on the AlphaStation DS10 with -current. I thought it was just me ;-) Hitting ~# in tip worked fine for me with a -current CVSup'd from yesterday. However, it did stump me for a second until I realized I was initially escaping into SSH and not tip. Let me clarify: the DS10 is running -current, the x86 that has tip running is on -stable. It could be that the DS10 was sufficiently catatonic to not react to a break (how likely is that in the first place? I was looking at a hard lockup). Now that I followed Drew's suggestion to quote I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable interrupt thread preemption). I'm on the west coast right now, away from my alphas, but I had several buildworlds complete last week with ithread preemption disabled. Drew /quote I have not seen a lockup anymore. I also had to take out options SMP in order to get the kernel link. 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: kern_linker.c rev. 1.75 and newer cause loading problem
On Sun, Mar 10, 2002 at 12:35:28AM -0800, Crist J. Clark wrote: On Sat, Mar 09, 2002 at 10:13:25AM -0800, Steve Kargl wrote: [snip] root[203] kldstat Id Refs AddressSize Name 1 12 0xc010 262e40 kernel 21 0xc0363000 18330linux.ko ^ 92 0xcb425000 14000linux.ko ^ Are you sure the same module is being loaded? $ find -x / -name linux.ko Yes, I am sure. kargl[204] kldconfig -r /boot/kernel;/boot/kernel;/boot/modules;/modules kargl[205] ls /boot/modules/ kargl[206] ls /modules/ ls: /modules/: No such file or directory kargl[208] ls -l /boot/kernel/lin* -rw--- 1 root wheel 15432 Mar 9 09:50 /boot/kernel/linker.hints -r-xr-xr-x 1 root wheel 19581 Mar 9 09:50 /boot/kernel/linprocfs.ko* -r-xr-xr-x 1 root wheel 97319 Mar 9 09:50 /boot/kernel/linux.ko* kargl[213] find /boot -name linux\* /boot/kernel/linux.ko -- Built at same time as 1.75 /boot/kernel.old/linux.ko -- Built at same time as 1.74 /boot/sgk/linux.ko-- not relevant see search path /boot/kargl/linux.ko -- not relevant see search path kargl[214] cmp /boot/kernel/linux.ko /boot/kernel.old/linux.ko kargl[215] cmp /boot/kernel/linprocfs.ko /boot/kernel.old/linprocfs.ko As I said, if I backup to revision 1.74 of kern_linker.c, then everything works. If I use revision 1.75 or newer, then you see the above problem. I haven't found the actual problem in kern_linker.c because it is a huge diff. kargl[220] diff -u /root/kern_linker.c-1.74 /root/kern_linker.c-1.75 |wc 2956 12329 102757 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
Robert Watson [EMAIL PROTECTED] wrote: (1) Is serial break currently broken in -CURRENT I can drop just fine into ddb with a serial break on my -CURRENT AlphaPC164. My kernel configuration has option BREAK_TO_DEBUGGER. (2) Is serial break currently broken in 'cu'? Works just fine from abovementioned alpha to my sparc. I don't have a pair of FreeBSD boxes tied together like that. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
Wilko Bulte [EMAIL PROTECTED] wrote: It could be that the DS10 was sufficiently catatonic to not react to a break (how likely is that in the first place? I was looking at a hard lockup). If you experience one of the lockups that currently plague -CURRENT/alpha, the machine won't react to break, ctrl-alt-esc, or anything else except HALT and RESET. Now that I followed Drew's suggestion to quote I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable interrupt thread preemption). /quote I have not seen a lockup anymore. Neither have I, but I have only been running with it for a day, and it has previously managed to survive for up to two days without locking up. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
Robert Watson wrote: For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT (2) Is serial break currently broken in 'cu'? I have't had a chance to follow up on either, but was wondering if anyone else had experienced this? Essentially, hitting ~# in cu no longer results in boxes dropping to the debugger. Enabling the alternative break and using ~^B works fine, and Ctrl-Alt-Escape works fine on the real console. The break signal is At least 250ms of marking space (line silence), according to the Bell 103C and 212A and B standards. There are two ways that UNIX programs try to do this; the first is an ioctl() for send a break; the second is to set the baud rate to 0, and then set it back after a sufficient time. You should check to see if both approaches (the working one and the non-working one) are trying to use the same approach, or not. If they aren't, it could be something as simple as the number of loops before the baud rate is set back is wrong for your clock speed, and the loops should be replaced with a call to nanosleep. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
b_to_q to a clist with no reserved cblocks
Just noticed the following for the first time today? (a) b_to_q console message, and (b), the truncated 'Mar' which presumably has to do with syslogd getting killed, some buffer getting flushed, or the like. The b_to_q thing is what I'm wondering about. # reboot Mar 10 18:36:39 reboot: rebooted by root Mar 10 18:36:39 reboot: rebooted by root Mar 10 18:36:39 reboot: rebooted by root b_to_q to a clist with no reserved cblocks. MarWaiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Uptime: 16m12s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
On Sun, Mar 10, 2002 at 06:15:53PM +, Christian Weisgerber wrote: Wilko Bulte [EMAIL PROTECTED] wrote: It could be that the DS10 was sufficiently catatonic to not react to a break (how likely is that in the first place? I was looking at a hard lockup). If you experience one of the lockups that currently plague -CURRENT/alpha, the machine won't react to break, ctrl-alt-esc, or anything else except HALT and RESET. Now that I followed Drew's suggestion to quote I suggest reverting rev 1.61 of alpha/alpha/interrupt.c (eg, disable interrupt thread preemption). /quote I have not seen a lockup anymore. Neither have I, but I have only been running with it for a day, and it has previously managed to survive for up to two days without locking up. Well, I had a close to 100% lockup or panic chance when I ran a make release. I just completed a succesful buildworld, and will subsequently run a make release. W/ -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
I just rebuilt -current on two development machines I use here at home, the serial break contol-alt-escape appears to work fine on a stand-alone vox. (1) Is serial break currently broken in -CURRENT If I do a 'tip com1' from one box to the other and then do an 'control-alt-escape' it breaks into ddd just fine as well : (2) Is serial break currently broken in 'cu'? Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
slight patch to ata-all.c
Hello
[on a very recent -Current]
wtih the Werror compile flag, I can't compile src/sys/dev/ata/ata-all.c
on a PC with nothing more than a single IDE disk
TfH
patch enclosed
--- ata-all.c Sun Mar 10 21:32:21 2002
+++ ata-all.c.new Sun Mar 10 20:44:15 2002
-274,10 +274,12
ataioctl(dev_t dev, u_long cmd, caddr_t addr, int32_t flag, struct thread *td)
{
struct ata_cmd *iocmd = (struct ata_cmd *)addr;
+#if defined(DEV_ATAPICD) || defined(DEV_ATAPIFD) || defined(DEV_ATAPIST)
struct ata_device *atadev;
+caddr_t buf;
+#endif
struct ata_channel *ch;
device_t device = devclass_get_device(ata_devclass, iocmd-channel);
-caddr_t buf;
int error, s;
if (cmd != IOCATA)
Re: Call for UMA (allocator) testers.
I have the UMA patch installed on two systems here, a 500Mhz K7 system and dual PIII SMP box, both of which have WITNESS and INVARIANTS configured in the kernel. I will run them for the next few days, and report anything that looks unusual in operation :) GG. I'd like people to test with WITNESS and INVARIANTS, although with these options on it is somewhat slower than the original kernel. With these disabled it is on par. If you have a SMP machine you will get witness warnings if you run low on memory. There is no real problem except that witness doesn't understand that the condition is safe. If you do test this patch, please send me an email so I know how many people are using this. If you get a lock order violation other than acquring duplicate lock of same type please let me know. If you get a panic, please give me a stack trace (tr in ddb) and the output of call uma_print_stats in the debugger if that is possible. This has been debugged and tested over several months so it is quite stable for me. Hopefully it will be stable for you too. :-) The patch and new files are available at: http://www.chesapeake.net/~jroberson/uma.tar Untar into src/sys and apply the patch. After you rerun config you should be ready to compile. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
error message
is the following message serious ? Mar 10 21:49:17 multi kernel: witness_get: witness exhausted is there anything special to do ? this is on a newly cvsuped, very lightly loaded, -Current (4 minutes after booting the machine) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern_linker.c rev. 1.75 and newer cause loading problem
Should be fixed in rev.1.78. -Maxim On Sun, 2002-03-10 at 10:35, Crist J. Clark wrote: On Sat, Mar 09, 2002 at 10:13:25AM -0800, Steve Kargl wrote: Well, I finally have narrowed the problem down to Revision 1.75 Fri Feb 22 04:14:49 2002 UTC (2 weeks, 1 day ago) by arr Branch: MAIN Changes since 1.74: +1295 -1271 lines Diff to previous 1.74 (colored) - Massive style fixup. Reviewed by: mike Approved by: dfr To recap: root[202] cat /boot/loader.conf miibus_load=YES if_rl_load=YES snd_pcm_load=YES snd_maestro3_load=YES linux_load=YES agp_load=YES hint.acpi.0.disable=1 root[203] kldstat Id Refs AddressSize Name 1 12 0xc010 262e40 kernel 21 0xc0363000 18330linux.ko ^ 32 0xc037c000 15480miibus.ko 41 0xc0392000 7798 if_rl.ko 52 0xc039a000 1a14csnd_pcm.ko 61 0xc03b5000 9538 snd_maestro3.ko 71 0xc03bf000 c860 agp.ko 81 0xcb052000 2000 blank_saver.ko root[204] kldload linprocfs kldload: can't load linprocfs: Exec format error root[206] tail -1 /var/log/messages Mar 9 10:00:27 kernel: KLD linprocfs.ko: depends on \ linux - not available root[209] kldunload linux root[210] kldload linux root[211] kldload linprocfs root[213] kldstat Id Refs AddressSize Name 1 15 0xc010 262e40 kernel 32 0xc037c000 15480miibus.ko 41 0xc0392000 7798 if_rl.ko 52 0xc039a000 1a14csnd_pcm.ko 61 0xc03b5000 9538 snd_maestro3.ko 71 0xc03bf000 c860 agp.ko 81 0xcb052000 2000 blank_saver.ko 92 0xcb425000 14000linux.ko ^ 101 0xcab88000 5000 linprocfs.ko Are you sure the same module is being loaded? $ find -x / -name linux.ko -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message signature.asc Description: This is a digitally signed message part
[no subject]
Hi, my machine is FreeBSD-current. No, PAM is in /etc/pam.d for ftpd, telnetd ..etc. But why I can ftp to my machine on my own machine but it doesn't allow any other machine ftp to my machine( MS client)? Best Regard. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
I have installed mozilla 0.9.8 from port,(my system is current), and jdk1.3.1 and flash plugs-in for mozilla. I get the following Error message: Script started on Sun Mar 10 22:36:37 2002 mozilla LoadPlugin: failed to initialize shared library /usr/X11R6/lib/mozilla/plugins/npflash.so [/usr/X11R6/lib/mozilla/plugins/npflash.so: Undefined symbol XtRemoveTimeOut] LoadPlugin: failed to initialize shared library /usr/local/jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so [/usr/local/jdk1.3.1/jre/plugin/i386/ns600/libjavaplugin_oji.so: Undefined symbol XtShellStrings] exit exit Script done on Sun Mar 10 22:36:48 2002 why? _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
On Sunday, 10 March 2002 at 10:07:07 -0500, Robert Watson wrote: For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT Yes, I think so. (2) Is serial break currently broken in 'cu'? No opinion, since I haven't tried using it. What I have observed is: I use the same gdb for remote serial debugging both for FreeBSD and Linux (ia32). That's right, it's a FreeBSD box running FreeBSD gdb in both cases. I can break to the Linux kernel, but not to the FreeBSD kernel. From this, I conclude that it's a kernel issue, not a gdb issue. 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
Re: error message
Thierry Herbelot wrote: is the following message serious ? Mar 10 21:49:17 multi kernel: witness_get: witness exhausted is there anything special to do ? this is on a newly cvsuped, very lightly loaded, -Current (4 minutes after booting the machine) You need to let it rest... there are so many people testing it that it's getting tired! 8-). Actually, you need to look at where the error message is generated, which will tell you that it's running out of the things returned by witness_get. Then increase the compile time constant that controls them, and you won't run out any more. In theory, the only thing that will suffer from this is that some things will not be witnessed correctly, which means that you could have any of the problems witness ordinarily catches for you, but not know about them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
On Sun, Mar 10, 2002 at 06:15:53PM +, Christian Weisgerber wrote: Wilko Bulte [EMAIL PROTECTED] wrote: It could be that the DS10 was sufficiently catatonic to not react to a break (how likely is that in the first place? I was looking at a hard lockup). If you experience one of the lockups that currently plague -CURRENT/alpha, the machine won't react to break, ctrl-alt-esc, or anything else except HALT and RESET. My testbox (NoName) doesn't even react on halt. But in the normal case a serial break just does what it should do. Serial client is tip from 4.3-20010630-STABLE. My notebook is running -current from 15th feb and tip's break also worked always fine. Well sending the break sequence against an ssh or not after a linebreak are typical mistakes in usage. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
serial break is different.. it is suppoesed to break into the d debugger if it receives a BREAK (i.e framing error) in the serial port. cu ,tip and other such programs have an escape sequence to send a break julian On Sun, 10 Mar 2002, Glenn Gombert wrote: I just rebuilt -current on two development machines I use here at home, the serial break contol-alt-escape appears to work fine on a stand-alone vox. (1) Is serial break currently broken in -CURRENT If I do a 'tip com1' from one box to the other and then do an 'control-alt-escape' it breaks into ddd just fine as well : (2) Is serial break currently broken in 'cu'? Glenn Gombert [EMAIL PROTECTED] 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
== Feel Look 10 Years Younger in 10 Weeks With HGH == 30151076
One more bulk email --- aren't you the least bit curious to find out what it's about? Well, visit our site: 1) http://theclinicforhgh.yeah.net OR, read on ... HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? (This product works best for people over 35) Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us anytime (24hrs) TOLL FREE 1-888-248-4571 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-248-4571. If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging. Dr. Daniel Rudman, MD, New England Journal of Medicine. Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly. D.W., New Jersey We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying! C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Call us now 1-888-248-4571 Offer expires March 20, 2002 *** === End of message To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and enter remove in the email subject line then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA WA. Screening of addresses has been done to the best of our technical ability. *** http://TheClinic.netxun.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: linprocfs.ko and kld loader problem?
According to Steve Kargl: root[202] kldload linprocfs kldload: can't load linprocfs: Exec format error The following message is on the system console: KLD linprocfs.ko: depends on linux - not available I'm happy to see that I'm not the only one with that problem... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gtags? htags?
julian It might be an idea if the kernel were kept separate because I julian find that the cross-reference is good but having kernel and julian userspace mixed up is a bit confusing.. Ok, I've separated the tour into 'kernel' part and 'userland' part (5-current kernel is now processing). Tour entrance is the same URL: http://snapshots.jp.FreeBSD.org/tour/ -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Package set for release media
Does anyone have suggestions for additional packages that should be included on the upcoming Developer Preview snapshot that are not already listed in src/release/scripts/print-cdrom-packages.sh? The only changes since the release of 4.5 have been the inclusion of samba and the upgrade to emacs21. Please send suggested packages to portmgr and re; no need to flood the list. Thanks, - Murray msg35935/pgp0.pgp Description: PGP signature
Re: Serial break into debugger broken from 'cu' on -CURRENT?
On Sun, 10 Mar 2002, Vallo Kallaste wrote: work. The other thing I noticed was that -current cu handles speed switch differently, e.g.: stable: cu -l /dev/cuaa1 -9600 works well current: cu -l /dev/cuaa1 -9600 will connect to cuaa0 not cuaa1.. -s 9600 will work however. What I recall is that some time back uucp was shaken out of base system and cu also, cu's functionality was folded back to tip. Stable indeed has different tip and cu binaries, in -current there's hard link. The -current cu is a crock of tip. One of the bugs in it is that cu -l /dev/foo doesn't use the default line speed for /dev/foo; it enforces 9600. This is bug for bug compatible with the V7 cu except for the unusably slow speed of 9600. For perfect brokenness, the default speed should be 300. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: b_to_q to a clist with no reserved cblocks
On Sun, 10 Mar 2002, Robert Watson wrote: Just noticed the following for the first time today? (a) b_to_q console message, and (b), the truncated 'Mar' which presumably has to do with syslogd getting killed, some buffer getting flushed, or the like. The b_to_q thing is what I'm wondering about. # reboot Mar 10 18:36:39 reboot: rebooted by root Mar 10 18:36:39 reboot: rebooted by root Mar 10 18:36:39 reboot: rebooted by root b_to_q to a clist with no reserved cblocks. MarWaiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Uptime: 16m12s Truncation at Mar is caused by ttymsg() not caring that its messages actually get written. Many messages may be truncated. I normally saw several N's in a row when I debug this last November. That meant that several messages starting with November were truncated to N. ttymsg() checks the result of writev() and is more careful if writev() returns EWOULDBLOCK, but for non-synchronous ttys like serial ttys, writev() normally just buffers the data and it takes a tcdrain() to ensure that the data has at least been transmitted. Unfortunately, there is no way to determine if the data has been transmitted without blocking, and ttymsg() doesn't want to block. ttymsg() compounds the error by using non-blocking mode in most cases. When non-blocking mode is in effect at last-close time, it tells close() to discard the data instead of blocking. The last-close sometimes occurs in exit() when blocking in it is very inconvenient because it gives an unkillable (half dead already) process. When writev() returns EWOULDBLOCK, ttymsg() switches to blocking mode and can generate a horde of blocked or unkillable children. I don't know exactly what causes the b_to_q message. It is most likely a race in close. You can first-open tty's that are blocked in last-close, and having this open succeed is very important for unblocking the close usi9ng comcontrol /dev/foo drainwait small, but the tty system doesn't seem to do nearly enough to handle races here. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
