Re: Linux JDK 1.3 and hotspot (native threads)

[Georg-W. Koltermann]

At Mon, 30 Apr 2001 11:59:38 +0200,
Georg-W. Koltermann <[EMAIL PROTECTED]> wrote:
> 
> On Fri, Apr 27, 2001 at 09:32:58PM -0400, Andrew Gallatin wrote:
> > 
> > Georg-W. Koltermann writes:
> > 
> > <...>
> >  > In order to get real performance I would like to run either the SUN
> >  > JDK with -hotspot, or the IBM 1.3 JVM.  Both of these use native linux
> >  > threads.  With a recent -current I can successfully execute small JAVA
> >  > test programs, but when I start a real application (e.g. Together from
> >  > togethersoft.com), it fails with a core dump.
> > 
> > <...>
> > Also, are there any non commercial apps that demonstrate the problem?
> > Or at least things that I don't have to sign my life away to get
> > access to?

Hi Andrew,

I just tried Forte for Java 3.0 Early Access, and it shows the above
problem quite easily during startup.  I ran it with truss(1), and the
last part of the output is:

linux_kill(0x15bc,0x20)  = 2 (0x2)
linux_brk(0x8232000) = 1 (0x1)
linux_rt_sigprocmask(0x2,0x0,0xbfbfc73c,0x8) = 4 (0x4)
write(4,0xbfbfc728,148)  = 3 (0x3)
linux_rt_sigprocmask(0x2,0x0,0xbfbfc6a8,0x8) = 4 (0x4)
SIGNAL 32
SIGNAL 32
SIGNAL 32
linux_rt_sigsuspend(0xbfbfc6a8,0x8)  ERR#4 'Interrupted system call'
linux_sigreturn(0xbfbfc3a0)  ERR#4 'Interrupted system call'
linux_sched_getscheduler(0x15c2) ERR#1 'Operation not permitted'
linux_kill(0x15c2,0x20)  = 2 (0x2)
linux_kill(0x15c2,0x20)  = 2 (0x2)
getpid() = 0 (0x0)
linux_mmap(0xbfbfc9bc)   = 1 (0x1)
mprotect(0xbfa0e000,0x2000,0x0)  = 3 (0x3)
linux_mmap(0xbfbfc9bc)   = 1 (0x1)
linux_sigaltstack(0xbfbfc9f8,0x0)= 2 (0x2)
-- System info 
linux_rt_sigprocmask(0x1,0xbfbfc968,0x0,0x8) = 4 (0x4)
linux_sched_getscheduler(0x15b9) ERR#1 'Operation not permitted'
  Product Version   = Forte for Java, CE v. 3.0 (Build 010523)
  IDE Versioning= IDE/1 spec=1.2.1 impl=010523
  Operating System  = Linux version 2.2.12 running on i386
  Java; VM; Vendor  = 1.3.1; Java HotSpot(TM) Client VM 1.3.1-b24; Sun 
Microsystems Inc.
  Java Home = /opt/jdk1.3.1/jre
  System Locale = en_US (f4j_ce)
  Home Dir; Current Dir = /home/hunter/gwk; /home/hunter/gwk
  IDE Install; User Dir = /opt/forte30; /home/hunter/gwk/ffjuser30
  CLASSPATH = 
/opt/forte30/lib/patches/openide-compat.jar:/opt/forte30/lib/ext/bsh-1_0-fj.jar:/opt/forte30/lib/ext/cmd.jar:/opt/forte30/lib/ext/cosnaming.jar:/opt/forte30/lib/ext/dd2beans.jar:/opt/forte30/lib/ext/ddl.jar:/opt/forte30/lib/ext/fjscript.jar:/opt/forte30/lib/ext/fscontext.jar:/opt/forte30/lib/ext/idlcompilers.jar:/opt/forte30/lib/ext/jaas.jar:/opt/forte30/lib/ext/jaxp.jar:/opt/forte30/lib/ext/jh.jar:/opt/forte30/lib/ext/jndi.jar:/opt/forte30/lib/ext/ldap.jar:/opt/forte30/lib/ext/ldapbp.jar:/opt/forte30/lib/ext/logger.jar:/opt/forte30/lib/ext/nis.jar:/opt/forte30/lib/ext/openorb-1.0.2.jar:/opt/forte30/lib/ext/oracle.jar:/opt/forte30/lib/ext/parser.jar:/opt/forte30/lib/ext/pbembeddedeval.jar:/opt/forte30/lib/ext/providerutil.jar:/opt/forte30/lib/ext/regexp.jar:/opt/forte30/lib/ext/rmi-ext.jar:/opt/forte30/lib/ext/rmiregistry.jar:/opt/forte30/lib/ext/sax2.jar:/opt/forte30/lib/ext/servlet.jar:/opt/forte30/lib/ext/xerces.jar:/opt/forte30/lib/ext/jdbc20x.zip:/opt/forte30/lib/locale/core_f4j.jar:/opt/forte30/lib/locale/core_f4j_ce.jar:/opt/forte30/lib/locale/openide_f4j.jar:/opt/forte30/lib/core.jar:/opt/forte30/lib/openide-fs.jar:/opt/forte30/lib/openide-nodes.jar:/opt/forte30/lib/openide-util.jar:/opt/forte30/lib/openide.jar:/opt/jdk1.3.1/lib/dt.jar:/opt/jdk1.3.1/lib/htmlconverter.jar:/opt/jdk1.3.1/lib/tools.jar
---
linux_rt_sigprocmask(0x2,0x0,0xbfbfc9cc,0x8) = 4 (0x4)

