Re: /usr/games/wtf

[Max Khon]

hi, there!

> > I would like to add /usr/games/wtf from NetBSD to base system.
> > Any opinions/objections?
> 
> wtf is it?

NAME
 wtf - translates acronyms for you

SYNOPSIS
 wtf [is] acronym ...

husky:~$wtf is pola
POLA: principle of least astonishment
husky:~$

/fjoe

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

Re: /usr/games/wtf

[Ruslan Ermilov]

On Tue, Aug 21, 2001 at 01:03:11PM +0700, Max Khon wrote:
> hi, there!
> 
> I would like to add /usr/games/wtf from NetBSD to base system.
> Any opinions/objections?
> 
FWIW, I don't like its name.  :-)


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

is 'suspend' broken in CURRENT?

[Vladimir B. Grebenschikov]

Juriy Goloveshkin writes:
 > I have sony vaio z505hs. I have latest cvs-tree.
 > suspend worked 1-2 weeks ago but now when I want to resume from suspend-mode
 > I see the same screen I saw before suspend but keyboard doesn't work and
 > harddisk doesn't spin.

Have same problem on:
FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sat Aug 18 00:12:19 MSD 
2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/VBOOK  i386

When I was running RELENG_4 my vaio z505s allways successful awake
from hibernation, and with probability about 30% freezes after awake
from suspend. Now (with -CURRENT) it always freezes after awake from
suspend, and often freezes after awake from hibernation.

 > bye
 > Juriy Goloveshkin

--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]

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

Re: Sound broken on -current again...

[Maxim Sobolev]

John Baldwin wrote:

> > The same is here (OPL3-SA driver on Toshiba Satellite Pro 445CDX notebook).
> > I found that after reverting the following deltas (jhb's 10 August commit)
> > sound starts working again:
>
> That's a rather large commit.  Is this the ast() fixup?  Is the process that
> has the sound device open hung?  Is it stuck in a wait channel?  If so, can you
> do a ps and find the wait channel?  Is it chewing up large amounts of CPU time?
> Has it exited with a signal?

Somebody tracked it down to kern_synch.c,v 1.154 and I'm confirming that reverting
this delta indeed fixes the problem. The process in question hangs and doesn't
respond to any signals (SIGKILL included). Following is the relevant piece of `ps
axl' output:

  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT   TIME COMMAND
0   275   267   0  -8  0 41496  212 -  R+v00:00,74 madplay /cdr

Please note that even though madplay above is in the `RUN' state it doesn't consume
any CPU time.

Please let me know if any additional information would be necessary.

-Maxim


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

Re: Sound broken on -current again...

[Søren Schmidt]

It seems John Baldwin wrote:
> > In servalan.mailinglist.fbsd-current Maxim Sobolev writes:
> >>I found that after reverting the following deltas (jhb's 10 August commit)
> >>sound starts working again:
> > 
> > [list of deltas deleted]
> > 
> > I found much the same thing; specifically, the problematic change is this
> > one:
> 
> What wait channel is the process (xmms, mpg123, whatever) in?

mpg123 hangs on sbwait

Oh and btw the same commits seem to have broken USB too (at least on
my VIA based board).

-Søren

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

Re: Where to put new bus_dmamap_load_mbuf() code

[Justin T. Gibbs]

>
>Correction.
>
>This sample:
>>
>> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
>> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
>> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
>> isp_prt(isp, ISP_LOGERR,
>> "cannot create a dma tag for control spaces");
>> free(isp->isp_xflist, M_DEVBUF);
>> free(pci->dmaps, M_DEVBUF);
>> return (1);
>> }
>>

You'll need to change the number of segments to match the max
supported by the card (or the max you will ever need).  This
example made me realize that the bounce code doesn't deal with
multiple segments being copied into a single page (i.e. tracking
and using remaining free space in a page already allocated for
bouncing for a single map).  I'll have to break loose some time
to fix that.

--
Justin

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

Re: Copyright Contradiction in libalias

[Brandon D. Valentine]

On Mon, 20 Aug 2001, Crist J. Clark wrote:

>It is now written policy, and I
>believe it was the understood, unwritten policy in the past, that any
>patches and additions to a file in FreeBSD are governed by the
>existing licensing of the file unless otherwise stated. This would
>indicate to me that this file is arguably still public domain.

The problem with source in the public domain versus a BSD license is
that public domain source code does not explicitly release the project
and author from liability.  I'm sure that's why a BSD license was
slapped over this code.

-- 
"Never put off until tomorrow what you can do today.  There might be a
law against it by that time."   -- /usr/games/fortune, 07/30/2001

Brandon D. Valentine 



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

Re: Where to put new bus_dmamap_load_mbuf() code

[Justin T. Gibbs]

>Every hear the phrase "you get what you pay for?" The API isn't all that
>clear, and we don't have a man page or document that describes in detail
>how to use it properly. Rather than whining about that, I decided to
>tinker with it and Use The Source, Luke (tm). This is the result.

Fair enough.

>My understanding is that you need a dmamap for every buffer that you want
>to map into bus space.

You need one dmamap for each independantly manageable mapping.  A
single mapping may result in a long list of segments, regardless
of whether you have a single KVA buffer or multiple KVA buffers
that might contribute to the mapping.

>Each mbuf has a single data buffer associated with
>it (either the data area in the mbuf itself, or external storage). We're
>not allowed to make assumptions about where these buffers are. Also, a
>single ethernet frame can be fragmented across multiple mbufs in a list.
>
>So unless I'm mistaken, for each mbuf in an mbuf list, what we
>have to do is this:
>
>- create a bus_dmamap_t for the data area in the mbuf using
>  bus_dmamap_create()

Creating a dmamap, depending on the architecture, could be expensive.
You really want to create them in advance (or pool them), with at most
one dmamap per concurrent transaction you support in your driver.

>- do the physical to bus mapping with bus_dmamap_load()

bus_dmamap_load() only understands how to map a single buffer.
You will have to pull pieces of bus_dmamap_load into a new
function (or create inlines for common bits) to do this
correctly.  The algorithm goes something like this:

foreach mbuf in the mbuf chain to load
/*
 * Parse this contiguous piece of KVA into
 * its bus space regions.
 */
foreach "bus space" discontiguous region
if (too_many_segs)
return (error);
Add new S/G element

With the added complications of deferring the mapping if we're
out of space, issuing the callback, etc.

>- call bus_dmamap_sync() as needed (might handle copying if bounce
>  buffers are required)
>- 
>- do post-DMA sync as needed (again, might require bounce copying)
>- call bus_dmamap_unload() to un-do the bus mapping (which might free
>  bounce buffers if some were allocated by bus_dmamap_load())
>- destroy the bus_dmamap_t

Chances are you are going to use the map again soon, so destroying
it on every transaction is a waste.

--
Justin

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

Re: /usr/games/wtf

[Kris Kennaway]

On Tue, Aug 21, 2001 at 01:03:11PM +0700, Max Khon wrote:
> hi, there!
> 
> I would like to add /usr/games/wtf from NetBSD to base system.
> Any opinions/objections?

wtf is it?

Kris

 PGP signature

/usr/games/wtf

[Max Khon]

hi, there!

I would like to add /usr/games/wtf from NetBSD to base system.
Any opinions/objections?

/fjoe

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

Re: Where to put new bus_dmamap_load_mbuf() code

[Matthew Jacob]

Correction.

This sample:
>
> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
> isp_prt(isp, ISP_LOGERR,
> "cannot create a dma tag for control spaces");
> free(isp->isp_xflist, M_DEVBUF);
> free(pci->dmaps, M_DEVBUF);
> return (1);
> }
>

Should have been:

if (bus_dma_tag_create(NULL, 1, 0, BUS_SPACE_MAXADDR_32BIT,
BUS_SPACE_MAXADDR, NULL, NULL, lim + 1,
255, lim, 0, &pcs->parent_dmat) != 0) {
device_printf(dev, "could not create master dma tag\n");
free(isp->isp_param, M_DEVBUF);
free(pcs, M_DEVBUF);
return (ENXIO);
}



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

Re: Where to put new bus_dmamap_load_mbuf() code

[Matthew Jacob]

On Mon, 20 Aug 2001, Bill Paul wrote:

> Every hear the phrase "you get what you pay for?" The API isn't all that
> clear, and we don't have a man page or document that describes in detail
> how to use it properly. Rather than whining about that, I decided to
> tinker with it and Use The Source, Luke (tm). This is the result.

Well, I'm more familiar with the NetBSD BusDma code, which is similar, and
heavily documented. I'm also one of the principle authors of the Solaris
DKI/DDI, which is *also* heavily documented, so I have some small notion of
how a few of these subsystems are supposed to work, and where documentation
exists for these- and similar systems (e.g., UDI).

