Re: Network stack changes

On Tuesday 24 September 2013 00:46:46 Sami Halabi wrote: > Hi, > > > http://info.iet.unipi.it/~**luigi/papers/20120601-dxr.pdf >et.unipi.it/~luigi/papers/20120601-dxr.pdf> > > http://www.nxlab.fer.hr/dxr/**stable_8_20120824.diff >er.hr/dxr/stable_8_20120824.diff

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Thursday 15 November 2012 20:32:06 Hans Petter Selasky wrote: > On Thursday 15 November 2012 20:16:12 Adrian Chadd wrote: > > Hans brings up a very good point for USB - they split if_alloc and > > if_attach across two different threads. Fine, so maybe one of the following options could work: 1

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote: > Hi, > > Here's what I have thus far. Please ignore the device_printf() change. > > This works for me, both for hotplug cardbus wireless devices as well > as (inadvertently!) a USB bluetooth device. > > What do you think? It looks that you

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote: > ping? > > Marko - would you be willing to add the if_free() vnet context setup into > -HEAD? Feel free to do it - though I'd suggest to use the CURVNET_SET_QUIET() variant there, to reduce the console spam with VNET_DEBUG. Marko Index: i

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Monday 22 October 2012 23:43:11 Adrian Chadd wrote: > Hi, > > I don't mind tackling the net80211 clone detach path. > > I do mind how the default for hotplug is "argh, it doesn't work." :-) > > So I'd like to come up with something to fix the basic device detach, > rather than having to actually

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Monday 22 October 2012 19:41:19 Adrian Chadd wrote: > On 22 October 2012 10:29, Julian Elischer wrote: > >> The trouble is going to be handling unplug and kldunload events too. > >> Does curvnet -> vnet0 during kldunload events? > > > > I think in unload events we probably need to cycle through

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Monday 22 October 2012 01:03:19 Adrian Chadd wrote: ... > > Obviously, handling device attach events is an exception from this > > rule, and up to this date this was never properly addressed... > > *laugh*. > > The problem now is figuring out how to do it without modifying all the > drivers. > >

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Sunday 21 October 2012 21:50:21 Adrian Chadd wrote: > On 21 October 2012 12:36, Marko Zec wrote: > > The right approach would be to do a single CURVNET_SET(vnet0) / > > CURVNET_RESTORE() somewhere near the root of the call graph being > > triggered by the hotplug attach e

Re: VIMAGE crashes on 9.x with hotplug net80211 devices

On Sunday 21 October 2012 21:04:41 Adrian Chadd wrote: > Hi all, > > I have some crashes in the VIMAGE code on releng_9. Specifically, when > I enable VIMAGE and then hotplug some cardbus ath(4) NICs. > > The panics are dereferencing the V_ ifindex and related fields. > > If I start adding CURVNET_

Re: superpages and kmem on amd64

On Monday 21 May 2012 01:12:01 Alan Cox wrote: ... > >>> BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size> > >>> 1G, even at boot time. Any ideas how to circumvent that (8.3-STABLE, > >>> amd64, 4G physical RAM)? > >> > >> I suspect that you need to increase the size of your k

Re: superpages and kmem on amd64

On Sunday 20 May 2012 19:34:26 Alan Cox wrote: ... > > In any case, I wish to be certain that a particular kmem virtual address > > range is mapped to superpages - how can I enforce that at malloc time, > > and / or find out later if I really got my kmem mapped to superpages? > > Perhaps vm_map_lo

Re: superpages and kmem on amd64

On Sunday 20 May 2012 09:25:59 Alan Cox wrote: > On Sun, May 20, 2012 at 2:01 AM, Marko Zec wrote: > > Hi all, > > > > I'm playing with an algorithm which makes use of large contiguous blocks > > of kernel memory (ranging from 1M to 1G in size), so it would be ni

superpages and kmem on amd64

Hi all, I'm playing with an algorithm which makes use of large contiguous blocks of kernel memory (ranging from 1M to 1G in size), so it would be nice if those could be somehow forcibly mapped to superpages. I was hoping that the VM system would automagically map (merge) contiguous 4k pages to

Re: Multiple IP Jail's patch for FreeBSD 6.2

On Wednesday 16 May 2007 09:32:37 Chris wrote: > On 16/05/07, Marko Zec <[EMAIL PROTECTED]> wrote: > > On Monday 14 May 2007 22:47:57 Andre Oppermann wrote: > > > Julian Elischer wrote: > > > > Bjoern A. Zeeb wrote: > > > >> On Mon, 1

Re: Multiple IP Jail's patch for FreeBSD 6.2

twork and routing > >>>> simulations Marco's work is more appropriate. > >>> > >>> Is there a way for us to colaborate on this? I'd really love to > >>> work on this sort of stuff and I think it's really interesting to > >>

Re: Multiple Ips in Jail

On Tuesday 09 December 2003 20:42, Mooneer Salem wrote: > Hello, > > On Mon, 2003-12-08 at 23:39, Mike K wrote: > > Anyone successfully get this to work in a working environment, not > > just install? > > I'm thinking that this would be a better solution for a virtual > hosting environment (once st

