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
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 Rab
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 t
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 C
[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 wh
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 */
> :
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'), befo
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: /hom
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 vno
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
$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
> 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 k
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 approac
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
> >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 curr
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
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 lo
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: /* CT
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
Fr
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 mirrore
> 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 r
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
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 susp
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 rec
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 mayb
>
> 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.
subscribe freebsd-current
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
27 matches
Mail list logo
