crashes on amd64 6.2-STABLE server
Once in a while my web-server running a fairly recent amd64-STABLE
reboots, after a panic.
I have the vmcore.[789] of the last three panics, but the backtraces say
little to me; can some help interpret them? what's going on?
% uname -a
FreeBSD motoko.lapo.it 6.2-STABLE FreeBSD 6.2-STABLE #7: Fri Jun 15
15:41:02 CEST 2007[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MOTOKO amd64
% kgdb /usr/obj/usr/src/sys/MOTOKO/kernel.debug vmcore.9
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[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 amd64-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 = 0xd5a015
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x80282fcf
stack pointer = 0x10:0xa4b31b80
frame pointer = 0x10:0x99d170a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 12 (swi4: clock sio)
trap number = 12
panic: page fault
Uptime: 18d20h28m34s
Physical memory: 1000 MB
Dumping 244 MB: 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5
#0 doadump () at pcpu.h:172
172 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x80273f63 in boot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:409
#3 0x80274566 in panic (fmt=0xff003cc7bbe0 X£Ç)
at /usr/src/sys/kern/kern_shutdown.c:565
#4 0x803fdab1 in trap_fatal (frame=0xff003cc7bbe0,
eva=18446742975217640280) at /usr/src/sys/amd64/amd64/trap.c:668
#5 0x803fe026 in trap (frame=
{tf_rdi = -1714027920, tf_rsi = 1628883229, tf_rdx = 14000133,
tf_rcx = 1628883229, tf_r8 = -1531765488, tf_r9 = 1, tf_rax = 299472,
tf_rbx = 1, tf_rbp = -1714327392, tf_r10 = -2141205256, tf_r11 =
-1098491905056, tf_r12 = 4, tf_r13 = -1099500839808, tf_r14 =
-1099511474880, tf_r15 = 2, tf_trapno = 12, tf_addr = 14000149, tf_flags
= -2144823770, tf_err = 0, tf_rip = -2144849969, tf_cs = 8, tf_rflags =
65538, tf_rsp = -1531765872, tf_ss = 16})
at /usr/src/sys/amd64/amd64/trap.c:239
#6 0x803e859b in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:168
#7 0x80282fcf in softclock (dummy=0x99d60270)
at /usr/src/sys/kern/kern_timeout.c:220
#8 0x8025b3f5 in ithread_loop (arg=0xff025540)
at /usr/src/sys/kern/kern_intr.c:682
#9 0x80259e43 in fork_exit (
callout=0x8025b2b0 ithread_loop, arg=0xff025540,
frame=0xa4b31c50) at /usr/src/sys/kern/kern_fork.c:821
#10 0x803e88fe in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:394
#11 0x in ?? ()
[all zeroes from now on]
% kgdb /usr/obj/usr/src/sys/MOTOKO/kernel.debug vmcore.8
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[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 amd64-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x6f
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x8034c8bb
stack pointer = 0x10:0xa4b31b50
frame pointer = 0x10:0xff002e8f5480
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock sio)
trap number = 12
panic: page fault
Uptime: 7d11h43m44s
Physical memory: 1000 MB
Dumping 238 MB: 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:172
172 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x80273f63 in boot (howto=260)
at
Re: Bug in less version 406.
Ted Hatfield wrote: Using less -E or more to display a file that is less than a full page, while then displaying a nonexistent file causes a segmentation fault. For example on a newly built system you can less -E /etc/group bogusfile This will display the file ending with /etc/group (file 1 of 2) (END) - Next: bogusfile when you press space or return it gives Segmentation fault: 11 I can reproduce it using more but not less -E. This is on -Current as of a week or so ago. TERM=xterm. Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
Graham Menhennitt wrote: Ted Hatfield wrote: Using less -E or more to display a file that is less than a full page, while then displaying a nonexistent file causes a segmentation fault. For example on a newly built system you can less -E /etc/group bogusfile This will display the file ending with /etc/group (file 1 of 2) (END) - Next: bogusfile when you press space or return it gives Segmentation fault: 11 I can reproduce it using more but not less -E. This is on -Current as of a week or so ago. TERM=xterm. I can reliably reproduce this with less -E on both -CURRENT and -STABLE... :S I need to do an operation on my eye this weekend so I have to wait a couple of days until I can recover from this. Cheers, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sata problems? / system freezes
Hi I have problems with a combination of Mainboard: Intel Serverboard SE7221BK1-E, ICH 6 Chipset, Bios Version P06 HDD: WD 4000YR, no raid FreeBSD 6.2-STABLE-200702 (boot messages see further down) From time to time (every 2-4 weeks) the server hangs without any message on the console or in log. It's not a kernel panic, the system freezes and there is no reaction from the server with the exception that the kernel debugger runs. It seems that the ata driver is hanging in an interrupt event and don't know what to do. Is there anybody who can give additional information about that? db bt Tracing pid 24 tid 100020 td 0xc637a480 kdb_enter(c072a8e2,e4f91bc8,c0,c637a480,c64ac400,...) at kdb_enter+0x30 siointr1(c64ac400,c64b60c0,c636f4c8,e4f91bec,c06d1799,...) at siointr1+0xd1 siointr(c64ac400,c637,e4f91bec,0,c637a480,...) at siointr+0x42 intr_execute_handlers(c636f4c8,e4f91c04,e4f91c7c,c06cdb33,37,...) at intr_execute_handlers+0xfa lapic_handle_intr(37) at lapic_handle_intr+0x3b Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc044c3ab, esp = 0xe4f91c48, ebp = 0xe4f91c7c --- ata_ahci_status(c64a4880,c63ffd38,c63ffc90,e4f91ce0,c0530521,...) at ata_ahci_status+0x57 ata_interrupt(c6479c00,c64a0cc0,4,e4f91ce0,c050ede2,...) at ata_interrupt+0x68 ata_generic_intr(c6489600,c637a480,f18bb,f2539122,c637a480,...) at ata_generic_intr+0x25 ithread_execute_handlers(c63ffc90,c6376300,c63ffc90,c637a480,c63ffc90,...) at ithread_execute_handlers+0x15e ithread_loop(c6462170,e4f91d38,,,,...) at ithread_loop+0x63 fork_exit(c050eec0,c6462170,e4f91d38) at fork_exit+0x7a fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f91d6c, ebp = 0 --- Doing some alltrace, go out of the debugger and reenter: ... Tracing command init pid 1 tid 17 td 0xc6379480 sched_switch(c6379480,0,1,11dd38b4,8d0595a4,...) at sched_switch+0x158 mi_switch(1,0) at mi_switch+0x1d4 sleepq_switch(c637f000,c6379480,0,e4f73c2c,c052ffcb,...) at sleepq_switch+0x91 sleepq_wait_sig(c637f000,5c,c07179db,100,c649c648,...) at sleepq_wait_sig+0x21 msleep(c637f000,c637f068,15c,c07179db,0,...) at msleep+0x288 kern_wait(c6379480,,e4f73c78,0,0,...) at kern_wait+0xb10 wait4(c6379480,e4f73d04,10,1a031,0,...) at wait4+0x3c syscall(3b,3b,bfbf003b,2,bfbfeef8,...) at syscall+0x34a Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (7, FreeBSD ELF32, wait4), eip = 0x8054197, esp = 0xbfbfed6c, ebp = 0xbfbfed88 --- Tracing command swapper pid 0 tid 0 td 0xc076f500 sched_switch(c076f500,0,1,b624e016,aa96b765,...) at sched_switch+0x158 mi_switch(1,0,0,0,0,...) at mi_switch+0x1d4 scheduler(0,c1e000,c1ec00,c1e000,0,...) at scheduler+0x224 mi_startup() at mi_startup+0xa0 begin() at begin+0x2c db continue ~KDB: enter: Line break on console [thread pid 24 tid 100020 ] Stopped at kdb_enter+0x30: leave db bt Tracing pid 24 tid 100020 td 0xc637a480 kdb_enter(c072a8e2,0,0,c637a480,c64ac400,...) at kdb_enter+0x30 siointr1(c64ac400,c64b60c0,c636f4c8,e4f91c80,c06d1799,...) at siointr1+0xd1 siointr(c64ac400,e4f91c74,c053cba3,0,c637a480,...) at siointr+0x42 intr_execute_handlers(c636f4c8,e4f91c98,e4f91ce0,c06cdb33,37,...) at intr_execute_handlers+0xfa lapic_handle_intr(37) at lapic_handle_intr+0x3b Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc06d781f, esp = 0xe4f91cdc, ebp = 0xe4f91ce0 --- spinlock_exit(1,0,c63ffc90,c637a480,c63ffc90,...) at spinlock_exit+0x28 ithread_loop(c6462170,e4f91d38,,,,...) at ithread_loop+0xf4 fork_exit(c050eec0,c6462170,e4f91d38) at fork_exit+0x7a fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f91d6c, ebp = 0 --- Trying do boot, but the hdd hangs in a timeout loop db call boot Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `bufdaemon' to stop... FreeBSD/i386 em1: watchdog timeout -- resetting ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=100029696 ad4: WARNING - SETFEATURES SET TRANSFER MODE
Re: named.conf restored to hint zone for the root by default
Doug Barton wrote: Oliver Fromme wrote: However, I noticed that the refresh interval of the root zone is 1800, i.e. it would be fetched every 30 minutes, No, refresh is how often the master servers are checked for serial number changes. True, I forgot about that. Thanks for reminding me. This is why what's suggested below is not a good idea either. Of course, you're right. By the way, I have changed from hints to slaves on the DNS servers for a large server farm (just testing right now; I might go back to hints if I don't feel it's worth it). It _seems_ a few applications run with lower latency, but I'll need to run some benchmarks in order to get some hard numbers. I will keep the hints zone on my office workstation and on my home machine. There seems to be consensus that slaving the root is not desirable in these cases. (Please correct me if I'm wrong.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildkernel failure
ok, thanks. I have made that change and now I've gotten this /usr/src/sys/ufs/ffs/ffs_vfsops.c: In function `ffs_mountfs': /usr/src/sys/ufs/ffs/ffs_vfsops.c:675: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:677: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:678: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:678: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:687: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:688: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:696: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:865: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:866: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:867: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c: In function `ffs_unmount': /usr/src/sys/ufs/ffs/ffs_vfsops.c:1028: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:1029: error: structure has no member named `mnt_gjprovider' /usr/src/sys/ufs/ffs/ffs_vfsops.c:1030: error: structure has no member named `mnt_gjprovider' *** Error code 1 I've searched the threads and found nothing so far relevant. pluknet wrote the following on 08/01/07 17:22: On 01/08/07, Kevin Kramer [EMAIL PROTECTED] wrote: I have a host that is running 6.2-PRERELEASE from Dec 14 2006. I'm trying to update it to 6.2 Stable. I've got the latest sources as of this morning. I'm also using gjournal so I've added the patch for that. The buildworld completed successfully, now I'm getting this when trying to buildkernel. /usr/src/sys/kern/vfs_subr.c: In function `vn_printf': /usr/src/sys/kern/vfs_subr.c:2551: error: `VV_DELETED' undeclared (first use in this function) /usr/src/sys/kern/vfs_subr.c:2551: error: (Each undeclared identifier is reported only once /usr/src/sys/kern/vfs_subr.c:2551: error: for each function it appears in.) *** Error code 1 I'm using GENERIC and have only added these lines and I moved my original /usr/src before cvs'ing. options SMP options UFS_GJOURNAL Thanks for any help. It was discussed: http://lists.freebsd.org/pipermail/freebsd-stable/2007-February/032985.html wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Friday 03 August 2007, Xin LI wrote:
Graham Menhennitt wrote:
Ted Hatfield wrote:
Using less -E or more to display a file that is less than a full page,
while then displaying a nonexistent file causes a segmentation fault.
For example on a newly built system you can
less -E /etc/group bogusfile
This will display the file ending with
/etc/group (file 1 of 2) (END) - Next: bogusfile
when you press space or return it gives
Segmentation fault: 11
I can reproduce it using more but not less -E. This is on -Current
as of a week or so ago. TERM=xterm.
I can reliably reproduce this with less -E on both -CURRENT and
-STABLE... :S I need to do an operation on my eye this weekend so I
have to wait a couple of days until I can recover from this.
Less keeps an internal filestate associated with each opened file. However
before opening the bogus file, it free()s the state. Less then notices that
the bogus file can't be opened, calls error(), which does some calculations
on the filestate ('thisfile' in ch.c) and crashes (Use after free). I have
written a workaround (attached) that moves the error() call below the
reinitialization of the previous state.
FYI it doesn't crash on the first file because any_display is not yet TRUE,
which causes error() to ignore the filestate.
There's also another regression in less: it doesn't automatically repaint the
screen anymore when you resize the terminal.
Regards,
Pieter de Goeje
--- contrib/less/edit.c.orig 2007-07-03 15:02:06.0 +0200
+++ contrib/less/edit.c 2007-08-04 01:03:43.0 +0200
@@ -308,8 +308,6 @@
/*
* It looks like a bad file. Don't try to open it.
*/
- error(%s, parg);
- free(parg.p_string);
err1:
if (alt_filename != NULL)
{
@@ -331,6 +329,13 @@
quit(QUIT_ERROR);
}
reedit_ifile(was_curr_ifile);
+
+ /*
+ * Cannot print the error if filestate isn't initialized.
+ */
+ error(%s, parg);
+ free(parg.p_string);
+
return (1);
} else if ((f = open(qopen_filename, OPEN_READ)) 0)
{
@@ -338,8 +343,6 @@
* Got an error trying to open it.
*/
parg.p_string = errno_message(filename);
- error(%s, parg);
- free(parg.p_string);
goto err1;
} else
{
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
On Aug 2, 2007, at 3:05 AM, Doug Barton wrote: I hope that we can now dial down the volume on the meta-issue of how the change was done, and focus on the operational issues of whether it's a good idea or not. Which has been answered to you, repeatedly, by the very people who know this best. A better question is what kind of beer/wine/cracker do we need to feed you so that your ears will open up and you'll start hearing the answers. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Sat, 4 Aug 2007, Pieter de Goeje wrote: *snip* There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. I have already reported that regression to Mark Nudelman. He is looking into an appropriate fix since this regression was introduced when fixing another bug. Sean -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Saturday 04 August 2007, Sean C. Farley wrote: On Sat, 4 Aug 2007, Pieter de Goeje wrote: *snip* There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. I have already reported that regression to Mark Nudelman. He is looking into an appropriate fix since this regression was introduced when fixing another bug. Sean Hmm I wonder what that other bug might have been... If I look at signal.c I see two signal handlers for things related to window changes. One for SIGWINCH and one for SIGWIND. The if(reading) intread(); statement was removed from the SIGWINCH handler. If removing that statement fixed the other bug why wasn't it removed from SIGWIND's handler? Does SIGWIND have different semantics? Anyway, re-adding if(reading) intread(); to signal.c:96 makes it work again, but I wonder what I broke by doing that. Regards, Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Saturday 04 August 2007, Alexander Kabaev wrote: On Sat, 4 Aug 2007 01:29:57 +0200 Pieter de Goeje [EMAIL PROTECTED] wrote: There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. Regards, Pieter de Goeje It most certainly does here. That's odd, are you sure you are using version 406? To clarify: you need to press a key before less notices the change in window size and redraws the screen. - Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in less version 406.
On Sat, 4 Aug 2007 01:29:57 +0200 Pieter de Goeje [EMAIL PROTECTED] wrote: There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. Regards, Pieter de Goeje It most certainly does here. -- Alexander Kabaev signature.asc Description: PGP signature
Re: named.conf restored to hint zone for the root by default
On Aug 3, 2007, at 5:25 PM, Doug Barton wrote: I'm getting tired of repeating this. A lot of really smart people are lined up on BOTH sides of this issue. You might want to take another look at the threads about this on the OARC list (or even this list for that matter) and try to have an open mind. Repeating this is a bad idea over and over again doesn't make it more true. No, they aren't. I'm actually quite amazed at your resistance to hearing what is being said. Several people (not a lot) think that slaving the root zone makes some good operational sense in specific scenarios. One person thought that the world would be a better place if it were operationally possible. NOBODY thinks that this will work in the real world, today, in a stable manner. NOBODY thinks that having *every* home user slaving the root makes good sense, even if it was operationally possible. And NOBODY thinks that just doing it without asking first was a good way to handle it. I'm really not sure why I wasted the keystrokes to write this, because you've been consistently willing to ignore pretty much everything said to you so far. I guess I'm just praying that perhaps, just maybe, this time you'll start paying attention. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
On Fri, 3 Aug 2007, Jo Rhett wrote: On Aug 2, 2007, at 3:05 AM, Doug Barton wrote: I hope that we can now dial down the volume on the meta-issue of how the change was done, and focus on the operational issues of whether it's a good idea or not. Which has been answered to you, repeatedly, by the very people who know this best. Jo, I'm getting tired of repeating this. A lot of really smart people are lined up on BOTH sides of this issue. You might want to take another look at the threads about this on the OARC list (or even this list for that matter) and try to have an open mind. Repeating this is a bad idea over and over again doesn't make it more true. Doug -- If you're never wrong, you're not trying hard enough ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
On Aug 3, 2007, at 6:12 PM, John Merryweather Cooper wrote: I would appreciate it if the personal attacks ceased. There was no personal attack there. I never called him names or made any remark about his lifestyle or anything else. I did say that he isn't paying attention to the people who disagree with him, but that is an observable fact. As an observer with no ax to grind on this issue, it is apparent that slaving the root zone is technically possible, but not necessarily good policy. Actually, it has been argued/shown-by-those-who-would-know that while you can do it, it won't work in a stable manner once everyone starts doing it. The protocol itself is not designed for many unknown associations, really. It would be nice if those arguing against slaving the root zone would articulate the specific effects on top-tier servers and quantify them. This has been done, both here and on the DNS Operations list where this is actually topical. Repeatedly. This topic is dead, horse beaten to crap, except that Doug Barton really loves this idea and won't listen to why it won't work, and why it shouldn't be done, and why he shouldn't have done it that way. He just keeps coming back and saying now lets talk about this some more... -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named.conf restored to hint zone for the root by default
Jo Rhett wrote: On Aug 3, 2007, at 5:25 PM, Doug Barton wrote: I'm getting tired of repeating this. A lot of really smart people are lined up on BOTH sides of this issue. You might want to take another look at the threads about this on the OARC list (or even this list for that matter) and try to have an open mind. Repeating this is a bad idea over and over again doesn't make it more true. No, they aren't. I'm actually quite amazed at your resistance to hearing what is being said. Several people (not a lot) think that slaving the root zone makes some good operational sense in specific scenarios. One person thought that the world would be a better place if it were operationally possible. NOBODY thinks that this will work in the real world, today, in a stable manner. NOBODY thinks that having *every* home user slaving the root makes good sense, even if it was operationally possible. And NOBODY thinks that just doing it without asking first was a good way to handle it. I'm really not sure why I wasted the keystrokes to write this, because you've been consistently willing to ignore pretty much everything said to you so far. I guess I'm just praying that perhaps, just maybe, this time you'll start paying attention. I would appreciate it if the personal attacks ceased. As an observer with no ax to grind on this issue, it is apparent that slaving the root zone is technically possible, but not necessarily good policy. It would be nice if those arguing against slaving the root zone would articulate the specific effects on top-tier servers and quantify them. As it is, this thread is painful to read because of the dross-to-substance ratio being rather high. jmc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Tuesday, July 31, 2007 14:47:50 -0700 Kris Moore [EMAIL PROTECTED] wrote: I'm not sure all the tests run properly since I didn't run through them yet. I'll try it out tomorrow morning though. All I tried was FireFox for Windows and installed StarCraft. Both worked just fine here. (I did a spawn of Starcraft since the safedisc support isn't working as far as I know) 'k, I just installed the latest patches from http://wiki.freebsd.org/Wine, and everything builds fine, and I'm getting alot further with the tests, but its failing at the rebar test ... I've posted to [EMAIL PROTECTED] with my results on this, as it seems to be the Wine side, not FreeBSD ... John, I've been running both the signal and pfault patches on my 6.x desktops since Tijl posted them, and haven't noticed any issues resulting from them ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGs+rw4QvfyHIvDvMRAiW8AKCpVIKvIZqWPA0yMLfxet/wl33FBQCghy1L AidVDAaM729qO7Mjms61UIY= =Z53o -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
