(Please send the followup to freebsd-testing@ and note Reply-To is set.)
FreeBSD CI Weekly Report 2019-08-25
===
Here is a summary of the FreeBSD Continuous Integration results for the period
from 2019-08-19 to 2019-08-25.
During this period, we have:
* 2262 buil
On 2019-08-27 19:41, Michael Butler wrote:
> On 2019-08-27 19:15, Niclas Zeising wrote:
>> On 2019-08-28 00:38, Alexander Motin wrote:
>>> Hi.
>>>
>>> On 27.08.2019 18:03, Niclas Zeising wrote:
I have an issue where the ses driver no longer attaches. Last known
good version was r351188,
On 2019-08-27 19:15, Niclas Zeising wrote:
> On 2019-08-28 00:38, Alexander Motin wrote:
>> Hi.
>>
>> On 27.08.2019 18:03, Niclas Zeising wrote:
>>> I have an issue where the ses driver no longer attaches. Last known
>>> good version was r351188, r351544 is broken. In that interval,
>>> something
I recompiled the kernel with the patch enabled and now we get at 'service
bluetooth start ubt0 (ubt1...)' :
*/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device
ubt0root@freeBSD13:/usr/home/miranda # service bluetooth start
ubt1/etc/rc.d/bluetooth: ERROR: Unable to setup Bluet
On 2019-08-28 00:38, Alexander Motin wrote:
Hi.
On 27.08.2019 18:03, Niclas Zeising wrote:
I have an issue where the ses driver no longer attaches. Last known
good version was r351188, r351544 is broken. In that interval,
something happened. I haven't had time to bisect yet.
I would apprec
Hi.
On 27.08.2019 18:03, Niclas Zeising wrote:
> I have an issue where the ses driver no longer attaches. Last known
> good version was r351188, r351544 is broken. In that interval,
> something happened. I haven't had time to bisect yet.
I would appreciate some details, like dmesg, error messa
Hi!
I have an issue where the ses driver no longer attaches. Last known
good version was r351188, r351544 is broken. In that interval,
something happened. I haven't had time to bisect yet.
Thanks!
Regards
--
Niclas Zeising
___
freebsd-current@freeb
Hi,
I have no tried (but it's in progress) this article:
http://zero-knowledge.org/post/126/
Hope it will help (for me too).
Thanks!
On Tue, Aug 27, 2019 at 11:25 AM O. Hartmann wrote:
> Hello list,
>
> trying to setup a poudriere jail on recent CURRENT and have some severe
> trouble.
>
> We
On 2019-08-24 19:09, Michael Butler wrote:
> On 2019-08-24 14:04, Konstantin Belousov wrote:
>> On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote:
>>> forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure
>>> that's the right fix.
>> More correct way to fix it is to in
On Tue, Aug 27, 2019 at 06:03:46AM -0700, Maksim Yevmenkin wrote:
> > > Hmm... interesting
> > >
> > > I only took a brief look at it. I suppose I can ensure user space address
> > > is wired and then copyout() can be called with mutex held
> >
> > >No, you cannot do this, at least without mak
> > Hmm... interesting
> >
> > I only took a brief look at it. I suppose I can ensure user space address
> > is wired and then copyout() can be called with mutex held
>
> >No, you cannot do this, at least without making the kernel to panic.
> User might unmap the wired mapping at any time stil
Hello list,
trying to setup a poudriere jail on recent CURRENT and have some severe trouble.
We have a single ZFS pool (raidz), call it pool00 and this pool00 conatins a
ZFS dataset pool00/poudriere which we want to exclusively attach to a jail.
pool00/poudriere contains a complete clone of a for
On Tue, 27 Aug 2019 at 9:11, Konstantin Belousov wrote:
On Mon, Aug 26, 2019 at 02:35:25PM -0700, maksim yevmenkin wrote:
>
>
> > On Aug 26, 2019, at 9:14 AM, Warner Losh wrote:
> >
> > Is it from read_connection_list? If so I have a 'patch' that I'm using but
> > haven't committed bec
On Mon, Aug 26, 2019 at 02:35:25PM -0700, maksim yevmenkin wrote:
>
>
> > On Aug 26, 2019, at 9:14 AM, Warner Losh wrote:
> >
> > Is it from read_connection_list? If so I have a 'patch' that I'm using but
> > haven't committed because it's just too gross: drop the lock before the
> > copyout an
14 matches
Mail list logo
