Re: boot loader blank screen

[Jakob Alvermark]

On 1/14/21 4:49 AM, monochrome wrote:
I should add my experience to this since its different and haven't 
seen anyone else mention it.
I see the new boot loader, it's not blank, but its large text, and 
it's very SLOW.
I can see each char drawn, and then when it gets to the bottom and has 
to redraw all the lines to scroll up for new lines, it loads so slowly 
it's like watching an 8086 on a 300 baud modem, or slower! Takes like 
an extra 30 seconds to get through all the loaded modules, then back 
to normal speed boot with the same large font.


added these lines and everything is back to normal with new appearance 
and small font like before, and at normal speed.

hw.vga.textmode="0"
vbe_max_resolution=1280x800

also removed the old lines for the amdgpu efi problem with no effect 
so I assume those are no longer necessary and why I'm seeing this change?

#hw.syscons.disable=1
#kern.vty=vt
#hw.vga.textmode=1

am using X and everything seems fine for now

system:
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current



On 1/5/21 8:54 PM, David Wolfskill wrote:

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:

...
the 58661b3ba9eb should hopefully fix the loader text mode issue, 
it would be cool if you can verify:)


thanks,
toomas


I think, I got it fixed (at least idwer did confirm for his system, 
thanks). If you can test this patch: 
http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
 
it would be really nice.


thanks,
toomas


I tested with each of the following "stanzas' in /boot/loader.conf,
using vt (vs. syscons) in each case (though that breaks video reset
on resume after suspend):

# hw.vga.textmode="0"
vbe_max_resolution=1280x800

This works, and provides a graphical console (depth 32).


hw.vga.textmode="0"
# vbe_max_resolution=1280x800

This also works, and provides a low-resolution (and depth 16)
graphical console (800x320 or something similar, IIRC).


# hw.vga.textmode="0"
# vbe_max_resolution=1280x800

(That is, not specifying anything for hw.vga.textmode or
vbe_max_resolution.)

This boots OK, but I see no kernel probe messages or single- to
multi-user mode messages.  I can use (e.g.) Ctl+Alt+F2 to switch to
vty1, see a "login: " prompt, and that (also) works.  (This is the
initial symptom I had reported.)


hw.vga.textmode="1"
# vbe_max_resolution=1280x800

This works -- boots OK, and I see kernel probe () messages; this is a
text console (mostly blue text; some white, against a dark background.
It's a medium-light blue, so it's easy enough to read (unlike a navy
blue, for example).


FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 
main-c255601-g9fd96b416c45-dirty: Tue Jan  5 17:24:45 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY 
amd64



+1 on the slowness.

I like the graphics mode, it's very pretty.

But slow. It seems to depend a lot on the screen resolution. On my small 
laptop, 1366x768, it's fairly OK. On the 1080p laptop it is very much 
slower, it takes about 35 seconds longer compared to the old loader.


Booting on a 4K monitor, well, I didn't time it...


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: How does /usr/bin/uname work in plain english?

[bob prohaska]

On Wed, Jan 13, 2021 at 10:15:32PM -0700, Warner Losh wrote:
> > > __FreeBSD_version is defined in sys/param.h. For -U, uname prints that
> > > value. For -K, it asks the kernel for this value to print.
> > >
> > > MMmmnnn where MM is the major version, mm is minor, and nnn is
> > incremental
> > > when the APIs change, approximately weekly.
> > >

Sounds like the numbers are manually set by humans...
I imagined something much more automated.

> 
> He has a newer kernel than userland... however that came to be...
> 
Yes, a new kernel was compiled to fix the "won't boot with HDMI connected"
problem on Raspberry Pi.

Thanks for explaining!

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: How does /usr/bin/uname work in plain english?

[Warner Losh]

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

> On 14/01/2021 04:46, Warner Losh wrote:
>
> > On Wed, Jan 13, 2021, 8:22 PM bob prohaska  wrote:
> >
> >> … uname -KU reports
> >> 1300135 1300134
> >> …
> > __FreeBSD_version is defined in sys/param.h. For -U, uname prints that
> > value. For -K, it asks the kernel for this value to print.
> >
> > MMmmnnn where MM is the major version, mm is minor, and nnn is
> incremental
> > when the APIs change, approximately weekly.
> >
> > Warner
>
>
> Thanks.
>
>  From the example above – with the inferior number – should I guess that
> Bob has not (yet) performed 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

___
> 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: How does /usr/bin/uname work in plain english?

[Graham Perrin]

On 14/01/2021 04:46, Warner Losh wrote:


On Wed, Jan 13, 2021, 8:22 PM bob prohaska  wrote:


… uname -KU reports
1300135 1300134
…

__FreeBSD_version is defined in sys/param.h. For -U, uname prints that
value. For -K, it asks the kernel for this value to print.

MMmmnnn where MM is the major version, mm is minor, and nnn is incremental
when the APIs change, approximately weekly.

Warner



Thanks.

From the example above – with the inferior number – should I guess that 
Bob has not (yet) performed the installworld part of a FreeBSD-CURRENT 
system update routine?


(Am I confused?)

___
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: How does /usr/bin/uname work in plain english?

[Warner Losh]

On Wed, Jan 13, 2021, 8:22 PM bob prohaska  wrote:

> Since the switch to git I've been wondering how /usr/bin/uname works.
> The man page is thin on details and uname.c is far too subtle.
>
> For example, on my test box uname -a reports
> FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #7
> main-c255937-g818390ce0ca5: Wed Jan 13 16:42:12 PST 2021
>  b...@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM
> arm64
> which seems to replay git nomeclature.
>
> However, uname -KU reports
> 1300135 1300134
> which is admirably readable, even for me.
>
> Is there a natural language description detailing  how
> uname -KU outputs are computed, and roughly what they mean?
> I've noticed that different sources sometimes produce the
> same values, so the level of detail is less, but might suffice
> for initial reports to the mailing lists.
>

__FreeBSD_version is defined in sys/param.h. For -U, uname prints that
value. For -K, it asks the kernel for this value to print.

MMmmnnn where MM is the major version, mm is minor, and nnn is incremental
when the APIs change, approximately weekly.

Warner

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"
>
___
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

[monochrome]

I should add my experience to this since its different and haven't seen 
anyone else mention it.
I see the new boot loader, it's not blank, but its large text, and it's 
very SLOW.
I can see each char drawn, and then when it gets to the bottom and has 
to redraw all the lines to scroll up for new lines, it loads so slowly 
it's like watching an 8086 on a 300 baud modem, or slower! Takes like an 
extra 30 seconds to get through all the loaded modules, then back to 
normal speed boot with the same large font.


added these lines and everything is back to normal with new appearance 
and small font like before, and at normal speed.

hw.vga.textmode="0"
vbe_max_resolution=1280x800

also removed the old lines for the amdgpu efi problem with no effect so 
I assume those are no longer necessary and why I'm seeing this change?

#hw.syscons.disable=1
#kern.vty=vt
#hw.vga.textmode=1

am using X and everything seems fine for now

system:
AMD Ryzen 5 2400G, using integrated vega GPU
ASRock B450M Pro4
13-current



On 1/5/21 8:54 PM, David Wolfskill wrote:

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:

...

the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be 
cool if you can verify:)

