> Do you know how other OSes handle this case? What kind of changes
> would be required to handle this in OpenBSD? At which layer? USB
> currently follows the same logic, so it could be solved there as
> well with the same stone.
No USB is much much harder. If I understand correctly the
There are two types of SD cards. Ones that go away, and ones that don't.
> You could borrow bits of mpath(4), specifically the devid parts that
> are used to identify whether a device is the same or not. However,
> devids rely on a device providing unique identifiers, and we know that
> this
On 12/11/18(Mon) 23:36, Ben Pye wrote:
> On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote:
> > On 11/11/18(Sun) 13:10, Ben Pye wrote:
> > > Hey all,
> > >
> > > In my quest for better OpenBSD support on my Chromebook 13 I have found
> > > that sdmmc(4)'s current strategy for
> On 13 Nov 2018, at 9:36 am, Ben Pye wrote:
>
> On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote:
>> On 11/11/18(Sun) 13:10, Ben Pye wrote:
>>> Hey all,
>>>
>>> In my quest for better OpenBSD support on my Chromebook 13 I have found
>>> that sdmmc(4)'s current strategy for
On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote:
> On 11/11/18(Sun) 13:10, Ben Pye wrote:
> > Hey all,
> >
> > In my quest for better OpenBSD support on my Chromebook 13 I have found
> > that sdmmc(4)'s current strategy for suspend/resume only really works
> > for removable
On Mon, Nov 12, 2018 at 06:50:27PM -0200, Martin Pieuchot wrote:
> On 09/11/18(Fri) 16:25, Ben Pye wrote:
> > On Thu, Nov 08, 2018 at 11:25:37PM -0600, joshua stein wrote:
> > > On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote:
> > > > Hi all,
> > > >
> > > > This patch adds a
Stuart Henderson(s...@spacehopper.org) on 2018.11.11 21:55:19 +:
> On 2018/11/11 22:45, Job Snijders wrote:
> > Shouldnt we already bomb out at the following?
> >
> > cannot bind to 0.0.0.0:179: Address already in use
> > cannot bind to [::]:179: Address already in use
> >
> > In any regard,
On 09/11/18(Fri) 16:25, Ben Pye wrote:
> On Thu, Nov 08, 2018 at 11:25:37PM -0600, joshua stein wrote:
> > On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote:
> > > Hi all,
> > >
> > > This patch adds a new touchpad driver, elan(4), which supports older non
> > > PTP I2C
On 11/11/18(Sun) 13:10, Ben Pye wrote:
> Hey all,
>
> In my quest for better OpenBSD support on my Chromebook 13 I have found
> that sdmmc(4)'s current strategy for suspend/resume only really works
> for removable storage. Upon a suspend it marks the device as dying, and
> upon resume will detach
On Mon, 2018-11-12 at 15:01 -0500, Brian Callahan wrote:
>
> On 11/12/18 1:13 PM, John Long wrote:
> > On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote:
> > > On 11/12/18 11:20 AM, John Long wrote:
> > > > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
> > > > > On Sun, Nov 11,
On 11/12/18 1:13 PM, John Long wrote:
On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote:
On 11/12/18 11:20 AM, John Long wrote:
On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote:
Hi tech --
Reminded by the recent
> Even if this looks more like an ad-hoc solution, I find it easier to
> grasp and review than the trap-based diff. Works fine here and seems to
> solve miod's problem.
>
> ok jca@
I concur. I'm slightly annoyed by the asymmetry between c_fc_depth++ vs
c_fc_reset(), but I think we've had enough
On Mon, Nov 12 2018, Martijn van Duren wrote:
> On 10/29/18 12:01 PM, Anton Lindqvist wrote:
>> On Mon, Oct 29, 2018 at 09:55:38AM +0100, Martijn van Duren wrote:
>>> On 10/28/18 8:13 PM, Anton Lindqvist wrote:
Hi,
Bug reported by miod@, how to reproduce:
$ command -v r
On Mon, 2018-11-12 at 12:38 -0500, Brian Callahan wrote:
>
> On 11/12/18 11:20 AM, John Long wrote:
> > On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
> > > On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote:
> > > > Hi tech --
> > > >
> > > > Reminded by the recent email
On 11/12/18 11:20 AM, John Long wrote:
On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote:
Hi tech --
Reminded by the recent email to tech@ about calendar.christian, I
took a look at syncing calendar.judaic.
This diff
Hello there,
Sorry I haven't access to my server until today.
Please find the requested output here : https://pastebin.com/V5ayBfyS
(dmesg, ifconfig bnxt, vmstat -zi)
I modified mac addresses on my different outputs, the mac addresses are
normal.
Cheers
Luthing
--
Sent from:
On Mon, 2018-11-12 at 06:57 +, Jason McIntyre wrote:
> On Sun, Nov 11, 2018 at 07:36:55PM -0500, Brian Callahan wrote:
> > Hi tech --
> >
> > Reminded by the recent email to tech@ about calendar.christian, I
> > took a look at syncing calendar.judaic.
> >
> > This diff does the following:
>
On Mon, Nov 12, 2018 at 04:51:38PM +0100, Martijn van Duren wrote:
> ping
>
> On 11/1/18 11:57 AM, Martijn van Duren wrote:
> > When experimenting with snmpd I found the following crash:
> > $ snmpctl snmp walk 127.0.0.1 oid 1
> > Segmentation fault (core dumped)
> >
>
ping
On 11/1/18 11:57 AM, Martijn van Duren wrote:
> When experimenting with snmpd I found the following crash:
> $ snmpctl snmp walk 127.0.0.1 oid 1
> Segmentation fault (core dumped)
>
> The problem is a NULL dereference in ber_free_elements:
> #0 0x0370920d24ca
On 10/29/18 12:01 PM, Anton Lindqvist wrote:
> On Mon, Oct 29, 2018 at 09:55:38AM +0100, Martijn van Duren wrote:
>> On 10/28/18 8:13 PM, Anton Lindqvist wrote:
>>> Hi,
>>> Bug reported by miod@, how to reproduce:
>>>
>>> $ command -v r
>>> alias r='fc -s'
>>> $ sleep 5
>>> $ r sleep
>>>
On 11.11.18 18:43, Claudio Jeker wrote:
> On Sun, Nov 11, 2018 at 06:32:53PM +0100, Bruno Flueckiger wrote:
> > On 11.11.18 15:29, Florian Obser wrote:
> > > On Sun, Nov 11, 2018 at 01:46:06PM +0100, Sebastian Benoit wrote:
> > > > Bruno Flueckiger(inform...@gmx.net) on 2018.11.11 10:31:34 +0100:
On Mon, Nov 12, 2018 at 08:12:37AM +0100, Claudio Jeker wrote:
> On Sun, Nov 11, 2018 at 04:40:54PM -0700, Theo de Raadt wrote:
> > Makes sense to me, I suppose.
> >
> > Isn't another approach to swap the opening of the sockets?
> >
> > Or why does failure to control :179 sockets not stop
22 matches
Mail list logo
