Re: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3

[Toomas Soome via freebsd-stable]

> On 1. Feb 2021, at 05:35, Yasuhiro Kimura  wrote:
> 
> From: Yasuhiro Kimura mailto:y...@utahime.org>>
> Subject: Setting for displaying utf8 characters on all vt consoles results in 
> panic on 14-CURRENT and 13.0-ALPHA3
> Date: Mon, 01 Feb 2021 11:41:35 +0900 (JST)
> 
>> To display utf8 characters on all vt console I did following settings.
>> 
>> 1. Download GNU Unifont BDF file
>>   
>> (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz)
>> 2. gunzip unifont-13.0.05.bdf.gz
>> 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt
>> 4. cp unifont.fnt /usr/share/vt/fonts
>> 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf
>> 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local
>> 7. shutdown -r now
>> 
>> On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on
>> 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic.
>> 
>> Screen shot of 14-CURRENT.
>> https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png
>> 
>> 14-CURRENT(main):
>> yasu@rolling-vm-freebsd1[1006]% uname -a
>> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 
>> 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb  1 10:55:51 JST 2021 
>> ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC
>>   amd64
>> 
>> 13.0-ALPHA3(stable/13):
>> yasu@rolling-vm-freebsd5[1005]% uname -a
>> FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 
>> #0 stable/13-c256214-g40cb0344eb2: Mon Feb  1 11:30:28 JST 2021 
>> ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC
>>   amd64
> 
> I submitted this problem to Bugzilla.
> 
> Bug 253147 - Setting for displaying utf8 characters on all vt consoles
> results in panic on 14-CURRENT and 13.0-ALPHA3
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147 
> 
> 
> ---
> Yasuhiro Kimura

Should be fixed on current now.

thanks,
toomas


___
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: EFI loader doesn't handle md_preload (md_image) correct?

[Toomas Soome via freebsd-stable]

Yes, I still do remember it, just need to find time to port the feature. 

Of course the root cause there is much more complicated (we can not assume to 
have contigous space above 1MB), but we mostly can cope...

Sent from my iPhone

> On 8 Apr 2019, at 09:44, Harry Schmalzbauer  wrote:
> 
>> Am 16.05.2017 um 18:26 schrieb Harry Schmalzbauer:
>> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:20 (localtime):
 On 16. mai 2017, at 19:13, Harry Schmalzbauer  wrote:
 
 Bezüglich Toomas Soome's Nachricht vom 16.05.2017 18:00 (localtime):
>> On 16. mai 2017, at 18:45, Harry Schmalzbauer > > wrote:
>> 
>> Bezüglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 
>> (localtime):
>>> Bezüglich Toomas Soome's Nachricht vom 16.05.2017 16:57 (localtime):
> On 16. mai 2017, at 17:55, Harry Schmalzbauer  > wrote:
> 
> Hello,
> 
> unfortunately I had some trouble with my preferred MFS-root setups.
> It seems EFI loader doesn't handle type md_image correctly.
> 
> If I load any md_image with loader invoked by gptboot or gptzfsboot,
> 'lsmod'
> shows "elf kernel", "elf obj module(s)" and "md_image".
> 
> Using the same loader.conf, but EFI loader, the md_image-file is
> prompted and sems to be loaded, but not registered.  There's no
> md_image
> with 'lsmod', hence it's not astonsihing that kernel doesn't attach 
> md0
> so booting fails since there's no rootfs.
> 
> Any help highly appreciated, hope Toomas doesn't mind beeing
> initially CC'd.
> 
> Thanks,
> 
> -harry
 The first question is, how large is the md_image and what other
 modules are loaded?
