KSE MIII kinda-HEADSUP

[Julian Elischer]

After some hacking work with others at USENIX,
KSE MIII is currently running pretty well on i386.
there seems to be a slight issue with alpha and ^Z
but it works fine for i386.  The test machine has not crashed
afer 2+1/2 hours of work at the moment. (not a lot but it's been this
stable for several months whenever I get it merged).

(If others are having crashes in very new -current, let me know)

Certainly if I can get either permission (to break) from those doing other
 architectures or patches for the few lines of assembler needed,
I want to commit tomorrow. (we have a general consensus here to do so)
I am about to stub out all the MD bits there that I can so there should be
minimal code needed for the Sparc-64 and ia64 ports. (and the others).

As soon as the other kernels can be compiled and boot I hope to commit.

See http://www.freebsd.org/~julian/ for more info






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

Re: Crash after world/kernel upgrade

[Jeffrey Hsu]

That looks like a different problem.


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

KSE changes to ps

[Julian Elischer]

So the question is: what information can PS show 
for a KSE threaded process?

I have been thinking of:

Certainly the first thing to decide it WHAT there is to show..
threads that are in userspace are not visible to ps, or for that matter
the kernel, as teh Userland thread scheduler may switch between them
without notifying the kernel. Only threads blocked in the kernel can show
any information other than running For those in the userland there
is only the information in the associated kse , and priority
info from the thread is available.

so for a process you can show:
process stuff (e.g. uid, pid, ppid)
kseg stuff (e.g. nice value, number runnable threads)
kse stuff(e.g. RUNNING @ priority 32 on cpu0)
kse stuff(e.g. RUNNING @ priority 31 on cpu1)   
runnable threads
e.g.
thread runnable priority 33
thread runnable priority 35
thread runnable priority 37
sleeping threads
e.g.
thread waiting at Mutex net1 prio 33
thread sleeping at biord prio 31
kseg stuff (for next kseg)
...
 


anyone have thoughts?



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

Re: KSE changes to ps

[Juli Mallett]

* Julian Elischer [EMAIL PROTECTED] escriurères
 So the question is: what information can PS show 
 for a KSE threaded process?
 
 I have been thinking of:
 
 Certainly the first thing to decide it WHAT there is to show..
 threads that are in userspace are not visible to ps, or for that matter
 the kernel, as teh Userland thread scheduler may switch between them
 without notifying the kernel. Only threads blocked in the kernel can show
 any information other than running For those in the userland there
 is only the information in the associated kse , and priority
 info from the thread is available.
 
 so for a process you can show:
 process stuff (e.g. uid, pid, ppid)

Hopefully this won't change.

 kseg stuff (e.g. nice value, number runnable threads)

Nice value and stuff are exported anyway via kproc_info.

Maybe we should look at packing an export_thread in there for exported kse
interfaces?

 kse stuff(e.g. RUNNING @ priority 32 on cpu0)
 kse stuff(e.g. RUNNING @ priority 31 on cpu1)   
 runnable threads
 e.g.
 thread runnable priority 33
 thread runnable priority 35
 thread runnable priority 37
 sleeping threads
 e.g.
 thread waiting at Mutex net1 prio 33
 thread sleeping at biord prio 31

This all has a simple solution.  Export each thread as a process via kinfo_\
proc, and ps(1) will use the existing mtxname interfaces and such..

I don't know how simple this is at a code level.

 kseg stuff (for next kseg)
 ...
  
 
 
 anyone have thoughts?

It'd be best to be able to poll the userland schedulers and the KSE stuff via
the ptrace(2) interface, I think, or just export things using kinfo_proc and
pad out the struct with things pertinent to KSE's.

Thanks.
-- 
Juli Mallett [EMAIL PROTECTED]  FreeBSD: The Power To Serve
Perception is prejudice / Don't classify me / Accept me as me / Not what you see

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

Re: KSE changes to ps

[Julian Elischer]

On Fri, 14 Jun 2002, Juli Mallett wrote:

 * Julian Elischer [EMAIL PROTECTED] escriurères
  So the question is: what information can PS show 
  for a KSE threaded process?
  
  I have been thinking of:
  
  Certainly the first thing to decide it WHAT there is to show..
  threads that are in userspace are not visible to ps, or for that matter
  the kernel, as teh Userland thread scheduler may switch between them
  without notifying the kernel. Only threads blocked in the kernel can show
  any information other than running For those in the userland there
  is only the information in the associated kse , and priority
  info from the thread is available.
  
  so for a process you can show:
  process stuff (e.g. uid, pid, ppid)
 
 Hopefully this won't change.
 
  kseg stuff (e.g. nice value, number runnable threads)
 
 Nice value and stuff are exported anyway via kproc_info.

kproc_info only has space for one KSEG. it currently gets filled out from
fields in the KSEG and KSE and thread, by assuming that there is only one
of each. It id oblivious to the possibility that there may be  1 thread,
or KSE or KSEG.

We need to work out a new kernel interface to get all this information...
:-)

 
 Maybe we should look at packing an export_thread in there for exported kse
 interfaces?
 
  kse stuff(e.g. RUNNING @ priority 32 on cpu0)
  kse stuff(e.g. RUNNING @ priority 31 on cpu1)   
  runnable threads
  e.g.
  thread runnable priority 33
  thread runnable priority 35
  thread runnable priority 37
  sleeping threads
  e.g.
  thread waiting at Mutex net1 prio 33
  thread sleeping at biord prio 31
 
 This all has a simple solution.  Export each thread as a process via kinfo_\
 proc, and ps(1) will use the existing mtxname interfaces and such..
 

hm that isn't a stupid idea.


 I don't know how simple this is at a code level.
 
  kseg stuff (for next kseg)
  ...
   
  
  
  anyone have thoughts?
 
 It'd be best to be able to poll the userland schedulers and the KSE stuff via
 the ptrace(2) interface, I think, or just export things using kinfo_proc and
 pad out the struct with things pertinent to KSE's.
 
 Thanks.
 -- 
 Juli Mallett [EMAIL PROTECTED]  FreeBSD: The Power To Serve
 Perception is prejudice / Don't classify me / Accept me as me / Not what you see
 


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

Re: KSE changes to ps

[Terry Lambert]

Julian Elischer wrote:
 So the question is: what information can PS show
 for a KSE threaded process?


The same thing ps shows for a threaded process with user space
threads today.