Re: PATCH: Pentium-M deeper sleep support in idle loop

On Friday 17 October 2003 11:23, Ducrot Bruno wrote: > In case of P-M (Banias), speedstep does work differently, and this will not > work. Be sure to disable speedstep stuff in such case (or implement it). True, the new "Centrino" CPUs are equipped with a slightly different speedstep control mode

PATCH: Pentium-M deeper sleep support in idle loop

>From http://www.tel.fer.hr/zec/BSD/pm/4.8-ich-ds.patch you can fetch an experimental patch for the 4.8-RELEASE kernel that allows for significant power savings on mobile systems by utilizing a feature called "deeper sleep mode". The deeper sleep mode is available on recent Intel mobile processo

Re: Network stack cloning / virtualization patches

Sean Chittenden wrote: > > I have been running tests between two machines with this patch > > installed. There is a "per packet" overhead increase of about 1%. > > there is no overhead increase in the per-byte overhead.. in ther > > words, sending 1 byte packets gets about a 1% decrease in throug

Re: Network stack cloning / virtualization patches

Sean Chittenden wrote: > can it be broken down into a smaller set of commits? No it can't. That's probably the biggest problem with the network stack cloning concept - you can either properly virtualize the entire stack or do no virtualization at all. Therefore even if I ever succeed in bringing

Re: Network stack cloning / virtualization patches

Juli Mallett wrote: > * Sean Chittenden <[EMAIL PROTECTED]> [ Date: 2003-05-30 ] > [ w.r.t. Re: Network stack cloning / virtualization patches ] > > > at http://www.tel.fer.hr/zec/vimage/ you can find a set of patches > > > against 4.8-RELEASE kernel that provide support for network stack

Re: Per-jail CPU limits?

Mooneer Salem wrote: > Hello, > > I've been looking at the kernel source, in particular the scheduler > in the past few weeks. I found a place in kern_switch.c where per-jail > CPU controls could be added (in particular, in the kse_reassign() function). > >From looking at that function, I could lo

Re: Routing within a Jail

Yakov Sudeikin wrote: > Hi freebsd-hackers, > > Jail with multiple LAN cards accessible from within? > > I have my 4.7 box serving a lot of things, and I have a Linux box routing > the network packets for people in my block. I am not an administraotr of the > router. I want to get rid of the Linux

Re: FreeBSD firewall for high profile hosts - waste of time ?

Terry Lambert wrote: > Josh Brooks wrote: > > You know, I keep hearing this ... the machine is a 500 mhz p3 celeron with > > 256 megs ram ... and normally `top` says it is at about 80% idle, and > > everything is wonderful - but when someone shoves 12,000-15,000 packets > > per second down its thr

Re: FreeBSD firewall for high profile hosts - waste of time ?

Josh Brooks wrote: > My freebsd machine does _nothing_ but filter packets and run ssh. > > > ONLY purpose is to deal with attacks. With an entire cpu dedicated > > to dealing with attacks you aren't likely to run out of CPU suds (at least > > not before your attackers fills your inter

Re: jail: multiple ip's

Terry Lambert wrote: > Tony Finch wrote: > > [EMAIL PROTECTED] (Mike Ghunt) wrote: > > > Has anyone hacked the jail code to support more than one ip? > > >Would it be wise to hack at the code to add such a feature? > > > > Probably the best way to address this issue is to incorporate the > > netw

Re: Clock Granularity (kernel option HZ)

Storms of Perfection wrote: > Ok. Since I have a limited hardware/software set at my finger tips. I can > generate an attack on my machine (such as a synflood or something) to see > what type of reponses I can get by setting it up and down. I think this may > apply to this feature, to help the ma

Re: FreeBSD4.4, fxp, no net after ifconfig for ~50 seconds (fwd)

As Cisco switches have STP enabled by default on all ports, maybe a reboot of an 4.4 system is seen as a change in link state, so Catalyst holds the port STP-blocked for a couple of seconds before putting it to forwarding state. Did you try disabling STP on Catalyst eth ports? Marko David Kirchn

Re: fxp patch - bundling receive interrupts

Mike Silbersack wrote: > That being said, I thought I should check on one thing: In your original > post, you mentioned that these techniques came from the linux drive for > these cards. In the process of writing this patch, did you copy any > section of code from the Linux driver? If possibl

Re: fxp patch - bundling receive interrupts

I am not an official FreeBSD commiter, so I can't tell really... Therefore jlemon was in cc: (he is the fxp driver maintainer), so it is his call. Nevertheless, I think this patch needs a little bit more testing - there are many 8255* chipset revisions out there, and as the code is *very* chipset

fxp patch - bundling receive interrupts

An updated fxp driver patch for bundling receive interrupts, thus saving a noticeable amount of CPU overhead for interrupt processing, can be found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: - control of microcode parameters through sysctl variables - activation/deactivation of m

fxp driver - receive interrupt bundling

On http://fly.cc.fer.hr/~zec/index.html you can find a 4.4-RELEASE fxp driver source, with patches that incorporate receive interrupt bundling microcode, borrowed from the Intel's Linux e100 driver. Bundling interrupts for a couple of received Ethernet frames can significantly lower interrupt pro