Re: Posting restrictions on this mailing list (for spam control)?
2006/11/8, LI Xin <[EMAIL PROTECTED]>: MQ wrote: [snip] > The mailing list denied all the mail from my previous mail box provided by > Netease(NASDAQ: NTES) from China mainland, even I subscribed to -net, and > asked me to wait the moderator's approval. But after I changed my > mailbox to > gmail, the filter never returned such message. I don't know why I can't > post > to -net even I subscribed to it. Maybe a misconfiguration? No. At least, not misconfiguration at FreeBSD.org side. I have discussed the situation with David (the postmaster@) and this seems to be caused by misconfiguration and wrong implementation of the e-mail standards by NTES, which in turn caused SpamAssassin to provide false positives (personally I do not think that they should be considered as false positives, they are REAL problems that should be addressed and corrected). Cheers, -- Xin LI < [EMAIL PROTECTED]>http://www.delphij.net/ FreeBSD - The Power to Serve! Ok, I see. But the messages return by SpamAssissin is really confusing. It is asking that I subscribe the mailing list, but actually that can't help. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reentrant problem with inet_ntoa in the kernel
2006/11/5, Bruce Evans <[EMAIL PROTECTED]>:
On Sat, 4 Nov 2006, Brooks Davis wrote:
> On Sat, Nov 04, 2006 at 02:46:30AM +, MQ wrote:
>> 2006/11/3, Brooks Davis <[EMAIL PROTECTED]>:
>>> The particular definition used is excedingly ugly. At a minimum there
>>> needs to be a define or a constant "16" for the lenght rather than the
>>> 4*sizeof("123") nonsense.
The `4*sizeof "123"' is not nonsense. It is better than the userland
version
at the time it was committed. The userland version hard-coded the size as
18 (sic). The current userland version still hard-codes 18, but now
actually needs it to print an error message of length 17. The uglyness in
`4*sizeof "123"' is just that it has 3 formatting style bugs (missing
spaces
around binary operator, space after sizeof, and missing parentheses for
sizeof) and depends on the storage for a '.' being the same as the storage
for the the '\0' terminator. I would write it as sizeof("255.255.255.255
").
>> Oh, I see. This kind of definition is really annoying, and hard to keep
all
>> the
>> occurrences consistent. Maybe a better way is use a macro to make that
>> clear?
>>
>> #define IPV4_ADDRSZ (4 * sizeof "123")
>> char buf[IPV4_ADDRSZ];
This is less clear, since it takes twice as much code to obfuscate the
size in a macro for no benefits since the macro is only used once.
>> This "ugly" definition comes from inet_ntoa() in
/sys/libkern/inet_ntoa.c,
>> I just copied the style without too much consideration, it's my fault.
>
> I'd just use 16. The inet_ntoa function is frankly inane. It attempts
> to support chars that aren't 8 bits which would break so much stuff it
> isn't funny.
No, it assumes 8-bit chars. It's masking with 0xff is apparently copied
from an old implementation that used plain chars. The userland
implementation at the time it was committed does that, but uses a macro
to do the masking and is missing lots of style bugs.
The userland version now calls inet_ntop(). This is missing the design
bug of using a static buffer. It calls inet_ntop4() for the ipv4 case.
This is closer to being non-ugly:
% static const char *
% inet_ntop4(const u_char *src, char *dst, socklen_t size)
% {
% static const char fmt[] = "%u.%u.%u.%u";
% char tmp[sizeof "255.255.255.255"];
% int l;
%
% l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2],
src[3]);
% if (l <= 0 || (socklen_t) l >= size) {
% errno = ENOSPC;
% return (NULL);
% }
% strlcpy(dst, tmp, size);
% return (dst);
% }
I would write this as:
%%%
CTASSERT(CHAR_BIT == 8);/* else src would be misintepreted */
static const char *
inet_ntop4(const u_char *src, char *dst, socklen_t size)
{
int n;
n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2],
src[3]);
assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */
if ((u_int)n >= size) {
errno = ENOSPC;
return (NULL);
}
return (dst);
}
%%%
This is closer to the version in RELENG_6 than the current version. It
doesn't use tmp[]] to preserve dst on error, and fixes the bounds checking
without introducing several style bugs and not actually fixing the bounds
checking. The old version was:
if ((socklen_t)snprintf(dst, size, fmt, src[0], src[1], src[2],
src[3]
>= size) {
...
}
This is good enough since 0 < l <= 16 implies that the preposterou case
(l <= 0) and the preposterous broken case ((socklen_t)l != l) can't
happen, but it is easier to use correct bounds checking than to understant
why bugs in the bounds checking are harmless.
Bruce
I don't know why the ret array in the userland version of the inet_ntoa
should be 17. The length of the message itself is 17, and an \0 is needed
for the str* to work.
By the way, 4 * sizeof("123") chars should be always enough to contain an
IPv4 address, no matter how many bits consititute a char.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > Unfortunately, it seems that this is still that unfinished driver from > Damien, that circulates on the net everywhere, but it only works for > some lucky people. As for me, I get an error message when loading the > module, that it could not allocate resources. I don't think it's "that unfinished driver from Damien" classify it correctly, as stated it's an unsupported version so case where it will not work are expected. Feel free to improve it or wait when some FreeBSD developer will port and maintain it. Thanks Florent for mirroring. -- Massimo.run(); ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reentrant problem with inet_ntoa in the kernel
On Fri, 10 Nov 2006, MQ wrote:
2006/11/5, Bruce Evans <[EMAIL PROTECTED]>:
On Sat, 4 Nov 2006, Brooks Davis wrote:
> On Sat, Nov 04, 2006 at 02:46:30AM +, MQ wrote:
>> 2006/11/3, Brooks Davis <[EMAIL PROTECTED]>:
>>> The particular definition used is excedingly ugly. At a minimum there
>>> needs to be a define or a constant "16" for the lenght rather than the
>>> 4*sizeof("123") nonsense.
The `4*sizeof "123"' is not nonsense. It is better than the userland
version
at the time it was committed. The userland version hard-coded the size as
18 (sic). The current userland version still hard-codes 18, but now
actually needs it to print an error message of length 17. The uglyness in
`4*sizeof "123"' is just that it has 3 formatting style bugs (missing
...
> I'd just use 16. The inet_ntoa function is frankly inane. It attempts
> to support chars that aren't 8 bits which would break so much stuff it
> isn't funny.
No, it assumes 8-bit chars. It's masking with 0xff is apparently copied
from an old implementation that used plain chars. The userland
implementation at the time it was committed does that, but uses a macro
to do the masking and is missing lots of style bugs.
The userland version now calls inet_ntop(). This is missing the design
bug of using a static buffer. It calls inet_ntop4() for the ipv4 case.
This is closer to being non-ugly:
% static const char *
% inet_ntop4(const u_char *src, char *dst, socklen_t size)
% {
% static const char fmt[] = "%u.%u.%u.%u";
% char tmp[sizeof "255.255.255.255"];
% int l;
%
% l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2],
src[3]);
% if (l <= 0 || (socklen_t) l >= size) {
% errno = ENOSPC;
% return (NULL);
% }
% strlcpy(dst, tmp, size);
% return (dst);
% }
I would write this as:
%%%
CTASSERT(CHAR_BIT == 8);/* else src would be misintepreted */
static const char *
inet_ntop4(const u_char *src, char *dst, socklen_t size)
{
int n;
n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2],
src[3]);
assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */
...
I don't know why the ret array in the userland version of the inet_ntoa
should be 17. The length of the message itself is 17, and an \0 is needed
for the str* to work.
Yes, it needs to be 18 for the error message. I wrote "18 (sic)" because
18 is a surprising value. Anyone who knows what an inet address is would
expect a length of 16. But programmers shouldn't be counting bytes in
strings and mentally computing max(16, 18) and hard-coding that. The
magic 16 won't change, but the 18 might. Spelling 16/18 as a macro
and hard-coding 16/18 in the macro would be even worse, since the value is
only used onece.
By the way, 4 * sizeof("123") chars should be always enough to contain an
IPv4 address, no matter how many bits consititute a char.
It's enough for an ipv4 address, but inet_ntop4() is a library routine
so it shouldn't crash on invalid input. With 8-bit chars, it happens
that there is no invalid input for u_char *src (except a src array with
less than 4 chars in it). With >= 10-bit chars, the result could be
"1023.1023.1023.1023", which isn't an ipv4 address and is too large
for a 16-18 byte buffer. inet_ntop4() needs to ensure that this and
some other errors don't occur. It uses mainly snprintf(), but with
snprintf() another set of errors and out-of-bounds values can occur
in theory, and inet_ntop4()'s handling of these is not quite right.
Bruce
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
On Nov 9, 2006, at 9:39 PM, Gábor Kövesdán wrote: Florent Thoumie wrote: On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: Hi all, I'm pleased to tell you i got the latest wpi driver from Damien Bergamini to work properly on a latest -stable on an Acer laptop. Nice work! Unfortunately, it seems that this is still that unfinished driver from Damien, that circulates on the net everywhere, but it only works for some lucky people. As for me, I get an error message when loading the module, that it could not allocate resources. Haven't taken my 3945 "powered" laptop in Milan, so I haven't had the chance to try it yet. Is it the same as the one we can find in deischen public space on freefall? -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Path MTU discovery broken in IPSec
Hi Bjoern. My apologies for the delay in response. > and no rules specific to ICMP? The only ICMP-specific rules allow everything through; [host1] ~# ipfw show | grep icmp 0170035776 3023614 pipe 25 icmp from any to table(1) in via em0 0170135776 3023614 skipto 1999 icmp from any to table(1) in via em0 0170235009 2970684 pipe 26 icmp from table(1) to any out via em0 0170335009 2970684 skipto 1999 icmp from table(1) to any out via em0 0200437204 3144438 allow icmp from any to table(1) in via em0 0200541289 3498204 allow icmp from table(1) to any out via em0 And similarly for host2; [host2] ~# ipfw show | grep icmp 0170021550 1789832 pipe 25 icmp from any to table(1) in via fxp0 0170121550 1789832 skipto 1999 icmp from any to table(1) in via fxp0 0170221190 1770208 pipe 26 icmp from table(1) to any out via fxp0 0170321190 1770208 skipto 1999 icmp from table(1) to any out via fxp0 0200422899 1903148 allow icmp from any to table(1) in via fxp0 0200527470 2297728 allow icmp from table(1) to any out via fxp0 > can you start trying with ping -s 1000 and going up to see when it > starts to fail? Try to find out exactly. It appears to be fine up until between 8000 and 9000, without any issues. Up to 8000, its appears to be fine. [host1] ~# ping -s 8000 citadel.os.org.za PING host2 (y.y.y.y): 8000 data bytes 8008 bytes from y.y.y.y: icmp_seq=0 ttl=112 time=533.652 ms 8008 bytes from y.y.y.y: icmp_seq=1 ttl=112 time=544.826 ms 8008 bytes from y.y.y.y: icmp_seq=2 ttl=112 time=531.899 ms 8008 bytes from y.y.y.y: icmp_seq=3 ttl=112 time=581.185 ms 8008 bytes from y.y.y.y: icmp_seq=4 ttl=112 time=674.831 ms 8008 bytes from y.y.y.y: icmp_seq=5 ttl=112 time=674.271 ms ^C --- host2 ping statistics --- 7 packets transmitted, 6 packets received, 14% packet loss round-trip min/avg/max/stddev = 531.899/590.111/674.831/61.870 ms By 9000, it starts to drop packets. [host1] ~# ping -s 9000 host2 PING host2 (y.y.y.y): 9000 data bytes 9008 bytes from y.y.y.y: icmp_seq=0 ttl=112 time=554.908 ms 9008 bytes from y.y.y.y: icmp_seq=2 ttl=112 time=527.464 ms 9008 bytes from y.y.y.y: icmp_seq=3 ttl=112 time=553.512 ms 9008 bytes from y.y.y.y: icmp_seq=4 ttl=112 time=755.606 ms 9008 bytes from y.y.y.y: icmp_seq=5 ttl=112 time=484.681 ms 9008 bytes from y.y.y.y: icmp_seq=6 ttl=112 time=485.256 ms 9008 bytes from y.y.y.y: icmp_seq=7 ttl=112 time=488.802 ms 9008 bytes from y.y.y.y: icmp_seq=8 ttl=112 time=491.750 ms 9008 bytes from y.y.y.y: icmp_seq=9 ttl=112 time=493.689 ms 9008 bytes from y.y.y.y: icmp_seq=11 ttl=112 time=547.049 ms 9008 bytes from y.y.y.y: icmp_seq=12 ttl=112 time=668.788 ms 9008 bytes from y.y.y.y: icmp_seq=13 ttl=112 time=479.957 ms 9008 bytes from y.y.y.y: icmp_seq=14 ttl=112 time=478.519 ms 9008 bytes from y.y.y.y: icmp_seq=15 ttl=112 time=479.967 ms 9008 bytes from y.y.y.y: icmp_seq=16 ttl=112 time=480.166 ms 9008 bytes from y.y.y.y: icmp_seq=17 ttl=112 time=492.812 ms ^C --- host2 ping statistics --- 18 packets transmitted, 16 packets received, 11% packet loss round-trip min/avg/max/stddev = 478.519/528.933/755.606/75.693 ms At 15000, it is fairly horrendous [host1] ~# ping -s 15000 host2 PING host2 (y.y.y.y): 15000 data bytes 15008 bytes from y.y.y.y: icmp_seq=1 ttl=112 time=510.439 ms 15008 bytes from y.y.y.y: icmp_seq=2 ttl=112 time=497.274 ms 15008 bytes from y.y.y.y: icmp_seq=5 ttl=112 time=536.947 ms 15008 bytes from y.y.y.y: icmp_seq=6 ttl=112 time=567.623 ms 15008 bytes from y.y.y.y: icmp_seq=7 ttl=112 time=534.828 ms 15008 bytes from y.y.y.y: icmp_seq=8 ttl=112 time=534.521 ms 15008 bytes from y.y.y.y: icmp_seq=13 ttl=112 time=574.470 ms 15008 bytes from y.y.y.y: icmp_seq=16 ttl=112 time=588.514 ms 15008 bytes from y.y.y.y: icmp_seq=17 ttl=112 time=575.090 ms 15008 bytes from y.y.y.y: icmp_seq=21 ttl=112 time=548.478 ms ^C --- host2 ping statistics --- 23 packets transmitted, 10 packets received, 56% packet loss round-trip min/avg/max/stddev = 497.274/546.818/588.514/28.122 ms > Also could you post the relevant netstat -rnW output? On host1; [host1] ~# netstat -rnW Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Netif Expire defaultx.x.x.1UGS 0 705597552 1000 em0 127.0.0.1 127.0.0.1 UH 0 2887710 16384 lo0 x.x.x link#1 UC 0 0 1500 em0 x.x.x.100:00:0c:07:ac:0a UHLW2 72598 1500 em0 1110 x.x.x.x00:12:3f:ec:d1:ce UHLW1 28404610 1500 lo0 Internet6: Destination Gateway Flags Refs UseMtuNetif Expire ::1 ::1 UH 00 16384 lo0 fe80::%em0/64 link#1UC 00 1500 em0 fe80::212:3fff:feec:d1ce%em0 00:12:3f:ec:d1:ce
Re: New wpi driver
Florent Thoumie wrote: On Nov 9, 2006, at 9:39 PM, Gábor Kövesdán wrote: Florent Thoumie wrote: On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: Hi all, I'm pleased to tell you i got the latest wpi driver from Damien Bergamini to work properly on a latest -stable on an Acer laptop. Nice work! Unfortunately, it seems that this is still that unfinished driver from Damien, that circulates on the net everywhere, but it only works for some lucky people. As for me, I get an error message when loading the module, that it could not allocate resources. Haven't taken my 3945 "powered" laptop in Milan, so I haven't had the chance to try it yet. Is it the same as the one we can find in deischen public space on freefall? Well, not actually. I compared them, and this one is different, but unfortunately still produces the same error for me on a Fujitsu-Siemens Amilo Pi 1556 01. -- Cheers, Gabor ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > Unfortunately, it seems that this is still that unfinished driver from > > Damien, that circulates on the net everywhere, but it only works for > > some lucky people. As for me, I get an error message when loading the > > module, that it could not allocate resources. > > I don't think it's "that unfinished driver from Damien" classify it > correctly, as stated it's an unsupported version so case where it will > not work are expected. Feel free to improve it or wait when some FreeBSD > developer will port and maintain it. I agree. On top of that, a more detailed error report would be preferable. From what you put above, it seems that you are out of sufficient continous memory at the point where you enable the hardware. Try enabling it before bringing up X11 etc. > Thanks Florent for mirroring. -- Max ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
2006/11/10, Max Laier <[EMAIL PROTECTED]>: On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > Unfortunately, it seems that this is still that unfinished driver from > > Damien, that circulates on the net everywhere, but it only works for > > some lucky people. As for me, I get an error message when loading the > > module, that it could not allocate resources. > > I don't think it's "that unfinished driver from Damien" classify it > correctly, as stated it's an unsupported version so case where it will > not work are expected. Feel free to improve it or wait when some FreeBSD > developer will port and maintain it. I agree. On top of that, a more detailed error report would be preferable. From what you put above, it seems that you are out of sufficient continous memory at the point where you enable the hardware. Try enabling it before bringing up X11 etc. Even if I'm not totally aware about what problem are gabor@ is having at the moment, some time ago I started looking at the code and one difference between ipi and wpi is in rings they use (and their allocation) and again in the usage of a shared DMA memory page between the host and the NIC. Maybe this is not done in the right way in the Damien's driver and this is beacause gabor would having allocation problems. Attilio PS: I will try to look at the code posted above ASAP... -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
2006/11/10, Attilio Rao <[EMAIL PROTECTED]>: 2006/11/10, Max Laier <[EMAIL PROTECTED]>: > On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > > Unfortunately, it seems that this is still that unfinished driver from > > > Damien, that circulates on the net everywhere, but it only works for > > > some lucky people. As for me, I get an error message when loading the > > > module, that it could not allocate resources. > > > > I don't think it's "that unfinished driver from Damien" classify it > > correctly, as stated it's an unsupported version so case where it will > > not work are expected. Feel free to improve it or wait when some FreeBSD > > developer will port and maintain it. > > I agree. On top of that, a more detailed error report would be preferable. > From what you put above, it seems that you are out of sufficient continous > memory at the point where you enable the hardware. Try enabling it before > bringing up X11 etc. Even if I'm not totally aware about what problem are gabor@ is having at the moment, some time ago I started looking at the code and one difference between ipi and wpi is in rings they use (and their allocation) and again in the usage of a shared DMA memory page between the host and the NIC. s/ipi/iwi. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
Hello Barry, On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: B>I see you listed on the EM stability issues list. I have a Tyan B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes B> without EM watchdog resets unless I use giant locks. B>Is there any way you'd like me to help you with testing the updated B> drivers? Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new kernel and report whether the problem is fixed or not. You see, I have added a o lot of people and two mailing lists to Cc. Please do not remove them, when replying. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
So far so good. I updated to the latest, including jfv's revision 1.65.2.21 from this AM. With the 6.1 ISO distribution, I would get watchdogs within seconds of starting a file transfer (except giant locked which worked fine). With RELENG_6 I've transfered 100's of GB via ftp and NFS over both ethernet ports and no problems yet. Thanks for all the hard work! Barry Gleb Smirnoff writes: > Hello Barry, > > On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: > B>I see you listed on the EM stability issues list. I have a Tyan > B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes > B> without EM watchdog resets unless I use giant locks. > B>Is there any way you'd like me to help you with testing the updated > B> drivers? > > Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new > kernel and report whether the problem is fixed or not. > > You see, I have added a o lot of people and two mailing lists to Cc. > Please do not remove them, when replying. Thanks! > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
2006/11/10, Attilio Rao <[EMAIL PROTECTED]>: 2006/11/10, Attilio Rao <[EMAIL PROTECTED]>: > 2006/11/10, Max Laier <[EMAIL PROTECTED]>: > > On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > > > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > > > Unfortunately, it seems that this is still that unfinished driver from > > > > Damien, that circulates on the net everywhere, but it only works for > > > > some lucky people. As for me, I get an error message when loading the > > > > module, that it could not allocate resources. > > > > > > I don't think it's "that unfinished driver from Damien" classify it > > > correctly, as stated it's an unsupported version so case where it will > > > not work are expected. Feel free to improve it or wait when some FreeBSD > > > developer will port and maintain it. > > > > I agree. On top of that, a more detailed error report would be preferable. > > From what you put above, it seems that you are out of sufficient continous > > memory at the point where you enable the hardware. Try enabling it before > > bringing up X11 etc. > > Even if I'm not totally aware about what problem are gabor@ is having > at the moment, some time ago I started looking at the code and one > difference between ipi and wpi is in rings they use (and their > allocation) and again in the usage of a shared DMA memory page between > the host and the NIC. s/ipi/iwi. Ok I gave a quick look at the code and gabor@ problem is about memory-mapped I/O resource allocation. First of all, WPI_PCI_BAR0 might not be defined in this way, but it should really use PCIR_BAR() macro. Then, probabilly, gabor's device I/O space is relative to another BAR, so simply try all 6 using PCIR_BAR(n) where n range is 0-6 until it does allocate. Attilio PS: I would like that the code will better follow stlye(9) too... -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
First of all, WPI_PCI_BAR0 might not be defined in this way, but it should really use PCIR_BAR() macro. Then, probabilly, gabor's device I/O space is relative to another BAR, so simply try all 6 using PCIR_BAR(n) where n range is 0-6 until it does allocate. Sorry, n ranges 0-5... (as I said before 6 different address spaces). Today it seems I'm absolutely sleeping... (probabilly I'm too angry to have not parecipied at EuroBSDCon...). Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
At 05:00 PM 11/9/2006, Mike Tancsa wrote: At 10:51 AM 11/9/2006, Scott Long wrote: Mike Tancsa wrote: At 08:19 PM 11/8/2006, Jack Vogel wrote: BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. It certainly does make a difference performance wise. I did some quick testing with netperf and netrate. Back to back boxes, using an AMD x2 with bge nic and one intel box CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2009.27-MHz 686-class CPU) CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2144.01-MHz 686-class CPU) The intel is a DG965SS with integrated em nic, the AMD a Tyan with integrated bge. Both running SMP kernels with pf built in, no inet6. Intel box as sender. In this test its with the patch from yesterday. The first set with the patch as is, the second test with -DEM_FAST_INTR. Thanks for the tests. One thing to note is that Gleb reported a higher rate of dropped packets with INTR_FAST. He is the only one who has reported this, so I'd like to find out if there is something unique to his environment, or if there is a larger problem to be addressed. There are ways that we can change the driver to not drop any packets at all for Gleb, but they expose the system to risk if there is ever an accidental (or malicious) RX flood on the interface. With a high rate of packets, I am able to live lock the box. I setup the following Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. SMP kernel fastfwd pf ipfw FAST_INTR streams np (Mb) x x x 2 livelock x x xx 2 468 livelock x x 2 453 lost packets, box sluggish x xx 2 lost packets, box sluggish x 2 468 lost packets, box sluggish x x 2 468 livelock x x x 2 468 livelock 2 475 livelock x 2 livelock P 2 OK P x 2 OK P x 2 OK The P is for Uniproc, but with Polling enabled (also kern.polling.idle_poll=1) UP single stream 58Kpps, no polling in kernel [bsd6-32bit]# ./netblast 192.168.44.1 500 10 10 start: 1163184051.627479975 finish:1163184061.628200458 send calls:5869051 send errors: 0 approx send rate: 586905 approx error rate: 0 with polling [bsd6-32bit]# ./netblast 192.168.44.1 500 10 10 start: 1163184606.651001121 finish:1163184616.651288588 send calls:5866199 send errors: 1 approx send rate: 586619 approx error rate: 0 With polling and 2 streams at the same time (a lot of pps! and its still totally responsive!!) [r6-32bit]# ./netblast 192.168.88.218 500 10 10 start: 1163184712.103954688 finish:1163184722.104388542 send calls:4528941 send errors: 0 approx send rate: 452894 approx error rate: 0 [r6-32bit]# [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163184793.172036336 finish:1163184813.173028921 send calls:11550594 send errors: 0 approx send rate: 577529 approx error rate: 0 [bsd6-32bit]# polling, 2 streams at the same time [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163185058.477137404 finish:1163185078.478025226 send calls:11679831 send errors: 0 approx send rate: 583991 approx error rate: 0 [bsd6-32bit]# ./netblast 192.168.44.1 500 10 20 start: 1163185167.969551943 finish:1163185187.970435295 send calls:11706825 send errors: 0 approx send rate: 585341 approx error rate: 0 [bsd6-32bit]# ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
Luck ran out. Hard "must press the reset button" hang. No console messages. The system was idle at the time. Is there anything you'd like me to do to attempt to narrow down the problem or get debugging output? I do not know if the freeze was related to em or something else. -Barry Barry Boes writes: > > So far so good. I updated to the latest, including jfv's revision > 1.65.2.21 from this AM. > > With the 6.1 ISO distribution, I would get watchdogs within seconds of > starting a file transfer (except giant locked which worked fine). > > With RELENG_6 I've transfered 100's of GB via ftp and NFS over both > ethernet ports and no problems yet. > > Thanks for all the hard work! > Barry > > > > Gleb Smirnoff writes: > > Hello Barry, > > > > On Fri, Nov 10, 2006 at 08:56:30AM -0600, Barry Boes wrote: > > B>I see you listed on the EM stability issues list. I have a Tyan > > B> H1000S with dual em ports on 6.1, and it won't stay up 5 minutes > > B> without EM watchdog resets unless I use giant locks. > > B>Is there any way you'd like me to help you with testing the updated > > B> drivers? > > > > Yes, please upgrade to the latemost RELENG_6 via cvsup, build a new > > kernel and report whether the problem is fixed or not. > > > > You see, I have added a o lot of people and two mailing lists to Cc. > > Please do not remove them, when replying. Thanks! > > > > -- > > Totus tuus, Glebius. > > GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
On Fri, Nov 10, 2006 at 04:28:30PM -0600, Barry Boes wrote: B> B> Luck ran out. Hard "must press the reset button" hang. No console B> messages. The system was idle at the time. B>Is there anything you'd like me to do to attempt to narrow down the B> problem or get debugging output? I do not know if the freeze was B> related to em or something else. In cases like this you need to prepare a kernel with debugger compiled in and try to exit into the debugger, when the hang occurs. You can try keyboard debugger sequence, and if it fails try serial break. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EM stability
On 11/10/06, Barry Boes <[EMAIL PROTECTED]> wrote: Luck ran out. Hard "must press the reset button" hang. No console messages. The system was idle at the time. Is there anything you'd like me to do to attempt to narrow down the problem or get debugging output? I do not know if the freeze was related to em or something else. Is this a machine running some graphic head? If not can you see anything on the console? Are you sure the machine is dead, like can you get in over the network... ? One thing I often do when you are dealing with unpredictable hangs is run 'vmstat 3' on one of the virtual terminals. You might also define the kernel debugger into your kernel, its best to have a serial console for this, I've seen the hardware console be locked but the serial will still work. The only way we will track this down is thru repetitive reproduction I'm afraid. Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reentrant problem with inet_ntoa in the kernel
2006/11/10, Bruce Evans <[EMAIL PROTECTED]>:
On Fri, 10 Nov 2006, MQ wrote:
> 2006/11/5, Bruce Evans <[EMAIL PROTECTED]>:
>>
>> On Sat, 4 Nov 2006, Brooks Davis wrote:
>>
>> > On Sat, Nov 04, 2006 at 02:46:30AM +, MQ wrote:
>> >> 2006/11/3, Brooks Davis <[EMAIL PROTECTED]>:
>>
>> >>> The particular definition used is excedingly ugly. At a minimum
there
>> >>> needs to be a define or a constant "16" for the lenght rather than
the
>> >>> 4*sizeof("123") nonsense.
>>
>> The `4*sizeof "123"' is not nonsense. It is better than the userland
>> version
>> at the time it was committed. The userland version hard-coded the size
as
>> 18 (sic). The current userland version still hard-codes 18, but now
>> actually needs it to print an error message of length 17. The uglyness
in
>> `4*sizeof "123"' is just that it has 3 formatting style bugs (missing
>> ...
>> > I'd just use 16. The inet_ntoa function is frankly inane. It
attempts
>> > to support chars that aren't 8 bits which would break so much stuff
it
>> > isn't funny.
>>
>> No, it assumes 8-bit chars. It's masking with 0xff is apparently
copied
>> from an old implementation that used plain chars. The userland
>> implementation at the time it was committed does that, but uses a macro
>> to do the masking and is missing lots of style bugs.
>>
>> The userland version now calls inet_ntop(). This is missing the design
>> bug of using a static buffer. It calls inet_ntop4() for the ipv4 case.
>> This is closer to being non-ugly:
>>
>> % static const char *
>> % inet_ntop4(const u_char *src, char *dst, socklen_t size)
>> % {
>> % static const char fmt[] = "%u.%u.%u.%u";
>> % char tmp[sizeof "255.255.255.255"];
>> % int l;
>> %
>> % l = snprintf(tmp, sizeof(tmp), fmt, src[0], src[1], src[2],
>> src[3]);
>> % if (l <= 0 || (socklen_t) l >= size) {
>> % errno = ENOSPC;
>> % return (NULL);
>> % }
>> % strlcpy(dst, tmp, size);
>> % return (dst);
>> % }
>>
>> I would write this as:
>>
>> %%%
>> CTASSERT(CHAR_BIT == 8);/* else src would be misintepreted */
>>
>> static const char *
>> inet_ntop4(const u_char *src, char *dst, socklen_t size)
>> {
>> int n;
>>
>> n = snprintf(dst, size, "%u.%u.%u.%u", src[0], src[1], src[2],
>> src[3]);
>> assert(n >= 0); /* CHAR_BIT == 8 imples 0 < n <= 16 */
>> ...
> I don't know why the ret array in the userland version of the inet_ntoa
> should be 17. The length of the message itself is 17, and an \0 is
needed
> for the str* to work.
Yes, it needs to be 18 for the error message. I wrote "18 (sic)" because
18 is a surprising value. Anyone who knows what an inet address is would
expect a length of 16. But programmers shouldn't be counting bytes in
strings and mentally computing max(16, 18) and hard-coding that. The
magic 16 won't change, but the 18 might. Spelling 16/18 as a macro
and hard-coding 16/18 in the macro would be even worse, since the value is
only used onece.
> By the way, 4 * sizeof("123") chars should be always enough to contain
an
> IPv4 address, no matter how many bits consititute a char.
It's enough for an ipv4 address, but inet_ntop4() is a library routine
so it shouldn't crash on invalid input. With 8-bit chars, it happens
that there is no invalid input for u_char *src (except a src array with
less than 4 chars in it). With >= 10-bit chars, the result could be
"1023.1023.1023.1023", which isn't an ipv4 address and is too large
for a 16-18 byte buffer. inet_ntop4() needs to ensure that this and
some other errors don't occur. It uses mainly snprintf(), but with
snprintf() another set of errors and out-of-bounds values can occur
in theory, and inet_ntop4()'s handling of these is not quite right.
Bruce
I see. Though inet_ntoa in the userland will never result in a buffer
overflow, it may return a invalid result to the caller. The inet_ntoa in the
kernel use an and with 0xff to ensure the reuslt is always a IPv4 Address,
so in this aspect, it's better than that in the userland. I really agree
with you that the use of a hard-coded macro is a bad idea. It's still
confusing and less portable than that calculated by the compiler.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
On Fri, 10 Nov 2006, Florent Thoumie wrote: On Nov 9, 2006, at 9:39 PM, Gábor Kövesdán wrote: Florent Thoumie wrote: On Nov 8, 2006, at 1:36 PM, Massimo Lusetti wrote: Hi all, I'm pleased to tell you i got the latest wpi driver from Damien Bergamini to work properly on a latest -stable on an Acer laptop. Nice work! Unfortunately, it seems that this is still that unfinished driver from Damien, that circulates on the net everywhere, but it only works for some lucky people. As for me, I get an error message when loading the module, that it could not allocate resources. Haven't taken my 3945 "powered" laptop in Milan, so I haven't had the chance to try it yet. Is it the same as the one we can find in deischen public space on freefall? It's very similar to the version I already had, the diff is maybe 10 lines. I realize the driver itself is beta, but I have also found the 3945 "card" to be a general piece of crap compared to my atheros pccard in terms of throughput and stability (in both windows and freebsd). -- This .signature sanitized for your protection___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
Mike Tancsa wrote: At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike Hi, Thanks for all of the data. I know that a good amount of testing was done with single stream stress tests, but it's not clear how much was done with multiple streams prior to your efforts. So, I'm not terribly surprised by your results. I'm still a bit unclear on the exact topology of your setup, so if could explain it some more in private email, I'd appreciate it. For the short term, I don't think that there is anything that can be magically tweaked that will safely give better results. I know that Gleb has some ideas on a fairly simple change for the non-INTR_FAST, non-POLLING case, but I and several others worry that it's not robust in the face of real-world network problems. For the long term, I have a number of ideas for improving both the RX and TX paths in the driver. Some of it is specific to the if_em driver, some involve improvements in the FFWD and PFIL_HOOKS code as well as the driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise unresponsive. If you can, getting a process dump might help confirm where each CPU is spending its time. Scott ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
- Original Message - From: "Scott Long" <[EMAIL PROTECTED]> To: "Mike Tancsa" <[EMAIL PROTECTED]> Cc: "freebsd-net" ; <[EMAIL PROTECTED]>; ; "Jack Vogel" <[EMAIL PROTECTED]> Sent: Saturday, November 11, 2006 8:42 AM Subject: Re: Proposed 6.2 em RELEASE patch Mike Tancsa wrote: At 05:00 PM 11/10/2006, Jack Vogel wrote: On 11/10/06, Mike Tancsa <[EMAIL PROTECTED]> wrote: Some more tests. I tried again with what was committed to today's RELENG_6. I am guessing its pretty well the same patch. Polling is the only way to avoid livelock at a high pps rate. Does anyone know of any simple tools to measure end to end packet loss ? Polling will end up dropping some packets and I want to be able to compare. Same hardware from the previous post. The commit WAS the last patch I posted. SO, making sure I understood you, you are saying that POLLING is doing better than FAST_INTR, or only better than the legacy code that went in with my merge? Hi, The last set of tests I posted are ONLY with what is in today's RELENG_6-- i.e. the latest commit. I did a few variations on the driver-- first with #define EM_FAST_INTR 1 in if_em.c one without and one with polling in the kernel. With a decent packet rate passing through, the box will lockup. Not sure if I am just hitting the limits of the PCIe bus, or interrupt moderation is not kicking in, or this is a case of "Doctor, it hurts when I send a lot of packets through"... "Well, dont do that" Using polling prevents the lockup, but it will of course drop packets. This is for firewalls with a fairly high bandwidth rate, as well as I need it to be able to survive a decent DDoS attack. I am not looking for 1Mpps, but something more than 100Kpps ---Mike Hi, Thanks for all of the data. I know that a good amount of testing was done with single stream stress tests, but it's not clear how much was done with multiple streams prior to your efforts. So, I'm not terribly surprised by your results. I'm still a bit unclear on the exact topology of your setup, so if could explain it some more in private email, I'd appreciate it. For the short term, I don't think that there is anything that can be magically tweaked that will safely give better results. I know that Gleb has some ideas on a fairly simple change for the non-INTR_FAST, non-POLLING case, but I and several others worry that it's not robust in the face of real-world network problems. For the long term, I have a number of ideas for improving both the RX and TX paths in the driver. Some of it is specific to the if_em driver, some involve improvements in the FFWD and PFIL_HOOKS code as well as the driver. What will help me is if you can hook up a serial console to your machine and see if it can be made to drop to the debugger while it is under load and otherwise unresponsive. If you can, getting a process dump might help confirm where each CPU is spending its time. Scott I applied Jack's patch to the em driver and all seemed well until xl was giving me the same issues. Thanks Jack on my machine your first patch looks 100% Since my box does not take too much load and to me a slightly more loaded machine is better than an unstable one i re-complied the kernel without SMP so I have a dual CPU system with only one of the CPU's working. I've smacked it with about 50G of data using samba and FTP and it didn't blink. I am however using a fxp card for the live IP side but the xl's are still in the kernel and getting picked up. I have just not configured them with IP's for traffic. I don't think this is the issue tho. I'd say there's something to do with the SMP code that is causing these issues. I have another box with SMP on it. Same kind of setup with a Tyan Tiger instead of a Thunder motherboard. 2 Fxp NICs in it. Most of the time it's stable but if i throw a lot of traffic at it it locks up too. Next time it does I will post the console message, but there is no warnings about watchdog timeouts far as I can remember. It's running 5.5-RELEASE-p8 with SMP enabled. -Clay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