>>> Thanks for your quick response.
>>> 
>>> The images are 50-500MB uncompressed (provided by gzip compressed file).
>>> Small ammount of elf modules, 5, each ~50kB.
>> On the real HW, there's vmm and some more:
>> Id Refs Address Size Name
>> 1   46 0x8020   16M kernel
>> 21 0x8121d000   86K unionfs.ko
>> 31 0x81233000  3.1M zfs.ko
>> 42 0x81545000   51K opensolaris.ko
>> 57 0x81552000  279K usb.ko
>> 61 0x81598000   67K ukbd.ko
>> 71 0x815a9000   51K umass.ko
>> 81 0x815b6000   46K aesni.ko
>> 91 0x815c3000   54K uhci.ko
>> 101 0x815d1000   65K ehci.ko
>> 111 0x815e2000   15K cc_htcp.ko
>> 121 0x815e6000  3.4M vmm.ko
>> 131 0xa3a21000   12K ums.ko
>> 141 0xa3a24000  9.1K uhid.ko
>> 
>> Providing md_image uncompressed doesn't change anything.
>> 
>> Will deploy a /usr separated rootfs, which is only ~100MB uncompressed
>> and see if that changes anything.
>> That's all I can provide, code is far beyond my knowledge...
>> 
>> -harry
> 
> The issue is, that current UEFI implementation is using 64MB staging
> memory for loading the kernel and modules and files. When the boot is
> called, the relocation code will put the bits from staging area into the
> final places. The BIOS version does not need such staging area, and that
> will explain the difference.
> 
> I actually have different implementation to address the same problem,
> but thats for illumos case, and will need some work to make it usable
> for freebsd; the idea is actually simple - allocate staging area per
> loaded file and relocate the bits into the place by component, not as
> continuous large chunk (this would also allow to avoid the mines like
> planted by hyperv;), but right now there is no very quick real solution
> other than just build efi loader with larger staging size.
 Ic, thanks for the explanation.
 While not aware about the purpose of the staging area nor the
 consequences of enlarging it, do you think it's feasable increasing it
 to 768Mib?
 
 At least now I have an idea baout the issue and an explanation why
 reducing md_imgae to 100MB hasn't helped – still more than 64...
 
 Any quick hint where to define the staging area size highly appreciated,
 fi there are no hard objections against a 768MB size.
 
 -harry
>>> The problem is that before UEFI Boot Services are not switched off, the 
>>> memory is managed (and owned) by the firmware,
>> Hmm, I've been expecting something like that (owend by firmware) ;-)
>> 
>> So I'll stay with CSM for now, and will happily be an early adopter if
>> you need someone to try anything (-stable mergable).
> 
> Hello Toomas,
> 
> thanks for your ongoing FreeBSD commits, saw your recent libstand 
> improvements and the efiloader commit.
> Which remembers me 

Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome via freebsd-stable]

Yes, that must be true but it does not hurt to get checked.

And of course, lsdev -v from 11.x loader would be good too.

Anyhow, I am afraid we have reached to point where more specific debug info is 
needed (printed out), with lack of output about disks at all, it must be 
related to floppy device checks.

Rgds,
Toomas

Sent from my iPhone

