Re: How to diagnose system freezes?
On 07/31/2012 17:50, Mark Saad wrote: Yuri Install sysutils/mcelog and try running the example included . While not a complete definitative hardware test it can report other hardware issues that memtest86+ misses and it can be run on line in multiuser mode and via cron . Thanks for suggesting this. I have a question, however. Let's say 'mcelog --daemon' runs and encounters some MCE and logs it. Wouldn't this record be lost during the subsequent ungraceful (poweroff) reboot? Nonfatal MCEs, if any, will stay but what about the fatal one? Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to diagnose system freezes?
On Jul 31, 2012, at 8:29 PM, Julian Elischer wrote: > On 7/31/12 5:02 PM, Yuri wrote: >> One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it >> would usually cycle with a very short period. And system stops being >> sensitive to keyboard/mouse. Also ping of this system doesn't get a response. >> I would normally think that this is the faulty memory. But memory was >> recently replaced and tested with memtest+ for hours both before and after >> freezes and it passes all tests. >> One out of the ordinary thing that is running on this system is nvidia >> driver. But the freezes happen even when there is no graphics activity. >> Another out of the ordinary thing is that the kernel is built for DTrace. >> But DTrace was never used in the sessions that had a freeze. >> >> What is the way to diagnose this problem? > The answer depends on a number of things but an NMI can be useful if you have > some way of > generating them. (some IPMI implementations can allw you to generate them and > some motherboards have > jumpers to allow you to attach a 'nmi-button'. > > The fact that ping is not responsive is important, as that is done at a very > low level but > it may still be alive down there somewhere. > > Make sure you have debugging enabled in your kernel. That will catch quite a > few 'hangs'. > > as also mentioned by others... a serial console and DDB may also be useful in > some hangs. > > > Julian >> CPU: i7 CPU 920 @ 2.67GHz >> Memory: 24GB >> MB: P2T >> >> Yuri >> Yuri Install sysutils/mcelog and try running the example included . While not a complete definitative hardware test it can report other hardware issues that memtest86+ misses and it can be run on line in multiuser mode and via cron . --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to diagnose system freezes?
On 7/31/12 5:02 PM, Yuri wrote: One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it would usually cycle with a very short period. And system stops being sensitive to keyboard/mouse. Also ping of this system doesn't get a response. I would normally think that this is the faulty memory. But memory was recently replaced and tested with memtest+ for hours both before and after freezes and it passes all tests. One out of the ordinary thing that is running on this system is nvidia driver. But the freezes happen even when there is no graphics activity. Another out of the ordinary thing is that the kernel is built for DTrace. But DTrace was never used in the sessions that had a freeze. What is the way to diagnose this problem? The answer depends on a number of things but an NMI can be useful if you have some way of generating them. (some IPMI implementations can allw you to generate them and some motherboards have jumpers to allow you to attach a 'nmi-button'. The fact that ping is not responsive is important, as that is done at a very low level but it may still be alive down there somewhere. Make sure you have debugging enabled in your kernel. That will catch quite a few 'hangs'. as also mentioned by others... a serial console and DDB may also be useful in some hangs. Julian CPU: i7 CPU 920 @ 2.67GHz Memory: 24GB MB: P2T Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to diagnose system freezes?
On 8/1/12, Yuri wrote: > One of my 9.1-BETA1 systems periodically freezes. If sound was playing, > it would usually cycle with a very short period. And system stops being > sensitive to keyboard/mouse. Also ping of this system doesn't get a > response. > I would normally think that this is the faulty memory. But memory was > recently replaced and tested with memtest+ for hours both before and > after freezes and it passes all tests. > One out of the ordinary thing that is running on this system is nvidia > driver. But the freezes happen even when there is no graphics activity. > Another out of the ordinary thing is that the kernel is built for > DTrace. But DTrace was never used in the sessions that had a freeze. > > What is the way to diagnose this problem? Start by adding SW_WATCHDOG to your machine with a reasonably low timeout. Also, can you use a serial console? If yes you may consider going with a serial break. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
How to diagnose system freezes?
One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it would usually cycle with a very short period. And system stops being sensitive to keyboard/mouse. Also ping of this system doesn't get a response. I would normally think that this is the faulty memory. But memory was recently replaced and tested with memtest+ for hours both before and after freezes and it passes all tests. One out of the ordinary thing that is running on this system is nvidia driver. But the freezes happen even when there is no graphics activity. Another out of the ordinary thing is that the kernel is built for DTrace. But DTrace was never used in the sessions that had a freeze. What is the way to diagnose this problem? CPU: i7 CPU 920 @ 2.67GHz Memory: 24GB MB: P2T Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: newbus' ivar's limitation..
On Tue, Jul 31, 2012 at 8:47 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Jul 31, 2012 at 12:27 PM, Warner Losh wrote: >> >> On Jul 31, 2012, at 9:20 AM, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: [...] We lack that right now, which is why you're trying to shoe-horn the FDT connections into a newbus world and complaining that everything sucks because it is a poor fit. I'd suggest that different mechanisms are necessary. >>> I'm not trying anything, or at least no longer. I do not see the point >>> working on that when I can not get trivial patches in, especially >>> those fixing poorly maintained drivers, whose issues _do_ affect >>> people. >> >> Hey Arnaud, sorry to be a little harsh, but maybe if you shouted less and >> cooperated more, people would be more willing to work with you. >> > I tried to be Mr Nice Guy in the past, all I got in return was being > ignored. Lists are full of unanswered problem because people do not > want to insist getting an answer. Now, believe me on one point, if you > are a driver or subsystem author, might I have an issue with your > work, I *will* be a recurring pain in your butt to get the issue > fixed, or to get in what I do believe, with the limited set of > knowledge and resources to my disposal[0], to be a correct fix for the > issue, at the time. If you are condescending, arrogant, or advocates > of the status-quo, as have been committers in the past, I will return > you favor. Let face it, FreeBSD is not the most outstanding OS out > there (despite obvious capabilities), and I would not be too proud of > its state. > > All that to say that asking politely does not work in the arbitrary > FreeBSD realm, where "the power to serve", is today nothing more that > a relic. Arnaud, the problem I see here is that as always you make strong and false claims on bugs and missing support from FreeBSD kernel, but when people points out what are you missing/misunderstanding, you turn the whole thread into "FreeBSD is a relic" baby-whining, without replying with real technical arguments and simply ignoring e-mail by freebsd developers. I didn't see any response from you to several technical e-mail in this threads and others (please don't force me to open mailman and show exactly all the responses you have deliberately ignored), spitting unrespectful, poison-weighted words on developers of our project. You don't want to work cooperatively. You don't want to build something with FreeBSD community. So why you keep insist on sending e-mail like this? Don't you think it would be more productive for you to stick with another project? (I have a couple of names into my head that may be a good fit for you...). I think it is very offensive that you mock our statement like that. For many people reading this e-mail it has a true meaning, people like you should really watch his mouth when speaking about FreeBSD. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: newbus' ivar's limitation..
Hi, On Tue, Jul 31, 2012 at 12:27 PM, Warner Losh wrote: > > On Jul 31, 2012, at 9:20 AM, Arnaud Lacombe wrote: > >> Hi, >> >> On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: >>> [...] We lack that right now, which is why you're trying to shoe-horn the >>> FDT connections into a newbus world and complaining that everything sucks >>> because it is a poor fit. I'd suggest that different mechanisms are >>> necessary. >>> >> I'm not trying anything, or at least no longer. I do not see the point >> working on that when I can not get trivial patches in, especially >> those fixing poorly maintained drivers, whose issues _do_ affect >> people. > > Hey Arnaud, sorry to be a little harsh, but maybe if you shouted less and > cooperated more, people would be more willing to work with you. > I tried to be Mr Nice Guy in the past, all I got in return was being ignored. Lists are full of unanswered problem because people do not want to insist getting an answer. Now, believe me on one point, if you are a driver or subsystem author, might I have an issue with your work, I *will* be a recurring pain in your butt to get the issue fixed, or to get in what I do believe, with the limited set of knowledge and resources to my disposal[0], to be a correct fix for the issue, at the time. If you are condescending, arrogant, or advocates of the status-quo, as have been committers in the past, I will return you favor. Let face it, FreeBSD is not the most outstanding OS out there (despite obvious capabilities), and I would not be too proud of its state. All that to say that asking politely does not work in the arbitrary FreeBSD realm, where "the power to serve", is today nothing more that a relic. - Arnaud ps: note that I am ready to be wrong and to be publicly proven so, as it's been the case recently. [0]: which certainly not mean I am wrong, very far from that. > Having said that, I'd be happy to help fix this problem. I've not seen the > patches you're talking about, I'd be happy to take a look and try to get them > in, as appropriate. > > Warner > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: dtraceall.ko with old nfsclient
Sean Bruno wrote:
> On Thu, 2012-07-12 at 12:47 -0700, Andrew Boyer wrote:
> > On Jul 12, 2012, at 3:39 PM, Andriy Gapon wrote:
> >
> > > on 12/07/2012 22:36 Fabian Keil said the following:
> > >> Andriy Gapon wrote:
> > >>
> > >>> on 12/07/2012 21:17 Fabian Keil said the following:
> > Benjamin Kaduk wrote:
> >
> > > On Wed, 11 Jul 2012, Fabian Keil wrote:
> > >
> > >> I'm using the following modification of Sean's patch:
> >
> > This way it seems to work as expected:
> >
> > diff --git a/sys/modules/dtrace/dtraceall/Makefile
> > b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644
> > --- a/sys/modules/dtrace/dtraceall/Makefile +++
> > b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD:
> > src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs
> > Exp $
> >
> > KMOD= dtraceall -SRCS= dtraceall.c opt_compat.h
> > +SRCS= dtraceall.c opt_compat.h opt_nfs.h
> >
> > CFLAGS+= -I${.CURDIR}/../../..
> >
> > >>>
> > >>> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does
> > >>> it compile OK with the above change?
> > >>
> > >> Depends on your expectations I guess. As neither NFS-related option gets
> > >> defined, no dependency on either NFS module is registered. The compiler
> > >> has
> > >> no complaints, though.
> > >
> > > Interesting. Could you repeat after sufficient cleaning up?
> > > I am not sure where from opt_nfs.h file could come.
> > >
> >
> > Maybe related: check out sys/modules/ipfw/Makefile. It makes its own
> > option headers for INET and INET6.
I think guessing that INET and INET6 are available is a lot more
reasonable than doing the same for the external NFS modules.
> I've pondered this on an off for a couple of weeks now. I can clearly
> see that if we want compile time dependencies, that's fine, we can make
> each nfclient object dependant on the #define. Both are valid cases to
> have loaded though, so they shouldn't be conditional on each other as in
> my patches.
>
> If one does this however, the module makefile needs to be adjusted like
> the ipfw makefile to create an opt_nfs.h with the NFS client defines,
> else you will have neither dtrace object available.
>
> There isn't a clear way that I can see to compile dtraceall.ko as a
> module if you are doing so outside of the kernel compile though. The
> module tree isn't really aware of what you are running, therefore it
> would have to compile to load both regardless. Which, if your kernel
> doesn't support one or both nfs objects, will cause a kldload failure.
In my opinion depending on neither nfs modules when the module
is build manually is preferable to depending on both.
For users without the nfs modules available, forcing the dependencies
renders the dtraceall module useless, while users who want to dtrace nfs
can still use dtraceall and simply load the nfs module manually afterwards
if the dependency is missing.
Fabian
signature.asc
Description: PGP signature
Re: newbus' ivar's limitation..
On Jul 31, 2012, at 9:20 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: >> [...] We lack that right now, which is why you're trying to shoe-horn the >> FDT connections into a newbus world and complaining that everything sucks >> because it is a poor fit. I'd suggest that different mechanisms are >> necessary. >> > I'm not trying anything, or at least no longer. I do not see the point > working on that when I can not get trivial patches in, especially > those fixing poorly maintained drivers, whose issues _do_ affect > people. Hey Arnaud, sorry to be a little harsh, but maybe if you shouted less and cooperated more, people would be more willing to work with you. Having said that, I'd be happy to help fix this problem. I've not seen the patches you're talking about, I'd be happy to take a look and try to get them in, as appropriate. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: newbus' ivar's limitation..
Hi, On Mon, Jul 30, 2012 at 11:51 PM, Warner Losh wrote: > [...] We lack that right now, which is why you're trying to shoe-horn the FDT > connections into a newbus world and complaining that everything sucks because > it is a poor fit. I'd suggest that different mechanisms are necessary. > I'm not trying anything, or at least no longer. I do not see the point working on that when I can not get trivial patches in, especially those fixing poorly maintained drivers, whose issues _do_ affect people. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using mcelog
On Tuesday, July 17, 2012 8:52:40 am Mark Saad wrote: > All > I wanted to see how users of mcelog were implementing it on FreeBSD . My Linux servers tend to run it via cron hourly and dump the results to syslog or a local log file . For now I am going to make a similar setup . Does using it as a daemon provide anything running it via cron can't ? Are there any options to stay away from , Linux only options etc ? Also does anyone know what options there are for FreeBSD on sparc ? I don't think I ported daemon mode for it. You will have to run it from cron for now. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3
On Wednesday, July 18, 2012 4:59:21 pm James wrote: > On Wed, Jul 18, 2012 at 3:26 PM, Bill Crisp wrote: > > > > Unfortunately I tried to put the code from the patch in place but there > > seems to be some missing functions in the header file and too many > > arguments to a function and some other errors below: > > Hi Bill. Yes, the patch for >= FreeBSD 7 won't apply directly to > 6. ksi and the refined SIGBUS traps don't exist yet. Here's how I > fixed it at work. Using this on multiple releng_6* branches. > > HTH! This looks correct. A cosmetic nit would be to move the new changes up above the "Traced system call" comment. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
