Re: FreeBSD 10-RC4: Got crash in igb driver
Le 10 janv. 2014 à 02:21, Yonghyeon PYUN pyu...@gmail.com a écrit : On Thu, Jan 09, 2014 at 04:06:09PM +0100, Alexandre Martins wrote: Dear, I experience some troubles with the igb device driver on FreeBSD 10-RC4. The kernel make a pagefault in the igb_tx_ctx_setup function when accessing to a IPv6 header. The network configuration is the following: - box acting as an IPv6 router - one interface with an IPv6 (igb0) - another interface with a vlan, and IPv6 on it (vlan0 on igb1) Vlan Hardware tagging is set on both interfaces. The packet that cause the crash come from igb0 and go to vlan0. After investigation, i see that the mbuf is split in two. The first one carry the ethernet header, the second, the IPv6 header and data payload. The split is due to the m_copy done in ip6_forward, that make the mbuf not writable and the M_PREPEND in ether_output that insert the new mbuf before the original one. The kernel crashes only if the newly allocated mbuf is at the end of a memory page, and no page is available after this one. So, it's extremly rare. I inserted a KASSERT into the function (see attached patch) to check this behavior, and it raises on every IPv6 forwarded packet to the vlan. The problem disapear if i remove hardware tagging. In the commit 256200, i see that pullups has been removed. May it be related ? I think I introduced the header parsing code to meet controller requirement in em(4) and Jack borrowed that code in the past but it seems it was removed in r256200. It seems igb_tx_ctx_setup() assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf of the chain. This looks wrong to me. Instead of patching each driver with pullup code we can add a generic pullup code ? - get the contiguous protocol requirement (L2, L3, L4) from underlying driver. - do the pullup Can you confirm the problem ? Probably Jack can tell more about change made in r256200. It's not easy for me to verify correctness of igb(4) at this moment. Best regards -- Alexandre Martins NETASQ -- We secure IT ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10-RC4: Got crash in igb driver
On Fri, Jan 10, 2014 at 09:37:33AM +0100, Fabien Thomas wrote: Le 10 janv. 2014 ? 02:21, Yonghyeon PYUN pyu...@gmail.com a ?crit : On Thu, Jan 09, 2014 at 04:06:09PM +0100, Alexandre Martins wrote: Dear, I experience some troubles with the igb device driver on FreeBSD 10-RC4. The kernel make a pagefault in the igb_tx_ctx_setup function when accessing to a IPv6 header. The network configuration is the following: - box acting as an IPv6 router - one interface with an IPv6 (igb0) - another interface with a vlan, and IPv6 on it (vlan0 on igb1) Vlan Hardware tagging is set on both interfaces. The packet that cause the crash come from igb0 and go to vlan0. After investigation, i see that the mbuf is split in two. The first one carry the ethernet header, the second, the IPv6 header and data payload. The split is due to the m_copy done in ip6_forward, that make the mbuf not writable and the M_PREPEND in ether_output that insert the new mbuf before the original one. The kernel crashes only if the newly allocated mbuf is at the end of a memory page, and no page is available after this one. So, it's extremly rare. I inserted a KASSERT into the function (see attached patch) to check this behavior, and it raises on every IPv6 forwarded packet to the vlan. The problem disapear if i remove hardware tagging. In the commit 256200, i see that pullups has been removed. May it be related ? I think I introduced the header parsing code to meet controller requirement in em(4) and Jack borrowed that code in the past but it seems it was removed in r256200. It seems igb_tx_ctx_setup() assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf of the chain. This looks wrong to me. Instead of patching each driver with pullup code we can add a generic pullup code ? - get the contiguous protocol requirement (L2, L3, L4) from underlying driver. - do the pullup I believe Andre already planned that and he would be working on removing home-grown header parser implemented in drivers. Can you confirm the problem ? Probably Jack can tell more about change made in r256200. It's not easy for me to verify correctness of igb(4) at this moment. Best regards -- Alexandre Martins NETASQ -- We secure IT ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unused in_cksum_update() ?
On Thu, Jan 09, 2014 at 08:21:14PM +0100, Luigi Rizzo wrote:
L a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h)
L have a lengthy definition for
L
L in_cksum_update(struct ip *ip)
L
L which seems completely unused in our source tree.
L Time to remove it perhaps ?
L
L grep cannot find any use at least since stable/8
I'd prefer not to hurry with its removal. Might be that pf will use it.
Since it lives in a header file, it doesn't add a single bit to kernel
size.
--
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10-RC4: Got crash in igb driver
Yonghyeon, On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote: Y I experience some troubles with the igb device driver on FreeBSD 10-RC4. Y Y The kernel make a pagefault in the igb_tx_ctx_setup function when accessing to Y a IPv6 header. Y Y The network configuration is the following: Y - box acting as an IPv6 router Y - one interface with an IPv6 (igb0) Y - another interface with a vlan, and IPv6 on it (vlan0 on igb1) Y Y Vlan Hardware tagging is set on both interfaces. Y Y The packet that cause the crash come from igb0 and go to vlan0. Y Y After investigation, i see that the mbuf is split in two. The first one carry Y the ethernet header, the second, the IPv6 header and data payload. Y Y The split is due to the m_copy done in ip6_forward, that make the mbuf not Y writable and the M_PREPEND in ether_output that insert the new mbuf before Y the original one. Y Y The kernel crashes only if the newly allocated mbuf is at the end of a memory Y page, and no page is available after this one. So, it's extremly rare. Y Y I inserted a KASSERT into the function (see attached patch) to check this Y behavior, and it raises on every IPv6 forwarded packet to the vlan. The Y problem disapear if i remove hardware tagging. Y Y In the commit 256200, i see that pullups has been removed. May it be related ? Y Y I think I introduced the header parsing code to meet controller Y requirement in em(4) and Jack borrowed that code in the past but it Y seems it was removed in r256200. It seems igb_tx_ctx_setup() Y assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf Y of the chain. Y This looks wrong to me. Can you please restore the important code in head ASAP? Although crashes happen only when the mbuf is last in a page and page isn't mapped, we read thrash from next allocation on almost every packet. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Move 3G modem from u3g to uhso?
Ah I see. Of course usb.conf is generated automatically :) I guess it is
generated at make buildkernel and the new one can be found in obj folder?
Here is the patch:
Index: sys/dev/usb/net/uhso.c
===
--- sys/dev/usb/net/uhso.c(revision 260369)
+++ sys/dev/usb/net/uhso.c(working copy)
@@ -281,6 +281,8 @@
UHSO_DEV(OPTION, ICON505, UHSO_AUTO_IFACE),
/* Option iCON 452 */
UHSO_DEV(OPTION, ICON505, UHSO_AUTO_IFACE),
+/* Option GTM661W */
+UHSO_DEV(OPTION, GTM661W, UHSO_AUTO_IFACE),
#undef UHSO_DEV
};
Index: sys/dev/usb/serial/u3g.c
===
--- sys/dev/usb/serial/u3g.c(revision 260369)
+++ sys/dev/usb/serial/u3g.c(working copy)
@@ -388,7 +388,6 @@
U3G_DEV(OPTION, GTMAXHSUPA, 0),
U3G_DEV(OPTION, GTMAXHSUPAE, 0),
U3G_DEV(OPTION, VODAFONEMC3G, 0),
-U3G_DEV(OPTION, GTM661W, 0),
U3G_DEV(QISDA, H20_1, 0),
U3G_DEV(QISDA, H20_2, 0),
U3G_DEV(QISDA, H21_1, 0),
Thank you!
--
Johannes Lundberg
On Fri, Jan 10, 2014 at 4:07 PM, Hans Petter Selasky h...@bitfrost.nowrote:
On 01/10/14 06:06, Lundberg, Johannes wrote:
Hi
I have been using Globetrotter HSUPA Modem Option N.V. usb modem for a
while with the uhso driver and now I installed 11-CURRENT and see that it
has been added to devd and u3g is loaded automatically. Since this device
has support for it wouldn't it be better to use uhso driver so we get the
uhso0 network interface?
The device in question is
nomatch 32 {
match bus uhub[0-9]+;
match mode host;
match vendor 0x0af0;
match product 0x9000;
action kldload -n u3g;
};
which I changed to
nomatch 32 {
match bus uhub[0-9]+;
match mode host;
match vendor 0x0af0;
match product 0x9000;
action kldload -n uhso;
};
But this also requires adding the device in sys/dev/usb/net/uhso.c
/* Option GTM661W */
UHSO_DEV(OPTION, GTM661W, UHSO_AUTO_IFACE),
Hi,
When you remove the device entry from the u3g.c driver, the usb.conf
file will be updated later. Can you submit a complete patch for this?
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nanobsd / dd problem?
mike wrote: Hi, On Mon, 9 Dec 2013, freebsdonline wrote: ... Theres also an issue with package management, the nanobsd script still uses pkg_add instead of pkg. for -current I've added cust_pkgng() to nanobsd.sh It needs to get called manually instead of cust_pkg() though. ( customize_cmd cust_pkgng ) Greetings --- Michael Reifenberger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Still the nanobsd.sh script is building a broken image on FreeBSD 10.0 RC4: After booting the image in a VirtualBox machine: Trying to mount root from ufs:/dev/ada0s1a [ro]... mount: /dev/ada0s3: Invalid argument mount -o ro /dev/ada0s3 /conf/default/etc failed: dropping into /bin/sh It seems the third partition (the one that holds the data for config files) has errors on it: # disklabel /dev/ada0s3 disklabel /dev/ada0s3 disklabel: /dev/ada0s3: no valid label found In my nanobsd.conf I have (20MB for data partition): NANO_MEDIASIZE=2097152 NANO_DATASIZE=40960 NANO_IMAGES=2 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: unused in_cksum_update() ?
On Fri, Jan 10, 2014 at 02:31:40PM +0400, Gleb Smirnoff wrote:
On Thu, Jan 09, 2014 at 08:21:14PM +0100, Luigi Rizzo wrote:
L a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h)
L have a lengthy definition for
L
Lin_cksum_update(struct ip *ip)
L
L which seems completely unused in our source tree.
L Time to remove it perhaps ?
L
L grep cannot find any use at least since stable/8
I'd prefer not to hurry with its removal. Might be that pf will use it.
Since it lives in a header file, it doesn't add a single bit to kernel
size.
we should care more about obfuscation and correcteness, and this is
a killer in both respects.
Depending on $arch the function is not even available or wrong:
In particular, the basic code follows the description in
http://tools.ietf.org/html/rfc1141A with ntohs/htons to deal
with endianness (note that the '256' should not be converted):
tmp = ntohs(sum)+256;
tmp = tmp + (tmp 16);
sum = htons(tmp); // also truncates high bits
It is correctly implemented (but in a totally generic way, so no
point to have it in the arch-specific files) for amd64, i386,
ia64, mips, powerpc; it is not implemented for arm, and it is wrong
for sparc64 (where the 256 is incorrectly replaced by a 1).
In terms of usage: the svn repo suggests that it was added in r15884
in 1996 (stable/2.2 is the first branch where it appears):
http://svnweb.freebsd.org/base/head/sys/i386/include/in_cksum.h?r1=15884r2=15883pathrev=15884
as far as i can tell never used anywhere, and copied from place to
place when we started to support different architectures.
Shall we wait until it becomes 18 ? :)
I am adding Garret to the list as he may have more details.
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10-RC4: Got crash in igb driver
The changes to igb were to add IPV6 support which previously was only in ixgbe, the transmit path code came from that code base, we did not see this issue in testing. Its not a simple matter of a few lines of code, I think we need to go forward not back... I'll look at the code. Jack On Fri, Jan 10, 2014 at 2:35 AM, Gleb Smirnoff gleb...@freebsd.org wrote: Yonghyeon, On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote: Y I experience some troubles with the igb device driver on FreeBSD 10-RC4. Y Y The kernel make a pagefault in the igb_tx_ctx_setup function when accessing to Y a IPv6 header. Y Y The network configuration is the following: Y - box acting as an IPv6 router Y - one interface with an IPv6 (igb0) Y - another interface with a vlan, and IPv6 on it (vlan0 on igb1) Y Y Vlan Hardware tagging is set on both interfaces. Y Y The packet that cause the crash come from igb0 and go to vlan0. Y Y After investigation, i see that the mbuf is split in two. The first one carry Y the ethernet header, the second, the IPv6 header and data payload. Y Y The split is due to the m_copy done in ip6_forward, that make the mbuf not Y writable and the M_PREPEND in ether_output that insert the new mbuf before Y the original one. Y Y The kernel crashes only if the newly allocated mbuf is at the end of a memory Y page, and no page is available after this one. So, it's extremly rare. Y Y I inserted a KASSERT into the function (see attached patch) to check this Y behavior, and it raises on every IPv6 forwarded packet to the vlan. The Y problem disapear if i remove hardware tagging. Y Y In the commit 256200, i see that pullups has been removed. May it be related ? Y Y I think I introduced the header parsing code to meet controller Y requirement in em(4) and Jack borrowed that code in the past but it Y seems it was removed in r256200. It seems igb_tx_ctx_setup() Y assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf Y of the chain. Y This looks wrong to me. Can you please restore the important code in head ASAP? Although crashes happen only when the mbuf is last in a page and page isn't mapped, we read thrash from next allocation on almost every packet. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2014-01-10 21:45:38 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-10 21:45:38 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-10 21:45:38 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-01-10 21:45:38 - cleaning the object tree TB --- 2014-01-10 21:45:38 - /usr/local/bin/svn stat /src TB --- 2014-01-10 21:45:42 - At svn revision 260510 TB --- 2014-01-10 21:45:43 - building world TB --- 2014-01-10 21:45:43 - CROSS_BUILD_TESTING=YES TB --- 2014-01-10 21:45:43 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-10 21:45:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-10 21:45:43 - SRCCONF=/dev/null TB --- 2014-01-10 21:45:43 - TARGET=sparc64 TB --- 2014-01-10 21:45:43 - TARGET_ARCH=sparc64 TB --- 2014-01-10 21:45:43 - TZ=UTC TB --- 2014-01-10 21:45:43 - __MAKE_CONF=/dev/null TB --- 2014-01-10 21:45:43 - cd /src TB --- 2014-01-10 21:45:43 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Fri Jan 10 21:45:50 UTC 2014 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 [...] ln -sf /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gthr-posix.h gthr-default.h ln -sf /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/unwind-generic.h unwind.h cc -O2 -pipe -I. -DGCCVER=\4.2\ -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -DCROSS_DIRECTORY_STRUCTURE -I/obj/sparc64.sparc64/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 -std=gnu89 -I/obj/sparc64.sparc64/src/tmp/legacy/usr/include -c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c: In function 'main': /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattr.c:91: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop. bmake[2]: stopped in /src/gnu/usr.bin/cc/cc_tools *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-10 21:48:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-10 21:48:34 - ERROR: failed to build world TB --- 2014-01-10 21:48:34 - 119.04 user 30.18 system 176.65 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Install 10.0-RC3 on MacBookPro Late 2013
Hi, I got one problem when I unplug/plug Buffalo WLI-UC-GNM, it is USB WLAN. All USB devices become to disconnected after unplug and plug: ugen0.9: Ralink at usbus0 run0: 1.0 on usbus0 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 4c:e6:76:d4:c9:5e wlan0: Ethernet address: 4c:e6:76:d4:c9:5e run0: firmware RT2870 ver. 0.33 loaded wlan0: link state changed to UP ugen0.9: Ralink at usbus0 (disconnected) run0: at uhub0, port 1, addr 8 (disconnected) wlan0: link state changed to DOWN xhci0: Port routing mask set to 0x usb_alloc_device: device init 9 failed (USB_ERR_IOERROR, ignored) ugen0.9: Unknown at usbus0 (disconnected) uhub_reattach_port: could not allocate new device ugen0.2: Logitech at usbus0 (disconnected) ums0: at uhub0, port 5, addr 1 (disconnected) ugen0.3: Apple Inc. at usbus0 (disconnected) uhub1: at uhub0, port 8, addr 2 (disconnected) ugen0.4: vendor 0x05ac at usbus0 (disconnected) ukbd0: at uhub1, port 1, addr 3 (disconnected) ugen0.5: vendor 0x05ac at usbus0 (disconnected) ums1: at uhub1, port 2, addr 4 (disconnected) ugen0.6: Apple Inc. at usbus0 (disconnected) ugen0.7: Apple Inc. at usbus0 (disconnected) ukbd1: at uhub0, port 12, addr 6 (disconnected) uhid0: at uhub0, port 12, addr 6 (disconnected) ums2: at uhub0, port 12, addr 6 (disconnected) ugen0.8: Apple at usbus0 (disconnected) umass0: at uhub0, port 19, addr 7 (disconnected) da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: APPLE SD Card Reader 3.00 s/n 0820 detached (da0:umass-sim0:0:0:0): Periph destroyed I still revert xhci_interrupt back to 9.1R, unplug/plug this WLAN, xhci driver works perfect. Cheers, Huang Wen Hui 2014/1/7 Hans Petter Selasky h...@bitfrost.no On 01/07/14 08:07, Huang Wen Hui wrote: Hi, This patch fixed my problem! Thanks, Huang Wen Hui. http://svnweb.freebsd.org/changeset/base/260388 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