> On 4 Dec 2018, at 22:19, Ian Lepore  wrote:
> 
> On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable
> wrote:
>> 
>>> 
>>> On 4 Dec 2018, at 19:59, Mark Martinec >> i> wrote:
>>> 
>>>> 
>>>>> 
>>>>> 2018-11-29 18:43, Toomas Soome wrote:
>>>>>> 
>>>>>> I just did push biosdisk updates to stable/12, I wonder if
>>>>>> you could
>>>>>> test those bits…
>>> Myself wrote:
>>>> 
>>>>> 
>>>>> Thank you!  I haven't tried it yet, but I wonder whether this
>>>>> fix was
>>>>> already incorporated into 12.0-RC3, which would make my rescue
>>>>> easier.
>>>>> Otherwise I can build a stable/12 on another host and
>>>>> transplant
>>>>> the problematic file(s) to the affected host - if I knew which
>>>>> files
>>>>> to copy.
>>> 2018-12-02 18:59, Toomas wrote:
>>>> 
>>>> The files are /boot/loader* binaries - to be exact, check which
>>>> one is
>>>> linked to /boot/loader. I can provide binaries if needed.
>>>> [...]
>>>> rgds,
>>>> toomas
>>> I got a maintenance window today so I tried with the new loader,
>>> and it did not help.
>>> 
>>> More specifically:
>>> 
>>> As it comes with 12-RC2, the /boot/loader was hard linked with
>>> loader_lua.
>>> Its size is 421888 bytes. So I concentrated on this loader.
>>> 
>>> I build a fresh stable/12 on another host, and copied the newly
>>> built loader_lua (425984 bytes) to the /boot directory of the
>>> affected
>>> host, deleted the file 'loader', and hard-linked loader_lua to
>>> loader.
>>> 
>>> The situation has not changed: the BTX loader lists all BIOS drives
>>> C..J (disk0..disk7), then a spinner starts and gets stuck forever.
>>> It never reaches the 'BIOS 635kB/3537856kB available memory' line.
>>> 
>>> While trying to restore the old /boot from 11.2, I tried booting
>>> a live image from a 12.0-RC3 memory stick - and the loader got
>>> stuck again, same as when booting from a disk.
>>> 
>>> So I had to boot from an 11.2 memstick to be able to regain
>>> control.
>>> 
>>>  Mark
>>> 
>>> 
>> ok, if you could perform 2 tests:
>> 
>> 1. from loader prompt enter 0x413 0xa000 - @w . cr
>> 
>> 2. on first spinner, press space and type on boot: prompt:
>> /boot/loader_4th and see if that will do better
>> thanks,
>> toomas
>> 
> 
> I don't think that will be an option.  If it hasn't gotten to the point
> of saying how much BIOS available memory there is, it's only halfway
> through loader main() and has hung before getting to interact().
> 
> In fact, if that line hasn't printed, but some disk drives have been
> listed, it pretty much has to be hung in the "March through the device
> switch probing for things" loop. If all the disks are listed, then it
> got through that entry in the devsw, and is likely hanging in the
> dv_init calls for either the pxedisk or zfsdev devices.
> 
> -- Ian
> 
>> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> On 29 Nov 2018, at 17:01, Mark Martinec >>>>>> b...@ijs.si> wrote:
>>>>>>> After successfully upgraded three hosts from 11.2-p4 to
>>>>>>> 12.0-RC2 (amd64,
>>>>>>> zfs, bios), I tried my luck with one of our production
>>>>>>> hosts, and ended up
>>>>>>> with a stuck loader after rebooting with a new kernel
>>>>>>> (after the first
>>>>>>> stage of upgrade).
>>>>>>> These were the steps, and all went smoothly and normally
>>>>>>> until a reboot:
>>>>>>> freebsd-update upgrade -r 12.0-RC2
>>>>>>> freebsd-update install
>>>>>>> shutdown -r now
>>>>>>> While booting, the 'BTX loader' comes up, li

Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome via freebsd-stable]

> On 4 Dec 2018, at 19:59, Mark Martinec  wrote:
> 
>>> 2018-11-29 18:43, Toomas Soome wrote:
 I just did push biosdisk updates to stable/12, I wonder if you could
 test those bits…
> 
> Myself wrote:
>>> Thank you!  I haven't tried it yet, but I wonder whether this fix was
>>> already incorporated into 12.0-RC3, which would make my rescue easier.
>>> Otherwise I can build a stable/12 on another host and transplant
>>> the problematic file(s) to the affected host - if I knew which files
>>> to copy.
> 
> 2018-12-02 18:59, Toomas wrote:
>> The files are /boot/loader* binaries - to be exact, check which one is
>> linked to /boot/loader. I can provide binaries if needed.
>> [...]
>> rgds,
>> toomas
> 
> I got a maintenance window today so I tried with the new loader,
> and it did not help.
> 
> More specifically:
> 
> As it comes with 12-RC2, the /boot/loader was hard linked with loader_lua.
> Its size is 421888 bytes. So I concentrated on this loader.
> 
> I build a fresh stable/12 on another host, and copied the newly
> built loader_lua (425984 bytes) to the /boot directory of the affected
> host, deleted the file 'loader', and hard-linked loader_lua to loader.
> 
> The situation has not changed: the BTX loader lists all BIOS drives
> C..J (disk0..disk7), then a spinner starts and gets stuck forever.
> It never reaches the 'BIOS 635kB/3537856kB available memory' line.
> 
> While trying to restore the old /boot from 11.2, I tried booting
> a live image from a 12.0-RC3 memory stick - and the loader got
> stuck again, same as when booting from a disk.
> 
> So I had to boot from an 11.2 memstick to be able to regain control.
> 
>  Mark
> 
> 

ok, if you could perform 2 tests:

1. from loader prompt enter 0x413 0xa000 - @w . cr

2. on first spinner, press space and type on boot: prompt: /boot/loader_4th and 
see if that will do better
thanks,
toomas


