Re: The choice of MAXPHYS

[Warner Losh]

In message <19990603231216.a36...@hal.mpn.cp.philips.com> Jos Backus writes:
: On Thu, Jun 03, 1999 at 07:30:20PM +0200, Wilko Bulte wrote:
: > 20 bits. But older cards can do no more than 64 kB.
: 
: Indeed, 20 bits (=1 Mbyte) for the address, 16 bits for the transfer counter
: (offset).

Isn't that 24 bits for addresses?  You can dma from an ISA card to
anywhere in the first 16M...

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: m3socks and cvsup

[Udo Schweigert]

On Tue, Jun 08, 1999 at 12:24:36AM -0600, Warner Losh wrote:
> In message <19990601190941.46f9f29...@localhost.localdomain> Christian Murray 
> writes:
> : I have some problems with m3socks and cvsup.
> 
> I've never been able to make this work.  You might try -P m and adding
> a netcat redirector or 10 on your gateway machine.
> 

I'm using it (runsocks cvsup -P m) for a year now and it works without 
any problems. (Since cvsup 16 the "-P m" is not needed, so "runsocks cvsup"
should so it).

Regards
---
Udo Schweigert  || Voice  : +49 89 636 42170
Siemens AG, Siemens CERT|| Fax: +49 89 636 48000
ZT IK 3 || email  : udo.schweig...@mchp.siemens.de
D-81730 Muenchen / Germany  ||: u...@cert.siemens.de
PGP fingerprint || 2A 53 F6 A6 30 59 64 02  6B C4 E0 73 B2 C9 6C E7
---


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: The choice of MAXPHYS

[Warner Losh]

In message

Zhihui Zhang writes: 
: The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
: size. I am wondering why it is not set larger.

I don't think that it is possible to guarantee that you can do a
larger write than 64k on a aha-1542 card given the worst case scatter
gather list you can have in FreeBSD.  I think that this used to be a
common limit.  I thought CAM raised the limit somewhat on cards that
could support it.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: m3socks and cvsup

[Warner Losh]

In message <19990601190941.46f9f29...@localhost.localdomain> Christian Murray 
writes:
: I have some problems with m3socks and cvsup.

I've never been able to make this work.  You might try -P m and adding
a netcat redirector or 10 on your gateway machine.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Kernel config script

[Warner Losh]

In message
<14162.35022.502546.522...@r84aap011262.sbo-smr.ma.cable.rcn.com>
Robert Huff writes: 
:   How often _do_ people rebuild their kernels?  (On non-testing
: machines.)

On my stable machines never, or very rarely.  I have machines in my
basement that tend to have 200-500 day uptimes between reboots (I like
my UPS), and I put a new kernel on every 10 reboots or so (note that
just because we typically have 200 day uptimes doesn't mean it is 2000
days since I last rebuilt the kernel).

On the machine I'm typing on right now, it varies from every couple of
minutes to every couple of weeks.  I do a 'config HARMONY' only when
required.

On the machines at work in the test lab, I build between 50 and 200
kernels in a week.  I do about 1 config a week, since the kernel is
fairly stable (we don't track -current or -stable, but pick good
points in time), modulo whatever bug(s) I'm working on.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Kernel config script

[Warner Losh]

In message <199905302213.raa05...@home.dragondata.com> Kevin Day writes:
: 1) The kernel config options are only documented in LINT, which really isn't
: meant for that sorta thing, and I'll admit, they're not documented well.
: (contrast linux's config where you can hit ? and get a few paragraphs of
: info for each option, such as "If I leave this in, and don't have the
: hardware, will it cause problems?" etc...)
: 
: 2) It's not the most graceful system for newbies, switching between two
: files in a text editor is a bit much for some folks.

We're working for the day that this is a completely moot point.

There will be very few options to build the kernel with (SMP is the
only one that comes to mind but I'm sure there are others).
Everything else will be a loadable module.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Multilingual Installer for 3.2-RELEASE (Re: pccard boot.flp...)

[HOSOKAWA Tatsumi]

In article <86r9nn8nzl@hamhae.wdb.co.kr>
c...@wdb.co.kr writes:

>> It means that I should update my messages.ko_KR translation after last
>> translation? And, what is the meaning, "almost okay"?

Sorry, I added many message ID's yesterday.
The new message.lt_EN can be found in the translation kit.

--
HOSOKAWA, Tatsumi
Assistant Manager
Information Technology Center, Keio University



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Session leader releasing the ctty

[Brian Somers]

> Hello,
> 
> I'm having a trouble programming a special login shell, and would like
> to hear any opinions on this.
> 
> I want this shell (which automatically becomes a session leader) to
> release its ctty but remain unterminated (the ctty must be taken by its
> child).  However, there seems to be no easy way to do this; termios(4)
> says one must call setsid() to release its ctty, but setsid(2) says the
> call will fail if the caller is already a session leader.
> 
> Would there be any other way for a session leader to release its ctty
> without terminating itself?  TIA.

You need to also drop your process id so that you're not the owner of 
the process group that the terminal points at.  Check bundle_setsid() 
in src/usr.sbin/ppp/bundle.c.  A second fork() is done here because 
the parent may continue and doesn't want to figure out how to reap 
the child - you probably don't need this if the original process is 
going to go away soon anyway.

> Cheers,
> Eugene Kim
> 
> PS. I'm now using a workaround that the shell will forward the SIGHUP
> that it received because it's a session leader, but this isn't a clean
> way. :-p
> 
> -- 
> Eugene M. Kim NTT Multimedia Communications Laboratories
> Software Developer   250 Cambridge Avenue, Suite 205
> +1 650 833 3630 (Voice) Palo Alto, CA 94040, USA
> +1 650 833 3633 (Fax) mailto:g...@nttmcl.com

-- 
Brian 
     
Don't _EVER_ lose your sense of humour !  




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: sgmlformat & making release

[John W. DeBoskey]

Hi,

   I too see this type of failure until I can download the appropriate
distfiles into /usr/ports/distfiles... 

   The file /etc/resolv.conf is copied from /etc to the chroot
area and is probably ok. I typically find that my upstream
domain name server is not responding correctly when this happens.

   From /usr/src/release/Makefile:

if [ -f /etc/resolv.conf ]; then \
cp -p /etc/resolv.conf ${CHROOTDIR}/etc; \
fi

   Again, From /usr/src/release/Makefile, this should copy any ports
from /usr/ports/distfiles into the associated chroot area:

if [ -d ${DISTFILES}/ ]; then \
cp -rp ${DISTFILES} ${CHROOTDIR}/usr/ports/distfiles; \ 
fi

   Hope this helps.

-John


> Wilko Bulte  writes:
> > >> sgmlformat-1.7.tar.gz doesn't seem to exist on this system.
> > >> Attempting to fetch from
> > http://fallout.campusview.indiana.edu/ports/distfiles/.
> > fetch: reading reply from fallout.campusview.indiana.edu: Operation timed
> > out
> > >> Attempting to fetch from
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/.
> > fetch: ftp.freebsd.org: Host name lookup failure
> > >> Couldn't fetch it - please try to retrieve this
> > >> port manually into /usr/ports/distfiles/ and try again.
> > *** Error code 1
> > 
> > Stop.
> > *** Error code 1
> > 
> 
> The build is running in a chroot tree which does not have a valid
> /etc/resolv.conf.
> 
> > yedi#ls /usr/ports/distfiles
> > docbk241.tar.Z  isoENTS.zip linuxdoc-1.1.tar.gz
> > docbk30.tar.Z   jade-1.2.1.tar.gz   sgmlformat-1.7.tar.gz
> 
> This is outside the chroot tree.
> 
> DES
> - -- 
> Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 
> --
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Multilingual Installer for 3.2-RELEASE (Re: pccard boot.flp...)

[CHOI, Junho]

> "HT" == HOSOKAWA Tatsumi  writes:

HT> Now, the Current Translation Status is:
HT> ---
HT> JapaneseKorean
HT> ---
HT> sysinstall messages:almost okay NG
HT> help files: almost okay almost okay
HT> ---

It means that I should update my messages.ko_KR translation after last
translation? And, what is the meaning, "almost okay"?

-- 
 ** Any opinions in this posting are my own and not those of my employers **
 CHOI, Junho   
 - Korea FreeBSD Users Group   
 - Web Data Bank Co. Seoul., ROK.   (+82-2-515-9941)


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

kernel panic maybe due to VM instability in 3.1R

[Jeong Sung Won]

I am using FreeBSD-3.1-RELEASE
I met panic.
Panic occured at FIONREAD ioctl().
I found it was called at rdchk() at rbsb.c in lrzsz 0.12.16 packages.
Before panic, there was kernel warning message 
--- "b_to_q to a clist with no reserved cblocks".
Is it related ?
Following is gdb output for core dump.


  - gdb output 

  # gdb -k /sys/compile/MYRI.19990430  vmcore.4
  GDB is free software and you are welcome to 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.
  GDB 4.16 (i386-unknown-freebsd),
  Copyright 1996 Free Software Foundation, Inc...
  IdlePTD 3792896
  initial pcb at 2e598c
  panicstr: from debugger
  panic messages:
  ---
  Fatal trap 12: page fault while in kernel mode
  fault virtual address   = 0x5480345f
  fault code  = supervisor read, page not present
  instruction pointer = 0x8:0xf016d01d
  stack pointer   = 0x10:0xfd69bec4
  frame pointer   = 0x10:0xfd69bf60
  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 = 69172 (IMP-lsz-0.12.16)
  interrupt mask  =
  panic: from debugger
  panic: from debugger

  dumping to dev 20401, offset 1572864
  dump 256 255 254 253 252 251 250 249 248  ...
  17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
  ---
  #0  boot (howto=260) at ../../kern/kern_shutdown.c:285
  285 dumppcb.pcb_cr3 = rcr3();
  (kgdb)  bt
  #0  boot (howto=260) at ../../kern/kern_shutdown.c:285
  #1  0xf016209d in panic (fmt=0xf0277128 "from debugger")
  at ../../kern/kern_shutdown.c:446
  #2  0xf012b3c5 in db_panic (addr=-266940387, have_addr=0, count=1,
  modif=0xfd69bd48 "") at ../../ddb/db_command.c:432
  #3  0xf012b365 in db_command (last_cmdp=0xf02b3920, cmd_table=0xf02b3780,
  aux_cmd_tablep=0xf02e317c) at ../../ddb/db_command.c:332
  #4  0xf012b42a in db_command_loop () at ../../ddb/db_command.c:454
  #5  0xf012d77b in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
  #6  0xf023f55e in kdb_trap (type=12, code=0, regs=0xfd69be88)
  at ../../i386/i386/db_interface.c:157
  #7  0xf02497d8 in trap_fatal (frame=0xfd69be88, eva=1417688159)
  at ../../i386/i386/trap.c:937
  #8  0xf02494b7 in trap_pfault (frame=0xfd69be88, usermode=0, eva=1417688159)
  at ../../i386/i386/trap.c:835
  #9  0xf02490ea in trap (frame={tf_es = -31850480, tf_ds = -43843568,
