From snabb@tiktik.epipe.com Wed Jan 26 08:59:17 2011 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A7D1065694 for ; Wed, 26 Jan 2011 08:59:17 +0000 (UTC) (envelope-from snabb@tiktik.epipe.com) Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:1828:0:3::2]) by mx1.freebsd.org (Postfix) with ESMTP id C5F9C8FC08 for ; Wed, 26 Jan 2011 08:59:16 +0000 (UTC) Received: from tiktik.epipe.com (localhost [127.0.0.1]) by tiktik.epipe.com (8.14.4/8.14.4) with ESMTP id p0Q8xCcY024512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 08:59:15 GMT (envelope-from snabb@tiktik.epipe.com) Received: (from snabb@localhost) by tiktik.epipe.com (8.14.4/8.14.4/Submit) id p0Q8xCpk024330; Wed, 26 Jan 2011 08:59:12 GMT (envelope-from snabb) Message-Id: <201101260859.p0Q8xCpk024330@tiktik.epipe.com> Date: Wed, 26 Jan 2011 08:59:12 GMT From: Janne Snabb Reply-To: Janne Snabb To: FreeBSD-gnats-submit@freebsd.org Cc: snabb@epipe.com Subject: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac X-Send-Pr-Version: 3.113 X-GNATS-Notify: >Number: 154302 >Category: kern >Synopsis: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-xen >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jan 26 09:00:23 UTC 2011 >Closed-Date: Tue Sep 27 13:41:12 UTC 2011 >Last-Modified: Tue Jan 31 18:20:12 UTC 2012 >Originator: Janne Snabb >Release: FreeBSD 8.2-RC2 amd64 >Organization: EPIPE Communications >Environment: 8.2RC1 (i386 and amd64) as distributed and 8.2RC2 (amd64) as of 2011-01-14 as well as CURRENT (amd64) as of 2011-01-14 (r217387). Xen 4.0.1 with Gentoo (x86_64 testing) dom0 and also Xen 4.0.1, 3.4.3 and 3.3.2 with CentOS 5.5 (x86_64) dom0. Various Linux dom0 kernel versions. >Description: I have been trying to get Xen para-virtualized device drivers to work with RELENG_8_2 and -current. It appears that that the netfront driver fails to get the vif mac address which leads to panic shortly afterwards. The Xen networking mode is bridged (with default config, automatically allocated mac address). Setting the mac address manually in Xen config does not help. If I enable the xenbus drivers (XENHVM kernel config on amd64 or XEN on i386) I always get the following result: [..] xenpci0: port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 xs_probe: Probe retuns 0 xenstore0: on xenpci0 [..] xenbusb_front0: on xenstore0 xn0: at device/vif/0 on xenbusb_front0 xn0: Error 2 parsing device/vif/0/mac xn0: Fatal error. Transitioning to Closing State xbd0: 30720MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 332MB at device/vbd/5632 on xenbusb_front0 xbd1: attaching as ad2 panic: do something smart When using full HVM mode (emulated realtek) I have no problems with Xen 4.0.1 nor 3.4.3 (both i386 and amd64 GENERIC kernels work fine). There is a mailing list thread by myself about this at: http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000761.html ...where one other person also confirms this problem at: http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000775.html He also confirms that my patch fixes the problem for him. Below is one full boot message log with a kernel backtrace. RELENG_8_2 kernel amd64 config XENHVM (Xen 4.0.1 HVM mode): KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RC2 #2: Fri Jan 14 06:05:39 UTC 2011 snabb@xxx.epipe.com:/usr/obj/usr/src/sys/XENHVM amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3460 @ 2.80GHz (2800.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0x1781fbff Features2=0x80982201> AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1016918016 (969 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 cpu4 (AP): APIC ID: 8 cpu5 (AP): APIC ID: 10 cpu6 (AP): APIC ID: 12 cpu7 (AP): APIC ID: 14 ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 xenpci0: port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0 xs_probe: Probe retuns 0 xenstore0: on xenpci0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc9000-0xc97ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec acd0: CDROM at ata1-master WDMA2 xenbusb_front0: on xenstore0 xn0: at device/vif/0 on xenbusb_front0 xn0: Error 2 parsing device/vif/0/mac xn0: Fatal error. Transitioning to Closing State xbd0: 30720MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 332MB at device/vbd/5632 on xenbusb_front0 xbd1: attaching as ad2 panic: do something smart cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 netfront_attach() at netfront_attach+0x18c device_attach() at device_attach+0x69 xenbusb_probe_children() at xenbusb_probe_children+0xdf xenbusb_attach() at xenbusb_attach+0x11c device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a xs_attach_deferred() at xs_attach_deferred+0x21 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0xab boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x2c mi_startup() at mi_startup+0x77 btext() at btext+0x2c KDB: enter: panic [thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3d: movq $0,0x6c7a90(%rip) db> halt >How-To-Repeat: Try to boot i386 XEN kernel or amd64 XENHVM kernel in similar environment. Obviously this does not happen with every Xen environment as there is no prior reports about this. >Fix: If the "mac" node does not appear in the front-end vif directory, look for it in the backend directory for the same vif. Two alternative patches: --- sys/dev/xen/netfront/netfront.c.orig 2010-12-21 17:09:25.000000000 +0000 +++ sys/dev/xen/netfront/netfront.c 2011-01-17 10:11:06.000000000 +0000 @@ -401,13 +401,14 @@ xen_net_read_mac(device_t dev, uint8_t mac[]) { int error, i; char *s, *e, *macstr; - error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, - (void **) &macstr); - if (error) + if (xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, + (void **) &macstr) == ENOENT && + (error = xs_read(XST_NIL, xenbus_get_otherend_path(dev), + "mac", NULL, (void **) &macstr)) != 0) return (error); s = macstr; for (i = 0; i < ETHER_ADDR_LEN; i++) { mac[i] = strtoul(s, &e, 16); --- sys/dev/xen/netfront/netfront.c.orig 2010-12-21 17:09:25.000000000 +0000 +++ sys/dev/xen/netfront/netfront.c 2011-01-17 10:11:06.000000000 +0000 @@ -401,13 +401,14 @@ xen_net_read_mac(device_t dev, uint8_t mac[]) { int error, i; char *s, *e, *macstr; - error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, - (void **) &macstr); - if (error) + if ((error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, + (void **) &macstr)) != 0 && + (error = xs_read(XST_NIL, xenbus_get_otherend_path(dev), + "mac", NULL, (void **) &macstr)) != 0) return (error); s = macstr; for (i = 0; i < ETHER_ADDR_LEN; i++) { mac[i] = strtoul(s, &e, 16); >Release-Note: >Audit-Trail: Responsible-Changed-From-To: freebsd-bugs->freebsd-xen Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 26 11:00:00 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154302 From: Janne Snabb To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: First patch is not good Date: Fri, 28 Jan 2011 07:26:05 +0000 (UTC) I wanted to add that the 1st patch I provided is not a good idea. It does not take into account that some other error than ENOENT could be returned. The 2nd patch is better. Alternatively it could be split to 2 separate if clauses. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From: Janne Snabb To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: xn0: Error 2 parsing device/vif/0/mac [WORKAROUND] Date: Sat, 12 Feb 2011 09:12:06 +0000 (UTC) Justin T. Gibbs pointed out[1] that there is a simple workaround to this problem: Just remove 'type=ioemu' from the Xen domU's configuration. For example change: vif = [ 'type=ioemu, bridge=br0' ] ...to: vif = [ 'bridge=br0' ] After that the the mac node magically appears on the front-end side: # xenstore-read device/vif/0/mac 00:16:3e:69:3e:99 I think there is still a need for a patch though because not everyone (for examle VPS customers) have access to their domU's configuration. References: [1] http://lists.freebsd.org/pipermail/freebsd-xen/2011-February/000825.html -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From: Nick Sayer To: bug-followup@FreeBSD.org, snabb@epipe.com Cc: Subject: Re: kern/154302: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac Date: Sun, 13 Feb 2011 00:36:31 -0800 > I think there is still a need for a patch though because not everyone > (for examle VPS customers) have access to their domU's configuration. Seconded. I am in this boat, and the patch is necessary and effective. From: Alex To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac Date: Mon, 14 Feb 2011 23:15:25 +1100 Thirded. My Xen VPS is unusable without this patch (unless I revert back to a non XEN kernel like GENERIC). From: Janne Snabb To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: Linux suffers from the same problem Date: Tue, 5 Apr 2011 08:47:26 +0000 (UTC) Just an interesting note about this issue: I noticed that Linux suffers from the same problem. The Linux driver is somehow able to proceed even though getting the mac address fails. Therefore this Xen bug/feature does not cause headaches there, even though we need a workaround in FreeBSD driver. Have a look at Red Hat's virtualization guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Troubleshooting_the_Xen_para_virtualized_drivers-Verifying_the_para_virtualized_drivers_have_successfully_loaded.html There you will see the following line: vif vif-0: 2 parsing device/vif/0/mac ...which is an indication of this very same error condition. However according to the Red Hat documentation this just means that the PV drivers have successfully loaded :). -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From: Janne Snabb To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: better do-something-smart.patch Date: Sun, 22 May 2011 09:16:19 +0000 (UTC) Here is a new patch which is hopefully neat enough to be committed. Could someone with a commit bit consider this? Lots of people are having trouble beacuse of this bug. It can be argued that the bug is in Xen and not in FreeBSD, but in reality we do need a work-around in FreeBSD. (Or if not, the panic message should be "something smarter". :) --- do-something-smart.patch begins here --- Index: sys/dev/xen/netfront/netfront.c =================================================================== --- sys/dev/xen/netfront/netfront.c (revision 222131) +++ sys/dev/xen/netfront/netfront.c (working copy) @@ -408,9 +408,27 @@ error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, (void **) &macstr); - if (error) - return (error); + if (error) { + /* + * Try to read the 'mac' node from the backend side in case + * it does not exist (ENOENT) in the frontend side. This + * happens with various Xen versions if 'type=ioemu' is set + * in the vif configuration. See PR 154302 for more details. + * Otherwise return the error to the caller. + */ + if (error != ENOENT) + return (error); + + if (xs_read(XST_NIL, xenbus_get_otherend_path(dev), "mac", + NULL, (void **) &macstr) != 0) + /* + * Return the error code of the frontend read (it + * is always ENOENT at this point). + */ + return (error); + } + s = macstr; for (i = 0; i < ETHER_ADDR_LEN; i++) { mac[i] = strtoul(s, &e, 16); --- do-something-smart.patch ends here --- -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: commit references a PR Date: Wed, 21 Sep 2011 00:13:12 +0000 (UTC) Author: gibbs Date: Wed Sep 21 00:13:04 2011 New Revision: 225708 URL: http://svn.freebsd.org/changeset/base/225708 Log: Modify the netfront driver so it can successfully attach to PV devices with the ioemu attribute set. sys/dev/xen/netfront/netfront.c: o If a mac address for the interface cannot be found in the front-side XenStore tree, look for an entry in the back-side tree. With ioemu devices, the emulator does not populate the front side tree and neither does Xend. o Return an error rather than panic when an attach attempt fails. Reported by: Janne Snabb (fix inspired by patch provided) PR: kern/154302 Approved by: re Modified: head/sys/dev/xen/netfront/netfront.c Modified: head/sys/dev/xen/netfront/netfront.c ============================================================================== --- head/sys/dev/xen/netfront/netfront.c Wed Sep 21 00:08:25 2011 (r225707) +++ head/sys/dev/xen/netfront/netfront.c Wed Sep 21 00:13:04 2011 (r225708) @@ -406,11 +406,33 @@ xen_net_read_mac(device_t dev, uint8_t m { int error, i; char *s, *e, *macstr; + const char *path; - error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, - (void **) &macstr); - if (error) + path = xenbus_get_node(dev); + error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr); + if (error == ENOENT) { + /* + * Deal with missing mac XenStore nodes on devices with + * HVM emulation (the 'ioemu' configuration attribute) + * enabled. + * + * The HVM emulator may execute in a stub device model + * domain which lacks the permission, only given to Dom0, + * to update the guest's XenStore tree. For this reason, + * the HVM emulator doesn't even attempt to write the + * front-side mac node, even when operating in Dom0. + * However, there should always be a mac listed in the + * backend tree. Fallback to this version if our query + * of the front side XenStore location doesn't find + * anything. + */ + path = xenbus_get_otherend_path(dev); + error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr); + } + if (error != 0) { + xenbus_dev_fatal(dev, error, "parsing %s/mac", path); return (error); + } s = macstr; for (i = 0; i < ETHER_ADDR_LEN; i++) { @@ -451,7 +473,7 @@ netfront_attach(device_t dev) err = create_netdev(dev); if (err) { xenbus_dev_fatal(dev, err, "creating netdev"); - return err; + return (err); } #if __FreeBSD_version >= 700000 @@ -461,7 +483,7 @@ netfront_attach(device_t dev) &xn_enable_lro, 0, "Large Receive Offload"); #endif - return 0; + return (0); } static int @@ -2067,11 +2089,8 @@ create_netdev(device_t dev) } err = xen_net_read_mac(dev, np->mac); - if (err) { - xenbus_dev_fatal(dev, err, "parsing %s/mac", - xenbus_get_node(dev)); + if (err) goto out; - } /* Set up ifnet structure */ ifp = np->xn_ifp = if_alloc(IFT_ETHER); @@ -2105,8 +2124,7 @@ create_netdev(device_t dev) exit: gnttab_free_grant_references(np->gref_tx_head); out: - panic("do something smart"); - + return (err); } /** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" State-Changed-From-To: open->closed State-Changed-By: gibbs State-Changed-When: Tue Sep 27 13:40:19 UTC 2011 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=154302 From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: commit references a PR Date: Tue, 31 Jan 2012 18:13:59 +0000 (UTC) Author: gibbs Date: Tue Jan 31 18:13:49 2012 New Revision: 230831 URL: http://svn.freebsd.org/changeset/base/230831 Log: MFC r225708 into stable/8: Modify the netfront driver so it can successfully attach to PV devices with the ioemu attribute set. sys/dev/xen/netfront/netfront.c: o If a mac address for the interface cannot be found in the front-side XenStore tree, look for an entry in the back-side tree. With ioemu devices, the emulator does not populate the front side tree and neither does Xend. o Return an error rather than panic when an attach attempt fails. Reported by: Janne Snabb (fix inspired by patch provided) PR: kern/154302 Modified: stable/8/sys/dev/xen/netfront/netfront.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/dev/xen/netfront/netfront.c ============================================================================== --- stable/8/sys/dev/xen/netfront/netfront.c Tue Jan 31 17:51:30 2012 (r230830) +++ stable/8/sys/dev/xen/netfront/netfront.c Tue Jan 31 18:13:49 2012 (r230831) @@ -402,11 +402,33 @@ xen_net_read_mac(device_t dev, uint8_t m { int error, i; char *s, *e, *macstr; + const char *path; - error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, - (void **) &macstr); - if (error) + path = xenbus_get_node(dev); + error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr); + if (error == ENOENT) { + /* + * Deal with missing mac XenStore nodes on devices with + * HVM emulation (the 'ioemu' configuration attribute) + * enabled. + * + * The HVM emulator may execute in a stub device model + * domain which lacks the permission, only given to Dom0, + * to update the guest's XenStore tree. For this reason, + * the HVM emulator doesn't even attempt to write the + * front-side mac node, even when operating in Dom0. + * However, there should always be a mac listed in the + * backend tree. Fallback to this version if our query + * of the front side XenStore location doesn't find + * anything. + */ + path = xenbus_get_otherend_path(dev); + error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr); + } + if (error != 0) { + xenbus_dev_fatal(dev, error, "parsing %s/mac", path); return (error); + } s = macstr; for (i = 0; i < ETHER_ADDR_LEN; i++) { @@ -447,7 +469,7 @@ netfront_attach(device_t dev) err = create_netdev(dev); if (err) { xenbus_dev_fatal(dev, err, "creating netdev"); - return err; + return (err); } #if __FreeBSD_version >= 700000 @@ -457,7 +479,7 @@ netfront_attach(device_t dev) &xn_enable_lro, 0, "Large Receive Offload"); #endif - return 0; + return (0); } @@ -2020,11 +2042,8 @@ create_netdev(device_t dev) } err = xen_net_read_mac(dev, np->mac); - if (err) { - xenbus_dev_fatal(dev, err, "parsing %s/mac", - xenbus_get_node(dev)); + if (err) goto out; - } /* Set up ifnet structure */ ifp = np->xn_ifp = if_alloc(IFT_ETHER); @@ -2066,8 +2085,7 @@ create_netdev(device_t dev) exit: gnttab_free_grant_references(np->gref_tx_head); out: - panic("do something smart"); - + return (err); } /** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" >Unformatted: