Re: Sense fetching [Was: cdrtools /devel ...]
Alexander Motin m...@freebsd.org wrote: Given the fact that many drives will probably only return 18 bytes of sense data, this will happen every time libscg is told to fetch more sense than the drive is willing to return. Is there a way to distinct an old kernel from a new one? I don't see the problem. Previous kernel in most cases reported sesnse_resid == 0, lying that there is more sense data then really is. New one should report real (often positive) value. In both cases sesnse_resid value measured from the value submitted to the kernel. Did the old kernel return a zero sense_resid for any implemented SCSI transport? Libscg is a generic SCSI transport library and cdrecord is just one user of this lib. Not sure I understand your question. Zero sesnse_resid is absolutely normal situation if device gave same amount of sense as application requested. As I can see, many of SCSI controllers report sesnse_resid properly. I may assume that some, like atapicd don't -- in that case you'll also see 0 there. FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be that some drives did return only 18 bytes. In this case, I would asume that there is a resid 0. Do you know the CAM behavior for other SCSI transports? I don't have real SCSI CD to test, but a as I can see, most of SCSI controllers return sense data automatically. Sense fetching changes should not affect/break anything there. The question still remains whether the previous implementation did return resid 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Joerg Schilling wrote: Alexander Motin m...@freebsd.org wrote: Given the fact that many drives will probably only return 18 bytes of sense data, this will happen every time libscg is told to fetch more sense than the drive is willing to return. Is there a way to distinct an old kernel from a new one? I don't see the problem. Previous kernel in most cases reported sesnse_resid == 0, lying that there is more sense data then really is. New one should report real (often positive) value. In both cases sesnse_resid value measured from the value submitted to the kernel. Did the old kernel return a zero sense_resid for any implemented SCSI transport? Libscg is a generic SCSI transport library and cdrecord is just one user of this lib. Not sure I understand your question. Zero sesnse_resid is absolutely normal situation if device gave same amount of sense as application requested. As I can see, many of SCSI controllers report sesnse_resid properly. I may assume that some, like atapicd don't -- in that case you'll also see 0 there. FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be that some drives did return only 18 bytes. In this case, I would asume that there is a resid 0. As I have said, many drivers return resid properly, but some others - don't. These changes should just improve situation. Do you know the CAM behavior for other SCSI transports? I don't have real SCSI CD to test, but a as I can see, most of SCSI controllers return sense data automatically. Sense fetching changes should not affect/break anything there. The question still remains whether the previous implementation did return resid 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Alexander Motin m...@freebsd.org wrote: The question still remains whether the previous implementation did return resid 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
--- On Thu, 11/11/10, Kirill Yelizarov ykir...@yahoo.com wrote:
From: Kirill Yelizarov ykir...@yahoo.com
Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
To: freebsd-stable@freebsd.org
Date: Thursday, November 11, 2010, 10:49 AM
--- On Thu, 11/11/10, Kevin Oberman ober...@es.net
wrote:
From: Kevin Oberman ober...@es.net
Subject: Re: icmp packets on em larger than 1472
[SEC=UNCLASSIFIED]
To: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au
Cc: freebsd-stable@freebsd.org
Date: Thursday, November 11, 2010, 8:26 AM
Date: Thu, 11 Nov 2010 13:01:26
+0800
From: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au
Sender: owner-freebsd-sta...@freebsd.org
0n Wed, Nov 10, 2010 at
04:21:12AM -0800, Kirill Yelizarov wrote:
All my em cards running
8.1 stable don't reply to icmp echo requests packets
larger
than 1472 bytes.
On stable 7.2 the same
hardware works as expected:
# ping -s 1500
192.168.64.99
PING 192.168.64.99
(192.168.64.99): 1500 data bytes
1508 bytes from
192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms
1508 bytes from
192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms
Here is the dump on em
interface
15:06:31.452043 IP
192.168.66.65 *: ICMP echo request, id 28729,
seq
5, length 1480
15:06:31.452047 IP
192.168.66.65 : icmp
15:06:31.452069 IP
192.168.66.65: ICMP echo reply, id 28729, seq 5,
length
1480
15:06:31.452071 IP ***
192.168.66.65: icmp
Same ping from same source
(it's a 8.1 stable with fxp interface) to em card
running
8.1 stable
#pciconf -lv
e...@pci0:3:4:0:
class=0x02 card=0x10798086 chip=0x10798086
rev=0x03
hdr=0x00
vendor
= 'Intel Corporation'
device
= 'Dual Port Gigabit Ethernet Controller
(82546EB)'
class
= network
subclass = ethernet
# ping -s 1472
192.168.64.200
PING 192.168.64.200
(192.168.64.200): 1472 data bytes
1480 bytes from
192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms
^C
# ping -s 1473
192.168.64.200
PING 192.168.64.200
(192.168.64.200): 1473 data bytes
^C
--- 192.168.64.200 ping
statistics ---
4 packets transmitted, 0
packets received, 100.0% packet loss
works fine for me:
FreeBSD 8.1-STABLE #0 r213395
e...@pci0:0:25:0:class=0x02 card=0x3035103c
chip=0x10de8086 rev=0x02 hdr=0x00
vendor
= 'Intel Corporation'
device
= 'Intel Gigabit network connection
(82567LM-3 )'
class =
network
subclass =
ethernet
#ping -s 1473 host
PING host(192.168.1.1): 1473 data bytes
1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253
time=31.506 ms
1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253
time=31.493 ms
1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253
time=31.550 ms
^C
The reason the '-s 1500' worked was that the packets
were
fragmented. If
I add the '-D' option, '-s 1473' fails on v7 and v8.
Are
the V8 systems
where you see if failing without the '-D' on the same
network segment?
If not, it is likely that an intervening device is
refusing
to fragment
the packet. (Some routers deliberately don't fragment
ICMP
Echos Request
packets.)
If i set -D -s 1473 sender side refuses to ping and that is
correct. All mentioned above machines are behind the same
router and switch. Same hardware running v7 is working while
v8 is not. And i never saw such problems before. Also
correct me if i'm wrong but the dump shows that the packet
arrived. I'll try driver from head and will post here
results.
Shame on me! It was pf. I disabled scrubbing. Any of the two methods work
1.
scrub in all
icmp_types = {0, 3, 4, 8, 11 }
pass out quick on $inside_if proto icmp from $inside_ip to any icmp-type
$icmp_types no state
pass in quick on $inside_if proto icmp from any to $inside_ip icmp-type
$icmp_types no state
2.
pass out quick on $inside_if proto icmp from $inside_ip to any no state
pass in quick on $inside_if proto icmp from any to $inside_ip no state
This works without scrubbing
Keep state also working
I disabled scrubbing because it seems to slow down nfs (i'm not shure if this
is right) and i specified icmp types i want to use. What am i doing wrong with
firewall icmp rules? Tcpdump shows echo requests and replies only.
I also compiled new driver from HEAD. It is working like the old one. And
firewall with igb has scrubbing.
Kirill
Kirill
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory
(Berkeley
Lab)
E-mail: ober...@es.net
Phone: +1 510
486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D
EBB3 987B 3751
Re: Sense fetching [Was: cdrtools /devel ...]
Joerg Schilling wrote: Alexander Motin m...@freebsd.org wrote: The question still remains whether the previous implementation did return resid 0 in some cases. In this case, I would need to implement both variants in the libscg adaption layer and I would need to know whether I am running on an old version or on a new version kernel. Do you know of a simple method to implement this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Alexander Motin m...@freebsd.org wrote: Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. What is the requested size with the various HBAs in earlier kernels? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Joerg Schilling wrote: Alexander Motin m...@freebsd.org wrote: Compare the number of sense bytes I like to request (18) with the number previous FreeBSD versions did actually request. It is obvious that in case there is a resid reported onm an old kernel, libscg (with your chanhge) would believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. What is the requested size with the various HBAs in earlier kernels? For HBAs with automatic sense fetching -- as passed in sence_len request field. In case of libscg it was SSD_FULL_SIZE before and I've set it to be real value now. Returned sense_resid should be real in both cases, respecting submitted sense_len. For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE and returned fake zero sense_resid, like if it just completely fulfilled sense_len from request. Now it should start honor sense_len on request and return real sense_resid on reply, relative to sense_len. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
Alexander Motin m...@freebsd.org wrote: What is the requested size with the various HBAs in earlier kernels? For HBAs with automatic sense fetching -- as passed in sence_len request field. In case of libscg it was SSD_FULL_SIZE before and I've set it to be real value now. Returned sense_resid should be real in both cases, respecting submitted sense_len. For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE and returned fake zero sense_resid, like if it just completely fulfilled sense_len from request. Now it should start honor sense_len on request and return real sense_resid on reply, relative to sense_len. Then your patch to libscg seems to be OK and without risk. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8-STABLE buildworld failure
On Tue, Nov 9, 2010 at 11:48 PM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
On Tue, Nov 09, 2010 at 06:09:08PM -0600, Bryce Edwards wrote:
After updating source today, I am receiving the following error when
running make NOCCACHE=YES -j16 buildkernel
Please re-run the buildkernel without any -j or -jXX flags to see where
the actual error happened. The below doesn't show the actual error due
to the nature of the parallel build.
I doubt this has anything to do with ccache.
Thanks Jeremy, I forgot to disable paralllel builds. It is very clear
now that it is related to the following in make.conf:
PORTS_MODULES=emulators/virtualbox-ose-kmod
Looks like the path of the make environment for the port doesn't find
yasm (which is indeed installed and located in /usr/local/bin/yasm).
cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod;
SYSDIR=/usr/src/sys /usr/obj/usr/src/make.amd64/make -B all
=== virtualbox-ose-kmod-3.2.10 depends on executable: yasm - not found
===Verifying install for yasm in /usr/ports/devel/yasm
=== Installing for yasm-1.1.0
=== yasm-1.1.0 depends on shared library: iconv.3 - found
=== yasm-1.1.0 depends on shared library: intl - found
=== Generating temporary packing list
=== Checking if devel/yasm already installed
=== yasm-1.1.0 is already installed
You may wish to ``make deinstall'' and install this port again
by ``make reinstall'' to upgrade it properly.
If you really wish to overwrite the old port of devel/yasm
without deleting it first, set the variable FORCE_PKG_REGISTER
in your environment or the make install command line.
*** Error code 1
Stop in /usr/ports/devel/yasm.
*** Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
*** Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
*** Error code 1
Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
=== zlib (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer
-I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone
-mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/src/sys/modules/zlib/../../net/zlib.c
ld -d -warn-common -r -d -o zlib.ko.debug zlib.o
: export_syms
awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms |
xargs -J% objcopy % zlib.ko.debug
objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols
objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug
zlib.ko
1 error
*** Error code 2
1 error
*** Error code 2
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) From: Kirill Yelizarov ykir...@yahoo.com --- On Thu, 11/11/10, Kevin Oberman ober...@es.net wrote: From: Kevin Oberman ober...@es.net Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] To: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Cc: freebsd-stable@freebsd.org Date: Thursday, November 11, 2010, 8:26 AM Date: Thu, 11 Nov 2010 13:01:26 +0800 From: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Sender: owner-freebsd-sta...@freebsd.org 0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. On stable 7.2 the same hardware works as expected: # ping -s 1500 192.168.64.99 PING 192.168.64.99 (192.168.64.99): 1500 data bytes 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms Here is the dump on em interface 15:06:31.452043 IP 192.168.66.65 *: ICMP echo request, id 28729, seq 5, length 1480 15:06:31.452047 IP 192.168.66.65 : icmp 15:06:31.452069 IP 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 15:06:31.452071 IP *** 192.168.66.65: icmp Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable #pciconf -lv e...@pci0:3:4:0: class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet # ping -s 1472 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1472 data bytes 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ^C # ping -s 1473 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1473 data bytes ^C --- 192.168.64.200 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Gigabit network connection (82567LM-3 )' class = network subclass = ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C The reason the '-s 1500' worked was that the packets were fragmented. If I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems where you see if failing without the '-D' on the same network segment? If not, it is likely that an intervening device is refusing to fragment the packet. (Some routers deliberately don't fragment ICMP Echos Request packets.) If i set -D -s 1473 sender side refuses to ping and that is correct. All mentioned above machines are behind the same router and switch. Same hardware running v7 is working while v8 is not. And i never saw such problems before. Also correct me if i'm wrong but the dump shows that the packet arrived. I'll try driver from head and will post here results. I did a bit more looking at this today and I see that something bogus is going on and it MAY be the em driver. I tried 1473 data byte pings without the DF flag. I then captured the packets on both ends (where the sending system has a bge (Broadcom GE) and the responding end has an em (Intel) card. What I saw was the fragmented IP packets all being received by the system with the em interface and an ICMP Echo Reply being sent back, again fragmented. I saw the reply on both ends, so both interfaces were able to fragment an over-sized packet, transmit the two pieces, and receive the two pieces. The em device could re-assemble them properly, but the bge device does not seem to re-assemble them correctly or else has a problem with ICMP packets bigger then MTU size. When I send from the em system, I see the packets and fragments all arrive in good form, but the system never sends out a reply. Since this is a kernel function, it may be a driver, but I suspect that it is in the IP stack since I am seeing the problem with a Broadcom card and I see the data all arriving. I think Jack can probably relax, but some patch to the network stack seems to have broken at least ICMP processing. And, since the bge system ups updated to 8-Stable on October 20 while the em system was updated back on August 9, I suspect the flaw was not driver related and was
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
On 11/11/2010 12:26 AM, Kevin Oberman wrote: Date: Thu, 11 Nov 2010 13:01:26 +0800 From: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Sender: owner-freebsd-sta...@freebsd.org 0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. On stable 7.2 the same hardware works as expected: # ping -s 1500 192.168.64.99 PING 192.168.64.99 (192.168.64.99): 1500 data bytes 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms Here is the dump on em interface 15:06:31.452043 IP 192.168.66.65 *: ICMP echo request, id 28729, seq 5, length 1480 15:06:31.452047 IP 192.168.66.65 : icmp 15:06:31.452069 IP 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 15:06:31.452071 IP *** 192.168.66.65: icmp Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable #pciconf -lv e...@pci0:3:4:0:class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet # ping -s 1472 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1472 data bytes 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ^C # ping -s 1473 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1473 data bytes ^C --- 192.168.64.200 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Gigabit network connection (82567LM-3 )' class = network subclass = ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C The reason the '-s 1500' worked was that the packets were fragmented. If I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems where you see if failing without the '-D' on the same network segment? If not, it is likely that an intervening device is refusing to fragment the packet. (Some routers deliberately don't fragment ICMP Echos Request packets.) I am not sure I follow. If you do a ping -s 1473 -D on an interface that has the default MTU of 1500, it wont work, as the entire packet is going to be 1501 (note the data bytes) eg. # ping -q -s 1472 -c 1 192.168.43.219 PING 192.168.43.219 (192.168.43.219): 1472 data bytes --- 192.168.43.219 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.714/1.714/1.714/0.000 ms on 192.168.43.219, I see and on .43.219, I see 0(ich10)# tcpdump -vvvni em2 icmp tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 96 bytes 13:49:17.564482 IP (tos 0x0, ttl 63, id 53656, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.42.11 192.168.43.219: ICMP echo request, id 23315, seq 0, length 1480 13:49:17.564499 IP (tos 0x0, ttl 64, id 14346, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.43.219 192.168.42.11: ICMP echo reply, id 23315, seq 0, length 1480 Note the length is 1500 of the packet. That being said, if its failing on the em nic where you dont specify the -D flag on the ping, then there is a bug somewhere. On certain em nics, I found doing ifconfig em0 -rxcsum ifconfig em0 -txcsum ifconfig em0 -tso works around a number of bugs ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
--- On Thu, 11/11/10, Mike Tancsa m...@sentex.net wrote: From: Mike Tancsa m...@sentex.net Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] To: freebsd-stable@freebsd.org Date: Thursday, November 11, 2010, 10:01 PM On 11/11/2010 12:26 AM, Kevin Oberman wrote: Date: Thu, 11 Nov 2010 13:01:26 +0800 From: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Sender: owner-freebsd-sta...@freebsd.org 0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. On stable 7.2 the same hardware works as expected: # ping -s 1500 192.168.64.99 PING 192.168.64.99 (192.168.64.99): 1500 data bytes 1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms 1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms Here is the dump on em interface 15:06:31.452043 IP 192.168.66.65 *: ICMP echo request, id 28729, seq 5, length 1480 15:06:31.452047 IP 192.168.66.65 : icmp 15:06:31.452069 IP 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 15:06:31.452071 IP *** 192.168.66.65: icmp Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable #pciconf -lv e...@pci0:3:4:0: class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet # ping -s 1472 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1472 data bytes 1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ^C # ping -s 1473 192.168.64.200 PING 192.168.64.200 (192.168.64.200): 1473 data bytes ^C --- 192.168.64.200 ping statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Gigabit network connection (82567LM-3 )' class = network subclass = ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C The reason the '-s 1500' worked was that the packets were fragmented. If I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems where you see if failing without the '-D' on the same network segment? If not, it is likely that an intervening device is refusing to fragment the packet. (Some routers deliberately don't fragment ICMP Echos Request packets.) I am not sure I follow. If you do a ping -s 1473 -D on an interface that has the default MTU of 1500, it wont work, as the entire packet is going to be 1501 (note the data bytes) eg. # ping -q -s 1472 -c 1 192.168.43.219 PING 192.168.43.219 (192.168.43.219): 1472 data bytes --- 192.168.43.219 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.714/1.714/1.714/0.000 ms on 192.168.43.219, I see and on .43.219, I see 0(ich10)# tcpdump -vvvni em2 icmp tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 96 bytes 13:49:17.564482 IP (tos 0x0, ttl 63, id 53656, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.42.11 192.168.43.219: ICMP echo request, id 23315, seq 0, length 1480 13:49:17.564499 IP (tos 0x0, ttl 64, id 14346, offset 0, flags [none], proto ICMP (1), length 1500) 192.168.43.219 192.168.42.11: ICMP echo reply, id 23315, seq 0, length 1480 Note the length is 1500 of the packet. That being said, if its failing on the em nic where you dont specify the -D flag on the ping, then there is a bug somewhere. On certain em nics, I found doing ifconfig em0 -rxcsum ifconfig em0 -txcsum ifconfig em0 -tso works around a number of bugs ---Mike Yes, i know it. This was the first thing i tried. Sorry, i didn't mention it. Kirill ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
On Thu, Nov 11, 2010 at 08:10:57AM -0800, Kevin Oberman wrote: Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) From: Kirill Yelizarov ykir...@yahoo.com --- On Thu, 11/11/10, Kevin Oberman ober...@es.net wrote: From: Kevin Oberman ober...@es.net Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] To: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Cc: freebsd-stable@freebsd.org Date: Thursday, November 11, 2010, 8:26 AM Date: Thu, 11 Nov 2010 13:01:26 +0800 From: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Sender: owner-freebsd-sta...@freebsd.org ? ???0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: ? ???All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. ? ??? ? ???On stable 7.2 the same hardware works as expected: ? ???# ping -s 1500 192.168.64.99 ? ???PING 192.168.64.99 (192.168.64.99): 1500 data bytes ? ???1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms ? ???1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms ? ??? ? ???Here is the dump on em interface ? ???15:06:31.452043 IP 192.168.66.65 *: ICMP echo request, id 28729, seq 5, length 1480 ? ???15:06:31.452047 IP 192.168.66.65 : icmp ? ???15:06:31.452069 IP 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 ? ???15:06:31.452071 IP *** 192.168.66.65: icmp ? ??? ? ???Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable ? ???#pciconf -lv ? ???e...@pci0:3:4:0:??? class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 ? ? vendor? ???= 'Intel Corporation' ? ? device? ???= 'Dual Port Gigabit Ethernet Controller (82546EB)' ? ? class? ? ? = network ? ? subclass???= ethernet ? ??? ? ???# ping -s 1472 192.168.64.200 ? ???PING 192.168.64.200 (192.168.64.200): 1472 data bytes ? ???1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ? ???^C ? ??? ? ???# ping -s 1473 192.168.64.200 ? ???PING 192.168.64.200 (192.168.64.200): 1473 data bytes ? ???^C ? ???--- 192.168.64.200 ping statistics --- ? ???4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 ? ???vendor? ???= 'Intel Corporation' ? ???device? ???= 'Intel Gigabit network connection (82567LM-3 )' ? ???class? ? ? = network ? ???subclass???= ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C The reason the '-s 1500' worked was that the packets were fragmented. If I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems where you see if failing without the '-D' on the same network segment? If not, it is likely that an intervening device is refusing to fragment the packet. (Some routers deliberately don't fragment ICMP Echos Request packets.) If i set -D -s 1473 sender side refuses to ping and that is correct. All mentioned above machines are behind the same router and switch. Same hardware running v7 is working while v8 is not. And i never saw such problems before. Also correct me if i'm wrong but the dump shows that the packet arrived. I'll try driver from head and will post here results. I did a bit more looking at this today and I see that something bogus is going on and it MAY be the em driver. I tried 1473 data byte pings without the DF flag. I then captured the packets on both ends (where the sending system has a bge (Broadcom GE) and the responding end has an em (Intel) card. What I saw was the fragmented IP packets all being received by the system with the em interface and an ICMP Echo Reply being sent back, again fragmented. I saw the reply on both ends, so both interfaces were able to fragment an over-sized packet, transmit the two pieces, and receive the two pieces. The em device could re-assemble them properly, but the bge device does not seem to re-assemble them correctly or else has a problem with ICMP packets bigger then MTU size. When I send from the em system, I see the packets and fragments all arrive in good form, but the system never sends out a reply. Since this is a kernel function, it may be a driver, but I suspect that it is in the IP stack since I am seeing the problem with a Broadcom card and I see the data all arriving. Most ethernet controllers including bge(4) have a function to
[releng_7_1 tinderbox] failure on i386/i386
TB --- 2010-11-11 15:34:59 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-11-11 15:34:59 - starting RELENG_7_1 tinderbox run for i386/i386 TB --- 2010-11-11 15:34:59 - cleaning the object tree TB --- 2010-11-11 15:35:03 - cvsupping the source tree TB --- 2010-11-11 15:35:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca -s /usr/home/tinderbox/RELENG_7_1/i386/i386/supfile TB --- 2010-11-11 15:35:08 - building world TB --- 2010-11-11 15:35:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-11 15:35:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-11 15:35:08 - TARGET=i386 TB --- 2010-11-11 15:35:08 - TARGET_ARCH=i386 TB --- 2010-11-11 15:35:08 - TZ=UTC TB --- 2010-11-11 15:35:08 - __MAKE_CONF=/dev/null TB --- 2010-11-11 15:35:08 - cd /src TB --- 2010-11-11 15:35:08 - /usr/bin/make -B buildworld World build started on Thu Nov 11 15:35:09 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies [...] === gnu/usr.bin/cc (depend) === gnu/usr.bin/cc/cc_tools (depend) cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-yacc+%DIKED.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-lex.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/errors.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/i386/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a libiberty.a: could not read symbols: File format not recognized *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-11 16:11:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-11 16:11:13 - ERROR: failed to build world TB --- 2010-11-11 16:11:13 - 1693.76 user 262.76 system 2174.26 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7_1-i386-i386.full ___ freebsd-stable@freebsd.org mailing list
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
From: Pyun YongHyeon pyu...@gmail.com Date: Thu, 11 Nov 2010 13:04:36 -0800 On Thu, Nov 11, 2010 at 08:10:57AM -0800, Kevin Oberman wrote: Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) From: Kirill Yelizarov ykir...@yahoo.com --- On Thu, 11/11/10, Kevin Oberman ober...@es.net wrote: From: Kevin Oberman ober...@es.net Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] To: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Cc: freebsd-stable@freebsd.org Date: Thursday, November 11, 2010, 8:26 AM Date: Thu, 11 Nov 2010 13:01:26 +0800 From: Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au Sender: owner-freebsd-sta...@freebsd.org ? ???0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: ? ???All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. ? ??? ? ???On stable 7.2 the same hardware works as expected: ? ???# ping -s 1500 192.168.64.99 ? ???PING 192.168.64.99 (192.168.64.99): 1500 data bytes ? ???1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms ? ???1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms ? ??? ? ???Here is the dump on em interface ? ???15:06:31.452043 IP 192.168.66.65 *: ICMP echo request, id 28729, seq 5, length 1480 ? ???15:06:31.452047 IP 192.168.66.65 : icmp ? ???15:06:31.452069 IP 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 ? ???15:06:31.452071 IP *** 192.168.66.65: icmp ? ??? ? ???Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable ? ???#pciconf -lv ? ???e...@pci0:3:4:0:??? class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 ? ? vendor? ???= 'Intel Corporation' ? ? device? ???= 'Dual Port Gigabit Ethernet Controller (82546EB)' ? ? class? ? ? = network ? ? subclass???= ethernet ? ??? ? ???# ping -s 1472 192.168.64.200 ? ???PING 192.168.64.200 (192.168.64.200): 1472 data bytes ? ???1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms ? ???^C ? ??? ? ???# ping -s 1473 192.168.64.200 ? ???PING 192.168.64.200 (192.168.64.200): 1473 data bytes ? ???^C ? ???--- 192.168.64.200 ping statistics --- ? ???4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 ? ???vendor? ???= 'Intel Corporation' ? ???device? ???= 'Intel Gigabit network connection (82567LM-3 )' ? ???class? ? ? = network ? ???subclass???= ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C The reason the '-s 1500' worked was that the packets were fragmented. If I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems where you see if failing without the '-D' on the same network segment? If not, it is likely that an intervening device is refusing to fragment the packet. (Some routers deliberately don't fragment ICMP Echos Request packets.) If i set -D -s 1473 sender side refuses to ping and that is correct. All mentioned above machines are behind the same router and switch. Same hardware running v7 is working while v8 is not. And i never saw such problems before. Also correct me if i'm wrong but the dump shows that the packet arrived. I'll try driver from head and will post here results. I did a bit more looking at this today and I see that something bogus is going on and it MAY be the em driver. I tried 1473 data byte pings without the DF flag. I then captured the packets on both ends (where the sending system has a bge (Broadcom GE) and the responding end has an em (Intel) card. What I saw was the fragmented IP packets all being received by the system with the em interface and an ICMP Echo Reply being sent back, again fragmented. I saw the reply on both ends, so both interfaces were able to fragment an over-sized packet, transmit the two pieces, and receive the two pieces. The em device could re-assemble them properly, but the bge device does not seem to re-assemble them correctly or else has a problem with ICMP packets bigger then MTU size. When I send from the em system, I see the packets and fragments all arrive in good form, but the system never sends out a reply. Since this is a
[releng_7_1 tinderbox] failure on i386/pc98
TB --- 2010-11-11 16:11:14 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2010-11-11 16:11:14 - starting RELENG_7_1 tinderbox run for i386/pc98 TB --- 2010-11-11 16:11:14 - mkdir /usr/home/tinderbox/RELENG_7_1/i386/pc98 TB --- 2010-11-11 16:11:14 - cleaning the object tree TB --- 2010-11-11 16:11:14 - cvsupping the source tree TB --- 2010-11-11 16:11:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca -s /usr/home/tinderbox/RELENG_7_1/i386/pc98/supfile TB --- 2010-11-11 16:14:28 - building world TB --- 2010-11-11 16:14:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-11 16:14:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-11 16:14:28 - TARGET=pc98 TB --- 2010-11-11 16:14:28 - TARGET_ARCH=i386 TB --- 2010-11-11 16:14:28 - TZ=UTC TB --- 2010-11-11 16:14:28 - __MAKE_CONF=/dev/null TB --- 2010-11-11 16:14:28 - cd /src TB --- 2010-11-11 16:14:28 - /usr/bin/make -B buildworld World build started on Thu Nov 11 16:14:29 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies [...] === gnu/usr.bin/cc (depend) === gnu/usr.bin/cc/cc_tools (depend) cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-yacc+%DIKED.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c gengtype-lex.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/errors.c cc -O2 -fno-strict-aliasing -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/obj/pc98/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a libiberty.a: could not read symbols: File format not recognized *** Error code 1 Stop in /src/gnu/usr.bin/cc/cc_tools. *** Error code 1 Stop in /src/gnu/usr.bin/cc. *** Error code 1 Stop in /src/gnu/usr.bin. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-11 16:50:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-11 16:50:14 - ERROR: failed to build world TB --- 2010-11-11 16:50:14 - 1702.50 user 287.94 system 2340.17 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7_1-i386-pc98.full
New event timers for 8-STABLE
Hi. I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
0n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote: I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). patches apply cleanly but buildkernel fails: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /usr/src/sys/kern/kern_et.c: No such file or directory cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/MARGS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
patches apply cleanly but buildkernel fails: Works here with fresh source, amd64 -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE
2010/11/11 Alexander Motin m...@freebsd.org: Hi. I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). Reporting successes! No noticeable anomalies yet, two 8-STABLE systems (behaving similarly to my 9-CURRENT system in regard to timer settings). I'll keep prodding away to see what I can break ;) Of course I'll report the pertinent bits if/when required... Good job Alexander! -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
On Thu, Nov 11, 2010 at 9:30 PM, Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au wrote: 0n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote: I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). patches apply cleanly but buildkernel fails: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /usr/src/sys/kern/kern_et.c: No such file or directory cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/MARGS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Revert the patch (patch -R) and reapply the patch with -p0: [/usr/src]# patch -p0 /path/to/file.patch ...and try it again :) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
