DVD driver

[Anthony Kimball]

Quoth Kenneth Wayne Culver on Mon, 27 December:
: I don't have a hardware decoder the software one looks fine but I'd like to
: know if anyone has tried to make a software decoder for FreeBSD. Thanks..

(I'll redirect to multimedia.)

I've been trying to build the nist mpeg2player on current lately.
It was reported to be working in late October, but I'm not having any
luck at the moment because of failures in static initializers in the
Regex package -- probably something to do with pthreads, and very
much non-trivial to debug, given my vanishingly small understanding
of the ever-changing thread model on CURRENT.



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

Re: Problem with PAM-AUTH for XFree86?

[Mark Murray]

> I just got my box up and running Current 12-27.  ATA works great for =
> both drives now.  However, I compiled XFree86 from the port and I chose =
> the options for RPC, Wraphelp.c, PAM and threads.  When I start x (using =
> startkde), I get many many password prompts.  I can only assume that the =
> PAM module used for athentication by XFree86 is broken.  Is the owner =
> aware of this?
> 
> I recompiled without PAM support and everything works as expected.

Is your /etc/* up to date? Specifically /etc/pam.conf?

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


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

Re: Problem with PAM-AUTH for XFree86?

[Clive Lin]

On Mon, Dec 27, 1999 at 11:01:50PM -0600, Thomas T. Veldhouse wrote:
> Hello,
> 
> I just got my box up and running Current 12-27.  ATA works great for both drives 
>now.  However, I compiled XFree86 from the port and I chose the options for RPC, 
>Wraphelp.c, PAM and threads.  When I start x (using startkde), I get many many 
>password prompts.  I can only assume that the PAM module used for athentication by 
>XFree86 is broken.  Is the owner aware of this?
> 
> I recompiled without PAM support and everything works as expected.
> 
Hi!
I dunno if this is tooo tricky, but I added a single line to solved the
same question as yours. the xserver line...

X clive@cartier ~> tail -5 /etc/pam.conf
# tricky tricky forgive me
xserver authsufficient  pam_permit.so   no_use
# If we don't match anything else, default to using getpwnam().
other   authrequiredpam_unix.so try_first_pass
other   account requiredpam_unix.so try_first_pass
X clive@cartier ~>

-- 
CirX 
Clive Lin <[EMAIL PROTECTED]>

FreeBSD - The Power to Serve 


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

Re: IPFW

[Steve O'Hara-Smith]

On 27-Dec-99 Emre wrote:
> Actually I haven't tried -release or -stable...I'm willing
> to take the chance.

I think you will find that you are taking much more of a chance with
-current than with -stable. After all -current is allowed to break sometimes,
-stable only does it by accident.



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

Re: Make world documentation

[Brooks Davis]

On Mon, Dec 27, 1999 at 11:23:21PM -0600, Kevin Entringer wrote:
> Recently someone posted a url that provided a quick run through on some
> important extra steps to take while doing a make world from -STABLE to
> -CURRENT, unfortunatly I lost the URL.  I was wondering if someone could
> post it again?  I did check the archives, but I wasn't able to find it. 

http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html

Though I though it was supposed to have been moved to the main site, but
that's what http://www.freebsd.org/tutorials/ says.

-- Brooks

P.S. This belonged on -questions.

-- 
"Those who desire to give up freedom in order to gain security, will not
have, nor do they deserve, either one"
   --Thomas Jefferson 


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

Make world documentation

[Kevin Entringer]

Recently someone posted a url that provided a quick run through on some
important extra steps to take while doing a make world from -STABLE to
-CURRENT, unfortunatly I lost the URL.  I was wondering if someone could
post it again?  I did check the archives, but I wasn't able to find it. 
Thanks.

Regards, Kevin.



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

Problem with PAM-AUTH for XFree86?

[Thomas T. Veldhouse]

Hello,

I just got my box up and running Current 12-27.  ATA works great for
both drives now.  However, I compiled XFree86 from the port and I chose the
options for RPC, Wraphelp.c, PAM and threads.  When I start x (using
startkde), I get many many password prompts.  I can only assume that the PAM
module used for athentication by XFree86 is broken.  Is the owner aware of
this?

I recompiled without PAM support and everything works as expected.

Tom Veldhouse
[EMAIL PROTECTED]



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

Problem with PAM-AUTH for XFree86?

[Thomas T. Veldhouse]

Hello,
 
    I just got my box up and running 
Current 12-27.  ATA works great for both drives now.  However, I 
compiled XFree86 from the port and I chose the options for RPC, Wraphelp.c, PAM 
and threads.  When I start x (using startkde), I get many many password 
prompts.  I can only assume that the PAM module used for athentication by 
XFree86 is broken.  Is the owner aware of this?
 
    I recompiled without PAM support 
and everything works as expected.
 
Tom Veldhouse
[EMAIL PROTECTED]

DVD driver

[Kenneth Wayne Culver]

I noticed recently (10 minutes ago) that FreeBSD will mount a DVD and I
can even look around on it as if it were a regular CD (on -CURRENT). I was
wondering if there was any mpeg2 decoder that would play DVD movies. I
don't have a hardware decoder the software one looks fine but I'd like to
know if anyone has tried to make a software decoder for FreeBSD. Thanks..


=
| Kenneth Culver  | FreeBSD: The best OS around.|
| Unix Systems Administrator  | ICQ #: 24767726 |
| and student at The  | AIM: AgRSkaterq |
| The University of Maryland, | Website: (Under Construction)   |
| College Park.   | http://www.wam.umd.edu/~culverk/|
=



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

Re: Proposed patch to fix VN device (again)

[Kip Macy]

> This is unwontedly personal and has no place in a public mailing list.
> Please keep your replies confined to technical content (or your
> concerns about the lack thereof) and keep always in mind that getting
> emotional serves only to generate heat when what's needed is light.
> 
> - Jordan

And it undermines even the strongest of technical arguments.

-Kip




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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:
:Matthew Dillon wrote:
:[..]
:> And, in anycase, I am not going to spend hours putting together a long 
:> involved patch when a simple short patch suffices.  If you want to
:> spend the time to come up with your own patch (that doesn't screw the
:> pooch in regards to cluster performance!), then I'm all ears, otherwise
:> this patch is what is going to go in for the 4.0 release.
:
:Please hold fire for a bit longer.  I have (what I think is) a much cleaner
:fix in mind.  There is no urgency here, a couple of hours isn't going to
:make the slightest difference to the big picture.
:
:On a side note, as the original author of the changes that lead to this, I
:would have thought it would have been appropriate to ask ME directly first
:before going public.
:
:Cheers,
:-Peter

Your fix looks pretty good, Peter.  I'll run it in and test it.  I only
wish you had come up with it before Poul started going off the deep end.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Proposed patch to fix VN device (again)

[Peter Wemm]

Peter Wemm wrote:
> David Greenman wrote:
> >I've heard from both of you that you think the other is wrong. This isn'
t
> > very helpful, however, in finding the correct solution. What I'd like to he
ar
> > from both of you is the reasons why swap is better as a device, or not. The
re
> > seems to be some unstated architectural philosophy that needs to be stated
> > before any informed decision can be made about what is the right direction 
to
> > go in.
> 
> The problem is that swapdev_vp needs to handle VOP_STRATEGY(), and swapdev_vp
> is incorrectly being pointed at spec_vnops.  Here is a proposed (UNTESTED!)
> clean fix:

This is missing a vop_default entry, so it will panic.  But as a proof of
concept it still stands.

Cheers,
-Peter




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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

   It makes no sense whatsoever to spend hours or days reworking a major
   subsystem *just* so the swap device can do without a dev_t.  I don't
   really give a damn about /dev/drum -- I said before and I will say again
   that we can leave it out.  But we need to give the swap device its's
   dev_t back to fix VN because no matter what you believe the *right*
   thing is to do, (A) nobody has time to rework a major subsystem at this
   time, and (B) VN was broken when the dev_t was removed, the dev_t should
   be added back in until someone comes up with a better overall solution.

   I also strongly believe that polluting *OTHER* subsystems (the buffer
   chaining code) just to avoid creating a dev_t for SWAP makes even less 
   sense.

   I do not have the inclination to spend huge amounts of my time reworking 
   the VOP or filesystem buffer subsystem because someone isn't willing to
   spend a tiny amount of code to partially back out a patch that broke 
   something (VN) in the system, that someone also not themselves willing 
   to spend the time required to rework the system properly.  It's that
   simple.  It makes no sense to impose such a requirement on someone else
   to fix a problem that they did not create.

   Now I would like to make a clarification:  The commit we are talking
   about was actually one Peter did with the approval of everyone, including
   me.  At the end of November.However, nobody including me realized that
   the second part of his commit, which was an optimization to remove the
   'cruft' of the SWAP device, broke VN.  If we had known then that this
   optimization would break VN it would *NOT* have gone in until the VN 
   problem was fixed.

-Matt




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

Re: Proposed patch to fix VN device (again)

[Jordan K. Hubbard]

> Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not
> reply to any of my postings.  Not a single one, because I am wholely
> sick and tired of your superiority complex.  This thread was not meant

This is unwontedly personal and has no place in a public mailing list.
Please keep your replies confined to technical content (or your
concerns about the lack thereof) and keep always in mind that getting
emotional serves only to generate heat when what's needed is light.

- Jordan


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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, David Greenman writes:

>There
>seems to be some unstated architectural philosophy that needs to be stated
>before any informed decision can be made about what is the right direction to
>go in.

The underlying problem is of course that struct buf is a conglomerate
of "struct block_cache" and "struct io_request", and in the cases
where you need only the latter functionality you still have to
respect all the conventions of the former.  This issue leads to
complexity and hacks in all code that needs to splite a io operation:
vinum, ccd, swap_pager and disk_slice/label.

For this reason the swap-pager has a bogus vnode: (swapdev_vp) to
hang buffers from.  This vnode even more bogusly uses spec_vnodeop_p
for its vop[], and at the far end of that vop[] it used to abuse
/dev/drum to get things done.

If we want to maintain the presently unused generality of the
chainbuf routines (they are currently only used in the swap-pager),
then the fix is to add a real vop[] to the bogus swapdev_vp so that
VOP_STRATEGY correctly end up in swstrategy() for swap device
buffers.

If we accept that the chainbuf routines are of limited utility, we
can simply s/VOP_STRATEGY/swstrategy/ in the flushchain procedure.

The reason why /dev/drum should not be brought back is that it
isn't a device and it shouldn't be made one.  In particular it
should not made one to paste over a bogus vnode, that would be a
step backwards.

If we want to *really* fix the problem, we should introduce a bop[]
function vector on struct buf.  Kirk already (almost) did this:
struct bio_ops.  This bop[] would be where code would find the
strategy, bwrite* and other operations on the buffer without knowing
if the buffer has a dev_t, a dev_t + a vnode, only a vnode or
neither associated with it.  This fix is out of scope for the
present problem, and certainly not a 4.0 item.  This fix will be
needed before we can put a non-device backed storage layer under
UFS.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:
:   I've heard from both of you that you think the other is wrong. This isn't
:very helpful, however, in finding the correct solution. What I'd like to hear
:from both of you is the reasons why swap is better as a device, or not. There
:seems to be some unstated architectural philosophy that needs to be stated
:before any informed decision can be made about what is the right direction to
:go in.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org

Ok, I'll buy that.  Though I will note that VN has been broken for over
a month - I found that out about half a month ago and posted the fact,
and if Poul is so interested in fixing it he could easily have done so
then.  I'm the one who has spent all the time tracking it down, patching,
and testing it, and frankly that should count for a hellofalot more then
nil.  Poul frankly does not have a leg to stand on to demand that I work
on a 'better' solution when I didn't cause the problem in the first place,
nor does he have any right to pollute the VM code to end-run around the
issue.  It would be tragic if Poul's behavior were allowed to conclude
the matter.

That said, here is my position, split into a 'history' and my 'reasoning':

Previously we had /dev/drum, which didn't work, and the
SWAP device was layered around a device and swap I/O was vectored through
the device subsystem.  

One month ago, after discussions, Peter Wemm removed the userland frontend
for the swap device, /dev/drum, and at the same time thought it would be
a good idea to collapse the VOP_STRATEGY routines (that ran through the
SWAP dev_t) into direct calls to swstrategy().  At the time I was
ambivalent but since the change seemed to clear out a bunch of cruft I
went with it.

However, this broke the VN device.  I found this out about half a month
later (around half a month ago) but at the time was hip deep in NFS work
for the 3.4 release and could not address the issue.  Now that the NFS
work is finished I revisited the now broken VN device to determine what
went wrong.  It turns out that the VN device indirectly runs through the
swap device using several generic filesystem buffer related subsystems.
When the swap dev_t was removed, the result was a panic.

-

The VN device uses vm_pager_strategy() to implement swap backing store.
vm_pager_strategy() is a generic mechanism that I introduced into the VM
system a number of months ago for two reasons:

(1) As a sounding board for giving the vm_pager_*() functions a
strategy entry point, to see how well it would work.

(2) To implement the swap backing store feature for the VN device.

vm_pager_strategy() in turn looks at the pager ID and does a table lookup
call through to the swap_pager_strategy() function.  This function takes
a VM object and a *generic* bp.  While the function itself is
swap-specific, the design of the code is supposed to be as generic as
possible.

vm_pager_strategy() may need to cut up the bp into subrequests to deal
with clustering issues.  It uses the generic 'chainbuf' routines to
manage the asynchronous I/O.

The 'chainbuf' routines are designed to be as generic as possible.. they
take BP's.  They do *NOT* and are not intended to be special cased in
any way.  This is my design for these routines, and even though they
are currently used only by the swap_pager_strategy() code I believe the
generic nature of the routines must be maintained.

I/O sequencing for the swap-backed VN device is thus:  
VN->vm_pager_strategy->chainbuf->STRATEGY.

I advocate that the best solution is to simply undo part of the original
commit and restore SWAP's dev_t which was removed a month ago.  Poul's
solution is considerably more complicated (the patch he offered will not
work in all cases, and I've already corrected all his other misstatements
that I do not really feel it appropriate to continue to correct his
misstatements when all he does with those corrections is use them as
a poolboard to make his next set of incorrect statements!).

I will tell you why Poul's patch will not work, but I am NOT going to
tell Poul because, damn it, he has no right to spend 5 minutes working
up a shoddy patch and then try to dictate to me that it should be used
over my well tested 8-hours-of-work patch!

Poul's patch will not work because flushchainbuf() is not the only chain
routine that flushes the buffers.  getchainbuf() and waitchainbuf() may 
*also* flush the buffers if there are already too many chain buffers
built up in the linked list.  Poul only addressed flushchainbuf().  
He obviously didn't bother to read the code carefully and he just
as obviously doesn't understand it.  And not understanding it I can't
imagine

Re: General ata grousing

[Warner Losh]

In message <[EMAIL PROTECTED]> Peter Wemm writes:
: Just as a BTW, dfr and sos are exchanging patches right now (and have been
: for quite a few days) that happen to fix the inthand_add() stuff.

This may also help the pccard code cases which I have floating around.

Warner


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

Re: Proposed patch to fix VN device (again)

[Peter Wemm]

David Greenman wrote:
>I've heard from both of you that you think the other is wrong. This isn't
> very helpful, however, in finding the correct solution. What I'd like to hear
> from both of you is the reasons why swap is better as a device, or not. There
> seems to be some unstated architectural philosophy that needs to be stated
> before any informed decision can be made about what is the right direction to
> go in.

The problem is that swapdev_vp needs to handle VOP_STRATEGY(), and swapdev_vp
is incorrectly being pointed at spec_vnops.  Here is a proposed (UNTESTED!)
clean fix:

Index: swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.129
diff -u -r1.129 swap_pager.c
--- swap_pager.c1999/11/22 15:27:09 1.129
+++ swap_pager.c1999/12/28 03:22:08
@@ -199,6 +199,32 @@
 static daddr_t swp_pager_meta_ctl __P((vm_object_t, vm_pindex_t, int));
 
 /*
+ * Handle a VOP_STRATEGY() on swapdev_vp
+ */
+
+static int
+swapdev_strategy(ap)
+   struct vop_strategy_args /* {
+   struct vnode *a_vp;
+   struct buf *a_bp;
+   } */ *ap;
+{
+   struct buf *bp;
+
+   bp = ap->a_bp;
+   return swstrategy(bp);
+}
+
+vop_t **swapdev_vnodeop_p;
+static struct vnodeopv_entry_desc swapdev_vnodeop_entries[] = {  
+   { &vop_strategy_desc,   (vop_t *) swapdev_strategy },
+   { NULL, NULL }
+};
+static struct vnodeopv_desc swapdev_vnodeop_opv_desc =
+   { &swapdev_vnodeop_p, swapdev_vnodeop_entries };
+VNODEOP_SET(swapdev_vnodeop_opv_desc);
+
+/*
  * SWP_SIZECHECK() -   update swap_pager_full indication
  * 
  * update the swap_pager_almost_full indication and warn when we are
@@ -329,7 +355,7 @@
 
swhash_mask = n - 1;
 
-   n = getnewvnode(VT_NON, NULL, spec_vnodeop_p, &swapdev_vp);
+   n = getnewvnode(VT_NON, NULL, swapdev_vnodeop_p, &swapdev_vp);
if (n)
panic("Cannot get vnode for swapdev");
swapdev_vp->v_type = VBLK;

After this, flushchainbuf() on a bp that is bound to swapdev_vp should do
the right thing.  There is still no need at all to redirect this via a fake
device.

I'll be testing this shortly, but I wanted to get an alternative in before the
arms race truely turned nuclear.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]



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

Re: Proposed patch to fix VN device (again)

[Peter Wemm]

Matthew Dillon wrote:
[..]
> And, in anycase, I am not going to spend hours putting together a long 
> involved patch when a simple short patch suffices.  If you want to
> spend the time to come up with your own patch (that doesn't screw the
> pooch in regards to cluster performance!), then I'm all ears, otherwise
> this patch is what is going to go in for the 4.0 release.

Please hold fire for a bit longer.  I have (what I think is) a much cleaner
fix in mind.  There is no urgency here, a couple of hours isn't going to
make the slightest difference to the big picture.

On a side note, as the original author of the changes that lead to this, I
would have thought it would have been appropriate to ask ME directly first
before going public.

Cheers,
-Peter



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

Re: INET6 userland tools

[Yoshinobu Inoue]

> Very INET6 specific patches are already prepared and under the
> review.  getaddrinfo() and getaddrname() is not yet, but I'll
> also prepare them.
> 
> And after those libraries are prepared, porting KAME tools
> onto current won't be difficult.

Getaddrinfo(), getaddrname(), etc support is commited,
and also several udp and raw socket apps are also committed.

 -gethostbyaddr(), gethostbyname(), etc support in libc/net
  (but DNS query over IPv6 transport is not yet)
 -several udp and raw socket apps
  ping6
  rtsol(host address autoconfiguration tool.
Actually the source code is shared with 'rtsold'.
Though it needs 'rtadvd' daemon on a router, 'rtadvd' for current
is not yet.)
  rtsold(host address autoconfiguration daemon for Note PC,
 which frequently change its subnet)
  gifconfig(v6/v4, v6/v4, v4/v4, v6/v6 tunneling configuration)
  ifmcstat(print out v6 multicast addr configuration info)
  prefix(assigne address prefix, e.g. subnet addr,
 just like ifconfig for full addr.
 it also support host internal prefix renumbering)
  route6d
  rip6query

Anyone interested in them please try and enjoy.
(Note that you need to build kernel with INET6 option.)

If there is any problems, please let me know. Thanks,

Yoshinobu Inoue
KAME project


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

Re: Proposed patch to fix VN device (again)

[David Greenman]

   I've heard from both of you that you think the other is wrong. This isn't
very helpful, however, in finding the correct solution. What I'd like to hear
from both of you is the reasons why swap is better as a device, or not. There
seems to be some unstated architectural philosophy that needs to be stated
before any informed decision can be made about what is the right direction to
go in.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>Sorry Poul, but you have no authority in this matter.  All the statements
>you have made in the last hour simply point out, in very clear terms,
>that you don't know what you are talking about.  Instead of simply
>admiting a mistake or even spending some time to review the code
>more closely, your solution is instead to continue to make outrageous
>statements.

The fact that I think the hacks should be kept firmly inside the
VM system, rather than spill out into the rest of the kernel is
not something I count amongst my mistakes.

I have actually spent quite some time looking at the code, both
before and again tonight just because of your email.

That is probably the best example of a review process which works.

>Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not
>reply to any of my postings.

This has been my general policy for a long time, but it gets
overridden whenever you come up with something which is obviously
wrong.  (And I find the fact that so many people have adopted this
policy disturbing, and sufficient grounds for me to relax my instance
of it.)

>  Not a single one, because I am wholely
>sick and tired of your superiority complex.  This thread was not meant
>for you, and your presence in it is not welcome.  And don't even think
>about doing an end-run around me and committing your frankly inappropriate
>'solution' - I'm going through proper channels to get this in.

I have all rights I need to answer you when you send an email in
public asking for a review.

It is my obligation to answer you when I am one of the few people
who are not intimidated by neither you nor the code in question
and I can see that what you are proposing is plain wrong.

So far you have one very experienced kernel programmer objecting
to your patch, so yes: you will bloddy have to go through proper
channels to resolve this issue.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>Huh?  Look Poul, I don't know what your problem is but I'm through
:>playing around with you.   You aren't making any sense and, frankly my
:>dear sir, the buffer cache, vm_pager interface, VN device, and
:>vm_pager_strategy subsystem is my ball of wax, not yours...
:
:Sorry, not so (and you've been told plenty many times already).
:
:You should fix the swap-pager to remove this last smoldering
:assumption about the existence of /dev/drum, rather than obfuscate
:the rest of the system by adding it back.
:
:I know it means more work for you, but we're not here to cut corners,
:we're here to get a better system.  We don't get a better system if
:you keep pushing the dirty bits into obscure corners of the kernel
:rather than fix them where they need fixed.

Sorry Poul, but you have no authority in this matter.  All the statements
you have made in the last hour simply point out, in very clear terms,
that you don't know what you are talking about.  Instead of simply
admiting a mistake or even spending some time to review the code
more closely, your solution is instead to continue to make outrageous
statements.

Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not
reply to any of my postings.  Not a single one, because I am wholely
sick and tired of your superiority complex.  This thread was not meant
for you, and your presence in it is not welcome.  And don't even think
about doing an end-run around me and committing your frankly inappropriate
'solution' - I'm going through proper channels to get this in.

-Matt



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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>Huh?  Look Poul, I don't know what your problem is but I'm through
>playing around with you.   You aren't making any sense and, frankly my
>dear sir, the buffer cache, vm_pager interface, VN device, and
>vm_pager_strategy subsystem is my ball of wax, not yours...

Sorry, not so (and you've been told plenty many times already).

You should fix the swap-pager to remove this last smoldering
assumption about the existence of /dev/drum, rather than obfuscate
the rest of the system by adding it back.

I know it means more work for you, but we're not here to cut corners,
we're here to get a better system.  We don't get a better system if
you keep pushing the dirty bits into obscure corners of the kernel
rather than fix them where they need fixed.

>I don't need
>your permission and I certainly don't need your help if this is all you
>can come up with.

I objected to your patch on the grounds that it would be a step backwards,
that has nothing to do with getting my permission.

>can come up with.  I'm not going to twist up all that wonderful clean code
>just to avoid making the swapper a real device.

You can call that "wonderful clean code" all you like, it is most
certainly not the term I would use for it, and either way the matter
of the fact is that struct buf is being abused to do something
which it isn't able to do in its current design, and the way to
fix that is not to add a hacked up dev_t but to give it special
handling where it needs that.

And adding a bogus dev_t and a equally bogus devsw does by no means
make the swapper "a real device".

I still object to your patch.  It is a step backwards and it would
further obfuscate the swap_pagers code.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:>:--
:>:Poul-Henning Kamp FreeBSD coreteam member
:>:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
:>
:>Uh... no.  The chain buffer routines are supposed to be generic.  In fact,
:>all the filesystem buffer cache I/O routines are supposed to be generic.
:>There is no way I'm going to pollute them to special case swap.
:
:Ok, fair enough:  Then stop abusing struct buf for swap device access :-)
:
:If you want to abuse struct buf for swap device access, you will need
:to special case it as applicable.
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."

Huh?  Look Poul, I don't know what your problem is but I'm through
playing around with you.   You aren't making any sense and, frankly my
dear sir, the buffer cache, vm_pager interface, VN device, and
vm_pager_strategy subsystem is my ball of wax, not yours... I don't need
your permission and I certainly don't need your help if this is all you
can come up with.  I'm not going to twist up all that wonderful clean code
just to avoid making the swapper a real device.  After all, making it a
real device is only a few simple lines of code - simple and 
straightforward.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:
>:Ahh, I see the mistake.
>:
>:All you need to fix this is to add a new function:
>:
>:  void
>:  flushswchainbuf(struct buf *nbp)
>:  {
>:  if (nbp->b_bcount) {
>:  nbp->b_bufsize = nbp->b_bcount;
>:  if ((nbp->b_flags & B_READ) == 0)
>:  nbp->b_dirtyend = nbp->b_bcount;
>:  BUF_KERNPROC(nbp);
>:  swstrategy(nbp);
>:  } else {
>:  biodone(nbp);
>:  }
>:  }
>:
>:And use this instead of flushchainbuf() in swap_pager_strategy().
>:
>:--
>:Poul-Henning Kamp FreeBSD coreteam member
>:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
>
>Uh... no.  The chain buffer routines are supposed to be generic.  In fact,
>all the filesystem buffer cache I/O routines are supposed to be generic.
>There is no way I'm going to pollute them to special case swap.

Ok, fair enough:  Then stop abusing struct buf for swap device access :-)

If you want to abuse struct buf for swap device access, you will need
to special case it as applicable.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:
:
:Ahh, I see the mistake.
:
:All you need to fix this is to add a new function:
:
:   void
:   flushswchainbuf(struct buf *nbp)
:   {
:   if (nbp->b_bcount) {
:   nbp->b_bufsize = nbp->b_bcount;
:   if ((nbp->b_flags & B_READ) == 0)
:   nbp->b_dirtyend = nbp->b_bcount;
:   BUF_KERNPROC(nbp);
:   swstrategy(nbp);
:   } else {
:   biodone(nbp);
:   }
:   }
:
:And use this instead of flushchainbuf() in swap_pager_strategy().
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."

Uh... no.  The chain buffer routines are supposed to be generic.  In fact,
all the filesystem buffer cache I/O routines are supposed to be generic.
There is no way I'm going to pollute them to special case swap.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

Ahh, I see the mistake.

All you need to fix this is to add a new function:

void
flushswchainbuf(struct buf *nbp)
{
if (nbp->b_bcount) {
nbp->b_bufsize = nbp->b_bcount;
if ((nbp->b_flags & B_READ) == 0)
nbp->b_dirtyend = nbp->b_bcount;
BUF_KERNPROC(nbp);
swstrategy(nbp);
} else {
biodone(nbp);
}
}

And use this instead of flushchainbuf() in swap_pager_strategy().

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>First, you are confusing the underlying swap devices that we swapon on
:>with the parent swap device that controls them.  The parent swap device
:>needs to have a dev_t - it does not currently have one, and this is
:>the entry point that the buffers are going into.  The underlying swap
:>devices *already* have a dev_t.  My kernel crashes on a NULL bp->b_dev.
:>In fact, it also crashes on a NULL vp->v_rdev.
:
:And where in the code does this crash happen ?

#9  0xc023c5b3 in trap ()
#10 0xc014b862 in devsw ()
#11 0xc017fa4a in vn_isdisk ()
#12 0xc018e1f3 in spec_strategy ()
#13 0xc020eb42 in flushchainbuf ()
#14 0xc0202e1e in swap_pager_strategy ()
#15 0xc020e675 in vm_pager_strategy ()

#9  0xc023c5e3 in trap ()
#10 0xc014b862 in devsw ()
#11 0xc018e26e in spec_strategy ()
#12 0xc020eb72 in flushchainbuf ()
#13 0xc0202e4e in swap_pager_strategy ()
#14 0xc020e6a5 in vm_pager_strategy ()

#9  0xc023c5c3 in trap ()
#10 0xc018e23f in spec_strategy ()
#11 0xc020eb52 in flushchainbuf ()
#12 0xc0202e2e in swap_pager_strategy ()
#13 0xc020e685 in vm_pager_strategy ()

:>Second, the clustering done above the VN device is done by the 
:>filesystem and has no understanding of whether the underlying media
:>controlled by the VN device can itself be clustered in the same way.
:>When using swap as backing store what may appear to be clusterable
:>by the filesystem may actually *NOT* be clusterable when you get into
:>the swap device due to potentially non-contiguous mappings as well
:>as border-crossings between interleaved swap devices.
:
:So you need to cluster all the way through the VN device ?  Obviously
:clustering on just one side will not buy you anything.  Tough luck...
:
:It sounds more and more like the mistake here is for VN to have a
:specfs VOP vector on top, I think it needs its own VOP vector so
:it can get hold of the VOP_BMAP function...
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."

Ummm.  The VN device is not a filesystem, it's a 'disk'.  The UFS 
filesystem does not recursively VOP_BMAP down into the underlying 
media so implementing VOP_BMAP in VN would not help.

We could implement our own set of device vectors but it would be rather
pointless since specfs's device vectors do everything we want.

And, in anycase, I am not going to spend hours putting together a long 
involved patch when a simple short patch suffices.  If you want to
spend the time to come up with your own patch (that doesn't screw the
pooch in regards to cluster performance!), then I'm all ears, otherwise
this patch is what is going to go in for the 4.0 release.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>First, you are confusing the underlying swap devices that we swapon on
>with the parent swap device that controls them.  The parent swap device
>needs to have a dev_t - it does not currently have one, and this is
>the entry point that the buffers are going into.  The underlying swap
>devices *already* have a dev_t.  My kernel crashes on a NULL bp->b_dev.
>In fact, it also crashes on a NULL vp->v_rdev.

And where in the code does this crash happen ?

>Second, the clustering done above the VN device is done by the 
>filesystem and has no understanding of whether the underlying media
>controlled by the VN device can itself be clustered in the same way.
>When using swap as backing store what may appear to be clusterable
>by the filesystem may actually *NOT* be clusterable when you get into
>the swap device due to potentially non-contiguous mappings as well
>as border-crossings between interleaved swap devices.

So you need to cluster all the way through the VN device ?  Obviously
clustering on just one side will not buy you anything.  Tough luck...

It sounds more and more like the mistake here is for VN to have a
specfs VOP vector on top, I think it needs its own VOP vector so
it can get hold of the VOP_BMAP function...

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>VN calls vm_pager_strategy() which collects I/O in filesystem buffers
:>(bp)'s in order to cluster the I/O, and you cannot initiate I/O on 
:>filesystem buffers without a valid b_dev.
:>
:>So, the jist of the problem is that in order to get reasonable performance
:>out of the thing (i.e. not issue 4K I/O's to the disk), we have to use
:>filesystem buffers which means the bp must be properly initialized.
:
:vm_pager_strategy() branches out based on the object type and ends up
:in swap_pager_strategy() which only uses b_dev after calling swstrategy()
:then only in a diagnostic printf which we had better never reach.
:
:swstrategy() which initializes bp->b_dev to the right physical device.
:
:I'm afraid I don't see why or where we would need the bogus /dev/drum dev_t.
:
:Furthermore, since we have already clustered above the VN device,
:I seriously doubt the utility of doing it again between VN and the
:swapdevice.
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!

Umm.  Poul, I know you don't like the idea but you obviously do not
understand the code in question.

First, you are confusing the underlying swap devices that we swapon on
with the parent swap device that controls them.  The parent swap device
needs to have a dev_t - it does not currently have one, and this is
the entry point that the buffers are going into.  The underlying swap
devices *already* have a dev_t.  My kernel crashes on a NULL bp->b_dev.
In fact, it also crashes on a NULL vp->v_rdev.  Without the patch.  So
if you are trying to say that b_dev is being magically set I gotta tell
you that my kernel dumps say otherwise.

Second, the clustering done above the VN device is done by the 
filesystem and has no understanding of whether the underlying media
controlled by the VN device can itself be clustered in the same way.
When using swap as backing store what may appear to be clusterable
by the filesystem may actually *NOT* be clusterable when you get into
the swap device due to potentially non-contiguous mappings as well
as border-crossings between interleaved swap devices.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>VN calls vm_pager_strategy() which collects I/O in filesystem buffers
>(bp)'s in order to cluster the I/O, and you cannot initiate I/O on 
>filesystem buffers without a valid b_dev.
>
>So, the jist of the problem is that in order to get reasonable performance
>out of the thing (i.e. not issue 4K I/O's to the disk), we have to use
>filesystem buffers which means the bp must be properly initialized.

vm_pager_strategy() branches out based on the object type and ends up
in swap_pager_strategy() which only uses b_dev after calling swstrategy()
then only in a diagnostic printf which we had better never reach.

swstrategy() which initializes bp->b_dev to the right physical device.

I'm afraid I don't see why or where we would need the bogus /dev/drum dev_t.

Furthermore, since we have already clustered above the VN device,
I seriously doubt the utility of doing it again between VN and the
swapdevice.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

newpcm and non-PnP SoundBlaster Vibra 16 4.13

[Khetan Gajjar]

Hi.

I have been following the thread(s) about getting the SoundBlaster
Vibra 16 sound-cards working in -current, and it appears that if
you have a PnP card, it seems to be working.

I do not have a PnP version of this card, and the last time I was
able to get the sound card recognised was October 2nd. A verbose
boot of that kernel reveals

sb_probe: no addr, trying (0x220, 0x240)
pcm:  4c000
pcm: setmap 4d, ff00; 0xc80c500 -> 4d000

and /dev/sndstat reveals

FreeBSD Audio Driver (newpcm) Oct 2 1999 14:30:27
Installed devices:
pcm0:  at io 0x220 irq 10 drq 3:7 (1/1 channels duplex)

With subsequent kernels, including a -current kernel from 20 Dec, the 
sound card is not detected. The definitions I'm using in my kernel 
currently (no pun intended :) are

#sound card
device pcm0
device sbc0 at isa? port ? irq 10 drq 3 flags 0x17

as compared to what I had

device pcm0 at isa? port ? irq 10 drq 3 flags 0x17

The card is probed if the machine is booted with a kernel of
Oct 2, and not probed if the machine is botted with a kernel
of Dec 20.

The only other thing I can think of is that the old kernel
had support for PnP, whereas the new ones doesn't. This shouldn't
matter though if I'm supplying the parameters directly to the card.

Khetan Gajjar.
---
[EMAIL PROTECTED]  * [EMAIL PROTECTED]* PGP Key, contact
UUNET South Africa  * FreeBSD enthusiast  * details and other
http://www.uunet.co.za/ * http://www.freebsd.org/ * information at
System Administration   * http://link.os.org.za/  * [EMAIL PROTECTED]



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

troubles with X

[Steve Price]

Hi all,

I just rebooted my -current box for the first time in a long
time.  Everything on this box is freshly compiled (including
X) as of only a couple of hours ago.  I even mergemaster'd
for good measure.

For some reason now I can't startx(1) as either myself or root.
I type startx and the PAM auth routines loop forever printing
out 'Password:'.  I comment out the last two lines in /etc/pam.conf
and I get an authentication failure (as I should).

Anyone have any ideas what I'm doing wrong?  What is the correct
method to start X on -current nowadays?

Thanks.

-steve

PS: I'd search the mailing lists but I can't get to my browser
and I'm not so good with lynx. :)



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

Re: Proposed patch to fix VN device (again)

[Matthew Dillon]

:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>Sigh.  Ok, I've fixed the VN device.  Again.  It looks like the removal of
:>/dev/drum removed a little too much.  We need the device infrastructure
:>to support the VN device's use of swap backing store.
:>
:>This patch below is a commit candidate.  It could use a review, then I'll
:>commit it.
:
:Could you please explain why you need this ?
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!

VN calls vm_pager_strategy() which collects I/O in filesystem buffers
(bp)'s in order to cluster the I/O, and you cannot initiate I/O on 
filesystem buffers without a valid b_dev.

So, the jist of the problem is that in order to get reasonable performance
out of the thing (i.e. not issue 4K I/O's to the disk), we have to use
filesystem buffers which means the bp must be properly initialized.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Proposed patch to fix VN device (again)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:

>Sigh.  Ok, I've fixed the VN device.  Again.  It looks like the removal of
>/dev/drum removed a little too much.  We need the device infrastructure
>to support the VN device's use of swap backing store.
>
>This patch below is a commit candidate.  It could use a review, then I'll
>commit it.

Could you please explain why you need this ?

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: buildworld failure

[Randy Bush]

so, to go for 3.4 to -current i had to
  o comment kerberos4 and perl from /etc/make.conf
  o build
  o build and install perl right in the directory
  o the usual cruft

it works.  and it fixed
  o wl0
  o my dlt free bus error

still working on kerberos, but i have learned to care less and less about
it.

randy


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

Proposed patch to fix VN device (again)

[Matthew Dillon]

Sigh.  Ok, I've fixed the VN device.  Again.  It looks like the removal of
/dev/drum removed a little too much.  We need the device infrastructure
to support the VN device's use of swap backing store.

This patch below is a commit candidate.  It could use a review, then I'll
commit it.

-Matt


Index: swap_pager.h
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.h,v
retrieving revision 1.27
diff -u -r1.27 swap_pager.h
--- swap_pager.h1999/11/18 06:55:40 1.27
+++ swap_pager.h1999/12/27 23:59:49
@@ -106,6 +106,7 @@
 
 /* choose underlying swap device and queue up I/O */
 struct buf;
+struct vnode *vm_swap_makevnode __P((void));
 void swstrategy __P((struct buf *bp)); /* probably needs to move elsewhere */
 
 #endif
Index: vm_swap.c
===
RCS file: /home/ncvs/src/sys/vm/vm_swap.c,v
retrieving revision 1.93
diff -u -r1.93 vm_swap.c
--- vm_swap.c   1999/12/15 23:02:35 1.93
+++ vm_swap.c   1999/12/28 00:05:55
@@ -68,6 +68,42 @@
 static int nswdev = NSWAPDEV;
 int vm_swap_size;
 
+#define CDEV_MAJOR 4
+
+static struct cdevsw sw_cdevsw = {
+   /* open */  nullopen,
+   /* close */ nullclose,
+   /* read */  noread,
+   /* write */ nowrite,
+   /* ioctl */ noioctl,
+   /* poll */  nopoll,
+   /* mmap */  nommap,
+   /* strategy */  swstrategy,
+   /* name */  "sw",
+   /* maj */   CDEV_MAJOR,
+   /* dump */  nodump,
+   /* psize */ nopsize,
+   /* flags */ D_DISK,
+   /* bmaj */  -1
+};
+
+struct vnode *
+vm_swap_makevnode(void)
+{
+   struct vnode *vp = NULL;
+
+   if (getnewvnode(VT_NON, NULL, spec_vnodeop_p, &vp)) {
+   panic("Cannot get vnode for swapdev");
+   return(NULL);
+   }
+   vp->v_rdev = make_dev(&sw_cdevsw, 1, UID_ROOT, GID_KMEM, 
+   0640, "swapdev");
+   vp->v_rdev->si_bsize_phys = PAGE_SIZE;
+   vp->v_rdev->si_bsize_best = PAGE_SIZE;
+   vp->v_type = VCHR;
+   return(vp);
+}
+
 /*
  * swstrategy:
  *
Index: swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.129
diff -u -r1.129 swap_pager.c
--- swap_pager.c1999/11/22 15:27:09 1.129
+++ swap_pager.c1999/12/28 00:01:24
@@ -329,10 +329,7 @@
 
swhash_mask = n - 1;
 
-   n = getnewvnode(VT_NON, NULL, spec_vnodeop_p, &swapdev_vp);
-   if (n)
-   panic("Cannot get vnode for swapdev");
-   swapdev_vp->v_type = VBLK;
+   swapdev_vp = vm_swap_makevnode();
 }
 
 /*
Index: /usr/src/sys/conf/majors
===
RCS file: /home/ncvs/src/sys/conf/majors,v
retrieving revision 1.94
diff -u -r1.94 majors
--- majors  1999/12/17 19:56:39 1.94
+++ majors  1999/12/27 23:27:37
@@ -21,7 +21,7 @@
 1  ctty/dev/tty
 2  mm  /dev/mem,kmem,etc
 3  wd  ST506 disk controller (with IDE extensions)
-4  was:swap/dev/drum
+4  swap/dev/drum
 5  pts pseudo tty "tty" half
 6  ptc pseudo tty "master" half
 7  log system log


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

Re: if_fxp.c

[Eric D. Futch]

hehe oops.. follow up to my own message this is for -stable :)

--
Eric Futch  New York Connect.Net, Ltd.
[EMAIL PROTECTED] Technical Support Staff
http://www.nyct.net (212) 293-2620
"Bringing New York The Internet Access It Deserves"

On Mon, 27 Dec 1999, Eric D. Futch wrote:

This is from -current as of Wed Dec 22 01:48:17 EST 1999

../../pci/if_fxp.c: In function `fxp_intr':
../../pci/if_fxp.c:1069: warning: label `getit' defined but not used
../../pci/if_fxp.c:1064: warning: label `dropit' defined but not used


--
Eric Futch  New York Connect.Net, Ltd.
[EMAIL PROTECTED] Technical Support Staff
http://www.nyct.net (212) 293-2620
"Bringing New York The Internet Access It Deserves"



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

if_fxp.c

[Eric D. Futch]

This is from -current as of Wed Dec 22 01:48:17 EST 1999

../../pci/if_fxp.c: In function `fxp_intr':
../../pci/if_fxp.c:1069: warning: label `getit' defined but not used
../../pci/if_fxp.c:1064: warning: label `dropit' defined but not used


--
Eric Futch  New York Connect.Net, Ltd.
[EMAIL PROTECTED] Technical Support Staff
http://www.nyct.net (212) 293-2620
"Bringing New York The Internet Access It Deserves"



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

Re: unknown pci card

[Matthew Jacob]

On Mon, 27 Dec 1999, Randy Bush wrote:

> any clue how i can find out what this puppy is
> 
> Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo.
>  -> pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18

Go to

http://www.pcisig.com/membership/vendors/sorted.html

to look up vendor ids (this one's a brooktree part)


> pcm0:  irq 17 at device 11.0 on pci0
> 
> i think everything in the box is working.
> 
> randy
> 
> 
> 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

unknown pci card

[Randy Bush]

any clue how i can find out what this puppy is

Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo.
 -> pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18
pcm0:  irq 17 at device 11.0 on pci0

i think everything in the box is working.

randy


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

Re: es1371 PCI128 Rev 7 patch

[Randy Bush]

>> dunno what's solved by what, but current is not blasting sound for me.
>> reading the lists, suggestions for adding
>> controller pnp0
> The pnp stuff shouldn't have anything to do with this card, it's pi.
^c
unnerstand.  but there's stuff on the current list saying to use that with
the pci128, so i thought i would debunk it.

> ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.2,patch

yes!  works fine on my asus p2b-ds with current as of this morning.

thank you.

randy


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

Re: IPFW

[Emre]

On Mon, Dec 27, 1999 at 10:02:29PM +0100, Wilko Bulte wrote:
> Is there any reason for you to run -current? Because if there isn't you'd
> be better off using a -stable version of FreeBSD.

Not really.  All my other boxes (NetBSD/OpenBSD) run -current so I'm
used to be on the "bleeding edge"  I figured it would be enabled
by default, since FreeBSD promises to be _the_ Server O/S.

Actually I haven't tried -release or -stable...I'm willing
to take the chance.  BTW, I fixed the firewalling stuff,
ipfw still has a bit anal syntax but I think I got it working.

Thanks for the help :)

-- 
Emre Yildirim
Fingerprint = B16C EBA7 97FE EF2C 365F C4C4 54AA 3676 5E9E E10A
DSS/DH 1024/4064: 0x5E9EE10A/0x2486FEBE  


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

Re: es1371 PCI128 Rev 7 patch

[Russell Cattelan]

Randy Bush wrote:

> > The problem with the PCI128 rev 7 and ASUS boards seem to be solved
> > with a simple patch.
> >
> > Anybody with  such a combination please try this patch
> > ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.patch
> >
> > Once it is verified to work, I'm sure somebody  will want to commit it.
>
> dunno what's solved by what, but current is not blasting sound for me.
> reading the lists, suggestions for adding
>
> controller pnp0

The pnp stuff shouldn't have anything to do with this card, it's pi.

Cameron did a bunch of code clean up, which is why the patch didn't apply.
I generated a new patch that should apply to current -current.
ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.2,patch

>

>
>
> seem out of date, as i get
>
> rip.psg.com:/sys/i386/conf# config RIP
> Don't forget to do a ``make depend''
> Warning: controller "pnp" is unknown
> Kernel build directory is ../../compile/RIP
>
> the patch mentioned above does not take with current.9912270034, two
> rejects.  so i expect a commit was done.
>
> dmesg whines
>
> pci0: Intel PIIX4 ATA controller (vendor=0x8086, dev=0x7111) at 4.1
> pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 4.2 
>irq 19
> ...
> bktr0:  irq 18 at device 10.0 on pci0
> iicbb0:  on bti2c0
> iicbus0:  on iicbb0 master-only
> smbus0:  on bti2c0
> bktr0: Hauppauge Model 6 A M
> bktr0: Detected a MSP3430G-A1 at 0x80
> Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo.
> pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18
> pcm0:  irq 17 at device 11.0 on pci0
> ac97: dac not ready
> ...
>
> kernel sez
>
> device  pcm0
>
> randy

--
Russell Cattelan
[EMAIL PROTECTED]





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

Re: IPFW

[Wilko Bulte]

On Mon, Dec 27, 1999 at 02:52:03PM +, Emre wrote:

> I apologize if this question is not appropriate for this list but...

It is not I'm afraid.

> I'm trying to firewall it using ipfw, when I issue the command
> 
> ipfw add deny udp from any to any 1-2200
> 
> I get 
> 
> 0 deny udp from any to any 1-2200
> ipfw: setsockopt(IP_FW_ADD): Protocol not available
> 
> I only changed two lines in the GENERIC kernel.  Did I screw it up?
> I assumed packet filtering was enabled in the GENERIC kernel by default.

Wrong assumption. See /sys/i386/conf/LINT for the entries you need
to enable the firewall code.

> Can anyone give me hints on how to fix this, or what this message means?
> I already RTFM and the stuff in the handbook (the man page looks very similar
> to the stuff that was in the handbook).

Is there any reason for you to run -current? Because if there isn't you'd
be better off using a -stable version of FreeBSD.

-- 
Wilko Bulte Arnhem, The Netherlands   - The FreeBSD Project 
WWW : http://www.tcja.nl  http://www.freebsd.org


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

Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test

[Garance A Drosihn]

At 8:55 AM -0500 12/24/99, Robert Watson wrote:
>For example, imagine that the user has a
>number of hard links to the file in question.

Okay, here's my newer version of the code, which takes into
account multiple hard links, and also makes it so the spooled
data file is owned by daemon instead of the user.  This works
fine.  At some later point I'll write an update so the spooled
data file is owned by daemon in other cases, too.

Further comments or observations welcome.  If this looks okay
I'll submit this as a new PR.

Index: lpr/lpr.c
===
RCS file: /Users/cvsdepot/lpr-fbsd/lpr/lpr.c,v
retrieving revision 1.1.1.1
diff -U5 -r1.1.1.1 lpr.c
--- lpr.c   1999/11/30 16:15:22 1.1.1.1
+++ lpr.c   1999/12/27 21:58:39
@@ -382,10 +382,69 @@
nact++;
continue;
}
if (sflag)
printf("%s: %s: not linked, copying 
instead\n", name, arg);
+
+   if (f) {
+   /*
+* The user wants the file removed after it is copied,
+* so see if it can be mv'ed instead of copy/unlink'ed.
+* This will be much faster and better than copying the
+* file, especially for larger files.  Can be very
+* useful for services like samba, pcnfs, CAP, et al.
+*/
+   int ret, didlink;
+   struct stat statb2;
+   seteuid(euid);
+   didlink = 0;
+   /* don't do this if the user's file is a symlink */
+   if (lstat(arg, &statb) < 0)  goto nohardlink;
+   if (S_ISLNK(statb.st_mode))  goto nohardlink;
+   /* if the attempt to link fails, abandon the move */
+   if (link(arg, dfname) != 0)  goto nohardlink;
+   didlink = 1;
+   /* make sure the user hasn't tried to trick us via
+* any race conditions */
+   if (lstat(dfname, &statb2) < 0)goto nohardlink;
+   if (statb.st_dev != statb2.st_dev) goto nohardlink;
+   if (statb.st_ino != statb2.st_ino) goto nohardlink;
+   /* skip if the file already had multiple hard links,
+* because changing the owner and access-bits would
+* change ALL versions of the file */
+   if (statb2.st_nlink > 2) goto nohardlink;
+
+   /* if we can access and remove the given file without
+* special setuid-ness then this method is safe. */
+   seteuid(uid);
+   ret = access(dfname, R_OK);
+   if (ret == 0)
+   ret = unlink(arg);
+   seteuid(euid);
+   /* the user does not have access to read or remove
+* this file, so abandon the move and fall back to
+* the usual (copy) methods. */
+   if (ret != 0) goto nohardlink;
+
+   /* unlink of user file was successful. fixup perms,
+* add entries to control file, and skip copy step */
+   chown(dfname, pp->daemon_user, getegid());
+   chmod(dfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
+   seteuid(uid);
+   if (format == 'p')
+   card('T', title ? title : arg);
+   for (i = 0; i < ncopies; i++)
+   card(format, &dfname[inchar-2]);
+   card('U', &dfname[inchar-2]);
+   card('N', arg);
+   nact++;
+   continue;
+nohardlink:
+   if (didlink) unlink(dfname);
+   seteuid(uid);   /* restore old uid */
+   } /* end: if (f) */
+
if ((i = open(arg, O_RDONLY)) < 0) {
printf("%s: cannot open %s\n", name, arg);
} else {
copy(pp, i, arg);
(void) close(i);
===


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


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

Re: es1371 PCI128 Rev 7 patch

[Randy Bush]

> The problem with the PCI128 rev 7 and ASUS boards seem to be solved
> with a simple patch.
> 
> Anybody with  such a combination please try this patch
> ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.patch
> 
> Once it is verified to work, I'm sure somebody  will want to commit it.

dunno what's solved by what, but current is not blasting sound for me.
reading the lists, suggestions for adding

controller pnp0

seem out of date, as i get

rip.psg.com:/sys/i386/conf# config RIP
Don't forget to do a ``make depend''
Warning: controller "pnp" is unknown
Kernel build directory is ../../compile/RIP

the patch mentioned above does not take with current.9912270034, two
rejects.  so i expect a commit was done.

dmesg whines

pci0: Intel PIIX4 ATA controller (vendor=0x8086, dev=0x7111) at 4.1
pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 4.2 
irq 19
...
bktr0:  irq 18 at device 10.0 on pci0
iicbb0:  on bti2c0
iicbus0:  on iicbb0 master-only
smbus0:  on bti2c0
bktr0: Hauppauge Model 6 A M 
bktr0: Detected a MSP3430G-A1 at 0x80
Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo.
pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18
pcm0:  irq 17 at device 11.0 on pci0
ac97: dac not ready
...

kernel sez

device  pcm0

randy


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

How to de-select DMA to ad0?

[David Gilbert]

I've had my share of problems with this drive's DMA abilities.  I'm
convinced that it has none... even though it probes as such.

ad0:  ATA-0 disk at ata0 as master
ad0: ...
ad0: 16 secs/int, 1 depth queue, DMA

now... when I boot -v, I don't have a chance to write down what it
says, but it will hang every time with the following output:

ad0: ad-timeout: lost disk contact
ata0: resetting drives -- mask=03 status0=50 status1=50 ..

And that's it.  It never prints out "done" which I see in many of the
list messages.  Is there a way of disabling DMA on a specific drive?
I read a bit of the source, but didn't find any obvious documentation
on the issue.

(This is all on a kernel compiled from a cvsup this afternoon)

Dave.

-- 

|David Gilbert, Velocet Communications.   | Two things can only be |
|Mail:   [EMAIL PROTECTED] |  equal if and only if they |
|http://www.velocet.net/~dgilbert |   are precisely opposite.  |
=GLO


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

Re: IPFW

[Emre]

On Mon, Dec 27, 1999 at 01:06:52PM -0800, Brian W. Buchanan wrote:

> Add the line:
> 
> options IPFIREWALL
> 
> to your kernel config and recompile.  See LINT for documentation and other
> options you may wish to consider.  IP Firewalling is not enabled by
> default in GENERIC.

Oh Thanks for the quick reply, I will try now :)

-- 
Emre Yildirim
Fingerprint = B16C EBA7 97FE EF2C 365F C4C4 54AA 3676 5E9E E10A
DSS/DH 1024/4064: 0x5E9EE10A/0x2486FEBE  


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

Re: IPFW

[Brian W. Buchanan]

On Mon, 27 Dec 1999, Emre wrote:

> Hi,
> 
> I apologize if this question is not appropriate for this list but...
> 
> I just installed FreeBSD 4.0-CURRENT (19991226) on a box.  I also recompiled
> the kernel so it would support SMP.  All I basicly did is change two lines
> concerning SMP in the GENERIC kernel (I followed the handbook).  The box
> is running just fine and I am very pleased with it.  Here is the problem:
> 
> I'm trying to firewall it using ipfw, when I issue the command
> 
> ipfw add deny udp from any to any 1-2200
> 
> I get 
> 
> 0 deny udp from any to any 1-2200
> ipfw: setsockopt(IP_FW_ADD): Protocol not available

Add the line:

options IPFIREWALL

to your kernel config and recompile.  See LINT for documentation and other
options you may wish to consider.  IP Firewalling is not enabled by
default in GENERIC.

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

IPFW

[Emre]

Hi,

I apologize if this question is not appropriate for this list but...

I just installed FreeBSD 4.0-CURRENT (19991226) on a box.  I also recompiled
the kernel so it would support SMP.  All I basicly did is change two lines
concerning SMP in the GENERIC kernel (I followed the handbook).  The box
is running just fine and I am very pleased with it.  Here is the problem:

I'm trying to firewall it using ipfw, when I issue the command

ipfw add deny udp from any to any 1-2200

I get 

0 deny udp from any to any 1-2200
ipfw: setsockopt(IP_FW_ADD): Protocol not available

I only changed two lines in the GENERIC kernel.  Did I screw it up?
I assumed packet filtering was enabled in the GENERIC kernel by default.

Can anyone give me hints on how to fix this, or what this message means?
I already RTFM and the stuff in the handbook (the man page looks very similar
to the stuff that was in the handbook).

Any help is greatly appreciated :)


