Help Needed on dial-in ppp
Hi, I hope that you can help me in this regard. I've setup a freebsd 4.6 server and ppp to dial-in. THe modem answers but NO CARRIER disconnects before authentication. Thanx Pieter ___ http://www.webmail.co.za the South-African free email service To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ppp dialup on 4.6
Hi, I hop eyou can help me, I'm strugling with a ppp setup on 4.6, getting it to work. The modem answers but then as soon as handshake's done it disconnects on No carrier. Please help. Thanx Pieter ___ http://www.webmail.co.za the South-African free email service To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Memory below 1 MB
| See /usr/srcsys/pci/agp* for the sources to agp.ko. | | You can't do what you want to do without using a device driver | to allocate the physical resource on your behalf, since you are | talking about physical memory. Ok, thank you. I'll have a look. | This is what I told you the first time you asked. | | By persisting, you remind me of a non-technical manager I had, Well, what I didn't have very clear when you answered was that it was the *only* way to solve the problem, and consequently tried to continue with which I had done. | If you insist on using VM86, the only real example is in the | X11 source code: | | xsrc/xc/programs/Xserver/hw/xfree86/vga256/drivers/s3_savage/lrmi.c | | If you can wade through it, the only other program that uses | it is in: | | /usr/src/usr.bin/doscmd Again, thank you for the sources. | But it does so much more to emulate the full DOS environment that | the calls you actually need t do something minimal are lost and | buried in the rest of it. Actually, I skim-read some x11 code before starting and found it a little bit messy. Thanks for confirming that observation :) | Good luck using vm86, if you insist on that route. Otherwise, | look at the source code to agp.ko. I have no particular interest in using vm86, but since that is the route I took when I began, I thought it would be possible to continue. Now that you've told me again that what I need is a device driver, I'll have a look at it. Thank you very much for your help. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
problems with IDE interface flash card reader
Hello, I'm trying to install an IDE interface flash card reader (sorry, but I can't give you more information about type, chipset etc; it's just a no name product...). After reboot I get the following error message: dmesg: ... afd0: MODE_SENSE_BIG - ILLEGAL REQUEST asc=0x24 ascq=0x00 error=0x04 afd0: IOMEGA ZIP 100 like IICA-1/01-12-17 floppy device - NO DRIVER! ... The device is connected as master to the second channel of my IDE controler. I think that the kernel does recognize the device but has no specific driver for it. Can somebody please tell me which device has to be inserted into my kernel configuration file. Thanks a lot for your help! Burkard --- uname -a FreeBSD Reineke.Malepartus.DE 4.6-STABLE FreeBSD 4.6-STABLE #12: Fri Aug 2 21:48:08 MEST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/REINEKE i386 bm@Reineke:/usr/home/bm$ --- my current configuration file: ident REINEKE machine i386#i386 family PC hardware architecture maxusers128 #controls the static sizing of system tables options ROOTDEVNAME=\ufs:ad0s1a\ cpu I686_CPU#aka Pentium Pro(tm) options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT#allow user-level ctrl of i386 ldt WINE options SYSVSHM # include support for shared memory options SHMMAXPGS=1025 # max amount of shared memory pages (4k on i386) options SHMALL=1025 # max amount of shared memory (bytes) options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) # max shared memory segment size (bytes) options SHMMIN=2# min shared memory segment size (bytes) options SHMMNI=129 # max number of shared memory identifiers options SHMSEG=33 # max shared memory segments per process options SYSVSEM # include support for semaphores options SEMMAP=31 # amount of entries in semaphore map options SEMMNI=11 # number of semaphore identifiers in the system options SEMMNS=61 # number of semaphores in the system options SEMMNU=31 # number of undo structures in the system options SEMMSL=61 # max number of semaphores per id options SEMOPM=101 # max number of operations per semop call options SEMUME=11 # max number of undo entries per process options SYSVMSG # include support for message queues options MSGMNB=2049 # max characters per message queue options MSGMNI=41 # max number of message queue identifiers options MSGSEG=2049 # max number of message segments in the system options MSGSSZ=16 # size of a message segment MUST be power of 2 options MSGTQL=41 # max amount of messages in the system options PMAP_SHPGPERPROC=300 options DDB #enable kernel debugger options DDB_UNATTENDED #don't drop into DDB for a panic. options KTRACE #kernel tracing options PERFMON #Pentium performance counters options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB options LIBMCHAIN #mbuf management library options LIBICONV#Kernel side iconv library pseudo-device ether #Generic Ethernet pseudo-device loop#Network loopback device pseudo-device bpf 4 #Berkeley packet filter pseudo-device disc#Discard device (ds0, ds1, etc) pseudo-device sl 1 #Kernel SLIP pseudo-device ppp 1 #Kernel PPP pseudo-device tun #Packet tunnel pseudo-device gif 4 #IPv6 and IPv4 tunneling pseudo-device faith 1 #IPv6-to-IPv4 relaying (translation) pseudo-device stf #6to4 IPv6 over IPv4 encapsulation options RANDOM_IP_ID#causes ID field in IP packets to be randomized options ICMP_BANDLIM#enables icmp error response bandwidth limiting options FFS #Fast filesystem options MFS #Memory File System options NFS_NOSERVER#Disable the NFS-server code. options CD9660 #ISO 9660 filesystem options KERNFS #Kernel filesystem options
JailNG.
Hello there... When jailNG will be commited? -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg36152/pgp0.pgp Description: PGP signature
Are you ready to Invest now
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D0_85E10D4E.D7384B52
Re: release variability
At 00:41 08/08/2002 -0700, Terry Lambert wrote: Colin Percival wrote: If two people `make release` on different machines, how much difference will there be between the results? Obviously the kernel will be different because it contains the user and host names from its build; should everything else be the same? Assuming identical source trees, and that the build takes place on systems installed with the same software, the only things that should be different are user, host, and time stamps. The kernel is one place that's stamped; the boot code is another. And, unfortunately, there's a hell of a lot more. I've grabbed the 4.6-RELEASE source tree and ran a make world - chroot - make world twice, and here's what I found: /kernel, /boot/loader, and /boot/pxeboot all contain user, host, time, and date stamps, as expected. All .a files (126 in /usr/lib, one in /usr/libdata/perl/5.00503/mach/auto/DynaLoader) contain some sort of indices of .o files, including seconds-since-epoch stamps User, host, time, and date stamps are found in /etc/mail/freebsd.cf /usr/sbin/named /usr/libexec/named-xfer Time and date stamps are found in: /usr/bin/suidperl /usr/bin/ntpq /usr/sbin/ntp(d|date|dc|timeset|trace) /usr/sbin/isdn(d|debug|monitor|phone|telctl) /usr/libdata/perl/5.00503/mach/perllocal.pod Date stamps are found in: /usr/sbin/ppp /var/db/port.mkversion /usr/share/doc/usd/(07.mail|13.viref|18.msdiffs|19.memacros|20.meref)/paper.ascii.gz (once you ungzip them) /usr/share/perl/man/man3/(Config|DynaLoader).3.gz (once you ungzip them) Files which are always the same size, but seem to have completely different contents: /usr/share/games/fortune/*.dat /var/games/phantasia/void This raises two questions: 1. Is there any way I can set up my system to consistently build the same world? The user and host are of course easy to fix; I'd consider running a daemon to reset my clock every second in order to keep the time stamps consistent, except that I don't think it would work, and I worry that it might break `make` anyway. 2. Is this really a desireable state of affairs at all? As it is, it is practically impossible for someone to `make release` on their own and compare their version to the official version to ensure that the build was correct. Reproducibility and verifiability are rather important matters when it comes to security. Colin Percival To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: release variability
On Sat, 2002-08-10 at 15:13, Colin Percival wrote: [...] This raises two questions: 1. Is there any way I can set up my system to consistently build the same world? The user and host are of course easy to fix; I'd consider running a daemon to reset my clock every second in order to keep the time stamps consistent, except that I don't think it would work, and I worry that it might break `make` anyway. I think what you're trying to do here is impossible. Every condition would have to be the same as on the initial build machine, and even then, your time will not always match. Whatever you're trying to do, it seems like the wrong solution to me... 2. Is this really a desireable state of affairs at all? As it is, it is practically impossible for someone to `make release` on their own and compare their version to the official version to ensure that the build was correct. Reproducibility and verifiability are rather important matters when it comes to security. There are better ways to check the integrity of the code. The most simple way I can think of, is if you e.g. install from a cd, check the md5sum. (Maybe a md5sum/pgp key could be distributed with the announcement itself?) If your code is clean, so will be your compiled software. Except when you have something (somebody?) in resident memory that screws it after installation, but this is unlikely if you just reinstalled the whole machine, and there's nothing you can do about that either way. If you sync from source and want to build a full release when one is made instead of downloading an iso (which is a pretty reasonable and common thing to do, I think), you have AFAIK no way to check if the source has not been tampered with. It might be better to download the release source packages then, those contain md5sums: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.6-RELEASE/src/ ,,, but this seems like something you don't want to do? wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: release variability
Colin Percival wrote: At 00:41 08/08/2002 -0700, Terry Lambert wrote: Colin Percival wrote: If two people `make release` on different machines, how much difference will there be between the results? Obviously the kernel will be different because it contains the user and host names from its build; should everything else be the same? Assuming identical source trees, and that the build takes place on systems installed with the same software, the only things that should be different are user, host, and time stamps. The kernel is one place that's stamped; the boot code is another. And, unfortunately, there's a hell of a lot more. [ ... good list of generated files containing timestamps ... ] Files which are always the same size, but seem to have completely different contents: /usr/share/games/fortune/*.dat /var/games/phantasia/void This is disturbing. This raises two questions: 1. Is there any way I can set up my system to consistently build the same world? The user and host are of course easy to fix; I'd consider running a daemon to reset my clock every second in order to keep the time stamps consistent, except that I don't think it would work, and I worry that it might break `make` anyway. For library files, there's nothing you can do, since it's the archive date, and .o files are assembled from multiple source files. Some of the generated files with timestamps really want to use the timestamp of the modification date of the sources, rather than the creation date of hte object. Correcting this is relatively minor; it's one of the reasons I suggested NFS mounting the sources; I imagine you would have a much worse time otherwise. 2. Is this really a desireable state of affairs at all? As it is, it is practically impossible for someone to `make release` on their own and compare their version to the official version to ensure that the build was correct. Reproducibility and verifiability are rather important matters when it comes to security. I personally agree. The hardest part has got to be the archive files; I don't see how it could be avoided, without destroying information, at least in the archive update case, and probably in the archive recreation from object files case. The main problem here is that there isn't a derivation date stamp on object files, that can be used instead of the date of last modification or creation date. I think changing the modification date vs. create date would break make. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
m_freem() in tcp_respond()
Hi, there.
In tcp_respond() from /sys/netinet/tcp_subr.c,
m_freem(m-m_next) is called without any checks.
I think it's better to check m-m_next is not NULL, at least.
--- /sys/netinet/tcp_subr.c.ORG Thu Jul 18 19:47:04 2002
+++ /sys/netinet/tcp_subr.c Sun Aug 11 04:00:09 2002
@@ -393,7 +393,8 @@
bcopy((caddr_t)th, (caddr_t)nth, sizeof(struct tcphdr));
flags = TH_ACK;
} else {
- m_freem(m-m_next);
+ if (m-m_next)
+ m_freem(m-m_next);
m-m_next = 0;
m-m_data = (caddr_t)ipgen;
/* m_len is set later */
Regards,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: m_freem() in tcp_respond()
FUJITA Kazutoshi wrote:
--- /sys/netinet/tcp_subr.c.ORG Thu Jul 18 19:47:04 2002
+++ /sys/netinet/tcp_subr.c Sun Aug 11 04:00:09 2002
@@ -393,7 +393,8 @@
bcopy((caddr_t)th, (caddr_t)nth, sizeof(struct tcphdr));
flags = TH_ACK;
} else {
- m_freem(m-m_next);
+ if (m-m_next)
+ m_freem(m-m_next);
m-m_next = 0;
m-m_data = (caddr_t)ipgen;
/* m_len is set later */
NO.
It is better to know that it's not NULL before it gets there.
If you check everything everywhere to see if it's NULL before
you do anything, then you are going to speen all your time
comparing things to NULL, rather than doing real work.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: m_freem() in tcp_respond()
m_freem() already checks to see if it gets passed in a NULL pointer. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SMP P4 Xeons out there?
Hey folks, Anyone other there with multiprocessor P4 Xeon systems with Hyperthreading enabled that are seeing 4 CPUs show up on boot? If you are, can you mail me the output of 'mptable'? It appears you need to enumerate CPUs out of ACPI if you want the logical CPUs to show up. FreeBSD doesn't appear to support this (yet -- correct me if I've misread the MP init code), but some people are seeing 4 CPUs anyway. I'm curious if those systems are modifying the mptable for the benefit of non-ACPI systems. Systems that don't modify the mptable (board/chipset): Intel SE7500WV2 (Intel E7500) Dell PE2650 (Serverworks GC-HE) If anyone understands the Proper(tm) way to support hyperthreaded CPUs and can explain it that would be neat too. Intels docs are a little lean on the matter. Thanks! -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: m_freem() in tcp_respond()
From: Terry Lambert [EMAIL PROTECTED]
Subject: Re: m_freem() in tcp_respond()
Date: Sat, 10 Aug 2002 13:19:47 -0700
Message-ID: [EMAIL PROTECTED]
It is better to know that it's not NULL before it gets there.
If you check everything everywhere to see if it's NULL before
you do anything, then you are going to speen all your time
comparing things to NULL, rather than doing real work.
Hmmm...
But my -STABLE box crashes at here when boot.
# gdb -k kernel.debug vmcore.0
GNU gdb 4.18 (FreeBSD)
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 0x005d2000
initial pcb at physical address 0x004e2880
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc021ef9c
stack pointer = 0x10:0xdc319cd0
frame pointer = 0x10:0xdc319cd8
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 = 197 (wnnstat)
interrupt mask = net tty
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc03b872c
stack pointer = 0x10:0xdc319ae4
frame pointer = 0x10:0xdc319aec
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = 197 (wnnstat)
interrupt mask = net tty
panic: from debugger
Uptime: 38s
dumping to dev #ad/0x30001, offset 1311872
dump ata0: resetting devices .. done
639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619
618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598
597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580 579 578 577
576 575 574 573 572 571 570 569 568 567 566 565 564 563 562 561 560 559 558 557 556
555 554 553 552 551 550 549 548 547 546 545 544 543 542 541 540 539 538 537 536 535
534 533 532 531 530 529 528 527 526 525 524 523 522 521 520 519 518 517 516 515 514
513 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493
492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472
471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451
450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430
429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409
408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 39
2 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371
370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350
349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329
328 327 326 325 324 323 322 321 320 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 /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0202e73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc02032b1 in panic (fmt=0xc03edd84 from debugger)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc014cbb9 in db_panic (addr=-1071517796, have_addr=0, count=-1,
modif=0xdc319b3c ) at
Re: m_freem() in tcp_respond()
Ian Dowse just fixed this. Please upgrade.
On Sun, Aug 11, 2002 at 08:22:59AM +0900, FUJITA Kazutoshi wrote:
From: Terry Lambert [EMAIL PROTECTED]
Subject: Re: m_freem() in tcp_respond()
Date: Sat, 10 Aug 2002 13:19:47 -0700
Message-ID: [EMAIL PROTECTED]
It is better to know that it's not NULL before it gets there.
If you check everything everywhere to see if it's NULL before
you do anything, then you are going to speen all your time
comparing things to NULL, rather than doing real work.
Hmmm...
But my -STABLE box crashes at here when boot.
# gdb -k kernel.debug vmcore.0
GNU gdb 4.18 (FreeBSD)
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 0x005d2000
initial pcb at physical address 0x004e2880
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc021ef9c
stack pointer = 0x10:0xdc319cd0
frame pointer = 0x10:0xdc319cd8
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 = 197 (wnnstat)
interrupt mask = net tty
panic: from debugger
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc03b872c
stack pointer = 0x10:0xdc319ae4
frame pointer = 0x10:0xdc319aec
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = 197 (wnnstat)
interrupt mask = net tty
panic: from debugger
Uptime: 38s
dumping to dev #ad/0x30001, offset 1311872
dump ata0: resetting devices .. done
639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619
618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598
597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580 579 578 577
576 575 574 573 572 571 570 569 568 567 566 565 564 563 562 561 560 559 558 557 556
555 554 553 552 551 550 549 548 547 546 545 544 543 542 541 540 539 538 537 536 535
534 533 532 531 530 529 528 527 526 525 524 523 522 521 520 519 518 517 516 515 514
513 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493
492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472
471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451
450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430
429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409
408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 39
2 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372
371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351
350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330
329 328 327 326 325 324 323 322 321 320 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 /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0202e73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc02032b1 in
arplookup: host is not on local network
Greetings, I have a FreeBSD box being colocated. Every few seconds, I get the following message: /kernel: arplookup 216.187.x.x failed: host is not on local network As I understand, this 216.187.x.x machine is acting as a proxy arp. I think it's supposed to be completely transparent, but evidently my box is noticing. I am on a 64.69.x.x address. I have tried explicitly setting host routes, with no results. I have tried setting a permanent arp entry for that IP address, but then I get: /kernel: arp: 00:d0:b7:bb:86:ec attempts to modify permanent entry for 216.187.x.x on xl0 even though this is the hardware address I've set for the explicit arp. This has polluted my server logs beyond my tolerance, and I am about to cave and just comment these out of the kernel. Any suggestions on how to rectify this? thanks, sh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: release variability
At 11:58 10/08/2002 -0700, Terry Lambert wrote: Colin Percival wrote: Files which are always the same size, but seem to have completely different contents: /usr/share/games/fortune/*.dat /var/games/phantasia/void This is disturbing. Upon further investigation, it turns out that the fortune files vary because `strfile` is instructed to randomize the order of the fortunes; as far as I can tell, this serves no purpose since `fortune` picks a random fortune anyway. (Two line patch to /usr/src/games/fortune/datfiles/Makefile) /var/games/phantasia/void is explicitly randomly generated; I'm not sure what purpose it serves. For library files, there's nothing you can do, since it's the archive date, and .o files are assembled from multiple source files. Some of the generated files with timestamps really want to use the timestamp of the modification date of the sources, rather than the creation date of hte object. Correcting this is relatively minor; it's one of the reasons I suggested NFS mounting the sources; I imagine you would have a much worse time otherwise. Actually I didn't NFS mount the sources, since I didn't understand how that would help. I'll try that and see if there it makes any difference. The hardest part has got to be the archive files; I don't see how it could be avoided, without destroying information, at least in the archive update case, and probably in the archive recreation from object files case. Could someone point me towards information on what these values are used for? Colin Percival To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: release variability
Colin Percival wrote: The hardest part has got to be the archive files; I don't see how it could be avoided, without destroying information, at least in the archive update case, and probably in the archive recreation from object files case. Could someone point me towards information on what these values are used for? man ar See -o and -u. The -u opinion in particular is used to updated the archive contents with only the new files. Say you have: LIB=foo SRCS=q.c r.c s.c t.c u.c v.c libfoo.a contains q.o, r.o, s.o, t.o, u.o, v.o And you modify only s.c, and rebuild. If your Makefile, etc., is set up properly, then only s.o will be updated in the archive, because only the s.o file has a date later than the date of the object file in the archive. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
