call for testing

call for testing

[cinap_lenrek]

i'v just pushed the new memory map code for pc and pc64 kernels:

http://code.9front.org/hg/plan9front/rev/7eba9c247d5d

i'v tested the code on qemu, vmware, t495, x230, x200 and t23
thinkpads and it works without issues for me.

however, this is a tricky part of code and the new memory map
code differs in reserving region types (now it uses strict
priorities: Reserved > ACPI > RAM > UMB > UPA). it is possible
that some machines just worked by accident before and now stop
booting.

so if you can, i'd like to encurage you to help test this by
just booting the current pc or pc64 kernel and see if it can
still boot.

on the plus side, the new code should be more robust against
broken uefi and bios memory maps. it works by delaying user
memory allocation until the acpi tables have been discovered
and mapped out. this means it can work around acpi tables
overlapping usable memory which might have prevented us booting
before (this is the case on the new lenovo t495 which motivated
the change).

so now would also be a good time to try these machines again.

--
cinap

Re: [9front] call for testing

[Juan Cuzmar]

My tablet samsung booted fine.

On Sat, Apr 4, 2020 at 2:40 PM <cinap_lenrek@felloff.net> wrote:
>
> i'v just pushed the new memory map code for pc and pc64 kernels:
>
> http://code.9front.org/hg/plan9front/rev/7eba9c247d5d
>
> i'v tested the code on qemu, vmware, t495, x230, x200 and t23
> thinkpads and it works without issues for me.
>
> however, this is a tricky part of code and the new memory map
> code differs in reserving region types (now it uses strict
> priorities: Reserved > ACPI > RAM > UMB > UPA). it is possible
> that some machines just worked by accident before and now stop
> booting.
>
> so if you can, i'd like to encurage you to help test this by
> just booting the current pc or pc64 kernel and see if it can
> still boot.
>
> on the plus side, the new code should be more robust against
> broken uefi and bios memory maps. it works by delaying user
> memory allocation until the acpi tables have been discovered
> and mapped out. this means it can work around acpi tables
> overlapping usable memory which might have prevented us booting
> before (this is the case on the new lenovo t495 which motivated
> the change).
>
> so now would also be a good time to try these machines again.
>
> --
> cinap

Re: [9front] call for testing

[ori]

> i'v just pushed the new memory map code for pc and pc64 kernels:
> 
> http://code.9front.org/hg/plan9front/rev/7eba9c247d5d
> 
> i'v tested the code on qemu, vmware, t495, x230, x200 and t23
> thinkpads and it works without issues for me.
> 

Works for me on x260. Have a couple more machines to test
on later too.

Re: [9front] call for testing

[mike]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

My results:

sys		pc			pc64

x201	ok			ok
x220	ok			ok
t420	fail		ok
t430	ok			ok
t430s	ok			ok
t500	ok			ok
t510	ok			ok
t43p	ok			-
t60		ok			-
a30		ok			-

I've attached a screenshot of the machine/kernel combo that failed to boot. Hope that helps.

[-- Attachment #2: Type: message/rfc822, Size: 2371 bytes --]

From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: [9front] call for testing
Date: Sat, 4 Apr 2020 19:39:50 +0200
Message-ID: <05E00F0CC340421AEDA9D66E230C7510@felloff.net>

i'v just pushed the new memory map code for pc and pc64 kernels:

http://code.9front.org/hg/plan9front/rev/7eba9c247d5d

i'v tested the code on qemu, vmware, t495, x230, x200 and t23
thinkpads and it works without issues for me.

however, this is a tricky part of code and the new memory map
code differs in reserving region types (now it uses strict
priorities: Reserved > ACPI > RAM > UMB > UPA). it is possible
that some machines just worked by accident before and now stop
booting.

so if you can, i'd like to encurage you to help test this by
just booting the current pc or pc64 kernel and see if it can
still boot.

on the plus side, the new code should be more robust against
broken uefi and bios memory maps. it works by delaying user
memory allocation until the acpi tables have been discovered
and mapped out. this means it can work around acpi tables
overlapping usable memory which might have prevented us booting
before (this is the case on the new lenovo t495 which motivated
the change).

so now would also be a good time to try these machines again.

--
cinap

[-- Attachment #3: bootfail-t420-9pc.png --]
[-- Type: image/png, Size: 336747 bytes --]

Re: [9front] call for testing

[stevie]

hello,

no problems on my thin clients which are all running 9front.
For now I've tested the new kernel on:

- Fujitsu Siemens S700	9pc64
- HP t620				9pc64
- Fujitsu Siemens A250	9pc

The only difference I observed were these qlock messages on
the HP t620:

sdE1: LLBA 31,277,232 sectors
  SanDisk SDSA6MM-016G-1006 U221006 144226401249 [newdrive]
ehci 0xffffff00feb6a000: polling
qlock: 0xffffffff8020ffa0: ilockdepth 1
qlock: 0xffffffff8020ffa0: nlocks 1
user[glenda]: 

Re: [9front] call for testing

[Iruatã Souza]

hi,

9pc and 9pc64 booting fine on a Dell XPS 13 9370.

On Mon, Apr 6, 2020 at 4:31 PM <stevie@kamalatta.ddnss.de> wrote:
>
> hello,
>
> no problems on my thin clients which are all running 9front.
> For now I've tested the new kernel on:
>
> - Fujitsu Siemens S700  9pc64
> - HP t620                               9pc64
> - Fujitsu Siemens A250  9pc
>
> The only difference I observed were these qlock messages on
> the HP t620:
>
> sdE1: LLBA 31,277,232 sectors
>   SanDisk SDSA6MM-016G-1006 U221006 144226401249 [newdrive]
> ehci 0xffffff00feb6a000: polling
> qlock: 0xffffffff8020ffa0: ilockdepth 1
> qlock: 0xffffffff8020ffa0: nlocks 1
> user[glenda]:
>

Re: [9front] call for testing

[Ethan Gardener]

R400.
Atomic batteries to power.
Turbines to speed.
Ready to move out.

Re: [9front] call for testing

[sl]

working well on thinkpad x250.

sl