Re: Lock-up with CPU busy at r217145; seems OK now at r217189
on 09/01/2011 20:36 Michael Butler said the following: > automoc4 spawns a child during a KDE-4 build which > turns into a zombie but is never seen to return and the build stalls - > weird :-( I believe that this one particular issue should be fixed by r217253. The problem resolved by the commit resulted in some signals being lost sometimes, in particular SIGCHLD. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Sun, 09.01.2011 at 01:13:54 +0100, Jilles Tjoelker wrote: > On Wed, Jan 05, 2011 at 10:30:43PM +0100, Ulrich Spörlein wrote: > > On Wed, 05.01.2011 at 20:36:53 +0100, Jilles Tjoelker wrote: > > > On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Spörlein wrote: > > > > *But*, it should grok that for err(3) and exit(3). Now there are some > > > > possible remedies: > > > > > - get IPA to work with clang, or at least file a bug > > > > > - mark functions as __dead2 (please don't do that) > > > > Why not? > > > Cause IMHO it adds clutter, is noisy and needs to be maintained > > manually, when we have these "computer" things that should deduct this > > by themselves. > > Yes, but to me it seems the only realistic option of your three. > Upstream is unlikely to add IPA to the checker and other kinds of > annotation are probably either similar to __dead2 with the same problems > and an additional one that gcc does not check it or very specific to a > particular complaint from the checker. > > > > I have done this in some cases because it leads to better code with gcc > > > (the system version in 9-current). See SVN commit r212508 to > > > bin/sh/parser.c. Although synexpect() and synerror() are static, adding > > > __dead2 to both makes the executable 576 bytes smaller on i386 (these > > > functions are called many times). Adding __dead2 to synexpect() only > > > causes a warning "noreturn function does return" (it calls synerror()). > > > Adding __dead2 to synerror() only also makes the executable smaller but > > > not as much as adding it to both. > > > > Reordering the functions in the file does not help to make gcc see that > > > the functions do not return. > > > This is too bad and really makes me sad. It shouldn't be necessary to > > hand-hold the compilers like that. Could you try some tests with gcc 4.5 > > to confirm this is still required? > > gcc 4.5 still needs it. gcc 4.6 and clang (the compiler) do not need it. > (For gcc, used ports gcc and compiled head bin/sh with some patches on > stable/8. For clang, used base clang and compiled head bin/sh on head.) Thank you for confirming this, this is good to know. Looks like I need to stop worrying and learn to love the __dead2! :D Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
why panic(9) ?
Hello, I'm just guessing why current BSD panic() when a problem occurs, all modern operating systems solve the problem instead of crashing suddently and corrupting all your data without saving your work. Yes, why this function exists? There is no way to solve a problem without panic'ing? Is panic really needed? Imagine someone working on something really important and his computer just panic, his work not saved everybody shout at him in the corporation. He lose his job, his wife, his dog, everything is wrong, just because of a panic() ! Seriously, I really hate when I play some music that suddenly the music get stucked in a infinite loop, why ? I don't know because the panic does not core dump. But after some search I found that the panic was done because of conky. How the hell conky can panic FreeBSD? We are in 2011 ! I think even Window 2000 does not crash on a user-land software. I'm guessing now, if minix panic when a bloated crappy software is running. I think Andrew is in the right way. -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/11/11 12:11, David DEMELIER wrote: > Yes, why this function exists? There is no way to solve a problem > without panic'ing? Is panic really needed? Imagine someone working on [...] Panic is used to stop the kernel in an aggressive way when data damage is detected and the damage is already beyond what the kernel can recover from. The kernel can and should be made more robust but no, I don't think we can totally eliminate panic(). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJNLL5FAAoJEATO+BI/yjfBekQIAKc/uSvo/mi1qTChwk4PgaHy mLVXF1Wrdrm2naOR6k6n2/SKGabCWWbaAknmir1METbcojhMGMCXgCznUAJ4zKRH qpiToOdJWOA6VTTQDueK/WIqhuNTWv0qc3pfTZ3oWa/3aardp6G7AQJZKcZi3OGi ePkRNom7cDd8eXkZ6Sohgv1d3y8RAk0SXzW6as363aotdrVgGJmDYTHYQkEIWyF2 VYmM+uPdg08lm9Ryt/xvsOWwQwzcA+YeAH5M/mZJf0E5OaBf0Gx5NH059UqQOQt+ QHOShqLOGTkZ1l7bCp2Dl1yK6Gujgb1k0AwesuQLv+w0/0CfbRdRZLQz4+oI+Mo= =WDrK -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Jan 11, 2011, at 12:11 PM, David DEMELIER wrote: > I'm just guessing why current BSD panic() when a problem occurs, all > modern operating systems solve the problem instead of crashing > suddently and corrupting all your data without saving your work. You've got it backwards. A system panic()s to avoid writing corrupted data to disk. > Yes, why this function exists? There is no way to solve a problem > without panic'ing? Is panic really needed? Sometimes, yes. If it was possible for the kernel to handle an error condition without panic()ing, then that is obviously preferred-- but there are situations where there is no way for the system to recover. Common examples of that include when the boot disk fails or disappears, or when the kernel runs out of memory in a situation where it can't get more free pages available. Less common is when some kind of kernel invariant is violated, indicating that essential kernel data structures have been corrupted. > Imagine someone working on something really important and his computer just > panic, his work not > saved everybody shout at him in the corporation. He lose his job, his > wife, his dog, everything is wrong, just because of a panic() ! I admire your contrived example. :-) The data available to me suggests that Solaris boxes on enterprise-grade hardware have the highest uptimes; FreeBSD (and related platforms like NetBSD/OpenBSD/DFly/etc) are next, then MacOS X, then Linux, then Windows. I expect anything based on Unix to be routinely capable of multi-year uptimes; some carefully chosen Windows boxes can also do that, but the widespread prevalence of security issues requiring reboots on Windows means that I don't usually see Windows boxes with uptimes of greater than a month. > Seriously, I really hate when I play some music that suddenly the > music get stucked in a infinite loop, why ? Probably a bug in the sound card driver. > I don't know because the panic does not core dump. But after some search I > found that the panic > was done because of conky. How the hell conky can panic FreeBSD? We are in > 2011 ! I think even Window 2000 does not crash on a user-land software. "think"? If you don't have experience running Windows 2000 are thus are simply guessing, let me assure you that Win 2000 can and does (or did) panic due to userland software. Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Tue, Jan 11, 2011 at 9:32 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 01/11/11 12:11, David DEMELIER wrote: >> Yes, why this function exists? There is no way to solve a problem >> without panic'ing? Is panic really needed? Imagine someone working on > [...] > > Panic is used to stop the kernel in an aggressive way when data damage > is detected and the damage is already beyond what the kernel can recover > from. > > The kernel can and should be made more robust but no, I don't think we > can totally eliminate panic(). Exactly. One area where the kernel should be made more robust is UFS with disappearing disks (e.g. USB mounted file systems, or, as recently happened here with a loose external SATA cable). Panicing here is REALLY annoying. ;-) > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Tue, Jan 11, 2011 at 9:50 PM, Boris Kochergin wrote: >> Exactly. One area where the kernel should be made more robust >> is UFS with disappearing disks (e.g. USB mounted file systems, >> or, as recently happened here with a loose external SATA cable). >> Panicing here is REALLY annoying. ;-) > > Getting slightly off-topic here, but... there was progress made on this > front a while ago. You can reliably detach at least USB storage with a > mounted MSDOSFS or UFS filesystem without soft updates and not risk a system > panic. There will be a panic if soft updates are enabled on UFS, however, at > least as of my last test in 2010. Hmmm... yes, you're absolutely right: every time I had those panics was with softupdates enabled. No recent panic with UFS without softupdates that I remember, nor with msdosfs btw. > -Boris -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On 01/11/11 15:37, C. P. Ghost wrote: On Tue, Jan 11, 2011 at 9:32 PM, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/11/11 12:11, David DEMELIER wrote: Yes, why this function exists? There is no way to solve a problem without panic'ing? Is panic really needed? Imagine someone working on [...] Panic is used to stop the kernel in an aggressive way when data damage is detected and the damage is already beyond what the kernel can recover from. The kernel can and should be made more robust but no, I don't think we can totally eliminate panic(). Exactly. One area where the kernel should be made more robust is UFS with disappearing disks (e.g. USB mounted file systems, or, as recently happened here with a loose external SATA cable). Panicing here is REALLY annoying. ;-) Getting slightly off-topic here, but... there was progress made on this front a while ago. You can reliably detach at least USB storage with a mounted MSDOSFS or UFS filesystem without soft updates and not risk a system panic. There will be a panic if soft updates are enabled on UFS, however, at least as of my last test in 2010. -Boris Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -cpghost. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Tue, Jan 11, 2011 at 9:11 PM, David DEMELIER wrote: > Hello, > > I'm just guessing why current BSD panic() when a problem occurs, all > modern operating systems solve the problem instead of crashing > suddently and corrupting all your data without saving your work. > > Yes, why this function exists? There is no way to solve a problem > without panic'ing? Is panic really needed? Imagine someone working on > something really important and his computer just panic, his work not > saved everybody shout at him in the corporation. He lose his job, his > wife, his dog, everything is wrong, just because of a panic() ! Sometimes, it's best to panic(9) rather than to try recovery. Imagine a situation where the kernel detects that some of its important internal data structures are corrupted. Should it resume execution with pointers pointing into some Nirwana (and "undefined behavior" in the worst case means that some serious bad things could happen), or is it preferable to panic(9) right away? Granted, some panics could handled more gracefully, e.g. flushing buffers and such to disk... but here again: in most cases, the kernel can't be sure that it is internally sane enough to write to disk (it could overwrite other parts of the disk by syncing, right?), so better leave the disks untouched in this circumstance (only exception: dumping core). > Seriously, I really hate when I play some music that suddenly the > music get stucked in a infinite loop, why ? I don't know because the > panic does not core dump. But after some search I found that the panic > was done because of conky. How the hell conky can panic FreeBSD? We > are in 2011 ! I think even Window 2000 does not crash on a user-land > software. > > I'm guessing now, if minix panic when a bloated crappy software is > running. I think Andrew is in the right way. The real problem we have here (IMHO), is that we don't have a microkernel architecture. Any error in a driver would panic the whole system. This is a real pain. But short of redesigning BSD from scratch, there's not much we could do atm. > -- > Demelier David -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On 01/11/11 15:11, David DEMELIER wrote: Hello, Hi. I'm just guessing why current BSD panic() when a problem occurs, all modern operating systems solve the problem instead of crashing suddently and corrupting all your data without saving your work. All modern operating systems? Maybe some niche ones, like the ones that run on Mars rovers, have made progress towards formal verification and are believed not to crash given correctly-functioning hardware. The latest versions of Windows, OS X, and Linux all panic. Yes, why this function exists? There is no way to solve a problem without panic'ing? Imagine you've got a machine with bad RAM. It corrupts a pointer in the kernel filesystem code. Imagine there is some code in the kernel filesystem code that checks whether a pointer points to memory belonging to the kernel filesystem code before dereferencing it, and the check failed. What should happen? Continued execution will, at best, lead to flamboyant failure of kernel subsystems or userspace programs, and, at worst, will silently destroy or modify data in memory or on your disk. (By the way, this actually happens.) Is panic really needed? Imagine someone working on something really important and his computer just panic, his work not saved everybody shout at him in the corporation. He lose his job, his wife, his dog, everything is wrong, just because of a panic() ! When I do kernel work, I keep my source code on an NFS share on a known-stable machine so that when the machine I'm working on inevitably crashes, I don't lose my code. Reliability is about more than software choices. There are other best practices to consider. Seriously, I really hate when I play some music that suddenly the music get stucked in a infinite loop, why ? I don't know because the panic does not core dump. But after some search I found that the panic was done because of conky. How the hell conky can panic FreeBSD? We are in 2011 ! I think even Window 2000 does not crash on a user-land software. Frustrating at it may be, there are things you can do, like compiling your kernel with DDB and performing online debugging. -Boris I'm guessing now, if minix panic when a bloated crappy software is running. I think Andrew is in the right way. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
2011/1/11 Chuck Swiger : > On Jan 11, 2011, at 12:11 PM, David DEMELIER wrote: >> I'm just guessing why current BSD panic() when a problem occurs, all >> modern operating systems solve the problem instead of crashing >> suddently and corrupting all your data without saving your work. > > You've got it backwards. A system panic()s to avoid writing corrupted data > to disk. > >> Yes, why this function exists? There is no way to solve a problem >> without panic'ing? Is panic really needed? > > Sometimes, yes. If it was possible for the kernel to handle an error > condition without panic()ing, then that is obviously preferred-- but there > are situations where there is no way for the system to recover. Common > examples of that include when the boot disk fails or disappears, or when the > kernel runs out of memory in a situation where it can't get more free pages > available. Less common is when some kind of kernel invariant is violated, > indicating that essential kernel data structures have been corrupted. > Well I see, I know that kern.sync_on_panic exists to force a sync on a panic but because my laptop usually does not core dump so never reboot my disk are not sync'ed :-( it results in a file system not clean an that's the thing I really hate. >> Imagine someone working on something really important and his computer just >> panic, his work not >> saved everybody shout at him in the corporation. He lose his job, his >> wife, his dog, everything is wrong, just because of a panic() ! > > I admire your contrived example. :-) The data available to me suggests that > Solaris boxes on enterprise-grade hardware have the highest uptimes; FreeBSD > (and related platforms like NetBSD/OpenBSD/DFly/etc) are next, then MacOS X, > then Linux, then Windows. > > I expect anything based on Unix to be routinely capable of multi-year > uptimes; some carefully chosen Windows boxes can also do that, but the > widespread prevalence of security issues requiring reboots on Windows means > that I don't usually see Windows boxes with uptimes of greater than a month. > >> Seriously, I really hate when I play some music that suddenly the >> music get stucked in a infinite loop, why ? > > Probably a bug in the sound card driver. > No no, it was a panic that didn't core dump so I needed to do a hard reboot. >> I don't know because the panic does not core dump. But after some search I >> found that the panic >> was done because of conky. How the hell conky can panic FreeBSD? We are in >> 2011 ! I think even Window 2000 does not crash on a user-land software. > > "think"? If you don't have experience running Windows 2000 are thus are > simply guessing, let me assure you that Win 2000 can and does (or did) panic > due to userland software. > In fact I like FreeBSD, and I don't expect running anything else. But I must say that I didnt see windows 2000 crashing on my every boxes I have before switching to FreeBSD. I understand everything, corrupts kernel data must not be used. That's why panic are made to prevent any dangerous things. -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Jan 11, 2011, at 1:11 PM, David DEMELIER wrote: > 2011/1/11 Chuck Swiger : >> [ ... ] >>> Yes, why this function exists? There is no way to solve a problem >>> without panic'ing? Is panic really needed? >> >> Sometimes, yes. If it was possible for the kernel to handle an error >> condition without panic()ing, then that is obviously preferred-- but there >> are situations where there is no way for the system to recover. Common >> examples of that include when the boot disk fails or disappears, or when the >> kernel runs out of memory in a situation where it can't get more free pages >> available. Less common is when some kind of kernel invariant is violated, >> indicating that essential kernel data structures have been corrupted. > > Well I see, I know that kern.sync_on_panic exists to force a sync on a > panic but because my laptop usually does not core dump so never reboot > my disk are not sync'ed :-( it results in a file system not clean an > that's the thing I really hate. How often do you get panics? I've got more FreeBSD systems that have never panic()ed in their operational lifespan than I've seen FreeBSD boxes which did panic, but most of the systems I deal with tend to be rack-mounted boxes in controlled datacenter environments. Anyway, using a journaled filesystem would help. >>> Seriously, I really hate when I play some music that suddenly the >>> music get stucked in a infinite loop, why ? >> >> Probably a bug in the sound card driver. > > No no, it was a panic that didn't core dump so I needed to do a hard reboot. Frankly, audio isn't (or doesn't seem to be) a core goal of FreeBSD. Macs are probably the best reference platform available for pro A/V work. [1] >>> I don't know because the panic does not core dump. But after some search I >>> found that the panic >>> was done because of conky. How the hell conky can panic FreeBSD? We are in >>> 2011 ! I think even Window 2000 does not crash on a user-land software. >> >> "think"? If you don't have experience running Windows 2000 are thus are >> simply guessing, let me assure you that Win 2000 can and does (or did) panic >> due to userland software. > > In fact I like FreeBSD, and I don't expect running anything else. But > I must say that I didnt see windows 2000 crashing on my every boxes I > have before switching to FreeBSD. I didn't see Win2K crashing often, but certainly more often than once a year if the system was being used interactively. On the other hand, I did see a Win2K database server running the Sybase-derived SQLServer platform in a data center, comparable to what I mentioned above, with a year-plus uptime. Regards, -- -Chuck [1]: Not just my opinion-- people who are/were recording engineers at studios back in the mid 90's and early 2000s widely used Avid's ProTools on the Mac. More recently, the ready availability of consumer computing systems with the disk space and I/O bandwidth to do 12/18/more channel multitrack recording and editting in 24-bit by 48KHz or 96KHz has actually put a significant dent into pro studios, since people are doing a half-decent job of production work from their basement studio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Tue, Jan 11, 2011 at 15:11, David DEMELIER wrote: > Hello, > > I'm just guessing why current BSD panic() when a problem occurs, all > modern operating systems solve the problem instead of crashing > suddently and corrupting all your data without saving your work. > > Yes, why this function exists? There is no way to solve a problem > without panic'ing? Is panic really needed? Imagine someone working on > something really important and his computer just panic, his work not > saved everybody shout at him in the corporation. He lose his job, his > wife, his dog, everything is wrong, just because of a panic() ! > This feature ensures we have country music hits for the life of the operating system. Greg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
R: Recent mouse freeze problem with X, different window managers, any browser and flash.
>> >>For a week or so, with up to date, current, ports, etc. everytime I >>open a page that has automatic flash video my mouse freezes and I have >>to manually kill X and restart. I had worked fine for many months. >>Yesterday I rebuilt all linux emulation. All ports are up to date as >>of today. I have no idea where to look. >> >>Anyone else seen this or know where to look. >> >>thanks, >> > >>From what I can see, on CURRENT most of the flash objects are triggering a X >error. >I can see it on the console where I started X, but I don't remember it now. >I'll post il later. >Anyway Xorg is still working after that. > >Barbara I think that it could be related to this message: http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021997.html even if I'm on i386 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Tue, Jan 11, 2011 at 10:43 PM, Chuck Swiger wrote: > On Jan 11, 2011, at 1:11 PM, David DEMELIER wrote: >> 2011/1/11 Chuck Swiger : >>> [ ... ] Yes, why this function exists? There is no way to solve a problem without panic'ing? Is panic really needed? Seriously, I really hate when I play some music that suddenly the music get stucked in a infinite loop, why ? >>> >>> Probably a bug in the sound card driver. >> >> No no, it was a panic that didn't core dump so I needed to do a hard reboot. > > Frankly, audio isn't (or doesn't seem to be) a core goal of FreeBSD. Macs > are probably the best reference platform available for pro A/V work. [1] But the point here is still that a bug in a driver causes the whole system to hang or panic(). This is precisely the problem with monolithic systems. I know, I know, that's an old and tired discussion, but it is (still) a part of the problem. As far as I know, Windows NT is a microkernel arch, and faulty drivers, often provided by external vendors would not bring that system (as much as we hate or despise its Windows OS personality that runs on top of it) to a complete halt. Maybe we should also think about this in the context of BSD... especially considering the ever increasing amount of hardware and drivers. Something like a microkernelized and compartimentalized BSD on top of, say, L4Ka::Pistachio (which is itself BSD-licensed and which provides super-fast IPC, so performance won't take a major hit as it did with BSD on top of Mach, a.k.a. Mac OS X) would be a lot more robust w.r.t. to faults. Sure, not every error would be harmless, even on such a system, but it would be a long way towards a more robust and fault-tolerant OS. But again, this is a major undertaking, and talk about it is cheap... ;) -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
[Replies redirected.] Boris Kochergin writes: > All modern operating systems? Maybe some niche ones, like the ones > that run on Mars rovers, have made progress towards formal > verification and are believed not to crash given correctly-functioning > hardware. The Mars rovers run on VxWorks. Which is a system I like, but it isn't anything like formally verifiable. And it certainly does the equivalent of FreeBSD panic() under some circumstances. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On Tue, Jan 11, 2011 at 12:11 PM, David DEMELIER wrote: > Hello, > > I'm just guessing why current BSD panic() when a problem occurs, all > modern operating systems solve the problem instead of crashing > suddently and corrupting all your data without saving your work. > > Yes, why this function exists? There is no way to solve a problem > without panic'ing? Is panic really needed? Imagine someone working on > something really important and his computer just panic, his work not > saved everybody shout at him in the corporation. He lose his job, his > wife, his dog, everything is wrong, just because of a panic() ! > > Seriously, I really hate when I play some music that suddenly the > music get stucked in a infinite loop, why ? I don't know because the > panic does not core dump. But after some search I found that the panic > was done because of conky. How the hell conky can panic FreeBSD? We > are in 2011 ! I think even Window 2000 does not crash on a user-land > software. > > I'm guessing now, if minix panic when a bloated crappy software is > running. I think Andrew is in the right way. So I guess with that reasoning we don't need asserts, bugs never occur, and the if the computer catches on fire we should just let it burn up instead of getting an extinguisher and put it out :D? As an example: I would rather have my PC panic and not write out corrupt data to disk instead of write out that corrupt data to disk. The latter has happened with userland apps on occasion before they crash, and that really fries my bacon... Similarly, if we're beyond recovery, panicing is the best and only option, but yes... recovery could be handled better in some cases. Filesystems are a bit trickier though because they're more mission critical than say a non-critical device driver (my sound driver?) tanking. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: R: Recent mouse freeze problem with X, different window managers, any browser and flash.
On Tue, 11 Jan 2011 22:58:16 +0100 (CET) Barbara wrote: > > >> > >>For a week or so, with up to date, current, ports, etc. everytime > >I >open a page that has automatic flash video my mouse freezes and > >I have >to manually kill X and restart. I had worked fine for many > >months. >Yesterday I rebuilt all linux emulation. All ports are up > >to date as >of today. I have no idea where to look. > >> > >>Anyone else seen this or know where to look. > >> > >>thanks, > >> > > > >>From what I can see, on CURRENT most of the flash objects are > >triggering a > X > >error. > >I can see it on the console where I started X, but I don't remember > >it now. I'll post il later. > >Anyway Xorg is still working after that. > > > >Barbara > > I think that it could be related to this message: > http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021997.html > even if I'm on i386 > Try disabling mtrr, machdep.disable_mtrrs=0 through /boot/loader.conf. If that is the case, you probably want this: http://people.freebsd.org/~ariff/misc/mtrr.diff I'm CCing jkim@ (r215415) -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot * users :P ... Going with the standard and orthodox is the death of intellect .. pgpOwQJayg77e.pgp Description: PGP signature
R: Recent mouse freeze problem with X, different window managers, any browser and flash.
> >On Tue, 11 Jan 2011 22:58:16 +0100 (CET) >Barbara wrote: >> >> >> >> >>For a week or so, with up to date, current, ports, etc. everytime >> >I >open a page that has automatic flash video my mouse freezes and >> >I have >to manually kill X and restart. I had worked fine for many >> >months. >Yesterday I rebuilt all linux emulation. All ports are up >> >to date as >of today. I have no idea where to look. >> >> >> >>Anyone else seen this or know where to look. >> >> >> >>thanks, >> >> >> > >> >>From what I can see, on CURRENT most of the flash objects are >> >triggering a >> X >> >error. >> >I can see it on the console where I started X, but I don't remember >> >it now. I'll post il later. >> >Anyway Xorg is still working after that. >> > >> >Barbara >> >> I think that it could be related to this message: >> http://lists.freebsd.org/pipermail/freebsd-current/2010-December/021997. html >> even if I'm on i386 >> > >Try disabling mtrr, machdep.disable_mtrrs=0 through /boot/loader.conf. > >If that is the case, you probably want this: > >http://people.freebsd.org/~ariff/misc/mtrr.diff > > >I'm CCing jkim@ (r215415) > >-- >Ariff Abdullah >FreeBSD > I solved the problems after a make world. Previous one has been done on Dec. 26th. I'll describe better you what I was seeing: first I noticed that most flash objects were not working, and that when it was happening a crash in Xorg caused somehow by gdk-pixbuf2 were trapped. Then I tried to rebuild graphics/gdk-pixbuf2 but the build was failing and as far as I can remember it was somehow related to endian.h. A required port, devel/gmake was failing too. Then I tried to run portsnap and update the (few) outdated ports and there was an error rebuilding java/openjdk6. No all the problem are gone away. Summarizing it was similar, except that I'm on i386, to the one reported in the same discussion reported before, exactly here: http://lists.freebsd.org/pipermail/freebsd-current/2010-December/022021.html So, from what I can understand, I think that what you are suggesting is not needed for me. Do you think I am correct? What kind of problem should the setting for loader fix? In any case, thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
Am Tue, 11 Jan 2011 22:11:13 +0100 schrieb David DEMELIER : Hi David, I want to say something to the two statements below. > In fact I like FreeBSD, and I don't expect running anything else. But > I must say that I didnt see windows 2000 crashing on my every boxes I > have before switching to FreeBSD. From my experience, when FreeBSD crashes, it means mostly that you have some defective hardware. Last time when I had regular panics, it was a Xeon CPU that was broken and flipped some bits in its cache when it got a bit hotter. The point is... this kind of errors would never be discovered by MS-Windows. Because it appears to crash from various reasons and you never know if you have hardware problems or a programming error. Then it's also normal that applications on MS-Windows crash here and there. It's mostly ignored because the whole system is not stable. I've had also MS-Windows 2000 long time ago. And it ran on a PC where CPU had wrong frequency multiplicator setting (all the time!). No one complained when it crashed. But when I tried to run a Linux Live-CD on it, it panic'ed very soon (mostly when starting). I suspect that MS-Windows has a few routines which ignore errors and tries to continue... which is very bad, in my opinion! It is really annoying to hear people saying "MS-Windows runs and FreeBSD crashes", because it means to me that FreeBSD discovered another hardware error where MS-Windows failed. (Btw, I changed the CPU a year ago and now it works without panics. Also the wrong multiplicator was corrected and the AMD K5 CPU ran correctly.) > I understand everything, corrupts kernel data must not be used. That's > why panic are made to prevent any dangerous things. Yes. No one wants to lose data. I don't want to say that FreeBSD does not have programming errors. Of course, a panic might be triggered by an unknown situation in a driver. But you have to figure it out somehow, where the origins of the error are. And that's why a panic helps here. The kernel shows you the NEAREST POSSIBLE position where it detected that something went wrong. Panics are also good for diagnosis. But also, you want to get the errors in FreeBSD fixed. I learned that when I insert assertions (see assert(3)) and let my applications crash intentionally when it detects an error, paradoxically the applications have far less errors than the ones that try to run as far as possible. First thing is, as I said before, you discover the programming error NEAR the place it happened (easier to fix). Second, sometimes (after years) a developer forgets what assertions he made to restrict the usage of certain routines (special cases/values are the worst things here). It reminds the developer quickly when doing basic tests (regression tests e.g.). But as I said, I would say that FreeBSD does not panic often. Look first if it's a hardware error (and these PC-DOCTOR applications cannot really discover any problems, I can tell you for sure; also memcheckers do not find errors in memory except for some trivial cases). The best test is to try to compile world on FreeBSD. When a PC survives this, it's functioning well (very probable). Then, think if you use any exotic hardware on your system. Some drivers which are not very common, might not cover every vendor or are still not tested well, because there are not many people who use them. All in all, Panics are important. They show you problems, try to give hints what happened that lead to this situation and save you from subsequent data disasters, as others pointed out. -- Martin signature.asc Description: PGP signature
