Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: > > I've never used mpd myself, but you might want to try adding the > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > # BEFORE: named > > mpd should also be fixed as the error code being returned is not > approprate. network unreachable is what should be returned. I'm not sure that is the whole problem - I found that it would return device not configured 'permanently' when I was using it. The link would be up (apparently) but nothing passes. Sometimes restarting it would fix it but other times it just persistently said the same thing. It seemed like there was some kernel state that was incorrect and even restarting mpd would not fix it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Mark Andrews wrote: > In message <497bbe2c.5060...@freebsd.org>, Doug Barton writes: >> Mark Andrews wrote: >>> In message <497b9ff4.30...@freebsd.org>, Doug Barton writes: Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. >>> Or keep a local copy of the zone which contains them. >> I actually considered suggesting that option, but it's unclear to me >> whether or not named would answer at all, even for a local zone, given >> the situation described. > > named will always answer for local zones. > > b.t.w. BIND 9 primes when it attempts to recurse for the > first time. Interesting, thanks! Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
In message <497bbe2c.5060...@freebsd.org>, Doug Barton writes: > Mark Andrews wrote: > > In message <497b9ff4.30...@freebsd.org>, Doug Barton writes: > >> Any time you are using NFS you should maintain the addresses of the > >> critical hosts in /etc/hosts. Yes, I realize that's anachronistic > >> (especially for a DNS guy) but it works. Obviously you should make > >> sure to update them as needed. > > > > Or keep a local copy of the zone which contains them. > > I actually considered suggesting that option, but it's unclear to me > whether or not named would answer at all, even for a local zone, given > the situation described. named will always answer for local zones. b.t.w. BIND 9 primes when it attempts to recurse for the first time. > Doug > This .signature sanitized for your protection -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Mark Andrews wrote: > In message <497b9ff4.30...@freebsd.org>, Doug Barton writes: >> Any time you are using NFS you should maintain the addresses of the >> critical hosts in /etc/hosts. Yes, I realize that's anachronistic >> (especially for a DNS guy) but it works. Obviously you should make >> sure to update them as needed. > > Or keep a local copy of the zone which contains them. I actually considered suggesting that option, but it's unclear to me whether or not named would answer at all, even for a local zone, given the situation described. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
In message <497b9ff4.30...@freebsd.org>, Doug Barton writes: > Lev Serebryakov wrote: > > Hello, Freebsd-stable. > > > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > > errors on every start and doesn't answer on requests for 30-60 seconds > > after that. Errors are like this: > > It's not necessary or desirable to paste in so many examples of the > same message. It's also not good to cross post the same message to > multiple lists. > > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib > /bind9/lib/isc/unix/socket.c:1567: unexpected error: > > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured > > That message is fairly clear, the system has told named that it can > talk to the outside world, but there isn't anything there for named to > talk to. As you already pointed out in another message, the IP > addresses are for the root name servers. The first thing named does > when it starts up is to verify the information in the hints file. > > > Main problem is, that mount_nfs failed on startup on this router > > because bind is not ready due to these errors and all system goes to > > single-user mode :( > > Any time you are using NFS you should maintain the addresses of the > critical hosts in /etc/hosts. Yes, I realize that's anachronistic > (especially for a DNS guy) but it works. Obviously you should make > sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. > > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > > fake addresses to vr2 and vr3 doesn't help at all. > > > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t > o two > > providers. > > > > But previous installation (on faster hardware) doesn't show these > > errors at all! > > I've never used mpd myself, but you might want to try adding the > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. > Doug > > -- > > This .signature sanitized for your protection > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Installing packages using ports after freebsd-update doesn't work on amd64
Sorin Panca wrote: > After upgrading the system using freebsd-update from 6.3-RELEASE to > 7.0-RELEASE and after that, from 7.0 to 7.1 trying to install > ports-mgmt/portupgrade fails at ruby18 with the following message: If you haven't already you have to remove and reinstall _all_ of your ports after doing a major version upgrade (6.x -> 7.x). -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Lev Serebryakov wrote: > Hello, Freebsd-stable. > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: It's not necessary or desirable to paste in so many examples of the same message. It's also not good to cross post the same message to multiple lists. > Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: > unexpected error: > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured That message is fairly clear, the system has told named that it can talk to the outside world, but there isn't anything there for named to talk to. As you already pointed out in another message, the IP addresses are for the root name servers. The first thing named does when it starts up is to verify the information in the hints file. > Main problem is, that mount_nfs failed on startup on this router > because bind is not ready due to these errors and all system goes to > single-user mode :( Any time you are using NFS you should maintain the addresses of the critical hosts in /etc/hosts. Yes, I realize that's anachronistic (especially for a DNS guy) but it works. Obviously you should make sure to update them as needed. > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > fake addresses to vr2 and vr3 doesn't help at all. > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to > two > providers. > > But previous installation (on faster hardware) doesn't show these > errors at all! I've never used mpd myself, but you might want to try adding the following line to /usr/local/etc/rc.d/mpd and see if it helps: # BEFORE: named Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Installing packages using ports after freebsd-update doesn't work on amd64
After upgrading the system using freebsd-update from 6.3-RELEASE to 7.0-RELEASE and after that, from 7.0 to 7.1 trying to install ports-mgmt/portupgrade fails at ruby18 with the following message: cc -shared -Wl,-soname,libruby18.so.18 array.o bignum.o class.o compar.o dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o dmyext.o -lcrypt -lm -rpath=/usr/lib:/usr/local/lib -pthread -o libruby18.so.18 /usr/bin/ld: /usr/lib/libpthread.a(thr_syscalls.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/lib/libpthread.a: could not read symbols: Bad value *** Error code 1 I added CFLAGS?= -O2 -fPIC -pipe to /etc/make.conf but the problem persists. I didn't activate pthread support for ruby18. Any ideas on what's going wrong here? Thank you! Sorin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs drive keeps failing between export and import
Wes Morgan wrote: You might try creating the pool, saving the first 512k of each block device to a file, then export the pool and repeat, then import (or try to). Run zdb on each file and compare the output. From creation to export to import they should only differ by the "state" in the top level of the label nvlist. If the entire label is corrupted, then likely it's a crypto problem. Although, it really sounds like you've been able to eliminate zfs as a culprit. This is pretty much what I tried. between export, geli detach, and geli attach, zdb -l went from reporting info on the pool to reporting that no labels were found. dd confirmed what zdb was saying, so I have no reason to think zfs is acting up. I just don't get why I haven't been able to reproduce this with another zpool-less disk or two md disks. Maybe the .eli device shows up before it's ready to use and something gets cached by zfs in the background. Maybe it has something to do with me using two disks. A race condition? None of these are really easy things to find. For now, the only two ideas I have are trying zfs on a single disk with this configuration, and trying it on multiple disks, when the RMA is done, with 2 disks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic in destroy_devl: null si_devsw
Andriy Gapon wrote: ... About the code that called destroy_dev(): it created cdev probably too early, failed to allocate some system resource, so it went to destroy the newly created cdev. Non-null cdevsw was definitely provided to make_dev. I saw a very, very similar panic with 7.1 sources and jhb's ppc locking patch yesterday. Could this be related to a difference in unit numbers between 8.x and 8.x? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
panic in destroy_devl: null si_devsw
System: FreeBSD 7.1-PRERELEASE amd64 somewhere from the beginning of
Decemeber
I am not sure how I managed to get to this panic - I believe my code is
correct - but I got a panic in destroy_devl on NULL si_devsw.
Backtrace:
--- trap 0xc, rip = 0x80271c3f, rsp = 0xdb3e8510, rbp =
0xdb3e8550 ---
destroy_devl() at 0x80271c3f = destroy_devl+0x316
destroy_dev() at 0x80271e2c = destroy_dev+0x19
heci_deallocate_resources() at 0xdb63e0e6 =
heci_deallocate_resources+0x20
heci_detach() at 0xdb63e183 = heci_detach+0x11
heci_pci_attach() at 0xdb63f921 = heci_pci_attach+0x123
device_attach() at 0x802caa21 = device_attach+0x327
device_probe_and_attach() at 0x802cb8ef =
device_probe_and_attach+0xe2
pci_driver_added() at 0x80212e82 = pci_driver_added+0xf9
devclass_add_driver() at 0x802c98fa = devclass_add_driver+0xd7
driver_module_handler() at 0x802ca641 = driver_module_handler+0x74
module_register_init() at 0x8029901d = module_register_init+0xf7
linker_load_module() at 0x80292582 = linker_load_module+0xa01
kern_kldload() at 0x80292aa2 = kern_kldload+0xd4
kldload() at 0x80292b66 = kldload+0x61
syscall() at 0x8043d58d = syscall+0x347
Xfast_syscall() at 0x80423a5b = Xfast_syscall+0xab
--- syscall (304, FreeBSD ELF64, kldload), rip = 0x80067ff3c, rsp =
0x7fffe5b8, rbp = 0 ---
Debug:
(kgdb) fr 7
#7 0x80271c3f in destroy_devl (dev=0xff0075d45800) at
/usr/src/sys/kern/kern_conf.c:906
906 if (LIST_EMPTY(&csw->d_devs)) {
(kgdb) list
901 if (!(dev->si_flags & SI_ALIAS)) {
902 /* Remove from cdevsw list */
903 LIST_REMOVE(dev, si_list);
904
905 /* If cdevsw has no more struct cdev *'s, clean
it */
906 if (LIST_EMPTY(&csw->d_devs)) {
907 fini_cdevsw(csw);
908 wakeup(&csw->d_devs);
909 }
910 }
(kgdb) p csw
$1 = (struct cdevsw *) 0x0
Perhaps I screwed up something myself, but here is a question - why do
we have a check for NULL csw here:
873 csw = dev->si_devsw;
874 dev->si_devsw = NULL; /* already NULL for SI_ALIAS */
875 while (csw != NULL && csw->d_purge != NULL &&
dev->si_threadcount) {
and don't have any check where the panic occurred?
About the code that called destroy_dev(): it created cdev probably too
early, failed to allocate some system resource, so it went to destroy
the newly created cdev. Non-null cdevsw was definitely provided to make_dev.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: A nasty ataraid experience.
Oliver Fromme wrote:
Bruce M Simpson wrote:
> [...]
> I also now understand that I can't rely on RAID alone to keep the
> integrity of my own data -- there is no substitute for backups,
That's 100% true. RAID -- even true hardware RAID -- is
*never* a substitute for backup. Consider:
- Fire.
- Theft.
- Lightning strike or power surge.
- The cleaning woman knocks the tower over.
- ...
In all of those cases, chances are that both disks in the
RAID mirror die. Also, as you mentioned, it doesn't
protect agains human errors ("rm *" in the wrong directory
and similar things).
Backups should always be made to media that can be taken
offline and stored in a safe place: Tape, optical disks,
hard disks in swappable drive trays, or external drives.
Messr. Fromme's point _can never_ be restated too often: Offline and
offsite. Pick your religion: dump, rsync, bacula, amanda, whatever,
just stick with it.
(To the list I would add:
- Fancy new well known manuf's ATX power supply received from a
reputable reseller. Unwrapped from factory package, installed and the
RAID array discovered the 12v and 5v rails were swapped internally at
the factory and there went all of the magic smoke.)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re[2]: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Hello, Daniel. You wrote 24 января 2009 г., 15:10:24: >> Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect >> to two providers. >> >> But previous installation (on faster hardware) doesn't show these >> errors at all! > I think this is an mpd problem - I had the same issue and I couldn't find a > solution. In the end I switched to userland PPP (which has an issue with PF > but you can work around that). userland ppp doesn't support l2tp :( -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs drive keeps failing between export and import
On Sat, 24 Jan 2009, David Ehrmann wrote: On Thu, Jan 22, 2009 at 8:07 PM, Wes Morgan wrote: On Thu, 22 Jan 2009, David Ehrmann wrote: On Fri, Jan 16, 2009 at 3:21 PM, David Ehrmann wrote: In the /dev/ad8.eli that zfs doesn't recognize, I found a 16 byte string that was repeated a lot, but it was also repeated in another place: the good /dev/ad10.eli (though the offsets were different). The other weird thing: the good and bad /dev/ad8.eli look a lot alike: one 16 byte string, then another that gets repeated, then another 16 byte string randomly shows up at 0x200. The "xxx.eli" devices are the decrypted versions, aren't they? ZFS vdev labels and uberblocks occupy the first 512k of the device, and consist of virtually identical data, differing only by the GUID that the label claims to be and a sha256 checksum... So, decrypted, they should all be very, very similar. You could actually use the label from any device in a pool to reconstruct the label for any other device. Let me clarify one thing: when zfs has problems reading the device, the data resemble the data when it's read fine, but by resemble, I don't mean values as much as structure. The values are all wrong, but if you overlaid hexdumps, both share repeated patterns. That makes me think it's an encryption problem, but I haven't been able to reproduce it with other configurations. You might try creating the pool, saving the first 512k of each block device to a file, then export the pool and repeat, then import (or try to). Run zdb on each file and compare the output. From creation to export to import they should only differ by the "state" in the top level of the label nvlist. If the entire label is corrupted, then likely it's a crypto problem. Although, it really sounds like you've been able to eliminate zfs as a culprit. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
On Saturday 24 January 2009 21:07:33 Lev Serebryakov wrote: > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > errors on every start and doesn't answer on requests for 30-60 seconds > after that. Errors are like this: > > Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: > unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: > 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: > /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:11 >1: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert > errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway ... > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect > to two providers. > > But previous installation (on faster hardware) doesn't show these > errors at all! I think this is an mpd problem - I had the same issue and I couldn't find a solution. In the end I switched to userland PPP (which has an issue with PF but you can work around that). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Hello, Lev. You wrote 24 января 2009 г., 13:37:33: > IP addresses are RANDOM and DIFFERENT on every restart. These IP > addresses are not mentioned in ANY config file on my computer, and > addresses on my network interfaces IS NOT from these networks. Ok, I'm stupid, it is root servers. Ok. But this knowledge doesn't help to fix problem :( > Main problem is, that mount_nfs failed on startup on this router > because bind is not ready due to these errors and all system goes to > single-user mode :( -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
panic in callout_reset: bad link in callwheel
System: FreeBSD 7.1-STABLE i386 (revision 187025)
Panic message:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xd2006ad0
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc05623aa
stack pointer = 0x28:0xdd4f6c34
frame pointer = 0x28:0xdd4f6c40
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 13 (swi4: clock)
trap number = 12
panic: page fault
KDB: stack backtrace:
db_trace_self_wrapper(c074bb2f,dd4f6b14,c05514af,c0749d10,c07b85e0,...)
at 0xc0478466 = db_trace_self_wrapper+0x26
kdb_backtrace(c0749d10,c07b85e0,c073b02b,dd4f6b20,dd4f6b20,...) at
0xc057a639 = kdb_backtrace+0x29
panic(c073b02b,c0761cb4,c36104dc,1,1,...) at 0xc05514af = panic+0xaf
trap_fatal(c0761bb6,c,c3a89460,c3a8965c,c,...) at 0xc0705723 =
trap_fatal+0x353
trap(dd4f6bf4) at 0xc07060ca = trap+0x10a
calltrap() at 0xc06f463b = calltrap+0x6
--- trap 0xc, eip = 0xc05623aa, esp = 0xdd4f6c34, ebp = 0xdd4f6c40 ---
callout_reset(c3a8552c,13,c0561940,c3a852b8,c3612690,...) at 0xc05623aa
= callout_reset+0x14a
realitexpire(c3a852b8,2d6100,c3612690,1,dd4f6cbc,...) at 0xc0561ab6 =
realitexpire+0x176
softclock(0,0,c0747617,4a1,0,...) at 0xc0562c25 = softclock+0x235
ithread_loop(c35e5a20,dd4f6d38,0,0,0,...) at 0xc053268b = ithread_loop+0x1cb
fork_exit(c05324c0,c35e5a20,dd4f6d38) at 0xc052eda1 = fork_exit+0xa1
fork_trampoline() at 0xc06f46b0 = fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xdd4f6d70, ebp = 0 ---
Some debugging:
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc05512b3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc05514ff in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0705723 in trap_fatal (frame=0xdd4f6bf4, eva=3523242704) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc07060ca in trap (frame=0xdd4f6bf4) at
/usr/src/sys/i386/i386/trap.c:320
#5 0xc06f463b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#6 0xc05623aa in callout_reset (c=0xc3a8552c, to_ticks=19,
ftn=0xc0561940 , arg=0xc3a852b8) at
/usr/src/sys/kern/kern_timeout.c:471
#7 0xc0561ab6 in realitexpire (arg=0xc3a852b8) at
/usr/src/sys/kern/kern_time.c:684
#8 0xc0562c25 in softclock (dummy=0x0) at
/usr/src/sys/kern/kern_timeout.c:274
#9 0xc053268b in ithread_loop (arg=0xc35e5a20) at
/usr/src/sys/kern/kern_intr.c:1088
#10 0xc052eda1 in fork_exit (callout=0xc05324c0 ,
arg=0xc35e5a20, frame=0xdd4f6d38) at /usr/src/sys/kern/kern_fork.c:804
#11 0xc06f46b0 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264
(kgdb) fr 6
#6 0xc05623aa in callout_reset (c=0xc3a8552c, to_ticks=19,
ftn=0xc0561940 , arg=0xc3a852b8) at
/usr/src/sys/kern/kern_timeout.c:471
471 /usr/src/sys/kern/kern_timeout.c: No such file or directory.
in /usr/src/sys/kern/kern_timeout.c
(kgdb) p *c
$1 = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev
= 0xd2006ad0}}, c_time = 2974104, c_arg = 0xc3a852b8, c_func =
0xc0561940 , c_mtx = 0x0, c_flags = 22}
(kgdb) p c->c_links.tqe.tqe_prev
$2 = (struct callout **) 0xd2006ad0
(kgdb) p *c->c_links.tqe.tqe_prev
Cannot access memory at address 0xd2006ad0
(kgdb) p callwheel[c->c_time & callwheelmask]
$4 = {tqh_first = 0x0, tqh_last = 0xd2006ad0}
The code:
467 c->c_arg = arg;
468 c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING);
469 c->c_func = ftn;
470 c->c_time = ticks + to_ticks;
471 TAILQ_INSERT_TAIL(&callwheel[c->c_time & callwheelmask],
472 c, c_links.tqe);
Additional info:
I recently added some new memory to this system.
The memory survived several passes of memtest86 before booting to
FreeBSD. It also survived one pass after the incident.
Still I wouldn't exclude a possibility of it being bad.
Small analysis:
If this is not because of bad memory, then it probably means that a
struct callout was earlier deallocated somewhere (possibly as a part of
a bigger object), but not unregistered/removed from callout mechanism.
I guess it is quite hard to backtrack that now.
All I can say that was nothing "funny" happening on the machine from the
point of view of attaching/detaching any HW or loading/unloading modules
or anything like that. Just "normal" work. So it could be something that
it is always "on", like network stack or ata subsystem, etc.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
Hello, Freebsd-stable. BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of errors on every start and doesn't answer on requests for 30-60 seconds after that. Errors are like this: Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 192.112.36.4#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 192.112.36.4#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1567: unexpected error: Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device not configured Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/errno2result.c:111: unexpected error: Jan 24 12:18:12 gateway named[1455]: unable to convert errno to isc_result: 6: Device not configured IP addresses are RANDOM and DIFFERENT on every restart. These IP addresses are not mentioned in ANY config file on my computer, and addresses on my network interfaces IS NOT from these networks. Main problem is, that mount_nfs failed on startup on this router because bind is not ready due to these errors and all system goes to single-user mode :( Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding fake addresses to vr2 and vr3 doesn't help at all. Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two providers. But previous installation (on faster hardware) doesn't show these errors at all! -- // Black Lion AKA Lev Serebryakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: interrupt storm on MSI IXP600 based motherboards
Dan Langille wrote: I shall try the hw.acpi.osname="Linux" option now. From dmsg: Jan 22 18:10:07 polo kernel: ACPI: Overriding _OS definition with "Linux" it works for me for 3 days, 16:27 and still no sign of interrupt storm. and emu10kx0 generates as many as 93 interrupt per second without trouble. What is your situation? The box has rebooted twice tonight. The first time, it was running the "while true; do dd..." script. The second time, it was not. The box is now up responding to pings, but I cannot ssh to it. I can't get to the console until Monday. try to build kernel with KDB and DDB. -- SY, Marat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs drive keeps failing between export and import
On Thu, Jan 22, 2009 at 8:07 PM, Wes Morgan wrote: > On Thu, 22 Jan 2009, David Ehrmann wrote: > >> On Fri, Jan 16, 2009 at 3:21 PM, David Ehrmann wrote: >> >> In the /dev/ad8.eli that zfs doesn't recognize, I found a 16 byte >> string that was repeated a lot, but it was also repeated in another >> place: the good /dev/ad10.eli (though the offsets were different). >> The other weird thing: the good and bad /dev/ad8.eli look a lot alike: >> one 16 byte string, then another that gets repeated, then another 16 >> byte string randomly shows up at 0x200. > > The "xxx.eli" devices are the decrypted versions, aren't they? ZFS vdev > labels and uberblocks occupy the first 512k of the device, and consist of > virtually identical data, differing only by the GUID that the label claims > to be and a sha256 checksum... So, decrypted, they should all be very, very > similar. You could actually use the label from any device in a pool to > reconstruct the label for any other device. Let me clarify one thing: when zfs has problems reading the device, the data resemble the data when it's read fine, but by resemble, I don't mean values as much as structure. The values are all wrong, but if you overlaid hexdumps, both share repeated patterns. That makes me think it's an encryption problem, but I haven't been able to reproduce it with other configurations. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