> 
> On 29 Nov 2018, at 17:01, Mark Martinec  
> wrote:
> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
> zfs, bios), I tried my luck with one of our production hosts, and ended up
> with a stuck loader after rebooting with a new kernel (after the first
> stage of upgrade).
> These were the steps, and all went smoothly and normally until a reboot:
> freebsd-update upgrade -r 12.0-RC2
> freebsd-update install
> shutdown -r now
> While booting, the 'BTX loader' comes up, lists the BIOS drives,
> then the spinner below the list comes up and begins turning,
> stuttering, and after a couple of seconds it grinds to a standstill
> and nothing happens afterwards.
> At this point the ZFS and the bootstrap loader is supposed to
> come up, but it doesn't.
> This host has too zfs pools, the system pool consists of two SSDs
> in a zfs mirror (also holding a freebsd-boot partition each), the
> other pool is a raidz2 with six JBOD disks on an LSI controller.
> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
> is happy with both pools.
> After rebooting from an USB drive and reverting the /boot directory
> to a previous version, the machine comes up normally again
> with the 11.2-RELEASE-p4.
> I found a file init.core in the / directory, slightly predating the
> last reboot with a salvaged system - although it was probably not
> a cause of the problem, but a consequence of the rescue operation.
> It is unfortunate that this is a production host, so I can't play
> much with it. One or two more quick experiments I can probably
> afford, but not much more. Should I just first wait for the
> official 12.0 release? Should I try booting with a 12.0 on USB
> and try to import pools? Suggestions welcome.
> Now that the /boot has been manually restored to the 11.2 state,
> A SECOND QUESTION is about freebsd-update, which still thinks we are
> in the middle of an upgrade procedure. Trying now to just update
> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
> # uname -a
> FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
> #
> # freebsd-version
> 11.2-RELEASE-p4
> #
> # freebsd-update fetch
> src component not installed, skipped
> You have a partially completed upgrade pending
> Run '/usr/sbin/freebsd-update install' first.
> Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
> So what is the right way to get rid of all traces of the
> unsuccessful upgrade, and let freebsd-update believe we are cleanly
> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
> Mark

___
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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome via freebsd-stable]

> On 2 Dec 2018, at 01:11, Mark Martinec  wrote:
> 
> 2018-11-29 18:43, Toomas Soome wrote:
>> I just did push biosdisk updates to stable/12, I wonder if you could
>> test those bits…
> 
> Thank you!  I haven't tried it yet, but I wonder whether this fix was
> already incorporated into 12.0-RC3, which would make my rescue easier.
> 
> Otherwise I can build a stable/12 on another host and transplant
> the problematic file(s) to the affected host - if I knew which files
> to copy.
> 
> I wonder also, if the today's posting by cksalexan...@q.com on the
> freebsd-stable ML titled "FreeBSD-12.0-RC3-i386-disc1.iso does not boot"
> could be describing the same problem?
> 
>  Mark
> 

The files are /boot/loader* binaries - to be exact, check which one is linked 
to /boot/loader. I can provide binaries if needed.

Can not tell about post in freebsd-stable - it simply does not provide enough 
information.

rgds,
toomas


> 
>>> On 29 Nov 2018, at 17:01, Mark Martinec  
>>> wrote:
>>> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
>>> zfs, bios), I tried my luck with one of our production hosts, and ended up
>>> with a stuck loader after rebooting with a new kernel (after the first
>>> stage of upgrade).
>>> These were the steps, and all went smoothly and normally until a reboot:
>>> freebsd-update upgrade -r 12.0-RC2
>>> freebsd-update install
>>> shutdown -r now
>>> While booting, the 'BTX loader' comes up, lists the BIOS drives,
>>> then the spinner below the list comes up and begins turning,
>>> stuttering, and after a couple of seconds it grinds to a standstill
>>> and nothing happens afterwards.
>>> At this point the ZFS and the bootstrap loader is supposed to
>>> come up, but it doesn't.
>>> This host has too zfs pools, the system pool consists of two SSDs
>>> in a zfs mirror (also holding a freebsd-boot partition each), the
>>> other pool is a raidz2 with six JBOD disks on an LSI controller.
>>> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
>>> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
>>> is happy with both pools.
>>> After rebooting from an USB drive and reverting the /boot directory
>>> to a previous version, the machine comes up normally again
>>> with the 11.2-RELEASE-p4.
>>> I found a file init.core in the / directory, slightly predating the
>>> last reboot with a salvaged system - although it was probably not
>>> a cause of the problem, but a consequence of the rescue operation.
>>> It is unfortunate that this is a production host, so I can't play
>>> much with it. One or two more quick experiments I can probably
>>> afford, but not much more. Should I just first wait for the
>>> official 12.0 release? Should I try booting with a 12.0 on USB
>>> and try to import pools? Suggestions welcome.
>>> Now that the /boot has been manually restored to the 11.2 state,
>>> A SECOND QUESTION is about freebsd-update, which still thinks we are
>>> in the middle of an upgrade procedure. Trying now to just update
>>> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
>>> # uname -a
>>> FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
>>> #
>>> # freebsd-version
>>> 11.2-RELEASE-p4
>>> #
>>> # freebsd-update fetch
>>> src component not installed, skipped
>>> You have a partially completed upgrade pending
>>> Run '/usr/sbin/freebsd-update install' first.
>>> Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
>>> So what is the right way to get rid of all traces of the
>>> unsuccessful upgrade, and let freebsd-update believe we are cleanly
>>> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
>>> Mark
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Toomas Soome via freebsd-stable]

