subscribe freebsd-current

[kevin . wallace]

subscribe freebsd-current



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

Re: ESS1869 logical ID

[John Saunders]

> 
> unknown0:  on isa0
> pcm0:  at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
> unknown1:  at port 0x201 on isa0
> unknown2:  at port 0x168-0x16f,0x36e-0x36f irq 
>9 on isa0
> 

Interestingly, that last device "unknown2:" looks to be an IDE interface
for a CDROM drive. Any plans, ideas, thoughts on the PnP system assigning
the ATA driver to this device?

The middle device could possibly be a game port, although the port looks
strange as game ports are normally port 0x200.

--++
. | John Saunders  - mailto:[EMAIL PROTECTED](EMail) |
,--_|\|- http://www.nlc.net.au/  (WWW) |
   /  Oz  \   |- 02-9489-4932 or 04-1822-3814  (Phone) |
   \_,--\_/   | NORTHLINK COMMUNICATIONS P/L - Supplying a professional,   |
 v| and above all friendly, internet connection service.   |
  ++


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

Re: System crash on "vinum start"

[Greg Lehey]

On Wednesday, 29 September 1999 at 13:41:42 +1000, John Saunders wrote:
> In freebsd-current you wrote:
>>> Being in the hardware RAID business myself I cannot help asking: why do you
>>> want to loose the hardware RAID in favor of a software solution? Flexibility
>>> (just guessing) or price maybe?
>
>> Because DPT has screwed this customer over for the last time...
>
> I suspect that back porting the ida (Compaq SMART RAID) driver from
> -current to 3.x would be both quicker and cheaper that the software
> development you propose. At least that way you don't have to deal
> with DPT.
>
> Any software additions to support hot swap and auto-rebuild would need
> to interoperate with vinum. From my understanding, vinum will survive
> a failed disk and continue to run. However no mechanism is yet available
> to automatically rebuild a new disk.

Correct.  At the moment it needs to be done manually.  That's what Rod
is asking for.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


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

Re: System crash on "vinum start"

[Greg Lehey]

On Tuesday, 28 September 1999 at 15:31:54 -0700, Rodney W. Grimes wrote:
>> As Rodney W. Grimes wrote ...
 On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