>
> My understanding is that you need a dmamap for every buffer that you want
> to map into bus space. Each mbuf has a single data buffer associated with
> it (either the data area in the mbuf itself, or external storage). We're
> not allowed to make assumptions about where these buffers are. Also, a
> single ethernet frame can be fragmented across multiple mbufs in a list.
>
> So unless I'm mistaken, for each mbuf in an mbuf list, what we
> have to do is this:
>
> - create a bus_dmamap_t for the data area in the mbuf using
>   bus_dmamap_create()
> - do the physical to bus mapping with bus_dmamap_load()
> - call bus_dmamap_sync() as needed (might handle copying if bounce
>   buffers are required)
> - 
> - do post-DMA sync as needed (again, might require bounce copying)
> - call bus_dmamap_unload() to un-do the bus mapping (which might free
>   bounce buffers if some were allocated by bus_dmamap_load())
> - destroy the bus_dmamap_t
>
> One memory region, one DMA map. It seems to me that you can't use a
> single dmamap for multiple memory buffers, unless you make certain
> assumptions about where in physical memory those buffers reside, and
> I thought the idea of busdma was to provide a consistent, opaque API
> so that you would not have to make any assumptions.
>
> Now if I've gotten any of this wrong, please tell me how I should be
> doing it. Remember to show all work. I don't give partial credit, nor
> do I grade on a curve.


This is fine insofar as it goes, but there's nothing, I believe, that requires
you to *create* a bus_dmamap_t each time you wish to map something and then
destroy it when you unmap something. You might ask why one actually has the
separate step from map creation and map load at all then. All the rest of the
stuff for load/sync/sync/unload is fine.

Using The Code (tm)- you can see that, for example, you can create
a tag that describes all of the the addressable space your device
can access, e.g.:

if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
isp_prt(isp, ISP_LOGERR,
"cannot create a dma tag for control spaces");
free(isp->isp_xflist, M_DEVBUF);
free(pci->dmaps, M_DEVBUF);
return (1);
}

Then, for each possible transaction slot- if you have a device that has a
fixed number of transactions that are possible (as many do), you can create
maps ahead of time:

for (i = 0; i < isp->isp_maxcmds; i++) {
error = bus_dmamap_create(pci->parent_dmat, 0, &pci->dmaps[i]);
if (error) {
...

so that for each transaction that needs to be mapped, you can dma load it:

bus_dmamap_t *dp;
...
dp = &pci->dmaps[isp_handle_index(rq->req_handle)];
...
s = splsoftvm();
error = bus_dmamap_load(pci->parent_dmat, *dp,
 csio->data_ptr, csio->dxfer_len, eptr, mp, 0);
...

which as part of the load process can sync it:

dp = &pci->dmaps[isp_handle_index(rq->req_handle)];

if ((csio->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_IN) {
bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_PREREAD);
} else {
bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_PREWRITE);
}

and when the transaction is done, you can sync and unload:

static void
isp_pci_dmateardown(struct ispsoftc *isp, XS_T *xs, u_int16_t handle)
{
struct isp_pcisoftc *pci = (struct isp_pcisoftc *)isp;
bus_dmamap_t *dp = &pci->dmaps[isp_handle_index(handle)];
if ((xs->ccb_h.flags & CAM_DIR_MASK) == CAM_DIR_IN) {
bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_POSTREAD);
} else {
bus_dmamap_sync(pci->parent_dmat, *dp, BUS_DMASYNC_POSTWRITE);
}
bus_dmamap_unload(pci->parent_dmat, *dp);
}




So- my question still stands- from a performance point of view (Networking
people *do* care about performance I believe, yes? :-))- if you don't need to
create the map each time, wouldn't you rather not? So, the mbuf mapping code,
which is cool to have, really might not need this?

Re: Sound broken on -current again...

[Richard Todd]

In servalan.mailinglist.fbsd-current jhb writes:
>On 19-Aug-01 Richard Todd wrote:
>> In servalan.mailinglist.fbsd-current Maxim Sobolev writes:
>>>I found that after reverting the following deltas (jhb's 10 August commit)
>>>sound starts working again:
>> 
>> [list of deltas deleted]
>> 
>> I found much the same thing; specifically, the problematic change is this
>> one:

>What wait channel is the process (xmms, mpg123, whatever) in?

Looking at a core file from a known-buggy kernel that I'd forced to core
itself with ddb, I find for the madplay process:
(kgdb) proc 855
(kgdb) bt
#0  mi_switch () at ../../../kern/kern_synch.c:707
#1  0xc0273645 in msleep (ident=0xc13e0b00, mtx=0xc13d2800, priority=332, 
wmesg=0xc042bcb4 "pcmwr", timo=1) at ../../../kern/kern_synch.c:466
#2  0xc01fcad8 in chn_sleep (c=0xc13d1680, str=0xc042bcb4 "pcmwr", timeout=1)
at ../../../dev/sound/pcm/channel.c:109
#3  0xc01fcd5c in chn_write (c=0xc13d1680, buf=0xc8f1af00)
at ../../../dev/sound/pcm/channel.c:259
#4  0xc01fef40 in dsp_write (i_dev=0xc13e0f00, buf=0xc8f1af00, flag=2359297)
at ../../../dev/sound/pcm/dsp.c:381
#5  0xc0243095 in spec_write (ap=0xc8f1ae90)
at ../../../fs/specfs/spec_vnops.c:289
#6  0xc0242dc9 in spec_vnoperate (ap=0xc8f1ae90)
at ../../../fs/specfs/spec_vnops.c:119
#7  0xc02b7c5f in vn_write (fp=0xc1623ec0, uio=0xc8f1af00, cred=0xc15c2600, 
flags=0, p=0xc8e54100) at vnode_if.h:303
#8  0xc028c073 in dofilewrite (p=0xc8e54100, fp=0xc1623ec0, fd=3, 
buf=0xbfbf8b74, nbyte=4608, offset=-1, flags=0) at ../../../sys/file.h:162
#9  0xc028bf26 in write (p=0xc8e54100, uap=0xc8f1af80)
at ../../../kern/sys_generic.c:334
#10 0xc03e2fc9 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
  tf_edi = -1077965964, tf_esi = 4608, tf_ebp = -1077937536, 
  tf_isp = -923684908, tf_ebx = -1077965964, tf_edx = 1103, tf_ecx = -411, 
  tf_eax = 4, tf_trapno = 0, tf_err = 2, tf_eip = 672022312, tf_cs = 31, 
  tf_eflags = 663, tf_esp = -1077966048, tf_ss = 47})
at ../../../i386/i386/trap.c:1128
#11 0xc03cce0d in syscall_with_err_pushed ()

so apparently it was waiting on 'pcmwr'. 

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

Re: QT23 not building

[Pete Fritchman]

[ this is probably more appropriate for -ports ]

++ 21/08/01 02:21 +0200 - Salvo Bartolotta:
| I am using XFree4 and my /etc/make.conf contains the required XFree86 version 
| string.
| 
| opengl/qgl.h:63: GL/gl.h: No such file or directory
| opengl/qgl.h:64: GL/glu.h: No such file or directory

These are included in the Mesa port, and the qt23 port has a depend for
Mesa (USE_MESA= yes), but this is broken for XFree86 4.  See my PR at
http://www.freebsd.org/cgi/query-pr.cgi?pr=29546, I'm still waiting for
someone on portmgr@ to commit it.

-pete

--
Pete Fritchman <[EMAIL PROTECTED]>
Databits Network Services, Inc. 
finger [EMAIL PROTECTED] for PGP key

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

Re: Copyright Contradiction in libalias

[Crist J. Clark]

On Tue, Aug 21, 2001 at 02:10:42AM +0100, Brian Somers wrote:
> > +---[ Brian Somers ]--
> > | > Check with Charles to see if he really wants to abandon copyright claims
> > | > to his code, or whether he was really implying some really liberal open source 
> > | > license.
> > | 
> > | With the BSD Copyright (only) he keeps the intellectual copyright on 
> > | the original.  That's what I've changed it to (as per his agreement).
> > 
> > Oh, I thought he put in the comment to the effect it was in the Public Domain,
> > if you did that you're naughty! d8)
> > 
> > If he did that, he probably needs to rethink it.
> 
> He originally wrote it to say it was in the public domain.  I asked 
> him if he minded me making it a BSD license and he said ok only I 
> didn't do the whole job :*)

If you look at the history of the files, they were imported into
FreeBSD with the statement that they are public domain. I don't think
there is any way he can take that back and claim copyright over
them.

Now, as to whether anyone can now claim a copyright over the
contents since (not very substantial) changes have been made is
something for lawyers to settle. It is now written policy, and I
believe it was the understood, unwritten policy in the past, that any
patches and additions to a file in FreeBSD are governed by the
existing licensing of the file unless otherwise stated. This would
indicate to me that this file is arguably still public domain.

Again, IANAL. For now, as they stand, the licensing text within them
is contradictory and should be "fixed." As for whether it's getting
fixed the "right way" is something only a lawyer could answer, and I
really doubt anyone is ever going to care enough about these couple of
files to pay a lawyer to have a look.
-- 
Crist J. Clark   [EMAIL PROTECTED]

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

Re: Copyright Contradiction in libalias

[Brian Somers]