thanks,
toomas


I think, I got it fixed (at least idwer did confirm for his system, thanks). If you 
can test this patch: 
http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
 it 
would be really nice.

thanks,
toomas


I tested with each of the following "stanzas' in /boot/loader.conf,
using vt (vs. syscons) in each case (though that breaks video reset
on resume after suspend):

# hw.vga.textmode="0"
vbe_max_resolution=1280x800

This works, and provides a graphical console (depth 32).


hw.vga.textmode="0"
# vbe_max_resolution=1280x800

This also works, and provides a low-resolution (and depth 16)
graphical console (800x320 or something similar, IIRC).


# hw.vga.textmode="0"
# vbe_max_resolution=1280x800

(That is, not specifying anything for hw.vga.textmode or
vbe_max_resolution.)

This boots OK, but I see no kernel probe messages or single- to
multi-user mode messages.  I can use (e.g.) Ctl+Alt+F2 to switch to
vty1, see a "login: " prompt, and that (also) works.  (This is the
initial symptom I had reported.)


hw.vga.textmode="1"
# vbe_max_resolution=1280x800

This works -- boots OK, and I see kernel probe () messages; this is a
text console (mostly blue text; some white, against a dark background.
It's a medium-light blue, so it's easy enough to read (unlike a navy
blue, for example).


FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 
main-c255601-g9fd96b416c45-dirty: Tue Jan  5 17:24:45 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

Peace,
david


___
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"

How does /usr/bin/uname work in plain english?

[bob prohaska]

Since the switch to git I've been wondering how /usr/bin/uname works.
The man page is thin on details and uname.c is far too subtle.

For example, on my test box uname -a reports
FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #7 
main-c255937-g818390ce0ca5: Wed Jan 13 16:42:12 PST 2021 
b...@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM  
arm64
which seems to replay git nomeclature.

However, uname -KU reports
1300135 1300134
which is admirably readable, even for me. 

Is there a natural language description detailing  how 
uname -KU outputs are computed, and roughly what they mean? 
I've noticed that different sources sometimes produce the 
same values, so the level of detail is less, but might suffice
for initial reports to the mailing lists.

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: GPF on boot with devmatch

[Rebecca Cran]

On 10/12/20 12:13 PM, Warner Losh wrote:
> Xin Li's traceback lead to code I just rewrote in current, while this code
> leads to code that's been there for a long time and hasn't been MFC'd. This
> suggests that Xin Li's backtrace isn't to be trusted, or there's two issues
> at play. Both are plausible. I've fixed a minor signedness bug and a
> possible one byte overflow that might have happened in the code I just
> rewrote. But I suspect this is due to something else related to how
> children are handled after we've raced. Maybe there's something special
> about how USB does things, because other buses will create the child early
> and the child list is stable. If USB's discovery code is adding something
> and is racing with devd's walking of the tree, that might explain it...  It
> would be nice if there were some way to provoke the race on a system I
> could get a core from for deeper analysis

I'm seeing this crash on 13-CURRENT main-c255937-g818390ce0ca-dirty when
running GENERIC (but not on GENERIC-NODEBUG).

I've uploaded the core dump etc. to
https://bsdio.com/freebsd/crashes/2021-01-13-devmatch/ .


-- 

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: Current kernel build broken with linuxkpi?

[Robert Huff]

Chris  writes:

>   >>  Further: if I have that set ... does that mean I can 
>   >> remove it from PORTS_MODULES?
>   > 
>   >  I don't know what that is
>   eg;
>   PORTS_MODULES=x11/nvidia-driver-304
>   for the nvidia driver, for example. see src.conf(5).

Actually make.conf(5).


Respectfully,


Robert 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"

Re: Current kernel build broken with linuxkpi?

[Chris]

On 2021-01-13 13:28, Emmanuel Vadot wrote:

On Wed, 13 Jan 2021 16:19:09 -0500
Robert Huff  wrote:



Emmanuel Vadot  writes:

>That's one of the problems of having external kmods.
>drm-current-kmod have the option by default to install it's
>   sources in /usr/local/sys/ and when doing a make buildkernel
>   those sources are getting built too.

That would be the SOURCE option?


 Yes


Further: if I have that set ... does that mean I can remove it
from PORTS_MODULES?


 I don't know what that is

eg;
PORTS_MODULES=x11/nvidia-driver-304
for the nvidia driver, for example. see src.conf(5).



(And I assume a note about this will appear in UPDATING?)


 A note about what ?

 Cheers,



Respectfully,


Robert Huff


___
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: Current kernel build broken with linuxkpi?

[Emmanuel Vadot]

On Wed, 13 Jan 2021 16:19:09 -0500
Robert Huff  wrote:

> 
> Emmanuel Vadot  writes:
> 
> > That's one of the problems of having external kmods.
> > drm-current-kmod have the option by default to install it's
> >   sources in /usr/local/sys/ and when doing a make buildkernel
> >   those sources are getting built too.
> 
>   That would be the SOURCE option?

 Yes

>   Further: if I have that set ... does that mean I can remove it
> from PORTS_MODULES?

 I don't know what that is

>   (And I assume a note about this will appear in UPDATING?)

 A note about what ?

 Cheers,

> 
>   Respectfully,
> 
> 
>   Robert Huff
>   
> 
> ___
> 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"


-- 
Emmanuel Vadot  
___
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]

Emmanuel Vadot  writes:

>   That's one of the problems of having external kmods.
>   drm-current-kmod have the option by default to install it's
>   sources in /usr/local/sys/ and when doing a make buildkernel
>   those sources are getting built too.

That would be the SOURCE option?
Further: if I have that set ... does that mean I can remove it
from PORTS_MODULES?
(And I assume a note about this will appear in UPDATING?)


Respectfully,


Robert Huff


