Re: T7200 CPU not detected by est
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Baldwin wrote: > On Monday 21 January 2008 11:16:06 am Gerrit Kühn wrote: >> Hi folks, >> >> I have several systems using T7200 mobile CPUs running under 7-stable. >> However, EST does not recognize the cpus. When loading cpufreq I get: > > You can try this patch. It won't add support for all of the levels, but it > will support the current level and the highest level (IIRC). > It works now on my T7700: dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 dev.est.0.freq_settings: 2401/35000 2400/35000 2000/28000 1600/22000 1200/16000 dev.est.1.%desc: Enhanced SpeedStep Frequency Control dev.est.1.%driver: est dev.est.1.%parent: cpu1 dev.est.1.freq_settings: 2401/35000 2400/35000 2000/28000 1600/22000 1200/16000 Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHlu/8xJBWvpalMpkRAmhxAKCMmNwKs5Lc4VqfZV7h2kyoFhXovQCcDl8N /t5yK13dWc6XywqAWEDCjP8= =xpsg -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 RC1/SPARC64 panic in boot
Will apply the patch and reboot in an hour or two.
The isp interface is only used for an external array, so we disable it
and boot from internal drives on esp.
Thanks!
/Eirik
On Jan 23, 2008, at 7:32 AM, Scott Long wrote:
Eirik Øverby wrote:
On Jan 22, 2008, at 7:23 PM, Marius Strobl wrote:
On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote:
Hi list,
by disabling the isp driver (set hint.isp.o.disabled=1), the
system comes up. This of course denies us access to the external
disk array hosted by the internal QLogic controller, but
pinpoints the problem.
We tried setting hint.isp.0.prefer_iomap=1, which made no
difference (though by reading the code, I don't see that it ever
used this).
Can anyone help us out here?
Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36?
If that would be the case I'd be most happy to hear that. I'll also
be more than happy to test, and can do so on relatively short
notice (at least for another few hours).
We have, for the record, gone through some basic troubleshooting:
Replaced memory (as this error also can show up under Solaris and
is usually an indicator of bad memory), replaced SCSI controller
with another one (still isp driven), and testing various device
hints - suffice to say we have wasted our time so far ;)
Are you able to compile a new kernel without having to install first?
if so, apply the attached patch and let me know if it works.
Scott
Index: isp_sbus.c
===
RCS file: /usr1/ncvs/src/sys/dev/isp/isp_sbus.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- isp_sbus.c 11 May 2007 13:47:28 - 1.35
+++ isp_sbus.c 5 Nov 2007 11:22:18 - 1.36
@@ -29,7 +29,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/sys/dev/isp/isp_sbus.c,v 1.35 2007/05/11
13:47:28 mjacob Exp $");
+__FBSDID("$FreeBSD: src/sys/dev/isp/isp_sbus.c,v 1.36 2007/11/05
11:22:18 scottl Exp $");
#include
#include
@@ -327,21 +327,26 @@
/*
* Make sure we're in reset state.
*/
+ ISP_LOCK(isp);
isp_reset(isp);
if (isp->isp_state != ISP_RESETSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
isp_init(isp);
if (isp->isp_role != ISP_ROLE_NONE && isp->isp_state !=
ISP_INITSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
isp_attach(isp);
if (isp->isp_role != ISP_ROLE_NONE && isp->isp_state !=
ISP_RUNSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
+ ISP_UNLOCK(isp);
return (0);
bad:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Latest Stable FreeBSD release and is it supported on dell 2950
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 navneet Upadhyay wrote: > Hi , > I have following questions. > > 1. Which is the latest release of FreeBSD. > > 2. When was it released? > > 3. What is the patch level? > > 4.What is the stability > > 5. Which compiler to use: cc or gcc and which version . > > 6. Which platform/machine which BSD supports. Is Dell 2950 ok > All of your questions are answered at these sites: http://www.freebsd.org/ http://lists.freebsd.org/ Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHluU58Mjk52CukIwRCL94AJ9rgxCArKiCAJe8W9ld6F7weXIg+gCggHGz aykX31C3vaB/RQJmWF8qSOY= =Z9SC -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 RC1/SPARC64 panic in boot
Eirik Øverby wrote:
On Jan 22, 2008, at 7:23 PM, Marius Strobl wrote:
On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote:
Hi list,
by disabling the isp driver (set hint.isp.o.disabled=1), the system
comes up. This of course denies us access to the external disk array
hosted by the internal QLogic controller, but pinpoints the problem.
We tried setting hint.isp.0.prefer_iomap=1, which made no difference
(though by reading the code, I don't see that it ever used this).
Can anyone help us out here?
Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36?
If that would be the case I'd be most happy to hear that. I'll also be
more than happy to test, and can do so on relatively short notice (at
least for another few hours).
We have, for the record, gone through some basic troubleshooting:
Replaced memory (as this error also can show up under Solaris and is
usually an indicator of bad memory), replaced SCSI controller with
another one (still isp driven), and testing various device hints -
suffice to say we have wasted our time so far ;)
Are you able to compile a new kernel without having to install first?
if so, apply the attached patch and let me know if it works.
Scott
Index: isp_sbus.c
===
RCS file: /usr1/ncvs/src/sys/dev/isp/isp_sbus.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- isp_sbus.c 11 May 2007 13:47:28 - 1.35
+++ isp_sbus.c 5 Nov 2007 11:22:18 - 1.36
@@ -29,7 +29,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/sys/dev/isp/isp_sbus.c,v 1.35 2007/05/11 13:47:28
mjacob Exp $");
+__FBSDID("$FreeBSD: src/sys/dev/isp/isp_sbus.c,v 1.36 2007/11/05 11:22:18
scottl Exp $");
#include
#include
@@ -327,21 +327,26 @@
/*
* Make sure we're in reset state.
*/
+ ISP_LOCK(isp);
isp_reset(isp);
if (isp->isp_state != ISP_RESETSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
isp_init(isp);
if (isp->isp_role != ISP_ROLE_NONE && isp->isp_state != ISP_INITSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
isp_attach(isp);
if (isp->isp_role != ISP_ROLE_NONE && isp->isp_state != ISP_RUNSTATE) {
isp_uninit(isp);
+ ISP_UNLOCK(isp);
goto bad;
}
+ ISP_UNLOCK(isp);
return (0);
bad:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nscd again (nis client cache)
I wanted to say Thanks!!! for this example, because before this point I was under the impression that nscd/cached was of no use for NIS clients, only LDAP or maybe other directory systems that I don't use. I tried "cache compat" as below for passwd and group and it works! Our NIS entries at work are big enough that without the cache, top takes 7+ seconds to open, ssh login takes a few seconds, and samba logins were concerningly slow. I did not try samba connections, but the other methods are much faster now on the second run. Wanted to post this for the archive too. On Sat, Jan 19, 2008 at 02:17:11PM +0300, Michael Bushkov wrote: Hi Denis, Several things: 1. You definitely can't use cache for *_compat sources. I mean lines like "group_compat: cache nis" aren't supported. 2. Cache should work ok with the configuration you've mentioned in your first example, i.e.: "group: cache compat". Just checking - why do you think that cache isn't working? The correct way to determine it is to perform the same query twice. During the first pass (when query is not cached), the request will be processed by NIS module and you'll have all the NIS-related stuff in the logs. On the second pass the request should be handled by scd module - and you shouldn't see any activity in NIS logs. It would be great to see the debug log (with nscd log turned on) separately - for the first and the second pass. It would help to find the error in nscd, if there is one. With best regards, Michael Bushkov On Jan 17, 2008, at 9:55 PM, Denis Barov wrote: >> Hello! >> >> I found some strange behaviour of NIS/nscd when NIS in compat mode. In >> /etc/nsswitch.conf I have: >> >> netgroup: cache compat >> passwd: cache compat >> group:cache compat ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Latest Stable FreeBSD release and is it supported on dell 2950
Hi , I have following questions. 1. Which is the latest release of FreeBSD. 2. When was it released? 3. What is the patch level? 4.What is the stability 5. Which compiler to use: cc or gcc and which version . 6. Which platform/machine which BSD supports. Is Dell 2950 ok Thanks, Navneet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: bin/119884: Make sysinstall use the new Brazillian ntp servers
Hello, Is there any chance that this fix get comited before the release of 7.0? The Brazilian [correctly spelled now :-)] NTP servers currently used by sysinstall are not reliable. It would be much better to use the new ones that use the atomic clock at the Brazil's National Astronomic Observatory for time reference. -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: Jan 22, 2008 1:50 AM Subject: Re: bin/119884: Make sysinstall use the new Brazillian ntp servers To: "Carlos A. M. dos Santos" <[EMAIL PROTECTED]> Thank you very much for your problem report. It has the internal identification `bin/119884'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=119884 >Category: bin >Responsible:freebsd-bugs >Synopsis: Make sysinstall use the new Brazillian ntp servers >Arrival-Date: Tue Jan 22 03:50:02 UTC 2008 -- Carlos A. M. dos Santos -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, 22 Jan 2008 19:41:54 -0500
"Alexandre \"Sunny\" Kovalenko" <[EMAIL PROTECTED]> wrote:
> Am I right to assume that this is *not* i386? I have 7-PRERELEASE (i386)
> cvsup'ed on January 22, early morning EST, and mred built from vanilla
> 372 sources (per your earlier recommendation) on January 8th. They seem
> to be pretty happy with each other. If there is any information I can
> provide that will help you with your quest, please, let me know.
You're correct, I'm running an amd64 system, and it turns out
that a bunch of the garbage collection code is different/more
complicated in that case. And it contains a bug:
Found it, and fixed it. Works fine in my test-build at -O0, and
I'm just re-building at -O2 to make sure...
--- plt-372.orig/src/mzscheme/gc2/newgc.c 2007-10-08 21:40:43.0 +1
000
+++ plt-372/src/mzscheme/gc2/newgc.c2008-01-23 11:21:25.0 +1100
@@ -260,13 +260,13 @@ inline static struct mpage **create_page
pos = (unsigned long)p >> 48;
page_maps = page_mapss[pos];
if (!page_maps) {
-page_maps = (struct mpage ***)malloc(sizeof(struct mpage **) * (1 << 16));
+page_maps = (struct mpage ***)calloc(1 << 16, sizeof(struct mpage **));
page_mapss[pos] = page_maps;
}
pos = ((unsigned long)p >> 32) & ((1 << 16) - 1);
page_map = page_maps[pos];
if (!page_map) {
-page_map = (struct mpage **)malloc(sizeof(struct mpage *) * (1 <<
USEFUL_ADDR_BITS));
+page_map = (struct mpage **)calloc(1 << USEFUL_ADDR_BITS, sizeof(struct
mpage *));
page_maps[pos] = page_map;
}
return page_map;
In essence, it was using malloc to create second-tier page maps
on the fly, and assuming (incorrectly) that the memory returned
would be initialized to zero. What's mildly confusing, then,
is that the memory that it was getting here in the pre-Jan-5
version of the system *was* zero. Probably just luck. Let this
be a lesson: I should have turned on the malloc-debug knob in
the first instance.
I'll feed the patches (I've also made some tweaks to ensure that
it all compiles with -Werror-implicit-function-declaration,
because that's usually a good source of breakage on 64-bit
systems) up-stream, and see what happens. I'll add the new
patches to the port PR, too.
Thanks, everyone, for your patience with my red-herring reports.
--
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, 2008-01-22 at 21:10 +1100, Andrew Reilly wrote: > Hi Marius, > > On Tue, 22 Jan 2008 10:33:27 +0100 > Marius Strobl <[EMAIL PROTECTED]> wrote: > > > The __gthread_active_p(), which returns false positives prior > > to the current version of gthr-posix.h, isn't only used in > > libstdc++ but also in headers that are installed beneath > > /usr/include/c++. So the code in those headers compiled into > > an existing binary which was built prior to the gthr-posix.h > > fix still might erroneously determine that it's running in a > > threaded environment while f.e. libstdc++ does not, causing > > the problems you see. Did you try a mred built on a stock > > 7-STABLE? > > When it first stopped working (around the 11th, from memory), my > first approach was to rebuild it (over and over, and attempt to > debug it...) No joy that way. It's only since I reverted to > the earlier version of FreeBSD that it's started working again. > > As part of the attempt to make mred work again, I re-built > *all* of the ports that I have installed (some 900-odd), so > all of the libraries in /usr/local/lib are post-15 Jan., and > have whatever effect the change introduces. Perhaps that is > why epiphany has gone unstable on me (seems to be complaining > about failing to connect to gnomevfs). I suspect that mred > wasn't minding false-positives before, because it's been > configured/compiled with pthreads enabled (for the benefit of > Mesa/OpenGL, apparently). > > If you think that it might help to track things down, I can jump > forward to -STABLE again and rebuild at least all of mred's > dependencies, but that's going to be a slow process... > > Reckon I'll give that a go. No point staying in the past, now > that we know where abouts the breakage occurred. Am I right to assume that this is *not* i386? I have 7-PRERELEASE (i386) cvsup'ed on January 22, early morning EST, and mred built from vanilla 372 sources (per your earlier recommendation) on January 8th. They seem to be pretty happy with each other. If there is any information I can provide that will help you with your quest, please, let me know. > > Cheers, > -- Alexandre "Sunny" Kovalenko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS assert panic
Some updates on this... 'zpool import' shows the pool OK but when I try to actually import it, I get the aforementioned panic. Under BeleniX I cannot import it because it says the pool is corrupted. The (crash) problem also occurs with 7.0 beta 2. So I cannot access an otherwise healthy pool now. :-P Now I got to examine the logs too. Right before the pool becoming unaccessible, these log entries appeared: Jan 20 17:12:01 ginger kernel: vm_fault: pager read error, pid 1282 (rtorrent) Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad14 offset=23070008320 size=44032 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad12 offset=23070008320 size=44032 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad8 offset=23070008832 size=43520 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad10 offset=23070008832 size=43520 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad14 offset=23070008320 size=44032 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad12 offset=23070008320 size=44032 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad8 offset=23070008832 size=43520 Jan 20 17:12:01 ginger root: ZFS: checksum mismatch, zpool=tank path=/dev/ad10 offset=23070008832 size=43520 Jan 20 17:12:01 ginger root: ZFS: zpool I/O failure, zpool=tank error=86 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
On Monday 21 January 2008 11:16:06 am Gerrit Kühn wrote:
> Hi folks,
>
> I have several systems using T7200 mobile CPUs running under 7-stable.
> However, EST does not recognize the cpus. When loading cpufreq I get:
You can try this patch. It won't add support for all of the levels, but it
will support the current level and the highest level (IIRC).
Index: est.c
===
RCS file: /usr/cvs/src/sys/i386/cpufreq/est.c,v
retrieving revision 1.11
diff -u -r1.11 est.c
--- est.c 11 May 2006 17:35:44 - 1.11
+++ est.c 2 Oct 2007 18:04:58 -
@@ -38,6 +38,7 @@
#include
#include "cpufreq_if.h"
+#include
#include
#include
@@ -70,6 +71,7 @@
struct est_softc {
device_tdev;
int acpi_settings;
+ int msr_settings;
freq_info *freq_list;
};
@@ -897,6 +899,7 @@
static int est_get_info(device_t dev);
static int est_acpi_info(device_t dev, freq_info **freqs);
static int est_table_info(device_t dev, uint64_t msr, freq_info **freqs);
+static int est_msr_info(device_t dev, uint64_t msr, freq_info **freqs);
static freq_info *est_get_current(freq_info *freq_list);
static int est_settings(device_t dev, struct cf_setting *sets, int *count);
static int est_set(device_t dev, const struct cf_setting *set);
@@ -1031,11 +1034,13 @@
static int
est_detach(device_t dev)
{
+#if 0
struct est_softc *sc;
sc = device_get_softc(dev);
- if (sc->acpi_settings)
+ if (sc->acpi_settings || sc->msr_settings)
free(sc->freq_list, M_DEVBUF);
+#endif
return (ENXIO);
}
@@ -1059,6 +1064,9 @@
if (error)
error = est_acpi_info(dev, &sc->freq_list);
+ if (error)
+ error = est_msr_info(dev, msr, &sc->freq_list);
+
if (error) {
printf(
"est: CPU supports Enhanced Speedstep, but is not recognized.\n"
@@ -1149,6 +1157,77 @@
return (0);
}
+/*
+ * Flesh out a simple rate table containing the high and low frequencies
+ * based on the current clock speed and the upper 32 bits of the MSR.
+ */
+static int
+est_msr_info(device_t dev, uint64_t msr, freq_info **freqs)
+{
+ struct est_softc *sc;
+ freq_info *fp;
+ int bus, freq, volts;
+ uint16_t id;
+
+ if (strcmp("GenuineIntel", cpu_vendor) != 0)
+ return (EOPNOTSUPP);
+
+ /* Figure out the bus clock. */
+ freq = tsc_freq / 100;
+ id = msr >> 32;
+ bus = freq / (id >> 8);
+ device_printf(dev, "Guessed bus clock (high) of %d MHz\n", bus);
+ if (bus != 100 && bus != 133) {
+ /* We may be running on the low frequency. */
+ id = msr >> 48;
+ bus = freq / (id >> 8);
+ device_printf(dev, "Guessed bus clock (low) of %d MHz\n", bus);
+ if (bus != 100 && bus != 133)
+ return (EOPNOTSUPP);
+
+ /* Calculate high frequency. */
+ id = msr >> 32;
+ freq = ((id >> 8) & 0xff) * bus;
+ }
+
+ /* Fill out a new freq table containing just the high and low freqs. */
+ sc = device_get_softc(dev);
+ fp = malloc(sizeof(freq_info) * 3, M_DEVBUF, M_WAITOK | M_ZERO);
+
+ /* First, the high frequency. */
+ volts = id & 0xff;
+ if (volts != 0) {
+ volts <<= 4;
+ volts += 700;
+ }
+ fp[0].freq = freq;
+ fp[0].volts = volts;
+ fp[0].id16 = id;
+ fp[0].power = CPUFREQ_VAL_UNKNOWN;
+ device_printf(dev, "Guessed high setting of %d MHz @ %d Mv\n", freq,
+ volts);
+
+ /* Second, the low frequency. */
+ id = msr >> 48;
+ freq = ((id >> 8) & 0xff) * bus;
+ volts = id & 0xff;
+ if (volts != 0) {
+ volts <<= 4;
+ volts += 700;
+ }
+ fp[1].freq = freq;
+ fp[1].volts = volts;
+ fp[1].id16 = id;
+ fp[1].power = CPUFREQ_VAL_UNKNOWN;
+ device_printf(dev, "Guessed low setting of %d MHz @ %d Mv\n", freq,
+ volts);
+
+ /* Table is already terminated due to M_ZERO. */
+ sc->msr_settings = TRUE;
+ *freqs = fp;
+ return (0);
+}
+
static freq_info *
est_get_current(freq_info *freq_list)
{
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Monday 21 January 2008 08:00:33 am Pete French wrote: > > If you are using RSDT, then RsdtPhysicalAddress is what you care about > > rather than XsdtPhysicalAddress. > > O.K., I have this now - RsdtPhysicalAddress is 0x7fec7f40 on > return from madt_map_table Can you print out the table header length in the madt_map_table() routine? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, Jan 22, 2008 at 09:10:14PM +1100, Andrew Reilly wrote: > Hi Marius, > > On Tue, 22 Jan 2008 10:33:27 +0100 > Marius Strobl <[EMAIL PROTECTED]> wrote: > > > The __gthread_active_p(), which returns false positives prior > > to the current version of gthr-posix.h, isn't only used in > > libstdc++ but also in headers that are installed beneath > > /usr/include/c++. So the code in those headers compiled into > > an existing binary which was built prior to the gthr-posix.h > > fix still might erroneously determine that it's running in a > > threaded environment while f.e. libstdc++ does not, causing > > the problems you see. Did you try a mred built on a stock > > 7-STABLE? > > When it first stopped working (around the 11th, from memory), my > first approach was to rebuild it (over and over, and attempt to > debug it...) No joy that way. It's only since I reverted to > the earlier version of FreeBSD that it's started working again. > > As part of the attempt to make mred work again, I re-built > *all* of the ports that I have installed (some 900-odd), so > all of the libraries in /usr/local/lib are post-15 Jan., and > have whatever effect the change introduces. Perhaps that is > why epiphany has gone unstable on me (seems to be complaining > about failing to connect to gnomevfs). I suspect that mred > wasn't minding false-positives before, because it's been > configured/compiled with pthreads enabled (for the benefit of > Mesa/OpenGL, apparently). > Ok, in your previous mail you talked about an "exisiting binary" so I assumed you haden't tried with a recompiled one or a recompiled one didn't exhibit the problem. Anyway, you're right and I've overlooked that mred is threaded anyway so in this case it shouldn't matter if __gthread_active_p() prevously returned false-positives or not. The only way I currently can think of the new __gthread_active_p() causing problems would be if now it returned false-negatives. So far I can't reproduce such a problem nor see how that could happen though. It would help if you could debug where mred craches and what __gthread_active_p() returned in this case. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Portsnap update always says Ports tree is already up to date in 6.2
Jose Miguel Lopez Coronado wrote: Dear all. I have been trying to use portsnap update to update automatically the ports tree in a server running release 6.2, but I always receive the same message: 'Ports tree is already up to date' I know this is not true because I have other freeBSD 6.2 machines with newer ports. If I'm not wrong this have been happening since version 6.2 as release 6.1 did not give me these problems. I'm using 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 Any idea? portsnap fetch update? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Portsnap update always says Ports tree is already up to date in 6.2
Dear all. I have been trying to use portsnap update to update automatically the ports tree in a server running release 6.2, but I always receive the same message: 'Ports tree is already up to date' I know this is not true because I have other freeBSD 6.2 machines with newer ports. If I'm not wrong this have been happening since version 6.2 as release 6.1 did not give me these problems. I'm using 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 Any idea? Thanks in advance and best wishes. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-RC1 ath0 will not work for more than a couple days (Access Point)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The most recently committed re(4) modifications correct this. Hugo Silva wrote: > re0: discard frame w/o packet header re0: discard frame w/o packet > header re0: discard frame w/o packet header re0: discard frame w/o > packet header re0: discard frame w/o packet header re0: discard > frame w/o packet header re0: discard frame w/o packet header re0: > discard frame w/o packet header re0: discard frame w/o packet > header re0: discard frame w/o packet header re0: discard frame w/o > packet header re0: discard frame w/o packet header re0: discard > frame w/o packet header re0: discard frame w/o packet header re0: > discard frame w/o packet header re0: discard frame w/o packet > header re0: discard frame w/o packet header re0: discard frame w/o > packet header ath0: stuck beacon; resetting (bmiss count 4) ath0: > ath_reset: unable to reset hardware; hal status 3 ath0: stuck > beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset > hardware; hal status 3 ath0: device timeout ath0: stuck beacon; > resetting (bmiss count 4) ath0: ath_reset: unable to reset > hardware; hal status 3 ath0: device timeout ath0: stuck beacon; > resetting (bmiss count 4) ath0: ath_reset: unable to reset > hardware; hal status 3 ath0: device timeout ath0: stuck beacon; > resetting (bmiss count 4) ath0: ath_reset: unable to reset > hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count > 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: > stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to > reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss > count 4) ath0: ath_reset: unable to reset hardware; hal status 3 > ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: > unable to reset hardware; hal status 3 ath0: device timeout ath0: > stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to > reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss > count 4) ath0: ath_reset: unable to reset hardware; hal status 3 > > > > > > ath0: flags=8843 metric 0 > mtu 2290 inet 192.168.200.110 netmask 0xff00 broadcast > 192.168.200.255 media: IEEE 802.11 Wireless Ethernet autoselect > mode 11g status: associated ssid zaurak_wifi channel 5 > (2432 Mhz 11g) bssid authmode WPA2/802.11i privacy MIXED deftxkey 2 > TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan > bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 pureg > protmode CTS wme burst hidessid -apbridge dtimperiod 1 > > > > > FreeBSD zaurak.bsdlan.org 7.0-RC1 FreeBSD 7.0-RC1 #1: Wed Jan 2 > 01:45:03 WET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ZAURAK > amd64 > > > > [EMAIL PROTECTED]:5:1:0:class=0x02 card=0x5a001385 > chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros > Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g > Wireless Adapter' class = network subclass = ethernet > [EMAIL PROTECTED]:5:4:0: class=0x02 card=0x820d1043 chip=0x816710ec > rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = > 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network > subclass = ethernet > > > > > ifconfig'ing ath0 up and down continuously will either make it > usable again for a few hours or result in a panic. > > Regards, > > Hugo > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable To > unsubscribe, send any mail to > "[EMAIL PROTECTED]" > - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com "Free software != Free beer" Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHllsNQi2hk2LEXBARAobHAKDfiFNge8q3sst9Ia30GyTkSgy0FgCfbyq2 rcnrU+x+AGRhTjkl0It4h90= =ybea -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-RC1 ath0 will not work for more than a couple days (Access Point)
Aryeh M. Friedman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The most recently committed re(4) modifications correct this. Hugo Silva wrote: re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: flags=8843 metric 0 mtu 2290 inet 192.168.200.110 netmask 0xff00 broadcast 192.168.200.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid zaurak_wifi channel 5 (2432 Mhz 11g) bssid authmode WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 pureg protmode CTS wme burst hidessid -apbridge dtimperiod 1 FreeBSD zaurak.bsdlan.org 7.0-RC1 FreeBSD 7.0-RC1 #1: Wed Jan 2 01:45:03 WET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ZAURAK amd64 [EMAIL PROTECTED]:5:1:0:class=0x02 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet [EMAIL PROTECTED]:5:4:0: class=0x02 card=0x820d1043 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet ifconfig'ing ath0 up and down continuously will either make it usable again for a few hours or result in a panic. Regards, Hugo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" - -- Aryeh M. Friedman FloSoft Systems, Java Tool Developers Developer, not business, friendly http://www.flosoft-systems.com "Free software != Free beer" Blog: http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHllsNQi2hk2LEXBARAobHAKDfiFNge8q3sst9Ia30GyTkSgy0FgCfbyq2 rcnrU+x+AGRhTjkl0It4h90= =ybea -END PGP SIGNATURE- I will give it a try during this week -- thanks for the feedback. Regards, Hugo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0-RC1 ath0 will not work for more than a couple days (Access Point)
re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header re0: discard frame w/o packet header ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: device timeout ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: stuck beacon; resetting (bmiss count 4) ath0: ath_reset: unable to reset hardware; hal status 3 ath0: flags=8843 metric 0 mtu 2290 inet 192.168.200.110 netmask 0xff00 broadcast 192.168.200.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid zaurak_wifi channel 5 (2432 Mhz 11g) bssid authmode WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 pureg protmode CTS wme burst hidessid -apbridge dtimperiod 1 FreeBSD zaurak.bsdlan.org 7.0-RC1 FreeBSD 7.0-RC1 #1: Wed Jan 2 01:45:03 WET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ZAURAK amd64 [EMAIL PROTECTED]:5:1:0:class=0x02 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet [EMAIL PROTECTED]:5:4:0: class=0x02 card=0x820d1043 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet ifconfig'ing ath0 up and down continuously will either make it usable again for a few hours or result in a panic. Regards, Hugo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Manual/Wiki or other documentation for PXE install mainlyinstall.cfg?
On 21 Jan 2008, at 18:04, Drew Weaver wrote: Not specifically that I don’t know, more specifically that install.cfg doesn't know whether it’s a rl0, fxp0 or 3 or 4 others.. I have some stuff at http://ruben.is.verweg.com/stuff/freebsd/ ifrename/ that might help with this (and other cases, like the "swapped" ethernet ports of a Dell PE 2950) YMMV - Ruben PGP.sig Description: This is a digitally signed message part
Re: 7.0 RC1/SPARC64 panic in boot
On Jan 22, 2008, at 7:23 PM, Marius Strobl wrote:
On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote:
Hi list,
by disabling the isp driver (set hint.isp.o.disabled=1), the system
comes up. This of course denies us access to the external disk array
hosted by the internal QLogic controller, but pinpoints the problem.
We tried setting hint.isp.0.prefer_iomap=1, which made no difference
(though by reading the code, I don't see that it ever used this).
Can anyone help us out here?
Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36?
If that would be the case I'd be most happy to hear that. I'll also be
more than happy to test, and can do so on relatively short notice (at
least for another few hours).
We have, for the record, gone through some basic troubleshooting:
Replaced memory (as this error also can show up under Solaris and is
usually an indicator of bad memory), replaced SCSI controller with
another one (still isp driven), and testing various device hints -
suffice to say we have wasted our time so far ;)
Holding breath...
/Eirik
Marius
On Jan 21, 2008, at 11:23 AM, Anders Gulden Olstad wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SUN Ultra 2 (2x400Mhz USII, 1500MB RAM)
Got the following panic during boot
panic: trap: fast data access mmu miss
cpuid = 0
This happened after upgrade from 6.2 -> 7.0 RC1. Tried to boot
from the CDROM as well, with same result
=
=
=
=
=
=
=
=
=
=
=
=
Console log:
{0} ok boot cdrom
Boot device: /sbus/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],0:f File
and args:
FreeBSD/sparc64 boot block
Boot path: /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
PROTECTED],0:f
Boot loader: /boot/loader
Consoles: Open Firmware console
Booting with sun4u support.
Boot path set to /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
PROTECTED],0:a
FreeBSD/sparc64 bootstrap loader, Revision 1.0
([EMAIL PROTECTED], Mon Dec 24 10:09:43 UTC 2007)
bootpath="/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
PROTECTED],0:a"
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x6eee48+0x72c68
syms=[0x8+0x76878+0x8+0x6663e]
\
Hit [Enter] to boot immediately, or any other key for command
prompt.
Booting [/boot/kernel/kernel]...
nothing to autoload yet.
jumping to kernel entry at 0xc007.
stray vector interrupt 2033
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
1994
The Regents of the University of California. All rights
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-RC1 #0: Tue Dec 25 02:17:08 UTC 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
real memory = 1610612736 (1536 MB)
avail memory = 1550393344 (1478 MB)
cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
RF5413, REGOPS_FUNC)
nexus0:
sbus0: mem 0x1fe-0x1fe7fff irq
2036,2037,2038,2021,2026,2039 on nexus0
sbus0: clock 25.000 MHz
sbus dvma: DVMA map: 0xfc00 to 0x
sbus0: [GIANT-LOCKED]
sbus0: [ITHREAD]
sbus0: [GIANT-LOCKED]
sbus0: [ITHREAD]
initializing counter-timer
Timecounter "counter-timer" frequency 100 Hz quality 100
auxio0: mem 0x190 on sbus0
sbus0: mem 0xc00-0xc0001ff irq 2020 type unknown
(no
driver attached)
sbus0: mem 0-0x7,0x138-0x13f type unknown
(no
driver attached)
sbus0: mem 0x140-0x147 irq 2025 type block (no
driver attached)
eeprom0: mem 0x120-0x1201fff on sbus0
eeprom0: model mk48t59
scc0: mem 0x110-0x113 irq
2024 on
sbus0
scc0: [FILTER]
uart0: on scc0
uart0: [FILTER]
uart0: console (9600,n,8,1)
uart1: on scc0
uart1: [FILTER]
scc1: mem 0x100-0x103 irq
2024 on
sbus0
scc1: [FILTER]
uart2: on scc1
uart2: [FILTER]
uart2: keyboard (1200,n,8,1)
uart2: keyboard not present
uart3: on scc1
uart3: [FILTER]
sbus0: mem 0x130-0x137 type unknown (no driver
attached)
sbus0: mem 0x1304000-0x1304002 type unknown (no driver
attached)
esp0: mem
0x880-0x88f,0x881-0x881003f irq 2016 on sbus0
esp0: [ITHREAD]
esp0: FAS366/HME, 40MHz, SCSI ID 7
hme0: mem
0x8c0-0x8c00107,0x8c02000-0x8c03fff,0x8c04000-0x8c05fff,
0x8c06000-0x8c07fff,0x8c07000-0x8c0701f
irq 2017 on sbus0
miibus0: on hme0
nsphy0: PHY 1 on miibus0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
hme0: Ethernet address: 08:00:20:91:d2:79
hme0: [ITHREAD]
sbus
Re: 7.0 RC1/SPARC64 panic in boot
On Tue, Jan 22, 2008 at 07:16:16AM +0100, Eirik verby wrote:
> Hi list,
>
> by disabling the isp driver (set hint.isp.o.disabled=1), the system
> comes up. This of course denies us access to the external disk array
> hosted by the internal QLogic controller, but pinpoints the problem.
>
> We tried setting hint.isp.0.prefer_iomap=1, which made no difference
> (though by reading the code, I don't see that it ever used this).
>
> Can anyone help us out here?
Scott, could this be due to a missing MFC of isp_sbus.c rev. 1.36?
Marius
>
> On Jan 21, 2008, at 11:23 AM, Anders Gulden Olstad wrote:
>
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >SUN Ultra 2 (2x400Mhz USII, 1500MB RAM)
> >
> >Got the following panic during boot
> >
> > panic: trap: fast data access mmu miss
> > cpuid = 0
> >
> >This happened after upgrade from 6.2 -> 7.0 RC1. Tried to boot
> >from the CDROM as well, with same result
> >
> >
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >=
> >==
> >Console log:
> >
> >{0} ok boot cdrom
> >Boot device: /sbus/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],0:f
> >File and args:
> >
> >>>FreeBSD/sparc64 boot block
> > Boot path: /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
> > PROTECTED],0:f
> > Boot loader: /boot/loader
> >Consoles: Open Firmware console
> >
> >Booting with sun4u support.
> >Boot path set to /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
> >PROTECTED],0:a
> >
> >FreeBSD/sparc64 bootstrap loader, Revision 1.0
> >([EMAIL PROTECTED], Mon Dec 24 10:09:43 UTC 2007)
> >bootpath="/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
> >PROTECTED],0:a"
> >Loading /boot/defaults/loader.conf
> >/boot/kernel/kernel data=0x6eee48+0x72c68
> >syms=[0x8+0x76878+0x8+0x6663e]
> >\
> >Hit [Enter] to boot immediately, or any other key for command prompt.
> >Booting [/boot/kernel/kernel]...
> >nothing to autoload yet.
> >jumping to kernel entry at 0xc007.
> >stray vector interrupt 2033
> >Copyright (c) 1992-2007 The FreeBSD Project.
> >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
> >1994
> > The Regents of the University of California. All rights
> >reserved.
> >FreeBSD is a registered trademark of The FreeBSD Foundation.
> >FreeBSD 7.0-RC1 #0: Tue Dec 25 02:17:08 UTC 2007
> > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> >real memory = 1610612736 (1536 MB)
> >avail memory = 1550393344 (1478 MB)
> >cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
> >cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
> >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >registered firmware set
> >ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
> >RF5413, REGOPS_FUNC)
> >nexus0:
> >sbus0: mem 0x1fe-0x1fe7fff irq
> >2036,2037,2038,2021,2026,2039 on nexus0
> >sbus0: clock 25.000 MHz
> >sbus dvma: DVMA map: 0xfc00 to 0x
> >sbus0: [GIANT-LOCKED]
> >sbus0: [ITHREAD]
> >sbus0: [GIANT-LOCKED]
> >sbus0: [ITHREAD]
> >initializing counter-timer
> >Timecounter "counter-timer" frequency 100 Hz quality 100
> >auxio0: mem 0x190 on sbus0
> >sbus0: mem 0xc00-0xc0001ff irq 2020 type unknown (no
> >driver attached)
> >sbus0: mem 0-0x7,0x138-0x13f type unknown (no
> >driver attached)
> >sbus0: mem 0x140-0x147 irq 2025 type block (no
> >driver attached)
> >eeprom0: mem 0x120-0x1201fff on sbus0
> >eeprom0: model mk48t59
> >scc0: mem 0x110-0x113 irq
> >2024 on
> >sbus0
> >scc0: [FILTER]
> >uart0: on scc0
> >uart0: [FILTER]
> >uart0: console (9600,n,8,1)
> >uart1: on scc0
> >uart1: [FILTER]
> >scc1: mem 0x100-0x103 irq
> >2024 on
> >sbus0
> >scc1: [FILTER]
> >uart2: on scc1
> >uart2: [FILTER]
> >uart2: keyboard (1200,n,8,1)
> >uart2: keyboard not present
> >uart3: on scc1
> >uart3: [FILTER]
> >sbus0: mem 0x130-0x137 type unknown (no driver attached)
> >sbus0: mem 0x1304000-0x1304002 type unknown (no driver
> >attached)
> >esp0: mem
> >0x880-0x88f,0x881-0x881003f irq 2016 on sbus0
> >esp0: [ITHREAD]
> >esp0: FAS366/HME, 40MHz, SCSI ID 7
> >hme0: mem
> >0x8c0-0x8c00107,0x8c02000-0x8c03fff,0x8c04000-0x8c05fff,
> >0x8c06000-0x8c07fff,0x8c07000-0x8c0701f
> >irq 2017 on sbus0
> >miibus0: on hme0
> >nsphy0: PHY 1 on miibus0
> >nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> >hme0: Ethernet address: 08:00:20:91:d2:79
> >hme0: [ITHREAD]
> >sbus0: mem 0xc80-0xc80001b irq 2018 type unknown (no
> >driver attached)
> >isp0 mem 0x1-0x1044f irq 2003 on sbus0
> >isp0: [ITHR
Re: firefox-2.0.0.11_1, 1 refuses to build because PORT_REPLACES_BASE_BIND
On Tue, Jan 22, 2008 at 05:09:23PM +, Robert Jameson wrote: >I ran into a problem today trying to build the latest firefox in ports >firefox-2.0.0.11_1,1. ... >firefox-2.0.0.11_1,1: bind installed with PORT_REPLACES_BASE_BIND causes build >problems. That seems fairly self-explanatory to me and has been the case for over two years. (The relevant test is at the end of the "gecko-post-patch" target in www/mozilla/Makefile.common). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpszBCMFZxlD.pgp Description: PGP signature
Re: NO_ knobs in /etc/make.conf
On Jan 21, 2008, at 3:34 PM, Doug Barton wrote: There is a cross-reference to src.conf(5) at the end of make.conf(5), but IMO the connection needs to be made more explicit. Anyone want to take that on? This should also go in the release notes if it's not already. So do I need to move my settings from make.conf to src.conf, or can I just leave it as-is and not worry about it. Reading the make.conf man page implies it will just continue to work without change. What was broken that required this to be "fixed"? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
firefox-2.0.0.11_1, 1 refuses to build because PORT_REPLACES_BASE_BIND
I ran into a problem today trying to build the latest firefox in ports firefox-2.0.0.11_1,1. ===> Extracting for firefox-2.0.0.11_1,1 => MD5 Checksum OK for firefox-2.0.0.11-source.tar.bz2. => SHA256 Checksum OK for firefox-2.0.0.11-source.tar.bz2. ===> firefox-2.0.0.11_1,1 depends on file: /usr/local/bin/perl5.8.8 - found ===> Patching for firefox-2.0.0.11_1,1 ===> firefox-2.0.0.11_1,1 depends on file: /usr/local/bin/perl5.8.8 - found ===> Applying FreeBSD patches for firefox-2.0.0.11_1,1 firefox-2.0.0.11_1,1: bind installed with PORT_REPLACES_BASE_BIND causes build problems. *** Error code 1 ** Listing the failed packages (*:skipped / !:failed) ! www/firefox (firefox-2.0.0.11,1) (unknown build error) * x11/yelp (yelp-2.20.0) * www/epiphany (epiphany-2.20.3) * security/seahorse (seahorse-2.20.3) * x11/gnome2 (gnome2-2.20.2) ---> Packages processed: 1 done, 881 ignored, 4 skipped and 1 failed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Low NTFS read performance
I can't get an Ultrium-2 LTO drive to stream, and (I think) I've traced the problem to the read performance of the USB2-attached NTFS disk, and specifically the NTFS filesystem. I'm reading a single 190GB file, and the throughput I'm getting is 5.4MB/s: $ dd if=ad2c.dump of=/dev/null bs=1M ^Τ load: 0.04 cmd: dd 1434 [biord] 0.00u 4.78s 2% 1672k 610+0 records in 610+0 records out 639631360 bytes transferred in 117.937613 secs (5423472 bytes/sec) The is an old but relatively fast machine CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2407.18-MHz 686-class CPU) running 7.0-RC1: $ uname -a FreeBSD icarian.dmst.aueb.gr 7.0-RC1 FreeBSD 7.0-RC1 #0: Mon Dec 24 12:18:24 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 and the load during the read remains comfortably low: $ uptime 6:34PM up 3:50, 3 users, load averages: 0.09, 0.04, 0.04 Reading from the raw device tripples the performance: # dd if=/dev/da0s1 bs=1m of=/dev/null 533725184 bytes transferred in 34.777460 secs (15346871 bytes/sec) bringing it on par with what I get from Windows (on a different machine): F:\>dd if=other.20051007.tgz of=/dev/null bs=1M 1231030919 bytes (1.2 GB) copied, 82.845 s, 14.9 MB/s These are some (vaguely) relevant parts of dmesg: ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 0.95 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 5 ports with 5 removable, self powered [...] ad0: 76319MB at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA33 acd1: DVDR at ata1-slave UDMA33 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C) GEOM_LABEL: Label for provider da0s1 is ntfs/Backup. Trying to mount root from ufs:/dev/ad0s2a GEOM_LABEL: Label ntfs/Backup removed. GEOM_LABEL: Label for provider da0s1 is ntfs/Backup. I'd appreciate any suggestions you may have. Diomidis Spinellis - http://www.spinellis.gr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 RC1/SPARC64 panic in boot
Hi list,
by disabling the isp driver (set hint.isp.o.disabled=1), the system
comes up. This of course denies us access to the external disk array
hosted by the internal QLogic controller, but pinpoints the problem.
We tried setting hint.isp.0.prefer_iomap=1, which made no difference
(though by reading the code, I don't see that it ever used this).
Can anyone help us out here?
Thanks,
/Eirik
On Jan 21, 2008, at 11:23 AM, Anders Gulden Olstad wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SUN Ultra 2 (2x400Mhz USII, 1500MB RAM)
Got the following panic during boot
panic: trap: fast data access mmu miss
cpuid = 0
This happened after upgrade from 6.2 -> 7.0 RC1. Tried to boot
from the CDROM as well, with same result
=
=
=
=
=
=
=
=
=
=
==
Console log:
{0} ok boot cdrom
Boot device: /sbus/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],0:f File
and args:
FreeBSD/sparc64 boot block
Boot path: /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
PROTECTED],0:f
Boot loader: /boot/loader
Consoles: Open Firmware console
Booting with sun4u support.
Boot path set to /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
PROTECTED],0:a
FreeBSD/sparc64 bootstrap loader, Revision 1.0
([EMAIL PROTECTED], Mon Dec 24 10:09:43 UTC 2007)
bootpath="/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL
PROTECTED],0:a"
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x6eee48+0x72c68
syms=[0x8+0x76878+0x8+0x6663e]
\
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
nothing to autoload yet.
jumping to kernel entry at 0xc007.
stray vector interrupt 2033
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
1994
The Regents of the University of California. All rights
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-RC1 #0: Tue Dec 25 02:17:08 UTC 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
real memory = 1610612736 (1536 MB)
avail memory = 1550393344 (1478 MB)
cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
registered firmware set
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
RF5413, REGOPS_FUNC)
nexus0:
sbus0: mem 0x1fe-0x1fe7fff irq
2036,2037,2038,2021,2026,2039 on nexus0
sbus0: clock 25.000 MHz
sbus dvma: DVMA map: 0xfc00 to 0x
sbus0: [GIANT-LOCKED]
sbus0: [ITHREAD]
sbus0: [GIANT-LOCKED]
sbus0: [ITHREAD]
initializing counter-timer
Timecounter "counter-timer" frequency 100 Hz quality 100
auxio0: mem 0x190 on sbus0
sbus0: mem 0xc00-0xc0001ff irq 2020 type unknown (no
driver attached)
sbus0: mem 0-0x7,0x138-0x13f type unknown (no
driver attached)
sbus0: mem 0x140-0x147 irq 2025 type block (no
driver attached)
eeprom0: mem 0x120-0x1201fff on sbus0
eeprom0: model mk48t59
scc0: mem 0x110-0x113 irq
2024 on
sbus0
scc0: [FILTER]
uart0: on scc0
uart0: [FILTER]
uart0: console (9600,n,8,1)
uart1: on scc0
uart1: [FILTER]
scc1: mem 0x100-0x103 irq
2024 on
sbus0
scc1: [FILTER]
uart2: on scc1
uart2: [FILTER]
uart2: keyboard (1200,n,8,1)
uart2: keyboard not present
uart3: on scc1
uart3: [FILTER]
sbus0: mem 0x130-0x137 type unknown (no driver attached)
sbus0: mem 0x1304000-0x1304002 type unknown (no driver
attached)
esp0: mem
0x880-0x88f,0x881-0x881003f irq 2016 on sbus0
esp0: [ITHREAD]
esp0: FAS366/HME, 40MHz, SCSI ID 7
hme0: mem
0x8c0-0x8c00107,0x8c02000-0x8c03fff,0x8c04000-0x8c05fff,
0x8c06000-0x8c07fff,0x8c07000-0x8c0701f
irq 2017 on sbus0
miibus0: on hme0
nsphy0: PHY 1 on miibus0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
hme0: Ethernet address: 08:00:20:91:d2:79
hme0: [ITHREAD]
sbus0: mem 0xc80-0xc80001b irq 2018 type unknown (no
driver attached)
isp0 mem 0x1-0x1044f irq 2003 on sbus0
isp0: [ITHREAD]
panic: trap: fast data access mmu miss
cpuid = 0
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Resetting ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHlHKUMVyOPWVstbURAlkZAKC26W5268Q/+cJc6a3ImsqG8kvAIACfUFvP
mElTmJup2GOa5GCcVhOKXFs=
=7rUk
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
g_eli kernel panic on freshly updated 6.3-STABLE
Today i took the time to update 2 workstations to a fresh RELENG_6 build (6.3-STABLE) after they've been running on 6.2-STABLE for a long time. To my surprise both systems now exhibit a 100% repeatable kernel panic during boot directly after/during the initialisation of the GELI module. Console output shows GEOM_ELI: Device ad10se.eli created. GEOM_ELI: Encryption: AES-CBC-128 GEOM_ELI:Crypto: software kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf9 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0721420 stack pointer = 0x28:0xe771fc10 frame pointer = 0x28:0xe771fc18 code segment= base 0x0, limit 0x, type 0x11b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 44 (g_eli[1] ad10s1e trap number = 12 panic: page fault cpuid = 0 uptime = 1s Normally the first line on the console after the GEOM_ELI entries is Trying to mount root from ufs:/dev/ad12s1a I was lucky enough to be able to transplant a compatible (6.3-PRERELEASE) kernel from a system i had upgraded to a fresh RELENG_6 last friday to get these systems in a workable state again as the old 6.2-STABLE kernel turned out to no longer be compatible with the now 6.3 core userland (which was kinda to be expected). This does mean though that the change that seems to cause this instability must have made its way into RELENG_6 somewhere between friday January 18th (afternoon CET) and tuesday January 22nd (around 14:00 CET). Considering that a kernel built from fresh sources just before that timeframe seems to work as expected. Unfortunately i had to get these systems into a workable state ASAP again so i was unable do acquire a kernel dump. (Tried but the kernel kept insisting no dumpdevice to be defined). I hope the information may be useful regardless and would definitely appreciate to be kept in touch on any possible resolutions. With kind regards, -- Pascal Hofstee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot problems?
Torfinn Ingolfsen wrote: On Tue, 22 Jan 2008 11:00:36 +0200 Krassimir Slavchev <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I am trying to boot 7.0-PRERELEASE on my notebook from USB memory stick. With the original BTX i have "BTX halted". The only way to Not related to your problem, but I'm interested: - what is the size of the memory stick you are using? - how did you buold / install FreeBSD on it. Are there build instructions somewhere? May be you want to look at m0n0wall and FreeNAS documentation as they both are FreeBSD based and can boot from usb stick :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot problems?
On Tue, 22 Jan 2008 11:00:36 +0200 Krassimir Slavchev <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi All, > > I am trying to boot 7.0-PRERELEASE on my notebook from USB memory > stick. With the original BTX i have "BTX halted". The only way to Not related to your problem, but I'm interested: - what is the size of the memory stick you are using? - how did you buold / install FreeBSD on it. Are there build instructions somewhere? -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: coretemp(4) causes System to stall
At 09:01 AM 1/22/2008, Michael Schuh wrote: Hi @List, i have tryed out the new coretemp driver for Intel Core CPU's my cpu is an T2400 Intel Core (w/o Duo). i have csup'ed the stable build from cvsup.uk.freebsd.org at this night. then built the entire system via sources ( with ULE-Scheduler, might If you are running RELENG_6, I dont think ULE is recommended. If you want ULE, try going to RELENG_7. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
coretemp(4) causes System to stall
Hi @List, i have tryed out the new coretemp driver for Intel Core CPU's my cpu is an T2400 Intel Core (w/o Duo). i have csup'ed the stable build from cvsup.uk.freebsd.org at this night. then built the entire system via sources ( with ULE-Scheduler, might this causes the stall?) then load the coretemp.ko with kldload and try to quest the temperature with sysctl -a|grep temperature after this, i put coretemp_load="YES" to my /boot/loader.conf up to this point all things are very good ( and the new release seems to me faster then 6.2) now with an new buildworld with cd /usr/src; make -j 8 buildworld >& ~/fbsd/mw.out & and in another xterm a sysctl -a |grep temp causes the system stalls. this error ist reproducable many times. now i have tryed the sysctl -a|grep temp during an buildworld w/o the coretemp module loaded and the system runs stable. i hope this informations help to fix. regards michael -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
On Tue, 22 Jan 2008 05:47:25 -0800 Jeremy Chadwick <[EMAIL PROTECTED]> wrote about Re: T7200 CPU not detected by est: JC> And I can tell the system is significantly "slower" when idle, which is JC> normal. :-) JC> So give that a try... First of all, thank you very much for your work and your mail. Surprisingly (at least to me :-) everything seems to work as you said with the system on my desk here, which has a T7200 and FreeBSD 6.3-RC2. However, I know I already tried this with my system at home with a T7200 and FreeBSD 7.0-Beta4, and it crashed and rebooted when starting powerd. Just to make sure, I will try again and report about it when I am back at home. Meanwhile, I also opened a PR under #119895. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
On Tue, Jan 22, 2008 at 01:24:55AM -0800, Jeremy Chadwick wrote:
> I believe the problem is that our CPUs don't match any of the
> identification verification methods performed in
> src/sys/i386/cpufreq/est.c.
>
> I should be able to make a patch for this, but will need time -- our
> to-be-dev/test C2D box sits in my living room waiting for CPUs to arrive
> so it can be built. :-)
I've spent most of this evening poking at the code in question, as well
as looking at [too many] Intel specification documents for both the
Intel Core 2 Duo Desktop (E) and Mobile (T) processors.
Some technical details are below, followed by the "i'm a user not a
programmer" stuff.
The message "CPU supports Enhanced Speedstep, but is not recognized" is
indeed because the E6420 and the T7200 are not in the frequency tables
within src/sys/i386/cpufreq/est.c. It appears that est.c is actually
for the older Pentium M and VIA Centaur platforms -- particularly, those
which do not offer frequency tables via ACPI, and instead use some
hard-coded tables based on CPU manufacturer specifications.
However, within docs for the Intel C2D CPUs, the tables in question are
no where to be found. You can find lots of documentation describing
what all the VID bits do and what multiplication factor they break down
to (e.g. 1. = normal, 0.8250 = slower, 0.6000 = even slower, etc.)
but there's no pre-defined list of frequencies that I could find. This
frustrated me, so I took a look at what Linux did.
Seems they were in the same boat, and ended up doing essentialy what
FreeBSD has done: support SpeedStep on platforms which don't provide
frequency tables through ACPI ("speedstep-centrino") and instead require
fiddling of bits via MSR, and also support SpeedStep on platforms which
have frequency tables provided via ACPI. They combined both drivers
into a single driver, "speedstep-cpufreq", which prefers the ACPI method
but will restort to the old MSR method on platforms where available:
http://osdir.com/ml/kernel.cpufreq/2006-09/msg4.html
Further research into the FreeBSD side of things showed me that the
cpufreq(4) driver supports both the MSR method (via est.c) and the ACPI
method. This can be seen in the cpufreq(4) manpage; the MSR method is
"est" (which is what est.c is), and the ACPI method is "acpi_perf".
There's also "acpi_throttle", but I'm not sure what that is. cpufreq(4)
provides both some kernel API functions for twiddling of stuff, as well
as sysctl(8) knobs.
That said, I did a `sysctl -a | grep freq` on our E6420 system with EIST
enabled, and found the following relevant data:
dev.cpu.0.freq: 2117
dev.cpu.0.freq_levels: 2117/-1 1852/-1 1587/-1 1323/-1 1058/-1 793/-1 529/-1
264/-1
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
The dev.cpu.0.freq_levels values are CPU MHz/milliwatt; the -1 values
for milliwatt are missing, but this shouldn't impact things.
Since cpufreq(4) is what obtains these via ACPI (a la acpi_perf, I
assume), it's safe to say that cpufreq(4) will slow the system down if
one was to change dev.cpu.0.freq to one of the values shown in
freq_levels. I have some ideas as to why there's no dev.cpu.1.freq,
but my ideas are based on the older EIST stuff I've read tonight.
That said:
powerd(8) on FreeBSD will flip through all of the above MHz values,
depending upon how you tune it.
I use powerd(8) on my AMD Athlon 64 X2 system at home. I had to
enable the Cool'n'Quiet BIOS option, and then this showed up:
cpu0: on acpi0
powernow0: on cpu0
cpu1: on acpi0
powernow1: on cpu1
icarus# ps -aux | grep powerd
root 669 0.0 0.0 3140 832 ?? Ss Thu06am 0:16.23
/usr/sbin/powerd -p 2000
And the sysctl values:
dev.cpu.0.freq: 1005
dev.cpu.0.freq_levels: 2010/89000 1809/84600 1005/40100
dev.powernow.0.freq_settings: 2010/89000 1809/84600 1005/40100
dev.powernow.1.freq_settings: 2010/89000 1809/84600 1005/40100
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1
Interesting thing here is that there's dev.powernow.[0].freq_settings
while on the E6420 box there's only the 0 index.
Anyway, I decided to run powerd on the EIST box to see what happened:
# ps -auxw | grep powerd
root25602 0.0 0.0 3120 820 ?? Ss5:43AM 0:00.00
/usr/sbin/powerd -p 2000
root25604 0.0 0.0 1588 780 p1 R+5:43AM 0:00.00 grep powerd
# sysctl -a | egrep 'dev.*freq:|freq_levels:'
dev.cpu.0.freq: 1323
dev.cpu.0.freq_levels: 2117/-1 1852/-1 1587/-1 1323/-1 1058/-1 793/-1 529/-1
264/-1
# sysctl -a | egrep 'dev.*freq:|freq_levels:'
dev.cpu.0.freq: 264
dev.cpu.0.freq_levels: 2117/-1 1852/-1 1587/-1 1323/-1 1058/-1 793/-1 529/-1
264/-1
And I can tell the system is significantly "slower" when idle, which is
normal. :-)
So give that a try...
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking
Re: 6.3-RELEASE panic
Petr Holub wrote: I tried to build it from the sources that come from the freebsd-update and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was unable to run gdb with the given vmcore against such a kernel. How do you did that? Try the following commands: # cd /usr/src/ # make buildkernel # cd /var/crash # gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug ./vmcore.0 |tee bt.txt (gdb) bt (gdb) bt full (gdb) q and show your /var/crash/bt.txt file. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 6.3-RELEASE panic
> > I thought we shipped the debugging symbols in /boot precisely for the > > reason of making panics with default installs not report useless traces :( > > I think building GENERIC kernel from sources with > tag=RELENG_6_3_0_RELEASE will help. I tried to build it from the sources that come from the freebsd-update and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was unable to run gdb with the given vmcore against such a kernel. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, Jan 22, 2008 at 09:44:05AM +1100, Andrew Reilly wrote: > Hello again, > > [to recap: drscheme, (which is an IDE that runs under the "mred" > runtime, built from ports/lang/drscheme (or actually manually > from a personal copy of that Makefile that builds the current > release: 372, rather than ver 370 in ports)) worked beautifully > on my system until I updated to 7-STABLE after 4 Jan. I track > -STABLE every week or two. After that, it segfaults before > printing or displaying anything, and running under gdb has found > that it stops in the garbage collector initialization. I > haven't raised a PR for this yet because I still think that the > problem is probably the drscheme FreeBSD configuration that has > bit-rotted a little, now that FreeBSD has changed slightly. > Still investigating... I've cc'd Joseph Koshy, because this > seems to be somehow related to PR ports/118808.] > > I've done the binary search through CVS, and established that > the precise file and revision that is causing me (or rather, > drscheme) grief: src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1 marius > at 5 Jan 22:58.51. Csupping back to 5 Jan 22:50 is enough to > make everyting happy again. > > Unfortunately, I'm at a loss to explain how this change could be > causing an existing binary to run or not, because it changes the > compiler. Well, presumably it changes the installed libc.so and > libstdc++.so, both of which are linked in at run-time (c++ is used > in mred/drscheme for the wxWidgets GUI). Indeed, the most recent > time that I backed this revision of gthr-posix.h out (regressed > to 5 Jan 22:50), drscheme started to work as soon as the system > libraries had been installed, before I had rebooted. The __gthread_active_p(), which returns false positives prior to the current version of gthr-posix.h, isn't only used in libstdc++ but also in headers that are installed beneath /usr/include/c++. So the code in those headers compiled into an existing binary which was built prior to the gthr-posix.h fix still might erroneously determine that it's running in a threaded environment while f.e. libstdc++ does not, causing the problems you see. Did you try a mred built on a stock 7-STABLE? > > Since there hasn't been any other wailing about incompatability > since this change, my guess is that mred was somehow working > around the previous FreeBSD behaviour: it has quite a bit of > low-level platform-specific configuration, since it is a > language runtime. The ideal solution will be to figure out how > to tweak it's FreeBSD compatability to suit the new operation. > If anyone can offer a hint as to which area I should be looking > at for configuration knobs, I'd be really grateful. > Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
Hi Marius, On Tue, 22 Jan 2008 10:33:27 +0100 Marius Strobl <[EMAIL PROTECTED]> wrote: > The __gthread_active_p(), which returns false positives prior > to the current version of gthr-posix.h, isn't only used in > libstdc++ but also in headers that are installed beneath > /usr/include/c++. So the code in those headers compiled into > an existing binary which was built prior to the gthr-posix.h > fix still might erroneously determine that it's running in a > threaded environment while f.e. libstdc++ does not, causing > the problems you see. Did you try a mred built on a stock > 7-STABLE? When it first stopped working (around the 11th, from memory), my first approach was to rebuild it (over and over, and attempt to debug it...) No joy that way. It's only since I reverted to the earlier version of FreeBSD that it's started working again. As part of the attempt to make mred work again, I re-built *all* of the ports that I have installed (some 900-odd), so all of the libraries in /usr/local/lib are post-15 Jan., and have whatever effect the change introduces. Perhaps that is why epiphany has gone unstable on me (seems to be complaining about failing to connect to gnomevfs). I suspect that mred wasn't minding false-positives before, because it's been configured/compiled with pthreads enabled (for the benefit of Mesa/OpenGL, apparently). If you think that it might help to track things down, I can jump forward to -STABLE again and rebuild at least all of mred's dependencies, but that's going to be a slow process... Reckon I'll give that a go. No point staying in the past, now that we know where abouts the breakage occurred. Cheers, -- Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
On Tue, Jan 22, 2008 at 09:47:56AM +0100, Gerrit Kühn wrote: > Ok, so it's probably neither specific for CPUs nor for the mainbaords; > however, up to now all CPUs with this problem are Core2 CPUs. > > JC> In the case of our servers, we usually turn EIST off (this one > JC> particular box has it enabled) because of the above problem -- but I'd > JC> much rather have it turned on to help save power. For a laptop or > JC> workstation, however, I can see this being an incredibly important > JC> feature. > > I run low power workstations here which are intended to be used in a lab > environment, and I would very much like to have working power-saving > features (otherwise the whole setup is quite useless). > > Can I somehow help debugging this, should I file a PR or are there any > further recommended things to do? I believe the problem is that our CPUs don't match any of the identification verification methods performed in src/sys/i386/cpufreq/est.c. I should be able to make a patch for this, but will need time -- our to-be-dev/test C2D box sits in my living room waiting for CPUs to arrive so it can be built. :-) If you'd like to file a PR in the meantime, that'd be great too; let me know what the PR # is. -- | Jeremy Chadwickjdc at 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 "[EMAIL PROTECTED]"
boot problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I am trying to boot 7.0-PRERELEASE on my notebook from USB memory stick. With the original BTX i have "BTX halted". The only way to boot was using: http://people.freebsd.org/~kib/realbtx/realbtx.2.patch With this patch the kernel is loaded but something remains wrong: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic = 00 fault virtual address = 0xbff1e000 fault code = supervisor write, page not found instruction pointer = 0x20:0xc0a892df stack pointer = 0x28:0xc5820cf4 frame pointer = 0x28:0xc5820d0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 () [thread pid 0 tid 0] Stopped at pmap_map+0x3f: movl%eax,PTmap(,%edx,4) db>bt Tracing pid 0 tid 0 td 0xc0c2b210 pmap_pmap(c5820d64, 7da85000,7fe8,3,c5c45000,...) at pmap_map+0x3f vm_page_startup(c5c86000,a,c5820d88,c0725716,0,...) at vm_page_startup+0x224 vm_mem_init(0,581ec00,581e000,581e000,5828000,...) at vm_mem_init+0x18 begin() at begin+0x2c db> I have seen similar panic with the original BTX on a dual core machine when tried to boot from USB. Any ideas what may cause this? Thanks in advance -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHlbC0xJBWvpalMpkRAi1NAJ0afhUsYXiJjqNZXwgc9SCCoF9bZQCgmXMO qTNxlm1qe8jZ9WUnXAJ5atk= =TaWD -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: T7200 CPU not detected by est
On Mon, 21 Jan 2008 09:01:02 -0800 Jeremy Chadwick <[EMAIL PROTECTED]> wrote about Re: T7200 CPU not detected by est: JC> > Jan 18 23:18:14 comet kernel: est1: > Control> on cpu1 Jan 18 23:18:14 comet kernel: est: CPU supports JC> > Control> Enhanced Speedstep, but is not recognized. JC> > Jan 18 23:18:14 comet kernel: est: cpu_vendor GenuineIntel, msr JC> > 6130c2906000c29 Jan 18 23:18:14 comet kernel: device_attach: est1 JC> > attach returned 6 JC> I see identical behaviour on our Supermicro PDSMI+ systems, using E6420 JC> CPUs, so I don't believe the problem is specific to your motherboard or JC> certain Intel CPU models: It is definitely not bound to certain mainboards, because I see it on several different ones. However, I have only T-series CPUs to test. JC> CPU: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz (2128.01-MHz JC> 686-class CPU) acpi0: on motherboard JC> acpi0: [ITHREAD] JC> acpi0: Power Button (fixed) JC> cpu0: on acpi0 JC> est0: on cpu0 JC> est: CPU supports Enhanced Speedstep, but is not recognized. JC> est: cpu_vendor GenuineIntel, msr 82a082a0600082a JC> device_attach: est0 attach returned 6 JC> cpu1: on acpi0 JC> est1: on cpu1 JC> est: CPU supports Enhanced Speedstep, but is not recognized. JC> est: cpu_vendor GenuineIntel, msr 82a082a0600082a JC> device_attach: est1 attach returned 6 Ok, so it's probably neither specific for CPUs nor for the mainbaords; however, up to now all CPUs with this problem are Core2 CPUs. JC> In the case of our servers, we usually turn EIST off (this one JC> particular box has it enabled) because of the above problem -- but I'd JC> much rather have it turned on to help save power. For a laptop or JC> workstation, however, I can see this being an incredibly important JC> feature. I run low power workstations here which are intended to be used in a lab environment, and I would very much like to have working power-saving features (otherwise the whole setup is quite useless). Can I somehow help debugging this, should I file a PR or are there any further recommended things to do? cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Big geli proglem: MD5 hash checksum mismatch for da0
Hello, I tried to change my passphrase for a geli provider. Like man page tells, I attached the provider (da0) and used 'geli setkey da0' to change the key (only one key, no keyfile used). Everything seemd to work but after detaching any attach attempt fails with: MD5 hash checksum mismatch for da0 What went wrong? And how can I solve it? Needless to say that it's important data and I really don't hope that geli was corrupting it! Thanks, -Harry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
geli problem: MD5 hash checksum mismatch for da0
Hello, I tried to change my passphrase for a geli provider. Like man page tells, I attached the provider (da0) and used 'geli setkey da0' to change the key (only one key, no keyfile used). Everything seemd to work but after detaching any attach attempt fails with: MD5 hash checksum mismatch for da0 What went wrong? And how can I solve it? Needless to say that it's important data and I really don't hope that geli was corrupting it! Thanks, -Harry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Kris Kennaway wrote: I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( I think building GENERIC kernel from sources with tag=RELENG_6_3_0_RELEASE will help. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