tf_edi = 4, tf_esi = -238539008, tf_ebp = -43401376, tf_isp = -43401552,
tf_ebx = -238632704, tf_edx = 0, tf_ecx = 1074030207,
tf_eax = -238658276, tf_trapno = 12, tf_err = 0, tf_eip = -266940387,
tf_cs = 8, tf_eflags = 66050, tf_esp = -43804224, tf_ss = -265588232})
  at ../../i386/i386/trap.c:437
  #10 0xf016d01d in ioctl (p=0xfd6399c0, uap=0xfd69bf94)
  at ../../kern/sys_generic.c:445
  #11 0xf0249a47 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272639696,
tf_esi = 84992, tf_ebp = -272642208, tf_isp = -43401244, tf_ebx = 105,
tf_edx = 85380, tf_ecx = 38099, tf_eax = 54, tf_trapno = 7, tf_err = 7,
tf_eip = 537363601, tf_cs = 31, tf_eflags = 646, tf_esp = -272642224,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
  #12 0x20078491 in ?? ()
  #13 0x7193 in ?? ()
  #14 0x69f7 in ?? ()
  #15 0x49bd in ?? ()
  #16 0x4450 in ?? ()
  #17 0x3afe in ?? ()
  #18 0x38f8 in ?? ()
  #19 0x1095 in ?? ()
  (kgdb) up 10
  #10 0xf016d01d in ioctl (p=0xfd6399c0, uap=0xfd69bf94)
  at ../../kern/sys_generic.c:445
  445 } else if ((com&IOC_OUT) && size)
  (kgdb) l ioctl
  389 /* ARGSUSED */
  390 int
  391 ioctl(p, uap)
  392 struct proc *p;
  393 register struct ioctl_args *uap;
  394 {
  395 register struct file *fp;
  396 register struct filedesc *fdp;
  397 register u_long com;
  398 int error;
  (kgdb) p  *uap
  $1 = {Segmentation fault (core dumped)
  ~ (gdb paniced here)

(kgdb) up
  #11 0xf0249a47 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272639696,
tf_esi = 84992, tf_ebp = -272642208, tf_isp = -43401244, tf_ebx = 105,
tf_edx = 85380, tf_ecx = 38099, tf_eax = 54, tf_trapno = 7, tf_err = 7,
tf_eip = 537363601, tf_cs = 31, tf_eflags = 646, tf_esp = -272642224,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
  1100error = (*callp->sy_call)(p, args);
  (kgdb) l syscall
  ...
  1032void
  1033syscall(frame)
  1034struct trapframe frame;
  1035{
  1036caddr_t params;
  1037int i;
  ...
1083if (params && (i = callp->sy_narg * sizeof(int)) &&
  1084(error = copyin(params, (caddr_t)args, (u_int)i))) {
  ...
  1089goto bad;

Re: Session leader releasing the ctty

[Julian Elischer]

you might look to see if 'screen' (in ports)
has something that does this when it disconnects from a session.
(just an idea)

julian


On Mon, 7 Jun 1999, Eugene M. Kim wrote:

> Hello,
> 
> I'm having a trouble programming a special login shell, and would like
> to hear any opinions on this.
> 
> I want this shell (which automatically becomes a session leader) to
> release its ctty but remain unterminated (the ctty must be taken by its
> child).  However, there seems to be no easy way to do this; termios(4)
> says one must call setsid() to release its ctty, but setsid(2) says the
> call will fail if the caller is already a session leader.
> 
> Would there be any other way for a session leader to release its ctty
> without terminating itself?  TIA.
> 
> Cheers,
> Eugene Kim
> 
> PS. I'm now using a workaround that the shell will forward the SIGHUP
> that it received because it's a session leader, but this isn't a clean
> way. :-p
> 
> -- 
> Eugene M. Kim NTT Multimedia Communications Laboratories
> Software Developer   250 Cambridge Avenue, Suite 205
> +1 650 833 3630 (Voice) Palo Alto, CA 94040, USA
> +1 650 833 3633 (Fax) mailto:g...@nttmcl.com
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Session leader releasing the ctty

[Eugene M. Kim]

Hello,

I'm having a trouble programming a special login shell, and would like
to hear any opinions on this.

I want this shell (which automatically becomes a session leader) to
release its ctty but remain unterminated (the ctty must be taken by its
child).  However, there seems to be no easy way to do this; termios(4)
says one must call setsid() to release its ctty, but setsid(2) says the
call will fail if the caller is already a session leader.

Would there be any other way for a session leader to release its ctty
without terminating itself?  TIA.

Cheers,
Eugene Kim

PS. I'm now using a workaround that the shell will forward the SIGHUP
that it received because it's a session leader, but this isn't a clean
way. :-p

-- 
Eugene M. Kim NTT Multimedia Communications Laboratories
Software Developer   250 Cambridge Avenue, Suite 205
+1 650 833 3630 (Voice) Palo Alto, CA 94040, USA
+1 650 833 3633 (Fax) mailto:g...@nttmcl.com



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: problem for the VM gurus

[Howard Goldstein]

On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman  
wrote:
 : On Mon, 7 Jun 1999, Matthew Dillon wrote:
 : > ... what version of the operating system?
 : 4.0-CURRENT

3.2R too...


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Strange kernel messages

[Brian Feldman]

I don't know why it's there, but that seems to be the sysctl tree.

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \._ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: problem for the VM gurus

[Brian Feldman]

On Mon, 7 Jun 1999, Matthew Dillon wrote:

> ... what version of the operating system?
> 
>   -Matt

4.0-CURRENT

> 
> :  In the long-standing tradition of deadlocks, I present to you all a new 
> one.
> :This one locks in getblk, and causes other processes to lock in inode. It's
> :easy to induce, but I have no idea how I'd go about fixing it myself
> :(being very new to that part of the kernel.)
> :  Here's the program which induces the deadlock:
> :
> :#include 
> :#include 
> :...
> 

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \._ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: help with I/O optimization with object

[Zhihui Zhang]

On Mon, 7 Jun 1999, Zhihui Zhang wrote:

> 
> While studying the file ufs_readwrite.c, I see routines like uiomoveco() 
> that calls vm_uiomove() in vm_map.c.  I am almost sure that these are new
> in FreeBSD 3.x. The comment in ffs_read() says "not a VM based I/O
> requests"  == "not headed for the buffer cache". This does not make sense
> to me although I understand something about VMIO buffers and non-VMIO
> buffers. I hope someone can explain the basic ideas of I/O optimization
> with VM object (relating to the OBJ_OPT flag and the global variable
> vfs_ioopt) so that I can understand the code easier. 
> 

After searching the mailing list archive for some time and tracing down
who calls vm_uiomove(), it seems to me that this is the zero copy read
stuff used to read data into the current process' address space.  However,
I do not know when it can be useful or any more details.

-Zhihui



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: netiso tree (fwd)

[Andy Doran]

The 'netiso' and 'netccitt' trees are still included in NetBSD.

- ad

On Mon, 7 Jun 1999, Alfred Perlstein wrote:

> -- Forwarded message --
> Date: Mon, 07 Jun 1999 15:23:57 -0400
> From: Spud Taylor 
> To: freebsd-questi...@freebsd.org
> Subject: netiso tree
> 
> We have been using Free BSD and BSDI since 1992.  There was a descision
> to eliminate the netiso and netccitt trees in the OS a few years ago.
> Can these trees still be obtained and where can I obtain them from?  I
> am having a problem reading raw CLNP PDUs because of the way BSD used
> to do it vs the way it is done now with the isopcbhead and isopcblist.
> If you could point me in the correct difre4ction, I would appreciate it.
> We have done extensive kernel programming and are familiar with what it
> will take to port a netiso tree into our current environment.  Thank
> you for your time and I look forward to hearing an answer from you.
> Lynn Taylor
> Senior Engineer
> Planning Systems Inc
> McLean, Va.
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-questions" in the body of the message
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: problem for the VM gurus

[Matthew Dillon]

... what version of the operating system?

-Matt

:  In the long-standing tradition of deadlocks, I present to you all a new one.
:This one locks in getblk, and causes other processes to lock in inode. It's
:easy to induce, but I have no idea how I'd go about fixing it myself
:(being very new to that part of the kernel.)
:  Here's the program which induces the deadlock:
:
:#include 
:#include 
:...


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: netiso tree (fwd)

[John-Mark Gurney]

Alfred Perlstein scribbled this message on Jun 7:
> -- Forwarded message --
> Date: Mon, 07 Jun 1999 15:23:57 -0400
> From: Spud Taylor 
> To: freebsd-questi...@freebsd.org
> Subject: netiso tree
> 
> We have been using Free BSD and BSDI since 1992.  There was a descision
> to eliminate the netiso and netccitt trees in the OS a few years ago.
> Can these trees still be obtained and where can I obtain them from?  I
> am having a problem reading raw CLNP PDUs because of the way BSD used
> to do it vs the way it is done now with the isopcbhead and isopcblist.
> If you could point me in the correct difre4ction, I would appreciate it.
> We have done extensive kernel programming and are familiar with what it
> will take to port a netiso tree into our current environment.  Thank
> you for your time and I look forward to hearing an answer from you.

take a look at cvsup'ing the RELENG_2_1_7_RELEASE brach of the FreeBSD
kernel to obtain this code...  it looks like that was the last branch
that the code was on...  or if you can get your hands on the kernel
source dist from 2.1.7-R they should have it..

-- 
  John-Mark Gurney  Voice: +1 541 684 8449
  Cu Networking   P.O. Box 5693, 97405

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

netiso tree (fwd)

[Alfred Perlstein]

-Alfred 

-- Forwarded message --
Date: Mon, 07 Jun 1999 15:23:57 -0400
From: Spud Taylor 
To: freebsd-questi...@freebsd.org
Subject: netiso tree

We have been using Free BSD and BSDI since 1992.  There was a descision
to eliminate the netiso and netccitt trees in the OS a few years ago.
Can these trees still be obtained and where can I obtain them from?  I
am having a problem reading raw CLNP PDUs because of the way BSD used
to do it vs the way it is done now with the isopcbhead and isopcblist.
If you could point me in the correct difre4ction, I would appreciate it.
We have done extensive kernel programming and are familiar with what it
will take to port a netiso tree into our current environment.  Thank
you for your time and I look forward to hearing an answer from you.
Lynn Taylor
Senior Engineer
Planning Systems Inc
McLean, Va.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-questions" in the body of the message



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Soren Schmidt]

It seems Chris D. Faulhaber wrote:
> 
> I have an off-brand (NEC) Zip Drive with:
>  
> which does have buggy firmware; I also have another one with:
>  
> that has no problem when I remove the 64 block limitation.
> 
> In this case, I would use strncmp instead of strcmp to test the first 27
> characters.
> 
> So what you are saying is that we are limiting all Zip drives instead of
> being based solely on firmware revision?  Any reason for that?

Hmm, well in the atapi-fd driver in the new ata/atapi system I only
check for !strncmp(atp->atapi_parm->model, "IOMEGA  ZIP", 11) which
is even more pessimistic. However the overhead added here is small
compared to the general speed of the ZIP drive, so its not a problem.

-Søren


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Mike Smith]

> On Mon, 7 Jun 1999, Mike Smith wrote:
> 
> > > 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be.
> > > Since the current method of sorting out the revisions doesn't seem to 
> > > be perfect, would it be acceptible to consider them all buggy unless known
> > > not to be (i.e. compare ap->revision instead of ap->model)?
> > 
> > Uh, that's what the code does; if it's a Zip drive, it's considered to 
> > be buggy regardless of revision.  If the string compare isn't matching 
> > a drive in the field, it means that Iomega have changed the string and 
> > we need to know what the new drives are calling themselves.
> > 
> 
> I have an off-brand (NEC) Zip Drive with:
>  
> which does have buggy firmware; I also have another one with:
>  
> that has no problem when I remove the 64 block limitation.
> 
> In this case, I would use strncmp instead of strcmp to test the first 27
> characters.

Gotcha, and that's definitely a good idea.

> So what you are saying is that we are limiting all Zip drives instead of
> being based solely on firmware revision?  Any reason for that?

No evidence suggesting that any revision ever worked or would work; the
simplest and safest technique is just to cap transfers at 32k - in
reality it doesn't affect performance at all, so there's no real need to
be extra-picky.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: linux and freebsd kernels conceptually different?

[Arun Sharma]

Christoph Kukulies  writes:

Comments from someone who's studied Linux for a while and has started
studying FreeBSD only recently.

> Could one say that Linux vs. FreeBSD kernels are conceptually
> different what task scheduling, queueing, interrupt handling,
> driver architecture, buffer caching, vm etc. is concerned?

- task scheduling

- Linux uses a linear linked list of runnable processes and
  recalculates priorities on every reschedule.

- FreeBSD uses multilevel runqueues

- Buffer caching

- Linux hasn't achieved the perfect integration between the
  page cache and the buffer cache yet. write(2) goes through
  the buffer cache, read(2) goes through the page cache. Also,
  buffers are cached based on  basis. But
  an IOlite style buffer caching scheme is in the works.

- FreeBSD seems to avoid data replication by a better
  integration of the page and buffer caches. Also, buffers are
  cached based on  basis

- VM

- Linux uses a 3 level page table as a generic data structure
  at the low level and data structures similar to SVR4 for
  high level mapping info. Also, Linux avoids chaining of ptes
  mapping the same data completely.

- FreeBSD separates machine dependent and independent data
  using the pmap abstraction. FreeBSD also uses pv_table to
  keep track of multiple ptes mapping same data. FreeBSD VM is
  based on Mach.

But for the most part, they are based on the same principles
documented in early UNIX internals text books. So it would be unfair
to say they are conceptually very different.

I'd say most of the differences are in implementation and development
methodology. Linux camp seems to be proud of breaking traditions and
concepts invented after lengthy research. I haven't seen that many
iconoclasts in my short encounter with FreeBSD.

Hope that helps,

-Arun


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Chris D. Faulhaber]

On Mon, 7 Jun 1999, Mike Smith wrote:

> > 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be.
> > Since the current method of sorting out the revisions doesn't seem to 
> > be perfect, would it be acceptible to consider them all buggy unless known
> > not to be (i.e. compare ap->revision instead of ap->model)?
> 
> Uh, that's what the code does; if it's a Zip drive, it's considered to 
> be buggy regardless of revision.  If the string compare isn't matching 
> a drive in the field, it means that Iomega have changed the string and 
> we need to know what the new drives are calling themselves.
> 

I have an off-brand (NEC) Zip Drive with:
 
which does have buggy firmware; I also have another one with:
 
that has no problem when I remove the 64 block limitation.

In this case, I would use strncmp instead of strcmp to test the first 27
characters.

So what you are saying is that we are limiting all Zip drives instead of
being based solely on firmware revision?  Any reason for that?


-
Chris D. Faulhaber   |  All the true gurus I've met never
System/Network Administrator,|  claimed they were one, and always
Reality Check Information, Inc.  |  pointed to someone better.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Mike Smith]