___
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: iichid touchpad stopped working

[Vladimir Kondratyev]

On 13.01.2021 23:29, Jakob Alvermark wrote:
> On 1/13/21 5:56 PM, Vladimir Kondratyev wrote:
>> On 13.01.2021 18:54, Jakob Alvermark wrote:
>>> Hi,
>>>
>>>
>>> After updating -current on my Acer laptop the touchpad stopped working.
>>>
>>> The device is detected fine:
>>>
>>> iichid0:  at addr 0x2c irq 67 on
>>> iicbus0
>>>
>>> But there are no events from it.
>>>
>>> Might it have something to do with this:
>>>
>>> commit b1f1b07f6d412cb3ec8588a634836e26396eec70
>>> Author: Vladimir Kondratyev 
>>> Date:   Wed Oct 7 00:50:16 2020 +0300
>>>
>>>  hid: Import iichid - I2C transport backend for HID subsystem
>>>
>>   It is quite possible. You should remove sysutils/iichid after this
>> commit.
> 
> I did. Still no luck.
> 
> Anything I can do to debug?
> 

Add following options to kernel config and rebuild kernel:

options IICHID_DEBUG
options IICHID_SAMPLING

Than add hw.iichid.debug=5 to /boot/loader.conf, than reboot and send me
a boot log.
___
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?

[Emmanuel Vadot]

On Wed, 13 Jan 2021 14:52:32 -0500
Robert Huff  wrote:

> 
> Hans Petter Selasky :
> 
> >   You need to update that DRM port you are using before the issue
> >   will be fixed.
> 
>   I'm confused.
>   I have drm-current-kmod listed in PORTS_MODULES; things on that
> list get built _after_ buildkernel (installkernel??) for reasons I
> thought I understood.
>   You are telling me I need to update this _before_ buildkernel?
> 
> 
>   Perplexedly,
> 
> 
>   Robert Huff
> 

 That's one of the problems of having external kmods.
 drm-current-kmod have the option by default to install it's sources
in /usr/local/sys/ and when doing a make buildkernel those sources are
getting built too.
 One problem is that when, like with the latest update to linuxkpi that
I did, we introduce changes that breaks external kmods, you first need
to upgrade your ports/package (not your ports tree) so the new sources
are updated too and then do a make buildkernel.
 That really sucks but still helps a bit when there isn't conflicted
changes in the source tree but you still need to rebuild your kernel
module.

-- 
Emmanuel Vadot  
___
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: iichid touchpad stopped working

[Jakob Alvermark]

On 1/13/21 6:52 PM, Mario Lobo wrote:

On Wed, Jan 13, 2021 at 1:57 PM Vladimir Kondratyev 
wrote:


On 13.01.2021 18:54, Jakob Alvermark wrote:

Hi,


After updating -current on my Acer laptop the touchpad stopped working.

The device is detected fine:

iichid0:  at addr 0x2c irq 67 on
iicbus0

But there are no events from it.

Might it have something to do with this:

commit b1f1b07f6d412cb3ec8588a634836e26396eec70
Author: Vladimir Kondratyev 
Date:   Wed Oct 7 00:50:16 2020 +0300

 hid: Import iichid - I2C transport backend for HID subsystem


  It is quite possible. You should remove sysutils/iichid after this commit.
___
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"


Try:

kern.evdev.rcpt_mask=3

in /etc/sysctl.conf and see if it helps.


No, it doesn't help...


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: iichid touchpad stopped working

[Jakob Alvermark]

On 1/13/21 5:56 PM, Vladimir Kondratyev wrote:

On 13.01.2021 18:54, Jakob Alvermark wrote:

Hi,


After updating -current on my Acer laptop the touchpad stopped working.

The device is detected fine:

iichid0:  at addr 0x2c irq 67 on
iicbus0

But there are no events from it.

Might it have something to do with this:

commit b1f1b07f6d412cb3ec8588a634836e26396eec70
Author: Vladimir Kondratyev 
Date:   Wed Oct 7 00:50:16 2020 +0300

     hid: Import iichid - I2C transport backend for HID subsystem


  It is quite possible. You should remove sysutils/iichid after this commit.


I did. Still no luck.

Anything I can do to debug?


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: Current kernel build broken with linuxkpi?

[David Wolfskill]

On Wed, Jan 13, 2021 at 02:52:32PM -0500, Robert Huff wrote:
> 
> Hans Petter Selasky :
> 
> >   You need to update that DRM port you are using before the issue
> >   will be fixed.
> 
>   I'm confused.
>   I have drm-current-kmod listed in PORTS_MODULES; things on that
> list get built _after_ buildkernel (installkernel??) for reasons I
> thought I understood.
>   You are telling me I need to update this _before_ buildkernel?
> 
> 
>   Perplexedly,
> 

He telling you to update the port itself -- e.g.,
/usr/ports/graphics/drm-kmod, as the port was recently updated:


r561457 | manu | 2021-01-13 03:22:25 -0800 (Wed, 13 Jan 2021) | 6 lines

graphics/drm-{current,devel}-kmod: Update to latest source

This fix a compilation problem with a pre 1300135 source tree.

Reported by:Filippo Moretti 


So you need to update the "ports files" to get that update, then rebuild
the port (in concert with rebuilding the kernel, as you are doing).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Current kernel build broken with linuxkpi?

[Robert Huff]

Hans Petter Selasky :

>   You need to update that DRM port you are using before the issue
>   will be fixed.

I'm confused.
I have drm-current-kmod listed in PORTS_MODULES; things on that
list get built _after_ buildkernel (installkernel??) for reasons I
thought I understood.
You are telling me I need to update this _before_ buildkernel?


Perplexedly,


Robert 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"

USB flash drive sometimes inexplicably read-only

[Graham Perrin]

On 12/01/2021 09:45, Johan Hendriks wrote:

> Re: zpool can not create a pool after using gdisk to prepare the device


On 12/01/2021 07:50, Graham Perrin wrote:

I used gdisk(8) with a USB flash drive to:

1. zap (destroy) GPT data structures
2. blank out the MBR
3. (below) write a new GPT with a FreeBSD ZFS (A504) partition at 
/dev/da1p1




root@mowa219-gjp4-8570p:~ # gdisk /dev/da1
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-7827358, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-7827358, default = 7827358) or {+-}size{KMGTP}:
Current type is A503 (FreeBSD UFS)
Hex code or GUID (L to show codes, Enter = A503): A504
Changed type of partition to 'FreeBSD ZFS'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE 
EXISTING

PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/da1.
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.
root@mowa219-gjp4-8570p:~ #



I exported the pool that used the device at /dev/da0 (preparing for a 
disruptive test), removed both devices then reconnected the USB flash 
drive.


zpool can not create a pool, the file system is reportedly read-only. 
Please, why is this?




root@mowa219-gjp4-8570p:~ # tail -n 0 -f /var/log/messages
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: ugen0.6: DataTraveler G2> at usbus0 (disconnected)
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: umass0: at uhub1, port 3, 
addr 14 (disconnected)
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: da0 at umass-sim0 bus 0 
scbus6 target 0 lun 0
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: da0: DataTraveler G2 1.00>  s/n 001D0F0CAABFF97115A00A15 detached
Jan 12 06:44:44 mowa219-gjp4-8570p kernel: (da0:umass-sim0:0:0:0): 
Periph destroyed

Jan 12 06:44:44 mowa219-gjp4-8570p kernel: umass0: detached
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: ugen0.6: DataTraveler G2> at usbus0

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0 on uhub1
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0: DataTraveler G2, class 0/0, rev 2.00/1.00, addr 15> on usbus0
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0:  SCSI over 
Bulk-Only; quirks = 0xc100
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: umass0:6:0: Attached to 
scbus6
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0 at umass-sim0 bus 0 
scbus6 target 0 lun 0
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: DataTraveler G2 1.00> Removable Direct Access SCSI-2 device
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: Serial Number 
001D0F0CAABFF97115A00A15

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: 40.000MB/s transfers
Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: 3821MB (7827392 512 
byte sectors)

Jan 12 06:44:48 mowa219-gjp4-8570p kernel: da0: quirks=0x2
^C
root@mowa219-gjp4-8570p:~ # lsblk da0
DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT
da0  1:247 3.7G GPT - -
   -:-   1.0M - - -
  da0p1  1:248 3.7G freebsd-zfs gpt/efiboot0 
root@mowa219-gjp4-8570p:~ # zpool create -m /media/sorry sorry 
/dev/da0p1

cannot open '/dev/da0p1': Read-only file system
root@mowa219-gjp4-8570p:~ #



It looks like it is mounted or something like that.
So see with mount if it is mounted somewhere.

I alway use gpart to partition disk and i never have problems.
gpart destroy -F /dev/da0
gpart create -s GPT /dev/da0
gpart create -a 1M -t freebsd-zfs -l LABELNAME /dev/da0

Now you can create your pool using zpool create sorry gpt/LABELNAME

This way you create your pool using the GPT labelname that never 
changes, and you can use it everywhere



Thank you.

With the device this evening at da1, it was again reportedly read-only; 
gpart destroy failed.


After disconnecting then reconnecting, gpart destroy succeeded and an 
iso9660 'heritage' was observed.


I'm now stress-testing the writeable space; 





root@mowa219-gjp4-8570p:~ # gpart destroy -F /dev/da1
gpart: geom 'da1': Read-only file system
root@mowa219-gjp4-8570p:~ # mount | grep /dev/da
root@mowa219-gjp4-8570p:~ # lsblk da1
DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT
da1  0:162 3.7G GPT - -
   -:-   1.0M - - -
  da1p1  0:163 3.7G freebsd-zfs gpt/FreeBSD 
root@mowa219-gjp4-8570p:~ # gpart show /dev/da1
=> 34  7827325  da1  GPT  (3.7G)
   34 2014   - free -  (1.0M)
 2048  7825311    1  freebsd-zfs  (3.7G)

root@mowa219-gjp4-8570p:~ # gpart destroy -F /dev/da1
da1 destroyed
root@mowa219-gjp4-8570p:~ # lsblk da1
DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT
da1  0:162 3.7G cd9660 iso9660/Kubuntu%2020.04.1%20LTS%20amd64 -

Re: kernel build fails

[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"

Re: boot loader blank screen

[Santiago Martinez]

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"



OpenPGP_signature
Description: OpenPGP digital signature

Re: Current kernel build broken with linuxkpi?

[Santiago Martinez]

Hi HPS! thanks, that solved the issue. sorry dint realize i had to
recompile the drm.

Cheers

Santi


On 1/13/21 2:45 PM, Hans Petter Selasky wrote:
> On 1/13/21 3:42 PM, Hans Petter Selasky wrote:
>> On 1/13/21 3:40 PM, Santiago Martinez wrote:
>>> Thanks Peter,  this is what i got
>>>
>>> root@tucho:/usr/src # git status
>>> On branch main
>>> Your branch is up to date with 'origin/main'.
>>>
>>> am i missing something?
>>
>> portsnap fetch update
>>
>
> You need to update that DRM port you are using before the issue will
> be fixed.
>
> --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"



OpenPGP_signature
Description: OpenPGP digital signature

Re: iichid touchpad stopped working

[Mario Lobo]

On Wed, Jan 13, 2021 at 1:57 PM Vladimir Kondratyev 
wrote:

> On 13.01.2021 18:54, Jakob Alvermark wrote:
> > Hi,
> >
> >
> > After updating -current on my Acer laptop the touchpad stopped working.
> >
> > The device is detected fine:
> >
> > iichid0:  at addr 0x2c irq 67 on
> > iicbus0
> >
> > But there are no events from it.
> >
> > Might it have something to do with this:
> >
> > commit b1f1b07f6d412cb3ec8588a634836e26396eec70
> > Author: Vladimir Kondratyev 
> > Date:   Wed Oct 7 00:50:16 2020 +0300
> >
> > hid: Import iichid - I2C transport backend for HID subsystem
> >
>  It is quite possible. You should remove sysutils/iichid after this commit.
> ___
> 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"
>

Try:

kern.evdev.rcpt_mask=3

in /etc/sysctl.conf and see if it helps.

-- 
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio YET!!]
___
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"

kernel build fails

[Robert Huff]

Hello:
On a system running:

FreeBSD 13.0-CURRENT #0 r365372: Sun Sep  6 10:51:26 EDT 2020  amd64 

with sources updated to last night, "buildworld" succeeds.
"buildkernel", with the appended config file, fails with:

/usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device'
typedef struct device   *device_t;
   ^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from 
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:152:9:
 error: implicit declaration of function 'dev_get_drvdata' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
return dev_get_drvdata(_dev->dev);
   ^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: static 
declaration of 'dev_get_drvdata' follows non-static declaration
dev_get_drvdata(const struct device *dev)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:242:9:
 note: previous implicit declaration is here