>  Good software shouldn't panic.
 I wish _I_ could convince some people of this :-(.
>>
 rather than having to recover each logical volume.  It would also be
 nice if you could recover mirrored root/swap without needing to
 unmirror and re-mirror them.
>>>
>>> Hummm.. this may seem like a really stange question, but I'll throw
>>> it out anyway:
>>>
>>> Would $9,000 paid to a developer here with immediate time avaliable
>>> bring FreeBSD 3.x to a state of being able to replace our current use
>>> of hardware raid to do Raid-1 mirroring with hot swap automagic
>>> rebuild capabilities?  (It would need to be production quality code
>>> for very serious business, and completed in 3 weeks time.)
>>>
>>> Serious responses only please.
>>
>> Rod,
>>
>> Being in the hardware RAID business myself I cannot help asking: why do you
>> want to loose the hardware RAID in favor of a software solution? Flexibility
>> (just guessing) or price maybe?
>
> Because DPT has screwed this customer over for the last time...

Another reason might be the performance.  Take a look at 
http://www.shub-internet.org/brad/FreeBSD/vinum.html.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


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

Re: System crash on "vinum start"

[John Saunders]

In freebsd-current you wrote:
>> Being in the hardware RAID business myself I cannot help asking: why do you
>> want to loose the hardware RAID in favor of a software solution? Flexibility
>> (just guessing) or price maybe?

> Because DPT has screwed this customer over for the last time...

I suspect that back porting the ida (Compaq SMART RAID) driver from
-current to 3.x would be both quicker and cheaper that the software
development you propose. At least that way you don't have to deal
with DPT.

Any software additions to support hot swap and auto-rebuild would need
to interoperate with vinum. From my understanding, vinum will survive
a failed disk and continue to run. However no mechanism is yet available
to automatically rebuild a new disk.

--++
. | John Saunders  - mailto:[EMAIL PROTECTED](EMail) |
,--_|\|- http://www.nlc.net.au/  (WWW) |
   /  Oz  \   |- 02-9489-4932 or 04-1822-3814  (Phone) |
   \_,--\_/   | NORTHLINK COMMUNICATIONS P/L - Supplying a professional,   |
 v| and above all friendly, internet connection service.   |
  ++


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

"oops: 894"

[Scott Michel]

I've got a slightly hosed -current at the moment that complains
with this error message:

# make
oops: 894

followed by a very healthy looking notice about a segfault and
because I'm root in single user mode, core dumps are abounding.

Since I'm DITW at the moment, anyone got a clue? This Windows
thing is not an environment I want to get used to...


-scooter

(*) I could boot up a 3.2 CD, but solving this 'oops', which
looks like a ld.so problem seems pretty important.



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

Re: System crash on "vinum start"

[Rodney W. Grimes]

> As Rodney W. Grimes wrote ...
> > > On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
> > > >  Good software shouldn't panic.
> > > I wish _I_ could convince some people of this :-(.
> 
> > > rather than having to recover each logical volume.  It would also be
> > > nice if you could recover mirrored root/swap without needing to
> > > unmirror and re-mirror them.
> > 
> > Hummm.. this may seem like a really stange question, but I'll throw
> > it out anyway:
> > 
> > Would $9,000 paid to a developer here with immediate time avaliable
> > bring FreeBSD 3.x to a state of being able to replace our current use
> > of hardware raid to do Raid-1 mirroring with hot swap automagic
> > rebuild capabilities?  (It would need to be production quality code
> > for very serious business, and completed in 3 weeks time.)
> > 
> > Serious responses only please.
> 
> Rod,
> 
> Being in the hardware RAID business myself I cannot help asking: why do you
> want to loose the hardware RAID in favor of a software solution? Flexibility
> (just guessing) or price maybe?

Because DPT has screwed this customer over for the last time...


-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


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

Re: System crash on "vinum start"

[Wilko Bulte]

As Rodney W. Grimes wrote ...
> > On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
> > >  Good software shouldn't panic.
> > I wish _I_ could convince some people of this :-(.

> > rather than having to recover each logical volume.  It would also be
> > nice if you could recover mirrored root/swap without needing to
> > unmirror and re-mirror them.
> 
> Hummm.. this may seem like a really stange question, but I'll throw
> it out anyway:
> 
> Would $9,000 paid to a developer here with immediate time avaliable
> bring FreeBSD 3.x to a state of being able to replace our current use
> of hardware raid to do Raid-1 mirroring with hot swap automagic
> rebuild capabilities?  (It would need to be production quality code
> for very serious business, and completed in 3 weeks time.)
> 
> Serious responses only please.

Rod,

Being in the hardware RAID business myself I cannot help asking: why do you
want to loose the hardware RAID in favor of a software solution? Flexibility
(just guessing) or price maybe?

Wilko
-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : 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: just found this

[Warner Losh]

In message <[EMAIL PROTECTED]> Kenneth 
Culver writes:
: Check this out, if anyone is intrested.
: 
: I found this on packetstorm.securify.com tonight. Any ideas??

Mycroft sent this out after we had fixed this before the 3.3R
release.  At least it appeared in bugtraq after it had been fixed in
FreeBSD, as far as I can tell.

Warner


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

Re: New PnP code does not work for me(?)

[Peter Wemm]

Doug Rabson wrote:
> On Mon, 27 Sep 1999, Andrew Sparrow wrote:
> 
> > 
> > > : case 0x31008c0e: /* CTL0031 */
> > > : case 0x41008c0e: /* CTL0041 */
> > > : case 0x42008c0e: /* CTL0042 */
> > > : +   case 0x44008c0e: /* CTL0044 */
> > > : case 0x45008c0e: /* CTL0045 */
> > 
> > > What is CTL0043?  Seems like a logical progression to me :-)
> > 
> > > Warner

switch(logical_id) {
>>  case 0x43008c0e: /* CTL0043 */
case 0x01008c0e: /* CTL0001 */
s = "Vibra16X";
break;
 
case 0x31008c0e: /* CTL0031 */
case 0x41008c0e: /* CTL0041 */
case 0x42008c0e: /* CTL0042 */
case 0x44008c0e: /* CTL0044 */
case 0x45008c0e: /* CTL0045 */
s = "SB16 PnP";
break;




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: just found this

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Ville-Pertti Keinonen writ
es:

n>Actual use obviously shouldn't include cached data.  Can you say off
>the top of your head whether v_holdcnt applies to anything other than
>v_cache_src and non-VM buffer-cache (struct buf) stuff?

Sorry, no, can't answer without looking.

>If not, then v_usecount == 0 could be considered non-use without
>worrying about v_holdcnt, since most vnodes with cached data are going
>to have an associated vm_object holding a real reference.
>
>> >BTW: You still haven't committed the v_id patch I sent you in May.  Is
>> >there any specific reason for this?
>> 
>> I seem to remember we stalled on some detail which wouldn't or
>> couldn't work was it NFS ?
>
>No, there was a completely unrelated NFS bug I ran into while looking
>into it (which has been fixed), the last comment from you seemed to
>imply that you were going to commit the patch.

Sorry, we must have missed each other.  I understood that since
NFS held "soft references" it was pointless.  Send me the patch
again and lets resume that one.

--
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: ESS1869 logical ID

[Wang Shidong]

On Tue, Sep 28, 1999 at 09:48:42AM +0100, Doug Rabson wrote:
> On Tue, 28 Sep 1999, Wang Shidong wrote:
> 
> > Following the suggestion of Mr. Peter Wemm, I manage to get my ESS1869
> > sound card work again. The attachments are the `dmesg' message and the
> > `pnpinfo -v' output. I am grateful if the ID can be added.
> > 
> > Thank you very much.
> 
> Can you confirm that this patch matches your card:

It works.


unknown0:  on isa0
pcm0:  at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
unknown1:  at port 0x201 on isa0
unknown2:  at port 0x168-0x16f,0x36e-0x36f irq 9 
on isa0


Thank you very much.

> 
> Index: sb.c
> ===
> RCS file: /home/ncvs/src/sys/dev/pcm/isa/sb.c,v
> retrieving revision 1.24
> diff -u -r1.24 sb.c
> --- sb.c  1999/09/28 08:25:08 1.24
> +++ sb.c  1999/09/28 08:46:26
> @@ -1274,6 +1274,10 @@
>   case 0x68187316: /* ESS1868 */
>   s = "ESS1868";
>   break;
> +
> + case 0x69187316: /* ESS1869 */
> + s = "ESS1869";
> + break;
>   }
>   if (s) {
>   device_set_desc(dev, s);
> 
> --
> Doug Rabson   Mail:  [EMAIL PROTECTED]
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
---end quoted text---

regards,
Wang Shidong


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

Re: just found this

[Ville-Pertti Keinonen]

> >If you want to include the other attack I mentioned (I just tried it,
> >got up to > 16 vnodes), then you have to exclude vnodes that are
> >only live because of v_cache_src entries from the count.
> 
> It should probably only count vnodes in "actual" use.

There's no counter for that currently.  Counting non-zero v_usecount
vs. non-zero v_holdcnt separately would be reasonably easy.

Actual use obviously shouldn't include cached data.  Can you say off
the top of your head whether v_holdcnt applies to anything other than
v_cache_src and non-VM buffer-cache (struct buf) stuff?

If not, then v_usecount == 0 could be considered non-use without
worrying about v_holdcnt, since most vnodes with cached data are going
to have an associated vm_object holding a real reference.

> >BTW: You still haven't committed the v_id patch I sent you in May.  Is
> >there any specific reason for this?
> 
> I seem to remember we stalled on some detail which wouldn't or
> couldn't work was it NFS ?

No, there was a completely unrelated NFS bug I ran into while looking
into it (which has been fixed), the last comment from you seemed to
imply that you were going to commit the patch.

There were lots of details that needed further attention in my
experiments for actually deallocating vnodes, but those patches
certainly weren't supposed to be committed.


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

Call for projects

[Jeroen Ruigrok/Asmodai]

Since no-one except Poul-Henning gave a start with this I thought I
might try my hand at this.

Given FreeBSD's rapid development over the last year a lot of things
around the releases have changed. Nik Clayton and his team are doing a
terrific job to keep up with the documentation.

However, what has been lacking, at least in my opinion, is the lack of
alerting less advanced, more time-restrained, however you wish to call
it, hackers of tasks which need to be fixed in FreeBSD. The PR system is
nice and works pretty well [thanks to a lot of people] but it is not
what I meant with my above words.

What I did mean though, is that when someone messes with source code at
large in FreeBSD to let the hacker/developer-community know of these
changes plus point out some areas which need to be fixed/looked-out with
these patches in place. Small-term projects.

Also, put out more patches on either -hackers or -current [depending on
what platform the patches aim at] and call for more test reviews to
eliminate more and more initial bugs upon introducing.

Plus, let the doc guys know what changes have been made and in which
places the docs should be altered. Doesn't take much, but remember that
not every docperson is a kernel hacker and vice versa, so UTSL, how well
intended doesn't always help in these cases.

All of this is merely a call for clearer communication between the
diverse efforts within the project as a whole and external hackers with
no access to the repository but who wish to send-pr diffs/patches to fix
up forgotten/neglected/overseen areas in the code.

Thanking you all in advance for helping on this.
It's together we make this project work...

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Any fool can make a rule  And every fool will mind it.


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

Re: just found this

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Ville-Pertti Keinonen writ
es:

>> The easiest way to detect this DOS is probably to keep track of the
>> 
>>  namecache entries
>>  -
>>  live vnodes
>> 
>> ratio, and enforce an upper limit on it.
>
>That seems like a reasonable approach.
>
>If you want to include the other attack I mentioned (I just tried it,
>got up to > 16 vnodes), then you have to exclude vnodes that are
>only live because of v_cache_src entries from the count.

It should probably only count vnodes in "actual" use.

>BTW: You still haven't committed the v_id patch I sent you in May.  Is
>there any specific reason for this?

I seem to remember we stalled on some detail which wouldn't or
couldn't work was it NFS ?

--
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: just found this

[Ville-Pertti Keinonen]

> I have been mulling over this issue for some time.  My current thinking
> is that pending some more well thought out mechanism, the right thing
> to do here is to detect the DOS and react to that, not to handicap
> the caching in general.
> 
> The easiest way to detect this DOS is probably to keep track of the
> 
>   namecache entries
>   -
>   live vnodes
> 
> ratio, and enforce an upper limit on it.

That seems like a reasonable approach.

If you want to include the other attack I mentioned (I just tried it,
got up to > 16 vnodes), then you have to exclude vnodes that are
only live because of v_cache_src entries from the count.

BTW: You still haven't committed the v_id patch I sent you in May.  Is
there any specific reason for this?


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

Re: Experimental ACPI driver.

[Ilya Naumov]

$BWT(B , 28 $BSE(B1999, $BwY(B $BNAPISALI(B:

> Apply this patch.

thanks, it works:

ACPI: Found ACPI BIOS data at 0xc00f6c10 (<123456>, RSDT@7ff3000)
acpi0: <123456> on motherboard
acpi0: ADDR RANGE 7ff3000 d000 (mapped 0xc779c000)
acpi0: ADDR RANGE 7ff 3000 (mapped 0xc77a9000)
acpi0: RSDT have 2 entries
acpi0: RSDT entry0 FACP
acpi0:  FACP found
acpi0:  DSDT found Size=8812 bytes
acpi0:  FACS Found Size=64 bytes
acpi0: RSDT entry1 BOOT
acpi0: at 0xb2 irq 9

so, what does mean? :) 

-- 

sincerely,
ilya naumov (at work)


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

Re: just found this

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Ville-Pertti Keinonen writes:
>
>Replying to myself...
>
>> Looking at the code, it would seem that the number of directories is
>> what's causing problems (one is created for each link).  The directory
>> vnodes can't be thrown out because a name cache entry exists in each
>> one.  All of the name cache entries point to the same vnode, which
>> can't be thrown out because it is open.
>
>My initial guess wasn't correct (I mis-read the program due to the
>lack of indentation) - huge amounts of memory actually are consumed by
>name cache entries, not just vnodes...
>
>Balancing the sizes of multiple caches can get quite interesting.

I have been mulling over this issue for some time.  My current thinking
is that pending some more well thought out mechanism, the right thing
to do here is to detect the DOS and react to that, not to handicap
the caching in general.

The easiest way to detect this DOS is probably to keep track of the

namecache entries
-
live vnodes

ratio, and enforce an upper limit on it.


--
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: just found this

[Ville-Pertti Keinonen]

Replying to myself...

> Looking at the code, it would seem that the number of directories is
> what's causing problems (one is created for each link).  The directory
> vnodes can't be thrown out because a name cache entry exists in each
> one.  All of the name cache entries point to the same vnode, which
> can't be thrown out because it is open.

My initial guess wasn't correct (I mis-read the program due to the
lack of indentation) - huge amounts of memory actually are consumed by
name cache entries, not just vnodes...

Setting a limit for the number of entries in the name cache should be
more acceptable if actual directory data blocks were cached more
efficiently, which I believe has been implemented in -current by Matt
Dillon, but it isn't enabled by default because of the wasteful use of
entire memory pages.  Even if making it the default were acceptable
(IMHO it isn't) it still doesn't make fixing things easy because there
is no longer a LRU policy for name cache entries, they are merely
associated with vnodes.

Balancing the sizes of multiple caches can get quite interesting.

> This should actually be fixed by something I did as part of some
> patches I played with earlier this year, avoiding the need to force
> parent directories of vnodes to be kept in memory.  I'll try to come
> up with a version that works against -current and doesn't contain of
> the other (experimental) features of the earlier patches.  IIRC the
> part required to allow parent vnodes to be reused is quite simple.

This was trivial, and it did sort of help, but only to the extent that
it made the DoS harder, requiring other programs to be run to increase
the vnode allocation count first.

It fixes another potential DoS attack (create a file, keep it open,
create a huge number of directories, each with a link to the file,
none of the directory vnodes can be deallocated), so I'll include it
anyhow.  It does have some negative impact on caching behavior so it
probably isn't desirable until an improved vnode caching policy can be
introduced.  The changes (against -current, but should be trivially
modifiable for 3.x) are:

Index: vfs_cache.c
===
RCS file: /m/cvs/freebsd/src/sys/kern/vfs_cache.c,v
retrieving revision 1.40
diff -u -r1.40 vfs_cache.c
--- vfs_cache.c 1999/08/28 00:46:23 1.40
+++ vfs_cache.c 1999/09/28 11:04:22
@@ -122,8 +122,6 @@
 {
LIST_REMOVE(ncp, nc_hash);
LIST_REMOVE(ncp, nc_src);
-   if (LIST_EMPTY(&ncp->nc_dvp->v_cache_src)) 
-   vdrop(ncp->nc_dvp);
if (ncp->nc_vp) {
TAILQ_REMOVE(&ncp->nc_vp->v_cache_dst, ncp, nc_dst);
} else {
@@ -292,8 +290,6 @@
bcopy(cnp->cn_nameptr, ncp->nc_name, ncp->nc_nlen);
ncpp = NCHHASH(dvp, cnp);
LIST_INSERT_HEAD(ncpp, ncp, nc_hash);
-   if (LIST_EMPTY(&dvp->v_cache_src))
-   vhold(dvp);
LIST_INSERT_HEAD(&dvp->v_cache_src, ncp, nc_src);
if (vp) {
TAILQ_INSERT_HEAD(&vp->v_cache_dst, ncp, nc_dst);
Index: vfs_subr.c
===
RCS file: /m/cvs/freebsd/src/sys/kern/vfs_subr.c,v
retrieving revision 1.228
diff -u -r1.228 vfs_subr.c
--- vfs_subr.c  1999/09/21 00:36:15 1.228
+++ vfs_subr.c  1999/09/28 11:04:33
@@ -523,10 +523,6 @@
TAILQ_REMOVE(&vnode_free_list, vp, v_freelist);
TAILQ_INSERT_TAIL(&vnode_tmp_list, vp, v_freelist);
continue;
-   } else if (LIST_FIRST(&vp->v_cache_src)) {
-   /* Don't recycle if active in the namecache */
-   simple_unlock(&vp->v_interlock);
-   continue;
} else {
break;
}



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

patch: v_maxio -> mnt_maxio

[Poul-Henning Kamp]

This patch moves the maxio information from all vnodes to the 
mountpoint.  It is a property of the device being mounted, not
of the individual vnodes on the mounted device.

Poul-Henning

Index: kern/vfs_cluster.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_cluster.c,v
retrieving revision 1.90
diff -u -r1.90 vfs_cluster.c
--- vfs_cluster.c   1999/09/20 19:53:23 1.90
+++ vfs_cluster.c   1999/09/28 08:41:26
@@ -106,7 +106,7 @@
 * Try to limit the amount of read-ahead by a few
 * ad-hoc parameters.  This needs work!!!
 */
-   racluster = vp->v_maxio/size;
+   racluster = vp->v_mount->mnt_maxio/size;
maxra = 2 * racluster + (totread / size);
if (maxra > MAXRA)
maxra = MAXRA;
@@ -363,7 +363,7 @@
for (bn = blkno, i = 0; i < run; ++i, bn += inc) {
if (i != 0) {
if ((bp->b_npages * PAGE_SIZE) +
-   round_page(size) > vp->v_maxio)
+   round_page(size) > vp->v_mount->mnt_maxio)
break;
 
if ((tbp = incore(vp, lbn + i)) != NULL) {
@@ -556,7 +556,7 @@
 
if (vp->v_clen == 0 || lbn != vp->v_lastw + 1 ||
(bp->b_blkno != vp->v_lasta + btodb(lblocksize))) {
-   maxclen = vp->v_maxio / lblocksize - 1;
+   maxclen = vp->v_mount->mnt_maxio / lblocksize - 1;
if (vp->v_clen != 0) {
/*
 * Next block is not sequential.
@@ -761,7 +761,7 @@
  ((bp->b_blkno + (dbsize * i)) !=
tbp->b_blkno) ||
  ((tbp->b_npages + bp->b_npages) >
-   (vp->v_maxio / PAGE_SIZE))) {
+   (vp->v_mount->mnt_maxio / PAGE_SIZE))) {
BUF_UNLOCK(tbp);
splx(s);
break;
Index: kern/vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.228
diff -u -r1.228 vfs_subr.c
--- vfs_subr.c  1999/09/21 00:36:15 1.228
+++ vfs_subr.c  1999/09/28 08:41:40
@@ -593,7 +593,6 @@
*vpp = vp;
vp->v_usecount = 1;
vp->v_data = 0;
-   vp->v_maxio = DFLTPHYS;
splx(s);
 
vfs_object_create(vp, p, p->p_ucred);
Index: kern/vfs_syscalls.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.136
diff -u -r1.136 vfs_syscalls.c
--- vfs_syscalls.c  1999/09/25 14:14:21 1.136
+++ vfs_syscalls.c  1999/09/28 08:47:32
@@ -278,6 +278,7 @@
strncpy(mp->mnt_stat.f_fstypename, vfsp->vfc_name, MFSNAMELEN);
mp->mnt_vnodecovered = vp;
mp->mnt_stat.f_owner = p->p_ucred->cr_uid;
+   mp->mnt_maxio = DFLTPHYS;
VOP_UNLOCK(vp, 0, p);
 update:
/*
Index: miscfs/specfs/spec_vnops.c
===
RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v
retrieving revision 1.114
diff -u -r1.114 spec_vnops.c
--- spec_vnops.c1999/09/25 18:52:03 1.114
+++ spec_vnops.c1999/09/28 08:42:11
@@ -251,13 +251,6 @@
if (!dev->si_bsize_phys)
dev->si_bsize_phys = DEV_BSIZE;
}
-   maxio = dev->si_iosize_max;
-   if (!maxio)
-   maxio = DFLTPHYS;
-   if (maxio > MAXPHYS)
-   maxio = MAXPHYS;
-   vp->v_maxio = maxio;
-
return (error);
 }
 
Index: sys/mount.h
===
RCS file: /home/ncvs/src/sys/sys/mount.h,v
retrieving revision 1.79
diff -u -r1.79 mount.h
--- mount.h 1999/09/19 06:24:21 1.79
+++ mount.h 1999/09/28 08:36:42
@@ -110,6 +110,7 @@
struct statfs   mnt_stat;   /* cache of filesystem stats */
qaddr_t mnt_data;   /* private data */
time_t  mnt_time;   /* last time written*/
+   u_int   mnt_maxio;  /* Max io request size */
 };
 
 /*
Index: sys/vnode.h
===
RCS file: /home/ncvs/src/sys/sys/vnode.h,v
retrieving revision 1.101
diff -u -r1.101 vnode.h
--- vnode.h 1999/09/21 00:36:15 1.101
+++ vnode.h 1999/09/28 08:36:52
@@ -111,7 +111,6 @@
daddr_t v_cstart;   /* start block of cluster */
daddr_t v_lasta;/* last allocation */
int v_clen; /* length of current cluster */
-   int v_maxio;/* maximum I/O cluster size */
struct vm_object *

Re: just found this

[Ville-Pertti Keinonen]

Kenneth Culver <[EMAIL PROTECTED]> writes:

> I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM,
> and it chugged along to about `02/03000' (meaning it created 3 files
> and about 63000 or so links), consuming a whopping 34MB of wired
> kernel memory (according to `top'), before all file system activity
> came to a screeching halt and the machine was unusable.

Looking at the code, it would seem that the number of directories is
what's causing problems (one is created for each link).  The directory
vnodes can't be thrown out because a name cache entry exists in each
one.  All of the name cache entries point to the same vnode, which
can't be thrown out because it is open.

So the main problem here is that one open vnode can be used to lock in
an arbitrary number of vnodes.

This should actually be fixed by something I did as part of some
patches I played with earlier this year, avoiding the need to force
parent directories of vnodes to be kept in memory.  I'll try to come
up with a version that works against -current and doesn't contain of
the other (experimental) features of the earlier patches.  IIRC the
part required to allow parent vnodes to be reused is quite simple.


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

Re: New PnP code does not work for me(?)

[Doug Rabson]

On Mon, 27 Sep 1999, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> Doug Rabson 
>writes:
> : case 0x31008c0e: /* CTL0031 */
> : case 0x41008c0e: /* CTL0041 */
> : case 0x42008c0e: /* CTL0042 */
> : +   case 0x44008c0e: /* CTL0044 */
> : case 0x45008c0e: /* CTL0045 */
> 
> What is CTL0043?  Seems like a logical progression to me :-)

CTL0043 is a vibra16x which is slightly different (and is matched by
another part of the switch).

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Loss of Functionality with newpnp

[Rodney W. Grimes]

[Reinsertion of original answer by jkh]

> > > That work is underway, and something to understand about -current
> > > is that it doesn't have to actually work at all times during the
> > > interim periods between releases.  Now, should 4.0 be on the horizon
> > > and the situation still be one where "equivalent functionality"
> > > has not been provided by the newpcm driver, we'll revert back to
> > > the original luigi driver and continue the experiment in the new
> > > post-branch (5.0) current.
[end reinsertion]

> > If that was only true.  Or should I ask why didn't CAM from -3.3 get
> > reverted to the old scsi code before 3.3 was released.  I have seen
> > no less than 2, and perhaps 3 people try to get cards that did work
> > under pre-CAM 3.x working under post-CAM 3.x.  I know this is a slippery
> > slope, but it invalidates your above assertion that we revert back
> > at release when functionality has been lost due to new code.
> 
> No, it doesn't invalidate it in any way shape or form.  I said that in
> this specific case, and you're free to read my message as many times
> as you wish but you'll not find anything saying I was speaking for
> anything BUT the newpcm driver here, the new stuff would be reverted
> if need be.

By implication the first sentence of your response seems to indicate
that only between releases should functionality be lost.  I'll agree
that you only specifically sited the newpcm driver.

>  CAM was a rather different situation since it was one of
> those painful-but-necessary trade-offs we had to accept both the pros
> and the cons for.  The a.out -> ELF transition was painful too, and
> I'm sure there were a few ports which broke and/or older commercial
> software packages which became harder to use as a result, but you
> won't hear anyone talking about going back to a.out for just that
> reason.
> 
> Each situation is different and there are NO hard-and-fast rules about
> when it does and does not make sense to accept the loss of certain
> functionality in exchange for new functionality.  To even assume
> that such a rule would be practical would be like saying that life
> itself always fits into neat, well-compartmentalized little boxes. :)

And I won't disagree here either, but I will re-phrase, once FreeBSD
has made the decision to go forward, with the understanding that
some functionality is being lost, it has never made the step backwards.
Which, IMHO, is _good_.  But saying FreeBSD would step backwards if
newpcm was missing ``equivalent functionality'' at 4.0, again IMHO,
is an overstatement.

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


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

Re: New PnP code does not work for me(?)

[Doug Rabson]

On Mon, 27 Sep 1999, Andrew Sparrow wrote:

> 
> > :   case 0x31008c0e: /* CTL0031 */
> > :   case 0x41008c0e: /* CTL0041 */
> > :   case 0x42008c0e: /* CTL0042 */
> > : + case 0x44008c0e: /* CTL0044 */
> > :   case 0x45008c0e: /* CTL0045 */
> 
> > What is CTL0043?  Seems like a logical progression to me :-)
> 
> > Warner
> 
> And me. Built-in sound on a Micron W6-Li SMP socket 8 board:
> 
> Card assigned CSN #2
> Vendor ID CTL00f0 (0xf0008c0e), Serial Number 0x
> PnP Version 1.0, Vendor Version 16
> Device Description: Creative ViBRA16X PnP
> 
> Logical Device ID: CTL0043 0x43008c0e #0
> Device Description: Audio
> 
> 
> 
> 
> Also, for the sake of completeness, an add-on ISA WaveBlaster card
> (supposed to make an SB16 equivalent to an AWE32, not recognised
> by any driver I've tried so far):
> 
> Card assigned CSN #1
> Vendor ID CTL00a5 (0xa5008c0e), Serial Number 0x0001c333
> PnP Version 1.0, Vendor Version 16
> Device Description: Creative EMU8000 PnP
> 
> Logical Device ID: CTL0021 0x21008c0e #0
> Device Description: WaveTable
> TAG Start DF

Well this is the same logical ID as the WaveTable on the AWE32 which makes
sense. If the awe driver is ported over to the new pnp format, it will be
easy to add this ID. (Does the old awe driver support AWE32 as well as
AWE64?).

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: ESS1869 logical ID

[Doug Rabson]

On Tue, 28 Sep 1999, Wang Shidong wrote:

> Following the suggestion of Mr. Peter Wemm, I manage to get my ESS1869
> sound card work again. The attachments are the `dmesg' message and the
> `pnpinfo -v' output. I am grateful if the ID can be added.
> 
> Thank you very much.

Can you confirm that this patch matches your card:

Index: sb.c
===
RCS file: /home/ncvs/src/sys/dev/pcm/isa/sb.c,v
retrieving revision 1.24
diff -u -r1.24 sb.c
--- sb.c1999/09/28 08:25:08 1.24
+++ sb.c1999/09/28 08:46:26
@@ -1274,6 +1274,10 @@
case 0x68187316: /* ESS1868 */
s = "ESS1868";
break;
+
+   case 0x69187316: /* ESS1869 */
+   s = "ESS1869";
+   break;
}
if (s) {
device_set_desc(dev, s);

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: New PnP code does not work for me(?)

[Doug Rabson]

On Mon, 27 Sep 1999, Donald J . Maddox wrote:

> Thanks, Doug.  Peter already provided an equivalent patch, and I am
> happy to report that it works like a charm (of course :-)).

Good. The next stage is probably to talk to the midi folks and possibly
see about porting the awe driver.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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

Re: Loss of Functionality with newpnp

[Doug Rabson]

On Mon, 27 Sep 1999, Amancio Hasty wrote:

> > It requires converting the ancient voxware driver to newbus which isn't
> > really feasable.
> 
> I am not sure about that ... The irq handling, card registration on the voxware
> is fairly straight forward. 

It seems that the awe-specific driver is fairly separated from voxware so
perhaps that won't be too hard to port.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




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