(PS: does the IPFILTER package work with FreeBSD?  Because I'm used it and
ipfw syntax is kinda anal.  If so, has anyone tried it and successfully
used it?  Thanks.)


-- 
Emre Yildirim
Fingerprint = B16C EBA7 97FE EF2C 365F C4C4 54AA 3676 5E9E E10A
DSS/DH 1024/4064: 0x5E9EE10A/0x2486FEBE  


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

Re: Installation bug (4.0-19991227-CURRENT)

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Forrest Aldrich writes
:
>Did a test install against the latest snapshot.   
>
>The network configuration comes up with "dc0" (we have de0), this
>"works" in that we were able to perform the network install (so it
>must be a typo somewhere).

No, dc0 is the new and improved driver for the newer tulip chips.

>However, it results in multiple entries in /etc/rc.conf (three,
>total), which have to be removed before the network will come up
>correctly after rebooting.
>
>NB, this was an install over a previous 4.0 instance, so there's
>the possibility that the rc.conf file was edited rather than written
>over -- though I would doubt that (?).

That is probably what happened here.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: Installation bug (4.0-19991227-CURRENT)

[Jesper Skriver]

On Mon, Dec 27, 1999 at 02:14:29PM -0500, Forrest Aldrich wrote:
> Did a test install against the latest snapshot.   
> 
> The network configuration comes up with "dc0" (we have de0), 
> this "works" in that we were able to perform the network 
> install (so it must be a typo somewhere).

