Re: Patch to fix "make buildkernel requires full obj directory" mistake

[Dan Langille]

On 22 Jan 2001, at 1:11, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> Neil Blakey-Milner writes:
> : "make buildkernel" currently fails if a "make buildworld" has not
> 
> I've committed this change, as threatened late last week, since no one
> said not to.
> 
> buildworld is still required acorss major releases, when binutils
> change, and when config's version changes.  if buildkernel fails, then
> do not complain unless you've also done a buildworld first and it
> still fails.  This is a convenience for those people that know what
> they are doing.

Thanks for that Warner.  Please have a read of this URL for me and give 
me some suggestions as to how you think it should be updated:

http://www.freebsd.org/handbook/kernelconfig-building.html

...and I'll submit a PR.  cheers.

--
Dan Langille
pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php


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

RE: more info about: odd result of pci_read_config

[Steve Shoecraft]

Nic - 0x6 is the return value from the error_method routine.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Donald
> J . Maddox
> Sent: Saturday, January 20, 2001 6:28 PM
> To: Nicolas Souchu
> Cc: [EMAIL PROTECTED]
> Subject: Re: more info about: odd result of pci_read_config
>
>
> Heh, this is pretty wierd :)
>
> I was intrigued by your little problem, so I started looking around.
> In sys/dev/pci/pciar.h is:
>
> static __inline u_int32_t
> pci_read_config(device_t dev, int reg, int width)
> {
> return PCI_READ_CONFIG(device_get_parent(dev), dev, reg, width);
> }
>
> However, this is the only occurence of the string "PCI_READ_CONFIG"
> that I can find in the whole damn source tree!  Where is this defined?
>
>
> On Sun, Jan 21, 2001 at 12:43:49AM +0100, Nicolas Souchu wrote:
> > On Sat, Jan 20, 2001 at 04:18:35PM +0100, Nicolas Souchu wrote:
> > > Hi folks,
> > >
> > > I have a problem with R4.2. The device driver I'm currently
> > > writing can't retrieve correctly the value from a PCI
> configuration
> > > register. What is strange is that when using the pciconf
> tool I get
> > > the result I expect, not with pci_read_config().
> > >
> > > pciconf -r pci0:7:3: 0x48   returns 0x6001
> > >
> > > but
> > >
> > > value = pci_read_config(dev, 0x48, 4); returns 0x6 !!!
> > >
> >
> > Here is some more testing:
> >
> > Reading any configuration register gives 0x6!
> >
> > But
> >
> > when creating a cfg structure with bus=0, slot=7 and func=3 in the
> > attach routine then pass it to pci_cfgread(), it works. Also, when
> > querying the pci bus with BUS_READ_IVAR() for BUS, SLOT and FUNC,
> > I get 0,7,3.
> >
> > What is the hose field?
> >
> > Note also that I had to return NULL on the detection of the device
> > 0x30401106 in pcisupport.c pcib_match() because it has a
> bridge class and the
> > pcib driver was attached to it before viapm.
> >
> > Here is the piece of code:
> >
> > static int
> > viapm_attach(device_t dev)
> > {
> > u_int32_t l, base_cfgreg;
> > u_int16_t s;
> > u_int8_t c;
> > struct viapm_data *viapm;
> > struct resource *res;
> > device_t bitbang;
> > pcicfgregs cfg;
> >
> > if (!(viapm = (struct viapm_data *)device_get_softc(dev)))
> > return ENXIO;
> >
> > bzero(viapm, sizeof(struct viapm_data));
> >
> > l = pci_read_config(dev, 0x8, 1);
> > printf("%s: rev id 0x%x\n", __FUNCTION__, l);
> >
> > ## returns 0x6! Which is stupid
> >
> > switch (l) {
> > case VIAPM_OEM_REV_E:
> > base_cfgreg = VIAPM_CFG_3040E_BASE;
> >
> > /* Activate IO block access */
> > s = pci_read_config(dev, VIAPM_CFG_3040E_ACTIV, 2);
> > pci_write_config(dev, VIAPM_CFG_3040F_ACTIV,
> > s | VIAPM_ACTIV_E_MASK, 2);
> > break;
> > case VIAPM_OEM_REV_F:
> > case VIAPM_PROD_REV_A:
> > default:
> > base_cfgreg = VIAPM_CFG_3040F_BASE;
> >
> > /* Activate IO block access */
> > c = pci_read_config(dev, VIAPM_CFG_3040F_ACTIV, 1);
> > pci_write_config(dev, VIAPM_CFG_3040F_ACTIV,
> > c | VIAPM_ACTIV_F_MASK, 1);
> > break;
> > }
> >
> > cfg.hose = -1;
> > cfg.bus = 0;
> > cfg.slot = 7;
> > cfg.func = 3;
> > l = pci_cfgread(&cfg, VIAPM_CFG_3040F_BASE, 4);
> > printf("%s: base addr 0x%x\n", __FUNCTION__, l);
> >
> > ## return 0x6001!   the correct value
> >
> > BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_BUS, &l);
> > printf("bus=%d\n", l);
> > BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_SLOT, &l);
> > printf("slot=%d\n", l);
> > BUS_READ_IVAR(device_get_parent(dev), dev,
> PCI_IVAR_FUNCTION, &l);
> > printf("func=%d\n", l);
> >
> > ## return 0,7,3
> >
> > if (!(res = bus_alloc_resource(dev, SYS_RES_IOPORT,
> &base_cfgreg,
> > 0l, ~0l, 1, RF_ACTIVE))) {
> > device_printf(dev, "could not allocate bus space\n");
> > return ENXIO;
> > }
> > viapm->st = rman_get_bustag(res);
> > viapm->sh = rman_get_bushandle(res);
> >
> > printf("viapm: 0x%x and 0x%x\n", viapm->st, viapm->sh);
> >
> > VIAPM_OUTB(GPIO_DIR, VIAPM_INB(GPIO_DIR) | VIAPM_SCL |
> VIAPM_SDA);
> >
> > device_printf(dev, "attaching bitbanging...\n");
> >
> > /* add generic bit-banging code */
> > if (!(bitbang = device_add_child(dev, "iicbb", -1)))
> > return ENXIO;
> >
> > return (device_probe_and_attach(bitbang));
> > }
> >
> > --
> > [EMAIL PROTECTED]
> > Alcôve - Open Source Software Engineer - http://www.alcove.fr
> >
> >
> > 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
>



To Unsubs

RE: more info about: odd result of pci_read_config

[Steve Shoecraft]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Nicolas Souchu
> Sent: Sunday, January 21, 2001 4:19 AM
> To: John Baldwin
> Cc: Donald J . Maddox; [EMAIL PROTECTED]
> Subject: Re: more info about: odd result of pci_read_config
>
>
> On Sat, Jan 20, 2001 at 04:35:11PM -0800, John Baldwin wrote:
> > Look in /sys/compile/ after compiling a kernel, it
> should be in pci_if.*
> > It's a function that ues kobj to lookup the pci_read_config
> method in the
> > parent bus.  Look in the PCI code to find the real
> pci_read_config...
> >
> > >From sys/dev/pci/pci.c:
> >
> > DEVMETHOD(pci_read_config,  pci_read_config_method),
> >
> > static u_int32_t
> > pci_read_config_method(device_t dev, device_t child, int
> reg, int width)
> > {
> > struct pci_devinfo *dinfo = device_get_ivars(child);
> > pcicfgregs *cfg = &dinfo->cfg;
> >
> > return PCIB_READ_CONFIG(device_get_parent(dev),
> > cfg->bus, cfg->slot, cfg->func,
> > reg, width);
> > }
>
> On -stable, it calls directly pci_cfgread() with the cfg.
>
> My viapm driver is a kmodule. Could it be that PCI_READ_CONFIG is not
> correctly resolved and returns ENXIO which is 0x6?

That's exactly whats going on here.  Have you turned on BUS_DEBUG (or mebbe
DEBUG_BUS) in /kern/subr_bus.c ?

Also, I have a userland app that loads and runs your kernel module - it
makes it alot easier to debug this kinda stuff.  Even does device file I/O.
If you want, you can check it out.

>
> I'll try to wire it in the kernel.
>
> Nicholas
>
> --
> [EMAIL PROTECTED]
> Alcôve - Open Source Software Engineer - http://www.alcove.fr
>
>
> 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

PPPoE

[Daniel C. Sobral]

It seems I need the following parameters to get my PPPoE to work. Could
we have these options, please?

>> -f disc:sess
>>The  -f  option  sets  the Ethernet frame types for
>>PPPoE discovery and session frames.  The types  are
>>specified  as  hexadecimal  numbers  separated by a
>>colon.  Standard PPPoE uses frame types  8863:8864.
>>You should not use this option unless you are abso¡
>>lutely sure the peer you are dealing with uses non-
>>standard  frame  types.  If your ISP uses non-stan¡
>>dard frame types, complain!
>>
>>  -S service_name
>> Specifies the desired  service  name.   pppoe  will
>> only  initiate  sessions  with access concentrators
>> which can provide the specified service.   In  most
>> cases,  you should not specify this option.  Use it
>> only if you know that  there  are  multiple  access
>> concentrators or know that you need a specific ser¡
>> vice name.

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"There is no spoon." -- Kiki


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

PAM (was: Re: MAIL set by whom?)

[Dominic Mitchell]

On Sun, Jan 21, 2001 at 04:45:50PM +0100, Roelof Osinga wrote:
> Grand gesture. Laudable even. Yeah, that PAM sure seems to've
> become popular. The Courier IMAP port also insisted upon its
> installation. Insisted in that fiddling with the makefile only
> resulted in failure to configure. But that's a whole different
> story.

Would it be a good idea to start using /etc/pam.d ala RedHat, instead of
the monolithic /etc/pam.conf?