return dev_get_drvdata(>dev);
   ^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: static 
declaration of 'dev_set_drvdata' follows non-static declaration
dev_set_drvdata(struct device *dev, void *data)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:248:2:
 note: previous implicit declaration is here
dev_set_drvdata(>dev, data);
^
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from 
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: static 
declaration of 'device_unregister' follows non-static declaration
device_unregister(struct device *dev)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:236:2:
 note: previous implicit declaration is here
device_unregister(>dev);
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:277:27:
 error: initializing 'struct backlight_device *' with an expression of 
incompatible type 'void'
struct backlight_device *bd = to_backlight_device(dev);
 ^
12 errors generated.
*** Error code 1

(Full build log available on request.)
Don't see anything applicable in UPDATING.
This is way above my pay grade.  Help, please.


Respectfully,


Robert Huff


#
# JERUSALEM --  kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: head/sys/amd64/conf/GENERIC  343949 2019-02-10 07:54:46Z cem $

cpu HAMMER
ident   JERUSALEM

makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols
makeoptions WITH_CTF=1  # Run ctfconvert(1) for DTrace support

options SCHED_ULE   # ULE scheduler
options NUMA# Non-Uniform Memory Architecture 
support
options PREEMPTION  # Enable kernel thread preemption
options VIMAGE  # Subsystem virtualization, e.g. VNET
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options IPSEC_SUPPORT   # Allow kldload of ipsec and tcpmd5
options ROUTE_MPATH # Multipath routing support
options TCP_OFFLOAD # TCP offload
options TCP_BLACKBOX# Enhanced TCP event logging
options TCP_HHOOK 

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[Andriy Gapon]