> On Tue, 8 Jun 1999, Junichi Satoh wrote:
> 
> > Hmm...
> > 
> > I have an ATAPI ZIP drive:
> > 
> > wdc0: unit 1 (atapi): , removable, intr, 
> > iordis
> > wfd1: medium type unknown (no disk)
> > wfd1: buggy Zip drive, 64-block transfer limit set
> > 
> > 
> > It does not work with your patch. It's a buggy drive.
> > 
> > Probably, using only strcmp() is not enough.
> > We shoud distinguish buggy or not using revision number.
> > 
> > #I don't know how many revisions are available. :-)
> > ---
> > Junichi Satoh   juni...@junichi.org
> > juni...@jp.freebsd.org
> > 
> 
> 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be.
> Since the current method of sorting out the revisions doesn't seem to 
> be perfect, would it be acceptible to consider them all buggy unless known
> not to be (i.e. compare ap->revision instead of ap->model)?

Uh, that's what the code does; if it's a Zip drive, it's considered to 
be buggy regardless of revision.  If the string compare isn't matching 
a drive in the field, it means that Iomega have changed the string and 
we need to know what the new drives are calling themselves.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

help with I/O optimization with object

[Zhihui Zhang]

While studying the file ufs_readwrite.c, I see routines like uiomoveco() 
that calls vm_uiomove() in vm_map.c.  I am almost sure that these are new
in FreeBSD 3.x. The comment in ffs_read() says "not a VM based I/O
requests"  == "not headed for the buffer cache". This does not make sense
to me although I understand something about VMIO buffers and non-VMIO
buffers. I hope someone can explain the basic ideas of I/O optimization
with VM object (relating to the OBJ_OPT flag and the global variable
vfs_ioopt) so that I can understand the code easier. 

