Re: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1

2021-03-20 Thread Fred via freebsd-stable 

On 3/20/21 10:26 AM, Kevin Oberman wrote:

On Sat, Mar 20, 2021 at 8:35 AM Fred via freebsd-stable <
freebsd-stable@freebsd.org> wrote:


On 3/19/21 7:59 PM, Mathias Picker wrote:


Fred Hall via freebsd-stable  writes:


I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run
FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via
freebsd-update. In both cases the boot process locks up on the line
"hwpstate_intel0:  on cpu0"
If running freebsd-update, a work around is to add
hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under
the Eighth Generation (2020) in
https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon
I was quite surprised to find the lack of support for hwpstate_intel
in 13 when it apparently worked under 11 and 12. Does anyone know the
status of hwpstate_intel on ThinkPads?


I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and
hwpstate_intel works fine, never had a problem.

mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15
dev.hwpstate_intel.7.%parent: cpu7
dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location:
dev.hwpstate_intel.7.%driver: hwpstate_intel
dev.hwpstate_intel.7.%desc: Intel Speed Shift
dev.hwpstate_intel.6.epp: 15
dev.hwpstate_intel.6.%parent: cpu6
dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location:
dev.hwpstate_intel.6.%driver: hwpstate_intel
dev.hwpstate_intel.6.%desc: Intel Speed Shift
[snip]

The gen3 is using
sudo dmesg|grep -i c
CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU)
[snip, snip]

mathiasp:~% uname -a
FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2
stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021
root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64


Cheers,

Mathias


Thanks for the feed back. Good to know most people won't encounter the
problem. Perhaps it is a bios issue specific to the model. I did update
to the latest bios version but that made no difference.

I have chosen to rollback to 12.2 as it works perfectly for me.




Cheers, Fred



There are two long tickets about this. Take a look at tickets 248659
 and 253288
. This problem
appeared in 13-current in Jan 2020 and I first saw it on my new Lenovo L15
that summer. It appears specific to Lenovo laptops. It appears that similar
issues have been seen with Linux.


Thank for the links to the bug reports, it would appear to be the same 
issue. I tested my wife's X1 Carbon Gen 3 and it worked fine. Perhaps a 
bios bug with the processor in my 4th gen.


CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (2808.11-MHz K8-class CPU)

In the 24 hours I tested 13.0, I also had some X windows failures while 
waking up from suspend which never happens with 12.2. Oh well, no worries.



--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"




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

Re: kldload zfs spins the system after upgrading from 12.2 to 13-BETA

2021-03-20 Thread Andriy Gapon 
On 20/03/2021 05:01, Yoshihiro Ota wrote:
> On Tue, 9 Mar 2021 11:24:53 +0200
> Andriy Gapon  wrote:
> 
>> On 08/03/2021 05:24, Yoshihiro Ota wrote:
>>> On Sun, 7 Mar 2021 00:09:33 +0200
>>> Andriy Gapon  wrote:
>>>
 On 06/03/2021 20:09, Yoshihiro Ota wrote:
> Hi all,
>
> I'm upgrading fron 12.2-RELEASE to 13-BETA/RC one by one.
>
> After upgrading one in VMWare, 'zfs mount -a' hangs the system.
> I don't have boottime zfs mount on nor don't have zfsroot.
> I just simply ran install world/kernel and mergemaster.

 Please use procstat -kk to capture a kernel stack trace of the hung 
 process.