Why confuse every ps-using shell script or perl script ever
written?


 so for a process you can show:
 process stuff (e.g. uid, pid, ppid)
 kseg stuff (e.g. nice value, number runnable threads)
 kse stuff(e.g. RUNNING @ priority 32 on cpu0)
 kse stuff(e.g. RUNNING @ priority 31 on cpu1)

[ ... ]

If you want to show all this stuff, it should be similar to the
-d option I patched into w for SunOS w compatability.

In other words, it should not be shown by default, it should
only show if you use special options to get it.

-- Terry

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

panic: xl0

[Stephan van Beerschoten]

This morning I cvsupped and redid my kernel and world with no
compilation errors whatsoever, which was nice to see again :)

Right now however I have panics with my xl0

Since I cannot copy/paste anything anywhere, I wrote as much info down
as I found to be relevant.

I tried to run the GENERIC kernel too, so the following is based on
that. While booting the following message appears right after the kernel
detects the xl0 interface:
 /usr/src/sys/vm/uma_core.c:1327 Could sleep with xl0 locked from
 /usr/src/sys/pci/if_pci.c:415

The above message also is displayed everytime the ifconfig command is
run on the xl0 interface, even if it is just to display current configs.
It does however boot and detects its mac adress and the media attached
to it.

I had to boot in single because the machine panic'd as soon as the
interface was initialized (with dhcp).

I traced down the following:

As soon as the interface is set to be up the kernel displays:
 Unregistered isr number: 18  - This happends a lot, maybe for every
 packet received by the interface ? (guess)

I can do the following:
# ifconfig xl0 130.x.x.x[enter]

 This works, BUT as soon as I add a netmask (like my net requires):
# ifconfig xl0 130.x.x.x netmask 255.255.254.0 [enter] - panic:

 blockable sleep lock (sleep mutex) process lock @
 /usr/src/sys/i386/trap.c:711

With regards,
 Stephan

-- 
Stephan van Beerschoten [SVB21-RIPE]   [EMAIL PROTECTED]
  PGP fingerprint:  4557 9761 B212 FB4C  778D 3529 C42A 2D27
 To err is human, to forgive is Not Company Policy

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

When was soundcard.h moved?

[Sheldon Hearn]

Hi folks,

When was soundcard.h moved from machine to sys?  A large number of ports
expect to find it in machine, and I can't find a __FreeBSD_version bump
supporting the change.

So I need to find out when it happened and piggy-back on the nearest
__FreeBSD_version bump. :-(

Ciao,
Sheldon.

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

Re: Crash after world/kernel upgrade

[Jeffrey Hsu]

   Jun 14 10:36:08 calvin syslogd: kernel boot file is /boot/kernel/kernel
   Jun 14 10:36:08 calvin kernel: panic: lock (sleep mutex) inp not locked @ 
/usr/src/sys/netinet/tcp_subr.c:1069

Thanks for the bug report, Sid.  This panic should be addressed by the
following commit:

hsu 2002/06/14 01:35:21 PDT

  Modified files:
sys/netinet  in_pcb.c in_pcb.h tcp_subr.c tcp_var.h 
 udp_usrreq.c udp_var.h 
sys/netinet6 in6_pcb.c in6_pcb.h raw_ip6.c 
 udp6_usrreq.c 
  Log:
  Notify functions can destroy the pcb, so they have to return an
  indication of whether this happenned so the calling function
  knows whether or not to unlock the pcb.
  
  Submitted by:   Jennifer Yang ([EMAIL PROTECTED])
  Bug reported by:  Sid Carter ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.108 +3 -2  src/sys/netinet/in_pcb.c
  1.50  +3 -2  src/sys/netinet/in_pcb.h
  1.132 +24 -15src/sys/netinet/tcp_subr.c
  1.81  +6 -3  src/sys/netinet/tcp_var.h
  1.113 +3 -2  src/sys/netinet/udp_usrreq.c
  1.26  +2 -1  src/sys/netinet/udp_var.h
  1.31  +3 -2  src/sys/netinet6/in6_pcb.c
  1.8   +3 -2  src/sys/netinet6/in6_pcb.h
  1.21  +1 -1  src/sys/netinet6/raw_ip6.c
  1.28  +1 -1  src/sys/netinet6/udp6_usrreq.c


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

Re: Broken world in rtld-elf...

[Bruce Evans]

On Thu, 13 Jun 2002, Alex Zepeda wrote:

 On Thu, Jun 13, 2002 at 12:26:05PM +1000, Bruce Evans wrote:

  rtld still uses asms with the old, broken/fragile 0 constraint.  This
  constraint is especially broken/fragile if things are pessimized by
  compiling without optimizations.

 D'oh!

 Is there any chance of sticking a warning in the makefile if -O0 (or
 whatever else would cause it to not compile) is present?

Not really.  It is a transient bug that is almost as easy to fix as
warn about.

Bruce


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

Re: panic: xl0

[Stephan van Beerschoten]

I'm sorry this message came across the net so long ago (3 days to
deliver mail!). this was because of DNS reverse lookups that failed on
my mailserver because of DNS outage. The item has been discussed already
in 2 threads, so I wasn't planning on starting a new one.
Actually, 3 days ago I was planning on starting the first ;)

On Tue, Jun 11, 2002 at 01:27:34PM +0200, Stephan van Beerschoten wrote:
This morning I cvsupped and redid my kernel and world with no
compilation errors whatsoever, which was nice to see again :)

Right now however I have panics with my xl0

Since I cannot copy/paste anything anywhere, I wrote as much info down
as I found to be relevant.

I tried to run the GENERIC kernel too, so the following is based on
that. While booting the following message appears right after the kernel
detects the xl0 interface:
/usr/src/sys/vm/uma_core.c:1327 Could sleep with xl0 locked from
/usr/src/sys/pci/if_pci.c:415

The above message also is displayed everytime the ifconfig command is
run on the xl0 interface, even if it is just to display current configs.
It does however boot and detects its mac adress and the media attached
to it.

I had to boot in single because the machine panic'd as soon as the
interface was initialized (with dhcp).

I traced down the following:

As soon as the interface is set to be up the kernel displays:
Unregistered isr number: 18  - This happends a lot, maybe for every
packet received by the interface ? (guess)

I can do the following:
# ifconfig xl0 130.x.x.x[enter]