Any help is appreciated. 

--
Zhihui Zhang.  Please visit http://www.freebsd.org
--



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Q: xl0: no memory for rx list -- packet dropped!

[Bill Paul]

Of all the gin joints in all the towns in all the world, Anthony Bourov 
had to walk into mine and say:

> Hi,
> 
> I am running a FreeBSD server, and I am running into this problem very 
> often. The machine stops responding and instead outputs 1000s of
> xl0: no memory for rx list -- packet dropped!
> xl0: no memory for rx list -- packet dropped!
> xl0: no memory for rx list -- packet dropped!
> xl0: no memory for rx list -- packet dropped!
> messages. The machine is usually pulling about 4-5 megabits but there is 
> usually a traffic spike right before this happens so an attack is not out 
> of the question, but I was wondering if there was any way I can raise the 
> threshold  for this (would more BUFFERs do the trick?).

You don't say what version of FreeBSD this is, or what driver version
you have. Sorry, but my mind reading helmet is in the shop this week.

If you're running something older than 3.2-RELEASE, try the latest
driver from http://www.freebsd.org/~wpaul/3Com. The newer version has
a larger RX and TX ring sizes. If you are running 3.2-RELEASE or later
or changing the ring sizes doesn't help, then try compiling a new
kernel with a larger value for NMBCLUSTERS, i.e.:

options "NMBCLUSTERS=2"

Actually, for newer versions of FreeBSD, you may have to do:

options NMBCLUSTERS="2"

If config(8) complains about the first syntax, try the second. This
will greatly increase the size of the mbuf cluster pool, which should
at least hold off the starvation condition for a while longer. You
might want to check the traffic on the line with tcpdump. I would
look for lots of ICMP or UDP traffic, or maybe lots of TCP segments
directed at ports where there's nothing listening.

Note: each mbuf cluster is 2K in size. 2 * 2048 == 40MB of RAM, so
you better have a lot of memory in this server. If not, try something
smaller.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home:  wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

question about Pacific Sierra HPF

[Ilia Chipitsine]

Hi, 
anybody here knows what is it about ?

/usr/home/ilia/test-hpf > hpf hello.f90 
 Pacific-Sierra Research VAST-HPF V5.1C  23:17:54   6/ 7/99   HPF 
