Re: -current and vmware2
On Sat, May 11, 2002 at 11:18:40AM -0700, Julian Elischer wrote: seems something broke in the networking side of things using host-only networking.. vmnet1 doesn;t show up any more.. VMWare is working fine on -CURRENT from May 7th. As Garance A Drosihn has pointed out, the vmware startup script needs to be adjusted in order to first create vmnet1 device node under /dev first and device nodes in /compat/linux/dev should be re-created to match device numbers reported by devfs. FreeBSD kan.dnsalias.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue May 7 23:44:37 EDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KAN i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
securelevel_gt used incorrectly in kldload?
The following check added into kern_linker.c seems wrong somehow:
if (securelevel_gt(td-td_ucred, 0) == 0) {
error = EPERM;
goto out;
}
The last thing securelevel_gt does is to perform this check:
return (active_securelevel level ? EPERM : 0);
i.e. it returns EPERM is securelevel restriction is violated.
Should above construct be rewritten as follows instead?
if ((error = securelevel_gt(td-td_ucred, 0)) != 0)
goto out;
The same bug is present in vfs_mount too.
--
Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Alex are you still workin' for a patch? Yes, I am. But as I write before I am not familiar with this particular part of GCC at all, so I cannot give any estimates and even promize to produce a working patch. If some other more knowledgeable person is feeling like beating me to it, please feel free to do so. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
Interesting. Is the DF_TEXTREL flag set in DT_FLAGS instead? Is the
library linked w/ -enable-new-dtags? Are the new dtags enabled by
default in the new binutils? Someting in elf32.em?
No. DT_FLAGS entry is not created regardless of whether the
--enable-new-dtags parameter has been passed to the linker. Ld simply
ignores dynamic relocation entries for local symbols while checking
whether either DT_FLAGS or DT_TEXTREL should be created. Attached
patch appears to fix the problem for me and has not caused any
problems on my test box so far but I am not making any claims about
its correctness. Use on your own risk.
Are the new dtags enabled by default in the new binutils?
No, it seems like the new dtags are disabled by default.
Index: bfd/elf32-i386.c
===
RCS file: /usr/ncvs/src/contrib/binutils/bfd/elf32-i386.c,v
retrieving revision 1.11
diff -u -r1.11 elf32-i386.c
--- bfd/elf32-i386.c27 Jan 2002 12:07:38 - 1.11
+++ bfd/elf32-i386.c15 Feb 2002 17:21:54 -
@@ -1506,6 +1506,10 @@
}
else
{
+ asection *s = p-sec-output_section;
+ if (s != NULL (s-flags SEC_READONLY) != 0)
+ info-flags |= DF_TEXTREL;
+
srel = elf_section_data (p-sec)-sreloc;
srel-_raw_size += p-count * sizeof (Elf32_External_Rel);
}
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
This suggests a problem with the runtime-linker (rtld), not binutils. Actually, the bug is somewhere in the new binutils code, and I am very close to finding where it is exactly. The new liker fails to set DT_TEXTREL property in the shared library header even though its relocation table contains several entries which refer to the code segment. As a result, ld-elf.so.1 fails to enable writes on the text segment when relocating the binary and crashes with SIGBUS while processing the very first relocation record. I still need some time in debugger to find a proper way to fix this. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: telnetd broken in -CURRENT
I had this problem with telnet some time ago. See PR bin/32591 at http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/32591 for a patch which fixes the problem for me. The memory block is being freed twice in the Heimdal code. Unfortunately, PR got no attention whatsoever for over a month now. It is currently assigned to Mark Murray. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NULLFS panic in -CURRENT
My -CURRENT box got this panic tonight. Apparently, null_inactive tries
to vput NULL lowervp vnode, but how lowervp has managed to become NULL
is not immediately clear for me :( I have crash dump available, if
anyone is interested.
#0 dumpsys () at ../../../kern/kern_shutdown.c:492
#1 0xc01f4ab8 in boot (howto=0x104) at
../../../kern/kern_shutdown.c:335
#2 0xc01f4f07 in panic (fmt=0xc032cbd9 bremfree: bp %p not locked)
at ../../../kern/kern_shutdown.c:634
#3 0xc0222c29 in bremfree (bp=0xc6df7cf0) at
../../../kern/vfs_bio.c:539
#4 0xc0224261 in vfs_bio_awrite (bp=0xc6df7cf0) at
../../../kern/vfs_bio.c:1528
#5 0xc01d5ff4 in spec_fsync (ap=0xd197c9c8) at
../../../fs/specfs/spec_vnops.c:404
#6 0xc01d5bad in spec_vnoperate (ap=0xd197c9c8) at
../../../fs/specfs/spec_vnops.c:119
#7 0xc02ae621 in ffs_sync (mp=0xc1c69600, waitfor=0x2,
cred=0xc0e5ac00, td=0xc03dc164) at vnode_if.h:441
#8 0xc022f4ea in sync (td=0xc03dc164, uap=0x0) at
../../../kern/vfs_syscalls.c:657
#9 0xc01f478d in boot (howto=0x100) at
../../../kern/kern_shutdown.c:244
#10 0xc01f4f07 in panic (fmt=0xc032e6da vput: null vp) at
../../../kern/kern_shutdown.c:634
#11 0xc022cdbd in vput (vp=0x0) at ../../../kern/vfs_subr.c:1665
#12 0xc1cba606 in null_inactive (ap=0xd197caa8) at
/usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:728
#13 0xc022ce86 in vput (vp=0xd1fc5840) at vnode_if.h:654
#14 0xc0492287 in nfs_lookup (ap=0xd197cbc4) at
/usr/src/sys/modules/nfsclient/../../nfsclient/nfs_vnops.c:808
#15 0xc022a8f9 in lookup (ndp=0xd197cc44) at vnode_if.h:45
#16 0xc022a3e4 in namei (ndp=0xd197cc44) at
../../../kern/vfs_lookup.c:168
#17 0xc0231375 in stat (td=0xd1899704, uap=0xd197cd20) at
../../../kern/vfs_syscalls.c:1976
#18 0xc02ec147 in syscall (frame={tf_fs = 0x2f, tf_es = 0xbfbf002f,
tf_ds = 0xbfbf002f, tf_edi = 0xbfbffe3a,
tf_esi = 0xbfbff938, tf_ebp = 0xbfbff998, tf_isp = 0xd197cd74,
tf_ebx = 0x810a720, tf_edx = 0x1, tf_ecx = 0x3,
tf_eax = 0xbc, tf_trapno = 0x0, tf_err = 0x2, tf_eip =
0x2830b9e3, tf_cs = 0x1f, tf_eflags = 0x200287,
tf_esp = 0xbfbff50c, tf_ss = 0x2f}) at
../../../i386/i386/trap.c:1140
#19 0xc02dfc1d in syscall_with_err_pushed ()
#20 0x8094e81 in ?? ()
#21 0x809a0ec in ?? ()
#22 0x8064dfb in ?? ()
#23 0x806d38c in ?? ()
#24 0x804d841 in ?? ()
(kgdb)
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 10-Dec-2001
Time: 11:18:02
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Weird PCI BIOS - long
You lose. Until someone writes a fallback for machines that don't
have the BIOS32 entry point for PCIBIOS, you are stuck.
Warner
No I don't. I knew I will get bitten by putting my comments at the end
of the long message, but I did it nonetheless :(. Anyway, here is shorter
and hopefully more clear explanation:
When kernel boots, PCI BIOS call entry _is_ found, according to the
following log output:
bios32: Found BIOS32 Service Directory header at 0xc00fd800
bios32: Entry = 0xfd820 (c00fd820) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xfd880+0x0
^^ Here
Hovewher, kernel fails to realize, that the call entry is here because
entry address is a pair of non-zero base (0xfd880) and zero offset.
The code in sys/i386/pci_cfgreg.c is checking only offset to be non-null
and ignores base altogether and as a result it mistakenly thinks that
PCI BIOS call entry is not available. I patched the kernel to check for
base + offset with the patch below and now pci_get_version is able to to
a bios32 call and is correctly reporting PCI BIOS 2.10 present.
Unfortunately, that is the only good result caused by the patch, as
kernel freezes shortly after any key has been pressed on the console :(
Patch also changes pci_cfgintr to print out the PCI BIOS version
returned from pcibios_get_version and here are relevant lines from the
boot -v output produced by the modified kernel:
pcard0: PC Card bus (classic) on pcic0
pci_cfgintr: using BIOS 2.10 for interrupt routing
^^^
pci_cfgintr_virgin: using routable PCI-only interrupt 11
pci_cfgintr: ROUTE_INTERRUPT failed.
pcic1: TI PCI-1250 PCI-CardBus Bridge mem 0x20821000-0x20821fff at device 2.1
on pci0
pci_cfgintr: using BIOS 2.10 for interrupt routing
pci_cfgintr_virgin: using routable PCI-only interrupt 11
pci_cfgintr: ROUTE_INTERRUPT failed.
pcic1: No PCI interrupt routed, trying ISA.
pcic1: Polling mode
pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC
parallel isa irq]
The patch is here:
Index: pci_cfgreg.c
===
RCS file: /usr/ncvs/src/sys/i386/pci/pci_cfgreg.c,v
retrieving revision 1.80
diff -u -r1.80 pci_cfgreg.c
--- pci_cfgreg.c28 Aug 2001 16:35:01 - 1.80
+++ pci_cfgreg.c2 Oct 2001 19:10:07 -
@@ -94,7 +94,7 @@
{
struct bios_regs args;
-if (PCIbios.entry == 0) {
+if (BIOS_VADDRTOPADDR(PCIbios.ventry) == 0) {
PRVERB((pcibios: No call entry point\n));
return (0);
}
@@ -244,7 +244,12 @@
pci_cfgintr: BIOS %x.%02x doesn't support interrupt routing\n,
(v 0xff00) 8, v 0xff));
return (255);
+} else {
+ PRVERB((
+ pci_cfgintr: using BIOS %x.%02x for interrupt routing\n,
+ (v 0xff00) 8, v 0xff));
}
+
if ((bus 0) || (bus 255) || (device 0) || (device 255) ||
(pin 1) || (pin 4))
return(255);
@@ -496,7 +501,7 @@
{
u_int16_t v = 0;
-if (PCIbios.entry != 0 enable_pcibios) {
+if (BIOS_VADDRTOPADDR(PCIbios.ventry) != 0 enable_pcibios) {
v = pcibios_get_version();
if (v 0)
printf(pcibios: BIOS version %x.%02x\n, (v 0xff00) 8,
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 03-Oct-2001
Time: 10:55:24
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Weird PCI BIOS - long
I am trying to install -CURRENT on ThinkPad 770ED with a limited success so far. I noticed that when the kernel boots on this notebook, it complains about PCI BIOS entry call point not being available. The following is a boot -v output from my kernel file(see below for further comments): Copyright (c) 1992-2001 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 #3: Tue Oct 2 14:42:07 EDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MONTY Calibrating clock(s) ... TSC clock: 265248670 Hz, i8254 clock: 1193117 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 265266729 Hz CPU: Pentium II/Pentium II Xeon/Celeron (265.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x650 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134021120 (130880K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00336000 - 0x07fc7fff, 130621440 bytes (31890 pages) avail memory = 127336448 (124352K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fd800 bios32: Entry = 0xfd820 (c00fd820) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd880+0x0 pnpbios: Found PnP BIOS data at 0xc00fe700 pnpbios: Entry = f:e724 Rev = 1.0 pnpbios: Event flag at 415 Other BIOS signatures found: Preloaded elf kernel /boot/kernel/kernel at 0xc030f000. null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled pci_open(1):mode 1 addr port (0x0cf8) is 0x38c8 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71928086) pcibios: No call entry point npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX host to PCI bridge (AGP disabled) at pcibus 0 on motherboard pci0: physical bus=0 map[10]: type 3, range 32, base , size 28, enabled found- vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 map[10]: type 1, range 32, base 20822000, size 12, enabled found- vendor=0x104c, dev=0xac16, revid=0x02 bus=0, slot=2, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 20821000, size 12, enabled found- vendor=0x104c, dev=0xac16, revid=0x02 bus=0, slot=2, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=b, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 2040, size 22, enabled map[14]: type 1, range 32, base 2080, size 17, enabled map[18]: type 1, range 32, base 2000, size 22, enabled found- vendor=0x1023, dev=0x9397, revid=0xf3 bus=0, slot=3, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 map[10]: type 1, range 32, base 2082, size 10, enabled found- vendor=0x1014, dev=0x007d, revid=0x00 bus=0, slot=5, func=0 class=04-80-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 found- vendor=0x8086, dev=0x7110, revid=0x01 bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base fcf0, size 4, enabled found- vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base 8400, size 5, enabled found- vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=11 map[90]: type 4, range 32, base efa0, size 4, enabled found- vendor=0x8086, dev=0x7113, revid=0x01 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 pci0: PCI bus on pcib0 pcibios: No call entry point pci_cfgintr: BIOS 0.00 doesn't support interrupt routing pcic0: TI PCI-1250 PCI-CardBus Bridge mem 0x20822000-0x20822fff at device 2.0 on pci0 pcibios: No call entry point pci_cfgintr: BIOS 0.00 doesn't support interrupt routing pcic0: No PCI interrupt routed, trying ISA. pcic0: Polling mode pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC parallel isa irq] pcic0: PCI Configuration space: 0x00: 0xac16104c 0x04: 0x0217 0x08: 0x06070002 0x0c: 0x0082a808 0x10: 0x20822000 0x14: 0x02a0 0x18: 0xb0030100 0x1c: 0x 0x20: 0x 0x24: 0x 0x28: 0x 0x2c: 0x 0x30: 0x 0x34: 0x 0x38: 0x 0x3c: 0x07e001ff 0x40: 0x00921014 0x44: 0x0001 0x48: 0x 0x4c: 0x 0x50:
current.freebsd.org is broken?
ftp -a fails to login to the current.freebsd.org with the following error message: --- Begin - Connected to usw2.freebsd.org. 220 usw2.freebsd.org FTP server (Version wu-2.6.0(1) Thu Jul 6 03:57:36 CDT 2000) ready. 331 Guest login ok, send your complete e-mail address as password. 530 Can't set guest privileges. ftp: Login failed. --- End --- Does anyone know any other mirror with a reasonably recent -CURRENT snapshot? E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 26-Sep-2001 Time: 16:16:46 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KSE-related panic in NFS + patch
It appears that nfs_msg function in nfsclient/nfs_socket.c file
is not prepared to deal with NULL thread pointer passed to it
and bogusly tries to reference td-td_proc.
I had to add this simple patch to avoid panics:
Index: nfs_socket.c
===
RCS file: /usr/ncvs/src/sys/nfsclient/nfs_socket.c,v
retrieving revision 1.68
diff -u -r1.68 nfs_socket.c
--- nfs_socket.c18 Sep 2001 23:31:51 - 1.68
+++ nfs_socket.c24 Sep 2001 19:39:21 -
@@ -1364,6 +1364,6 @@
nfs_msg(struct thread *td, char *server, char *msg)
{
- tprintf(td-td_proc, LOG_INFO, nfs server %s: %s\n, server, msg);
+ tprintf((td ? td-td_proc : NULL), LOG_INFO, nfs server %s: %s\n, server,
+msg);
return (0);
}
#0 dumpsys () at ../../../kern/kern_shutdown.c:488
#1 0xc01f1bc0 in boot (howto=260) at ../../../kern/kern_shutdown.c:331
#2 0xc01f1ffd in panic (fmt=0xc030535e from debugger)
at ../../../kern/kern_shutdown.c:628
#3 0xc0158a75 in db_panic (addr=-1069018059, have_addr=0, count=-1,
modif=0xc8ddfae8 ) at ../../../ddb/db_command.c:443
#4 0xc0158a15 in db_command (last_cmdp=0xc035c558, cmd_table=0xc035c398,
aux_cmd_tablep=0xc0352d58, aux_cmd_tablep_end=0xc0352d5c)
at ../../../ddb/db_command.c:341
#5 0xc0158adf in db_command_loop () at ../../../ddb/db_command.c:465
#6 0xc015ade3 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7 0xc02d2ca0 in kdb_trap (type=12, code=0, regs=0xc8ddfc30)
at ../../../i386/i386/db_interface.c:167
#8 0xc02e04a0 in trap_fatal (frame=0xc8ddfc30, eva=0)
at ../../../i386/i386/trap.c:931
#9 0xc02e01f5 in trap_pfault (frame=0xc8ddfc30, usermode=0, eva=0)
at ../../../i386/i386/trap.c:850
#10 0xc02df9c8 in trap (frame={tf_fs = 24, tf_es = -849281008, tf_ds = -925040624,
tf_edi = -849248992, tf_esi = -1044303808, tf_ebp = -924976000,
tf_isp = -924976036, tf_ebx = -924975948, tf_edx = -1044650766, tf_ecx = 0,
tf_eax = -924975948, tf_trapno = 12, tf_err = 0, tf_eip = -1069018059,
tf_cs = 8, tf_eflags = 66178, tf_esp = 6, tf_ss = -1068979139})
at ../../../i386/i386/trap.c:406
#11 0xc0481435 in nfs_msg (td=0x0, server=0xc1bbe4f2 tips8:/home/tips8,
msg=0xc8ddfcb4 not responding 10 9)
at /usr/src/sys/modules/nfsclient/../../nfsclient/nfs_socket.c:1367
#12 0xc0480f37 in nfs_timer (arg=0x0)
at /usr/src/sys/modules/nfsclient/../../nfsclient/nfs_socket.c:1102
#13 0xc01fa536 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:187
#14 0xc01e588b in ithread_loop (arg=0xc17c9d00) at ../../../kern/kern_intr.c:532
#15 0xc01e4d3a in fork_exit (callout=0xc01e5760 ithread_loop, arg=0xc17c9d00,
frame=0xc8ddfd48) at ../../../kern/kern_fork.c:785
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Freshly cvsuped kernel fails to build trying to find acpi_isa.c file, which does not exist anymore. On 30-Aug-2001 Mike Smith wrote: I have just committed some changes to the way that ACPI works in current. This has an impact on all -current users, so please take a few seconds to read this and feel free to ask questions. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Pb with compiling kdebase 2.2
ld had a nasty bug in -CURRENT which resulted exactly in this kind of errors. David O'Brien has imported a new snapshot which fixes the problem some time ago. Upgrade your -CURRENT box. On 17-Aug-2001 Ollivier Robert wrote: I'm trying tpo compile kdebase 2.2 (kdelibs 2.2 went fine) on my Jul, 18th current system. It fails with the following error: ... /usr/X11R6/bin/uic -o kmousedlg.h ./kmousedlg.ui /usr/libexec/ld-elf.so.1: /usr/lib/crtn.o: unsupported file type 510 [10:50] root@caerdonn:kdebase2# file /usr/X11R6/bin/uic /usr/lib/crtn.o /usr/X11R6/bin/uic: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped /usr/lib/crtn.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped -r-xr-xr-x 1 root wheel 204968 Jul 31 16:41 /usr/X11R6/bin/uic* -r--r--r-- 1 root wheel 621 Jun 15 17:03 /usr/lib/crtn.o The same package compiled fine on my 4.4-PRERELEASE system. Any idea? E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 17-Aug-2001 Time: 09:41:29 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Pb with compiling kdebase 2.2
ld only is not sufficient. ld + all libraries it depends on (read: binutils) should be recompiled. On 17-Aug-2001 Ollivier Robert wrote: According to Alexander N. Kabaev: ld had a nasty bug in -CURRENT which resulted exactly in this kind of errors. David O'Brien has imported a new snapshot which fixes the problem some time ago. Upgrade your -CURRENT box. Hmmm, I've upgraded ld, ld-elf.so, crt*.o and it still does this... Will I have to buildworld... ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 17-Aug-2001 Time: 13:28:27 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panics with debug.witness_watch=0
-CURRENT kernel panics when booting with debug.witness_watch tunable set to 0 in loader. It looks like witness_assert function should not do anything in this case. Attached patch fixes the problem for me. The panic I am getting looks like that: panic: Lock (sx) fork list not locked @ ../../kern/kern_fork.c:590. Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db trace Debugger(c034ff7b) at Debugger+0x44 panic(c0353360,c0350540,c034da0e,c034da2a,24e) at panic+0x70 witness_assert(c03e3c00,2,c034da2a,24e,0) at witness_assert+0x9f _sx_sunlock(c03e3c00,c034da2a,24e,c03c7c30,c0b3dad0) at _sx_sunlock+0x8e fork1(c0426e00,20014,c0426de0) at fork1+0x1c6a create_init(0,4eec00,4ee000,0,c012f0b2) at create_init+0x18 mi_startup() at mi_startup+0x90 begin() at begin+0x29 db The patch: Index: subr_witness.c === RCS file: /usr/ncvs/src/sys/kern/subr_witness.c,v retrieving revision 1.77 diff -u -r1.77 subr_witness.c --- subr_witness.c 2001/06/27 06:27:29 1.77 +++ subr_witness.c 2001/06/28 20:27:57 @@ -1351,6 +1351,9 @@ #ifdef INVARIANT_SUPPORT struct lock_instance *instance; + if (lock-lo_witness == NULL || witness_dead) + return; + if ((lock-lo_class-lc_flags LC_SLEEPLOCK) != 0) instance = find_instance(curproc-p_sleeplocks, lock); else if ((lock-lo_class-lc_flags LC_SPINLOCK) != 0) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: [HEADS-UP]: Mbuf allocator changes
UP kernel can not be compiled in -CURRENT after your changes because kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP case. Should this variable be moved out of #ifdef SMP? On 22-Jun-2001 Bosko Milekic wrote: Hi -current people, I have recently made some significant changes to the mbuf allocator. Although I have invested, along with several other developers, very significant time in testing the newly introduced code, should any problems arise, please let me know ASAP. One noticeable difference that I am aware of is that mbtypes statistics have been TEMPORARILY disabled. Please be patient. :-) Thank you for flying -CURRENT, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 22-Jun-2001 Time: 11:41:47 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Fw: Stop annoying message of lnc
See my PR kern/25582. The explanation why Bill Paul does not want to make this change yet is there :) On 18-Mar-2001 Makoto MATSUSHITA wrote: I've sent an email to [EMAIL PROTECTED], a maintainer of lnc ethernet driver, to fix the module name of lnc almost two weeks before. However, he maybe too busy working, there is no response from him. Are there any committers to check my patch and fix the driver? -- - Makoto MATSUSHITA -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 18-Mar-2001 Time: 00:02:17 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fw: Stop annoying message of lnc
That's Paul Richards, not Bill Paul. My apologies, I should have checked before pressing that 'Send' button :( I don't quite understand Paul's reasoning, though; it's not actually useful to unload/reload parts of a device's bus attachment without unloading/reloading all the downstream parts of the driver. I think the fix should probably be committed and the driver turned into a single monolithic module. I am not advocating either approach. Just wanted to point out that there is PR available which should be closed if the fix will get committed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -CURRENT no longer boots
Do you have WITNESS_SKIPSPIN option in your kernel config? Here is what supposedly causing the trouble: a) the process p_spinlocks variable is initialized to one in fork1 during the process creation b) the sched_lock is released later in fork_exit, but the process' p_spinlocks field is not decreased because sched_lock is not tracked by the witness subsystem b) process tried to grab Giant but sees p_spinlocks 0 ... instant panic :) The quick and dirty fix is to either set debug.witness_skipspin=0 in /boot/loader.conf or modify witness_enter function to ignore p_skipspin counter if debug.witness_skipspin is non-zero. -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 12-Mar-2001 Time: 12:40:36 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -CURRENT no longer boots
Just don't use the skipspin stuff, it shouldn't hurt at all. The new witness code will hopefully be in by the end of the week. *crosses fingers* Cool. WITNESS_SKIPSPIN was quite useful for NETGRAPH users because of some unregistered spin mutexes there. Julian fixed the problem already, so you are right - skipspin is not that useful anymore. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lpt driver broken?
But I remember some posts about a lpt panic some days ago. I tried to compile a new kernel because I think this is resolved, but I have to solve some problems with my system at the moment. My -CURRENT used to crash every time lpr has been used but the panic went away when John Baldwin committed his ithread cleanup megapatch: jhb 2001/02/09 09:47:47 PST Modified files: sys/i386/i386nexus.c sys/i386/isa intr_machdep.c intr_machdep.h ithread.c Log: Use the MI ithread helper functions in the x86 interrupt code. The kernel from Feb 9 worked just fine for me, but then the following commit has been made and the system started to crash again: jhb 2001/02/09 18:41:51 PST Modified files: sys/i386/isa ithread.c Log: Re-enable preemption on interrupts. My last commit accidentally reverted it as I was playing with some other ways of doing kernel preemption. Revision ChangesPath 1.14 +9 -2 src/sys/i386/isa/ithread.c If you badly need your printer to work, you can simply revert this patch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
I can easily reproduce the panic on my -CURRENT Athlon box by just starting any
print job. Other that that, the system seems to be running OK, i.e. no panics
occur unless some lpr activity is involved. Here is the stack dump:
#9 0xc02a9fbc in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
tf_edi = -857849588, tf_esi = 32, tf_ebp = -696148124,
tf_isp = -696148164, tf_ebx = -1069967232, tf_edx = -857849856,
tf_ecx = -868400672, tf_eax = -1070952435, tf_trapno = 9, tf_err = 32,
tf_eip = -1070952316, tf_cs = 8, tf_eflags = 65670,
tf_esp = -1071733991, tf_ss = 0}) at ../../i386/i386/trap.c:656
#10 0xc02a9084 in sw1b ()
#11 0xc02b075b in ithd_loop (dummy=0x0) at ../../i386/isa/ithread.c:216
#12 0xc01dc48d in fork_exit (callout=0xc02b0664 ithd_loop, arg=0x0,
frame=0xd6819fa8) at ../../kern/kern_fork.c:669
and disassembled code at the point of the trap looks like
0xc02a9076 sw1b+105: mov%eax,0x0(%ebx)
0xc02a9079 sw1b+108: mov0x4(%edi),%eax
0xc02a907c sw1b+111: mov%eax,0x4(%ebx)
0xc02a907f sw1b+114: mov$0x20,%esi
0xc02a9084 sw1b+119: ltr%si
..^^
Also, a pretty unpleasant crash occurs on the latest current boxes everytime
vidcontrol is used to change console resolution to the VESA_800x600 mode.
I was able to get the crash dump, but unfortunately it seems like the stack is
becoming corrupt and so there is no useful information to report.
--
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 07-Feb-2001
Time: 00:35:38
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
Re: the strace db trace above, is it possible that it might be because I have: CFLAGS ?= -O -pipe -mcpu=i686 -march=i686 COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686 No, I was getting the same panic with the kernel, compiled with stock flags. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
However, your problems with lpr are a known problem and one that is in the process of being fixed. That was me who reported lpr problems in this thread. I just found it curious that Andrea's panics look absolutely identical to ones I am getting here when attempting to use lpr. Do you really think that is a pure coincidence? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with dlopen()/dlsym() after recent crt* changes
Nope, explicitly linking shared module with -lgcc doesn't solve this problem. -Maxim Then it is not new crt* code that is broken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with dlopen()/dlsym() after recent crt* changes
John, I think dymanic loader should clear it's error_string variable before returning success to the caller. I am halfway done preparing the patch to do that. Is that the bug you mentioned or there is something else? Anyway, do you want to see my patch when it is ready or you prefer to take care of the problem yourself? That's correct. The new crt code just uncovered the bug in the dynamic linker. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with dlopen()/dlsym() after recent crt* changes
I don't think it is allowed to do that. See the SUSv2 description: http://www.opengroup.org/onlinepubs/007908799/xsh/dlerror.html Sorry, you are right of course. The attached patch removes the _rtld_error call at the end of the symlook_default function which seems to be unnecessary. Is that what you had in mind? rtld.patch
RE: Problem with dlopen()/dlsym() after recent crt* changes
I've spent couple hours already trying to reproduce the error and so far failed miserably. Am I the only one who does not see this problem at all? On 06-Nov-00 Maxim Sobolev wrote: After the crt changes the following piece of code, which worked previously, gives a 'host: dlopen() failed: ./module.so: Undefined symbol "__register_frame_info' error message (yeah, I know that it's better to check To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with dlopen()/dlsym() after recent crt* changes
Why FreeBSD does not link libgcc into shared libraries by default? Everyone else is doing that. Linking shared libraries with libgcc seems to be the ultimate work-around. Are there any compatibility problems which are keeping FreeBSD from doing that? OK, thanks. I'll take a look at it as soon as I can -- hopefully tonight. If I can come up with a reasonable work-around, I'll do so. John -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** changes to /usr/lib/crt*.o
What caused such a change? I mean, what the purpose of it, what set of problems should it (probably?) solve? http://www.FreeBSD.org/cgi/query-pr.cgi?pr=20966 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange messages on -CURRENT
I am seeing these messages on the -CURRENT box as of FreeBSD kanpc.gte.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Aug 14 10:04:38 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/KANPC i386 Aug 22 13:07:40 kanpc /kernel: unexpected vn driver lock: 0xc8010d40: type VREG, usecount 2, writecount 1, refcount 25, flags (VOBJBUF) Aug 22 13:07:40 kanpc /kernel: unexpected vn driver lock: 0xc8010d40: type VREG, usecount 2, writecount 1, refcount 25, flags (VOBJBUF) Aug 22 13:07:40 kanpc /kernel: tag VT_UFS, ino 349296, on dev #ad/0x30005 (116, 196613) lock type inode: EXCL (count 1) by pid 5 Aug 22 13:07:40 kanpc /kernel: tag VT_UFS, ino 349296, on dev #ad/0x30005 (116, 196613) lock type inode: EXCL (count 1) by pid 5 -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 22-Aug-00 Time: 13:09:40 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse frozen in X when returning from text console
There was a patch floating around which fixed these mouse problems for me. XFree86-patch
Suspicious warnings in -CURRENT
After today's buildworld, I am seeing lots of warning messages from libc like: expr in free(): warning: modified (chunk-) pointer Does it happen to anyone else on this list? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT buildworld breakage in openssl
make -j8 buildworld fails with these messages for a second day in a row: cd /usr/src/secure/lib/libssl; make _EXTRADEPEND === librsausa mkdir: openssl: File exists *** Error code 1 cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h \ openssl/opensslconf.h 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup crash
Actually, it seems that Java borrowed a whole lot of ideas from Modula-3. And C++ experience can even hurt instead helping when switching to Java. Java inherits some parts of C++ syntax but is based on rather different design. On 19-Apr-00 Donn Miller wrote: Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm broken in -current for SB16
Subject says it all. Everytime I am trying to use my SB16PNP card to play any sound file (WAV, MP3), all I am getting is garbled sound because driver plays sound at increased rate (i.e. it takes less than 10 sec for mpg123 to decode 5 min long song). FreeBSD Audio Driver (newpcm) Apr 19 2000 09:43:52 Installed devices: pcm0: SB DSP 4.13 at io 0x220 irq 5 drq 1:5 (1p/1r channels duplex) -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 19-Apr-00 Time: 12:16:37 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: newpcm broken in -current for SB16
Correction to my own message. The problem is not with newpcm driver per se but with esd/newpcm combination. mpg123 recompiled without OPT_ESOUND works just fine, so does xmms when using OSS output plugin. Only when I force these two to use ESD for output, then I am getting "fast forward"-like cacophony I was describing in my previous message. Subject says it all. Everytime I am trying to use my SB16PNP card to play any sound file (WAV, MP3), all I am getting is garbled sound because driver plays sound at increased rate (i.e. it takes less than 10 sec for mpg123 to decode 5 min long song). FreeBSD Audio Driver (newpcm) Apr 19 2000 09:43:52 Installed devices: pcm0: SB DSP 4.13 at io 0x220 irq 5 drq 1:5 (1p/1r channels duplex) -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 19-Apr-00 Time: 12:43:51 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Overwhelming messages from /sys/netinet/if_ether.c
The message in question can be extremely useful in case there is IP address
clash on the local network. I suggest we just change the code in question to
ignore clashes over 0.0.0.0 address only.
On 07-Apr-00 Donn Miller wrote:
Since I started using a cable modem and dhclient, my system has been
literally overwhelmed with messages like:
/kernel: arp: xx:xx:xx:xx:xx:xx is using my IP address 0.0.0.0!
Man, these messages were pouring out of syslogd like mad, and my
/var/log/messages* files had to be deleted, because they were growing
so huge. There were literally hundreds of these messages pouring out
via syslogd per second, and they were coming non-stop. There were so
many messages coming out, my hard drive was overwhelmed until dhclient
finally obtain/ed a lease. That said, I suggest we make the following
patch to /sys/netinet/if_ether.c:
--- if_ether.c.orig Wed Mar 29 02:50:39 2000
+++ if_ether.c Fri Apr 7 11:24:54 2000
@@ -554,9 +554,9 @@
return;
}
if (isaddr.s_addr == myaddr.s_addr) {
- log(LOG_ERR,
+ /* log(LOG_ERR,
"arp: %6D is using my IP address %s!\n",
- ea-arp_sha, ":", inet_ntoa(isaddr));
+ ea-arp_sha, ":", inet_ntoa(isaddr)); */
itaddr = myaddr;
goto reply;
}
- Donn
----------
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 07-Apr-00
Time: 11:49:33
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Overwhelming messages from /sys/netinet/if_ether.c
Trivial patch attached :) On 07-Apr-00 John Polstra wrote: In article [EMAIL PROTECTED], Alexander N. Kabaev [EMAIL PROTECTED] wrote: The message in question can be extremely useful in case there is IP address clash on the local network. I suggest we just change the code in question to ignore clashes over 0.0.0.0 address only. I agree. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa if_ether.diff
Re: Overwhelming messages from /sys/netinet/if_ether.c
FreeBSD dhclient-script assigns 0.0.0.0 address to the interface in PREINIT in order to bring interface up. Windows seems to do that as well or there is no sane explanation for the relatively big number of these nasty messages I am getting every time MediaOne network goes down and several PCs sharing the same cable network segment attempt to renew their lease at the same time. On 07-Apr-00 Rodney W. Grimes wrote: The message in question can be extremely useful in case there is IP address clash on the local network. I suggest we just change the code in question to ignore clashes over 0.0.0.0 address only. No, don't do that, anyone arping 0.0.0.0 on any network around here I sure as heck want to know about it asap! Someone someplace on that stupid telco's DSL bridged network is mis-configured and sending out arp messages for the 0 addresses. Easy enough to cause though: ifconfig xx0 0.0.0.0 up should do the trick... -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 07-Apr-00 Time: 14:35:14 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Overwhelming messages from /sys/netinet/if_ether.c
I have the same impression fom reading dhclient sources. On 07-Apr-00 David Holloway wrote: I say with 99% certainty that assigning 0.0.0.0 to the interface is a requirement of dhcp. You can't stop using it and expect dhcp to work. -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 07-Apr-00 Time: 15:44:39 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0?
I am perfectly aware of the way OpenBSD builds contrib software. I am just making a point that they have found perl 5.6.0 is stable enough to be included into their OS. On 07-Apr-00 Kris Kennaway wrote: On Thu, 6 Apr 2000, Alexander N. Kabaev wrote: According to OpenBSD ournal site, OpenBSD-current has perl 5.6.0 in it's source tree already. OpenBSD don't even try to make their "bundled software" comply with the rest of the system build architecture - they basically just import the perl distribution into gnu/usr.bin/, munge some of the build bits, and let the software build the way it wants to. Needless to say, thats not an acceptable style for FreeBSD, not to mention probably breaking certain features we support such as cross-compilation :-) Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 07-Apr-00 Time: 00:51:49 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: C++ exceptions doesn't work in shared libraries
Well,
I cannot comment on OpenBSD or Solaris, since I do not have access to them
right now. My guess is that OpenBSD and Solaris x86 either
1. do not use sjlj exception propagation, or
2. do not use _builtin_setjmp
Linux does not use sjlj exceptions for sure and as a result it is not affected
by this bug.
In case when they do not use sjlj exceptions, appropriate EBX restoration code
is provided by the exception_receiver RTL. Unfortunately, G++ only emits
exception_receiver when using non-sjlj exceptions. In my first patch I tried
to force exception_receiver to be emitted in for sjlj exceptions too, but
only when GCC uses builtin{setjmp|longjmp} implementations. Standard C
library setjmp/longjmp should have EBX preserved correctly already and thus do
not need any special code. I have looked at Aplha backend and found out, that
Alpha does the right thing and tries to restore its equivalent of PIC register
on setjmp receive point, so apparently, GCC expects _builtin_setjmp and
builtin_longjmp to do all necessary register preservations. i386 backend clearly
fails to do that.
On 17-Jan-00 David O'Brien wrote:
On Mon, Jan 17, 2000 at 02:51:00PM -0500, Alexander N. Kabaev wrote:
As I already pointed out in private message, this bug is in fact i386
specific and it was wrong to fix it in gcc/except.c file. The real
problem is that default builtin_setjmp implementation does not restore
any registers except for stack pointers when doing nonlocal jump. This
means, that every platform, that needs to store/restore some other
state between jumps, has to provide appropriate definitions for
builtin_setjmp_setup and builtin_setjmp_receiver RTL expansions.
Why doesn't OpenBSD, Linux, or Solaris x86 need this patch?
That is exactly what I do in a second (improved, I hope) patch I have
sent to David yesterday.
I may go with this patch, but I need to understand more why it is needed
before I take a file off the vendor branch. Any help would be
appreciated.
--
-- David([EMAIL PROTECTED])
--
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 17-Jan-00
Time: 14:57:58
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ exceptions doesn't work in shared libraries
Why doesn't OpenBSD, Linux, or Solaris x86 need this patch?
I tried to compile and run attached program on dual-processor Compaq
Proliant server running RedHat Linux 6.1 at Compaq testdrive site (thanks,
Compaq!) and guess what? Compiled with -fsjlj-exceptions Linux bails out with
"Not enough memory" error message. Compiled without -fsjlj-exceptions, it dumps
core. It _could_ use some patches after all :)
I would really appreciate if people having access to the OpenBSD/i386
Solaris/x86 boxes will try the following program on these boxes and share
results with us. I will be greatly surprised if OpenBSD will survive the test
since their egcs looks like stock egcs 1.1.2 version which has not been heavily
patched from original Cygnus version.
--
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 17-Jan-00
Time: 20:30:14
--
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# Makefile
# foo.cc
# main.cc
#
echo x - Makefile
sed 's/^X//' Makefile 'END-of-Makefile'
XCXX=g++
XLD=ld
XCXXFLAGS=-g -fpic -fexceptions
X
Xall: arf
X
Xarf: main.o foo.so
X ${CXX} -o arf main.o foo.so
X
X
Xfoo.so: foo.o
X ${LD} -Bshareable -o foo.so foo.o
X
Xclean:
X rm -f arf *.o *.so
END-of-Makefile
echo x - foo.cc
sed 's/^X//' foo.cc 'END-of-foo.cc'
X#include stdio.h
X
Xint Foo ();
X
Xint Baz ()
X{
Xchar *msg = "Bax thowing...";
Xprintf ("in baz\n");
Xthrow msg;
Xprintf ("baz should not be here.\n");
X}
X
X
Xint Foo ()
X{
Xtry {
XBaz ();
X} catch (char *msg) {
Xprintf ("foo caught %s\n", msg);
X}
X}
END-of-foo.cc
echo x - main.cc
sed 's/^X//' main.cc 'END-of-main.cc'
X#include stdio.h
X
Xint Foo ();
X
Xint
Xmain ()
X{
Xtry {
Xprintf ("calling foo\n");
XFoo ();
Xprintf ("returned from foo\n");
X} catch (char *msg) {
Xprintf ("exception from foo: %s\n", msg);
X} catch (...) {
Xprintf ("unknown exception\n");
X}
X}
END-of-main.cc
exit
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ exceptions doesn't work in shared libraries
As promised, I tried to look into the problem little futher. The following
patch fixes all crashes for me and I was unable to reproduce the bug anymore. I
would really like to hear if it works for you too. I am especially interested
to know if it works on Alpha, because I cannot test it myself.
PS. The code in question is in mashine independent, so I have reason to believe
that this patch may fix the problem for other platforms too...
Index: contrib/gcc/except.c
===
RCS file: /home/ncvs/src/contrib/gcc/except.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 except.c
--- contrib/gcc/except.c1999/10/16 06:03:55 1.1.1.2
+++ contrib/gcc/except.c2000/01/15 04:06:03
@@ -724,9 +724,11 @@
rtx handler_label;
{
emit_label (handler_label);
-
+
#ifdef HAVE_exception_receiver
+#ifdef DONT_USE_BUILTIN_SETJMP
if (! exceptions_via_longjmp)
+#endif
if (HAVE_exception_receiver)
emit_insn (gen_exception_receiver ());
#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: C++ exceptions doesn't work in shared libraries
Well, I tried to investigate this problem and the following is what I've found so far: It looks like we are dealing with gcc -O code generation bug. I recompiled libgcc and libgcc_r without -O flag and everything works just fine, including the sample from PR3441. Unfortunately, I was unable to locate exact place where it blows yet, although _builtin_setjmp seems to be very suspicious. I will post the result of my 'investigation' if something interesting will come out of it :) On 12-Jan-00 Maxim Sobolev wrote: David O'Brien wrote: On Wed, Jan 12, 2000 at 10:01:42AM +0200, Maxim Sobolev wrote: Is there are any compiler guys to address my question or not? There is, I'm the one. But there are a few things ahead in the queue. Please excuse me if I've offended you, but I just doubted that no one has read my message, so I've tried to check for sure ;). Hovewer it seems that I've selected wrong way to do it, so I'll try to be more patient in the future. Of course a patch would make things go much faster. Unfortunately, I'm not one of the "compiler gurus", so it would be almost impossible for me to fix this problem. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message ------ E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 13-Jan-00 Time: 22:06:51 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: C++ exceptions doesn't work in shared libraries
I am sorry, my previous letter was incorrect. Compiling libgcc{_r}.a
without optimisation stopped _my_ test program and the program from PR from
crashing, but any attempt to rethrow the exception from the catch block in
Foo() results in signal 11 crash.
--
E-Mail: Alexander N. Kabaev [EMAIL PROTECTED]
Date: 13-Jan-00
Time: 22:35:50
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 testing...willing to help
These are my results: % ifconfig -a xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80:1::250:daff:fe20:495b prefixlen 64 inet 24.218.93.188 netmask 0xfc00 broadcast 24.218.95.255 ether 00:50:da:20:49:5b media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10bas P full-duplex 10baseT/UTP 100baseTX hw-loopback sl0: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552 sl1: flags=c010POINTOPOINT,LINK2,MULTICAST mtu 552 ppp0: flags=8010POINTOPOINT,MULTICAST mtu 1500 ppp1: flags=8010POINTOPOINT,MULTICAST mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80:6::1 prefixlen 64 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 gif0: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:7::250:daff:fe20:495b prefixlen 64 gif1: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:8::250:daff:fe20:495b prefixlen 64 gif2: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:9::250:daff:fe20:495b prefixlen 64 gif3: flags=8010POINTOPOINT,MULTICAST mtu 1280 inet6 fe80:a::250:daff:fe20:495b prefixlen 64 faith0: flags=8002BROADCAST,MULTICAST mtu 1500 ds0: flags=8008LOOPBACK,MULTICAST mtu 65532 % netstat -rn -f inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::@xl0/64 link#1UC xl0 fe80::250:daff:fe20:495b@xl0 0:50:da:20:49:5b UHLWlo0 fe80::@lo0/64 fe80::1@lo0 Uc lo0 fe80::@gif0/64fe80::250:daff:fe20:495b@gif0 Uc gif0 fe80::250:daff:fe20:495b@gif0 ::1 UH lo0 fe80::@gif1/64fe80::250:daff:fe20:495b@gif1 Uc gif1 fe80::250:daff:fe20:495b@gif1 ::1 UH lo0 fe80::@gif2/64fe80::250:daff:fe20:495b@gif2 Uc gif2 fe80::250:daff:fe20:495b@gif2 ::1 UH lo0 fe80::@gif3/64fe80::250:daff:fe20:495b@gif3 Uc gif3 fe80::250:daff:fe20:495b@gif3 ::1 UH lo0 ff01::/32 ::1 U lo0 ff02::@xl0/32 link#1UC xl0 ff02::@lo0/32 fe80::1@lo0 UC lo0 ff02::@gif0/32fe80::250:daff:fe20:495b@gif0 UC gif0 ff02::@gif1/32fe80::250:daff:fe20:495b@gif1 UC gif1 ff02::@gif2/32fe80::250:daff:fe20:495b@gif2 UC gif2 ff02::@gif3/32fe80::250:daff:fe20:495b@gif3 UC gif3 % traceroute6 fe80:1::250:daff:fe20:495b traceroute to fe80:1::250:daff:fe20:495b (fe80:1::250:daff:fe20:495b), 30 hops max, 12 byte packets 1 fe80::250:daff:fe20:495b 0.171 ms 0.144 ms 0.091 ms % ping6 fe80:1::250:daff:fe20:495b PING6(56=40+8+8 bytes) fe80::250:daff:fe20:495b -- fe80:1::250:daff:fe20:495b 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=0 hlim=64 time=0.178 ms 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=1 hlim=64 time=0.129 ms 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=2 hlim=64 time=0.138 ms 16 bytes from fe80::250:daff:fe20:495b, icmp_seq=3 hlim=64 time=0.133 ms ^C --- fe80:1::250:daff:fe20:495b ping6 statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.129/0.144/0.178 ms To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, tell me again why we can't read audio CDs in SCSI drives
I have TOSHIBA DVD-ROM SD-M1201 1R08 on Adaptec 2440U2W and tosha works fine with it. I used to get the same error messages from tosha just a couple weeks ago. cdd2wav worked OK. I upgraded to the latest firmware on both the controller and the drive and error messages disappeared. Kernel and world cvsupped on on Jan 4. BTW, running dd on my DVD fails with the following error: # dd if=/dev/rcd0a bs=2k of=/dev/null dd: /dev/rcd0a: Invalid argument 0+0 records in 0+0 records out 0 bytes transferred in 0.001683 secs (0 bytes/sec) Jan 7 00:04:51 kan /kernel: (cd0:ahc0:0:6:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 Jan 7 00:04:51 kan /kernel: (cd0:ahc0:0:6:0): ILLEGAL REQUEST asc:64,0 Jan 7 00:04:51 kan /kernel: (cd0:ahc0:0:6:0): Illegal mode for this track Jan 7 00:04:51 kan /kernel: (cd0:ahc0:0:6:0): cddone: got error 0x16 back J Is that something to be expected? How to copy a complete CD-ROM image into ISO file then? On 07-Jan-00 Jordan K. Hubbard wrote: Any other SCSI CD owners here currently using tosha? I'd be quite interested to know if this is drive-specific. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: rpc.umntall does not work with AIX [LONG]
Well, it seems like RPCMNT_UMNTALL call always fails with RPC_SYSTEMERROR on
all systems except FreeBSD. I tested HP/UX, AIX and Solaris boxes - they all
behave identically as follows:
rpc.umntall -h $HOST always fails
rpc.umntall -h $HOST -p $DIR - works just fine since it is using RPCMNT_UMOUNT
umount $HOST:$DIR works just fine
Interesting, even if RPC_UMNTALL call returns error code, it nonetheless
causes mount entry to be removed from the server, i.e. showmount -a $HOST
output does not report my client machine as having any mounts on $HOST anymore.
All entries in my /var/db/mounttab appear to be correct, I do not think they
are causing the problem.
Also, I have questions regarding the following code fragment from the
rpc.umntall.c file:
1) for (mtab = mtabhead; mtab != NULL; mtab = mtab-next) {
2) if (*mtab-mtab_host != '\0'
3) (do_umntall(mtab-mtab_host) ||
4) mtab-mtab_time = (time(now) - expire))) {
5) if (keep is_mounted(mtab-mtab_host,
6) mtab-mtab_dirp)) {
7) if (verbose) {
8) warnx("skipping entry %s:%s",
9) mtab-mtab_host,
10)mtab-mtab_dirp);
11)}
12)} else
13)clean_mtab(mtab-mtab_host, NULL);
14)}
15)}
It seems like it does RPCMNT_UMNTALL call for each mounttab entry regardless of
the -k parameter passed in the command line, while man page suggests that
it should simply skip entries for currently mounted filesystems.
-k Keep entries for existing NFS filesystems. Compare the NFS
filesystems from the mounttab against the kernel mount list and do
not send the RPC to existing mount entries. Useful during startup
of the system. It may be possible that there are already mounted
NFS filesystems, so calling RPC UMNTALL isn't a good idea. This
is the case if the user has rebooted to 'single user mode' and
starts up the system again.
Furthermore, using RPC_UMNTALL in the above loop is probably not a good idea
either because client host may have two different directories mounted from the
same server. If -k flag is specified, you cannot use UMNTALL because it will
remove /var/run/mountdtab entries not only for the mount point left over
from the crash but also for all other mounts some of which may be perfectly
valid and should be kept intact.
May be, we should use RPCMNT_UMOUNT call instead? It seems to me that
RMCMNT_UMNTALL is only applicable when utility is called with -h option as the
only option.
-Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
rpc.umntall does not work with AIX
I am getting the folowing error messages for each mounted directory every time rpc.umntall is being run: Bad MNT RPC: RPC: Remote system error The following is fragment of my /etc/fstab file: # DeviceMountpoint FStype Options DumpPass# kan:/home/ak03 /usr/home/ak03 nfs rw 0 0 tips6:/usr/local/aix/javapkg /usr/local/javapkg nfs rw 0 0 kan there is running AIX 4.2 and tips6 box is HP/UX I am perfectly willing to do any necessary debugging if someone with sufficient NFS knowledge will point me in right direction. -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 01-Dec-99 Time: 17:53:48 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Netscape and -current
The same here. CURRENT updated and built on Sunday causes native FreeBSD Netscape to lock up. Linux Netscape still works fine. On 22-Nov-99 Jean-Marc Zucconi wrote: 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 -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 22-Nov-99 Time: 09:28:45 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: copy-on-write optimized faults
vmstat -s reports these numbers on my computer: 3649151 copy-on-write faults 1 copy-on-write optimized faults On 29-Oct-99 Alan Cox wrote: I would appreciate it if people running -current would run a "vmstat -s" and tell me if they see a NON-ZERO value for copy-on-write optimized faults. About six months ago, I implemented a simpler and more general optimization at an earlier "fork in the road". (In effect, I avoid the creation of the redundant vm object that "copy-on-write optimized faults" applies to.) If I don't hear anything, I plan to remove the vestiges of this "optimization" from the vm fault handler. Alan 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
intpm0: Could not allocate Bus space
Current (cvsupped and build today) fails to attach to the intpm0 device. The following is my dmesg message: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Tue Oct 26 11:31:29 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/KANPC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (398.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) avail memory = 126738432 (123768K bytes) Preloaded elf kernel "kernel" at 0xc0334000. Preloaded elf module "splash_bmp.ko" at 0xc033409c. Preloaded elf module "vesa.ko" at 0xc0334140. Preloaded splash_image_data "/boot/splash.bmp" at 0xc03341dc. VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc0321102 (122) VESA: STB Velocity 128 (RIVA 128) Pentium Pro MTRR support enabled apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: NVidia Riva128 graphics accelerator irq 11 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller at device 7.3 on pci0 intpm0: Could not allocate Bus space device_probe_and_attach: intpm0 attach returned 6 xl0: 3Com 3c905B-TX Fast Etherlink XL irq 11 at device 13.0 on pci0 xl0: Ethernet address: 00:10:4b:94:9f:5c miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: unknown card (vendor=0x12eb, dev=0x0001) at 14.0 irq 10 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A pca0 at port 0x40 on isa0 pca0: PC speaker audio driver ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 pcm0: SB16 PnP at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 unknown0: Reserved at port 0x100 on isa0 unknown1: Reserved at port 0x108 on isa0 unknown2: Game at port 0x200-0x207 on isa0 unknown3: U.S.Robotics x2 Winmodem Voice at port 0x109-0x110 irq 3 on isa0 ds0 XXX: driver didn't set ifq_maxlen ad0: IBM-DTTA-351680/T51OA70B ATA-4 disk at ata0 as master ad0: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 31 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 acd0: NEC CD-ROM DRIVE:28B/3.05 CDROM drive at ata1 as master acd0: read 2412KB/s (5512KB/s), 256KB buffer, DMA acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked changing root device to wd0s2a WARNING: driver snd should register devices with make_dev() (dev_t = "#snd/3") To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Filesystem deadlock
The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE as of today) to lookup. Shortly after this script is started, all disk activity stops and any attempt to create new process causes system to freese. While in DDB, ps command shows, that all ten fgrep processes are sleeping on inode, all xargs are in waitpid and all sh processes are in wait. Unfortunately, I cannot run -g kernel on my box at this time, so amount of useful information I can provide is pretty much limited :( #!/bin/sh for j in 1 2 3 4 5 6 7 8 9 10; do echo -n $i $j nohup sh -c 'while :; do find /usr -type f | xargs fgrep zukabuka; done' \ /dev/null 21 echo done To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: arplookup 127.0.0.1 failed: could not allocate llinfo
I am having similar problem after installing recent binary snapshot from current.freebsd.org. I do not run amd, but every time when I am trying to ping or telnet to my $HOSTNAME (not localhost!!), I am starting to get these messages. On 19-Nov-99 Luoqi Chen wrote: With the latest current, whenever I start amd, I would see a lot of log messages repeating: arplookup 127.0.0.1 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 127.0.0.1rt If I ifconfig my ether interface down, as expected, the messages would stop. It's puzzling that a packet destined for 127.0.0.1 could end up on the output queue of an ethernet card. It happens only if I run amd, I could telnet to localhost without any problem. Any idea? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 19-Nov-99 Time: 09:37:48 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: arplookup 127.0.0.1 failed: could not allocate llinfo
Well, I REALLY should search mailing lists before sending useless messages... There is PR conf/14913 which describes what is going wrong. Will somebody commit the fix? On 19-Nov-99 Luoqi Chen wrote: With the latest current, whenever I start amd, I would see a lot of log messages repeating: arplookup 127.0.0.1 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 127.0.0.1rt If I ifconfig my ether interface down, as expected, the messages would stop. It's puzzling that a packet destined for 127.0.0.1 could end up on the output queue of an ethernet card. It happens only if I run amd, I could telnet to localhost without any problem. Any idea? -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 19-Nov-99 Time: 10:39:27 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
