The documentation for HAST assumes that the disks being used are of
identical size. In the real world, this rarely happens. How are disks of
different sizes handled? In my case, on drive is about 1TB and one is
about 500GB.
Is it possible to run HAST on a partition? All the examles show it
Ah -- I didn't implement the fix I had in that bugzilla correctly -- em and
igb devices will use the same function instead of using two different ones
even though it seems em devices generally require the interface restart yet
igb devices do not.
The other issue is that I still don't know which
On 11/6/2020 5:32 PM, Eric Joyner wrote:
> Could you reply to that issue with what you've found?
>
> Though, as far as I can recall, igb(4) devices are not supposed to do
> the iflib reset talked about in the bug, so I wouldn't expect to see a
> link flap on those.
>
Hi Eric,
I have added my
Just updated CURRENT to r367415 and loading linux kernel module(s) fail with
# kldload linux
link_elf_obj: symbol sdt_provider_linuxulator undefined
linker_load_file: /boot/kernel/linux_common.ko - unsupported file type
KLD linux.ko: depends on linux_common - not available or version mismatch
On Fri, Nov 06, 2020 at 09:59:06AM +0100, O. Hartmann wrote:
> Just updated CURRENT to r367415 and loading linux kernel module(s) fail with
>
> # kldload linux
>
> link_elf_obj: symbol sdt_provider_linuxulator undefined
> linker_load_file: /boot/kernel/linux_common.ko - unsupported file type
>
On Fri, Nov 06, 2020 at 08:35:41AM -0800, John Kennedy wrote:
> I had this crop up this morning r367410, while yesterdays build against
> r367379 seemed fine. I think this is an issue because of r367395:
>
> linux(4): Deduplicate unimpl/dummy syscall handlers
>
> If I tracked it down
On Fri, Nov 06, 2020 at 08:35:41AM -0800, John Kennedy wrote:
> Trying a run against r367420 with the LIN_SDT_PROVIDER_DECLARE() commented
> out.
Not the solution.
___
freebsd-current@freebsd.org mailing list
I had this crop up this morning r367410, while yesterdays build against
r367379 seemed fine. I think this is an issue because of r367395:
linux(4): Deduplicate unimpl/dummy syscall handlers
If I tracked it down correctly, the LIN_SDT_PROVIDER_DECLARE(LINUX_DTRACE)
in
On 11/6/2020 2:17 PM, mike tancsa wrote:
> On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
>> Hello Ian,
>>
>> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
>>
>>> I noticed that my VLAN interfaces stopped working after a recent build.
>>> tcpdump showed traffic leaving leaving and entering the
Having tried an upgrade from r365296 to r367410 I ran into a problem.
If a system panics during boot, then it does not automatically reboot.
It prints:
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the
Hello,
I updated both host and poudriere jail from r367172 to r367418. But
after that `poudriere bulk` fails as following.
--
yasu@rolling-vm-freebsd1[1014]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT
I think I have an idea how to keep this. In the meantime you can just
comment it out.
On 11/6/20, Mateusz Guzik wrote:
> On 11/6/20, Andriy Gapon wrote:
>> On 06/11/2020 22:58, Mateusz Guzik wrote:
>>> Note the underlying primitive was recently replaced.
>>>
>>> One immediate thing to check
Could you reply to that issue with what you've found?
Though, as far as I can recall, igb(4) devices are not supposed to do
the iflib reset talked about in the bug, so I wouldn't expect to see a link
flap on those.
- Eric
On Fri, Nov 6, 2020 at 12:48 PM mike tancsa wrote:
> On 11/6/2020 2:17
On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> Hello Ian,
>
> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
>
>> I noticed that my VLAN interfaces stopped working after a recent build.
>> tcpdump showed traffic leaving leaving and entering the interface but no
>> host on the network actually
The subject panic happens for me with r367410 when mounting root filesystem.
The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook.
I have a picture of the screen with a little bit more details, I'll share it
later.
--
Andriy Gapon
On 06/11/2020 22:58, Mateusz Guzik wrote:
> Note the underlying primitive was recently replaced.
>
> One immediate thing to check would be exact state of the lock.
> READ_HELD checks for reading only, fails if you have this
> write-locked, which is a plausible explanation if you are coming in
>
From: Yasuhiro KIMURA
Subject: Fails to load linprocfs
Date: Sat, 07 Nov 2020 05:11:20 +0900 (JST)
> I updated both host and poudriere jail from r367172 to r367418. But
> after that `poudriere bulk` fails as following.
>
(snip)
>
> What's wrong?
Two people told me following bug report by
Note the underlying primitive was recently replaced.
One immediate thing to check would be exact state of the lock.
READ_HELD checks for reading only, fails if you have this
write-locked, which is a plausible explanation if you are coming in
from less likely codepath.
iow what's the backtrace
On 11/6/20, Andriy Gapon wrote:
> On 06/11/2020 22:58, Mateusz Guzik wrote:
>> Note the underlying primitive was recently replaced.
>>
>> One immediate thing to check would be exact state of the lock.
>> READ_HELD checks for reading only, fails if you have this
>> write-locked, which is a
19 matches
Mail list logo