Unexpected Signal : 11 occurred at PC=0x806535a
Function name=(N/A)
Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error
  just occurred. Please refer to release documentation for possible
  reason and solutions.



Current Java thread:

Dynamic libraries:
Can not get information for pid = 5570

Local Time = Fri Jun  8 23:14:38 2001
Elapsed Time = 2
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002CC
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.3.1-b24 mixed mode)
#
# An error report file has been saved as hs_err_pid5570.lo

MVB

[MVB]

ÂÛ ÇÍÀÅÒÅ  ×ÒΠ ÒÀÊÎÅ 
ÃÐÈÍÌÅÉË ?
ÝÒΠ ÀÊÖÈÎÍÅÐÍÛÉ  ØÀÍÒÀÆ, ÀÃÐÅÑÑÈÂÍÎÅ
ÏÎÃËÎÙÅÍÈÅ ÏÐÅÄÏÐÈßÒÈÉ, ÏÅÐÅÕÂÀÒ
ÓÏÐÀÂËÅÍÈß  ÀÎ, ÑÀÁÎÒÀÆ ÐÀÁÎÒÛ
ÏÐÅÄÏÐÈßÒÈß, ÓÑÒÐÀÍÅÍÈÅ ÊÎÍÊÓÐÅÍÒÎÂ È
ÌÍÎÃÎÅ ÄÐÓÃÎÅ, ÍÎ ÇÀÌÅÒÜÒÅ, ÊÀÊ ÍÅ
ÏÀÐÀÄÎÊÑÀËÜÍÎ, ÂѨ  ÐÀÌÊÀÕ ÇÀÊÎÍÀ!
Åñëè åù¸ 5-10 ëåò íàçàä ÿâëåíèå
ãðèíìåéëà áûëî ïðåðîãàòèâîé çàïàäíîé
ýêîíîìèêè, òî ñåé÷àñ ìîæíî óòâåðæäàòü, ÷òî
ðîññèéñêèé ãðèíìåéë óæå âñòàë íà íîãè (ïðèíöèï
ñîçäàíèÿ èìïåðèè "Ðóññêèé Àëþìèíèé"),
õîòÿ â íàøåé ñòðàíå ïðèñóòñòâóåò è
ãîñóäàðñòâåííûé ãðèíìåéë (ÍÒÂ).
Âû õîòèòå çíàòü îá ýòîì áîëüøå ? Õîòèòå
çíàòü, êàê îòáèðàþòñÿ ïðåäïðèÿòèÿ,
íåîæèäàííî ìåíÿåòñÿ ðóêîâîäñòâî  ÀÎ, êàê
äåëàþòñÿ ïðåäëîæåíèÿ "îò êîòîðûõ íåëüçÿ
îòêàçàòüñÿ", êàê áîãàòûå ñòàíîâÿòñÿ
áåäíûìè è êàê çàùèòèòñÿ îò íåäðóæåñòâåííûõ
äåéñòâèé, òîãäà Âàì íåîáõîäèìî çíàòü, ÷òî 3
èþíÿ îòêðûëñÿ ôîðóì "ÀÊÖÈÎÍÅÐÍÛÅ ÂÎÉÍÛ",
ïîñâÿù¸ííûé òåìàòèêå ãðèíìåéëà íà ñàéòå
ÈÍÂÅÑÒÈÖÈÎÍÍÛÅ ÐÅÑÓÐÑÛ www.mvb.ru
. Íà ôîðóìå Âû ìîæåòå ïîëó÷èòü áåñïëàòíûå
êîíñóëüòàöèè îò þðèñòîâ,
ñïåöèàëèçèðóþùèõñÿ íà ãðèíìåéëå.
 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

NEVERMIND: strangeness in recent current

[Benjamin P. Grubin]

Brain fart on my end.  Sorry for wasted bandwidth.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Benjamin P.
> Grubin
> Sent: Saturday, June 09, 2001 12:24 AM
> To: [EMAIL PROTECTED]
> Subject: strangeness in recent current
> 
> 
> Folks,
> 
> I checked the commits and the recent list mail, but there's 
> no hint as to
> why a recent world (supped earlier this evening) would have 
> had this happen.
> It seems when I attempt to execute non-native binaries (such as linux
> binaries: netscape, etc) I am seeing complaints like the following:
> 
> ELF binary type "3" not known
> Abort trap
> 
> The same happens when I attempt to execute "linux" and load 
> the linux compat
> module.  Rebranding didn't fix it.  Don't know the compat 
> system well enough
> to know where to look next.
> 
> Little help?  =)
> 
> Cheers,
> Ben
> 
> 
> Benjamin P. Grubin  [EMAIL PROTECTED]
> PGP Fingerprint: EDE9 A88F 3BCC 514A  F310 FEFB 7109 2380
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 
> 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

strangeness in recent current

[Benjamin P. Grubin]

Folks,

I checked the commits and the recent list mail, but there's no hint as to
why a recent world (supped earlier this evening) would have had this happen.
It seems when I attempt to execute non-native binaries (such as linux
binaries: netscape, etc) I am seeing complaints like the following:

ELF binary type "3" not known
Abort trap

The same happens when I attempt to execute "linux" and load the linux compat
module.  Rebranding didn't fix it.  Don't know the compat system well enough
to know where to look next.

Little help?  =)

Cheers,
Ben


