Re: [releng_5 tinderbox] failure on sparc64/sparc64

2007-05-11 Thread Matthew Jacob
Sorry- my bad. I'll fix shortly. On 5/10/07, FreeBSD Tinderbox [EMAIL PROTECTED] wrote: TB --- 2007-05-10 14:42:44 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2007-05-10 14:42:44 - starting RELENG_5 tinderbox run for sparc64/sparc64 TB --- 2007-05-10 14:42:44 - cleaning the

Re: clock problem

2007-05-11 Thread Oliver Fromme
M. Warner Losh wrote: Peter Jeremy wrote: : There seems to be a bug in ntpd where the PLL can saturate at : +/-500ppm and will not recover. This problem seems too occur mostly : where the reference servers have lots of jitter (ie a fairly congested : link to them). Yes. This is a

freebsd and securelevel question

2007-05-11 Thread Gót András
Hi, So. The simple question is: Why FreeBSD has securelevel 0 if init sets it to 1, if it sees at boot that the level is 0? :) It's OK that it's in the manual, but there are two default ways to set securelevel at boot time also. I don't really get the point of this forced 0 to 1 changing. We'd

Re: freebsd and securelevel question

2007-05-11 Thread Thomas Hurst
* G?t Andr?s ([EMAIL PROTECTED]) wrote: So. The simple question is: Why FreeBSD has securelevel 0 if init sets it to 1, if it sees at boot that the level is 0? :) So when you boot to single user mode you can turn off immutable/append only flags etc, without letting those capabilities propagate

Re: freebsd and securelevel question

2007-05-11 Thread Oliver Fromme
Gót András [EMAIL PROTECTED] wrote: So. The simple question is: Why FreeBSD has securelevel 0 if init sets it to 1, if it sees at boot that the level is 0? :) It's OK that it's in the manual, but there are two default ways to set securelevel at boot time also. I don't really get the point

Re: UNIX domain sockets MFC's

2007-05-11 Thread Robert Watson
On Tue, 8 May 2007, Robert Watson wrote: Right now I am tracking two known issues with UNIX domain sockets in RELENG_6: - Reported NULL point derference in unp_connect(), which occurs due to the dropping of locks around sonewconn(). This is fixed in HEAD, and I am preparing an MFC of this

Re: clock problem

2007-05-11 Thread Martin Dieringer
On Thu, 10 May 2007, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : well now it works without restrict: : # ntpq -p : remote refid st t when poll reach delay offset jitter :

[releng_6 tinderbox] failure on sparc64/sparc64

2007-05-11 Thread FreeBSD Tinderbox
TB --- 2007-05-11 13:24:38 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2007-05-11 13:24:38 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2007-05-11 13:24:38 - cleaning the object tree TB --- 2007-05-11 13:25:06 - checking out the source tree TB --- 2007-05-11 13:25:06

Re: clock too slow - big time offset with ntpdate

2007-05-11 Thread Martin Dieringer
On Wed, 9 May 2007, Ian Smith wrote: Bottom line might be: if it hurts when you run powerd with APM, don't. If you want powerd to work, I'd suggest trying ACPI again ok, using ACPI solved the clock problem, the suspend problem has to be solved later m.

Re: UNIX domain sockets MFC's

2007-05-11 Thread Marc G. Fournier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, May 11, 2007 12:49:32 +0100 Robert Watson [EMAIL PROTECTED] wrote: On Tue, 8 May 2007, Robert Watson wrote: Right now I am tracking two known issues with UNIX domain sockets in RELENG_6: - Reported NULL point derference in

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : problem is solved by switching to ACPI instead of APM It is a hardware problem. APM + powerd changes the frequency of the TSC. If the TSC

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : Peter Jeremy wrote: : : There seems to be a bug in ntpd where the PLL can saturate at : : +/-500ppm and will not recover. This problem seems too occur mostly : : where the reference

Re: clock problem

2007-05-11 Thread Tom Evans
On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : problem is solved by switching to ACPI instead of APM It is a hardware

Re: panic: spin lock held too long (w/ backtrace)

