Chris Cappuccio 於 2018-12-04 08:56 寫到:
Reyk Floeter [r...@openbsd.org] wrote:
Yes, KVM???s stable bit is not a reliable indication as it is seems to
depend on the capabilities of the KVM version and not the actual
availability of the feature on the particular hardware. How annoying.
As ment
Hi Scott,
Scott Cheloha wrote on Mon, Dec 03, 2018 at 08:47:23PM -0600:
> This diff makes it an error to invoke sed(1) without any command
> or script.
I'm not convinced this makes anything better for anybody.
For people who do not currently call sed(1) without giving
a script, it makes no diffe
Hi,
This diff makes it an error to invoke sed(1) without any command or
script.
In POSIX.1-2008 the sed(1) synopsis changed from this:
sed [-n] script[file...]
sed [-n][-e script]...[-f script_file]...[file...]
to this:
sed [-n] script [file...]
sed [-n] -e script [-e script]... [-f sc
Reyk Floeter [r...@openbsd.org] wrote:
>
> Yes, KVM???s stable bit is not a reliable indication as it is seems to depend
> on the capabilities of the KVM version and not the actual availability of the
> feature on the particular hardware. How annoying.
>
> As mentioned before: I???d like to disab
> Am 04.12.2018 um 00:52 schrieb Chris Cappuccio :
>
> johnw [johnw.m...@gmail.com] wrote:
>>
>> Hi, after disable pvclock, it can boot with new kernel again, thanks.
> ...
>> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 105.29 MHz, 06-17-0a
>> cpu0:
>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,
johnw [johnw.m...@gmail.com] wrote:
>
> Hi, after disable pvclock, it can boot with new kernel again, thanks.
...
> cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 105.29 MHz, 06-17-0a
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,
On Mon, Dec 03, 2018 at 05:59:26PM +0100, Julien Dhaille wrote:
> Hi. I am using bgpd within a rdomain (1).
> After the upgrade to 6.4 stable, I can’t announce prefixes anymore via
> bgpctl :
>
> router# ps aux -o rtable|grep bgp
>
> root 4039 0.0 0.1 300 1292 p0 S+p 5:12PM 0:00.
On Mon, Dec 03, 2018 at 09:19:10PM +0100, Denis Fondras wrote:
> On Mon, Dec 03, 2018 at 05:59:26PM +0100, Julien Dhaille wrote:
> > Hi. I am using bgpd within a rdomain (1).
> > After the upgrade to 6.4 stable, I can’t announce prefixes anymore via
> > bgpctl :
> >
> > router# ps aux -o rtable|gr
Ping?
Could anyone give more feedback on this one?
Im running this patch for around 2 minths without issues on my laptop
with E2400 chipset.
I understand that this is quite big change and also it might be that
no one has supported card for this driver. Or perhaps because of the
driver being for
On Mon, Dec 03, 2018 at 06:22:14PM +0100, Claudio Jeker wrote:
> This adds a feature to vmctl/vmd to wait for a VM to stop.
> It is a feature usable in many situation where you wait for a VM to halt
> after work is done. This is more or less vmctl stop -w without
> sending the termination to the V
On Mon, Dec 03, 2018 at 12:14:13PM +0100, Claudio Jeker wrote:
> There is a trivial optimization that bgpd can do when loading the filter
> ruleset. If the rule is the same as the previous rule than the filterset
> can be merged. e.g.
>
> match from ebgp set community delete $myAS:*
> mat
This adds a feature to vmctl/vmd to wait for a VM to stop.
It is a feature usable in many situation where you wait for a VM to halt
after work is done. This is more or less vmctl stop -w without
sending the termination to the VM.
There is only one vmctl that can wait so if a second one comes in t
On Mon, Dec 03, 2018 at 11:57:34AM +0100, Claudio Jeker wrote:
> Next round of conversions. Additionally to converting MH_ALIGN() to
> m_align() this also switches m_gethdr/M_GETHDR calls to m_get/M_GET calls
> because M_MOVE_PKTHDR() is initialising the pkthdr and so there is no need
> to do that
Hi. I am using bgpd within a rdomain (1).
After the upgrade to 6.4 stable, I can’t announce prefixes anymore via
bgpctl :
router# ps aux -o rtable|grep bgp
root 4039 0.0 0.1 300 1292 p0 S+p 5:12PM 0:00.00 grep
bgp 0
root 68170 0.0 0.2 1056 2060 p2 I+ 4:5
On Mon, Dec 03, 2018 at 01:44:38PM +0100, Mark Kettenis wrote:
> > Date: Mon, 3 Dec 2018 12:51:32 +0100
> > From: Nils Frohberg
> >
> > Hi,
> >
> > is it safe to call usbd_delay_ms() from under splusb()? In axen(4),
> > axen_rxeof() is called from usb_transfer_complete() which runs at
> > splusb()
> Date: Mon, 3 Dec 2018 12:51:32 +0100
> From: Nils Frohberg
>
> Hi,
>
> is it safe to call usbd_delay_ms() from under splusb()? In axen(4),
> axen_rxeof() is called from usb_transfer_complete() which runs at
> splusb() (called via usbd_transfer()).
It is perfectly fine to call usbd_delay_ms()
Hi,
I'm currently investigating crashes that occur when using an ASIX
88179 USB 3.0 adapter. I'm comparing axen(4) with FreeBSD and Linux
drivers. There is a bigger patch to clean up axen(4) in the pipeline,
but there's still a bit of work to be done.
The following patch was sent by sc.dying to t
Hi,
is it safe to call usbd_delay_ms() from under splusb()? In axen(4),
axen_rxeof() is called from usb_transfer_complete() which runs at
splusb() (called via usbd_transfer()).
The following patch prevents a panic on my system.
Index: sys/dev/usb/if_axen.c
===
There is a trivial optimization that bgpd can do when loading the filter
ruleset. If the rule is the same as the previous rule than the filterset
can be merged. e.g.
match from ebgp set community delete $myAS:*
match from ebgp set community $myAS:15
match from ebgp set med 100
Will b
Next round of conversions. Additionally to converting MH_ALIGN() to
m_align() this also switches m_gethdr/M_GETHDR calls to m_get/M_GET calls
because M_MOVE_PKTHDR() is initialising the pkthdr and so there is no need
to do that when allocating the mbuf.
OK?
--
:wq Claudio
Index: net/if_gre.c
=
On Sun, Dec 02, 2018 at 11:15:03AM +0100, Claudio Jeker wrote:
> On Sun, Dec 02, 2018 at 09:29:23AM +0100, Claudio Jeker wrote:
> > On Sat, Dec 01, 2018 at 06:44:31PM -0800, Greg Steuck wrote:
> > > This thwarts the reproducer. Again, I don't know if the invariants are
> > > getting violated somewh
21 matches
Mail list logo
