cvsup-devel port build problem (pm3-base)
Hi, I ran into some problems building the cvsup-devel port. In one of it's dependants, the c file is attempting to include nfs/nfs.h which is nolonger valid. /usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4/RTHeapDepC.c As a quick fix I symlinked nfs.h - ../nfsclient/nfs.h which allowed the compile to complete. The following more generic/correct fix could probably be dropped into the files directory as patch-XX: --- RTHeapDepC.c.orig Mon Nov 19 00:27:30 2001 +++ RTHeapDepC.cMon Nov 19 00:28:21 2001 @@ -98,7 +98,11 @@ #include sys/time.h #include nfs/rpcv2.h #include nfs/nfsproto.h +#if __FreeBSD__ = 5 +#include nfsclient/nfs.h +#else #include nfs/nfs.h +#endif #include ufs/ufs/ufsmount.h #endif -John ps: I also ran into problems with libutil.h but I haven't determined where the actual problem is coming from. Copying /usr/src/lib/libutil/libutil.h to /usr/include avoids the immediate problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
__getcwd errno 20 (Not a directory) vfs_cache.c
Hi,
I'm in the middle of trying to debug a java problem
and have found something I don't quite understand.
Basically, __getcwd() is returning errno 20, Not
a directory. man getcwd doesn't list ENOTDIR so I
started looking in the sources and found kern/vfs_cache.c:
if (vp-v_dd-v_id != vp-v_ddid) {
numcwdfail1++;
free(buf, M_TEMP);
return (ENOTDIR);
}
Could someone who is more familiar with the vfs
layers provide some pointers as to what is being
done here? The code is instrumented, and sysctl
has the following to say:
% sysctl -a | grep cwd
vfs.cache.numcwdcalls: 225014
vfs.cache.numcwdfail1: 845 1 - ENOTDIR
vfs.cache.numcwdfail2: 6775 2 - ENOENT
vfs.cache.numcwdfail3: 0
vfs.cache.numcwdfail4: 0
vfs.cache.numcwdfound: 217394
The really annoying aspect to this is that it doesn't
happen everytime, and happens more often when in a nfs
mounted directory vs. a local directory.
Thanks!
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Passing -I option to dependant pkg_add invocations
Hi,
Currently, the only option passed on to dependant
pkg_add invocations is the '-v' verbose option. During an
automated install, we use the '-I' option to ignore
any pre/post installation scripts for certain packages.
The following patch allows the '-I' option to
be passed on to dependant pkg_add invocations:
http://people.freebsd.org/~jwd/perform.c.patch
A pasted copy is below (typical tabbing issues).
Thanks,
John
Index: perform.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/perform.c,v
retrieving revision 1.65
diff -u -r1.65 perform.c
--- perform.c 2001/08/15 14:22:01 1.65
+++ perform.c 2001/08/23 14:27:36
@@ -260,7 +260,8 @@
if (cp) {
if (Verbose)
printf(Loading it from %s.\n, cp);
- if (vsystem(pkg_add %s'%s', Verbose ? -v : , cp)) {
+ if (vsystem(pkg_add %s%s'%s', NoInstall ? -I : ,
+ Verbose ? -v : , cp)) {
warnx(autoload of dependency '%s' failed%s,
cp, Force ? (proceeding anyway) : !);
if (!Force)
@@ -283,7 +284,8 @@
if (!Force)
++code;
}
- else if (vsystem((pwd; cat +CONTENTS) | pkg_add %s-S, Verbose ?
-v : )) {
+ else if (vsystem((pwd; cat +CONTENTS) | pkg_add %s%s-S,
+ NoInstall ? -I : , Verbose ? -v : )) {
warnx(pkg_add of dependency '%s' failed%s,
p-name, Force ? (proceeding anyway) : !);
if (!Force)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Signal handler context restore difference - pthreads/non-pthreads
Hi, I have run into an issue with the difference between what happens when a signal handler returns from a program converted to use pthreads (vs non-pthreads). Basically, in the non-pthread case, a change made to the sc_eip element of the scp struct is honored when the kernel restores the processes context. In the pthreads case, the change to the sc_eip element is ignored. A test case which shows both a working and non-working version of this resides at: http://www.freebsd.org/~jwd/sigtst/ The makefile produces two executables: fptrap : a 'correct' executable - non-pthreads fptrapt: a 'bad' executable - pthreads %./fptrap ** Result correct: 1234.57 %./fptrapt ** Result incorrect: 1 I'd like to hear if you've dealt with the issue of precise error recovery and how it was dealt with. I'm currently exploring whether a fix to the pthread library is feasible or whether an application change is required (or conclude that the type of error recovery I need can't be done with pthreads). Thanks! John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Minor read.2 (readv) doc update w/patch
I ran into a minor error in the doc for readv. I double checked the kernel code and it checks against UIO_MAXIOV. writev.2 is correct. -john Index: read.2 === RCS file: /home/ncvs/src/lib/libc/sys/read.2,v retrieving revision 1.11 diff -u -r1.11 read.2 --- read.2 2000/06/23 05:05:44 1.11 +++ read.2 2001/05/21 19:18:38 @@ -207,7 +207,8 @@ .Bl -tag -width Er .It Bq Er EINVAL .Fa Iovcnt -was less than or equal to 0, or greater than 16. +was less than or equal to 0, or greater than +.Dv UIO_MAXIOV . .It Bq Er EINVAL One of the .Fa iov_len To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
You are one brave soul if the only precedent you have for this patch is GNU cp. Personally, I see nothing wrong with it. With respect to how you short circuit the copy if the mtimes are 'ok', you probably need to return a value different than 1 so that your caller can distinquish between a failed copy (badcp = rval = 1) and a skipped copy. Thus, the return code from 'cp' will be correct. With your patch, if the -u option skips a file, the return code from cp is 1. Just my .02 cents, -John - Jeroen Ruigrok/Asmodai's Original Message - Please test this further. This adds -u to our cp, which is a reimplemented GNU feature after Jim Mock asked me if we supported -u in our cp. Basically cp -u compares src and dest and only overwrites if dest's mtime src's mtime. Only caveat which I haven't yet solved is that it still shows dirs on cp -Ruv copy actions, whilst it doesn't copy the directory. Solutions welcome. Question is, do we want to add this to our cp? I found it handy for stuff like: cp -Ruv mozilla mozilla-test so that my mozilla CVS tree [not touched] only overwrites the mozilla-test files which are older. -- Jeroen Ruigrok van der Werven/Asmodai --=-- asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best http://www.freebsd.org/doc/en_US.ISO_8859-1/books/developers-handbook/ Only in sleep can one find salvation that resembles Death... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated: cp -t patch (w/ commentary)
Hi David, Brian, Thank you for taking the time to reply. I hope you were able to review the patch also. I am dealing with a production process that currently runs approximately 10 hours. (on 28 866Mhz processors, 2 Netapps). This process fell into my lap about 2 months ago. After studying the process, the 1st item that came to the fore-front was the number of fork/exec pairs occuring for the file copy process. Please note, as written in previous emails, the copy process copies files from multiple directories to a singular directory. I have reduced the runtime of the process so far by a solid hour. My change to cp is the lowest level/minimal change fix which allows me to maintain a O(1) time constraint. I've played with (non-freebsd) versions of xargs already, and found them (the various algorithms in xargs) to be more expensive than the patch to cp. I realize you folks are not here, and cannot examine the processes I have to deal with first hand. I can only simply ask you to trust that the work I and others have done while coming to the conclusion that the cp patch is the best alternative is correct. On a different note, I have spoken with my mentor (seems funny calling him that these days) Jordan, and his response to my email was: I think you should just commit the cp changes and let the xargs weenies debate themselves silly if the want to. :) The two issues are not really related. -Jordan I must say at this point, I tend to agree with him. Basically, my review request was skipped over and folks simply went on to discuss/argue the merits/demerits of various patchs to xargs. The question of whether xargs is appropriate and maintains adequate performance for my particular process seems to have been left on the roadside... I hope I haven't rambled to much. And again, thanks for taking the time to respond. -John - Current List's Original Message - On Mon, Apr 23, 2001 at 11:33:24AM -0700, John W. De Boskey wrote: After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. I thought people generally agreed the right fix was to add functionality to `xargs', not `cp' as you aren't scratching the general itch. -- -- David ([EMAIL PROTECTED]) 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
4.3-RELEASE will not boot after install (boot0 ?)
Hi, I have a Dell Optiplex GXi 200Mhz machine which will not boot after installing 4.3-RELEASE. After rebooting, the normal F1 FreeBSD prompt comes up with a beep. Pressing F1 causes the machine to beep again. I believe the following code sequence is the failure location: /usr/src/sys/boot/i386/boot0/boot0.s main.15:movw $LOAD,%bx # Address for read movb $0x2,%ah # Read sector callw intx13# from disk jc main.10 # If error cmpw $MAGIC,0x1fe(%bx) # Bootable? jne main.10 # No where main.10 beeps... maybe we could have it beep twice for a read err, once for a MAGIC error.. How I got here... Sysinstall disk sequence: Expert, delete existing partition, All, Quit, BootMgr, Auto, quit, etc, etc.. The above sequence works fine and produces a bootable system on other machines. Anyways, after doing a expert install but before rebooting, I can then go to the debug shell and get the following: From df Filesystem 512-blocks UsedAvail Capacity Mounted on /dev/md0c 5607 3819 173269%/ /dev/ad0s1a 19836658206 12429232%/mnt /mnt/dev/ad0s1f1676814 1211590 33108079%/mnt/usr /mnt/dev/ad0s1e 39630 23436226 1%/mnt/var /dev/cd0c 1317216 13172160 100%/dist From dislabel -r ad0 # /dev/ad0c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 1032 sectors/unit: 2115552 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20480004.2BSD 1024 819216 # (Cyl.0 - 99) b: 139376 204800 swap# (Cyl. 100 - 168*) c: 21155520unused0 0 # (Cyl.0 - 1032*) e:40960 3441764.2BSD 1024 819216 # (Cyl. 168*- 188) f: 1730416 3851364.2BSD 1024 819216 # (Cyl. 188*- 1032*) I have dumped the 1st 100 blocks of the disk. They are at: http://people.freebsd.org/~jwd/noboot/bblocks.hd (hex dump) http://people.freebsd.org/~jwd/noboot/bblocks (raw data) the output from 'fdisk ad0' is: http://people.freebsd.org/~jwd/noboot/fdisk and the dmesg for the machine: http://people.freebsd.org/~jwd/noboot/dmesg The next thing I will try is a 'dd if=/dev/zero of=/dev/ad0 count=2'. If this fixes the problem, it seems to indicate the install process has a problem with existing fdisk partition information. If someone can provide some pointers I'll try to figure what is going on. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Updated: cp -t patch (w/ commentary)
Hello, After some feedback, I have changed the patch slightly. Rename -d to -t and remove the requirement for the option to have a value. -t aquire the target from *argv++ instead of argv[argc--] The patch can be found at: http://people.freebsd.org/~jwd/cp-t.patch Some comments: -t was chosen to help match the existing (and be co-existant with) gnu cp option--target-directory=DIRECTORY I have seen many proposals posted with respect to why don't you do it this way? Bascally, they don't do the same thing. cat BigFileList | xargs cp -t targetdir where cat BigFileList is actually a seperate and complex process that I do not own/support. The list of files given to the process spans many subtrees and mount points. The goal is to bring a copy of those files into a single directory. Tar, cpio, and other file copy processes copy hierarchies. Cp is the only program which allows for a simple yet elegant way of transferring files from disparate locations to a single location. cp -s allows for a very simple yet highly effective method of doing what needs to be done. Yes, I am also willing to update mv to work the same way. -John ps: As a humorous aside with respect to standards. I thought FreeBSD set the standard! :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
If you just want an xargs that supports --replstr/-i simply install: ftp://ftp.gnu.org/gnu/findutils or even more easily: /usr/ports/misc/findutils two comments: I don't want to enter a protracted discussion over the benefits/drawbacks of the current xargs vs an updated xargs, nor try to do a write-from-scratch. The cp -d option has runtime execution of O(1). Xargs addes O(n) due to it's manipulation of the arguement vector in -i mode. The process I'm dealing with already takes many hours to run. I want to reduce time, not increase it. Comments welcome. -john - Garance A Drosihn's Original Message - At 10:08 PM -0700 4/19/01, Dima Dorfman wrote: Garance A Drosihn [EMAIL PROTECTED] writes: Or maybe something to indicate where the list of arguments should go in a command. Hrm. Let's say '-Y replstr' or '-y[replstr]' (no blank after -y). If no [replstr] is given on -y, it defaults to the two characters '[]'. Then one might do: cat big_file_list | xargs -y cp [] target_directory This is a great idea! I'm willing to implement it if nobody else wants to. Woo-hoo! Someone to do the work! Yes! you're trying to address. On the other hand, the man page for 'xargs' on FreeBSD says: The xargs utility is expected to be IEEE Std 1003.2 (``POSIX.2'') compliant. so I don't know how we go about adding options to it. On the other hand, that same issue is faced by adding options to 'cp', as there is a similar claim made in cp's man page. I don't think it's a problem. We're adding new options here, not changing--sometimes known as breaking--what already exists. I'm pretty sure that the standards don't say anything to the effect of, "You must support this and nothing else." That'd be rather silly. Actually, it's not as silly as it sounds. If you're writing scripts, and you use those extra parameters, then you'll get into trouble when running the script on some other POSIX-based OS which does not have these new options. I really do like the idea of both the -I/-i options from solaris, and the -Y/-y options that I just dreamed up, but I'm not sure what the right procedure is to introduce them (and eventually have them standard everywhere... :-). Maybe we could initially have a 'yargs' command, which is just like 'xargs' except that it adds those four options. Maybe I'm just overly pedantic. Hmm. Checking my copy of "Single Unix Specification, v2", the -I/-i parameters are defined in THAT standard, but it doesn't have anything matching my -Y/-y suggestion. Hmm, I wonder if I should be copying this "meta-question" to the mailing list for standardizing things... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cp -d dir patch for review
Hi, I have added a -d dir option to cp. This allows the target directory to be specified at the head of the command line instead of the tail. This makes cp work much more nicely with tools like xargs... (allowing for major performance improvements over inline shell loops). The patch is at: http://www.freebsd.org/~jwd/cp-d.patch which allows: cp -d target_directory source1 source2 ... sourceN and/or cat big_file_list | xargs cp -d target_directory The changes required to do this turned out to be simple. Please let me know if you have any comments. Note: I do not have a man page update yet. Working with man pages on current appears to be broken. nroff/groff are also producing bad output on freefall.. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIO* doc added to tty.4 (review)
Hi, I wondered about this. However, after looking around what I found was that the FIO* requests seemed to be documented in driver pages (and only a handful at that), and not documented with ioctl. Since I don't want to change the other existing driver man pages, what if I add generic documentation to the ioctl along with a comment saying to look at the individual driver man pages for information specific to the driver. ie: FIONREAD will succeed from a backgrounded process, but the data read itself with hang (tty driver). Thanks, John ps: Is cross-referencing #define values frowned upon? It would be nice if "man -k FIONREAD" (for instance) would return useful results. - Garrett Wollman's Original Message - On Sun, 15 Apr 2001 22:26:37 -0700, "John W. De Boskey" [EMAIL PROTECTED] said: I've been doing some tty related work and found the FIO* requests don't seem to be documented. I've added some reasonable doc to tty.4 and put up the the diff and html forms: As the initial letter suggests, they are generic file ioctls and not specific to the teletype driver. They should be described in the ioctl(2) manual page. -GAWollman 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
FIO* doc added to tty.4 (review)
Hi, I've been doing some tty related work and found the FIO* requests don't seem to be documented. I've added some reasonable doc to tty.4 and put up the the diff and html forms: http://people.freebsd.org/~jwd/doc/tty.4.html http://people.freebsd.org/~jwd/doc/tty.4.diff Any comments are welcome. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel.c disklabel.8 patch
Hi, I've been using the disklabel.c patch which allows easier configuration by being able to specify a new disklabel of the form: #size offsetfstype [fsize bsize bps/cpg] a: 400M04.2BSD 4096 1638475 # (Cyl.0 - 812*) b: 1G* swap c: **unused e: 204800*4.2BSD f: 5g*4.2BSD g: **4.2BSD An up-to-date copy of disklabel.c can be found at: http://people.freebsd.org/~jwd/disklabel.c The man page can be found at: http://people.freebsd.org/~jwd/disklabel/disklabel.8 or in html format: http://people.freebsd.org/~jwd/disklabel/disklabel.8.html Patch files: http://people.freebsd.org/~jwd/disklabel/disklabel.c.patch http://people.freebsd.org/~jwd/disklabel/disklabel.8.patch I'd like to commit these if no one sees any major problems with them. These patches are the original work of Randell Jesup, and I believe Matt Dillon, with additional work by Warner Losh. Please let me know if I've left someone out. Incorporated into this is the fix for PR bin/22727. A simple one character fix. Comments Welcome! -John ps: The .html file was generated via groff. It seems to have some interesting side effects with the '[' and ']' characters. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release - no luck
Hi, I've been trying to create a -current release for awhile now and have run into numerouse problems. However, this one seems to be reproducible (last 3 days or so): -- stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes cd /usr/src/include;make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo "$COPYRIGHT" osreldate.h; echo \#'undef __FreeBSD_version' osreldate.h; echo \#'define __FreeBSD_version' $RELDATE osreldate.h === rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h rpcgen: cannot find any C preprocessor (cpp) *** Error code 1 Stop in /usr/src/include/rpcsvc. *** Error code 1 Stop in /usr/src/include. *** Error code 1 There is a cpp in /usr/obj/usr/src/i386/usr/bin which is really /snap/release/usr/obj/usr/src/i386/usr/bin. I'll look into this more closely if no one has any quick answers. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current kernel panic: ufs_ihashget
Hi, I'm getting the following panic when I run the following command: tar -cvf - . | compress | dd bs=64m of=/dev/sa0 running with a blocksize of 2,4,8,16, or 32meg on the dd command run to completion with no problems. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x293944 instruction pointer = 0x8:0xc02a119f stack pointer = 0x10:0xd720dca4 frame pointer = 0x10:0xd720dcb4 code segment= base 0x0, limit 0xf, type = 0x1b = DPL 0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, IOPL = 0 current process = 290 (tar) trap number = 12 panic: page fault nm /boot/kernel/kernel | grep c02a11 | sort c02a1100 T ufs_ihashinit c02a1120 T ufs_ihashlookup c02a1168 T ufs_ihashget c02a11fc T ufs_ihashins System is -current as of 11:30am EST, Mon Dec 4, 2000 (today :-) dmesg output is included below. I'll compile up a kernel with gdb tomorrow. (Yes, it replicates...) -John Copyright (c) 1992-2000 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: Mon Dec 4 15:50:25 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/FreeBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 797416080 Hz CPU: Pentium III/Pentium III Xeon/Celeron (797.42-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 534933504 (522396K bytes) avail memory = 516440064 (504336K bytes) Preloaded elf kernel "kernel" at 0xc041a000. ccd0-3: Concatenated disk drivers Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 11 entries at 0xc00fbbe0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: Intel model 1132 VGA-compatible display device at 2.0 irq 9 pcib1: Intel 82801BA (ICH2) Hub to PCI bridge at device 30.0 on pci0 pci1: PCI bus on pcib1 ahc0: Adaptec 2940/DUAL Ultra SCSI adapter port 0xec00-0xecff mem 0xfdfff000-0xfdff irq 9 at device 7.0 on pci1 aic7895: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec 2940/DUAL Ultra SCSI adapter port 0xe800-0xe8ff mem 0xfdffe000-0xfdffefff irq 10 at device 7.1 on pci1 aic7895: Single Channel B, SCSI Id=7, 32/255 SCBs amr0: AMI MegaRAID port 0xe480-0xe4ff irq 3 at device 9.0 on pci1 amr0: Series 428 Firmware U.77, BIOS 1.47, 32MB RAM xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xe400-0xe47f mem 0xfdffdc00-0xfdffdc7f irq 3 at device 12.0 on pci1 xl0: Ethernet address: 00:b0:d0:7d:7c:8e miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: Intel 82801BA (ICH2) PCI to LPC bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: UHCI (generic) USB controller port 0xff80-0xff9f irq 11 at device 31.2 on pci0 uhci0: (New UHCI DeviceId=0x24428086) usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: (0x24428086) UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: Intel 82801BA (ICH2) SMBus controller at 31.3 irq 10 pci0: Intel 82801BA (ICH2) AC'97 Audio Controller at 31.5 irq 10 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 isa_dmainit(2, 1024) failed fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 unknown: PNP0501 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0303 can't assign resources ad0: 19092MB WDC WD200BB-75AUA1 [38792/16/63] at ata0-master UDMA100 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master using PIO4 Waiting 5 seconds for SCSI devices to settle amrd0: MegaRAID logical drive on amr0 amrd0: 69112MB (141541376 sectors) RAID 0
No console on AlphaServer 2000 4/233 4.2-RC2
Hi, Console, console, where's the console? We are attempting to use FreeBSD 4.2-RC2 on an AlphaServer 2000 4/233 and are running into trouble with the console device. When we boot from the CD, it comes up to the boot prompt on the console where we tell it to boot from the cd device. The cd then boots up to the following: /stand/sysinstall running as init on serial console These are the predefined terminal types available to sysinstall when running stand-alone. Please choose the closest match for your particular terminal. 1 .. Standard ANSI terminal. 2 .. VT100 or compatible terminal. 3 .. FreeBSD system console (color) 4 .. FreeBSD system console (monochrome) 5 .. xterm terminal emulator Your choice: (1-5) At this point, no keyboard input is accepted. We then successfully installed onto an AlphaServer 1000 and moved the disks to the 2000. At this point the console is still useless, but we can telnet into the machine and use it... I've included the dmesg output below. Note, on the console after boot, but right before the useless login prompt: Cannot open /dev/ttyv0: not such device or address and from ls: %ls -al /dev/ttyv0 crw--- 1 root wheel 12, 0 Nov 21 10:02 /dev/ttyv0 So, it seems getty can't open the virtual terminal devices. A ps -aux right after boot: PID PPID UID %CPU %MEM STAT TIME COMMAND 0 0 0 0.0 0.0 DLs0:00.00 (swapper) 1 0 0 0.0 0.2 ILs0:00.03 (init) 2 0 0 0.0 0.0 DL 0:00.00 (pagedaemon) 3 0 0 0.0 0.0 DL 0:00.00 (vmdaemon) 4 0 0 0.0 0.0 DL 0:00.00 (bufdaemon) 5 0 0 0.0 0.0 DL 0:00.07 (syncer) 83 1 0 0.0 0.4 Ss 0:00.57 syslogd -s 86 1 1 0.0 0.3 Is 0:00.01 /usr/sbin/portmap 102 1 0 0.0 0.5 Is 0:00.13 inetd -wW 104 1 0 0.0 0.5 Is 0:00.04 cron 107 1 0 0.0 0.8 Is 0:00.05 sendmail: accepting connections (sen 111 1 0 0.0 0.8 Is 0:05.88 /usr/sbin/sshd 141 102 0 0.0 0.9 Ss 0:00.37 telnetd 142 141 896 0.0 0.3 Is 0:00.23 -ksh (ksh) 159 142 0 0.0 0.3 S 0:00.26 -su (ksh) 206 159 0 0.0 0.2 R+ 0:00.00 /bin/ps -axo pid aux 140 1 0 0.0 0.4 Is+0:00.05 /usr/libexec/getty Pc console and dmesg: (Yes, the 1st 2 lines are from dmesg, and I cannot find where they are coming from yet). Unrecognized boot flag '0'. Unrecognized boot flag ','. Copyright (c) 1992-2000 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 4.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ALPHADOG DEC AlphaServer 2100 AlphaServer 2000 4/233, 233MHz 8192 byte page size, 1 processor. CPU: EV45 (21064A) major=6 minor=2 OSF PAL rev: 0x4000c0002012d real memory = 266264576 (260024K bytes) avail memory = 254279680 (248320K bytes) Preloaded elf kernel "kernel" at 0xfc5f8000. md0: Malloc disk pci0: PCI bus on pcib0 sym0: 810 port 0x1-0x100ff mem 0x8108-0x810800ff irq 33 at device 1.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: interrupting at T2 irq 33 isab0: Intel 82375EB PCI-EISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 pci0: unknown card (vendor=0x1011, dev=0x0004) at 6.0 irq 32 de0: Digital 21143 Fast Ethernet port 0x10100-0x1017f mem 0x81080100-0x8108017f irq 36 at device 7.0 on pci0 de0: interrupting at T2 irq 36 de0: DEC DE500-BA 21143 [10-100Mb/s] pass 3.0 de0: address 00:00:f8:07:3a:b7 pci0: unknown card (vendor=0x10d5, dev=0x0002) at 8.0 irq 37 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 12.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 12.4 irq 65 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 13.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 13.4 irq 65 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at T2 irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: interrupting at T2 irq 1 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: interrupting at T2 irq 12 psm0: model Generic PS/2 mouse, device ID 0 mcclock0: MC146818A real time clock at port 0x70-0x71 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at T2 irq 4 sio1: reserved for low-level i/o ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Polled port ppc0: interrupting at T2 irq 7
Re: No console on AlphaServer 2000 4/233 4.2-RC1
Grr... make that 4.2-RC1 FreeBSD 4.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000 -john - John W. De Boskey's Original Message - Hi, Console, console, where's the console? We are attempting to use FreeBSD 4.2-RC2 on an AlphaServer 2000 4/233 and are running into trouble with the console device. When we boot from the CD, it comes up to the boot prompt on the console where we tell it to boot from the cd device. The cd then boots up to the following: /stand/sysinstall running as init on serial console These are the predefined terminal types available to sysinstall when running stand-alone. Please choose the closest match for your particular terminal. 1 .. Standard ANSI terminal. 2 .. VT100 or compatible terminal. 3 .. FreeBSD system console (color) 4 .. FreeBSD system console (monochrome) 5 .. xterm terminal emulator Your choice: (1-5) At this point, no keyboard input is accepted. We then successfully installed onto an AlphaServer 1000 and moved the disks to the 2000. At this point the console is still useless, but we can telnet into the machine and use it... I've included the dmesg output below. Note, on the console after boot, but right before the useless login prompt: Cannot open /dev/ttyv0: not such device or address and from ls: %ls -al /dev/ttyv0 crw--- 1 root wheel 12, 0 Nov 21 10:02 /dev/ttyv0 So, it seems getty can't open the virtual terminal devices. A ps -aux right after boot: PID PPID UID %CPU %MEM STAT TIME COMMAND 0 0 0 0.0 0.0 DLs0:00.00 (swapper) 1 0 0 0.0 0.2 ILs0:00.03 (init) 2 0 0 0.0 0.0 DL 0:00.00 (pagedaemon) 3 0 0 0.0 0.0 DL 0:00.00 (vmdaemon) 4 0 0 0.0 0.0 DL 0:00.00 (bufdaemon) 5 0 0 0.0 0.0 DL 0:00.07 (syncer) 83 1 0 0.0 0.4 Ss 0:00.57 syslogd -s 86 1 1 0.0 0.3 Is 0:00.01 /usr/sbin/portmap 102 1 0 0.0 0.5 Is 0:00.13 inetd -wW 104 1 0 0.0 0.5 Is 0:00.04 cron 107 1 0 0.0 0.8 Is 0:00.05 sendmail: accepting connections (sen 111 1 0 0.0 0.8 Is 0:05.88 /usr/sbin/sshd 141 102 0 0.0 0.9 Ss 0:00.37 telnetd 142 141 896 0.0 0.3 Is 0:00.23 -ksh (ksh) 159 142 0 0.0 0.3 S 0:00.26 -su (ksh) 206 159 0 0.0 0.2 R+ 0:00.00 /bin/ps -axo pid aux 140 1 0 0.0 0.4 Is+0:00.05 /usr/libexec/getty Pc console and dmesg: (Yes, the 1st 2 lines are from dmesg, and I cannot find where they are coming from yet). Unrecognized boot flag '0'. Unrecognized boot flag ','. Copyright (c) 1992-2000 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 4.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ALPHADOG DEC AlphaServer 2100 AlphaServer 2000 4/233, 233MHz 8192 byte page size, 1 processor. CPU: EV45 (21064A) major=6 minor=2 OSF PAL rev: 0x4000c0002012d real memory = 266264576 (260024K bytes) avail memory = 254279680 (248320K bytes) Preloaded elf kernel "kernel" at 0xfc5f8000. md0: Malloc disk pci0: PCI bus on pcib0 sym0: 810 port 0x1-0x100ff mem 0x8108-0x810800ff irq 33 at device 1.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: interrupting at T2 irq 33 isab0: Intel 82375EB PCI-EISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 pci0: unknown card (vendor=0x1011, dev=0x0004) at 6.0 irq 32 de0: Digital 21143 Fast Ethernet port 0x10100-0x1017f mem 0x81080100-0x8108017f irq 36 at device 7.0 on pci0 de0: interrupting at T2 irq 36 de0: DEC DE500-BA 21143 [10-100Mb/s] pass 3.0 de0: address 00:00:f8:07:3a:b7 pci0: unknown card (vendor=0x10d5, dev=0x0002) at 8.0 irq 37 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 12.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 12.4 irq 65 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 13.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 13.4 irq 65 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at T2 irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: interrupting at T2 irq 1 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: interrupting at T2 irq 12 psm0: model Generic PS/2 mouse, device ID 0 mcclock0: MC146818A real time clock at port 0x70-0x71 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at
Highspeed serial consoles and -current
Hi, I'm trying to increase the speed of the serial console on a -current box from 9600 to 38400. I've put the following in /etc/make.conf: BOOT_COMCONSOLE_SPEED=38400 # serial console speed Unfortunately, it doesn't work. It still runs at 9600. I remember seeing something about this (I thought) in one of the mailing lists, but I can't seem to find it. If anyone can shed some light, I'd appreciate it. I'll be happy to summarize and provide a doc update. Thanks, John ps: Just a note, I have serial console and login working on ttyd0 at 9600. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getty bug when run by hand
- Bruce Evans's Original Message -
On Mon, 13 Nov 2000, John W. De Boskey wrote:
When the following command is run as root:
/usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1
the call to login_tty() fails in the opentty() function:
else {
login_tty(i);
return 1;
}
However, the return code is not checked. File descripters 0,
1, and 2 are not modified to point at ttyd1, and the getty then
proceeds to run on the current terminal session.
At a minimum, I'd like to commit the following patch. It would
have helped avoid some frustrating moments...
===
RCS file: /home/ncvs/src/libexec/getty/main.c,v
retrieving revision 1.31
diff -u -r1.31 main.c
--- main.c 2000/10/10 01:53:00 1.31
+++ main.c 2000/11/14 02:25:31
@@ -444,7 +444,10 @@
return 0;
}
else {
- login_tty(i);
+ if (login_tty(i) 0) {
+ syslog(LOG_ERR, "login_tty %s: %m", ttyn);
+ return 0;
+ }
return 1;
}
}
This needs a "close(i);" for the error case.
This of course then leads to the question of why the
TIOCSCTTY ioctl call failes. From the above change:
Nov 13 17:25:47 mail getty[1236]: login_tty /dev/ttyd1: Operation not
permitted
This is because the process isn't a session leader. It isn't a session
leader because the setsid() call before the ioctl failed (and it wasn't
a session leader before that). The result of the setsid() is ignored,
which is correct if setsid() failed due to the process already being a
session leader, but obfuscates the error otherwise. setsid() fails
because the process is a process group leader. This is the normal
environment for processes started from shells. Session, process group
and controlling terminal stuff is all set up for normal job control, and
is difficult of impossible to change except in a new process.
getty works when it is started from init because init doesn't do much
setup for getty. It only sets up a controlling terminal for running
/etc/rc and for single user mode...
Bruce
I re-written the patch to fix the error case, and to allow getty
to be run from a command line and DTRT. I have this running on
my system right now (from /etc/ttys, and from a console). I'd like
to commit this unless anyone sees any fatal mistakes I've made.
Thanks,
-John
freefall:/d/home/jwd/src/src/libexec/getty/main.c
cvs diff: Diffing .
Index: main.c
===
RCS file: /home/ncvs/src/libexec/getty/main.c,v
retrieving revision 1.31
diff -u -r1.31 main.c
--- main.c 2000/10/10 01:53:00 1.31
+++ main.c 2000/11/14 19:26:17
@@ -444,7 +444,18 @@
return 0;
}
else {
- login_tty(i);
+ if (login_tty(i) 0) {
+ if (daemon(0,0) 0) {
+ syslog(LOG_ERR,"daemon: %m");
+ close(i);
+ return 0;
+ }
+ if (login_tty(i) 0) {
+ syslog(LOG_ERR, "login_tty %s: %m", ttyn);
+ close(i);
+ return 0;
+ }
+ }
return 1;
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
getty bug when run by hand
Hi,
I've been working on serial ports/consoles the last few days
and have run into what I consider a bug in getty (-current)..
When the following command is run as root:
/usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1
the call to login_tty() fails in the opentty() function:
else {
login_tty(i);
return 1;
}
However, the return code is not checked. File descripters 0,
1, and 2 are not modified to point at ttyd1, and the getty then
proceeds to run on the current terminal session.
At a minimum, I'd like to commit the following patch. It would
have helped avoid some frustrating moments...
===
RCS file: /home/ncvs/src/libexec/getty/main.c,v
retrieving revision 1.31
diff -u -r1.31 main.c
--- main.c 2000/10/10 01:53:00 1.31
+++ main.c 2000/11/14 02:25:31
@@ -444,7 +444,10 @@
return 0;
}
else {
- login_tty(i);
+ if (login_tty(i) 0) {
+ syslog(LOG_ERR, "login_tty %s: %m", ttyn);
+ return 0;
+ }
return 1;
}
}
This of course then leads to the question of why the
TIOCSCTTY ioctl call failes. From the above change:
Nov 13 17:25:47 mail getty[1236]: login_tty /dev/ttyd1: Operation not
permitted
It's worth noting that /dev/ttyd1 has been successfully openned
on fd 3 this point. The serial ports work fine with tip or kermit
and from dmesg are:
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
comments welcome.
-John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
tar : needs some attention?
Hi, Each night I run a 'make release' and then tar it off to a public storage area... For some time now, tar has been complaining... tar: cdrom/disc2/dev/acd0t32: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t33: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t34: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t35: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t36: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t37: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t38: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped Is this the expected behaviour, or is it worth digging into tar and making some fixes? -John ps: This is on a current machine :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
boot_crunch make release ppp
... are not liking each other after the lastest ppp commits. I do not have time to look into this until late tomorrow (and no, I don't see any commits which would appear to fix this yet). -John crunchide -k _crunched_usbdevs_stub usbdevs.lo cc -static -o boot_crunch boot_crunch.o sh.lo find.lo sed.lo test.lo rm.lo pwd.lo ppp.lo sysinstall.lo newfs.lo minigzip.lo cpio.lo fsck.lo ifconfig.lo route.lo slattach.lo mount_nfs.lo dhclient.lo arp.lo hostname.lo rtsol.lo pccardc.lo pccardd.lo usbd.lo usbdevs.lo -ll -ledit -lutil -lkvm -lmd -lcrypt -lftpio -lz -lnetgraph -ldialog -lncurses -lmytinfo -ldisk -lipx ppp.lo: In function `MPPEKeyChange': ppp.lo(.text+0x2b261): undefined reference to `GetNewKeyFromSHA' ppp.lo(.text+0x2b27a): undefined reference to `RC4_set_key' ppp.lo(.text+0x2b28e): undefined reference to `RC4' ppp.lo: In function `MPPEOutput': ppp.lo(.text+0x2b31f): undefined reference to `RC4_set_key' ppp.lo(.text+0x2b35c): undefined reference to `RC4' ppp.lo(.text+0x2b381): undefined reference to `RC4' ppp.lo: In function `MPPEInput': ppp.lo(.text+0x2b4bb): undefined reference to `RC4_set_key' ppp.lo(.text+0x2b4dc): undefined reference to `RC4' ppp.lo(.text+0x2b512): undefined reference to `RC4' ppp.lo: In function `MPPEInitInput': ppp.lo(.text+0x2b7f0): undefined reference to `GetAsymetricStartKey' ppp.lo(.text+0x2b801): undefined reference to `GetNewKeyFromSHA' ppp.lo: In function `MPPEInitOutput': ppp.lo(.text+0x2b8f4): undefined reference to `GetAsymetricStartKey' ppp.lo(.text+0x2b905): undefined reference to `GetNewKeyFromSHA' *** Error code 1 Stop in /usr/obj/usr/src/release/boot_crunch. *** Error code 1 Stop in /usr/src/release. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /stand/sysinstall fdisk won't work
I believe you need to update sysinstall.
The following is what I do to update sysinstall on our
'make release' machine. Similar should work for you (change
sysinstalldir MAKEOBJDIR).
-John
#
# Install sysinstall into /stand/sysinstall (binary manpage)
#
function do_sysinstall {
sysinstalldir="$RDIR/usr/src/release/sysinstall"
if [[ -d $sysinstalldir ]]; then
cd $sysinstalldir
pwd
export MAKEOBJDIR=/snap/release/usr/obj/usr/src/release/sysinstall
make obj make all install;
return 0
else
echo "Hey! Where is $sysinstalldir!!"
return 0
fi
bail 1 "Installation of sysinstall failed!"
# NotReached
return 1
}
- [EMAIL PROTECTED]'s Original Message -
After installing the latest version of the current source,
/stand/sysinstall's fdisk will not find any devices. Can anybody tell me
what I forgot to do? I did do the /dev/MAKEDEV all.
JAn
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
vinum fsck wrappers strangeness
Hi, I ran into an interesting gotcha with fsck and vinum... I have the following line in /etc/fstab: /dev/vinum/raid5/pubufs rw 2 2 and during an upgrade (old current to current), I commented the line out during the reboot process. After bringing the new system online, I executed: /sbin/fsck -y /dev/vinum/raid5 and received the following error: fsck: exec /usr/sbin/fsck_unused for /dev/vinum/raid5: No such file or directory Knowing that I've been able to fsck this volume in the past I checked for a vinum specific fsck binary. Nothing there. It then occurred to me it's a ufs volume, and I've always fsck'd it by mount point. I then uncommented the line in /etc/fstab and executed: /sbin/fsck -y /pub and it worked correctly. After the above (with the /etc/fstab line uncommented), I re-executed:o /sbin/fsck -y /dev/vinum/raid5 and it worked correctly. So, it appears that fsck is attempting to determine a file system type, tries to use /etc/fstab, and then falls back to a secondary scheme. In the secondary scheme, ufs is what we want, but vinum is what we're getting. If anyone has any information about this please let me know. I'll try to look into it tomorrow. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release failure - ipfilter(osreldate.h)
Subject says it. I'll try to look at it later this evenning. === ipfilter cc -O -pipe -DIPFILTER=1 -DIPFILTER_LKM -DIPFILTER_LOG -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c In file included from /usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c:44: @/netinet/ip_compat.h:268: osreldate.h: No such file or directory *** Error code 1 Stop in /usr/src/sys/modules/ipfilter. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. *** Error code 1 --- Sat Oct 28 16:09:16 EDT 2000 - build of 5.0-20001028-SNAP was an abject failure. Sources current as of 11:50am EST. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
Jordan writes a nice piece of mail... If this was happening in -stable I'd be in total agreement. However, we're talking -current, and is not -current the integration area for new technologies, whether they be rough or round edged? This reminds me of the old development arguement: Don't do that, it hurts me. which has caused alot of good code to never see the light of day. -John - Jordan Hubbard's Original Message - The issue is one of seeding the device strongly. If all you care about is getting a different fortune when you boot then seeding with e.g. the system boot time would be enough, but obviously it doesnt make /dev/random cryptographically secure. I think there's a more general point being made here - if we're not seeding /dev/random effectively at startup, fortune is the least of our worries since all the other startup services will be unrandom as well. This situation I see with /dev/random is kind of disturbing since I think we're running the danger of falling into the following all-too-common scenario in engineering: 1) Person X falls in love with a new algorithm or technique and implements it in a fairly key service with quite a few rough edges. 2) The users fail to embrace this new technology all that fervently since those same rough edges make it a promising but annoying or downright non-functional implementation. 3) Person X vigorously defends himself and/or the algorithm since he knows it's really a much better thing in the long run and simply needs "tweaking" to make it fully work. 4) The users see this as an attempt to cram broken bits down their throats and just as vigorously fight back against what they see as someone's fancy solution in search of a problem to solve. 5) Constructive dialog breaks down and it all turns into an exchange of increasingly irritated words as each side feels the other isn't hearing what it's trying to say or appreciating the bigger pictures. Let's try not to go there with /dev/random, please. :) - Jordan 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
src/release/Makefile patch so cdrom will autoboot
Don't want to step on toes.. Someone please commit. I believe
we need to 'load /kernel' no matter what... it's the
'read' that's in question. Allows a cdrom to autoboot.
patch also located at ~jwd/src/src/release/Makefile.patch so you
don't have to cut'n'paste.
-John
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.576
diff -u -r1.576 Makefile
--- Makefile2000/10/24 19:05:39 1.576
+++ Makefile2000/10/25 23:01:44
@@ -827,8 +827,8 @@
${RD}/kernels/BOOTMFS.${FSIMAGE}.hints \
${RD}/image.${FSIMAGE}/boot/device.hints \
echo "include /boot/device.hints" ${RD}/image.${FSIMAGE}/boot/loader.rc
-.if !defined(FDSIZE) || ${FDSIZE} != "BIG"
@echo "load /kernel" ${RD}/image.${FSIMAGE}/boot/loader.rc
+.if !defined(FDSIZE) || ${FDSIZE} != "BIG"
@echo "echo \\007\\007" ${RD}/image.${FSIMAGE}/boot/loader.rc
@echo "echo Please insert MFS root floppy and press enter:"
${RD}/image.${FSIMAGE}/boot/loader.rc
@echo "read" ${RD}/image.${FSIMAGE}/boot/loader.rc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: entropy reseeding is totally broken
Also, what rev of /etc/rc do you have installed? -john - Mark Murray's Original Message - I'm not knocking anyone or any code, especially considering this IS -current... BUT... I don't need to read the code to know that I am seeing the same fortunes on first login after reboot more often than I can attribute to random chance. Maybe nanotime is being harvested, but it seems that there is a time lag between system startup and reaching a state of "true pseudo-entropy". Also, every reboot has entropy caching failing to work. I don't know if this is a product of the broken reseeding or what, because the /etc/rc files seem to be fine. I am not seeing this, and I am unable to reproduce it. i terefore need better info than "it is so" to do anything about it. Please get a complete log of the boot process (put a set -x in /etc/rc while you are about it) and get that over to me. M To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current hangs during boot (UPDATING entry)
Thanks for the updates. A few questions below. -John - Mark Hittinger's Original Message - It does look like an updating entry is needed for this badly. I did the following things, some of which may not be needed, and now my -current boxes boot OK. 1. update MAKEDEV from /usr/src/etc, run MAKEDEV all 2. update /etc/rc /etc/rc.* /etc/defaults/rc.conf from /usr/src/etc 3. add random_load="YES" to /boot/loader.conf or add the random device to the kernel config file. 4. update /etc/login.conf from /usr/src/etc I don't remember having to do this... was there a specific reason? 5. do a "shutdown -r now" which creates the entropy file and reboots Now the system boot does not hang at the ldconfig spots. It does look like there is a lot to do to get back on course, enough to justify adding to UPDATING. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ftp vs. nfs install times
Hi, I've tested last nights make release built install via both ftp and nfs and am seeing some rather strange results timeing wise: A full install (ie: select ALL) w/ ports. NFS: about 18 minutes. (ave. about 1000KB/sec) FTP: about 70 minutes. (ave. about 45KB/sec) on the same box after the install, I can ftp to the server and mget all the files in just a few moments. ie: The snap server I'm using isn't the problem. Any ideas of what the best way to debug this from the holographic shell might be? Some tools are available, others are available but don't work (like top). While this is happenning, the idle process is accumulating time almost lockstep with walltime. Ideas welcome. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage on today's -current
The following patch brings the floppy size down enough to fix the problem. One is a leftover from the config file syntax change. Also, I don't know how useful INET6 is to a GENERIC kernel on todays' networks (faith gif are already removed). Index: dokern.sh === RCS file: /mirror/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.37 diff -r1.37 dokern.sh 43c43 -e '/apm0/d' \ --- -e '/apm/d' \ 46a47 -e '/INET6/d' \ 65c66 -e '/apm0/d' \ --- -e '/apm/d' \ 68a70 -e '/INET6/d' \ I'll commit this later today unless I hear objections. -John - Makoto MATSUSHITA's Original Message - Maybe kernel image for kern.flp is a little bit larger than a 1.44MB floppy. *** linking BOOTMFS text data bss dec hex filename 2613503196388 130744 2940635 2cdedb BOOTMFS install -c -m 555 -o root -g wheel -fschg BOOTMFS /R/stage/kernels mv /R/stage/kernels/BOOTMFS /R/stage/image.kern/kernel Setting up /boot directory for kern floppy /R/stage/image.kern/kernel:54.9% -- replaced with /R/stage/image.kern/kernel.gz sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 8 fd1440 disklabel: ioctl DIOCWLABEL: Operation not supported by device Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvnn1c: 2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. *** FYI: You can also fetch (last 50 lines of) logfile via: URL:ftp://current.jp.freebsd.org/pub/FreeBSD/snapshots/i386/5.0-CURRENT-20001024-JPSNAP.log "finger [EMAIL PROTECTED]" will also provide you the same result. -- - 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
make release breakage - dokern.sh patch 2
Ok, folks want INET6. It's back.. It's been pointed out to me by "Thomas D. Dean" [EMAIL PROTECTED] that the 'le' driver does not work. Can someone provide additional information about why it's in GENERIC? Other candidates I've been pointed to include the removal of /boot/boot[12] and NFS (which I seem to remember Jordan axing at one point before we went to a 2 disk set). So, the 2nd try at the patch is below. Comments welcome. -John Index: dokern.sh === RCS file: /mirror/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.37 diff -r1.37 dokern.sh 40a41 -e '/ le/d' \ 43c44 -e '/apm0/d' \ --- -e '/apm/d' \ 63c64,65 sed -e '/pty/d' \ --- sed -e '/ le/d' \ -e '/pty/d' \ 65c67 -e '/apm0/d' \ --- -e '/apm/d' \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current hangs during boot (UPDATING entry)
It didn't work without the device line when I tested it last week(Thursday/Friday). -John - David O'Brien's Original Message - On Mon, Oct 23, 2000 at 06:30:29PM -0400, John W. De Boskey wrote: 2. Make sure your kernel includes: device random # Entropy device Are you implying the random.ko module is broken? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage - dokern.sh patch 2
- David O'Brien's Original Message - On Tue, Oct 24, 2000 at 02:36:44PM -0400, John W. De Boskey wrote: the 'le' driver does not work. Can someone provide additional information about why it's in GENERIC? Get confirmation that it does not work (one user isn't suffient in my book as there could be many issues which could make it ``not work'' for one person). That's part of what this mail is/was for. Other candidates I've been pointed to include the removal of /boot/boot[12] and NFS IMO NFS needs to stay. It is *very* useful to many (including me). I haven't removed it. But it is an option. I was a very heavy user of NFS, but it didn't matter to jkh when he removed it last time. The switch to ftp isn't hard. P.S. PLEASE trim the CC line. It has gotten redictulously long. To the point some might consider not sending a single message on this thread, else they'll get their mailbox flooded from then on. I copied those folks who responded to my original mail. Standard curtesy. I did not copy you on this. -John -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current hangs during boot (UPDATING entry)
I'm beginning to think we need an updating entry. 1. Make sure /dev/random exists 'cd /dev sh MAKEDEV std' 2. Make sure your kernel includes: device random # Entropy device 3. Make sure /etc/rc is at rev 1.237 or higher. 4. Make sure /etc/rc.shutdown is at rev 1.13 or 1.15 5. At this time, remove ALL MFS filesystems from /etc/fstab. They can be hand mounted after bootup or via a local rc startup script. 6. Reboot your system via 'init 6' or 'shutdown -r now' (or similar). Do not use 'reboot'. 7. If at any time during the boot process a 'cntrl-t' shows a process hung in 'rndblk', hit 'cntrl-\', 'ls -al /etc /dev/random', and then 'exit'. This should get your machine to boot for this session until you figure out which of the above are not done. -John - Brian O'Shea's Original Message - On Sun, Oct 22, 2000 at 07:35:39PM -0400, John W. De Boskey wrote: - David O'Brien's Original Message - On Sun, Oct 22, 2000 at 04:14:08PM +0800, Donny Lee wrote: with the mfs enable, it hangs there right after FILESYSTEM checking, and with random_load set to YES, it hangs at ldconfig. mount_mfs is blocking on "rndblk". Our /dev/*random is fubar'ed *again*. I saw this the other day... I've been examining the mfs code, and I'm not really sure why it needs to use random values... When ldconfig hangs, it is in a mkstemp() call. The mkstemp() function probably uses random numbers to generate unique file names: #0 0x8054340 in read () #1 0x804c966 in mktemp () #2 0x804ca33 in arc4random_stir () #3 0x804cad9 in arc4random () #4 0x804c791 in mktemp () #5 0x804c692 in mkstemp () #6 0x804886a in write_elf_hints () #7 0x8048818 in update_elf_hints () #8 0x8048c61 in main () #9 0x8048139 in _start () -brian -- Brian O'Shea [EMAIL PROTECTED] 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 hangs during boot (UPDATING entry)
- Makoto MATSUSHITA's Original Message - jwd 5. At this time, remove ALL MFS filesystems from /etc/fstab. jwdThey can be hand mounted after bootup or via a local rc jwdstartup script. Is there any chance to mount MFS filesystem listed in /etc/fstab just after the /dev/random reseeding is done ? I cannot put up with that we cannot put 'mfs' line to /etc/fstab forever. Moreover, /tmp (common MFS candidate) is already used by X server after rebooting; you may not want to mount /tmp at hand later. Or, it's only for upgrading procedure, and we can put 'mfs' lines back? #5 above represents a bug in the current code. It needs to be fixed, but I don't know what the 'correct' thing to do is just yet. Does the FSIRAND code in mfs require crypto strength randomness? -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
See below..
- Bruce Evans's Original Message -
On Sun, 22 Oct 2000 [EMAIL PROTECTED] wrote:
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes
the problem.
With just a quick review of the patch, I'm not sure I
understand what forces the last dirty buffer to be
written.
This worried me too.
Try the enclosed patch. It flushes the dirty buffer before
program exit and before reading blocks.
There are still some serious (?) overflow bugs.
Index: mkfs.c
===
RCS file: /home/ncvs/src/sbin/newfs/mkfs.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -c -2 -r1.29 -r1.30
*** mkfs.c1999/08/28 00:13:50 1.29
--- mkfs.c2000/10/17 00:41:36 1.30
...
***
*** 1341,1344
--- 1347,1381
}
if (Nflag)
+ return;
+ done = 0;
+ if (wc_end == 0 size = WCSIZE) {
+ wc_sect = bno;
+ bcopy(bf, wc, size);
+ wc_end = size;
+ if (wc_end WCSIZE)
+ return;
+ done = 1;
+ }
+ if (wc_sect * sectorsize + wc_end == bno * sectorsize
^ overflow ^ overflow
I agree it's an overflow, and I'll get a patch in for it. But
from a lucky point of view, since the overflow occurs on both sides
of the test, it's a serendipidoues match which doesn't hurt, or
the match fails, which causes the cache to flush.
+ wc_end + size = WCSIZE) {
+ bcopy(bf, wc + wc_end, size);
+ wc_end += size;
+ if (wc_end WCSIZE)
+ return;
+ done = 1;
+ }
+ if (wc_end) {
+ if (lseek(fso, (off_t)wc_sect * sectorsize, SEEK_SET) 0) {
^^^ must cast like this to prevent overflow
Well, the above can overflow, but the probability of it overflowing
when things are working correctly approaches zero :-)
Regardless, we could put in a test to make sure the final offset
computed is valid.
-john
+ printf("seek error: %ld\n", (long)wc_sect);
+ err(35, "wtfs - writecombine");
+ }
+ n = write(fso, wc, wc_end);
+ if (n != wc_end) {
+ printf("write error: %ld\n", (long)wc_sect);
+ err(36, "wtfs - writecombine");
+ }
+ wc_end = 0;
+ }
+ if (done)
return;
if (lseek(fso, (off_t)bno * sectorsize, SEEK_SET) 0) {
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current hangs during boot
- Leif Neland's Original Message - On Sun, 22 Oct 2000, Donny Lee wrote: Hi there, I've done a very recent week's make world(S) on -current, making and installing world and kernel go fine, but all hang on boot, with no error codes or msgs. Solution: Due to changes in the random/entropy stuff, you have to reboot the machine with "shutdown -r now" or Ctrl-alt-del, not "reboot". (Why do we have a separate reboot command? Couldn't it just be an alias for shutdown -r now?) See pr 14829 and: http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/rc revision 1.235 for a few additional comments. -John Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current hangs during boot
- David O'Brien's Original Message - On Sun, Oct 22, 2000 at 04:14:08PM +0800, Donny Lee wrote: with the mfs enable, it hangs there right after FILESYSTEM checking, and with random_load set to YES, it hangs at ldconfig. mount_mfs is blocking on "rndblk". Our /dev/*random is fubar'ed *again*. I saw this the other day... I've been examining the mfs code, and I'm not really sure why it needs to use random values... Anyone know the history on the '#ifdef FSIRAND' code? -john ps: break out of the boot sequence, 'ls -al /etc/ /dev/random' and then 'exit' will get around this and other problems, but requires hands on reboots. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newfs/fsck problem (bad superblocks)
Hi, I posted a question concerning fsck yesterday. A number of people replied with the 'bad harddisk' comment. I have followed up some more on the problem, and can now reproduce it on different filesystems. Below, I umount my /usr/obj, newfs it, mount it, unmount it, and then fsck it. The fsck complains about a bad superblock. Also, do not remotely reboot after this if the newly newfs'd filesystem is automounted in /etc/fstab. The boot process will hang waiting for fsck to be run manually. Example: + %umount /usr/obj %newfs /dev/ccd0a Warning: 1616 sector(s) in last cylinder unallocated /dev/ccd0a: 672 sectors in 1628 cylinders of 1 tracks, 4096 sectors 3255.2MB in 102 cyl groups (16 c/g, 32.00MB/g, 4096 i/g) super-block backups (for fsck -b #) at: 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, 6488096, 6553632, 6619168 %mount /dev/ccd0a /usr/obj %df -m /usr/obj Filesystem 1M-blocks UsedAvail Capacity Mounted on /dev/ccd0a 32010 2944 0%/usr/obj %umount /usr/obj %/sbin/fsck -y /dev/ccd0a ** /dev/ccd0a BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE LOOK FOR ALTERNATE SUPERBLOCKS? yes USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 1638914 free (18 frags, 204862 blocks, 0.0% fragmentation) UPDATE STANDARD SUPERBLOCK? yes * FILE SYSTEM WAS MODIFIED * % + I am wondering about the following patch : peter 2000/10/16 17:41:37 PDT Modified files: sbin/newfs mkfs.c Log: Implement simple write combining for newfs - this is particularly useful for large scsi disks with WCE = 0. This yields around a 7 times speedup on elapsed newfs time on test disks here. 64k clusters seems to be the sweet spot for scsi disks using our present drivers. Revision ChangesPath 1.30 +38 -1 src/sbin/newfs/mkfs.c I will revert this patch tomorrow. I also wonder if this is related to the 'make release' problems. Comments welcome. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newfs/fsck problem (bad superblocks)
Reverting src/sbin/newfs/mkfs.c to revision 1.29 fixes the problem. With just a quick review of the patch, I'm not sure I understand what forces the last dirty buffer to be written. revert the patch? try to fix it? comments? -John - John W. De Boskey's Original Message - Hi, I posted a question concerning fsck yesterday. A number of people replied with the 'bad harddisk' comment. I have followed up some more on the problem, and can now reproduce it on different filesystems. Below, I umount my /usr/obj, newfs it, mount it, unmount it, and then fsck it. The fsck complains about a bad superblock. Also, do not remotely reboot after this if the newly newfs'd filesystem is automounted in /etc/fstab. The boot process will hang waiting for fsck to be run manually. Example: + %umount /usr/obj %newfs /dev/ccd0a Warning: 1616 sector(s) in last cylinder unallocated /dev/ccd0a: 672 sectors in 1628 cylinders of 1 tracks, 4096 sectors 3255.2MB in 102 cyl groups (16 c/g, 32.00MB/g, 4096 i/g) super-block backups (for fsck -b #) at: 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, 6488096, 6553632, 6619168 %mount /dev/ccd0a /usr/obj %df -m /usr/obj Filesystem 1M-blocks UsedAvail Capacity Mounted on /dev/ccd0a 32010 2944 0%/usr/obj %umount /usr/obj %/sbin/fsck -y /dev/ccd0a ** /dev/ccd0a BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE LOOK FOR ALTERNATE SUPERBLOCKS? yes USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 1638914 free (18 frags, 204862 blocks, 0.0% fragmentation) UPDATE STANDARD SUPERBLOCK? yes * FILE SYSTEM WAS MODIFIED * % + I am wondering about the following patch : peter 2000/10/16 17:41:37 PDT Modified files: sbin/newfs mkfs.c Log: Implement simple write combining for newfs - this is particularly useful for large scsi disks with WCE = 0. This yields around a 7 times speedup on elapsed newfs time on test disks here. 64k clusters seems to be the sweet spot for scsi disks using our present drivers. Revision ChangesPath 1.30 +38 -1 src/sbin/newfs/mkfs.c I will revert this patch tomorrow. I also wonder if this is related to the 'make release' problems. Comments welcome. -John 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
fsck not rewriting super block?
Hi, I've run into an interesting problem: ad0: 19473MB Maxtor 92049U6 [39566/16/63] at ata0-master UDMA33 ad1: 19541MB Maxtor 52049H4 [39703/16/63] at ata0-slave UDMA33 I have swap and two large partitions on ad1: #size offsetfstype [fsize bsize bps/cpg] b: 104857600 swap# (Cyl.0 - 10402*) c: 400205610unused0 0 # (Cyl.0 - 39702*) e: 25165824 104857604.2BSD 1024 819216 # (Cyl. 10402*-35368*) f: 4368977 356515844.2BSD 1024 819216 # (Cyl. 35368*-39702*) However, the f partition will not fsck correctly: %/sbin/fsck -y /dev/ad1s1f ** /dev/ad1s1f BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE LOOK FOR ALTERNATE SUPERBLOCKS? yes USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 2116933 free (13 frags, 264615 blocks, 0.0% fragmentation) UPDATE STANDARD SUPERBLOCK? yes * FILE SYSTEM WAS MODIFIED * So, running fsck again produces the same identical output. The superblock is not updated. No failures are reported on the console or in the messages file. System is current: FreeBSD 5.0-CURRENT #0: Thu Oct 19 Any ideas on the best way to track this down are appreciated. Thanks, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current GENERIC failure (bktr_os.c:484)
Hi,
I'm seeing the following failure with sources current
as of 19:39pm EDT (Oct 19). Occurs when building the GENERIC kernel.
cc -pipe -g -D_KERNEL -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include
-mpreferred-stack-boundary=2 -c
/usr/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c
/usr/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c: In function
`bktr_detach':
/usr/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c:484: `unit'
undeclared (first use in this function)
/usr/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c:484: (Each
undeclared identifier is reported only once
/usr/src/sys/modules/bktr/bktr/../../../dev/bktr/bktr_os.c:484: for each
function it appears in.)
*** Error code 1
Stop in /usr/src/sys/modules/bktr/bktr.
*** Error code 1
From the source:
#if (__FreeBSD_version =50)
if (unit == 0) {
destroy_dev(bktr-vbidev_alias);
destroy_dev(bktr-tunerdev_alias);
destroy_dev(bktr-bktrdev_alias);
}
#endif
Looks like we need a:
unsigned intunit;
unit = device_get_unit(dev);
at the head of the function (wrapped in __FreeBSD_version =50 ??)
Comments welcome.
Thanks,
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