> +---[ Brian Somers ]--
> | > Check with Charles to see if he really wants to abandon copyright claims
> | > to his code, or whether he was really implying some really liberal open source 
> | > license.
> | 
> | With the BSD Copyright (only) he keeps the intellectual copyright on 
> | the original.  That's what I've changed it to (as per his agreement).
> 
> Oh, I thought he put in the comment to the effect it was in the Public Domain,
> if you did that you're naughty! d8)
> 
> If he did that, he probably needs to rethink it.

He originally wrote it to say it was in the public domain.  I asked 
him if he minded me making it a BSD license and he said ok only I 
didn't do the whole job :*)

> -- 
> Totally Holistic Enterprises Internet|  | Andrew Milton
> The Internet (Aust) Pty Ltd  |  |
> ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
> PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

-- 
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-current" in the body of the message

Re: Copyright Contradiction in libalias

[Andrew Kenneth Milton]

+---[ Brian Somers ]--
| > Check with Charles to see if he really wants to abandon copyright claims
| > to his code, or whether he was really implying some really liberal open source 
| > license.
| 
| With the BSD Copyright (only) he keeps the intellectual copyright on 
| the original.  That's what I've changed it to (as per his agreement).

Oh, I thought he put in the comment to the effect it was in the Public Domain,
if you did that you're naughty! d8)

If he did that, he probably needs to rethink it.

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

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

Re: Copyright Contradiction in libalias

[Brian Somers]

> Check with Charles to see if he really wants to abandon copyright claims
> to his code, or whether he was really implying some really liberal open source 
> license.

With the BSD Copyright (only) he keeps the intellectual copyright on 
the original.  That's what I've changed it to (as per his agreement).
-- 
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-current" in the body of the message

QT23 not building

[Salvo Bartolotta]

Dear FreeBSD'ers,

I am running -CURRENT as of August 18, 2001 -- yet another entry in the 
-current userbase, BTW.

I am using XFree4 and my /etc/make.conf contains the required XFree86 version 
string.

Qt23 will NOT build. It dies here:


gmake[2]: Leaving directory `/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/tools'
gmake[1]: Leaving directory `/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/tools'

The Qt library is now built in ./lib
The Qt examples are built in the directories in ./examples
The Qt tutorials are built in the directories in ./tutorial

Note: be sure to set $QTDIR to point to here or to wherever
  you move these directories.

Enjoy!   - the Trolltech team

(cd /usr/ports/x11-toolkits/qt23/work/qt-2.3.1/src && /usr/bin/env 
QTDIR=/usr/ports/x11-toolkits/qt23/work/qt-2.3.1 
LD_LIBRARY_PATH=/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/lib 
PORTOBJFORMAT=elf PREFIX=/usr/X11R6 LOCALBASE=/usr/local X11BASE=/usr/X11R6 
MOTIFLIB="-L/usr/X11R6/lib -lXm -lXp" LIBDIR="/usr/lib" CFLAGS="-O -pipe 
-march=pentiumpro" CXXFLAGS=" -O -pipe -march=pentiumpro" 
BSD_INSTALL_PROGRAM="install -c -s -o root -g wheel -m 555"  
BSD_INSTALL_SCRIPT="install -c -o root -g wheel -m 555"  
BSD_INSTALL_DATA="install -c -o root -g wheel -m 444"  
BSD_INSTALL_MAN="install -c -o root -g wheel -m 444" gmake -f Makefile  
opengl/qgl.o opengl/qgl_x11.o opengl/moc_qgl.o)
c++  -c -I/usr/X11R6/include 
-I/usr/ports/x11-toolkits/qt23/work/qt-2.3.1/include -pthread -D_THREAD_SAFE 
-I/usr/X11R6/include -DQT_PREFIX=\"/usr/X11R6\" -pipe -O -fno-exceptions  -O 
-pipe -march=pentiumpro -I/usr/include -D_PTH_H_ -D_PTH_PTHREAD_H_ 
-frerun-cse-after-loop -fPIC -DQT_BUILTIN_GIF_READER=1 -DQT_XFT 
-fno-exceptions  -I/usr/local/include  -o opengl/qgl.o opengl/qgl.cpp
In file included from opengl/qgl.cpp:38:
opengl/qgl.h:63: GL/gl.h: No such file or directory
opengl/qgl.h:64: GL/glu.h: No such file or directory
opengl/qgl.cpp: In method `void QGLWidget::glDraw()':
opengl/qgl.cpp:1604: `GL_FRONT_LEFT' undeclared (first use this function)
opengl/qgl.cpp:1604: (Each undeclared identifier is reported only once
opengl/qgl.cpp:1604: for each function it appears in.)
opengl/qgl.cpp:1604: implicit declaration of function `int glDrawBuffer(...)'
opengl/qgl.cpp:1616: implicit declaration of function `int glFlush(...)'
opengl/qgl.cpp: In method `void QGLWidget::qglColor(const QColor &) const':
opengl/qgl.cpp:1634: implicit declaration of function `int glColor3ub(...)'
opengl/qgl.cpp:1636: implicit declaration of function `int glIndexi(...)'
opengl/qgl.cpp: In method `void QGLWidget::qglClearColor(const QColor &) 
const':
opengl/qgl.cpp:1654: `GLfloat' undeclared (first use this function)
opengl/qgl.cpp:1654: syntax error before `.'
opengl/qgl.cpp:1659: confused by earlier errors, bailing out
gmake: *** [opengl/qgl.o] Error 1
*** Error code 2

Stop in /usr/ports/x11-toolkits/qt23.
*** Error code 1

Stop in /usr/ports/x11-toolkits/qt23.
*** Error code 1

Stop in /usr/ports/x11-toolkits/qt23.
*** Error code 1

Stop in /usr/ports/x11-toolkits/qt23.



The archives (-questions, -current, -ports) seem to contain other complaints. 

Is qt supposed to build with XFree86-4 under -CURRENT? What am I missing ?

-- Salvo (If I've missed something rivial, many apologies for the noise)

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

Re: Where to put new bus_dmamap_load_mbuf() code

[Bill Paul]

> 
> Another thing- maybe I'm confused- but I still don't see why you want to
> require the creating of a map each time you want to load an mbuf
> chain. Wouldn't it be better and more efficient to let the driver decide when
> and where the map is created and just use the common code for loads/unloads?

Every hear the phrase "you get what you pay for?" The API isn't all that
clear, and we don't have a man page or document that describes in detail
how to use it properly. Rather than whining about that, I decided to
tinker with it and Use The Source, Luke (tm). This is the result.

My understanding is that you need a dmamap for every buffer that you want
to map into bus space. Each mbuf has a single data buffer associated with
it (either the data area in the mbuf itself, or external storage). We're
not allowed to make assumptions about where these buffers are. Also, a
single ethernet frame can be fragmented across multiple mbufs in a list.

So unless I'm mistaken, for each mbuf in an mbuf list, what we
have to do is this:

- create a bus_dmamap_t for the data area in the mbuf using
  bus_dmamap_create()
- do the physical to bus mapping with bus_dmamap_load()
- call bus_dmamap_sync() as needed (might handle copying if bounce
  buffers are required)
- 
- do post-DMA sync as needed (again, might require bounce copying)
- call bus_dmamap_unload() to un-do the bus mapping (which might free
  bounce buffers if some were allocated by bus_dmamap_load())
- destroy the bus_dmamap_t

One memory region, one DMA map. It seems to me that you can't use a
single dmamap for multiple memory buffers, unless you make certain
assumptions about where in physical memory those buffers reside, and
I thought the idea of busdma was to provide a consistent, opaque API
so that you would not have to make any assumptions.

Now if I've gotten any of this wrong, please tell me how I should be
doing it. Remember to show all work. I don't give partial credit, nor
do I grade on a curve.

> > Yay!
> > 
> > The current suggestion is fine except that each platform might have a more
> > efficient, or even required, actual h/w mechanism for mapping mbufs.

It might, but right now, it doesn't. All I have to work with is the
existing API. I'm not here to stick my fingers in it and change it all
around. I just want to add a bit of code on top of it so that I don't
have to go through quite so many contortions when I use the API in
network adapter drivers.
 
> > I'd also be a little concerned with the way you're overloading stuff into mbuf
> > itself- but I'm a little shakier on this.

I thought about this. Like it says in the comments, at the device driver
level, you're almost never going to be using some of the pointers in the
mbuf header. On the RX side, *we* (i.e. the driver) are allocating the
mbufs, so we can do whatever the heck we want with them until such time
as we hand them off to ether_input(), and by then we will have put things
back the way they were. For the TX side, by the time we get the mbufs
off the send queue, we always know we're going to have just an mbuf list
(and not an mbuf chain), and we're going to toss the mbufs once we're done
with them, so we can trample on certain things that we know don't matter
to the OS or network stack anymore.

The alternatives are:

- Allocate some extra space in the DMA descriptor structures for the
  necessary bus_dmamap_t pointers. This is tricky with this particular
  NIC, and a little awkward.
- Allocate my own private arrays of bus_dmamap_t that mirror the DMA
  rings. This is yet more memory I need to allocate and free at device
  attach and detach time.

I've got space in the mbuf header. It's not being used. It's right
where I need it. Why not take advantage of it?

> > Finally- why not make this an inline?

Er... because that idea offended my delicate sensibilities? :)