Benjamin P. Grubin  [EMAIL PROTECTED]
PGP Fingerprint: EDE9 A88F 3BCC 514A  F310 FEFB 7109 2380


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PCCARD and -current

[Julian Elischer]

So the question remains..
where was I supposed to change the interrupt mentionned in the 
UPDATING entry..
if not in the pccard.conf, then where?

I certainly get the 'hangs' mentionned as being a symptom
of NOT doing it..

Warner?

On Fri, 8 Jun 2001, Mike Smith wrote:

> > On Fri, Jun 08, 2001 at 11:19:10AM -0700, Julian Elischer wrote:
> > > kernel: pcic1:  irq 11 at device 4.1 on pci0
> > 
> > > in pccard.conf I had
> > > 
> > > irq 11
> > > 
> > > is this not what I was supposed to do?
> > 
> > Sorry, I guess maybe this directive is counter-intuative. It supposed to
> > be a list of the free irq's in the system for pccardd to use with
> > inserted pccards when configuring them. Trying to use the irq that the
> > cardbus bridge already has will definetly result in a resource
> > allocation failure.
> 
> Er, well, it shouldn't, and more to the point, in most modern laptops you 
> *have* to share the two.
> -- 
> ... every activity meets with opposition, everyone who acts has his
> rivals and unfortunately opponents also.  But not because people want
> to be opponents, rather because the tasks and relationships force
> people to take different points of view.  [Dr. Fritz Todt]
>V I C T O R Y   N O T   V E N G E A N C E
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PCCARD and -current

[Mike Smith]

> On Fri, Jun 08, 2001 at 11:19:10AM -0700, Julian Elischer wrote:
> > kernel: pcic1:  irq 11 at device 4.1 on pci0
> 
> > in pccard.conf I had
> > 
> > irq 11
> > 
> > is this not what I was supposed to do?
> 
> Sorry, I guess maybe this directive is counter-intuative. It supposed to
> be a list of the free irq's in the system for pccardd to use with
> inserted pccards when configuring them. Trying to use the irq that the
> cardbus bridge already has will definetly result in a resource
> allocation failure.

Er, well, it shouldn't, and more to the point, in most modern laptops you 
*have* to share the two.
-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Problems booting recent -current

[Tony Fleisher]

After blowing away my obj/ and src/ directories and
getting them fresh, this problem was no longer 
present... not sure what caused them, but either
I had something strange in my obj/ or src/ tree,
or the problem was fixed in the last week.

Regards,

Tony.

On Mon, 4 Jun 2001, John Baldwin wrote:

> 
> On 03-Jun-01 Tony Fleisher wrote:
> > I just tried to boot a -current kernel cvsupped 
> > at Sat Jun  2 14:11:35 PDT 2001, and was thrown
> > the following error trying to boot to single-user
> > (transcribed by hand):
> > 
> > src/sys/kern/kern_sync.c:385 sleeping with "eventhandler" 
> > locked from src/sys/kern/subr_eventhandler:159
> 
> It would be helpful to know what eventhandler was being fired perhaps..
> 
> > acquiring duplicate lock of same type: "allproc"
> >  1st @ /usr/local/src/freebsd/src/sys/kern/kern_proc.c:584
> >  2nd @ /usr/local/src/freebsd/src/sys/kern/kern_proc.c:143
> 
> This is older than June 2.  Is this from your old kernel?
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: anyone seen these outside of alpha? or on non-SMP?

[Tor . Egge]

> Why can't a filesystem hacker back it out until his return?  Things are
> not getting better and this is tripping up more and more people.

The enclosed patch might help somewhat against the "active pagedep"
panics introduced in revision 1.98 of ffs_softdep.c.  Instead of a
panic, a message is printed and the pagedep structure isn't freed (it
will be freed later by free_newdirblk()).

- Tor Egge



Index: sys/ufs/ffs/ffs_softdep.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v
retrieving revision 1.98
diff -u -r1.98 ffs_softdep.c
--- sys/ufs/ffs/ffs_softdep.c   2001/06/05 01:49:37 1.98
+++ sys/ufs/ffs/ffs_softdep.c   2001/06/07 18:30:16
@@ -1932,14 +1932,16 @@
WORKLIST_INSERT(&inodedep->id_bufwait,
&dirrem->dm_list);
}
+   
+   WORKLIST_REMOVE(&pagedep->pd_list);
if ((pagedep->pd_state & NEWBLOCK) != 0) {
-   FREE_LOCK(&lk);
-   panic("deallocate_dependencies: "
- "active pagedep");
+   /* XXX: Wait for newdirblk to be freed */
+   printf("deallocate_dependencies: "
+  "active pagedep\n");
+   } else {
+   LIST_REMOVE(pagedep, pd_hash);
+   WORKITEM_FREE(pagedep, D_PAGEDEP);
}
-   WORKLIST_REMOVE(&pagedep->pd_list);
-   LIST_REMOVE(pagedep, pd_hash);
-   WORKITEM_FREE(pagedep, D_PAGEDEP);
continue;
 
case D_ALLOCINDIR:

Re: pthread and write()

[Jason Evans]