I just did push biosdisk updates to stable/12, I wonder if you could test those 
bits…

rgds,
toomas

> On 29 Nov 2018, at 17:01, Mark Martinec  wrote:
> 
> After successfully upgraded three hosts from 11.2-p4 to 12.0-RC2 (amd64,
> zfs, bios), I tried my luck with one of our production hosts, and ended up
> with a stuck loader after rebooting with a new kernel (after the first
> stage of upgrade).
> 
> These were the steps, and all went smoothly and normally until a reboot:
> 
>  freebsd-update upgrade -r 12.0-RC2
>  freebsd-update install
>  shutdown -r now
> 
> While booting, the 'BTX loader' comes up, lists the BIOS drives,
> then the spinner below the list comes up and begins turning,
> stuttering, and after a couple of seconds it grinds to a standstill
> and nothing happens afterwards.
> 
> At this point the ZFS and the bootstrap loader is supposed to
> come up, but it doesn't.
> 
> This host has too zfs pools, the system pool consists of two SSDs
> in a zfs mirror (also holding a freebsd-boot partition each), the
> other pool is a raidz2 with six JBOD disks on an LSI controller.
> The gptzfsboot in both freebsd-boot partitions is fresh from 11.2,
> both zpool versions are up-to-date with 11.2. The 'zpool status -v'
> is happy with both pools.
> 
> After rebooting from an USB drive and reverting the /boot directory
> to a previous version, the machine comes up normally again
> with the 11.2-RELEASE-p4.
> 
> I found a file init.core in the / directory, slightly predating the
> last reboot with a salvaged system - although it was probably not
> a cause of the problem, but a consequence of the rescue operation.
> 
> It is unfortunate that this is a production host, so I can't play
> much with it. One or two more quick experiments I can probably
> afford, but not much more. Should I just first wait for the
> official 12.0 release? Should I try booting with a 12.0 on USB
> and try to import pools? Suggestions welcome.
> 
> 
> 
> Now that the /boot has been manually restored to the 11.2 state,
> A SECOND QUESTION is about freebsd-update, which still thinks we are
> in the middle of an upgrade procedure. Trying now to just update
> the 11.2-RELEASE-p4 to 11.2-RELEASE-p5, the fetch complains:
> 
>  # uname -a
>  FreeBSD xxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4
>  #
>  # freebsd-version
>  11.2-RELEASE-p4
>  #
>  # freebsd-update fetch
>  src component not installed, skipped
>  You have a partially completed upgrade pending
>  Run '/usr/sbin/freebsd-update install' first.
>  Run '/usr/sbin/freebsd-update fetch -F' to proceed anyway.
> 
> So what is the right way to get rid of all traces of the
> unsuccessful upgrade, and let freebsd-update believe we are cleanly
> at 11.2-p4 ?  Removing /var/db/freebsd-update did not help.
> 
>  Mark
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-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: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot

[Toomas Soome via freebsd-stable]

Note about hw.vga.textmode: this tunable has no meaning for UEFI - first of 
all, there is no API to change to VGA text mode in UEFI, secondly, there may or 
may not be VGA (firmware) at all. We only do land in kernel with linear 
framebuffer mode active and all we have is information about that mode (FB 
address, size and color bits). In *worst* case, it is actually even possible 
that we only have UEFI API for boot loader and no linear framebuffer for kernel.

