> On 14 Feb 2020, at 19:18, Ed Maste wrote:
>
> Upstream OpenSSH-portable removed libwrap support in version 6.7,
> released in October 2014. We've maintained a patch in our tree to
> restore it, but it causes friction on each OpenSSH update and may
> introduce security vulnerabilities not pres
you suggested you (Borja Marcos) did with the Dell salesman), where in
> reality each has its own advantages and disadvantages.
I know, but this is not the case. But it’s quite frustrating to try to order a
server with a HBA rather than a RAID and receiving an answer such as
“the HBA op
> On 01 Aug 2016, at 15:12, O. Hartmann wrote:
>
> First, thanks for responding so quickly.
>
>> - The third option is to make the driver expose the SAS devices like a HBA
>> would do, so that they are visible to the CAM layer, and disks are handled by
>> the stock “da” driver, which is the ide
> On 01 Aug 2016, at 08:45, O. Hartmann wrote:
>
> On Wed, 22 Jun 2016 08:58:08 +0200
> Borja Marcos wrote:
>
>> There is an option you can use (I do it all the time!) to make the card
>> behave as a plain HBA so that the disks are handled by the “da” driver
On Dec 5, 2014, at 2:00 PM, Steven Hartland wrote:
>
> On 04/09/2014 09:49, Borja Marcos wrote:
>> On Jun 30, 2014, at 8:02 PM, John Baldwin wrote:
>>
>>> I think these sound fine, but I've cc'd Xin Li (delphij@) who has worked
>>> with
>&
On Jun 30, 2014, at 8:02 PM, John Baldwin wrote:
>
> I think these sound fine, but I've cc'd Xin Li (delphij@) who has worked with
> folks at Emulex to maintain this driver. He is probably the best person to
> review this.
Hi,
Seems 10.1 is on the pipeline now, but as far as I know none of th
On Jul 15, 2014, at 1:36 PM, Stefano Garzarella wrote:
> So, asking for spiritual counsel now. Would you use this driver in a
> production environment instead of the 747 version downloaded from Emulex? I
> think the latter is giving slightly better performance but, anyway, I disable
> LRO and
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 both
directions) and it doesn't crash.
Without the fixes I ob
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?
Borja.
___
freebsd-c
On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote:
> I used the "oce" driver in CURRENT.
> I think that this patch in combination with the previous one should work in
> 10-STABLE.
>
> I have only tested if it works with CURRENT, but now I try if it works with
> 10-STABLE and I'll send you s
On Jul 15, 2014, at 10:43 AM, Stefano Garzarella wrote:
> I used the "oce" driver in CURRENT.
> I think that this patch in combination with the previous one should work in
> 10-STABLE.
>
> I have only tested if it works with CURRENT, but now I try if it works with
> 10-STABLE and I'll send yo
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 keeping it running for s
On Jul 7, 2014, at 1:23 PM, Luigi Rizzo wrote:
> On Mon, Jul 7, 2014 at 1:03 PM, Borja Marcos wrote:
> we'll try to investigate, can you tell us more about the environment you use ?
> (FreeBSD version, card model (PCI id perhaps), iperf3 invocation line,
> interface configurati
On Jul 1, 2014, at 10:24 PM, Luigi Rizzo wrote:
>
>
>
> On Tue, Jul 1, 2014 at 8:58 PM, wrote:
> El 30.06.2014 18:36, Stefano Garzarella escribió:
>
> Hello,
> I had problems during some experiments with Emulex and "oce" driver in
> CURRENT.
> I found several bugs in the "oce" driver and thi
On Sep 13, 2013, at 2:18 PM, Steven Hartland wrote:
> This is a recent bit of code by Justin cc'ed, so he's likely the best person
> to
> investigate this one.
Hmm. There is still a lot of confusion surrounding all this, and it's a time
bomb waiting to explode.
A friend had serious problems o
Looking at the kernel sources, I see that in /usr/src/sys/i386/i386/trap.c,
--- snip
/*
* note: PCPU_LAZY_INC() can only be used if we can afford
* occassional inaccuracy in the count.
*/
PCPU_LAZY_INC(cnt.v_syscall);
--- snip
This seems to be a macro to
Hello,
I have tried to file PR, but the web pages give an authorization error.
There is a problem in -CURRENT. The vm.stats.sys.v_syscall from the system
MIB is not updated. This variable was used at least by the systat command,
and it happens to be used by an Orca (www
17 matches
Mail list logo