programhello   
/home/ilia/fortran-cd/vast/vhpf_linux/lib//libvhpf_pvm.a(envnproc.o): In
function `envnproc_':
envnproc.o(.text+0xe2): undefined reference to `__ctype_b'
collect2: ld returned 1 exit status
/usr/home/ilia/test-hpf > 

Regards, (Наилучшие пожелания)

 Ilia Chipitsine (Илья Шипицин)




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Multilingual Installer for 3.2-RELEASE (Re: pccard boot.flp...)

[HOSOKAWA Tatsumi]

In article <199906071600.baa09...@afs.ntc.mita.keio.ac.jp>
hosok...@itc.keio.ac.jp writes:

>> Currently, following binary package is compiled with English, Japanese
>> and Korean support.  As a result of increased size of boot.flp,
>> Japanese and Korean support is now merged again into the same boot.flp
>> image.

I recieved translated Japanese document files just after I sent last
mail.  I recompiled these files again and replaced with the old ones.

>> http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/floppies-19990608.tar.gz
>>  (Compiled boot.flp, kern.flp, and mfsroot.flp binaries)
>> 
>> http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/release-19990608.tar.gz
>>  (Patched source tree of /usr/src/release)
>> 
>> http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/translation-kit-19990608.tar.gz
>>  (All you have to translate is this tarball)
>> 
>> Current Translation Status:
>> ---
>>  JapaneseKorean
>> ---
>> sysinstall messages: almost okay NG
>> help files:  NG  almost okay
>> ---


Now, the Current Translation Status is:
---
JapaneseKorean
---
sysinstall messages:almost okay NG
help files: almost okay almost okay
---

--
HOSOKAWA, Tatsumi
Assistant Manager
Information Technology Center, Keio University



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Q: xl0: no memory for rx list -- packet dropped!

[Anthony Bourov]

Hi,

I am running a FreeBSD server, and I am running into this problem very 
often. The machine stops responding and instead outputs 1000s of

xl0: no memory for rx list -- packet dropped!
xl0: no memory for rx list -- packet dropped!
xl0: no memory for rx list -- packet dropped!
xl0: no memory for rx list -- packet dropped!
messages. The machine is usually pulling about 4-5 megabits but there is 
usually a traffic spike right before this happens so an attack is not out 
of the question, but I was wondering if there was any way I can raise the 
threshold  for this (would more BUFFERs do the trick?).


Thanks in advance,
Anthony


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

RE: linux and freebsd kernels conceptually different?

[Alton, Matthew]

Yes, quite.

> -Original Message-
> From: Christoph Kukulies [SMTP:k...@gilberto.physik.rwth-aachen.de]
> Sent: Monday, June 07, 1999 10:59 AM
> To:   hack...@freebsd.org
> Subject:  linux and freebsd kernels conceptually different?
> 
> Could one say that Linux vs. FreeBSD kernels are conceptually
> different what task scheduling, queueing, interrupt handling,
> driver architecture, buffer caching, vm etc. is concerned?
> 
> -- 
> Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Chris D. Faulhaber]

Here is a patch that checks for the revision numbers instead of simply the
inquiry string (and adds my buggy revision):

--- wfd.c.orig  Thu Feb 18 17:06:08 1999
+++ wfd.c   Mon Jun  7 12:02:25 1999
@@ -243,17 +243,21 @@
return -1;

/*
-* The IOMEGA ZIP 100, at firmware 21.* and 23.* at least
+* The IOMEGA ZIP 100, at firmware 12.A, 21.* and 23.* at least
 * is known to lock up if transfers > 64 blocks are
 * requested.
 */
-   if (!strcmp(ap->model, "IOMEGA  ZIP 100   ATAPI")) {
-   printf("wfd%d: buggy Zip drive, 64-block transfer limit
set\n",
-  t->lun);
-   t->maxblks = 64;
-   } else {
-   t->maxblks = 0; /* no limit */
-   }
+
+   if (!strncmp(ap->model, "IOMEGA  ZIP 100   ATAPI", 27))
+   if ((!strncmp(ap->revision, "12", 2)) ||
+   (!strncmp(ap->revision, "21", 2)) ||
+   (!strncmp(ap->revision, "23", 2))) {
+   printf("wfd%d: buggy Zip drive, 64-block transfer 
limit set\n",
+   t->lun);
+   t->maxblks = 64;
+   } else {
+   t->maxblks = 0; /* no limit */
+   }


-
Chris D. Faulhaber   |  All the true gurus I've met never
System/Network Administrator,|  claimed they were one, and always
Reality Check Information, Inc.  |  pointed to someone better.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Multilingual Installer for 3.2-RELEASE (Re: pccard boot.flp...)

[HOSOKAWA Tatsumi]

In <199906060553.oaa24...@afs.ntc.mita.keio.ac.jp> I wrote,

>> Thank you.  Now I'm working on updated sysinstall messages.
>> I'll send the URL of message.lt_EN, *.TXT, *.hlp files to translate 
>> when I finished this work.
>> I want translators to other languages.  

I finished updating indices of messages, and complied the first public
test version.

Currently, following binary package is compiled with English, Japanese
and Korean support.  As a result of increased size of boot.flp,
Japanese and Korean support is now merged again into the same boot.flp
image.

http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/floppies-19990608.tar.gz
(Compiled boot.flp, kern.flp, and mfsroot.flp binaries)

http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/release-19990608.tar.gz
(Patched source tree of /usr/src/release)

http://wing-yee.ntc.keio.ac.jp/hosokawa/32flp/translation-kit-19990608.tar.gz
(All you have to translate is this tarball)

Current Translation Status:
---
JapaneseKorean
---
sysinstall messages:almost okay NG
help files: NG  almost okay
---

--
HOSOKAWA, Tatsumi
Assistant Manager
Information Technology Center, Keio University



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

linux and freebsd kernels conceptually different?

[Christoph Kukulies]

Could one say that Linux vs. FreeBSD kernels are conceptually
different what task scheduling, queueing, interrupt handling,
driver architecture, buffer caching, vm etc. is concerned?

-- 
Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Extra text modes via vidcontrol...

[bush doctor]

Quoting Dag-Erling Smorgrav (d...@flood.ping.uio.no):
> Kazutaka YOKOTA  writes:
> > >su-2.02# config BANTU
> > >BANTU:135: unknown option "VM86"
> > >Unknown option used - it is VERY important that you do
> > > make clean && make depend
> > >before recompiling
> > >Kernel build directory is ../../compile/BANTU
> > 
> > Umm, this means that your source tree is not as current as it should
> > be, in order to be called "4.0-CURRENT".  The VM86 option was added to
> > the -CURRENT branch long before 3.0-RELEASE!  How are you updating
> > your source tree in /usr/src?
> 
> VM86 is no longer an option. Remove it, and everything will be fine.
Noted.  thanxs ...

> 
> DES
> -- 
> Dag-Erling Smorgrav - d...@flood.ping.uio.no
> 

#;^)
-- 
So ya want ta here da roots?
Dem that feels it knows it ...
bush doctor 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: egcs - kernel?

[Chris Costello]

On Mon, Jun 7, 1999, Christoph Kukulies wrote:
> What is the status of the EGCS compiler WRT kernel build?
> (And world build in general?)

   It's been working great for ages in -CURRENT.  I don't know
how it may handle in -STABLE, though.

-- 
Chris Costello
It said, "Insert disk #3," but only two will fit!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

egcs - kernel?

[Christoph Kukulies]

What is the status of the EGCS compiler WRT kernel build?
(And world build in general?)

-- 
Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Chris D. Faulhaber]

On Tue, 8 Jun 1999, Junichi Satoh wrote:

