Hi,
I am archiving some old disks and while trying to umount [-f] them I am
getting errors and I basically cannot get rid of the mount anymore
without rebooting. This is on a HEAD from mid-end-August (around
r351518M).
Given there is a lot of work going on at the moment to deal with
Hi!
On 2019-10-24 01:32, Clay Daniels Jr. wrote:
Niclas, my last working install of 13.0 Current was r353072 of Oct 4th. The
next week's r353427 of Oct 11th did not work and I reverted to r353072 for
a week. Then r353709 of Oct 18th did not work, and when I tried to revert
back to r353072 it
On Thu, 2019-10-24 at 17:04 +0300, Andriy Gapon wrote:
> For a lack of a more specific mailing list (or my not being aware of it),
> asking
> here.
>
> gpioiic, a very simple driver, has this code:
> ===
> static void
>
On 24/10/2019 18:38, Ian Lepore wrote:
> On Thu, 2019-10-24 at 17:04 +0300, Andriy Gapon wrote:
>> For a lack of a more specific mailing list (or my not being aware of it),
>> asking
>> here.
>>
>> gpioiic, a very simple driver, has this code:
>>
The removal of these KPIs yields:
link_elf_obj: symbol if_multiaddr_array undefined
linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type
imb
___
freebsd-current@freebsd.org mailing list
On Thu, 2019-10-24 at 19:01 +0300, Andriy Gapon wrote:
> Also, if we universally implement GPIO_PIN_PRESET we still need to answer the
> question. Because some consumer might still try to change an input, either by
> mistake or for some reason, and we need a rule on how to handle that.
Well,
For a lack of a more specific mailing list (or my not being aware of it), asking
here.
gpioiic, a very simple driver, has this code:
===
static void
gpioiic_setsda(device_t dev, int val)
{
struct gpioiic_softc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241399
tested r353887 and r354013, freebsd and linux bhyve guests
lldb -c /bhyve.core /usr/sbin/bhyve
(lldb) target create "/usr/sbin/bhyve" --core "/bhyve.core"
Core file '/bhyve.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name =
> On 24. Oct 2019, at 7:56 PM, Gleb Smirnoff wrote:
>
> On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote:
> M> The removal of these KPIs yields:
> M>
> M> link_elf_obj: symbol if_multiaddr_array undefined
> M> linker_load_file: /boot/modules/if_em_updated.ko - unsupported file
I discovered a similar kernel panic.
To reproduce, just run CURRENT in bhyve with e1000 network backend.
I think the problem is that the debugnet_any_ifnet_update () function calls
iflib_debugnet_init () when the private driver data is not yet fully
initialized.
sys/net/iflib.c:
The last known good update of CURRENT on a Fujitsu Primergy RX2530-M5 (only one
of two sockets equipted, 64 GB RAM) was October, 17th, 2019 before 15 o'clock,
I suppose that was r353680 that time. Today's update to r353881 resulted in an
immediate crash when the network (igb0-igb3, two built-in
> From: "Bjoern A. Zeeb"
> To: "FreeBSD Current"
> Subject: fsync: giving up on dirty, umount -f fails
> Date: Thu, 24 Oct 2019 07:58:39 +
>
> Hi,
>
> I am archiving some old disks and while trying to umount [-f] them I am
> getting errors and I basically cannot get rid of the mount
On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote:
M> The removal of these KPIs yields:
M>
M> link_elf_obj: symbol if_multiaddr_array undefined
M> linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type
What's the reason to keep these outside of the tree drivers?
On 10/22/19 8:42 PM, Alexey Dokuchaev wrote:
> On Tue, Oct 22, 2019 at 04:34:53PM -0700, John Baldwin wrote:
>> On 10/18/19 10:05 AM, Alexey Dokuchaev wrote:
>>> hi there,
>>>
>>> i've made my -CURRENT world and installed, but "make delete-old" tells
>>> me it cannot remove some directories:
>>>
On 10/24/19 1:56 PM, Gleb Smirnoff wrote:
> On Thu, Oct 24, 2019 at 11:12:10AM -0400, Michael Butler wrote:
> M> The removal of these KPIs yields:
> M>
> M> link_elf_obj: symbol if_multiaddr_array undefined
> M> linker_load_file: /boot/modules/if_em_updated.ko - unsupported file type
>
> What's
On Thu, Oct 24, 2019 at 12:57 PM Ian Lepore wrote:
> On Thu, 2019-10-24 at 12:46 -0600, Alan Somers wrote:
> > I count 5 thread pool implementations in contrib:
> > * cddl/compat/opensolaris/misc/thread_pool.c
> > * contrib/apr-util/misc/apr_thread_pool.c
> > *
I count 5 thread pool implementations in contrib:
* cddl/compat/opensolaris/misc/thread_pool.c
* contrib/apr-util/misc/apr_thread_pool.c
* contrib/llvm/lib/Support/ThreadPool.cpp
* contrib/openmp/runtime/src/kmp_tasking.cpp
* contrib/ofed/opensm/complib/cl_threadpool.c
However, I can't find any
On Thu, 2019-10-24 at 12:46 -0600, Alan Somers wrote:
> I count 5 thread pool implementations in contrib:
> * cddl/compat/opensolaris/misc/thread_pool.c
> * contrib/apr-util/misc/apr_thread_pool.c
> * contrib/llvm/lib/Support/ThreadPool.cpp
> * contrib/openmp/runtime/src/kmp_tasking.cpp
> *
18 matches
Mail list logo