On Thu, Jun 07, 2001 at 09:33:22PM +1000, Idea Receiver wrote:
> 
> I dont know if this is cause by -current, I have not yet try on the
> -stable. However, I just write here, maybe someone can help me.. :P
> 
> recently, I wrote a multithread network server for my work. what it does
> is to accept TCP connection from remote, and then put it into a new
> thread. I have wrote a simulation client to test this application i
> wrote. The simulation client will keep opening multi connection to the
> server, and keep sent a 8byte structure to server using loop and
> sleep(1) in between each write(). Also each of the thread created by
> server will simply reply a 8byte structure to its client (using
> write() again).
> 
> When the client bring up "enough" (between 300-1000) connection to
> the server, then the server will core dump around 30mis to 1hr time.
> After I trace the problem, I found it is cause by write() with signal
> 11. then i use gdb to trace out the problem. follow is what i get from
> gdb:
>  
>Program received signal SIGSEGV, Segmentation fault.
>0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4
> 
> can anyone plz help with this problem? is there anything important I
> missed?

This probably isn't enough information to be able to diagnose the problem
(which may very well be in your application).  Please provide an example
program that exhibits the behavior.

Thanks,
Jason

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PCCARD and -current

[Seth Kingsley]

On Fri, Jun 08, 2001 at 01:55:40PM -0700, Seth Kingsley wrote:
> On Fri, Jun 08, 2001 at 11:19:10AM -0700, Julian Elischer wrote:
> > kernel: pcic1:  irq 11 at device 4.1 on pci0
> 
> > in pccard.conf I had
> > 
> > irq 11
> > 
> > is this not what I was supposed to do?
> 
> Sorry, I guess maybe this directive is counter-intuative. It supposed to
> be a list of the free irq's in the system for pccardd to use with
> inserted pccards when configuring them. Trying to use the irq that the
> cardbus bridge already has will definetly result in a resource
> allocation failure.

Oops! I didn't even read the UPDATING line even. I withdraw all of my
comments.

-- 
|| Seth Kingsley || Platforms Lab Opps || [EMAIL PROTECTED] ||

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: PCCARD and -current

[Seth Kingsley]

On Fri, Jun 08, 2001 at 11:19:10AM -0700, Julian Elischer wrote:
> kernel: pcic1:  irq 11 at device 4.1 on pci0

> in pccard.conf I had
> 
> irq 11
> 
> is this not what I was supposed to do?

Sorry, I guess maybe this directive is counter-intuative. It supposed to
be a list of the free irq's in the system for pccardd to use with
inserted pccards when configuring them. Trying to use the irq that the
cardbus bridge already has will definetly result in a resource
allocation failure.

-- 
|| Seth Kingsley || Platforms Lab Opps || [EMAIL PROTECTED] ||

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Switching to RELEASE

[User Tomdean]

I started tracking -current about 5 years ago.  It was interesting.  I
learned a lot.  I did a few "fox paws" and saw a few.  Maybe I helped
a time or two in testing and reporting.

My last world was two or three months ago.  The one before that was
similar.  I am not tracking so I should be with RELEASE.  Maybe I
should always have been there.

I had only one or two suprise outages in all that time.  That speaks
lots for the quality of the developers, maintainers, orgainzers and
everyone involved.

I installed 4.3-RELEASE from the CD on a new disk, no problem, little
effort.  Great!

Thank you for your efforts, support and understanding.

tomdean

( I am off the list - traveling )

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

PCCARD and -current

[Julian Elischer]

I upgraded to last nights's -current.
UPGRADING said:
20010604:
pccard support for pci cards has been committed.  You must change
your /etc/pccard.conf irq lines.  It must match the irq used by
pcic device.  Interrupt storms may result if you fail to do this.
Interrupt storms look a lot like a hang.


dmesg says:

kernel: pci_cfgintr_unique: hard-routed to irq 11
kernel: pci_cfgintr: 0:4 INTA routed to irq 11
kernel: pcic0:  irq 11 at device 4.0 on pci0
kernel: pcic0: PCI Memory allocated: 0x4400
kernel: pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr
save][pci only]
kernel: pccard0:  on pcic0
kernel: pci_cfgintr_unique: hard-routed to irq 11
kernel: pci_cfgintr: 0:4 INTA routed to irq 11
kernel: pcic1:  irq 11 at device 4.1 on pci0
kernel: pcic1: PCI Memory allocated: 0x44001000
kernel: pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr
save][pci only]
kernel: pccard1:  on pcic1


but:
 Card "Linksys"("EtherFast 10/100 PC Card (PCMPC100)") [] [(null)] matched
"Linksys" ("/Ether[Ff]ast 10/100 PC Card \(PCMPC100.*\)/") [(null)] [(null
)]
 Failed to allocate IRQ for Linksys
 pccardd started

in pccard.conf I had

irq 11

is this not what I was supposed to do?

what do I need to get my ethernet card working again?


-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  Presently in San Francisco, CA 
v




config file follows:



machine i386
cpu I686_CPU
ident   NMDM
maxusers32

#To statically compile in device wiring instead of /boot/device.hints
#hints  "GENERIC.hints" #Default places to look for devices.

makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols


options MATH_EMULATE
options INET#InterNETworking
options FFS #Berkeley Fast Filesystem
options SOFTUPDATES #Enable FFS soft updates support
options NFS #Network Filesystem
options MSDOSFS #MSDOS Filesystem
options CD9660  #ISO 9660 Filesystem
#optionsDEVFS   #Device Filesystem
options PROCFS  #Process filesystem
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE#Allow users to grab the console
options USERCONFIG  #boot -c editor
options VISUAL_USERCONFIG   #visual boot -c editor
options KTRACE  #ktrace(1) support
options P1003_1B#Posix P1003_1B real-time extensions
options _KPOSIX_PRIORITY_SCHEDULING
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options DDB

# To make an SMP kernel, the next two are needed

