Blank console on recent current

[Steve Kargl]

Is there an estimate on when the blank console on
booting may be fixed?  If the answer is someday,
can whoever is responsible for break console 
output please revert their changes?

There is a much worse problem at the moment on
my laptop where heavy disk IO leads to a 
complete lock-up of the system.  The lock up
sometimes times out after 30 seconds.  Without
a console it is somewhat difficult to boot 
either in single user mode or to boot an 
older kernel.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Rebecca Cran]

On 1/15/21 3:26 AM, Jakob Alvermark wrote:
>
> When rebooting my thinkpad the 'bufdaemon' times out:
>
> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ...
> timed out


I'm glad other people are seeing this: I was about to report it to the list!

I'm running an AMD Threadripper 2990WX. I can trigger it by running a
buildworld/buildkernel and then rebooting.


-- 

Rebecca Cran


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

[Mark Millard]

Warner Losh imp at bsdimp.com wrote on
Sat Jan 16 00:22:51 UTC 2021 :

> On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O. 
> wrote:
> 
> > Running FreeBSD CURRENT on a USB only platform with a customised kernel, I
> > see this
> > message all the time I reboot or log console messages:
> >
> > [...]
> > WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD
> > 13.0.
> >
> > Where does this message come from and what is causing the warning? I tried
> > to identify
> > and eliminate this message, but it seems to be stuck with the USB
> > device/keyboard
> > attached to the system.
> >
> > Any hint?
> >
> 
> to eliminate the message, kbd needs to be rewritten to not use giant.
> 
> It will not be deleted before 13. I'll change the message to 14.

Other examples for the general type of question . . .


For example, various aarch64, armv7, and powerpc*:

WARNING: Device "openfirm" is Giant locked and may be deleted before 
FreeBSD 13.0.


RPi4B and RPi3B:

WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.


powerpc (old PowerMac G4):

WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD 
13.0.

WARNING: Device "consolectl" is Giant locked and may be deleted before 
FreeBSD 13.0.