>>>
>>> Actually, spining was 'kldload zfs'.
>>> Console doesn't response but ping and sshd sessions still work.
>>> procstat output is below.
>>> In addition, this doesn't happen to systems that I've been following 
>>> 13-CURRENT
>>> but rather happen only wiht a system upgraded from 12.2-RELEASE to 13-RC.
>>>
>>>
>>> # procstat -kk 1049
>>>   PIDTID COMMTDNAME  KSTACK 
>>>   
>>>  1049 100215 kldload -   spa_init+0xc6 
>>> zfs_kmod_init+0x1a
>>> zfs_modevent+0x34 module_register_init+0x8c linker_load_module+0xaab 
>>> kern_kldload+0xc1
>>> sys_kldload+0x50 syscall+0x17d g_ctx+0xe280bf29 
>>>
>>
>> If you could use kgdb to find out what source code line spa_init+0xc6
>> corresponds to that may help to see what's going on.
>>
> 
> It look me a while to get kgdb working properly.
> At last, I got the output.
> It looks it is spining on a mutex.
> 
> I have few other machines run the same kernel but they can load zfs.ko.
> It is only vmware VM that spins with 'kldload zfs'.
> 
> vmware# kgdb101 /usr/usr/lib/debug/boot/kernel/zfs.ko.debug
> GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD]
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "i386-portbld-freebsd13.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "helpType "apropos word" to search for commands related to 
> "word"...
> Reading symbols from zfs.ko.debug...
> (kgdb) info line *spa_init+0xc6
> Line 2345 of "/usr/src/sys/contrib/openzfs/module/zfs/spa_misc.c"
>starts at address 0x2b0461 
>and ends at 0x2b0467 .
> (kgdb) 
> 
> void
> spa_init(spa_mode_t mode)
> {
> mutex_init(_namespace_lock, NULL, MUTEX_DEFAULT, NULL);
> mutex_init(_spare_lock, NULL, MUTEX_DEFAULT, NULL); // <- line 
> 2345
> 

It would highly unusual (and unexplainable) for a thread to get stuck here.
Are you sure that your source tree matches the binary?
Can you disassemble the function to check instructions at and near 0xc6 offset?


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

Re: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1

2021-03-20 Thread Kevin Oberman 
On Sat, Mar 20, 2021 at 8:35 AM Fred via freebsd-stable <
freebsd-stable@freebsd.org> wrote:

> On 3/19/21 7:59 PM, Mathias Picker wrote:
> >
> > Fred Hall via freebsd-stable  writes:
> >
> >> I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run
> >> FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via
> >> freebsd-update. In both cases the boot process locks up on the line
> >> "hwpstate_intel0:  on cpu0"
> >> If running freebsd-update, a work around is to add
> >> hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under
> >> the Eighth Generation (2020) in
> >> https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon
> >> I was quite surprised to find the lack of support for hwpstate_intel
> >> in 13 when it apparently worked under 11 and 12. Does anyone know the
> >> status of hwpstate_intel on ThinkPads?
> >
> > I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and
> > hwpstate_intel works fine, never had a problem.
> >
> > mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15
> > dev.hwpstate_intel.7.%parent: cpu7
> > dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location:
> > dev.hwpstate_intel.7.%driver: hwpstate_intel
> > dev.hwpstate_intel.7.%desc: Intel Speed Shift
> > dev.hwpstate_intel.6.epp: 15
> > dev.hwpstate_intel.6.%parent: cpu6
> > dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location:
> > dev.hwpstate_intel.6.%driver: hwpstate_intel
> > dev.hwpstate_intel.6.%desc: Intel Speed Shift
> > [snip]
> >
> > The gen3 is using
> > sudo dmesg|grep -i cpu
> > CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU)
> > [snip, snip]
> >
> > mathiasp:~% uname -a
> > FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2
> > stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021
> > root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> >
> >
> > Cheers,
> >
> > Mathias
>
> Thanks for the feed back. Good to know most people won't encounter the
> problem. Perhaps it is a bios issue specific to the model. I did update
> to the latest bios version but that made no difference.
>
> I have chosen to rollback to 12.2 as it works perfectly for me.
>
> >
> >> Cheers, Fred
>
There are two long tickets about this. Take a look at tickets 248659
 and 253288
