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
On Jan 5, 2006, at 9:57 AM, David Malone wrote:
On Wed, Jan 04, 2006 at 05:59:44PM -0700, Dan Joumaa wrote:
entry->fw_prot = IPPROTO_TCP|IPPROTO_UDP;
This may not be your problem, but I think you need two rules to do
this the protocol number is a 8 bit number, not a bit field (ie.
IPPROTO
On Thursday 05 January 2006 07:46 am, Necati Ersen Siseci wrote:
> Hello,
>
> I am using FreeBSD 5.4-RELASE-p8.
>
> When i disable the serial port ttyd0 and try to write to ttyd0 system get
> stuck.
>
> For example, after disabling serial ports from BIOS and issuing
>
> echo > /dev/ttyd0
>
> or ena
On 5 Jan 2006, at 18:43, Ahnjoan Amous wrote:
In 5.2.1-RELEASE, setfacl updates the modification time of the file
when acls are changed. I haven't been able to find any complaints
about this behavior, is this something folks on the list would expect
when using setfacl? If so, does anyone know
In 5.2.1-RELEASE, setfacl updates the modification time of the file
when acls are changed. I haven't been able to find any complaints
about this behavior, is this something folks on the list would expect
when using setfacl? If so, does anyone know a work around?
Thanks
Ahnjoan
__
On Wed, Jan 04, 2006 at 05:59:44PM -0700, Dan Joumaa wrote:
>entry->fw_prot = IPPROTO_TCP|IPPROTO_UDP;
This may not be your problem, but I think you need two rules to do
this the protocol number is a 8 bit number, not a bit field (ie.
IPPROTO_TCP is 6 and IPPROTO_UDP is 17, so oring them toget
Hello,
I am using FreeBSD 5.4-RELASE-p8.
When i disable the serial port ttyd0 and try to write to ttyd0 system get stuck.
For example, after disabling serial ports from BIOS and issuing
echo > /dev/ttyd0
or enabling ttyd0 on /etc/ttys will get stuck the system when booting
up and try to
run ge
Danny Braniss wrote:
Okey. I found the cause of this problem. I fixed it :)
http://people.freebsd.org/~daichi/unionfs/unionfs-p2.diff
can you make the diffs for 6.0?
thanks,
danny
For 7-current patch:
http://people.freebsd.org/~daichi/unionfs/unionfs-p2.diff (latest patch)
http:
Danny Braniss wrote:
Masanori OZAWA wrote:
[...]
Nice work! This is just a "works for me". In only find some issues with
permissions that were already present in the previous implementation of
unionfs. Some of them are partially corrected in the "useful" copymode.
I mailed the details to the aut
9 matches
Mail list logo
