Re: [-CURRENT tinderbox] failure on i386/i386

[Dag-Erling Smørgrav]

Peter Wemm [EMAIL PROTECTED] writes:
 Tinderbox wrote:
  gzip -cn 
  /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3  
  catgets.3.gz
  Segmentation fault (core dumped)
  *** Error code 139
 These false alarms are wearing a bit thin.  Is there a problem with the
 tinderbox build machine perhaps?

No, the failures are too systematic for that.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on i386/i386

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=
 writes:
Peter Wemm [EMAIL PROTECTED] writes:
 Tinderbox wrote:
  gzip -cn 
  /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/catgets.3  
  catgets.3.gz
  Segmentation fault (core dumped)
  *** Error code 139
 These false alarms are wearing a bit thin.  Is there a problem with the
 tinderbox build machine perhaps?

No, the failures are too systematic for that.

Don't trust that, I've seen RAM errors be reproducible to +/- 4 instructions
in the cc1 binary in the past.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on i386/i386

[Harti Brandt]

On Sun, 20 Jul 2003, Peter Wemm wrote:

PWTinderbox wrote:
PW
PW gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/cat
PWgets.3  catgets.3.gz
PW Segmentation fault (core dumped)
PW *** Error code 139
PW
PWThese false alarms are wearing a bit thin.  Is there a problem with the
PWtinderbox build machine perhaps?

This seems to be a real bug. There was a discussion on sparc64 Tinderbox
coredumps recently. I see the same problem when doing 'make universe'
about one third of the kernels or buildworlds fail with a make dumping
core in vfork() (according to gdb). I had no chance yet to try with
a make that uses fork() instead of vfork().

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP problem with uma_zalloc

[Harti Brandt]

On Sat, 19 Jul 2003, Bosko Milekic wrote:

BM
BMOn Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara  Harti Brandt wrote:
BM[...]
BM Well the problem is, that nothing is starved. I have an idle machine and
BM a zone that I have limited to 60 or so items. When allocating the 2nd
BM item I get block on the zone limit. Usually I get unblocked whenever I
BM free an item. This will however not happen, because I have neither
BM reached the limit nor is there memory pressure in the system to which I
BM could react. I simply may be blocked forever.
BM
BM  UMA_ZFLAG_FULL is set on the zone prior to the msleep().  This means
BM  that the next free will result in your wakeup, as the next free will
BM  be sent to the zone internally, and not the pcpu cache.

But there is no free to come. To explain where we have the problem:

the HARP ATM code uses a zone in the IP code to allocate control blocks
for VCCs. The zone is limited to 100 items which evaluates to 1 page.
When I start an interface, first the signalling vcc=5 is opened. This
allocates one item from the zone, all the other items go into the CPU
cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works
on UP machines (the zone allocator will find a free item in the CPU
cache), on my 2-proc machine half of the time ILMI gets blocked on the
zonelimit. And it blocks there forever, because, of course nobody is going
to free the one and only allocated item. On a four processor machine the
blocking probability will be 75%.

So in order to be able to get out N items from a zone (given that there is
no shortage of memory) one has to set the limit to N + nproc *
items_per_allocation, which one cannot do because he doesn't know
items_per_allocation.

harti

BM That makes the limit feature for zones rather useless, because I cannot
BM predict how many of the items I can really allocate (this depends on the
BM number of processors, the page size and the configuration of UMA itself).
BM
BM Perhaps we could make the behaviour dependent on the maximum number of
BM items. When it is rather low (a couple of pages worth) and I would block
BM on the zone limit and I have free items in another CPU's cache then
BM drain one of the caches.
BM
BM Or I could simply remove the limits.
BM
BM
BM harti
BM
BM
BM
BM
BM

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on i386/i386

[Mark Murray]

Peter Wemm writes:
 Tinderbox wrote:
 
  gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/c
 at
 gets.3  catgets.3.gz
  Segmentation fault (core dumped)
  *** Error code 139
 
 These false alarms are wearing a bit thin.  Is there a problem with the
 tinderbox build machine perhaps?