device  isa
device  pci

# parallel port
device  ppc
device  ppbus
device  lpt

# Floppy drives
device  fdc

# ATA and ATAPI devices
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   #Static device numbering

 

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # At keyboard controller
device  atkbd   # at keyboard
device  psm # psm mouse

device  vga # VGA screen

# syscons is the default console driver, resembling an SCO console
device  sc

# Floating point support - do not disable.
device  npx

# Power management support (see NOTES for more options) 
device  apm
# Add suspend/resume support for the i8254.
device  pmtimer

# Audio support
device  pcm

# PCCARD (PCMCIA) support
device  card# pccard bus
device  pcic# PCMCIA bridge

# Serial (COM) ports
device  sio # 8250, 16[45]50 based serial ports

# Parallel port


# ISA Ethernet NICs.  pccard nics included.
device  miibus  # MII bus support
device  ed  # NE[12]000, SMC Ultra, 3c503, DS8390 cards



# Pseudo devices - the number indicates how many units to allocated.
device  random  # Entropy device
device  loop# Network loopback
device  ether   # Ethernet support
device  tun # Packet tunnel.
device  pty # Pseudo-ttys (telnet etc)
device  md  # Memory "disks"

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
device  bpf # Berkeley packet filter

device nmdm  # back-to-back ttys (like pty but both ends are ttys)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with

Re: Unrecognised CBCP packet [strange problems with ppp(8)]

[Brian Somers]

> Brian Somers wrote:
> 
> > I've had reports of this in the past.  The other end is sending a
> > ``code 5'' packet - something that doesn't appear in the spec :(
> >
> > ppp(8) just ignores these (emitting a warning), they shouldn't be
> > causing any problems themselves (even if CBCP is actually being used).
> >
> > Try enabling IPCP logging.  You may be having a problem at that
> > level, or alternatively, perhaps the peer thinks you've already got a
> > connection and is (rudely) dropping the connection because of that.
> 
> Attached please find relevant log. I could add that now the problem became even
> more frequent, so I would appreciate any help.
> 
> Thank you!
> 
> -Maxim
[.]
> Phase: Pap Output: sobomax1 
[.]
> Phase: Pap Input: SUCCESS ()

So authentication is ok.

[.]
> IPCP: deflink: LayerUp.
> IPCP: myaddr 212.35.189.239 hisaddr = 212.35.189.18

The IP layer is up.

[.]
> IPCP: deflink: RecvTerminateReq(3) state = Opened
> IPCP: deflink: LayerDown: 212.35.189.239
[.]

And the peer closes the connection.

To be honest, I have no idea what's going on here.  It doesn't even 
look as if you sent any data.  I think you may have to ask your ISP 
why they're closing the connection :/
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unrecognised CBCP packet [strange problems with ppp(8)]

[Maxim Sobolev]

Brian Somers wrote:

> I've had reports of this in the past.  The other end is sending a
> ``code 5'' packet - something that doesn't appear in the spec :(
>
> ppp(8) just ignores these (emitting a warning), they shouldn't be
> causing any problems themselves (even if CBCP is actually being used).
>
> Try enabling IPCP logging.  You may be having a problem at that
> level, or alternatively, perhaps the peer thinks you've already got a
> connection and is (rudely) dropping the connection because of that.

Attached please find relevant log. I could add that now the problem became even
more frequent, so I would appreciate any help.

Thank you!

-Maxim

> > Hi,
> >
> > I'm having strange problems with one of local dial-up providers: without
> > any visible reasons from time to time I can't establish PPP connection
> > during 20-30 minutes. Shortly after going into `Network' mode ppp(8)
> > complains about `Unrecognised CBCP packet' and drops down line.
> > Restarting ppp/machine/modem etc. doesn't help and provider's technical
> > people have no idea what could be wrong. Attached please find piece of
> > log, please let me know if any additional information would be necessary.
> >
> > -Maxim
> >
> > Phase: bundle: Authenticate
> > Phase: deflink: his = PAP, mine = none
> > Phase: Pap Output: sobomax1 
> > Ppp ON vega> Phase: Pap Input: SUCCESS ()
> > Phase: deflink: lcp -> open
> > Phase: bundle: Network
> > PPp ON vega> Warning: Unrecognised CBCP packet (code 5, length 4)
> > PPp ON vega> Phase: deflink: open -> lcp
> > Phase: bundle: Terminate
> > ppp ON vega> Phase: deflink: Carrier lost
> > Phase: deflink: Disconnected!
> > Phase: deflink: lcp -> logout
> > Phase: deflink: Disconnected!
> > Phase: deflink: logout -> hangup
> > Phase: deflink: Connect time: 32 secs: 248 octets in, 235 octets out
>
> --
> Brian <[EMAIL PROTECTED]>
>      
> Don't _EVER_ lose your sense of humour !





ppp ON vega> set log local +ipcp +phase +debug

ppp ON vega> dia