Note: FreeBSD has boot problems for various powerpc64 and 32-bit
powerpc PowerMacs, so some material is from somewhat older vintages
of 13. (I've not looked at the old PowerMac G3 at all for this.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Invoking -v for clang during buildworld

[bob prohaska]

While playing with -current on armv7 using a raspberry pi 2 v1.1 
an error crops up with recent kernels while building world:

++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [clang.full] Error code 1

make[5]: stopped in /usr/freebsd-src/usr.bin/clang/clang

How does one invoke -v in this situation?

For the record, uname -a reports
FreeBSD www.zefox.com 13.0-CURRENT FreeBSD 13.0-CURRENT #6 
main-c950-gff1a307801: Wed Jan 13 19:02:18 PST 2021 
b...@www.zefox.com:/usr/obj/usr/freebsd-src/arm.armv7/sys/GENERIC-MMCCAM  arm

The present sources are a day or two newer.

Nothing is obviously wrong; swap usage is small, no warnings or errors on the 
console.

In past occurrences, an old kernel (pre-git) worked through the problem.
If a restart of make buildworld doesn't get past the stoppage I'll check again.

Thanks for reading,

bob prohaska


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

[Yasuhiro Kimura]

From: Mark Millard 
Subject: Re: WARNING: Device "kbd" is Giant locked and may be deleted before 
FreeBSD 13.0.
Date: Fri, 15 Jan 2021 16:54:26 -0800

> Other examples for the general type of question . . .
> 
> 
> For example, various aarch64, armv7, and powerpc*:
> 
> WARNING: Device "openfirm" is Giant locked and may be deleted before 
> FreeBSD 13.0.
> 
> 
> RPi4B and RPi3B:
> 
> WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
> 
> 
> powerpc (old PowerMac G4):
> 
> WARNING: Device "agp" is Giant locked and may be deleted before FreeBSD 
> 13.0.
> 
> WARNING: Device "consolectl" is Giant locked and may be deleted before 
> FreeBSD 13.0.
> 
> 
> Note: FreeBSD has boot problems for various powerpc64 and 32-bit
> powerpc PowerMacs, so some material is from somewhat older vintages
> of 13. (I've not looked at the old PowerMac G3 at all for this.)

Following files are the source of this warning messages.

yasu@rolling-vm-freebsd1[1009]% git grep -F D_NEEDGIANT
sys/cam/scsi/scsi_target.c: .d_flags =  D_NEEDGIANT,
sys/contrib/ipfilter/netinet/mlfk_ipl.c:.d_flags =  0,  /* 
D_NEEDGIANT - Should be SMP safe */
sys/dev/adlink/adlink.c:.d_flags =  D_NEEDGIANT,
sys/dev/agp/agp.c:  .d_flags =  D_NEEDGIANT,
sys/dev/amr/amr.c:  .d_flags =  D_NEEDGIANT,
sys/dev/atkbdc/psm.c:   .d_flags =  D_NEEDGIANT,
sys/dev/ce/if_ce.c: .d_flags= D_NEEDGIANT,
sys/dev/fb/fb.c:.d_flags =  D_NEEDGIANT,
sys/dev/fb/fbd.c:   .d_flags =  D_NEEDGIANT,
sys/dev/kbd/kbd.c:  .d_flags =  D_NEEDGIANT,
sys/dev/ofw/openfirmio.c:   .d_flags =  D_NEEDGIANT,
sys/dev/ofw/openpromio.c:   .d_flags =  D_NEEDGIANT,
sys/dev/pbio/pbio.c:.d_flags = D_NEEDGIANT,
sys/dev/speaker/spkr.c: .d_flags =  D_NEEDGIANT,
sys/dev/syscons/syscons.c:  .d_flags = D_NEEDGIANT | D_TRACKCLOSE,
sys/dev/tdfx/tdfx_pci.c:.d_flags =  D_NEEDGIANT,
sys/dev/tpm/tpm.c:  .d_flags =  D_NEEDGIANT,
sys/dev/vkbd/vkbd.c:.d_flags =  D_NEEDGIANT | D_NEEDMINOR,
sys/i386/bios/smapi.c:  .d_flags =  D_NEEDGIANT,
sys/i386/i386/elan-mmcr.c:  .d_flags =  D_NEEDGIANT,
sys/i386/i386/perfmon.c:.d_flags =  D_NEEDGIANT,
sys/isa/vga_isa.c:  .d_flags =  D_NEEDGIANT,
sys/kern/kern_conf.c:   if (devsw->d_flags & D_NEEDGIANT) {
sys/kern/kern_conf.c:   if (devsw->d_flags & D_NEEDGIANT) {
sys/kern/kern_conf.c:   } else if (devsw->d_flags & D_NEEDGIANT)
\
sys/sys/conf.h:#define  D_NEEDGIANT 0x0040  /* driver want Giant */
yasu@rolling-vm-freebsd1[1010]%

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

[Warner Losh]

On Fri, Jan 15, 2021 at 1:03 PM Hartmann, O. 
wrote:

> Running FreeBSD CURRENT on a USB only platform with a customised kernel, I
> see this
> message all the time I reboot or log console messages:
>
> [...]
> WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD
> 13.0.
>
> Where does this message come from and what is causing the warning? I tried
> to identify
> and eliminate this message, but it seems to be stuck with the USB
> device/keyboard
> attached to the system.
>
> Any hint?
>

to eliminate the message, kbd needs to be rewritten to not use giant.

It will not be deleted before 13. I'll change the message to 14.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Mark Millard]

In the interest of documenting some variability . . .

While not readily reproducible, on a ThreadRipper 1950X
that I have access to, a recent reboot had one "system
thread" time out: bufspacedaemon-3 . The rest of the
"system thread" list behaved normally.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problem with drm

[Filippo Moretti]

 
Yes the port is up to date and I did rebuild from ports drm-current-kmod 
gpu-firmware-kmod and drm-kmodFilippo
On Friday, January 15, 2021, 10:29:38 AM GMT+1, Hans Petter Selasky 
 wrote:  
 
 On 1/15/21 10:11 AM, Filippo Moretti wrote:
> After upgrading my custom kernel I get the following error (that did not 
> occur before hid):hidbus0:  on usbhid0
> link_elf_obj: symbol linux_pci_get_class undefined
> Warning: memory type debugfsint leaked memory on destroy (2 allocations, 80 
> bytes leaked).
> linker_load_file: /boot/modules/radeonkms.ko - unsupported file type
> 
> Also the generic kernel was working fine before I upgraded my kernel STING 
> now it no longer works and Xorg start with scfb instead of radeon kms.After 
> completing installworld I always rebuild from ports drm-current-kmod 
> gpu-firmware-kmod drm-kmod.SincerelyFilippo

Is your ports updated to the latest?

Looks like radeonkms was not re-build after upgrading and installing the 
sources.

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot loader blank screen

[sm]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

[Hartmann, O.]

Running FreeBSD CURRENT on a USB only platform with a customised kernel, I see 
this
message all the time I reboot or log console messages:

[...]
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.

Where does this message come from and what is causing the warning? I tried to 
identify
and eliminate this message, but it seems to be stuck with the USB 
device/keyboard
attached to the system.

Any hint?

Many thanks in advance,

oh


pgpKS04T7Chxe.pgp
Description: OpenPGP digital signature

Re: boot loader blank screen

[Johan Hendriks]

On 15/01/2021 14:51, Toomas Soome wrote:

Could you please check latest current now?:)

Thanks,
Toomas


On 13. Jan 2021, at 20:13, Santiago Martinez  wrote:

Hi, +1 on this, i still have issue on a supermicro.

Santi


On 1/8/21 8:11 PM, John Kennedy wrote:

On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote:
  I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font),
31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly
babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> screen.textmode).

  Didn't fix the blank screen, and I thought the hw.vga.textmode workaround