distorted console after kernel start means that either the kernel efifb driver 
does something wrong, or the console device gfx mode change did happen but the 
FB driver was not properly informed about the fact.

rgds,
toomas


> On 28 Nov 2018, at 11:51, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is 
> latest, r1.22
> from 2013). The E751 is of model series S26391-K326-V100 and equipted with a 
> Core
> i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according to 
> the
> techniscal specifications from Fujitsu.
> 
> Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I 
> could grap from
> the download page), the screen becomes distorted immediately after the kernel 
> has
> loaded and initialised/booted. The screen is at the loader's all right so far.
> 
> Trying to disable graphics mode via escaping to the loader's prompt and 
> setting 
> 
> set hw.vga.textmode=1
> 
> subsequently loading the kernel and then booting, doesn't help. The screen is 
> distorted
> again. The notebook seems UEFI only and doesn't boot off from MBR partioned 
> devices (i.e.
> NanoBSD I used to use).
> 
> Loading /boot/kernel/i915kms.ko
> 
> after manually having loaded /boot/kernel/kernel (and not booted yet) doesn't 
> change
> anything either.
> 
> Booting off and installing Linux (Ubuntu, Mint so far, most revent verions I 
> can get my
> hands on) is no problem. The console works fine from the beginning and so the 
> graphics.
> 
> Is there a chance to get a FreeBSD booting the easy way? 
> 
> The provided boot images do not contain any of the 
> graphics/drm-stable|next|legacy-kmod
> stuff, I tried to load i915kms.ko off from /boot/modules/ (were those modules 
> from the
> ports are supposed to reside) but no chance.
> 
> Before starting investigating this issue further I'd like to ask wether there 
> is a
> general support provided or is that type of notebook dead matter for FreeBSD 
> of the
> modern kind?
> 
> Thanks in advance,
> 
> oh
> 
> p.s. please CC me, I'm not subscribing all lists.
> 
> - -- 
> O. Hartmann
> -BEGIN PGP SIGNATURE-
> 
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY
> lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP
> /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf
> vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg
> =XD7b
> -END PGP SIGNATURE-
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-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: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

[Toomas Soome via freebsd-stable]

> On 23 Oct 2018, at 13:53, Lev Serebryakov  wrote:
> 
> On 22.10.2018 12:27, Toomas Soome wrote:
> 
>> It would help to get output from loader lsdev -v command.
> current loader crashes on "lsdev" for me:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not
> threadripper-related, my hardware is Intel Atom).
> 
> -- 
> // Lev Serebryakov
> 

That error means something is corrupting the memory, it is hard to guess what 
exactly and debugging it is nasty - it means we would need to track down what 
was allocated before this memory block (guard1 is marker inserted in front of 
the allocated memory block). 

Fortunately the code to print the partition table is in stand/common/disk.c and 
the partition code is just next to it and so it should be relatively easy to 
find the guilty one… I will try to see if I can replicate the issue.

rgds,
toomas
___
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: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

[Toomas Soome via freebsd-stable]

> On 22 Oct 2018, at 13:58, Mark Millard  wrote:
> 
> On 2018-Oct-22, at 2:27 AM, Toomas Soome http://me.com/>> 
> wrote:
>> 
>>> On 22 Oct 2018, at 06:30, Warner Losh  wrote:
>>> 
>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh  wrote:
>>> 
 
 
 On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable <
 freebsd-stable@freebsd.org> wrote:
 
