Re: Mount before SCSI comes up ? (was Re: Root mount failed:22 ???)
On Fri, Nov 19, 1999 at 02:52:13PM -0800, Mike Smith wrote: The diagnostic is relatively harmless, but it suggests that /etc/fstab is wrong. Here is fstab line, please point what is wrong? /dev/da0s4a / ufs rw,userquota 1 1 I have no idea; it'd be handy to know what it's trying to mount that's failing, but I don't recall that in your output. It is NOT say, what it tries to mount that failing :-( That's because it's not actually trying to mount anything. vfs_mountroot_try() is being called with a NULL argument, almost certainly because your loader is out of date (vfs.root.mountfrom does not exist in the environment). It's possible that there's a problem with the loader that's resulting in it not being set; you should instrument /sys/boot/common/boot.c:getrootmount() to determine this. It's also possible that it's being called for some other reason; you should look at vfs_mountroot() to see what else might be the culprit. Here is quote in more wide scope. Is it tries to mount root before SCSI devices come up? No; 22 is EINVAL, wheras you would exepect ENXIO (6) for that case. Waiting 2 seconds for SCSI devices to settle Creating DISK da0 Creating DISK da1 Root mount failed: 22 Mounting root from ufs:da0s4a This completes successfully, so everything looks happy. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Root mount failed:22 ???
I see this: Root mount failed: 22 This suggests you may have an old loader, or the loader's parsing of your /etc/fstab file may be failing. I probably need to add a diagnostic to it to help us track this down. Mounting root from ufs:da0s4a [snip] Root mount failed: 6 Mounting root from ufs:da0a -- this is defined in my config file This indicates that we're using the fallback code (intended for this purpose), and that you have a "truly dedicated" disk, ie. the s4 entry is "historically bogus", so whilst the kernel etc. was loaded using slice 4, the disk is not actually sliced at all. There would need to be _two_ error 6 failures before you got to the point where the compiled-in default was tried, I think. It's normal. Some change which phk introduced into /sys/kern/vfs_conf.c, I think. No. It _shouldn't_ be normal, provided that your /etc/fstab refers to the correct device. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VERSION undefined in
-- --- Bruce Burden[EMAIL PROTECTED] Tandem Computers Inc. 512-432-8944Network Verification 14231 Tandem Blvd. Auto answer(4 rings) Austin, TX 78726 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VERSION undefined in /usr/src/gnu/usr.bin/grep/grep.c
Okay, here is the problem: cc -O -pipe -DGREP -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MEMCHR=1 -DHAVE_STRERROR=1 -DHAVE_VALLOC=1 -DHAVE_WORKING_MMAP=1 -DHAVE_LIBZ=1 -DHAVE_FTS=1 -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/grep/dfa.c cc -O -pipe -DGREP -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MEMCHR=1 -DHAVE_STRERROR=1 -DHAVE_VALLOC=1 -DHAVE_WORKING_MMAP=1 -DHAVE_LIBZ=1 -DHAVE_FTS=1 -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/grep/grep.c /usr/src/gnu/usr.bin/grep/grep.c: In function `main': /usr/src/gnu/usr.bin/grep/grep.c:1314: `VERSION' undeclared (first use in this function) /usr/src/gnu/usr.bin/grep/grep.c:1314: (Each undeclared identifier is reported only once /usr/src/gnu/usr.bin/grep/grep.c:1314: for each function it appears in.) Here is the Makefile header: # $FreeBSD: src/gnu/usr.bin/grep/Makefile,v 1.18 1999/11/20 09:40:03 peter Exp $ MAINTAINER= wosch Obviously I could simply define anything I wanted for "VERSION" in the cflags, and go on my merry way, but I thought I would ask what VERSION was supposed to be, and point out that it is missing. Thanks, Bruce -- --- Bruce Burden[EMAIL PROTECTED] Tandem Computers Inc. 512-432-8944Network Verification 14231 Tandem Blvd. Auto answer(4 rings) Austin, TX 78726 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Root mount failed:22 ???
I see this: Root mount failed: 22 This suggests you may have an old loader, or the loader's parsing of your /etc/fstab file may be failing. I probably need to add a diagnostic to it to help us track this down. Okay, here's another one. I have 3.3-STABLE on wd0s1a, and -current (from 18. November) on wd0s1d. I boot this by pressing the space bar so I get the "boot: " prompt, and then typing "wd(0,d)kernel". This works fine, except I get the "Root mount failed" error message: ad0: IBM-DTTA-351010/T56OA73A ATA-4 disk at ata0 as master ad0: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 31 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 ... Root mount failed: 22 Mounting root from ufs:wd0s1d This is what my fstab for -current looks like: # DeviceMountpoint FStype Options DumpPass# /dev/wd0s1b noneswapsw 0 0 /dev/wd0s1d / ufs rw 1 1 /dev/wd0s1f /usrufs rw 2 2 /dev/wd0s1h /local ufs rw 2 2 proc/proc procfs rw 0 0 With the commit you just did to vfs_conf.c I guess it'll be silent after the next time I've cvsup'ed and built world - I'm just wondering why this happens now. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Root mount failed:22 ???
This suggests you may have an old loader, or the loader's parsing of your /etc/fstab file may be failing. I probably need to add a diagnostic to it to help us track this down. Okay, here's another one. I have 3.3-STABLE on wd0s1a, and -current (from 18. November) on wd0s1d. I boot this by pressing the space bar so I get the "boot: " prompt, and then typing "wd(0,d)kernel". This works fine, except I get the "Root mount failed" error message: You should be using the loader to load the kernel. wd(0,d)/boot/loader would be correct. With the commit you just did to vfs_conf.c I guess it'll be silent after the next time I've cvsup'ed and built world - I'm just wondering why this happens now. You're not using the loader, so nothing gets to read /etc/fstab and set vfs.root.mountfrom. Thus the kernel can't use it to find the root filesystem. I should probably emit a diagnostic to the effect that it wasn't set, since in many cases to come that will be fatal for the boot process. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NewATA on ISA and PCI
Please wrap your messages to 72 columns like other civilised authors. No, I do not talking about /etc/fstab, I'm talking about what device kernel is using to mount root *before* starting /sbin/init (e.g. "changing root device to ..." in dmesg). Hmm, the bootblock or the loader might be responsible This is -current. If the message is "changing root device to..." you are out of date and must update before we can help you. The root mount code has changed quite a lot just recently, and debugging the 'old' code isn't practical anymore. You are not right - I'm usually rebuilding kernel in one-three days, and world in a week. My current kernel built from sources sup'ed (cvsup.freebsd.org) yesterday. There is no room for me to be "not right"; the "changing root device to" message has been gone for quite some time now. If you are seeing it, you are "not right" and are running code built from old sources. To cover your original point; an up-to-date -current kernel correctly booted will mount the device listed in /etc/fstab as the root device "*before* starting /sbin/init". The re-mount of the root filesystem subsequently performed will actually re-use the device that's already mounted there, _not_ the entry from /etc/fstab (this is an enhancement designed to make life easier when /etc/fstab is not quite right, eg. when the kernel has had to guess about the root filesystem, or when it's been moved maually). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dd and gzip'd files
I recently tried using dd to transfer a binary image to floppy. It was the Linux root disk image, color.gz. Basically, dd works ok with non-gzipped files, but with files in gzip format, it chokes: root@lc186 floppies# dd if=color.gz of=/dev/rfd0 dd: /dev/rfd0: Invalid argument 2453+1 records in 2453+0 records out 1255936 bytes transferred in 42.665771 secs (29437 bytes/sec) Notice the line that says: 2453+1 records in ^^ For some reason, it is offsetting to 1 before writing to disk. No, that's not what it means. You are ignoring the error message on the preceeding line. "2453+1" means that it has read 2453 complete records and one extra byte. The 'fd' driver has (correctly) refused to write the single trailing byte. It appears to have worked. I guess the output block size of 16k is key for floppies, then. The conv=osync does the padding. No, the block size requirement for floppies is 512 bytes, as it is for almost any device. conv=osync is correct if you insist on using the raw device. Note that the optimal block size for 1.44MB floppies is 9k (one track). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dd and gzip'd files
It appears to have worked. I guess the output block size of 16k is key for floppies, then. The conv=osync does the padding. I use 18K (one cylinder) but any multiple of 9k should work well. No, the block size requirement for floppies is 512 bytes, as it is for almost any device. conv=osync is correct if you insist on using the raw device. as this is -current, we only have raw devices now, remember? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fsck follies
I was giving vinum + softupdates a bit of a workout on 4 really old SCSI disks (Sun shoeboxes, if you must know) attached to an aha1542B. The rest of the machine is a Pentium 133 with 64MB of parity ram, a few more disks, and another aha1542B. It runs -current (about 10 days old now). I was copying a newer -current source tree onto the box when I lost power to my house for maybe half a second. Being foolish and shortsighted, I have no UPS. (An interesting side note: out of the 3 machines in use at the time, 2 of the keyboards locked up and required a power down to recover. I was unaware that keyboards could crash.) When the system came back up, fsck -p didn't like the vinum volume. No sweat, I ran it manually. There were many INCORRECT BLOCK COUNT I=n (4 should be 0) messages. I assumed this was an artifact of soft updates. The fsck completed successfully. Being paranoid, I reran fsck. This time it reported a number of unreferenced inodes (199 to be exact), and linked them in to lost+found. It is this last item that bothers me. When the first fsck completed, the filesystem should have been structurally correct. But it wasn't. A third fsck confirmed that 2 runs of fsck were enough. I seem to recall sagely advice from days gone by to always run fsck twice and sync thrice. I thought I could forget all that stuff nowadays. By the way, I saved the broken old source tree and compared it to the full tree. There were no unusual differences, except for the broken one being incomplete. So, if fsck were a little better, things would be fine. As good as you could expect, given a power failure. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: flashplugin
Add Cc: to current...
Hi,
Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] wrote:
www/flashplugin dies under CURRENT's gcc 2.95.2 with:
=== Building for flashplugin-0.4.3
c++ -O2 -pipe -I/usr/X11R6/include -I./Lib -I./Plugin -fpic -fno-rtti
-DXP_UNIX -O2 -DCHECK_TEXT_PLAIN -c ./Lib/bitmap.cc
{standard input}: Assembler messages:
{standard input}:1211: Error: no such 386 instruction: `fild'
*** Error code 1
Does not matter if I use -O or -O2 happens on both.
Funy thing is I tried grepping in the sources for fild but couldn't find
it.
Ideas are welcome to solve this since I am a little in the dark now.
Gcc 2.95.2 output asmcodes which contain 'fild' opcode, but
/usr/libexec/aout/as (a.out version of as) does not support 'fild'.
# /usr/libexec/elf/as (elf version of as) support 'fild'.
I found "make -DWANT_AOUT world" of today's -current fails for
the same reason.
=== libmp
cc -O2 -m486 -pipe -I/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpn/x86
-I/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpz -DBERKELEY_MP
-I/usr/src/gnu/lib/libmp/../../../contrib/libgmp
-I/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpn/generic -DBROKEN_ALIGN
-I/usr/obj/aout/usr/src/gnu/lib/libmp -I/usr/obj/aout/usr/src/tmp/usr/include
-c /usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpz/pow_ui.c
-o mpz/pow_ui.o
{standard input}: Assembler messages:
{standard input}:52: Error: no such 386 instruction: `fild'
*** Error code 1
Stop in /usr/src/gnu/lib/libmp.
*** Error code 1
I think we must add the 'fild' opcode to src/gnu/usr.bin/as/opcode/i386.h.
--
Motoyuki Konno [EMAIL PROTECTED] (Univ)
[EMAIL PROTECTED] (Home)
[EMAIL PROTECTED] (FreeBSD Project)
Yamanashi Medical Universityhttp://www.freebsd.org/~motoyuki/ (WWW)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP: (USB only) usb.h changed, recompile usbdevs
HEADS UP: (USB only) Fields have been added to the usb_devinfo struct, so at least src/usr.sbin/usbdevs needs to be recompiled for the latest and greatest kernel. Ezload, available in ports/misc/ezload, as well if you use it. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dd and gzip'd files
I recently tried using dd to transfer a binary image to floppy. It was the Linux root disk image, color.gz. Basically, dd works ok with non-gzipped files, but with files in gzip format, it chokes: root@lc186 floppies# dd if=color.gz of=/dev/rfd0 dd: /dev/rfd0: Invalid argument 2453+1 records in 2453+0 records out 1255936 bytes transferred in 42.665771 secs (29437 bytes/sec) Notice the line that says: 2453+1 records in ^^ For some reason, it is offsetting to 1 before writing to disk. No, that's not what it means. You are ignoring the error message on the preceeding line. "2453+1" means that it has read 2453 complete records and one extra byte. The 'fd' driver has (correctly) refused to write the single trailing byte. Small technical correction, the value after the + is not bytes, but number of partial blocks: When finished, dd displays the number of complete and partial input and output blocks, truncated input records and odd-length byte-swapping blocks to the standard error output. A partial input block is one where less than the input block size was read. A partial output block is one where less than the output block size was written. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fsck follies
On Sun, Nov 21, 1999 at 10:36:32PM +1000, Stephen McKay wrote: When the system came back up, fsck -p didn't like the vinum volume. No sweat, I ran it manually. There were many INCORRECT BLOCK COUNT I=n (4 should be 0) messages. I assumed this was an artifact of soft updates. The fsck completed successfully. Being paranoid, I reran fsck. This time it reported a number of unreferenced inodes (199 to be exact), and linked them in to lost+found. It is this last item that bothers me. When the first fsck completed, the filesystem should have been structurally correct. But it wasn't. A third fsck confirmed that 2 runs of fsck were enough. Presumably you are using vinum for mirroring? I have had to stop doing so after trashing several filesystems. There are some serious bugs that allow the plexes to get out of sync; as reads from a mirror set are round-robin, this can be very bad. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
a bad sysinstall/useredit problem
I just tried to install a 4.0 snap on a machine with a 3com netcard, this doesn't work, and whats worse I can't make it work. The problem is that the ex0 or ie0 driver, I'm not sure which, hoses the 3com card such that the ep driver cannot read the serial eeprom. I used to be able to disable the ex0 and ie0 drivers in userconfig but that is no longer possible it seems. Anyone know enough about how userconfig works these days to fix this ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Root mount failed:22 ???
On Sun, Nov 21, 1999 at 12:51:59AM -0800, Mike Smith wrote: You're not using the loader, so nothing gets to read /etc/fstab and set vfs.root.mountfrom. Thus the kernel can't use it to find the root filesystem. I should probably emit a diagnostic to the effect that it wasn't set, since in many cases to come that will be fatal for the boot process. I just rebuild/reinstall -current /kernel and /sys/boot and update bootblocks via disklabel, as result diagnostic in question gone, but I _not_ see vfs.root.mountfrom variable in my sysctl -a output. -- Andrey A. Chernov http://nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC+ D A a++ C G+ QH+(++) 666+++ Y To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Root mount failed:22 ???
"Andrey A. Chernov" wrote: On Sun, Nov 21, 1999 at 12:51:59AM -0800, Mike Smith wrote: You're not using the loader, so nothing gets to read /etc/fstab and set ^^ vfs.root.mountfrom. Thus the kernel can't use it to find the root filesystem. I should probably emit a diagnostic to the effect that it wasn't set, since in many cases to come that will be fatal for the boot process. I just rebuild/reinstall -current /kernel and /sys/boot and update bootblocks via disklabel, as result diagnostic in question gone, but I _not_ see vfs.root.mountfrom variable in my sysctl -a output. Loader/kernel environment variables are not sysctls. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Then again maybe not going to heaven would be a blessing. Relkin liked a certain amount of peace and harmony, since there'd been a pronounced shortage of them in his own life; however, nothing but peace and harmony, forever and forever? He wasn't sure about that. And no beer? Very dubious proposition." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a bad sysinstall/useredit problem
I just tried to install a 4.0 snap on a machine with a 3com netcard, this doesn't work, and whats worse I can't make it work. The problem is that the ex0 or ie0 driver, I'm not sure which, hoses the 3com card such that the ep driver cannot read the serial eeprom. I used to be able to disable the ex0 and ie0 drivers in userconfig but that is no longer possible it seems. Anyone know enough about how userconfig works these days to fix this ? Er, it ought to still be possible. What happens when you try? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Root mount failed:22 ???
On Sun, Nov 21, 1999 at 12:51:59AM -0800, Mike Smith wrote: You're not using the loader, so nothing gets to read /etc/fstab and set vfs.root.mountfrom. Thus the kernel can't use it to find the root filesystem. I should probably emit a diagnostic to the effect that it wasn't set, since in many cases to come that will be fatal for the boot process. I just rebuild/reinstall -current /kernel and /sys/boot and update bootblocks via disklabel, as result diagnostic in question gone, but I _not_ see vfs.root.mountfrom variable in my sysctl -a output. I had hoped I made it clear earlier; vfs.root.mountfrom is a kernel environment variable, not a sysctl variable. You can read the kernel environment from the kern.environment sysctl in a slightly non-obvious fashion: get the oid for kern.environment (two values), then add one more value to the oid and iterate it from 0 until you receive ENOENT. Each read will return one string from the kernel environment. You're probably right in that it should be exposed in the sysctl space, yes. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a bad sysinstall/useredit problem
In message [EMAIL PROTECTED], Mike Smith writes: I just tried to install a 4.0 snap on a machine with a 3com netcard, this doesn't work, and whats worse I can't make it work. The problem is that the ex0 or ie0 driver, I'm not sure which, hoses the 3com card such that the ep driver cannot read the serial eeprom. I used to be able to disable the ex0 and ie0 drivers in userconfig but that is no longer possible it seems. Anyone know enough about how userconfig works these days to fix this ? Er, it ought to still be possible. What happens when you try? It doesn't even show the ie0 driver in visual mode... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
failure in build
I've been seeing this failure since I tried to rebuild my system
(last built on 10/9/99
I didn't see anything in UPDATING or on this list. I'm wondering if
there's a possible hardware problem -- but it's done it 3 times and
I've cvsup'd three times yesterday and today and started with the
same source tree...
while in /usr/src/gnu/lib
=== libdialog
=== libgcc
=== libgcc_r
=== libgmp
=== libgmp/doc
=== libmp
cc -O -pipe -mcpu=i386 -I/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpn/x86
-I/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpz -DBERKELEY_MP
-I/usr/src/gnu/lib/libmp/../../../contrib/libgmp
-I/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpn/generic -DBROKEN_ALIGN
-I/usr/obj/aout/usr/src/gnu/lib/libmp -I/usr/obj/aout/usr/src/tmp/usr/include -c
/usr/src/gnu/lib/libmp/../../../contrib/libgmp/mpz/pow_ui.c -o mpz/pow_ui.o
{standard input}: Assembler messages:
{standard input}:54: Error: no such 386 instruction: `fild'
*** Error code 1
Stop in /usr/src/gnu/lib/libmp.
*** Error code 1
Stop in /usr/src/gnu/lib.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
---
[EMAIL PROTECTED]|[EMAIL PROTECTED]
Three things never anger: First, the one who runs your DEC,
The one who does Field Service and the one who signs your check.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: installing onto ami mega raid.
I spent about 2 to 3 hours last night futzing with sysinstall and getting the amr.ko file onto the 4.0 install disk (using the 4.0-19991114 SNAP) I tried adding the amr disks to devices.c in sysinstall but had no luck. Bah. I knew I forgot something there. That should just about have done it. After booting the install disks and loading the amr kld (the probe messages showed that it was detected) I escaped to the prompt (alt+f4). I saw that the amrd0 /dev/ entries had been created, but attempts to access them gave "unit 0 not available" (as far as i remeber) That's not an error message that the driver can produce. It'd be helpful to know what it actually said, and whether you have actually created an array yet. What exactly needs to be done to get 4.0 installed with a amr disk as root? Sysinstall needs the patch you supplied; apart from that I'm not aware of anything else. I haven't, obviously, had time to work on this yet. A better diagnostic from you above would save me at least one release build... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing onto ami mega raid.
On Sun, 21 Nov 1999, Mike Smith wrote: I spent about 2 to 3 hours last night futzing with sysinstall and getting the amr.ko file onto the 4.0 install disk (using the 4.0-19991114 SNAP) I tried adding the amr disks to devices.c in sysinstall but had no luck. Bah. I knew I forgot something there. That should just about have done it. After booting the install disks and loading the amr kld (the probe messages showed that it was detected) I escaped to the prompt (alt+f4). I saw that the amrd0 /dev/ entries had been created, but attempts to access them gave "unit 0 not available" (as far as i remeber) That's not an error message that the driver can produce. It'd be helpful to know what it actually said, and whether you have actually created an array yet. What exactly needs to be done to get 4.0 installed with a amr disk as root? Sysinstall needs the patch you supplied; apart from that I'm not aware of anything else. I haven't, obviously, had time to work on this yet. A better diagnostic from you above would save me at least one release build... Unfortunatly all the amr systems I have are now in production, I can not test a new install on them. The way I did manage to do the install was nfs mounting another machine's /, /usr, and /var then using dump/restore to init the system over a hand done disklabel on the amr (disklabel, not sysinstall). I'm sorry. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing onto ami mega raid.
[moving this off -current] On Sun, 21 Nov 1999, Alfred Perlstein wrote: Unfortunatly all the amr systems I have are now in production, I can not test a new install on them. The way I did manage to do the install was nfs mounting another machine's /, /usr, and /var then using dump/restore to init the system over a hand done disklabel on the amr (disklabel, not sysinstall). I'm sorry. Mike, I have a brand spanking new poweredge with PERC SC/2 give me (or Jeremy, CC'd) a call at the number in my .signature and we'll test whatever you want us to. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - PS. Jeremy, I'm talking about 'tiger'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Route table leaks
Have any of you been seeing route table leaks in -current? I noticed
this week that cvsup-master.freebsd.org is suffering from them. I
actually had to reboot it because it couldn't allocate any more. From
the "vmstat -m" output:
Memory statistics by type Type Kern
Type InUse MemUse HighUse Limit Requests Limit Limit Size(s)
[...]
routetbl150907 21221K 21221K 21221K 4621840 0 16,32,64,128,256
Watching it again now after the reboot, the {In,Mem,High}Use numbers
are climbing steadily. Also the references to the default route as
reported by "netstat -rn" are climbing. (They went from 187 to 193 in
the past 2 minutes or so.)
The machine is running -current from September 29. It's only doing
a couple of things:
* Running a CVSup server for the mirrors.
* Running a shell script which does a CVSup from freefall every
6 minutes, or as fast as it can go when it takes longer than
that.
The only other network daemons running on the machine are routed,
syslogd, xntpd, portmap, ypbind, sshd, and sendmail (in outbound-only
mode). No NFS, no amd.
I can think of some experiments to try in order to start to diagnose
it. But first, have any of you seen this problem?
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Netscape and -current
This happens with a kernel/world from today: netscape is unusable. Most of the time it freezes after a few seconds. Here is the tail of kdump: 484 communicator-4.7 RET select 0 484 communicator-4.7 CALL old.sigprocmask(0x1,0) 484 communicator-4.7 RET old.sigprocmask 0 484 communicator-4.7 CALL gettimeofday(0xbfbfb874,0) 484 communicator-4.7 RET gettimeofday 0 484 communicator-4.7 CALL old.sigprocmask(0x3,0) 484 communicator-4.7 RET old.sigprocmask 0 484 communicator-4.7 CALL old.sigprocmask(0x1,0x2000) 484 communicator-4.7 RET old.sigprocmask 0 484 communicator-4.7 CALL select(0xa,0x50011f48,0,0x50011f08,0x50011efc) 484 communicator-4.7 RET select 0 484 communicator-4.7 CALL gettimeofday(0x50011dac,0) 484 communicator-4.7 RET gettimeofday 0 484 communicator-4.7 CALL old.sigprocmask(0x3,0) 484 communicator-4.7 RET old.sigprocmask 8192/0x2000 484 communicator-4.7 CALL gettimeofday(0x50011f60,0) 484 communicator-4.7 RET gettimeofday 0 484 communicator-4.7 PSIG SIGALRM caught handler=0x8fea40 mask=0x0 code=0x0 484 communicator-4.7 CALL sigreturn(0x50011ed4) 484 communicator-4.7 RET sigreturn -1 errno 14 Bad address Any idea? Jean-Marc -- Jean-Marc ZucconiPGP Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FYI: KAME netinet6 basic part is committed
Hello, FYI, KAME(IPv6, IPsec, and etc update kit for BSDs, http://www.kame.net) netinet6 basic part is committed to freebsd-current. It doesn't yet include several important parts (e.g.no IPsec, no v6 multcast forwarding, no TCP/UDP for IPv6 yet), but now it can assigne IPv6 addr automatically and can reply to IPv6 ping, if the kernel is built with "INET6" kernel config option. Please take care because inpcb structure is changed to be shared between netinet and netinet6. You will need to update include files to build several inpcb aware tools and applications. (fstat, netstat, systat, etc) Yoshinobu Inoue KAME project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP! The bridge drivers for sound cards have been committed.
The bridge drivers for sound cards have just been committed. These drivers will accomodate coming newmidi drivers. People using Sound Blaster 16/AWE32/AWE64/ViBRA16C/ViBRA16X should add sbc driver to your kernel config file in addition to pcm driver, rebuild and reinstall a new kernel. See LINT as well. This commit also adds pcm support for the following cards: GUS PnP and non-PnP ISA (gusc driver) Crystal Semiconductor CS461x/428x PCI (csa driver) For a GUS non-PnP ISA card, write down the configuration of your card to gusc, not pcm. Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