had broken until I read that commit fully (will try it next reboot).

  At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476.

  At main-c255756-g40903394bf48, still no love for my system yet.  FYI,
screen.textmode=0 continued to work around the issue, as expected.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"




I found out my desktop pc that i updated today also has a blank screen.
In my case setting the following helps

screen.textmode=1
vbe_max_resolution=800x600

And thank you for that lovely boot screen and awesome font, very neat!

My release is main-c255921-gec2700e01532: Wed Jan 13 12:32:28 CET 2021

This is on a old intel core 2
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #24 main-c255921-gec2700e01532: Wed Jan 13 12:32:28 
CET 2021

    root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-rc2-0-g43ff75f2c3f)

VT(vbefb): resolution 1280x1024
CPU: Intel(R) Core(TM)2 Duo CPU E6550  @ 2.33GHz (2327.55-MHz 
K8-class CPU)

  Origin="GenuineIntel"  Id=0x6fb  Family=0x6  Model=0xf Stepping=11
Features=0xbfebfbff
Features2=0xe3fd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Yasuhiro Kimura]

From: Yasuhiro Kimura 
Subject: Re: Waiting for bufdaemon
Date: Fri, 15 Jan 2021 20:10:30 +0900 (JST)

> I have been experiencing same problem with my 13-CURRENT amd64
> VirtualBox VM for about a month. The conditions that the problem
> happens are unclear and all what I can say is
> 
> * It happens only after I login in the VM and do something for a
>   while. If I boot the VM and shut it down immediately, it never
>   happens.
> * When the problem happens, one or more unkillable processes seem to
>   be left.

CPU of my host is not AMD but Intel. According to the
/var/run/dmesg.boot of VM, information of CPU is as following.

CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x906ed  Family=0x6  Model=0x9e  Stepping=13
  
Features=0x1783fbff
  
Features2=0x5eda2203
  AMD Features=0x28100800
  AMD Features2=0x121
  Structured Extended 
Features=0x842421
  Structured Extended Features3=0x3400
  IA32_ARCH_CAPS=0x29
  TSC: P-state invariant

Just FYI.

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Rainer Hurling]

Am 15.01.21 um 16:45 schrieb Konstantin Belousov:
> On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:
>> On 15/01/2021 16:02, Konstantin Belousov wrote:
>>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:
 On 15/01/2021 11:26, Jakob Alvermark wrote:
> Hi,
>
>
> When rebooting my thinkpad the 'bufdaemon' times out:
>
> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
> out
>
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
> ... timed out
>
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
> ... timed out
>
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
> ... timed out
>
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
> ... timed out
>
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
> ... timed out
>
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
> ... timed out
>
>
> This started happening recently (within the last week I think).

 Hi,

 I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.

 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
 orphaned
 groups) "seems" ok

 cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
 support), affected by the timeout.

 I haven't tried the intermediate commit yet.

 My intel machine doesn't seem to be affected
>>>
>>> If you revert only 9e680e4005b7, is it fixed ?
>>>
>> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests,
>> I can do more if you want)
> Please show me the output from sysctl
> kern.timecounter
> kern.eventtimer
> and first 100 lines of dmesg from the verbose boot (that contains the CPU
> ident lines).


I also have this timeout issue only on AMD, here Ryzen 3950X:

[...]
Waiting for PIDS: 2905
90 seconds watchdog timeout expired. Shutdown terminated.
Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated
abnormally, going to single user mode
Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15
wg0: link state changed to DOWN
Waiting (max 69 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done
Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop...
timeout
Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop...
timeout
Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop...


You will find the wanted output from sysctl and boot -v in the attachment.

HTH,
Rainer Hurling
#sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) 
dummy(-100)
kern.timecounter.hardware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 3355373301
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 3626460971
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 21196
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1746752087
kern.timecounter.tc.TSC-low.counter: 869144438
kern.timecounter.tc.TSC-low.mask: 4294967295

#sysctl kern.eventtimer
kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPET2(350) i8254(100) 
RTC(0)
kern.eventtimer.et.HPET2.quality: 350
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 350
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 350
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182

Re: Waiting for bufdaemon

[Freddie Cash]

On Fri., Jan. 15, 2021, 9:41 a.m. Juraj Lutter,  wrote:

> > On 15 Jan 2021, at 18:26, Freddie Cash  wrote:
> >
> > /var/run/dmesg.boot includes all output from dmesg for the current boot.
> No
> > need to manually redirect dmesg output to a file or play with buffer
> sizes.
> > :) Just upload that file.
>
> On boot, dmesg is saved to dmesg.boot quite lately and start of the
> circular
> buffer can already be rewritten.
>