As far as I can see the support is already there, it's just not being
used due to the presence of the /etc/pam.conf.

This would make installing PAM entries far easier for the ports.

-Dom


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

Re: PAM (was: Re: MAIL set by whom?)

[Stijn Hoop]

On Mon, Jan 22, 2001 at 09:46:47AM +, Dominic Mitchell wrote:
> Would it be a good idea to start using /etc/pam.d ala RedHat, instead of
> the monolithic /etc/pam.conf?
> 
> As far as I can see the support is already there, it's just not being
> used due to the presence of the /etc/pam.conf.
> 
> This would make installing PAM entries far easier for the ports.

Seconded. I don't see any reason *not* to do it this way.

OTOH, ports are not supposed to install in /etc, so the best way would
be to extend pam to support /usr/local/etc/pam.d *and* /etc/pam.d
(if it doesn't already do this).

No, I'm not sending patches, sorry :)

--Stijn

-- 
Nostalgia ain't what it used to be.


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

RE: PAM (was: Re: MAIL set by whom?)

[Niekie Myburgh (QData)]

Title: RE: PAM (was: Re: MAIL set by whom?)





I posted a question about PAM & Passwd on 4.2.  It seems that passwd "ignores" any passwd lines in pam.conf.  I tried the pam.d thing (Run Linux compatibility, copy rc.d/* from Redhat 6.1 to BSD.  When you try to log in, the login terminates, and syslog shows:

/kernel: pid 22202 (login), uid 0: exited on siglan 10 (core dumped)


Rename pam.d, and all is happy (which means I'm back to pam.conf).


I have 300Mb swap (all unused) and 26Mb RAM inactive.  I don't think that memory / out of swap space is the problem in this case. (I gather from what I could see on the net, that the main culprit for signal 10 seems to be swap space / memory)

Can anyone give me an example line for the passwd entry in pam.conf (seems to be happier, although it seems to ignore my changes)

I'm using the following:


passwd      password    required        pam_xxx options_options..


I tried pam_cracklib.so with it's options, as well as pam_passwdqc and it's options.  I am being ignored.


Regards.


Niekie






-Original Message-
From:   Stijn Hoop [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, January 22, 2001 12:07 PM
To: Dominic Mitchell
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:    Re: PAM (was: Re: MAIL set by whom?)


On Mon, Jan 22, 2001 at 09:46:47AM +, Dominic Mitchell wrote:
> Would it be a good idea to start using /etc/pam.d ala RedHat, instead of
> the monolithic /etc/pam.conf?
> 
> As far as I can see the support is already there, it's just not being
> used due to the presence of the /etc/pam.conf.
> 
> This would make installing PAM entries far easier for the ports.


Seconded. I don't see any reason *not* to do it this way.


OTOH, ports are not supposed to install in /etc, so the best way would
be to extend pam to support /usr/local/etc/pam.d *and* /etc/pam.d
(if it doesn't already do this).


No, I'm not sending patches, sorry :)


--Stijn


-- 
Nostalgia ain't what it used to be.



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

Re: PPPoE

[Felix-Antoine Paradis]

To get pppoe to work, just set the options in the kernel and use a good
config (ppp.conf) and use pppd.

On Mon, 22 Jan 2001, Daniel C. Sobral wrote:

> It seems I need the following parameters to get my PPPoE to work. Could
> we have these options, please?
>
> >> -f disc:sess
> >>The  -f  option  sets  the Ethernet frame types for
> >>PPPoE discovery and session frames.  The types  are
> >>specified  as  hexadecimal  numbers  separated by a
> >>colon.  Standard PPPoE uses frame types  8863:8864.
> >>You should not use this option unless you are abso¡
> >>lutely sure the peer you are dealing with uses non-
> >>standard  frame  types.  If your ISP uses non-stan¡
> >>dard frame types, complain!
> >>
> >>  -S service_name
> >> Specifies the desired  service  name.   pppoe  will
> >> only  initiate  sessions  with access concentrators
> >> which can provide the specified service.   In  most
> >> cases,  you should not specify this option.  Use it
> >> only if you know that  there  are  multiple  access
> >> concentrators or know that you need a specific ser¡
> >> vice name.
>
> --
> Daniel C. Sobral  (8-DCS)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>   "There is no spoon." -- Kiki
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>

. . . . . . . . . . . . . . . . . . . . . . . . . . . .  .
.   Felix-Antoine Paradis.  cell:1-418-261-0865  .
.  IRC:   reel @ DALnet  .  job:Idemnia Network  .
.  Email: [EMAIL PROTECTED]  .  *** www.FreeBSD.org ***  .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .  .



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

Sablotron - 0.5

[Vladimir Terziev]

   Hi Hackers,

   I've tryed to install Sablotron XSLT Processor version 0.5 (the latest one),
but the configure script said to me that there is no "wchar.h" file on my 
machine.

   I checked this and it is true. Can somebody tell me, what is the reason for 
this?

   regards,

Vladimir




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

Re: PPPoE

[Daniel C. Sobral]

Felix-Antoine Paradis wrote:
> 
> To get pppoe to work, just set the options in the kernel and use a good
> config (ppp.conf) and use pppd.

Kernel options are bad for a number of reasons, not the least of them
the inability to do network installs (I mean, you have ADSL and get
restricted to cd installs?). Anyway... what _are_ the kernel options?

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"There is no spoon." -- Kiki


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

Re: PPPoE

[James Housley]

Drew Sanford wrote:
> 
> It's been a while since I set up PPPoE on my box here, but if memory
> serves, the handbook covers it very well - I believe it calls for the
> addition of:
> 
> options netgraph
> options netgraph_pppoe
> options netgraph_socket
> 
Yes and all of these can be loaded at runtime as KLDs

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
-
If it happens once, it's a bug.
If it happens twice, it's a feature.
If it happens more than twice, it's windows.
-- Luiz de Barros


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

Re: PPPoE

[Daniel C. Sobral]

Drew Sanford wrote:
> 
> It's been a while since I set up PPPoE on my box here, but if memory
> serves, the handbook covers it very well - I believe it calls for the
> addition of:
> 
> options netgraph
> options netgraph_pppoe
> options netgraph_socket
> 
> But you might actually check the handbook for that.

The default frame type won't work.

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"There is no spoon." -- Kiki


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

Re: PPPoE

[Drew Sanford]

It's been a while since I set up PPPoE on my box here, but if memory 
serves, the handbook covers it very well - I believe it calls for the 
addition of:

options netgraph
options netgraph_pppoe
options netgraph_socket

But you might actually check the handbook for that.

Daniel C. Sobral wrote:

> Felix-Antoine Paradis wrote:
> 
>> To get pppoe to work, just set the options in the kernel and use a good
>> config (ppp.conf) and use pppd.
> 
> 
> Kernel options are bad for a number of reasons, not the least of them
> the inability to do network installs (I mean, you have ADSL and get
> restricted to cd installs?). Anyway... what _are_ the kernel options?


-- 
Drew Sanford
Systems Administrator
[EMAIL PROTECTED]



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

Re: more info about: odd result of pci_read_config

[Nicolas Souchu]

On Mon, Jan 22, 2001 at 04:05:31AM -0600, Steve Shoecraft wrote:
> > My viapm driver is a kmodule. Could it be that PCI_READ_CONFIG is not
> > correctly resolved and returns ENXIO which is 0x6?
> 
> That's exactly whats going on here.  Have you turned on BUS_DEBUG (or mebbe
> DEBUG_BUS) in /kern/subr_bus.c ?

Not yet. I will then.

> 
> Also, I have a userland app that loads and runs your kernel module - it
> makes it alot easier to debug this kinda stuff.  Even does device file I/O.
> If you want, you can check it out.

Thanks, where?

-- 
[EMAIL PROTECTED]
Alcôve - Open Source Software Engineer - http://www.alcove.fr


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

Re: PPPoE

[Julian Elischer]

Felix-Antoine Paradis wrote:
> 
> To get pppoe to work, just set the options in the kernel and use a good
> config (ppp.conf) and use pppd.
> 
> On Mon, 22 Jan 2001, Daniel C. Sobral wrote:
> 
> > It seems I need the following parameters to get my PPPoE to work. Could
> > we have these options, please?
> >
> > >> -f disc:sess
> > >>The  -f  option  sets  the Ethernet frame types for
> > >>PPPoE discovery and session frames.  The types  are
> > >>specified  as  hexadecimal  numbers  separated by a
> > >>colon.  Standard PPPoE uses frame types  8863:8864.
> > >>You should not use this option unless you are abso¡
> > >>lutely sure the peer you are dealing with uses non-
> > >>standard  frame  types.  If your ISP uses non-stan¡
> > >>dard frame types, complain!

Definitly complain! This is equivalent to calling a protocol tcp/ip
but using a first byte in the packet.
I will look at a configuration message for the netgraph node
but Brian will hav eto work out how to send it, and where the
configuration parameter should be set to do this..

The other possibility is a sysctl.


> > >>  -S service_name
> > >> Specifies the desired  service  name.   pppoe  will
> > >> only  initiate  sessions  with access concentrators
> > >> which can provide the specified service.   In  most
> > >> cases,  you should not specify this option.  Use it
> > >> only if you know that  there  are  multiple  access
> > >> concentrators or know that you need a specific ser¡
> > >> vice name.


If you are talking about the netgraph based pppoe, then -xxx type 
flags are not how you configure it.  I think you are talking about
the (rather inefficient) userland ppp daemon.

the service name requested is already an argument in the pppoe 
configuration.

"If a PPPoE:iface[:provider] specification is given, ppp will at-
tempt to create a PPP over Ethernet connection using the given
iface interface by using netgraph(4). "

In this case the "provider" is the service name.


-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
---> X_.---._/  from Perth, presently in:  Budapest
v



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

contigmalloc, M_WAITOK, & leaks.

[Robert Lipe]

Hi, Gang.

I know that anytime a message starts with a subject like this, the
first reaction is to think that I've hosed the heap or am not freeing
something.  While it's possible, I really don't think I have.  (I also
know that everyone thinks that. :-)

I'm on FreeBSD 4.1.1.  I've not seen any flagrantly smoking guns since
then in vm_page.c, although version 1.154 might be...

I'm calling contigmalloc() with M_WAITOK.  For every contigmalloc, I
have a corresponding contigfree().  But after a few thousand cycles,
contigmalloc() starts returning NULL.  It self-destructs in about 3
minutes.  I see the same behaviour with M_NOWAIT.  As an aside, WAITOK's
should never return NULL, right?  They should be put to sleep and
awakened when the resource is available.

So I'm suspecting there are two problems (they may be problems in my
understanding and not the code): One is that we leak something that
makes it fail.  The other is that M_WAITOK isn't honoured when it does
fail.

Fortunately, the allocations in question for my test have really simple
constraints.  I know that it's *really* calling contigmalloc with single
byte alignment that can be located anywhere in 32-bit address space
and I'm on a 32-bit host.  If I replace contigmalloc/contigfree with
malloc/free it runs fine for hours.  Since all I did was replace the
single call site of each, I really don't think I'm leaking it.  While
this is a cute special case (and presumably a potential optimization),
it's also not typical of real hardware in real systems that have to have
real constraints passed to contigmalloc.

Looking at the callers of contigmalloc/contigfree in the tree, I don't
see a lot of highly dynamic uses of them.  For the most part, drivers
are making a low number of calls at attachment time and a low number of
releases at detachment time.   Thus, it's possible that a problem here
could have gone unnoticed.

Any ideas?  Is there something magic to contig management?  Do I have to
hold an elevated PL during calls to these to prevent corruption?

Thanx,
RJL


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

Re: contigmalloc, M_WAITOK, & leaks.

[Alfred Perlstein]

* Robert Lipe <[EMAIL PROTECTED]> [010122 09:04] wrote:
> Hi, Gang.
> 
> I know that anytime a message starts with a subject like this, the
> first reaction is to think that I've hosed the heap or am not freeing
> something.  While it's possible, I really don't think I have.  (I also
> know that everyone thinks that. :-)
> 
> I'm on FreeBSD 4.1.1.  I've not seen any flagrantly smoking guns since
> then in vm_page.c, although version 1.154 might be...
> 
> I'm calling contigmalloc() with M_WAITOK.  For every contigmalloc, I
> have a corresponding contigfree().  But after a few thousand cycles,
> contigmalloc() starts returning NULL.  It self-destructs in about 3
> minutes.  I see the same behaviour with M_NOWAIT.  As an aside, WAITOK's
> should never return NULL, right?  They should be put to sleep and
> awakened when the resource is available.

Making heavy use of contigmalloc is a bad idea, if you really need
this contig allocations then allocate a fair number of them early
and keep using them.  Memory get's fragmented, there's not much
you can do about it.  I doubt that contigmalloc respects the WAITOK
flag, there's a good chance that kernel memory has become so
fragmented that your chances of successfully completing the
contigmalloc are near zero, it's much better to return a temporary
resource failure than block a kernel thread forever.

This issue has come up before, and most everyone was able to either
use a workaround (calling VTOPHYS? on each page) or pre-allocating
the contig space and reuseing it instead of allocating and freeing
it over and over.

best of luck,
-Alfred


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

Re: contigmalloc, M_WAITOK, & leaks.

[Robert Lipe]

Alfred Perlstein wrote:
> * Robert Lipe <[EMAIL PROTECTED]> [010122 09:04] wrote:

> > I'm calling contigmalloc() with M_WAITOK.  For every contigmalloc, I
> > have a corresponding contigfree().  But after a few thousand cycles,
> > contigmalloc() starts returning NULL.  It self-destructs in about 3
> 
> Making heavy use of contigmalloc is a bad idea, if you really need
> this contig allocations then allocate a fair number of them early
> and keep using them.  

I understand that and in a production system, these would indeed be
cached.

> Memory get's fragmented, there's not much you can do about it.  I
> doubt that contigmalloc respects the WAITOK flag, there's a good
> chance that kernel memory has become so fragmented that your chances
> of successfully completing the contigmalloc are near zero,

If I were allocating something truly hard to get (like multiple
contiguous pages with page alignment) I'd take that answer and move on.
I've even given that answer before. :-) But this example requested *no*
specified alignment and at any physaddr.  So if there's memory in the
system (and there must be or malloc couldn't find it) it should be able
to find it, right?

> it's much better to return a temporary resource failure than block a
> kernel thread forever.

In this case, the resource failure isn't temporary.  Once it starts
failing, it fails until the system is rebooted.  Since this is on a
dedicated thread, I could handle it if it really was temporary.  Of
course, putting me to sleep so that someone else (or even another of my
own threads) could run around and free the resources would be ideal.  As
it stands, once I get the failure notice, I'm hosed.

> This issue has come up before, and most everyone was able to either
> use a workaround (calling VTOPHYS? on each page) 

Tell me more about this.  You can't just replace contigmalloc with a
malloc and a vtophys becuase you can't express hardware constraints
that way.  You can express a common subset of them.  So there must be
something else you're hinting at.

> or pre-allocating the contig space and reuseing it instead of
> allocating and freeing it over and over.

Yes, I'll have a scheme like that that I'll need to implement for
performance but I was hoping to defer that.

> best of luck,

Thanx much,
RJL


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

Re: contigmalloc, M_WAITOK, & leaks.

[Alfred Perlstein]

* Robert Lipe <[EMAIL PROTECTED]> [010122 10:39] wrote:
> Alfred Perlstein wrote:
> > * Robert Lipe <[EMAIL PROTECTED]> [010122 09:04] wrote:
> 
> > Memory get's fragmented, there's not much you can do about it.  I
> > doubt that contigmalloc respects the WAITOK flag, there's a good
> > chance that kernel memory has become so fragmented that your chances
> > of successfully completing the contigmalloc are near zero,
> 
> If I were allocating something truly hard to get (like multiple
> contiguous pages with page alignment) I'd take that answer and move on.
> I've even given that answer before. :-) But this example requested *no*
> specified alignment and at any physaddr.  So if there's memory in the
> system (and there must be or malloc couldn't find it) it should be able
> to find it, right?

Yes, but it seems like there isn't any. :)

> > it's much better to return a temporary resource failure than block a
> > kernel thread forever.
> 
> In this case, the resource failure isn't temporary.  Once it starts
> failing, it fails until the system is rebooted.  Since this is on a
> dedicated thread, I could handle it if it really was temporary.  Of
> course, putting me to sleep so that someone else (or even another of my
> own threads) could run around and free the resources would be ideal.  As
> it stands, once I get the failure notice, I'm hosed.

Yup, it's sort of the fault of the memory allocator, afaik except
for allocations that are > (PAGE_SIZE/2), you can't free back to
the kernel map, meaning that if you allocate several thousand <
(PAGE_SIZE/2) chunks you've pretty much broken contigmalloc.

> > This issue has come up before, and most everyone was able to either
> > use a workaround (calling VTOPHYS? on each page) 
> 
> Tell me more about this.  You can't just replace contigmalloc with a
> malloc and a vtophys becuase you can't express hardware constraints
> that way.  You can express a common subset of them.  So there must be
> something else you're hinting at.

Not hinting much, the only reason I can guess that you need contigmalloc
is because you're allocating > PAGE_SIZE chunks and you don't want to
tell your hardware to do scatter/gather IO and would rather point it
at some physically contig memory and be done with it.

This is possible (using contigmalloc) if you cache the contigmalloc'd
chunks, but not if you keep discarding them and allow the kernel memory
map to become more fragmented.

> > or pre-allocating the contig space and reuseing it instead of
> > allocating and freeing it over and over.
> 
> Yes, I'll have a scheme like that that I'll need to implement for
> performance but I was hoping to defer that.

Best to do it now.

My question is, why exactly do you need contigmalloc, is this some
device you're trying to write a driver for?  Can you explain it some?
That would help me suggest a workaround.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: contigmalloc, M_WAITOK, & leaks.

[Robert Lipe]

> > In this case, the resource failure isn't temporary.  Once it starts
> > failing, it fails until the system is rebooted.  Since this is on a
> > dedicated thread, I could handle it if it really was temporary.  Of
> > course, putting me to sleep so that someone else (or even another of my
> > own threads) could run around and free the resources would be ideal.  As
> > it stands, once I get the failure notice, I'm hosed.
> 
> Yup, it's sort of the fault of the memory allocator, afaik except
> for allocations that are > (PAGE_SIZE/2), you can't free back to
> the kernel map, meaning that if you allocate several thousand <
> (PAGE_SIZE/2) chunks you've pretty much broken contigmalloc.

Aaaah.  There's a hint.  Yes, by the time we get into trouble, I've
allocated (and freed) several thousand chunks that are < PAGE_SIZE/2.
This is happening in periods of a few dozen.  (I don't know the number,
but I think it's 48 or 64.) The test program allocates a few dozen tx
buffers, fills them up, then the tx completion handler releases them.
There are never very many of these outstanding at any time.  All the
allocs (in this specific case) are always the same size, and there are
no intervening calls to contigmalloc.  This should stack the deck pretty
well for fragmentation.

So if I sandbagged the allocs to be *larger* the KMA would behave more
consistently with what I'd expect becuase it would then reclaim?  I
didn't see that one coming. :-)

Would rounding them up to PAGE_SIZE/2 suffice, or did you really mean ">
PAGE_SIZE/2"?


> Not hinting much, the only reason I can guess that you need contigmalloc
> is because you're allocating > PAGE_SIZE chunks and you don't want to
> tell your hardware to do scatter/gather IO and would rather point it
> at some physically contig memory and be done with it.

Is there an s/g memory interface in FreeBSD?  This was my first choice,
but since I couldn't find a set of functions to build a list of buffers
that satisfied a set of constraints, I fell back to contigmalloc to get
things off the ground.  I'd be delighted to use an interface to get me
an s/g list with a given set of constraints that pointed to a list of
buffers with a given set of constraints.

> This is possible (using contigmalloc) if you cache the contigmalloc'd
> chunks, but not if you keep discarding them and allow the kernel memory
> map to become more fragmented.

Implementing a cache for these is a few lines of code and will improve
the robustness of what I have.  I'm clearly going to have to do this.

> My question is, why exactly do you need contigmalloc, is this some
> device you're trying to write a driver for?  Can you explain it some?
> That would help me suggest a workaround.

Sure.  I'm trying to write a driver for arbitrary devices. :-) This is
kinky, I know.

UDI (www.projectudi.org) allows a driver writer to specify a very rich
set of constraints on DMA objects.  I'm implementing the piece of the
UDI environment that provides this to the drivers.  So while I know
that the test program and driver I'm using right now don't *really*
need contigmalloc, we'll eventually need the ability to ensure that DMA
buffers for 32-bit PCI cards are in the bottom 32 bits, (or perhaps
even not the bottom if you have intervening bus bridges) that stupid
hardware providing 24 bits of addressing but bolted to a PCI controller
gets allocated in the bottom 16Mb, etc.  

If I was trying to support a very specific piece of hardware, I could
divine workarounds, but it's something I'm probably going to have to
determine programmatically.

Thanx again,
RJL


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

Re: contigmalloc, M_WAITOK, & leaks.

[Mike Smith]

> I'm calling contigmalloc() with M_WAITOK.  For every contigmalloc, I
> have a corresponding contigfree().  But after a few thousand cycles,
> contigmalloc() starts returning NULL.  It self-destructs in about 3
> minutes.  I see the same behaviour with M_NOWAIT.  As an aside, WAITOK's
> should never return NULL, right?  They should be put to sleep and
> awakened when the resource is available.

No, contigmalloc will return NULL if physical memory space is fragmented 
to the point where it can't honour your request.

You should avoid calling contigmalloc at any time other than when setting 
up your driver; there is no support in the kernel for defragmenting 
physical address space, so over time you'll run into the problem you're 
seeing.

Allocate your space up front, and then leave it alone.  Also, you should 
probably be using bus_dmamem_alloc() since the only real use for 
contiguous memory is for DMA purposes, and you'll be better served by 
allocating DMA'able buffers matching your device's characteristics than 
by assuming that you can DMA to/from all physical memory.


-- 
... 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: PPPoE

[Ras-Sol]

Hmmm, I seem to remember something about another way to do PPPoE...

But I've been using ppp's built-in PPPoE support for about a year now.
(With Netgraph etc)
Simple to set up, works flawlessly.

Uses 21% CPU on a 486 DX2-50.

--

"Jupiter accepts your offer..."

 AIM: IMFDUP
- Original Message -
From: Daniel C. Sobral <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 22, 2001 3:01 AM
Subject: PPPoE


It seems I need the following parameters to get my PPPoE to work. Could
we have these options, please?

>> -f disc:sess
>>The  -f  option  sets  the Ethernet frame types for
>>PPPoE discovery and session frames.  The types  are
>>specified  as  hexadecimal  numbers  separated by a
>>colon.  Standard PPPoE uses frame types  8863:8864.
>>You should not use this option unless you are abso¡
>>lutely sure the peer you are dealing with uses non-
>>standard  frame  types.  If your ISP uses non-stan¡
>>dard frame types, complain!
>>
>>  -S service_name
>> Specifies the desired  service  name.   pppoe  will
>> only  initiate  sessions  with access concentrators
>> which can provide the specified service.   In  most
>> cases,  you should not specify this option.  Use it
>> only if you know that  there  are  multiple  access
>> concentrators or know that you need a specific ser¡
>> vice name.

--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"There is no spoon." -- Kiki


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: contigmalloc, M_WAITOK, & leaks.

[Alfred Perlstein]

* Robert Lipe <[EMAIL PROTECTED]> [010122 11:21] wrote:
> > > In this case, the resource failure isn't temporary.  Once it starts
> > > failing, it fails until the system is rebooted.  Since this is on a
> > > dedicated thread, I could handle it if it really was temporary.  Of
> > > course, putting me to sleep so that someone else (or even another of my
> > > own threads) could run around and free the resources would be ideal.  As
> > > it stands, once I get the failure notice, I'm hosed.
> > 
> > Yup, it's sort of the fault of the memory allocator, afaik except
> > for allocations that are > (PAGE_SIZE/2), you can't free back to
> > the kernel map, meaning that if you allocate several thousand <
> > (PAGE_SIZE/2) chunks you've pretty much broken contigmalloc.
> 
> Aaaah.  There's a hint.  Yes, by the time we get into trouble, I've
> allocated (and freed) several thousand chunks that are < PAGE_SIZE/2.
> This is happening in periods of a few dozen.  (I don't know the number,
> but I think it's 48 or 64.) The test program allocates a few dozen tx
> buffers, fills them up, then the tx completion handler releases them.
> There are never very many of these outstanding at any time.  All the
> allocs (in this specific case) are always the same size, and there are
> no intervening calls to contigmalloc.  This should stack the deck pretty
> well for fragmentation.
> 
> So if I sandbagged the allocs to be *larger* the KMA would behave more
> consistently with what I'd expect becuase it would then reclaim?  I
> didn't see that one coming. :-)
> 
> Would rounding them up to PAGE_SIZE/2 suffice, or did you really mean ">
> PAGE_SIZE/2"?

On i386, PAGE_SIZE is 4096, so the allocations need to be 2048+1
:).  so it's > PAGE_SIZE/2.

but... this is a terrible workaround, I'm not sure it would work
and you shouldn't do it. :)

> > Not hinting much, the only reason I can guess that you need contigmalloc
> > is because you're allocating > PAGE_SIZE chunks and you don't want to
> > tell your hardware to do scatter/gather IO and would rather point it
> > at some physically contig memory and be done with it.
> 
> Is there an s/g memory interface in FreeBSD?  This was my first choice,
> but since I couldn't find a set of functions to build a list of buffers
> that satisfied a set of constraints, I fell back to contigmalloc to get
> things off the ground.  I'd be delighted to use an interface to get me
> an s/g list with a given set of constraints that pointed to a list of
> buffers with a given set of constraints.

See the busdma stuff, there's a problem because there's no busdma
for mbufs (well actually there is but it fails on really small
unaligned blocks which basically breaks it for mbufs).  NetBSD has
some stuff for setting up s/g on mbufs (more busdma) but it looks
pretty inefficient and I havne't had a chance to look at emulating
or providing a different interface for it.

> > This is possible (using contigmalloc) if you cache the contigmalloc'd
> > chunks, but not if you keep discarding them and allow the kernel memory
> > map to become more fragmented.
> 
> Implementing a cache for these is a few lines of code and will improve
> the robustness of what I have.  I'm clearly going to have to do this.

There's no way around it if you want to use contigmalloc.  However
if you were to use busdma you could do it with normal malloc'd
blocks.

> > My question is, why exactly do you need contigmalloc, is this some
> > device you're trying to write a driver for?  Can you explain it some?
> > That would help me suggest a workaround.
> 
> Sure.  I'm trying to write a driver for arbitrary devices. :-) This is
> kinky, I know.
> 
> UDI (www.projectudi.org) allows a driver writer to specify a very rich
> set of constraints on DMA objects.  I'm implementing the piece of the
> UDI environment that provides this to the drivers.  So while I know
> that the test program and driver I'm using right now don't *really*
> need contigmalloc, we'll eventually need the ability to ensure that DMA
> buffers for 32-bit PCI cards are in the bottom 32 bits, (or perhaps
> even not the bottom if you have intervening bus bridges) that stupid
> hardware providing 24 bits of addressing but bolted to a PCI controller
> gets allocated in the bottom 16Mb, etc.  
> 
> If I was trying to support a very specific piece of hardware, I could
> divine workarounds, but it's something I'm probably going to have to
> determine programmatically.

ack, I'd review patches if you wanted to write/port busdma for mbufs..

see:
http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/arch/i386/i386/bus_machdep.c

for a starting point.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: contigmalloc, M_WAITOK, & leaks.

[Mike Smith]

> Aaaah.  There's a hint.  Yes, by the time we get into trouble, I've
> allocated (and freed) several thousand chunks that are < PAGE_SIZE/2.
> This is happening in periods of a few dozen.  (I don't know the number,
> but I think it's 48 or 64.) The test program allocates a few dozen tx
> buffers, fills them up, then the tx completion handler releases them.
> There are never very many of these outstanding at any time.  All the
> allocs (in this specific case) are always the same size, and there are
> no intervening calls to contigmalloc.  This should stack the deck pretty
> well for fragmentation.

Several things to note.

 - Calling contigmalloc is wrong.  Use bus_dmamem_alloc()
 - Calling an allocator is generally wrong; keep a freelist and just 
   recycle your buffers.  If you're not sure about how many you need, 
   then by all means error out in the "freelist empty" case and allocate 
   a few more (up to some sane limit).

> So if I sandbagged the allocs to be *larger* the KMA would behave more
> consistently with what I'd expect becuase it would then reclaim?  I
> didn't see that one coming. :-)

No, this isn't going to help much.  It's possible that contigfree is 
actually doing the wrong thing, but regardless, what you're doing is a 
recipie for frustration.  If your allocations are always guaranteed to be 
much smaller than PAGE_SIZE, making an individual allocation per object 
is also wasteful (since contigmalloc will have to give you a whole 
page...).  You should definitely be using bus_dmamem_alloc, and allocate 
a cluster of objects.   eg. if your object is (say) 20 bytes in size, you 
should round up to 32, then allocate (PAGE_SIZE / 32) objects and push 
them all onto your freelist.  (This requires tracking the base addresses 
of your clusters, but it's much more efficient.)

> Is there an s/g memory interface in FreeBSD?  This was my first choice,
> but since I couldn't find a set of functions to build a list of buffers
> that satisfied a set of constraints, I fell back to contigmalloc to get
> things off the ground.  I'd be delighted to use an interface to get me
> an s/g list with a given set of constraints that pointed to a list of
> buffers with a given set of constraints.

Yes; this is where the busdma stuff comes in.  Use bus_dma_tag_create to 
create a DMA tag which defines the costraints applicable to your DMA-able 
memory.  Then you can either use bus_dmamem_alloc/bus_dmamem_free to 
allocate conforming memory, or just take memory in the kernel's address 
space.  In either case, you use bus_dmamap_load to build the scatter/
gather list (and possibly perform other setup work), bus_dmamap_unload
to tear down any of the setup work, and bus_dmamem_sync to perform 
possibly-required bounce buffering, bus scatter/gather control, etc.

> UDI (www.projectudi.org) allows a driver writer to specify a very rich
> set of constraints on DMA objects.  I'm implementing the piece of the
> UDI environment that provides this to the drivers.  So while I know
> that the test program and driver I'm using right now don't *really*
> need contigmalloc, we'll eventually need the ability to ensure that DMA
> buffers for 32-bit PCI cards are in the bottom 32 bits, (or perhaps
> even not the bottom if you have intervening bus bridges) that stupid
> hardware providing 24 bits of addressing but bolted to a PCI controller
> gets allocated in the bottom 16Mb, etc.  

All this is already provided for with the above.

I hope this helps, feel free to ask more questions if you need more 
answers. 8)

-- 
... 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: contigmalloc, M_WAITOK, & leaks.

[Mike Smith]

> > Is there an s/g memory interface in FreeBSD?  This was my first choice,
> > but since I couldn't find a set of functions to build a list of buffers
> > that satisfied a set of constraints, I fell back to contigmalloc to get
> > things off the ground.  I'd be delighted to use an interface to get me
> > an s/g list with a given set of constraints that pointed to a list of
> > buffers with a given set of constraints.
> 
> Yes; this is where the busdma stuff comes in.  Use bus_dma_tag_create to 
> create a DMA tag which defines the costraints applicable to your DMA-able 
> memory.  Then you can either use bus_dmamem_alloc/bus_dmamem_free to 
> allocate conforming memory, or just take memory in the kernel's address 
> space.  In either case, you use bus_dmamap_load to build the scatter/
> gather list (and possibly perform other setup work), bus_dmamap_unload
> to tear down any of the setup work, and bus_dmamem_sync to perform 
> possibly-required bounce buffering, bus scatter/gather control, etc.

Urk.  I should avoid replying to messages in the first 20 minutes or so 
after I wake up; my dreams get confused with reality.

With dma-conformant allocated memory:

struct buf_cluster {
void *vaddr;
vm_offset_t paddr;
bus_dmamap_t map;
}

bus_dma_tag_create(parent_tag, ... &tag);
bus_dmamem_alloc(tag, &cluster.vaddr, BUS_DMA_NOWAIT, &cluster.map);
bus_dmamap_load(tag, cluster.map, cluster.vaddr, cluster_size,
cluster_helper_func, &cluster, 0)
...
void
cluster_helper_func(void *arg, bus_dma_segment_t *segs, int nseg, int error)
{
struct buf_cluster *cluster = (struct buf_cluster *)arg;

cluster->paddr = segs[0].ds_addr;
}

The above case works if you've specified the tag as giving you a single, 
unfragmented allocation.  If you took a more generous route and allowed 
it to be fragmented because your structures would never cross a page 
boundary then you would want to make the helper function more elaborate; 
the scatter gather list is in the usual base/length format in the segs 
array, and nsegs of course gives you its length.

I hope this helps, there are lots of examples of the use of this 
interface scattered throughout the tree.

-- 
... 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: PPPoE

[Ras-Sol]

Actually, I believe that the kernel optons are not needed anymore-

Or, if you tell PPP to start at bootup in "/etc/defaults/rc.conf" it
dynamically loads the netgraph stuff.

And btw, does anyone else completely DETEST the "/etc/rc.conf" -
"/etc/defaults/rc.conf"?
Why can't we just have ONE file, instead of one file, plus an override file?

And yah- I set mine up by looking in the handbook, so check there...
--

"Jupiter accepts your offer..."

 AIM: IMFDUP
- Original Message -
From: Daniel C. Sobral <[EMAIL PROTECTED]>
To: Felix-Antoine Paradis <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 22, 2001 6:51 AM
Subject: Re: PPPoE


> Felix-Antoine Paradis wrote:
> >
> > To get pppoe to work, just set the options in the kernel and use a good
> > config (ppp.conf) and use pppd.
>
> Kernel options are bad for a number of reasons, not the least of them
> the inability to do network installs (I mean, you have ADSL and get
> restricted to cd installs?). Anyway... what _are_ the kernel options?
>
> --
> Daniel C. Sobral (8-DCS)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> "There is no spoon." -- Kiki
>
>
> 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: contigmalloc, M_WAITOK, & leaks.

[Robert Lipe]

Alfred Perlstein wrote:

> > So if I sandbagged the allocs to be *larger* the KMA would behave more
> > consistently with what I'd expect becuase it would then reclaim?  I
> > didn't see that one coming. :-)
> 
> but... this is a terrible workaround, I'm not sure it would work
> and you shouldn't do it. :)

Good.  I didn't actully *want* to do that.  I still have to respect
myself in the morning. :-)

> > Is there an s/g memory interface in FreeBSD?  This was my first choice,
> 
> See the busdma stuff, 

Yes, this looks to be much closer to the interface I really wanted
anyway.  I see no man pages for them.  Is there any doc anywhere?  "Read
the source and look at existing examples" will do if it must but any
pointers to better doc are appreciated.

> there's a problem because there's no busdma
> for mbufs (well actually there is but it fails on really small
> unaligned blocks which basically breaks it for mbufs).  

Can you tell me more about this hazard?  I can't control the alignment
that's asked for by the driver, but I can certainly fudge the size and
alignment of the request by the time it gets to this interface.  Just
tell me the rules. :-)

> ack, I'd review patches if you wanted to write/port busdma for mbufs..

Thanx for the offer, but I'm hoping to avoid that right now.

It's very much a goal of mine (esp. now that we're in the final days
of the NDA requirement) to stamp out something that works on shipping
FreeBSD well enough for this crowd to see what remains to be done and
see where we are.  Then we can figure out how to improve interfaces or
otherwise enhance the base OS if we want to.  So given a choice between,
say, incurring an extra copy in a data path and porting busdma for mbufs
I'll take the former for now. 

RJL


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

Re: PPPoE

[Warner Losh]

In message <054e01c084b5$6c4ee270$[EMAIL PROTECTED]> "Ras-Sol" writes:
: And btw, does anyone else completely DETEST the "/etc/rc.conf" -
: "/etc/defaults/rc.conf"?

I don't.

: Why can't we just have ONE file, instead of one file, plus an override file?

Because we had one file in the past.  It was a nightmare to support.
Even with mergemaster there were all kinds of headaches that it caused
and support nightmares for the folks who answer questions in the
-stable and -current mailing lists.  A defaults file gives us the
ability to tweak the defaults over time and to add new defaults which
you don't get in the one file case.

This will likely never change back to one file.  Get used to it.

Warner


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

Re: contigmalloc, M_WAITOK, & leaks.

[Alfred Perlstein]

* Robert Lipe <[EMAIL PROTECTED]> [010122 12:50] wrote:
> Alfred Perlstein wrote:
> 
> > > So if I sandbagged the allocs to be *larger* the KMA would behave more
> > > consistently with what I'd expect becuase it would then reclaim?  I
> > > didn't see that one coming. :-)
> > 
> > but... this is a terrible workaround, I'm not sure it would work
> > and you shouldn't do it. :)
> 
> Good.  I didn't actully *want* to do that.  I still have to respect
> myself in the morning. :-)
> 
> > > Is there an s/g memory interface in FreeBSD?  This was my first choice,
> > 
> > See the busdma stuff, 
> 
> Yes, this looks to be much closer to the interface I really wanted
> anyway.  I see no man pages for them.  Is there any doc anywhere?  "Read
> the source and look at existing examples" will do if it must but any
> pointers to better doc are appreciated.

I know of no docs, I don't write drivers. (lucky me)

> > there's a problem because there's no busdma
> > for mbufs (well actually there is but it fails on really small
> > unaligned blocks which basically breaks it for mbufs).  
> 
> Can you tell me more about this hazard?  I can't control the alignment
> that's asked for by the driver, but I can certainly fudge the size and
> alignment of the request by the time it gets to this interface.  Just
> tell me the rules. :-)

I don't know, Bill Paul explained that the normal busdma stuff is
pretty broken for chunks too small.  Basically, disks work, network
cards won't because mbufs are too small.

> > ack, I'd review patches if you wanted to write/port busdma for mbufs..
> 
> Thanx for the offer, but I'm hoping to avoid that right now.
> 
> It's very much a goal of mine (esp. now that we're in the final days
> of the NDA requirement) to stamp out something that works on shipping
> FreeBSD well enough for this crowd to see what remains to be done and
> see where we are.  Then we can figure out how to improve interfaces or
> otherwise enhance the base OS if we want to.  So given a choice between,
> say, incurring an extra copy in a data path and porting busdma for mbufs
> I'll take the former for now. 

With mbufs you're stuck.  I have some code that needs to send > PAGE_SIZE
chunks of data down the network stack, my current "hack" is that I
prebuild the mbuf packets and split them on page boundries, then just
call m_copym on the chain, but I doubt that'll help you.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: contigmalloc, M_WAITOK, & leaks.

[Warner Losh]

In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
: > Yes, this looks to be much closer to the interface I really wanted
: > anyway.  I see no man pages for them.  Is there any doc anywhere?  "Read
: > the source and look at existing examples" will do if it must but any
: > pointers to better doc are appreciated.
: 
: I know of no docs, I don't write drivers. (lucky me)

There are no docs.  You can find docs on NetBSD's busdma
implementation from all the usual places.  The busdma interface for
FreeBSD is close to NetBSD's, but the implementation is somewhat
different.  FreeBSD's busspace, however, is missing many parts of the
NetBSD interface, and implementing those would be hard give newbus.
At leas that was my take when I tried.

: I don't know, Bill Paul explained that the normal busdma stuff is
: pretty broken for chunks too small.  Basically, disks work, network
: cards won't because mbufs are too small.

Yuck.  We should fix that.

Warner


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

Re: contigmalloc, M_WAITOK, & leaks.

[Robert Lipe]

> > > there's a problem because there's no busdma for mbufs (well
> > > actually there is but it fails on really small unaligned blocks
> > > which basically breaks it for mbufs).
> >
> > Can you tell me more about this hazard?  I can't control the
> > alignment that's asked for by the driver, but I can certainly fudge
> > the size and alignment of the request by the time it gets to this
> > interface.  Just tell me the rules. :-)
>
> I don't know, Bill Paul explained that the normal busdma stuff is
> pretty broken for chunks too small.  Basically, disks work, network
> cards won't because mbufs are too small.

Ouch.  That's a problem.  Of course, one of the goals of UDI is to
provide a consistent API into this sort of stuff.  We don't distinguish
at the driver level between disk buffers and network buffers.  Ideally,
the underlying DMA code really wouldn't know (or have to care) what type
any of this is.

If busdma is "pretty broken" for network-sized requests, I may just
avoid it for now, implement the contigmalloc cache, and move on to more
interesting problems.

RJL


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

Re: contigmalloc, M_WAITOK, & leaks.

[Mike Smith]

> If busdma is "pretty broken" for network-sized requests, I may just
> avoid it for now, implement the contigmalloc cache, and move on to more
> interesting problems.

It's broken for network-sized requests because it uses contigmalloc. 8)

The cache approach will work equally well for either interface; the 
busdma interface is "more correct".  At some point, some changes in the 
busdma interface will make it possible for you to throw out a lot of code 
related to doing s/g for network drivers.

For now, to work around the network interface problem you can just 
defragment outbound packets into a single buffer; this is the 'extra 
copy' tradeoff you mentioned.  Once busdma is fixed, that can go away.

-- 
... 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: contigmalloc, M_WAITOK, & leaks.

[Alfred Perlstein]

* Warner Losh <[EMAIL PROTECTED]> [010122 13:09] wrote:
> In message <[EMAIL PROTECTED]> Alfred Perlstein writes:
> : > Yes, this looks to be much closer to the interface I really wanted
> : > anyway.  I see no man pages for them.  Is there any doc anywhere?  "Read
> : > the source and look at existing examples" will do if it must but any
> : > pointers to better doc are appreciated.
> : 
> : I know of no docs, I don't write drivers. (lucky me)
> 
> There are no docs.  You can find docs on NetBSD's busdma
> implementation from all the usual places.  The busdma interface for
> FreeBSD is close to NetBSD's, but the implementation is somewhat
> different.  FreeBSD's busspace, however, is missing many parts of the
> NetBSD interface, and implementing those would be hard give newbus.
> At leas that was my take when I tried.

It would be uber-nice to have docs, the interface has only existed
for afaik 2-3 years now. :(

> 
> : I don't know, Bill Paul explained that the normal busdma stuff is
> : pretty broken for chunks too small.  Basically, disks work, network
> : cards won't because mbufs are too small.
> 
> Yuck.  We should fix that.

I don't know about "fixing it", netbsd seems to offer a different
interface for it (bus_dmamap_load_mbuf).  Possibly for effeciency
reasons but i'm not sure.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


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

Re: Possible bug in /usr/bin/makewhatis

[Jos Backus]

This patch gets rid of the Broken pipe messages.

--- makewhatis.orig Mon Jan 22 12:54:09 2001
+++ makewhatis  Mon Jan 22 13:01:31 2001
@@ -333,7 +333,8 @@
 
 local($source) = 0;
 local($list);
-while() {
+local($flag) = 0;
+LOOP: while() {
# ``man'' style pages
# &&: it takes you only half the user time, regexp is slow!!!
if (/^\.SH/ && /^\.SH[ \t]+["]?($section_name)["]?/) {
@@ -352,7 +353,7 @@
$list .= ' ';
}
}
-   &out($list); close F; return 1;
+   &out($list); $flag++; last LOOP;
} elsif (/^\.Sh/ && /^\.Sh[ \t]+["]?($section_name)["]?/) {
# ``doc'' style pages
local($flag) = 0;
@@ -375,12 +376,15 @@
$list .= ' ';
}
}
-   &out($list); close F; return 1;
+   &out($list); $flag++; last LOOP;
 
} elsif(/^\.so/ && /^\.so[ \t]+man/) {
-   close F; return 1;
+   $flag++; last LOOP;
}
 }
+1 while(); # Flush pipe
+close F;
+return 1 if $flag;
 if (!$source && $verbose) {
warn "\n" if $pointflag;
warn "Maybe $file is not a manpage\n" ;

-- 
Jos Backus _/  _/_/_/"Modularity is not a hack."
  _/  _/   _/-- D. J. Bernstein
 _/  _/_/_/ 
_/  _/  _/_/
[EMAIL PROTECTED] _/_/   _/_/_/use Std::Disclaimer;


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

RE: more info about: odd result of pci_read_config

[Steve Shoecraft]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Nicolas Souchu
> Sent: Monday, January 22, 2001 10:48 AM
> To: Steve Shoecraft
> Cc: 'John Baldwin'; 'Donald J . Maddox'; [EMAIL PROTECTED]
> Subject: Re: more info about: odd result of pci_read_config
>
>
> On Mon, Jan 22, 2001 at 04:05:31AM -0600, Steve Shoecraft wrote:
> > > My viapm driver is a kmodule. Could it be that
> PCI_READ_CONFIG is not
> > > correctly resolved and returns ENXIO which is 0x6?
> >
> > That's exactly whats going on here.  Have you turned on
> BUS_DEBUG (or mebbe
> > DEBUG_BUS) in /kern/subr_bus.c ?
>
> Not yet. I will then.
>
> >
> > Also, I have a userland app that loads and runs your kernel
> module - it
> > makes it alot easier to debug this kinda stuff.  Even does
> device file I/O.
> > If you want, you can check it out.
>
> Thanks, where?
>

I've included it as an attachment (very small -- only 14k).

I forgot to add in the readme file you need to create the test device:

cd /dev
mknod test0 c 252 0

Once you get it running, you can enable the output of the newbus debug code
by editing mod/test_bus.c and setting DEBUG to 1.  You'll have to re-install
testmod before your changes will take effect (the testmod program loads
testmod.ko from /modules).

- Steve

> --
> [EMAIL PROTECTED]
> Alcôve - Open Source Software Engineer - http://www.alcove.fr
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>

 testmod.tgz

Re: PPPoE

[Brian Somers]

I think the best way to implement this is some sort of config message 
to the pppoe node (before the connect/listen).  The NETGRAPH version 
of ppp(8) is capable of doing ``chat scripts'' with netgraph nodes, 
so it's fairly easy to configure the node configuration conversation...

Hopefully now that Christmas is over I'll be able to get back to 
netgraph'ifying ppp :-)

> Felix-Antoine Paradis wrote:
> > 
> > To get pppoe to work, just set the options in the kernel and use a good
> > config (ppp.conf) and use pppd.
> > 
> > On Mon, 22 Jan 2001, Daniel C. Sobral wrote:
> > 
> > > It seems I need the following parameters to get my PPPoE to work. Could
> > > we have these options, please?
> > >
> > > >> -f disc:sess
> > > >>The  -f  option  sets  the Ethernet frame types for
> > > >>PPPoE discovery and session frames.  The types  are
> > > >>specified  as  hexadecimal  numbers  separated by a
> > > >>colon.  Standard PPPoE uses frame types  8863:8864.
> > > >>You should not use this option unless you are abso¡
> > > >>lutely sure the peer you are dealing with uses non-
> > > >>standard  frame  types.  If your ISP uses non-stan¡
> > > >>dard frame types, complain!
> 
> Definitly complain! This is equivalent to calling a protocol tcp/ip
> but using a first byte in the packet.
> I will look at a configuration message for the netgraph node
> but Brian will hav eto work out how to send it, and where the
> configuration parameter should be set to do this..
> 
> The other possibility is a sysctl.
> 
> 
> > > >>  -S service_name
> > > >> Specifies the desired  service  name.   pppoe  will
> > > >> only  initiate  sessions  with access concentrators
> > > >> which can provide the specified service.   In  most
> > > >> cases,  you should not specify this option.  Use it
> > > >> only if you know that  there  are  multiple  access
> > > >> concentrators or know that you need a specific ser¡
> > > >> vice name.
> 
> 
> If you are talking about the netgraph based pppoe, then -xxx type 
> flags are not how you configure it.  I think you are talking about
> the (rather inefficient) userland ppp daemon.
> 
> the service name requested is already an argument in the pppoe 
> configuration.
> 
> "If a PPPoE:iface[:provider] specification is given, ppp will at-
> tempt to create a PPP over Ethernet connection using the given
> iface interface by using netgraph(4). "
> 
> In this case the "provider" is the service name.
> 
> 
> -- 
>   __--_|\  Julian Elischer
>  /   \ [EMAIL PROTECTED]
> (   OZ) World tour 2000
> ---> X_.---._/  from Perth, presently in:  Budapest
> v

-- 
Brian <[EMAIL PROTECTED]>
     
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

Re: PPPoE

[Felix-Antoine Paradis]

I would say...

options NETGRAPH
options NETGRAPH_PPPOE
options NETGRAPH_SOCKET

That's it. recompile and conf'd your pppd.

On Mon, 22 Jan 2001, Daniel C. Sobral wrote:

> Felix-Antoine Paradis wrote:
> >
> > To get pppoe to work, just set the options in the kernel and use a good
> > config (ppp.conf) and use pppd.
>
> Kernel options are bad for a number of reasons, not the least of them
> the inability to do network installs (I mean, you have ADSL and get
> restricted to cd installs?). Anyway... what _are_ the kernel options?
>
> --
> Daniel C. Sobral  (8-DCS)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>   "There is no spoon." -- Kiki
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>

. . . . . . . . . . . . . . . . . . . . . . . . . . . .  .
.   Felix-Antoine Paradis.  cell:1-418-261-0865  .
.  IRC:   reel @ DALnet  .  job:Idemnia Network  .
.  Email: [EMAIL PROTECTED]  .  *** www.FreeBSD.org ***  .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .  .



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

Re: PPPoE

[Udo Erdelhoff]

On Mon, Jan 22, 2001 at 05:24:46PM -0500, Felix-Antoine Paradis wrote:
> I would say...
> 
> options NETGRAPH
> options NETGRAPH_PPPOE
> options NETGRAPH_SOCKET

add NETGRAPH_ETHER for 4.2 and above.

/s/Udo
-- 
Eat the rich -- the poor are tough and stringy.


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

Re: Patch to fix "make buildkernel requires full obj directory" mistake

[Warner Losh]

In message <[EMAIL PROTECTED]> "Dan Langille" writes:
: http://www.freebsd.org/handbook/kernelconfig-building.html

This change should do the trick if I'm reading things right.

Warner

Index: chapter.sgml
===
RCS file: 
/home/imp/FreeBSD/CVS/doc/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml,v
retrieving revision 1.36
diff -u -r1.36 chapter.sgml
--- chapter.sgml2000/08/10 02:09:18 1.36
+++ chapter.sgml2001/01/22 23:20:48
@@ -167,8 +167,8 @@
   following commands:
 
 &prompt.root; cd /usr/src
-&prompt.root; make buildkernel KERNEL=MYKERNEL
-&prompt.root; make installkernel KERNEL=MYKERNEL
+&prompt.root; make buildkernel KERNCONF=MYKERNEL
+&prompt.root; make installkernel KERNCONF=MYKERNEL
 
 If you have not upgraded your source
   tree in any way (you have not run CVSup, 


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

kernel debugging help

[Zhiui Zhang]

I am debugging a kernel. Since a kernel is consisted of many files, how
can I load a specific file into gdb, browse it, and set a break point at
some line within that file? Right now, I can only view the file whose
statements are being executed. Thanks.

-Zhihui



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

Re: Possible bug in /usr/bin/makewhatis

[Dag-Erling Smorgrav]

Jos Backus <[EMAIL PROTECTED]> writes:
> This patch gets rid of the Broken pipe messages.

No need to name the loop...

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


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

Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h

[Sergey Babkin]

To mention it from the start, I've backed out my changes.
(Yes, the pre-backed-out version was the one with the old behavior
enabled by default and changed behavior enabled by an option).

Doug Barton wrote:
> 
> On Sun, 21 Jan 2001, Sergey Babkin wrote:
> 
> > Doug Barton wrote:
> > >
> > > This needs to be backed out immediately. This isn't even close to what 
>was
> > > discussed in -hackers. After LONG, often pointless discussion, the
> > > following points were agreed to there.
> >
> > Could you please look at the changes first ? The changes I
> > committed are _not_ those from NetBSD.
> 
> So instead of following what was agreed to on -hackers you went
> off on your own and committed something totally different? This is worse
> than I thought.

Gerhard Sittig did test the changes from NetBSD and
found that they do not quite solve the DST problem. That means
that some other way of handling the DST changes should be used.
I proposed such a way.

> > My changes do not try
> > to cover all the cases of skipped minutes but are specifically
> > for the change of DST and actually take many precautions to avoid
> > messing with the other cases.
> 
> ... which makes the POLA violation worse instead of better. When
> we tell people that our cron handles DST changes, the people who live in
> areas where the change is not exactly one hour happening at :00 will
> not hear the disclaimer that they are, "out of luck," as you put it.

Yes, I agree that this is not good. Though considering that
practically all the world except Kirgizia and two smaller islands near 
Australia falls into the lucky category, this is not that bad.

I think I see a reasonably easy way to fix it now.
 
> > On the points:
> >
> > > Gerhard Sittig wrote:
> > > > I take notice of your (and Greg Black's) reservation / being
> > > > opposed, respect it and conclude that the change will have to
> > > > - default to the current behaviour (something quite usual for
> > > >   expanding changes)
> >
> > The behavior is quite close to the current one, differing for
> > only the jobs running less frequently than every hour when of course they hit the 
>DST change frame, and different in a rather safe way.
> 
> For a definition of "safe" that is entirely inadequate.

In the traditional way strange things happen to the jobs scheduled
between 1am and 3am (for Europe/US, time may differ for other
time zones) at the DST changes. In the changed way other things
happen which are somewhat less strange. That sounds very much like
"safe".

> > > > - yet be enabled easily for those interested in the change to
> > > >   work for them and free up some of their resources for more
> > > >   important tasks
> > > > - maybe provide knobs (besides the on-off-switch) to customize
> > > >   behaviour in a more fine grained way
> >
> > All the discussion in the thread was about that sysadmins must
> > not schedule jobs at 2:00-2:59 AM time (and actually 1:00-1:59
> > as well to avoid duplication though somehow nobody mentioned it).
> > If no jobs are scheduled at this interval, then the behavior
> > of the cron with my changes is absolutely identical to the
> > old one.
> 
> That is certainly NOT the only discussion. I made the point
> several times that someone who schedules a time critical job during the
> DST change period will have a huge problem if their job is unexpectedly
> run without sufficient time to finish, or 

There are other things which may not allow a job to finish in 
a predefined time slot. For example, other operations going on
and consuming CPU, disk or network bandwidth. So presuming
that a job would finish by some time is inherently unsafe.
The safe way is to put both jobs sequentially into one script
and run this one script from cron.

And of course there is a very good chance that the problem would
be exactly the same or worse if the job does not run at all,
what happens with the traditional implementation. 

> what is frequently worse their
> job is run twice. 

That's what happens now at switch from 1am DST to 1am ST - all the
jobs in the interval 1:00-1:59 run the second time. And that's a part 
of what my change prevents.

> The proponents of the change responded by saying that
> you shouldn't schedule time critical jobs during this period, to which I
> replied that if you can solve the problem other ways then there is no need
> to modify cron.

Time critical jobs should be avoided at all, by including all the
dependent jobs into one script and running only this script
from cron. There is no reason why the DST-dependent period is worse
for this purpose than any other one.
 
> What I object to about making this the default is that you are
> effectively programming to the lowest common denominator, assuming from
> the start that people are too stupid to schedule their jobs properly,
> therefore we must fix them in ways that potentially break cron for people
> who expect the well established behavi

Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)

[Sergey Babkin]

Matt Dillon wrote:
> 
> :> with your rather large diff set.  For better or for worse, people
> :> already know about the daylight savings shift problem.  Thousands
> :> of people depend on cron to work, which means that when you
> :> make a major change like this it must be tested by a wider audience
> :> for a longer time before becoming the default.  It needs to have some
> :> real-life operational experience behind it.
> :
> :This can be applied to whole FreeBSD just as well. And IMHO
> :cron is less critical than any part of the kernel, yet changes
> :to the kernel don't usually bring such a strong reaction.
> 
> I think you have a valid argument in regards to cron vs the kernel.
> But keep in mind that even though you are fixing a 'bug', it's a well
> known 'bug' so you are in fact creating an operational change to the
> code rather then just a bug fix or minor performance enhancement, etc...

Yes, I understand that and I tried to make the change maximally
compatible with the existing behavior. Even with all this I agree
that making this change optional is a yet safer approach and by
now I feel quite sorry that I did not take it from the start.

> When I do major kernel work, it's usually tested by third parties for
> a week or two.  The last three major commits I've done had been under
> test for three weeks (don't let the 2-5 day MFC fool you, I have to
> do all my work on -stable first, then forward port to -current, then
> MFC back to -stable).

I never intended to MFC it immediately, that's why I said
"in a few weeks" thus implying something like a month or so,
possibly more. Also this change is not quite a major one.

> :> This is broken.  If you want to check for a DLS change there is only
> :> one right way to do it, and that is to compare the wall clock
> :> differential verses the GMT differential, and to not put in any silly
> :
> :I disagree. Checking the difference from GMT creates a danger
> :of misrecognition of a time zone change (for example, when
> :a machine was physically moved) for a DST switch. So comparing
> :is_dst is the only reliable way to tell if there actually was
> :such a switch.
> 
> I don't consider someone changing the machine's /etc/localtime zone
> to be an issue, since it rarely if ever happens.  And if a machine is
> moved, it's likely to be powered down anyway cron is not going to
> nor is it supposed to 'catch up' after downtime.  Additionally, cron
> cannot detect a timezone change without being restarted, so the point
> is moot anyhow.

Agreed, this did not occur to me at once. Actually, after some 
thinking I see a reason why the difference from GMT may change without
changing the DST state: if the country adopts different offset for 
its time zones, then the zoneinfo file would be updated in advance
and cron would discover it on time. So comparing the difference 
really is the right way. And I think I see a simple way to do that 
and handling of arbitrary offsets as well.

-SB


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

Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab)

[Sergey Babkin]

Greg Black wrote:
> 
> Sergey Babkin wrote:
> 
> > It still can be backed out.
> 
> Well, what are you waiting for?  Back it out.  Listen to what
> people are saying and then maybe propose something that takes
> into account their concerns.

I wanted to get a confirmation from Doug Barton that he still
considers the changes unacceptable even after looking at them.
Demanding the changes backed out without even looking at them
does not strike me as a very good way of conducting a technical 
discussion.

> To make this point a little more clearly -- the fact that Matt
> Dillon, who is no fool, and you have wildly divergent ideas on
> the appropriate/correct method to determine when to do things is
> further evidence (as if any were needed) that this is not a
> trivial thing to get right.  First, people have to agree on what
> is right and we're not there yet.
> 
> Please take note of what people are saying, stop the silly
> protests about your failure to be convinced by other people's
> arguments, and recognise that you don't have a special line to
> the One True Way.

I never mentioned that I know this One True Way. I'm still not
convinced but I've backed out the changes anyway. Yet I'd still
like to see the discussion of technical merits of keeping the
traditional behavior.
 
> Finally, in reference to the confusion over POLA, get something
> straight:  the people we must take most care not to astonish are
> current users of FreeBSD; after them, we can consider users who
> are migrating from other Unix variants.  The fact that others
> may do things differently is not, of itself, an argument to take
> a wild jump into the darkness here.

I agree that random changes are bad. What I'm trying to say is that
the current FreeBSD users most probably divided into two classes:

1) Those who know about the DST switch issues. For them POLA works
as you say but they would probably avoid the 1:00-2:59am timeframe 
and thus would not be affected by the changes.

2) Those who don't know about this issue (speaking in Doug's
words, those "too stupid") - they don't care for now but if some
day they schedule a cron job in this timeframe, for them POLA would 
work the other way, and with the traditional behavior they are
going to learn a harder lesson. 

Some people who use both FreeBSD and some other Unix may get into the
second category as well.
 
> The continued, predictable, behaviour of cron is important to
> users and cannot be just played about with at your whim, and
> this is especially true when you don't even have support for the
> so-called solution you have proposed.

As far as I can see, I do have some support. 

-SB


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

Kernel programming

[Yonny Cardenas B.]

Hello 

I am adding a set the new system calls to FreeBSD kernel, 
but to compile and to test new source code within the kernel 
is a little hard  when there is some problem.

Is there anybody knows some reference (URL), tools or some help 
to programming and debugging in the kernel FreeBSD?
That is some suggestions, examples, etc., different to 
kernel?s source code of course.

Thanks.

+--+
| YONNY CARDENAS B. Apartado Aereo  22828  |
| Systems Engineer  Santafe de Bogota D.C. |
|   Colombia - South America   |
| Student M.Sc. Tel:   +571 6095477| 
| UNIVERSIDAD DE LOS ANDES  mailto: [EMAIL PROTECTED]   | 
|   [EMAIL PROTECTED]  |
|   http://www.geocities.com/ycardena  |
+--+
UNIX is BSD, and FreeBSD is an advanced 4.4BSD


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

Re: Kernel programming

[Tim McMillen]

Are you looking for something more than:
http://www.freebsd.org/handbook/kerneldebug.html
I don't know if there is any.  There are a fair amount of undocumented 
system calls in the FreeBSD kernel as I understand it.  Chapter 22 of 
the handbook may be helpful too.
There may also be some articles in say daemonnews or something, but 
basically the source code is going to be what you'll have to go on.

Tim

On Monday January 22, 2001 22:16, Yonny Cardenas B. wrote:
> Hello
>
> I am adding a set the new system calls to FreeBSD kernel,
> but to compile and to test new source code within the kernel
> is a little hard  when there is some problem.
>
> Is there anybody knows some reference (URL), tools or some help
> to programming and debugging in the kernel FreeBSD?
> That is some suggestions, examples, etc., different to
> kernel?s source code of course.
>
> Thanks.
>
> +--+
>
> | YONNY CARDENAS B. Apartado Aereo  22828  |
> | Systems Engineer  Santafe de Bogota D.C. |
> |   Colombia - South America   |
> | Student M.Sc. Tel:   +571 6095477|
> | UNIVERSIDAD DE LOS ANDES  mailto: [EMAIL PROTECTED]   |
> |   [EMAIL PROTECTED]  |
> |   http://www.geocities.com/ycardena  |
>
> +--+
> UNIX is BSD, and FreeBSD is an advanced 4.4BSD
>
>
> 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: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h

[Greg Black]

Sergey Babkin wrote:

> To mention it from the start, I've backed out my changes.

Thank you.

> There are other things which may not allow a job to finish in 
> a predefined time slot. For example, other operations going on
> and consuming CPU, disk or network bandwidth. So presuming
> that a job would finish by some time is inherently unsafe.
> The safe way is to put both jobs sequentially into one script
> and run this one script from cron.

Remember that for later.

> Time critical jobs should be avoided at all, by including all the
> dependent jobs into one script and running only this script
> from cron.

And remember that while you read this:

> I can give you one example from my past experience: a nightly cold
> backup of a database which takes a long time, must be started after 
> all the day's work would be complete, and finish by 7:30AM the next
> morning. The time of backup depends on the amount of change logs
> generated during the day, so to be safe it should be started as
> early as possible. Well, eventually we got the day's close
> processing to complete by 12:50 and scheduled the job there.
> But the fact that two hours of time are unusable for starting
> any jobs is not a particularly exciting one nor fun to discover.

This is an absurd claim, especially in the light of what you
said earlier (quoted above).  If the backup depends on the
processing of something else, then the script that starts the
other processing should run the backup at the end, and issues of
DST are completely irrelevant.  This has always been the case,
and still is.

You keep demanding technical arguments (which I think means
arguments about the content of the proposed changes) -- but the
matter of concern to me is /not/ that at all, it's whether there
is any need for potentially breaking an important utility which
has known behaviour to "solve" things that don't need and are
not suited to technical solutions, no matter who else might
think that is the way to go.  Arguing that commercial Unix
vendors have decided to meet the lowest common denominator by
changing cron is not a case for FreeBSD to go down the same
road.

> > > > I made the additional point that the options should be command line
> > > > options, instead of environment variables as someone else suggested.
> > >
> > > And I made the additional point that practically all the commercial
> > > Unixes do support intelligent handling of DST. Being different
> > > from them makes no good and is a lot of inconvenience.
> > 
> > If you want to offer the option of making cron think for the user
> > instead of following traditional behavior then it should be offered as a
> > command line option, defaulting to off. Period. "We're not like everyone
> > else" is not a compelling argument here.
> 
> This sort of arguments is largely responsible for why Unix had
> branched in so many incompatible ways. The NIH syndrome is not
> the most productive approach.

A certain TLA once came out with their own Unix (known by
another TLA) and I had the joy of working with beta versions of
this OS.  Thousands of things just didn't work, including dozens
of awk scripts.  It turned out that the company had "audited"
the awk code and "fixed" it to comply with their in-house coding
standards.  Just because other people do something is not of
itself a compelling argument to follow suit.


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

Re: Possible bug in /usr/bin/makewhatis

[Jos Backus]

On Tue, Jan 23, 2001 at 02:31:48AM +0100, Dag-Erling Smorgrav wrote:
> No need to name the loop...

Oops, you're right, sorry.

-- 
Jos Backus _/  _/_/_/"Modularity is not a hack."
  _/  _/   _/-- D. J. Bernstein
 _/  _/_/_/ 
_/  _/  _/_/
[EMAIL PROTECTED] _/_/   _/_/_/use Std::Disclaimer;


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

Re: PAM (was: Re: MAIL set by whom?)

[Daniel C. Sobral]

Dominic Mitchell wrote:
> 
> On Sun, Jan 21, 2001 at 04:45:50PM +0100, Roelof Osinga wrote:
> > Grand gesture. Laudable even. Yeah, that PAM sure seems to've
> > become popular. The Courier IMAP port also insisted upon its
> > installation. Insisted in that fiddling with the makefile only
> > resulted in failure to configure. But that's a whole different
> > story.
> 
> Would it be a good idea to start using /etc/pam.d ala RedHat, instead of
> the monolithic /etc/pam.conf?
> 
> As far as I can see the support is already there, it's just not being
> used due to the presence of the /etc/pam.conf.
> 
> This would make installing PAM entries far easier for the ports.

Ports shouldn't touch /etc.

Does the existance of /etc/pam.conf precludes /usr/local/etc/pam.d from
working?

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"There is no spoon." -- Kiki


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

Re: PAM (was: Re: MAIL set by whom?)

[Jacques A. Vidrine]

On Tue, Jan 23, 2001 at 02:42:41AM +0900, Daniel C. Sobral wrote:
> Ports shouldn't touch /etc.
> 
> Does the existance of /etc/pam.conf precludes /usr/local/etc/pam.d from
> working?

Other way around.  From the man page (the last sentence is even
underlined :-)
 
Alternatively, the configuration can be set by individual
configuration files located in the /etc/pam.d/ directory.  The
presence of this directory will cause PAM to ignore /etc/pam.conf.

-- 
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]



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