Re: can't connect to cvsup.freebsd.org
I dont have any problems here, get a maximum connections exceeded message though. Hope this helps! On Tue, Dec 05, 2006 at 05:34:32PM -0500, Steven Friedrich wrote: but I'm able to connect to cvsup5 and cvsup6. The main ftp site says: Cannot connect to data port: Connection refused This started around the time of the cut-overs. -- i386 FreeBSD 4.11-STABLE There are 10 types of people in this world. Ones that understand binary and then, the others. -- Kind regards, Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't connect to cvsup.freebsd.org
On Tuesday 05 December 2006 16:34, Steven Friedrich wrote: but I'm able to connect to cvsup5 and cvsup6. The main ftp site says: Cannot connect to data port: Connection refused This started around the time of the cut-overs. *default host=cvsup.FreeBSD.org gimpy# csup /usr/local/etc/ports-supfile Connected to 198.104.69.57 Updating collection ports-all/cvs Edit ports/LEGAL ... gimpy# dig a ftp.freebsd.org ... ftp.freebsd.org.180 IN A 62.243.72.50 ftp.freebsd.org.180 IN A 204.152.184.73 gimpy# dig a cvsup.freebsd.org . cvsup.freebsd.org. 3535IN CNAME n.cwu.edu. n.cwu.edu. 86335 IN A 198.104.69.57 My point, in case you don't understand the ouput of all these commands is that cvsup.freebsd.org and ftp.freebsd.org are presumably two different machines, and it's entirely possible that ftp.freebsd.org isn't a cvsup server. -- Thanks, Josh Paetzel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't connect to cvsup.freebsd.org
On 12/5/06, Steven Friedrich [EMAIL PROTECTED] wrote: but I'm able to connect to cvsup5 and cvsup6. The main ftp site says: Cannot connect to data port: Connection refused This started around the time of the cut-overs. -- i386 FreeBSD 4.11-STABLE There are 10 types of people in this world. Ones that understand binary and then, the others. Are you using cvsup or csup to connect to cvsup[5,6] or an ftp client? Just courius since you mention that the main ftp site says you can't connect. Regards! //Niclas -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Burning RW cdrom error message
On 12/3/06, ros [EMAIL PROTECTED] wrote: Trying to burn a RW CDROM, I notice the CD-ROM device was freeze and nothing happen. After a hard reboot (I turn off completly the computer), I find this message on the /var/log/message file Dec 3 19:04:40 bill kernel: acd0: req=0xc24e5258 SEND_OPC_INFO semaphore timeout !! DANGER Will Robinson !! Dec 3 19:04:42 bill kernel: acd0: req=0xc2063258 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! This is an old bug, I think. I've seen the message before. Which version of FreeBSD do you use? Try googling around for the error message and look through the list archives, you'll probably find something about the error there. Regards! //Niclas -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver not unset properly after kldunload
On Wednesday 29 November 2006 18:18, Iasen Kostoff wrote: Hi, It seems that after I load and then unload a driver its name stays linked to the device e.g: [EMAIL PROTECTED]:10:0: class=0x068000 card=0x81411043 chip=0x005710de rev=0xa3 hdr=0x00 but of course if_nfe is neither compiled in kernel nor is loaded as module anymore. I digged around in kernel and saw this in device_detach(): if (!(dev-flags DF_FIXEDCLASS)) devclass_delete_device(dev-devclass, dev); dev-state = DS_NOTPRESENT; device_set_driver(dev, NULL); device_set_desc(dev, NULL); device_sysctl_fini(dev); I've put some device_printf()s around and then looked at devclass_delete_device(). It destroys (frees) a lot of the info about the device and so the device_printf() prints device name as unknown (NULL). That seems to be a problem for at least device_set_driver(dev, NULL) - it doesn't unset the driver. I'm not so sure about the other 2 but I guess it's same there. So when I changed the order of this funcs everything worked fine (at least it looks like it worked fine :) I'm not absolutely sure that this won't broke something else). I've attached a patch for review. I don't see why this patch changes things. devclass_delete_device() only clears dev-unit, dev-devclass, and dev-nameunit. device_set_driver() doesn't check or clear any of those. In fact, your change does make device_set_driver() not work at all since the device state will still be DS_ATTACHED when you call device_set_driver() now. So, I guess your patch actually makes the device _not_ be detached from the driver. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Forcing C program to core dump
Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing C program to core dump
Garrett Cooper wrote: Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? Thanks, -Garrett Did a bit more poking around and determined how to do it. It wasn't core dumping because I didn't set the maximum limit for the coredump size to unlimited (ulimit -c unlimited). Good page about this topic: http://linuxfocus.berlios.de/English/July2004/article343.shtml. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing C program to core dump
On Wednesday 06 December 2006 20:02, Garrett Cooper wrote: Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? See gcore(1) and abort(3). sysctl -a | grep core might turn up some interesting sysctls. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp7Tja5B2ZqY.pgp Description: PGP signature
Re: Forcing C program to core dump
On Wednesday 06 December 2006 20:02 Garrett Cooper wrote: Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? Some signals default action is to cause the program to dump core, when they're delivered. You can see the list in the signal(3) man page. libc also provides the abort(3) function, which does what you want. The code is here: /usr/src/lib/libc/stdlib/abort.c Cheers, Vik -- PGP Key: 0xE09DC8D8/6799 4011 EBDE 6412 05A1 090C DBDF 5887 E09D C8D8 Signed/encrypted mail welcome! pgpXtluuOBwyC.pgp Description: PGP signature
Re: Forcing C program to core dump
Garrett Cooper wrote: Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? Thanks, -Garrett Just kill it with the abort signal (SIGABRT) or some other signal that makes the program dump core. Be aware though that if you are catching or ignoring the signal, this won't work. Regards! //Niclas -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forcing C program to core dump
Niclas Zeising wrote: Garrett Cooper wrote: Hello, This may be obvious to some, but after some Googling (apparently with the wrong search terms, perhaps) and reading the gcc/gdb manpages, I can't seem to find out how to get a program to produce core dumps. So I was wondering, is there some simple means to produce core dumps or a set of conditions that I need to adhere to in order to get the OS to core dump the progrdam??? Thanks, -Garrett Just kill it with the abort signal (SIGABRT) or some other signal that makes the program dump core. Be aware though that if you are catching or ignoring the signal, this won't work. Regards! //Niclas Wow. I got a lot of interesting ways to kill and force a coredump. Haha... Not quite what I had in mind, but I guess that's what I get for improperly wording the question. Thank you all, the information I've gotten recently is definitely educational and it'll probably end up being useful later! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on 6.1-RELEASE-p3
Anthony Chavez [EMAIL PROTECTED] writes:
John Baldwin [EMAIL PROTECTED] writes:
On Thursday 02 November 2006 15:19, Anthony Chavez wrote:
freebsd-hackers:
I have attached the backtraces of 17 core dumps from one of my
machines. I have several deployments of this same FreeBSD version in
the wild, and this is the only machine exhibiting this behavior.
Initially, the cause of these panics seemed to be related to some
component in the FreeBSD toolchain, as they would occur when
attempting to install a port. net/samba3 was the one we'd usually
test with, but the system would panic with most other larger packages
as well.
However, the system is panicking at irrgeular intervals, ranging
between 1-3 weeks apart. This is mostly happening in the off-hours
when no human users are actively using the machine, but there have
been 1 or 2 incidences where the machine has panicked during prime
time.
Have you ran a memory checker or other diags to check for failing hardware?
I ran sysutils/memtest twice. Both times, it failed to panic the
system. I have yet to bring the system down and boot into a real
memory/hardware checker, however. I usually just go with
ultimatebootcd.com when testing, but if you have other suggestions for
tools, I'd welcome your input before we schedule to do the testing.
Rather than pay us to debug the problem, our client opted to simply
replace the memory, and it only took them 17 more panics to move on
it until it started becoming a daily issue.
What follows is yet another backtrace from a panic that occurred after
about 20.5 hours of uptime.
I would appreciate any further assistance in addressing this problem.
--
Anthony Chavez http://anthonychavez.org/
mailto:[EMAIL PROTECTED] jabber:[EMAIL PROTECTED]
mybox% kgdb /usr/obj/usr/src/sys/WITFW/kernel.debug vmcore.37
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06809c4
stack pointer = 0x28:0xe9606bb4
frame pointer = 0x28:0xe9606bbc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 42888 (nagios)
trap number = 12
panic: page fault
Uptime: 20h27m59s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261808 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc065ff79 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc0660240 in panic (fmt=0xc08b378a %s)
at /usr/src/sys/kern/kern_shutdown.c:558
#3 0xc087a09e in trap_fatal (frame=0xe9606b74, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc087979a in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -987783168, tf_esi = 0,
tf_ebp = -379556932, tf_isp = -379556960, tf_ebx = -985433088, tf_edx =
-985433088, tf_ecx = -985433088, tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip
= -1066923580, tf_cs = 32, tf_eflags = 65539, tf_esp = 0, tf_ss = -987818712})
at /usr/src/sys/i386/i386/trap.c:269
#5 0xc08689aa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6 0xc06809c4 in turnstile_broadcast (ts=0x0)
at /usr/src/sys/kern/subr_turnstile.c:717
#7 0xc0657587 in _mtx_unlock_sleep (m=0xc51f1528, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:676
#8 0xc07fef0c in vnode_pager_lock (first_object=0xc5dcfa50)
at /usr/src/sys/vm/vnode_pager.c:1198
#9 0xc07eb572 in vm_fault (map=0xc591da8c, vaddr=134918144,
fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:299
#10 0xc0879cff in trap_pfault (frame=0xe9606d38, usermode=1, eva=134921272)
at /usr/src/sys/i386/i386/trap.c:721
#11 0xc087988f in trap (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134921272, tf_esi =
672508804, tf_ebp = -1077961820, tf_isp = -379556508, tf_ebx = 671912920,
tf_edx = 0, tf_ecx = 134534302, tf_eax =