> Hmm...
> 
> I have an ATAPI ZIP drive:
> 
> wdc0: unit 1 (atapi): , removable, intr, 
> iordis
> wfd1: medium type unknown (no disk)
> wfd1: buggy Zip drive, 64-block transfer limit set
> 
> 
> It does not work with your patch. It's a buggy drive.
> 
> Probably, using only strcmp() is not enough.
> We shoud distinguish buggy or not using revision number.
> 
> #I don't know how many revisions are available. :-)
> ---
> Junichi Satoh juni...@junichi.org
>   juni...@jp.freebsd.org
> 

12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be.
Since the current method of sorting out the revisions doesn't seem to 
be perfect, would it be acceptible to consider them all buggy unless known
not to be (i.e. compare ap->revision instead of ap->model)?

-
Chris D. Faulhaber   |  All the true gurus I've met never
System/Network Administrator,|  claimed they were one, and always
Reality Check Information, Inc.  |  pointed to someone better.




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Extra text modes via vidcontrol...

[Dag-Erling Smorgrav]

Kazutaka YOKOTA  writes:
> >su-2.02# config BANTU
> >BANTU:135: unknown option "VM86"
> >Unknown option used - it is VERY important that you do
> > make clean && make depend
> >  before recompiling
> >  Kernel build directory is ../../compile/BANTU
> 
> Umm, this means that your source tree is not as current as it should
> be, in order to be called "4.0-CURRENT".  The VM86 option was added to
> the -CURRENT branch long before 3.0-RELEASE!  How are you updating
> your source tree in /usr/src?

VM86 is no longer an option. Remove it, and everything will be fine.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: wfd.c and ATAPI Zip

[Junichi Satoh]

>> My thoughts now are:
>> 1) My two drive are somewhat 'rogue' in that they don't conform to the
>> driver's expectations.
>> 2) When the driver was written, the '!strcmp' should be 'strcmp' since
>> strcmp returns 0 when equal (-1 or 1 when < or >), in which case my patch 
>> makes sense:
>> 
>> --- /sys/i386/isa/wfd.c.origThu Feb 18 17:06:08 1999
>> +++ /sys/i386/isa/wfd.c Tue Jun  6 08:59:59 1999
>> @@ -247,7 +247,7 @@
>>  * is known to lock up if transfers > 64 blocks are
>>  * requested.
>>  */
>> -   if (!strcmp(ap->model, "IOMEGA  ZIP 100   ATAPI")) {
>> +   if (strcmp(ap->model, "IOMEGA  ZIP 100   ATAPI")) {
>> printf("wfd%d: buggy Zip drive, 64-block transfer limit 
>> set\n",
>>t->lun);
>> t->maxblks = 64;
>> 
>> 3) I've just plain lost it :)
>> 
>> Can anyone else with an ATAPI Zip Drive confirm this?
Hmm...

I have an ATAPI ZIP drive:

wdc0: unit 1 (atapi): , removable, intr, 
iordis
wfd1: medium type unknown (no disk)
wfd1: buggy Zip drive, 64-block transfer limit set


It does not work with your patch. It's a buggy drive.

Probably, using only strcmp() is not enough.
We shoud distinguish buggy or not using revision number.

#I don't know how many revisions are available. :-)
---
Junichi Satoh   juni...@junichi.org
juni...@jp.freebsd.org


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Extra text modes via vidcontrol...

[Kazutaka YOKOTA]

>> Are you sure you enabled "options VM86" in the kernel configuration
>> file and loaded the vesa module by the boot loader?
>Hmmm ...
>When I added "options VM86" to my kernel config file I get:
>
>su-2.02# config BANTU
>BANTU:135: unknown option "VM86"
>Unknown option used - it is VERY important that you do
> make clean && make depend
>before recompiling
>Kernel build directory is ../../compile/BANTU

Umm, this means that your source tree is not as current as it should
be, in order to be called "4.0-CURRENT".  The VM86 option was added to
the -CURRENT branch long before 3.0-RELEASE!  How are you updating
your source tree in /usr/src?

>bantu.cl.msu.edu:dervish> uname -a
>FreeBSD bantu.cl.msu.edu 4.0-CURRENT FreeBSD 4.0-CURRENT #19: Thu Jun  3 13:54
>:15 EDT 1999 r...@bantu.cl.msu.edu:/usr/src/sys/compile/BANTU  i386
>
>I did get splash screen to work with the default 320x200 bmp files ...
>The files I'm working with are from
>   http://advocacy.freebsd.org/ammunition/splash.html

Good!

Kazu


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Extra text modes via vidcontrol...

[bush doctor]

Quoting Kazutaka YOKOTA (yok...@zodiac.mech.utsunomiya-u.ac.jp):

[snip, snip]
> Are you sure you enabled "options VM86" in the kernel configuration
> file and loaded the vesa module by the boot loader?
Hmmm ...
When I added "options VM86" to my kernel config file I get:

su-2.02# config BANTU
BANTU:135: unknown option "VM86"
Unknown option used - it is VERY important that you do
 make clean && make depend
 before recompiling
 Kernel build directory is ../../compile/BANTU

bantu.cl.msu.edu:dervish> uname -a
FreeBSD bantu.cl.msu.edu 4.0-CURRENT FreeBSD 4.0-CURRENT #19: Thu Jun  3 
13:54:15 EDT 1999 r...@bantu.cl.msu.edu:/usr/src/sys/compile/BANTU  i386

I did get splash screen to work with the default 320x200 bmp files ...
The files I'm working with are from
http://advocacy.freebsd.org/ammunition/splash.html


#;^)
-- 
So ya want ta here da roots?
Dem that feels it knows it ...
bush doctor 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

panic at FIONREAD ioctl() may be due to syscall()

[swjeong]

I am using FreeBSD-3.1-RELEASE
I met panic.
Panic occured at FIONREAD ioctl().
I found it was called at rdchk() at rbsb.c in lrzsz 0.12.16 packages.
Before panic, there was kernel warning message 
--- "b_to_q to a clist with no reserved cblocks".
Is it related ?
Following is gdb output for core dump.


  - gdb output 

  # gdb -k /sys/compile/MYRI.19990430  vmcore.4
  GDB is free software and you are welcome to 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.
  GDB 4.16 (i386-unknown-freebsd),
  Copyright 1996 Free Software Foundation, Inc...
  IdlePTD 3792896
  initial pcb at 2e598c
  panicstr: from debugger
  panic messages:
  ---
  Fatal trap 12: page fault while in kernel mode
  fault virtual address   = 0x5480345f
  fault code  = supervisor read, page not present
  instruction pointer = 0x8:0xf016d01d
  stack pointer   = 0x10:0xfd69bec4
  frame pointer   = 0x10:0xfd69bf60
  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 = 69172 (IMP-lsz-0.12.16)
  interrupt mask  =
  panic: from debugger
  panic: from debugger

  dumping to dev 20401, offset 1572864
  dump 256 255 254 253 252 251 250 249 248  ...
  17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
  ---
  #0  boot (howto=260) at ../../kern/kern_shutdown.c:285
  285 dumppcb.pcb_cr3 = rcr3();
  (kgdb)  bt
  #0  boot (howto=260) at ../../kern/kern_shutdown.c:285
  #1  0xf016209d in panic (fmt=0xf0277128 "from debugger")
  at ../../kern/kern_shutdown.c:446
  #2  0xf012b3c5 in db_panic (addr=-266940387, have_addr=0, count=1,
  modif=0xfd69bd48 "") at ../../ddb/db_command.c:432
  #3  0xf012b365 in db_command (last_cmdp=0xf02b3920, cmd_table=0xf02b3780,
  aux_cmd_tablep=0xf02e317c) at ../../ddb/db_command.c:332
  #4  0xf012b42a in db_command_loop () at ../../ddb/db_command.c:454
  #5  0xf012d77b in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
  #6  0xf023f55e in kdb_trap (type=12, code=0, regs=0xfd69be88)
  at ../../i386/i386/db_interface.c:157
  #7  0xf02497d8 in trap_fatal (frame=0xfd69be88, eva=1417688159)
  at ../../i386/i386/trap.c:937
  #8  0xf02494b7 in trap_pfault (frame=0xfd69be88, usermode=0, eva=1417688159)
  at ../../i386/i386/trap.c:835
  #9  0xf02490ea in trap (frame={tf_es = -31850480, tf_ds = -43843568,