Really? Interesting. Haven't run into that (not saying it can't happen). I
always thought it was essentially streamed to that file once / or /var was
mounted.

Now I'll have to read some RC scripts to see. :)

Thanks for the info.

Cheers,
Freddie

Typos due to smartphone keyboard.

>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot loader blank screen

[Toomas Soome]

Could you please check latest current now?:)

Thanks,
Toomas

> On 13. Jan 2021, at 20:13, Santiago Martinez  wrote:
> 
> Hi, +1 on this, i still have issue on a supermicro.
> 
> Santi
> 
>> On 1/8/21 8:11 PM, John Kennedy wrote:
>>> On Wed, Jan 06, 2021 at 02:19:12PM -0800, John Kennedy wrote:
>>>  I saw your commit of 99870c70bac7 (loader: rewrite vidc_install_font),
>>> 31c2bcad7e44 (loader: remove left over call to unsetenv()), and belatedly
>>> babda0952f8355a89b3241d5e8943c7da0fa4f6b (hw.vga.textmode -> 
>>> screen.textmode).
>>> 
>>>  Didn't fix the blank screen, and I thought the hw.vga.textmode workaround
>>> had broken until I read that commit fully (will try it next reboot).
>>> 
>>>  At main-c255633-g3efe9b3e77c3 right now (also past your f1829643c476.
>>  At main-c255756-g40903394bf48, still no love for my system yet.  FYI,
>> screen.textmode=0 continued to work around the issue, as expected.
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Juraj Lutter]

> On 15 Jan 2021, at 18:26, Freddie Cash  wrote:
> 

> 
> /var/run/dmesg.boot includes all output from dmesg for the current boot. No
> need to manually redirect dmesg output to a file or play with buffer sizes.
> :) Just upload that file.


On boot, dmesg is saved to dmesg.boot quite lately and start of the circular
buffer can already be rewritten.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Freddie Cash]

On Fri., Jan. 15, 2021, 8:47 a.m. Mikaël Urankar, 
wrote:

> On 15/01/2021 17:35, Konstantin Belousov wrote:
> > It is clipped at the start, and that was the information which I need.
> > Add something like
> > kern.msgbufsize=1048576
> > to /boot/loader.conf and try again.  I need to see the lines starting
> with
> >
> > CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU)
> >Origin="GenuineIntel"  Id=0x806ea  Family=0x6  Model=0x8e  Stepping=10
> >
> Features=0xbfebfbff > MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > ...
> >
> > (well, this is my w/s, your CPU would be different of course).
> >
> Thanks, I've updated the file on freefall.


/var/run/dmesg.boot includes all output from dmesg for the current boot. No
need to manually redirect dmesg output to a file or play with buffer sizes.
:) Just upload that file.

Cheers,
Freddie

Typos due to smartphone keyboard.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Mikaël Urankar]

On 15/01/2021 17:35, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 05:18:56PM +0100, Mikaël Urankar wrote:

On 15/01/2021 16:45, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:

On 15/01/2021 16:02, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:

On 15/01/2021 11:26, Jakob Alvermark wrote:

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
... timed out


This started happening recently (within the last week I think).


Hi,

I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.

5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned
groups) "seems" ok

cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
support), affected by the timeout.

I haven't tried the intermediate commit yet.

My intel machine doesn't seem to be affected


If you revert only 9e680e4005b7, is it fixed ?


Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests,
I can do more if you want)

Please show me the output from sysctl
kern.timecounter
kern.eventtimer
and first 100 lines of dmesg from the verbose boot (that contains the CPU
ident lines).



I put the /var/run/dmesg.boot file on freefall /home/mikael/dmesg.boot (it
seems to be truncated though, I don't know how to retrieve the full log)

sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
dummy(-100)
kern.timecounter.hardware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 1470549582
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 378058131
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 20425
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1900039387
kern.timecounter.tc.TSC-low.counter: 2386729797
kern.timecounter.tc.TSC-low.mask: 4294967295

sysctl kern.eventtimer
kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPET2(350)
i8254(100) RTC(0)
kern.eventtimer.et.HPET2.quality: 350
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 350
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 350
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.frequency: 50001034
kern.eventtimer.et.LAPIC.flags: 7
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2


It is clipped at the start, and that was the information which I need.
Add something like
kern.msgbufsize=1048576
to /boot/loader.conf and try again.  I need to see the lines starting with

CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU)
   Origin="GenuineIntel"  Id=0x806ea  Family=0x6  Model=0x8e  Stepping=10
   
