I was wondering whether anyone is working on support for the Realtek 8180 chipset.
This chipset is used on various wireless PCI and PCMCIA cards (I bought one and then
found out FreeBSD doesn''t support it yet).
Regards,
Sander Buskens
___
[EMAIL
Hello,
I did some changes in my patch to FreeBSD kernel. I have changed my
pr, and the new one is 54383. Now, only the diff is on the FreeBSD page.
Take a look.
If somebody knows who is the devel man, that can help me to add this patch
as a new feature in FreeBSD kernel, please tell me.
I
Hmmm,
What we observed on our embedded system is the packet gets sent on all
attached interfaces, with dest IP 255.255.255.255, and a src IP of the
local address that has the default route. If there isn't a default
route, sending to 255.255.255.255 fails with no route to host.
Maybe I am
Currently, whenever maxsockets is increased, this causes kernel memory to be
preallocated for each type of pcb (tcp, udp, raw, divert). The number of
pcbs preallocated for each of these is always the same as maxsockets.
This is probably a waste of memory for raw sockets and divert sockets, since
On Tue, 15 Jul 2003, Scot Loach wrote:
Is there any reason I should not modify the kernel code to only let a small,
fixed number of raw and divert pcbs be preallocated instead of having them
scale with maxsockets?
Your idea is sound.
Next, does this seem like a generally useful thing that
On Tuesday 15 July 2003 10:09, Matthew Grooms wrote:
Hmmm,
What we observed on our embedded system is the packet gets sent on
all attached interfaces, with dest IP 255.255.255.255, and a src IP
of the local address that has the default route. If there isn't a
default route, sending to
Wes Peters wrote:
[ ... ]
The idea is, we have listener on each ethernet interface listening via a
bpf. The listener listens for an 'appliance discovery' packet which is
broadcast by the console application running on the admin's
workstation. When we receive this discovery packet, we're
Hi Bill,
Sorry for the previous e-mail, but have in mind that I'm trying to cooperate
by testing your drivers and
I am not aware of the rules for declaring a hardware problem in the mailing
lists. The only way I can send
you the messages from the kernel is if I rewrite them from the console.
Here
Of all the gin joints in all the towns in all the world, Boris Georgiev
had to walk into mine and say:
Hi Bill,
Sorry for the previous e-mail, but have in mind that I'm trying to cooperate
by testing your drivers and
I am not aware of the rules for declaring a hardware problem in the
On 15 Jul, Mike Silbersack wrote:
On Tue, 15 Jul 2003, Scot Loach wrote:
Is there any reason I should not modify the kernel code to only let a small,
fixed number of raw and divert pcbs be preallocated instead of having them
scale with maxsockets?
Your idea is sound.
Next, does this
True, I can add a tunable for each of tcp, udp, raw, divert.
What will happen when the system runs out of pcbs?
-Original Message-
From: Don Lewis [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 8:48 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re:
On Tue, Jul 15, 2003 at 03:48:48PM -0700, Wes Peters wrote:
It's a broadcast, the socket isn't bound to an interface. ;^)
The idea is, we have listener on each ethernet interface listening via a
bpf. The listener listens for an 'appliance discovery' packet which is
broadcast by the
On Tue, 15 Jul 2003, Scot Loach wrote:
True, I can add a tunable for each of tcp, udp, raw, divert.
That's probably a good idea, I'm sure I'll end up messing with it a bit
once you send it to me. :)
What will happen when the system runs out of pcbs?
I think it should handle everything fine.
13 matches
Mail list logo