If you had been following -current, you would know that Bill Paul
has written the dc driver, that works with much of the same cards
that the de driver does. If both the de and dc driver are available,
the dc driver wins.

> However, it results in multiple entries in /etc/rc.conf (three, 
> total), which have to be removed before the network will come 
> up correctly after rebooting.
> 
> NB, this was an install over a previous 4.0 instance, so there's 
> the possibility that the rc.conf file was edited rather than written 
> over -- though I would doubt that (?).

That is probably the case ...

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk
Work:Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek@ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


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

Re: Installation bug (4.0-19991227-CURRENT)

[Mike Smith]

The 'de' driver has been obsoleted for the 21143 part by the 'dc' driver.
You should be using 'dc' for those devices that it supports.

> Did a test install against the latest snapshot.   
> 
> The network configuration comes up with "dc0" (we have de0), this "works" in that we 
>were able to perform the network install (so it must be a typo somewhere).
> 
> However, it results in multiple entries in /etc/rc.conf (three, total), which have 
>to be removed before the network will come up correctly after rebooting.
> 
> NB, this was an install over a previous 4.0 instance, so there's the possibility 
>that the rc.conf file was edited rather than written over -- though I would doubt 
>that (?).
> 
> FYI.
> 
> 
> 
> _F
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Installation bug (4.0-19991227-CURRENT)