Features=0xbfebfbff
...

(well, this is my w/s, your CPU would be different of course).


Thanks, I've updated the file on freefall
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Konstantin Belousov]

On Fri, Jan 15, 2021 at 05:18:56PM +0100, Mikaël Urankar wrote:
> On 15/01/2021 16:45, Konstantin Belousov wrote:
> > On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:
> > > On 15/01/2021 16:02, Konstantin Belousov wrote:
> > > > On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:
> > > > > On 15/01/2021 11:26, Jakob Alvermark wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > 
> > > > > > When rebooting my thinkpad the 'bufdaemon' times out:
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... 
> > > > > > timed
> > > > > > out
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to 
> > > > > > stop
> > > > > > ... timed out
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to 
> > > > > > stop
> > > > > > ... timed out
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to 
> > > > > > stop
> > > > > > ... timed out
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to 
> > > > > > stop
> > > > > > ... timed out
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to 
> > > > > > stop
> > > > > > ... timed out
> > > > > > 
> > > > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to 
> > > > > > stop
> > > > > > ... timed out
> > > > > > 
> > > > > > 
> > > > > > This started happening recently (within the last week I think).
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare 
> > > > > metal.
> > > > > 
> > > > > 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
> > > > > orphaned
> > > > > groups) "seems" ok
> > > > > 
> > > > > cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
> > > > > support), affected by the timeout.
> > > > > 
> > > > > I haven't tried the intermediate commit yet.
> > > > > 
> > > > > My intel machine doesn't seem to be affected
> > > > 
> > > > If you revert only 9e680e4005b7, is it fixed ?
> > > > 
> > > Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 
> > > tests,
> > > I can do more if you want)
> > Please show me the output from sysctl
> > kern.timecounter
> > kern.eventtimer
> > and first 100 lines of dmesg from the verbose boot (that contains the CPU
> > ident lines).
> > 
> 
> I put the /var/run/dmesg.boot file on freefall /home/mikael/dmesg.boot (it
> seems to be truncated though, I don't know how to retrieve the full log)
> 
> sysctl kern.timecounter
> kern.timecounter.tsc_shift: 1
> kern.timecounter.smp_tsc_adjust: 0
> kern.timecounter.smp_tsc: 1
> kern.timecounter.invariant_tsc: 1
> kern.timecounter.fast_gettime: 1
> kern.timecounter.tick: 1
> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000)
> dummy(-100)
> kern.timecounter.hardware: TSC-low
> kern.timecounter.alloweddeviation: 5
> kern.timecounter.timehands_count: 2
> kern.timecounter.stepwarnings: 0
> kern.timecounter.tc.ACPI-fast.quality: 900
> kern.timecounter.tc.ACPI-fast.frequency: 3579545
> kern.timecounter.tc.ACPI-fast.counter: 1470549582
> kern.timecounter.tc.ACPI-fast.mask: 4294967295
> kern.timecounter.tc.HPET.quality: 950
> kern.timecounter.tc.HPET.frequency: 14318180
> kern.timecounter.tc.HPET.counter: 378058131
> kern.timecounter.tc.HPET.mask: 4294967295
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.counter: 20425
> kern.timecounter.tc.i8254.mask: 65535
> kern.timecounter.tc.TSC-low.quality: 1000
> kern.timecounter.tc.TSC-low.frequency: 1900039387
> kern.timecounter.tc.TSC-low.counter: 2386729797
> kern.timecounter.tc.TSC-low.mask: 4294967295
> 
> sysctl kern.eventtimer
> kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPET2(350)
> i8254(100) RTC(0)
> kern.eventtimer.et.HPET2.quality: 350
> kern.eventtimer.et.HPET2.frequency: 14318180
> kern.eventtimer.et.HPET2.flags: 3
> kern.eventtimer.et.HPET1.quality: 350
> kern.eventtimer.et.HPET1.frequency: 14318180
> kern.eventtimer.et.HPET1.flags: 3
> kern.eventtimer.et.HPET.quality: 350
> kern.eventtimer.et.HPET.frequency: 14318180
> kern.eventtimer.et.HPET.flags: 3
> kern.eventtimer.et.RTC.quality: 0
> kern.eventtimer.et.RTC.frequency: 32768
> kern.eventtimer.et.RTC.flags: 17
> kern.eventtimer.et.i8254.quality: 100
> kern.eventtimer.et.i8254.frequency: 1193182
> kern.eventtimer.et.i8254.flags: 1
> kern.eventtimer.et.LAPIC.quality: 600
> kern.eventtimer.et.LAPIC.frequency: 50001034
> kern.eventtimer.et.LAPIC.flags: 7
> kern.eventtimer.periodic: 0
> kern.eventtimer.timer: LAPIC
> kern.eventtimer.idletick: 0
> kern.eventtimer.singlemul: 2