Phase: bundle: Establish
Phase: deflink: closed -> opening
Debug: deflink: Opened /dev/cuaa0
Debug: deflink: tty_Create: physical (get): fd = 1, iflag = 0, oflag = 0, cflag = 34b00
Debug: deflink: physical (put): iflag = 201, oflag = 0, cflag = 3cb00
Phase: deflink: Connected!
Phase: deflink: opening -> dial
ppp ON vega> Phase: deflink: dial -> carrier
Debug: deflink: Using tty_Timeout [0x8071f50]
Debug: Waiting for carrier
Debug: Waiting for carrier
Phase: deflink: /dev/cuaa0: CD detected
Phase: deflink: carrier -> login
Debug: deflink: Entering tty_Raw
Phase: deflink: login -> lcp
Debug: deflink: Still online
Debug: fsm_Output
Debug:  01 28 00 18 08 02 07 02 02 06 00 00 00 00 01 04  .(..
Debug:  05 dc 05 06 e3 2d 98 14  .-..
Debug: proto_LayerPush: Using 0xc021
Debug: link_PushPacket: Transmit proto 0xc021
Debug: m_enqueue: len = 1
Debug: m_dequeue: queue len = 1
Debug: link_Dequeue: Dequeued from queue 1, containing 0 more packets
Debug: deflink: DescriptorWrite: wrote 53(53) to 1
Debug: deflink: DescriptorRead: read 34/2048 from 1
Debug: deflink: DescriptorRead: read 77/2048 from 1
Debug: deflink: hdlc_LayerPull: fcs = f0b8 (good)
Debug: proto_LayerPull: unknown -> 0xc021
Debug: link_PullPacket: Despatch proto 0xc021
Debug: fsm_Output
Debug:  02 01 00 1f 01 04 05 f4 02 06 00 00 00 00 03 04  
Debug:  c0 23 07 02 08 02 13 09 03 00 c0 7b 8f 05 53 .#.{..S
Debug: proto_LayerPush: Using 0xc021
Debug: link_PushPacket: Transmit proto 0xc021
Debug: m_enqueue: len = 1
Debug: m_dequeue: queue len = 1
Debug: link_Dequeue: Dequeued from queue 1, containing 0 more packets
Debug: deflink: DescriptorWrite: wrote 65(65) to 1
Debug: deflink: DescriptorRead: read 5/2048 from 1
Debug: deflink: hdlc_LayerPull: fcs = f0b8 (good)
Debug: proto_LayerPull: unknown -> 0xc021
Debug: link_PullPacket: Despatch proto 0xc021
Phase: bundle: Authenticate
Phase: deflink: his = PAP, mine = none
Debug: pap_Req: namelen = 8, keylen = 6
Phase: Pap Output: sobomax1 
Debug: proto_LayerPush: Using 0xc023
Debug: link_PushPacket: Transmit proto 0xc023
Debug: m_enqueue: len = 1
Ppp ON vega> Debug: m_dequeue: queue len = 1
Debug: link_Dequeue: Dequeued from queue 1, containing 0 more packets
Debug: deflink: DescriptorWrite: wrote 26(26) to 1
Debug: deflink: DescriptorRead: read 33/2048 from 1
Debug: deflink: hdlc_LayerPull: fcs = f0b8 (good)
Debug: proto_LayerPull: unknown -> 0xc023
Debug: link_PullPacket: Despatch proto 0xc023
Phase: Pap Input: SUCCESS ()
IPCP: Using trigger address 0.0.0.0
Phase: deflink: lcp -> open
Phase: bundle: Network
IPCP: FSM: Using "deflink" as a transport
IPCP: deflink: State change Initial --> Closed
IPCP: deflink: LayerStart.
IPCP: deflink: SendConfigReq(69) state = Closed
IPCP:  IPADDR[6]  0.0.0.0
Debug: fsm_Output
Debug:  01 45 00 0a 03 06 00 00 00 00.E
Debug: proto_LayerPush: Using 0x8021
Deb

K-6 Laptop running current.

[Edwin Culp]

I sent this to Mobile yesterday and didn't get an answer.  I sure don't
feel good being the only person with this problem, but . . . I've cleaned
and polished my pointy hat.

I updated my world and kernel from a cvsup of May 26 to June 6, including 
a mergemaster run that included a new pccard.conf. and as best I can tell
I jumped right into the interrupt storms and haven't figured out how to 
apply the following from UPDATING

20010604:
pccard support for pci cards has been committed.  You must change
your /etc/pccard.conf irq lines.  It must match the irq used by
pcic device.  Interrupt storms may result if you fail to do this.
Interrupt storms look a lot like a hang.

My pcic device is always on irq 10
pcic-pci0:  irq 10 at device 3.0 on pci0
pcic0 is in polling mode.  Should I assign an irq in my kernel conf? [ haven't
done this yet ]

My pccard.conf is 100% generic and works with my May 26 kernel.
# $FreeBSD: src/etc/defaults/pccard.conf,v 1.186 2001/05/30 21:30:40 imp Exp $

Does the above mean that my IRQ line should change?
>From irq 3 5 10 11 15 to irq   10? [ didn't work ]

or does it mean that I should add IRQ 10 to my wi entry or both?  [ didn't 
work either ]

Thanks for your help and your patience,

ed

---
   The illiterate of the 21st century will not be
 those who cannot read and write,
   but those who cannot learn, unlearn and relearn.
--Alvin Toffler


---
   The illiterate of the 21st century will not be
 those who cannot read and write, 
   but those who cannot learn, unlearn and relearn. 
--Alvin Toffler

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: nsrexecd in FreeBSD current

[Matthew Jacob]

On Fri, 8 Jun 2001, Terry Lambert wrote:

> Matthew Jacob wrote:
> 
> [ ... FreeBSD Legato client coredump ... ]
> 
> > This is really a 'ports' issue...
> 
> No, it's an Advocacy and commercial support of FreeBSD issue.
> 
> 
> > I don't know why this happens. It was suggested that it
> > was probably a bug in nsrexecd- malloc maybe. Possibly.
> > It doesn't always happen, as it's happily running right
> > now on at least one i386 running -current (June 3) and
> > one alpha (June 2)- but don't let the dates spoof you as
> > these systems were fine a month ago as well.
> > 
> > Since all nsrexecd does is open a socket range and start
> > listening so that a remote server can connect and do NSR
> > style authentication, and that nsrexecd has been reported
> > to die right away if it dies at all, one can presume that
> > each instance does just about the same thing.
> 
> A common Linux-derived code bug is that thaey do not
> bzero() the sockaddr_in before starting to fill it out.
> 
> In the BSD case, this results in code that either cores
> immediately, or code which runs intermittently, based
> on local configuration (since that determines how much
> of the first 4k of the stack is scribbled on, instead of
> being left all zero's, as it was on startup, and then
> overlays the sockaddr_in that is the culprit).
> 
> This bug is consistent with the behaviour you are seeing,
> and should probably be reported to the maintainer of the
> code (at Legato).
> 

That maintainer is 'me'. There is no *BSD maintainer at Legato.
I'm pretty sure I got this bug a while back, but I'll check again.


-matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pthread and write()

[Idea Receiver]

> >Program received signal SIGSEGV, Segmentation fault.
> >0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4
> 
> You're not running -current if you're using libc_r.so.4.
> We're at libc_r.so.5.  And fd locks have also been disabled
> in -current.
> 

err~~ sorry about my stupid... i wasnt aware that i run it on the wrong
system

ok.. now i konw it is not working on the -stable :P .. ill give a try on
-current...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

pthread and write()

[Idea Receiver]

I dont know if this is cause by -current, I have not yet try on the
-stable. However, I just write here, maybe someone can help me.. :P

recently, I wrote a multithread network server for my work. what it does
is to accept TCP connection from remote, and then put it into a new
thread. I have wrote a simulation client to test this application i
wrote. The simulation client will keep opening multi connection to the
server, and keep sent a 8byte structure to server using loop and
sleep(1) in between each write(). Also each of the thread created by
server will simply reply a 8byte structure to its client (using
write() again).

When the client bring up "enough" (between 300-1000) connection to
the server, then the server will core dump around 30mis to 1hr time.
After I trace the problem, I found it is cause by write() with signal
11. then i use gdb to trace out the problem. follow is what i get from
gdb:
 
   Program received signal SIGSEGV, Segmentation fault.
   0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4

can anyone plz help with this problem? is there anything important I
missed?

thx!!
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

pthread and write()

[Idea Receiver]

I dont know if this is cause by -current, I have not yet try on the
-stable. However, I just write here, maybe someone can help me.. :P

recently, I wrote a multithread network server for my work. what it does
is to accept TCP connection from remote, and then put it into a new
thread. I have wrote a simulation client to test this application i
wrote. The simulation client will keep opening multi connection to the
server, and keep sent a 8byte structure to server using loop and
sleep(1) in between each write(). Also each of the thread created by
server will simply reply a 8byte structure to its client (using
write() again).

When the client bring up "enough" (between 300-1000) connection to
the server, then the server will core dump around 30mis to 1hr time.
After I trace the problem, I found it is cause by write() with signal
11. then i use gdb to trace out the problem. follow is what i get from
gdb:
 
   Program received signal SIGSEGV, Segmentation fault.
   0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4

can anyone plz help with this problem? is there anything important I
missed?

thx!!
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

pthread and write()

[Idea Receiver]

I dont know if this is cause by -current, I have not yet try on the
-stable. However, I just write here, maybe someone can help me.. :P

recently, I wrote a multithread network server for my work. what it does
is to accept TCP connection from remote, and then put it into a new
thread. I have wrote a simulation client to test this application i
wrote. The simulation client will keep opening multi connection to the
server, and keep sent a 8byte structure to server using loop and
sleep(1) in between each write(). Also each of the thread created by
server will simply reply a 8byte structure to its client (using
write() again).

When the client bring up "enough" (between 300-1000) connection to
the server, then the server will core dump around 30mis to 1hr time.
After I trace the problem, I found it is cause by write() with signal
11. then i use gdb to trace out the problem. follow is what i get from
gdb:
 
   Program received signal SIGSEGV, Segmentation fault.
   0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4

can anyone plz help with this problem? is there anything important I
missed?

thx!!
 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

pthread and write()

[Idea Receiver]

I dont know if this is cause by -current, I have not yet try on the
-stable. However, I just write here, maybe someone can help me.. :P

recently, I wrote a multithread network server for my work. what it does
is to accept TCP connection from remote, and then put it into a new
thread. I have wrote a simulation client to test this application i
wrote. The simulation client will keep opening multi connection to the
server, and keep sent a 8byte structure to server using loop and
sleep(1) in between each write(). Also each of the thread created by
server will simply reply a 8byte structure to its client (using
write() again).

When the client bring up "enough" (between 300-1000) connection to
the server, then the server will core dump around 30mis to 1hr time.
After I trace the problem, I found it is cause by write() with signal
11. then i use gdb to trace out the problem. follow is what i get from
gdb:
 
   Program received signal SIGSEGV, Segmentation fault.
   0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4

can anyone plz help with this problem? is there anything important I
missed?

thx!!
 





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pthread and write()

[Daniel Eischen]

On Fri, 8 Jun 2001, Idea Receiver wrote:
> I dont know if this is cause by -current, I have not yet try on the
> -stable. However, I just write here, maybe someone can help me.. :P
> 
> recently, I wrote a multithread network server for my work. what it does
> is to accept TCP connection from remote, and then put it into a new
> thread. I have wrote a simulation client to test this application i
> wrote. The simulation client will keep opening multi connection to the
> server, and keep sent a 8byte structure to server using loop and
> sleep(1) in between each write(). Also each of the thread created by
> server will simply reply a 8byte structure to its client (using
> write() again).
> 
> When the client bring up "enough" (between 300-1000) connection to
> the server, then the server will core dump around 30mis to 1hr time.
> After I trace the problem, I found it is cause by write() with signal
> 11. then i use gdb to trace out the problem. follow is what i get from
> gdb:
>  
>Program received signal SIGSEGV, Segmentation fault.
>0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4

You're not running -current if you're using libc_r.so.4.
We're at libc_r.so.5.  And fd locks have also been disabled
in -current.

-- 
Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

pthread and write()

[Idea Receiver]

I dont know if this is cause by -current, I have not yet try on the
-stable. However, I just write here, maybe someone can help me.. :P

recently, I wrote a multithread network server for my work. what it does
is to accept TCP connection from remote, and then put it into a new
thread. I have wrote a simulation client to test this application i
wrote. The simulation client will keep opening multi connection to the
server, and keep sent a 8byte structure to server using loop and
sleep(1) in between each write(). Also each of the thread created by
server will simply reply a 8byte structure to its client (using
write() again).

When the client bring up "enough" (between 300-1000) connection to
the server, then the server will core dump around 30mis to 1hr time.
After I trace the problem, I found it is cause by write() with signal
11. then i use gdb to trace out the problem. follow is what i get from
gdb:
 
   Program received signal SIGSEGV, Segmentation fault.
   0x28121637 in _fd_lock_backout () from /usr/lib/libc_r.so.4

can anyone plz help with this problem? is there anything important I
missed?

thx!!
 





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Krb5 problems

[Assar Westerlund]

Gordon Tetlow <[EMAIL PROTECTED]> writes:
> Anyway, I'm able to setup the realm correctly but when I try to run the
> k5admind daemon, it cores whenever I try to connect to it. I'll look into
> building a debug version and try to get some more info on this one.

Do you run the k5admind from inetd or standalone?  Information from
the core dump of a debug version would be useful.

> Another issue I'm having is with trying to get tickets. When I k5init on
> the kdc box, it works fine. But when I try to get my -stable box to get a
> ticket, I keep getting an incorrect password error. Maybe I have my keytab
> setup wrong on my -stable box? (this is possible since I had to manually
> put it on the -stable box).

You should not need any keytab on your client (-stable box) to be able
to run k5init.

> There is also a fair amount of man pages missing. k5admind comes to mind,
> but there are others as well.

Yes, part of the problem is the duality between k5admind and kadmind.
There's a man-page in the source at
src/crypto/heimdal/kadmin/kadmind.8 but it's not installed since it
would have to be changed to k5admind to make sense.  My plan is to
install both the program and man-page as kadmind instead.

/assar

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: nsrexecd in FreeBSD current

[Terry Lambert]

Matthew Jacob wrote:

[ ... FreeBSD Legato client coredump ... ]

> This is really a 'ports' issue...

No, it's an Advocacy and commercial support of FreeBSD issue.


> I don't know why this happens. It was suggested that it
> was probably a bug in nsrexecd- malloc maybe. Possibly.
> It doesn't always happen, as it's happily running right
> now on at least one i386 running -current (June 3) and
> one alpha (June 2)- but don't let the dates spoof you as
> these systems were fine a month ago as well.
> 
> Since all nsrexecd does is open a socket range and start
> listening so that a remote server can connect and do NSR
> style authentication, and that nsrexecd has been reported
> to die right away if it dies at all, one can presume that
> each instance does just about the same thing.

A common Linux-derived code bug is that thaey do not
bzero() the sockaddr_in before starting to fill it out.

In the BSD case, this results in code that either cores
immediately, or code which runs intermittently, based
on local configuration (since that determines how much
of the first 4k of the stack is scribbled on, instead of
being left all zero's, as it was on startup, and then
overlays the sockaddr_in that is the culprit).

This bug is consistent with the behaviour you are seeing,
and should probably be reported to the maintainer of the
code (at Legato).

-- Terry (who has fixed many of these in OpenLDAP, SLPv1,
and other prrograms too numerous to name)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: The FreeBSD core team needs your help

[John Merryweather Cooper]

On 2001.06.08 00:47 Terry Lambert wrote:
> Poul-Henning Kamp wrote:
> > 
> > I think you guys should write a short-and-to-the-point application
> > and send it to the core team.
> 
> Feel free to copy mine, and send it to the core team...
> 
> /* A short and sweet application */
> int
> main()
> {
>   write( 1, "Hello World!\n", 13);
>   return( 0);
> }
> 
> -- Terry
> 

I prefer:

with Ada.Text_IO;   use Ada.Text_IO;

procedure Short_Application is
begin
   Put_Line ("Hello World!");
end Short_Application;

although I can handle other dialects too . . . :)

jmc


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: The FreeBSD core team needs your help

[Terry Lambert]

Poul-Henning Kamp wrote:
> 
> I think you guys should write a short-and-to-the-point application
> and send it to the core team.

Feel free to copy mine, and send it to the core team...

/* A short and sweet application */
int
main()
{
write( 1, "Hello World!\n", 13);
return( 0);
}

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message