My home box is doing it too. as(1) blowing up randomly. No usable core
dumps. :-(.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: telnet build fails without openssl...

[Mark Murray]

Anti writes:
 buildworld fails at telnet if you build with NOCRYPT and NO_OPENSSL --
 telnet stuff is looking for NO_CRYPTO to disable this, which isn't
 documented anywhere...

Thanks!

This should be fixed now.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Fatal trap 12: page fault while in kernel mode

[Bjoern A. Zeeb]

Hi,

while booting a 5.1REL kernel on that machine is fine, booting HEAD
results in...

--- cut ---
Copyright (c) 1992-2003 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.1-CURRENT #0: Mon Jul 21 08:13:36 UTC 2003
[EMAIL PROTECTED]:/u2/src/obj/u2/src/HEAD/src/sys/HAUKI-20030718-01
Preloaded elf kernel /boot/kernel/kernel at 0xc0593000.
Preloaded elf module /boot/kernel/linux.ko at 0xc05930d8.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0593184.
Preloaded elf module /boot/kernel/snd_ich.ko at 0xc0593230.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 996768803 Hz
CPU: Intel Pentium III (996.77-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 536870912 (512 MB)
avail memory = 515473408 (491 MB)
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 10 entries at 0xc00e8790
pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pci_cfgintr: 0:31 INTD BIOS irq 10
pci_cfgintr: 0:31 INTB BIOS irq 11
agp0: Intel 82815 (i815 GMCH) host to PCI bridge mem 0x4800-0x4bff at device 
0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x240
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0395ab4
stack pointer   = 0x10:0xc05b5836
frame pointer   = 0x10:0xc05b587a
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at  trap+0x414: testb   $0x10,0x240(%eax)
db x 0xc0395ab4
trap+0x414: 24080f6
db trace
trap(b0018,58c00010,c05b0010,c150050a,c039d82d) at trap+0x414
calltrap() at calltrap+0x5
--- trap 0x9, eip = 0xc00e8a14, esp = 0xc05b58c2, ebp = 0xc05b58f4 ---
kernbase(c0381ece,8,c05b5940,0,1) at 0xc00e8a14
(null)(50a,c05b596c,c039d82d,c1507700,c1507500) at 0x80246
db panic
panic: from debugger
Debugger(panic)


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0384734
stack pointer   = 0x10:0xc05b55b6
frame pointer   = 0x10:0xc05b55c2
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 0 (swapper)
Stopped at  trap+0x414: testb   $0x10,0x240(%eax)
db reset
--- cut ---

done a gdb -k kernel.debug I get this:

--- cut ---
(kgdb) l *0xc0395ab4
0xc0395ab4 is in trap (/u2/src/HEAD/src/sys/i386/i386/trap.c:472).
467 break;
468
469 /* FALL THROUGH */
470
471 case T_SEGNPFLT:/* segment not present fault */
472 if (PCPU_GET(curpcb)-pcb_flags  PCB_VM86CALL)
473 break;
474
475 /*
476  * Invalid %fs's and %gs's can be created using
(kgdb) q
--- cut ---

Any ideas ? Anything I might try ?

PS: though calling panic I do not get crashdumps.

-- 
Greetings

Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[Gordon Tetlow]

On Fri, Jul 18, 2003 at 11:39:53AM -0700, Tim Kientzle wrote:
 
 I wrote the /rescue stuff and a lot of people have
 reported that it breaks parallel builds, but I haven't yet
 come up with anything.  (In part, because I haven't yet
 managed to reproduce it. sigh)
 
 A couple of things look odd about this:
 
 1) You should not be building 'rescue.mk' twice.
That could be the problem right there, if the rescue.mk
makefile is getting rebuilt (overwritten) while another
build thread is using it.  The dependencies in
rescue/rescue/Makefile look right to me, but I
could be missing something.

It seems that the $(OUTPUTS) target (which has 3 components) causes
this particular error. It can be easily avoided with the following
patch (against an older version of src/rescue/rescue/Makefile,
should be fine):

(Whitespace is probably messed up)
 //depot/user/gordon/dynamic/src/rescue/rescue/Makefile#7 - /home/gtetlow/p4
/dynamic/src/rescue/rescue/Makefile 
@@ -244,6 +244,7 @@
 .endfor


+.ORDER: $(OUTPUTS)
 $(OUTPUTS): $(CONF)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) \
$(CONF)


After doing that, I run into a problem with clparse.o from the dhclient
build. I think I might have a solution for that, but I'm too tired
right now to think straight. I'll look at it tomorrow.

-gordon


pgp0.pgp
Description: PGP signature

Re: Fatal trap 12: page fault while in kernel mode

[Noriyoshi Kawano]

Hi,

I have similar problem.
disable re-route interrupts.
It's works fine.

--- /sys/dev/pci/pci.c.orig Tue Jul  1 23:08:32 2003
+++ /sys/dev/pci/pci.c  Mon Jul 21 11:04:55 2003
@@ -800,7 +800,7 @@
}
 
if (cfg-intpin  0  PCI_INTERRUPT_VALID(cfg-intline)) {
-#if defined(__ia64__) || (defined(__i386__)  !defined(SMP))
+#if defined(__ia64__)
/*
 * Try to re-route interrupts. Sometimes the BIOS or
 * firmware may leave bogus values in these registers.


At Mon, 21 Jul 2003 10:40:09 +0200 (CEST),
Bjoern A. Zeeb wrote:
 
 Hi,
 
 while booting a 5.1REL kernel on that machine is fine, booting HEAD
 results in...
 
 --- cut ---
 Copyright (c) 1992-2003 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.1-CURRENT #0: Mon Jul 21 08:13:36 UTC 2003
 [EMAIL PROTECTED]:/u2/src/obj/u2/src/HEAD/src/sys/HAUKI-20030718-01
 Preloaded elf kernel /boot/kernel/kernel at 0xc0593000.
 Preloaded elf module /boot/kernel/linux.ko at 0xc05930d8.
 Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0593184.
 Preloaded elf module /boot/kernel/snd_ich.ko at 0xc0593230.
 Timecounter i8254  frequency 1193182 Hz
 Timecounter TSC  frequency 996768803 Hz
 CPU: Intel Pentium III (996.77-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0x686  Stepping = 6
   
 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
 real memory  = 536870912 (512 MB)
 avail memory = 515473408 (491 MB)
 Pentium Pro MTRR support enabled
 npx0: math processor on motherboard
 npx0: INT 16 interface
 pcibios: BIOS version 2.10
 Using $PIR table, 10 entries at 0xc00e8790
 pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard
 pci0: PCI bus on pcib0
 pci_cfgintr: 0:31 INTD BIOS irq 10
 pci_cfgintr: 0:31 INTB BIOS irq 11
 agp0: Intel 82815 (i815 GMCH) host to PCI bridge mem 0x4800-0x4bff at 
 device 0.0 on pci0
 pcib1: PCI-PCI bridge at device 1.0 on pci0
 pci1: PCI bus on pcib1
 
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x240
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc0395ab4
 stack pointer   = 0x10:0xc05b5836
 frame pointer   = 0x10:0xc05b587a
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 0 (swapper)
 kernel: type 12 trap, code=0
 Stopped at  trap+0x414: testb   $0x10,0x240(%eax)
 db x 0xc0395ab4
 trap+0x414: 24080f6
 db trace
 trap(b0018,58c00010,c05b0010,c150050a,c039d82d) at trap+0x414
 calltrap() at calltrap+0x5
 --- trap 0x9, eip = 0xc00e8a14, esp = 0xc05b58c2, ebp = 0xc05b58f4 ---
 kernbase(c0381ece,8,c05b5940,0,1) at 0xc00e8a14
 (null)(50a,c05b596c,c039d82d,c1507700,c1507500) at 0x80246
 db panic
 panic: from debugger
 Debugger(panic)
 
 
 Fatal trap 3: breakpoint instruction fault while in kernel mode
 instruction pointer = 0x8:0xc0384734
 stack pointer   = 0x10:0xc05b55b6
 frame pointer   = 0x10:0xc05b55c2
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
 processor eflags= IOPL = 0
 current process = 0 (swapper)
 Stopped at  trap+0x414: testb   $0x10,0x240(%eax)
 db reset
 --- cut ---
 
 done a gdb -k kernel.debug I get this:
 
 --- cut ---
 (kgdb) l *0xc0395ab4
 0xc0395ab4 is in trap (/u2/src/HEAD/src/sys/i386/i386/trap.c:472).
 467 break;
 468
 469 /* FALL THROUGH */
 470
 471 case T_SEGNPFLT:/* segment not present fault */
 472 if (PCPU_GET(curpcb)-pcb_flags  PCB_VM86CALL)
 473 break;
 474
 475 /*
 476  * Invalid %fs's and %gs's can be created using
 (kgdb) q
 --- cut ---
 
 Any ideas ? Anything I might try ?
 
 PS: though calling panic I do not get crashdumps.
 
 -- 
 Greetings
 
 Bjoern A. Zeebbzeeb at Zabbadoz dot NeT
 56 69 73 69 74http://www.zabbadoz.net/
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to [EMAIL PROTECTED]
 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: make release of CURRENT on 4.7 broken again ?

[Andrey Elperin]

On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
   A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
   box, building without -jsomething) :
  
  cc -Os -pipe -c chown_stub.c
  ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
  crunchide -k _crunched_chown_stub chown.lo
  echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return 
  main(argc,argv,envp);} chroot_stub.c
  cc -Os -pipe -c chroot_stub.c
  ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
  crunchide -k _crunched_chroot_stub chroot.lo
  cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo 
  echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo 
  bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo 
  mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo 
  chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
  -lutil
  *** Error code 1
   
  Stop in /usr/obj/usr/src/release/fixit_crunch.
  *** Error code 1
  
 I have committed a fix for this to src/bin/ed/ a few minutes ago.

 Hmm. But I got the same error during last release building (this night).

 Cheers,
 -- 
 Ruslan ErmilovSysadmin and DBA,
 [EMAIL PROTECTED] Sunbay Software Ltd,
 [EMAIL PROTECTED] FreeBSD committer



-- 
Andrey Elperin

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

dhclient -n option does not work

[Tobias Roth]

from dhclient(8):

  The DHCP client can be directed not to attempt to configure any
  interfaces using the -n flag. 


this does not seem to work, my interface gets configured, resolv.conf
written.

can anyone confirm this? what sort of action should be taken to fix
this?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Does linux-sun-jdk_1.4.2 work?

[Yamada Ken Takeshi]

  I have the following error and cannot compile jdk14
on FreeBSD-current, July 20th. cvsup'ed with the latest
linux_base.

  Is is unique to me alone?

tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
#
# Error ID: 4F533F4C494E55580E43505001C9
#

Heap at VM Abort:
Heap
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP problem with uma_zalloc

[Bosko Milekic]

On Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote:
 On Sat, 19 Jul 2003, Bosko Milekic wrote:
 
 BM
 BMOn Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara  Harti Brandt wrote:
 BM[...]
 BM Well the problem is, that nothing is starved. I have an idle machine and
 BM a zone that I have limited to 60 or so items. When allocating the 2nd
 BM item I get block on the zone limit. Usually I get unblocked whenever I
 BM free an item. This will however not happen, because I have neither
 BM reached the limit nor is there memory pressure in the system to which I
 BM could react. I simply may be blocked forever.
 BM
 BM  UMA_ZFLAG_FULL is set on the zone prior to the msleep().  This means
 BM  that the next free will result in your wakeup, as the next free will
 BM  be sent to the zone internally, and not the pcpu cache.
 
 But there is no free to come. To explain where we have the problem:
 
 the HARP ATM code uses a zone in the IP code to allocate control blocks
 for VCCs. The zone is limited to 100 items which evaluates to 1 page.
 When I start an interface, first the signalling vcc=5 is opened. This
 allocates one item from the zone, all the other items go into the CPU
 cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works
 on UP machines (the zone allocator will find a free item in the CPU
 cache), on my 2-proc machine half of the time ILMI gets blocked on the
 zonelimit. And it blocks there forever, because, of course nobody is going
 to free the one and only allocated item. On a four processor machine the
 blocking probability will be 75%.
 
 So in order to be able to get out N items from a zone (given that there is
 no shortage of memory) one has to set the limit to N + nproc *
 items_per_allocation, which one cannot do because he doesn't know
 items_per_allocation.

  It sounds to me like your example is really not the general-case one.
  Basically, you're using a zone capped off at 1 page.  Currently in
  UMA, this is the size of the slab.  So, basically, you have this whole
  zone (with all associated overhead) so as to serve a maximum of only
  one slab.  This defeats most of the assumptions made when the zone is
  created with PCPU caches.  The zone maximum exists to prevent more
  than the specified amount of resources to be allocated toward the
  given zone; I don't think that the intention was to ensure that if
  the maximum items aren't allocated, there will always be one
  available, despite the fact that that is the effective behavior on
  UP.

  The solution to your really small zone problem is to either make the
  zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API
  properly so that you can skip the pcpu caches for all allocations and
  go straight to the zone.  I'd suggest that you make the zone bigger,
  unless there's a Really Good reason not to.

  In mb_alloc (for mbufs) I had implemented something that in this sort
  of scenario would dip into the other caches and transfer over what I
  called a bucket to the current cpu cache.  Although in this
  scenario, it seems like that sort of solution would do what you want,
  some more thought into its behavior reveals that in fact it pessimizes
  the situation.  To give you a better idea, let's consider what happens
  in this specific scenario, where a bucket would be all of a page.
  The allocator would make an attempt to allocate from its pcpu cache
  but would find it empty, so it would then attempt to steal a bucket
  from the second cpu's cache.  There, it would find the bucket, move it
  to its cpu's cache, and grab an item from it.  However, a thread on
  the second cpu may then attempt to grab an item, and the bucket will
  just ping-pong from pcpu cache to pcpu cache; the problem that the
  allocator was trying to solve for such really small zones was in fact
  still there - because of the general assumptions made in the design
  with respect to the size of most zones that it dealt with - only
  instead of failing the allocation, it was pessimizing it.

 harti

Regards,
-- 
Bosko Milekic  *  [EMAIL PROTECTED]  *  [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Does linux-sun-jdk_1.4.2 work?

[Ernst de Haan]

There are indeed more problems with that JDK 1.4.2. Please try on 
freebsd-java instead of ports-committers...

Ernst

On Monday 21 July 2003 14:55, Yamada Ken Takeshi wrote:
   I have the following error and cannot compile jdk14
 on FreeBSD-current, July 20th. cvsup'ed with the latest
 linux_base.

   Is is unique to me alone?

 tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version
 #
 # HotSpot Virtual Machine Error, Internal Error
 # Please report this error at
 # http://java.sun.com/cgi-bin/bugreport.cgi
 #
 # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
 #
 # Error ID: 4F533F4C494E55580E43505001C9
 #

 Heap at VM Abort:
 Heap
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP problem with uma_zalloc

[Harti Brandt]

On Mon, 21 Jul 2003, Bosko Milekic wrote:

BM
BMOn Mon, Jul 21, 2003 at 09:03:00AM +0200, Harti Brandt wrote:
BM On Sat, 19 Jul 2003, Bosko Milekic wrote:
BM
BM BM
BM BMOn Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara  Harti Brandt wrote:
BM BM[...]
BM BM Well the problem is, that nothing is starved. I have an idle machine and
BM BM a zone that I have limited to 60 or so items. When allocating the 2nd
BM BM item I get block on the zone limit. Usually I get unblocked whenever I
BM BM free an item. This will however not happen, because I have neither
BM BM reached the limit nor is there memory pressure in the system to which I
BM BM could react. I simply may be blocked forever.
BM BM
BM BM  UMA_ZFLAG_FULL is set on the zone prior to the msleep().  This means
BM BM  that the next free will result in your wakeup, as the next free will
BM BM  be sent to the zone internally, and not the pcpu cache.
BM
BM But there is no free to come. To explain where we have the problem:
BM
BM the HARP ATM code uses a zone in the IP code to allocate control blocks
BM for VCCs. The zone is limited to 100 items which evaluates to 1 page.
BM When I start an interface, first the signalling vcc=5 is opened. This
BM allocates one item from the zone, all the other items go into the CPU
BM cache. Next I start ILMI. ILMI tries to open its vcc=16. While this works
BM on UP machines (the zone allocator will find a free item in the CPU
BM cache), on my 2-proc machine half of the time ILMI gets blocked on the
BM zonelimit. And it blocks there forever, because, of course nobody is going
BM to free the one and only allocated item. On a four processor machine the
BM blocking probability will be 75%.
BM
BM So in order to be able to get out N items from a zone (given that there is
BM no shortage of memory) one has to set the limit to N + nproc *
BM items_per_allocation, which one cannot do because he doesn't know
BM items_per_allocation.
BM
BM  It sounds to me like your example is really not the general-case one.
BM  Basically, you're using a zone capped off at 1 page.  Currently in
BM  UMA, this is the size of the slab.  So, basically, you have this whole
BM  zone (with all associated overhead) so as to serve a maximum of only
BM  one slab.  This defeats most of the assumptions made when the zone is
BM  created with PCPU caches.  The zone maximum exists to prevent more
BM  than the specified amount of resources to be allocated toward the
BM  given zone; I don't think that the intention was to ensure that if
BM  the maximum items aren't allocated, there will always be one
BM  available, despite the fact that that is the effective behavior on
BM  UP.
BM
BM  The solution to your really small zone problem is to either make the
BM  zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API
BM  properly so that you can skip the pcpu caches for all allocations and
BM  go straight to the zone.  I'd suggest that you make the zone bigger,
BM  unless there's a Really Good reason not to.

I think I take two paths: for stuffs like VCC where there may be a large
number I will just remove the limit. The limits were a leftover when the
ATM code had its own memory pool code. For stuff where there is a high
probability that only a handful (usually 1 or 2) of them will be allocated
(network interfaces) I will try to make it to use malloc().

How do you think about adding a paragraph for uma_zone_set_max to the man
page?:

An upper limit of items in the zone can be specified with a call to
uma_zone_set_max. This limits the total number of items which includes:
allocated items, free items and free items in the per-cpu caches. On
systems with more than one CPU it may not be possible to allocate the
specified number of items, because all of the remaining free items may
be in the caches of the other CPUs when the limit is hit.

Regards,
harti

 BM
BM  In mb_alloc (for mbufs) I had implemented something that in this sort
BM  of scenario would dip into the other caches and transfer over what I
BM  called a bucket to the current cpu cache.  Although in this
BM  scenario, it seems like that sort of solution would do what you want,
BM  some more thought into its behavior reveals that in fact it pessimizes
BM  the situation.  To give you a better idea, let's consider what happens
BM  in this specific scenario, where a bucket would be all of a page.
BM  The allocator would make an attempt to allocate from its pcpu cache
BM  but would find it empty, so it would then attempt to steal a bucket
BM  from the second cpu's cache.  There, it would find the bucket, move it
BM  to its cpu's cache, and grab an item from it.  However, a thread on
BM  the second cpu may then attempt to grab an item, and the bucket will
BM  just ping-pong from pcpu cache to pcpu cache; the problem that the
BM  allocator was trying to solve for such really small zones was in fact
BM  still there - because of the general assumptions made in the design
BM  with respect to the size of most zones that it 

Re: SMP problem with uma_zalloc

[Bosko Milekic]

On Mon, Jul 21, 2003 at 03:47:54PM +0200, Harti Brandt wrote:
 On Mon, 21 Jul 2003, Bosko Milekic wrote:
[...]
 BM  It sounds to me like your example is really not the general-case one.
 BM  Basically, you're using a zone capped off at 1 page.  Currently in
 BM  UMA, this is the size of the slab.  So, basically, you have this whole
 BM  zone (with all associated overhead) so as to serve a maximum of only
 BM  one slab.  This defeats most of the assumptions made when the zone is
 BM  created with PCPU caches.  The zone maximum exists to prevent more
 BM  than the specified amount of resources to be allocated toward the
 BM  given zone; I don't think that the intention was to ensure that if
 BM  the maximum items aren't allocated, there will always be one
 BM  available, despite the fact that that is the effective behavior on
 BM  UP.
 BM
 BM  The solution to your really small zone problem is to either make the
 BM  zone bigger, or to hack at UMA to export the UMA_ZONE_INTERNAL API
 BM  properly so that you can skip the pcpu caches for all allocations and
 BM  go straight to the zone.  I'd suggest that you make the zone bigger,
 BM  unless there's a Really Good reason not to.
 
 I think I take two paths: for stuffs like VCC where there may be a large
 number I will just remove the limit. The limits were a leftover when the
 ATM code had its own memory pool code. For stuff where there is a high
 probability that only a handful (usually 1 or 2) of them will be allocated
 (network interfaces) I will try to make it to use malloc().

  A.  Given the explanation, the small size of the limits makes a
  lot more sense now.  Previously, the limit probably enforced the
  actual number of cached (pre-allocated) items in the pool.  So, it was
  more than just a limit, it was a cache size parameter.  That is
  probably why its size was kept relatively small.  In the zone setting,
  the limit can easily be made larger or removed altogether (if there is
  no danger of that structure consuming all of kernel memory).

 How do you think about adding a paragraph for uma_zone_set_max to the man
 page?:
 
 An upper limit of items in the zone can be specified with a call to
 uma_zone_set_max. This limits the total number of items which includes:
 allocated items, free items and free items in the per-cpu caches. On
 systems with more than one CPU it may not be possible to allocate the
 specified number of items, because all of the remaining free items may
 be in the caches of the other CPUs when the limit is hit.

  Given that it has obviously led to confusion, this sort of change to
  the man page would be encouraging.

  Perhaps you would also ammend to it the purpose of uma_zone_set_max(),
  as it currently stands:

  The purpose of uma_zone_set_max() is to limit the maximum
  amount of memory that the system can dedicate toward the zone
  specified by the 'zone' argument. insert your text from above here

  Would you like to commit the change?

 Regards,
 harti

 -- 
 harti brandt,
 http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
 [EMAIL PROTECTED], [EMAIL PROTECTED]

Cheers,
-- 
Bosko Milekic  *  [EMAIL PROTECTED]  *  [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[Garance A Drosihn]

At 12:34 AM -0400 7/21/03, Garance A Drosihn wrote:
I do know that buildworld finishes OK if I define NORESCUE.
Right now I am running a buildworld that does not specify -j,
and I'll see if that completes OK.
The buildworld without -j did successfully complete.  I have
added that logfile to the lines in ~gad/rescueb if anyone
wants to look at them.
All of these builds were with -current as of Friday.

--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP problem with uma_zalloc

[Harti Brandt]

On Mon, 21 Jul 2003, Bosko Milekic wrote:

BM  A.  Given the explanation, the small size of the limits makes a
BM  lot more sense now.  Previously, the limit probably enforced the
BM  actual number of cached (pre-allocated) items in the pool.  So, it was
BM  more than just a limit, it was a cache size parameter.  That is
BM  probably why its size was kept relatively small.  In the zone setting,
BM  the limit can easily be made larger or removed altogether (if there is
BM  no danger of that structure consuming all of kernel memory).

No, there isn't. VCCs are usually limited by the interface card to a couple
of thousand.

BM How do you think about adding a paragraph for uma_zone_set_max to the man
BM page?:
BM
BM An upper limit of items in the zone can be specified with a call to
BM uma_zone_set_max. This limits the total number of items which includes:
BM allocated items, free items and free items in the per-cpu caches. On
BM systems with more than one CPU it may not be possible to allocate the
BM specified number of items, because all of the remaining free items may
BM be in the caches of the other CPUs when the limit is hit.
BM
BM  Given that it has obviously led to confusion, this sort of change to
BM  the man page would be encouraging.
BM
BM  Perhaps you would also ammend to it the purpose of uma_zone_set_max(),
BM  as it currently stands:
BM
BM  The purpose of uma_zone_set_max() is to limit the maximum
BM  amount of memory that the system can dedicate toward the zone
BM  specified by the 'zone' argument. insert your text from above here
BM
BM  Would you like to commit the change?

Ok, I'll commit it.

Regards,
harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Does linux-sun-jdk_1.4.2 work?

[Adam]

On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote:
   I have the following error and cannot compile jdk14
 on FreeBSD-current, July 20th. cvsup'ed with the latest
 linux_base.
 
   Is is unique to me alone?
 
 tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version
 #
 # HotSpot Virtual Machine Error, Internal Error
 # Please report this error at
 # http://java.sun.com/cgi-bin/bugreport.cgi
 #
 # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
 #
 # Error ID: 4F533F4C494E55580E43505001C9
 #
 
 Heap at VM Abort:
 Heap

It happens to me too. Looks like this port was released too quickly.
Java on FreeBSD is always a bit dodgy, it seems.

-- 
Adam [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: make release of CURRENT on 4.7 broken again ?

[Ruslan Ermilov]

On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote:
 On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
   
   cc -Os -pipe -c chown_stub.c
   ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
   crunchide -k _crunched_chown_stub chown.lo
   echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return 
   main(argc,argv,envp);} chroot_stub.c
   cc -Os -pipe -c chroot_stub.c
   ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
   crunchide -k _crunched_chroot_stub chroot.lo
   cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo 
   echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo 
   sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo 
   mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo 
   chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
   -lutil
   *** Error code 1

   Stop in /usr/obj/usr/src/release/fixit_crunch.
   *** Error code 1
   
  I have committed a fix for this to src/bin/ed/ a few minutes ago.
 
  Hmm. But I got the same error during last release building (this night).
 
The make -j buildworld is currently broken by the recent changes
to kerberos5/, and the issue is being worked out.  The breakage is
mostly visible in the 4.x doing the build of 5.x case, because
the latter has /usr/include/roken.h and hides the building bug.
At the moment, I'm retesting the snapshot build of 5.x on my 4.x
SMP box without -j.  I will follow up with what I get.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature

Re: Does linux-sun-jdk_1.4.2 work?

[Florian Smeets]

Adam wrote:
On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote:

tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
#
# Error ID: 4F533F4C494E55580E43505001C9
#
Heap at VM Abort:
Heap


It happens to me too. Looks like this port was released too quickly.
Java on FreeBSD is always a bit dodgy, it seems.
Hi,

try mounting linprocfs(5) that seemed to solved the problem for me.

regards,
flo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Fatal trap 12: page fault while in kernel mode

[Bjoern A. Zeeb]

On Mon, 21 Jul 2003, Noriyoshi Kawano wrote:

 I have similar problem.
 disable re-route interrupts.
 It's works fine.

 --- /sys/dev/pci/pci.c.orig   Tue Jul  1 23:08:32 2003
 +++ /sys/dev/pci/pci.cMon Jul 21 11:04:55 2003
 @@ -800,7 +800,7 @@
   }

   if (cfg-intpin  0  PCI_INTERRUPT_VALID(cfg-intline)) {
 -#if defined(__ia64__) || (defined(__i386__)  !defined(SMP))
 +#if defined(__ia64__)
   /*
* Try to re-route interrupts. Sometimes the BIOS or
* firmware may leave bogus values in these registers.


Thanks. This works fine. Is there any global solution to the problem
so that I won't need to patch again the time 5.2R comes out ?

-- 
Greetings

Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
56 69 73 69 74  http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: rpcinfo

[Alexander Leidinger]

On Fri, 18 Jul 2003 02:14:18 +0200
Pawel Worach [EMAIL PROTECTED] wrote:

 Danny Braniss wrote:
  I just run rpcinfo:
  
  # rpcinfo
  rpcinfo: can't contact rpcbind: RPC: Port mapper failure - RPC: Success
  
  :=)
 This really belongs in questions@, make sure you have rpcbind_enable=YES in 
 rc.conf

I think he is amused about the use of failure and Success in the
same error message.

Bye,
Alexander.

-- 
   One world, one web, one program  -- Microsoft promotional ad
 Ein Volk, ein Reich, ein Fuehrer  -- Adolf Hitler

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[Tim Kientzle]

Gordon Tetlow wrote:
It seems that the $(OUTPUTS) target (which has 3 components) causes
this particular error.
+.ORDER: $(OUTPUTS)
 $(OUTPUTS): $(CONF)
MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) \
$(CONF)
Hmmm...  Is that what .ORDER is for?  To work around a
parallel make that gratuitously rebuilds things?
After doing that, I run into a problem with clparse.o from the dhclient
build. I think I might have a solution for that, but I'm too tired
right now to think straight. I'll look at it tomorrow.


A-ha!  I've known that dhclient was a problem, but the
above gives me an idea.  I wonder if the following helps?
Tim

Index: sbin/dhclient//Makefile
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sbin/dhclient/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- sbin/dhclient/Makefile 29 Jun 2003 18:46:17 -  1.20
+++ sbin/dhclient/Makefile 21 Jul 2003 16:34:22 -
@@ -52,6 +52,8 @@
 # though, so we must run ``make all'' instead when we are asked to
 # generate an individual object file.
+.ORDER: $(OBJS)
+
 # Note: Must have some commands here to override the default build action
 ${OBJS}: all
@true
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[Gordon Tetlow]

On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote:
 Gordon Tetlow wrote:
 It seems that the $(OUTPUTS) target (which has 3 components) causes
 this particular error.
 
 +.ORDER: $(OUTPUTS)
  $(OUTPUTS): $(CONF)
 MAKEOBJDIRPREFIX=${CRUNCHOBJS} crunchgen -q -m $(OUTMK) -c $(OUTC) 
 \
 $(CONF)
 
 Hmmm...  Is that what .ORDER is for?  To work around a
 parallel make that gratuitously rebuilds things?

Right it serializes build dependencies. The problem with crunchgen is
that a single command makes all of the OUTPUTS, so normally make will
spawn off the same command 3 times in parallel (which seems to cause
problems). To get around it, make it so you each of the OUTPUTS is
built in order and what occurs is a single crunchgen invocation that
the sees that the other OUTPUT targets are up-to-date and then
contintues along.

 After doing that, I run into a problem with clparse.o from the dhclient
 build. I think I might have a solution for that, but I'm too tired
 right now to think straight. I'll look at it tomorrow.
 
 
 A-ha!  I've known that dhclient was a problem, but the
 above gives me an idea.  I wonder if the following helps?

I'll give it a whirl.

-gordon


pgp0.pgp
Description: PGP signature

Re: Buildworld fails in 5.1

[Tim Kientzle]

Gordon Tetlow wrote:
On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote:
Hmmm...  Is that what .ORDER is for?  To work around a
parallel make that gratuitously rebuilds things?
Right it serializes build dependencies. The problem with crunchgen ...
I would argue the problem with make... ;-)  I think it's pretty
clear that
a b c: foo
buildabc
does not require that 'buildabc' be run three times.  Make
should be able to note that 'buildabc' was already spawned
for 'a' and just add 'b' and 'c' to the wait list for
that operation, rather than running additional copies.
Tim

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration

[David O'Brien]

On Tue, Jul 15, 2003 at 07:59:43AM +0200, Harti Brandt wrote:
 On Tue, 15 Jul 2003, Jun Kuriyama wrote:
 JKWith new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
 JK
 JKcc -Wshadow -c re.c
 JKre.c: In function `get_compiled_pattern':
 JKre.c:44: warning: declaration of `exp' shadows a global declaration
 JKbuilt-in:0: warning: shadowed declaration is here
 JK
 JKIt seems local variable exp is conflicted with exp(3) declaration.  I
 JKdon't know what name should be used...
 
 I would call this a compiler bug. It shouldn't declare exp(3) when you
 don't include math.h. As I understand the standard the names in math.h are
 only reserved when you include math.h. I remember that an earlier version
 of gcc had this bug, that was fixed then. Probably they unfixed it again.
 
 What's the chance of getting this fixed?

There is a discussion on the [EMAIL PROTECTED] mailing list, but
they are having a hard time agreeing there is a bug here.  FreeBSD's GCC
problems have a better chance of getting fixed if those that experience
and understand the bug would participate in related discussions on the
GCC mailing lists.  The Linux and Solaris community has no problem doing
this -- for some reason the BSD communities expects the poor guy doing
the GCC imports to be the single voice for BSD. :-(

-- 
-- David([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[-CURRENT tinderbox] failure on alpha/alpha

[Tinderbox]

TB --- 2003-07-21 16:00:00 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-07-21 16:00:00 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-21 16:02:08 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-21 17:06:23 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Mon Jul 21 17:06:23 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: 
error: initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: 
error: (near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: 
error: initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:150: 
error: (near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:412: 
error: `MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:412: 
error: (Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/harp/if_harp.c:412: 
error: for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
TB --- 2003-07-21 17:14:14 - /usr/bin/make returned exit code  1 
TB --- 2003-07-21 17:14:14 - ERROR: failed to build generic kernel
TB --- 2003-07-21 17:14:14 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[Garance A Drosihn]

At 9:46 AM -0700 7/21/03, Tim Kientzle wrote:
Gordon Tetlow wrote:
On Mon, Jul 21, 2003, Tim Kientzle wrote:
Hmmm...  Is that what .ORDER is for?  To work around a
parallel make that gratuitously rebuilds things?
Right it serializes build dependencies. The problem with
crunchgen ...
I would argue the problem with make... ;-)  I think it's
pretty clear that
a b c: foo
buildabc
does not require that 'buildabc' be run three times.  Make
should be able to note that 'buildabc' was already spawned
for 'a' and just add 'b' and 'c' to the wait list for
that operation, rather than running additional copies.
It may not be quite that simple, when it gets to splitting
apart the make rules to build things in parallel.  I tracked
down two problems with parallel builds, and in both cases
make was doing the right thing, given the rules that it
was working with.  On the other hand, I'm certainly no expert
when it comes to writing makefiles for parallel builds.
In any case, the suggested change did not solve the problem
for me, when doing a make -j5 buildworld.  I still get the
failure with:
make: don't know how to make 
/usr/obj/usr/src/rescue/rescue//usr/src/sbin/dhclie
nt/client/clparse.o. Stop

If there's some other way I should run the buildworld to
generate a more helpful output, let me know.  The failure
seems to be 100% reproducible on my machine, at least if I
start out by removing all of /usr/obj/usr/src.
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: putting /dev/lpt in polling mode in boot time.

[Terry Lambert]

Evan Dower wrote:
 From: Andrew Lankford [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Re:  putting /dev/lpt in polling mode in boot time.
 Date: Sun, 20 Jul 2003 15:40:21 -0600
 
 Before anyone corrects me, yes, the man page says bit 5 controls polling,
 0x20.  My question stands.
 
 I may be smoking crack, but isn't it:
 bit 5 = 0001  = 0x10 ?
 bit 6 = 0010  = 0x20 ?
 E

Not if you start counting at 0.

8-).

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: make release of CURRENT on 4.7 broken again ?

[Ruslan Ermilov]

On Mon, Jul 21, 2003 at 06:08:43PM +0300, Ruslan Ermilov wrote:
 On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote:
  On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
 A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
 box, building without -jsomething) :

cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return 
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo 
echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo 
sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo 
mount_cd9660.lo mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo 
ftp.lo telnet.lo vi.lo chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
-lutil
*** Error code 1
 
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1

   I have committed a fix for this to src/bin/ed/ a few minutes ago.
  
   Hmm. But I got the same error during last release building (this night).
  
 The make -j buildworld is currently broken by the recent changes
 to kerberos5/, and the issue is being worked out.  The breakage is
 mostly visible in the 4.x doing the build of 5.x case, because
 the latter has /usr/include/roken.h and hides the building bug.
 At the moment, I'm retesting the snapshot build of 5.x on my 4.x
 SMP box without -j.  I will follow up with what I get.
 
Yes, I can see the breakage:

: crunchide -k _crunched_vi_stub vi.lo
: echo int _crunched_chown_stub(int argc, char **argv, char **envp){return main(a
: rgc,argv,envp);} chown_stub.c
: cc -Os -pipe -c chown_stub.c
: ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
: crunchide -k _crunched_chown_stub chown.lo
: echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return main(
: argc,argv,envp);} chroot_stub.c
: cc -Os -pipe -c chroot_stub.c
: ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
: crunchide -k _crunched_chroot_stub chroot.lo
: cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo
: .lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo b
: sdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo mount_msd
: osfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo chown.lo
:  chroot.lo -ledit -lgeom -lkvm -lm -lncurses -lutil
: telnet.lo: In function `display':
: telnet.lo(.text+0x122e): undefined reference to `EncryptStatus'
: telnet.lo: In function `status':
: telnet.lo(.text+0x1e85): undefined reference to `encrypt_display'
: ...
: 
: telnet.lo(.data+0xaa0): undefined reference to `EncryptStatus'
: *** Error code 1
: 
: Stop in /usr/obj/usr/src/release/fixit_crunch.
: *** Error code 1
: 
: Stop in /usr/src/release.

I believe Mark has committed a fix for this today (commit log
is attached).


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
---BeginMessage---
markm   2003/07/20 16:29:46 PDT

  FreeBSD src repository

  Modified files:
lib/libtelnetMakefile 
libexec/telnetd  Makefile 
usr.bin/telnet   Makefile 
  Log:
  Test correct macro for without crypto option(s).
  
  Revision  ChangesPath
  1.16  +1 -1  src/lib/libtelnet/Makefile
  1.21  +1 -1  src/libexec/telnetd/Makefile
  1.23  +1 -1  src/usr.bin/telnet/Makefile
---End Message---


pgp0.pgp
Description: PGP signature

yesterday's ACPI not working - patch

[Olivier Cortes]

Hi,
i cvsuped around monday morning, and after building / installing, my
kernel said every second or so :

Jul 17 09:48:01 syrenna kernel: ACPI-0438: *** Error: Handler for
[EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
Jul 17 09:48:01 syrenna kernel: ACPI-1287: *** Error: Method execution
failed [\_SB_.PCI0.BAT0._BIF] (Node 0xc3ccc760), AE_NO_HARDWARE_RESPONSE
Jul 17 09:48:01 syrenna kernel: ACPI-0438: *** Error: Handler for
[EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
Jul 17 09:48:01 syrenna kernel: ACPI-1287: *** Error: Method execution
failed [\_SB_.PCI0.AC0_._PSR] (Node 0xc3ccc660), AE_NO_HARDWARE_RESPONSE

note that before upgrading, it was saying:

Jul 16 16:44:22 syrenna kernel: ACPI-0432: *** Error: Handler for
[EmbeddedControl] returned AE_ERROR
Jul 16 16:44:22 syrenna kernel: ACPI-1287: *** Error: Method execution
failed [\_SB_.PCI0.AC0_._PSR] (Node 0xc3ccb660), AE_ERROR
Jul 16 16:44:22 syrenna kernel: ACPI-0432: *** Error: Handler for
[EmbeddedControl] returned AE_ERROR
Jul 16 16:44:22 syrenna kernel: ACPI-1287: *** Error: Method execution
failed [\_SB_.PCI0.BAT0._BST] (Node 0xc3ccb720), AE_ERROR


and now with my patch (taken from a recent mail from Nate) it is OK.
THE PATCH : i just changed line 662 : 1000 - 1.
as i read in other mails, it should already been changed to 5000 or so.

just to make you notice i had the problem too.

note that i use a custom DSDT (the original worked only with windows, and
i found a page related to linux which has inspired my hack on the dsdt).
KERNEL, dmesg, modified DSDT, and other informations (description of the machine)
are to be found at:
http://www.deep-ocean.net/~olive/freebsd/syrenna/

best regards to the -CURRENT team,

Olivier Cortes

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[Marcel Moolenaar]

On Mon, Jul 21, 2003 at 09:46:03AM -0700, Tim Kientzle wrote:
 
 I would argue the problem with make... ;-)  I think it's pretty
 clear that
 
 a b c: foo
 buildabc
 
 does not require that 'buildabc' be run three times.

It's a common perception and one that's wrong.

a b c: d
foo

is a shorthand for

a: d
foo

b: d
foo

c: d
foo

Since most make variants only look at the timestamp one can avoid
building a, b, and c thrice by enforcing an ordering. Make variants
like clearmake may not be tricked that easily, because they keep
track of much more.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Annoucning DragonFly BSD!

[Terry Lambert]

Kris Kennaway wrote:
 On Thu, Jul 17, 2003 at 03:29:12PM +0300, Maxim Sobolev wrote:
  No, everything seems real - at least Matt replies to e-mails
  sent to him on this topic. There is also a live nntp server
  up and running @ dragonflybsd.org, I saw Matt and Terry Lambert
  discussing kernel things this morning there. I doubt that somebody
  will be able to impersonate both Matt and Terry. :))
 
 A Markov chain script could do a fairly passable impersonation of the
 latter.

8^p.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

kmem_mmap_toosmall -- repeatable panic

[Mikhail Teterin]

Hello!

I tried to create a cscope's database with about 6200 files listed
in the cscope.files. The entire tree (including the cscope.files)
is mounted over NFS from a Solaris server.

The July 11th kernel would just crash, today's one is more intelligent:

kmem_malloc(4096): kmem_mmap_too_small: 275251200 total allocated

The machine has 1Gb of RAM and 512Mb of swap...

-mi



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[-CURRENT tinderbox] failure on i386/i386

[Tinderbox]

TB --- 2003-07-21 18:19:35 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-07-21 18:19:35 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-21 18:21:29 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ttyname.3  
ttyname.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/tzset.3  
tzset.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ualarm.3  
ualarm.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ucontext.3  
ucontext.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/ulimit.3  
ulimit.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/uname.3  
uname.3.gz
gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/gen/unvis.3  
unvis.3.gz
Bus error (core dumped)
*** Error code 138

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src.
TB --- 2003-07-21 19:01:12 - /usr/bin/make returned exit code  1 
TB --- 2003-07-21 19:01:12 - ERROR: failed to build world
TB --- 2003-07-21 19:01:12 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[-CURRENT tinderbox] failure on i386/pc98

[Tinderbox]

TB --- 2003-07-21 19:01:13 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-07-21 19:01:13 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-21 19:03:15 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-21 20:02:20 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Mon Jul 21 20:02:20 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: 
`MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/harp/if_harp.c:412: error: 
for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-07-21 20:09:36 - /usr/bin/make returned exit code  1 
TB --- 2003-07-21 20:09:36 - ERROR: failed to build generic kernel
TB --- 2003-07-21 20:09:36 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Buildworld fails in 5.1

[David O'Brien]

On Mon, Jul 21, 2003 at 09:46:03AM -0700, Tim Kientzle wrote:
 Gordon Tetlow wrote:
 On Mon, Jul 21, 2003 at 09:36:37AM -0700, Tim Kientzle wrote:
 Hmmm...  Is that what .ORDER is for?  To work around a
 parallel make that gratuitously rebuilds things?
 
 Right it serializes build dependencies. The problem with crunchgen ...
 
 I would argue the problem with make... ;-)  I think it's pretty
 clear that

It is not clear.

 a b c: foo
 buildabc
 
 does not require that 'buildabc' be run three times.

The above is short hand for

a: foo
buildabc
b: foo
buildabc
c: foo
buildabc

make in no way knows that buildabc produces 3 things and not a single
one.

-- 
-- David  ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

FreeBSD 5.1-R kernel panic

[Stephane Raimbault]

I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the
following kernel panic.

panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated

I'm trying to figure out what could be causing this, what kind of
information that I could provide to this group (or other group?) to see if
this is a bug in FreeBSD that needs to be looked into?

The box is basically a busy apache server... the kernel panic seemed to
occur during the periodic daily was running.  It seems to complete the
440.status-mailq part of periodic daily , but doesn't do
450.status-security.

This isn't the first time the box has crashed at aprox. 3:01 am (when daily
runs)... however this is the first time I've seend the kernel panic message
quoted above in the /var/run/dmesg.boot file.

I have attached the entire /var/run/dmesg.boot file to this message.

What can I do to assist in identifiying and resolving this problem?

Thanks,
Stephane Raimbault.
%cat /var/run/dmesg.boot
76.232.138 in via em0
panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated
cpuid = 0; lapic.id = 
boot() called on cpu#0

syncing disks, buffers remaining... 7154 7154 7153 7153 7153 7153 7154 7152 7152 7152 
7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152
Copyright (c) 1992-2003 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.1-RELEASE #0: Fri Jun 20 18:36:54 MDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SRV2
Preloaded elf kernel /boot/kernel/kernel at 0xc06ef000.
Preloaded elf module /boot/kernel/ipfw.ko at 0xc06ef2e4.
Preloaded elf module /boot/kernel/acpi.ko at 0xc06ef390.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2399328676 Hz
CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf27  Stepping = 7
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Hyperthreading: 2 logical CPUs
real memory  = 4160225280 (3967 MB)
avail memory = 4045828096 (3858 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
Programming 24 pins in IOAPIC #1
Programming 24 pins in IOAPIC #2
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00050014, at 0xfee0
 cpu1 (AP):  apic id:  6, version: 0x00050014, at 0xfee0
 cpu2 (AP):  apic id:  1, version: 0x00050014, at 0xfee0
 cpu3 (AP):  apic id:  7, version: 0x00050014, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec0
 io1 (APIC): apic id:  3, version: 0x00178020, at 0xfec8
 io2 (APIC): apic id:  4, version: 0x00178020, at 0xfec80400
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: PTLTDRSDT   on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 24 entries at 0xc00fde40
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
IOAPIC #0 intpin 16 - irq 2
IOAPIC #0 intpin 19 - irq 10
IOAPIC #0 intpin 18 - irq 11
pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0
pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND
pci1: ACPI PCI bus on pcib1
pci1: base peripheral, interrupt controller at device 28.0 (no driver attached)
pcib2: ACPI PCI-PCI bridge at device 29.0 on pci1
pci2: ACPI PCI bus on pcib2
IOAPIC #2 intpin 6 - irq 16
IOAPIC #2 intpin 7 - irq 17
em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 0x3000-0x303f mem 
0xf820-0xf821 irq 16 at device 3.0 on pci2
em0:  Speed:100 Mbps  Duplex:Half
em1: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 0x3040-0x307f mem 
0xf822-0xf823 irq 17 at device 3.1 on pci2
em1:  Speed:1000 Mbps  Duplex:Full
pci1: base peripheral, interrupt controller at device 30.0 (no driver attached)
pcib3: ACPI PCI-PCI bridge at device 31.0 on pci1
pci3: ACPI PCI bus on pcib3
IOAPIC #1 intpin 6 - irq 18
asr0: Adaptec Caching SCSI RAID mem 
0xfc00-0xfdff,0xfb00-0xfbff,0xf830-0xf83f irq 18 at device 3.0 
on pci3
asr0: major=154
asr0: ADAPTEC 2015S FW Rev. 3B05, 2 channel, 256 CCBs, Protocol I2O
uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x2000-0x201f irq 2 at 
device 29.0 on pci0
usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x2020-0x203f irq 10 at 
device 29.1 on pci0
usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1
usb1: USB 

msdosfs causes system panic under CURRENT and on 4.8-RELEASE

[Alexander Portnoy]

I have an image of floppy disk formatted under win2k that causes
system panic under CURRENT and on 4.8-RELEASE. This hapens
after I mount the image (via vnode or directly from floppy) and do 'ls'
of one of directories on the image.  If somebody wants to fix the bug
 - send me an e-mail and I will send the image.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[-CURRENT tinderbox] failure on ia64/ia64

[Tinderbox]

TB --- 2003-07-21 20:09:36 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-07-21 20:09:36 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-21 20:11:47 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-21 21:23:38 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Mon Jul 21 21:23:38 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:150: error: 
(near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: 
`MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/harp/if_harp.c:412: error: 
for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-07-21 21:33:40 - /usr/bin/make returned exit code  1 
TB --- 2003-07-21 21:33:40 - ERROR: failed to build generic kernel
TB --- 2003-07-21 21:33:40 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on i386/i386

[Peter Wemm]

Mark Murray wrote:
 Peter Wemm writes:
  Tinderbox wrote:
  
   gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls
/c
  at
  gets.3  catgets.3.gz
   Segmentation fault (core dumped)
   *** Error code 139
  
  These false alarms are wearing a bit thin.  Is there a problem with the
  tinderbox build machine perhaps?
 
 My home box is doing it too. as(1) blowing up randomly. No usable core
 dumps. :-(.

Hmm. I thought it was gzip that was dying. Looks like its make instead, and
is rather consistent.

 grep dump /var/log/messages
Jul 20 14:14:52 cueball kernel: pid 34706 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 20 14:56:35 cueball kernel: pid 16740 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 20 18:32:07 cueball kernel: pid 6784 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 21 00:43:54 cueball kernel: pid 85754 (make), uid 722: exited on signal 11 (core 
dumped)
Jul 21 15:01:12 cueball kernel: pid 51790 (make), uid 722: exited on signal 10 (core 
dumped)

So, who has been messing with make(1) lately?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Does linux-sun-jdk_1.4.2 work?

[Charles Anderson]

I still get 
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
#
# Error ID: 4F533F4C494E55583F491418160E43505002EF
#

Heap at VM Abort:
Heap
(and here it hangs, and I kill -9 from another window)

And I do have linprocfs mounted.

-Charlie
On Mon, Jul 21, 2003 at 05:37:36PM +0200, Florian Smeets wrote:
 Adam wrote:
 On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote:
 
 tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version
 #
 # HotSpot Virtual Machine Error, Internal Error
 # Please report this error at
 # http://java.sun.com/cgi-bin/bugreport.cgi
 #
 # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
 #
 # Error ID: 4F533F4C494E55580E43505001C9
 #
 
 Heap at VM Abort:
 Heap
 
 
 It happens to me too. Looks like this port was released too quickly.
 Java on FreeBSD is always a bit dodgy, it seems.
 
 Hi,
 
 try mounting linprocfs(5) that seemed to solved the problem for me.
 
 regards,
 flo
 
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-java
 To unsubscribe, send any mail to [EMAIL PROTECTED]

-- 
Charles Andersoncaa at columbus dot rr dot com

No quote, no nothin'
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD 5.1-R kernel panic

[Mik Firestone]

For what it is worth, I am having the exact same problem.  I cvsup'd and
builtworld on Sunday, July 20,  and my machine has been crashing about every
half-hour since.  It starts slowing down, the load average begins to
climb until it eventually grinds to a halt.  If I wait long enough, I
will see the same panic Stephane saw.

Doing a ps -auxw shows that usb0 is using the vast majority of the CPU
time before the grinding halt.  I have tried leaving the machine in
multi-user and sigle-user mode with the same results.  I have attempted
to compile a new kernel that does not have the USB stuff compiled in,
but my machine won't stay running long enough.

I do have the debugger compiled in, but I do not know enough of what I
am doing to provide reasonable information to the list.  If somebody
can tell me the commands to run in the debugger, I will let my machine
panic again and grab that data.

Mik

On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote:
 I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the
 following kernel panic.
 
 panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated
 
 I'm trying to figure out what could be causing this, what kind of
 information that I could provide to this group (or other group?) to see if
 this is a bug in FreeBSD that needs to be looked into?
 
 The box is basically a busy apache server... the kernel panic seemed to
 occur during the periodic daily was running.  It seems to complete the
 440.status-mailq part of periodic daily , but doesn't do
 450.status-security.
 
 This isn't the first time the box has crashed at aprox. 3:01 am (when daily
 runs)... however this is the first time I've seend the kernel panic message
 quoted above in the /var/run/dmesg.boot file.
 
 I have attached the entire /var/run/dmesg.boot file to this message.
 
 What can I do to assist in identifiying and resolving this problem?
 
 Thanks,
 Stephane Raimbault.

 %cat /var/run/dmesg.boot
 76.232.138 in via em0
 panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated
 cpuid = 0; lapic.id = 
 boot() called on cpu#0
 
 syncing disks, buffers remaining... 7154 7154 7153 7153 7153 7153 7154 7152 7152 
 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 7152 
 7152
 Copyright (c) 1992-2003 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.1-RELEASE #0: Fri Jun 20 18:36:54 MDT 2003
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SRV2
 Preloaded elf kernel /boot/kernel/kernel at 0xc06ef000.
 Preloaded elf module /boot/kernel/ipfw.ko at 0xc06ef2e4.
 Preloaded elf module /boot/kernel/acpi.ko at 0xc06ef390.
 Timecounter i8254  frequency 1193182 Hz
 Timecounter TSC  frequency 2399328676 Hz
 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0xf27  Stepping = 7
   
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   Hyperthreading: 2 logical CPUs
 real memory  = 4160225280 (3967 MB)
 avail memory = 4045828096 (3858 MB)
 Programming 24 pins in IOAPIC #0
 IOAPIC #0 intpin 2 - irq 0
 Programming 24 pins in IOAPIC #1
 Programming 24 pins in IOAPIC #2
 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
  cpu0 (BSP): apic id:  0, version: 0x00050014, at 0xfee0
  cpu1 (AP):  apic id:  6, version: 0x00050014, at 0xfee0
  cpu2 (AP):  apic id:  1, version: 0x00050014, at 0xfee0
  cpu3 (AP):  apic id:  7, version: 0x00050014, at 0xfee0
  io0 (APIC): apic id:  2, version: 0x00178020, at 0xfec0
  io1 (APIC): apic id:  3, version: 0x00178020, at 0xfec8
  io2 (APIC): apic id:  4, version: 0x00178020, at 0xfec80400
 Pentium Pro MTRR support enabled
 npx0: math processor on motherboard
 npx0: INT 16 interface
 acpi0: PTLTDRSDT   on motherboard
 pcibios: BIOS version 2.10
 Using $PIR table, 24 entries at 0xc00fde40
 acpi0: power button is handled as a fixed feature programming model.
 Timecounter ACPI-fast  frequency 3579545 Hz
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 acpi_cpu0: CPU on acpi0
 acpi_cpu1: CPU on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 IOAPIC #0 intpin 16 - irq 2
 IOAPIC #0 intpin 19 - irq 10
 IOAPIC #0 intpin 18 - irq 11
 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0
 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND
 pci1: ACPI PCI bus on pcib1
 pci1: base peripheral, interrupt controller at device 28.0 (no driver attached)
 pcib2: ACPI PCI-PCI bridge at device 29.0 on pci1
 pci2: ACPI PCI bus on pcib2
 IOAPIC #2 intpin 6 - irq 16
 IOAPIC #2 intpin 7 - irq 17
 em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 0x3000-0x303f mem 
 0xf820-0xf821 irq 16 at device 3.0 on pci2
 em0:  

Re: FreeBSD 5.1-R kernel panic

[Bosko Milekic]

On Mon, Jul 21, 2003 at 03:01:24PM -0600, Stephane Raimbault wrote:
 I'm running FreeBSD 5.1-RELEASE with the SMP kernel and ran across the
 following kernel panic.
 
 panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated
 
 I'm trying to figure out what could be causing this, what kind of
 information that I could provide to this group (or other group?) to see if
 this is a bug in FreeBSD that needs to be looked into?
 
 The box is basically a busy apache server... the kernel panic seemed to
 occur during the periodic daily was running.  It seems to complete the
 440.status-mailq part of periodic daily , but doesn't do
 450.status-security.
 
 This isn't the first time the box has crashed at aprox. 3:01 am (when daily
 runs)... however this is the first time I've seend the kernel panic message
 quoted above in the /var/run/dmesg.boot file.
 
 I have attached the entire /var/run/dmesg.boot file to this message.
 
 What can I do to assist in identifiying and resolving this problem?
 
 Thanks,
 Stephane Raimbault.

  Just a few things:

  1) Do you have PAE enabled?
  
  2) Can you upgrade to src/sys/kern/kern_malloc.c version 1.126 or
  upgrade to HEAD?

  If you have PAE enabled and (2) does not fix your problem, then please
  post a stack trace that resulted in the panic.  You also have a lot of
  RAM so if (2) above does not fix your problem, try setting the
  kern.vm.kmem.size bootable to approximately 350,000,000 or so (even
  400,000,000 is OK as long as NMBCLUSTERS is not too-too high).

-- 
Bosko Milekic  *  [EMAIL PROTECTED]  *  [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[-CURRENT tinderbox] failure on sparc64/sparc64

[Tinderbox]

TB --- 2003-07-21 21:33:41 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-07-21 21:33:41 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-21 21:35:42 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-21 22:32:13 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Mon Jul 21 22:32:13 GMT 2003
[...]
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: 
error: initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: 
error: (near initialization for `map_devs[13].dev')
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: 
error: initializer element is not constant
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:150: 
error: (near initialization for `map_devs[13]')
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c: In 
function `harp_attach':
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:412: 
error: `MEDIA_UTP25' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:412: 
error: (Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/harp/if_harp.c:412: 
error: for each function it appears in.)
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/harp.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-07-21 22:38:29 - /usr/bin/make returned exit code  1 
TB --- 2003-07-21 22:38:29 - ERROR: failed to build generic kernel
TB --- 2003-07-21 22:38:29 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD 5.1-R kernel panic

[Bosko Milekic]

On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote:
 For what it is worth, I am having the exact same problem.  I cvsup'd and
 builtworld on Sunday, July 20,  and my machine has been crashing about every
 half-hour since.  It starts slowing down, the load average begins to
 climb until it eventually grinds to a halt.  If I wait long enough, I
 will see the same panic Stephane saw.
 
 Doing a ps -auxw shows that usb0 is using the vast majority of the CPU
 time before the grinding halt.  I have tried leaving the machine in
 multi-user and sigle-user mode with the same results.  I have attempted
 to compile a new kernel that does not have the USB stuff compiled in,
 but my machine won't stay running long enough.
 
 I do have the debugger compiled in, but I do not know enough of what I
 am doing to provide reasonable information to the list.  If somebody
 can tell me the commands to run in the debugger, I will let my machine
 panic again and grab that data.
 
 Mik

  Does reverting to pre-July 20 get rid of your problem?  Note that the
  originator of the first Email mentionned that he is running what
  appeared to be stock 5.1-RELEASE, which may or may not be related to
  what you're seeing.

  If reverting to pre-July 20 gets rid of your problem, perhaps we can
  figure out what commit triggered this behavior for you.  Also, do you
  have PAE enabled?

-- 
Bosko Milekic  *  [EMAIL PROTECTED]  *  [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD 5.1-R kernel panic

[Bruce Cran]

On Mon, Jul 21, 2003 at 06:43:11PM +, Bosko Milekic wrote:
 
 
 On Mon, Jul 21, 2003 at 06:24:07PM -0400, Mik Firestone wrote:
  For what it is worth, I am having the exact same problem.  I cvsup'd and
  builtworld on Sunday, July 20,  and my machine has been crashing about every
  half-hour since.  It starts slowing down, the load average begins to
  climb until it eventually grinds to a halt.  If I wait long enough, I
  will see the same panic Stephane saw.
  
  Doing a ps -auxw shows that usb0 is using the vast majority of the CPU
  time before the grinding halt.  I have tried leaving the machine in
  multi-user and sigle-user mode with the same results.  I have attempted
  to compile a new kernel that does not have the USB stuff compiled in,
  but my machine won't stay running long enough.
  
  I do have the debugger compiled in, but I do not know enough of what I
  am doing to provide reasonable information to the list.  If somebody
  can tell me the commands to run in the debugger, I will let my machine
  panic again and grab that data.
  
  Mik
 
   Does reverting to pre-July 20 get rid of your problem?  Note that the
   originator of the first Email mentionned that he is running what
   appeared to be stock 5.1-RELEASE, which may or may not be related to
   what you're seeing.
 
   If reverting to pre-July 20 gets rid of your problem, perhaps we can
   figure out what commit triggered this behavior for you.  Also, do you
   have PAE enabled?
 

It sounds like the same or similar problem reported in the 'USB crappiness'
thread - the system slows down, and then any command crashes the system with
the error about kmem.  I posted a backtrace to the problem in usb_mem.c, and
the developer has posted a temporary fix - it was a problem with bus_dma,
it was allocating too much memory and running out of kernel memory.

If the kernel debugger is compiled in, the system should drop to the db 
prompt when it panics.  Type 'tr' and post the results it gives.  This
panic appears to stop memory dumps working, otherwise you could set the
dumpdev variable in rc.conf also get
the source listing of where the problem occurs: the FreeBSD Developers Handbook
has more information.

--
Bruce Cran
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP and setrunnable()- scheduler 4bsd

[Andy Farkas]

On Wed, 9 Jul 2003, Terry Lambert wrote:
 Andy Farkas wrote:
  On Tue, 8 Jul 2003, Julian Elischer wrote:
   It looks tp me that if we make a thread runnable
   and there is a processor in the idle loop, the idle processor should be
   kicked in some way to make it go get the newly runnable thread.
 
  Is this what's happenning to me an my setiathomes?

 The command:

   sysctl machdep.cpu_idle_hlt

 will tell you.  If it says 1, then it may be the problem.  If it
 says 0, then it's not the problem.  You can explicitly set it to
 zero to disable halting in the idle loop.  If you do this, your
 machine is likely to run ~20% hotter (depending on the CPU type),
 since HLT'ing an idle CPU tends to cool it off.

 If this fixes your problem, then it's likely that what's happening
 is that one or more of your CPU's are being idled until the clock
 or some other interrupt fires, at which point in time your setiathome
 processes are probably not the highest priority, as other things with
 higher priority have gotten in the run queue ahead of them.

 If this is the case, then Julian's suggested fix of an IPI to one or
 more idle CPU's when a process becomes ready-to-run will most likely
 be necessary to avoid this situation.

Well, looks like machdep.cpu_idle_hlt affects the 4bsd scheduler.

Julian, have your patches at http://www.freebsd.org/~julian/it.diff been
incorporated yet? SHould I try them?

hummer# sysctl -a | grep kern.ver
kern.version: FreeBSD 5.1-RELEASE #0: Thu Jun 26 01:57:42 EST 2003
hummer# sysctl -a | grep cpu
kern.threads.virtual_cpu: 4
kern.ccpu: 1948 --- whats this?
kern.smp.cpus: 4
hw.ncpu: 4
machdep.cpu_idle_hlt: 0
machdep.hlt_cpus: 0
hummer#
hummer# vmstat -c 12 -w 10
 procs  memory  pagedisks faults  cpu
 r b w avmfre  flt  re  pi  po  fr  sr ad0 am0   in   sy  cs us sy id
 1 1 3  124804  20792   99   0   0   0 131  20   0   0  3620 544 33  3 64
 2 1 2  125240  32460  197   0   0   0 358 258   0   1  3650 2161 67 26  7
 2 1 2  124728  32204  214   0   0   0 249   0   0   1  3820 1280 72 23  5
 1 1 3  124112  29652  257   0   0   0 247   0   3   1  4140 1571 70 25  5
 3 1 1  124624  26020  236   0   0   0 297   0   0   1  3730 1367 70 24  7
 2 1 2  124792  25464  222   0   0   0 266   0   2   1  4080 1308 72 24  4
 3 1 1  123764  25172  203   0   0   0 227   0   0   1  3800 1053 72 23  5
 3 1 2  124164  22004  229   0   0   0 264   0   0   1  3710 1164 72 25  3
 3 1 2  124796  20232  208   0   0   0 262   0   1   1  3830 1269 72 23  5
 3 1 1  123768  20448  225   0   0   0 252   0   0   1  3740 1306 72 25  3
 3 1 0  122736  33736  214   0   0   0 458 194   0   1  3630 1341 72 24  4
 3 1 1  123380  32008  236   0   0   0 222   0   2   1  4050 1430 72 25  4
hummer#
hummer# sysctl machdep.cpu_idle_hlt=1
machdep.cpu_idle_hlt: 0 - 1
hummer# vmstat -c 12 -w 10
 procs  memory  pagedisks faults  cpu
 r b w avmfre  flt  re  pi  po  fr  sr ad0 am0   in   sy  cs us sy id
 2 1 1  124760  20848   99   0   0   0 131  20   0   0  3620 544 33  3 64
 1 1 3  123948  20844  157   0   0   0 191   0   0   1  3850 1142 51 21 28
 2 1 2  124408  20472  134   0   0   0 176   0   0   1  3720 1118 48 22 30
 2 1 1  124992  18800  179   0   0   0 181   0   1   2  3940 1147 49 20 31
 2 2 3  123792  31228  162   0   0   0 367 196   0   1  3780  48 21 30
 1 1 4  124348  30048  175   0   0   0 169   0   0   1  3680 1084 51 22 27
 2 0 4  18  29140  142   0   0   0 193   0   1   2  3990 1056 53 21 26
 2 1 2  124688  25324  176   0   0   0 135   0   0   1  3700 1138 47 21 31
 2 1 1  122632  26572  136   0   0   0 209   0   0   1  3740 1110 50 21 30
 2 1 2  122288  26036  162   0   0   0 193   0   1   2  3840 1152 49 22 29
 2 1 2  122288  25204  136   0   0   0 157   0   0   1  3690 1101 50 21 29
 2 1 2  122700  23720  172   0   0   0 183   0   0   1  3760 1123 48 21 31

Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60
every few minutes! (xload looks like a graph of a sinewave)

If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where
it should be.

--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/




___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP and setrunnable()- scheduler 4bsd

[Julian Elischer]

On Tue, 22 Jul 2003, Andy Farkas wrote:

 On Wed, 9 Jul 2003, Terry Lambert wrote:
  Andy Farkas wrote:
   On Tue, 8 Jul 2003, Julian Elischer wrote:
It looks tp me that if we make a thread runnable
and there is a processor in the idle loop, the idle processor should be
kicked in some way to make it go get the newly runnable thread.
  
   Is this what's happenning to me an my setiathomes?
 
  The command:
 
  sysctl machdep.cpu_idle_hlt
 
  will tell you.  If it says 1, then it may be the problem.  If it
  says 0, then it's not the problem.  You can explicitly set it to
  zero to disable halting in the idle loop.  If you do this, your
  machine is likely to run ~20% hotter (depending on the CPU type),
  since HLT'ing an idle CPU tends to cool it off.
 
  If this fixes your problem, then it's likely that what's happening
  is that one or more of your CPU's are being idled until the clock
  or some other interrupt fires, at which point in time your setiathome
  processes are probably not the highest priority, as other things with
  higher priority have gotten in the run queue ahead of them.
 
  If this is the case, then Julian's suggested fix of an IPI to one or
  more idle CPU's when a process becomes ready-to-run will most likely
  be necessary to avoid this situation.
 
 Well, looks like machdep.cpu_idle_hlt affects the 4bsd scheduler.
 
 Julian, have your patches at http://www.freebsd.org/~julian/it.diff been
 incorporated yet? SHould I try them?

Mr Wolf,

They are not incorporated..
you may try them (but I didn't see much difference)
I would like to readress the issue some time.


 
 hummer# sysctl -a | grep kern.ver
 kern.version: FreeBSD 5.1-RELEASE #0: Thu Jun 26 01:57:42 EST 2003
 hummer# sysctl -a | grep cpu
 kern.threads.virtual_cpu: 4
 kern.ccpu: 1948 --- whats this?

no idea

 kern.smp.cpus: 4
 hw.ncpu: 4
 machdep.cpu_idle_hlt: 0
 machdep.hlt_cpus: 0
 hummer#
 hummer# vmstat -c 12 -w 10
  procs  memory  pagedisks faults  cpu
  r b w avmfre  flt  re  pi  po  fr  sr ad0 am0   in   sy  cs us sy id
  1 1 3  124804  20792   99   0   0   0 131  20   0   0  3620 544 33  3 64
  2 1 2  125240  32460  197   0   0   0 358 258   0   1  3650 2161 67 26  7
  2 1 2  124728  32204  214   0   0   0 249   0   0   1  3820 1280 72 23  5
  1 1 3  124112  29652  257   0   0   0 247   0   3   1  4140 1571 70 25  5
  3 1 1  124624  26020  236   0   0   0 297   0   0   1  3730 1367 70 24  7
  2 1 2  124792  25464  222   0   0   0 266   0   2   1  4080 1308 72 24  4
  3 1 1  123764  25172  203   0   0   0 227   0   0   1  3800 1053 72 23  5
  3 1 2  124164  22004  229   0   0   0 264   0   0   1  3710 1164 72 25  3
  3 1 2  124796  20232  208   0   0   0 262   0   1   1  3830 1269 72 23  5
  3 1 1  123768  20448  225   0   0   0 252   0   0   1  3740 1306 72 25  3
  3 1 0  122736  33736  214   0   0   0 458 194   0   1  3630 1341 72 24  4
  3 1 1  123380  32008  236   0   0   0 222   0   2   1  4050 1430 72 25  4
 hummer#
 hummer# sysctl machdep.cpu_idle_hlt=1
 machdep.cpu_idle_hlt: 0 - 1
 hummer# vmstat -c 12 -w 10
  procs  memory  pagedisks faults  cpu
  r b w avmfre  flt  re  pi  po  fr  sr ad0 am0   in   sy  cs us sy id
  2 1 1  124760  20848   99   0   0   0 131  20   0   0  3620 544 33  3 64
  1 1 3  123948  20844  157   0   0   0 191   0   0   1  3850 1142 51 21 28
  2 1 2  124408  20472  134   0   0   0 176   0   0   1  3720 1118 48 22 30
  2 1 1  124992  18800  179   0   0   0 181   0   1   2  3940 1147 49 20 31
  2 2 3  123792  31228  162   0   0   0 367 196   0   1  3780  48 21 30
  1 1 4  124348  30048  175   0   0   0 169   0   0   1  3680 1084 51 22 27
  2 0 4  18  29140  142   0   0   0 193   0   1   2  3990 1056 53 21 26
  2 1 2  124688  25324  176   0   0   0 135   0   0   1  3700 1138 47 21 31
  2 1 1  122632  26572  136   0   0   0 209   0   0   1  3740 1110 50 21 30
  2 1 2  122288  26036  162   0   0   0 193   0   1   2  3840 1152 49 22 29
  2 1 2  122288  25204  136   0   0   0 157   0   0   1  3690 1101 50 21 29
  2 1 2  122700  23720  172   0   0   0 183   0   0   1  3760 1123 48 21 31
 
 Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60
 every few minutes! (xload looks like a graph of a sinewave)
 
 If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where
 it should be.

define should.




 
 --
 
  :{ [EMAIL PROTECTED]
 
 Andy Farkas
 System Administrator
Speednet Communications
  http://www.speednet.com.au/
 
 
 
 
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on i386/i386

[Dag-Erling Smørgrav]

Peter Wemm [EMAIL PROTECTED] writes:
 Hmm. I thought it was gzip that was dying. Looks like its make instead, and
 is rather consistent.

told you so

 So, who has been messing with make(1) lately?

I believe that the problem is in the kernel, not in make(1); it just
happens to be triggered by make(1) because it is a big (if not the
biggest) vfork(2) consumer.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP and setrunnable()- scheduler 4bsd

[Andy Farkas]

 Mr Wolf,

Heh, you noticed :)

  Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60
  every few minutes! (xload looks like a graph of a sinewave)
 
  If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where
  it should be.

 define should.

When all 3 seti's get their normal 95% cpu time:

32531 setiathome 139   15 16536K 15520K *Giant 1  60.9H 95.85% 95.85% setiathome
32533 setiathome 139   15 16856K 16032K CPU3   3  61.0H 95.65% 95.65% setiathome
32532 setiathome 139   15 15524K 14912K CPU2   2  60.8H 95.51% 95.51% setiathome
54738 andyf  1320  3084K  2140K *Giant 0  64:54 83.84% 83.84% ssh
   12 root   -160 0K12K RUN2 133.4H  3.81%  3.81% idle: cpu2
   13 root   -160 0K12K RUN1 131.7H  3.47%  3.47% idle: cpu1
   14 root   -160 0K12K CPU0   0 130.8H  3.37%  3.37% idle: cpu0
   11 root   -160 0K12K RUN3 135.2H  2.88%  2.88% idle: cpu3

As opposed to abnormal when cpu_idle_hlt=1:

32533 setiathome 139   15 15828K 15000K CPU1   2  61.0H 89.40% 89.40% setiathome
32532 setiathome 139   15 16552K 15660K *Giant 2  60.8H 88.18% 88.18% setiathome
54738 andyf  1300  3084K  2140K select 2  68:54 75.78% 75.78% ssh
   13 root   -160 0K12K RUN1 131.7H 29.05% 29.05% idle: cpu1
   12 root   -160 0K12K CPU2   2 133.4H 28.08% 28.08% idle: cpu2
   11 root   -160 0K12K CPU3   3 135.2H 27.83% 27.83% idle: cpu3
   14 root   -160 0K12K RUN0 130.8H 26.37% 26.37% idle: cpu0
32531 setiathome 131   15 15640K 14976K *Giant 2  61.0H 20.51% 20.51% setiathome


--

 :{ [EMAIL PROTECTED]

Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SMP and setrunnable()- scheduler 4bsd

[Julian Elischer]

On Tue, 22 Jul 2003, Andy Farkas wrote:

  Mr Wolf,
 
 Heh, you noticed :)
 
   Currently (cpu_idle_hlt=1) the load is fluctuating between 2.20 and 3.60
   every few minutes! (xload looks like a graph of a sinewave)
  
   If I set cpu_idle_hlt back to 0 the load goes back to a steady 3.80 where
   it should be.
 
  define should.
 
 When all 3 seti's get their normal 95% cpu time:

the change MAY do what you want but it 'may not'

you'll need to try it to see.. :-/


 
 32531 setiathome 139   15 16536K 15520K *Giant 1  60.9H 95.85% 95.85% setiathome
 32533 setiathome 139   15 16856K 16032K CPU3   3  61.0H 95.65% 95.65% setiathome
 32532 setiathome 139   15 15524K 14912K CPU2   2  60.8H 95.51% 95.51% setiathome
 54738 andyf  1320  3084K  2140K *Giant 0  64:54 83.84% 83.84% ssh
12 root   -160 0K12K RUN2 133.4H  3.81%  3.81% idle: cpu2
13 root   -160 0K12K RUN1 131.7H  3.47%  3.47% idle: cpu1
14 root   -160 0K12K CPU0   0 130.8H  3.37%  3.37% idle: cpu0
11 root   -160 0K12K RUN3 135.2H  2.88%  2.88% idle: cpu3
 
 As opposed to abnormal when cpu_idle_hlt=1:
 
 32533 setiathome 139   15 15828K 15000K CPU1   2  61.0H 89.40% 89.40% setiathome
 32532 setiathome 139   15 16552K 15660K *Giant 2  60.8H 88.18% 88.18% setiathome
 54738 andyf  1300  3084K  2140K select 2  68:54 75.78% 75.78% ssh
13 root   -160 0K12K RUN1 131.7H 29.05% 29.05% idle: cpu1
12 root   -160 0K12K CPU2   2 133.4H 28.08% 28.08% idle: cpu2
11 root   -160 0K12K CPU3   3 135.2H 27.83% 27.83% idle: cpu3
14 root   -160 0K12K RUN0 130.8H 26.37% 26.37% idle: cpu0
 32531 setiathome 131   15 15640K 14976K *Giant 2  61.0H 20.51% 20.51% setiathome
 
 
 --
 
  :{ [EMAIL PROTECTED]
 
 Andy Farkas
 System Administrator
Speednet Communications
  http://www.speednet.com.au/
 
 
 
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on i386/i386

[Peter Wemm]

Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= wrote:
 Peter Wemm [EMAIL PROTECTED] writes:
  Hmm. I thought it was gzip that was dying. Looks like its make instead, a=
 nd
  is rather consistent.
 
 told you so
 
  So, who has been messing with make(1) lately?
 
 I believe that the problem is in the kernel, not in make(1); it just
 happens to be triggered by make(1) because it is a big (if not the
 biggest) vfork(2) consumer.

For a minute I had a horrible thought that it might have been a consequence
of the lazy switch stuff.  But the kernel on cueball predates the turn-on
and doesn't have the options enabled.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Does linux-sun-jdk_1.4.2 work?

[Adam Migus]

Adam said:
 On Mon, 2003-07-21 at 08:55, Yamada Ken Takeshi wrote:
   I have the followinacquirer and cannot compile jdk14
 on FreeBSD-current, July 20th. cvsup'ed with the
 latest
 linux_base.

   Is is unique to me alone?

 tyd3# /usr/local/linux-sun-jdk1.4.2/bin/java -version
 #
 # HotSpot Virtual Machine Error, Internal Error
 # Please report this error at
 # http://java.sun.com/cgi-bin/bugreport.cgi
 #
 # Java VM: Java HotSpot(TM) Client VM (1.4.2-b28
 mixed mode)
 #
 # Error ID: 4F533F4C494E55580E43505001C9
 #

 Heap at VM Abort:
 Heap

 It happens to me too. Looks like this port was released
 too quickly.
 Java on FreeBSD is always a bit dodgy, it seems.

 --
 Adam [EMAIL PROTECTED]


Actually it's trying to aquire a lock on a file in the
linux proc filesystem which is most likely failing
because you have the Linux proc file system mounted
read-only.  Try mounting it read-write...
Hm...

[EMAIL PROTECTED]:ttyp0:amigus$ grep -ci [EMAIL PROTECTED]
/src/freebsd/ports/INDEX
0
[EMAIL PROTECTED]:ttyp0:amigus$

Perhaps you should try writing a port yourself before
you judge others on whether or not their ports are
released too early or not.
When you get your foot out of your mouth also try using
your full name in your email address too so people can
use it when calling you a pompous ass.  I wouldn't want
people getting us confused...

Regards,
--
Adam Migus - Research Scientist
Network Associates Laboratories (http://www.nailabs.com)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Stop in /usr/src/sys/modules/harp

[Xaos]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I keep getting this error when compiling a freshly cvsup'd source. 5.1-Current

/usr/src/sys/dev/harp/if_harp.c:128: `VENDAPI_FORE_2' undeclared here (not in 
a function)
/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for 
`map_devs[2].api')
/usr/src/sys/dev/harp/if_harp.c:128: `DEV_FORE_HE155' undeclared here (not in 
a function)
/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for 
`map_devs[2].dev')
/usr/src/sys/dev/harp/if_harp.c:128: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:128: (near initialization for 
`map_devs[2]')
/usr/src/sys/dev/harp/if_harp.c:130: `VENDAPI_FORE_2' undeclared here (not in 
a function)
/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for 
`map_devs[3].api')
/usr/src/sys/dev/harp/if_harp.c:130: `DEV_FORE_HE622' undeclared here (not in 
a function)
/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for 
`map_devs[3].dev')
/usr/src/sys/dev/harp/if_harp.c:130: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:130: (near initialization for 
`map_devs[3]')
/usr/src/sys/dev/harp/if_harp.c:132: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:132: (near initialization for 
`map_devs[4]')
/usr/src/sys/dev/harp/if_harp.c:134: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:134: (near initialization for 
`map_devs[5]')
/usr/src/sys/dev/harp/if_harp.c:136: `DEV_FORE_LE25' undeclared here (not in a 
function)
/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for 
`map_devs[6].dev')
/usr/src/sys/dev/harp/if_harp.c:136: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:136: (near initialization for 
`map_devs[6]')
/usr/src/sys/dev/harp/if_harp.c:138: `DEV_FORE_LE155' undeclared here (not in 
a function)
/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for 
`map_devs[7].dev')
/usr/src/sys/dev/harp/if_harp.c:138: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:138: (near initialization for 
`map_devs[7]')
/usr/src/sys/dev/harp/if_harp.c:140: `DEV_IDT_25' undeclared here (not in a 
function)
/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for 
`map_devs[8].dev')
/usr/src/sys/dev/harp/if_harp.c:140: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:140: (near initialization for 
`map_devs[8]')
/usr/src/sys/dev/harp/if_harp.c:142: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:142: (near initialization for 
`map_devs[9]')
/usr/src/sys/dev/harp/if_harp.c:144: `VENDAPI_IDT_2' undeclared here (not in a 
function)
/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for 
`map_devs[10].api')
/usr/src/sys/dev/harp/if_harp.c:144: `DEV_IDTABR_25' undeclared here (not in a 
function)
/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for 
`map_devs[10].dev')
/usr/src/sys/dev/harp/if_harp.c:144: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:144: (near initialization for 
`map_devs[10]')
/usr/src/sys/dev/harp/if_harp.c:146: `VENDAPI_IDT_2' undeclared here (not in a 
function)
/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for 
`map_devs[11].api')
/usr/src/sys/dev/harp/if_harp.c:146: `DEV_IDTABR_155' undeclared here (not in 
a function)
/usr/src/sys/dev/harp/if_harp.c:146: initializer element is not 
constant/usr/src/sys/dev/harp/if_harp.c:146: (near initialization for 
`map_devs

- -Tom
- -- 
Death is merciful, for there is no return 
therefrom, but with him who has come back
out of the nethermost chambers of night,
haggard and knowing, peace rests nevermore
- -Lovecraft
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/HKwQ4yFLRHBUZMwRAtAKAKC+DXMotlpa/s7c5R50WfvFneQ/HQCgkH9e
w/az+o+YtNHT95L9apqLPq8=
=Kewt
-END PGP SIGNATURE-

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Does linux-sun-jdk_1.4.2 work?

[Adam]

On Mon, 2003-07-21 at 22:35, Adam Migus wrote:
 Perhaps you should try writing a port yourself before
 you judge others on whether or not their ports are
 released too early or not.
 When you get your foot out of your mouth also try using
 your full name in your email address too so people can
 use it when calling you a pompous ass.  I wouldn't want
 people getting us confused...

Eh, there's no need to flaming here. I never said maintaining Java on
FreeBSD was easy. I said that Java support on FreeBSD is dodgy, which is
really a well-known public fact, for anyone that's ever done any reading
on the subject. In fact, when the core developers give a public
interview, this is frequently a topic of discussion. 

Perhaps you should try working with Java 1.4.x on FreeBSD before you
assume something about me that's highly inaccurate. I think you'll find
very quickly that it doesn't work nicely unless the process is running
as root. 

-- 
Adam [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

any one running a rtl8201 phy tranceiver nic

[Eriq Lamar]

If so could some one point me in the right direction for the right driver. thx

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

[-CURRENT tinderbox] failure on alpha/alpha

[Tinderbox]

TB --- 2003-07-22 04:00:01 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-07-22 04:00:01 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-07-22 04:02:19 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 stage 1: bootstrap tools
 stage 2: cleaning up the object tree
 stage 2: rebuilding the object tree
 stage 2: build tools
 stage 3: cross tools
 stage 4: populating 
 /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
TB --- 2003-07-22 05:06:23 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Tue Jul 22 05:06:24 GMT 2003
[...]
awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/alpha/clock_if.m -h
awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/pci/alphapci_if.m -h
awk -f /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/tools/makeobjops.awk 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/dec/mcclock_if.m -h
if [ -f .olddep ]; then mv .olddep .depend; fi
rm -f .newdep
/home/des/tinderbox/CURRENT/alpha/alpha/obj/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/make.i386/make
 -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES |  MKDEP_CPP=cc -E CC=cc 
xargs mkdep -a -f .newdep -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common  -mno-fp-regs -ffixed-8 -Wa,-mev6 
-ffreestanding
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/eisa/eisaconf.c:34:22: 
opt_eisa.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC.
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
TB --- 2003-07-22 05:07:21 - /usr/bin/make returned exit code  1 
TB --- 2003-07-22 05:07:21 - ERROR: failed to build generic kernel
TB --- 2003-07-22 05:07:21 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]