FreeBSD 5.2-BETA installation failed on VMware 4
I can remember that somebody already reports somewhere, but this bug(?) is still standing there, so here's again: I failed to install recent 5-current (5.2-BETA as of Nov/29/2003) to VMware Workstation 4.x (tested with 4.0.5 and 4.1 beta). I've observed that: * It seems that FreeBSD misunderstands that the computer is a SMP machine or something like that. * 'set kern.smp.disabled=1 to loader prompt' is not working as my expectation, it seems that SMP feature is still available. * After acd/ad devices are found by kernel, VMware panics. I've also reported this problem to VMware Inc. However, it seems that there's something troubles or bugs on FreeBSD. Anybody knows what's the problem, how to fix it, or any workarounds? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Teach '-m' option of bsdlabel(8) to sunlabel(8)
I'd like to try to bulid FreeBSD/sparc64 on i386 box, but due to the lack of bsdlabel(8)'s '-m' option (set machine archtecture) on sunlabel(8), newfs(8) cannot work. Question: Anybody working on teaching '-m' option to sunlabel(8)? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Teach '-m' option of bsdlabel(8) to sunlabel(8)
Self followup... matusita I'd like to try to bulid FreeBSD/sparc64 on i386 box, but matusita due to the lack of bsdlabel(8)'s '-m' option (set machine matusita archtecture) on sunlabel(8), newfs(8) cannot work. I'm confused something. The fact that newfs(8) on i386 cannot newfs a filesystem which is sunlabel(8)ed is true, but it does NOT come with sunlabel(8) itself. Obviously sunlabel(8) doesn't need -m option since it is used on on sparc64 :-) Anyway how can I newfs a filesystem for sparc64 on i386 box? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Teach '-m' option of bsdlabel(8) to sunlabel(8)
brooks I don't think you can because our UFS on disk format is byte brooks order dependent. Someone probalby needs to import the NetBSD brooks endien-independence stuff. My friends told me that I can do with a help of geom_sunlabel, and it's right. -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: release build problems, drivers.flp: file system is full
toha Release build fails: toha drivers.flp: file system if full. Since yesterday. toha Can somebody remove some driver from drivers.conf? No, don't do that. Since we have only 3 floppies, simply removing some modules may mean it cannot use it while installing FreeBSD. Fortunately we have some rooms in mfsroot.flp, we can move some drivers (back?) to there. I'm just trying which module(s) can be moved or not. -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 20031021 snapshot install has glitches
asmodai You cannot set the root password as passwd dumps core on a signal 12. % pwd /usr/src % echo **/*(.)|xargs grep 'You cannot set the root password' % It should not be an message of passwd(1) or other sources, so it would be hard to reproduce (if we can) what you've seen. What you've tried and got an error? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh being dodgy, or pipe code ishoos?
jmallett Anyone with insight into this? Me Too with zsh 4.0.6 on 5-current as of early June/2003. -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD/alpha kern.flp flood
It seems that kern.flp for FreeBSD/alpha is flooded (tested on FreeBSD/i386). Maybe several kbytes should be removed from the kernel: % du -s image.kern 1420image.kern % ls -lR image.kern total 1209 drwxr-xr-x 2 root wheel 512 Mar 28 00:57 boot -r-xr-xr-x 1 root wheel 1223388 Mar 28 00:57 kernel.gz image.kern/boot: total 210 -rw-r--r-- 1 root wheel 764 Mar 28 00:57 device.hints -r-xr-xr-x 1 root wheel 200864 Mar 28 00:57 loader -rw-r--r-- 1 root wheel 245 Mar 28 00:57 loader.rc Anybody have an idea to reduce the size? -- - Makoto `MAR' Matsushita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any ideas why we can't even boot a i386 ?
drosih GENERIC +VMWARE-friendly settings It'll be unneeded for further VMware releases. At least, very recent 5-current runs quite fine on my VMware 4 beta. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: performance / /usr/src/UPDATING
kuku Can this be switched off with a single switch in the Makefile? No, or you misunderstand what FreeBSD-current is. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
keramida Just in case anyone tries to build today's current and sees keramida it fail because of boot2, you can always set BOOT2_UFS=UFS1_ONLY keramida or BOOT2_UFS=UFS2_ONLY in your make.conf and rebuild. It should work, but it can't be used for a release distribution:) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
riccardo Is this stuff really needed on a boot floppy? Maybe we can leave riccardo only I486_CPU? What about removing also device eisa and/or bpf? riccardo (I'm just curious, don't expect to be an expert :-) The bpf is required for DHCP client. We cannot remove it, or cannot network install FreeBSD via fetch-IPv4-address-by-DHCP-only network. I doubt if we can already livin' IPv6-only network :-) I have no idea about eisa; I don't have any (PCs and cards). But if eisa is removed, we lost some users who has EISA-based PCs so it may be avoided. Note that both devices cannot load as a kernel module at this time; removing these devices means that we cannot use them for installation. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
ticso What about some uncommon ISA scsi controllers like stg and ncv? ticso Both are available as a module. Maybe it's ok, do you know whether stg/ncv kernel modules work as they should be? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
We (at least, I) don't know exactly that which options and/or drivers can be picked out from the kernel for kern.flp... maybe it's chance to find out all of them. jhay What about moving the slip driver (sl) to the drivers floppy? I know its jhay not much, but it is enough to make things fit on the floppy again. Maybe that's also an option; do you know if_sl works as kernel module, as expected? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
Maybe it's ok, do you know whether stg/ncv kernel modules work as they should be? ticso No - I just can say that they got build on my system. ticso I can't test either, because I don't have such cards. Ah, ok, thank you. Anybody in this list knows? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/alpha make-release on FreeBSD/i386: dislabel problem
phk Not yet. I think adding a -m architecture flag to disklabel is the phk way around this problem, but have not had time to do so. Thanks, I'm waiting until you have enough time to do since I have little knowledge about this issue:) BTW, what's changes do you imagine? Make a table which holds architecture name, label size, offset, etc and use it in disklabel.c:makebootarea()? Maybe it requires some changes in sys/disklabel.h since LABELOFFSET and other macros are defined inside of architecture-dependent #ifdefs... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD/i386 kern.flp flooding again
It seems that our kenrel for kern.flp does not fit again :-( (Quote from make release logfile) + mdconfig -a -t vnode -f /R/stage/floppies/kern.flp + MDDEVICE=md1 + [ ! -c /dev/md1 ] + disklabel -w -B -b /R/stage/trees/base/boot/boot md1 fd1440 + newfs -i 8 -o space -m 0 /dev/md1c fstab: /etc/fstab:0: No such file or directory /dev/md1c: 1.4MB (2880 sectors) block size 4096, fragment size 512 using 1 cylinder groups of 1.41MB, 360 blks, 32 inodes. super-block backups (for fsck -b #) at: 32 + mount /dev/md1c /mnt + [ -d /R/stage/image.kern ] + set -e + cd /R/stage/image.kern + find+ cpio -dump . -print /mnt cpio: write error: No space left on device *** Error code 1 (End quote) There are about 1414kbytes in image.kern directory. Note that kern.flp has about 1407kbytes (see below); reduce 7k is required. % pwd /R/stage/image.kern % ls -lR total 1313 drwxr-xr-x 2 root wheel 512 Feb 16 09:31 boot -r-xr-xr-x 1 root wheel 1327754 Feb 16 09:31 kernel.gz ./boot: total 100 -rw-r--r-- 1 root wheel 2352 Feb 16 09:31 device.hints -rwxr-xr-x 1 root wheel 97639 Feb 16 09:31 loader -rw-r--r-- 1 root wheel245 Feb 16 09:31 loader.rc % Apparantly, we have a chance to gzip /boot/loader: % cd boot % gzip loader % ls -l loader.gz -rwxr-xr-x 1 root wheel 90372 Feb 16 09:31 loader.gz % And, it fits to 1.44MB floppy again: % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1c 1407 1404 3 100%/mnt % ls -lR /mnt total 1305 drwxr-xr-x 2 root wheel 512 Feb 16 20:16 boot -r-xr-xr-x 1 root wheel 1327754 Feb 16 09:31 kernel.gz /mnt/boot: total 99 -rw-r--r-- 1 root wheel 2352 Feb 16 09:31 device.hints -rwxr-xr-x 1 root wheel 90372 Feb 16 09:31 loader.gz -rw-r--r-- 1 root wheel245 Feb 16 09:31 loader.rc There are ONLY 3 kbytes left, maybe it flood again in very near future:) Anyway that's all about current 5-current kern.flp problem -- How do you think about this? May I gzip /boot/loader on kern.flp? Do you know any drivers/features which can drop from the kernel on kern.flp? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
Ouch.. matusita % gzip loader I've forgotten that this loader is already kgzip(8)ed, ignore me. Sorry. Ok, we have to shrink at least 7kbytes of kernel on kern.flp. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
Sorry for spamming again. matusita Ok, we have to shrink at least 7kbytes of kernel on kern.flp. If you are serious about this, attached below is a current kernel configuration file for kern.flp kernel named BOOTMFS (attention: it is only just for boot floppy, not GENERIC nor default installed kernel). Anybody knows what happen if _KPOSIX_PRIORITY_SCHEDULING is removed? -- - Makoto `MAR' Matsushita # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.376 2003/02/13 22:24:43 obrien Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident BOOTMFS #To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints #Default places to look for devices. options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options MD_ROOT #MD is a potential root device options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev # output. Adds ~128k to driver. # output. Adds ~215k to driver. # Debugging for use in -current # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # RAID controllers interfaced to the SCSI subsystem device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss# Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options! device iir # Intel Integrated RAID # SCSI peripherals device scbus # SCSI bus (required) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD # RAID controllers device aac # Adaptec FSA RAID device aacp# SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device pst # Promise Supertrak SX6000 # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm
FreeBSD/alpha make-release on FreeBSD/i386: dislabel problem
I've tried to do make release of FreeBSD/alpha on FreeBSD/i386 box last night, and found that follow error while generating drivers.flp: + export BLOCKSIZE=512 + [ /R/stage/floppies/drivers.flp = -s ] + do_size= + FSIMG=/R/stage/floppies/drivers.flp + shift + RD=/R/stage + shift + MNT=/mnt + shift + FSSIZE=1440 + shift + FSPROTO=/R/stage/driversfd + shift + FSINODE=8 + shift + FSLABEL=fd1440 + shift + [ -f /R/stage/trees/base/boot/boot ] + BOOT1=-B -b /R/stage/trees/base/boot/boot + deadlock=20 + uname -r + dofs_md + true + rm -f /R/stage/floppies/drivers.flp + [ x != x ] + dd of=/R/stage/floppies/drivers.flp if=/dev/zero count=1440 bs=1k + mdconfig -a -t vnode -f /R/stage/floppies/drivers.flp + MDDEVICE=md0 + [ ! -c /dev/md0 ] + disklabel -w -B -b /R/stage/trees/base/boot/boot md0 fd1440 disklabel: bootstrap doesn't leave room for disk label *** Error code 2 Stop in /usr/src/release. If my understandings are correct, this is because disklabel(8) kicked is FreeBSD/i386 native binary which doesn't know about FreeBSD/alpha disklabel structure or whatever. Are there any workaround/fix? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Comments welcome: 1-line patch: teach FTP_PASSIVE_MODE to${CHROOT}/mk
I'd like to commit following patch to src/release/Makefile. Here's background: A user may want to build their own FreeBSD distribution. During the release build, pkg_add(1) runs within chroot sandbox to install mkisofs(8) iff MAKE_ISOS=YES. Imagine what's happen if the user is living behind the Internet firewall -- pkg_add(1) try to fetch the package from outside but it can't since firewall usually doesn't allow outer-to-inner connections. According to the pkg_add(1) manpage, FTP_PASSIVE_MODE environment variable enables passive ftp connections. You know there are many solutions about this issue. IIRC, it can be easily fixed with passing FTP_PASSIVE_MODE variable to the chroot sandbox. Following patch was tested on FreeBSD/i386, and it should work on other archs since this is arch-independent code. If there's no problem around, I'll commit it later. Any comments and/or suggestions are welcome. -- - Makoto `MAR' Matsushita Index: Makefile === RCS file: /home/ncvs/src/release/Makefile,v retrieving revision 1.749 diff -u -r1.749 Makefile --- Makefile4 Feb 2003 16:07:20 - 1.749 +++ Makefile10 Feb 2003 11:19:41 - @@ -430,6 +430,7 @@ DOMINIMALDOCPORTS \ EXTRA_SRC \ FIXCRYPTO \ + FTP_PASSIVE_MODE \ KERNELS \ KERNEL_FLAGS \ MAKE_ISOS \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release.9 fails ... ?
scrappy I found the release man page this evening, after more searching, and scrappy understand from it that a simple: From release(7): floppies Generate a new set of boot floppies. This will call the release.5, release.9, and release.10 targets to re-generate the floppy images of a previous ``make release''. This is most often used to build custom boot floppies. Be aware the word re-generate (not generate); you'll need to run make release first. In theory, you can use floppies target after you've run release.[1-4] (and doc.[12] if you want RELNOTESng documents). scrappy Known bug, or is there another step that I need to run first? Maybe a bug, but it is an expected behavior. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-20021027-CURRENT.iso cdrom will not mount
jwdThe iso(s) boot correctly and sysinstall works fine. The disks jwd are formated and newfs'd correctly. However, when sysinstall jwd tries to mount the cdrom, the following error is received: jwd Error mounting /dev/acd0c on /dist: Operation not supported by device (19). Which type of machine did you try? I've heard exactly the same error on the VMware's virtual machine. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-20021025-CURRENT snapshot
jwd A new 5.0-20021025-CURRENT snapshot is available jwd via anonymous ftp at usw2.freebsd.org: Wonderful! Is it a time to switch back 'current.FreeBSD.org' name to that machine? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-20021025-CURRENT snapshot
attila only problem with snapshot.jp at this point is that attila release does not build: md0 problems That should be a local problem IMO, and I believe it was fixed several hours before (ya, sorry for being lazy.) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
jroberson I suspect that there is some other bug then. 1/2 of your jroberson memory should not be consumed by kernel malloc. Do you jroberson have an abnormally large MD or something? MD devices are used to create installation floppies but no, it should be 1.44MB/2.88MB size, relatively small one. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_maptoosmall...
tlambert2 The worst case failure with my Ugly patch should be that tlambert2 things hang, and quit running completey. I've emailed to the list that I've tried your patch but it cannot boot (actually it boots, but panics immediately.) Maybe I'm using different time of source code. Which 5-current source code did you use to write the patch? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol__sF)
carl I fail to see how a reduction of hours (even just one) is carl insignificant to someone on a dial-up connection. Time is money carl for some people; even a meager three hours. Don't you think 30+ hours of time to fetch an ISO image is _not_ wasting of money? carl Again, I fail to see how a reduction in download time for -anyone- is carl insignificant. Can you explain how I am missing the point? These ISO images are build everyday. That means, after 24 hours have past, new ISO image are available. Yes, compressing images help less downloading time and it'll be helpful for someone. However, - For xDSL and/or optical line users, reducing time is maybe less than hours. It can be considered as a range of error. - For slow analog modem users, reducing time is about several hours. However, they still have to spend more than 1 day to fetch. It can be also considered as a range of error. so I think there are small number of peoples who get lots of merits by compressed ISO images. The costs of compressing images is small, but not zero. Somebody already argues to me that hey, please stop compressing ISO images. You should know that it costs several minutes/hours to make available images for the public. Providing both compressing and uncompressing images are hard to accomplish due to the disk spaces. *** carl I think it would be better to focus on whether or not the carl snapshot machine can even handle such a task, and, more carl importantly, whether the administrator even wants to do it. I have '[EMAIL PROTECTED]' hat on my head. I don't say I hate to compress ISO images. However, I think there is very few merits for compressing images. There are many tasks for providing whole services; if it can be avoidable task, I would like not to do. Your requests are very valuable suggestion for me, but at this time, please wait it until I can get more CPU time and disk spaces (but I don't know when it comes true.) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic with panic: kmem_malloc(4096): kmem_map too small...
After upgrading my 5-current box (as of late September 2002), the kernel panics periodically with following message: panic: kmem_malloc(4096): kmem_map too small: 107651072 total allocated The number '4096' and '107651072' is always the same. What am I missing something? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
I'm now trying Terry's patch (just rebuilding a kernel). jroberson You are using 100mb of KVA for malloc(9)? Are you certain jroberson that you don't have a memory leak? Maybe there's a chance of a memory leakage by GLOBAL, but I don't sure. jroberson How much memory is in this machine? What are you using it jroberson for? It has 256MB memory, and is used for 5-current release buildbox. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
tlambert2 This was recently discussed on -current. I posted a dumb tlambert2 patch that fixes the problem. (stuff deleted) tlambert2 See the archive of the posting, for more details: Thank you, I'll try it right now. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic with panic: kmem_malloc(4096): kmem_map toosmall...
matusita Thank you, I'll try it right now. Unfortunately, kernel panics soon after it wakes up... maybe I've still missed something. -- - Makoto `MAR' Matsushita Booting [/boot/kernel/kernel]... 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: Tue Oct 15 11:18:35 JST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SNAPSHOTS_CURRENT Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3e fault code = supervisor write, page not present instruction pointer = 0x8:0xc0262891 stack pointer = 0x10:0xc03d3b5c frame pointer = 0x10:0xc03d3b5c 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 = 0 () trap number = 12 panic: page fault Uptime: 1s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol__sF)
tlambert2 That's 3.4 hours saved on a 28.8K modem download time, tlambert2 overall... a 14% reduction in size. The percentage doesn't matter. If ISO image is compressed, user who downloads the image may de-compress that image to burn (I don't know any about the burner softwares which support compressed ISO image). What's happen if there is no space to make de-compressed image on a HDD? Also, the image size is still over 200MB; it is too large to fetch via 28.8k link IMHO (saving 3.4hours doesn't help either). There are lots of broadband connection services we can temporary buy (at airport, starbucks, etc), so why not use it for large file downloads :-) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol__sF)
tlambert2 fetch -o - URL | gunzip unzipped_image You fully forgot that all users use FreeBSD. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: Old port recompiles needed (Re: Unknown symbol__sF)
carl 3.4 hours is a lot of time on a dial-up connection (granted it carl is not a one size fits all period of time). You forget that you still compressed image with about 30 hours (at least, full 1 day or more), and it is not helpful for ordinal users, not you. Again, reducing hours/percentages with compressed image doesn't matter; please focus total download time which is actually needed for all users. Missing the point is not helpful for the discussion. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: snapshots.jp.freebsd.org -- 15 days of problems
attila If it reaches this far, both the 'livetree' and 'obj' attila trees would be available. Good idea, I'll try it later. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
culverk This seems a lot like personal preferance to me, I for one culverk don't like a lot of tty's, because running getty on a bunch culverk of ttys that I'm not going to use is a waste of ram Seconded. Two ttys are enough for me. Many getty(8) processes usually waste our process table entry :-) Usually small PC keyboards don't have their own F11/F12 key; key combination such as Fn+F1/Fn+F2 is required (read: a little bit hard to push). It would be better to avoid for the default configuration IMHO. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: need current kernel
kuku So there is no more /kernel file? Yes. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot -c ?
elitetek boot -c on DP1, and the latest snapshots doesnt seem to do elitetek anything, I have been unable to find any info regarding a elitetek change to the command or what other switches it supports. Userconfig was gone away in 5-current. Tweak /boot/device.hints instead, or set appropriate variable with loader(8) prompt. Tweaking hints.* via loader(8) is not yet implemented (actually patch is available, but not yet committed and/or reviewed.) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Release building broken for -current
jhay md5 died on zero length files. You will have to upgrade the machine or jhay at least do a buildworld with new source before you try a release again. Ya, that's exactly the problem on my buildbox... Thank you for the info. But if new md5(1) doesn't used by during a release, it's yet another similar problem to be fixed, since current make release don't (actually, cannot) update its own chroot sandbox before starting final release procedures... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC 3.2
mb The situation is very unpleasant. IIRC, we have no active GCC maintainer, no matter you feel unpleasant or not... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
ru This was broken again. I don't have any ideas of what to move ru out. There are some ideas to do around boot floppies in my mind: 1) More drivers to move kernel modules, including other network drivers, pccard and friends, filesystems, etc. Apparantly it reduces kernel size so kern.flp will fit to 1.44MB again. It requires some consideration that which driver can be moved as a kernel module. 2) Concatinate multiple kernel modules into a single one. It doesn't help kern.flp flood, but mfsroot.flp may contain more kernel modules. I've tried this before, and it seems working at that time (see mail archive of [EMAIL PROTECTED]). 3) Create 'the 3rd floppy' for kernel modules. It should be an optional floppy. We can load kernel modules on a floppy from the sysinstall(8) menu. src/release/scripts/driver-*.awk and Makefile(s) should be hacked for this. It doesn't help to reduce kern.flp size, but we can have more kernel modules. 4) Use bzip2 (instead of gzip) for compression. Apparantly it reduces the size of compressed kernel/loader size. However I've heard that there are some problems if bzip2 is used (I don't know the details). 5) Give up supporting current device drivers and options which are contained within the kernel of kern.flp. Hard to accept for me, but it should reduce the size of the kernel. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
jhay nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can jhay reside somewhere else. It seems that it's time to make the 3rd floppy for kernel modules... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
brooks It does work though. It should work, but I wonder if 5-current kernel can mount CD-ROM as the root filesystem. I've tried before (March/2002 or something), but it doesn't work, kernel refused to mount CD-ROM (see email archive for more detail). Sorry if it was already fixed. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org
chuckr Ohhhkay. The .jp site I found stopped making snaps on 6/21. Mainly because kern.flp was flood. Any tiny breakages refuse to make a distribution. chuckr Manfred Antar told me about ftp.kddlabs.co.jp, which is the chuckr good site. It mirrors snapshots.jp.FreeBSD.org daily, if my log analysis is correct. snapshots.jp.FreeBSD.org is now becoming too busy ftp site, many connections are rejected because of max connection limit. I'm now seeking donors of network bandwidth and PCs (but I don't know I can find or not). Anyway, sorry for inconveniences at this time. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sysinstall meets perl5 packages: the solution is ...?
mark /usr/sbin/sysinstall * - fix - * What should we do about sysinstall and perl5 package? Options for the solution may include: 1) Install perl5 package also if 'base' distribution is selected. pros: Nobody forget to install perl5 package. /usr/bin/perl should work as like as 4-stable. cons: Users who want to have perl-free FreeBSD dislike it. 2) Use additional menu for install perl5 package or not, if 'base' distribution is selected. Install perl5 package if user selects yes to the menu. pros: Choices is available. Maybe nobody forget to install perl5 package. cons: New menu sometimes confuses users. Somebody request that why only perl? please add new menu for installing (your favorite application name here). 3) New entry 'perl5' is added to the distributions list, just like base, compat4x, crypto, XFree86, etc. Install perl5 package if perl5 package is selected. pros: Simple and obvious for users. Also some meta-distribution (for example, 'User') may include perl5 explicitly. cons: Since there are only 32bit for distributions type, if we want to add COMPAT5X distribution in the future, these flags need to be re-organized. Somebody requests that why only perl? please add (your favorite application name here) to the menu. 4) Do nothing. pros: Nothing to be done is a good news :-) cons: Some users may shout: Help! where is my perl? 5) (add your option here) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failed
gmh003532 the fix is (yet again) to rebuild sed. Is this mean that src/usr.bin/sed should be a build-tool? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for Review: allow sysinstall to tweak tri-valuesendmail_enable
gshapiro One more change please. Change: I'm very glad to hear a comment from sendmail maintainer, thank you. Just committed. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for Review: allow sysinstall to tweak tri-valuesendmail_enable
Here is a patch to enable sysinstall to set 'sendmail_enable' value to 'YES', 'NO', and 'NONE'. Current sysinstall can't set this value to 'NONE'; users who do *not* want to use sendmail can't stop sendmail via sysinstall. Following patch creates submenu to change the sendmail_enable value. However, I don't know who want to set this variable to 'NO'. If selecting 'YES' and 'NONE' is enough, I'll try to make another patch. Any comments? I want to push this feature to 4.6-RELEASE... -- - Makoto `MAR' Matsushita Index: menus.c === RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v retrieving revision 1.343 diff -u -r1.343 menus.c --- menus.c 20 May 2002 17:08:00 - 1.343 +++ menus.c 31 May 2002 17:49:18 - @@ -1372,11 +1372,31 @@ { Rwhod, This machine wants to run the rwho daemon, dmenuVarCheck, dmenuToggleVariable, NULL, rwhod_enable=YES }, { Sendmail, This machine wants to run the sendmail daemon, - dmenuVarCheck, dmenuToggleVariable, NULL, sendmail_enable=YES }, + NULL, dmenuSubmenu, NULL, MenuSendmail }, { Sshd, This machine wants to run the ssh daemon, dmenuVarCheck, dmenuToggleVariable, NULL, sshd_enable=YES }, { TCP Extensions, Allow RFC1323 and RFC1644 TCP extensions?, dmenuVarCheck, dmenuToggleVariable, NULL, tcp_extensions=YES }, + { NULL } }, +}; + +DMenu MenuSendmail = { +DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS, +Sendmail Invocation Selection, +There are three options for invocating sendmail at startup.\n +Please select Yes if you want to use sendmail as your mail transfer\n +agent. Selecting No disables sendmail to open network socket for\n +incoming email, but still runs at startup. None disables sendmail\n +completely at startup., +NULL, +NULL, +{ + { Yes,Start sendmail, + dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=YES }, + { No, Start sendmail, but don't listen from network, + dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NO }, + { None, Don't start any sendmail processes, + dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NONE }, { NULL } }, }; Index: sysinstall.h === RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v retrieving revision 1.227 diff -u -r1.227 sysinstall.h --- sysinstall.h31 May 2002 13:38:17 - 1.227 +++ sysinstall.h31 May 2002 17:49:19 - @@ -407,6 +407,7 @@ extern DMenu MenuSysconsScrnmap; /* System console screenmap configuration menu */ extern DMenuMenuSysconsTtys;/* System console terminal type menu */ extern DMenu MenuNetworking; /* Network configuration menu */ +extern DMenu MenuSendmail; /* Sendmail configuration menu + */ extern DMenu MenuInstallCustom; /* Custom Installation menu */ extern DMenu MenuDistributions; /* Distribution menu */ extern DMenu MenuDiskDevices;/* Disk type devices */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for Review: allow sysinstall to tweak tri-valuesendmail_enable
bmah Comments on the text only (i.e. I haven't tested the new menus)... Thank you. I've (of course) tested; making floppies and do a test that sysinstall saves sendmail_enable line to /etc/rc.conf. -- - Makoto `MAR' Matsushita Index: menus.c === RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v retrieving revision 1.343 diff -u -r1.343 menus.c --- menus.c 20 May 2002 17:08:00 - 1.343 +++ menus.c 1 Jun 2002 05:20:02 - @@ -1372,11 +1372,31 @@ { Rwhod, This machine wants to run the rwho daemon, dmenuVarCheck, dmenuToggleVariable, NULL, rwhod_enable=YES }, { Sendmail, This machine wants to run the sendmail daemon, - dmenuVarCheck, dmenuToggleVariable, NULL, sendmail_enable=YES }, + NULL, dmenuSubmenu, NULL, MenuSendmail }, { Sshd, This machine wants to run the ssh daemon, dmenuVarCheck, dmenuToggleVariable, NULL, sshd_enable=YES }, { TCP Extensions, Allow RFC1323 and RFC1644 TCP extensions?, dmenuVarCheck, dmenuToggleVariable, NULL, tcp_extensions=YES }, + { NULL } }, +}; + +DMenu MenuSendmail = { +DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS, +Sendmail Invocation Selection, +There are three options for invoking sendmail at startup.\n +Please select Yes if you want to use sendmail as your mail transfer\n +agent. Selecting No disables sendmail's network socket for incoming\n +email, but still enables sendmail for outbound mail. None disables\n +sendmail completely at startup., +NULL, +NULL, +{ + { Yes,Start sendmail, + dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=YES }, + { No, Start sendmail, but don't listen from network, + dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NO }, + { None, Don't start any sendmail processes, + dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NONE }, { NULL } }, }; Index: sysinstall.h === RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v retrieving revision 1.227 diff -u -r1.227 sysinstall.h --- sysinstall.h31 May 2002 13:38:17 - 1.227 +++ sysinstall.h1 Jun 2002 05:20:02 - @@ -407,6 +407,7 @@ extern DMenu MenuSysconsScrnmap; /* System console screenmap configuration menu */ extern DMenuMenuSysconsTtys;/* System console terminal type menu */ extern DMenu MenuNetworking; /* Network configuration menu */ +extern DMenu MenuSendmail; /* Sendmail configuration menu + */ extern DMenu MenuInstallCustom; /* Custom Installation menu */ extern DMenu MenuDistributions; /* Distribution menu */ extern DMenu MenuDiskDevices;/* Disk type devices */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Argument list too long in BUILDWORLD
wizard I've got error : wizard /bin/sh:Argument list too long, wizard while making buildworld, IIRC, it is already fixed; re-cvsup again. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: build a -current kernel on a -stable box
ken It worked fine, up until the commit to kmod.mk. That's by chance. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: build a -current kernel on a -stable box
ken Sorry, it was this commit that broke building -current kernels on -stable: How do you build -current kernel on your -stable box? cd /usr cvs -d /your/CVSROOT checkout src cd src make buildworld make buildkernel should work as it should be (and it's the only guaranteed procedure IIRC). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
cjc However, I have (and think I posted somewhere?) some kludgey cjc patches that build kldxref(8) as a cross-tool so that it works cjc for 4.5 to 5.0 upgrades. But it's not really the right fix cjc (since it is not a true cross-tool), so I haven't committed it. Can we add kldxref(8) to bootstrap-tools, just like config(8)? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PPPoE using aue ethernet goes kernel panic
Following are observed with 5-current kernel as of Apr/25/2002. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01898d1 stack pointer = 0x10:0xc9476b24 frame pointer = 0x10:0xc9476b40 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 = 136 (ppp) trap number = 12 panic: page fault I'm subscribing NTT's ADSL line, and using 'aue' USB ethernet for PPPoE device. The kernel boots fine, detecting my aue0, but while /etc/rc is running, kernel panics. I must provide more detailed information, but here's quick report. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PPPoE using aue ethernet goes kernel panic
matusita I must provide more detailed information, but here's quick report. Using trace command, this panic is caused by: usbd_open_pipe_ival(c40416e0, 1, c8148858, ) at usbd_open_pipe_ival+0x1d usbd_open_pipe(c40416e0, 81, 1, c8148858, c40769c0, c8148880, 2, 1, c8148880, 2) at usbd_open_pipe+0x1a aue_init(...) (this is by hand copy, so it may have some typos). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross-platform releases
ru This is just a heads up for anyone interested that I have just ru started working on a cross-platform make release issue so that ru make release TARGET_ARCH=alpha on an i386 box would produce a ru working Alpha release. Wonderful! If there are any tasks I can help for you, feel free to email me. My buildboxes are awaiting more jobs to do, but myself is awaiting more spare times to do :-( ru The next task will be to support cross-branch make releases ru so that a 4.x box could be used to produce a 5.0 snapshot. It seems that there are 2 problems; some syscall issue, and md/vn device issue. However, IIRC, the latter problem was already resolved by nyan-san. ru Supporting non-root make releases might be a good idea too. This requires that non-root uses vn/md device... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: upgrade from 4.5 to current fails
sgk Note the Error code 1(ignored). That's right, it's not an actual *error*. However, we have seen such a report so many, many times. We may want to consider changing src/sys/conf/kmod.mk to shut it up. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross-platform releases
ru A fast -CURRENT box with root access for make release would be ru highly appreciated. My 500MHz Celeron is too slow for this. snapshots.jp.FreeBSD.org and associate build machines are all P3-500Mhz, not so fast like Celeron 500Mhz... ru There are no syscall issues in my version because I do not do a ru second installworld. Ah, I see, and we cannot do second installworld since it installs 'target' arch's binary :-) ru I estimate that 30% is already done. :-) Great, keep on :-) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5-current buildworld breakage?
Using 5-current code as of Apr/17/2002 15:00:00 GMT: # pwd /usr/src/gnu/usr.bin/groff/src/preproc/eqn # ident Makefile Makefile: $FreeBSD: src/gnu/usr.bin/groff/src/preproc/eqn/Makefile,v 1.3 2002/04/11 11:06:03 ru Exp $ # make -n neqn make: don't know how to make neqn. Stop # Anybody have seen this? or it's my local problem? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-current buildworld breakage?
dwcjr Yeah, your make is broken, try rebuilding make by itself and dwcjr install it then try the buildworld again Ah, sorry. I've missed what src/usr.bin/make/str.c rev 1.19 said. I just rebuilt make(1) and confirmed that it works again. Thanks. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: plug aue ethernet goes to panic
jhb Can you get a backtrace in ddb? It looks like a null pointer jhb dereference, and knowing where it happened would help. Backtrace told me that the panic was occured when usbd_get_interface_descriptor() is called from aue_attach(). jhb Finding the file and line of the instruction pointer using jhb addr2line on kernel.debug would be helpful as well. But unfortunately, my kernel.debug prints uhub0: device problem, disabling port 2 and doesn't panic :-( *** I've confirmed that kernel and its module are in sync. There no /modules directory since this machine was born as 5-current box, and /boot/modules directory is empty. ident(1) output of src/sys/dev/usb is attached below. -- - Makoto `MAR' Matsushita /sys/dev/usb/dsbr100io.h: $FreeBSD: src/sys/dev/usb/dsbr100io.h,v 1.1 2002/03/04 03:51:19 alfred Exp $ /sys/dev/usb/hid.c: $NetBSD: hid.c,v 1.17 2001/11/13 06:24:53 lukem Exp $ $FreeBSD: src/sys/dev/usb/hid.c,v 1.18 2002/04/07 17:53:58 joe Exp $ /sys/dev/usb/hid.h: $NetBSD: hid.h,v 1.6 2000/06/01 14:28:57 augustss Exp $ $FreeBSD: src/sys/dev/usb/hid.h,v 1.11 2002/04/01 19:01:08 joe Exp $ /sys/dev/usb/if_aue.c: $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_auereg.h: $FreeBSD: src/sys/dev/usb/if_auereg.h,v 1.13 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_cue.c: $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_cuereg.h: $FreeBSD: src/sys/dev/usb/if_cuereg.h,v 1.10 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_kue.c: $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_kuereg.h: $FreeBSD: src/sys/dev/usb/if_kuereg.h,v 1.10 2002/04/07 12:04:02 joe Exp $ /sys/dev/usb/kue_fw.h: $FreeBSD: src/sys/dev/usb/kue_fw.h,v 1.2 2000/04/03 20:58:23 n_hibma Exp $ /sys/dev/usb/ohci.c: $NetBSD: ohci.c,v 1.121 2002/03/16 16:11:18 tsutsui Exp $ $FreeBSD: src/sys/dev/usb/ohci.c,v 1.102 2002/04/07 16:36:30 joe Exp $ /sys/dev/usb/ohcireg.h: $NetBSD: ohcireg.h,v 1.17 2000/04/01 09:27:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcireg.h,v 1.18 2002/04/01 13:21:43 joe Exp $ /sys/dev/usb/ohcivar.h: $NetBSD: ohcivar.h,v 1.30 2001/12/31 12:20:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcivar.h,v 1.32 2002/04/07 15:16:31 joe Exp $ /sys/dev/usb/rio500_usb.h: $FreeBSD: src/sys/dev/usb/rio500_usb.h,v 1.1 2000/04/08 17:02:13 n_hibma Exp $ /sys/dev/usb/ucom.c: $NetBSD: ucom.c,v 1.39 2001/08/16 22:31:24 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucom.c,v 1.16 2002/04/01 21:30:36 jhb Exp $ /sys/dev/usb/ucomvar.h: $NetBSD: ucomvar.h,v 1.9 2001/01/23 21:56:17 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucomvar.h,v 1.1 2002/03/18 18:23:39 joe Exp $ /sys/dev/usb/udbp.c: $FreeBSD: src/sys/dev/usb/udbp.c,v 1.14 2002/04/04 21:03:17 jhb Exp $ /sys/dev/usb/udbp.h: $FreeBSD: src/sys/dev/usb/udbp.h,v 1.1 2000/05/01 22:48:22 n_hibma Exp $ /sys/dev/usb/ufm.c: $FreeBSD: src/sys/dev/usb/ufm.c,v 1.4 2002/03/11 16:38:53 imp Exp $ /sys/dev/usb/ugen.c: $NetBSD: ugen.c,v 1.51 2001/11/13 07:59:32 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugen.c,v 1.59 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/ugraphire_rdesc.h: $NetBSD: usb/ugraphire_rdesc.h,v 1.1 2000/12/29 01:47:49 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugraphire_rdesc.h,v 1.1 2002/04/07 17:04:01 joe Exp $ /sys/dev/usb/uhci.c: $NetBSD: uhci.c,v 1.158 2002/03/17 18:02:53 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhci.c,v 1.119 2002/04/07 18:33:12 joe Exp $ /sys/dev/usb/uhcireg.h: $NetBSD: uhcireg.h,v 1.15 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcireg.h,v 1.20 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhcivar.h: $NetBSD: uhcivar.h,v 1.33 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcivar.h,v 1.33 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhid.c: $NetBSD: uhid.c,v 1.45 2001/10/26 17:58:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhid.c,v 1.49 2002/04/07 17:13:00 joe Exp $ /sys/dev/usb/uhub.c: $NetBSD: uhub.c,v 1.57 2001/11/20 16:08:37 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhub.c,v 1.42 2002/04/07 11:29:31 joe Exp $ /sys/dev/usb/ukbd.c: $FreeBSD: src/sys/dev/usb/ukbd.c,v 1.37 2002/04/07 13:16:17 joe Exp $ /sys/dev/usb/ulpt.c: $NetBSD: ulpt.c,v 1.46 2001/12/31 12:15:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/ulpt.c,v 1.43 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/umass.c: $FreeBSD: src/sys/dev/usb/umass.c,v 1.60 2002/04/11 21:09:41 jhb Exp $ $NetBSD: umass.c,v 1.28 2000/04/02 23:46:53 augustss Exp $ /sys/dev/usb/umodem.c: $NetBSD: umodem.c,v 1.5
plug aue ethernet goes to panic
Following are observed with 5-current kernel as of Apr/13/2002. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0189b4a stack pointer = 0x10:0xc03f5180 frame pointer = 0x10:0xc03f5180 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 = 0 (swapper) trap number = 12 panic: page fault Loading kernel is OK, it boots fine if my 'aue' ethernet is not plugged. When I plug aue to the PC, kernel panic with messages above. Also, kernel panics after usb0, uhub0 is attached (same reason). Does anybody have aue see this?, or I'm alone? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX halted
'BTX halted' on floppy boot is still a problem on 5-current. Nobody can install latest 5-current (not 5.0-DP1 :-) to a fresh PC at this time. debolaz Well, here's a dump from me too, it's debolaz 5.0-CURRENT-20020313-JPSNAP, the first snap from debolaz snapshots.jp.freebsd.org which has the problem. I also confirmed this. 5.0-CURRENT-20020312-JPSNAP goes fine, but 5.0-CURRENT-20020313-JPSNAP make 'BTX halted'. My sample is: int=0006 err= efl=0006 eip=c03069d7 eax=0081 ebx=0082fc00 ecx= edx=0102 esi=0082f000 edi=00837000 ebp=c0832d94 esp=c0832d94 cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010 es:eip=ff ff 18 57 56 53 a1 44-15 37 c0 a3 c4 76 38 c0 a1 48 15 37 c0 a3 7c 77-38 c0 05 a0 1d ff ff a3 ss:esp=00 00 00 00 94 93 12 c0-00 70 83 00 00 f0 82 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted *** I doubt there is a problem around libz (which is updated between two JPSNAPs shown above), since the kernel in kern.flp is gzipped, but most users doesn't gzip their kernel on HDD. Any testers (who have 5-current PC, installworlded after Mar/13/2002) who try to gzip their kernel, and try to boot from that? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX halted
matusita I doubt there is a problem around libz (which is updated matusita between two JPSNAPs shown above), since the kernel in matusita kern.flp is gzipped, but most users doesn't gzip their matusita kernel on HDD. Yeah, bingo! :-) My friend on IRC confirms that 'gzip'-ed kernel on HDD doesn't boot. gzip's compression level doesn't matter; gzip -9 kernel (the same option of boot floppy's kernel) and gzip kernel (no option) is the same result. I've swapped kern.flp's /boot/loader (actually kgzip-ed loader(8)) to older one, and it works perfectly. All problems are in loader(8). loader(8) uses libstand, and libstand have a part of libz code. After importing new libz, something goes wrong with libstand. Anybody know typical pitfalls of using new libz? I've seen some commits for adapting the new libz, but sorry I forget what they were. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX halted
matusita Anybody know typical pitfalls of using new libz? I've seen some matusita commits for adapting the new libz, but sorry I forget what they were. I've tried to boot 5.0-CURRENT-20020404-JPSNAP and got a success @_@ Does recent change to src/lib/libz/infcodes.c rev 1.4 solve this issue? Anyway, we have a installable 5-current again... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no current snapshots available
wosch there are no up to date current snapshots available. Yes, current 5-current's fixit.flp is flooded. I have an idea how to fix it (see current@), but sorry I have no time to check that my idea is good or bad... -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: no current snapshots available
jhay I'm building the fixit floppy without a populated /dev. That leaves jhay enough space open to fit all the rest of the stuff and it shouldn't jhay be needed on -current because of devfs. But I haven't tried it. :-) That is all I want to check it ASAP :-) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fixit.flp full again
matusita But I don't checked that we can safely remove /dev/* files from matusita fixit.flp (sorry, if no one try to do, I'll do it later). I've confirmed that it makes no problem, so commit it. We get about 40kbytes of free fixit.flp space again. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vmware
never Maybe it's better to make two different ports vmware-tools and never vmware-tools3, first of which is for vmware2? Ancient ports/emulators/vmware-tools (FreeBSD native vmware-tools for VMware _1.x_) is outdated for VMware 2.x; it doesn't have time sync feature. If you're VMware 2.x user, you may want to consider to install ports/emulators/linux-vmware-toolbox. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just a reminder
rwatson It seems to me the kernel entry point should be mi_start() rwatson rather than main(), however. Good point. I just did a small hack to do that: URL:http://snapshots.jp.freebsd.org/tour/current/kernel/ 4-stable kernel tour will be changed also tomorrow. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
rwatson Certainly we can MFC eaccess(), but that's not going to make rwatson the problem go away. Fundamentally our model is backward rwatson compatibility, not forward compatibility. We need to build rwatson 5.0 packages on 5.0. That's why I build FreeBSD 5-current snapshots on a 5-current box. Note that we have already experienced such a situation before (at least in September 1999, sigset_t change). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4-5 REL - 5.0 CUR
jstocker kldxref /boot/kernel jstocker kldxref:No such file or directory jstocker *** Error code 1 (ignored) See the message (ignored). It is the intentional behavior. If you don't like this, make NO_XREF=YES installkernel will help you. Check src/sys/conf/kmod.mk for more details. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gtags? htags?
julian It might be an idea if the kernel were kept separate because I julian find that the cross-reference is good but having kernel and julian userspace mixed up is a bit confusing.. Ok, I've separated the tour into 'kernel' part and 'userland' part (5-current kernel is now processing). Tour entrance is the same URL: http://snapshots.jp.FreeBSD.org/tour/ -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gtags? htags?
gnn They're needed for the tags: target in the kernel makefiles and gnn since I'd like to be able to browse code... Feel free to check URL:http://snapshots.jp.FreeBSD.org/tour/. Both 5-current and 4-stable code are HTMLed with GLOBAL daily. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gtags? htags?
julian It might be an idea if the kernel were kept separate because julian I find that the cross-reference is good but having kernel and userspace julian mixed up is a bit confusing.. Hmm, maybe it's a good idea about userland/kernel separation. I'll try it later (maybe this evening or this weekend). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 make release breakage
murray I'm currently looking into #2 and #3, as well as working with Ted murray Lemon from the ISC to fix some symbol pollution that this whole mess murray has exposed. Any other ideas? Currently nothing, it seems that #3 (or its variant) is better IMHO. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD/i386 make release breakage
Current 5-current fails 'make release' when processing release.4 target (making a crunch binary). Here's sample session: === doc rm -f cpio.info cpio.info.gz rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH /usr/obj/usr/src/gnu/usr.bin/cpio/GRTAGS /usr/obj/usr/src/gnu/usr.bin/cpio/GSYMS /usr/obj/usr/src/gnu/usr.bin/cpio/GTAGS === doc make: don't know how to make dhclient_clean. Stop src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target. % cd /usr/src/sbin/dhclient % make -n dhclient_clean make: don't know how to make dhclient_clean. Stop It seems that crunchgen misunderstands src/sbin/dhclient/Makefile, and fails to generate a Makefile for crunch binary. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 make release breakage
Ouch. matusita src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target. Of course that's normal, dhclient_clean target should be created by crunchgen. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 make release breakage
null After the cvs checkout completes: Ah, big sorry... I just fixed in src/release/Makefile rev 1.658. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
will Jordan announced recently that Qwest is upgrading the hardware will and that there would be intermittent problems with the server for will a certain period (a few days as I recall). It would be: From: Jordan Hubbard [EMAIL PROTECTED] Subject: stable.freebsd.org AKA releng4.freebsd.org down for next 2 days To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Sat, 02 Feb 2002 13:35:57 -0800 Most people don't mirror anything from this machine, but just for the few who do, please consider this a HEADS UP! The machine is being replaced by a much beefier and faster machine, courtesy of Qwest, and will be back up just as soon as its new incarnation is clearly doing everything the old one did. Now when I say down I also don't mean actually down 24/7, and I'll actually endevor to keep the service mostly up for those two days, I just want you all to know that I'll feel free to reboot it or take it off-line at any time and without notice during that period until the service is transitioned. Thanks for your patience. But this doesn't mention about current.FreeBSD.org, and today is Feb/07/2002. I'm anxious about something goes wrong (machine troubles, jkh is still busy working, or something like that). -- - Makoto `MAR' Matsushita 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
Re: current.freebsd.org down?
I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? Hmm... galtvalion % ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:matusita): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp ^D 221 Goodbye. galtvalion % ftp stable.freebsd.org ftp: connect: Connection refused galtvalion % Both snapshots machine are not available for services... anybody knows what's going on? -- - Makoto `MAR' Matsushita 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
Re: current.freebsd.org down?
I know this is probably offtopic but is there any problem with current.freebsd.org at the moment? Hmm... galtvalion % ftp current.freebsd.org Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version 6.00LS) ready. Name (current.freebsd.org:matusita): ftp 331 Guest login ok, send your email address as password. Password: 550 Can't set guest privileges. ftp: Login failed. ftp ^D 221 Goodbye. galtvalion % ftp stable.freebsd.org ftp: connect: Connection refused galtvalion % Both snapshots machine are not available for services... anybody knows what's going on? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current.freebsd.org down?
will Jordan announced recently that Qwest is upgrading the hardware will and that there would be intermittent problems with the server for will a certain period (a few days as I recall). It would be: From: Jordan Hubbard [EMAIL PROTECTED] Subject: stable.freebsd.org AKA releng4.freebsd.org down for next 2 days To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Sat, 02 Feb 2002 13:35:57 -0800 Most people don't mirror anything from this machine, but just for the few who do, please consider this a HEADS UP! The machine is being replaced by a much beefier and faster machine, courtesy of Qwest, and will be back up just as soon as its new incarnation is clearly doing everything the old one did. Now when I say down I also don't mean actually down 24/7, and I'll actually endevor to keep the service mostly up for those two days, I just want you all to know that I'll feel free to reboot it or take it off-line at any time and without notice during that period until the service is transitioned. Thanks for your patience. But this doesn't mention about current.FreeBSD.org, and today is Feb/07/2002. I'm anxious about something goes wrong (machine troubles, jkh is still busy working, or something like that). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vmware
ggombert VMware tools for FreeBSD is woefully out of date as well, Really? % cd /usr/ports/emulators/vmware-tools % make -V PORTVERSION 3.0.0.1455 VMware 3.0 bundles a new VMware tools, and it is up-to-date version as of Linux guests. % cd /usr/ports/emulators/vmware-tools % make -V MAINTAINER [EMAIL PROTECTED] Belive me, I'm using VMware 3.0, (old) FreeBSD 5-current guest, installing VMware tools via ports. *** If you are talking about VMware 2.x, yes, it's too old. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vmware
matusita I've just filed an incident (I have a license of VMware 3.0). I've received a reply from VMware: Thank you for submitting the incident and letting us know the potential workaround. I must apologize because we do not support FreeBSD 5.0 as a guest OS yet in Workstation 3.0. Please see: http://www.vmware.com/support/ws3/doc/ws30_intro4.html We will consider providing the support in a future release. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vmware
rwatson If someone has a commercial license, it would make sense rwatson submitting this via a trouble ticket, as well as providing rwatson the VMware support people with some brief directions on rwatson installing 5.0. I've just filed an incident (I have a license of VMware 3.0). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATAPI CD doesn't listed up to 'kern.disks' kernel MIB
I found that acd, ATAPI CD device, doesn't listed up to 'kern.disks' kernel MIB which should list all disks in the running system. Here is a sample: ringo % sysctl kern.disks kern.disks: ad0 ringo % grep acd /var/run/dmesg.boot acd0: CDROM TOSHIBA CD-ROM XM-6202B at ata1-master PIO4 ringo % I've investigated that this is because ATAPI CD driver doesn't call disk_create() when detecting CD device. Other disks, including SCSI CD or RAID HDD calls this function. http://snapshots.jp.freebsd.org/tour/current/cgi-bin/global.cgi?pattern=disk_createid=type=reference Is it a feature or something forgotten to add it? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sudo redu
FYI: pam_setcred() call seems used in OpenSSH, ftpd, rshd, login, and su already included in FreeBSD source code. URL:http://snapshots.jp.freebsd.org/tour/current/cgi-bin/global.cgi?pattern=pam_setcredid=type=reference imp OK. This looks like a problem in 1.6.4p1 of sudo. It isn't a problem imp with 1.6.3p7_2. 1.6.4 works on -stable, but not -current. I've checked about new sudo's behavior on some OSes: Debian (woody) sudo-1.6.4.1OK (tested on 1 machine) FreeBSD 2.2.8-RELEASE sudo-1.6.5.1OK (tested on 1 machine) FreeBSD 3.4-stable sudo-1.6.5.1NG (tested on 1 machine) FreeBSD 4-stablesudo-1.6.5.1OK (tested on some machines) FreeBSD 5-current sudo-1.6.5.1OK / NG (tested on some machines) OK / NG means that some machines work fine, but some machines goes wrong. *** I don't know what's the real problem, but it seems that sudo doesn't have the problem IMHO. Anyone has a solution about this problem? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release broken
jhay The last one that worked here was on 20020108. The one on the jhay next day broke. The release builds are started from cron at jhay midnight SAST which is 2 hours ahead of UTC. FYI: 5.0-CURRENT-20020113-JPSNAP builds goes fine here. I dunno what change fixes this :-) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release broken
This error is occured when make release try to roll 'bin' distribution. jhay Make release of -current has been broken here for the past few jhay days. I had a look on the Japanese snapshot site and theirs jhay break with the same error. Do anybody have an idea about what jhay is going wrong? Somewhat strange behavior, since the file '.exists' is there. % pwd /R/stage/dists/bin % tail -f bin.mtree # ./usr/libdata/perl /set type=file uname=root gname=wheel mode=0755 nlink=1 perltype=dir nlink=4 size=512 # ./usr/libdata/perl/5.6.0 /set type=file uname=root gname=wheel mode=0555 nlink=1 5.6.0 type=dir mode=0755 nlink=32 size=2560 .exists size=0^C % cd ../../trees/bin/usr/libdata/perl/5.6.0 % pwd /R/stage/trees/bin/usr/libdata/perl/5.6.0 % ls -l .exists -r-xr-xr-x 1 root wheel 0 Jan 12 06:22 .exists -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel compile fails...
coolvibe What header file defines SWI_NOSWITCH? http://snapshots.jp.freebsd.org/tour/current/cgi-bin/global.cgi?pattern=SWI_NOSWITCHid=type=symbol SWI_NOSWITCH are used and/or defined by these files. You can easily find that this list have only one *.h file -- sys/sys/interrupt.h. % grep SWI_NOSWITCH /usr/src/sys/sys/interrupt.h #define SWI_NOSWITCH0x0 % It's easy to find :-) -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release breakage: src/sbin/ifconfig
With 5-current as of Dec/04/2001 15:00:00 GMT. It seems that this is because 'WARNS=0' line is inside of !defined(RELEASE_CRUNCH) clause. IMO, if an application's code requires to set 'WARNS=0 for build, it should also be set when building as a part of a crunched binary. -- - Makoto `MAR' Matsushita (cd /usr/src/sbin/ifconfig make -DRELEASE_CRUNCH -Dlint depend make -DRELEASE_CRUNCH -Dlint ifconfig.o ifmedia.o ifieee80211.o) rm -f .depend mkdep -f .depend -a-DUSE_IF_MEDIA -DUSE_IEEE80211 -DNO_IPX -DNS -I.. /usr/src/sbin/ifconfig/ifconfig.c /usr/src/sbin/ifconfig/ifmedia.c /usr/src/sbin/ifconfig/ifieee80211.c cd /usr/src/sbin/ifconfig; make _EXTRADEPEND echo ifconfig: /usr/lib/libc.a .depend cc -O -pipe -DUSE_IF_MEDIA -DUSE_IEEE80211 -DNO_IPX -DNS -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -I.. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/sbin/ifconfig/ifconfig.c cc1: warnings being treated as errors /usr/src/sbin/ifconfig/ifconfig.c:157: warning: declaration of `name' shadows global declaration /usr/src/sbin/ifconfig/ifconfig.c:197: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:197: warning: (near initialization for `cmds[0].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:198: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:198: warning: (near initialization for `cmds[1].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:199: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:199: warning: (near initialization for `cmds[2].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:200: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:200: warning: (near initialization for `cmds[3].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:201: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:201: warning: (near initialization for `cmds[4].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:202: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:202: warning: (near initialization for `cmds[5].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:203: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:203: warning: (near initialization for `cmds[6].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:204: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:204: warning: (near initialization for `cmds[7].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:205: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:205: warning: (near initialization for `cmds[8].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:206: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:206: warning: (near initialization for `cmds[9].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:207: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:207: warning: (near initialization for `cmds[10].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:213: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:213: warning: (near initialization for `cmds[11].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:226: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:226: warning: (near initialization for `cmds[12].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:227: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:227: warning: (near initialization for `cmds[13].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:228: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:228: warning: (near initialization for `cmds[14].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:229: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:229: warning: (near initialization for `cmds[15].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:230: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:230: warning: (near initialization for `cmds[16].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:232: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:232: warning: (near initialization for `cmds[18].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:233: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:233: warning: (near initialization for `cmds[19].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:234: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:234: warning: (near initialization for `cmds[20].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:235: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:235: warning: (near initialization for `cmds[21].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:236: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:236: warning: (near initialization for `cmds[22].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:237: warning: missing initializer /usr/src/sbin/ifconfig/ifconfig.c:237: warning: (near initialization for `cmds[23].c_func2') /usr/src/sbin/ifconfig/ifconfig.c:238: warning: missing initializer
src/usr.bin/telnet: make release broken while making crunchedbinary
With the 5-current source as of Dec/02/2001 15:00 GMT. -- - Makoto `MAR' Matsushita (cd /usr/src/usr.bin/telnet make -DRELEASE_CRUNCH depend make -DRELEASE_CRUNCH commands.o main.o network.o ring.o sys_bsd.o telnet.o terminal.o utilities.o genget.o getent.o misc.o) rm -f .depend mkdep -f .depend -a-DKLUDGELINEMODE -DUSE_TERMIO -DENV_HACK -DOPIE -I/usr/src/usr.bin/telnet/../../lib -I/usr/src/usr.bin/telnet/../../lib/libtelnet/ -DHAS_CGETENT /usr/src/usr.bin/telnet/commands.c /usr/src/usr.bin/telnet/main.c /usr/src/usr.bin/telnet/network.c /usr/src/usr.bin/telnet/ring.c /usr/src/usr.bin/telnet/sys_bsd.c /usr/src/usr.bin/telnet/telnet.c /usr/src/usr.bin/telnet/terminal.c /usr/src/usr.bin/telnet/utilities.c /usr/src/usr.bin/telnet/../../lib/libtelnet/genget.c /usr/src/usr.bin/telnet/../../lib/libtelnet/getent.c /usr/src/usr.bin/telnet/../../lib/libtelnet/misc.c cd /usr/src/usr.bin/telnet; make _EXTRADEPEND echo telnet: /usr/lib/libc.a /usr/lib/libtermcap.a /usr/obj/usr/src/usr.bin/telnet/../../lib/libtelnet/libtelnet.a .depend cc -O -pipe -DKLUDGELINEMODE -DUSE_TERMIO -DENV_HACK -DOPIE -I/usr/src/usr.bin/telnet/../../lib -I/usr/src/usr.bin/telnet/../../lib/libtelnet/ -DHAS_CGETENT -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/usr.bin/telnet/commands.c cc1: warnings being treated as errors /usr/src/usr.bin/telnet/commands.c: In function `tn': /usr/src/usr.bin/telnet/commands.c:2082: warning: label `af_again' defined but not used /usr/src/usr.bin/telnet/commands.c: In function `sourceroute': /usr/src/usr.bin/telnet/commands.c:2566: warning: unused variable `sin6' /usr/src/usr.bin/telnet/commands.c:2563: warning: unused variable `cmsg' /usr/src/usr.bin/telnet/commands.c: At top level: /usr/src/usr.bin/telnet/commands.c:92: warning: `switch_af' declared `static' but never defined *** Error code 1 Stop in /usr/src/usr.bin/telnet. *** Error code 1 Stop in /usr/obj/usr/src/release/fixit_crunch. *** Error code 1 Stop in /usr/src/release. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: sysinstall to remove userconfig code
Sorry for late reply. jkh Don't you want to try the devfs mount and only copy device files jkh if that returns an error code? Hmm, it seems better to me. I'll try it again... I find that more error handling is required if mounting devfs is failed. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: sysinstall to remove userconfig code
jkh Don't you want to try the devfs mount and only copy device files jkh if that returns an error code? How 'bout this patch (attached below)? I've recreate boot floppies with this patch, then put them to: http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/ -- - Makoto `MAR' Matsushita Index: install.c === RCS file: /pub/snapshots/cvsup/FreeBSD.cvs/src/usr.sbin/sysinstall/install.c,v retrieving revision 1.309 diff -c -r1.309 install.c *** install.c 20 Oct 2001 09:28:53 - 1.309 --- install.c 1 Dec 2001 13:49:27 - *** *** 857,863 int installFilesystems(dialogMenuItem *self) { ! int i; Disk *disk; Chunk *c1, *c2, *rootdev, *swapdev, *usrdev, *vardev; Device **devs; --- 857,863 int installFilesystems(dialogMenuItem *self) { ! int i, mountfailed; Disk *disk; Chunk *c1, *c2, *rootdev, *swapdev, *usrdev, *vardev; Device **devs; *** *** 932,938 } dialog_clear_norefresh(); msgNotify(Checking integrity of existing %s filesystem., dname); ! i = vsystem(fsck -y %s, dname); if (i) msgConfirm(Warning: fsck returned status of %d for %s.\n This partition may be unsafe to use., i, dname); --- 932,938 } dialog_clear_norefresh(); msgNotify(Checking integrity of existing %s filesystem., dname); ! i = vsystem(fsck_ffs -y %s, dname); if (i) msgConfirm(Warning: fsck returned status of %d for %s.\n This partition may be unsafe to use., i, dname); *** *** 949,954 --- 949,969 msgConfirm(Unable to mount the root file system on %s! Giving up., dname); return DITEM_FAILURE | DITEM_RESTORE; } + + /* Mount devfs for other partitions to mount */ + Mkdir(/mnt/dev); + if (!Fake) + mountfailed = mount(devfs, /mnt/dev, 0, NULL); + + if (mountfailed) { + dialog_clear_norefresh(); + msgNotify(Copying initial device files..); + /* Copy the boot floppy's dev files */ + if ((root-newfs || upgrade) vsystem(find -x /dev | cpio %s -pdum +/mnt, cpioVerbosity())) { + msgConfirm(Couldn't clone the /dev files!); + return DITEM_FAILURE | DITEM_RESTORE; + } + } } /* Now buzz through the rest of the partitions and mount them too */ *** *** 962,974 msgConfirm(No chunk list found for %s!, disk-name); return DITEM_FAILURE | DITEM_RESTORE; } ! if (RunningAsInit root (root-newfs || upgrade)) { ! Mkdir(/mnt/dev); ! if (!Fake) ! MakeDevDisk(disk, /mnt/dev); } - else if (!RunningAsInit !Fake) - MakeDevDisk(disk, /dev); for (c1 = disk-chunks-part; c1; c1 = c1-next) { if (c1-type == freebsd) { --- 977,991 msgConfirm(No chunk list found for %s!, disk-name); return DITEM_FAILURE | DITEM_RESTORE; } ! if (mountfailed) { ! if (RunningAsInit root (root-newfs || upgrade)) { ! Mkdir(/mnt/dev); ! if (!Fake) ! MakeDevDisk(disk, /mnt/dev); ! } ! else if (!RunningAsInit !Fake) ! MakeDevDisk(disk, /dev); } for (c1 = disk-chunks-part; c1; c1 = c1-next) { if (c1-type == freebsd) { *** *** 983,989 if (tmp-newfs (!upgrade || !msgNoYes(You are upgrading - are you SURE you want to newfs /dev/%s?, c2-name))) command_shell_add(tmp-mountpoint, %s %s/dev/%s, tmp-newfs_cmd, RunningAsInit ? /mnt : , c2-name); else ! command_shell_add(tmp-mountpoint, fsck -y %s/dev/%s, RunningAsInit ? /mnt : , c2-name); if (tmp-soft) command_shell_add(tmp-mountpoint, tunefs -n enable %s/dev/%s, RunningAsInit ? /mnt : , c2-name); command_func_add(tmp-mountpoint, Mount, c2-name); --- 1000,1006 if (tmp-newfs (!upgrade || !msgNoYes(You are upgrading - are you SURE you want to newfs /dev/%s?, c2-name))) command_shell_add(tmp-mountpoint, %s %s/dev/%s, tmp-newfs_cmd, RunningAsInit ? /mnt : , c2-name); else ! command_shell_add(tmp-mountpoint, fsck_ffs -y %s/dev/%s, RunningAsInit ? /mnt : , c2-name); if (tmp-soft) command_shell_add(tmp-mountpoint, tunefs -n enable %s/dev/%s, RunningAsInit ? /mnt : , c2-name); command_func_add(tmp-mountpoint,
Re: PATCH: sysinstall to remove userconfig code
jkh Looks good to me, I'd say commit it! Thanks! I'll commit it in this weekend. BTW, how dou you think my other patch (use 'devfs' while mounting filesystems, use fsck_ffs instead of fsck) for sysinstall, which was posted about a week before to [EMAIL PROTECTED]? You can fetch from: URL:http://people.freebsd.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/patch -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Sysinstall is still horribly broken.
matusita OK, a patch is attached below. Sorry, forget to add the patch... try again. If anybody test with boot floppies, available at http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/, please let me know your results. -- - Makoto `MAR' Matsushita Index: install.c === RCS file: /pub/snapshots/cvsup/FreeBSD.cvs/src/usr.sbin/sysinstall/install.c,v retrieving revision 1.309 diff -c -r1.309 install.c *** install.c 20 Oct 2001 09:28:53 - 1.309 --- install.c 21 Nov 2001 02:22:00 - *** *** 932,938 } dialog_clear_norefresh(); msgNotify(Checking integrity of existing %s filesystem., dname); ! i = vsystem(fsck -y %s, dname); if (i) msgConfirm(Warning: fsck returned status of %d for %s.\n This partition may be unsafe to use., i, dname); --- 932,938 } dialog_clear_norefresh(); msgNotify(Checking integrity of existing %s filesystem., dname); ! i = vsystem(fsck_ffs -y %s, dname); if (i) msgConfirm(Warning: fsck returned status of %d for %s.\n This partition may be unsafe to use., i, dname); *** *** 949,954 --- 949,967 msgConfirm(Unable to mount the root file system on %s! Giving up., dname); return DITEM_FAILURE | DITEM_RESTORE; } + + dialog_clear_norefresh(); + msgNotify(Copying initial device files..); + /* Copy the boot floppy's dev files */ + if ((root-newfs || upgrade) vsystem(find -x /dev | cpio %s -pdum /mnt, +cpioVerbosity())) { + msgConfirm(Couldn't clone the /dev files!); + return DITEM_FAILURE | DITEM_RESTORE; + } + + /* Mount devfs for other partitions to mount */ + Mkdir(/mnt/dev); + if (!Fake) + mount(devfs, /mnt/dev, 0, NULL); } /* Now buzz through the rest of the partitions and mount them too */ *** *** 962,974 msgConfirm(No chunk list found for %s!, disk-name); return DITEM_FAILURE | DITEM_RESTORE; } - if (RunningAsInit root (root-newfs || upgrade)) { - Mkdir(/mnt/dev); - if (!Fake) - MakeDevDisk(disk, /mnt/dev); - } - else if (!RunningAsInit !Fake) - MakeDevDisk(disk, /dev); for (c1 = disk-chunks-part; c1; c1 = c1-next) { if (c1-type == freebsd) { --- 975,980 *** *** 983,989 if (tmp-newfs (!upgrade || !msgNoYes(You are upgrading - are you SURE you want to newfs /dev/%s?, c2-name))) command_shell_add(tmp-mountpoint, %s %s/dev/%s, tmp-newfs_cmd, RunningAsInit ? /mnt : , c2-name); else ! command_shell_add(tmp-mountpoint, fsck -y %s/dev/%s, RunningAsInit ? /mnt : , c2-name); if (tmp-soft) command_shell_add(tmp-mountpoint, tunefs -n enable %s/dev/%s, RunningAsInit ? /mnt : , c2-name); command_func_add(tmp-mountpoint, Mount, c2-name); --- 989,995 if (tmp-newfs (!upgrade || !msgNoYes(You are upgrading - are you SURE you want to newfs /dev/%s?, c2-name))) command_shell_add(tmp-mountpoint, %s %s/dev/%s, tmp-newfs_cmd, RunningAsInit ? /mnt : , c2-name); else ! command_shell_add(tmp-mountpoint, fsck_ffs -y %s/dev/%s, RunningAsInit ? /mnt : , c2-name); if (tmp-soft) command_shell_add(tmp-mountpoint, tunefs -n enable %s/dev/%s, RunningAsInit ? /mnt : , c2-name); command_func_add(tmp-mountpoint, Mount, c2-name); *** *** 1015,1032 } } - if (RunningAsInit) { - dialog_clear_norefresh(); - msgNotify(Copying initial device files..); - /* Copy the boot floppy's dev files */ - if ((root-newfs || upgrade) vsystem(find -x /dev | cpio %s -pdum /mnt, cpioVerbosity())) { - msgConfirm(Couldn't clone the /dev files!); - return DITEM_FAILURE | DITEM_RESTORE; - } - } - command_sort(); command_execute(); dialog_clear_norefresh(); return DITEM_SUCCESS | DITEM_RESTORE; } --- 1021,1032 } } command_sort(); command_execute(); + if (rootdev RunningAsInit) { + if (!Fake) + unmount(/mnt/dev, MNT_FORCE); + } dialog_clear_norefresh(); return DITEM_SUCCESS | DITEM_RESTORE; } Index: boot_crunch.conf === RCS file: /pub/snapshots/cvsup/FreeBSD.cvs/src/release/i386/boot_crunch.conf,v retrieving
swapfile doesn't work if md driver is not pre-loaded
In /etc/rc, there is a swapfile feature, to configure a file to use swap device. Here is a script for that. # Add additional swapfile, if configured. # case ${swapfile} in [Nn][Oo] | '') ;; *) if [ -w ${swapfile} -a -c /dev/mdctl ]; then echo Adding ${swapfile} as additional swap mdev=`mdconfig -a -t vnode -f ${swapfile}` swapon /dev/${mdev} fi ;; esac In this shell script, checking that /dev/mdctl file is present as a character device before configureing swap. It seems there is no problem, but it'll fail in some cases, such as: * kernel doesn't have 'md' driver, * loader doesn't load 'md' module, and * /boot/${kernel}/md.ko is present. If kernel doesn't know md, /dev/mdctl is not there, however, if md.ko is available, mdconfig(8) loads the module, then configure md device so mdconfig swapon will success without any problem. Are there any other reason to check the presense of /dev/mdctl? If not, can we remove /dev/mdctl testing? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Sysinstall is still horribly broken.
matusita If it seems fine for me, I'll post a patch. OK, a patch is attached below. I've also made boot floppies (use 5-current code as of Nov/21/2001) for anyone who try to find out that this problem is gone away. http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/boot.flp http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/kern.flp http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/mfsroot.flp MD5 checksums are: MD5 (boot.flp) = 88105fdd57ac68d1b2f9e7c3e067e30f MD5 (kern.flp) = ba73babdfc4cad42abfcdafa7f1fd74b MD5 (mfsroot.flp) = 8bf6b1c898b99bc549933c578dca3743 Any good or bad results are welcome. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message