Julian Elischer scribbled this message on Sep 10:
> At least one person has already written this program...
>
> THeey have mentionned this in the hackers list so maybe a search of the
> list may turn something up..
> withing th last 2 years from memory.
actually, it should be part of my ffsrecov
Julian Elischer scribbled this message on Sep 10:
> At least one person has already written this program...
>
> THeey have mentionned this in the hackers list so maybe a search of the
> list may turn something up..
> withing th last 2 years from memory.
actually, it should be part of my ffsreco
(sorry if this appears here twice - but as far as i can see the first
try didn't make it here due to non optimal configuration of my news
to mailinglist gateway :-)
i'm a bit at the end of my phantasie with this machine i'm writing
this here on ... something mystically seems to be broken with
runn
(sorry if this appears here twice - but as far as i can see the first
try didn't make it here due to non optimal configuration of my news
to mailinglist gateway :-)
i'm a bit at the end of my phantasie with this machine i'm writing
this here on ... something mystically seems to be broken with
run
On Mon, 13 Sep 1999, Matthew Dillon wrote:
> The case that is causing the panics is with the non-interrupt mbuf
> allocation mechanism. Specifically, the case where M_WAIT is used.
>
> The second problem under discussion, which really ought to be separated
> out from the mbuf pan
On Mon, 13 Sep 1999, Matthew Dillon wrote:
> The case that is causing the panics is with the non-interrupt mbuf
> allocation mechanism. Specifically, the case where M_WAIT is used.
>
> The second problem under discussion, which really ought to be separated
> out from the mbuf pa
:In 4.3, the code was able to deal with cluster allocation failing. We
:have a somewhat different situation now, because many network
:interface devices have less-flexible DMA mechanisms which don't allow
:packet reception into non-contiguous buffers, so we need to have at
:least a certain number
:In 4.3, the code was able to deal with cluster allocation failing. We
:have a somewhat different situation now, because many network
:interface devices have less-flexible DMA mechanisms which don't allow
:packet reception into non-contiguous buffers, so we need to have at
:least a certain number
I think that what needs to be done is to split the problem in two. First,
allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
is used, it simply means 'try harder, sleeping a bit if necessary'. This
requires ensuring that all the networking code deal with the
:Matthew Dillon wrote:
:> :Tony Finch wrote:
:...
:>
:> Hmm... well, there is a problem here. I believe this will allow
:> you to open the underlying block device read-only as well as mount
:> the filesystem read-only. This will confuse the buffer cache badly.
:
:I don't think so
:Our ftp server crashed early this morning with what appears to be a softupdates
:error:
:
:> Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on
/exports/share3/ftp/.2: file system full
:>
:> panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568
:> syncing disks...
:Tony Finch wrote:
:
:Well, in the absence of any comments I hacked around a bit and ended
:up with the following patch (against 3.3-RC), which permits the same
:block device to be mounted read-only more than once. The motivation
:for this is to permit multiple chrooted environments to share the s
:
:http://www.boston.com/dailyglobe2/259/business/Even_better_than_Linux+.shtm
:l
Neato! But next time don't line-break the URL :-)
-Matt
Matthew Dillon
To Unsubscribe:
I think that what needs to be done is to split the problem in two. First,
allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT
is used, it simply means 'try harder, sleeping a bit if necessary'. This
requires ensuring that all the networking code deal with th
> I would also add that you can "fake" a minor number by simple
> multiplication. You have to assume how many digits you want
> to allow in minor numbers.
>
> For example, if we assume a minor number has no more than 3
> digits (allowing the minor numbers to grow to 999) then,
> M.N can readil
:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:> :Tony Finch <[EMAIL PROTECTED]> wrote:
:...
:>
:> Hmm... well, there is a problem here. I believe this will allow
:> you to open the underlying block device read-only as well as mount
:> the filesystem read-only. This will confuse the b
:Our ftp server crashed early this morning with what appears to be a softupdates
:error:
:
:> Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on /exports/share3/ftp/.2:
:file system full
:>
:> panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568
:> syncing disks..
:Tony Finch <[EMAIL PROTECTED]> wrote:
:
:Well, in the absence of any comments I hacked around a bit and ended
:up with the following patch (against 3.3-RC), which permits the same
:block device to be mounted read-only more than once. The motivation
:for this is to permit multiple chrooted environ
:
:http://www.boston.com/dailyglobe2/259/business/Even_better_than_Linux+.shtm
:l
Neato! But next time don't line-break the URL :-)
-Matt
Matthew Dillon
<[EMAIL PROTECTED
> I would also add that you can "fake" a minor number by simple
> multiplication. You have to assume how many digits you want
> to allow in minor numbers.
>
> For example, if we assume a minor number has no more than 3
> digits (allowing the minor numbers to grow to 999) then,
> M.N can readi
>
> In a discussion with Nate Williams, I have learned that the reason FreeBSD
> doesn't use minor numbers with shared libraries because standard ELF doesn't
> support it. Is this a hard-and-fast unbreakable rule, or is this something
> that could be implemented if it can be done in a way that's c
>
> In a discussion with Nate Williams, I have learned that the reason FreeBSD
> doesn't use minor numbers with shared libraries because standard ELF doesn't
> support it. Is this a hard-and-fast unbreakable rule, or is this something
> that could be implemented if it can be done in a way that's
i've just upgraded one of my machines here at work to -current
and enabled the ata stuff - but after rebooting it says "cannot
mount root" - earlier then i tried this with -current it was
working fine and transparent (i.e. without anything to change
from wd0 to ad0) - so the question - did anything
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT)
Mohit Aron wrote:
...well, I'm speaking from the NetBSD perspective, but it's the same
in FreeBSD, because both use the OSF/1 PALcode...
> as I understand it, TLB misses on the alpha are handled by the
> software (as opposed to x86 where they ar
i've just upgraded one of my machines here at work to -current
and enabled the ata stuff - but after rebooting it says "cannot
mount root" - earlier then i tried this with -current it was
working fine and transparent (i.e. without anything to change
from wd0 to ad0) - so the question - did anythin
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT)
Mohit Aron <[EMAIL PROTECTED]> wrote:
...well, I'm speaking from the NetBSD perspective, but it's the same
in FreeBSD, because both use the OSF/1 PALcode...
> as I understand it, TLB misses on the alpha are handled by the
> software (as opposed
As mtv 1.1 is producing unusable stuttering audio on 3.3-RC (I know,
I'll cvsup tonite..) I wonder if someone has an older version for
me to try.
W/
--
| / o / / _ Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www
In a discussion with Nate Williams, I have learned that the reason FreeBSD
doesn't use minor numbers with shared libraries because standard ELF doesn't
support it. Is this a hard-and-fast unbreakable rule, or is this something
that could be implemented if it can be done in a way that's compatible w
As mtv 1.1 is producing unusable stuttering audio on 3.3-RC (I know,
I'll cvsup tonite..) I wonder if someone has an older version for
me to try.
W/
--
| / o / / _ Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://ww
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general res
In a discussion with Nate Williams, I have learned that the reason FreeBSD
doesn't use minor numbers with shared libraries because standard ELF doesn't
support it. Is this a hard-and-fast unbreakable rule, or is this something
that could be implemented if it can be done in a way that's compatible
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general re
As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple
routes to the same destination (identical key and mask). Does the radix
tree code in FreeBSD - 4.0 has the same limitation? I am wondering if
there is already a solution for this?
Any help is appreciated.
---
As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple
routes to the same destination (identical key and mask). Does the radix
tree code in FreeBSD - 4.0 has the same limitation? I am wondering if
there is already a solution for this?
Any help is appreciated.
--
It seems Roger Hardiman wrote:
> Hi,
>
> I want to move the Bt848 driver to /sys/dev/bktr
>
> So, does anyone see any problems with this?
Nope, go for it I'd say, and could we then have some of all the
version text and stuff put away too, thats why we have CVS :)
-Soren
To Unsubscribe: send m
Hi,
I want to move the Bt848 driver to /sys/dev/bktr
Here is why.
The Bt848 driver (bktr) is contained in one file
(/sys/pci/brooktree848.c) and currently runs to about 7000 lines.
I've broken the driver down into 4 smaller files which cleanly
splits the functionality (tuner, audio, card pr
It seems Roger Hardiman wrote:
> Hi,
>
> I want to move the Bt848 driver to /sys/dev/bktr
>
> So, does anyone see any problems with this?
Nope, go for it I'd say, and could we then have some of all the
version text and stuff put away too, thats why we have CVS :)
-Soren
To Unsubscribe: send
On Thu, Sep 16, 1999 at 11:25:53PM -0700, Doug White wrote:
[...]
> An update:
>
> I set up a test config at work with some spare boxes. I found that if you
> specify an aliasIP that is the primary alias address (as determined by the
> -n or -a options), those redirections will be ignored. Other
Hi,
I want to move the Bt848 driver to /sys/dev/bktr
Here is why.
The Bt848 driver (bktr) is contained in one file
(/sys/pci/brooktree848.c) and currently runs to about 7000 lines.
I've broken the driver down into 4 smaller files which cleanly
splits the functionality (tuner, audio, card p
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
j = 0;
> if (flag)
> j = 1;
>
Gregory Bond writes:
> Us humans can see that j is not used without being set, but cc can't. How do
> I
> remove this warning in a style(9)-compatible way?
Initialize j.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe
On Thu, Sep 16, 1999 at 11:25:53PM -0700, Doug White wrote:
[...]
> An update:
>
> I set up a test config at work with some spare boxes. I found that if you
> specify an aliasIP that is the primary alias address (as determined by the
> -n or -a options), those redirections will be ignored. Othe
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
j = 0;
> if (flag)
> j = 1;
>
Gregory Bond <[EMAIL PROTECTED]> writes:
> Us humans can see that j is not used without being set, but cc can't. How do I
> remove this warning in a style(9)-compatible way?
Initialize j.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote:
> Would not the 'panic' option in DDB be enough to handle this, or
> am I missing something?
He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote:
> Would not the 'panic' option in DDB be enough to handle this, or
> am I missing something?
He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
>
> if (flag)
> j = 1;
>
> /*
> * This noop statement is enough to
On Thu, 16 Sep 1999, Mohit Aron wrote:
> Hi,
> as I understand it, TLB misses on the alpha are handled by the
> software (as opposed to x86 where they are handled in hardware). Can someone
> help me with the FreeBSD code. I'm trying to locate the kernel code that
> implements the TLB handle
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing "may not be used" warnings:
int
foo(int flag)
{
int j;
if (flag)
j = 1;
/*
* This noop statement is enough to confuse the optimiser so
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
>
> if (flag)
> j = 1;
>
> /*
> * This noop statement is enough t
On Thu, 16 Sep 1999, Mohit Aron wrote:
> Hi,
> as I understand it, TLB misses on the alpha are handled by the
> software (as opposed to x86 where they are handled in hardware). Can someone
> help me with the FreeBSD code. I'm trying to locate the kernel code that
> implements the TLB handl
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing "may not be used" warnings:
int
foo(int flag)
{
int j;
if (flag)
j = 1;
/*
* This noop statement is enough to confuse the optimiser so
> int major;
> dev_t dev;
> struct vnode *vp;
>
> major = ultp_cdevsw.d_maj;
> dev = makedev(major, self->dv_unit)
> vp = SLIST_FIRST(&dev->si_hlist);
if (vfinddev(dev, VCHR, &vp))
VOP_REVOKE(vp, REVOKEALL);
#if 0
> if (vp) {
> VOP_REVOKE(vp. REVOKEALL);
> }
#endif
> rem
53 matches
Mail list logo
