Thanks to all!
as NGie says, I used the labeling through NANO_LABEL and it works very
well!
Now in the /etc/fstab I have the label and not the disk specific partition!
Maybe is better to set default label in the nanobsd.sh and not the driver
in according to NGie.
Cheers,
Stefano
Il giorno mer
m=ufs:/dev/da0s1a
vfs.root.mountfrom.options=ro
mountroot>
At this point I need to manually specify "ufs:/dev/ad0s1a" to properly mount
the root.
Can you help me?
There is some tricks to avoid this mountroot error?
Thanks,
Stefano Garzarella
Hi Oliver,
Thank you very much!
I solved it setting NANO_LABEL="mylabel".
Cheers,
Stefano
Il giorno mar 15 set 2015 alle 12:05 O. Hartmann <
ohart...@zedat.fu-berlin.de> ha scritto:
> On Tue, 15 Sep 2015 11:31:36 +0200
> Stefano Garzarella <stefanogarzare...@gmail
Hi all,
when I compile bhyve, I have the following errors from clang:
pci_emul.c:750:2: error: unused typedef '__assert750'
[-Werror,-Wunused-local-typedef]
CTASSERT(sizeof(struct msicap) == 14);
pci_emul.c:776:2: error: unused typedef '__assert776'
[-Werror,-Wunused-local-typedef]
, 2015 at 2:29 PM Eric Joyner e...@freebsd.org wrote:
I guess I could reverse-MFC r283668, then, to make that work on HEAD.
On Mon, Jun 22, 2015, 12:07 PM Stefano Garzarella
stefanogarzare...@gmail.com wrote:
Hi all,
I tried to compile FreeBSD-head with only device ix (without device
ixv
2015-06-22 17:03 GMT+02:00 Luigi Rizzo ri...@iet.unipi.it:
On Monday, June 22, 2015, Stefano Garzarella stefanogarzare...@gmail.com
wrote:
Hi all,
I'm using picobsd on FreeBSD-head (r284697) to build a picobsd image with
gcc, but I have the following errors during the init phase
(release
\
compile-with ${NORMAL_C} -I$S/dev/ixgbe
dev/ixgbe/ixgbe_dcb.c optional ix ixv inet \
compile-with ${NORMAL_C} -I$S/dev/ixgbe
cheers,
Stefano
--
*Stefano Garzarella*
Software Engineer
e-mail: stefano.garzare...@gmail.com
github: http://github.com/stefano-garzarella
linkedin: http
HAVE_IMMINTRIN_H 1
#endif
Before r281316 all work fine.
Thanks,
Stefano Garzarella
--
*Stefano Garzarella*
Software Engineer
e-mail: stefano.garzare...@gmail.com
github: http://github.com/stefano-garzarella
linkedin: http://it.linkedin.com/pub/stefano-garzarella
, Stefano Garzarella
stefanogarzare...@gmail.com wrote:
Much of the advantage of TSO comes from crossing the network stack only
once per (large) segment instead of once per 1500-byte frame.
GSO does the same both for segmentation (TCP) and fragmentation (UDP)
by doing these operations as late
, Stefano Garzarella
stefanogarzare...@gmail.com wrote:
I saw the discussion about TSO, but the GSO is a software
implementation unrelated with the hardware.
Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is
not executed, because is useless.
After the execution
/17/14 20:18, Stefano Garzarella wrote:
Hi Adrian,
the results that I sent, regard just one flow, but I can try with two
simultaneous flows and I'll send you the results.
Thanks,
Stefano
Hi Stefano,
You might have seen the discussion about TSO. Is it so that the proposed
GSO feature only
-m_pkthdr.csum_flags CSUM_GSO_MASK) != 0), it is segmented
or fragmented, and then they are sent to the device driver.
At https://github.com/stefano-garzarella/freebsd-gso
you can find the kernel patches for FreeBSD-current, FreeBSD
10-stable, FreeBSD 9-stable, a simple application (gso-stats.c)
that prints
for outbound, so it's not _as_ big a deal as it is for inbound,
but it'd still be nice to know.
-a
On 17 September 2014 01:27, Stefano Garzarella
stefanogarzare...@gmail.com wrote:
Hi all,
I have recently worked, during my master’s thesis with the supervision
of Prof. Luigi Rizzo, on a project
using the same Borja environment and
I don't have panic.
Can you try this patch? Do you still have the panic?
Cheers,
Stefano Garzarella
diff --git a/sys/dev/oce/oce_if.c b/sys/dev/oce/oce_if.c
index af57491..33b35b4 100644
--- a/sys/dev/oce/oce_if.c
+++ b/sys/dev/oce/oce_if.c
@@ -142,6 +142,7
Marcos bor...@sarenet.es:
On Jul 15, 2014, at 10:22 AM, Stefano Garzarella wrote:
Hi,
I found other problems in the oce driver during some experiments with
netmap in emulation mode.
What about driver version 10.0.747.0? At least in my configuration it
works perfectly, no crashes despite
I think there is some problem with the email formatting.
I send you a file with both patches.
Cheers,
Stefano
2014-07-15 11:12 GMT+02:00 Borja Marcos bor...@sarenet.es:
On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote:
I used the oce driver in CURRENT.
I think that this patch
I just tried to run iperf3 with this patch and STABLE-10 and it seems to
work.
Do you have a panic?
Cheers,
Stefano
2014-07-15 11:19 GMT+02:00 Stefano Garzarella stefanogarzare...@gmail.com:
I think there is some problem with the email formatting.
I send you a file with both patches
2014-07-15 11:46 GMT+02:00 Borja Marcos bor...@sarenet.es:
On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote:
I just tried to run iperf3 with this patch and STABLE-10 and it seems to
work.
Do you have a panic?
Still compiling :) Anyway, you didn't suffer panics before, right
2014-07-15 12:00 GMT+02:00 Borja Marcos bor...@sarenet.es:
On Jul 15, 2014, at 11:45 AM, Stefano Garzarella wrote:
I just tried to run iperf3 with this patch and STABLE-10 and it seems to
work.
Do you have a panic?
So far, so good. I've ran a couple of iperf3 tests (60 seconds, trying
) and
other drivers:
if the mbuf is enqueued, the proper return value is 0
This patch has been reviewed by luigi (in cc).
If someone could have a look on this and give me some feedback it would be
great.
Regards,
Stefano Garzarella
diff --git a/sys/dev/oce/oce_if.c b/sys/dev/oce/oce_if.c
index
20 matches
Mail list logo