[Forrest Aldrich]

Did a test install against the latest snapshot.   

The network configuration comes up with "dc0" (we have de0), this "works" in that we 
were able to perform the network install (so it must be a typo somewhere).

However, it results in multiple entries in /etc/rc.conf (three, total), which have to 
be removed before the network will come up correctly after rebooting.

NB, this was an install over a previous 4.0 instance, so there's the possibility that 
the rc.conf file was edited rather than written over -- though I would doubt that (?).

FYI.



_F




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

Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test

[Garance A Drosihn]

At 8:55 AM -0500 12/24/99, Robert Watson wrote:
>... keep in mind that this optimization does not produce behavior
>behavior in some cases.  For example, imagine that the user has a
>number of hard links to the file in question.  If the file is copied and
>then deleted, then the link count is decremented by one, and the data used
>to print is independent of the original file.  However, if a single file
>system rename is used, the link count remains the same until the end of
>the print job, and if any of the other references to the same inode are
>modified, the print job will see inconsistent versions of the file (i.e.,
>it being changed out from under it).

Hmm.  This was a very good point to bring up, even if people don't use it
to modify the file (or do anything else nefarious).  The real problem here
is that lpr changes the ownership and permissions of the file after moving
it.  That means that if the user does give us a file with multiple hard
links, lpr will repermit *all* copies of the file, not just the version it
moved into the spool directory.  Clearly we also need to check the inode
count.  Thanks for that observation!

>I do not know whether the current
>lpr waits until it finishes copying before returning, but assume so,
>meaning that once lpr returns, normally, you are guaranteed that unless
>using the symlink option, you can continue to modify the inode in question
>with impunity.  With this optimization makes that assumption not true.  A
>caveat is already present for the symlink, "-s", option to this effect.  I
>believe this also allows users to present files that start out being
>within the maximum file size when that is checked, but later add more,
>allowing users to avoid the file size limit on print jobs.  This is
>presumably already present with "-s", and it's possible that lpd checks
>for this.

Well, for some reason lpr is dumber than that.  The spooled datafile ends
up being owned by the user who sent the job, and thus the user can go in
any time and make changes.  That's already true, without this update or
'-s' being used.  Personally I think that is bad, because it does allow
the user to circumvent any checks done at job-submission time.  I think
I'll write a separate update for that (maybe next year... :-).


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


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

Re: more patch for secondary buffer, polling and DMA emulation in pcm

[Seigo Tanimura]

On Mon, 27 Dec 1999 16:08:01 +0900,
  Seigo Tanimura <[EMAIL PROTECTED]> said:

Seigo> Another fix was made on feeding and sucking pcm data. Now chn_wrfeed()
Seigo> and the other functions do not attempt excessive feeding during DMA
Seigo> transfer to eat up the whole processor. The patch is at:

