> 2015/07/19 19:16、Stefan Fritsch :
>
> On Sat, 18 Jul 2015, David Hill wrote:
>> Whenever I plug a device into my USB ports, my machine locks hard. I
>> have the Intel Series 7 / C216 chip, so xhci attempts to route the port
>> from ehci to xhci.
>>
>> The following diff is from FreeBSD and
After applied the diff, my intel Series 7 PC could not attach any USB3.0 devices
to xHCI, as following (usbdevs output)
addr 1: xHCI root hub, Intel
addr 2: Keyboard & Mouse Ver.0D0200, Microchip Technology Inc.
addr 3: AX88179, ASIX Elec. Corp.
addr 1: EHCI root hub, Intel
addr 2: Rate Match
On Sat, 18 Jul 2015, David Hill wrote:
> Whenever I plug a device into my USB ports, my machine locks hard. I
> have the Intel Series 7 / C216 chip, so xhci attempts to route the port
> from ehci to xhci.
>
> The following diff is from FreeBSD and makes my USB devices work again.
> https://githu
so pflow(4) shoving it's data with ip_output into the network stack
seems wrong. this converts it to use sosend(9) and might even give us
non-legacy IP support.
tests from (heavy) pflow(4) users would be appriciated.
diff --git if_pflow.c if_pflow.c
index 4f3ac5e..624fdaf 100644
--- if_pflow.c
++
Hi Philip,
Philip Guenther wrote on Sun, Jul 19, 2015 at 11:19:53AM -0700:
> On Sun, Jul 19, 2015 at 11:04 AM, Ingo Schwarze wrote:
>> Philip Guenther wrote on Sun, Jul 19, 2015 at 10:28:57AM -0700:
>>> On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze wrote:
I don't think we are vulnerable.
Some (early) acpi machines leave the cardbus bridge unconfigured. In
particular, those machines don't configure the bus number for the
cardbus bus. This makes our driver skip attaching the 32-bit cardbus
handling and only support 16-bit pcmcia cards.
Diff below makes our driver assign an availab
On Mon, Jul 20, 2015 at 02:21:00AM +0200, Hrvoje Popovski wrote:
> On 20.7.2015. 0:53, Bob Beck wrote:
> >
>
> >>>
> >>> I'm pretty sure that's a different problem. But thanks for pointing this
> >>> out.
> >>>
> >>> -ml
> >>>
> >
> > no, just update your tree please, I just committed th
On 20.7.2015. 0:53, Bob Beck wrote:
>
>>>
>>> I'm pretty sure that's a different problem. But thanks for pointing this
>>> out.
>>>
>>> -ml
>>>
>
> no, just update your tree please, I just committed the fix
>
thank you, everything is working after your fix
On 20.7.2015. 0:06, Mark Kettenis wrote:
> The acpi code that reads and writes pci config space is quite busted.
> It always does byte-sized reads and writes even if the aml specifies
> an access size of four bytes. This made vmware unhappy, because it
> expetcs to see a magic value being written
> >>
> >
> > I'm pretty sure that's a different problem. But thanks for pointing this
> > out.
> >
> > -ml
> >
no, just update your tree please, I just committed the fix
On 20.7.2015. 0:41, Mike Larkin wrote:
> On Mon, Jul 20, 2015 at 12:38:19AM +0200, Hrvoje Popovski wrote:
>> On 20.7.2015. 0:06, Mark Kettenis wrote:
>>> The acpi code that reads and writes pci config space is quite busted.
>>> It always does byte-sized reads and writes even if the aml specifies
>>
On Mon, Jul 20, 2015 at 12:38:19AM +0200, Hrvoje Popovski wrote:
> On 20.7.2015. 0:06, Mark Kettenis wrote:
> > The acpi code that reads and writes pci config space is quite busted.
> > It always does byte-sized reads and writes even if the aml specifies
> > an access size of four bytes. This made
On 20.7.2015. 0:06, Mark Kettenis wrote:
> The acpi code that reads and writes pci config space is quite busted.
> It always does byte-sized reads and writes even if the aml specifies
> an access size of four bytes. This made vmware unhappy, because it
> expetcs to see a magic value being written
The acpi code that reads and writes pci config space is quite busted.
It always does byte-sized reads and writes even if the aml specifies
an access size of four bytes. This made vmware unhappy, because it
expetcs to see a magic value being written into a 32-bit register and
not the individual byt
Theo de Raadt cvs.openbsd.org> writes:
>
[replying via gmane, which apparently doesn't like text from the original
email to be quoted so I had to severely strip out text from the original
message, and also doesn't allow this bracketed message to be placed at the
top of my message]
Hi,
I w
On Mon, Jul 20, 2015 at 04:27:45AM +0900, Ryan McBride wrote:
> ok mcbride@
>
err
I took a look at the patch one more time. I've realized PF must bind the rules
to state before STATE_INC_COUNTERS() gets called. Not doing so makes PF to
play games with dangling pointers to rule from state. St
On Sun, Jul 19, 2015 at 08:53:04PM +0200, Gregor Best wrote:
> On Sun, Jul 19, 2015 at 07:03:59PM +0100, Stuart Henderson wrote:
> > [...]
> > I'm uncertain about whether dhclient should do this at all, it seems
> > to be the opposite of the direction dhclient has been going in
> > recently,
> > [.
ok
Stuart Henderson(st...@openbsd.org) on 2015.07.19 17:55:00 +0100:
> In the past, the only option for unbound-control was a TCP socket
> using SSL/TLS, but nowadays it also supports unix domain sockets,
> so it seems like it would be reasonable to enable it by default
> in our configuration so t
On Sun, Jul 19, 2015 at 07:03:59PM +0100, Stuart Henderson wrote:
> [...]
> I'm uncertain about whether dhclient should do this at all, it seems
> to be the opposite of the direction dhclient has been going in
> recently,
> [...]
I've had a similar intuition at first, but it's one less thing to ru
On Sun, Jul 19, 2015 at 11:04 AM, Ingo Schwarze wrote:
> Philip Guenther wrote on Sun, Jul 19, 2015 at 10:28:57AM -0700:
>> On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze wrote:
>
>>> I don't think we are vulnerable.
>>>
>>> If my analysis is accurate, the only user-controlled files
>>> we open
Hi Philip,
Philip Guenther wrote on Sun, Jul 19, 2015 at 10:28:57AM -0700:
> On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze wrote:
>> I don't think we are vulnerable.
>>
>> If my analysis is accurate, the only user-controlled files
>> we open in security(8) are ~/.rhosts and ~/.shosts
>> in che
On 2015/07/19 19:53, Gregor Best wrote:
> On Sun, Jul 19, 2015 at 03:31:33PM +, Florian Obser wrote:
> > [...]
> > Oh god, yes please. I always wanted to write this diff myself ;)
> > More comments in the diff below.
> > [...]
>
> Great to read. I've attached an updated patch.
I'm uncertain a
On Sun, Jul 19, 2015 at 03:31:33PM +, Florian Obser wrote:
> [...]
> Oh god, yes please. I always wanted to write this diff myself ;)
> More comments in the diff below.
> [...]
Great to read. I've attached an updated patch.
--
Gregor Best
Index: clparse.c
===
On Sun, Jul 19, 2015 at 10:24 AM, Ingo Schwarze wrote:
...
> I don't think we are vulnerable.
>
> If my analysis is accurate, the only user-controlled files
> we open in security(8) are ~/.rhosts and ~/.shosts
> in check_rhosts_content(). However, there is
>
> next unless -s $filename;
>
> righ
Hi,
Ted Unangst wrote on Sun, Jul 19, 2015 at 10:26:19AM -0400:
> Sevan Janiyan wrote:
>> The feature was actually added to ensure whatever cat was meant
>> to be reading from was indeed a plain file and not another
>> which could block a process.
>> "Use cat -f to avoid denial of service attacks
On Fri, Jul 17, 2015 at 08:54:26PM +0200, Mark Kettenis wrote:
> Tobias Ulmer schreef op 2015-07-15 02:33:
> >As we all know, some Thinkpads have problems with their EC fan control.
> >EC is not spinning up the fans to maximum speed, let alone blast mode.
> >They also do not offer ACPI methods to s
In the past, the only option for unbound-control was a TCP socket
using SSL/TLS, but nowadays it also supports unix domain sockets,
so it seems like it would be reasonable to enable it by default
in our configuration so that users added to the _unbound group
can access stats and do various types of
On 19/07/15(Sun) 18:33, Mark Kettenis wrote:
> So my "unlocking the reaper" diff that was committed the other day
> breaks the MP architectures that don't have an "mpsafe" pmap yet (see
> my commit message). Is seems hppa's pmap is actually safe enough, but
> alpha, m88k, mips64 and powerpc aren't
Mark Kettenis schreef op 2015-07-19 18:33:
So my "unlocking the reaper" diff that was committed the other day
breaks the MP architectures that don't have an "mpsafe" pmap yet (see
my commit message). Is seems hppa's pmap is actually safe enough, but
alpha, m88k, mips64 and powerpc aren't. The d
I really like this idea, modulo the comments that Florian made.
On 2015 Jul 19 (Sun) at 13:08:46 +0200 (+0200), Gregor Best wrote:
:Hello,
:
:the following is a patch that adds an option called `update_unbound' to
:dhclient.conf. With this option enabled, dhclient will call
:
: unbound-cont
So my "unlocking the reaper" diff that was committed the other day
breaks the MP architectures that don't have an "mpsafe" pmap yet (see
my commit message). Is seems hppa's pmap is actually safe enough, but
alpha, m88k, mips64 and powerpc aren't. The diff below fixes alpha
and powerpc with a big
On 2015/07/19 13:08, Gregor Best wrote:
> Hello,
>
> the following is a patch that adds an option called `update_unbound' to
> dhclient.conf. With this option enabled, dhclient will call
>
> unbound-control forwards
>
> instead of rewriting /etc/resolv.conf.
>
> My usage scenario is th
On Sun, Jul 19, 2015 at 01:08:46PM +0200, Gregor Best wrote:
> Hello,
>
> the following is a patch that adds an option called `update_unbound' to
> dhclient.conf. With this option enabled, dhclient will call
>
> unbound-control forwards
>
> instead of rewriting /etc/resolv.conf.
>
> My
On 19/07/2015 16:13, Ted Unangst wrote:
> I could maybe be convinced. However, fopen is the C standard stdio function.
> One reason you may be using stdio is because you want portability, so
> adding nonportable extensions to it seems counter productive.
Understood, I'll leave it as it's not req
Sevan Janiyan wrote:
>
>
> On 19/07/2015 15:35, Bob Beck wrote:
> > The place to solve this is in whatever is using cat for this purpose.
> > check for the file type before blindly cat'ing.
>
> Understood both your & Ted's explanation regarding cat.
> Just so it's crisp clear, ignoring cat(1), h
On 19/07/2015 15:35, Bob Beck wrote:
> The place to solve this is in whatever is using cat for this purpose.
> check for the file type before blindly cat'ing.
Understood both your & Ted's explanation regarding cat.
Just so it's crisp clear, ignoring cat(1), having such a flag in
fopen(2) is not
The place to solve this is in whatever is using cat for this purpose.
check for the file type before blindly cat'ing.
this solution is like soaking your clothing with antiseptic every
morning because you are prone to stabbing yourself.
On Sun, Jul 19, 2015 at 8:26 AM, Ted Unangst wrote:
> Sevan
Sevan Janiyan wrote:
> The feature was actually added to ensure whatever cat was meant to be
> reading from was indeed a plain file and not another which could block a
> process.
> "Use cat -f to avoid denial of service attacks by people who make
> .rhosts files fifos."
> http://mail-index.netbsd.o
On 18/07/2015 07:40, Philip Guenther wrote:
> You have in mind a place where this would be used? Where are there
> bugs that this would resolve?
Hi Philip,
I originally thought it was meant to be a performance thing in busy
environments but that's because I'd misinterpreted things due to
O_NONB
Hello,
the following is a patch that adds an option called `update_unbound' to
dhclient.conf. With this option enabled, dhclient will call
unbound-control forwards
instead of rewriting /etc/resolv.conf.
My usage scenario is that I'm running unbound on my laptop as a local
resolver. /
40 matches
Mail list logo