> [I built based on WITHOUT_ZFS= for other reasons. But,
> after installing the build, Hyper-V based boots are
> working.]
> 
> On 2018-Oct-20, at 2:09 AM, Mark Millard  wrote:
> 
>> On 2018-Oct-20, at 1:39 AM, Mark Millard  wrote:
>> 
>>> I attempted to jump from head -r334014 to -r339076
>>> on a threadripper 1950X board and the boot fails.
>>> This is both native booting and under Hyper-V,
>>> same machine and root file system in both cases.
>> 
>> I did my investigation under Hyper-V after seeing
>> a boot failure native.
>> 
>> Looks like the native failure is even earlier,
>> before db> is even possible, possibly during
>> early loader activity.
>> 
>> So this report is really for running under
>> Hyper-V: -r338804 boots and -r338810 does
>> not. By contrast -r334804 does not boot native.
>> (But I've little information for that context.)
>> 
>> Sorry for the confusion. I rushed the report
>> in hopes of getting to sleep. It was not to be.
>> 
>>> It fails just after the FreeBSD/SMP lines,
>>> reporting "kernel trap 9 with interrupts disabled".
>>> 
>>> It fails in pmap_force_invaldiate_cache_range at
>>> a clflusl (%rax) instruction that produces a
>>> "Fatal trap 9: general protection fault while
>>> in kernel mode". cpudid=0 apic id= 00
>>> 
>>> I used kernel.txz files from:
>>> 
>>> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/
>>> 
>>> to narrow the range of kernel builds for working -> failing
>>> and got:
>>> 
>>> -r338804 boots fine
>>> (no amd64 kernel builds between to try)
>>> -r338810+ fails (any that I tried, anyway)
>>> 
>>> In that range is -r338807 :
>>> 
>>> QUOTE
>>> Author: kib
>>> Date: Wed Sep 19 19:35:02 2018
>>> New Revision: 338807
>>> URL:
>>> https://svnweb.freebsd.org/changeset/base/338807
>>> 
>>> 
>>> Log:
>>> Convert x86 cache invalidation functions to ifuncs.
>>> 
>>> This simplifies the runtime logic and reduces the number of
>>> runtime-constant branches.
>>> 
>>> Reviewed by: alc, markj
>>> Sponsored by:The FreeBSD Foundation
>>> Approved by: re (gjb)
>>> Differential revision:
>>> https://reviews.freebsd.org/D16736
>>> 
>>> Modified:
>>> head/sys/amd64/amd64/pmap.c
>>> head/sys/amd64/include/pmap.h
>>> head/sys/dev/drm2/drm_os_freebsd.c
>>> head/sys/dev/drm2/i915/intel_ringbuffer.c
>>> head/sys/i386/i386/pmap.c
>>> head/sys/i386/i386/vm_machdep.c
>>> head/sys/i386/include/pmap.h
>>> head/sys/x86/iommu/intel_utils.c
>>> END QUOTE
>>> 
>>> There do seem to be changes associated with
>>> clflush(...) use. Looking at:
>>> 
>>> 
> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432
>>> 
>>> it appears that pmap_force_invalidate_cache_range has not
>>> changed since -r338807.
>>> 
>>> It seems that -r338806 and -r3388810 would be unlikely
>>> contributors.
>> 
> 
> I went after my native-boot loader problem first because I
> could switch kernels via the loader for booting FreeBSD under
> Hyper-V. Switching loaders is more of a problem.
> 
> In order to avoid the loader-time crash I switched to building
> installing based on WITHOUT_ZFS= . I've had no active use of
> ZFS in years. (The old official-build loaders that worked were
> non-ZFS ones.)
> 
> This took care of the native-boot loader-crash --and, to my
> surprise, also the Hyper-V-boot kernel-time crash.
> 
> My private builds now boot the 1950X in both contexts just
> fine.
> 
> During my early investigation I did pick up specific changes
> from after -r339076 that seemed to be tied to Ryzen and such.
> (They made no difference to the boot problems at the time
> but I saw no reason to remove them.)
> 
> # uname -apKU
> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun
> Oct 21 16:44:25 PDT 2018 
> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
> amd64 amd64 1200084 1200084
 
 
>>> (stupid gmail)
>>> 
>>> The phrase "no active use" bothers me. What does that mean? Are there any
>>> ZFS pools or any disks that any whiff of ZFSish thing on it at all?
>>> Clearly, there's something in the zfs boot loader that's freaking out by
>>> something on your system, but absent 

Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated

[Toomas Soome via freebsd-stable]

> On 22 Oct 2018, at 06:30, Warner Losh  wrote:
> 
> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh  > wrote:
> 
>> 
>> 
>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable <
>> freebsd-stable@freebsd.org> wrote:
>> 
>>> [I built based on WITHOUT_ZFS= for other reasons. But,
>>> after installing the build, Hyper-V based boots are
>>> working.]
>>> 
>>> On 2018-Oct-20, at 2:09 AM, Mark Millard  wrote:
>>> 
 On 2018-Oct-20, at 1:39 AM, Mark Millard  wrote:
 
> I attempted to jump from head -r334014 to -r339076
> on a threadripper 1950X board and the boot fails.
> This is both native booting and under Hyper-V,
> same machine and root file system in both cases.
 
 I did my investigation under Hyper-V after seeing
 a boot failure native.
 
 Looks like the native failure is even earlier,
 before db> is even possible, possibly during
 early loader activity.
 
 So this report is really for running under
 Hyper-V: -r338804 boots and -r338810 does
 not. By contrast -r334804 does not boot native.
 (But I've little information for that context.)
 
 Sorry for the confusion. I rushed the report
 in hopes of getting to sleep. It was not to be.
 
> It fails just after the FreeBSD/SMP lines,
> reporting "kernel trap 9 with interrupts disabled".
> 
> It fails in pmap_force_invaldiate_cache_range at
> a clflusl (%rax) instruction that produces a
> "Fatal trap 9: general protection fault while
> in kernel mode". cpudid=0 apic id= 00
> 
> I used kernel.txz files from:
> 
> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/
> 
> to narrow the range of kernel builds for working -> failing
> and got:
> 
> -r338804 boots fine
> (no amd64 kernel builds between to try)
> -r338810+ fails (any that I tried, anyway)
> 
> In that range is -r338807 :
> 
> QUOTE
> Author: kib
> Date: Wed Sep 19 19:35:02 2018
> New Revision: 338807
> URL:
> https://svnweb.freebsd.org/changeset/base/338807
> 
> 
> Log:
> Convert x86 cache invalidation functions to ifuncs.
> 
> This simplifies the runtime logic and reduces the number of
> runtime-constant branches.
> 
> Reviewed by: alc, markj
> Sponsored by:The FreeBSD Foundation
> Approved by: re (gjb)
> Differential revision:
> https://reviews.freebsd.org/D16736
> 
> Modified:
> head/sys/amd64/amd64/pmap.c
> head/sys/amd64/include/pmap.h
> head/sys/dev/drm2/drm_os_freebsd.c
> head/sys/dev/drm2/i915/intel_ringbuffer.c
> head/sys/i386/i386/pmap.c
> head/sys/i386/i386/vm_machdep.c
> head/sys/i386/include/pmap.h
> head/sys/x86/iommu/intel_utils.c
> END QUOTE
> 
> There do seem to be changes associated with
> clflush(...) use. Looking at:
> 
> 
>>> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432
> 
> it appears that pmap_force_invalidate_cache_range has not
> changed since -r338807.
> 
> It seems that -r338806 and -r3388810 would be unlikely
> contributors.
 
>>> 
>>> I went after my native-boot loader problem first because I
>>> could switch kernels via the loader for booting FreeBSD under
>>> Hyper-V. Switching loaders is more of a problem.
>>> 
>>> In order to avoid the loader-time crash I switched to building
>>> installing based on WITHOUT_ZFS= . I've had no active use of
>>> ZFS in years. (The old official-build loaders that worked were
>>> non-ZFS ones.)
>>> 
>>> This took care of the native-boot loader-crash --and, to my
>>> surprise, also the Hyper-V-boot kernel-time crash.
>>> 
>>> My private builds now boot the 1950X in both contexts just
>>> fine.
>>> 
>>> During my early investigation I did pick up specific changes
>>> from after -r339076 that seemed to be tied to Ryzen and such.
>>> (They made no difference to the boot problems at the time
>>> but I saw no reason to remove them.)
>>> 
>>> # uname -apKU
>>> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun
>>> Oct 21 16:44:25 PDT 2018 
>>> markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
>>> amd64 amd64 1200084 1200084
>> 
>> 
> (stupid gmail)
> 
> The phrase "no active use" bothers me. What does that mean? Are there any
> ZFS pools or any disks that any whiff of ZFSish thing on it at all?
> Clearly, there's something in the zfs boot loader that's freaking out by
> something on your system, but absent that information I can't help you.
> 

It would help to get output from loader lsdev -v command. Also if you could 
test boot loader with UEFI - for example get to loader prompt via usb/cd boot 
and then get the same lsdev -v output. I would be interested to see the sector 
size information and if the UEFI loader does also have issues. If it does, I’d 
like to see the