. This problem
appeared in 13-current in Jan 2020 and I first saw it on my new Lenovo L15
that summer. It appears specific to Lenovo laptops. It appears that similar
issues have been seen with Linux.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD 13.0-RC3 Now Available

2021-03-20 Thread Glen Barber 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third RC build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-RC3 amd64 GENERIC
o 13.0-RC3 i386 GENERIC
o 13.0-RC3 powerpc GENERIC
o 13.0-RC3 powerpc64 GENERIC64
o 13.0-RC3 powerpc64le GENERIC64LE
o 13.0-RC3 powerpcspe MPC85XXSPE
o 13.0-RC3 armv6 RPI-B
o 13.0-RC3 armv7 GENERICSD
o 13.0-RC3 aarch64 GENERIC
o 13.0-RC3 aarch64 RPI
o 13.0-RC3 aarch64 PINE64
o 13.0-RC3 aarch64 PINE64-LTS
o 13.0-RC3 aarch64 PINEBOOK
o 13.0-RC3 aarch64 ROCK64
o 13.0-RC3 aarch64 ROCKPRO64
o 13.0-RC3 riscv64 GENERIC
o 13.0-RC3 riscv64 GENERICSD

Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-RC2 includes:

o A virtual memory list locking fix has been addressed.

o A fix for systems running under VirtualBox has been addressed.

o A fix in the service(8) utility has been addressed.

o The if_wg(4) pseudo driver has been removed.

o A fix to TSO for TCP/IPV6 has been addressed in the vtnet(4) driver.

o Several other miscellaneous fixes have been addressed.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC3/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0ad55ef28f5927282
  eu-north-1 region: ami-0fde22c6026e95a57
  ap-south-1 region: ami-06fd5c64b54c3e005
  eu-west-3 region: ami-093ba1f2661abd0be
  eu-west-2 region: ami-0803205f015f5ec14
  eu-south-1 region: ami-03e90955c75a8c809
  eu-west-1 region: ami-0d9313767b0b818fd
  ap-northeast-3 region: ami-0f25c989c843d8dbb
  ap-northeast-2 region: ami-0f27bdd4fd819bb6c
  me-south-1 region: ami-032ee25ad2976ad49
  ap-northeast-1 region: ami-0fb5829e3ff1f1b15
  sa-east-1 region: ami-0f66abb1219e00a5c
  ca-central-1 region: ami-062381d2a77db4a3d
  ap-east-1 region: ami-0d21456c4a5bd1384
  ap-southeast-1 region: ami-0519190624816cc77
  ap-southeast-2 region: ami-0805e040cf3167547
  eu-central-1 region: ami-0abb1093896437395
  us-east-1 region: ami-02f65312a05a1abfd
  us-east-2 region: ami-023106328f1d2d3c7
  us-west-1 region: ami-00802b96b8eec8b49
  us-west-2 region: ami-090a96d68eed457a1

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-04e1b958484d79c53
  eu-north-1 region: ami-09784ab80e6a9812f
  ap-south-1 region: ami-0641ef56dae855387
  eu-west-3 region: ami-0cc83c013292eb9ee
  eu-west-2 region: ami-033fa6488ab12698b
  eu-south-1 region: ami-02fe3008ea2757fed
  eu-west-1 region: ami-06fdd3bce845d8c96
  ap-northeast-3 region: ami-0afb61493a8eb593d
  ap-northeast-2 region: ami-0a81e284ff987ba61
  me-south-1 region:

Re: Rasberry Pi 4 has no USB

2021-03-20 Thread Carl Johnson 
Carl Johnson  writes:

> Emmanuel Vadot  writes:
>
>> On Sun, 28 Feb 2021 09:26:23 -0800
>> Carl Johnson  wrote:
>>
>>> I have an 8GB RPi 4B that I am trying out, but it has no USB response at
>>> all. That means that I can't use a keyboard or mouse, but I can use a
>>> serial console and ethernet.  I can plug any USB device into any port,
>>> but there is nothing logged in /var/messages.  Running usbconfig as root
>>> just reports 'No device match or lack of permissions'.  Running
>>> 'dmesg | grep -i usb' reports only the following lines:
>>> 
>>>   usb_nop_xceiv0:  on ofwbus0
>>>   bcm_xhci0:  irq 81 at 
>>> device 0.0 on pci2
>>>   usb_needs_explore_all: no devclass
>>>   
>>> Running 'pciconf -lv' shows there is a VL805 USB controller present.  I
>>> tested this with Linux and everything worked properly.  This is a new
>>> computer that I bought only a couple of weeks ago.  Does anybody have
>>> any ideas on what this might be, or what I could do to try to figure it
>>> out?
>>> 
>>> Thanks in advance for any ideas.
>>> -- 
>>> Carl Johnsonca...@peak.org
>>
>>  Hello,
>>
>>  This is known, see
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252971#c25
>>
>>  I wanted to wait that a tag was created on the rpi-firmware github
>> repo but it seems that they don't want to so I'll update the port next
>> week so RC1 will have the updated firmware.
>>
>>  Cheers,
>
> Thank you very much for that!  I will test that as soon as it comes
> out.

Just for the record, RC3 now works properly.  Thanks to everyone for
getting this fix in before the release.

-- 
Carl Johnsonca...@peak.org

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

Re: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1

2021-03-20 Thread Fred via freebsd-stable 

On 3/19/21 7:59 PM, Mathias Picker wrote:


Fred Hall via freebsd-stable  writes:

I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run 
FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via 
freebsd-update. In both cases the boot process locks up on the line 
"hwpstate_intel0:  on cpu0"
If running freebsd-update, a work around is to add 
hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under 
the Eighth Generation (2020) in 
https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon
I was quite surprised to find the lack of support for hwpstate_intel 
in 13 when it apparently worked under 11 and 12. Does anyone know the 
status of hwpstate_intel on ThinkPads?


I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and 
hwpstate_intel works fine, never had a problem.


mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15
dev.hwpstate_intel.7.%parent: cpu7
dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location: 
dev.hwpstate_intel.7.%driver: hwpstate_intel

dev.hwpstate_intel.7.%desc: Intel Speed Shift
dev.hwpstate_intel.6.epp: 15
dev.hwpstate_intel.6.%parent: cpu6
dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location: 
dev.hwpstate_intel.6.%driver: hwpstate_intel

dev.hwpstate_intel.6.%desc: Intel Speed Shift
[snip]

The gen3 is using
sudo dmesg|grep -i cpu
CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU)
[snip, snip]

mathiasp:~% uname -a
FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2 
stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021 
root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64



Cheers,

Mathias


Thanks for the feed back. Good to know most people won't encounter the 
problem. Perhaps it is a bios issue specific to the model. I did update 
to the latest bios version but that made no difference.


I have chosen to rollback to 12.2 as it works perfectly for me.




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






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

Request: Mount zfs encrypted datasets at boot? Re: FreeBSD 13.0-RC2 Now Available

2021-03-20 Thread Ruben van Staveren via freebsd-stable 
Hi,

> On 13 Mar 2021, at 1:11, Glen Barber  wrote:
> 
> The second RC build of the 13.0-RELEASE release cycle is now available.


Might it be interesting to change the

zfs mount -a / zfs unmount -a

in /etc/rc.d/zfs to

zfs mount -al / zfs unmount -au

so that filesystems using the openzfs encryption feature can be automatically 
mounted?

given their keylocation is not “prompt" and accessible during boot.

This would make it possible for me to move away from my current dual pool boot 
setup, in where the boot pool has the geli keys for my geli encrypted system 
pool, which seems to be incompatible with beadm/bectl handling of things these 
days…
The single geli encrypted pool does not work for me as it doesn’t allow for 
unattended reboots.

Best regards,
Ruben



signature.asc
Description: Message signed with OpenPGP