-Bill

--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
 [EMAIL PROTECTED] | Wind River Systems
=
"I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
=

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

Re: Syntax change in ppp?

[Daniel Rock]

Brian Somers schrieb:
> 
> > Hi,
> >
> > after the latest updates I just noticed a different behaviour of ppp.
> >
> > in /etc/ppp/ppp.linkup I had an additional line
> >   iface clear
> > for my profile to get rid of stuffed up IP pairs. After the latest update
> > this entry also clears my defaultroute, but only after redialing.
> >
> > I now had to put the "iface clear" into /etc/ppp/ppp.linkdown, but then
> > the old IP pair is still there during the next connection.
> 
> Putting ``iface clear'' in ppp.linkup will result in the whole
> iface-alias thing being broken.  It's meant to be in ppp.linkdown.
> 
> The objective is that ppp, once connected, has two IP numbers on the
> interface, one for what was there before the connection completed and
> one for the negotiated IP address.  When this happens, the ``first
> connection'' continues to work (the process that caused the dial-up
> will be bound to the IP number that was on the interface when it
> started and the nat engine will tweak these packets so that they use
> the negotiated IP number).

Suppose on the first connection I got the IP pair
A <-> B
and on the second
C <-> D

while the second one still active another person will get
A <-> B
assigned by our ISP.

Will I be able to talk with A or B? Or will they point back to myself?
I put the "iface clear" in ppp.linkup for exactly this case.


> So really, you're doing the equivalent of ``disable iface-alias'' and
> stopping your first connection from working.  Moving the ``iface
> clear'' to ppp.linkdown should be better.
> 
> > Were my assumptions wrong (regarding the "iface clear" command) or is
> > something
> > broken in ppp?
> 
> Yes and yes.

Hmm, I didn't notice any problems before the last commit... Any automatic
connection (even the first) worked without any problems.
But: iface clear just went from ppp.linkdown to ppp.linkup some weeks
ago, but after I got DSL. With DSL the destination IP address is always
the same.
I don't know if this configuration would work with my old ISDN access with
changing destination IP addresses.



[...]
> 
> When IPCP comes up, ppp adds the new address to the interface.  It's
> *meant* to change the old interface destination address to
> 255.255.255.255, but is getting this wrong.  Then, as you've already
> spotted, when your ``iface clear'' is run, it blows away the default
> route.
> 
> I've just committed a fix for this.  It's in version 1.25 of iface.c.
> 
> > BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out
> > tons of messages
> > Error: iface_Add: socket(): Protocol not supported
> 
> Yep, a fix for that was committed a few days ago too.  My apologies.

Oh, I just discovered that cvsup didn't update my tree for 3 days.
Everything works ok again - even the things which weren't design
to work at all.


-- 
Daniel

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

Re: Where to put new bus_dmamap_load_mbuf() code

[Matthew Jacob]

Another thing- maybe I'm confused- but I still don't see why you want to
require the creating of a map each time you want to load an mbuf
chain. Wouldn't it be better and more efficient to let the driver decide when
and where the map is created and just use the common code for loads/unloads?

On Mon, 20 Aug 2001, Matthew Jacob wrote:

> 
> Yay!
> 
> The current suggestion is fine except that each platform might have a more
> efficient, or even required, actual h/w mechanism for mapping mbufs.
> 
> I'd also be a little concerned with the way you're overloading stuff into mbuf
> itself- but I'm a little shakier on this.
> 
> Finally- why not make this an inline?
> 
> -matt
> 
> 
> On Mon, 20 Aug 2001, Bill Paul wrote:
> 
> > Okay, I decided today to write a bus_dmamap_load_mbuf() routine to
> > make it a little easier to convert the PCI NIC drivers to use the
> > busdma API. It's not the same as the NetBSD code. There are four
> > new functions:
> > 
> > bus_dmamap_load_mbuf()
> > bus_dmamap_unload_mbuf()
> > bus_dmamap_sync_mbuf()
> > bus_dmamap_destroy_mbuf()
> > 
> > This is more or less in keeping with the existing API, except the new
> > routines work exclusively on mbuf lists. The thing I need to figure
> > out now is where to put the code. The current suggestion from jhb is
> > to create the following two new files:
> > 
> > sys/kern/kern_busdma.c
> > sys/sys/busdma.h
> > 
> > The functions are machine-independent, so they shouldn't be in
> > sys///busdma_machdep.c. I mean, they could go there, but
> > that would just result in code duplication. If somebody has a better
> > suggestion, now's the time to speak up. Please let's avoid creating
> > another bikeshed over this.
> > 
> > Current code snapshot resides at:
> > 
> > http://www.freebsd.org/~wpaul/busdma
> > 
> > There's also a modified version if the Adaptec "starfire" driver there
> > which uses the new routines. I'm running this version of the driver on
> > a test box in the lab right now.
> > 
> > -Bill
> > 
> > --
> > =
> > -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
> >  [EMAIL PROTECTED] | Wind River Systems
> > =
> > "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
> > =
> > 
> > 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-current" in the body of the message

Re: Where to put new bus_dmamap_load_mbuf() code

[Matthew Jacob]

Yay!

The current suggestion is fine except that each platform might have a more
efficient, or even required, actual h/w mechanism for mapping mbufs.

I'd also be a little concerned with the way you're overloading stuff into mbuf
itself- but I'm a little shakier on this.

Finally- why not make this an inline?

-matt


On Mon, 20 Aug 2001, Bill Paul wrote:

> Okay, I decided today to write a bus_dmamap_load_mbuf() routine to
> make it a little easier to convert the PCI NIC drivers to use the
> busdma API. It's not the same as the NetBSD code. There are four
> new functions:
> 
> bus_dmamap_load_mbuf()
> bus_dmamap_unload_mbuf()
> bus_dmamap_sync_mbuf()
> bus_dmamap_destroy_mbuf()
> 
> This is more or less in keeping with the existing API, except the new
> routines work exclusively on mbuf lists. The thing I need to figure
> out now is where to put the code. The current suggestion from jhb is
> to create the following two new files:
> 
> sys/kern/kern_busdma.c
> sys/sys/busdma.h
> 
> The functions are machine-independent, so they shouldn't be in
> sys///busdma_machdep.c. I mean, they could go there, but
> that would just result in code duplication. If somebody has a better
> suggestion, now's the time to speak up. Please let's avoid creating
> another bikeshed over this.
> 
> Current code snapshot resides at:
> 
> http://www.freebsd.org/~wpaul/busdma
> 
> There's also a modified version if the Adaptec "starfire" driver there
> which uses the new routines. I'm running this version of the driver on
> a test box in the lab right now.
> 
> -Bill
> 
> --
> =
> -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
>  [EMAIL PROTECTED] | Wind River Systems
> =
> "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
> =
> 
> 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-current" in the body of the message

Where to put new bus_dmamap_load_mbuf() code

[Bill Paul]

Okay, I decided today to write a bus_dmamap_load_mbuf() routine to
make it a little easier to convert the PCI NIC drivers to use the
busdma API. It's not the same as the NetBSD code. There are four
new functions:

bus_dmamap_load_mbuf()
bus_dmamap_unload_mbuf()
bus_dmamap_sync_mbuf()
bus_dmamap_destroy_mbuf()

This is more or less in keeping with the existing API, except the new
routines work exclusively on mbuf lists. The thing I need to figure
out now is where to put the code. The current suggestion from jhb is
to create the following two new files:

sys/kern/kern_busdma.c
sys/sys/busdma.h

The functions are machine-independent, so they shouldn't be in
sys///busdma_machdep.c. I mean, they could go there, but
that would just result in code duplication. If somebody has a better
suggestion, now's the time to speak up. Please let's avoid creating
another bikeshed over this.

Current code snapshot resides at:

http://www.freebsd.org/~wpaul/busdma

There's also a modified version if the Adaptec "starfire" driver there
which uses the new routines. I'm running this version of the driver on
a test box in the lab right now.

-Bill

--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
 [EMAIL PROTECTED] | Wind River Systems
=
"I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
=

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

Re: Copyright Contradiction in libalias

[Andrew Kenneth Milton]

+---[ Brian Somers ]--
| This is my fault.  Charles gave me permission to change these files 
| to a BSD license a while ago.  It looks like I got it wrong :-/
| 
| I'll fix it now.

Well since copyright was abandoned (being placed into the public domain is
abandonment of copyright), the changed file can be copyrighted by whomever 
makes changes. The new file is then covered by the license from that point
forward.

If Charles was the copyright holder and licensed them to you under a BSD 
license then the license still holds (but, not if they were already 
Public Domain, since you don't need permission if they're abandoned, and
Charles no longer holds copyright anyway). This is true even if they are 
subsequently released to the public domain, although Charles would probably 
have no recourse if you broke your license with him d8)