It is clipped at the start, and that was the information which I need.
Add something like
kern.msgbufsize=1048576
to /boot/loader.conf and try again.  I need to see the lines starting with

CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class 

Re: Waiting for bufdaemon

[Mikaël Urankar]

On 15/01/2021 16:45, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:

On 15/01/2021 16:02, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:

On 15/01/2021 11:26, Jakob Alvermark wrote:

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
... timed out


This started happening recently (within the last week I think).


Hi,

I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.

5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned
groups) "seems" ok

cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
support), affected by the timeout.

I haven't tried the intermediate commit yet.

My intel machine doesn't seem to be affected


If you revert only 9e680e4005b7, is it fixed ?


Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests,
I can do more if you want)

Please show me the output from sysctl
kern.timecounter
kern.eventtimer
and first 100 lines of dmesg from the verbose boot (that contains the CPU
ident lines).



I put the /var/run/dmesg.boot file on freefall /home/mikael/dmesg.boot 
(it seems to be truncated though, I don't know how to retrieve the full log)


sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) 
dummy(-100)

kern.timecounter.hardware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 1470549582
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 378058131
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 20425
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1900039387
kern.timecounter.tc.TSC-low.counter: 2386729797
kern.timecounter.tc.TSC-low.mask: 4294967295

sysctl kern.eventtimer
kern.eventtimer.choice: LAPIC(600) HPET(350) HPET1(350) HPET2(350) 
i8254(100) RTC(0)

kern.eventtimer.et.HPET2.quality: 350
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 350
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 350
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.frequency: 50001034
kern.eventtimer.et.LAPIC.flags: 7
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Konstantin Belousov]

On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:
> On 15/01/2021 16:02, Konstantin Belousov wrote:
> > On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:
> > > On 15/01/2021 11:26, Jakob Alvermark wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > When rebooting my thinkpad the 'bufdaemon' times out:
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
> > > > out
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
> > > > ... timed out
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
> > > > ... timed out
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
> > > > ... timed out
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
> > > > ... timed out
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
> > > > ... timed out
> > > > 
> > > > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
> > > > ... timed out
> > > > 
> > > > 
> > > > This started happening recently (within the last week I think).
> > > 
> > > Hi,
> > > 
> > > I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.
> > > 
> > > 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
> > > orphaned
> > > groups) "seems" ok
> > > 
> > > cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
> > > support), affected by the timeout.
> > > 
> > > I haven't tried the intermediate commit yet.
> > > 
> > > My intel machine doesn't seem to be affected
> > 
> > If you revert only 9e680e4005b7, is it fixed ?
> > 
> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests,
> I can do more if you want)
Please show me the output from sysctl
kern.timecounter
kern.eventtimer
and first 100 lines of dmesg from the verbose boot (that contains the CPU
ident lines).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Mikaël Urankar]

On 15/01/2021 16:02, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:

On 15/01/2021 11:26, Jakob Alvermark wrote:

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
... timed out


This started happening recently (within the last week I think).


Hi,

I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.

5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned
groups) "seems" ok

cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
support), affected by the timeout.

I haven't tried the intermediate commit yet.

My intel machine doesn't seem to be affected


If you revert only 9e680e4005b7, is it fixed ?

Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 
tests, I can do more if you want)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Jakob Alvermark]

On 1/15/21 3:56 PM, Mikaël Urankar wrote:

On 15/01/2021 11:26, Jakob Alvermark wrote:

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... 
timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop 
... timed out



This started happening recently (within the last week I think).


Hi,

I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.

5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
orphaned groups) "seems" ok


cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP 
support), affected by the timeout.


I haven't tried the intermediate commit yet.

My intel machine doesn't seem to be affected



I observed the same here. It seems to only happen on my AMD laptop.

I have an Intel laptop which seems fine.


Jakob

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Konstantin Belousov]

On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:
> On 15/01/2021 11:26, Jakob Alvermark wrote:
> > Hi,
> > 
> > 
> > When rebooting my thinkpad the 'bufdaemon' times out:
> > 
> > Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
> > out
> > 
> > Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
> > ... timed out
> > 
> > Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
> > ... timed out
> > 
> > Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
> > ... timed out
> > 
> > Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
> > ... timed out
> > 
> > Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
> > ... timed out
> > 
> > Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
> > ... timed out
> > 
> > 
> > This started happening recently (within the last week I think).
> 
> Hi,
> 
> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.
> 
> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of orphaned
> groups) "seems" ok
> 
> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
> support), affected by the timeout.
> 
> I haven't tried the intermediate commit yet.
> 
> My intel machine doesn't seem to be affected

