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
|
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
|
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.
|
D510MO and D945GCLF images not included either, due to lack of testing.
|
||||||
|
|
||||||
*All other boards have ROM images in this release.*
|
*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.
|
the last Canoeboot release, so I decided to another quick one.
|
||||||
|
|
||||||
That is all.
|
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