i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> usr.sbin/pstat ... *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sell on eBay and Make a Fortune!
Warning Unable to process data: multipart/mixed;boundary="=_NextPart_000_00C7_80E03A1C.C5823D85"
Re: Recent commit to sys/kern/kern_environment.c broke reading tunables
Maxime Henrion wrote: > Peter Wemm wrote: > > This turned out to be part of the problem. I committed your patch and > > another followup that got the rest of it. The outstanding problems were: > > 1) checkmethod caused use_kenv to be set only once and the next time it > > was called, use_kenv would stay at zero and static hints only got used. > > 2) the termination of the kenvp[] loop could do a null deref. > > > > Anyway, I've committed both your and my changes, it should be working now. > > If anybody else sees problems still, please yell. > > Thanks for taking the time to fix this. I was unavailable the whole day > and tried to see what was causing the problem quickly this morning, but > I expected this to not be sufficient, and it indeed wasn't :-). I think a lot of this was hidden on i386 because of the acpi/pnpbios support, and the fact that a bunch of devices are hard coded in (clock etc). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent commit to sys/kern/kern_environment.c broke reading tunables
Peter Wemm wrote: > This turned out to be part of the problem. I committed your patch and > another followup that got the rest of it. The outstanding problems were: > 1) checkmethod caused use_kenv to be set only once and the next time it > was called, use_kenv would stay at zero and static hints only got used. > 2) the termination of the kenvp[] loop could do a null deref. > > Anyway, I've committed both your and my changes, it should be working now. > If anybody else sees problems still, please yell. Thanks for taking the time to fix this. I was unavailable the whole day and tried to see what was causing the problem quickly this morning, but I expected this to not be sufficient, and it indeed wasn't :-). Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing -Current on Dell Power Edge 4100
On Thu, Apr 25, 2002 at 05:57:50PM -0400, Glenn Gombert wrote: > use (from running NT Server 4.0) to FreeBSD. After installing either i think this is a mbr-problem. try to boot from a dos-floppy and do a fdisk /mbr. afterwards reinstall the freebsd bootloader. hope that helps toni -- Toni Schmidbauer <[EMAIL PROTECTED]> "es gibt 2 dinge die sind unendlich - das universum und die menschliche dummheit. beim universum bin ich mir noch nicht ganz sicher." - a. einstein msg37783/pgp0.pgp Description: PGP signature
Re: Recent commit to sys/kern/kern_environment.c broke reading tunables
Peter Wemm wrote: > Maxime Henrion wrote: > > Hi, > > > > > > I think I may have found the bug. Could someone test the attached patch > > and report if it fixes the problem or not ? > > > > Thanks in advance, > > Maxime > > No joy: > > FreeBSD 5.0-CURRENT #8: Sat Apr 27 13:48:13 PDT 2002 > [EMAIL PROTECTED]:/home/src/sys/alpha/compile/ASHBURTON > Preloaded elf kernel "/boot/kernel/kernel" at 0xfc5f6000. > EB164 > Digital AlphaPC 164SX 533 MHz, 531MHz > 8192 byte page size, 1 processor. > CPU: PCA56 (21164PC) major=9 minor=2 extensions=0x101 > OSF PAL rev: 0x1000600020117 > real memory = 132038656 (128944K bytes) > > > Sorry.. :-/ (I'll look at this today) This turned out to be part of the problem. I committed your patch and another followup that got the rest of it. The outstanding problems were: 1) checkmethod caused use_kenv to be set only once and the next time it was called, use_kenv would stay at zero and static hints only got used. 2) the termination of the kenvp[] loop could do a null deref. Anyway, I've committed both your and my changes, it should be working now. If anybody else sees problems still, please yell. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: d-link dwl520 wireless pci
On Sat, Apr 27, 2002 at 01:07:37AM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Brooks Davis <[EMAIL PROTECTED]> writes: > : If it's going to work the definition for the Linksys WMP11 will do it. > : It will have the wrong name in dmesg, but that doesn't do anything. > : This entry should be changed to reflect the fact that it's actually an > : Intersil Prism 2.5 ID that lazy vendors are using. > > Comments on the following patch? It removes the extra IEEE 802.11 > stuff (which is noise since wi is an 802.11b driver :-) and changes > Linksys WMP11 to the more generic Intersil Prism2.5 PCI. Looks reasionable. You might rip out the PCI bit since the attachment bus is printed seperatly. Since all the lines are changing anyway, you might also sort it. I've been meaning to do that and haven't got arount to it. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg37781/pgp0.pgp Description: PGP signature
Uptime of 8909 days on 5-CURRENT
I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. Here's my dmesg: == boot() called on cpu#1 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 9 8 7 6 5 4 3 2 2 done 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-CURRENT #0: Sat Apr 27 15:17:05 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc059d000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc059d0a8. Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 536788992 (524208K bytes) avail memory = 515842048 (503752K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f1370 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.3 (no driver attached) ahc0: port 0xd400-0xd4ff mem 0xed80-0xed800fff irq 10 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xd000-0xd0ff mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: at device 16.0 on pci0 pci2: on pcib2 fxp0: port 0xb800-0xb83f mem 0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:90:27:bc:09:95 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 8.0 (no driver attached) pci2: at device 8.1 (no driver attached) ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 12949MB [26310/16/63] at ata0-master UDMA66 acd0: DVD-ROM at ata1-master PIO4 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687369 512 byte sectors: 255H 63S/T 4462C) Mounting root from ufs:/dev/ad0s1a SMP: AP CPU #1 Launched! swi_net: unregistered isr number: 18. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Builworld fails on libssh.so while building sftp-server
On Sat, Apr 27, 2002 at 09:52:00PM +0200, Eric Jacoboni wrote: > I think this problem is related to my own /usr/src tree as i don't see > any other messages about such a pb in -Current. As i update with > cvsup, i don't know where this problem could come from. Yeah..most likely explanation is that you're missing some of the cvsup collections from your cvsup file. Kris msg37779/pgp0.pgp Description: PGP signature
Re: Recent commit to sys/kern/kern_environment.c broke reading tunables
Maxime Henrion wrote: > Hi, > > > I think I may have found the bug. Could someone test the attached patch > and report if it fixes the problem or not ? > > Thanks in advance, > Maxime No joy: FreeBSD 5.0-CURRENT #8: Sat Apr 27 13:48:13 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/alpha/compile/ASHBURTON Preloaded elf kernel "/boot/kernel/kernel" at 0xfc5f6000. EB164 Digital AlphaPC 164SX 533 MHz, 531MHz 8192 byte page size, 1 processor. CPU: PCA56 (21164PC) major=9 minor=2 extensions=0x101 OSF PAL rev: 0x1000600020117 real memory = 132038656 (128944K bytes) Sorry.. :-/ (I'll look at this today) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current leaking?
[Story about box running out of swap] Never mind, it turned out to be pilot error as a result of not fixing my smb.conf after switching DSL providers. Sorry to bother y'all. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current leaking?
Since rebooting yesterday I am seeing active memory in top increasing steadily over the course of around 20 minutes (without running X), eventually leading to things like Apr 27 11:05:24 lizzy kernel: swap_pager_getswapspace: failed Apr 27 11:05:24 lizzy kernel: pid 6626 (ld), uid 0, was killed: out of swap space Apr 27 11:06:56 lizzy kernel: swap_pager: out of swap space Apr 27 11:06:56 lizzy kernel: swap_pager_getswapspace: failed As I type this, Active is increasing at a rate of 1MB/second. last pid: 839; load averages: 0.01, 0.06, 0.03 up 8909+09:04:4413:27:27 327 processes: 1 running, 325 sleeping, 1 zombie CPU states: 0.4% user, 0.0% nice, 2.3% system, 11.2% interrupt, 86.0% idle Mem: 111M Active, 37M Inact, 45M Wired, 61M Buf, 307M Free Swap: 256M Total, 256M Free at which point all I can do is reboot the machine. Is anybody else seeing this? Note that this is with today's kernel. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Builworld fails on libssh.so while building sftp-server
Hi, I'm running 5.0-Current (Apr 10, 2002) but i'm unable to update it on my i386 box: ==> secure/libexec/sftp-server cc -O -pipe -march=pentiumpro -DNO_IDEA -o sftp-server sftp-server.o sftp-common.o -lssh -lcrypto /usr/obj/usr/src/i386/usr/lib/libssh.so: undefined reference to `fatal' *** Error Code 1 Thinking i have cvsup between two updates, i have tried several day to update my src tree with cvsup, but without success... Before the build, i've nuked my /usr/obj directory and do a 'make clean cleandir' I think this problem is related to my own /usr/src tree as i don't see any other messages about such a pb in -Current. As i update with cvsup, i don't know where this problem could come from. Any clue? -- Éric Jacoboni, né il y a 1323380374 secondes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent commit to sys/kern/kern_environment.c broke reading tunables
--- Bruce Evans <[EMAIL PROTECTED]> wrote: > On Fri, 26 Apr 2002, Shizuka Kudo wrote: > > > It seems the latest commit of > > sys/kern/kern_environment to current broke the > reading > > of system tunables set by loader.conf. This is > true at > > least for hw.cbb.start_mem of my cardbus bridge. > With > > this latest commit, the hw.cbb.start_mem sysctl > still > > shows the default value after boot up. > > > > Reverting back to version 1.22 solve my problem. > Is > > this unique to me? > > The tunable for this sysctl spelled inconsistently > as > "hw.cbb.start_memory", so rev.1.23 "fixed" finding > it if it is > misspelled in the environment as "hw.cbb.start_mem". > From > dev/pccbb/pccbb.c: > > /* There's no way to say TUNEABLE_LONG to get the > right types */ > u_long pccbb_start_mem = PCCBB_START_MEM; > TUNABLE_INT("hw.cbb.start_memory", (int > *)&pccbb_start_mem); > SYSCTL_ULONG(_hw_cbb, OID_AUTO, start_mem, > CTLFLAG_RD, > &pccbb_start_mem, PCCBB_START_MEM, > "Starting address for memory allocations"); > > Does changing the spelling in the environment to > match the tunable > fix the problem? > > Bruce > This is the problem for me. I overlooked and should have checked it first. Thanks __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic at shutdown, ums related?
On Wed, Apr 24, 2002 at 04:53:32PM -0700, Peter Wemm wrote: > > USB is pretty hosed. :-( > > For a while, removing the mouse didn't get detected and you had to kill moused > manually. Then the removal event happened. A new moused would start but it > was impossible to kill -9 the old moused. If you remove the mouse again, it > instantly panics the box. I've not seen what is happening as I've always been > in X at the time. :-/ > Is that still happening? I've got a usoft usb mouse here, and it works fine for me, pluggin or unplugging - no problems. There do however appear to be hub problems - if a hub gets unplugged the usb bus code loops and doesn't register that it's gone. I'm using uhci though, are you, or are you using ohci? Joe msg37773/pgp0.pgp Description: PGP signature
Re: Recent commit to sys/kern/kern_environment.c broke readingtunables
On Sat, 27 Apr 2002, Maxime Henrion wrote: > I think I may have found the bug. Could someone test the attached patch > and report if it fixes the problem or not ? I hope the problem with rev.1.22 is just spelling inconsistencies in dev/pccbb/pccbb.c and the user's configuration ("hw.cbb.start_mem" in the environment used to match the tunable "hw.cbb.start_memory", but rev.1.22 fixed this). PR 37443 is about the same bug as your patch. It has a slightly larger patch (involving moving the (*cp == '\0') clause into the new else clause). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent commit to sys/kern/kern_environment.c broke readingtunables
On Fri, 26 Apr 2002, Shizuka Kudo wrote: > It seems the latest commit of > sys/kern/kern_environment to current broke the reading > of system tunables set by loader.conf. This is true at > least for hw.cbb.start_mem of my cardbus bridge. With > this latest commit, the hw.cbb.start_mem sysctl still > shows the default value after boot up. > > Reverting back to version 1.22 solve my problem. Is > this unique to me? The tunable for this sysctl spelled inconsistently as "hw.cbb.start_memory", so rev.1.23 "fixed" finding it if it is misspelled in the environment as "hw.cbb.start_mem". From dev/pccbb/pccbb.c: /* There's no way to say TUNEABLE_LONG to get the right types */ u_long pccbb_start_mem = PCCBB_START_MEM; TUNABLE_INT("hw.cbb.start_memory", (int *)&pccbb_start_mem); SYSCTL_ULONG(_hw_cbb, OID_AUTO, start_mem, CTLFLAG_RD, &pccbb_start_mem, PCCBB_START_MEM, "Starting address for memory allocations"); Does changing the spelling in the environment to match the tunable fix the problem? Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent commit to sys/kern/kern_environment.c broke reading t
In message: <[EMAIL PROTECTED]> Ruslan Ermilov <[EMAIL PROTECTED]> writes: : On Sat, Apr 27, 2002 at 01:03:00AM -0600, M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > John Baldwin <[EMAIL PROTECTED]> writes: : > : : > : On 27-Apr-2002 Shizuka Kudo wrote: : > : > It seems the latest commit of : > : > sys/kern/kern_environment to current broke the reading : > : > of system tunables set by loader.conf. This is true at : > : > least for hw.cbb.start_mem of my cardbus bridge. With : > : > this latest commit, the hw.cbb.start_mem sysctl still : > : > shows the default value after boot up. : > : > : > : > Reverting back to version 1.22 solve my problem. Is : > : > this unique to me? : > : : > : No, it seems to be broken for all environment variables : > : on alpha. : > : > It is busted for me as well. I had some not too nice words to say : > when I discovered that :-( : > : This does not have any relation to my src/release/Makefile : commit, does it? (I'm asking because you referred one of : the messages in that thread.) I don't think so, because I'm building kernels in the "old-school" way of config + make. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent commit to sys/kern/kern_environment.c broke reading t
On Sat, Apr 27, 2002 at 01:03:00AM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John Baldwin <[EMAIL PROTECTED]> writes: > : > : On 27-Apr-2002 Shizuka Kudo wrote: > : > It seems the latest commit of > : > sys/kern/kern_environment to current broke the reading > : > of system tunables set by loader.conf. This is true at > : > least for hw.cbb.start_mem of my cardbus bridge. With > : > this latest commit, the hw.cbb.start_mem sysctl still > : > shows the default value after boot up. > : > > : > Reverting back to version 1.22 solve my problem. Is > : > this unique to me? > : > : No, it seems to be broken for all environment variables > : on alpha. > > It is busted for me as well. I had some not too nice words to say > when I discovered that :-( > This does not have any relation to my src/release/Makefile commit, does it? (I'm asking because you referred one of the messages in that thread.) 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 msg37769/pgp0.pgp Description: PGP signature
Re: ipfilter not broken for me
On Sat, Apr 27, 2002 at 04:01:28PM +1000, Darren Reed wrote: > In some email I received from Doug Barton, sie wrote: > > On Fri, 26 Apr 2002, Ruslan Ermilov wrote: > > > > > I tested this on i386 only with 2 days old -CURRENT (today's is > > > broken due to the import of latest IPFilter suite) > > > > I updated to the latest and greatest last night around midnight > > and built/installed -current just fine. What about the ipfilter import is > > broken, and have you let Darren know? I haven't seen anything on the lists > > about it... > > I have not received any email about it. I tested building all the ipfilter > binaries and kernel after the import and came up clean. if ref5 was a bit > quicker > That was probably a local problem on one of the Brian's fast machines where I initially attempted to finally test my patch (unsynched cvsup update?). Sorry for the false alarm, I can't check it right now anyway. 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 msg37768/pgp0.pgp Description: PGP signature
Re: cvs commit: src Makefile Makefile.inc1 src/etc Makefile src/gnu/usr.bin/perl/library Makefile.inc src/release Makefile src/release/scripts catpages-make.sh doFS.sh manpages-make.sh src/secure/usr.bin/ssh Makefile src/secure/usr.sbin/sshd Makefile ...
On Fri, Apr 26, 2002 at 01:44:51PM -0700, Marcel Moolenaar wrote: > On Fri, Apr 26, 2002 at 10:12:14PM +0300, Ruslan Ermilov wrote: > > On Fri, Apr 26, 2002 at 11:59:21AM -0700, Marcel Moolenaar wrote: > > > On Fri, Apr 26, 2002 at 09:26:34PM +0300, Ruslan Ermilov wrote: > > > > > > > I.e., if you built world a month ago, and didn't touch /usr/src > > > > since, and /usr/obj has "buildworld" output for this /usr/src, > > > > and you have booted with this world, it should be okay to start > > > > building today's release. > > > > > > I share my src tree, so I almost always have a /usr/src that's not > > > in sync with the /usr/obj for and on a particular machine. > > > > > > What goes wrong if /usr/src and /usr/obj are out of sync? > > > > > The prerequisite for a successful "make release" is to "installworld" > > first the same world as you are currently running. This is done to > > create a pristine environment (with an empty /etc/make.conf, etc.) > > which is then chroot'ed into. > > I see. Doing a "make everything TARGET_ARCH=foo -DNOCLEAN" should > probably be enough in most cases to sync the object tree, right? > If libraries, kernel, compiler, and headers didn't change, then yes. :-) Otherwise, "make world kernel" and reboot is necessary. So that the subsequent "installworld" of the same world into the chroot'ed environment will give you a _compatible_ (with the currently running kernel) world. > > Also, when I wrote "/usr/src" and "/usr/obj" I didn't mean them > > literally. > > That's mostly academic :-) > > BTW: Do you have plans to remove the exception for non-cross builds > to have the object tree rooted under /usr/obj/$TARGET_ARCH? > The exception was created for make release, but from a pure > cross-building point of view it's inconsistent and is one of > the blockers to build, say, alpha on i386 and doing a native > install on alpha (the other would be having an empty temproot). > Yes, I was planning to do it anyway, for the same reason. You know, it's a matter of removing three lines from Makefile.inc1. :-) It does not of course prevent you from building alpha on i386 and then installing on alpha, all that needs to be done on alpha is: /usr/bin/env MAKEOBJIRPREFIX=/usr/obj/alpha installworld 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 msg37767/pgp0.pgp Description: PGP signature
Re: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
On 2002-04-26 23:52, Poul-Henning Kamp wrote: > >phk 2002/04/26 14:51:08 PDT > > > > Modified files: > >sys/kern kern_tc.c > >sys/sys timepps.h timetc.h > > Log: > > Now that the private parts of timecounters are no longer being fingered > > by other bits of code, split struct timecounter into two. > > Please let me know if you see any changes in timekeeping behaviour > as a result of this series of commits. Given the fact that I'm running xntpd and it syncs the clock with a known good source while online, is it possible that any problems might get `hidden' by xntpd resetting the clock before it runs too different from a correct value? That is, should I disable ntpd for a while? Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent commit to sys/kern/kern_environment.c broke reading tunables
Hi, I think I may have found the bug. Could someone test the attached patch and report if it fixes the problem or not ? Thanks in advance, Maxime Index: subr_hints.c === RCS file: /space2/ncvs/src/sys/kern/subr_hints.c,v retrieving revision 1.4 diff -u -p -r1.4 subr_hints.c --- subr_hints.c17 Apr 2002 13:06:36 - 1.4 +++ subr_hints.c27 Apr 2002 10:42:04 - @@ -150,9 +150,11 @@ res_find(int *line, int *startln, break; if (use_kenv) cp = kenvp[++i]; - while (*cp != '\0') + else { + while (*cp != '\0') + cp++; cp++; - cp++; + } if (*cp == '\0') { cp = NULL; break;
Re: xdm broken on current
John Baldwin <[EMAIL PROTECTED]> writes: > Please back out revision 1.3 of src/etc/pam.d/xdm since it breaks xdm. > xdm core dumps with a signal 6 if there is no session management > configured for it in PAM. Obviously this commmit wasn't actually tested > with xdm (at least not on X 4). Yes, it was. Please show me the output of 'ldd /usr/X11R6/bin/xdm'. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: d-link dwl520 wireless pci
Seems to be working just fine, appropriate portion of dmesg wi0: mem 0xfb80-0xfb800fff irq 2 at device 10.0 on pci0 wi0: 802.11 address: 00:05:5d:da:5f:47 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary 1.00.07, Station 1.03.05 Kinda unrelated I think.. But dunno it just started happening after I ran the patch and recompiled... I have numerous machines, all 10.0.0.x and a wireless networks 10.0.x.x My rl0 card has decided it won't talk to .4 and the .4 machine won't talk to the .2 machine, but both of the machines will talk to the rest of the network just fine (note I did do a cvsup just before I ran your patch). After about 5 to 10 min they start talking just fine.. No user interferance.. They just start to work.. Dunno.. Prolly under wrong thread... But I figured I would throw it out there anyways. However the wireless network works great, well no real diff as far as I can tell. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of M. Warner Losh Sent: Saturday, April 27, 2002 3:08 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: d-link dwl520 wireless pci In message: <[EMAIL PROTECTED]> Brooks Davis <[EMAIL PROTECTED]> writes: : If it's going to work the definition for the Linksys WMP11 will do it. : It will have the wrong name in dmesg, but that doesn't do anything. : This entry should be changed to reflect the fact that it's actually an : Intersil Prism 2.5 ID that lazy vendors are using. Comments on the following patch? It removes the extra IEEE 802.11 stuff (which is noise since wi is an 802.11b driver :-) and changes Linksys WMP11 to the more generic Intersil Prism2.5 PCI. Warner Index: if_wi_pci.c === RCS file: /home/imp/FreeBSD/CVS/src/sys/dev/wi/if_wi_pci.c,v retrieving revision 1.5 diff -u -r1.5 if_wi_pci.c --- if_wi_pci.c 14 Apr 2002 22:08:58 - 1.5 +++ if_wi_pci.c 27 Apr 2002 07:06:57 - @@ -94,13 +94,13 @@ int bus_type; char *desc; } pci_ids[] = { - {0x1638, 0x1100, WI_BUS_PCI_PLX, "PRISM2STA PCI WaveLAN/IEEE 802.11"}, - {0x1385, 0x4100, WI_BUS_PCI_PLX, "Netgear MA301 PCI IEEE 802.11b"}, - {0x16ab, 0x1101, WI_BUS_PCI_PLX, "GLPRISM2 PCI WaveLAN/IEEE 802.11"}, - {0x16ab, 0x1102, WI_BUS_PCI_PLX, "Linksys WDT11 PCI IEEE 802.11b"}, - {0x1260, 0x3873, WI_BUS_PCI_NATIVE, "Linksys WMP11 PCI Prism2.5"}, - {0x10b7, 0x7770, WI_BUS_PCI_PLX, "3Com Airconnect IEEE 802.11b"}, - {0x111a, 0x1023, WI_BUS_PCI_PLX, "Siemens SpeedStream IEEE 802.11b"}, + {0x1638, 0x1100, WI_BUS_PCI_PLX, "PRISM2STA PCI WaveLAN"}, + {0x1385, 0x4100, WI_BUS_PCI_PLX, "Netgear MA301 PCI"}, + {0x16ab, 0x1101, WI_BUS_PCI_PLX, "GLPRISM2 PCI WaveLAN"}, + {0x16ab, 0x1102, WI_BUS_PCI_PLX, "Linksys WDT11 PCI"}, + {0x1260, 0x3873, WI_BUS_PCI_NATIVE, "Intersil Prism2.5 PCI"}, + {0x10b7, 0x7770, WI_BUS_PCI_PLX, "3Com Airconnect"}, + {0x111a, 0x1023, WI_BUS_PCI_PLX, "Siemens SpeedStream"}, {0, 0, 0, NULL} }; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message