date:20011206


* David Xu <[EMAIL PROTECTED]> [011207 00:01] wrote:
> you mean we can use  OBJT_PHYS?  do we fully support it?
> althougth we have phys_pager,  I suspect it is not enough,  because
> along with fault handling,  graphics driver will need other operations,  for
> examples, unmap other pages and setup hardware registers,
> think about a frame buffer driver need to map 32K  window  into 1024K
> address space,  when fault ocurrs in second  32K window,  it should unmap
> first 32K address and activate second 32K address and setup graphics card
> registers to let later access to its internal second 32K memory bank.
> how can you handle such issue after vm_fault?

By setting the proper page protections.


-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
   http://www.morons.org/rants/gpl-harmful.php3

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

Re: kld VM pager

2001-12-06 Thread David Xu

you mean we can use  OBJT_PHYS?  do we fully support it?
althougth we have phys_pager,  I suspect it is not enough,  because
along with fault handling,  graphics driver will need other operations,  for
examples, unmap other pages and setup hardware registers,
think about a frame buffer driver need to map 32K  window  into 1024K
address space,  when fault ocurrs in second  32K window,  it should unmap
first 32K address and activate second 32K address and setup graphics card
registers to let later access to its internal second 32K memory bank.
how can you handle such issue after vm_fault?

Regards,
--
David Xu

Alfred Perlstein wrote:

>* David Xu <[EMAIL PROTECTED]> [011206 22:15] wrote:
>
>>FreeBSD does not have fault hook available,  all faults are processed in 
>>vm_fault.
>>I know Linux supports that idea,  you can insert  a  fault hook to 
>>monitor some
>>address range where fault occurs, and then graphics frame buffer can be 
>>supported.
>>
>
>I'm sure one could add a callback in vm_fault without much issue.
>However this isn't the point of the hook.  One can insert the
>vm object into the vm map, when a fault occurs the vm_fault code
>will call the pager handler to service it.
>
>The only good part for having a fault hook in linux is most likely
>for debug purposes.
>

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

Re: kld VM pager

* David Xu <[EMAIL PROTECTED]> [011206 22:15] wrote:
> FreeBSD does not have fault hook available,  all faults are processed in 
> vm_fault.
> I know Linux supports that idea,  you can insert  a  fault hook to 
> monitor some
> address range where fault occurs, and then graphics frame buffer can be 
> supported.

I'm sure one could add a callback in vm_fault without much issue.
However this isn't the point of the hook.  One can insert the
vm object into the vm map, when a fault occurs the vm_fault code
will call the pager handler to service it.

The only good part for having a fault hook in linux is most likely
for debug purposes.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
   http://www.morons.org/rants/gpl-harmful.php3

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

Re: Tracking down system freeze

2001-12-06 Thread Warner Losh


In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: * Warner Losh <[EMAIL PROTECTED]> [011205 23:00] wrote:
: > In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: > : What you do is fold a paperclip then use it to make the last
: > : two pins of the ISA bus short:
: > 
: > and it doesn't work on PCI bus, or any other bus than ISA (except
: > maybe EISA).  I have a small ISA card that I have connected to the
: > parallel port for remote NMI generation/reset.  But it is a gross
: > hack.
: 
: It will work so long as none of the busses leading from ISA to the
: cpu are locked up.  So it will work on a PCI system so long as the
: PCI bus or system bus is not locked.

No, I was saying that the PCI bus can't generate an NMI with a
paperclip.  That's all :-)

Warner

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Warner Losh


In message <[EMAIL PROTECTED]> Mike Barcroft writes:
: Leo Bicknell <[EMAIL PROTECTED]> writes:
: > The problem with GENERIC is it is the lowest common denominator.
: > While it's really cool we can still boot on a 386 with 4 meg of
: > RAM, making the compromises to make that happen is not terribly
: > useful.
: 
: 386 support has been removed from -CURRENT.  -CURRENT also doesn't
: support 486SX's out of the box, one is required to load a kernel
: module from the loader if they need FPU emulation.

I assume that you mean that the GENERIC kernel doesn't support i386.
You can still build a kernel for i386 machines on -current.

Warner

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

Re: UDP checksum error after encapsulating multicast packet



I looked at the larger context and realized that ip_mloopback()
was wrong too.  Try this updated patch; it is a superset of the
previous one.

  Bill



Index: ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.143
diff -u -r1.143 ip_output.c
--- ip_output.c 1 Dec 2001 13:48:16 -   1.143
+++ ip_output.c 7 Dec 2001 04:37:33 -
@@ -353,6 +363,16 @@
 */
if (!rsvp_on)
  imo = NULL;
+   /*
+* XXX
+* delayed checksums are not currently
+* compatible with IP multicast routing
+*/
+   if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
+   in_delayed_cksum(m);
+   m->m_pkthdr.csum_flags &=
+   ~CSUM_DELAY_DATA;
+   }
if (ip_mforward(ip, ifp, m, imo) != 0) {
m_freem(m);
goto done;
@@ -1906,6 +2358,17 @@
register struct ip *ip;
struct mbuf *copym;
 
+   /*
+* XXX
+* delayed checksums are not currently
+* compatible with IP multicast routing.
+* Can't do this on copym because it may
+* be shared.
+*/
+   if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
+   in_delayed_cksum(m);
+   m->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA;
+   }
copym = m_copy(m, 0, M_COPYALL);
if (copym != NULL && (copym->m_flags & M_EXT || copym->m_len < hlen))
copym = m_pullup(copym, hlen);
@@ -1946,12 +2409,6 @@
copym->m_pkthdr.rcvif = ifp;
ip_input(copym);
 #else
-   /* if the checksum hasn't been computed, mark it as valid */
-   if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
-   copym->m_pkthdr.csum_flags |=
-   CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
-   copym->m_pkthdr.csum_data = 0x;
-   }
if_simloop(ifp, copym, dst->sin_family, 0);
 #endif
}

Re: UDP checksum error after encapsulating multicast packet



>However, there does exist one case that have good checksum, no matter I 
>apply the patch or not.

Is the local system a member of one or the other of these groups?
i.e. does it work when the local system is a member, or not, or
is that not a predictor of the behavior?

  Bill

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

Re: kld VM pager

2001-12-06 Thread David Xu


FreeBSD does not have fault hook available,  all faults are processed in 
vm_fault.
I know Linux supports that idea,  you can insert  a  fault hook to 
monitor some
address range where fault occurs, and then graphics frame buffer can be 
supported.

--
David Xu

Nicolas Souchu wrote:

>Hi VM developers,
>
>Has anyone already some useful utils to develop a VM pager for FreeBSD?
>The KGI port project is progressing and is now up to the point that I have
>to handle the VM events as done in Linux.
>
>http://www.freebsd.org/~nsouch/ggiport.html
>
>Reading the 4.4BSD Internals, I've understood that I should look in the pager
>direction and the code shows that the device pager is not much far from my
>willing...
>
>More precisely, has anybody some way to load/unload a pager? Is it really
>possible? What advices could you address me before I start this?
>
>Thanks in advance!
>
>Nicholas
>



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

Re: UDP checksum error after encapsulating multicast packet

2001-12-06 Thread Yung-Sheng Tang


On Thu, 6 Dec 2001, Bill Fenner wrote:

> 
> Please try this patch.  It gives multicast packets on a multicast
> router similar treatment to those that IPSEC packets get, by calculating
> the delayed checksum early and not permitting it to be offloaded to
> the interface.
> 


It does not work.

11:28:52.098146 150.9.120.183.1063 > 224.3.4.5.2345:  [udp sum ok] udp 16 
(ttl 16, id 25575, len 44)
 4500 002c 63e7  1011 5411 9609 78b7
 e003 0405 0427 0929 0018 5571 ea02 0400
     bb30 0100
11:28:52.098266 150.9.120.183 > 192.9.200.127: 150.9.120.183.1063 > 224.3
.4.5.2345:  [bad udp cksum 7e62!] udp 16 (ttl 15, id 25575, len 44) (ttl 
64, id 25576, len 64)
 4500 0040 63e8  4004 7f88 9609 78b7
 c009 c87f 4500 002c 63e7  0f11 5511
 9609 78b7 e003 0405 0427 0929 0018 f2f2
 ea02 0400     bb30 0100

However, there does exist one case that have good checksum, no matter I 
apply the patch or not.


11:28:52.474363 150.9.120.66.1088 > 234.8.7.1.1088:  [udp sum ok] udp 64 
(ttl 2, id 14422, len 92)
 4500 005c 3856  0211 80e6 9609 7842
 ea08 0701 0440 0440 0048 7f34 6d65 6368
 7075 6232   0100  605d 7381
        
        
      
11:28:52.474508 150.9.120.183 > 192.9.200.127: 150.9.120.66.1088 > 234.8.
7.1.1088:  [udp sum ok] udp 64 [ttl 1] (id 14422, len 92) (ttl 64, id 255
78, len 112)
 4500 0070 63ea  4004 7f56 9609 78b7
 c009 c87f 4500 005c 3856  0111 81e6
 9609 7842 ea08 0701 0440 0440 0048 7f34
 6d65 6368 7075 6232   0100 
 605d 7381      
        

BTW, I am using 4.4-RELEASE. Thank you.

--
Yung-Sheng Jeff Tang


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

CONVITE HP ALERTA

2001-12-06 Thread Keila - Curitiba


Olá!
Veja meu site pessoal. Basta clicar no endereço
abaixo. GARANTO SER SUI-GENERIS  -  CLIQUE ABAIXO:
http://www.pastorinha.atfreeweb.com
Mais de 162.000 internautas visitaram a PG., existe 6 Álbuns:
Se você quiser, por favor, indique minha Home Page, a outros
Internautas.  Mais detalhes, se comunique, passe um e-mail, que
responderei brevemente. Dentro da Home Page, ao lado das fotos,
você poderá saber muito mais sobre mim!
Obrigada.
e-mail: [EMAIL PROTECTED]
Beijos:- Keila - Curitiba - Pr
- Podes falar comigo, direto dela. Brevemente uma Carta Aberta.
- Embora derrubem a página eu a subo em 3 horas novamente.

 "Esta mensagem é enviada com a complacência da nova legislação 
sobre
correio eletrônico, Seção 301, Parágrafo (a) (2) (c) Decreto S. 1618,
Título Terceiro aprovado pelo "105º Congresso Base das Normativas
Internacionais sobre o SPAM". Este E-mail não poderá ser considerado
SPAM quando incluir uma forma de ser removido. Para ser removido
de futuros correios, simplesmente responda indicando
no Assunto: REMOVER"

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

CONVITE HP ALERTA

2001-12-06 Thread Keila - Curitiba


Olá!
Veja meu site pessoal. Basta clicar no endereço
abaixo. GARANTO SER SUI-GENERIS  -  CLIQUE ABAIXO:
http://www.pastorinha.atfreeweb.com
Mais de 162.000 internautas visitaram a PG., existe 6 Álbuns:
Se você quiser, por favor, indique minha Home Page, a outros
Internautas.  Mais detalhes, se comunique, passe um e-mail, que
responderei brevemente. Dentro da Home Page, ao lado das fotos,
você poderá saber muito mais sobre mim!
Obrigada.
e-mail: [EMAIL PROTECTED]
Beijos:- Keila - Curitiba - Pr
- Podes falar comigo, direto dela. Brevemente uma Carta Aberta.
- Embora derrubem a página eu a subo em 3 horas novamente.

 "Esta mensagem é enviada com a complacência da nova legislação 
sobre
correio eletrônico, Seção 301, Parágrafo (a) (2) (c) Decreto S. 1618,
Título Terceiro aprovado pelo "105º Congresso Base das Normativas
Internacionais sobre o SPAM". Este E-mail não poderá ser considerado
SPAM quando incluir uma forma de ser removido. Para ser removido
de futuros correios, simplesmente responda indicando
no Assunto: REMOVER"

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

Re: cable modem connection problem


Mike D wrote:

> going out. I haven't checked for either packet drops / RTT increase (how?) 
> but when I say slow, I mean for eaxmple to get www.google.com up takes 5-10 
> minutes. Also other machines on the LAN can not really get out at all.


If you ping/traceroute, do you see losses (and where)? If you look at 
"netstat -s" output, do you see retransmissions?

 
> Somebody mentioned on this list that deleting the arp table entry of the 
> default router of the cable modem provider (as a cron job) solved the 
> problem. 


