Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
On Thu, Nov 11, 2010 at 9:30 PM, Wilkinson, Alex 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"
Re: New event timers for 8-STABLE
2010/11/11 Alexander Motin : > 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]
> > 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 [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"
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"
[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-relen
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
> From: Pyun YongHyeon > 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 > > > > > > > > > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > > > > > From: Kevin Oberman > > > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > > > To: "Wilkinson, Alex" > > > > 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" > > > > > 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
[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 __
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 > > > > > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > > > From: Kevin Oberman > > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > > To: "Wilkinson, Alex" > > > 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" > > > > 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
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
--- On Thu, 11/11/10, Mike Tancsa wrote: > From: Mike Tancsa > 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" > >> 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" > _
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" >> 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]
> Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > From: Kirill Yelizarov > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > From: Kevin Oberman > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > To: "Wilkinson, Alex" > > 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" > > > 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 th
Re: 8-STABLE buildworld failure
On Tue, Nov 9, 2010 at 11:48 PM, Jeremy Chadwick 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: Sense fetching [Was: cdrtools /devel ...]
Alexander Motin 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: Sense fetching [Was: cdrtools /devel ...]
Joerg Schilling wrote: > Alexander Motin 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 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 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: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
--- On Thu, 11/11/10, Kirill Yelizarov wrote: > From: Kirill Yelizarov > 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 > wrote: > > > From: Kevin Oberman > > Subject: Re: icmp packets on em larger than 1472 > [SEC=UNCLASSIFIED] > > To: "Wilkinson, Alex" > > 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" > > > 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) > > Er
Re: Sense fetching [Was: cdrtools /devel ...]
Alexander Motin 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: Sense fetching [Was: cdrtools /devel ...]
Joerg Schilling wrote: > Alexander Motin 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 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"