sysinstall compilation issue
Hi
This is i386 RELENG_7.
Following section of the /usr/src/usr.sbin/sysinstall/Makefile does not
generate C code properly:
makedevs.c: Makefile rtermcap
echo '#include ' > makedevs.c
${RTERMCAP} ansi | \
file2c 'const char termcap_ansi[] = {' ',0};' \
>> makedevs.c
At compile time, above expands to:
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap
ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c
Which generates C code as follows:
const char termcap_ansi[] = {
,0};
That is, it generates 3 lines, which results a compilation error.
I presume, intended generated code should be:
const char termcap_ansi[] = {' ',0};
Am I right?
That intended code can be generated by a modified statement as:
TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap
ansi | file2c "const char termcap_ansi[] = {""' ',0};"
What is wrong at my end?
Note, I linked the rtermcap with ncursesw libraries, can that be the cause? Any
ideas?
Many thanks in advance.
Kind regards
Unga
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Query timeouts on FreeBSD 7 over network
Hi, I gave up and installed Debian (etch ) on other machine. I've tried FreeBSD 7.0 amd64 on blade machine also and it didn't work perfectly. On the same machine with Debian on board problems stopped. The most strange thing is that on other servers with FreeBSD 4.8 Stable everything works perfectly without problems even after bind upgrade. It looks like Bind and FreeBSD > 6.x have problems or maybe something is wrong with my machines. But how to explain that other system on the same machine works fie ? Best regards, Sebastian Tymków ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regression 7.0R -> 7-stable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit Kühn wrote: | Hi folks, | | I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 | processor (triple core is somehow strange :-) and a lot of NVidia stuff | onboard. I installed 7.0-R, which ran quite well except for the bge driver | and snd_hda which both complained. | After putting in an extra networking card I was able to install some more | software and all appeared to be nice. Then I cvsupped to the recent | 7-stable as of today. My hope was that maybe the bge or the sound card | would improve from this. However, the new kernel I compiled does not run | at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits | there and does nothing anymore. I have verified this behaviour with amd64 | snapshot images from July and August to make sure I did not compile a bad | kernel. Both show the same behaviour. | Are there any ideas what has changed from 7.0-R to recent 7.0-stable that | could cause this? What can I do to debug/fix this? Could you please try disabling ACPI and boot? Additionally a 'boot -v' may reveal some useful information as well. Just some random thoughts. Cheers, - -- Xin LI <[EMAIL PROTECTED]>http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkibfWEACgkQi+vbBBjt66CMKwCfcwhp75YfAKOsmPPmmXmzBGSp 3NEAn388u/YD77vpMTRS/QK6moSu3iu1 =1s3u -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: ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 KES wrote: [...] | kes# make deinstall reinstall clean | ===> Deinstalling for net-mgmt/ng_ipacct | ===> ng_ipacct not installed, skipping | ===> Building for ng_ipacct-20061223 | ===> ng_ipacct (all) | Warning: Object directory not changed from original /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct | cc -O -pipe -g -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc - -I/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ - -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 - --param large-function-growth=1000 -fno-common -mno-align-long-strings - -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 - -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs - -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline - -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ng_ipacct.c | ng_ipacct.c: In function 'pcb_get_cred': | ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local' | *** Error code 1 Newer FreeBSD versions requires a 'ucred' parameter, from my understanding it looks that one has to pass the current thread's ucred? Cheers, - -- Xin LI <[EMAIL PROTECTED]>http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkibeN4ACgkQi+vbBBjt66DO6wCfeG4bbzuFs40CNR28aNFoR/ld P0UAniG1zwrzmQurBOg3yRSDejM4mEaN =mN+B -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: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.)
Hi, John. >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 0; apic id = 00 >> > fault virtual address = 0x38 >> > fault code = supervisor read, page not present >> > instruction pointer = 0x20:0xc058ec16 >> > stack pointer = 0x28:0xfb8b8ac8 >> > frame pointer = 0x28:0xfb8b8ac8 >> > 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 = 1176 (powerd) >> > db:0:kdb.enter.default> show pcpu >> > cpuid= 0 >> > curthread= 0xc4ec0aa0: pid 1176 "powerd" >> > curpcb = 0xfb8b8d90 >> > fpcurthread = none >> > idlethread = 0xc3f80cc0: pid 10 "idle: cpu0" >> > APIC ID = 0 >> > currentldt = 0x50 >> > db:0:kdb.enter.default> bt >> > Tracing pid 1176 tid 100103 td 0xc4ec0aa0 >> > device_is_attached(0,c87e6b40,fb8b8afc,0,101,...) at device_is_attached+0x6 >> > cf_set_method(c420b600,c87e6b40,64,fb8b8ba4,c87e33b4,...) at >> cf_set_method+0x6a3 >> > cpufreq_curr_sysctl(c420d840,c4207000,0,fb8b8ba4,fb8b8ba4,...) at >> cpufreq_curr_sysctl+0x232 >> > sysctl_root(fb8b8ba4,4,1,c4ec0aa0,c4501d38,...) at sysctl_root+0x137 >> > userland_sysctl(c4ec0aa0,fb8b8c14,4,0,0,...) at userland_sysctl+0x151 >> > __sysctl(c4ec0aa0,fb8b8cfc,18,fb8b8ca0,46,...) at __sysctl+0xec >> > syscall(fb8b8d38) at syscall+0x345 >> > Xint0x80_syscall() at Xint0x80_syscall+0x20 >> > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28161bd3, esp = >> 0xbfbfe8cc, ebp = 0xbfbfe8f8 --- >> > db:0:kdb.enter.default> capture off >> > Is it intentional? (kgdb) p level.rel_count $44 = 1986356271 First level.rel_set+5 are NULL in my case. (kgdb) p i $46 = 0 P.S. Same problem/hardware/bt/sysctl/dmesg on Banias 1.6GHz, worked ok on previous stable7 from Jun 16. hth, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Swapping boot disks and getting mountroot>===SOLVED
I got thinks working by commenting out options ATA_STATIC_ID # Static device numbering in the kernel. I had to build a test kernel as described in /usr/src/UPDATING. I still got my mountroot> prompt but for a change is showed me some possible devices. I was able to ad0s1a to boot from. I rebooted to my working kernel and edited /etc/fstab to use ad0. Then booted my test kernel again. The system booted. I installed the kernel w/o ATA_STATIC_ID and was able to boot in my Sunfire X2100 and my X2200. LB Lisa Besko wrote: Joseph Koshy wrote: I notice that it finds the device ad4 but then it tries to mount root from /dev/ad6s1a. I've edited the fstab to have it look for ad4s1a but it still won't boot. Anyone have any pointers or ideas? Have you tried interrupting the boot sequence and setting new values for the `rootdev' and `root_disk_unit' loader variables? The loader(8) manual page has more information. No I haven't tried that yet. Will that get me to a point where I can trust it to boot on it's own to the correct disk all the time? LB -- Lisa Besko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386 vs amd64?
On Aug 7, 2008, at 2:34 AM, Milan Obuch wrote:
5) Get familiar with mergemaster, specifically the side-by-side
interactive diff feature. It looks scary the first time around,
but once you learn that "r" applies the stuff you see on the right,
and "l" applies the stuff you see on the left, you should be fine.
Funny observation: "r" is on LEFT keyboard side, "l" is on RIGHT
keyboard
side. I for one have problem at times precisely for this reason, but
I know
this is an important step and one need to act with great care.
Fortunately, the diffutils maintainer has accepted a patch to allow
"1" and "2" (similar to http://www.pkix.net/~chuck/sdiff2.diff);
hopefully your system is recent enough to include that change:
Regards,
--
-Chuck
Begin forwarded message:
From: Chuck Swiger <[EMAIL PROTECTED]>
Date: June 13, 2007 11:57:34 AM PDT
To: LI Xin <[EMAIL PROTECTED]>
Cc: FreeBSD Current <[EMAIL PROTECTED]>
Subject: Re: RFC: diff(1) update
On Jun 13, 2007, at 2:10 AM, LI Xin wrote:
I have done a first cut of bringing latest GNU diffutils (2.8.1) to
the
FreeBSD base system. This consists two parts of changes:
[ ... ]
Some notes:
- I have tried to keep as most our local features (DIFF_OPTIONS,
etc),
but we still need to have some test cases to figure out whether
there is
regression.
- Local changes are now maintained as patchsets.
- Still need to find a better way to handle local manpage changes...
Comments?
Thanks for looking into updating diffutils, Xin.
Paul Eggert, the diffutils maintainer, has recently adopted a patch
for sdiff which allows using "1" and "2" in addition to "l" and "r",
which is exceptionally useful when people are running mergemaster.
Also, v2.8.6 also includes a fix for invoking an editor in sdiff mode:
Paul Eggert <[EMAIL PROTECTED]> wrote:
Chuck Swiger <[EMAIL PROTECTED]> writes:
At least with diff-2.7 or thereabouts, invoking the
external editor via "e l" or "e r" would always fail and return the
warning from this line of diff code:
fatal ("Subsidiary editor failed");
You can double-check, but I think that bug was fixed here:
2004-04-12 Paul Eggert <[EMAIL PROTECTED]>
* NEWS, configure.ac (AC_INIT): Version 2.8.6.
...
* src/sdiff.c (check_child_status): Renamed from ck_editor_status,
and
accept a new arg MAX_OK_STATUS. All callers changed.
Handle status 126/127 as per POSIX.
--
Good point, thanks. I installed this:
2007-06-06 Paul Eggert <[EMAIL PROTECTED]>
* NEWS: Mention new sdiff aliases 1 and 2 for l and r.
* doc/diff.texi (Merge Commands): Likewise.
* src/sdiff.c (give_help): Give help for them.
(edit): Support them.
Index: NEWS
===
RCS file: /cvsroot/diffutils/diffutils/NEWS,v
retrieving revision 1.25
diff -u -p -r1.25 NEWS
--- NEWS5 Sep 2006 23:02:32 - 1.25
+++ NEWS6 Jun 2007 23:40:12 -
@@ -14,6 +14,8 @@ User-visible changes since 2.8.7 (in "ve
"Utility Syntax Guidelines" in the Minutes of the January 2005
Meeting .
+* sdiff now understands '1' and '2' as synonyms for 'l' and 'r'.
+
Version 2.8.7 contains no user-visible changes.
--
-Chuck
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: should looking at an interface with 'ifconfig' trigger a change ?
On Thu, Aug 07, 2008 at 06:11:58PM +0100, Pete French wrote: > > The bce driver is not properly generating link state events. > > OK, that explains why it doesnt failover - but why does looking at it > with ifconfig make a difference ? surely that should be 'read only ? ifconfig will cause the media status to be read from the hardware at which time the link change is generated as it is different to the stored value. 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: should looking at an interface with 'ifconfig' trigger a change ?
On Thu, Aug 07, 2008 at 05:27:53PM +0100, Pete French wrote: > I have a very odd problem here - two interfaces bundled using lagg > in 'failover' mode, so one interface is active and the other not being > used. if the carrier drops on the active one I expect it to > failover, but it doesnt. > > ...until I type 'ifconfig bce0' to look at the status of the interface > which has gone down. At which point it fails over properly! > > This is most odd - how can simply looking at the config of an > interface trigger the failover ? It wont fail over otherwise either - you > can leave it as long as you like and lagg wont realise that the active > has gone down. > > The interfaces here are 'bce' by the way, if that make a difference The bce driver is not properly generating link state events. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: should looking at an interface with 'ifconfig' trigger a change ?
> The bce driver is not properly generating link state events. OK, that explains why it doesnt failover - but why does looking at it with ifconfig make a difference ? surely that should be 'read only ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
should looking at an interface with 'ifconfig' trigger a change ?
I have a very odd problem here - two interfaces bundled using lagg in 'failover' mode, so one interface is active and the other not being used. if the carrier drops on the active one I expect it to failover, but it doesnt. ...until I type 'ifconfig bce0' to look at the status of the interface which has gone down. At which point it fails over properly! This is most odd - how can simply looking at the config of an interface trigger the failover ? It wont fail over otherwise either - you can leave it as long as you like and lagg wont realise that the active has gone down. The interfaces here are 'bce' by the way, if that make a difference -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Swapping boot disks and getting mountroot>
Joseph Koshy wrote: I notice that it finds the device ad4 but then it tries to mount root from /dev/ad6s1a. I've edited the fstab to have it look for ad4s1a but it still won't boot. Anyone have any pointers or ideas? Have you tried interrupting the boot sequence and setting new values for the `rootdev' and `root_disk_unit' loader variables? The loader(8) manual page has more information. No I haven't tried that yet. Will that get me to a point where I can trust it to boot on it's own to the correct disk all the time? LB -- Lisa Besko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPP doesn't set the correct interface in 7-STABLE
On Wed, 6 Aug 2008, Mike Tancsa wrote: > At 10:16 AM 8/6/2008, Andy Dills wrote: > > > I'm trying to setup pptpd to enable VPN connections. This worked well in > > all versions of FreeBSD prior to 7. > > I would turf pptpd and look at mpd51 from the ports. It is far, far better > maintained and is quite solid as an LNS as well as PPTP termination server. Yep, it looks like this is definitely the best solution, for a number of reasons. Thanks for the pointer. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386 vs amd64?
Hello everybody. (sorry for my english) > > # For individuals wanting to upgrade their sources (even if only a > # delta of a few days): > # > # 1. `cd /usr/src' (or to the directory containing your source > tree). > # 2. `make buildworld' > # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is > GENERIC). > # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is > GENERIC). > # 5. `reboot'(in single user mode: boot -s from the loader > prompt). > # 6. `mergemaster -p' > # 7. `make installworld' > # 8. `make delete-old' > # 9. `mergemaster' > # 10. `reboot' > # 11. `make delete-old-libs' (in case no 3rd party program uses them > anymore) > Pls tell me what for I need 5 step? I have about 15 remote servers (10 on 6.X-stable and others on 7.0-stable). These servers are far far away from me and I really cant connect serial or keyboard to it. So I upgrade remotely without "# 5 reboot" very long time, starting from at least 5.4 (maybe 4.x I dont remember), 5.4-stable -> 6.0-stable, 6.0-stable -> 6.2-stable, 6.0/6.2-stable -> 6.3-stable and of couse 6.2/6.3-stable -> 7.0-stable. Only once I got a problem with /libexec/ld-elf.so.X then I try upgrade from 6.2-RELEASE-pX to 7.0-stable. Of couse I got phisical access to this server to repair it. I got this file from another server and then succesfully rebuild all the world with my "reception". This was really hard situation. (I use /rescue and have shamanian danced with tambourine around this server ;) lol ;) ) I dont remember why I had on that server this strange (for me) version (6.2-RELEASE). So have I a chance to upgrade remote servers without single mode? Now my practice is (a few last years): #cd /usr/src #mergemaster -p && make -j8 buildworld && make -j8 buildkernel KERNCONF=KMD && make installkernel KERNCONF=KMD && make installworld && mergemaster -iU && reboot *) -j8 on 2x- or 4x-kernels cpu and -j4 on 1x-kernel cpu *) some time I did "make -j4 installkernel KERNCONF=KMD" and "make -j4 installworld" but it's worked not stable. Sometimes it returns an error. Maybe hdd was not speedy - dont know why it was so and dont know how to say it all in english. :\ *) on Phenom 9750 with 2GB DDR2 800MHz memory "-j8 buildworld" makes in about 16 minutes and "-j8 buildkernel KERN..." in about 5 minutes. As a result all upgrade takes about 30 minutes or less. On x2 CPUs I put this long command in ssh-term and go away. When I come back "mergemaster -iU" is waiting me. And if I make major update (6.x to 7.x) I'll portupgrade all ports as in manual "portupgrade -faP" and then reboot after that "make delete-old" and "make delete-old-libs" and reboot All of this I do remotely. Is this way very wrong? I understand that it's not a "canonical" way but how I can do it right and remotely? Thanks in advance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regression 7.0R -> 7-stable?
On Thu, Aug 07, 2008 at 05:19:40AM -0700, Jeremy Chadwick wrote: > On Thu, Aug 07, 2008 at 09:47:06PM +1000, Edwin Groothuis wrote: > > On Thu, Aug 07, 2008 at 01:29:47PM +0200, Gerrit K?hn wrote: > > > Hi folks, > > > > > > I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 > > > processor (triple core is somehow strange :-) and a lot of NVidia stuff > > > onboard. I installed 7.0-R, which ran quite well except for the bge driver > > > and snd_hda which both complained. > > > After putting in an extra networking card I was able to install some more > > > software and all appeared to be nice. Then I cvsupped to the recent > > > 7-stable as of today. My hope was that maybe the bge or the sound card > > > would improve from this. However, the new kernel I compiled does not run > > > at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits > > > there and does nothing anymore. I have verified this behaviour with amd64 > > > snapshot images from July and August to make sure I did not compile a bad > > > kernel. Both show the same behaviour. > > > Are there any ideas what has changed from 7.0-R to recent 7.0-stable that > > > could cause this? What can I do to debug/fix this? > > > > Make sure you have this in your /etc/sysctl.conf: > > > > [~] [EMAIL PROTECTED]>grep hyper /etc/sysctl.conf > > machdep.hyperthreading_allowed=1 > > > > Then with top you can see the CPUs in use --v > > > > PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND > > 69200 edwin 9 440 236M 130M ucond 0 33:37 5.76% > > seamonkey-b > > 3317 edwin 1 710 38404K 33572K select 1 3:51 0.10% mutt > > 3015 edwin 1 450 403M 81672K select 0 101:52 0.00% Xorg > > I think you misread what he was saying. :-) He's saying that his > system locks up hard after the kernel prints the "SMP: AP CPU #x > Launched!" messages. It's indeed a different interpretation of what I originally read. Sorry for the noise! Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regression 7.0R -> 7-stable?
On Thu, 7 Aug 2008 05:19:40 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote about Re: Regression 7.0R -> 7-stable?: JC> I think you misread what he was saying. :-) He's saying that his JC> system locks up hard after the kernel prints the "SMP: AP CPU #x JC> Launched!" messages. Exactly. ;-) JC> I believe this is the 2nd or 3rd report we've had of this behaviour, JC> re: system locking up hard after those messages. I'll see if I can JC> find the past reports; I'm going off of memory, but they were in JC> recent days. Please let me know if I can provide any further information. However, I will probably not be on the net from tomorrow (Friday) until Monday. 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: Regression 7.0R -> 7-stable?
On Thu, Aug 07, 2008 at 09:47:06PM +1000, Edwin Groothuis wrote: > On Thu, Aug 07, 2008 at 01:29:47PM +0200, Gerrit K?hn wrote: > > Hi folks, > > > > I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 > > processor (triple core is somehow strange :-) and a lot of NVidia stuff > > onboard. I installed 7.0-R, which ran quite well except for the bge driver > > and snd_hda which both complained. > > After putting in an extra networking card I was able to install some more > > software and all appeared to be nice. Then I cvsupped to the recent > > 7-stable as of today. My hope was that maybe the bge or the sound card > > would improve from this. However, the new kernel I compiled does not run > > at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits > > there and does nothing anymore. I have verified this behaviour with amd64 > > snapshot images from July and August to make sure I did not compile a bad > > kernel. Both show the same behaviour. > > Are there any ideas what has changed from 7.0-R to recent 7.0-stable that > > could cause this? What can I do to debug/fix this? > > Make sure you have this in your /etc/sysctl.conf: > > [~] [EMAIL PROTECTED]>grep hyper /etc/sysctl.conf > machdep.hyperthreading_allowed=1 > > Then with top you can see the CPUs in use --v > > PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND > 69200 edwin 9 440 236M 130M ucond 0 33:37 5.76% > seamonkey-b > 3317 edwin 1 710 38404K 33572K select 1 3:51 0.10% mutt > 3015 edwin 1 450 403M 81672K select 0 101:52 0.00% Xorg I think you misread what he was saying. :-) He's saying that his system locks up hard after the kernel prints the "SMP: AP CPU #x Launched!" messages. I believe this is the 2nd or 3rd report we've had of this behaviour, re: system locking up hard after those messages. I'll see if I can find the past reports; I'm going off of memory, but they were in recent days. Also (for you Edwin), be aware of the security issues when enabling HTT, as well as the possible decrease in system performance (while increase in power draw) it can cause: http://en.wikipedia.org/wiki/Hyper-threading#Security http://en.wikipedia.org/wiki/Hyper-threading#Future -- | 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]"
Re: bsnmp header files question
On Thu, Aug 07, 2008 at 03:22:21AM -0700, Unga wrote: > 1) /usr/include/bsnmp/snmpmod.h /usr/src/usr.sbin/bsnmpd/modules/Makefile > 2) /usr/include/bsnmp/snmp_mibII.h /usr/src/usr.sbin/bsnmpd/modules/snmp_mibII/Makefile > 3) /usr/include/bsnmp/snmp_atm.h /usr/src/usr.sbin/bsnmpd/modules/snmp_atm/Makefile Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgp5n0iMda9zb.pgp Description: PGP signature
Re: Regression 7.0R -> 7-stable?
On Thu, Aug 07, 2008 at 01:29:47PM +0200, Gerrit K?hn wrote: > Hi folks, > > I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 > processor (triple core is somehow strange :-) and a lot of NVidia stuff > onboard. I installed 7.0-R, which ran quite well except for the bge driver > and snd_hda which both complained. > After putting in an extra networking card I was able to install some more > software and all appeared to be nice. Then I cvsupped to the recent > 7-stable as of today. My hope was that maybe the bge or the sound card > would improve from this. However, the new kernel I compiled does not run > at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits > there and does nothing anymore. I have verified this behaviour with amd64 > snapshot images from July and August to make sure I did not compile a bad > kernel. Both show the same behaviour. > Are there any ideas what has changed from 7.0-R to recent 7.0-stable that > could cause this? What can I do to debug/fix this? Make sure you have this in your /etc/sysctl.conf: [~] [EMAIL PROTECTED]>grep hyper /etc/sysctl.conf machdep.hyperthreading_allowed=1 Then with top you can see the CPUs in use --v PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 69200 edwin 9 440 236M 130M ucond 0 33:37 5.76% seamonkey-b 3317 edwin 1 710 38404K 33572K select 1 3:51 0.10% mutt 3015 edwin 1 450 403M 81672K select 0 101:52 0.00% Xorg Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Regression 7.0R -> 7-stable?
Hi folks, I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 processor (triple core is somehow strange :-) and a lot of NVidia stuff onboard. I installed 7.0-R, which ran quite well except for the bge driver and snd_hda which both complained. After putting in an extra networking card I was able to install some more software and all appeared to be nice. Then I cvsupped to the recent 7-stable as of today. My hope was that maybe the bge or the sound card would improve from this. However, the new kernel I compiled does not run at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits there and does nothing anymore. I have verified this behaviour with amd64 snapshot images from July and August to make sure I did not compile a bad kernel. Both show the same behaviour. Are there any ideas what has changed from 7.0-R to recent 7.0-stable that could cause this? What can I do to debug/fix this? cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsnmp header files question
Hi Could I know on i386 RELENG_7, what Makefiles install following header files: 1) /usr/include/bsnmp/snmpmod.h 2) /usr/include/bsnmp/snmp_mibII.h 3) /usr/include/bsnmp/snmp_atm.h Appreciate your reply very much. Kind regards Unga ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386 vs amd64?
On Thursday 07 August 2008, Jeremy Chadwick wrote: > On Thu, Aug 07, 2008 at 12:58:06AM -0700, Ask Bjørn Hansen wrote: [ snip ] > But be aware that there still are some applications (ports) which don't > behave correctly on amd64. So my recommendation is to build a test > box that mimics your production environment, and make sure all of your > stuff works on it. This means you should do some work before actually deciding the way to go... but it's the best way. Test and then use in production. Your own experience is worth an added bit of work. [ snip ] > 5) Get familiar with mergemaster, specifically the side-by-side > interactive diff feature. It looks scary the first time around, > but once you learn that "r" applies the stuff you see on the right, > and "l" applies the stuff you see on the left, you should be fine. Funny observation: "r" is on LEFT keyboard side, "l" is on RIGHT keyboard side. I for one have problem at times precisely for this reason, but I know this is an important step and one need to act with great care. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: i386 vs amd64?
On Thu, Aug 07, 2008 at 12:58:06AM -0700, Ask Bjørn Hansen wrote: > We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll be > used as firewalls / very basic routers (our network on one side, the > world via a /29 on the other side). We currently use Soekris and PC > Engine boxes for this (with custom NanoBSD images), so this will be a bit > of an upgrade. :-) What motherboard model is used on those boxes? The website doesn't say. The reason I'm asking is that I'm working on a H/W monitoring project which currently is focusing on Supermicro boards, and need more testers for boards I don't already have data for. :-) > I was planning to install pfSense on them, but I'm losing faith in that a > bit after figuring out that the pfSense project doesn't seem all that > open[2]; so I'm considering just installing "plain FreeBSD 7" instead. > > So the question: Would I be happier with 64 or 32bit FreeBSD? Our > Linux application and database servers are all 64 bit, but they also > have 32GB RAM each. The "firewall boxes" are probably vastly overdone > with memory at 4GB each. :-) We have numerous Supermicro machines in our co-lo, all of which run i386 except for one. The reason was that I hadn't spent the time to really get a feel for amd64 (all the machines run RELENG_6 except for the amd64 box, which runs RELENG_7). I run amd64 at home, and it's fine. I'm looking forward to being able to upgrade our SQL server in the co-lo to either 4GB or 8GB of RAM without having to bother with PAE (ugh!). But be aware that there still are some applications (ports) which don't behave correctly on amd64. So my recommendation is to build a test box that mimics your production environment, and make sure all of your stuff works on it. You might also be asking "is there some form of compatibility where amd64 can continue to run i386 binaries?" Yes, it's called lib32. I choose not to install it (during a FreeBSD install), and I disable it from buildworld by using WITHOUT_LIB32=true in /etc/src.conf (that file is new compared to older FreeBSD, so be aware). My attitude is "this is a 64-bit box, and you will recompile your programs to work on a 64-bit arch". Avoiding it also greatly decreases buildworld time. > A secondary question: Is the preferred way to upgrade a FreeBSD box > still cd /usr/src; make update && make buildworld && ... ? (I mostly > use FreeBSD for building my NanoBSD-flavor images these days, so I'm a > bit out of touch). First and foremost: to update the sources, you should use csup and not cvsup. csup comes in the base system, is written in C, and supports most all of the flags that cvsup does. The upgrade procedure is described in detail in /usr/src/Makefile. Here's what I'm referring to: # For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) Some footnotes: 1) You can put KERNCONF=WHATEVER in /etc/make.conf, thus avoiding the need to specify it during steps 3 and 4. 2) On amd64, your kernel config will go in /sys/amd64/conf, not /sys/i386/conf. (This may be obvious to most, but not so much to newer folks). 3) After step #5, and you're in single-user, you'll probably have to type "mount -a -t ufs" to get all of your filesystems mounted. 4) Don't skip the single-user step or try to do it from multi-user; I've seen numerous cases where /libexec/ld-elf.so.1 doesn't get updated as a result of people trying to avoid single-user. If you admin these boxes remotely, you're going to need serial console for the above. 5) Get familiar with mergemaster, specifically the side-by-side interactive diff feature. It looks scary the first time around, but once you learn that "r" applies the stuff you see on the right, and "l" applies the stuff you see on the left, you should be fine. -- | 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]"
i386 vs amd64?
Hi everyone, We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll be used as firewalls / very basic routers (our network on one side, the world via a /29 on the other side). We currently use Soekris and PC Engine boxes for this (with custom NanoBSD images), so this will be a bit of an upgrade. :-) I was planning to install pfSense on them, but I'm losing faith in that a bit after figuring out that the pfSense project doesn't seem all that open[2]; so I'm considering just installing "plain FreeBSD 7" instead. So the question: Would I be happier with 64 or 32bit FreeBSD? Our Linux application and database servers are all 64 bit, but they also have 32GB RAM each. The "firewall boxes" are probably vastly overdone with memory at 4GB each. :-) A secondary question: Is the preferred way to upgrade a FreeBSD box still cd /usr/src; make update && make buildworld && ... ? (I mostly use FreeBSD for building my NanoBSD-flavor images these days, so I'm a bit out of touch). - ask [1] http://www.siliconmechanics.com/i15328/xeon-3000.php [2] http://forum.pfsense.org/index.php/topic,10769.0.html -- http://develooper.com/ - http://askask.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local'
When .ifndef PACKAGE_BUILDING IGNORE= "Depends on kernel" .endif I get Depends on kernel When I change that to: .ifndef PACKAGE_BUILDING NO_PACKAGE= "Depends on kernel" .endif a get: kes# make deinstall reinstall clean ===> Deinstalling for net-mgmt/ng_ipacct ===> ng_ipacct not installed, skipping ===> Building for ng_ipacct-20061223 ===> ng_ipacct (all) Warning: Object directory not changed from original /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct cc -O -pipe -g -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ng_ipacct.c ng_ipacct.c: In function 'pcb_get_cred': ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local' *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. kes# ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