If you revert only 9e680e4005b7, is it fixed ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Mikaël Urankar]

On 15/01/2021 11:26, Jakob Alvermark wrote:

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... 
timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop 
... timed out



This started happening recently (within the last week I think).


Hi,

I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.

5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
orphaned groups) "seems" ok


cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP 
support), affected by the timeout.


I haven't tried the intermediate commit yet.

My intel machine doesn't seem to be affected


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current kernel build broken with linuxkpi?

[Robert Huff]

Yesterday I typod:

>   So, yes as I believe I said buildkernel ran successfully.

Please make that:

So, yes as I believe I said buildworld ran successfully.
[Whack! Whack! Whack!]


Respectfully,


Robert "ENOBRAIN" Huff

-- 
Hello ... my name is SARS-CoV-2.
You are not wearing a mask?
Prepare to die!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Problem with drm

[Filippo Moretti]

After upgrading my custom kernel I get the following error (that did not occur 
before hid):hidbus0:  on usbhid0
link_elf_obj: symbol linux_pci_get_class undefined
Warning: memory type debugfsint leaked memory on destroy (2 allocations, 80 
bytes leaked).
linker_load_file: /boot/modules/radeonkms.ko - unsupported file type

Also the generic kernel was working fine before I upgraded my kernel STING now 
it no longer works and Xorg start with scfb instead of radeon kms.After 
completing installworld I always rebuild from ports drm-current-kmod 
gpu-firmware-kmod drm-kmod.SincerelyFilippo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Santiago Martinez]

Hi, there, im having the same issue here ( AMD Ryzen7). i do not use mrsas but 
in my case even if i try to reboot immediately after a fresh reboot i get the 
timeouts. Regards Santiago
 Original message From: Juraj Lutter  Date: 
15/01/2021  12:17  (GMT+01:00) To: freebsd-current@freebsd.org Subject: Re: 
Waiting for bufdaemon > On 15 Jan 2021, at 12:10, Yasuhiro Kimura 
 wrote:> > From: Jakob Alvermark > 
Subject: Waiting for bufdaemon> Date: Fri, 15 Jan 2021 11:26:47 +0100> >> When 
rebooting my thinkpad the 'bufdaemon' times out:>> >> Waiting (max 60 seconds) 
for system thread 'bufdaemon' to stop>> ... timed out>> >> Waiting (max 60 
seconds) for system thread 'bufspacedaemon-0' to stop>> ... timed out>> >> 
Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop>> ... 
timed out>> >> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to 
stop>> ... timed out>> >> Waiting (max 60 seconds) for system thread 
'bufspacedaemon-3' to stop>> ... timed out>> >> Waiting (max 60 seconds) for 
system thread 'bufspacedaemon-4' to stop>> ... timed out>> >> Waiting (max 60 
seconds) for system thread 'bufspacedaemon-5' to stop>> ... timed out>> >> >> 
This started happening recently (within the last week I think).>> >> >> Any 
ideas?> > I have been experiencing same problem with my 13-CURRENT amd64> 
VirtualBox VM for about a month. The conditions that the problem> happens are 
unclear and all what I can say is> > * It happens only after I login in the VM 
and do something for a>  while. If I boot the VM and shut it down immediately, 
it never>  happens.> * When the problem happens, one or more unkillable 
processes seem to>  be left.I have been fighting with situations like this for 
month or two, opened more PRs about it.My observation was that after putting 
some load on the machine, mysterious mrsas(4)timeouts started to happen, 
processes were unkillable, reboots could not complete in time...For sake of 
bisect, main-c255656-gb500c184b656 is known to work OK for me as of 
now.___freebsd-curr...@freebsd.org 
mailing listhttps://lists.freebsd.org/mailman/listinfo/freebsd-currentTo 
unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Juraj Lutter]

> On 15 Jan 2021, at 12:10, Yasuhiro Kimura  wrote:
> 
> From: Jakob Alvermark 
> Subject: Waiting for bufdaemon
> Date: Fri, 15 Jan 2021 11:26:47 +0100
> 
>> When rebooting my thinkpad the 'bufdaemon' times out:
>> 
>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop
>> ... timed out
>> 
>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
>> ... timed out
>> 
>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
>> ... timed out
>> 
>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
>> ... timed out
>> 
>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
>> ... timed out
>> 
>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
>> ... timed out
>> 
>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
>> ... timed out
>> 
>> 
>> This started happening recently (within the last week I think).
>> 
>> 
>> Any ideas?
> 
> I have been experiencing same problem with my 13-CURRENT amd64
> VirtualBox VM for about a month. The conditions that the problem
> happens are unclear and all what I can say is
> 
> * It happens only after I login in the VM and do something for a
>  while. If I boot the VM and shut it down immediately, it never
>  happens.
> * When the problem happens, one or more unkillable processes seem to
>  be left.