Does this work for you, too?

 
> Could this have something to do with leases being renewed (by the isp dhcp 
> server and consequently the cable modem) and FreeBSD not updating routing 
> tables? (I'm guessing big time here - not an expert by any means)

If your cable modem provides IP, it's probably not involved in the DHCP 
negotiations. Does your IP address change before you start to see this 
slowdown?

Lars
-- 
Lars Eggert <[EMAIL PROTECTED]>   Information Sciences Institute
http://www.isi.edu/larse/  University of Southern California


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

Re: cable modem connection problem

2001-12-06 Thread Mike D


> This sounds a lot like your cable modem provider throtteling the link if
> it doesn't see some sort of negotiation (DHCP, ARP, etc.) after a fixed
> amount of time. I could imagine that some companies do this for
> residential connections.
>
> Does your cable modem provide IP service, or do you need PPPoE or
> something like that?

they provide IP. I have this set-up:

INET---modem---10BT---FreeBSD---100BT LAN...

> Is this going out from behind the box, or coming in from the Internet?
> Also, do you see packet drops or RTT increases (define "slow").

going out. I haven't checked for either packet drops / RTT increase (how?) 
but when I say slow, I mean for eaxmple to get www.google.com up takes 5-10 
minutes. Also other machines on the LAN can not really get out at all.

Somebody mentioned on this list that deleting the arp table entry of the 
default router of the cable modem provider (as a cron job) solved the 
problem. 

Could this have something to do with leases being renewed (by the isp dhcp 
server and consequently the cable modem) and FreeBSD not updating routing 
tables? (I'm guessing big time here - not an expert by any means)

Again, thanks very much for the advice so far, if you have any more would be 
extremely greatful!

Mike

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

Re: cable modem connection problem

S. Aeschbacher wrote:
 > A solution I found is deleting the arp table entry of the default
 > router of the cable modem provider (as a cron job). I did not
 > investigate the source of the problem. Anyone got any clues?

This sounds a lot like your cable modem provider throtteling the link if
it doesn't see some sort of negotiation (DHCP, ARP, etc.) after a fixed
amount of time. I could imagine that some companies do this for
residential connections.

Does your cable modem provide IP service, or do you need PPPoE or
something like that?

 > Mike D wrote:
 >> I have a set up where my FreeBSD 4.4 box is acting as a firewall
 >> and gateway between a cable modem on xl1 and my home net on xl0.
...
 >> It seems that after approx 10 hours the connection REALLY slows
 >> down, most connection attempts on other ports (e.g. 110) time out
 >> and I have to reboot the box. After the reboot everything is
 >> back to normal.

Is this going out from behind the box, or coming in from the Internet?
Also, do you see packet drops or RTT increases (define "slow").

Lars
-- 
Lars Eggert <[EMAIL PROTECTED]>   Information Sciences Institute
http://www.isi.edu/larse/  University of Southern California

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

Re: cable modem connection problem

2001-12-06 Thread Mike D


Stefan,

could you (if it's not too much hassle) mail me the details of setting that 
cron job up - as an interim solution. Hopefully we'll get a better one of 
this list soon!

Thanks in advance,

Mike

On Thursday 06 December 2001 1:57 pm, S. Aeschbacher wrote:
> Hi
> I experienced similar problems here in Switzerland. It happend with
> FreeBSD as well
> as with OpenBSD routers. A solution I found is deleting the arp table
> entry of the
> default router of the cable modem provider (as a cron job).
> I did not investigate the source of the problem. Anyone got any clues?
>
> Stefan
>
> Mike D wrote:
> > I have a set up where my FreeBSD 4.4 box is acting as a firewall and
> > gateway between a cable modem on xl1 and my home net on xl0.
> >
> > I have a pretty tight rules list and don't have that many procs running
> > (ipfw, natd, mysql, tomcat - that's it!)
> >
> > It seems that after approx 10 hours the connection REALLY slows down,
> > most connection attempts on other ports (e.g. 110) time out and I have to
> > reboot the box. After the reboot everything is back to normal.
> >
> > If you have *any* thoughts at all as to what this could be - please let
> > me know, I'm getting pretty desperate.
> >
> > many thanks in advance!
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message

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

Re: what is PSEUDOFS?

2001-12-06 Thread Dag-Erling Smorgrav

Hiten Pandya <[EMAIL PROTECTED]> writes:
> i know what DEVFS is... after the lecture at the
> BSDCon 2001 Europe by phk

Well, the author of pseudofs was there too, and did mention it in his
lightning talk right before Jordan's MacOS X presentation.  You could
have asked him there :)

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: tar and nodump flag (fwd)

2001-12-06 Thread .


Joerg Schilling writes:
> >From [EMAIL PROTECTED] Thu Dec  6 00:41:54 2001
> 
> >Joerg Schilling writes:
> >.
> >> STAR OptionDescription
> Gnu tar equiv.  Remarks
> >> ======
> =   ===
> >.
> >> file=nm,f=nm   use 'nm' as tape instead of stdin/stdout   
> -f  close to identical
> >May be close to identical in function, but not in convenience
> >What about f=*.[ch] or f=something
> 
> Here is a more complete desciption of the features of the getargs()
> function that is used to parse the command line arguments of all
> schily programs:
> 
> /*--*/
> As a hint for readers to the star manual page, star uses getargs() to parse
> the command line. Getargs() is much more flexible than getopt() and is even
> older than getopt(). The following features 
> 
> - All single char boolean options and all single char increment type
>   options may be combined into a single string starting with a single
>   dash (-).
> 
> - getargs() has a compatibility mode for GNU programs and allows to
>   preceede long options with a double dash (--) instead of the usual
>   single dash (-).
> 
> - All options that take an argument are listed in the man page for
>   better readability of the manual as:
>   
>   option=arg
> 
>   but the following variants may appear in the actual command line:
> 
>   option=arg
>   option= arg
>   -option=arg
>   -option= arg
>   -optionarg
>   -option arg
> 
> - A separate double dash (--) may preceede any argument that looks like
>   an option and specifies that the immediately following argument is
>   a file type argument.
> 
> /*--*/
> 
> I am not shure whether I should ad this to all of my maual pages or whether I
> should add a "SEE ALSO" note in the man page and include the getargs() man page
> with all programs.
There is the first time I install star and I see
no other way to know quikly about getargs.
Yes, I use sometimes sources for investigate some trick
but I am restricted by time.
I think others too.
Any way to include in manual is better then none.
Thanks.

-- 
@BABOLO  http://links.ru/

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Andreas Klemm


On Thu, Dec 06, 2001 at 09:26:40AM -0800, Lamont Granquist wrote:
> An alternative solution that i haven't read anyone suggest on this thread
> is simply to improve man tuning(7) and make people more aware of it.

Could (should ???) be part of the installation process, accessible as
menue or submenue  ??? Since it contains useful hints how to plan
a useful filesystem layout.

What I'm missing is, to make use of memory filesystems for /tmp

mfs:30 on /tmp (mfs, asynchronous, local)

Filesystem  1K-blocks UsedAvail Capacity  Mounted on
mfs:30 507639   13   467015 0%/tmp

Best regards

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD
Need a magic printfilter today ? http://www.apsfilter.org/
Songs from our band >> 64Bits << http://www.64bits.de
Inofficial band pages with add-on stuff  http://www.apsfilter.org/64bits.html



msg29722/pgp0.pgp
Description: PGP signature

Re: Can TCP changes be put in RELENG_4?


* Greg Shenaut <[EMAIL PROTECTED]> [011206 15:12] wrote:
> In message <[EMAIL PROTECTED]>, Leo Bicknell cleopede:
> 
> Speaking as someone with a lab full of older machines, including
> some 8MB 386SXs happily humming along under FreeBSD, and no machine
> with > 32 MB, I obviously am going to disagree vehemently with this
> entire line of argumentation.  (I always build a custom kernel for
> my machines, but if you required 64MB or more just to boot the
> installation floppy, I would have to go buy RAM just to have a
> machine to install the next version on.  Ptui!)
> 
> However, I do see the value in making it easier to have a faster,
> more memory-intensive kernel, so why not just provide a "turbo
> kernel" in the standard root distribution along with the current
> "generic kernel"?  Shoot, I think even casual, non kernel-configuring
> users might be interested in comparing performance under the two
> kernels; plus, having the config file for the turbo kernel available
> for perusal in the kernel source would be a big plus in my book.

Considering how trivial it is to build a "kern.flp" nowadays, I'm
suprised that:

1) No one has made a HOWTO on doing this.
2) No one has added to the standard release additional boot
   floppies.
3) No one has fixed up the CDrom image so that the loader
   prompts for several different kernels specially made for
   machines with low memory.

*shrug*

It's not that difficult, but my TODO list is about 2 miles long
at the current time.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
   http://www.morons.org/rants/gpl-harmful.php3

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Greg Shenaut

In message <[EMAIL PROTECTED]>, Leo Bicknell cleopede:
>On Thu, Dec 06, 2001 at 06:23:31AM -0800, Terry Lambert wrote:
>> > I'd suggest our target should be a P-III 600 with around 256M of
>> > RAM as what Generic should be tuned for
>> 
>> Can't.  The static allocations for that much assumed RAM would
>> result in the machine not booting, with the amount of RAM for
>> the page tables alone ~1/4M.  By default, the 120M KVA space
>> mappings are arguably overlarge for small memory machines.
>
>Would result in what machines not booting?  As long as a 64M PC
>can boot (even if it has only 10 Meg free for user apps) that's ok
>in my book.  If we're still trying to boot on 4, 8, or 16 meg
>machines that's just dumb.
>
>As I've said before, there are two types of FreeBSD users.  There
>are "users", who want something to replace windows and who really
>like the Linux distro's with KDE and all that.  These people are
>unlikely to build a kernel, and as time goes by are even less likely
>to know what a kernel is.  They are also likely to have a < 3 year
>old PC, probably that they are dual booting.  Linux recognized this,
>and targest this sort of hardware out-of-the-box.
>
>The second type of user is someone like you, or me, or most of the
>people on this list.  They will build a custom kernel no matter
>how appropriate the default settings.  They will tune things for
>odd application boxes, like IRC and News servers and the like.
>The defaults are virtually irrevelant for these people, provided
>sysinstall can finish.
>
>As far as I'm concerned any machine with < 64M these days falls
>into the second catagory, where someone should have to futz with
>it to make it work.  When 256M DIMMs are $18 we need to get with
>the program.

Speaking as someone with a lab full of older machines, including
some 8MB 386SXs happily humming along under FreeBSD, and no machine
with > 32 MB, I obviously am going to disagree vehemently with this
entire line of argumentation.  (I always build a custom kernel for
my machines, but if you required 64MB or more just to boot the
installation floppy, I would have to go buy RAM just to have a
machine to install the next version on.  Ptui!)

However, I do see the value in making it easier to have a faster,
more memory-intensive kernel, so why not just provide a "turbo
kernel" in the standard root distribution along with the current
"generic kernel"?  Shoot, I think even casual, non kernel-configuring
users might be interested in comparing performance under the two
kernels; plus, having the config file for the turbo kernel available
for perusal in the kernel source would be a big plus in my book.

Greg Shenaut

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

FileCrypt SDK - Your new security library

2001-12-06 Thread contact

Title: FileCrypt SDK - Your new security
Library


 



 
 

Developers who need to
implement strong security in their applications will find the
FileCrypt SDK library fits their needs
perfectly.

 
Find out for
yourself...
Obtain the
30-day free evaluation after you fill out the form you find
at http://www.veridis.com/filecryptsdk/fcsdk_evaluation_request.pdf.

Supporting the standards in strong cryptography, we have designed
FileCrypt SDK for speed and easy integration with third party
software.

In addition, our experts can assist you should you be on a strict
deadline... 
  
 
FileCrypt SDK
is the ideal multi-platform toolkit to add security features to any
e-commerce application:



It gives easy access to all
functions needed to make use of the OpenPGP Public Key
Infrastructure (PKI), totally compliant with the IETF RFC 2440 OpenPGP
standard. Amongst others, it contains the functions to create
keypairs, to encrypt and sign documents and messages, to certify keys,
... It also allows communication with the other elements of the
OpenPGP PKI such as posting keys to a key server as well as retrieving
keys from a key server. 
  

FileCrypt SDK also contains calls
to PGP/MIME functions, specifically intended to achieve secure
e-mail messaging according to the PGP/MIME standard as described in
the IETF RFC 2015.
  

Its Java-like interface adds
a familiar look for all modern-time developers and allows the use of
the library in all kinds of environments.
  

Thanks to the open architecture, developers
can add their own modules or replace existing modules by their own
implementations.
  

The Automatic Garbage Collector is
probably a feature most developers will appreciate a lot, allowing them not
to worry about disposing the objects they create, thus avoiding memory
leaks - totally automatically.
  

Full compatibility with the PGP 6
extensions is also offered (User's photograph and X.509
certificates).
  

FileCrypt is based on a multi-purpose library and
therefore includes useful additional services like thread,
file, memory, list & collection management, ...
  

FileCrypt SDK also comes with a clear HTML
documentation and many examples, making the learning process as
short as possible.
  


Veridis offers the library on
various platforms, making OpenPGP encryption available on Windows,
any Unix implementation, Mac OS and Symbian. Implementations on other
platforms will follow.

For further information,
visit http://www.veridis.com or send a message to [EMAIL PROTECTED]


CONTACT:
Axel de Landtsheer
Veridis 
156 rue Berckmans
B-1060  Brussels, Belgium
Phone: +32 2 543 04 00
Fax: +32 2 537 51 55
http://www.veridis.com

Re: kld VM pager

2001-12-06 Thread Rodolphe Ortalo

On Thu, 6 Dec 2001, Brooks Davis wrote:
[...]
> If it got us a port sooner with fewer bugs, I'd certaintly be happy to
> see the FreeBSD port not support ancient hardware.  Linux and NetBSD are
> both doing an excelent job in that space.

IMHO, it's not only about supporting ancient (graphics) hardware. Even if
FreeBSD is not actively ported to as many architectures as NetBSD, it
still surely has the capacity to be ported to these architectures.

 Graphics hardware apparently loves to play with adressing schemes and
esoteric RAM features (something understandable when you look at this kind
of hardware in more details: SGRAM block modes, dual ported RAM, Sun's "3D
RAM", LUT everywhere and in every possible direction, bus-mastering,
texture-page-tables, etc, ...). So it seems to me that a graphics driver
framework like KGI really needs some way to take into account these
features, and allow userspace applications to use a much more conventional
uniform and linear view of all these memory areas.

 It does not mean that we want to actively support all of them, but not
taking into account this variety may lead us to an architecture that would
not be able to adapt to future evolutions. (IMO, microcode memory areas
are the "tricky" MMIO areas of the future: applications will want to
access them to program their own specialized 3D graphic pipes...)

Rodolphe

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

Re: UDP checksum error after encapsulating multicast packet



Please try this patch.  It gives multicast packets on a multicast
router similar treatment to those that IPSEC packets get, by calculating
the delayed checksum early and not permitting it to be offloaded to
the interface.

Thanks,
  Bill



Index: ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.143
diff -u -r1.143 ip_output.c
--- ip_output.c 1 Dec 2001 13:48:16 -   1.143
+++ ip_output.c 6 Dec 2001 20:40:24 -
@@ -353,6 +363,16 @@
 */
if (!rsvp_on)
  imo = NULL;
