Re: i386 tinderbox failure
Dag-Erling Smorgrav wrote: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Apparently an eternal pessimist, you were not expecting success? 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/src/usr.sbin/pcvt/kcon
David O'Brien wrote: On Wed, May 22, 2002 at 12:37:57AM +0200, John Angelmo wrote: su-2.05a# make cc -O -pipe -march=pentiumpro -I/usr/src/usr.sbin/pcvt/kcon/../keycap -DKEYB_DEVICE=\/dev/ttyv0\ -o kcon kcon.o -lkeycap /usr/libexec/elf/ld: cannot find -lkeycap collect2: ld returned 1 exit status *** Error code 1 It would be nice to see a `cd' or `pwd' here so we can fully know what you are doing. I will assume you are in the /usr/src/usr.sbin/pcvt directory before you typed `make'. Warning, you cannot build all things in /usr/src in isolation. However you should have a /usr/lib/libkeycap.a, which would allow you to build this. You really need tell us more about what you are doing, and what your system is (`uname -a'). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Ah sorry I thought it was so clear that it was /usr/src/usr.sbin/pcvt/kcon :) Well there it broke when I did make world so I went there trying to isolate stuff /usr/lib/libkeycap is there FreeBSD Amnesiac 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue May 21 19:37:38 CEST 2002 root@Amnesiac:/usr/obj/usr/src/sys/Linn i386 Well here is the thing, I just updated before gcc 3.1, everything worked fine, last night I felt like gcc 3.1 was ready for my system, So I did: make buildworld make buildkernel KERNCONF=Linn make installkernel KERNCONF=Linn mergemaster -v drop to single make installworld well no biggie there, but after reboot I got a strange dmesg (need to reboot to get it again) so I found out that not everything was build in /usr/src/usr.sbin and some other stuff. Right now I'm trying to do a new make buildworld and hope it works this time. and that my wi0 card will work one again :) /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cannot make vidcontrol
I got this problem: [ /usr/src/usr.sbin ]#make vidcontrol Warning: Object directory not changed from original /usr/src/usr.sbin/vidcontrol cc -O -pipe -c vidcontrol.c vidcontrol.c: In function `load_font': vidcontrol.c:221: structure has no member named `font_size' *** Error code 1 Stop in /usr/src/usr.sbin/vidcontrol. *** Error code 1 Stop in /usr/src/usr.sbin. I've CVSUPed the whole tree before 10 minutes. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot make vidcontrol
Martin Kacerovsky wrote: I got this problem: [ /usr/src/usr.sbin ]#make vidcontrol Warning: Object directory not changed from original /usr/src/usr.sbin/vidcontrol cc -O -pipe -c vidcontrol.c vidcontrol.c: In function `load_font': vidcontrol.c:221: structure has no member named `font_size' *** Error code 1 Stop in /usr/src/usr.sbin/vidcontrol. *** Error code 1 Stop in /usr/src/usr.sbin. sys/consio.h header installed on your system is too old. You need to do a fresh `make world' and rebuild/reinstall your kernel - it's the only way to do vidcontrol upgrade properly. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: multi default routes in freebsd !?
÷ Wed, 22.05.2002, × 00:52, Terry Lambert ÎÁÐÉÓÁÌ: Vladimir B. Grebenschikov wrote: Multipath routing is not as useful as you imply. Neither is round-robin'ing between a set of paths. It assumes that the pool retention time on the router is longer than the drain time for a single path, such that you end up with a higher aggregate throughput than you would otherwise get. Most of the time, with what you are suggesting, you will get the same throughput, you will just get differential pipe utilization (using B == !A). When this isn't the case, the amount of latency for a single path is such that you end up with only a small fractional improvement, when there is any improvement at all. Lets imagine - we have 3 links 2Mbit/s on different interfaces. I want to join them all, but I have no control of other end (provider) so I can't build netgraph-joiner. Solution with installing 3 routes (through BGP of course, one BGP session per link) solves problem. I have 6 Mbit/s summary bandwith. No, you don't. Without the cooperation of the tother end, you don't have control of the symmetry of the return route. So maybe your packets are round-robin'ed out interfaces, but they all come back through the same interface, because you have no control of the other end. On other end I have providers CISCO router _with_ standard BGP multipath feature, so I have symmetric situation. The only way around this is to have the default routes outbound be totally seperate from the inbound (don't eat your inbound bandwidth witho outbound load). The unidirectional troughput goes to 1, and your total throughput doubles. But it never gets beyond double. I do not talk about _default_ all I have said can right for any set of routes. This is why BGP is a better deal: it implicitly enlists the cooperation of the other end of the link. Once again, BGP can deal with multipath, it can utilize multipath if we have more then one link with same weight/etc. The primary failure of this is that it can't detect when a route goes down, so you are screwed when that happens. If interface goes down route will be DOWN by kernel. So it is not problem. No. ,---. | BOX WITH TWO | ,---| DEF. ROUTES |---. route #1 | `---' | route #2 | | ,---. ,---. | ROUTER A | | ROUTER B | `---' `---' | | | | good link dead link The link between the box and router B remains up. Therefore the box fails to note that packets sent via route #2 never get to their destination. No, if link BOX-routerB fails kernel must down one of two routes with same prefix (you said default). If from side of BOX it is noot seen thar carrier (whatever) on link BOX-routerB down - BGP session over this link will down so, BGP software will down route. I am not happy with hack pach when one route have more then one gateway, may opinion to allow insert more then one full-featured route to one prefix into kernel FIB, but it is implementation issue. It's ridiculous to think that the interface for route #2 will somehow magically down itself on box because, several hops down the line, the line is dead. If you have direct link, say serial - kernel will detect interface down easily, if you have some kind of multihop - multihop BGP will save situation, but it is unwise scheme (I think). So in this case you better to build: ,---. | BOX WITH TWO | ,---| DEF. ROUTES |---. route #1 | `---' | route #2 | | ,---. ,---. | ROUTER A | | ROUTER B | `---' `---' | | link X | | BGP here good link,. | | Another router | | `' routes source --/ So all routes comes from routes source (It can be core router of provider with full view or default issuing router) And, if link X fails set of routes (or only default) will disappear from BOX-routerB link, and BGP software will remove second path routes. Anyway if problem happens without downing interface BGP will detect problem and down routes. Only if you are using BGP. And if you are using BGP, you
Re: cannot make vidcontrol
On Wed, May 22, 2002 at 11:22:43AM +0300, Maxim Sobolev wrote: sys/consio.h header installed on your system is too old. You need to do a fresh `make world' and rebuild/reinstall your kernel - it's the only way to do vidcontrol upgrade properly. I don't understand, I have CVSUPed the whole tree and rebuilt the kernel, after boot when I launched vidcontrol it said me unapropriate ioctl ..., so I've decided to rebuild it from the same tree as kernel, so IMO the sys/consio.h is the same version as vidcontrol is, isn't it? I don't understand why I must build the whole world, if only vidcontrol has problems with the new kernel. (The old world is snapshot 5.0-20020302-PREVIEW). Maybe I don't understand, because I am stupid, but I thought making new world is neccesary only when upgrading from -stable. I thought that in that snapshot the world already is 5.0, so it isn't neccessary to rebuild it all. If I am wrong (99.9% probability), be so kind and correct me or at least show me the right way (drop some links). Regards, Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb breaks world
On Monday 20 May 2002 3:49 am, Terry Lambert wrote: Steve Kargl wrote: Use -ggdb instead, thus avoiding DWARF. BZZZT... Thanks for play! Did Mark Peek's suggestion of using the gdb that matched the compiler (gdb 5.2 from ports) work instead? GDB 5.2 works pretty well with -current - I've been using it recently. I plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to sort out the CVS magic). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot make vidcontrol
Martin Kacerovsky wrote: On Wed, May 22, 2002 at 11:22:43AM +0300, Maxim Sobolev wrote: sys/consio.h header installed on your system is too old. You need to do a fresh `make world' and rebuild/reinstall your kernel - it's the only way to do vidcontrol upgrade properly. I don't understand, I have CVSUPed the whole tree and rebuilt the kernel, after boot when I launched vidcontrol it said me unapropriate ioctl ..., so I've decided to rebuild it from the same tree as kernel, so IMO the sys/consio.h is the same version as vidcontrol is, isn't it? I don't understand why I must build the whole world, if only vidcontrol has problems with the new kernel. (The old world is snapshot 5.0-20020302-PREVIEW). Maybe I don't understand, because I am stupid, but I thought making new world is neccesary only when upgrading from -stable. I thought that in that snapshot the world already is 5.0, so it isn't neccessary to rebuild it all. If I am wrong (99.9% probability), be so kind and correct me or at least show me the right way (drop some links). You are seeing this because you didn't follow proper upgrade procedure. Each time you are rebuilding your kernel from the freshly cvsuped sources you need to do make world as well, because in FreeBSD kernel and some utilities in the base system are tightly integrated. Therefore you can't use September kernel with August world, and vice-versa (actually you can, but then you will see the problems like this one or even worse). Rebuilding only problematic utilities from the sources isn't going to help you either, because without make world, your set of C header files in /usr/include/sys describing kernel interfaces remains outdated, so that compilation would either fail or doesn't produce any sensible results. I believe that there is a chapter in the FreeBSD Handbook about doing source upgrades properly - please check it out. Handbook itself is available from the www.FreeBSD.org site. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot link C++ apps any more (GCC 3.1)
Am Di, 2002-05-21 um 21.35 schrieb Szilveszter Adam: Hello, On Tue, May 21, 2002 at 02:26:57PM +0200, Georg-W. Koltermann wrote: Hi, I am unable to link C++ apps with a recent -current. It seems I would need a new libstdc++ which was not included. My libstdc++.so is a leftover from the previous cvsup. Yes, this is correct. THe libraries libstdc++v3 and libsupc++v3 are not built for the system compiler. You can, however, use ports/lang/gcc31. Ok that works. But, since the system compiler does not include a libstdc++ any more, are there any plans on removing the /usr/bin/c++ and /usr/bin/g++ commands? Seems the are not useful any more, and may conflict with a port which installs these commands. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't install world
David O'Brien [EMAIL PROTECTED] schrieb am 22.05.02: On Tue, May 21, 2002 at 04:33:32PM +0200, yuri khotyaintsev wrote: make buildworld ... make buildkernel ... make installkernel ... mergemaster ... You have to reboot here with new kernel. Actually you want to reboot before mergemaster -- you don't have the matching binaries installed yet. i rebootet after mergemaster did a second mergemaster after having the new world installed. seems to work. btw: frequently i see Could Not Sleep... messages like those Glenn mentioned yesterday. Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
John Baldwin [EMAIL PROTECTED] writes: Erm, this is the second blank message. Is this really a success and not a failure? If so, can we not have a mail sent out for successful builds? :) It's a failure, but ref5 doesn't have Perl installed, so the script that selects what portions of the log to mail out didn't run. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems with DP1
On Tue, May 21, 2002 at 03:27:46PM -0700, Kris Kennaway wrote: Hi, That's not actually where the panic is occurring (it's a second panic caused by the kernel trying to sync disks after it panics the first time). Please provide a full traceback so it can be investigated. I've attached both a backtrace and my dmesg. Is any extra info needed? Kernel was built from a modified GENERIC with SMP enabled, WITNESS and INVARIANTS disabled, and device pcm. The rest is off the shelf 5.0-DP1 stuff. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... IdlePTD at phsyical address 0x00467000 initial pcb at physical address 0x00378b00 panicstr: bwrite: buffer is not busy??? panic messages: --- panic: setrunnable(2) cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks... panic: bwrite: buffer is not busy??? cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 5h34m33s /dev/vmmon: Module vmmon: unloaded dumping to dev da1s1b, offset 131328 dump 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at ../../../kern/kern_shutdown.c:505 505 if (!dodump) (kgdb) bt #0 dumpsys () at ../../../kern/kern_shutdown.c:505 #1 0xc01d53a8 in boot (howto=260) at ../../../kern/kern_shutdown.c:337 #2 0xc01d5899 in panic (fmt=0xc030292b bwrite: buffer is not busy???) at ../../../kern/kern_shutdown.c:647 #3 0xc020ade7 in bwrite (bp=0xc9323ae8) at ../../../kern/vfs_bio.c:747 #4 0xc020c1f6 in vfs_bio_awrite (bp=0xc9323ae8) at ../../../kern/vfs_bio.c:1606 #5 0xc01ac878 in spec_fsync (ap=0xd0412ae8) at ../../../fs/specfs/spec_vnops.c:403 #6 0xc01ac435 in spec_vnoperate (ap=0xd0412ae8) at ../../../fs/specfs/spec_vnops.c:121 #7 0xc028a02c in ffs_sync (mp=0xc2cb5800, waitfor=2, cred=0xc102eb80, td=0xc0344920) at vnode_if.h:441 #8 0xc02184a1 in sync (td=0xc0344920, uap=0x0) at ../../../kern/vfs_syscalls.c:669 #9 0xc01d4ff0 in boot (howto=256) at ../../../kern/kern_shutdown.c:246 #10 0xc01d5899 in panic (fmt=0xc02fed34 setrunnable(2)) at ../../../kern/kern_shutdown.c:647 #11 0xc01dbde2 in setrunnable (td=0xd21952a0) at ../../../kern/kern_synch.c:800 #12 0xc01d8547 in psignal (p=0xd21951a0, sig=23) at ../../../kern/kern_sig.c:1517 #13 0xc01d9ac0 in pgsigio (sigio=0xc306b860, sig=23, checkctty=0) at ../../../kern/kern_sig.c:2095 #14 0xc02049f3 in sowakeup (so=0xd0593fa0, sb=0xd0593ff0) at ../../../kern/uipc_socket2.c:344 #15 0xc0235c99 in tcp_input (m=0xc1039100, off0=20) at ../../../netinet/tcp_input.c:1028 #16 0xc0231700 in ip_input (m=0xc1039100) at ../../../netinet/ip_input.c:845 #17 0xc02317be in ipintr () at ../../../netinet/ip_input.c:870 #18 0xc01c64f4 in swi_net (dummy=0x0) at ../../../kern/kern_intr.c:644 #19 0xc01c6220 in ithread_loop (arg=0xc102e680) at ../../../kern/kern_intr.c:533 #20 0xc01c5432 in fork_exit (callout=0xc01c607c ithread_loop, arg=0xc102e680, frame=0xd0412d48) at ../../../kern/kern_fork.c:799 (kgdb) Copyright (c) 1992-2002 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 5.0-DP1 #0: Wed May 15 19:35:03 CEST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KAJSA Preloaded elf kernel /boot/kernel/kernel at 0xc0448000. Preloaded elf module /boot/kernel/acpi.ko at
Re: can't install world
Those error(s) seem to be gone with today's cvsup and rebuild, I think that John Baldwin made a change to kern_mutex.c that seems to have resolved the problem :-) btw: frequently i see Could Not Sleep... messages like those Glenn mentioned yesterday. -- Glenn Gombert [EMAIL PROTECTED] Never trust any operating system you don't have the source code for -- http://fastmail.fm/ - A no graphics, no pop-ups email service To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot make vidcontrol
On 2002-05-22 10:39, Martin Kacerovsky wrote: On Wed, May 22, 2002 at 11:22:43AM +0300, Maxim Sobolev wrote: sys/consio.h header installed on your system is too old. You need to do a fresh `make world' and rebuild/reinstall your kernel - it's the only way to do vidcontrol upgrade properly. I don't understand, I have CVSUPed the whole tree and rebuilt the kernel, after boot when I launched vidcontrol it said me unapropriate ioctl ..., so I've decided to rebuild it from the same tree as kernel, so IMO the sys/consio.h is the same version as vidcontrol is, isn't it? I don't understand why I must build the whole world, if only vidcontrol has problems with the new kernel. (The old world is snapshot 5.0-20020302-PREVIEW). It's very likely that other things will have problems with the new kernel too. You just haven't discovered yet. You should really always try to run a userland and kernel that have been compiled from the same set of sources. -- Giorgos Keramidas- http://www.FreeBSD.org [EMAIL PROTECTED] - The Power to Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot make vidcontrol
On Wed, May 22, 2002 at 04:29:33PM +0300, Giorgos Keramidas wrote: It's very likely that other things will have problems with the new kernel too. You just haven't discovered yet. You should really always try to run a userland and kernel that have been compiled from the same set of sources. OK, Maxim already has shown me the right way :) Thanks, Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: thanks for heads-up on devfs
On Wed, 22 May 2002, Giorgos Keramidas wrote: On 2002-05-21 15:03, Rob wrote: I am still wondering why MAKEDEV showed up in /usr/src/etc if it is not needed? I had an empty directory before I cvsup'd. Thanks, Rob. You'll probably need it if you manually disable DEVFS in CURRENT. However, I don't know if this still works, as I haven't tried it. I still use !DEVFS, since I don't believe in DEVFS. I needed to fix some bitrot in the disk cloning code for finding the root device to work. Initialization of the pty driver causes warnings. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: passwd issue
on Tue May 21 13:07:13 2002, Trish Lynch [EMAIL PROTECTED] said: femme:~$ passwd Changing local password for trish Old Password: passwd in free(): error: junk pointer, too high to make sense Abort trap does your log file have a swap space exceeded error? If so, restart your inetd. --mark tinguely To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: passwd issue
In message [EMAIL PROTECTED], mark tinguely wri tes: on Tue May 21 13:07:13 2002, Trish Lynch [EMAIL PROTECTED] said: femme:~$ passwd Changing local password for trish Old Password: passwd in free(): error: junk pointer, too high to make sense Abort trap does your log file have a swap space exceeded error? If so, restart your inetd. That answer doesn't make sense... see malloc(3) for more info. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: passwd issue
On Wed, 22 May 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], mark tinguely wri tes: on Tue May 21 13:07:13 2002, Trish Lynch [EMAIL PROTECTED] said: femme:~$ passwd Changing local password for trish Old Password: passwd in free(): error: junk pointer, too high to make sense Abort trap does your log file have a swap space exceeded error? If so, restart your inetd. That answer doesn't make sense... see malloc(3) for more info. Yeah exactly, BTW, the patch for this issue is currently at http://people.freebsd.org/~jmallett/pam_unix.c.patch DES has been notified by juli. It was the location of the free() that was an issue, it now works for me. -Trish -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: passwd issue
Trish Lynch wrote: took me a while to notice it, because I don;t use passwd on a daily basis FreeBSD femme.listmistress.org 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Tue May 14 00:57:05 EDT 2002 [EMAIL PROTECTED]:/admins/obj/admins/src/sys/FEMME i386 femme:~$ passwd Changing local password for trish Old Password: passwd in free(): error: junk pointer, too high to make sense Abort trap Anyone seen this? is it fixed in -current already, I haven;t seen anything on this list yet except for sudo problems. Get a coredump and do the following: $ gdb passwd passwd.core (gdb) bt It show you backtrace, from it should be clear which function tried to free() junk pointer (usually statically allocated array). -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld broken
Hi, I've got this error during buildworld: building shared library libusbhid.so.0 === lib/libvgl cc -O -pipe -Wall -I/mnt/store/usr/src/lib/libvgl -c /mnt/store/usr/src/lib/libvgl/main.c -o main.o In file included from /mnt/store/usr/src/lib/libvgl/vgl.h:37, from /mnt/store/usr/src/lib/libvgl/main.c:41: /usr/obj/mnt/store/usr/src/i386/usr/include/machine/cpufunc.h:362: conflicting types for `pause' /usr/obj/mnt/store/usr/src/i386/usr/include/unistd.h:119: previous declaration of `pause' *** Error code 1 Stop in /mnt/store/usr/src/lib/libvgl. *** Error code 1 Stop in /mnt/store/usr/src/lib. *** Error code 1 Stop in /mnt/store/usr/src. *** Error code 1 Stop in /mnt/store/usr/src. *** Error code 1 Stop in /mnt/store/usr/src. *** Error code 1 Stop in /mnt/store/usr/src. Martin P.S.: When I re-cvsuped, it didn't upload any files to the lib section To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld broken
On Wed, May 22, 2002 at 05:21:59PM +0200, Martin Kacerovsky wrote: Hi, I've got this error during buildworld: Have you read UPDATING and put what it told you to in make.conf? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld broken
On Wed, 22 May 2002 10:23:31 -0500 David W. Chapman Jr. [EMAIL PROTECTED] wrote: On Wed, May 22, 2002 at 05:21:59PM +0200, Martin Kacerovsky wrote: Hi, I've got this error during buildworld: Have you read UPDATING and put what it told you to in make.conf? This is a genuine error, since it's not a warning. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld broken
On Wed, May 22, 2002 at 10:23:31AM -0500, David W. Chapman Jr. wrote: On Wed, May 22, 2002 at 05:21:59PM +0200, Martin Kacerovsky wrote: Hi, I've got this error during buildworld: Have you read UPDATING and put what it told you to in make.conf? Yes, I've put NO_WERROR=yes into /etc/make.conf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Upgrade instructions are incorrect
Hi!
The upgrade instructions found in src/UPDATING and src/Makefile.inc1
are not quite correct. Suggesting to reboot with the new kernel and
non-matching userland is safer than opposite of course, but does not
always work nor guaranteed to work at all. Here's the safest version
I could think of; it ensures everything is installed using the tools
compatible with the currently running kernel. I'd like your comments
guys as you were touching these instructions in the past.
%%%
Index: UPDATING
===
RCS file: /home/ncvs/src/UPDATING,v
retrieving revision 1.208
diff -u -r1.208 UPDATING
--- UPDATING20 May 2002 13:06:24 - 1.208
+++ UPDATING22 May 2002 15:45:49 -
@@ -958,10 +958,10 @@
make buildkernel KERNCONF=YOUR_KERNEL_HERE
cp src/sys/${MACHINE_ARCH}/conf/GENERIC.hints /boot/device.hints [2]
make installkernel KERNCONF=YOUR_KERNEL_HERE
- reboot in single user [3]
+ shutdown in single user [3]
mergemaster -p [5]
- make installworld
mergemaster [4]
+ make installworld
[1]
reboot
@@ -985,14 +985,17 @@
your own device.hints to reflect your unique hardware
configuration.
- [3] From the bootblocks, boot -s, and then do
+ [3] Do not reboot with the new kernel as your installed
+ binaries may be incompatible with it. Instead, shutdown
+ or reboot with the old kernel in single user mode. If
+ rebooted, from the bootblocks, boot -s, and then do
fsck -p
mount -u /
mount -a
cd /usr/src
adjkerntz -i# if CMOS is wall time
Also, when doing a major release upgrade, it is required that
- you boot into single user mode to do the installworld.
+ you operate in single user mode to do the installworld.
[4] Note: This step is non-optional. Failure to do this step
can result in a significant reduction in the functionality of the
Index: Makefile
===
RCS file: /home/ncvs/src/Makefile,v
retrieving revision 1.256
diff -u -r1.256 Makefile
--- Makefile12 May 2002 16:00:43 - 1.256
+++ Makefile22 May 2002 15:45:49 -
@@ -48,10 +48,10 @@
# 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).
+# 5. `shutdown' or `reboot' into single user mode with the old kernel.
# 6. `mergemaster -p'
-# 7. `make installworld'
-# 8. `mergemaster'
+# 7. `mergemaster'
+# 8. `make installworld'
# 9. `reboot'
#
# See src/UPDATING `COMMON ITEMS' for more complete information.
%%%
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38687/pgp0.pgp
Description: PGP signature
RE: Upgrade instructions are incorrect
On 22-May-2002 Ruslan Ermilov wrote: Hi! The upgrade instructions found in src/UPDATING and src/Makefile.inc1 are not quite correct. Suggesting to reboot with the new kernel and non-matching userland is safer than opposite of course, but does not always work nor guaranteed to work at all. Here's the safest version I could think of; it ensures everything is installed using the tools compatible with the currently running kernel. I'd like your comments guys as you were touching these instructions in the past. Wrong. If you are following the proper upgrade path, then your old binaries will always work with your new kernel. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade instructions are incorrect
On Wed, May 22, 2002 at 01:05:48PM -0400, John Baldwin wrote: Wrong. If you are following the proper upgrade path, then your old binaries will always work with your new kernel. Can I ask you what the proper upgrade path is? In /usr/src/UPDATING : To rebuild everything and install it on the current system. --- make world Build a new kernel, see above. In handbook: make buildworld make buildkernel make installkernel reboot into single use mode make installworld ... Although the world target still exists, you are strongly encouraged not to use it. I thing that are two different ways, aren't they? Which one is right? I'm naturally speaking about upgrading of the -current system, the way of upgrading from 4.X is similar in both documents. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld broken at libvgl [May 22]
cc -O -pipe -march=pentiumpro -Wall -I/usr/src/lib/libvgl -c /usr/src/lib/libvgl/main.c -o main.o In file included from /usr/src/lib/libvgl/vgl.h:37, from /usr/src/lib/libvgl/main.c:41: /usr/obj/usr/src/i386/usr/include/machine/cpufunc.h:362: conflicting types for `pause' /usr/obj/usr/src/i386/usr/include/unistd.h:119: previous declaration of `pause' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: multi default routes in freebsd !?
Vladimir B. Grebenschikov wrote: Without the cooperation of the tother end, you don't have control of the symmetry of the return route. So maybe your packets are round-robin'ed out interfaces, but they all come back through the same interface, because you have no control of the other end. On other end I have providers CISCO router _with_ standard BGP multipath feature, so I have symmetric situation. This is a circular argument. Why can't you use BGP on FreeBSD, then, instead of having to invent this new thing? If interface goes down route will be DOWN by kernel. So it is not problem. No. ,---. | BOX WITH TWO | ,---| DEF. ROUTES |---. route #1 | `---' | route #2 | | ,---. ,---. | ROUTER A | | ROUTER B | `---' `---' | | | | good link dead link The link between the box and router B remains up. Therefore the box fails to note that packets sent via route #2 never get to their destination. No, if link BOX-routerB fails kernel must down one of two routes with same prefix (you said default). Since this is a cable you own, it's highly unlikely. You are much more likely to lose your T1 on the *other side* of router B. If from side of BOX it is noot seen thar carrier (whatever) on link BOX-routerB down - BGP session over this link will down so, BGP software will down route. On the ISP side, which does not affect packets you send, since you are refusing to run BGP, or you won't need the hack. I am not happy with hack pach when one route have more then one gateway, may opinion to allow insert more then one full-featured route to one prefix into kernel FIB, but it is implementation issue. No. The hack for multiple default routes implicitly assumes that it is not a protocol issue that it's trying to solve. The problem you have requires a protocol to solve it. I'm not surprised that it doesn't make you happy: it's not a fix for your problem. [ ... ] Again multipath IS in BGP concept not it is FreeBSD kernel hack for BGP because can't do multipath. Are you saying that this is a feature that the FreeBSD BGP lacks? So it is not a routing protocol solution in any sense of things. As I already said I am not fight for these patches - for me it is ugly hack, I fight for multiple routes for one prefix in kernel. This is the classic seperation of the control plane from the data plane. It is a good thing. The patches only implement, they do not set policy. It is the job of other software to set policy. I don't think you can get what you want without the cooperation of the other end of the link. If you want FEC, then use Bill Paul's FEC code, which does the channel bonding that you seem to want. But you will need the other end to cooperate. I know, anyway thinks like FEC will only solve problem of connecting two boxes by some number of links but will not solve problem of many x many connection. I don't think anything short of source routing can really solve the problem that you are saying you have, because that's the only way you will get to dictate the return path for response packets. My opinion - it is useful feature for FreeBSD kernel, often used now as good routing platform. I already said that I think the code should be committed to the main line kernel, and preserved. May be it is better to discuss a bit what we want to have in kernel exactly ? I think better to have another rt_entry structure for second/third/etc routes for some prefix. Only modifications it will take - lookup algorithm ( I think radix tree code will need some modification ) - forwarding code ( need to choose one of few routes ) - code for add/delete/get routes (something like allow multipath option for addition and remove all for deletion) You seem to imply that this will fix a bug in the FreeBSD BGP implementation; what bug? If it's not a FreeBSD bug, then what problem are you trying to solve? You can't control the return path for responses to packets you send out. How does doing this make FreeBSD more like Cisco? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb breaks world
On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote: GDB 5.2 works pretty well with -current - I've been using it recently. I plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to sort out the CVS magic). I fail to see your patches to gdb 5.2 for the kernel bits. It would be nice to get them in the public view before they are committed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot link C++ apps any more (GCC 3.1)
On Wed, May 22, 2002 at 11:16:11AM +0200, Georg-W. Koltermann wrote: Am Di, 2002-05-21 um 21.35 schrieb Szilveszter Adam: Yes, this is correct. THe libraries libstdc++v3 and libsupc++v3 are not built for the system compiler. You can, however, use ports/lang/gcc31. Ok that works. But, since the system compiler does not include a libstdc++ any more, are there any plans on removing the /usr/bin/c++ and /usr/bin/g++ commands? Seems the are not useful any more, and may conflict with a port which installs these commands. This is only transitional. As soon as it will be ready, the libstdc++ libraries will be built also in the base system. Until such time, you can use this workaround. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade instructions are incorrect
This seems exactly backwards. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb breaks world
On Wednesday 22 May 2002 6:49 pm, David O'Brien wrote: On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote: GDB 5.2 works pretty well with -current - I've been using it recently. I plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to sort out the CVS magic). I fail to see your patches to gdb 5.2 for the kernel bits. It would be nice to get them in the public view before they are committed. I'll certainly put them up for review when I've written them. I've been busy on other things since we last spoke on the subject. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gdb breaks world
On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote: On Monday 20 May 2002 3:49 am, Terry Lambert wrote: Steve Kargl wrote: Use -ggdb instead, thus avoiding DWARF. BZZZT... Thanks for play! -ggdb means to use the most expressive debugging format the compiler knows about. You want -gstabs+ or -gstabs To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot link C++ apps any more (GCC 3.1)
On Wed, May 22, 2002 at 11:16:11AM +0200, Georg-W. Koltermann wrote: are there any plans on removing the /usr/bin/c++ and /usr/bin/g++ commands? Seems the are not useful any more, and may conflict with a port which installs these commands. A port will never install a binary with these names. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: multi default routes in freebsd !?
Terry, FreeBSD has no support for BGP. To get BGP support you install a router daemon. That inserts routes in the routing table in the kernel. The kernel will do all packet forwarding. The kernel has to support two or more routes to the same destination if you are going to do BGP (or OSPF) equal cost multipath. I am sorry but ther is no way around it, if you have two links of equal cost and want to use both, you have to have support for that in the kernel. There are situations where this is needed, and you do get good performance from it if you have many flows. One flow should always take the same path. (I will not say anything about the patch in queston as I have not read it) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld broken at libvgl [May 22]
Yes, femme:/usr/src/include87 grep pause unistd.h int pause(void); femme:/usr/src/sys/i386/include93 grep pause cpufunc.h pause(void) __asm __volatile(pause); voidpause(void); femme:/usr/src/lib/libvgl99 grep include vgl.h #include stdlib.h #include unistd.h #include string.h #include machine/cpufunc.h See where it is? -Trish On Wed, 22 May 2002, walt wrote: cc -O -pipe -march=pentiumpro -Wall -I/usr/src/lib/libvgl -c /usr/src/lib/libvgl/main.c -o main.o In file included from /usr/src/lib/libvgl/vgl.h:37, from /usr/src/lib/libvgl/main.c:41: /usr/obj/usr/src/i386/usr/include/machine/cpufunc.h:362: conflicting types for `pause' /usr/obj/usr/src/i386/usr/include/unistd.h:119: previous declaration of `pause' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Trish Lynch [EMAIL PROTECTED] FreeBSD The Power to Serve Ecartis Core Team [EMAIL PROTECTED] http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems with DP1
Miguel Mendez [EMAIL PROTECTED] writes: I've attached both a backtrace and my dmesg. Is any extra info needed? RTFAQ. #10 0xc01d5899 in panic (fmt=0xc02fed34 setrunnable(2)) at ../../../kern/kern_shutdown.c:647 #11 0xc01dbde2 in setrunnable (td=0xd21952a0) at ../../../kern/kern_synch.c:800 #12 0xc01d8547 in psignal (p=0xd21951a0, sig=23) at ../../../kern/kern_sig.c:1517 Looks like a race: when psignal() was called, the process was stopped or sleeping, but by the time setrunnable() was called, it was running. Something is touching p_stat without acquiring sched_lock (psignal() acquires it before examining p_stat, and holds it until it returns; setrunnable() also acquires it - recusrively since psignal() already holds it) Somebody[tm] should take a close look at p_stat, where it's modified and how it's protected, specifically: des@des ~% current -nw p_stat | grep 'p_stat =[^=]' sys/alpha/linux/linux_machdep.c: 183: p2-p_stat = SRUN; sys/i386/linux/linux_machdep.c: 364:p2-p_stat = SRUN; sys/kern/init_main.c: 329: p-p_stat = SRUN; sys/kern/init_main.c: 665: initproc-p_stat = SRUN; sys/kern/kern_condvar.c: 118: td-td_proc-p_stat = SSLEEP; sys/kern/kern_condvar.c: 152: td-td_proc-p_stat = SRUN; sys/kern/kern_condvar.c: 491: td-td_proc-p_stat = SRUN; sys/kern/kern_fork.c: 414: p2-p_stat = SIDL; /* protect against others */ sys/kern/kern_fork.c: 701: p2-p_stat = SRUN; sys/kern/kern_idle.c: 63: p-p_stat = SRUN; sys/kern/kern_intr.c: 204: p-p_stat = SWAIT; sys/kern/kern_intr.c: 233: p-p_stat = SRUN; /* XXXKSE */ sys/kern/kern_intr.c: 392: p-p_stat = SRUN; sys/kern/kern_intr.c: 552: p-p_stat = SWAIT; /* we're idle */ sys/kern/kern_kthread.c: 112: p2-p_stat = SRUN; sys/kern/kern_mutex.c: 588: td-td_proc-p_stat = SMTX; sys/kern/kern_mutex.c: 725: td1-td_proc-p_stat = SRUN; sys/kern/kern_synch.c: 495: td-td_proc-p_stat = SSLEEP; sys/kern/kern_synch.c: 629: td-td_proc-p_stat = SRUN; sys/kern/kern_synch.c: 674: td-td_proc-p_stat = SRUN; sys/kern/kern_synch.c: 812: td-td_proc-p_stat = SRUN; sys/kern/kern_sig.c: 1441: p-p_stat = SSLEEP; sys/kern/kern_sig.c: 1709: p-p_stat = SSTOP; sys/kern/kern_exit.c: 436: p-p_stat = SZOMB; One of these is touching p_stat without holding sched_lock. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade instructions are incorrect
- Original Message - From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, May 22, 2002 2:04 PM Subject: Re: Upgrade instructions are incorrect This seems exactly backwards. Warner Unlike replying to something without including a shred of context, to half-a-dozen addresses including a mail list, to which all the other recipients are probably subscribed anyways. Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Surecom EP-428X PCCARD in -CURRENT
Morning all ... Just got my Vaio Z505s upgraded to -CURRENT, in order to get my new Surecom Ethernet PCMCIA card to work ... looked in /etc/defaults/pccard.conf, and found the EP-427X card(s) in there, but haven't got a clue on how to setup a similar entry for the -428X to be recognized ... Pointers/directions? Thanks ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem with wi and tcpdump?
Hello I noticed that my wi card crashed when I run tcpdump from /var/log/messages I got this: May 23 02:37:58 Amnesiac kernel: wi0: promiscuous mode enabled May 23 02:38:03 Amnesiac kernel: wi0: watchdog timeout May 23 02:38:04 Amnesiac kernel: wi0: time out allocating memory on card May 23 02:38:04 Amnesiac kernel: wi0: tx buffer allocation failed May 23 02:38:04 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:04 Amnesiac kernel: wi0: mgmt. buffer allocation failed May 23 02:38:04 Amnesiac kernel: wi0: timeout in wi_seek to 0/0; last status 4000 May 23 02:38:04 Amnesiac kernel: wi0: timeout in wi_seek to 0/44; last status 4044 May 23 02:38:04 Amnesiac kernel: wi0: xmit failed May 23 02:38:06 Amnesiac kernel: wi0: promiscuous mode disabled May 23 02:38:08 Amnesiac kernel: wi0: watchdog timeout May 23 02:38:08 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:08 Amnesiac kernel: wi0: tx buffer allocation failed May 23 02:38:08 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:08 Amnesiac kernel: wi0: mgmt. buffer allocation failed May 23 02:38:08 Amnesiac kernel: wi0: timeout in wi_seek to 0/0; last status 4000 May 23 02:38:08 Amnesiac kernel: wi0: timeout in wi_seek to 0/44; last status 4044 May 23 02:38:08 Amnesiac kernel: wi0: xmit failed May 23 02:38:13 Amnesiac kernel: wi0: watchdog timeout May 23 02:38:13 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:13 Amnesiac kernel: wi0: tx buffer allocation failed May 23 02:38:13 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:13 Amnesiac kernel: wi0: mgmt. buffer allocation failed May 23 02:38:13 Amnesiac kernel: wi0: timeout in wi_seek to 0/0; last status 4000 May 23 02:38:13 Amnesiac kernel: wi0: timeout in wi_seek to 0/44; last status 4044 May 23 02:38:13 Amnesiac kernel: wi0: xmit failed May 23 02:38:18 Amnesiac kernel: wi0: watchdog timeout May 23 02:38:18 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:18 Amnesiac kernel: wi0: tx buffer allocation failed May 23 02:38:18 Amnesiac kernel: wi0: failed to allocate 1594 bytes on NIC May 23 02:38:18 Amnesiac kernel: wi0: mgmt. buffer allocation failed May 23 02:38:18 Amnesiac kernel: wi0: timeout in wi_seek to 0/0; last status 4000 May 23 02:38:18 Amnesiac kernel: wi0: timeout in wi_seek to 0/44; last status 4044 May 23 02:38:18 Amnesiac kernel: wi0: xmit failed May 23 02:38:20 Amnesiac kernel: wi0: wi_cmd: busy bit won't clear. May 23 02:38:20 Amnesiac kernel: wi0: detached Finally I had to remove the wi card and then insert it again I'm using a Symbol Spectrum24 Wireless LAN PC Card Another thin I noticed is that dhclient went nuts and started to use 100% CPU untill I killed it. My uname -a: FreeBSD Amnesiac 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu May 23 00:51:13 CEST 2002 root@Amnesiac:/usr/obj/usr/src/sys/Linn i386 /John msg38703/pgp0.pgp Description: PGP signature
Infinite 'make' loops while building ports
Hello, I just upgraded my 4-STABLE machine to -CURRENT via source. Everything seemed to go smoothly and things are running fine, EXCEPT when I try to build *any* of the ports in the ports collection. Every time I run 'make' it gets stuck in an infinite loop and doesn't build the port. Some examples: sysutils/portupgrade: borges[164] # make === Extracting for portupgrade-20020429 Checksum OK for pkgtools-20020429.tar.bz2. === portupgrade-20020429 depends on file: /usr/local/bin/ruby - found === Patching for portupgrade-20020429 === Configuring for portupgrade-20020429 === Building for portupgrade-20020429 === Extracting for portupgrade-20020429 No MD5 checksum file. === portupgrade-20020429 depends on file: /usr/local/bin/ruby - found === Patching for portupgrade-20020429 === Configuring for portupgrade-20020429 === Building for portupgrade-20020429 === Extracting for portupgrade-20020429 No MD5 checksum file. ...[ad infinitum] devel/autoconf213: borges[167] # make === Extracting for autoconf213-2.13.000227_1 Checksum OK for autoconf-000227.tar.bz2. === autoconf213-2.13.000227_1 depends on executable: gm4 - found === Patching for autoconf213-2.13.000227_1 === Applying FreeBSD patches for autoconf213-2.13.000227_1 === Configuring for autoconf213-2.13.000227_1 creating cache ./config.cache checking for gm4... /usr/local/bin/gm4 checking for mawk... no checking for gawk... gawk checking for perl... /usr/bin/perl checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel updating cache ./config.cache creating ./config.status creating Makefile creating testsuite/Makefile === Building for autoconf213-2.13.000227_1 === Extracting for autoconf213-2.13.000227_1 No MD5 checksum file. === autoconf213-2.13.000227_1 depends on executable: gm4 - found === Patching for autoconf213-2.13.000227_1 === Configuring for autoconf213-2.13.000227_1 creating cache ./config.cache checking for gm4... /usr/local/bin/gm4 checking for mawk... no checking for gawk... gawk checking for perl... /usr/bin/perl checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel updating cache ./config.cache creating ./config.status creating Makefile creating testsuite/Makefile === Building for autoconf213-2.13.000227_1 === Extracting for autoconf213-2.13.000227_1 No MD5 checksum file. ...[also ad infinitum until I hit ^C] This is pretty much the case with any port I try to build. I'm sure it's due to some silly thing I missed in the upgrade process somewhere, but after hours of beating my head against a wall, I can't seem to come up with any answers. Anyone else seen this or know what to do about it? Searching Google and the archives yields nothing of any use. TIA, Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Infinite 'make' loops while building ports
On Wed, May 22, 2002 at 06:21:22PM -0700, Scott Reese wrote: Hello, I just upgraded my 4-STABLE machine to -CURRENT via source. Everything seemed to go smoothly and things are running fine, EXCEPT when I try to build *any* of the ports in the ports collection. Every time I run 'make' it gets stuck in an infinite loop and doesn't build the port. Some examples: Are you sure you have an up-to-date ports collection? This bug was fixed a few weeks ago. Kris msg38705/pgp0.pgp Description: PGP signature
Re: Infinite 'make' loops while building ports
On Wed, 2002-05-22 at 18:27, Kris Kennaway wrote: I just upgraded my 4-STABLE machine to -CURRENT via source. Everything seemed to go smoothly and things are running fine, EXCEPT when I try to build *any* of the ports in the ports collection. Every time I run 'make' it gets stuck in an infinite loop and doesn't build the port. Some examples: Are you sure you have an up-to-date ports collection? This bug was fixed a few weeks ago. Yes, I cvsup-ed the ports collection just a few minutes prior to my first email. Should I blow away the whole ports tree and re-grab them? The relevant lines in my cvsup file are as follows: *default host=cvsup14.FreeBSD.org *default base=/usr/local/etc/cvsup *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix ports-all To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems with DP1
On 22-May-2002 Dag-Erling Smorgrav wrote: Miguel Mendez [EMAIL PROTECTED] writes: I've attached both a backtrace and my dmesg. Is any extra info needed? RTFAQ. #10 0xc01d5899 in panic (fmt=0xc02fed34 setrunnable(2)) at ../../../kern/kern_shutdown.c:647 #11 0xc01dbde2 in setrunnable (td=0xd21952a0) at ../../../kern/kern_synch.c:800 #12 0xc01d8547 in psignal (p=0xd21951a0, sig=23) at ../../../kern/kern_sig.c:1517 Looks like a race: when psignal() was called, the process was stopped or sleeping, but by the time setrunnable() was called, it was running. Something is touching p_stat without acquiring sched_lock (psignal() acquires it before examining p_stat, and holds it until it returns; setrunnable() also acquires it - recusrively since psignal() already holds it) Actually, in DP1 psignal() might not have held it the entire time. I fixed that rather recently: revision 1.155 date: 2002/04/13 23:33:36; author: jhb; state: Exp; lines: +22 -36 - Change killpg1()'s first argument to be a thread instead of a process so we can use td_ucred. - In killpg1(), the proc lock is sufficient to check if p_stat is SZOMB or not. We don't need sched_lock. - Close some races in psignal(). In psignal() there is a big switch statement based on p_stat. All the different cases are assuming that the process (or thread) isn't going to change state out from under it. To ensure this is true, just lock sched_lock for the entire switch. We practically held it the entire time already anyways. This also simplifies the locking somewhat and actually results in fewer lock operations. - Allow signotify() to be called with the sched_lock held since psignal() now does that. - Use td_ucred in a couple of places. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
f77, too [Re: cannot link C++ apps any more (GCC 3.1)]
I have trouble that f77 cannot find -lfrtbegin which gcc-3.1 has. For example, the program shown below cannot be linked. ---8--8--8--8--- program killw2k c write(*,*) '\t\b\b' stop end ---8--8--8--8--- Verbose output is like this. $ f77 -v killw2k.f Driving: f77 -v killw2k.f -lfrtbegin -lg2c -lm Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) /usr/libexec/f771 killw2k.f -quiet -dumpbase killw2k.f -version -o /home/nakaji/tmp/ccCXNucA.s GNU F77 version 3.1 [FreeBSD] 20020509 (prerelease) (i386-undermydesk-freebsd) compiled by GNU C version 3.1 [FreeBSD] 20020509 (prerelease). /usr/libexec/elf/as -v -o /home/nakaji/tmp/ccSLtLlz.o /home/nakaji/tmp/ccCXNucA.s GNU assembler version 2.12.0 [FreeBSD] 2002-04-10 (i386-obrien-freebsd5.0) using BFD version 2.12.0 [FreeBSD] 2002-04-10 /usr/libexec/elf/ld -V -dynamic-linker /usr/libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /home/nakaji/tmp/ccSLtLlz.o -lfrtbegin -lg2c -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o GNU ld version 2.12.0 [FreeBSD] 2002-04-10 Supported emulations: elf_i386 /usr/libexec/elf/ld: cannot find -lfrtbegin The kernel is built yesterday. $ uname -a FreeBSD boggy.acest.tutrp.tut.ac.jp 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Wed May 22 13:08:08 JST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NAKAJI i386 -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade instructions are incorrect
At 7:02 PM +0300 5/22/02, Ruslan Ermilov wrote: The upgrade instructions found in src/UPDATING and src/Makefile.inc1 are not quite correct. Suggesting to reboot with the new kernel and non-matching userland is safer than opposite of course, but does not always work nor guaranteed to work at all. If you only boot into single-user mode (so you're not running all the daemons), then what programs would not work? So far I have never run into any problems. I should admit I'm generally less than a month out-of-date when I do a new buildworld, so not all that much has changed. I know that programs like 'ps' or 'top' will produce the wrong results, of course, but I would not expect any catastrophic problems should happen. Much more important, to me, is to catch the cases where the new kernel does *not* work, and I definitely have run into those cases. When a problem like that happens, at the time I find out about the it, the only change I have made is to install the new kernel. At that point it is pretty easy to back out of the problem. If I do the installworld before booting up off a new kernel, then I would definitely be in trouble when I realize the new kernel does not work on my hardware. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade instructions are incorrect
On Wed, May 22, 2002 at 01:05:48PM -0400, John Baldwin wrote: On 22-May-2002 Ruslan Ermilov wrote: Hi! The upgrade instructions found in src/UPDATING and src/Makefile.inc1 are not quite correct. Suggesting to reboot with the new kernel and non-matching userland is safer than opposite of course, but does not always work nor guaranteed to work at all. Here's the safest version I could think of; it ensures everything is installed using the tools compatible with the currently running kernel. I'd like your comments guys as you were touching these instructions in the past. Wrong. If you are following the proper upgrade path, then your old binaries will always work with your new kernel. Grr, right, was smoking a crack. 4.0-R binaries work just fine with the 4.6-RC kernel, and the current technique has a nicety of verifying that the new kernel works before giving you a chance to shoot yourself in a foot. Sorry for the false alarm. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38710/pgp0.pgp Description: PGP signature