Ouch, the patch broke Rollemup, so I fixed just now. The URI is the same.

Seigo> http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: more patch for secondary buffer, polling and DMA emulation in pcm

[Seigo Tanimura]

On Mon, 27 Dec 1999 03:39:56 -0500,
  Donn Miller <[EMAIL PROTECTED]> said:

>> http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz

Donn> Hmmm...  this seems to have broken the probe at boot time. 
Donn> Here's a sample of my dmesg:
(snip)
Donn> unknown1:  at port
Donn> 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0

That is odd... The patch does not even touch sbc.c. How does your
pnpinfo(1) look like?

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: PPP still has problems with config parsing

[Brian Somers]

[.]
> tun0: Command: ip-telecom: set dial ABORT BUSY ABORT NO\sCARRIER ABORT
> NO\sDIAL\sTONE TIMEOUT 5 "" AT OK-AT-OK AT&F OK
> AT#F0$R1%E0S20=8&E2S48=16 OK \dATDP\T TIMEOUT 40 CONNECT
[.]

ppp was treating everything from the # to the end of line as a 
comment.  It should be fixed now.
-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>




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

subscribe

[MULLER Miklos]

subscribe



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

Re: more patch for secondary buffer, polling and DMA emulation in pcm

[Donn Miller]

Seigo Tanimura wrote:
> 
> Another fix was made on feeding and sucking pcm data. Now chn_wrfeed()
> and the other functions do not attempt excessive feeding during DMA
> transfer to eat up the whole processor. The patch is at:
> 
> http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz

Hmmm...  this seems to have broken the probe at boot time. 
Here's a sample of my dmesg:

unknown0:  at port
0x800-0x807 on isa0
unknown1:  at port
0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
unknown2:  at port 0x201 on
isa0

- Donn


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