This works, BUT as soon as I add a netmask (like my net requires):
# ifconfig xl0 130.x.x.x netmask 255.255.254.0 [enter] - panic:

blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/i386/trap.c:711

With regards,
Stephan

-- 
Stephan van Beerschoten [SVB21-RIPE]   [EMAIL PROTECTED]
  PGP fingerprint:  4557 9761 B212 FB4C  778D 3529 C42A 2D27
 To err is human, to forgive is Not Company Policy

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

-- 
Stephan van Beerschoten [SVB21-RIPE]   [EMAIL PROTECTED]
  PGP fingerprint:  4557 9761 B212 FB4C  778D 3529 C42A 2D27
 To err is human, to forgive is Not Company Policy

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

panic -- trap in mtx_lock_sleep

[Georg-W. Koltermann]

Hi,

I got the following panic while compiling openoffice. I suspect it was
somehow triggered by the high I/O activity.

Last CVSup was 17 May 22:27 GMT-2.

I'll keep the dump around for a couple of days, so let me know if I
should provide any additional information.

--
Georg.

hunter# cat info.21
Good dump found on device /dev/ad0s2b
  Architecture: i386
  Architecture version: 1
  Dump length: 1073086464B (1023 MB)
  Blocksize: 512
  Dumptime: Fri Jun 14 14:02:18 2002
  Hostname: hunter.muc.macsch.com
  Versionstring: FreeBSD 5.0-CURRENT #70: Mon Jun  3 15:00:22 CEST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/HUNTER
  Panicstring: bwrite: buffer is not busy???
  Bounds: 21
hunter# 

hunter[5]$ gdb -k kernel.debug vmcore.21
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x00514000
initial pcb at physical address 0x00420b20
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc01eee7f
stack pointer   = 0x10:0xe3758be8
frame pointer   = 0x10:0xe3758c08
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 = 1410 (slogin)
trap number = 12
panic: page fault

syncing disks... panic: bwrite: buffer is not busy???
Uptime: 4h58m25s
pfs_vncache_unload(): 2 entries remaining
/dev/vmmon: Module vmmon: unloaded
Dumping 1023 MB
ata0: resetting devices .. ata0-slave: ATA identify retries exceeded
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0  0xc01fa1a4 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
353 }
(kgdb) t
[Current thread is 0 (process 0)]
(kgdb) where
#0  0xc01fa1a4 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
#1  0xc01fa7d1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:353
#2  0xc01fa9dd in panic (fmt=0xc03aab0b bwrite: buffer is not busy???)
at /usr/src/sys/kern/kern_shutdown.c:353
#3  0xc0240eac in bwrite (bp=0xd290c844) at /usr/src/sys/kern/vfs_bio.c:1367
#4  0xc0242635 in vfs_bio_awrite (bp=0xd290c844)
at /usr/src/sys/kern/vfs_bio.c:1367
#5  0xc01c8a67 in spec_fsync (ap=0xe37589c0)
at /usr/src/sys/fs/specfs/spec_vnops.c:849
#6  0xc01c844e in spec_vnoperate (ap=0xe37589c0)
at /usr/src/sys/fs/specfs/spec_vnops.c:849
#7  0xc030b72a in VOP_FSYNC (vp=0xe0e03000, cred=0xd277ff00, waitfor=2, 
td=0xc03ea5a0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:810
#8  0xc030abc1 in ffs_sync (mp=0xe0c25200, waitfor=2, cred=0xd277ff00, 
td=0xc03ea5a0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:810
#9  0xc025424b in sync (td=0xc03ea5a0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:640
#10 0xc01fa2ab in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:353
#11 0xc01fa9dd in panic (fmt=0xc03c70de %s)
at /usr/src/sys/kern/kern_shutdown.c:353
#12 0xc036d714 in trap_fatal (frame=0xe3758ba8, eva=0)
at /usr/src/sys/i386/i386/trap.c:652
#13 0xc036d34b in trap_pfault (frame=0xe3758ba8, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:652
#14 0xc036cd34 in trap (frame={tf_fs = -481361896, tf_es = -481361904, 
  tf_ds = -472580080, tf_edi = 0, tf_esi = -1, tf_ebp = -478835704, 
  tf_isp = -478835756, tf_ebx = -481313712, tf_edx = 0, tf_ecx = 1183, 
  tf_eax = -481313456, tf_trapno = 12, tf_err = 2, tf_eip = -1071714689, 
  tf_cs = 8, tf_eflags = 66182, tf_esp = -472555008, tf_ss = -481313456})
at /usr/src/sys/i386/i386/trap.c:652
#15 0xc01eee7f in _mtx_lock_sleep (m=0xe38a74b4, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:574
#16 0xc024e927 in vrele (vp=0xe38a744c) at /usr/src/sys/kern/vfs_subr.c:2030
#17 0xc01d9979 in fdfree (td=0xe34fbd50)
at /usr/src/sys/kern/kern_descrip.c:476
#18 0xc01e03a0 in exit1 (td=0xe34fbd50, rv=-256)
at /usr/src/sys/kern/kern_exit.c:448
#19 0xc01dffc8 in exit1 (td=0xe34fbd50, rv=-478835464)
at /usr/src/sys/kern/kern_exit.c:448
#20 0xc036da82 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = 0, tf_esi = -1, tf_ebp = -1077938808, tf_isp = -478835340, 
  tf_ebx = 673230588, tf_edx = 10, tf_ecx = 673230224, tf_eax = 1, 
  tf_trapno = 22, tf_err = 2, tf_eip = 672833571, tf_cs = 31, 
  tf_eflags = 658, tf_esp = -1077938852, tf_ss = 

Re: When was soundcard.h moved?

[Will Andrews]