I have been fighting with situations like this for month or two, opened more 
PRs about it.
My observation was that after putting some load on the machine, mysterious 
mrsas(4)
timeouts started to happen, processes were unkillable, reboots could not 
complete in time...

For sake of bisect, main-c255656-gb500c184b656 is known to work OK for me as of 
now.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Jakob Alvermark]

On 1/15/21 11:53 AM, Konstantin Belousov wrote:

On Fri, Jan 15, 2021 at 11:26:47AM +0100, Jakob Alvermark wrote:

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ...
timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ...
timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ...
timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ...
timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ...
timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ...
timed out


This started happening recently (within the last week I think).


Any ideas?

It is bare metal install, right?

Yes, this is a Thinkpad X395 (AMD Ryzen 5 PRO 3500U)

Do you see any mis-handling of time or timeouts while the system operates?
My webcam (using webcamd) seems to be a little flakey, but that's about 
the only thing I have noticed.


Can you bisect it?


I could try, but it will take some time, it seems this only happens when 
system has been running for a while. Rebooting right after a boot does 
not show this behavior.



Jakob

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Yasuhiro Kimura]

From: Jakob Alvermark 
Subject: Waiting for bufdaemon
Date: Fri, 15 Jan 2021 11:26:47 +0100

> When rebooting my thinkpad the 'bufdaemon' times out:
> 
> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop
> ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
> ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
> ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
> ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
> ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
> ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
> ... timed out
> 
> 
> This started happening recently (within the last week I think).
> 
> 
> Any ideas?

I have been experiencing same problem with my 13-CURRENT amd64
VirtualBox VM for about a month. The conditions that the problem
happens are unclear and all what I can say is

* It happens only after I login in the VM and do something for a
  while. If I boot the VM and shut it down immediately, it never
  happens.
* When the problem happens, one or more unkillable processes seem to
  be left.

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Waiting for bufdaemon

[Konstantin Belousov]

On Fri, Jan 15, 2021 at 11:26:47AM +0100, Jakob Alvermark wrote:
> Hi,
> 
> 
> When rebooting my thinkpad the 'bufdaemon' times out:
> 
> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop ...
> timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop ...
> timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop ...
> timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop ...
> timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop ...
> timed out
> 
> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop ...
> timed out
> 
> 
> This started happening recently (within the last week I think).
> 
> 
> Any ideas?

It is bare metal install, right?
Do you see any mis-handling of time or timeouts while the system operates?

Can you bisect it?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Waiting for bufdaemon

[Jakob Alvermark]

Hi,


When rebooting my thinkpad the 'bufdaemon' times out:

Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed out

Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop 
... timed out


Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop 
... timed out



This started happening recently (within the last week I think).


Any ideas?


Thanks,

Jakob

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problem with drm

[Hans Petter Selasky]

On 1/15/21 10:11 AM, Filippo Moretti wrote:

After upgrading my custom kernel I get the following error (that did not occur before 
hid):hidbus0:  on usbhid0
link_elf_obj: symbol linux_pci_get_class undefined
Warning: memory type debugfsint leaked memory on destroy (2 allocations, 80 
bytes leaked).
linker_load_file: /boot/modules/radeonkms.ko - unsupported file type

Also the generic kernel was working fine before I upgraded my kernel STING now 
it no longer works and Xorg start with scfb instead of radeon kms.After 
completing installworld I always rebuild from ports drm-current-kmod 
gpu-firmware-kmod drm-kmod.SincerelyFilippo


Is your ports updated to the latest?

Looks like radeonkms was not re-build after upgrading and installing the 
sources.


--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

buildworld, installworld, world: etymology

[Graham Perrin]

On 14/01/2021 05:15, Warner Losh wrote:

> Re: How does /usr/bin/uname work in plain english?

On Wed, Jan 13, 2021, 10:13 PM Graham Perrin > wrote:



… the installworld part of a FreeBSD-CURRENT
system update routine?

(Am I confused?)


He has a newer kernel than userland... however that came to be...

Warner



Asked a few years ago 
 
but there was not exactly an answer.


Why, instead of 'builduserland' or 'builduserspace', do we have 
'buildworld'?




Was it maybe that the word is shorter?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"