Re: fd0: Debugger(d_iocmd botch) called.
Bruce wrote: On Fri, 24 Mar 2000, Jim Bloom wrote: FreeBSD mailing list wrote: This patch does indeed fix the writing of floppies. However, fdformat(1) still fails as follows: That is very strange. My patch only applies to formatting floppies. It did not touch any routine used in writing a floppy. I have no idea at this time what is causing your other problems. I am unable to write to a floppy at this time. I'm not seeing any errors, but nothings is getting written. Reading of floppies is broken too. The wrong flags are passed to isa_dmastart(), so the DMA direction is wrong. It defaults to the most dangerous direction (ISADMA_WRITE), of course. I've confirmed that writing floppies seemingly works just fine, although I can't read at all. I've written a number of floppy boot images and checked them out, as well as performed a newfs_msdos and verified it on DOS machines. Cheers, -scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
Jim Bloom wrote:
Upgrade sys/vm/swap_pager.c to the current version. There was a bug there which
has been fixed.
Jim Bloom
[EMAIL PROTECTED]
FreeBSD mailing list wrote:
/var/log/messages indicates:
Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
I cvsup'd once more this morning... Nothing significant has changed since the
last one.
For reference:
ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c
* $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $
Nonetheless, I built a new kernel using "config -r". No change in floppy operation.
Thanks,
-scott
--
Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED]
MRY Systems [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fd0: Debugger(d_iocmd botch) called.
Jim Bloom wrote: I reproduced the problem and have attached a patch. It was the exact same problem as in swap_pager.c (assuming B_WRITE was 0). Hopefully phk will commit this fix shortly. Index: sys/isa/fd.c === RCS file: /users/ncvs/src/sys/isa/fd.c,v retrieving revision 1.179 diff -u -r1.179 fd.c --- sys/isa/fd.c 2000/03/20 11:28:39 1.179 +++ sys/isa/fd.c 2000/03/24 20:20:53 @@ -2228,6 +2228,7 @@ BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); bp-b_flags = B_PHYS | B_FORMAT; + bp-b_iocmd = BIO_WRITE; /* * calculate a fake blkno, so fdstrategy() would initiate a This patch does indeed fix the writing of floppies. However, fdformat(1) still fails as follows: ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440 Format 1440K floppy `/dev/fd0.1440'? (y/n): y Processing EE^C with /var/log/messages indicating: Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44abnrml,top_head ST1 4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 1 hd 0 sec 2) (and continuing). Additionally, reading a floppy returns errors for any read: (This is a freshly formatted floppy verified on other machines) ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc dd: /dev/rfd0.1440: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 2.395566 secs (0 bytes/sec) 0 0 0 with /var/log/messages indicating: Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40abnrml ST1 4sec_not_fnd ST2 0 cyl 0 hd 0 sec 2) Thanks, -scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fd0: Debugger(d_iocmd botch) called.
Accessing fd0 (1440) floppies have been impossible with CURRENT
on both test machines here since 4.0 was released. The following
are as of cvsup yesterday:
(83) [11:30pm]
ttyp8:--ROOT--@mrynet (83): dd if=/dev/rfd0.1440 bs=512 x
dd: /dev/rfd0.1440: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 2.390958 secs (0 bytes/sec)
/var/log/messages indicates:
Mar 23 23:30:09 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-127 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
(84) [11:32pm]
ttyp8:--ROOT--@mrynet (84): fdformat -f 1440 fd0.1440
Format 1440K floppy `/dev/fd0.1440'? (y/n): y
Processing ^C--
/var/log/messages indicates:
Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0
40abnrml ST1 4sec_not_fnd ST2 0
cyl 0 hd 0 sec 2)
Mar 23 23:32:49 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0
44abnrml,top_head ST1
4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2)
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0
44abnrml,top_head ST1
4sec_not_fnd ST2 0 cyl 0 hd 1 sec 2)
Mar 23 23:32:49 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:50 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0
40abnrml ST1 4sec_not_fnd ST2
0 cyl 1 hd 0 sec 2)
Mar 23 23:32:50 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0
40abnrml ST1 4sec_not_fnd ST2
0 cyl 1 hd 0 sec 2)
Mar 23 23:32:50 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:50 mrynet /kernel: fd0c: hard error reading fsbn 54 of 54-71 (ST0
44abnrml,top_head ST1
4sec_not_fnd ST2 0 cyl 1 hd 1 sec 2)
Mar 23 23:32:51 mrynet /kernel: fd0c: hard error reading fsbn 54 of 54-71 (ST0
44abnrml,top_head ST1
4sec_not_fnd ST2 0 cyl 1 hd 1 sec 2)
and on and on, had I let it run without interrupting.
Attempting to write floppies, formatted elsewhere, with dd returns the same.
I don't recall any recent reports about floppy changes or breakage.
I've searched the mailing lists via the web page, but since the searchable
portion of the mailing lists has yet to have its indexes updated this century,
and similarly the browseable portion hasn't been updated since February 20,
I can't do any further checking.
/BOFH_WHINGER_COUNTERACT
I have indeed replaced with alternate controllers, cables, and actually
even new floppy drives.
Since these floppy drives work in other machines, and the floppies
themselves format without problem elsewhere, I can only suspect CURRENT.
If this is a known issue, could someone drop me information on resolving
it?
If not, could someone with a recent kernel (within a few days) let me know if
anything similar is experienced please?
dmesg follows below.
Thanks,
-scott
--
Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED]
MRY Systems [EMAIL PROTECTED]
--
(kernel was freshly cvsup'd and built just prior to the stamp below)
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #3: Thu Mar 23 21:24:35 PST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/MRYMACH6
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 451023632 Hz
CPU: AMD-K6(tm) 3D processor (451.02-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x58c Stepping = 12
Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX
AMD Features=0x8800SYSCALL,3DNow!
real memory = 134217728 (131072K bytes)
avail memory = 125960192 (123008K bytes)
Preloaded elf kernel "kernel" at 0xc038f000.
VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc032c422 (122)
VESA: ATI MACH64
K6-family MTRR support enabled (2 registers)
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: AcerLabs M1541 (Aladdin-V) PCI host bridge on motherboard
pci0: PCI bus on pcib0
pcib1: AcerLabs M5243 PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: ATI Mach64-GZ graphics accelerator at 0.0
pci0: AcerLabs M5237 (Aladdin-V) USB controller at 2.0 irq 11
isab0: AcerLabs M1533 portable PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: AcerLabs Aladdin ATA33 controller port
0xf000-0xf00f,0x374-0x377,0x170-0x17f,0x3f4-0x3f7,0x1f0-0x1ff at device 15.0 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ed0: NE2000 PCI Ethernet (ProLAN) port 0xe000-0xe01f irq 5 at device 18.0 on pci0
ed0: supplying EUI64: 00:20:78:ff:fe:12:07:39
ed0: address 00:20:78:12:07:39, type NE2000 (16 bit)
ahc0: Adaptec 2940 Ultra SCSI adapter port 0xe400-0xe4ff mem 0xed00-0xed000fff
irq 10 at device 20.0 on pci0
ahc0:
Re: sshd in current....no config files in /etc/ssh
I did the following to manually set up ssh after the world build: cp /usr/src/crypto/openssh/sshd_config /etc/ssh It's as simple as that. Then when you reboot next, the host key will be regenerated by /etc/rc.network, provided you updated that from /usr/src/etc as well. If you don't want to wait until reboot to start sshd, do: /usr/bin/ssh-keygen -N "" -f /etc/ssh/ssh_host_key This is the command used by /etc/rc.network. It Worked For Me. You know people, it's quite sad that those with knowledge simply refuse to answer simple questions without "RTFM" attitudes and indirect (and more frequently direct) insults to intelligence and sensibilities. There is absolutely no reason why you can't submit the help, with suggestion toward ones perception of "the Right Way" to do it, rather than beat the issue to death with superior posturing. Pursue your Ideal Methodologies, but try some constructiveness rather than the Attitudes of the Norm common on other development lists. -scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
The fact remains, however -- If moused_enable is set to YES, and the mouse is not present, the kernel crashes when trying to start moused, and it crashes VERY hard. It is a total freeze. This crash is the issue. I'm pursuing the fact that if this is reproducible elsewhere that it is unacceptable. I've now done a completely clean cvs and world build, and the same for the kernel. The problem is still occuring. Would you carry out the following test? 1. Boot the system, but don't run moused yet. 2. Run moused as follows: moused -d -f -p /dev/cuaa0 -i all You should see something like the following (if everything is Ok :-) zeus# moused -d -f -p /dev/cuaa0 -i all moused: PnP COM device rev 1.0 probe... moused: modem status 03 moused: alternate probe... moused: cannot determine mouse type on /dev/cuaa0 /dev/cuaa0 unknown unknown generic zeus# I would like to know at which point your system hangs. (BTW, the above output is obtained from my -CURRENT box cvsupped and compiled on 8 February.) Kazu The following is, as indicated, a kernel built from Jan 24 cvs snap. Everything with this kernel is fine. ttyp1:--ROOT--@portley (2)# uname -a FreeBSD portley.mrynet.com 4.0-CURRENT FreeBSD 4.0-CURRENT #24: Mon Jan 24 17:36:27 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/PORTLEY i386 ttyp1:--ROOT--@portley (1)# moused -d -f -p /dev/cuaa0 -i all moused: PnP COM device rev 1.0 probe... moused: modem status 03 moused: alternate probe... moused: cannot determine mouse type on /dev/cuaa0 /dev/cuaa0 unknown unknown generic The kernel built today exhibits the same as mentioned before: hard hang. Nothing at all moves. Not even the keyboard lights for CAPS, etc. Just for graphics: ttyp1:--ROOT--@portley (2) moused -d -f -p /dev/cuaa0 -i all [The computer is now frozen solid] Lemme know if I should check anything else that might be amiss on my end, of if I can test anything else for you. Thanks Kazu, -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: moused hangs HARD when mouse not plugged in
You have a multiport serial card in your system, right? What is it and how do you configure it in your kernel configuration file? Here's the relevant bits (note: sio0 has been tried without 0x10): # generic multi-I/O card with 16550 type UARTS device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 # STB-4 4-port serial - non-AST compatible device sio2at isa? port 0x1f8 flags 0x705 device sio3at isa? port 0x1e8 flags 0x705 device sio4at isa? port 0x2a8 flags 0x705 device sio5at isa? port 0x1a8 flags 0x705 irq 10 # S-LINK 4-port serial AST compatible device sio6at isa? port 0x180 flags 0x901 device sio7at isa? port 0x188 flags 0x901 device sio8at isa? port 0x190 flags 0x901 device sio9at isa? port 0x198 flags 0x901 irq 5 Cheers, -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
moused hangs HARD when mouse not plugged in
Last cvs was a few hours ago and world was installed. A kernel built from this cvs hangs dead-hard when moused runs from rc.i386 and no mouse is plugged into the psm0 port device psm0at atkbdc? irq 12 The moused config is: moused_enable="NO" # Run the mouse daemon. moused_type="mousesystems" # See man page for rc.conf(5) for available settings. moused_port="/dev/cuaa0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. I haven't tested if the kernel hangs when a mouse IS actually plugged in, but by not running moused at all the kernel so far is fine otherwise. Last kernel built was Jan 24, and it works fine when no mouse is plugged in. A log of a verbose startup follows below. Regards, Scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Fri Feb 11 14:10:38 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/PORTLEY2 Calibrating clock(s) ... i8254 clock: 1193284 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CPU: Cyrix 6x86 (486-class CPU) Origin = "CyrixInstead" DIR=0x1731 Stepping=1 Revision=7 real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0036e000 - 0x03febfff, 63430656 bytes (15486 pages) bios32: Found BIOS32 Service Directory header at 0xc00fae40 bios32: Entry = 0xfb2c0 (c00fb2c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xb2f0 pnpbios: Found PnP BIOS data at 0xc00fc070 pnpbios: Entry = f:c098 Rev = 1.0 Other BIOS signatures found: ACPI: Preloaded elf kernel "nkernel" at 0xc0355000. pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=70308086) npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=70308086) pcib0: Host to PCI bridge on motherboard found- vendor=0x8086, dev=0x7030, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base f000, size 4 found- vendor=0x8086, dev=0x7020, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=11 map[20]: type 1, range 32, base 6000, size 5 found- vendor=0x9004, dev=0x8178, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=12 map[10]: type 1, range 32, base 6100, size 8 map[14]: type 1, range 32, base e400, size 12 found- vendor=0x5333, dev=0x8811, revid=0x54 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=12 map[10]: type 1, range 32, base e000, size 26 found- vendor=0x10b7, dev=0x9050, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base 6200, size 6 pci0: PCI bus on pcib0 PCI Concurrency: enabled Cache: 256K pipelined-burst secondary; L1 enabled DRAM: no memory hole, 66 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-2-2-2 RAS-CAS delay: 3 clocks isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ12, B: IRQ12, C: disabled, D: IRQ11 MB0: IRQ15, MB1: isa0: ISA bus on isab0 ata-pci0: Intel PIIX3 ATA controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xf008 ata1: mask=00 status0=ff status1=ff pci0: Intel 82371SB (PIIX3) USB controller (vendor=0x8086, dev=0x7020) at 7.2 irq 11 ahc0: Adaptec 2940 Ultra
Re: Printer fiascos
For what its worth, I am able to reproduce this problem on my system. Simply submit something to lpr, wait for the printer light to blink, and pull the paper tray. The system hangs hard as described and does not return to normal until the paper tray is put back in. I haven't been able to make it do anything while the printer has the system hung, so I haven't been able to track it down, yet. However, I haven't had much time to spend on this problem, but thought I'd chime in a "me too" when I saw someone had the (apparently) same problem. I have an HP LaserJet 4 connected to the parallel port. I am running -current, and a buildworld as of about a week ago. -Brian -- Brian Dean [EMAIL PROTECTED] I will confirm this problem with the lpt driver. Even worse, on my LaserJet IIIsi printer... Not only did it hang the system, but I went as far as turning the printer off, then back on. THE SYSTEM REBOOTED. There was no panic or other context to share. I suspect it MAY have been related to the about of time it takes the LJ III to cycle on a power-up. Regardless, this is wholly unacceptable for a RELEASE. FWIW, my dmesg follows to show the port-type, etc. ppp0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 pps0: Pulse per second Timing Interface on ppbus0 Cheers, -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
install(1) installed too late in world
The following occured during a world build after this morning's CVSUP: === bin/rcp install -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 An install in usr.bin/xinstall fixed the problem. Last world build was two days ago. Regards, Scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/net/bridge.c IPFIREWALL DUMMYNET? WTF?
* Matthew N. Dodd [EMAIL PROTECTED] [000124 18:11] wrote: Any reason that the IPFIREWALL and DUMMYNET code is present in sys/net/bridge.c? It appears that it makes a number of bad assumptions and in general violates the semantics of 'bridging' vs. 'routing'. Should we even encourage people to use this functionality? Do we really want bridge.c to have its own private IP stack? Should this code be diked out before 4.0 so we don't expose the masses to it? I'm not sure what your proposing, if it's removing BRIDGE support from the kernel, I'd have to object. BRIDGE enables me to run a transparent firewall without worrying about routing issues, just drop a machine with BRIDGE and IPFIREWALL in between two points and everything is ok. However enable a DIVERT socket, and it all goes to hell last i checked. Anyhow, can you clarify? -Alfred I would also object. Rather than Matthew just complaining he doesn't like the coding style or the implementation, perhaps he could suggest something constructive towards improvement or redesign rather than criticise and suggest callously pitching it. This functionality has proven instrumental and necessary for transparent and effortless combining of unlike physical topologies. It also provides the extra protective measure of being able to firewall public traffic on subnetworks connected to public-traffic providers such as cable modems. The functionality of bridging is solid. The added functionality of bridging has nothing offensive to it except perhaps offending someone's idea of sensibility in this instance. Questioning code and usefulness is one thing. Presumtive resolve with disregard is another. Regards, Scott -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
YAWF: World failure- undefined reference to `RSA_PKCS1_RSAref'
cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/usr/src/i386/usr/include -o openssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto -L/usr/local/lib -lrsaref speed.o: In function `speed_main': speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref' /usr/local/lib/libcrypto.so: undefined reference to `ERR_load_RSAREF_strings' *** Error code 1 Stop in /usr/src/secure/usr.bin/openssl. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
World fail
i=== libroken cc -O -pipe -I/usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/include -I/usr/obj/usr/src/kerberosIV/lib/libroken/../../include -I/usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/lib/roken -I/usr/obj/usr/src/kerberosIV/lib/libroken -I/usr/src/kerberosIV/lib/libroken/../../include -Wall -DHAVE_CONFIG_H -I/usr/obj/usr/src/kerberosIV/lib/libroken/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -I/usr/obj/usr/src/i386/usr/include -o make-print-version /usr/src/kerberosIV/lib/libroken/../../../crypto/kerberosIV/lib/roken/make-print-version.c /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot open libgcc.a: No such file or directory *** Error code 1 Stop in /usr/src/kerberosIV/lib/libroken. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Empty core files left with coredumpsize=0 (Was Re: cc taking a signal 11)
Hi,
While I'm at it, a co-worker gave this one to me earlier today.
cc: Internal compiler error: program cc1 got fatal signal 11
4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Dec 20 01:45:25 EST 1999
FreeBSD(root)/tmp %cc -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)
FreeBSD(root)/tmp %cc -O foo.c -o foo.o -c
cc: Internal compiler error: program cc1 got fatal signal 11
static void getsig11(parfree,dbl,lambda)
long parfree;
double *dbl;
double *lambda;
{
long i, j;
j = -1;
for(i = 0; i parfree; i++) {
j += i+1;
dbl[j] *= (1.0 + *lambda);
}
return;
}
Yes, the algorithm looks funny, but is correct. The program will
compile correctly if the 'j += i+1;' is changed to 'j = i+1;' or if
the variable 'lambda' is changed from a pointer to an actual value.
Anyone want to take a stab at this? I'm not a big compiler
person myself... (Dave, you there?).
I'll verify the compiler bug exists.
However, I'll also point out that csh is still dumping empty
core files when coredumpsize is 0. This isn't happening with tcsh
though.
-Skots
--
Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED]
MRY Systems [EMAIL PROTECTED]
(Skots Gregorijs Akmentins-Teilors -- just call me "Skots")
- Labak miris neka sarkans -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kernel compile failure w/gcc2.95.2
The following is AFTER cvsup, world build, config, make clean, and make depend: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i386/isa/pcaudio.c ../../i386/isa/pcaudio.c: In function `pcawrite': ../../i386/isa/pcaudio.c:196: Invalid `asm' statement: ../../i386/isa/pcaudio.c:196: fixed or forbidden register 0 (ax) was spilled for class AREG. ../../i386/isa/pcaudio.c:196: Invalid `asm' statement: ../../i386/isa/pcaudio.c:196: fixed or forbidden register 0 (ax) was spilled for class AREG. *** Error code 1 Stop in /usr/src/sys/compile/MRYMACH. mrynet# gcc -v Using builtin specs. gcc version 2.95.2 19991024 (release) Last cvsup was completed at 05:51 +0800 on 19991115. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i386/isa/pnp.h is absent!
On Fri, 3 Sep 1999, Andrey A. Chernov wrote: Many drivers tries to include #include i386/isa/pnp.h which is absent now, please fix ASAP, kernel build fails on "make depend" I noticed this with with some NIC code too. /sys/pci/if_xl.c attempts to include "miibus_if.h" which doesn't exist and breaks make depend... a last ditch effort of pointing the include to "/usr/obj/usr/src/sys/modules/xl/miibus_if.h" allows make depend to finish, but make still dies. I found this in the LINT file: # MII bus support is required for some PCI 10/100 ethernet NICs, # namely those which use MII-compliant transceivers or implement # tranceiver control interfaces that operate like an MII. Adding # "controller miibus0" to the kernel config pulls in support for # the generic miibus API and all of the PHY drivers, including a # generic one for PHYs that aren't specifically handled by an # individual driver. controller miibus0 Including that controller resolved the miibus_if.h issues completely. It seems to me that additional commentary to the effect of: # The xl NIC controller also requires inclusion of the miibus # controller. would clear this issue up for a lotta people. -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make world failing in perl
Due to a failed world build which rendered sendmail unable to bind to a socket, which resulted in my being apparently unsubscribed, and the fact that the mailing list indexes aren't updated for a period of days, I'm unable to to check the archives regarding this problem. Perl is failing due to some kind of conflict in library versions: miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*.pm lib/*/*.pm Perl lib version (5.00502) doesn't match executable version (5.00503) at /usr/libdata/perl/5.00503/mach/Config.pm line 7. BEGIN failed--compilation aborted at /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/AutoSplit.pm line 4. BEGIN failed--compilation aborted at -e line 1. *** Error code 255 A number of cvsup's have been performed during the last two days, and this problem has persisted, as well as clearing the source tree and cvsup'ing anew, as well as the usual obj removal and clean build. Any help is, of course, appreciated ;) stay...@mrynet.com (aka free...@mrynet.com) From freebsd Mon May 3 10:56:51 1999 From: freebsd To: freebsd-current Subject: perl failure in make world Date: Mon, 3 May 1999 10:56:51 + Due to a failed world build which rendered sendmail unable to bind to a socket, which resulted in my being apparently unsubscribed, and the fact that the mailing list indexes aren't updated for a period of days, I'm unable to to check the archives regarding this problem. Perl is failing due to some kind of conflict in library versions: miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*.pm lib/*/*.pm Perl lib version (5.00502) doesn't match executable version (5.00503) at /usr/libdata/perl/5.00503/mach/Config.pm line 7. BEGIN failed--compilation aborted at /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/AutoSplit.pm line 4. BEGIN failed--compilation aborted at -e line 1. *** Error code 255 A number of cvsup's have been performed during the last two days, and this problem has persisted, as well as clearing the source tree and cvsup'ing anew, as well as the usual obj removal and clean build. Any help is, of course, appreciated ;) stay...@mrynet.com (aka free...@mrynet.com) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
