Re: Old /etc files back, or cvs error?
On Monday 23 February 2009 10:11:45 pm Warren Block wrote: Lately I've installed a couple of test systems from 7.1-RELEASE CDs, then csupped to RELENG_7 from cvsup9: *default host=cvsup9.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_7 *default delete use-rel-suffix mergemaster adds a *lot* of old files in /etc that were not there in 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a bunch of bluetooth files and /etc/isdn/*. The version numbers and dates in mergemaster look wrong. For example, /etc/bluetooth/hcsecd.conf: # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax Exp $ Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? The latest entries for files in /etc/isdn are 9 months old, and were removals. This looks like an error, but maybe I'm missing something. And other cvsup mirrors seem to agree with cvsup9. You are looking at the version for the 7.1 release version. The RELENG_7 version is Revision 1.3: download - view: text, markup, annotated - select for diffs Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0, RELENG_7, HEAD Branch point for: RELENG_7_1 Diff to: previous 1.2: preferred, colored Changes since revision 1.2: +1 -1 lines Go to http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/bluetooth/hcsecd.conf and you can see the versions and the tags. Kent -- kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ 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
E7400 Speedstep support?
Hi, I recently got a new Intel E7400 based system and dmesg reports.. est0: Enhanced SpeedStep Frequency Control on cpu0 est0: Guessed bus clock (high) of 37 MHz est0: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est1: Guessed bus clock (high) of 37 MHz est1: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 I'm running 7.1-STABLE and I was wondering how hard it is to add support for est for this CPU? Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Intel Q45 problems on 7.1-STABLE (fixed)
On Monday 23 February 2009 12:00:30 Daniel O'Connor wrote: Initially it hung solid when X started, however when I reduced the amount of RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the text console and back to X then the machine locks solid (no numlock, have to hard reset). I note that dmesg reports 32764k of stolen memory, however I set the DVMT RAM to 128Mb (and 256Mb, makes no difference). Also the aperture size is always reported as 256Mb no matter what it actually is in the BIOS. Someone in a private email suggested I update the BIOS (went from 63 to 73) and it seems to work fine now. The reported value of stolen memory is still wrong however. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Cleaning unused libraries and rebuilding dependent ones?
Hi all,
I'm sure that these questions have been asked before, however, a quick
search of forums on the Web didn't turn up any obvious answers.
I currently use portupgrade on all my FreeBSD installations, however, I
have noticed over time that a fair amount of detritus can build up in
${PREFIX}/lib/compat/pkg. So my questions are:-
1. Is there a tool like Gentoo's revdep-rebuild to force packages
depending on packaged libraries to be rebuilt?
2. Is there a more complete tool to clean orphaned libraries like
'portsclean -L' used to do?
Whilst I greatly appreciate the hard work and effort which the FreeBSD
ports maintainers put in to ensure shared library versions get bumped
when needed, this isn't always possible, as it requires keeping a sharp
eye out for 3rd party software packages which do the wrong thing, and
don't bump the major(s) when significant semantic changes happen inside
their libraries, or when the ABI changes.
[1] revdep-rebuild has very similar semantics to what I'm looking for,
as it will navigate the dependency graph for all packages installed on
the system, and rebuild packages where dependent libraries have changed.
To do the same with portupgrade alone, I need to know which port(s)
contain shared libraries, and tell it to go off and rebuild these
*specific* packages if things change.
[2] 'portsclean -L' used to do something :-) it does not appear to do
anything now.
I realize I could use libchk to discover which libraries are
unreferenced at load-time, however, a fair number of the libraries which
portupgrade moves into ${PREFIX}/lib/compat/pkg can potentially be
loaded by dlopen() at run-time.
Using libchk's output to remove unreferenced libraries isn't really an
option without significant post-processing of its output.
I would rather not rely on 'portupgrade -f -a -r', as this is going to
cause a *lot* of work on the affected systems.
Thanks for any help!
BMS
___
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: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
I tried using my ath based D-Link DWL G650, which still seems to have some issues in regard to interrupt handling: I've been able to get /most/ wireless cards working with ndiswrapper. --- Kevin www.stardothosting.com/linux-vps-hosting ___ 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: Cleaning unused libraries and rebuilding dependent ones?
On 2/24/2009 9:06 AM, Bruce Simpson wrote: Hi all, [1] revdep-rebuild has very similar semantics to what I'm looking for, as it will navigate the dependency graph for all packages installed on the system, and rebuild packages where dependent libraries have changed. To do the same with portupgrade alone, I need to know which port(s) contain shared libraries, and tell it to go off and rebuild these *specific* packages if things change. I don't think revdep-rebuild works as cleanly as you think. Technically, revdep-rebuild only locates packages that are *already broken* due to missing shared libraries, and rebuilds them. What revdep-rebuild does is literally run ldd on every executable file in the search path, grep for either not found or a specific library name, then assign each broken binary to a package name for portage to rebuild. This is exactly what libchk also does, so the effect would be the same. Specifically, revdep-rebuild also won't pick up missing dlopen() libs and such. The semantics you're talking about sounds like the new @preserved-libs set that's in the upcoming portage, but in order for that to work it has to be maintained at the time of library update: as a shared lib is moved into the compat folder, record any packages that depend on the previously installed package into a set for later rebuilding. --K ___ 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: Intel Q45 problems on 7.1-STABLE (fixed)
On Tue, 2009-02-24 at 21:05 +1030, Daniel O'Connor wrote: On Monday 23 February 2009 12:00:30 Daniel O'Connor wrote: Initially it hung solid when X started, however when I reduced the amount of RAM to 2Gb it worked OK. Unfortunately if I exit X, or go to the text console and back to X then the machine locks solid (no numlock, have to hard reset). I note that dmesg reports 32764k of stolen memory, however I set the DVMT RAM to 128Mb (and 256Mb, makes no difference). Also the aperture size is always reported as 256Mb no matter what it actually is in the BIOS. Someone in a private email suggested I update the BIOS (went from 63 to 73) and it seems to work fine now. The reported value of stolen memory is still wrong however. Hrm, I wonder if I have missed an MFC... Please send me some logs and additional details. Your -STABLE is current right? robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: E7400 Speedstep support?
2009/2/24 Daniel O'Connor docon...@gsoft.com.au: Hi, I recently got a new Intel E7400 based system and dmesg reports.. est0: Enhanced SpeedStep Frequency Control on cpu0 est0: Guessed bus clock (high) of 37 MHz est0: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 est1: Guessed bus clock (high) of 37 MHz est1: Guessed bus clock (low) of 466 MHz est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6164a2206004a22 device_attach: est1 attach returned 6 p4tcc1: CPU Frequency Thermal Control on cpu1 I'm running 7.1-STABLE and I was wondering how hard it is to add support for est for this CPU? May those error messages be BIOS related? From my E7200 (well, this is from -current): cpu0: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - CF, should be C6 [20070320] est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 dev.cpu has also expected values. -- wbr, pluknet ___ 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: Big problems with 7.1 locking up :-(
On Mon, 23 Feb 2009, aneeth wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=130652cat= OK, will give this a try, unless anyone else wants any traces from this locked machine ? Is there a known way to tickle this bug when I've rebooted, to make sure it's fixed ? We'v been having similar issues with a couple of our servers as well (7.0 and 7.1). However the problem shows up only on quad core machines. The dual core machines r running fine. FYI, I'm currently awaiting testing results from Pete on the MFC of a number of routing table locking fixes, and once that's merged (hopefully tomorrow?) I'll start on the patches in the above PR. I've taken a crash-course in routing table locking in the last few days... :-) The patches I sent him are at: http://www.watson.org/~robert/freebsd/20090221-route-locking.diff They do not include the patch from the above PR which I want to handle separately as it's a significantly different issue. Robert N M Watson Computer Laboratory University of Cambridge ___ 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
7.1 hangs in cache_lookup mutex?
I think I may have found a clue regarding some of the hangs I'm seeing
on FreeBSD 7.1.
I have a program (kvoop), compiled under FreeBSD 6 and using
compatibility libraries under FreeBSD 7, that seems to be consistently
involved during these hangs. This time, I noticed that many processes
are stopped, waiting on the ufs lock. I can't tell for certain, but I
assume this kvoop process 33203 is blocking the other processes. The
kvoop process looks to me like it is waiting for a mutex, but nothing
shows up being deadlocked. Am I on the right track? Is there something
else I should be looking for?
(kgdb) proc 33203
[Switching to thread 129 (Thread 100241)]#0 sched_switch (
td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
1944cpuid = PCPU_GET(cpuid);
(kgdb) where
#0 sched_switch (td=0xff0019109a50, newtd=0x0, flags=1)
at ../../../kern/sched_ule.c:1944
#1 0x803a573b in mi_switch (flags=1, newtd=0x0)
at ../../../kern/kern_synch.c:440
#2 0x803d1214 in turnstile_wait (ts=Variable ts is not available.
)
at ../../../kern/subr_turnstile.c:748
#3 0x80392db0 in _mtx_lock_sleep (m=0x8083c220,
tid=18446742974618442320, opts=Variable opts is not available.
) at ../../../kern/kern_mutex.c:420
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 ../../../kern/vfs_cache.c, line=327)
at ../../../kern/kern_mutex.c:186
#5 0x80403bc6 in cache_lookup (dvp=0xff00013e0dc8,
vpp=0xa2d93a18, cnp=0xa2d93a40)
at ../../../kern/vfs_cache.c:327
#6 0x80404093 in vfs_cache_lookup (ap=Variable ap is not
available.
)
at ../../../kern/vfs_cache.c:674
#7 0x805628a0 in VOP_LOOKUP_APV (vop=0x8076e440,
a=0xa2d936b0) at vnode_if.c:99
#8 0x80409afd in lookup (ndp=0xa2d939f0) at vnode_if.h:57
#9 0x8040a824 in namei (ndp=0xa2d939f0)
at ../../../kern/vfs_lookup.c:219
#10 0x8041dc4f in vn_open_cred (ndp=0xa2d939f0,
flagp=0xa2d9393c, cmode=0, cred=0xff0001588600,
fp=0xff0001964200) at ../../../kern/vfs_vnops.c:188
#11 0x8041ccc7 in kern_open (td=0xff0019109a50,
path=0xac30 Address 0xac30 out of bounds, pathseg=Variable
pathseg is not available.
)
at ../../../kern/vfs_syscalls.c:1032
#12 0x80544660 in ia32_syscall (frame=0xa2d93c80)
at ../../../amd64/ia32/ia32_syscall.c:182
#13 0x805014d0 in Xint0x80_syscall () at ia32_exception.S:65
#14 0x28284037 in ?? ()
(kgdb) frame 4
#4 0x80392ea6 in _mtx_lock_flags (m=0x8083c220, opts=0,
file=0x805bd438 ../../../kern/vfs_cache.c, line=327)
at ../../../kern/kern_mutex.c:186
186 _get_sleep_lock(m, curthread, opts, file, line);
(kgdb) list
181 (mtx_lock() of spin mutex %s @ %s:%d,
m-lock_object.lo_name,
182 file, line));
183 WITNESS_CHECKORDER(m-lock_object, opts | LOP_NEWORDER
| LOP_EXCLUSIVE,
184 file, line);
185
186 _get_sleep_lock(m, curthread, opts, file, line);
187 LOCK_LOG_LOCK(LOCK, m-lock_object, opts,
m-mtx_recurse, file,
188 line);
189 WITNESS_LOCK(m-lock_object, opts | LOP_EXCLUSIVE,
file, line);
190 curthread-td_locks++;
(kgdb) print *m
$2 = {lock_object = {lo_name = 0x805bd5d2 Name Cache,
lo_type = 0x805bd5d2 Name Cache, lo_flags = 16973824,
lo_witness_data = {lod_list = {stqe_next = 0x807cd600},
lod_witness = 0x807cd600}}, mtx_lock = 4, mtx_recurse = 0}
___
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: Old /etc files back, or cvs error?
On Tue, 24 Feb 2009 00:58:31 -0800 Kent Stewart kstew...@owt.com wrote: You are looking at the version for the 7.1 release version. The RELENG_7 version is The real question is: why are the files in 7.1-release newer than those in RELENG_7? In other words: why haven't those files been updated in RELENG_7? Are there something wrong with the newer files? For RELENG_7 users it is inconvenient to have to go through all these files every time a 7.1-release install gets updated to RELENG_7. -- Regards, Torfinn Ingolfsen ___ 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: Old /etc files back, or cvs error?
On Tue, 24 Feb 2009, Kent Stewart wrote: On Monday 23 February 2009 10:11:45 pm Warren Block wrote: Lately I've installed a couple of test systems from 7.1-RELEASE CDs, then csupped to RELENG_7 from cvsup9: mergemaster adds a *lot* of old files in /etc that were not there in 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a bunch of bluetooth files and /etc/isdn/*. The version numbers and dates in mergemaster look wrong. For example, /etc/bluetooth/hcsecd.conf: # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax Exp $ Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? You are looking at the version for the 7.1 release version. The RELENG_7 version is Revision 1.3: download - view: text, markup, annotated - select for diffs Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0, RELENG_7, HEAD Branch point for: RELENG_7_1 Diff to: previous 1.2: preferred, colored Changes since revision 1.2: +1 -1 lines I guess I just don't understand. Why did that file and so many others in /etc go backwards: 7.1-RELEASE had 1.3.6.1 2008/11/25 Three months later: RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 Were those later versions (maybe just version strings) included in 7.1-RELEASE by mistake? Were they tagged by mistake and this latest change is just fixing that error? -Warren Block * Rapid City, South Dakota USA ___ 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: Old /etc files back, or cvs error?
On Tue, Feb 24, 2009 at 5:53 PM, Warren Block wbl...@wonkity.com wrote: I guess I just don't understand. Why did that file and so many others in /etc go backwards: 7.1-RELEASE had 1.3.6.1 2008/11/25 Three months later: RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 Were those later versions (maybe just version strings) included in 7.1-RELEASE by mistake? Were they tagged by mistake and this latest change is just fixing that error? I think the 2008/11/25 date is from when RELENG_7_1 was branched --- the branch took place after the file was created, so it looks newer, even though the content is the same. -Ben Kaduk ___ 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: E7400 Speedstep support?
On Wednesday 25 February 2009 06:43:33 pluknet wrote: May those error messages be BIOS related? From my E7200 (well, this is from -current): Could be, bubt I have the latest BIOS.. cpu0: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - CF, should be C6 [20070320] est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 dev.cpu has also expected values. Hmm OK, but maybe the 7400 hasn't been added? (or I have a different rev or something..) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Old /etc files back, or cvs error?
On Tue, Feb 24, 2009 at 03:53:18PM -0700, Warren Block wrote: On Tue, 24 Feb 2009, Kent Stewart wrote: On Monday 23 February 2009 10:11:45 pm Warren Block wrote: Lately I've installed a couple of test systems from 7.1-RELEASE CDs, then csupped to RELENG_7 from cvsup9: mergemaster adds a *lot* of old files in /etc that were not there in 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a bunch of bluetooth files and /etc/isdn/*. The version numbers and dates in mergemaster look wrong. For example, /etc/bluetooth/hcsecd.conf: # $Id: hcsecd.conf,v 1.1 2003/05/26 22:50:47 max Exp $ # $FreeBSD: src/etc/bluetooth/hcsecd.conf,v 1.3 2006/05/18 17:53:49 emax Exp $ Shouldn't that be 1.3.6.1 from Tue Nov 25 02:59:29 2008? You are looking at the version for the 7.1 release version. The RELENG_7 version is Revision 1.3: download - view: text, markup, annotated - select for diffs Thu May 18 17:53:49 2006 UTC (2 years, 9 months ago) by emax Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_1_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0, RELENG_7, HEAD Branch point for: RELENG_7_1 Diff to: previous 1.2: preferred, colored Changes since revision 1.2: +1 -1 lines I guess I just don't understand. Why did that file and so many others in /etc go backwards: 7.1-RELEASE had 1.3.6.1 2008/11/25 Three months later: RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 Were those later versions (maybe just version strings) included in 7.1-RELEASE by mistake? Were they tagged by mistake and this latest change is just fixing that error? The tagging itself causes the version number of the file to be updated. This makes the file in -RELEASE *look* newer then the ones in -STABLE even if the contents of the files haven't actually changed. So there is no mistake, just an annoying side-effect of how the svn-cvs export works with regards to tagging. -- 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: Intel Q45 problems on 7.1-STABLE (fixed)
On Wed, 2009-02-25 at 09:54 +1030, Daniel O'Connor wrote: On Wednesday 25 February 2009 05:40:09 Robert Noland wrote: The reported value of stolen memory is still wrong however. Hrm, I wonder if I have missed an MFC... Please send me some logs and additional details. Your -STABLE is current right? It's about a week or so old. I can update it if you like (or I can let you know specific revs) That is new enough. I've attached dmesg and Xorg log, although the former is truncated due to verbose booting.. The code all looks correct based on the Q45 docs. I can only assume that the BIOS is still not doing the right thing for your settings. robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
7.1-R to RELENG_7 upgrade breaks re nic
Hi, I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after booting, re0 works for only a short time, then gives re0: PHY read failed over and over. Does anyone have a suggestion on how to debug? Thanks, Steve ___ 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: Old /etc files back, or cvs error?
Warren Block wrote: Lately I've installed a couple of test systems from 7.1-RELEASE CDs, then csupped to RELENG_7 from cvsup9: *default host=cvsup9.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_7 *default delete use-rel-suffix That looks right. mergemaster adds a *lot* of old files in /etc that were not there in 7.1-RELEASE. (Remember the rc.d rework? Like that.) For example, a bunch of bluetooth files and /etc/isdn/*. That is definitely not the outcome you should have ended up with. I just checked both the official svn repo and the official cvs repo and the files they are passing out for the two relevant branches are correct, and the real differences (not $Id tags) between the files in the two branches are what I expected to see. Therefore, the problem is somewhere downstream. This looks like an error, but maybe I'm missing something. And other cvsup mirrors seem to agree with cvsup9. My suggestion to you would be to move all source trees that you may have currently somewhere else, move aside /var/db/sup, then start over from scratch and see if what you get is what you expect. If that doesn't work, please script your mergemaster session and send us the output. hope this helps, Doug -- This .signature sanitized for your protection ___ 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: Old /etc files back, or cvs error?
Torfinn Ingolfsen wrote: On Tue, 24 Feb 2009 00:58:31 -0800 Kent Stewart kstew...@owt.com wrote: You are looking at the version for the 7.1 release version. The RELENG_7 version is The real question is: why are the files in 7.1-release newer than those in RELENG_7? They aren't. At least not in the master svn and cvs repositories. Doug -- This .signature sanitized for your protection ___ 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: Intel Q45 problems on 7.1-STABLE (fixed)
On Wednesday 25 February 2009 11:05:45 Robert Noland wrote: I've attached dmesg and Xorg log, although the former is truncated due to verbose booting.. The code all looks correct based on the Q45 docs. I can only assume that the BIOS is still not doing the right thing for your settings. How annoying since it's an Intel product you'd hope they could get it right :( Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: 7.1 hangs in cache_lookup mutex?
Date: Tue, 24 Feb 2009 15:46:28 -0600 From: Guy Helmer ghel...@palisadesys.com Sender: owner-freebsd-sta...@freebsd.org I think I may have found a clue regarding some of the hangs I'm seeing on FreeBSD 7.1. I have a program (kvoop), compiled under FreeBSD 6 and using compatibility libraries under FreeBSD 7, that seems to be consistently involved during these hangs. This time, I noticed that many processes are stopped, waiting on the ufs lock. I can't tell for certain, but I assume this kvoop process 33203 is blocking the other processes. The kvoop process looks to me like it is waiting for a mutex, but nothing shows up being deadlocked. Am I on the right track? Is there something else I should be looking for? For whatever it is worth, I have seen this three times over the past couple of weeks. My system is RELENG_7 of Feb. 7. I have no real information to add other than that I have also had this problem. When it happens, the only way out is a reboot. It hit me twice while updating Xorg. Thanks for your efforts! I hope someone can track down what is triggering with this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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
