On 4/26/07, Hans Petter Selasky <[EMAIL PROTECTED]> wrote:
Hi,
In the new USB stack I have defined the following:
Could you perhaps describe some of the codepaths in the USB stack that
require this behavior?
--
Bosko Milekic <[EMAIL PROTECTED]>
http://www.cr
ojects/
Cheers.
_____.
Bosko Milekic bmile...@dsuper.net |
Network Operations Delphi SuperNet |
http://www.dsuper.net/ an Internet Direct company |
+1.514.281.7500, x233 (phone) +1.514.281.659
This post is regarding that thread on the (PCI) ed being detected as ed1
(as opposed to ed0)... A recent post mentionned the use of the rl device
as opposed to ed... ed _does_ support the PCI device:
Are you running this as root?
<- - - . .
Bosko Milekic http://www.dsuper.net/~bmilekic/
Network Operations - Delphi SuperNet, an Internet Direct company
+1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.
roperly, it would be much appreciated, and would
> certainly help me in my efforts to continue expanding trusted bsd.
>
> Ive included the code below...
>
> Thanks
> Andrew
[snipped]
<- - - . .
Bosko Milekic http://www.dsuper.net/~bmilekic/
Network Operations - Del
This may seem to be a ridiculous question... (sorry)
I have a question specifically regarding sys/vm/swap_pager.c,
I'm not very familiar with sys/vm/*, but I've noticed that the value of
the static int no_swap_space (which is initially set to 1) is almost never
checked. The only times that this v
#x27;d
like to know if there are objections to doing this or, in fact, if there
are any suggestions on how to handle mbuf shortage situations (aside from
just limiting -- although limiting is in itself a good solution and I'm
glad that Brian F. is working on that).
Cheers,
Bosko.
/*
*
very once
in a while so that finally, when the counter would expire, we would return
a deffinate null _even_ if we are M_WAIT, but this can only be implemented
if we make sure that ALL the MGET and company callers check for this
(which would be annoying to do).
Cheers,
Bosko Milekic.
--- /usr
est, I don't think that script kids having to comprimise more than one
account just so they can DoS a box will be much of an issue (if worse
comes to worse, we can limit per gid -as opposed to per uid). With
exhaustion attacks such as these, we're better off just limiting.
Regards,
Bosko
ou
say above, it's dealing with the failure that is the issue.
!>
!>-GAWollman
!>
!>--
!>Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the
same
!>woll...@lcs.mit.edu | O Siem / The fires of freedom
!>Opinions not those of| Dance in the burni
; 2. If memory type is in kernel module, vm.memguard_desc sysctl should be
>configured before loading the module.
>
> --
> Pawel Jakub Dawidek http://www.wheel.pl
> [EMAIL PROTECTED] http://www.FreeBSD.org
> FreeBSD committer
This: bus_teardown_intr(dev, sc->irq, sc->ih) != 0 ); looks pretty odd. See
your ir_detach().
Alex wrote:
> Hi,
>
> I started experimenting with kernel hacking to write an
> infrared device driver. Therfore I read Alexander Langer's
> article on DaemonNews and started modifying the led.c
> examp
Since nobody else has asked this, I think I will:
What network device are you using and with what driver?
Please show the output of `ifconfig -a' when you notice this problem.
Finally, try `ifconfig down' followed by `ifconfig
up' when you notice this, and see if it temporarily
fixes the probl
Shankar Agarwal wrote:
> Hi,
> Can you please tell me when did the MGET function change it
> implementation from using MALLOC to using pool_get to allocate a
mbuf. I
Never. We don't use pool_get(). That's a NetBSD-ism. :-)
The mbuf subsystem uses its own allocator and stats are kept in
s entire thread.
This is exactly my philosophy toward the whole thing. And I can tell you from
previous dealings with companies that use FreeBSD as their main platform that
this is one of the main reasons why.
> -Matt
Regards,
--
Bosko Mil
s more things
> running in the background to cause context switches to
> the non-shared address spaces of other tasks. Put the
> same test to a 4 processor box with 4 NIC cartds, and I
> have no doubt that an identically configured NT box will
> beat the Linux box hands down.
>
cs gathering cheaper would be nice, because
currently doing a 'vmstat -z' is really terrible for performance.
Which reminds me... those of you doing benchmarks, please don't run
'vmstat -z' while you're doing them, it might skew/pessimize your
results.
--
ket looks like.
What are you trying to do, exactly?
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ebuild userland stuff, but
that will wait until the end of all mbuf system modifications.
Comments welcome. Special thanks to Mike Silbersack for already
discussing such issues with me.
Regards,
Bosko
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED
* Patch up userland to deal with all of these changes.
* Get some profiling / optimisation done.
Since my initial post, I have received quite a few hits/requests for the
posted code, and have even received a few comments/suggestions. These
have been most helpful. I invite man
al pages as a consequence, etc. -- and there are more
changes to come), I think that it's safe to say that there is still a
little bit before this goes through.
Regards,
Bosko.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://www.technokratis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ps. :-)
> --
> Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin
> Duke University Email: [EMAIL PROTECTED]
> Department of Computer Science
ve Baukus
> [EMAIL PROTECTED]
> Chiaro Networks ltd.
> Richardson, Texas, USA.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://www.technokratis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
ncluding a data structure,
or even a pointer to the mbuf. So this information can be extracted in
either case.
>
> Ken
> --
> Kenneth Merry
> [EMAIL PROTECTED]
>
>
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
[EMAIL PROTECTED] * http://ww
fs as you'd like cached on the free lists.
> David Greenman
> Co-founder, The FreeBSD Project - http://www.freebsd.org
> Manufacturer of high-performance Internet servers - http://www.terasolutions.com
> Pave the road of life with opportunities.
-Bosko
--
Bosko Milekic *
't
much, as they are both doubly-linked, so insertion/removal is fast).
That's it, roughly. I hope this clears up some things for those of
you who didn't look at the actual code.
Regards,
Bosko.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.
other "pro" opinions on this;
some people have even sent suggestions. So I know that I am not the only
one (not by far, in fact) to see an opportunity to benefit from this.
Either way, I know *I* will be using this code in time to come, so I
suppose the question is:
Would
ail).
>I'm not trying to 'frown upon evolution', unless the particular form of
> evolution is to make the software worse than it was. I *can* be convinced
> that your proposed changes are a good thing and I'm asking you to step up
> to the plate and prove it.
lling to
m_mbmapalloc() when allocations are to be done with M_NOWAIT (i.e. from
interrupts).
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice
ow) == M_DONTWAIT, which
will virtually maintain great performance during interrupts. I've
actually already done this, but it's difficult to see the nice effects of
it as I cannot profile MFREE (since it's a macro) but only m_free, which
is typically called at M_WAIT
On Thu, 6 Jul 2000, Bosko Milekic wrote:
> I've recently had the chance to get some profiling done.
>
> I used metrics obtained from gprof, as well as the (basic block
> length) * (number of executions) metric generated by kernbb. The latter
> revea
PROTECTED]
> http://www.blackhelicopters.org/~mwlucas/
> Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ut can be tuned from loader.
> You can determine which is needed more through a quick netstat -m.
>
> Mike "Silby" Silbersack
Cheers,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
:cputime=infinity:\
> >>> :datasize-cur=22M:\
> >>> :stacksize-cur=8M:\
> >>> :memorylocked-cur=10M:\
> >>> :memoryuse-cur=30M:\
> >>> :filesize=infinity:\
> >>> :coredumpsize=infinity:\
> >>> :maxproc-cur=64:\
> >>> :openfiles-cur=64:\
> >>> :priority=0:\
> >>> :requirehome@:\
> >>> :umask=022:\
For starters, I don't see "sbsize" in there, although it doesn't
sound like something that should be causing a panic() anymore anyway.
Please provide more debugging infos.
Thanks,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
or the patch?
>
> Thanks,
>
> -Jin
Please see sendfile(2).
Regards,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
#15 0xc017bdcb in ip_input ()
> #16 0xc017be2b in ipintr ()
> #17 0xc01f69d5 in swi_net_next ()
> #18 0xc0153881 in sendit ()
> #19 0xc0153975 in sendto ()
> #20 0xc020070d in syscall2 ()
> #21 0xc01f5575 in Xint0x80_syscall ()
> Cannot access memory at address 0xbfbffc8c.
&g
+
> | Chris Costello| This system will self-destruct in five minutes. |
> | [EMAIL PROTECTED] | |
> +---+-+
Later,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Dennis wrote:
> >: Still, I personally believe, that "core" or general "freebsd community"
> >: should explicitly state, that support for binary drivers and support
for
> >: easier inclusion of binary driver or just third party driver is eagerly
> >: encouraged. And as much as possible, easy inclu
Hi Michael,
What version of FreeBSD are you running? If it's not too much trouble,
can you please provide the code you're using to simulate the problem? Are the
TIME_WAIT state connections eventually timing out/disappearing?
Michael wrote:
> If this is not proper place to ask this, let me k
Hey!
These images are hip! :-)
Cheers,
Bosko.
Matthew N. Dodd wrote:
> On Tue, 16 Jan 2001, Poul-Henning Kamp wrote:
> > Isn't there *anybody* here who has a SO/family member/neighbor in the
> > graphic/design business ?
>
> Yes.
>
> http://www.svaha.net/daemon/index.html
>
> --
> | Matthe
n taking some of it on.
Oh, and keep me in the CC; I have no idea if I'm
subscribed to these lists anymore. You should also follow
up to this thread on -net and not on -hackers (trim
-hackers from CC in the future). Thanks and happy
hacking!
Regards,
--
Bosko Mil
(Hello Chris Haalboom? :-))
Hello,
In order to avoid having to type everything again, I'll refer
to the commit log. PLEASE READ IT IN FULL:
Bring in mbuma to replace mballoc.
mbuma is an Mbuf & Cluster allocator built on top of a number of
extensions to the UMA framework, all included here
> Bosko,
[deletia]
> are you going to convert mbuf tag allocator to UMA? Now
>tags are allocated with malloc(). AFAIK, tags are used heavily in pf,
>and forthcoming ALTQ. Moving to UMA should affect their performance
>positively.
First off, malloc() *is* UMA. With mbuma in the tree, I don'
seeing what you come up with,
as this could be a very useful diagnostic tool.
-Bosko
--
Bosko Milekic <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
"For the wicked / Carry us away / Captivity require from us a song /
How can we sing king alpha's song in a strange land?" --Bob M
I wrote:
Another option to look into would be to implement a sysctl(8)-exported
handler that iterates over the mbuf chain and prints out the mbuf chains
in something like XML, which your userland application can then more or less
easily parse, and reproduce the chain ("fake it up") in user
going to bed but my INBOX awaits.
> Mike "Silby" Silbersack
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ng.
> please tell me.
> thanx in advance.
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
cal memory or until you exhaust the kmem_map virtual address
space, whichever comes first.
> is there any configuration we can do depending on our
> RAM size?
> please reply.
> thx
> vishwanath
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTE
> --
> Dan Nelson
> [EMAIL PROTECTED]
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ihui
It actually has to do with the fact that 2K is the only size equal to
or greater than the maximum MTU worth of data that can be multiplied to a page
size without any leftover (in other words, page size modulo 2K is zero).
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
just the most convenient size
for a cluster as it fits the maximum MTU size while at the same time fitting
nicely into a page, reducing allocation complexity.
> -Zhihui
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers&qu
can. Whether they are or not I'm not sure.
> -- Terry
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
to refil thier DMA
> > recieve buffers?
>
> Look at the Tigon II and FXP drivers. The allocations in
> the macros turn into m_get, not m_clusterget.
From if_fxp.c (fxp_add_rfabuf(), sometimes called from fxp_intr()):
MGETHDR(...); <-- get mbuf
if (m != NU
It never calls malloc(). Sometimes, although rarely, it may end up
in kmem_malloc() which calls vm_page_alloc(), but vm_page_alloc() should not
block as in this case it will be called with the VM_ALLOC_INTERRUPT flag.
> -Zhihui
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send
ver it was uipc_mbuf.c was
initially imported from) all _MBUFS_ were allocated directly with malloc()?
Obviously, mbufs are allocatable at interrupt time (and always were, afaic
remember). All that you have to make sure to do, when allocating at interrupt
time is to allocate with the M_NOWAIT flag.
> -- Terry
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
; reduces the overall overhead. Even what we have today, with
Obviously.
> the big giant lock and redirecting interrupts to "the CPU in
> the kernel" is better than that...
>
> -- Terry
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
y patches on the way, but I'm not sure if they address
thread scheduling with the above intent in mind or if they merely introduce
an _interface_ to bind a thread to a single CPU.
> -Matt
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send ma
stems Inc. Santa Clara California 95054
> Email: [EMAIL PROTECTED] http://www.coyotepoint.com/
> ---
> For support call: 1-888-891-8150 Email: <[EMAIL PROTECTED]>
> -
-Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
lf but there is no indication as to
what exactly was changed.
diff -u bootp_subr.c.old bootp_subr.c
would be good enough.
Or if you have the sources checked out with cvs,
cvs diff -u bootp_subr.c
I think this would generate a quicker response. As for the idea
itse
neering team.
> >
> Thanks
>
> Ken
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ave performance results
resulting from such a change.
Finally, I'd like to sort of make a longshot proposal; more of a "if
you have the time" follow-up to your work that someone could be able
to perform, and that would certainly be interesting to see: how all
this w
s locked all
the time.
There are a lot of structures which could probably be re-organized for
cache gain purposes but at this point we have so many structures
changing so quickly that this sort of change becomes difficult to do
properly.
--
Bosko Milekic * [EMAIL PROTECTED] *
be defined at least if you're using our
system (stock) compiler.
Ideally, though, the API would be the same. :-)
> -=| Ben
>
> http://libnss-mysql.sourceforge.net
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.
You can still test for whether or not it is defined.
#if defined(__FreeBSD__)
/* Do freebsd-specific stuff */
#else
/* Other systems? */
#endif
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
nel, which is
why your signal is not being delivered.
Anyway, this is just one possibility. See if all the processes you
describe as 'frozen' have the same MWCHAN and, if so, what is it?
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
ppens under heavy load... your
zone is starved and if you then flush all the pcpu caches and the load
is still heavy, you're likely to have other threads try to allocate
anyway, so they'll end up having to dip into the zone anyway;
therefore, there doesn't seem to be mu
ever, you may want to
wait for someone from the TRB (is there a list of who's part of this
group somewhere, anyway?) and/or -core to respond before you take
action.
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
ty to play with configs, so I'll try
> again to play with invariants, witnesses, etc.
>
> Thanks to all for help.
>
>
> -netch-
Cheers,
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
TECHNOkRATIS Consulting Services * http://www.technokratis.com/
hat is the problem here?
>
> harti
>
> --
> harti brandt,
> http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> _______
> [EMAIL PROTECTED] mailing list
> http://li
On Fri, Aug 01, 2003 at 01:32:05PM +, Bosko Milekic wrote:
>
> I screwed up... fix coming shortly. Sorry!
>
> On Fri, Aug 01, 2003 at 07:00:19PM +0200, Harti Brandt wrote:
> >
> > Hi,
> >
> > with a kernel from yesterday I get a panic on an
m = head->m_next;
> +#endif
> + m = m_free(m);
> + head->m_next = m;
> }
> }
> }
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
hat you're doing. Typically a packet
consists of a chain with a head mbuf that is M_PKTHDR and contains the
additional information. You don't normally do what you wrote, but again,
it depends on the implementation, ultimately.
> Thanks
> Skye
--
Bosko Milekic
[EMAIL PROTECTED]
r by busting the cache.
> -DG
>
> David Greenman
> Co-founder, The FreeBSD Project - http://www.freebsd.org
> President, TeraSolutions, Inc. - http://www.terasolutions.com
> President, Download Technologies, Inc. - http://www.downloadtech.com
> Pave the road of life with opportun
umentation translation?
The rest will/may come with time.
> A lot of regards and wish for best work,
>
> Dragoslav Zaric
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
contact me for more information reg.
> these deltas.
>
> --
> Hiten Pandya
> http://storm.uk.FreeBSD.org/~hiten
> Finger [EMAIL PROTECTED] for PGP public key
> -- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ry
problem or the dump isn't working properly (I've never heard of
anything like this before).
> Thanks,
> -Archie
>
> ______
> Archie Cobbs * Packet Design * http://www.packetdesign.com
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
uot;I'm the ocean, I'm the giant undertow."
> http://www.iki.fi/aaro
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Bill H., is that you?
On Tue, Jun 18, 2002 at 08:39:57AM +, Bill Flamerola wrote:
> Okay, this is not really intended as a flame, but kinda necessary, given the
> current situation in the FreeBSD camp.
[...useless stuff...]
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED
RY" Email would not
only generate the warning, but would also set off a timer and only blast
the Email away in N minutes, unless it is cancelled prior to the
blastoff time.
Anyway, I really think that (1) would be extremely useful. As for (2),
well, it's kind of funny. :-)
Cheers,
On Thu, Jun 20, 2002 at 02:36:41PM -0500, Sean Kelly wrote:
> On Thu, Jun 20, 2002 at 03:24:54PM -0400, Bosko Milekic wrote:
> >
> > Hi,
> >
> > Two ideas have come up recently to extend the features of the mutt(1)
> > Email client. I'm not one
On Thu, Jun 20, 2002 at 01:10:39PM -0700, Matthew Hunt wrote:
> On Thu, Jun 20, 2002 at 03:24:54PM -0400, Bosko Milekic wrote:
>
> > cool if mutt did it). What this does is pretty straightforward: I see
> > a thread with subject "foo." I don't like it. I real
On Thu, Jun 20, 2002 at 03:27:24PM -0500, Brandon D. Valentine wrote:
> On Thu, 20 Jun 2002, Bosko Milekic wrote:
>
> >On Thu, Jun 20, 2002 at 01:10:39PM -0700, Matthew Hunt wrote:
> >> This shouldn't be hard to glue together without modifying mutt itself.
> >&g
efore concatenating p2 to p1 (or after). To place the added
requirement that p1 be a packet header type mbuf would be placing an
additional requirement on callers to m_cat().
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
BSD developer
hanging around. :-)
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
Regards,
--
Bosko Milekic
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send
l_map, if the kernel_map lockmgr lock wasn't held,
so this way if we had a recursive call we would get around this
problem. I think this whole thing is flaky in general (if this was
the way to get around recursion, we should fix it).
JHB and/or JeffR: why is the kmem_map lockmgr l
the panic seems to happen early on during boot,
according to the trace first provided.
> Is arm using a seperate allocf?
>
> Jeff
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
db) frame 12
> #12 0xc0273a0f in tcp_respond (tp=0x0, ipgen=0xc183b93c, th=0xc183b950,
> m=0xc183b900, ack=2100704027, seq=0, flags=20)
> at /usr/src/sys/netinet/tcp_subr.c:396
> 396 m_freem(m->m_next);
> (kgdb) print m
> $1 = (struct mbuf *) 0xc183b900
RIPE Network Coordination Centre
> http://www.ripe.net/home/mark/ New Projects Group/TTM
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
--
Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
terrupt handler) or block on a non-spin
> > mutex.
>
> what is the general locking technique for interrupt handlers?
> there must be some sort of locking, right?
You are allowed to use mutex locks (both spin and MTX_DEF), only you
are only allowed to user the former for fast int
On Mon, Aug 26, 2002 at 10:14:32AM -0700, Maksim Yevmenkin wrote:
> Bosko Milekic wrote:
> >
> > On Mon, Aug 26, 2002 at 09:41:43AM -0700, Maksim Yevmenkin wrote:
> > > John Baldwin wrote:
> > > >
> > > > On 26-Aug-2002 M. Warner Losh wro
ojects/
Cheers.
_____.
Bosko Milekic [EMAIL PROTECTED] |
Network Operations Delphi SuperNet |
http://www.dsuper.net/ an Internet Direct company |
+1.514.281.7500, x233 (phone) +1.514.281.659
d_attach_NE2000_pci __P((int, int));
#endif
--8<--
Also, the PCI driver is actually documented in /usr/src/sys/pci/if_ed_p.c
which begins with:
#if NPCI > 0
NPCI is defined in pci.h, obviously (doh) after a config, based on the
kernel configuration...
Just my two cents...
//Bosko.
<-
Are you running this as root?
<- - - . .
Bosko Milekic <[EMAIL PROTECTED]> http://www.dsuper.net/~bmilekic/
Network Operations - Delphi SuperNet, an Internet Direct company
+1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.d
roperly, it would be much appreciated, and would
> certainly help me in my efforts to continue expanding trusted bsd.
>
> Ive included the code below...
>
> Thanks
> Andrew
[snipped]
<- - - . .
Bosko Milekic <[EMAIL PROTECTED]> http://www.dsuper.net/~bmileki
This may seem to be a ridiculous question... (sorry)
I have a question specifically regarding sys/vm/swap_pager.c,
I'm not very familiar with sys/vm/*, but I've noticed that the value of
the static int no_swap_space (which is initially set to 1) is almost never
checked. The only times that this
#x27;d
like to know if there are objections to doing this or, in fact, if there
are any suggestions on how to handle mbuf shortage situations (aside from
just limiting -- although limiting is in itself a good solution and I'm
glad that Brian F. is working on that).
Cheers,
Bosko.
/*
* Bo
ce
in a while so that finally, when the counter would expire, we would return
a deffinate null _even_ if we are M_WAIT, but this can only be implemented
if we make sure that ALL the MGET and company callers check for this
(which would be annoying to do).
Cheers,
Bosko Milekic.
--- /usr/src/s
e
honest, I don't think that script kids having to comprimise more than one
account just so they can DoS a box will be much of an issue (if worse
comes to worse, we can limit per gid -as opposed to per uid). With
exhaustion attacks such as these, we're better off just limiting.
Regards,
Bo
e, it's dealing with the failure that is the issue.
!>
!>-GAWollman
!>
!>--
!>Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
!>[EMAIL PROTECTED] | O Siem / The fires of freedom
!>Opinions not those of| Dance in the burning flame
!&g
1 - 100 of 127 matches
Mail list logo
