Leah Rowe
parent
6036db04fe
commit
4c27f0bff5
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: Contatti
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
Supporto utenti
|
||||
===============
|
||||
|
||||
IRC o Reddit sono consigliati, sebbene preferiamo che usi il canale IRC
|
||||
per avere o per offrire supporto tecnico. Continua a leggere per avere
|
||||
ulteriori informazioni.
|
||||
|
||||
Mailing list
|
||||
============
|
||||
|
||||
No mailing lists at present.
|
||||
|
||||
Discussione sullo sviluppo
|
||||
==========================
|
||||
|
||||
Per ora dai un occhiata sulla
|
||||
[pagina Git](git.md) per avere maggiori informazioni su come puoi
|
||||
assistere con lo sviluppo.
|
||||
|
||||
Su quella stessa pagina puoi trovare informazioni su come inviare
|
||||
correzioni (patches) tramite pull requests.
|
||||
|
||||
Canale IRC
|
||||
==========
|
||||
|
||||
IRC e' il modo principale per contattare chi collabora con il progetto Canoeboot.
|
||||
Il canale ufficiale e' `#canoeboot` su Libera IRC.
|
||||
|
||||
Webchat:
|
||||
<https://web.libera.chat/#canoeboot>
|
||||
|
||||
Libera e' una tra le piu' grandi reti IRC usate per i progetti di software libero.
|
||||
Maggiori informazioni le trovi qui: <https://libera.chat/>
|
||||
|
||||
Puoi usare il client IRC che preferisci (come weechat or irssi) usando le seguenti informazioni:
|
||||
|
||||
* Server: `irc.libera.chat`
|
||||
* Canale: `#canoeboot`
|
||||
* Porta (TLS): `6697`
|
||||
* Porta (non-TLS): `6667`
|
||||
|
||||
Ti suggeriamo di usare la porta `6697` e ablitare la cifratura TLS...
|
||||
|
||||
Inoltre ti suggeriamo di abilitare l'autenticazione SASL. Le pagine web
|
||||
di Libera spiegano come:
|
||||
|
||||
* Guida per WeeChat: <https://libera.chat/guides/weechat>
|
||||
* Guida per Irssi: <https://libera.chat/guides/irssi>
|
||||
* Guida per HexChat: <https://libera.chat/guides/hexchat>
|
||||
|
||||
Comunque dovresti sempre controllare la documentazione del tuo client IRC preferito.
|
||||
|
||||
Reti sociali online
|
||||
===================
|
||||
|
||||
Canoeboot esiste ufficialmente in molte piattaforme.
|
||||
|
||||
Mastodon
|
||||
--------
|
||||
|
||||
Il fondatore e sviluppatore principale, Leah Rowe, e' su Mastodon:
|
||||
|
||||
* <https://mas.to/@libreleah>
|
||||
|
||||
Posta elettronica
|
||||
-----------------
|
||||
|
||||
Leah puo' essere contattata anche via email a questo indirizzo:
|
||||
[leah@libreboot.org](mailto:leah@libreboot.org)
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
title: Dell Latitude thermal throttling
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
On some Dell Latitude laptops, you may encounter random shutdowns on
|
||||
heavy load. We believe this is because the SMSC EC is overly conservative
|
||||
by default; it is in charge of handling thermals and fan control on this
|
||||
machine. Our theory is that coreboot needs to write certain EC commands
|
||||
to allow higher temperatures; please read:
|
||||
|
||||
<https://codeberg.org/libreboot/lbmk/issues/202> (NOTE: libreboot issue page,
|
||||
no point duplicating in Canoeboot. Fixes in Libreboot that are suitable for
|
||||
Canoeboot get put in Canoeboot anyway)
|
||||
|
||||
Basically, what you need to do is:
|
||||
|
||||
* Use high quality thermal paste (don't use the same dried up paste that the
|
||||
laptop came with, if you bought it on ebay for example). Arctic MX-6 is good.
|
||||
* Check that the fan works reliably
|
||||
|
||||
Also: the `intel_pstate` driver can be used to artifically cap CPU speed. See:
|
||||
|
||||
<https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html>
|
||||
|
||||
When you use this machine, it is recommended that you cap the CPU speed once
|
||||
you've booted into Linux. Set it to something like 50% at first. Then run a
|
||||
stress test, for example:
|
||||
|
||||
stress -c x
|
||||
|
||||
Where `x` is the number of CPU cores, e.g. 2. Monitor the temperatures using
|
||||
something like `xsensors`, making sure the CPU doesn't exceed 80c temperature.
|
||||
|
||||
You can also monitor CPU speeds in Linux like so:
|
||||
|
||||
watch -n .2 grep MHz /proc/cpuinfo
|
||||
|
||||
This will let you know what speed you're at. You can use this to determine
|
||||
whether the `intel_pstate` driver is working. How to cap speed to 50 percent, as
|
||||
in the above example:
|
||||
|
||||
echo 50 > /sys/devices/system/cpu/cpufreq/intel_pstate/max_perf_pct
|
||||
|
||||
Gradually increase the CPU speed (up to 100 on `max_perf_pct`), waiting a few
|
||||
minutes each time. You should ensure that your machine does not exceed 80C.
|
||||
|
||||
Dell's thermal safety is far too protective by default, on some of these, and
|
||||
we don't yet know how to properly configure it. Running a CPU below 80c in
|
||||
temperature and never higher than that, is a good idea anyway, for the
|
||||
long term life of your CPU.
|
||||
|
||||
Regardless, thermal shutdown is extremely reliable on this machine, but Dell
|
||||
makes it shut down *earlier*, before it can even start to CPU throttle.
|
||||
|
|
@ -3,53 +3,6 @@ title: Installation instructions
|
|||
x-toc-enable: true
|
||||
...
|
||||
|
||||
**GRUB payload warning**
|
||||
====================
|
||||
|
||||
Firstly, it should be stated: in almost all cases, GRUB works just fine, on
|
||||
all of the machines that we test, but as of 26 May 2024 we got the error
|
||||
report:
|
||||
|
||||
See: <https://codeberg.org/libreboot/lbmk/issues/216>
|
||||
|
||||
We've seen this elsewhere too, always on Sandybridge-based Dell Latitude
|
||||
laptops, which Canoeboot doesn't support anyway (the above report is for
|
||||
Libreboot, upon which Canoeboot is based), but:
|
||||
|
||||
Although we've only seen this thus far (as per user reports) on Intel
|
||||
SandyBridge based Dell Latitude laptops, we advise:
|
||||
|
||||
**DO NOT use a ROM image where GRUB is the first payload. If you want to
|
||||
use the GRUB payload, please use a ROM image with `seabios_` at the start
|
||||
of the file name. Avoid images with `grub_` at the start of the file name.**
|
||||
|
||||
ROM images with `grubonly` in them should also be avoided; if you want GRUB
|
||||
to be the first thing you see (without interruption), use a ROM image
|
||||
with `seabios_` at the start of the file name, and `grubfirst` at the end;
|
||||
these place a bootorder file in CBFS, so that SeaBIOS loads GRUB first, but
|
||||
you can still press ESC to bring up the SeaBIOS boot select menu.
|
||||
|
||||
*This warning applies to Canoeboot 20240504/20240510 and other recent releases.*
|
||||
|
||||
**We have since fully mitigated this bug**; SeaBIOS is now the primary payload on
|
||||
all boards, with GRUB still available in the boot select menu, and we have
|
||||
identified that it was caused by the xHCI driver which has since been removed
|
||||
for the affected machines(machines which don't have xHCI anyway, but they
|
||||
touch code that does run on the given machines). The xHCI support works fine
|
||||
on some newer machines and will be re-added there by making GRUB multi-tree,
|
||||
so that different boards can use different versions of GRUB. This will be done,
|
||||
and present in the next Canoeboot release after 20240510, in addition to fixing
|
||||
the actual bug itself. **For now, there are no problems!**
|
||||
|
||||
Canoeboot releases after 20240510 will *only* (on x86) contain ROM images where
|
||||
SeaBIOS is the first payload, without disabling the SeaBIOS menu (no `grubonly`). You'll still be able to use GRUB, either by pressing ESC for the boot
|
||||
select menu, and/or using an image with `grubfirst` in the file name so that
|
||||
SeaBIOS loads it first (while still permitting boot select via ESC keypress).
|
||||
|
||||
GRUB's code is vast, and complicated, so this policy change is permanent,
|
||||
until GRUB can be well-audited (likely forked, with dead/legacy code removed).
|
||||
SeaBIOS code is much smaller and more robust. Remember always: code equals bugs.
|
||||
|
||||
Flashprog
|
||||
=========
|
||||
|
||||
|
|
|
|||
|
|
@ -466,3 +466,53 @@ All of the following boards have been disabled in the build system:
|
|||
D510MO and D945GCLF images not included either, due to lack of testing.
|
||||
|
||||
*All other boards have ROM images in this release.*
|
||||
|
||||
Errata
|
||||
======
|
||||
|
||||
See: <https://codeberg.org/libreboot/lbmk/issues/216>
|
||||
|
||||
This bug has been *fixed* in lbmk.git, and the fix will be included in
|
||||
the next release, but it wasn't caught in the 20240504 release. The same
|
||||
fix has been applied to Canoeboot's build system, cbmk.
|
||||
|
||||
It is almost certainly guaranteed that *no* Canoeboot users were ever
|
||||
affected by this, but extreme measures have been taken to ensure that it
|
||||
is *entirely* guaranteed from now on. Read on to know more:
|
||||
|
||||
The bug is quite serious, and it was previously decided that documentation
|
||||
should be written warning about it (in docs/install/). The bug was *only*
|
||||
triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never
|
||||
reported on other boards, but there's no way to fully know; what is known
|
||||
is that the offending patch that caused the bug has been *removed*; namely,
|
||||
xHCI GRUB patches, which are now only provided on Haswell and Broadwell
|
||||
hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the
|
||||
GRUB tree with xHCI support is provided, but not currently used on any
|
||||
mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
|
||||
|
||||
The next release will exclude xHCI support on machines that don't need it, which
|
||||
is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510),
|
||||
and a mitigation is in place that makes SeaBIOS the primary payload, to prevent
|
||||
effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the
|
||||
first payload then the machine remains bootable even if a similar bug occurs.
|
||||
|
||||
It is now the default behaviour, in the next release, that certain images
|
||||
contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
|
||||
still press ESC to access the SeaBIOS boot menu if you want to directly boot
|
||||
an OS from that. This, and the other change mentioned above, will guarantee
|
||||
stability. GRUB is *no longer* the primary payload, on any mainboard.
|
||||
|
||||
However, it was later decided to put this release in the `testing`
|
||||
directory instead; it was initially designated as a stable release.
|
||||
|
||||
All ROM images for the 20240504/20240510 releases have been *removed* from
|
||||
rsync, but the source tarball remains in place.
|
||||
|
||||
For now, you are advised to use the November 2023 release, or build from
|
||||
cbmk.git at revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` (which is known
|
||||
to be reliable and is the current revision as of this time of writing) - or,
|
||||
alternatively, you are advised to use the next release after 20240510.
|
||||
|
||||
A new [audit](audit1.md) has been conducted, marked complete as of 9 June 2024,
|
||||
fixing this and many issues; a new *true* stable release will be made available
|
||||
some time in June 2024.
|
||||
|
|
|
|||
|
|
@ -148,3 +148,53 @@ Again, very minor release. I wasn't fully happy with the last one, specifically
|
|||
the last Canoeboot release, so I decided to another quick one.
|
||||
|
||||
That is all.
|
||||
|
||||
Errata
|
||||
======
|
||||
|
||||
See: <https://codeberg.org/libreboot/lbmk/issues/216>
|
||||
|
||||
This bug has been *fixed* in lbmk.git, and the fix will be included in
|
||||
the next release, but it wasn't caught in the 20240504 release. The same
|
||||
fix has been applied to Canoeboot's build system, cbmk.
|
||||
|
||||
It is almost certainly guaranteed that *no* Canoeboot users were ever
|
||||
affected by this, but extreme measures have been taken to ensure that it
|
||||
is *entirely* guaranteed from now on. Read on to know more:
|
||||
|
||||
The bug is quite serious, and it was previously decided that documentation
|
||||
should be written warning about it (in docs/install/). The bug was *only*
|
||||
triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never
|
||||
reported on other boards, but there's no way to fully know; what is known
|
||||
is that the offending patch that caused the bug has been *removed*; namely,
|
||||
xHCI GRUB patches, which are now only provided on Haswell and Broadwell
|
||||
hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the
|
||||
GRUB tree with xHCI support is provided, but not currently used on any
|
||||
mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.**
|
||||
|
||||
The next release will exclude xHCI support on machines that don't need it, which
|
||||
is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510),
|
||||
and a mitigation is in place that makes SeaBIOS the primary payload, to prevent
|
||||
effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the
|
||||
first payload then the machine remains bootable even if a similar bug occurs.
|
||||
|
||||
It is now the default behaviour, in the next release, that certain images
|
||||
contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can
|
||||
still press ESC to access the SeaBIOS boot menu if you want to directly boot
|
||||
an OS from that. This, and the other change mentioned above, will guarantee
|
||||
stability. GRUB is *no longer* the primary payload, on any mainboard.
|
||||
|
||||
However, it was later decided to put this release in the `testing`
|
||||
directory instead; it was initially designated as a stable release.
|
||||
|
||||
All ROM images for the 20240504/20240510 releases have been *removed* from
|
||||
rsync, but the source tarball remains in place.
|
||||
|
||||
For now, you are advised to use the November 2023 release, or build from
|
||||
cbmk.git at revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` (which is known
|
||||
to be reliable and is the current revision as of this time of writing) - or,
|
||||
alternatively, you are advised to use the next release after 20240510.
|
||||
|
||||
A new [audit](audit1.md) has been conducted, marked complete as of 9 June 2024,
|
||||
fixing this and many issues; a new *true* stable release will be made available
|
||||
some time in June 2024.
|
||||
|
|
|
|||
Loading…
Reference in New Issue