On Fri, Jun 14, 2002 at 10:05:52AM +0200, Sheldon Hearn wrote:
 When was soundcard.h moved from machine to sys?  A large number of ports
 expect to find it in machine, and I can't find a __FreeBSD_version bump
 supporting the change.
 
 So I need to find out when it happened and piggy-back on the nearest
 __FreeBSD_version bump. :-(

Actually, if you don't care about 3.x, you can just change it to
sys/soundcard.h (which seems a little more standardized judging
by where other OSs put it).  4.x and on have had
sys/soundcard.h synchronized with machine/soundcard.h.  And
5.x recently only has sys/soundcard.h.

Regards,
-- 
wca

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

Re: HEADS UP: rc.d is in the tree

[Dennis Kristensen]

Gordon Tetlow wrote:

...
Please try out the functionality by putting rc_ng=YES into your rc.conf 
and post any problems you might have.
  

I have given this a try, but have a few problems. My rc.conf is attached.

1:
When bringing up fxp0 with IP from DHCP i get:
Doing initial network setup: hostnamefxp0: 
flags=8843UP,BROADCAST,RUNNING,SIMPL
EX,MULTICAST mtu 1500
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
...
Without rc_ng, and a manual 'dhclient fxp0' still works. Is there 
another way to do this with this new scheme?

2:
Setting mta_start_script to , drops me into a shell. I need to 
manually exit the shell to continue booting. How should i prevent mta's 
from starting now?

Besides this, everything works great! Good work. If more info is needed just let me 
know.

~$ uname -a
FreeBSD lap.snicki.dk 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Fri Jun 14 10:10:14 CEST 
2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAP  i386


-Dennis



rc_ng=YES
font8x14=cp850-8x14
font8x16=cp850-8x16
font8x8=cp850-8x8
hostname=lap.snicki.dk
ifconfig_fxp0=DHCP
kern_securelevel_enable=NO
keymap=danish.iso
keyrate=fast
linux_enable=YES
moused_enable=YES
moused_flags=-3
nfs_client_enable=YES
mta_start_script=
sshd_enable=YES
usbd_enable=YES
#allscreens_flags=80x60

Re: When was soundcard.h moved?

[Trish Lynch]

On Fri, 14 Jun 2002, Sheldon Hearn wrote:


 Hi folks,

 When was soundcard.h moved from machine to sys?  A large number of ports
 expect to find it in machine, and I can't find a __FreeBSD_version bump
 supporting the change.

 So I need to find out when it happened and piggy-back on the nearest
 __FreeBSD_version bump. :-(

 Ciao,
 Sheldon.


Sheldon,
do a little research, that actually happened in
3.0-CURRENT/RELEASE, however the symlink was kept there for backwards
compatibility, now that 5.0-CURRENT is moving towards release, the symlink
was removed.

If you want to do it via version bump, the safe way is to consider
everything v4-STABLE and earlier to have it in machine/*

-Trish





--
Trish Lynch [EMAIL PROTECTED]
FreeBSD The Power to Serve
Ecartis Core Team   [EMAIL PROTECTED]
   http://www.freebsd.org



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

Re: HEADS UP: rc.d is in the tree

[zhuravlev alexander]

On Fri, Jun 14, 2002 at 03:28:40PM +0200, Dennis Kristensen wrote:
 Gordon Tetlow wrote:
 
 ...
 Please try out the functionality by putting rc_ng=YES into your rc.conf 
 and post any problems you might have.
   
 
 I have given this a try, but have a few problems. My rc.conf is attached.
 
 1:
 When bringing up fxp0 with IP from DHCP i get:
 Doing initial network setup: hostnamefxp0: 
 flags=8843UP,BROADCAST,RUNNING,SIMPL
 EX,MULTICAST mtu 1500
 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
 ...
 Without rc_ng, and a manual 'dhclient fxp0' still works. Is there 
 another way to do this with this new scheme?
 
 2:
 Setting mta_start_script to , drops me into a shell. I need to 
 manually exit the shell to continue booting. How should i prevent mta's 
 from starting now?

maybe this helps 
sendmail_enable=NONE

 
 Besides this, everything works great! Good work. If more info is needed just let me 
know.
 
 ~$ uname -a
 FreeBSD lap.snicki.dk 5.0-CURRENT FreeBSD 5.0-CURRENT #7: Fri Jun 14 10:10:14 CEST 
2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAP  i386
 
 
 -Dennis
 

 rc_ng=YES
 font8x14=cp850-8x14
 font8x16=cp850-8x16
 font8x8=cp850-8x8
 hostname=lap.snicki.dk
 ifconfig_fxp0=DHCP
 kern_securelevel_enable=NO
 keymap=danish.iso
 keyrate=fast
 linux_enable=YES
 moused_enable=YES
 moused_flags=-3
 nfs_client_enable=YES
 mta_start_script=
 sshd_enable=YES
 usbd_enable=YES
 #allscreens_flags=80x60


-- 
zhuravlev alexander
 u l s t u  n o c

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

Re: HEADS UP: rc.d is in the tree

[Dennis Kristensen]

zhuravlev alexander wrote:

On Fri, Jun 14, 2002 at 03:28:40PM +0200, Dennis Kristensen wrote:
  

Gordon Tetlow wrote:



...
Please try out the functionality by putting rc_ng=YES into your rc.conf 
and post any problems you might have.
 

  

I have given this a try, but have a few problems. My rc.conf is attached.

1:
When bringing up fxp0 with IP from DHCP i get:
Doing initial network setup: hostnamefxp0: 
flags=8843UP,BROADCAST,RUNNING,SIMPL
EX,MULTICAST mtu 1500
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
...
Without rc_ng, and a manual 'dhclient fxp0' still works. Is there 
another way to do this with this new scheme?

2:
Setting mta_start_script to , drops me into a shell. I need to 
manually exit the shell to continue booting. How should i prevent mta's 
from starting now?



   maybe this helps 
   sendmail_enable=NONE

No, then it complains that:
   /etc/rc: WARNING: $sendmail_enable is not set properly.
abd still starts sendmail.


Thanks anyway,
-Dennis


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

Re: HEADS UP: rc.d is in the tree

[Danny Braniss]

in amd, 
# REQUIRE: rpcbind mountall ypbind nfsclient
**
since i don't use yp, how can i override this?

or in other words, can REQUIRE be configurable too?

danny



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

Have random panic somewhere near console driver on fresh current

[Vladimir B . Grebenschikov]

Submitter-Id:  [EMAIL PROTECTED]
Originator:Vladimir B. Grebenschikov
Organization:  SWsoft
Confidential:  no
Synopsis:  Have random panic somewhere near console driver on fresh current
Severity:  critical
Priority:  high
Category:  kern
Class: sw-bug
Release:   FreeBSD 5.0-CURRENT i386
Environment:
System: FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Wed Jun 5 
17:36:46 MSD 2002 [EMAIL PROTECTED]:/usr/local/src/sys/i386/compile/VBOOK i386
gdm runned from /etc/ttys by init
gnome environment
xconsole runned both by gdm on login screen and by gnome-session after login

dmesg.boot:

Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #2: Wed Jun  5 17:36:46 MSD 2002
[EMAIL PROTECTED]:/usr/local/src/sys/i386/compile/VBOOK
Preloaded elf kernel /boot/kernel/kernel at 0xc0468000.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04680b4.
Preloaded elf module /boot/kernel/snd_neomagic.ko at 0xc0468160.
Preloaded elf module /boot/kernel/ukbd.ko at 0xc0468214.
Preloaded elf module /boot/kernel/usb.ko at 0xc04682c0.
Preloaded elf module /boot/kernel/ums.ko at 0xc0468368.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0468410.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 331580917 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (331.58-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x66a  Stepping = 10
  
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory  = 201261056 (196544K bytes)
avail memory = 190615552 (186148K bytes)
Pentium Pro MTRR support enabled
Using $PIR table, 7 entries at 0xc00fdf50
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: PTLTDRSDT   on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_button0: Power Button on acpi0
acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: PCI bus on acpi_pcib0
pci0: network, ethernet at device 6.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xfc90-0xfc9f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfca0-0xfcbf irq 9 at device 
7.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller 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
uhub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2
uhub1: 4 ports with 4 removable, self powered
ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.
ukbd0: Behavior Tech. Computer Keyboard with mouse port, rev 1.00/1.00, addr 4, iclass 
3/1
kbd1 at ukbd0
ums1: Behavior Tech. Computer Keyboard with mouse port, rev 1.00/1.00, addr 4, iclass 
3/1
ums1: 3 buttons
intpm0: Intel 82371AB Power management controller port 0x2180-0x218f irq 9 at device 
7.3 on pci0
intpm0: I/O mapped 2180
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
smb0: SMBus generic I/O on smbus0
intpm0: PM I/O mapped 8000 
pci0: display, VGA at device 8.0 (no driver attached)
pcm0: NeoMagic 256AV mem 0xfea0-0xfeaf,0xfe00-0xfe3f irq 9 at device 
8.1 on pci0
pci0: serial bus, FireWire at device 9.0 (no driver attached)
acpi_pcib0: device is routed to IRQ 9
pcic0: Ricoh RL5C475 PCI-CardBus Bridge irq 9 at device 10.0 on pci0
pcic0: PCI Memory allocated: 0x4400
pccard0: PC Card bus (classic) on pcic0
pci0: simple comms at device 11.0 (no driver attached)
atspeaker0 port 0x61 on acpi0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model GlidePoint, device ID 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A, console
sio1 port 0x140-0x147,0x3e8-0x3ef irq 10 drq 0 on acpi0
sio1: type 16550A
ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
acpi_cmbat0: Control method Battery on acpi0
acpi_acad0: AC adapter on acpi0
orm0: Option ROMs at iomem 0xdc000-0xd,0xc-0xcbfff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x100
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
IP packet filtering 

duplicate -ffreestanding in kernel build

[Maxime Henrion]

Hi all,


I recently noticed that we are adding the -ffreestanding flag twice for
kernel builds.  It's added once if GCC3 is defined in
/usr/share/mk/bsd.kern.mk and another time inconditionally in
/sys/conf/kern.pre.mk.  As a result, I have -ffreestanding once on my
x86 box still running with GCC 2.95 and I have it twice on my sparc box
running GCC 3.  One of these should be removed, but I'm not sure which
one yet.  Keeping it in kern.pre.mk has the advantage that it will work
even if someone is using a staled bsd.kern.mk.  Also, I wonder if it
should be conditional on GCC3 being defined since we were adding it
inconditionally there.

Any thoughts?

Thanks,
Maxime

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

Re: HEADS UP: rc.d is in the tree

[Dennis Kristensen]

 Please try out the functionality by putting rc_ng=YES into your 
 rc.conf and post any problems you might have.
  

 I have given this a try, but have a few problems. My rc.conf is attached.

 1:
 When bringing up fxp0 with IP from DHCP i get:
 Doing initial network setup: hostnamefxp0: 
 flags=8843UP,BROADCAST,RUNNING,SIMPL
 EX,MULTICAST mtu 1500
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
 ...
 Without rc_ng, and a manual 'dhclient fxp0' still works. Is there 
 another way to do this with this new scheme?


This is solved with the below patch.

-Dennis

~$ diff -u /usr/src/etc/rc.d/network1 
/etc/rc.d/network1  
--- /usr/src/etc/rc.d/network1  Fri Jun 14 00:14:36 2002
+++ /etc/rc.d/network1  Fri Jun 14 18:24:08 2002
@@ -140,7 +140,8 @@
done
 
if [ ! -z ${dhcp_interfaces} ]; then
-   ${dhcp_program:-/sbin/dhclient} ${dhcp_flags} 
${dhcp_interfaces}fi
+   ${dhcp_program:-/sbin/dhclient} ${dhcp_flags} 
${dhcp_interfaces}
+   fi
 
for ifn in ${network_interfaces}; do
# Check to see if aliases need to be added
@@ -274,7 +275,6 @@
# XXX this must die
if [ -s /etc/netstart.local ]; then
sh /etc/netstart.local start
-   fi
fi
echo '.'



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

Re: HEADS UP: rc.d is in the tree

[Dennis Kristensen]

Dennis Kristensen wrote:

 Gordon Tetlow wrote:

 ...
 Please try out the functionality by putting rc_ng=YES into your 
 rc.conf and post any problems you might have.
  

 I have given this a try, but have a few problems. My rc.conf is attached.

 2:
 Setting mta_start_script to , drops me into a shell. I need to 
 manually exit the shell to continue booting. How should i prevent 
 mta's from starting now? 


sendmail_enable=NONE  did'nt help either. This can be fixed with below 
patch.
It still complains with
  /etc/rc: WARNING: $sendmail_enable is not set properly.
but sendmail is no longer started.

-Dennis

~$ diff -u /usr/src/etc/rc.d/sendmail /etc/rc.d/sendmail
--- /usr/src/etc/rc.d/sendmail  Fri Jun 14 09:47:25 2002
+++ /etc/rc.d/sendmail  Fri Jun 14 18:44:39 2002
@@ -64,7 +64,7 @@

case `${CMD_OSTYPE}` in
FreeBSD)
-   case $SENDMAIL_ENABLE in
+   case $sendmail_enable in
   NONE)
   exit
   ;;


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

Re: Perl scripts that need rewiting - Any volunteers?

[Jonathan Belson]

Mark Murray wrote:
These seem to be the same program.  I'll take this if there are no
objections. 
 
 You have it!

Okay, here's my vidfont/kbdmap rewrite for review.  Any feedback
is welcome, the same goes for bug reports :-)

Cheers,


--Jon

http://www.witchspace.com



#include sys/queue.h
#include sys/types.h

#include assert.h
#include ctype.h
#include dirent.h
#include stdio.h
#include stdlib.h
#include string.h
#include stringlist.h
#include unistd.h


static char *lang_default = en;
static char *font;
static char *lang;
static const char *program;
static char *keymapdir = /usr/share/syscons/keymaps;
static char *fontdir = /usr/share/syscons/fonts;
static char *sysconfig = /etc/rc.conf;
static char *font_default = cp437-8x16.fnt;
static char *font_current;
static char *dir;
static const char *menu = ;

static int x11;
static int show;
static int verbose;
static int print;


struct keymap {
char*desc;
char*keym;
int mark;
SLIST_ENTRY(keymap) entries;
};
static SLIST_HEAD(slisthead, keymap) head = SLIST_HEAD_INITIALIZER(head);


/*
 * Get keymap entry for 'key', or NULL of not found
 */
struct keymap *
get_keymap(const char *key)
{
struct keymap *km;

SLIST_FOREACH(km, head, entries) {
if (!strcmp(km-keym, key)) {
return km;
}
}

return NULL;
}

/*
 * Count the number of keymaps we found
 */
static int
get_num_keymaps(void)
{
struct keymap *km;
int count = 0;

SLIST_FOREACH(km, head, entries) {
count++;
}

return count;
}

/*
 * Remove any keymap with given keym
 */
static void
remove_keymap(const char *keym)
{
struct keymap *km;

SLIST_FOREACH(km, head, entries) {
if (!strcmp(keym, km-keym)) {
SLIST_REMOVE(head, km, keymap, entries);
free(km);
break;
}
}
}

/*
 * Add to hash with 'key'
 */
void
add_keymap(const char *desc, int mark, const char *keym)
{
struct keymap *km, *km_new;

/* Is there already an entry with this key? */
SLIST_FOREACH(km, head, entries) {
if (!strcmp(km-keym, keym)) {
/* Reuse this entry */
free(km-desc);
km-desc = strdup(desc);
km-mark = mark;
return;
}
}

km_new = (struct keymap *) malloc (sizeof(struct keymap));
km_new-desc = strdup(desc);
km_new-keym = strdup(keym);
km_new-mark = mark;

/* Add to keymap list */
SLIST_INSERT_HEAD(head, km_new, entries);
}

/*
 * Figure out the default language to use.
 */
static char *
get_locale(void)
{
char *locale;

locale = getenv(LC_ALL);
if (locale == NULL) {
locale = getenv(LC_CTYPE);
if (locale == NULL) {
locale = getenv(LANG);
if (locale == NULL) {
locale = lang_default;
}
}
}

/* Check for alias */
if (!strcmp(locale, C)) {
locale = en;
}

return locale;
}

/*
 * Extract filename part
 */
static const char *
extract_name(char *name)
{
char *p;

p = strrchr(name, '/');
if (p != NULL  p[1] != '\0') {
return p + 1;
} 

return name;
}

/*
 * Return file extension or NULL
 */
static char *
get_extension(const char *name)
{
char *p;

p = strrchr(name, '.');

if (p != NULL  p[1] != '\0') {
return p;
}

return NULL;
}

/*
 * Read font from /etc/rc.conf else return default.
 * Freeing the memory is the caller's responsibility.
 */
static char *
get_font(void)
{
char line[256], buf[20];
char *font = NULL;

FILE *fp = fopen(sysconfig, r);
if (fp) {
while (fgets(line, sizeof(line), fp)) {
int a, b, matches;

if (line[0] == '#') {
continue;
}

matches = sscanf(line,  font%dx%d = \%20[-.0-9a-zA-Z_], a, 
b, buf);
if (matches==3) {
if (strcmp(buf, NO)) {
if (font) {
free(font);
}
font = (char *) malloc(strlen(buf) + 1);
strcpy(font, buf);
}
}
}
} else {
printf(Could not open %s for reading\n, sysconfig);
}

return font;
}

/*
 * 

Re: Device cloning

[Mark Santcroos]

On Tue, Jun 11, 2002 at 10:14:48AM -0700, Maksim Yevmenkin wrote:
 or USB dongle. They all MUST talk via HCI. So HCI is not really a
 device driver, and, IMO, it is not a pseudo device driver. It sort
 of looks like /dev/tcp :)

Hi Maksim,

A ng_device netgraph node is coming up.
That will present you with a /dev/whatever you want interface to the
netgraph subsystem.
That might be a starting point, as your work is also a netgraph node.

Mark

-- 
Mark Santcroos  RIPE Network Coordination Centre
http://www.ripe.net/home/mark/  New Projects Group/TTM

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

Re: Device cloning

[Maksim Yevmenkin]

Hi Mark,

 On Tue, Jun 11, 2002 at 10:14:48AM -0700, Maksim Yevmenkin wrote:
  or USB dongle. They all MUST talk via HCI. So HCI is not really a
  device driver, and, IMO, it is not a pseudo device driver. It sort
  of looks like /dev/tcp :)
 
 A ng_device netgraph node is coming up.
 That will present you with a /dev/whatever you want interface to the
 netgraph subsystem.
 That might be a starting point, as your work is also a netgraph node.

Yeah, i know. I think, i have the source. It is most likely outdated.
In the version i have you create a new device entry per hook, but what
i really wanted is one device per node with ability to clone devices.
I.e. two (or more) things open /dev/foo and each of them get unique
private context within node. Since it is not going to work anyway,
i will stick to multiple hooks idea which would fit perfectly into
ng_device interface.

thanks,
max

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

Re: HEADS UP: rc.d is in the tree

[Mike Makonnen]

On Fri, 14 Jun 2002 19:38:15 +0200
Dennis Kristensen [EMAIL PROTECTED] wrote:

 
 sendmail_enable=NONE  did'nt help either. This can be fixed with below 
 patch.
 It still complains with
   /etc/rc: WARNING: $sendmail_enable is not set properly.
 but sendmail is no longer started.
[patch ommited]

Thanks. 

It's supposed to complain to remind me to get together with the sendmail maintainer
to figure out how to handle sendmail's non-standard NONE option.


Cheers,
Mike Makonnen

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

Re: HEADS UP: rc.d is in the tree

[Mike Makonnen]

On Fri, 14 Jun 2002 16:55:40 +0300
Danny Braniss [EMAIL PROTECTED] wrote:

 in amd, 
   # REQUIRE: rpcbind mountall ypbind nfsclient
   **
 since i don't use yp, how can i override this?
 
 or in other words, can REQUIRE be configurable too?

The REQUIRE line doesn't mean it will be started. It just means that 
ypbind comes before amd in the boot process.

Cheers,
Mike Makonnen

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

Re: HEADS UP: rc.d is in the tree

[Terry Lambert]

Mike Makonnen wrote:
 Danny Braniss [EMAIL PROTECTED] wrote:
  in amd,
# REQUIRE: rpcbind mountall ypbind nfsclient
**
  since i don't use yp, how can i override this?
 
  or in other words, can REQUIRE be configurable too?
 
 The REQUIRE line doesn't mean it will be started. It just means that
 ypbind comes before amd in the boot process.

Ick.

What should be used instead of REQUIRE to mean that it will be
started?

I.e. if REQUIRE describes soft dependency ordering, what
describes hard dependency ordering?

-- Terry

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

Re: HEADS UP: rc.d is in the tree

[Greg 'groggy' Lehey]

On Thursday, 13 June 2002 at 15:37:55 -0700, Gordon Tetlow wrote:
 I've imported the excellent work by Mike Makonnen into the tree.

Can you summarize what the differences are?

Greg
--
See complete headers for address and phone numbers

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

(J!$B9-9p(J!$B!!=P2q$$%S%8%M(B$B%9#3E@%;%C%H$GBgLY$1!*(B

[umeda]

$BCK=w=P2q$$%S%8%M%9$K$D$$$F$N$*CN$i$;$G$9!#%a!<%k$NITMW$NJ}$O(B
$B$3$N$^$^JV?.$7$F$*CN$i$;$/$@$5$$!#(B

$BCK=w=P2q$$%S%8%M%9$GBgLY$1$7$^$;$s$+!)=P2q$$7O%5%$%H$O@$$NCf(B
$B$K#3K|7o$[$I$"$k$H8@$o$l$F$$$^$9$,!"6%9g$,B?$9$.$FBgLY$1$7$F(B
$B$$$k%5%$%H$O$4$/0lIt!#:#2s$4Ds0F$9$k!VCK=w=P2q$$%S%8%M%9#3e$2$k$K$O%7%9%F%`$,Fq2r(B
$B#2!K=P2q$$7O%5%$%H$NBeM}E9$K2CLA$9$k$H$7$F$b2CLA6b$,#1#0K|1_(B
$B0J>e$H9b3[(B
$B#3!KCK=w2q0w3MF@!JFC$K=w@-!K$N@kEA9-9pHqEy$NHqMQ$,KDBg$K$+$+$k(B
$B#4!KCK@-2q0w3NJ]$N$?$a$N7G<(HD=q$-9~$_Ey$N@kEA:n6H$,LLE]3n$D(B
$B;~4V$,$+$+$k!J;~4VE*$K$_$FHs8zN(!K(B

$B:#2s$4Ds0F$9$k!VCK=w=P2q$$%S%8%M%9#3e5-$N7gE@$r(B
$BA4$F2r7h$7$F$*$j!"=i?4h$;$k$3$H$,$G$-$^$9!#(B

$BCK=w8r:]6H$O!"=P2q$$7O%5%$%H$b4^$a$F=w@-2q0w3NJ]$,0lHV$N2]Bj(B
$B$G$7$?!#:#2sDs0F$9$k%S%8%M%9%b%G%k$G$O!"=w@-2q0w3NJ]$O$b$A$m$s(B
$B$N$3$H!"CK@-$KBP$9$k@kEAJ}K!$b4J7i$K$G$-$F$$$^$9$N$G!"$9$G$K=P(B
$B2q$$7O%5%$%H$r1?1D$7$F$$$kJ}$K$H$C$F$b!"2h4|E*$JJ}K!$G$"$k$3$H$O(B
$B$^$A$,$$$"$j$^$;$s!#$^$?!"$"$kDxEY47$l$F$-$?$i!J$"$k$$$O%9%?!<%H(B
$BCJ3,$+$i!KLLE]$J;vL3E*:n6HEy$O%"%k%P%$%H$KG$$;$F!"<+J,$O2?$b$;(B
$B$:$H$b%3%s%9%?%s%H$J<}F~$r$"$2$k$3$H$b==J,2DG=$H$J$C$F$$$-$^$9!#(B

$B>\:Y4uK>$NJ}$O!"2<5-%a!<%k%"%I%l%9$X!VCK=w8r:]%S%8%M%9#3\:Y4uK>!W$H$$$&%?%$%H%k$G!"#1!K;aL>!!#2!K=;=j!J2?8)2?;T$^$G!K!!#3!K(B
$BG/Np!!#4!K%a!<%k%"%I%l%9!!$rL@5-$N>e$4O"Mm$/$@$5$$!#(B

$B!!@83h8~>e0Q0w2q(B  [EMAIL PROTECTED]


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

Re: Broken world in rtld-elf...

[Alex Zepeda]

On Fri, Jun 14, 2002 at 07:09:06PM +1000, Bruce Evans wrote:

 Not really.  It is a transient bug that is almost as easy to fix as
 warn about.

So when can I expect the fix to be committed? :-D

- alex

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

ACPI errors on laptop running latest -current

[David W. Chapman Jr.]

When I boot up my gateway solo 2550, I get the following errors

ACPI-0428: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
ACPI-1305: *** Error: Method execution failed, AE_ERROR
ACPI-0428: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
ACPI-1305: *** Error: Method execution failed, AE_ERROR
ACPI-0428: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
ACPI-1305: *** Error: Method execution failed, AE_ERROR
ACPI-0428: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
ACPI-1305: *** Error: Method execution failed, AE_ERROR
ACPI-0428: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
ACPI-1305: *** Error: Method execution failed, AE_ERROR
ACPI-0428: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
ACPI-1305: *** Error: Method execution failed, AE_ERROR

I've attached my dmesg.  I also think there is a problem with acpi 
detecting the battery properly.  IF anyone has any ideas I'd 
appreciate it.

hw.acpi.acline: 0
hw.acpi.battery.life: 0
hw.acpi.battery.time: -1
hw.acpi.battery.state: 0
hw.acpi.battery.units: 1
hw.acpi.battery.info_expire: 5


-- 
David W. Chapman Jr.
[EMAIL PROTECTED]   Raintree Network Services, Inc. www.inethouston.net
[EMAIL PROTECTED]   FreeBSD Committer www.FreeBSD.org


Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #1: Wed Jun 12 22:44:45 CDT 2002
root@:/usr/obj/usr/src/sys/DWCJR
Preloaded elf kernel /boot/kernel/kernel at 0xc03e9000.
Preloaded elf module /boot/kernel/usb.ko at 0xc03e90a8.
Preloaded elf module /boot/kernel/random.ko at 0xc03e9150.
Preloaded elf module /boot/kernel/sysvmsg.ko at 0xc03e91fc.
Preloaded elf module /boot/kernel/sysvsem.ko at 0xc03e92a8.
Preloaded elf module /boot/kernel/snp.ko at 0xc03e9354.
Preloaded elf module /boot/kernel/acpi.ko at 0xc03e93fc.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 647189041 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (647.19-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x686  Stepping = 6
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 167706624 (163776K bytes)
avail memory = 158613504 (154896K bytes)
Pentium Pro MTRR support enabled
Using $PIR table, 15 entries at 0xc00fded0
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: PTLTDRSDT   on motherboard
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0
acpi_cpu0: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: PCI bus on acpi_pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0x1000-0x100f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 5 at device 7.2 on pci0
uhci0: Could not map ports
device_probe_and_attach: uhci0 attach returned 6
pci0: bridge, PCI-unknown at device 7.3 (no driver attached)
pccbb0: TI1225 PCI-CardBus Bridge irq 10 at device 10.0 on pci0
cardbus0: CardBus bus on pccbb0
pccard0: 16-bit PCCard bus on pccbb0
pccbb1: TI1225 PCI-CardBus Bridge irq 10 at device 10.1 on pci0
cardbus1: CardBus bus on pccbb1
pccard1: 16-bit PCCard bus on pccbb1
pci0: multimedia, audio at device 14.0 (no driver attached)
pci0: simple comms at device 16.0 (no driver attached)
acpi_acad0: AC adapter on acpi0
acpi_cmbat0: Control method Battery on acpi0
acpi_button0: Sleep Button on acpi0
acpi_ec0: embedded controller port 0x66,0x62 on acpi0
ppc0 port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel I/O on ppbus0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
fdc0: enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
orm0: Option ROM at iomem 0xc-0xcbfff on isa0
sc0: System console on isa0
sc0: VGA 16 virtual consoles, flags=0x200
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
pmtimer0 on isa0
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
Timecounters tick every 10.000 msec
acpi_cpu: CPU throttling enabled, 

Re: Mozilla 1.0 error

[Joe Marcus Clarke]

On Mon, 2002-06-10 at 14:36, Alexandr Kovalenko wrote:
 Hello, Kris Kennaway!
 
 On Fri, Jun 07, 2002 at 02:02:52PM -0700, you wrote:
 
  On Fri, Jun 07, 2002 at 04:56:45PM -0400, Joe Marcus Clarke wrote:
   On Fri, 2002-06-07 at 10:52, Jun Kuriyama wrote:
At Fri, 7 Jun 2002 12:43:27 + (UTC),
John Angelmo wrote:
   (cd /usr/ports/www/mozilla/work/mozilla/dist/bin;  /usr/bin/env
   LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regxpcom;  echo
   skin,install,select,classic/1.0  chrome/installed-chrome.txt;  echo
   locale,install,select,en-US  chrome/installed-chrome.txt;
   /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regchrome)
   [1]   Segmentation fault (core dumped)
   *** Error code 139
 
   Stop in /usr/ports/www/mozilla.
I got same result, too.
   This problem seems to happen on -CURRENT and alpha -stable.
  And i386 -stable.
 Worked fine for me:
 [never@mile ~]$ cat /usr/ports/www/mozilla/Makefile | grep \$FreeBSD
 # $FreeBSD: ports/www/mozilla/Makefile,v 1.107 2002/06/06 18:52:31 sobomax Exp $
 [never@mile ~]$ uname -a
 FreeBSD mile.nevermind.kiev.ua 4.6-RC FreeBSD 4.6-RC #0: Wed Jun  5 21:12:35 EEST 
2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/mile  i386
 [never@mile ~]$ gcc -v
 Using builtin specs.
 gcc version 2.95.3 20010315 (release) [FreeBSD]

Yeah, it's worked fine for me on every -stable i386 machine I've built
it on using gcc 2.95.  I'm running some tests on -CURRENT with gcc 3.1
from ports, and the results are good.  gcc 3.1 from ports builds Mozilla
successfully.

Based on what mbr has done with OO, I'm going to try out some gcc-3.1
(port) mods to Mozilla's Makefile so we can hopefully start building
some alpha packages.

Joe

 
 -- 
 NEVE-RIPE
 Ukrainian FreeBSD User Group
 http://uafug.org.ua/
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 




signature.asc
Description: This is a digitally signed message part

'sh' core dumps with signal 4 and another problems...

[Vladimir G. Drobyshevsky]

Hello all!

  11 Jun I was installed 2002.06.10-JPSNAP from
  snapshot.jp.freebsd.org. All seems to be ok. After that I builded
  kernel without debug. And now I have some troubles:

  1. I can't normally load bktr module - bktr_mem cannon assign memory
 and can't attach device - device_attach return signal 6.

  2. When I try to build kernel with bktr (or just to build custom
 kernel) 'sh' is core dumps.


  And I cannon synchronize my local cvs-tree with main repository (it
  didn't consequence of new kernel building. Just contemporaneous.
  cvsup tell me for example:

  Parsing supfile /etc/cvs-supfile
  Connecting to cvsup.FreeBSD.org
  Connected to cvsup.FreeBSD.org
  Server software version: SNAP_16_1e
  Negotiating file attribute support
  Exchanging collection information

  Premature EOF from server
  Will retry at 10:48:21
  
  And with mirrors is the same situation.

  All comments welcome!

Vl.




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