2007-05-11 Thread Scott Swanson
[EMAIL PROTECTED] /usr/src/sys/i386/conf kldstat Id Refs AddressSize Name 13 0xc040 65e308 kernel 21 0xc0a5f000 59f20acpi.ko So, yes then :) Can you follow the steps for debugging modules and see if it gives a better trace? Kris Unfortunately, after

Intel ICH5 UDMA100 controller TIMEOUT - READ_DMA

2007-05-11 Thread Richard Puga
I am working with a new IBM XSeries 226 server. It worked fine with the original 80 gig drives. Upon replacing them with 2 new Hitichi 500 gig drives I get DMA timouts at random times while using the on board Intel SATA controller. I put a Promice SATA controller in the machine and everything

Re: Intel ICH5 UDMA100 controller TIMEOUT - READ_DMA

2007-05-11 Thread Jeremy Chadwick
On Fri, May 11, 2007 at 07:20:06AM -1000, Richard Puga wrote: I am working with a new IBM XSeries 226 server. It worked fine with the original 80 gig drives. Upon replacing them with 2 new Hitichi 500 gig drives I get DMA timouts at random times while using the on board Intel SATA

Re: clock problem

2007-05-11 Thread Ian Smith
On Fri, 11 May 2007, Tom Evans wrote: On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Dieringer [EMAIL PROTECTED] writes: : This is NOT a hardware problem. 1. I have this on 2 machines, 2. the : problem is solved by switching

Re: panic: spin lock held too long (w/ backtrace)

2007-05-11 Thread Kris Kennaway
On Fri, May 11, 2007 at 10:43:54AM -0600, Scott Swanson wrote: [EMAIL PROTECTED] /usr/src/sys/i386/conf kldstat Id Refs AddressSize Name 13 0xc040 65e308 kernel 21 0xc0a5f000 59f20acpi.ko So, yes then :) Can you follow the steps for debugging modules and

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Tom Evans [EMAIL PROTECTED] writes: : On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Martin Dieringer [EMAIL PROTECTED] writes: : : This is NOT a hardware problem. 1. I have this on 2 machines, 2.

Re: UNIX domain sockets MFC's

2007-05-11 Thread Abdullah Ibn Hamad Al-Marri
On 5/11/07, Robert Watson [EMAIL PROTECTED] wrote: On Tue, 8 May 2007, Robert Watson wrote: Right now I am tracking two known issues with UNIX domain sockets in RELENG_6: - Reported NULL point derference in unp_connect(), which occurs due to the dropping of locks around sonewconn(). This

Re: 6.2-R on Dell Poweredge 2950 with Dell PERC 5/i [mfi(4)]

2007-05-11 Thread David Wolfskill
On Thu, May 10, 2007 at 05:14:01PM -0600, Scott Long wrote: ... Not sure that this impression is entirely accurate. The biggest problem with MFI machines is online RAID management. The storage driver itself matured very quickly and has been very reliable. Ah; good to know: thank you.

Re: clock problem

2007-05-11 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Ian Smith [EMAIL PROTECTED] writes: : On Fri, 11 May 2007, Tom Evans wrote: : On Fri, 2007-05-11 at 08:53 -0600, M. Warner Losh wrote: :In message: [EMAIL PROTECTED] :Martin Dieringer [EMAIL PROTECTED] writes: :: This is NOT a

Re: UNIX domain sockets MFC's

2007-05-11 Thread Robert Watson
On Fri, 11 May 2007, Abdullah Ibn Hamad Al-Marri wrote: On 5/11/07, Robert Watson [EMAIL PROTECTED] wrote: On Tue, 8 May 2007, Robert Watson wrote: Right now I am tracking two known issues with UNIX domain sockets in RELENG_6: - Reported NULL point derference in unp_connect(), which

Re: 6.2-R on Dell Poweredge 2950 with Dell PERC 5/i [mfi(4)]

2007-05-11 Thread Scott Long
David Wolfskill wrote: On Thu, May 10, 2007 at 05:14:01PM -0600, Scott Long wrote: ... Not sure that this impression is entirely accurate. The biggest problem with MFI machines is online RAID management. The storage driver itself matured very quickly and has been very reliable. Ah; good to

Re: clock problem

2007-05-11 Thread Peter Jeremy
On 2007-May-11 12:11:29 +0200, Oliver Fromme [EMAIL PROTECTED] wrote: Of course, the best solution is to buy a GPS or DCF radio receiver and set up a startum-1 yourself. One of our customers has 6 GPS-locked NTP servers. Only problem is that two of them are reporting a time that is exactly one

