Re: Build option survey for stable/8 r210741 (for nanobsd)
In message 2010085940.4...@unknown, Bruce Cran writes: On Sun, 22 Aug 2010 21:23:48 + Poul-Henning Kamp p...@phk.freebsd.dk wrote: http://phk/misc/build_options_stable_8_210741/ Did you mean http://phk.freebsd.dk/misc/build_options_stable_8_210741/ ? Yes, sorry, I was sleepy... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel MCA messages
on 23/08/2010 05:05 Dan Langille said the following: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 And another one: kernel: MCA: Bank 4, Status 0x9459c0014a080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff670 I believe that you get correctable RAM ECC errors, but not entirely sure. There is mcelog utility that decodes such messages into human-friendly descriptions. The utility is available on Linux-based systems. John Baldwin has a port of it to FreeBSD, but it seems to be WIP and is private so far. Wait and watch John posting decoded text in this thread :-) -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS performance question
On 08/20/10 12:30, Heinrich Rebehn wrote: I am somewhat concerned about the numbers for per-char-output and per-char-input. In fact, i have never before seen that low numbers in a bonnie test. Using a single disk with UFS yields about 6 times as much. BTW: Running OpenSolaris on the same hardware yields 110306 for per-char-write and 94698 for per-char-read. per-char stats are different between different operating systems because of how they are implemented. Apparently, bonnie++ forces full disk writes (fsyncs) for each byte written on BSDs, but Linux (and apparently Solaris) somehow manage to write-cache this (or at least - cache it much more). It only matters if you have software which depends on this caching and performs slowly otherwise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Watchdog not being disabled while dumping core
It was brought to my attention that on FreeBSD with a hardware watchdog in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's quite possible for the watchdog to fire (reboot the system) once the panic has happened. This issue basically inhibits the ability for a system with a hardware watchdog in place to be able to successfully complete doadump(). There's confirmations of this problem dating all the way back to 2005: PR kern/82219, opened in 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82219 PR bin/145183, opened in 2010 (not sure if this is the same): http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 Confirmation that the problem still exists today (first paragraph): http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058350.html On Linux, it appears that they've worked around this problem by using what's called a pretimeout (basically a way to get the watchdog to become delayed, thus not firing during important tasks): http://www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt According to watchdog(4), it looks like the kernel setting WD_PASSIVE immediately upon entering panic would solve the problem, but the BUGS section indicates WD_PASSIVE hasn't been implemented (returns ENOSYS). Thoughts on solving this dilemma? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Watchdog not being disabled while dumping core
In message 20100823103412.ga21...@icarus.home.lan, Jeremy Chadwick writes: It was brought to my attention that on FreeBSD with a hardware watchdog in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's quite possible for the watchdog to fire (reboot the system) once the panic has happened. This issue basically inhibits the ability for a system with a hardware watchdog in place to be able to successfully complete doadump(). The good news is that the watchdog hopefully gets your system back on the air, even if the dumping hangs. If it is decided to reset/disarm the watchdog before a dump, please make that a sysctl tunable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Watchdog not being disabled while dumping core
On Mon, Aug 23, 2010 at 3:34 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: PR bin/145183, opened in 2010 (not sure if this is the same): http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 Speaking for this I think we can do it by issuing an explicit watchdog(8) command on shutdown (like, set the timeout to several minutes) in /etc/rc.d/watchdog's shutdown section. This would be trivial to implement. Additionally, I'd personally think init(8) should be taught about watchdog facility. For panics, I think we should have the disk driver to pat watchdog rather than disabling it in their write success callback? Another thing is that ddb should be able to disable watchdog when it's waiting for keyboard input (or received first user input) I think. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Watchdog not being disabled while dumping core
on 23/08/2010 13:53 Poul-Henning Kamp said the following: In message 20100823103412.ga21...@icarus.home.lan, Jeremy Chadwick writes: It was brought to my attention that on FreeBSD with a hardware watchdog in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's quite possible for the watchdog to fire (reboot the system) once the panic has happened. This issue basically inhibits the ability for a system with a hardware watchdog in place to be able to successfully complete doadump(). The good news is that the watchdog hopefully gets your system back on the air, even if the dumping hangs. If it is decided to reset/disarm the watchdog before a dump, please make that a sysctl tunable. I'd rather add code to take over watchdog from watchdogd and to pat the dog while dumping, perhaps some other crucial places (like right before calling reset). This way we could ensure that system doesn't hang while dumping or in reset routine or etc. Another workaround is to set watchdog timeout large enough for dumping to complete, but that increases time that system is unavailable during a 'hard' hang (e.g. caused by hardware). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Watchdog not being disabled while dumping core
In message 4c725dfc.8000...@icyb.net.ua, Andriy Gapon writes: on 23/08/2010 13:53 Poul-Henning Kamp said the following: In message 20100823103412.ga21...@icarus.home.lan, Jeremy Chadwick writes: Another workaround is to set watchdog timeout large enough for dumping to complete, but that increases time that system is unavailable during a 'hard' hang (e.g. caused by hardware). You cannot trust the hardware to support such long timeouts. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel MCA messages
On Monday, August 23, 2010 2:44:38 am Andriy Gapon wrote: on 23/08/2010 05:05 Dan Langille said the following: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 And another one: kernel: MCA: Bank 4, Status 0x9459c0014a080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff670 I believe that you get correctable RAM ECC errors, but not entirely sure. There is mcelog utility that decodes such messages into human-friendly descriptions. The utility is available on Linux-based systems. John Baldwin has a port of it to FreeBSD, but it seems to be WIP and is private so far. Wait and watch John posting decoded text in this thread :-) It is not private, it is in //depot/projects/mcelog/... in p4. It is not a complete port yet though (doesn't support the daemon and client modes for example). Details for these errors: HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 7ff6b0 Northbridge RAM Chipkill ECC error Chipkill ECC syndrome = fe18 bit32 = err cpu0 bit46 = corrected ecc error bus error 'local node origin, request didn't time out generic read mem transaction memory access, level generic' STATUS 940c4001fe080813 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 5 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge ADDR 7ff670 Northbridge RAM Chipkill ECC error Chipkill ECC syndrome = 4ab3 bit32 = err cpu0 bit46 = corrected ecc error bus error 'local node origin, request didn't time out generic read mem transaction memory access, level generic' STATUS 9459c0014a080813 MCGSTATUS 0 MCGCAP 105 APICID 0 SOCKETID 0 CPUID Vendor AMD Family 15 Model 5 As Andriy guessed, I believe both of these are corrected ECC errors. You can likely ignore them as a low rate of corrected ECC errors is not unexpected. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange buildworld error (uuid_*)
On Friday, August 20, 2010 8:46:04 am Mikhail T. wrote: Hello! With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now boots nicely. I'd like to make another round of buildworld/buildkernel -- using the existing tools... That, however, breaks in the most unexpected place: Your libstand is too stale. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Watchdog not being disabled while dumping core
On Mon, Aug 23, 2010 at 04:07:47AM -0700, Xin LI wrote: On Mon, Aug 23, 2010 at 3:34 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: PR bin/145183, opened in 2010 (not sure if this is the same): http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/145183 Speaking for this I think we can do it by issuing an explicit watchdog(8) command on shutdown (like, set the timeout to several minutes) in /etc/rc.d/watchdog's shutdown section. This would be trivial to implement. No, it would not be trivial to implement (at least not if you want it to actually work correctly.) The reason for that is that at least some (perhaps even most) hardware watchdog devices do not support so long timeouts. I know for example that the watchdog in the ixp425 CPU has a maximum timeout of 65 seconds. Reading the manpage for ichwd(4) it seems that it has maximum timeout of about 37 seconds. I suspect that other hardware watchdogs have similar limits, which leads to the conclusion that one should not assume watchdog timeouts longer than maybe 30 seconds to be supported. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange buildworld error (uuid_*)
23.08.2010 08:17, John Baldwin написав(ла): With some trickery (had to define: WITHOUT_CDDL, WITHOUT_SSP, WITH_GCC3, NO_WERROR) I upgraded my laptop directly from 6.3 to 8.1-STABLE. It now boots nicely. I'd like to make another round of buildworld/buildkernel -- using the existing tools... That, however, breaks in the most unexpected place: Your libstand is too stale. The only libstand found on the computer (/usr/lib/libstand.a) is from August 19th -- the version built by FreeBSD-6's gcc-3 from FreeBSD-8.1's sources. According to nm, the library does define both uuid_equal and uuid_is_nil: m...@vaio:~ (106) nm /usr/lib/libstand.a | grep uuid uuid_equal.o: T uuid_equal U uuid_is_nil uuid_is_nil.o: T uuid_is_nil Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1R ZFS almost locking up system
On 2010-Aug-21 23:04:35 +0100, Tim Bishop t...@bishnet.net wrote: I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems that ZFS gets in to an almost unresponsive state. Last time it did it (two weeks ago) I couldn't even log in, although the system was up, this time I could manage a reboot but couldn't stop any applications (they were likely hanging on I/O). Unless you have a ZFS-only system, it's possible you are running out of free memory (see the free entry in top(1) or 'systat -v') - in which case r211581 (and r211599 which fixes a mismerge) should help. Your very high kstat.zfs.misc.arcstats.memory_throttle_count suggests this is your problem. I have a more extensive patch in http://www.freebsd.org/cgi/query-pr.cgi?pr=146410 -- Peter Jeremy pgpVn6Q2Ml3YY.pgp Description: PGP signature
Re: kernel MCA messages
On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of John Baldwin, and lo! it spake thus: It is not private, it is in //depot/projects/mcelog/... in p4. Which may as well be Siberia for us lowly non-developers. Any chance you could stick a tarball or a patch against upstream mcelog somewhere? -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1R ZFS almost locking up system
On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: In the last episode (Aug 21), Tim Bishop said: I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems that ZFS gets in to an almost unresponsive state. Last time it did it (two weeks ago) I couldn't even log in, although the system was up, this time I could manage a reboot but couldn't stop any applications (they were likely hanging on I/O). Could your pool be very close to full? Zfs will throttle itself when it's almost out of disk space. I know it's saved me from filling up my filesystems a couple times :) It's not close to full, so I don't think that's the issue. A few items from top, including zfskern: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 5 root4 -8- 0K60K zio-i 0 54:38 3.47% zfskern 91775 70 1 440 53040K 31144K tx-tx 1 2:11 0.00% postgres 39661 tdb 1 440 55776K 32968K tx-tx 0 0:39 0.00% mutt 14828 root1 470 14636K 1572K tx-tx 1 0:03 0.00% zfs 11188 root1 510 14636K 1572K tx-tx 0 0:03 0.00% zfs At some point during this process my zfs snapshots have been failing to complete: root5 0.8 0.0 060 ?? DL7Aug10 54:43.83 [zfskern] root 8265 0.0 0.0 14636 1528 ?? D10:00AM 0:03.12 zfs snapshot -r po...@2010-08-21_10:00:01--1d root11188 0.0 0.1 14636 1572 ?? D11:00AM 0:02.93 zfs snapshot -r po...@2010-08-21_11:00:01--1d root14828 0.0 0.1 14636 1572 ?? D12:00PM 0:03.04 zfs snapshot -r po...@2010-08-21_12:00:00--1d root17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs snapshot -r po...@2010-08-21_13:00:01--1d root20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs snapshot -r po...@2010-08-21_14:00:01--1d procstat -k on some of these processes might help to pinpoint what part of the zfs code they're all waiting in. I'll do that. Thanks for the pointer :-) Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel MCA messages
On 8/22/2010 10:05 PM, Dan Langille wrote: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 And another one: kernel: MCA: Bank 4, Status 0x9459c0014a080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff670 kernel: MCA: Bank 4, Status 0x947ec000d8080a13 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Responder RD Memory kernel: MCA: Address 0xbfa9930 Another one. These errors started appearing after upgrading to 8.1-STABLE from 7.2.. something. I suspect the functionality was added about then -- Dan Langille - http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1R ZFS almost locking up system
On Tue, Aug 24, 2010 at 06:49:23AM +1000, Peter Jeremy wrote: On 2010-Aug-21 23:04:35 +0100, Tim Bishop t...@bishnet.net wrote: I've had a problem on a FreeBSD 8.1R system for a few weeks. It seems that ZFS gets in to an almost unresponsive state. Last time it did it (two weeks ago) I couldn't even log in, although the system was up, this time I could manage a reboot but couldn't stop any applications (they were likely hanging on I/O). Unless you have a ZFS-only system, it's possible you are running out of free memory (see the free entry in top(1) or 'systat -v') - in which case r211581 (and r211599 which fixes a mismerge) should help. Your very high kstat.zfs.misc.arcstats.memory_throttle_count suggests this is your problem. Thanks. At the time I had a reasonable amount free (~450MB from 3GB), but it had dropped lower than that at some points previously. I'll take a closer look at that next time, and look at that patch (or upgrade to 8-STABLE). And the system has a UFS root, but all the apps/data are stored in ZFS. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel MCA messages
on 24/08/2010 02:43 Dan Langille said the following: On 8/22/2010 10:05 PM, Dan Langille wrote: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 And another one: kernel: MCA: Bank 4, Status 0x9459c0014a080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff670 kernel: MCA: Bank 4, Status 0x947ec000d8080a13 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Responder RD Memory kernel: MCA: Address 0xbfa9930 Another one. These errors started appearing after upgrading to 8.1-STABLE from 7.2.. something. I suspect the functionality was added about then Please strop the flood :-) Depending on hardware there could be hundreds of such errors per day. Either replace memory modules or learn to live with these messages. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: kernel MCA messages
On 8/23/2010 7:47 PM, Andriy Gapon wrote: on 24/08/2010 02:43 Dan Langille said the following: On 8/22/2010 10:05 PM, Dan Langille wrote: On 8/22/2010 9:18 PM, Dan Langille wrote: What does this mean? kernel: MCA: Bank 4, Status 0x940c4001fe080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff6b0 FreeBSD 7.3-STABLE #1: Sun Aug 22 23:16:43 And another one: kernel: MCA: Bank 4, Status 0x9459c0014a080813 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Source RD Memory kernel: MCA: Address 0x7ff670 kernel: MCA: Bank 4, Status 0x947ec000d8080a13 kernel: MCA: Global Cap 0x0105, Status 0x kernel: MCA: Vendor AuthenticAMD, ID 0xf5a, APIC ID 0 kernel: MCA: CPU 0 COR BUSLG Responder RD Memory kernel: MCA: Address 0xbfa9930 Another one. These errors started appearing after upgrading to 8.1-STABLE from 7.2.. something. I suspect the functionality was added about then Please strop the flood :-) Sure. Three emails is hardly a flood. :) Depending on hardware there could be hundreds of such errors per day. Either replace memory modules or learn to live with these messages. I was posting a remark anyone. Thought I'd include one more that I noticed. Surely you can cope. :) -- Dan Langille - http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
