Nate Nielsen wrote:
> I'm experiencing a memory leak in the net80211 code. I have two atheros
> 5213-A cards on two embedded systems running FreeBSD 6.0. They are setup
> as IBSS (adhoc) stations. After roughly 15 seconds of ~14Mbps TCP
> traffic (single stream) I promptly
I've recently been optimizing the hifn driver for low performance
systems like the Soekris. I've implemented polling (rather than using
interrupts for everything) in the driver, which speeds things up
considerably.
The polling functionality in FreeBSD is currently a bit NIC centric.
With a few cha
Nate Nielsen wrote:
> The polling functionality in FreeBSD is currently a bit NIC centric.
> With a few changes other types devices can use the polling subsystem.
> Attached is my first whack at this.
>
> This is some of my first hacking on the FreeBSD kernel. It'd be great if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ed Maste wrote:
> In addition, the current polling algorithm breaks down when you get to
> very high CPU utilization by the stack (e.g. if acting as a high
> bandwidth router). This happens because it adds one count per tick
> if the polling did not r
I'm developing for small embedded systems, and I'm looking into the
possibility of dumping a kernel core dump to a USB memory stick (umass
driver). It currently doesn't work (see below), but I'm interested in
fixing it.
Yes, I know it'll be slow. It's probably also a non-tested (and
non-reliable)
Ian Dowse wrote:
>
> The USB stack supports polled operations, so it's actually not to
> hard to make this work. Below is a patch I had in one of my local
> trees that adds a CAM poll handler to the umass driver. I've just
> tested this and it does seem to make kernel dumping work, but I
> guess i
FreeLSD wrote:
> Good day!
> I've obtained the following strang results with the em Ethernet interface
> speeds on a 6.1-PRERELEASE:
> Polling on:
> UDP stream to FreeBSD: 327843.84 Kbit/sec,
> TCP stream to FreeBSD: 524550.12 Kbit/sec.
> Polling off:
> UDP stream to FreeBSD: 740409.38 K
Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Scott Long writes:
>
>>You're correct that dumping is meant to be done with interrupts and task
>>switching disabled. The first thing that the umass driver is missing is
>>a working CAM poll handler. Without this, there is no way for command
>>c
I'm working on a bit of code to get devctl notifications for attaching
and removing of disks. This would allow actions to be taken via devd
when a disk is attached or removed from the system.
Currently I have the attach and detach notifications hooked into
disk_create() and disk_destroy() in geom_
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Nielsen <[EMAIL PROTECTED]> writes:
> : I'm working on a bit of code to get devctl notifications for attaching
> : and removing of disks. This would allow actions to be taken via devd
> : wh
'jailer' can do this but it requires a process running in each jail.
http://memberwebs.com/nielsen/freebsd/jails/
Cheers,
Nate
Dirk Engling wrote:
> I'm currently looking for a standardized way to 'reboot' jails from
> within.
___
freebsd-hackers@fre
No. I think each instance of natd (at least last time I looked at it)
could only use one IP address as it's public address.
Cheers,
Nate
Daniel Dias Gonçalves wrote:
> Exists the possibility to make NAT POOL with IPFW + NATD ?
>
___
freebsd-hackers@fr
12 matches
Mail list logo