On 2021-01-13 16:13, David Wolfskill wrote:
> On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote:
>> ...
>>> I believe that this is evidence in favor of a "race condition" diagnosis.
>>> (In precisely what, I don't know,)
>>
>> I haven't followed source changes too closely as of recent.
>> It might be a good idea to check for recent imports of ACPICA updates.
>> 
> 
> Most recent of those in head was:
> 
> | commit fbde34778ba0ba31fcae99e992f353d989433dba
> | Merge: a2fe464c81de 960614968e0d
> | Author: Jung-uk Kim 
> | Date:   Fri Nov 13 22:45:26 2020 +
> | 
> | MFV:r367652
> | 
> | Merge ACPICA 20201113.
> | 
> | Notes:
> | svn path=/head/; revision=367654
> 
> and I certainly had not been seeing the symptom at all until I
> mentioned it on 11 January.  (And I have been tracking head daily,
> including the "poweroff" at the end).

Another "wild" idea: some sort of a change related to signal delivery or
checking.

As I understand, the whole kernel shutdown procedure is executed in a
context of a userland process (init? shutdown?).  And I guess that that
process gets a signal at some point during the shutdown.
Now, our implementation of the ACPI mutex is such that it would abort /
fail if msleep(PCATCH) in it returns EINTR.  I was concerned about that
for a long time and I think that it is wrong, but it didn't cause much
problems before.  Also, I should note that that applies not only to
mutexes declared in AML but also to ACPICA's mutexes that protect its
internal states (such as ACPI_MTX_Caches / ACPI_MTX_CACHES which appears
in your output).

So, if that mutex is uncontested then it can be acquired even when a
signal is pending and everything is okay.  But if the mutex happens to
be held by some other thread, then the signal gets checked and the
operation is failed because of EINTR.

This is the only failure mode that I can think of for that mutex.
But again, I have no idea what could have changed recently with respect
to signal delivery / signal checking.
Or perhaps it's something else, something that creates concurrent ACPI
activity that increases likelihood of that mutex being contested.

-- 
Andriy Gapon
___
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: iichid touchpad stopped working

[Vladimir Kondratyev]

On 13.01.2021 18:54, Jakob Alvermark wrote:
> Hi,
> 
> 
> After updating -current on my Acer laptop the touchpad stopped working.
> 
> The device is detected fine:
> 
> iichid0:  at addr 0x2c irq 67 on
> iicbus0
> 
> But there are no events from it.
> 
> Might it have something to do with this:
> 
> commit b1f1b07f6d412cb3ec8588a634836e26396eec70
> Author: Vladimir Kondratyev 
> Date:   Wed Oct 7 00:50:16 2020 +0300
> 
>     hid: Import iichid - I2C transport backend for HID subsystem
> 
 It is quite possible. You should remove sysutils/iichid after this commit.
___
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"

iichid touchpad stopped working

[Jakob Alvermark]

Hi,


After updating -current on my Acer laptop the touchpad stopped working.

The device is detected fine:

iichid0:  at addr 0x2c irq 67 on 
iicbus0


But there are no events from it.

Might it have something to do with this:

commit b1f1b07f6d412cb3ec8588a634836e26396eec70
Author: Vladimir Kondratyev 
Date:   Wed Oct 7 00:50:16 2020 +0300

    hid: Import iichid - I2C transport backend for HID subsystem

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"

snd_hda random crack noise on Realtek ALC257

[Ali Abdallah]

Hello,

I'm running 13-current on my Thinkpad T495 (AMD Ryzen 7 PRO 3700U)
It has the following sound devices:

cat /dev/sndstat 
Installed devices:
pcm0:  (play) default
pcm1:  (play)
pcm2:  (play)
pcm3:  (play/rec)
pcm4:  (play/rec)
No devices installed from userspace.

So far so good, but randomly, while listening to music videos, there is
a random crack noise for about a second coming out of the HDMI monitor
speaker (or the internal laptop speaker when pcm3 is used). It is not
very frequent, but quiet annoying. The noise is not associated
particularly with heavy load, it is random even when I'm running
literally nothing but the music player.

I've played with the vchans settings, snd.latency setting, but nothing
improved the situation. The only thing that solved completely the issue
is assigning a single processor to the media player.

$ cpuset -l 0 mpv --audio-device=oss//dev/dsp0 video_file.mp4

That worked with firefox as well, even under heavy load. I don't have
pulseaudio, but I've tried also sound with pulseaudio and sndio, same
issue.

Any thoughts?

Ali

___
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: jail fib no longer works after net.add_addr_allfibs=0

[qroxana]

‐‐‐ Original Message ‐‐‐
On Monday, January 11, 2021 7:37 PM, Alexander V. Chernikov  
wrote:

> 11.01.2021, 14:59, "qroxana" qrox...@protonmail.com:
>
> > On Mon, 11 Jan 2021 13:25:51 +, Alexander V. Chernikov melif...@ipfw.ru 
> > wrote:
> >
> > > Could you please consider clarifying the end result you want to achieve?
> > >  If you could include some more details of how it was configured earlier, 
> > > it would help as well.
> >
> > Thank you for the quick reply.
> > Let's say there are two jails defined in /etc/jail.conf
> > jail1 {
> > ...
> > ip4.addr = 192.168.1.101;
> > exec.fib = 1;
> > ...
> > }
> > jail2 {
> > ...
> > ip4.addr = 192.168.1.102;
> > exec.fib = 2;
> > ...
> > }
>
> Got it, thank you for the clarification.
>
> > All the traffic in jail1 goes to the default router defined in fib 1,
> > and traffic in jail2 goes to the default router defined in fib 2.
>
> Could you describe interface setup as well?
> In particular, I'm looking into details of setting up # of fibs, interface 
> configuration and default route setup.

Sure, the interface is em0 for both host and jails:

/etc/rc.conf
ipv4_addrs_em0="192.168.1.100/24"

static_routes="jail1 jail2"
route_jail1="default 192.168.1.10 -fib 1"
route_jail2="default 192.168.1.20 -fib 2"

/etc/jail.conf
jail1 {
...
interface = em0;
ip4.addr = 192.168.1.101;
exec.fib = 1;
...
}

jail2 {
...
interface = em0;
ip4.addr = 192.168.1.102;
exec.fib = 2;
...
}

I noticed net.add_addr_allfibs defaults to 0 after the
commit 2d39824195933c173bbfc9b31773070202d2e30e
svn path=/head/; revision=367491

I also noted that net.add_addr_allfibs=1 needs to be added into
/etc/sysctl.conf so it can be set before running /etc/rc.d/netif.

# setfib -F 2 route add default 192.168.1.20
route: writing to routing socket: Network is unreachable
add net default: gateway 192.168.1.20 fib 2: Network is unreachable

# sysctl net.add_addr_allfibs=1
net.add_addr_allfibs: 0 -> 1

# setfib -F 2 route add default 192.168.1.20
route: writing to routing socket: Network is unreachable
add net default: gateway 192.168.1.20 fib 2: Network is unreachable

# /etc/rc.d/netif restart
# setfib -F 2 route add default 192.168.1.20
add net default: gateway 192.168.1.20 fib 2

I'm just wondering what's the best practice for using jails
with fib when net.add_addr_allfibs=0?

Thanks.
___
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"

Fresh openssh before 13.0 release

[cglogic]

Hi there,

Any chance to see fresh openssh in upcoming 13.0 release?

Thanks.
___
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: Livelock on recent current

[Marco]

On 2020-09-12 01:24, Kevin Oberman wrote:


I'm happy to see that I am not crazy!

This is mostly anecdotal. The freezes have occurred regularly, without
question, but the details are not statistically verified. This is based 
on
my perceptions. The only things I am really sure of is that the system 
is
unusable on head and runs well on 12.1-Release. This system has a 
rather

new Intel GPU, the Comet Lake, and is only supported on head with
drm-devel-kmod, so moving back to 12.1 is not an option. I am curious 
what

processor is on the T490. I am using the default keyboard layout.
On terminal sessions (vt), when the keyboard is idle. I have had the 
system
run for a couple of hours or longer with no problems. To get bigger 
ports
to build, I usually switch to another vty and keep that one fairly 
busy. It

will freeze when no vty is active, but as long as any is active every
minute or less. I have had freezes in under a minute, but rarely.

Moving on to other possibly related (or not) issues:
When running on X (MATE), it may freeze whether the keyboard is active 
or
not. OTOH, it seems to freeze less often. I've had X lock up mid-word 
but

also run for 15 or more minutes. It eventually does freeze, but I don't
think I've ever gone more than 10 minutes on an idle keyboard without a
freeze without X running.

Switching to a vty and keeping it fairly active still seems to keep the
system alive while X is being used. X is performing very poorly. If the
processors are busy, say by building a port, screen updates are very 
slow,
often pausing for several seconds. Expose events seem to often redraw 
all

windows which is very annoying. Several times I thought the system was
frozen only to suddenly have the screen update and everything be 
normal,

again.


I also have this issue on a Carbon X1 7th Gen (type 20QDCTO1WW) on 
recent -CURRENT snapshots.
I'll try 12-STABLE for now since the system is totally unreliable on 
-CURRENT.

I used the default English kb layout but that didn't resolve anything.

The longest I've been able to just let the live cd run (running top) 
when on AC before my system completely freezes is roughly about 7 hours.
Then again, I've also seen even the live cd from the memstick.img freeze 
after a couple of seconds after login (did a tail -f on 
/var/log/messages and it almost immediately froze right after that).

When it freezes the fan ramps up at a fairly high rpm.
Unless I forcibly power down the high rpm just continues.
Power mode for AC is set to max performance.
Adaptive thermal management scheme for AC also set to max performance.

I've tried booting both using UEFI and also legacy BIOS but in both 
cases I've experienced the same behaviour.


Any specific settings in BIOS to perhaps avoid?

I bought this ThinkPad based on the info listed on 
https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon


I just made the following BIOS changes:

config -> power -> adaptive thermal management > scheme for AC : 
balanced (was : maximize performance)

config -> power -> sleep state : Linux (was: windows 10)
config -> intel AMT > intel AMT control : disabled (was : enabled)
security -> security chip > security chip : Off (was : On) <-- security 
chip type : TPM 2.0


Hasn't improved anything i'm afraid.

User Duffyx on the forums mentioned
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248659

So consider this an official 'me too'

___
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?

[Hans Petter Selasky]

On 1/13/21 3:42 PM, Hans Petter Selasky wrote:

On 1/13/21 3:40 PM, Santiago Martinez wrote:

Thanks Peter,  this is what i got

root@tucho:/usr/src # git status
On branch main
Your branch is up to date with 'origin/main'.

am i missing something?


portsnap fetch update



You need to update that DRM port you are using before the issue will be 
fixed.


--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"

Re: Current kernel build broken with linuxkpi?

[Hans Petter Selasky]

On 1/13/21 3:40 PM, Santiago Martinez wrote:

Thanks Peter,  this is what i got

root@tucho:/usr/src # git status
On branch main
Your branch is up to date with 'origin/main'.

am i missing something?


portsnap fetch update

Maybe?

--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"

Re: Current kernel build broken with linuxkpi?

[Santiago Martinez]

Thanks Peter,  this is what i got

root@tucho:/usr/src # git status
On branch main
Your branch is up to date with 'origin/main'.

am i missing something?

Santi


On 1/13/21 2:34 PM, Hans Petter Selasky wrote:
> On 1/13/21 3:31 PM, Santiago Martinez wrote:
>> Hi there,
>>
>> Just wondering if somebody else is having issues building the kernel
>> (amd64) with the latest current.
>>
>> I have tried with clean,  etc and same issue.
>>
>> Uploaded the make output into "pastebin.com"
>>
>> https://pastebin.com/va5HCYtY
>>
>
> Try to update your ports tree. I believe manu@ just fixed this.
>
> --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"



OpenPGP_signature
Description: OpenPGP digital signature

Re: Current kernel build broken with linuxkpi?

[Hans Petter Selasky]

On 1/13/21 3:31 PM, Santiago Martinez wrote:

Hi there,

Just wondering if somebody else is having issues building the kernel
(amd64) with the latest current.

I have tried with clean,  etc and same issue.

Uploaded the make output into "pastebin.com"

https://pastebin.com/va5HCYtY



Try to update your ports tree. I believe manu@ just fixed this.

--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"

Problem compiling drm-current-kmod

[Filippo Moretti]

Good morning,    my system:[root@STING 
/usr/ports/graphics/drm-current-kmod]# uname -a
FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #16 main-c255860-g2903606b606: 
Tue Jan 12 04:59:16 CET 2021 
root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64

I get the following error while trying to upgrade drm-current-kmod from 
ports:/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
 error: implicit declaration of function 'pci_is_root_bus' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]
    if (pci_is_root_bus(adev->pdev->bus)) {
    ^
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
 note: did you mean 'pci_set_bus'?
/usr/src/sys/dev/pci/pcivar.h:385:1: note: 'pci_set_bus' declared here
PCI_ACCESSOR(bus,   BUS,    uint8_t)
^
/usr/src/sys/dev/pci/pcivar.h:371:2: note: expanded from macro 'PCI_ACCESSOR'
    __BUS_ACCESSOR(pci, var, PCI, ivar, type)
    ^
/usr/src/sys/sys/bus.h:812:22: note: expanded from macro '__BUS_ACCESSOR'
static __inline void varp ## _set_ ## var(device_t dev, type t) \
 ^
:77:1: note: expanded from here
pci_set_bus
^
1 error generated.*** Error code 1

Stop.
make[4]: stopped in 
/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/amd/amdgpu
*** Error code 1
*** Error code 1
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/graphics/drm-current-kmod
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/drm-current-kmod

Filippo
___
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"

Current kernel build broken with linuxkpi?

[Santiago Martinez]

Hi there,

Just wondering if somebody else is having issues building the kernel 
(amd64) with the latest current.

I have tried with clean,  etc and same issue.

Uploaded the make output into "pastebin.com"

https://pastebin.com/va5HCYtY

Thanks

Santi






OpenPGP_signature
Description: OpenPGP digital signature

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote:
> ...
> > I believe that this is evidence in favor of a "race condition" diagnosis.
> > (In precisely what, I don't know,)
> 
> I haven't followed source changes too closely as of recent.
> It might be a good idea to check for recent imports of ACPICA updates.
> 

Most recent of those in head was:

| commit fbde34778ba0ba31fcae99e992f353d989433dba
| Merge: a2fe464c81de 960614968e0d
| Author: Jung-uk Kim 
| Date:   Fri Nov 13 22:45:26 2020 +
| 
| MFV:r367652
| 
| Merge ACPICA 20201113.
| 
| Notes:
| svn path=/head/; revision=367654

and I certainly had not been seeing the symptom at all until I
mentioned it on 11 January.  (And I have been tracking head daily,
including the "poweroff" at the end).

FWIW.

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[Andriy Gapon]

On 2021-01-13 16:03, David Wolfskill wrote:
> On Tue, Jan 12, 2021 at 07:37:28AM -0800, David Wolfskill wrote:
>> On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote:
>>> On 2021-01-11 14:55, David Wolfskill wrote:
 pci3: unknown notify 0x2
 ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex 
 [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434)
>>>
>>> Looks like that was some sort of a race or otherwise transient condition
>>> that lead to the _PTS (prepare-to-sleep) failure.
>>>
 ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) 
 (20201113/psparse-689)
 acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY
>>> 
>>
>> That's certainly plausible -- as I noted a bit earlier today, there was
>> no recurrence  after this morning's main-c255850-g16079c7233be ->
>> main-c255894-g8b1839548750 update.
>>
>> Should I encounter a recurrence, I will plan to get another screenshot,
>> then bring the machine back up and re-try the poweroff (and then report
>> my findings).
>> 
> 
> I had a recurrence this morninig, after the update from:
> 
> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 
> main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300134 1300134
> 
> to:
> 
> FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #121 
> main-c255921-gec2700e01532-dirty: Wed Jan 13 05:06:22 PST 2021 
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1300135 1300135
> 
> 
> New swcreenshot is in https://www.catwhisker.org/~david/FreeBSD/head/c255921;
> the previous one is in https://www.catwhisker.org/~david/FreeBSD/head/c255850.
> 
> They look quite similar to me.
> 
> After grabbing the screenshot, I rebooted again, but the poweroff
> just worked normally on re-try.
> 
> I believe that this is evidence in favor of a "race condition" diagnosis.
> (In precisely what, I don't know,)

I haven't followed source changes too closely as of recent.
It might be a good idea to check for recent imports of ACPICA updates.


-- 
Andriy Gapon
___
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: Laptop ACPI poweroff failed after main-c255826 -> main-c255850

[David Wolfskill]

On Tue, Jan 12, 2021 at 07:37:28AM -0800, David Wolfskill wrote:
> On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote:
> > On 2021-01-11 14:55, David Wolfskill wrote:
> > > pci3: unknown notify 0x2
> > > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex 
> > > [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434)
> > 
> > Looks like that was some sort of a race or otherwise transient condition
> > that lead to the _PTS (prepare-to-sleep) failure.
> > 
> > > ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) 
> > > (20201113/psparse-689)
> > > acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY
> > 
> 
> That's certainly plausible -- as I noted a bit earlier today, there was
> no recurrence  after this morning's main-c255850-g16079c7233be ->
> main-c255894-g8b1839548750 update.
> 
> Should I encounter a recurrence, I will plan to get another screenshot,
> then bring the machine back up and re-try the poweroff (and then report
> my findings).
> 

I had a recurrence this morninig, after the update from:

FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 
main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300134 1300134

to:

FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #121 
main-c255921-gec2700e01532-dirty: Wed Jan 13 05:06:22 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1300135 1300135


New swcreenshot is in https://www.catwhisker.org/~david/FreeBSD/head/c255921;
the previous one is in https://www.catwhisker.org/~david/FreeBSD/head/c255850.

They look quite similar to me.

After grabbing the screenshot, I rebooted again, but the poweroff
just worked normally on re-try.

I believe that this is evidence in favor of a "race condition" diagnosis.
(In precisely what, I don't know,)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"What happened at the Capitol last Wednesday, then, wasn't the first
time Trump's base took him literally. It was the culmination of having
taken him literally the entire duration of his presidency." - Chris Cillizza

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic after updating

[Ian Lepore]

On Wed, 2021-01-13 at 10:37 +0100, Jakob Alvermark wrote:
> On 1/13/21 10:07 AM, Hans Petter Selasky wrote:
> > > 
> > > Yes! That works! Thank you!
> > > 
> > 
> > See:
> > 
> > 
https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f
> >  
> > 
> 
> 
> Nice! Thanks again!
> 
> 
> Jakob
> 

Indeed, thank you for taking care of this, my $job has me way too busy
these days.

-- Ian


___
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 compiling drm-current-kmod

[Emmanuel Vadot]

On Wed, 13 Jan 2021 11:45:31 +0100
Emmanuel Vadot  wrote:

> On Wed, 13 Jan 2021 10:32:01 + (UTC)
> Filippo Moretti  wrote:
> 
> > Good morning,    my system:[root@STING 
> > /usr/ports/graphics/drm-current-kmod]# uname -a
> > FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #16 
> > main-c255860-g2903606b606: Tue Jan 12 04:59:16 CET 2021 
> > root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64
> > 
> > I get the following error while trying to upgrade drm-current-kmod from 
> > ports:/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
> >  error: implicit declaration of function 'pci_is_root_bus' is invalid in 
> > C99 [-Werror,-Wimplicit-function-declaration]
> >     if (pci_is_root_bus(adev->pdev->bus)) {
> >     ^
> > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
> >  note: did you mean 'pci_set_bus'?
> > /usr/src/sys/dev/pci/pcivar.h:385:1: note: 'pci_set_bus' declared here
> > PCI_ACCESSOR(bus,   BUS,    uint8_t)
> > ^
> > /usr/src/sys/dev/pci/pcivar.h:371:2: note: expanded from macro 
> > 'PCI_ACCESSOR'
> >     __BUS_ACCESSOR(pci, var, PCI, ivar, type)
> >     ^
> > /usr/src/sys/sys/bus.h:812:22: note: expanded from macro '__BUS_ACCESSOR'
> > static __inline void varp ## _set_ ## var(device_t dev, type t) \
> >  ^
> > :77:1: note: expanded from here
> > pci_set_bus
> > ^
> > 1 error generated.*** Error code 1
> > 
> > Stop.
> > make[4]: stopped in 
> > /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/amd/amdgpu
> > *** Error code 1
> > *** Error code 1
> > *** Error code 1
> > 
> > Stop.
> > make[1]: stopped in /usr/ports/graphics/drm-current-kmod
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/ports/graphics/drm-current-kmod
> > 
> > Filippo
> > ___
> > 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"
> 
>  Sorry that's my fault.
> https://github.com/freebsd/drm-kmod/blob/master/linuxkpi/gplv2/include/linux/pci.h#L121
> 
>  This if 0 should have been #if __FreeBSD_version < 1300135
>  I'll check if I've missed more and update the port.
>  In the meantime either update your kernel after commit
> 35a39dc5b34962081eeda8dbcf0b99a31585499b or wait that I fix this.

 Fixed in r561457.

-- 
Emmanuel Vadot  
___
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 compiling drm-current-kmod

[Emmanuel Vadot]

On Wed, 13 Jan 2021 10:32:01 + (UTC)
Filippo Moretti  wrote:

> Good morning,    my system:[root@STING 
> /usr/ports/graphics/drm-current-kmod]# uname -a
> FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #16 
> main-c255860-g2903606b606: Tue Jan 12 04:59:16 CET 2021 
> root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING  amd64
> 
> I get the following error while trying to upgrade drm-current-kmod from 
> ports:/usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
>  error: implicit declaration of function 'pci_is_root_bus' is invalid in C99 
> [-Werror,-Wimplicit-function-declaration]
>     if (pci_is_root_bus(adev->pdev->bus)) {
>     ^
> /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4009:6:
>  note: did you mean 'pci_set_bus'?
> /usr/src/sys/dev/pci/pcivar.h:385:1: note: 'pci_set_bus' declared here
> PCI_ACCESSOR(bus,   BUS,    uint8_t)
> ^
> /usr/src/sys/dev/pci/pcivar.h:371:2: note: expanded from macro 'PCI_ACCESSOR'
>     __BUS_ACCESSOR(pci, var, PCI, ivar, type)
>     ^
> /usr/src/sys/sys/bus.h:812:22: note: expanded from macro '__BUS_ACCESSOR'
> static __inline void varp ## _set_ ## var(device_t dev, type t) \
>  ^
> :77:1: note: expanded from here
> pci_set_bus
> ^
> 1 error generated.*** Error code 1
> 
> Stop.
> make[4]: stopped in 
> /usr/ports/graphics/drm-current-kmod/work/drm-kmod-drm_v5.4.62_6/amd/amdgpu
> *** Error code 1
> *** Error code 1
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/graphics/drm-current-kmod
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/graphics/drm-current-kmod
> 
> Filippo
> ___
> 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"

 Sorry that's my fault.
https://github.com/freebsd/drm-kmod/blob/master/linuxkpi/gplv2/include/linux/pci.h#L121

 This if 0 should have been #if __FreeBSD_version < 1300135
 I'll check if I've missed more and update the port.
 In the meantime either update your kernel after commit
35a39dc5b34962081eeda8dbcf0b99a31585499b or wait that I fix this.

-- 
Emmanuel Vadot 
___
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: Panic after updating

[Jakob Alvermark]

On 1/13/21 10:07 AM, Hans Petter Selasky wrote:


Yes! That works! Thank you!



See:

https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f 




Nice! Thanks again!


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: Panic after updating

[Hans Petter Selasky]

Yes! That works! Thank you!



See:

https://cgit.freebsd.org/src/commit/?id=bafb682656724d06045fa494efb83a4312036f1f

--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"