Hard Hang, nothing in logs / no panics

2007-05-11 Thread Roger Miranda
Good Day everyone. I have this one system setup with If_bridge to filter traffic. It does work quite good. I am running FreeBSD 6.2 but as a TINYBSD Image. The one problem I have is I place the machine at the perimeter on our network with 27 seats. At that time anywhere between 15min -

Re: UNIX domain sockets MFC's

2007-05-11 Thread Abdullah Ibn Hamad Al-Marri
On 5/11/07, Robert Watson [EMAIL PROTECTED] wrote: On Fri, 11 May 2007, Abdullah Ibn Hamad Al-Marri wrote: On 5/11/07, Robert Watson [EMAIL PROTECTED] wrote: On Tue, 8 May 2007, Robert Watson wrote: Right now I am tracking two known issues with UNIX domain sockets in RELENG_6: -

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Kris Kennaway
On Fri, May 11, 2007 at 02:42:51PM -0500, Roger Miranda wrote: Good Day everyone. I have this one system setup with If_bridge to filter traffic. It does work quite good. I am running FreeBSD 6.2 but as a TINYBSD Image. The one problem I have is I place the machine at the perimeter on our

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Roger Miranda
On Friday 11 May 2007 16:00, Kris Kennaway wrote: See the developers handbook chapter on kernel debugging. Kris, I have gone through the kernel debugging sections of the developers handbook. The one problem is when I get a hard hang, I do not get any error or panics. And there is no crash

Re: clock problem

2007-05-11 Thread Matthew Dillon
:One of our customers has 6 GPS-locked NTP servers. Only problem is :that two of them are reporting a time that is exactly one second :different to the other four. You shouldn't rely solely on your :GPS or DCF receiver - use it as the primary source but have some :secondary sources for sanity

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Kris Kennaway
On Fri, May 11, 2007 at 04:21:25PM -0500, Roger Miranda wrote: On Friday 11 May 2007 16:00, Kris Kennaway wrote: See the developers handbook chapter on kernel debugging. Kris, I have gone through the kernel debugging sections of the developers handbook. The one problem is when I get a

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Roger Miranda
You missed that the debugger is there to debug bugs (including deadlocks). Break to the debugger and obtain the necessary debugging I should've been more clear. I can not break to the debugger (CTRL-ALT-ESC) when the system locks up. Am I possible looking at a hardware issue? If so what

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Kris Kennaway
On Fri, May 11, 2007 at 04:43:06PM -0500, Roger Miranda wrote: You missed that the debugger is there to debug bugs (including deadlocks). Break to the debugger and obtain the necessary debugging I should've been more clear. I can not break to the debugger (CTRL-ALT-ESC) when the

Re: clock problem

2007-05-11 Thread Matthew Dillon
Another idea to help track down timebase problems. Port dntpd to FreeBSD. You need like three sysctls (because the ntp API and the original sysctl API are both insufficient). Alternatively you could probably hack dntpd to run in debug mode without having to implement any new

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Diane Bruce
On Fri, May 11, 2007 at 05:47:35PM -0400, Kris Kennaway wrote: On Fri, May 11, 2007 at 04:43:06PM -0500, Roger Miranda wrote: You missed that the debugger is there to debug bugs (including deadlocks). Break to the debugger and obtain the necessary debugging I should've been more

Re: Hard Hang, nothing in logs / no panics

2007-05-11 Thread Daniel O'Connor
On Saturday 12 May 2007 07:34, Diane Bruce wrote: You may need the KDB_STOP_NMI option, especially if it is an SMP He can also try a serial console, if he can scare up something to use as a serial console. Serial ports are becoming legacy but if he can do it, it might help him. Or Firewire,

Re: UNIX domain sockets MFC's

2007-05-11 Thread Mark Linimon
On Fri, May 11, 2007 at 11:26:37PM +0300, Abdullah Ibn Hamad Al-Marri wrote: How safe is using 7.0 for MySQL server now? -CURRENT is never recommended for mission-critical applications. mcl ___ freebsd-stable@freebsd.org mailing list