+   /*
+* XXX
+* delayed checksums are not currently
+* compatible with IP multicast routing
+*/
+   if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
+   in_delayed_cksum(m);
+   m->m_pkthdr.csum_flags &=
+   ~CSUM_DELAY_DATA;
+   }
if (ip_mforward(ip, ifp, m, imo) != 0) {
m_freem(m);
goto done;

Re: UDP checksum error after encapsulating multicast packet



This is a bug in delayed checksum.  The checksum in the encapsulated
packet is the pseudo-header checksum:

mango% ipcksum
0011 0018 c009 c87f e002 0304
correct checksum of the 12 bytes is 9446 1's complement is 6bb9

(6bb9 is the udp checksum in the encapsulated packet).  ip_output()
has to do the udp checksum if it's going to hand it to ip_mforward();
this is particularly problematic if the outgoing interface is actually
going to perform the checksum.  It is probably necessary to create a
copy of the IP/UDP headers and perform the delayed checksum before
handing off to ip_mforward().

  Bill

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

Re: kld VM pager

2001-12-06 Thread Rodolphe Ortalo

On Thu, 6 Dec 2001, Terry Lambert wrote:

> Nicolas Souchu wrote:
> > > From my reading of the code, all it is is a pseudo device that
> > > permits you to establish/remove memory mappings for various regions
> > > of the graphics card memory, which may or may not be apertured,
> > > into process address space, as a file buffer mapping.
> [ ... ]
> > As you consider it later, the VM is supposed to move the aperture window
> > if the hardware does not support linear frame buffering (VGA 64k window
> > for example). This is a minimal feature for the so-called mmio resources.
> > Some other kind of resources may be mapped as well, especially acceleration
> > resources like DMA, graphic pipelines... to provide the user application a
> > uniform API (memory mapping) for any kind of hw capacities.
> 
> If the intent is just to turn non-linear into linear from the
> perspective of an applicaiton, and the boundary is always 4K
> or more, and it's not an access aperture that needs the card
> to be sent a control message to expose a different region in
> the host visible window, then you just need to make a bunch
> of different mappings to make non-linear physical memory into
> linear virtual memory.

In this case (not the general case), you usually *also* need to update
some hw registers (send control message in your wording) in the graphic
board chipset to have it make available the specific (e.g. 4k) card memory
area. (Sort of paged->linear mapping.) So the actual card driver needs to
register a fault handler and the kernel subsystem (KGI "driver") should
call it when needed. Needless to say that this is really bad for
performance and mostly useful only for old chipsets (e.g. to have a VGA
board present a linear 256ko memory area to applications via a 32k
window...). Definitely not the general case nowadays...

> I'm not sure if I understand you, though.  Is all of the card
> memory visible in physical memory, or is only part of the card
> memory visible in physical memory?  Forget virtual for a second.

Most of the time, with modern and common PC graphic cards, the entire card
physical memory can be visible in physical memory. However, this is a
modern evolution, old or advanced graphics hardware usually plays *a lot*
with the graphic memori(es) adressing wires.

 Also the (KGI-)kernel (sometimes) would like to restrict the accessible
range, possibly *with* hardware help (IIRC advanced graphic hardware
provide hw control for windows, or stereo displays).

> If only a part of the card memory is visible in physical memory,
> then you will have to do fault handling, as I first suggested.
> 
> FreeBSD doesn't support external pagers, per se.  You might be
> able to hook it in, but really, it's not expected.  You really
> want to look at /sys/vm/device_pager.c.

IMHO, this is not the most general case, especially for framebuffer
accesses which are usually linear<->linear (ie classical) mappings.
 *However*, VGA-only drivers are still extremely useful as most cards are
VGA-compatible; e.g. at boot time on an otherwise unsupported card... IIRC
our basic VGA (especially VGA-text) driver takes advantage of this kind of
mechanism (SetOffset hook in the exported memory resource).

> The main problem, if there is really an aperture you have to
> move around, is that there's an implicit asumption that you have
> all the memory mapped, and the "put" is as simple as just
> writing to memory, so you aren't going to get the write fault
> that gets handled by a fault handler that you need.
[...]
> I find it incredibly hard to believe that anyone would build a
> video card that would be so slow to access, but I could easily
> be wrong here.

VGA text mode, even incredibly slow, is still much more convenient than a
black screen (well, unless you can have a real VT100 somewhere and the
ability to configure it with the eyes closed :-).
 But you are right, this is not the general case. Let's summarize the
various kind of MMIO resources available via KGI: PAGED_PAGED,
LINEAR_PAGED, PAGED_LINEAR and LINEAR_LINEAR.

Amon all of them, the LINEAR_LINEAR case is clearly the simplest and most
useful one. However, even if the other mappings are tricky and potentially
inefficient, in the past, we have found useful to have them available:
that's why they were implemented.

 The example which come to my mind is usually the VGA-text case: provide
access to 256k of VGA memory via a single 32k window. It allows several
things: have 4 VGA-compatible boards running (the 32k "window" is usually
in a fixed adress range: 0xA-0xB), have simple access to the text
font ("upper" part of the 256ko memory, modulo some mangling that the
driver does silently) and finally let the console code access a 32k (or
64k) area as a linear area.
 I'm sure other cases could arise - as I said graphics hardware tends to
play a lot with the memory adressing and I would not be surprised it
they invented something new in the future...

[...]
> > But, I don't want an

Re: switching to real mode

On Thu, 6 Dec 2001, Mike Smith wrote:

> As John said, actually, really going back to real mode is hard.  It would
> be easier to just reboot the system, especially since we have probably
> left hardware in odd states.

True. For two kernel monte and LOBOS we never leave protected mode before
booting the new OS. Getting into real mode just isn't that important.

ron

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

Re: switching to real mode

2001-12-06 Thread Ian Dowse

In message <[EMAIL PROTECTED]>, John Baldwin writes:
>The short form is htat you need to hack the cpu_halt to call a function that
>puts a stub down in low memory, and calls it.  This code needs to be mapped 1:1
>so that the logical address == physical address.  The first thing you will

Yeah, I attempted something like this a few years ago without much
success. I've just updated the code to compile on -stable, and it
seems to half-work in that it appears to successfully switch to
real mode and clear the screen using the video BIOS, but then it
just hangs. That's pretty close to what I remember it doing
originally, although I think it might have worked before the VM86
stuff was enabled by default in FreeBSD. Getting this sort of code
to work reliably is almost impossible... Source is at

http://www.maths.tcd.ie/~iedowse/FreeBSD/diskboot/

(loading the resulting KLD immediately shuts down to real mode).

Ian

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

Problem with two smbus devices


Hi,

we have a couple of 4.4-RELEASE machines that have both Intel 82801AA 
(ICH) SMBus controllers and BrookTree 878 TV cards. Both of these attach 
to smbus devices, the BrookTree to smbus0 and the Intel to smbus1.

The problem is that all system status utilities I tried (wmhm, wmlmmon, 
etc.) access smbus0, which is the TV card, causing a kernel hang.

Is there any way to force the Intel controller to attach to smbus0 
instead? (I could patch the source of the utilities, but they need to be 
able to run on "standard" machines as well.)

Here's the relevant dmesg output:

bktr0:  mem 0xf6001000-0xf6001fff irq 13 at device 9.0 on 
pci2
iicbb0:  on bti2c0
iicbus0:  on iicbb0 master-only
smbus0:  on bti2c0
smb0:  on smbus0
bktr0: Hauppauge Model 61381 D423
bktr0: Detected a MSP3430G-A4 at 0x80
bktr0: Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, msp3400c 
stereo, remote control.
ichsmb0:  port 0xdcd0-0xdcdf irq 
13 at device 31.3 on pci0
smbus1:  on ichsmb0
smb1:  on smbus1

Thanks,
Lars
-- 
Lars Eggert <[EMAIL PROTECTED]>   Information Sciences Institute
http://www.isi.edu/larse/  University of Southern California


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

Re: Tracking down system freeze


* Warner Losh <[EMAIL PROTECTED]> [011205 23:00] wrote:
> In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
> : What you do is fold a paperclip then use it to make the last
> : two pins of the ISA bus short:
> 
> and it doesn't work on PCI bus, or any other bus than ISA (except
> maybe EISA).  I have a small ISA card that I have connected to the
> parallel port for remote NMI generation/reset.  But it is a gross
> hack.

It will work so long as none of the busses leading from ISA to the
cpu are locked up.  So it will work on a PCI system so long as the
PCI bus or system bus is not locked.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
   http://www.morons.org/rants/gpl-harmful.php3

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

Re: kld VM pager

2001-12-06 Thread Brooks Davis

On Thu, Dec 06, 2001 at 01:13:55PM -0500, Brian S. Julin wrote:
> 
> 
> I'll take a shot at qualifying what is is that KGI wants:
> 
> Yes, we definitely want page-fault handlers if we can possibly 
> get them:
> 
> 1) For fossil cards where the aperture is smaller than the VRAM,
>with impossible-or-dangerous-to-expose-to-userpace aperture 
>control.  Also this provides naive applications with often desired
>contiguous direct buffer access.
> 2) For fossil planar mode cards with dangerous-to-expose-to-userspace 
>plane-mask controls, to allow for direct access to different 
>planes/plane-masks such that naive applications need not
>explicitly use an IOCTL to set the plane masks. *

> * Why support such cretinous hardware?  Laptops.  Especially of the
> non-x86 variety.

I'm curious how likely either of these are to come up on platforms
FreeBSD is likely to support.  I'm sure Linux and NetBSD will find
them, but FreeBSD's focus is on "modern", "popular" architectures.
The architectures with active ports either working or being developed
are i386, ia64, x86-64, sparc64 (pci only for now), PowerPC, and alpha.
There's also a rather inactive arm port (the list hasn't even been
spammed since August) and a proposed MIPS port with no one working on it.
Add the fact that actual 386 and 486sx parts are not supported by the
GENERIC kernel in 5.0-current and I'm wondering if either of these weird
types of hardware are going to appear anytime soon outside of some really
strange situations.

If it got us a port sooner with fewer bugs, I'd certaintly be happy to
see the FreeBSD port not support ancient hardware.  Linux and NetBSD are
both doing an excelent job in that space.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

msg29710/pgp0.pgp
Description: PGP signature

Re: DRIVER_MODULE macro devclass_t argument used?

2001-12-06 Thread Mike Smith


> This makes me believe the devclass_t structure defined in a driver is
> never used. Is there another code path I'm missing?

Yes; there is a twisty maze of macros which ultimately results in the 
driver_module_data structure ending up in a linker set.  The devclass 
structure is, as Warner pointed out, critical in maintaining correct 
numbering for a class of devices.

For example; you can legitimately have several different drivers calling 
themselves "foo", but there must only be one "foo" devclass, and they all 
have to reference it.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

Re: cable modem connection problem

2001-12-06 Thread .