Charles probably didn't want to really put his code into the public domain, 
and as it seems Charles has licensed the code under a BSDL to us, the 
license in the file is correct.

Check with Charles to see if he really wants to abandon copyright claims
to his code, or whether he was really implying some really liberal open source 
license.

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

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

Re: Copyright Contradiction in libalias

[Brian Somers]

This is my fault.  Charles gave me permission to change these files 
to a BSD license a while ago.  It looks like I got it wrong :-/

I'll fix it now.

> I was doing some things in libalias when something caught my eye,
> 
>   $ cat alias.c
>   /* -*- mode: c; tab-width: 8; c-basic-indent: 4; -*- */
> 
>   /*-
>* Copyright (c) 2001 Charles Mott <[EMAIL PROTECTED]>
>* All rights reserved.
>*
>[snip usual BSD licence legalese and comments about the code.]
> 
>   This software is placed into the public domain with no restrictions
>   on its distribution.
> 
> This is contained in several files in there.
> 
> This is a contradiction. Public domain software can't also have
> copyright notices and a bunch of license disclaimers. The BSD-style
> copyright header was added back in June. You can't just take something
> in the public domain and slap a copyright on it, but IANAL.
> 
> Still, the comments in the code as written are self-contradictory. It
> can't have a BSD-license _and_ be public domain. And since again
> IANAL, I am not saying which needs to stay or which needs to go, but
> one of those statements does.
> -- 
> Crist J. Clark   [EMAIL PROTECTED]

-- 
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-current" in the body of the message

Re: Syntax change in ppp?

[Brian Somers]

> Brian Somers schrieb:
> > 
> > > Hi,
> > >
> > > after the latest updates I just noticed a different behaviour of ppp.
> > >
> > > in /etc/ppp/ppp.linkup I had an additional line
> > >   iface clear
> > > for my profile to get rid of stuffed up IP pairs. After the latest update
> > > this entry also clears my defaultroute, but only after redialing.
> > >
> > > I now had to put the "iface clear" into /etc/ppp/ppp.linkdown, but then
> > > the old IP pair is still there during the next connection.
> > 
> > Putting ``iface clear'' in ppp.linkup will result in the whole
> > iface-alias thing being broken.  It's meant to be in ppp.linkdown.
> > 
> > The objective is that ppp, once connected, has two IP numbers on the
> > interface, one for what was there before the connection completed and
> > one for the negotiated IP address.  When this happens, the ``first
> > connection'' continues to work (the process that caused the dial-up
> > will be bound to the IP number that was on the interface when it
> > started and the nat engine will tweak these packets so that they use
> > the negotiated IP number).
> 
> Suppose on the first connection I got the IP pair
> A <-> B
> and on the second
> C <-> D
> 
> while the second one still active another person will get
> A <-> B
> assigned by our ISP.
> 
> Will I be able to talk with A or B? Or will they point back to myself?
> I put the "iface clear" in ppp.linkup for exactly this case.

Say for example that you do ``set ifaddr A B'' and then 
``telnet X'' when the link is down.  telnet does a connect(X), 
resulting in a local binding to address A with a destination address 
of X.

ppp brings the link up and negotiates C <--> D, but keeps A <--> B on 
the interface.

The initial ``telnet X'' packet (A --> X) can now be transmitted, 
but ppp's alias address is now C.  It NATs the packet to C --> X and 
sends it out.  X gets it and sends a packet back to C.  Your ISP 
routes to C correctly and your ppp process unNATs it back to A.

Thus your ``first connection'' works when in reality it should not.

If you ``iface clear'' on linkup, ppp doesn't NAT the A --> X packet 
and X replies to A -- which your ISP (of course) can't route.

> > So really, you're doing the equivalent of ``disable iface-alias'' and
> > stopping your first connection from working.  Moving the ``iface
> > clear'' to ppp.linkdown should be better.
> > 
> > > Were my assumptions wrong (regarding the "iface clear" command) or is
> > > something
> > > broken in ppp?
> > 
> > Yes and yes.
> 
> Hmm, I didn't notice any problems before the last commit... Any automatic
> connection (even the first) worked without any problems.

That may be because most connections consist of a DNS lookup 
followed by the connect... but I'm not sure about that.

> But: iface clear just went from ppp.linkdown to ppp.linkup some weeks
> ago, but after I got DSL. With DSL the destination IP address is always
> the same.
> I don't know if this configuration would work with my old ISDN access with
> changing destination IP addresses.

It should work ok now.  Adding an interface address only needs to 
special-case things when either the source or destination addresses 
conflict with ones that are already assigned to the interface.

[.]
> -- 
> Daniel

-- 
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-current" in the body of the message

Copyright Contradiction in libalias

[Crist J. Clark]

I was doing some things in libalias when something caught my eye,

  $ cat alias.c
  /* -*- mode: c; tab-width: 8; c-basic-indent: 4; -*- */

  /*-
   * Copyright (c) 2001 Charles Mott <[EMAIL PROTECTED]>
   * All rights reserved.
   *
   [snip usual BSD licence legalese and comments about the code.]

  This software is placed into the public domain with no restrictions
  on its distribution.

This is contained in several files in there.

This is a contradiction. Public domain software can't also have
copyright notices and a bunch of license disclaimers. The BSD-style
copyright header was added back in June. You can't just take something
in the public domain and slap a copyright on it, but IANAL.

Still, the comments in the code as written are self-contradictory. It
can't have a BSD-license _and_ be public domain. And since again
IANAL, I am not saying which needs to stay or which needs to go, but
one of those statements does.
-- 
Crist J. Clark   [EMAIL PROTECTED]

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

Re: iso target in release/Makefile

[Jordan Hubbard]

From: "David O'Brien" <[EMAIL PROTECTED]>
Subject: Re: iso target in release/Makefile
Date: Mon, 20 Aug 2001 14:06:34 -0700

> It is part of a patch set I sent you for review.

And that patch looks good - please commit it and then merge the
resulting changes into RELENG_4 if you get the chance.  Thanks!

- Jordan

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

Re: iso target in release/Makefile

[David O'Brien]

On Mon, Aug 20, 2001 at 01:15:20PM -0700, Jordan Hubbard wrote:
> > You didn't MFC the iso.1 target.  We are all building releases on
> > RELENG_4 right now :-) (-current releases have been broken for quite a
> > while).  Thus my patch was developed on RELENG_4 and only committed to
> > current so I could as the RE about MFC'ing it.
> 
> Uh, no offense, but that explanation makes absolutely NO sense
> whatsoever!  If you'd developed something independently in RELENG_4
> and only considered it applicable to that branch, then it would NOT go
> into -current for obvious reasons, especially if it was a duplication
> of something already there.

Damned if you do, damned if you don't.  I've asked you about putting
stuff into RELENG_4 before and you said to put it in -current and then
immediately MFC it so people wouldn't complain that it didn't go thru
current.  (I also didn't consider it applicable only to that branch)


> What you'd do instead is either commit it
> only to RELENG_4 (and there is some precedent for that) or you'd ask
> for an MFC of the feature which was already in -current.

I didn't know about the feature in current (nor did those on the Alpha
list that were asking how to make ISOs).

> Please back this out, it's ugly and wrong.

It is part of a patch set I sent you for review.

-- 
-- David  ([EMAIL PROTECTED])

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

Re: iso target in release/Makefile

[Jordan Hubbard]

From: "David O'Brien" <[EMAIL PROTECTED]>
Subject: Re: iso target in release/Makefile
Date: Mon, 20 Aug 2001 11:43:16 -0700

> You didn't MFC the iso.1 target.  We are all building releases on
> RELENG_4 right now :-) (-current releases have been broken for quite a
> while).  Thus my patch was developed on RELENG_4 and only committed to
> current so I could as the RE about MFC'ing it.

Uh, no offense, but that explanation makes absolutely NO sense
whatsoever!  If you'd developed something independently in RELENG_4
and only considered it applicable to that branch, then it would NOT go
into -current for obvious reasons, especially if it was a duplication
of something already there.  What you'd do instead is either commit it
only to RELENG_4 (and there is some precedent for that) or you'd ask
for an MFC of the feature which was already in -current.

Please back this out, it's ugly and wrong.  Thanks!  I'll be happy
to MFC the pre-existing stuff if such is wanted.

- Jordan

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

Re: sharing disk between current and stable?

[Kris Kennaway]

On Mon, Aug 20, 2001 at 01:09:12PM -0400, Andrew Gallatin wrote:
> 
> Is it safe to share a disk between -current and -stable these days?
> 
> I've been away from freebsd for the last few months and have a fuzzy
> recollection that something about the on-disk superblock structure
> changed in -current earlier this summer (related to dirprefs?) and
> fsck on -stable wouldn't be able to fsck a fs used by current.
> 
> Is that still a problem?

When I reverted to -stable, I had fsck come up with a long list of
complaints about snapshot files which should have been deleted long
ago.  Probably they were caused by a failed background fsck under
-current (I had an unexpected softupdates inconsistency on the
partition due to a kernel panic, and background fsck would just wedge
the entire machine when trying to deal with it).  However, I don't
know why they weren't dealt with by fsck under -current.

Kris

 PGP signature

Re: devfs

[Kris Kennaway]

On Mon, Aug 20, 2001 at 08:02:44AM -0500, David W. Chapman Jr. wrote:
> On Mon, Aug 20, 2001 at 02:05:06AM -0400, Brandon D. Valentine wrote:
> > On Sun, 19 Aug 2001, Kris Kennaway wrote:
> > 
> > >Devices are just inodes..you shouldn't have anything in /dev other
> > >than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes.
> > >You probably have some other file in there which was accidentally
> > >created by something like
> > >
> > ># verbosecommand > /dev/nlul
> > 
> > The following command should reveal the culprit:
> > du -h /dev/* | grep -v 0B
> > 
> The only problem is devfs is mounted and I can't seem to get around 
> that.

Boot single-user.

Kris

 PGP signature

Re: iso target in release/Makefile

[David O'Brien]

On Sun, Aug 19, 2001 at 11:51:31PM -0700, Jordan Hubbard wrote:
> H.  I'm not sure why this reinvents a lot of the "wheel" in the
> already existing iso.1 target.  Could you explain its purpose a little
> better as well as why you didn't simply conditionalize the iso.1
> target in some way if it didn't currently suit?

You didn't MFC the iso.1 target.  We are all building releases on
RELENG_4 right now :-) (-current releases have been broken for quite a
while).  Thus my patch was developed on RELENG_4 and only committed to
current so I could as the RE about MFC'ing it.

-- 
-- David  ([EMAIL PROTECTED])

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

Re: Sound broken on -current again...

[John Baldwin]

On 19-Aug-01 Richard Todd wrote:
> In servalan.mailinglist.fbsd-current Maxim Sobolev writes:
>>I found that after reverting the following deltas (jhb's 10 August commit)
>>sound starts working again:
> 
> [list of deltas deleted]
> 
> I found much the same thing; specifically, the problematic change is this
> one:

What wait channel is the process (xmms, mpg123, whatever) in?

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: sharing disk between current and stable?

[David Wolfskill]

>From: Andrew Gallatin <[EMAIL PROTECTED]>
>Date: Mon, 20 Aug 2001 13:09:12 -0400 (EDT)

>Is it safe to share a disk between -current and -stable these days?

I've ben doing in since about the 2nd week of March, tracking -STABLE &
-CURRENT daily (with a few exceptions; sometimes I couldn't build
-CURRENT for as much as a day).

>I've been away from freebsd for the last few months and have a fuzzy
>recollection that something about the on-disk superblock structure
>changed in -current earlier this summer (related to dirprefs?) and
>fsck on -stable wouldn't be able to fsck a fs used by current.

>Is that still a problem?

It doesn't seem to be a problem for me.  YMMV; void where prohibited,
taxed, or otherwise restricted, etc.

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

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

Re: Sound broken on -current again...

[John Baldwin]

On 19-Aug-01 Maxim Sobolev wrote:
> On Sat, 18 Aug 2001 21:10:40 -0500, Daniel M . Kurry wrote:
>> On Wed, Aug 15, 2001 at 07:01:46PM +0200, some SMTP stream spewed forth: 
>> > 
>> > One gets the first DMA buffer full, then the process hangs...
>> 
>> Due to the lack of replies, I'll go ahead.
>> 
>> I am seeing sound breakage also.
>> My card is a 
>> Creative Labs SoundBlaster Live!.
>> 
>> xmms will play a short (less than a second) spurt of audio and then stop
>> responding. mpg123 will not play (any audio to the speakers) at all.
>> 
>> I ran a buildworld today which apparently broke it.
>> That puts the breakage between today and sometime less than 2 months
>> ago.
>> (I really cannot be more specific.)
>> 
>> Suggestions gladly welcomed.
>> 
>> 
>> > -Søren
> 
> The same is here (OPL3-SA driver on Toshiba Satellite Pro 445CDX notebook).
> I found that after reverting the following deltas (jhb's 10 August commit)
> sound starts working again:

That's a rather large commit.  Is this the ast() fixup?  Is the process that
has the sound device open hung?  Is it stuck in a wait channel?  If so, can you
do a ps and find the wait channel?  Is it chewing up large amounts of CPU time?
Has it exited with a signal?

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

sharing disk between current and stable?

[Andrew Gallatin]

Is it safe to share a disk between -current and -stable these days?

I've been away from freebsd for the last few months and have a fuzzy
recollection that something about the on-disk superblock structure
changed in -current earlier this summer (related to dirprefs?) and
fsck on -stable wouldn't be able to fsck a fs used by current.

Is that still a problem?

Thanks,

Drew

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

Re: devfs

[Matthew Jacob]

Hmm- this is because  init gets the 'd' argument if devfs is linked into the
kernel with the variable 'devfs_present' set.

Isn't there a way for the loader to dork with this?



On Mon, 20 Aug 2001, David W. Chapman Jr. wrote:

> On Mon, Aug 20, 2001 at 11:17:42AM -0400, Brandon D. Valentine wrote:
> > On Mon, 20 Aug 2001, David W. Chapman Jr. wrote:
> >
> > >The only problem is devfs is mounted and I can't seem to get around
> > >that.
> >
> > I haven't had much time lately to fool with my -CURRENT box but
> > it seems that booting singleuser oughta help?
> >
> Already tried that, still mounts devfs immediately.
> --
> David W. Chapman Jr.
> [EMAIL PROTECTED] Raintree Network Services, Inc. 
> [EMAIL PROTECTED] FreeBSD Committer 
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>


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

Re: devfs

[David W. Chapman Jr.]

On Mon, Aug 20, 2001 at 11:17:42AM -0400, Brandon D. Valentine wrote:
> On Mon, 20 Aug 2001, David W. Chapman Jr. wrote:
> 
> >The only problem is devfs is mounted and I can't seem to get around
> >that.
> 
> I haven't had much time lately to fool with my -CURRENT box but
> it seems that booting singleuser oughta help?
> 
Already tried that, still mounts devfs immediately.
-- 
David W. Chapman Jr.
[EMAIL PROTECTED]   Raintree Network Services, Inc. 
[EMAIL PROTECTED]   FreeBSD Committer 

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

Re: devfs

[Manfred Antar]

At 11:17 AM 8/20/2001 -0400, Brandon D. Valentine wrote:
>On Mon, 20 Aug 2001, David W. Chapman Jr. wrote:
>
>>The only problem is devfs is mounted and I can't seem to get around
>>that.
>
>I haven't had much time lately to fool with my -CURRENT box but
>it seems that booting singleuser oughta help?
>
>-- 
>"Never put off until tomorrow what you can do today.  There might be a
>law against it by that time."   -- /usr/games/fortune, 07/30/2001
>
>Brandon D. Valentine 
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message 

I couldn't do this from single user. I forget the error somthing about moving a mount 
point.
What worked for me was
to boot off the CDROM and go into the fixit mode then
mount the / partition on /mnt. cd /mnt/dev/
rm -r *

Manfred


==
||  [EMAIL PROTECTED]   ||
||  Ph. (415) 681-6235  ||
==


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

Re: devfs

[Brandon D. Valentine]

On Mon, 20 Aug 2001, David W. Chapman Jr. wrote:

>The only problem is devfs is mounted and I can't seem to get around
>that.

I haven't had much time lately to fool with my -CURRENT box but
it seems that booting singleuser oughta help?

-- 
"Never put off until tomorrow what you can do today.  There might be a
law against it by that time."   -- /usr/games/fortune, 07/30/2001

Brandon D. Valentine 


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

Implications of stdio changes (was Re: cvs commit: src/include stdio.h src/lib/libc Makefilesrc/lib)

[Stephen McKay]

On Tuesday, 14th August 2001, Daniel Eischen wrote:

>> > So do we allow FILE to be extended only after bumping the library
>> > version once (after 5.0-release)?  And thereafter all extensions to
>> > FILE do not need a version bump?
>> 
>> We've already bumped libc for 5.x.  Assuming this works ok, we shouldn't need
>> any further bumps for extending FILE.
>
>True.  I guess the real problem is the other libraries that reference
>stdin, stdout, stderr.  These need to be rebuilt with the new stdio.h
>and libc in order to avoid any impact from future FILE changes.

I might sound like the harbinger of doom, but you have to bump the major
number on every library that uses stdio to solve the "FILE has changed
size" problem.  It's the same sort of problem that changing errno caused.
That was "solved" by the switch to elf, which caused global recompilation.

People are hoping to do this by just waiting.  Eventually most libraries
will experience a major version bump.  Similarly, most useful programs will
be recompiled (either against bumped libraries, or recompiled old ones).
But some programs will not be recompiled, and will fail in mysterious ways.
I often use really old binaries, so odds are it will happen to me. :-)

To prevent old binaries from going bad, the libraries they link to must
use the old version of stdio.  Definite ideas of the offset in __sF of
stdout and stderr are embeded in both the old programs, and the old
libraries (and of course, the old version of stdio).  If you recompile
the libraries against the new stdio, you break the old binaries.  The
solution is to not do that.

In short, when FILE changes size (and hence __sF offsets change), then
every consumer(*) of stdio must be bumped.  The recent __stdinp (and friends)
addition prevents this problem happening again in the future, but does not
solve the current problem of old binaries and old libraries knowing the
internals of stdio.

Stephen.

(*) OK, technically only uses of "stdout" and "stderr" variables screw up
when FILE changes size.  Uses of macros (like getc variants that are
sometimes macros) will screw up if offsets change, but that's easier
to avoid.

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

Re: devfs

[David W. Chapman Jr.]

On Mon, Aug 20, 2001 at 02:05:06AM -0400, Brandon D. Valentine wrote:
> On Sun, 19 Aug 2001, Kris Kennaway wrote:
> 
> >Devices are just inodes..you shouldn't have anything in /dev other
> >than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes.
> >You probably have some other file in there which was accidentally
> >created by something like
> >
> ># verbosecommand > /dev/nlul
> 
> The following command should reveal the culprit:
> du -h /dev/* | grep -v 0B
> 
The only problem is devfs is mounted and I can't seem to get around 
that.

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

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

pam_unix: look and maybe commit bin/29897 please

[Ilmar S. Habibulin]

I was reading login.conf(5) and testing capabilities, when i found this
bug. And one-two more questions. How should i mark such reports in the
future?
Where can I find more info on named accounting limits on login.conf(5)
manpage? Maybe i would be able to implement them as PAM modules.




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

Re: Mailing list problem because of DNS

[Bernd Walter]

On Sat, Aug 18, 2001 at 05:18:55PM -0400, Buzz Megg wrote:
> I'm getting an error when attempting to send to [EMAIL PROTECTED] from an 
> address that used to work.
> 
> Has anything changed recently on the mailing list server?

Not that I know of.
But you should fix the named problem anyway:
ticso@cicely6# host -a 216.12.228.198
rcode = 3 (Non-existent domain), ancount=0
Host not found.
Exit 1

It looks like the complete 216.in-addr.arpa is not known by the root
servers - which is bad.
Your provider should contact ARIN to setup a functional reverse mapping.

>- Transcript of session follows -
> ... while talking to hub.freebsd.org.:
> >>>RCPT To:<[EMAIL PROTECTED]>
> <<< 450 Client host rejected: cannot find your hostname, [216.12.228.198]
> <[EMAIL PROTECTED]>... Deferred: 450 Client host rejected: cannot find 
> your
> hostname, [216.12.228.198]
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 5 days old

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

Re: Syntax change in ppp?

[Brian Somers]

> Hi,
> 
> after the latest updates I just noticed a different behaviour of ppp.
> 
> in /etc/ppp/ppp.linkup I had an additional line
>   iface clear
> for my profile to get rid of stuffed up IP pairs. After the latest update
> this entry also clears my defaultroute, but only after redialing.
> 
> I now had to put the "iface clear" into /etc/ppp/ppp.linkdown, but then
> the old IP pair is still there during the next connection.

Putting ``iface clear'' in ppp.linkup will result in the whole 
iface-alias thing being broken.  It's meant to be in ppp.linkdown.

The objective is that ppp, once connected, has two IP numbers on the 
interface, one for what was there before the connection completed and 
one for the negotiated IP address.  When this happens, the ``first 
connection'' continues to work (the process that caused the dial-up 
will be bound to the IP number that was on the interface when it 
started and the nat engine will tweak these packets so that they use 
the negotiated IP number).

So really, you're doing the equivalent of ``disable iface-alias'' and 
stopping your first connection from working.  Moving the ``iface 
clear'' to ppp.linkdown should be better.

> Were my assumptions wrong (regarding the "iface clear" command) or is
> something
> broken in ppp?

Yes and yes.

> I have an idea which might cause the accidential removal of the defaultroute
> after redialing:
> 
> Before the first connection I have to set a dummy IP pair:
>   set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0
> so my defaulroute will be set to 172.23.11.2
> 
> After dialing I'm getting a different destination IP address from my provider,
> and
> the old route will be deleted:
> route del $OLDADDR
> But after that, even if my own address will be different, the destination
> address will be the same:
> tun0: flags=8051 mtu 1492
> inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 
> inet 217.224.28.71 --> 217.5.98.90 netmask 0x 
> inet 217.224.27.153 --> 217.5.98.90 netmask 0x 
> so after executing "iface clear" from /etc/ppp/ppp.linkup, ppp will also
> delete
> the old route - but this time the old route is the same as the current one.

When IPCP comes up, ppp adds the new address to the interface.  It's 
*meant* to change the old interface destination address to 
255.255.255.255, but is getting this wrong.  Then, as you've already 
spotted, when your ``iface clear'' is run, it blows away the default 
route.

I've just committed a fix for this.  It's in version 1.25 of iface.c.

> BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out
> tons of messages
> Error: iface_Add: socket(): Protocol not supported 

Yep, a fix for that was committed a few days ago too.  My apologies.

> Daniel

-- 
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-current" in the body of the message

Disk I/O problems with -current.

[Josef Karthauser]

I'm having strange problems with -current on a laptop with 64mb of
memory.  Periodically "things go strange" [tm].

Because of the lack of memory I'm using a fair amount of swap.

Everything runs smoothly up until a point, which seems to depend upon
not running too many large processes for too long.  Then the file system
grinds to a halt for seconds at a time.  Some processes run, and others
just hang.

Here's a snapshot from top:

last pid:  1861;  load averages:  1.58,  1.63,  1.26up 0+00:43:56  09:58:09
39 processes:  1 running, 38 sleeping
CPU states:  1.2% user,  0.0% nice,  8.1% system,  5.8% interrupt, 84.9% idle
Mem: 14M Active, 2712K Inact, 21M Wired, 1460K Cache, 14M Buf, 20M Free
Swap: 512M Total, 16M Used, 496M Free, 3% Inuse

  PID USERNAME PRI NICE   SIZERES STATETIME   WCPUCPU COMMAND
  594 root  960 23300K 10784K select   0:12  0.00%  0.00% XFree86
 1731 joe   -80  6056K  3352K biowr0:14  5.08%  5.08% vim
  691 joe   960  4092K  1804K select   0:02  0.00%  0.00% wmaker
 1719 joe80  3340K  1864K wait 0:00  0.00%  0.00% mutt
  658 root   80  2964K   908K wait 0:00  0.00%  0.00% xdm
  591 root  200  2800K   632K pause0:00  0.00%  0.00% xdm
  279 root  960  2364K   480K select   0:00  0.00%  0.00% sshd
  724 joe80  2324K   740K nanslp   0:01  0.00%  0.00% wmCalClock
 1209 joe   960  2292K  1168K select   0:01  0.10%  0.10% rxvt
 1716 joe   960  2256K  1348K select   0:00  0.00%  0.00% rxvt
 1214 joe   200  2088K  1188K pause0:00  0.00%  0.00% zsh
  725 joe80  2060K   824K nanslp   0:10  0.00%  0.00% wmtop
 1401 joe   960  2028K   888K RUN  0:02  0.00%  0.00% top
 1812 joe  -120  2012K   768K inode0:01  0.00%  0.00% rxvt
  700 joe80  1988K   840K nanslp   0:00  0.00%  0.00% xautolock
  701 joe   960  1828K   492K select   0:00  0.00%  0.00% ssh-agent
  253 root  84  -12  1388K   564K select   0:00  0.00%  0.00% ntpd
 1779 root  960  1232K   760K select   0:00  0.00%  0.00% local
 1777 postfix   960  1228K   820K select   0:00  0.00%  0.00% smtpd
  649 postfix   960  1204K   656K select   0:01  0.00%  0.00% qmgr
 1778 postfix   960  1196K   760K select   0:00  0.00%  0.00% cleanup
  271 root  960  1184K   416K select   0:00  0.00%  0.00% inetd
 1700 postfix   960  1152K   676K select   0:00  0.00%  0.00% trivial-rewri
  648 root  960  1144K   496K select   0:00  0.00%  0.00% pickup
  647 root  960  1120K   528K select   0:00  0.00%  0.00% master
  273 root   80  1108K   548K nanslp   0:00  0.00%  0.00% cron
  276 root  960  1076K   388K select   0:00  0.00%  0.00% lpd
  583 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  588 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  585 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  590 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  586 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  587 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  589 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  584 root   50  1064K   396K ttyin0:00  0.00%  0.00% getty
  243 root  960  1060K   492K select   0:00  0.00%  0.00% syslogd
  341 root  960  1024K   388K select   0:00  0.00%  0.00% usbd
  397 root  960  1020K   400K select   0:03  0.00%  0.00% moused
 1730 joe80   816K   156K wait 0:00  0.00%  0.00% sh

The vim process (pid=1731) was waiting in biowr for about a minute when
I took this snapshot.  I'd ZZ'd it, but instead of writing it's file, it
just blocked instead.

Interestingly take a look at the disk i/o irqs:


2 usersLoad  1.21  1.49  1.24  Aug 20 09:59

Mem:KBREALVIRTUAL VN PAGER  SWAP PAGER
Tot   Share  TotShareFree in  out in  out
Act8368164829620 2824   21312 count
All   404721952  2567408 4908 pages
 Interrupts
Proc:r  p  d  s  wCsw  Trp  Sys  Int  Sof  Fltcow1966 total
   2 10  7194   15 1038 2031   13   17  21612 wirestray irq0
14404 act stray irq6
 7.5%Sys   5.3%Intr  1.2%User  0.0%Nice 86.0%Idl 2984 inact   acpi0 irq9
||||||||||   1472 cache  1697 ata0 irq14
++> 19840 freeata1 irq15
  daefr   uhci0 irq5
Namei Name-cacheDir-cache prcfr 1 pcm0 irq5
Calls hits% hits% react   atkbd0 irq
  504  5

Re: Sound broken on -current again...

[Maxim Sobolev]

"SÜren Schmidt" wrote:

> It seems Jim Bryant wrote:
> > >Yups, reverting this, even in a newer kernel makes sound work again,
> > >well the VIA support is still not sounding proberly, but it didn't
> > >before as well so thats not related to this bogon...
> > >
> > Perhaps the bug in the chipset^wPCI-spec?
> > 
> > >>>I dont think so, before the latest changes it worked just fine...
> > >>>
> > >>What's the problem? I didn't noticed anything.
> > >>
> > > It seems that there is either a slight pause, or random noise
> > > between each DMA buffer played...
> > >
> > > -SÜren
> >
> > Was this chipset or motherboard-dependant?
>
> That particualar problem is dependend on the VIA 82c686[ab] I'd say,
> but having no other sound HW right now, I really cant tell, I think
> I've seen other sound HW with this problem too lately on the lists...
>
> > Like I said, I had no problems running SMP and with a SB/Live!-Value...
> >
> > Current as of yesterday morning [6-7AMish CDT], Tyan S1696DLUA motherboard, 2 
>Pentium-II/333's, SB/Live! Value card. Did not produce
> > thse issues.
>
> I'm pretty sure the problem with no sound due to jhb's commit mentioned
> earlier hoses more than just the VIA chips...

Yes, as I reported my OPL3-SA sound card was also affected by the same commit,
so it is certainly not a VIA-specific.

-Maxim



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

Syntax change in ppp?

[Daniel Rock]

Hi,

after the latest updates I just noticed a different behaviour of ppp.

in /etc/ppp/ppp.linkup I had an additional line
  iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my defaultroute, but only after redialing.

I now had to put the "iface clear" into /etc/ppp/ppp.linkdown, but then
the old IP pair is still there during the next connection.


Were my assumptions wrong (regarding the "iface clear" command) or is
something
broken in ppp?


I have an idea which might cause the accidential removal of the defaultroute
after redialing:

Before the first connection I have to set a dummy IP pair:
  set ifaddr 172.23.11.1/0 172.23.11.2/0 255.255.255.255 0.0.0.0
so my defaulroute will be set to 172.23.11.2

After dialing I'm getting a different destination IP address from my provider,
and
the old route will be deleted:
route del $OLDADDR
But after that, even if my own address will be different, the destination
address will be the same:
tun0: flags=8051 mtu 1492
inet6 fe80::2e0:7dff:fe75:fdfb%tun0 prefixlen 64 scopeid 0x6 
inet 217.224.28.71 --> 217.5.98.90 netmask 0x 
inet 217.224.27.153 --> 217.5.98.90 netmask 0x 
so after executing "iface clear" from /etc/ppp/ppp.linkup, ppp will also
delete
the old route - but this time the old route is the same as the current one.


BTW: If I disable IPv6 in the kernel, ppp won't start at all. It will spit out
tons of messages
Error: iface_Add: socket(): Protocol not supported 




Daniel

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

Re: Sound broken on -current again...

[Alexander Leidinger]

On 19 Aug, Søren Schmidt wrote:

>> What's the problem? I didn't noticed anything.
> 
> It seems that there is either a slight pause, or random noise
> between each DMA buffer played...

Verry strange... with a normal Aug 18 kernel and the VIA chipset I'm
able to listen to xmms-played audio without noticing anything I didn't
like (except there slipped in a song into the playlist I didn't like
;-)).

Bye,
Alexander.

-- 
  Loose bits sink chips.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


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

Re: Sound broken on -current again...

[Søren Schmidt]

It seems Jim Bryant wrote:
> >Yups, reverting this, even in a newer kernel makes sound work again,
> >well the VIA support is still not sounding proberly, but it didn't
> >before as well so thats not related to this bogon...
> >
> Perhaps the bug in the chipset^wPCI-spec?
> 
> >>>I dont think so, before the latest changes it worked just fine...
> >>>
> >>What's the problem? I didn't noticed anything.
> >>
> > It seems that there is either a slight pause, or random noise
> > between each DMA buffer played...
> > 
> > -Søren
> 
> Was this chipset or motherboard-dependant?

That particualar problem is dependend on the VIA 82c686[ab] I'd say, 
but having no other sound HW right now, I really cant tell, I think
I've seen other sound HW with this problem too lately on the lists...

> Like I said, I had no problems running SMP and with a SB/Live!-Value...
> 
> Current as of yesterday morning [6-7AMish CDT], Tyan S1696DLUA motherboard, 2 
>Pentium-II/333's, SB/Live! Value card. Did not produce 
> thse issues.

I'm pretty sure the problem with no sound due to jhb's commit mentioned
earlier hoses more than just the VIA chips...

-Søren

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

Re: no new snapshotonftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/

[Makoto MATSUSHITA]

wosch> Sorry, my fault.

Never mind :-)

wosch> Nevertheless, current sucks. No successfully builds since 9 days ;-{{

I've checked the original CVS code. It seems that

http://ccvs.cvshome.org/source/browse/ccvs/src/client.c.diff?r1=1.302&r2=1.303>

will fix our problem (sorry I don't test it).

-- -
Makoto `MAR' MATSUSHITA

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

Re: libss termination

[NAKAJI Hiroyuki]

> In <[EMAIL PROTECTED]> 
>   Kris Kennaway <[EMAIL PROTECTED]> wrote:

nakaji> Usr.bin/mk_cmds is still using libss. And buildworld fails.
Kris> Thanks; I fixed this already (by removing mk_cmds too :-)

Oops...

I should have checked
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.bin/mk_cmds/
first.

Thanks.
-- 
NAKAJI Hiroyuki

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

Re: libss termination

[Kris Kennaway]

On Mon, Aug 20, 2001 at 04:28:07PM +0900, NAKAJI Hiroyuki wrote:
> > Mark Murray <[EMAIL PROTECTED]> wrote:
> MM> > > 
> MM> > > As far as I can tell, there's nothing in the tree which uses libss any
> MM> > > longer, and hasnt been for quite some time.  Is there any reason to
> MM> > > keep it?
> MM> > 
> MM> > Nope.
> 
> MM> Right. Kill it.
> 
> Usr.bin/mk_cmds is still using libss. And buildworld fails.

Thanks; I fixed this already (by removing mk_cmds too :-)

Kris

 PGP signature

Re: libss termination

[NAKAJI Hiroyuki]

>   Mark Murray <[EMAIL PROTECTED]> wrote:
MM> > > 
MM> > > As far as I can tell, there's nothing in the tree which uses libss any
MM> > > longer, and hasnt been for quite some time.  Is there any reason to
MM> > > keep it?
MM> > 
MM> > Nope.

MM> Right. Kill it.

Usr.bin/mk_cmds is still using libss. And buildworld fails.

===> usr.bin/mk_cmds
yacc -d /usr/src/usr.bin/mk_cmds/ct.y
cp y.tab.c ct.c
lex -t -l /usr/src/usr.bin/mk_cmds/cmd_tbl.l > cmd_tbl.c
rm -f .depend
mkdep -f .depend -a   -nostdinc -I. -I/usr/src/usr.bin/mk_cmds/../../lib/libss 
-DIN_MK_CMDS -I/usr/obj/usr/src/i386/usr/include  /usr/src/usr.bin/mk_cmds/mk_cmds.c 
/usr/src/usr.bin/mk_cmds/options.c /usr/src/usr.bin/mk_cmds/utils.c ct.c cmd_tbl.c
/usr/src/usr.bin/mk_cmds/mk_cmds.c:16: ss_internal.h: No such file or directory
/usr/src/usr.bin/mk_cmds/options.c:8: ss.h: No such file or directory
/usr/src/usr.bin/mk_cmds/utils.c:9: ss_internal.h: No such file or directory
/usr/src/usr.bin/mk_cmds/ct.y:30: ss.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /usr/src/usr.bin/mk_cmds.
-- 
NAKAJI Hiroyuki

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