tf_edi = 4, tf_esi = -238539008, tf_ebp = -43401376, tf_isp = -43401552,
tf_ebx = -238632704, tf_edx = 0, tf_ecx = 1074030207,
tf_eax = -238658276, tf_trapno = 12, tf_err = 0, tf_eip = -266940387,
tf_cs = 8, tf_eflags = 66050, tf_esp = -43804224, tf_ss = -265588232})
  at ../../i386/i386/trap.c:437
  #10 0xf016d01d in ioctl (p=0xfd6399c0, uap=0xfd69bf94)
  at ../../kern/sys_generic.c:445
  #11 0xf0249a47 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272639696,
tf_esi = 84992, tf_ebp = -272642208, tf_isp = -43401244, tf_ebx = 105,
tf_edx = 85380, tf_ecx = 38099, tf_eax = 54, tf_trapno = 7, tf_err = 7,
tf_eip = 537363601, tf_cs = 31, tf_eflags = 646, tf_esp = -272642224,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
  #12 0x20078491 in ?? ()
  #13 0x7193 in ?? ()
  #14 0x69f7 in ?? ()
  #15 0x49bd in ?? ()
  #16 0x4450 in ?? ()
  #17 0x3afe in ?? ()
  #18 0x38f8 in ?? ()
  #19 0x1095 in ?? ()
  (kgdb) up 10
  #10 0xf016d01d in ioctl (p=0xfd6399c0, uap=0xfd69bf94)
  at ../../kern/sys_generic.c:445
  445 } else if ((com&IOC_OUT) && size)
  (kgdb) l ioctl
  389 /* ARGSUSED */
  390 int
  391 ioctl(p, uap)
  392 struct proc *p;
  393 register struct ioctl_args *uap;
  394 {
  395 register struct file *fp;
  396 register struct filedesc *fdp;
  397 register u_long com;
  398 int error;
  (kgdb) p  *uap
  $1 = {Segmentation fault (core dumped)

(kgdb) up
  #11 0xf0249a47 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272639696,
tf_esi = 84992, tf_ebp = -272642208, tf_isp = -43401244, tf_ebx = 105,
tf_edx = 85380, tf_ecx = 38099, tf_eax = 54, tf_trapno = 7, tf_err = 7,
tf_eip = 537363601, tf_cs = 31, tf_eflags = 646, tf_esp = -272642224,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
  1100error = (*callp->sy_call)(p, args);
  (kgdb) l syscall
  ...
  1032void
  1033syscall(frame)
  1034struct trapframe frame;
  1035{
  1036caddr_t params;
  1037int i;
  ...
1083if (params && (i = callp->sy_narg * sizeof(int)) &&
  1084(error = copyin(params, (caddr_t)args, (u_int)i))) {
  ...
  1089goto bad;
  (kgdb) l
  1090}
  
  1095p->

Strange kernel messages

[Alexander Maret]

Hello,

I got the following kernel messages. Does anybody know what
caused this messages? Is this the first sign of upcoming problems?

Jun  5 21:05:01 mail /kernel: 128 v_inactive_target R  *Handler Int
Jun  5 21:05:01 mail /kernel: 129 v_inactive_count R  *Handler Int
Jun  5 21:05:01 mail /kernel: 130 v_cache_count R  *Handler Int
Jun  5 21:05:01 mail /kernel: 131 v_cache_min R  *Handler Int
Jun  5 21:05:01 mail /kernel: 132 v_cache_max R  *Handler Int
Jun  5 21:05:01 mail /kernel: 133 v_pageout_free_min R  *Handler Int
Jun  5 21:05:01 mail /kernel: 134 v_interrupt_free_min R  *Handler Int
Jun  5 21:05:02 mail /kernel: 102 misc RW Node
Jun  5 21:05:02 mail /kernel: 100 zero_page_count R  *Handler Int
Jun  5 21:05:02 mail /kernel: 101 cnt_prezero R  *Handler Int
Jun  5 21:05:02 mail /kernel: 114 pageout_stats_max RW *Handler Int
Jun  5 21:05:02 mail /kernel: 115 pageout_full_stats_interval RW *Handler
Int
Jun  5 21:05:02 mail /kernel: 116 pageout_stats_interval RW *Handler Int
Jun  5 21:05:02 mail /kernel: 117 pageout_stats_free_max RW *Handler Int
Jun  5 21:05:02 mail /kernel: 118 swap_idle_enabled RW *Handler Int
Jun  5 21:05:02 mail /kernel: 119 defer_swapspace_pageouts RW *Handler Int
Jun  5 21:05:02 mail /kernel: 120 disable_swapspace_pageouts RW *Handler Int
Jun  5 21:05:02 mail /kernel: 121 max_page_launder RW *Handler Int
Jun  5 21:05:02 mail /kernel: 122 zone R  *Handler String
Jun  5 21:05:02 mail /kernel: 123 zone_kmem_pages R  *Handler Int
Jun  5 21:05:02 mail /kernel: 124 zone_kmem_kvaspace R  *Handler Int
Jun  5 21:05:02 mail /kernel: 125 zone_kern_pages R  *Handler Int
Jun  5 21:05:02 mail /kernel: 3 vfs RW Node
Jun  5 21:05:02 mail /kernel: 0 generic R  *Handler Node
Jun  5 21:05:02 mail /kernel: 100 numdirtybuffers R  *Handler Int
Jun  5 21:05:02 mail /kernel: 101 lodirtybuffers RW *Handler Int
Jun  5 21:05:02 mail /kernel: 10
Jun  5 21:05:02 mail /kernel: 2 hidirtybuffers RW *Handler Int
Jun  5 21:05:02 mail /kernel: 103 numfreebuffers R  *Handler Int
Jun  5 21:05:02 mail /kernel: 104 lofreebuffers RW *Handler Int
Jun  5 21:05:02 mail /kernel: 105 hifreebuffers RW *Handler Int
Jun  5 21:05:02 mail /kernel: 106 maxbufspace RW *Handler Int
Jun  5 21:05:02 mail /kernel: 107 bufspace R  *Handler Int
Jun  5 21:05:02 mail /kernel: 108 maxvmiobufspace RW *Handler Int
Jun  5 21:05:02 mail /kernel: 109 vmiospace R  *Handler Int
Jun  5 21:05:02 mail /kernel: 110 maxmallocbufspace RW *Handler Int
Jun  5 21:05:02 mail /kernel: 111 bufmallocspace R  *Handler Int
Jun  5 21:05:02 mail /kernel: 112 kvafreespace R  *Handler Int
Jun  5 21:05:02 mail /kernel: 113 cache RW Node
Jun  5 21:05:02 mail /kernel: 100 numneg R  *Handler Int
Jun  5 21:05:02 mail /kernel: 101 numcache R  *Handler Int
Jun  5 21:05:02 mail /kernel: 102 numcalls R  *Handler Int
Jun  5 21:05:02 mail /kernel: 103 dothits R  *Handler Int
Jun  5 21:05:02 mail /kernel: 104 dotdothits R  *Handler Int
Jun  5 21:05:02 mail /kernel: 105 numchecks R  *Handler Int
Jun  5 21:05:02 mail /kernel: 106 nummiss R  *Handler Int
Jun  5 21:05:02 mail /kernel: 107 nummisszap R  *Handler Int
Jun  5 21:05:02 mail /kernel: 108 numposzaps R  *Handler Int
Jun  5 21:05:02 mail /kernel: 109 numposhits R  *Handler Int
Jun  5 21:05:02 mail /kernel: 110 numnegzaps R  *Handler Int
Jun  5 21:05:02 mail /kernel: 111 numneghits R  *Handler Int
Jun  5 21:05:02 mail /kernel: 112 numcwdcalls R  *Handler Int
Jun  5 21:05:03 mail /kernel: 113 numcwdfail1 R  *Handler Int
Jun  5 21:05:03 mail /kernel: 114 numcwdfail2 R  *Handler Int
Jun  5 21:05:03 mail /kernel: 115 numcwdfail3 R  *Handler Int
Jun  5 21:05:03 mail /kernel: 116 numcwdfail4 R  *Handler Int
Jun  5 21:05:03 mail /kernel: 117 numcwdfound R  *Handl
Jun  5 21:05:03 mail /kernel: er Int
Jun  5 21:05:03 mail /kernel: 114 mod0 R  *Handler Int
Jun  5 21:05:03 mail /kernel: 115 mod1 R  *Handler Int
Jun  5 21:05:03 mail /kernel: 116 usermount RW *Handler Int
Jun  5 21:05:03 mail /kernel: 117 aio RW Node
Jun  5 21:05:03 mail /kernel: 100 max_aio_per_proc RW *Handler Int
Jun  5 21:05:03 mail /kernel: 101 max_aio_queue_per_proc RW *Handler Int
Jun  5 21:05:03 mail /kernel: 102 max_aio_procs RW *Handler Int
Jun  5 21:05:03 mail /kernel: 103 num_aio_procs R  *Handler Int
Jun  5 21:05:03 mail /kernel: 104 num_queue_count R  *Handler Int
Jun  5 21:05:03 mail /kernel: 105 max_aio_queue RW *Handler Int
Jun  5 21:05:03 mail /kernel: 106 target_aio_procs RW *Handler Int
Jun  5 21:05:03 mail /kernel: 107 max_buf_aio RW *Handler Int
Jun  5 21:05:03 mail /kernel: 108 num_buf_aio R  *Handler Int
Jun  5 21:05:03 mail /kernel: 109 aiod_lifetime RW *Handler Int
Jun  5 21:05:03 mail /kernel: 110 aiod_timeout RW *Handler Int
Jun  5 21:05:03 mail /kernel: 118 ffs RW Node
Jun  5 21:05:03 mail /kernel: 3 doreallocblks RW *Handler Int
Jun  5 21:05:03 mail /kernel: 4 doasyncfree RW *Handler Int
Jun  5 21:05:03 mail /kernel: 4 net RW Node
Jun  5 21:05:03 mail /kernel: 1 local RW Node
Jun  5 21:05:03 mail /kernel: 1 stream RW Node
Jun  5 21:05:03 ma

Re: problem for the VM gurus

[John S. Dyson]

Brian Feldman said:
>   In the long-standing tradition of deadlocks, I present to you all a new one.
> This one locks in getblk, and causes other processes to lock in inode. It's
> easy to induce, but I have no idea how I'd go about fixing it myself
> (being very new to that part of the kernel.)
>   Here's the program which induces the deadlock:
> 
> 
>   tmp = mmap(NULL, psize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
>   if (tmp == MAP_FAILED) {
>   perror("mmap");
>   exit(1);
>   }
>   printf("write retval == %lld", write(fd, tmp, psize));
> 
I responded earlier to a reply to this message :-).  This did
work about the time that I left, and it appears that it is likely
that code has been removed that mitigated this as a problem.

It is important to either modify the way that read or write
operations occur (perhaps prefault before letting the uiomove
operation occur (yuck, and it also still doesn't close all 
windows), or reinstate the handling of recursive operations
on a vnode by the same process.)  Handling the vnode locking
in a more sophistcated way would be better, but reinstating
(or fixing) the already existant code that used to handle
this would be a good fix that will mitigate the problem
for now.

-- 
John  | Never try to teach a pig to sing,
dy...@iquest.net  | it makes one look stupid
jdy...@nc.com | and it irritates the pig.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: problem for the VM gurus

[John S. Dyson]

>
> One of the problems that would make it sensible to do a complete rewrite
> of vfs_bio.c is this?
> 
Specifically for that reason, probably not.  However, if the effort
was taken as an entire and encompassing effort, with the understanding
of what is really happening in the code regarding policy (and there
is alot more than the original vfs_bio type things), then it would
certainly be best.  Note that some of the policy might even be
marginalized given a restructuring by eliminating the conventional
struct buf's for everything except for I/O.  In the case of I/O,
it would be good to talk to those who work on block drivers, and
collect info on what they need.  The new definition could replace
the struct bufs for the block I/O subsystems, but in many ways could
be similar to struct bufs (for backwards compat.)

In the current vfs_bio, the continual remapping is problematical,
and was one of the very negative side-effects of the backwards
compatibility choice.  The original vfs_bio merged cache design
actually (mostly) eliminated the struct bufs for the buffer cache
interfacing, and the temporary mappings thrashed much less often.
It would also be good to design in the ability to use physical
addressing (for those architectures that don't incur significant
additional cost for physically mapping all of memory.)  Along
with proper design, the fully mapped physical memory would
eliminate the need for remapping entirely.  Uiomove in this
case  wouldn't need virtually mapped I/O buffers, and this
would be ideal.  However, it is unlikely that X86 machines
would ever support this option.  PPC's, R(X) and Alpha
can support mapping all of memory by their various means 
though.

In a sense, the deadlock issue is an example of the initially
unforseen problems when hacking on that part of the code.  I suggest
a carefully orchestrated and organized migration towards the more
efficient and perhaps architecturally cleaner approach.  The
deadlock was an after the fact bug that we found very early on,
and there was a "temporary" fix for part of it, and a mitigation
of the other part.  Issues like that can be very, very nasty to
deal with.

John


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: [Fwd: Good news from NVIDIA]

[Morten A. Middelthon]

On Thu, 3 Jun 1999, Jake Burkholder wrote:

> I spent most of the day recompiling X and what not.
> All the patches applied cleanly, there are some rejects with MESA,
> but I think that has to do with tags and comments at the beginning of
> files.
>  
> Everything compiled fine, and the module loads, now I just need to
> get my hands on quake2 :)
>  
> my video card is a RIVA 128, pci.
> Seems like they've improved 2d accel quite a bit.
>  
> Here are the steps I took:
[SNIP]
> Most Cool.  I'd appreciate if someone with quake 2 handy could let me know
> if it works...

I haven't tried with Quake2 or 3 yet, but with the GL-modes in xlockmore
(gears, pipes, superquadrics, moebius, etc) it went as smooth as cream
when 3D-accelerated by my TNT card.

--
Morten A. Middelthon
Freenix Norge
http://www.freenix.no/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: problem for the VM gurus

[Brian Feldman]

One of the problems that would make it sensible to do a complete rewrite
of vfs_bio.c is this?

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \._ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message