S. Aeschbacher writes:
> Hi
> I experienced similar problems here in Switzerland. It happend with
> FreeBSD as well
> as with OpenBSD routers. A solution I found is deleting the arp table
> entry of the
> default router of the cable modem provider (as a cron job).
> I did not investigate the source of the problem. Anyone got any clues?
> 
> Stefan
> 
> Mike D wrote:
> > 
> > I have a set up where my FreeBSD 4.4 box is acting as a firewall and gateway
> > between a cable modem on xl1 and my home net on xl0.
> > 
> > I have a pretty tight rules list and don't have that many procs running
> > (ipfw, natd, mysql, tomcat - that's it!)
> > 
> > It seems that after approx 10 hours the connection REALLY slows down, most
> > connection attempts on other ports (e.g. 110) time out and I have to reboot
> > the box. After the reboot everything is back to normal.
> > 
> > If you have *any* thoughts at all as to what this could be - please let me
> > know, I'm getting pretty desperate.
> > 
> > many thanks in advance!
What does

netstat -m

show?

-- 
@BABOLO  http://links.ru/

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

Re: UDP checksum error after encapsulating multicast packet


ignore that patch, it is completely wrong.

sorry.

--mark.

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

Re: switching to real mode

2001-12-06 Thread Mike Smith


> It's still there.  See the code in /sys/boot, in particular,
> the bios code in boot2 and boot 3.

You're thinking of the bioscall interface in BTX, I guess, which uses
v86 mode, not real mode.

As John said, actually, really going back to real mode is hard.  It would 
be easier to just reboot the system, especially since we have probably 
left hardware in odd states.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

Re: UDP checksum error after encapsulating multicast packet


the len and offset have been put in net order, but the len is then
assumed to be in host order:

in sys/netinet:

--- ip_mroute.c.origThu Jul 19 01:37:26 2001
+++ ip_mroute.c Thu Dec  6 12:26:25 2001
@@ -1595,6 +1595,7 @@
  */
 ip = (struct ip *)((caddr_t)ip_copy + sizeof(multicast_encap_iphdr));
 --ip->ip_ttl;
+len = ip->ip_len;
 HTONS(ip->ip_len);
 HTONS(ip->ip_off);
 ip->ip_sum = 0;
@@ -1605,7 +1606,7 @@
 if (vifp->v_rate_limit == 0)
tbf_send_packet(vifp, mb_copy);
 else
-   tbf_control(vifp, mb_copy, ip, ip_copy->ip_len);
+   tbf_control(vifp, mb_copy, ip, len);
 }
 
 /*

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

Re: kld VM pager

2001-12-06 Thread Brian S. Julin




I'll take a shot at qualifying what is is that KGI wants:

Yes, we definitely want page-fault handlers if we can possibly 
get them:

1) For fossil cards where the aperture is smaller than the VRAM,
   with impossible-or-dangerous-to-expose-to-userpace aperture 
   control.  Also this provides naive applications with often desired
   contiguous direct buffer access.
2) For fossil planar mode cards with dangerous-to-expose-to-userspace 
   plane-mask controls, to allow for direct access to different 
   planes/plane-masks such that naive applications need not
   explicitly use an IOCTL to set the plane masks. *
3) For resources of lower access privilage which are move around 
   inside an aperture of higher privilage (e.g. if an area of VRAM
   controlled by a normal application must be relocated in VRAM 
   by a session leader.)
4) For policing access to RAM, usually DMA-capable RAM, such
   that the application can write accelerator commands to a
   page and submit the page to the kernel, which then revokes
   write privilages until the page has been proofread and 
   swapped for a clean page such that it can be executed asyncronously,
   while the application obliviously continues to write commands.  
   Page faults and blocking behavior are needed in this case in 
   order to provide a ring-buffer-like feel to applications that use 
   the ring-buffer paradigm for command FIFOs, and doubtless they
   will become useful in implementing a display-list paradigm as well.


In a perfect world, a user application would be able to explicitly say
where it wants pages mapped (and which command-queue pages are ready 
for execution) by altering some shared memory that serves as a control
interface to the VM, and as long as the application's request is sane,
the requested mapping would occur on the next page fault on the existing
mapping, explicitly through IOCTL, or asyncronously as desired (obviously 
we need to work on advisory locking for the VM control/status interface.)  
The items listed above could all use such a mechanism to acheive secure 
access, but in addition to that, the sugar of emulated ring buffers and 
emulated contiguous apertures using page faults are minor technical 
enhancements that are major API improvements, as they ease porting 
applications that were coded to graphics systems that had those features.

Under Linux a few mods to speed up the VM are needed, as we can 
demand that the userpace application not attempt anything esoteric
under penality of death by the kernel and thus remove some cruft, but 
basically other than that we can define our own VM fault handler
that remaps things as we please... what's the story under FreeBSD?

* Why support such cretinous hardware?  Laptops.  Especially of the
non-x86 variety.

--
Brian


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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread John Baldwin



On 06-Dec-01 Lamont Granquist wrote:
> 
> 
> On Thu, 6 Dec 2001, Leo Bicknell wrote:
>> On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote:
>> > > and ordinary user will find FreeBSD is slower, could we let user to
>> > > select which kernel to install at installing time?
>> >
>> > It's a possibility that I've considered, given that sysinstall
>> > had a hard time supporting installing FreeBSD from a single CDROM
>> > image to support both developers and the end product with a single
>> > "golden" system image.
>> >
>> > The problem with doing this is that it sort of grates against the
>> > idea of a "GENERIC" entirely.
>>
>> The problem with GENERIC is it is the lowest common denominator.
>> While it's really cool we can still boot on a 386 with 4 meg of
>> RAM, making the compromises to make that happen is not terribly
>> useful.
> 
> An alternative solution that i haven't read anyone suggest on this thread
> is simply to improve man tuning(7) and make people more aware of it.

Actually, we _can't_ boot on a 386 with 4 megs of ram.  I think you need at
least 8, and GENERIC on -current doesn't boot on a 386.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

FreeBSD performs worse that Linux - Patches #2 & #3

2001-12-06 Thread D J Hawkey Jr


Hello all.

I read with interest (and fair ignorance ;-) ) the thread about delayed
ACKs in the TCP/IP stack.

Looking at the results of tbench, it looked like something I wanted in
my 4.2 kernel. So I patched my kernel accordingly, and ran the tests:

---8<---

Pre-patch:

[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 1 localhost
Throughput 1.15675 MB/sec (NB=1.44593 MB/sec  11.5675 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 2 localhost
Throughput 2.18475 MB/sec (NB=2.73094 MB/sec  21.8475 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 3 localhost
Throughput 3.20828 MB/sec (NB=4.01035 MB/sec  32.0828 MBit/sec)

[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 1 sheol
Throughput 1.14315 MB/sec (NB=1.42894 MB/sec  11.4315 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 2 sheol
Throughput 2.12477 MB/sec (NB=2.65596 MB/sec  21.2477 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 3 sheol
Throughput 3.16156 MB/sec (NB=3.95195 MB/sec  31.6156 MBit/sec)

Post-patch:

[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 1 localhost
Throughput 13.8458 MB/sec (NB=17.3073 MB/sec  138.458 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 2 localhost
Throughput 12.8562 MB/sec (NB=16.0703 MB/sec  128.562 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 3 localhost
Throughput 12.1043 MB/sec (NB=15.1304 MB/sec  121.043 MBit/sec)

[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 1 sheol
Throughput 9.62885 MB/sec (NB=12.0361 MB/sec  96.2885 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 2 sheol
Throughput 8.7068 MB/sec (NB=10.8835 MB/sec  87.068 MBit/sec)
[sheol] /usr/home/hawkeyd/projects/dbench$ ./tbench 3 sheol
Throughput 8.89676 MB/sec (NB=11.1209 MB/sec  88.9676 MBit/sec)

--->8---

I didn't bother running through my 100Mb switch - only 10Mb NICs on the
other side. Similar results going to the "other" NIC in this box (it's
my NAT/FW/GW).

Machine particulars:

  FreeBSD sheol.localdomain 4.2-RELEASE FreeBSD 4.2-RELEASE #33: Thu Dec  6 10:20:08 
CST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/SHEOL  i386


  Copyright (c) 1992-2000 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 4.2-RELEASE #33: Thu Dec  6 10:20:08 CST 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/SHEOL
  Timecounter "i8254"  frequency 1193182 Hz
  CPU: Pentium III/Pentium III Xeon/Celeron (764.35-MHz 686-class CPU)
Origin = "GenuineIntel"  Id = 0x686  Stepping = 6

Features=0x383f9ff
  ...
  dc0:  port 0x3000-0x30ff mem 0xf410-0xf41003ff irq 11 
at device 13.0 on pci1


  dc0: flags=8843 mtu 1500
inet 192.168.16.2 netmask 0xff00 broadcast 192.168.16.255
inet6 fe80::203:6dff:fe11:63d2%dc0 prefixlen 64 scopeid 0x1 
ether 00:03:6d:11:63:d2 
media: autoselect (100baseTX ) status: active
supported media: autoselect 100baseTX  100baseTX 10baseT/UTP 
 10baseT/UTP none


If Matt or any other qualified hackers can make the time to double-check
my patches, I'd appreciate it. Matt's first patch didn't apply (no NewReno
in 4.2REL), and the third patch (to tcp_input.c) required a little more work
(I changed tests for 'tcp_delack_enabled' to 'DELAY_ACK()'). I'd just like
some assurance I got it right.

All in all, kudos to Matt for this. In day-to-day use, I can "feel" the
improvementi, and everything seems as solid as ever!

Dave

-- 
  __ __
  \__   \D. J. HAWKEY JR.   /   __/
 \/\ [EMAIL PROTECTED]/\/
  http://www.visi.com/~hawkeyd/

---8<---

--- /usr/src/sys/kern/uipc_socket.c.42REL   Fri Nov 17 13:47:27 2000
+++ /usr/src/sys/kern/uipc_socket.c Thu Dec  6 07:26:28 2001
@@ -913,6 +913,14 @@
!sosendallatonce(so) && !nextrecord) {
if (so->so_error || so->so_state & SS_CANTRCVMORE)
break;
+   /*
+* The window might have closed to zero, make
+* sure we send an ack now that we've drained
+* the buffer or we might end up blocking until
+* the idle takes over (5 seconds).
+*/
+   if (pr->pr_flags & PR_WANTRCVD && so->so_pcb)
+   (*pr->pr_usrreqs->pru_rcvd)(so, flags);
error = sbwait(&so->so_rcv);
if (error) {
sbunlock(&so->so_rcv);


--- /usr/src/sys/netinet/tcp_input.c.42REL  Wed Aug 16 01:14:23 2000
+++ /usr/src/sys/netinet/tcp_input.cThu Dec  6 10:05:53 2001
@@ -164,6 +164,17 @@
 #endif
 
 /*
+ * Indicate whether this ack should be delayed.

Re: Success! [with patch] (was Re: umass & ATAPI)


Martin Heller wrote:

> I can confirm that the patches are also working flawlessly for a Pentax
> Optio 330 on a 5.0-current system.

Great! Did you try the patch I posted (quirks added to scsi_da.c) or the 
one from the PR? (They're different.)

Lars
-- 
Lars Eggert <[EMAIL PROTECTED]>   Information Sciences Institute
http://www.isi.edu/larse/  University of Southern California


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

Re: Re[2]: switching to real mode

2001-12-06 Thread Nate Williams


> >> > I saw an example of switching in real mode in linux' sources (it looks
> >> > pretty clear) and thouhgt it is possible to do the same under FreeBSD.
> >> > The problem is I'm absolutely lost in FreeBSD's physical memory management
> >> > implementation (page tables and directory and so on).
> >> 
> >> That code is quite broken. You need to check out the ones I mentioned
> >> earlier. All that the code does in the linux kernel is fail badly.
> >> 
> >> Actually there used to be in freebsd some really nice code for popping
> >> into real mode and back again. It was to support calling BIOS for certain
> >> things.
> > 
> > I believe the code is still there, and it's used for APM bios calls,
> > if I remember correctly.
> 
> It uses VM86 mode, not real mode.  Going back and forth to real mode is too
> expensive.

Ahh, that's right.  However, if I remember right, in older versions of
FreeBSD it did the real-mode switch, because we didn't have the VM86
code.

(This would be prior to FreeBSD 4).


Nate

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Lamont Granquist




On Thu, 6 Dec 2001, Leo Bicknell wrote:
> On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote:
> > > and ordinary user will find FreeBSD is slower, could we let user to
> > > select which kernel to install at installing time?
> >
> > It's a possibility that I've considered, given that sysinstall
> > had a hard time supporting installing FreeBSD from a single CDROM
> > image to support both developers and the end product with a single
> > "golden" system image.
> >
> > The problem with doing this is that it sort of grates against the
> > idea of a "GENERIC" entirely.
>
> The problem with GENERIC is it is the lowest common denominator.
> While it's really cool we can still boot on a 386 with 4 meg of
> RAM, making the compromises to make that happen is not terribly
> useful.

An alternative solution that i haven't read anyone suggest on this thread
is simply to improve man tuning(7) and make people more aware of it.


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

Re: Re[2]: switching to real mode

2001-12-06 Thread John Baldwin



On 06-Dec-01 Nate Williams wrote:
>> > I saw an example of switching in real mode in linux' sources (it looks
>> > pretty clear) and thouhgt it is possible to do the same under FreeBSD.
>> > The problem is I'm absolutely lost in FreeBSD's physical memory management
>> > implementation (page tables and directory and so on).
>> 
>> That code is quite broken. You need to check out the ones I mentioned
>> earlier. All that the code does in the linux kernel is fail badly.
>> 
>> Actually there used to be in freebsd some really nice code for popping
>> into real mode and back again. It was to support calling BIOS for certain
>> things.
> 
> I believe the code is still there, and it's used for APM bios calls,
> if I remember correctly.

It uses VM86 mode, not real mode.  Going back and forth to real mode is too
expensive.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: switching to real mode


On Thu, 6 Dec 2001, Ronald G Minnich wrote:

> no, you are right. It's just that the freebsd code for this is a nice
> tutorial, then when he looks at bootimg or whatever it will be easier to
  ^^^
NOT a typo. bootimg is Werner Almesberger's (LILO guy) linux-boots-linux
code.

ron


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

Re: Re[2]: switching to real mode

2001-12-06 Thread Nate Williams


> > I saw an example of switching in real mode in linux' sources (it looks
> > pretty clear) and thouhgt it is possible to do the same under FreeBSD.
> > The problem is I'm absolutely lost in FreeBSD's physical memory management
> > implementation (page tables and directory and so on).
> 
> That code is quite broken. You need to check out the ones I mentioned
> earlier. All that the code does in the linux kernel is fail badly.
> 
> Actually there used to be in freebsd some really nice code for popping
> into real mode and back again. It was to support calling BIOS for certain
> things.

I believe the code is still there, and it's used for APM bios calls,
if I remember correctly.



Nate

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Mike Barcroft


Leo Bicknell <[EMAIL PROTECTED]> writes:
> Put generically, I want to see a way for users to have FreeBSD make
> better use of their hardware with at-most them having to select a
> single option of a menu of 4-5 choices.  The guy who just bought
> a gig of ram because it came in a cracker jack box should be able
> to click the 'use an obscene amount of memory to make everything
> faster' button, without having to understand the 300+ things he
> could tune in a kernel, or loader.conf, or whereever else you can
> set things.

Great, I'd love to see your patches.

Best regards,
Mike Barcroft

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

Re: switching to real mode


On Thu, 6 Dec 2001, Terry Lambert wrote:

> It isn't enough to do what he wants, though.  He wants to effectively
> return to real mode and jump to a real mode boot strap loader, as if
> in the second stage of a boot manager, after the partition to boot has
> been selected (e.g. "Reboot to Linux", "Reboot to Windows", "Reboot to
> XXX").  I understand the desire now.  It all depends on how much work
> he's willing to do.

no, you are right. It's just that the freebsd code for this is a nice
tutorial, then when he looks at bootimg or whatever it will be easier to
understand.

ron


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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Mike Barcroft

Leo Bicknell <[EMAIL PROTECTED]> writes:
> The problem with GENERIC is it is the lowest common denominator.
> While it's really cool we can still boot on a 386 with 4 meg of
> RAM, making the compromises to make that happen is not terribly
> useful.

386 support has been removed from -CURRENT.  -CURRENT also doesn't
support 486SX's out of the box, one is required to load a kernel
module from the loader if they need FPU emulation.

Best regards,
Mike Barcroft

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

Re: switching to real mode

Ronald G Minnich wrote:
> > I saw an example of switching in real mode in linux' sources (it looks
> > pretty clear) and thouhgt it is possible to do the same under FreeBSD.
> > The problem is I'm absolutely lost in FreeBSD's physical memory management
> > implementation (page tables and directory and so on).
> 
> That code is quite broken. You need to check out the ones I mentioned
> earlier. All that the code does in the linux kernel is fail badly.
> 
> Actually there used to be in freebsd some really nice code for popping
> into real mode and back again. It was to support calling BIOS for certain
> things.

It's still there.  See the code in /sys/boot, in particular,
the bios code in boot2 and boot 3.

It isn't enough to do what he wants, though.  He wants to effectively
return to real mode and jump to a real mode boot strap loader, as if
in the second stage of a boot manager, after the partition to boot has
been selected (e.g. "Reboot to Linux", "Reboot to Windows", "Reboot to
XXX").  I understand the desire now.  It all depends on how much work
he's willing to do.

-- Terry

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

Re: switching to real mode

Dmitry Konyshev wrote:

[ ... reboot with new active partition ... ]

> I thought of this way, but it might seem "strange" for a user if her
> computer would want to reboot without any obvious reason. I'll keep
> this way in mind for the case I fail to implement it in more user-friendly
> manner. :)
> 
> I saw an example of switching in real mode in linux' sources (it looks
> pretty clear) and thouhgt it is possible to do the same under FreeBSD.

During the boot process, we swithc back and forth.  Once the IDT is
replaced in low memory, though, we pretty much have to use VM86()
to access that space.

If the OS you want to boot is "DOS" or some other that runs in 8086
"real mode", then you could run it via a VM86() call, and trap the
BIOS reset vector to return you to FreeBSD by exiting the VM86()
call.  For this to work, you will probably want to be able to save
and restore a "pristine" VM86() environment (I'm not sure we template
this; you could ask Mike Smith, as he did a lot of that code).

> The problem is I'm absolutely lost in FreeBSD's physical memory management
> implementation (page tables and directory and so on).

Ugh.  FreeBSD's physical memory management... yet another series
of articles I have drafted, but haven't yet had time to complete
(I think it is a 2 or 3 part thing).  Right now, I have sent one
"Embedded BSD" article off to "Dameon News", and have another
"Embedded BSD" article (about "Rebadging FreeBSD") pending later
completion.

The answer is "you could do it, but putting the code in the low 16M
so that it would be addressible and resetting the segment registers,
IDT, etc., and disabling paging would be pretty hard".

> Devices states shouldn't be a problem because version of FreeBSD I'm
> going to use will have minimal option. Anyway I could reset such
> devices (if any) manually before loading other OS.

Device states are incredibly ugly.  I'm pretty sure that there
is not a Linux program that can successfully boot Linux from
Windows NT/95, since most of the IDT vectors in the VM86() get
moved over to point to thunks into Windows protected mode code,
so the initial VM86() calls in the Linux startup break, just
like the FreeBSD ones, since they try to thunk into an OS that
isn't there any more to service them.

You basically need to get the system back to the POST state,
after IO.SYS (and potentially, the LBA disk INT patch) have
been loaded, before Windows takes them all over.

That's basically what you are asking "How do I do this?" for
FreeBSD.

-- Terry

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Mike Silbersack

On Thu, 6 Dec 2001, Leo Bicknell wrote:

> I'm not stuck on the idea of doing it with a kernel, using loader.conf
> is fine.  I do think there are a number of relatively statically
> configured things (most of them dependant on maxusers by default)
> that loader.conf probably can't change now.
>
> Put generically, I want to see a way for users to have FreeBSD make
> better use of their hardware with at-most them having to select a
> single option of a menu of 4-5 choices.  The guy who just bought
> a gig of ram because it came in a cracker jack box should be able
> to click the 'use an obscene amount of memory to make everything
> faster' button, without having to understand the 300+ things he
> could tune in a kernel, or loader.conf, or whereever else you can
> set things.
>
> --
>Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440

No disagreement there, I just wanted to make sure that we were talking
about mulitple kernels for the correct reasons.

I have a patch which scales the maxuser-derived memory allocations at
boot time based on the amount of ram in the system that should remove the
need for much tuning on the large systems of most people.
(Super-specialized systems excluded, of course.)  I'm waiting on it
being reviewed by other committers, but I'm still holding out hope that I
can get it in for 4.5-release.

Mike "Silby" Silbersack

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

Re[2]: switching to real mode

On Thu, 6 Dec 2001, Dmitry Konyshev wrote:

> I saw an example of switching in real mode in linux' sources (it looks
> pretty clear) and thouhgt it is possible to do the same under FreeBSD.
> The problem is I'm absolutely lost in FreeBSD's physical memory management
> implementation (page tables and directory and so on).

That code is quite broken. You need to check out the ones I mentioned
earlier. All that the code does in the linux kernel is fail badly.

Actually there used to be in freebsd some really nice code for popping
into real mode and back again. It was to support calling BIOS for certain
things.

ron

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

Re: UDP checksum error after encapsulating multicast packet

Yung-Sheng Tang wrote:
> I am sorry that I don't get what you mean well. The multicast-sending
> AP, mrouted and tcpdump all run on the same machine. From tcpdump
> result, the multicast AP gives the right checksum, whereas
> encapsulating module(?) gives the wrong checksum, right? So, What next
> I should examine for?

Ah.  I thought you might have a bad source host.

See Mark Tinguely's post: he found the problem; it's a byte-order
at the tme of calculation problem.

I think you would have to HTONS(), do the checksum recalculation,
and then HTONS() it back (or delay the recalculation untul after
it was naturally HTONS()'ed, if possible).

-- Terry

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

Re: switching to real mode


On Thu, 6 Dec 2001, Terry Lambert wrote:

> Dmitry Konyshev wrote:
> > For some odd reason I need to load another OS (no matter which one,
> > everything that known about it is its boot sector number)
> > at the end of the reboot syscall. Could someone please explain how to
> > switch processor to real mode and continue program execution from some
> > point in low memory?

you can check out the various linux-boot-linux programs that do this.

It gets complex.

Four examples: bootimg, LOBOS, two-kernel-monte, and kexec.

ron


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

Re: Can TCP changes be put in RELENG_4?

On Thu, Dec 06, 2001 at 11:05:15AM -0500, Mike Silbersack wrote:
> This discussion about shipping mulitple kernels is getting silly, as
> nothing in this discussion has addressed why we need multiple kernels.  As
> of 4.4, nearly every important setting can be tuned through options in
> loader.conf; I updated the tuning manpage to recognize this a few weeks
> ago.  Give it a look over, I think most everything can be done with those
> settings.

I'm not stuck on the idea of doing it with a kernel, using loader.conf
is fine.  I do think there are a number of relatively statically
configured things (most of them dependant on maxusers by default)
that loader.conf probably can't change now.

Put generically, I want to see a way for users to have FreeBSD make
better use of their hardware with at-most them having to select a
single option of a menu of 4-5 choices.  The guy who just bought
a gig of ram because it came in a cracker jack box should be able
to click the 'use an obscene amount of memory to make everything
faster' button, without having to understand the 300+ things he
could tune in a kernel, or loader.conf, or whereever else you can
set things.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

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

Re: kld VM pager

Nicolas Souchu wrote:
> > From my reading of the code, all it is is a pseudo device that
> > permits you to establish/remove memory mappings for various regions
> > of the graphics card memory, which may or may not be apertured,
> > into process address space, as a file buffer mapping.
[ ... ]
> As you consider it later, the VM is supposed to move the aperture window
> if the hardware does not support linear frame buffering (VGA 64k window
> for example). This is a minimal feature for the so-called mmio resources.
> Some other kind of resources may be mapped as well, especially acceleration
> resources like DMA, graphic pipelines... to provide the user application a
> uniform API (memory mapping) for any kind of hw capacities.

If the intent is just to turn non-linear into linear from the
perspective of an applicaiton, and the boundary is always 4K
or more, and it's not an access aperture that needs the card
to be sent a control message to expose a different region in
the host visible window, then you just need to make a bunch
of different mappings to make non-linear physical memory into
linear virtual memory.

I'm not sure if I understand you, though.  Is all of the card
memory visible in physical memory, or is only part of the card
memory visible in physical memory?  Forget virtual for a second.

If only a part of the card memory is visible in physical memory,
then you will have to do fault handling, as I first suggested.

FreeBSD doesn't support external pagers, per se.  You might be
able to hook it in, but really, it's not expected.  You really
want to look at /sys/vm/device_pager.c.

> > Probably, you should look at the FreeBSD code for support of the
> > mmap() of console video memory, which is part of the console
> > driver itself, rather than looking at the mmap() code in the VM
> > system for help.
> 
> In this case, the mmap() is made on the /dev/console, no? Which is a
> file entry like /dev/graphic would be.

No.  The console is handled by the device pager.  It is a special
device, not a file.  Device nodes are handled differently.

Specifically, grep arounf for "d_mmap".

The main problem, if there is really an aperture you have to
move around, is that there's an implicit asumption that you have
all the memory mapped, and the "put" is as simple as just
writing to memory, so you aren't going to get the write fault
that gets handled by a fault handler that you need.

You might be able to hack together something based on the code
in /sys/vm/swap_pager.c, but you would need to do the same as
swap_pager_unswapped() on the pages in the prior aperture, if
you adjusted the aperture at all.

I find it incredibly hard to believe that anyone would build a
video card that would be so slow to access, but I could easily
be wrong here.

> > The only issue I see that might be tough is that the aperture
> > might be too small for the full card memory.
> >
> > If this is the case, you will probably need to allocate kernel
> > memory for it, and do explicit coherency calls, after moving
> > the aperture (if necessary).  I don't think anything does this
> > in FreeBSD now, so there might be read/write fault handler work
> > required (e.g. unmap the memory, but reserve a mapping hole for
> 
> Isn't the pager responsible for this?

Not really.  The card is still backing store, but it has different
physical memory exposed.  It's more like a disk driver, at that
point, where the physical disk is acting as backing store for
RAM (except you want the write through to be immediate, not
deleayed, as it would be with a disk driver, so that your changes
are reflected when you want them to be, instead of some time
later).  Basically you "address" the card memory into the window
and write it, the same way you do PIO to a disk, where the host is
responsible for the DMA into the disk RAM that represents the
addressed sector.

It's possible to write a different pager to do this, but you would
have to really work to hook it in.  Basically, you would open the
device, and work up the chain and replace it in the vnode that
was opened for the device.

The problem with doing this is that you are then responsible
for instance reference counting, and you have to ask for close
notifications to be able to do this (they are[were?] not default).

> > Unfortunately, the book you are looking at doesn't know about
> > the VM and buffer cache unification which occurred in FreeBSD,
> > so it doesn't know that the memory in the buffer cache _IS_
> > the backing object, as far as you are concerned.
> 
> But, I don't want any kind of buffering. /dev/graphic is just a Unix-like
> file entrypoint to pass orders to the VM.

You have buffering, anyway, if you have an aperture mapping that
is changing.  Minimally, you have to take a fault on the write
to any memory not currently exposed in the aperture, remap the
aperture, and then restart the operation with the fault having
been satisfied.  So you will need to remap the pages as having
or not havin

Re[2]: switching to real mode

2001-12-06 Thread Dmitry Konyshev

Hello Terry,

Thursday, December 06, 2001, 6:08:44 PM, you wrote:

TL> Dmitry Konyshev wrote:
>> For some odd reason I need to load another OS (no matter which one,
>> everything that known about it is its boot sector number)
>> at the end of the reboot syscall. Could someone please explain how to
>> switch processor to real mode and continue program execution from some
>> point in low memory?

TL> The system is not reset to real mode on reboot.

TL> To reset the system to real mode, you should probably copy the
TL> VM86 memory area over low core, and switch that way.  It will
TL> be incredibly difficult.  You might also be able to re-POST
TL> the low core memory with a software reset in VM86, but I would
TL> not rely on this not really resetting the machine.

TL> The real problem is the interrupt routing table and the active
TL> devices which may result in interrupts during this process; if
TL> you take away the FreeBSD IRQ routing and substitute the BIOS
TL> routing, things will probably go to hell.  At the very least,
TL> using BIOS services will be unreliable, unless all devices are
TL> returned to POST state (I had a system at one time that did not
TL> reset UART state on POST, and the serial ports ceased to work
TL> correctly without a power off, since the Xenix I was running
TL> enabled the FIFOs, and the BIOS post did not disable them).

TL> A better alternative would be to simply mark the target partition
TL> as "active" and reboot normally (assuming that you don't want to
TL> reboot to FreeBSD on power on, and then switch to another OS on
TL> a soft reboot only).  Most "multiboot" boot managers will mark
TL> the booting partition as active as part of their boot selection
TL> process.

I thought of this way, but it might seem "strange" for a user if her
computer would want to reboot without any obvious reason. I'll keep
this way in mind for the case I fail to implement it in more user-friendly
manner. :)

I saw an example of switching in real mode in linux' sources (it looks
pretty clear) and thouhgt it is possible to do the same under FreeBSD.
The problem is I'm absolutely lost in FreeBSD's physical memory management
implementation (page tables and directory and so on).

Devices states shouldn't be a problem because version of FreeBSD I'm
going to use will have minimal option. Anyway I could reset such
devices (if any) manually before loading other OS.

TL> Without a better understanding of why it is you think you want
TL> to do this evil thing, I can only suggest reading:

TL> Protected Mode Software Architecture
TL> Tom Shanley
TL> Mindshare, Inc.
TL> Addison-Wesley Publishing Company
TL> ISBN 0-201-5447-X

TL> -- Terry

-- 
Best regards,
 Dmitrymailto:[EMAIL PROTECTED]

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

Re: UDP checksum error after encapsulating multicast packet

2001-12-06 Thread Yung-Sheng Tang

On Thu, 6 Dec 2001, Terry Lambert wrote:

> On the other hand, you should also examine the packet in
> from the other machine, as the checksum might have started
> out broken.  If so, an incremental update wouldn't correct
> it.

I am sorry that I don't get what you mean well. The multicast-sending
AP, mrouted and tcpdump all run on the same machine. From tcpdump
result, the multicast AP gives the right checksum, whereas
encapsulating module(?) gives the wrong checksum, right? So, What next
I should examine for?

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

Re: UDP checksum error after encapsulating multicast packet


In bad taste to reply to myself...I said:

> My best guess is that someone has the UDP src, dst and ports in host
> order not net order and on Intel arch. this causes a UDP checksum error.
>It may have something to do with this being the originating host,
> and wee have a copy of the packet before the net byte order was restored.

it apprears from tcp_output.c that the offset and length fields are in
host order at the time that mforward is called, not the src, dst, port
like I speculated above.

in sys/netinet/ip_mroute.c, before you calculate the cksum, you need
to use HTONS() or htons() to place these fields in network order.

If you need a diff, I can give you one, I unfortunately cannot test it
for you.

--mark tinguely.

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Mike Silbersack

On Thu, 6 Dec 2001, Leo Bicknell wrote:

> Would it not be simple to create say, GENERIC-64M, GENERIC-128M,
> GENERIC-256M (or small medium large, or whatever), tune a number
> of critical parameters, and just ship them as part of /bin?  Surely
> the code to have the installer check the sysctl for the amount
> of ram in the machine and hard link that one to /kernel would
> be trival, and at least give us something.  Just by changing a
> few memory settings and making a "guess" about maxusers (and
> the cascade of changes that has) based on total RAM would be a
> crude but useful start.
>
> --
>Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440

This discussion about shipping mulitple kernels is getting silly, as
nothing in this discussion has addressed why we need multiple kernels.  As
of 4.4, nearly every important setting can be tuned through options in
loader.conf; I updated the tuning manpage to recognize this a few weeks
ago.  Give it a look over, I think most everything can be done with those
settings.

What would be interesting to know is whether or not any non-tuneable
options make a performance difference.  For example, I386_CPU, unneeded
device drivers, etc.  If that's the case, maybe multiple kernels is a
possibility.  However, if we're just talking about maxusers and mbufs,
there's no need for a different kernel.

Mike "Silby" Silbersack

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

Re: Can TCP changes be put in RELENG_4?

On Thu, Dec 06, 2001 at 10:49:48AM -0500, Michael R. Wayne wrote:
> There needs to be an >automatic< way to help the new user get a
> better kernel on his box.  Matt Dillon provided a man page, now
> what's needed is a program (call it autotune) that looks at the
> machine and, possibly after asking the user some questions about
> proposed machine use, builds OPTIMIZED and generates changes for
> system files (e.g. adding softupdates to /etc/fstab).

Would it not be simple to create say, GENERIC-64M, GENERIC-128M,
GENERIC-256M (or small medium large, or whatever), tune a number
of critical parameters, and just ship them as part of /bin?  Surely
the code to have the installer check the sysctl for the amount
of ram in the machine and hard link that one to /kernel would
be trival, and at least give us something.  Just by changing a
few memory settings and making a "guess" about maxusers (and
the cascade of changes that has) based on total RAM would be a
crude but useful start.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Michael R. Wayne

On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote:
> 
> > and ordinary user will find FreeBSD is slower, could we let user to
> > select which kernel to install at installing time?
> 
> It's a possibility that I've considered, given that sysinstall
> had a hard time supporting installing FreeBSD from a single CDROM
> image to support both developers and the end product with a single
> "golden" system image.
> 
> The problem with doing this is that it sort of grates against the
> idea of a "GENERIC" entirely.

GENERIC is just fine the way it is.  I have always considered it
a way to get everything installed and a nice saftey net. 

The issue is not that GENERIC performs poorly, the issue is that
the kernel that remains on the box performs poorly.  I've been
considering this issue for a quite some time.

There needs to be an >automatic< way to help the new user get a
better kernel on his box.  Matt Dillon provided a man page, now
what's needed is a program (call it autotune) that looks at the
machine and, possibly after asking the user some questions about
proposed machine use, builds OPTIMIZED and generates changes for
system files (e.g. adding softupdates to /etc/fstab).

A scaled back version of autotune would also run daily out of cron
to check system resources (e.g. mbuf utilization), parse syslogs
and suggest a kernel reconfig/rebuild as needed.

Given a working, easy to update skeleton program, I suspect that
convincing the person who most understands a given subsystem to write
optimization rules would not be difficult. 

/\/\ \/\/

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

Re: kld VM pager

2001-12-06 Thread Nicolas Souchu


On Thu, Dec 06, 2001 at 06:51:38AM -0800, Terry Lambert wrote:
> Nicolas Souchu wrote:
> > 
> > Hi VM developers,
> > 
> > Has anyone already some useful utils to develop a VM pager for FreeBSD?
> > The KGI port project is progressing and is now up to the point that I have
> > to handle the VM events as done in Linux.
> > 
> > http://www.freebsd.org/~nsouch/ggiport.html
> 
> Your "README.kgi" referenced by this page does not exist.

True, until I fix it, I join it to the mail.

> I went looking for "graphic.c", and found it at:
> 
> 
>
> 
> >From my reading of the code, all it is is a pseudo device that
> permits you to establish/remove memory mappings for various regions
> of the graphics card memory, which may or may not be apertured,
> into process address space, as a file buffer mapping.

Although I'm not completly aware of KGI VM features, it seems to be
a bit more complex (I quote entirely your mail and cc to KGI mailing
for this reason).

As you consider it later, the VM is supposed to move the aperture window
if the hardware does not support linear frame buffering (VGA 64k window
for example). This is a minimal feature for the so-called mmio resources.
Some other kind of resources may be mapped as well, especially acceleration
resources like DMA, graphic pipelines... to provide the user application a
uniform API (memory mapping) for any kind of hw capacities.

> In FreeBSD, the VM and buffer cache are unified, so what you
> really want it to map the memory into the process space directly,
> rather than into the file (in Linux, this amounts to equating a
> region of a pseudo-file buffer cache to the memory on board the
> graphics card).
> 
> Probably, you should look at the FreeBSD code for support of the
> mmap() of console video memory, which is part of the console
> driver itself, rather than looking at the mmap() code in the VM
> system for help.

In this case, the mmap() is made on the /dev/console, no? Which is a
file entry like /dev/graphic would be.

> Worst case, you can look at the hook in for anonymous memory
> mappings in the /dev/zero pseudo device, but since it grabs
> anonymous pages, rather than explicit physical pages, it's much
> less interesting.
> 
> The only issue I see that might be tough is that the aperture
> might be too small for the full card memory.
> 
> If this is the case, you will probably need to allocate kernel
> memory for it, and do explicit coherency calls, after moving
> the aperture (if necessary).  I don't think anything does this
> in FreeBSD now, so there might be read/write fault handler work
> required (e.g. unmap the memory, but reserve a mapping hole for

Isn't the pager responsible for this?

> it, and then move the aperture as necesswary to satisfy the
> fault, and restart the request; this assumes that the aperture
> is 4k or some multiple thereof, so it's on even page boundaries).
> 
> I don't know of any video card where this would be required, but
> you could imagine one (e.g. the TI 99/4A had apertured 4k window
> onto video RAM, making it hard to update).  I suspect you could
> just ignore the problem entirely (I don't see a fault handler for
> an aperture adjustment in the Linux code, but perhaps I'm not
> reading it correctly, or my memory of the Linux VM is not as fresh
> as it needs to be to correctly answer the question).
> 
> 
> > Reading the 4.4BSD Internals, I've understood that I should look in the pager
> > direction and the code shows that the device pager is not much far from my
> > willing...
> 
> Actually, it's very far away.
> 
> Unfortunately, the book you are looking at doesn't know about
> the VM and buffer cache unification which occurred in FreeBSD,
> so it doesn't know that the memory in the buffer cache _IS_
> the backing object, as far as you are concerned.

But, I don't want any kind of buffering. /dev/graphic is just a Unix-like
file entrypoint to pass orders to the VM.

> Since you don't care about backing store, there isn't an explicit
> coherency requirement (even in Linux, there is no such explicit
> coherency requirement, since you are operating on the mmap'ed
> object directly... which is why Linux doesn't require a backing
> store allocation, either).
> 
> 
> > More precisely, has anybody some way to load/unload a pager? Is it really
> > possible? What advices could you address me before I start this?
> 
> You really don't want to do this.  Just map the memory directly
> into the target process address space (see examples, cited above).

What would handle my VM faults in this case?

> If the issue is mapping it into the kernel virtual address space,
> a cheap way of doing both is to set the PG_U bit on the page,
> which will make the kernel memory space visible to (all) user
> processes.  This might lack sufficient priviledge protection for
> your tastes.  The alternative is to map it into both address
> spaces.
> 
> M

Re: Can TCP changes be put in RELENG_4?

Leo Bicknell wrote:
> Would result in what machines not booting?  As long as a 64M PC
> can boot (even if it has only 10 Meg free for user apps) that's ok
> in my book.  If we're still trying to boot on 4, 8, or 16 meg
> machines that's just dumb.

Ugh, save me from the Novell decision that lost UNIX the desktop
market!

> As I've said before, there are two types of FreeBSD users.  There
> are "users", who want something to replace windows and who really
> like the Linux distro's with KDE and all that.  These people are
> unlikely to build a kernel, and as time goes by are even less likely
> to know what a kernel is.  They are also likely to have a < 3 year
> old PC, probably that they are dual booting.  Linux recognized this,
> and targest this sort of hardware out-of-the-box.

If they are dual booting, then either they are clued enough
to repartition their disk (ala "Partition Magic"), or they
have installed a second disk on the machine.  Either one is
an argument that they are clued enough to build a kernel,
and even if they aren't, are willing to go to extra effort to
run the software.

I would be much more in favor of targeting large server users
with any changes that you want to make, and even then, I
don't see orphaning small meory systems.  In fact, with the
drivers being mostly modular, I see a time when "GENERIC"
will contain only the boot devices, and load the rest of the
drivers as modules, and we might see 8M machines make a
comeback (or even 4M, the RAM disk gods willing).

> The second type of user is someone like you, or me, or most of the
> people on this list.  They will build a custom kernel no matter
> how appropriate the default settings.  They will tune things for
> odd application boxes, like IRC and News servers and the like.
> The defaults are virtually irrevelant for these people, provided
> sysinstall can finish.

This is a big "if".  Installation is the main barrier to entry
for FreeBSD these days, IMO, and it needs to work if it can,
and not fail because of a bad default.

> As far as I'm concerned any machine with < 64M these days falls
> into the second catagory, where someone should have to futz with
> it to make it work.  When 256M DIMMs are $18 we need to get with
> the program.

I still think that most first time installations are on old
hardware that has outlived its usefulness as a Microsoft
platform, as Windows has moved upmarket on the hardware it is
willing to run on.

(NBL This is quickly turning into something that should be on
-advocacy, not -hackers).

> This is one area where Microsoft got it right.  Worrying about the
> hardware isn't worth your time.  It will continue to grow at moores
> law, making the bloat unimportant.  Target what's being sold now,
> as if you target last years computers by the time your OS is on
> them next year they will be retired.

Microsoft got it wrong here.

The problem is that Microsoft engineers get the new toys before
the consumers do, so when the software is written, there's no
incentive to make it run in a smaller footprint (disk, RAM,
whatever).  I would be sorely tempted to restrict all the
Microsoft engineers to 1 year old machines, for everything
but compiling, so that they could feel their customer's pain.

-- Terry

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

Re: Can TCP changes be put in RELENG_4?

Jonathan Lemon wrote:
> 
> In article [EMAIL PROTECTED]> you write:
> >Really, it boils down to the allocation systems needing rewrite,
> >and (painful as this is to say) a move away from type stable
> >memory, to permit reuse, rather than static purposing of large
> >blocks: static purposing is the primary reason a general turning
> >can not be near optimal for a lot of applications.
> 
> Okay, this I can agree with.  But I don't have the time or inclination
> to write a new memory allocator.  Did you have something in mind?

I have a modification of the zone allocator which is much better
at not wasting space, and doesn't recalculate information which
never changes.

I think that this combined with Alfred Perlsteins "second level"
("Horde") allocator code might be enough to allow the second
level to reclaim page chunks at a time.

I'm really loathe to suggest it, but going to a "handle" style
mechanism ala Macintosh would make it very easy to move memory
out from under the pointers that reference it, but it's too
expensive to ven contemplate.

The real problem is knowing when a region of a zone can be
reclaimed.  Probably, you want three reclaimation policies:

1)  Never (you could default to this for debugging)
2)  High watermark (when "free" exceeds the high
watermark, reclaim what you can until you hit a
point just above the low watermark or can't
reclaim any more)
3)  Dire circumstances (a callback mechanism that is
a "return what you can to the system", for use in
extreme low memory circumstances)

There are corresponding allocation policies, as well:

1)  Static (this is _my_ memory)
2)  Low watermark (may or may not include initial fill
to the low watermark)
3)  As much as you can, up to some maximum

You'd need the same zone differentiation that lives there
currently too, to seperate what can and can't be allocated at
interrupt time (allocation would be in N-page units, per the
modified zone allocator that avoids recalculation and is
space efficient).

So if you wanted to allocate an mbuf (for example), they are 256
bytes, so you would get 1 page out of KVA space where a preexiting
page mapping existed, yielding 16 new mbufs, and return one of
those, assuming you didn't fail the allocation because you had hit
an administrative limit on the total number of mbufs, or there was
no memory available for backing.

You could similarly chunk the KVA space into regions, based on the
expected mapping size allocation units (e.g. an even number of
pages for a 60 byte structure to not waste space would be 15, so
the expected allocation unit would be 15 pages) to avoid fragmentation,
but unless that's shown to be a problem in the real world, it's
probably overkill (you'd need to change from one load type to a
drastically dissimilar load type to trigger something like this, I
believe).

-- Terry

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

Re: switching to real mode

2001-12-06 Thread Bob Bishop


Hi,

At 17:04 06/12/01 +0300, Dmitry Konyshev wrote:
>Hello!
>
>For some odd reason I need to load another OS (no matter which one,
>everything that known about it is its boot sector number) [etc]

man boot0cfg, look at the -s option.

eg something like:

boot0cfg -s 2 ad0
reboot

--
Bob Bishop  +44 (0)118 977 4017
[EMAIL PROTECTED]fax +44 (0)118 989 4254


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

Re: UDP checksum error after encapsulating multicast packet


the UDP checksum should not change before encapsulation. re-displaying
your packets:

18:27:12.968167 192.9.200.127.1399 > 224.2.3.4.1234: [udp sum ok] udp
16 (ttl 16, id 38554, len 44)
4500 002c 969a  1011 a897 c009 c87f
^^   
ttl  ipcksm
e002 0304 0577 04d2 0018 22c5
 
 udpcksm
ea02 0400 3c0f 4401 0001 3145 c7c6 
data

18:27:12.968185 192.9.200.127 > 150.9.120.183: 192.9.200.127.1399 >
224.2.3.4.1234:  [bad udp cksum bb7!] udp 16 (ttl 15, id 38554, len 44)
(ttl 64, id 38555, len 64)
4500 0040 969b  4004 4cd5 c009 c87f
9609 78b7
ip-ip ecap (not use in the below UDP checksum)
4500 002c 969a  0f11 a997 c009 c87f
^^   
ttl  ipcksm
e002 0304 0577 04d2 0018 6bb9
 
 udpcksm
ea02 0400 3c0f 4401 0001 3145 c7c6 

the only thing that changes from the first calculation of the UDP checksum
to the final calculation of the UDP checksum is the decrement of the TTL and
the adjustment of the IP header checksum these changes will not change the
UDP checksum (they cancel out).

My best guess is that someone has the UDP src, dst and ports in host
order not net order and on Intel arch. this causes a UDP checksum error.
It may have something to do with this being the originating host,
and wee have a copy of the packet before the net byte order was restored.

--mark tinguely.

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

Re: switching to real mode

Dmitry Konyshev wrote:
> For some odd reason I need to load another OS (no matter which one,
> everything that known about it is its boot sector number)
> at the end of the reboot syscall. Could someone please explain how to
> switch processor to real mode and continue program execution from some
> point in low memory?

The system is not reset to real mode on reboot.

To reset the system to real mode, you should probably copy the
VM86 memory area over low core, and switch that way.  It will
be incredibly difficult.  You might also be able to re-POST
the low core memory with a software reset in VM86, but I would
not rely on this not really resetting the machine.

The real problem is the interrupt routing table and the active
devices which may result in interrupts during this process; if
you take away the FreeBSD IRQ routing and substitute the BIOS
routing, things will probably go to hell.  At the very least,
using BIOS services will be unreliable, unless all devices are
returned to POST state (I had a system at one time that did not
reset UART state on POST, and the serial ports ceased to work
correctly without a power off, since the Xenix I was running
enabled the FIFOs, and the BIOS post did not disable them).

A better alternative would be to simply mark the target partition
as "active" and reboot normally (assuming that you don't want to
reboot to FreeBSD on power on, and then switch to another OS on
a soft reboot only).  Most "multiboot" boot managers will mark
the booting partition as active as part of their boot selection
process.

Without a better understanding of why it is you think you want
to do this evil thing, I can only suggest reading:

Protected Mode Software Architecture
Tom Shanley
Mindshare, Inc.
Addison-Wesley Publishing Company
ISBN 0-201-5447-X

-- Terry

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

Re: UDP checksum error after encapsulating multicast packet

Yung-Sheng Tang wrote:
> 
> I am setting up a multicast router. Recompiling kernel with MROUTING
> option and enabling mrouted are done. Basically, my multicast AP runs
> well, but if that AP and mrouted run on the same machine, forwarded
> packets would get udp checksum error. Here is the result from tcpdump:

[ ... ]

> Did I make some mistake? Thank you for your attention.

I have noticed a number of bad checksum instances, as well, in
particular in the piggy-back ACK implementation of a former
coworker, but did not track them down.

It seems to me that this is the "one's complement" problem that
the incremental checksum modification RFC update refers to, but
I could be mistaken.

I don't think that code is incredibly exercised in FreeBSD.

On the other hand, you should also examine the packet in
from the other machine, as the checksum might have started
out broken.  If so, an incremental update wouldn't correct
it.

-- Terry

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

Re: kld VM pager

Nicolas Souchu wrote:
> 
> Hi VM developers,
> 
> Has anyone already some useful utils to develop a VM pager for FreeBSD?
> The KGI port project is progressing and is now up to the point that I have
> to handle the VM events as done in Linux.
> 
> http://www.freebsd.org/~nsouch/ggiport.html

Your "README.kgi" referenced by this page does not exist.

I went looking for "graphic.c", and found it at:

>From my reading of the code, all it is is a pseudo device that
permits you to establish/remove memory mappings for various regions
of the graphics card memory, which may or may not be apertured,
into process address space, as a file buffer mapping.

In FreeBSD, the VM and buffer cache are unified, so what you
really want it to map the memory into the process space directly,
rather than into the file (in Linux, this amounts to equating a
region of a pseudo-file buffer cache to the memory on board the
graphics card).

Probably, you should look at the FreeBSD code for support of the
mmap() of console video memory, which is part of the console
driver itself, rather than looking at the mmap() code in the VM
system for help.

Worst case, you can look at the hook in for anonymous memory
mappings in the /dev/zero pseudo device, but since it grabs
anonymous pages, rather than explicit physical pages, it's much
less interesting.

The only issue I see that might be tough is that the aperture
might be too small for the full card memory.

If this is the case, you will probably need to allocate kernel
memory for it, and do explicit coherency calls, after moving
the aperture (if necessary).  I don't think anything does this
in FreeBSD now, so there might be read/write fault handler work
required (e.g. unmap the memory, but reserve a mapping hole for
it, and then move the aperture as necesswary to satisfy the
fault, and restart the request; this assumes that the aperture
is 4k or some multiple thereof, so it's on even page boundaries).

I don't know of any video card where this would be required, but
you could imagine one (e.g. the TI 99/4A had apertured 4k window
onto video RAM, making it hard to update).  I suspect you could
just ignore the problem entirely (I don't see a fault handler for
an aperture adjustment in the Linux code, but perhaps I'm not
reading it correctly, or my memory of the Linux VM is not as fresh
as it needs to be to correctly answer the question).

> Reading the 4.4BSD Internals, I've understood that I should look in the pager
> direction and the code shows that the device pager is not much far from my
> willing...

Actually, it's very far away.

Unfortunately, the book you are looking at doesn't know about
the VM and buffer cache unification which occurred in FreeBSD,
so it doesn't know that the memory in the buffer cache _IS_
the backing object, as far as you are concerned.

Since you don't care about backing store, there isn't an explicit
coherency requirement (even in Linux, there is no such explicit
coherency requirement, since you are operating on the mmap'ed
object directly... which is why Linux doesn't require a backing
store allocation, either).

> More precisely, has anybody some way to load/unload a pager? Is it really
> possible? What advices could you address me before I start this?

You really don't want to do this.  Just map the memory directly
into the target process address space (see examples, cited above).

If the issue is mapping it into the kernel virtual address space,
a cheap way of doing both is to set the PG_U bit on the page,
which will make the kernel memory space visible to (all) user
processes.  This might lack sufficient priviledge protection for
your tastes.  The alternative is to map it into both address
spaces.

Matt Dillon could give you more help, as could Bruce Evans, Alfred
Perlstein, me, or half a dozen other people, when you decide the
effect you are trying to achive, rather than trying to do exactly
what Linux does to achieve the effect, assuming that the examples
aren't sufficient by themselves.  Let one of us know; I'm personally
very intersted in seeing this get into FreeBSD, considering 386BSD
first started working on something like this back at the end of 1992.

-- Terry

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

Final summary: [WAS Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]

2001-12-06 Thread Greg Lane


G'day everyone,

Sorry I was out of the loop for a couple of days. One of our students
handed in his thesis. It has been a tad busy.

I did the following tests on my laptop by just remaking ppp alone (rather
than the world like in my first attempts to track down the problem) 
using source from 12am 30th july and 12am 1st August. This was 
with a 4.4-stable kernel and userland. 

A few people with Telstra ADSL emailed me saying they have no
problems at all using recent versions, (4.4 release and very recent
4.4-stable). 

However, it appears they have all used values of 1492 rather
than 1454 for mtu/mru. Phillip Crumpler stated that he found these
values by removing the set lines from his ppp.conf and letting it
autonegotiate. I tried that and it indeed auto-negotiated values of
1492 and worked AOK. Directly setting the values to 1492 with:

  set mru 1492
  set mtu 1492

worked OK too. However setting to 1454 didn't work in two
aspects. First, rather than setting to 1454, the mtu was set to 1492
which agrees with the behaviour in the PR of Jim Housley: 

http://www.freebsd.org/cgi/query-pr.cgi?pr=32040

where the "set" option was observed not to "set" at all. Secondly, 
traffic with "large" packets failed to flow. 

On Brian's suggestion I tried 

  set mru max 1454
  set mtu max 1454

with the Aug 1st version which happily set the mtu and mru to 1454 and
worked without a problem. 

Once I knew I could reproduce everything, I updated my gateway box to
4.4-stable, made the world and confirmed that the behaviour was the
same on it as in my laptop tests with ppp from Aug 1st. So the strange
behaviour was introduced on July 30th. 

I have emailed the ppp connection logs direct to Brian rather than
send an (even more!) lengthy email to the lists. 

So the upshot is I now have a working 4-STABLE gateway (hooray!!) and
can confirm the PR of Jim Housley. If anyone is using more recent
versions of stable (post Jul 30th) with Telstra ADSL I am pretty sure
they will have trouble if they follow Paul Hoadley's instructions
(www.logicsquad.net) exactly. The "set mt[ur] 1454" has to be
changed to either "set mt[ur] max 1454" or "set mt[ur] 1492".

A big thanks to everyone who responded!! I really appreciate it.

Greg

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

Re: Can TCP changes be put in RELENG_4?

2001-12-06 Thread Jonathan Lemon


In article [EMAIL PROTECTED]> you write:
>Really, it boils down to the allocation systems needing rewrite,
>and (painful as this is to say) a move away from type stable
>memory, to permit reuse, rather than static purposing of large
>blocks: static purposing is the primary reason a general turning
>can not be near optimal for a lot of applications.

Okay, this I can agree with.  But I don't have the time or inclination
to write a new memory allocator.  Did you have something in mind?
-- 
Jonathan

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

Re: Can TCP changes be put in RELENG_4?

On Thu, Dec 06, 2001 at 06:23:31AM -0800, Terry Lambert wrote:
> > I'd suggest our target should be a P-III 600 with around 256M of
> > RAM as what Generic should be tuned for
> 
> Can't.  The static allocations for that much assumed RAM would
> result in the machine not booting, with the amount of RAM for
> the page tables alone ~1/4M.  By default, the 120M KVA space
> mappings are arguably overlarge for small memory machines.

Would result in what machines not booting?  As long as a 64M PC
can boot (even if it has only 10 Meg free for user apps) that's ok
in my book.  If we're still trying to boot on 4, 8, or 16 meg
machines that's just dumb.

As I've said before, there are two types of FreeBSD users.  There
are "users", who want something to replace windows and who really
like the Linux distro's with KDE and all that.  These people are
unlikely to build a kernel, and as time goes by are even less likely
to know what a kernel is.  They are also likely to have a < 3 year
old PC, probably that they are dual booting.  Linux recognized this,
and targest this sort of hardware out-of-the-box.

The second type of user is someone like you, or me, or most of the
people on this list.  They will build a custom kernel no matter
how appropriate the default settings.  They will tune things for
odd application boxes, like IRC and News servers and the like.
The defaults are virtually irrevelant for these people, provided
sysinstall can finish.

As far as I'm concerned any machine with < 64M these days falls
into the second catagory, where someone should have to futz with
it to make it work.  When 256M DIMMs are $18 we need to get with
the program.

This is one area where Microsoft got it right.  Worrying about the
hardware isn't worth your time.  It will continue to grow at moores
law, making the bloat unimportant.  Target what's being sold now,
as if you target last years computers by the time your OS is on
them next year they will be retired.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

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

Re: Can TCP changes be put in RELENG_4?

I've shortened the Cc: list (don't know if you are on -hacker, Leo,
so I left you on; sortry if you get two copies).

Leo Bicknell wrote:
> > The problem with doing this is that it sort of grates against the
> > idea of a "GENERIC" entirely.
> 
> The problem with GENERIC is it is the lowest common denominator.
> While it's really cool we can still boot on a 386 with 4 meg of
> RAM, making the compromises to make that happen is not terribly
> useful.

No.

GENERIC can not auto-size its structures at runtime.  This means
even something as relatively simple as scaling of amount of real,
physical RAM, is not an option.

After that hurdle is passed, then installation specific tuning of
some subsystems at the expense of others (e.g. never drop below a
low watermark for certain structures, but permit allocation of RAM
to mbufs on a network server or process memory on an application
server, etc.) needs to be considered.  This can't be done now,
since once respources are committed to a specif purpose, they must
remain committed to that purpose.

I think that it's also going to far to adjust the KVA space at
boot time, instead of runtime, though that should certainly become
feasible at some point (just not now).  One could easily imagine
a KVA space of 3G for a network cache server, but 1G (or less)
for an application server, and such a beast would be impossible to
get in a runtime adjustment scenario.

> GENERIC should be tuned _above_ the median PC, because after it's
> out PC's will continue to be upgraded.  If we want to retain the
> (easy) ability to boot on a 4 meg machine we can supply a second
> MICRO-GENERIC.

This implies the issue of distributing multiple kernels, and the
sysinstall issues that that causes, have all been resolved.  At a
bare minimum, installation requires a minimal resource kernel for
boot, since boot could be taking place on a minimally resourced
machine.

> For some random thoughts, MAXMEM should be 256M minimum, 1G
> preferably.

This is an operational limit.  It's possible to compile a kernel
with a large value, and dynamically size it down to reasonableness,
based on knowing the real physical memory size.  This is a special
case, however, since what we are really talking about with MAXMEM
is an administrative limit bounded by swap and user memory size.

> MAXUSERS should be perhaps 128 or 256 out of the box.

This is much less cut and dried, since these things are (probably
incorrectly) used to size other allocations (allocations which also
could be reasonably dynamically sized, in the absence of intentional
administrative override, e.g. in the local loader.rc).

> I'd suggest our target should be a P-III 600 with around 256M of
> RAM as what Generic should be tuned for

Can't.  The static allocations for that much assumed RAM would
result in the machine not booting, with the amount of RAM for
the page tables alone ~1/4M.  By default, the 120M KVA space
mappings are arguably overlarge for small memory machines.

-- Terry

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

switching to real mode

2001-12-06 Thread Dmitry Konyshev


Hello!

For some odd reason I need to load another OS (no matter which one,
everything that known about it is its boot sector number)
at the end of the reboot syscall. Could someone please explain how to
switch processor to real mode and continue program execution from some
point in low memory?

Thanks in advance.

-- 
Best regards,
Dmitry Konyshev mailto:[EMAIL PROTECTED]


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

UDP checksum error after encapsulating multicast packet

2001-12-06 Thread Yung-Sheng Tang




I am setting up a multicast router. Recompiling kernel with MROUTING
option and enabling mrouted are done. Basically, my multicast AP runs
well, but if that AP and mrouted run on the same machine, forwarded 
packets would get udp checksum error. Here is the result from tcpdump:


18:27:12.968167 192.9.200.127.1399 > 224.2.3.4.1234: [udp sum ok] udp 
16 (ttl 16, id 38554, len 44)
 4500 002c 969a  1011 a897 c009 c87f
 e002 0304 0577 04d2 0018 22c5 ea02 0400
 3c0f 4401 0001 3145 c7c6 
18:27:12.968185 192.9.200.127 > 150.9.120.183: 192.9.200.127.1399 > 
224.2.3.4.1234:  [bad udp cksum bb7!] udp 16 (ttl 15, id 38554, len 44)
(ttl 64, id 38555, len 64)
 4500 0040 969b  4004 4cd5 c009 c87f
 9609 78b7 4500 002c 969a  0f11 a997
 c009 c87f e002 0304 0577 04d2 0018 6bb9
 ea02 0400 3c0f 4401 0001 3145 c7c6 

Did I make some mistake? Thank you for your attention.

--
Yung-Sheng Jeff Tang



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

kld VM pager

2001-12-06 Thread Nicolas Souchu


Hi VM developers,

Has anyone already some useful utils to develop a VM pager for FreeBSD?
The KGI port project is progressing and is now up to the point that I have
to handle the VM events as done in Linux.

http://www.freebsd.org/~nsouch/ggiport.html

Reading the 4.4BSD Internals, I've understood that I should look in the pager
direction and the code shows that the device pager is not much far from my
willing...

More precisely, has anybody some way to load/unload a pager? Is it really
possible? What advices could you address me before I start this?

Thanks in advance!

Nicholas

-- 
Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com
FreeBSD Developer - [EMAIL PROTECTED]

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

Re: Can TCP changes be put in RELENG_4?

On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote:
> > and ordinary user will find FreeBSD is slower, could we let user to
> > select which kernel to install at installing time?
> 
> It's a possibility that I've considered, given that sysinstall
> had a hard time supporting installing FreeBSD from a single CDROM
> image to support both developers and the end product with a single
> "golden" system image.
> 
> The problem with doing this is that it sort of grates against the
> idea of a "GENERIC" entirely.

The problem with GENERIC is it is the lowest common denominator.
While it's really cool we can still boot on a 386 with 4 meg of
RAM, making the compromises to make that happen is not terribly
useful.

GENERIC should be tuned _above_ the median PC, because after it's
out PC's will continue to be upgraded.  If we want to retain the
(easy) ability to boot on a 4 meg machine we can supply a second
MICRO-GENERIC.

For some random thoughts, MAXMEM should be 256M minimum, 1G
preferably.  MAXUSERS should be perhaps 128 or 256 out of the box.
I'd suggest our target should be a P-III 600 with around 256M of
RAM as what Generic should be tuned for

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

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

Re: [Fwd: Jul 30 changes to ppp break my Telstra ADSL PPPoE connection]

2001-12-06 Thread Brian Somers


> Brian Somers wrote:
> > 
> > Hi,
> > 
> > Thanks for your report.  Would you be able to grab me logs of the
> > connection that doesn't work (the latest ppp) and the one that works
> > (the pre-July 30 one) with the following set:
> > 
> >   set log tun chat lcp ipcp
> > 
> > It may be possible to fix the problem by changing your ``set mru''
> > and ``set mtu'' lines to
> > 
> >   set mru max 1454
> >   set mtu max 1454
> > 
> > but, even if this is successful, I'd be interested in the logs.
> > 
> > It may also be worth trying the latest version of ppp from my web
> > site (http://www.Awfulak.org/~brian) - just in case it's something
> > that I've already fixed but have forgotten to MFC.  If that's the
> > case, then I should be able to find the bogus code more easily.
> > 
> 
> I am having great difficulty getting logs.  I noticed the last time I had ppp log 
>data was November 20th.  But this is what I have.
> 
> /etc/syslog.conf:
> !ppp
> *.* /var/log/ppp.log
> 
> /var/log/ppp.log:
> Dec  5 08:02:26 server ppp[198]: tun0: LCP: deflink: RecvEchoRequest(2) state = 
>Opened 
> Dec  5 08:02:26 server ppp[198]: tun0: LCP: deflink: SendEchoReply(2) state = Opened 

This looks ok.  Can you show me the logs from when the connection is 
established in each case ?

Cheers.

> jhousley@server:~ {13} pppctl -p xx 3000 show log
> Log:   Chat IPCP LCP Tun Warning Error Alert
> Local: Warning Error Alert
> 
> I am getting this with both RELENG_4_3 ppp and RELENG_4 ppp.  Yes syslogd is running 
>as "syslogd -s -s"  If I turn on tcp/ip or debug I get lots of information in the log
> files.  Is it possible that some of the log levels were broken.  I will try the 
>latest verson from (http://www.Awfulak.org/~brian) is see if that logs properly
> 
> Jim
> -- 
> /"\   ASCII Ribbon Campaign  .
> \ / - NO HTML/RTF in e-mail  .
>  X  - NO Word docs in e-mail .
> / \ -
> [EMAIL PROTECTED]  http://www.FreeBSD.org The Power to Serve
> [EMAIL PROTECTED]  http://www.TheHousleys.net
> [EMAIL PROTECTED]  http://www.SimTel.Net
> -
> Your mouse has moved.
> Windows NT must be restarted for the change to take effect!
> 
> Reboot now?  [OK]

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
  http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !  



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

37 Ways to Win That Sale!

2001-12-06 Thread PowerSelling

Title: PowerSelling: 37 Ways to Win That Sale!

PowerSelling
37 Ways to Win That Sale!
Australia Wide Tour -
Previous Tours Sold Out!
Come and See why PowerSelling is

Australia's Most Popular Sales Seminar
At last a feature packed 3 hour seminar
that lets you in on the Secrets of Winning the Sale.
At a location near you...

Power Up Your Sales Team with PowerSelling

Back By Popular Demand

The Truly Australian Way to Sell
Professional selling is an art. And Australians are truly a different buying people to Americans or the English.
PowerSelling is about closing sales in Australia in 2002 and beyond. What separates the pros from all the rest is the ability to
"Close the Sale." Without this ability to get the customer to buy, many salespeople fail, businesses don't reach their true potential and countless dollars are lost.
The PowerSelling Seminar, presented by Wayne Mansfield -
author of the best selling Australian Sales Script Book, shows you at least 37 proven ways to close the
sale. Hard times have gone on too long... make a decision to attend this seminar and start on the road to sales
success
PowerSelling: 37 Secrets of Winning the Sale!

If money was no object

Research by Harvard University shows that most salespeople give up too soon in the sales process. Most purchases are made after the prospect has said no 5 times... most salespeople give up after just 2 nos! Learn closing techniques that put you in the top 20% of salespeople in
Australia

The Price is Too High!

Most salespeople are afraid of telling the prospect the price. Learn why the price is so important and how you can use it to get an immediate agreement to purchase from your prospect.

Help enough people get what they
want..

Realising that people actually want to be helped to buy your product will turbo charge your selling. Learn tactics that have the prospect telling you what they want then all you have
to do is help them get it. Uncover the Secrets that Million Dollar producers in Insurance and Real Estate use to set sales records.

The Ben Franklin Close

Many people continue to look for a new answer to help in "Closing the Sale" when the old tried and tru

Re: cable modem connection problem

2001-12-06 Thread S. Aeschbacher


Hi
I experienced similar problems here in Switzerland. It happend with
FreeBSD as well
as with OpenBSD routers. A solution I found is deleting the arp table
entry of the
default router of the cable modem provider (as a cron job).
I did not investigate the source of the problem. Anyone got any clues?

Stefan

Mike D wrote:
> 
> I have a set up where my FreeBSD 4.4 box is acting as a firewall and gateway
> between a cable modem on xl1 and my home net on xl0.
> 
> I have a pretty tight rules list and don't have that many procs running
> (ipfw, natd, mysql, tomcat - that's it!)
> 
> It seems that after approx 10 hours the connection REALLY slows down, most
> connection attempts on other ports (e.g. 110) time out and I have to reboot
> the box. After the reboot everything is back to normal.
> 
> If you have *any* thoughts at all as to what this could be - please let me
> know, I'm getting pretty desperate.
> 
> many thanks in advance!
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

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

Re: what is PSEUDOFS?

2001-12-06 Thread Maxim Sobolev

Hiten Pandya wrote:
> 
> hi all...
> i would like to know if possible what is PSEUDOFS...
> cause i forgot to update my kernel configuration file,
> regarding the message in the UPDATING section...
> 
> i know what DEVFS is... after the lecture at the
> BSDCon
> 2001 Europe by phk

As far as I know, PSEUDOFS is a kernel infrastructure that simplifies
creation of fully-synthetic filesystems (a la procfs, or linprocfs).
It should decrease amount of code duplication among such filesystems.

-Maxim

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

Re: tar and nodump flag (fwd)

2001-12-06 Thread Joerg Schilling


>From [EMAIL PROTECTED] Thu Dec  6 00:41:54 2001

>Joerg Schilling writes:
>.
>> STAR Option  Description Gnu 
>tar equiv.  Remarks
>> ===  === 
>=   ===
>.
>> file=nm,f=nm use 'nm' as tape instead of stdin/stdout-f 
> close to identical
>May be close to identical in function, but not in convenience
>What about f=*.[ch] or f=something

Here is a more complete desciption of the features of the getargs()
function that is used to parse the command line arguments of all
schily programs:

/*--*/
As a hint for readers to the star manual page, star uses getargs() to parse
the command line. Getargs() is much more flexible than getopt() and is even
older than getopt(). The following features 

-   All single char boolean options and all single char increment type
options may be combined into a single string starting with a single
dash (-).

-   getargs() has a compatibility mode for GNU programs and allows to
preceede long options with a double dash (--) instead of the usual
single dash (-).

-   All options that take an argument are listed in the man page for
better readability of the manual as:

option=arg

but the following variants may appear in the actual command line:

option=arg
option= arg
-option=arg
-option= arg
-optionarg
-option arg

-   A separate double dash (--) may preceede any argument that looks like
an option and specifies that the immediately following argument is
a file type argument.

/*--*/

I am not shure whether I should ad this to all of my maual pages or whether I
should add a "SEE ALSO" note in the man page and include the getargs() man page
with all programs.

Jörg

 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED]   (uni)  If you don't have iso-8859-1
   [EMAIL PROTECTED]   (work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

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

Re: what is PSEUDOFS?

2001-12-06 Thread Sheldon Hearn




On Thu, 06 Dec 2001 03:09:59 PST, Hiten Pandya wrote:

> i would like to know if possible what is PSEUDOFS...
> cause i forgot to update my kernel configuration file,
> regarding the message in the UPDATING section...

man pseudofs

Ciao,
Sheldon.

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

what is PSEUDOFS?

2001-12-06 Thread Hiten Pandya


hi all...
i would like to know if possible what is PSEUDOFS...
cause i forgot to update my kernel configuration file,
regarding the message in the UPDATING section...

i know what DEVFS is... after the lecture at the
BSDCon
2001 Europe by phk



=
thanks...
regards...
Hiten Pandya

<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

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

Re: DRIVER_MODULE macro devclass_t argument used?

2001-12-06 Thread Warner Losh


In message <[EMAIL PROTECTED]> "Stephen Hulten" 
writes:
: My question is whether the static devclass_t structure is really ever
: used.

Yes, it is used.  It is where the devclass numbering comes from.

Warner

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

DRIVER_MODULE macro devclass_t argument used?

2001-12-06 Thread Stephen Hulten


I've been ramping up to write a device driver using the newbus
architecture and so have been reading example drivers and looking at the
kernel sources. All the example drivers define a static method table, a
static driver_t structure and a static devclass_t structure. These are
then all linked together via the DRIVER_MODULE macro which then adds an
entry to the "linker set" via the SYSINIT macro.

My question is whether the static devclass_t structure is really ever
used. At system startup it looks like the routine
driver_module_handler(module_t mod, int what, void * arg)
(kern/subr_bus.c) is called with what==MOD_LOAD and arg set to a ptr to
the static driver_module_data structure defined internally via
DRIVER_MODULE The driver_module_data structure contains the reference
to the static devclasss_t structure that was declared in the driver.
But the devclass_t ptr is overwritten by the statement

*dmd->dmd_devclass = devclass_find_internal(dmd->dmd_drivers[0]->name,TRUE)

This makes me believe the devclass_t structure defined in a driver is
never used. Is there another code path I'm missing?

Thanks
-Steve

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

Re: dhcpd problem

2001-12-06 Thread Josh Paetzel


On Thu, Dec 06, 2001 at 07:57:02AM +, Mike D wrote:
> I'm having trouble configuring my dhcpd.
> 
> This is the config file I've nocked up:
> 
>  start config file --
> default-lease-time 3600;
> max-lease-time 9;
> ddns-update-style ad-hoc;
> option subnet-mask 255.255.255.0;
> option broadcast-address 192.10.10.255;
> option domain-name-servers 194.168.8.100,194.168.4.100;
> option domain-name dolphintime;
>  end config file --
> 
> When I try to start dhcpd (by running "/usr/local/etc/rc.d/dhcpd") I get the 
> following error:
> 
>  start error message --
> No subnet declaration for xl1 (80.x.x.x).
> ** Ignoring requests on xl1.  If this is not what
>you want, please write a subnet declaration
>in your dhcpd.conf file for the network segment
>to which interface xl1 is attached. **
> 
> No subnet declaration for xl0 (192.10.10.4).
> ** Ignoring requests on xl0.  If this is not what
>you want, please write a subnet declaration
>in your dhcpd.conf file for the network segment
>to which interface xl0 is attached. **
> 
> Not configured to listen on any interfaces!
>  end error message --

DHCPD wants to know about your subnets.  The way to tell it about them 
is with a section like this:

subnet 192.10.10.0 netmask 255.255.255.0 {
  range 192.10.10.10 192.10.10.90;
}

There's more you can do than that, but I think seeing this will ring 
your bell, especially if you are looking in the man pages.

Josh

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

Re: 4G phisical memory kernel trap